[MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07

[Bo Burman <[e-mail]>]

WG, Authors,

 

I've reviewed draft-ietf-mmusic-t140-usage-data-channel-07 as part of the
shepherd's review performed by the chairs. Please address these comments
together with any comments from the formal shepherd (Flemming).

 

I think the document is in pretty good shape, but have a number of comments:

1.	In section 1, note 1, with "WebRTC term", do you mean that "T.140
data channel" is introduced in WebRTC specifications? Or should it be "This
T.140 data channel term in WebRTC context."? If not, in what way is it a
"WebRTC term", which I interpret as something belonging to or being
originated from WebRTC?
2.	In the same note 1, suggest to change "actually synonym to" to
"technically equivalent to" or "technically similar to". If you think that
would not be appropriate, please elaborate on in what way it is synonym.
3.	In section 4.2.1, it says that "If the 'fmtp' attribute is not
included, it indicates that no maximum character transmission rate is
indicated.  It does not mean that the default value of 30 applies"; why is
this deviation from RFC 4103 chosen? Does it introduce a risk for
interoperability problems with systems that also doesn't use fmtp but
interprets it as maximum 30 cps?
4.	In section 4.2.3.1.1, for the 'inactive' case, it is unclear to me
in which cases a t140 data channel would be opened but not used. Why open
the channel in the first place when a new SDP O/A is anyway needed to change
'inactive' to something else? I'm however OK to keep it for completeness and
it shouldn't do any harm if kept, but a clarification would be helpful.
5.	In section 5.5, in the note, it says '.with limitations in real-time
performance and presentation style'; I think it would be helpful to briefly
elaborate on what type of limitations would be expected and why.
6.	In section 6, bullet "If the gateway detects or suspects loss of
data on the RTP stream."; shouldn't it await possible redundancy first and
missing text marker is inserted only when the used redundancy is not capable
to repair the loss?
7.	In section 6, bullet "If the gateway detects that the T.140 data
channel has failed"; what about if the RTP stream has failed and was
reestablished? Shouldn't missing text markers be inserted by the gateway
then too?
8.	In section 7, you mention "subprotocol"; do you mean the "dcmap"
line subprotocol parameter?
9.	In section 7, the ".MUST specify the modality for that subprotocol."
seems like a general update to 8374 that is not specific or exclusive to
T.140? I'm not convinced making such statement is within the scope of this
document.
10.	In section 8, you reference draft-ietf-rtcweb-data-channel and
draft-ietf-mmusic-data-channel-sdpneg; are there any additional
T.140-specific considerations, e.g. related to T.140 use of -sdpneg? If not,
it could be helpful to say so.
11.	In section 9.2, 9.3, and 9.4, please change all occurrences of
"MMUSIC Chairs" to "IESG" and "[e-mail]" to "[e-mail]",
since IESG is expected to persist longer than any individual WG.
12.	In section 11.1, in the [T140ad1] reference, is "aEUR" really part
of the name? The name I find listed on the ITU-T web is "ITU-T T.140 (1998)
Add. 1 (02/2000)", and the title in the document itself seems to be
"Protocol for multimedia application text conversation; Addendum 1".

 

Editorial comments/nits:

a.	In section 1, note 2, suggest to change:
Old: ".over a data channel, instead of using RTP based transport [RFC4103],
in WebRTC is constituted by use-case."
New: ".over a data channel in WebRTC, instead of using RTP based transport
[RFC4103], is motivated by use-case."
b.	Section 4.2.3: "negotite" -> "negotiate"
c.	Section 4.2.3.1; Is this extra level heading needed? It's not a
strong opinion but the resulting 5 levels is a bit deep and section 4.2.3 is
already "Real-time Text Direction", so it should be clear that having
"Generating an Offer" etc. sub-headings apply to SDP negotiation.
d.	In section 4.2.3.1.1, "neither send or" -> "neither send nor"
e.	In section 4.2.3.1.1, "a 'inactive'" -> "an 'inactive'"
f.	In section 4.2.3.1.1, in the part to move (above), suggest to change
".not support the procedures in." to ".not support the text direction
procedures in.".
g.	In section 4.2.3.1.1, the last part of the section describes when
the offerer receives an answer to the offer and doesn't fit under
"Generating an Offer"; suggest moving that text to a separate clause
'4.2.3.1.3 Offerer Receiving an Answer'.
h.	In section 4.3, suggest changing 'The maximum character transmission
rate is set to 20, and the default text transmission direction "sendrecv",
apply' to 'The maximum character transmission rate is set to 20 and the
default text transmission direction "sendrecv" applies'.
i.	In section 5.4, in the note, remove duplicate 'the'.
j.	In section 5.5, in the note, "are able present" -> "are able to
present".
k.	In section 6, suggest changing "packet switched" ->
"packet-switched" and "circuit switched" -> "circuit-switched"
l.	In section 6, suggest consider removing "etc" after "obsoleted", or
elaborate more.
m.	In section 6, the last note, suggest changing ".a mechanism to
provide such end-to-end encryption has not been defined" to ".no mechanism
to provide such end-to-end encryption is defined".
n.	In section 7, "retreive" -> "retrieve".

 

Datatracker also finds the following nits
<https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draf
t-ietf-mmusic-t140-usage-data-channel-07.txt> :

*	The "Updates: " line should list only the numbers of the updated
RFCs; change "RFC8373" to "8373". 
*	In section 4.2.1, a reference is made to "[Section 6]", which is a
document-internal reference and should remove the "[ ]".

 

Thanks,

/Bo

MMUSIC co-chair