[MMUSIC] AD Review: draft-ietf-mmusic-t140-usage-data-channel

[Adam Roach <[e-mail]>]

This is my AD review for draft-ietf-mmusic-t140-usage-data-channel-11.
Thanks to the working group and author for the work put into this
document. I don't see any showstoppers that prevent IETF last call,
so I will be requesting that momentarily. I do have a handful of
minor comments on the document that should be addressed along with any
other IETF last-call comments.

/a

---------------------------------------------------------------------------

Abstract:

 >  The
 >  document updates RFC 8373.

Given the relatively simple nature of the update, it may be useful to
consumers of the Abstract to briefly indicate the nature of the change; 
e.g.:

"This document updates RFC 8373 to specify its use with WebRTC 
Datachannels."

---------------------------------------------------------------------------

§1:

 >  and how the SDP offer/answer mechanism
 >  [I-D.ietf-mmusic-data-channel-sdpneg] can be used to negotiate such
 >  data channel.

Nit: This document is the O/A mechanism, and this will become confusing
when it's replaced with a plain RFC number. Consider:

    and how the SDP offer/answer mechanism for data channels
    [I-D.ietf-mmusic-data-channel-sdpneg] can be used to negotiate such
    a data channel.

---------------------------------------------------------------------------

§1:

 >  This document is based on an earlier Internet draft edited by Keith
 >  Drage, Juergen Stoetzer-Bradler and Albrecht Schwarz.

This is kind of unusual for an "Introduction" section. Consider moving this
sentence to the start of Section 10.

---------------------------------------------------------------------------

§4.1:

 >  The offerer and answerer MAY include the priority attribute parameter
 >  and the label attribute parameter in the 'dcmap' attribute value.  If
 >  the offerer includes a label attribute parameter, the answerer MUST
 >  NOT change the value in the answer.

This should be explicit about whether the answerer is allowed to add a label
if the offerer did not. It should also be clear about whether the 
priority is
allowed to be different in the answer than in the offer.

---------------------------------------------------------------------------

§4.1:

 >  The offerer and answerer MUST NOT include the max-retr and max-time
 >  attribute parameters in the 'dcmap' attribute.

Ideally, this would include text that indicates what a recipient of such
messages would do (with the obvious choices being ignoring them or treating
them as an error). I suggest the easiest thing to specify is that recipients
of either attribute for a T.140 section MUST ignore them.

---------------------------------------------------------------------------

§4.2:

 >  An offerer and answerer MAY, in each offer and answer, include one or
 >  more SDP 'dcsa' attributes [I-D.ietf-mmusic-data-channel-sdpneg] in

Since this appears to be restating behavior defined elsewhere, consider
changing the normative "MAY" to a simple English "may".

---------------------------------------------------------------------------

§4.2.1:

 >  If the 'fmtp' attribute is not included, the default value of 30
 >  applies [RFC4103].

This isn't quite what you mean (as future specs could, in theory,
define fmtp parameters that apply). What is intended appears to be:

    If no 'fmtp' attribute with a 'cps' parameter is included, the default
    value of 30 applies [RFC4103].

---------------------------------------------------------------------------

§4.2.3:

 >  Session level direction attributes [I-D.ietf-mmusic-rfc4566bis] have
 >  no impact on a T.140 data channel.

Nit: "Session-level..."

---------------------------------------------------------------------------

§4.3:

 >      m=application 911 UDP/DTLS/SCTP webrtc-datachannel
 >      c=IN IP6 2001:db8::3
 >      a=max-message-size:1000
 >      a=sctp-port 5000
 >      a=dcmap:2 label="ACME customer service";subprotocol="t140"
 >      a=dcsa:2 fmtp:t140 cps=20
 >      a=dcsa:2 hlang-send:es eo
 >      a=dcsa:2 hlang-recv:es eo

Per draft-ietf-mmusic-sctp-sdp section 10.2, this example needs to include
a 'setup' attribute. The same applies to other examples.

---------------------------------------------------------------------------

§5.4:

 >  If this happens but the session sustains, it
 >  is RECOMMENDED that implementations tries to reestablish the T.140
 >  data channels.

Nit: "...that the implementation..."

---------------------------------------------------------------------------

§5.4:

 >  The procedure
 >  after the reestablishment of the T.140 data channel defined in this
 >  section apply no matter if only the T.140 data channel, or the whole
 >  SCTP association, got torn down.


Nit: "The procedures..."

---------------------------------------------------------------------------

§5.5:

 >  e.g., include human readable text labels in the real-time text stream
 >  that indicates the source whenever the conference server switches the

Nit: "...that indicate..."

---------------------------------------------------------------------------

§9.1:

 > +--------------------------+-------------+
 >               | Subprotocol Identifier:  | t140        |
 >               | Subprotocol Common Name: | ITU-T T.140 |
 >               | Subprotocol Definition:  | RFCXXXX     |
 >               | Reference:               | RFCXXXX     |
 > +--------------------------+-------------+

It would be more friendly to users of that registry if the common name were
more descriptive for people unfamiliar with ITU-T specifications. I suggest:
"ITU-T T.140 Real-Time Text"

---------------------------------------------------------------------------

§9.2:

 > +-----------------------+-------------------------------------------+
 >  | Contact name:         | IESG                                      |
 >  | Contact email:        | [e-mail]                             |
 >  | Attribute name:       | fmtp                                      |
 >  | Usage level:          | dcsa(t140)                                |
 >  | Purpose:              | Indicate the maximum transmission rate    |
 >  |                       | that an endpoint is willing to receive on |
 >  |                       | a T.140 data channel.                     |
 >  | Reference:            | RFCXXXX                                   |
 > +-----------------------+-------------------------------------------+

The purpose here appears to be perhaps a bit too narrow, as future
specifications might reasonably define new "fmtp" parameters that apply. I
would suggest rephrasing the purpose as "Indicate format parameters for a
T.140 data channel, such as maximum character transmission rates."