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

From: Adam Roach <[email-masked]>
Date: Thu, 23 Jan 2020 16:46:55 -0600

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:        | [email-masked]                             |
 >  | 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."

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Jan 2020 11:30:55 +0000

Hi Adam,

Thank You for the review! 

I have removed the comments where I agree and will modify as suggested without further discussion. Please see inline for the rest.

    §4.1:
    
    > priority is allowed to be different in the answer than in the offer.

If not explicitly included, the default value is 256, so there will always be a value (implicit or explicit). I guess we can point that out.

Perhaps something like:

OLD:

NEW:

   The offerer and answerer MAY include the priority attribute parameter
   and the label attribute parameter in the 'dcmap' attribute value.  As
   defined in [I-D.ietf-mmusic-data-channel-sdpneg], in absence of the
   attribute parameter an attribute parameter value of 256 is assumed.
   The answerer MUST not change the value in the answer. 

    
    > of either attribute for a T.140 section MUST ignore them.

Just to note:

- The draft defines that the T.140 data channel is reliable.
- max-retr and max-time are used to indicate that a data channel is partially reliable, so there would be a conflict.

So, the question is whether it is ok to just ignore, or whether it is a protocol error and the m- line therefore should be rejected.

If *both* attribute parameters are included in an offer (which would also create a conflict), draft-channel-sdpneg says that the offer must be rejected.

    
    > changing the normative "MAY" to a simple English "may".

I suggest to use "can", because some reviewers don't want to use the normative words unless in capital letters.

    Regards.

Christer

---

From: Adam Roach <[email-masked]>
Date: Fri, 24 Jan 2020 06:08:24 -0600

> I have removed the comments where I agree and will modify as suggested without further discussion. Please see inline for the rest.

Sounds good to me.

Given this last fact, it seems that the best approach would be to treat 
the presence of either parameter in this context as an error. The key 
here is that the behavior should be spelled out.

Sure; that works.

Thanks!

/a

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Jan 2020 13:09:57 +0000

Hi,

    > here is that the behavior should be spelled out.

I suggest the following:

OLD:

NEW:

   The offerer and answerer MUST NOT include the max-retr and max-time
   attribute parameters in the 'dcmap' attribute. If any of the
   attribute parameters are included in an offer or answer, the receiver
   MUST take the proper actions to reject the SDP.

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 26 Jan 2020 14:41:07 +0000

Hi,

See a comment at the end of the proposed text:

> Hi,

In RFC 3264, there are only ways for the answering party to reject an 
SDP specified.

If you mean that the offering party should reject the SDP, how should it 
behave? Make a re-invite without the subchannel in error? Can that 
really be called "reject the SDP"?  Or is a rapid close of the whole 
session and all connections with an error indication the proper action?

/Gunnar
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

-- 

+ + + + + + + + + + + + + +

Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 26 Jan 2020 16:54:08 +0000

Hi Gunnar,

    > session and all connections with an error indication the proper action?

We don't specify HOW an answer is rejected, because that is a generic procedure that 3264 is supposed to specify. We only say "take the proper actions".

Or, if there are some data channel specific procedures for rejecting offers and/or answers, those should be specified in draft-sdpneg.

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 26 Jan 2020 19:25:00 +0000

Hi,

Den 2020-01-26 kl. 17:54, skrev Christer Holmberg:

Hi Gunnar,

What I mean is that after the offer-answer procedure has been performed, it is too late to say that the SDP shall be rejected.

sdpneg has the following wording in 6.2 for the error case when both parameters are included in the answer:

  "If an SDP answer contains both
   of these parameters then the offerer MUST treat the associated SDP
   offer/answer as failed."

We should use similar wording.
Proposal for the NEW wording:
   "The offerer and answerer MUST NOT include any of the max-retr or max-time
    attribute parameters in the 'dcmap' attribute. If any of these
    attribute parameters are included in an offer, the answering part
    MUST take the proper actions to reject the SDP. If an SDP answer contains any
    of these parameters then the offerer MUST treat the associated SDP
    offer/answer as failed."

Then we get language and logic matching sdpneg.
/Gunnar

Regards,

Christer

--

Gunnar Hellström
Omnitor
[email-masked]<mailto:[email-masked]>
+46 708 204 288

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 26 Jan 2020 20:18:03 +0000

Hi,

Please see comment on the priority and label parameters below.

Den 2020-01-24 kl. 12:30, skrev Christer Holmberg:

Hi Adam,

Perhaps something like:

OLD:

NEW:

This is not clear enough. But the intention is to express exactly the same rules as specified in sdpneg.

So, it would then be best to just refer to sdpneg according to this alternative proposed

NEW wording alternative 1:

The offerer and answerer MAY include the priority attribute parameter
   and the label attribute parameter in the 'dcmap' attribute value as
   specified in [I-D.ietf-mmusic-data-channel-sdpneg].

Alternatively, if you want to spell it out, I suggest the following complete description:
NEW wording alternative 2.

   The offerer and answerer MAY include the priority attribute parameter
   and the label attribute parameter in the 'dcmap' attribute value.  As
   defined in [I-D.ietf-mmusic-data-channel-sdpneg], in absence of the
   priority attribute parameter a priority attribute parameter value of 256 is assumed.
   In the absence of the label attribute parameter a label attribute parameter value of the empty string is assumed.
   The answerer MUST not change the values in the answer.

I suggest to use alternative 1.

Regards

Gunnar

Just to note:

    Regards.

Christer

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

--

Gunnar Hellström
Omnitor

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Jan 2020 10:44:31 -0500

On 1/26/20 2:25 PM, Gunnar Hellström wrote:
> What I mean is that after the offer-answer procedure has been performed, 
> it is too late to say that the SDP shall be rejected.

I agree. There is no way to *reject* an answer.

>     of these parameters then the offerer MUST treat the associated SDP

The tricky part of treating the O/A as having failed is that only the 
offerer knows this, while the answerer thinks it has succeeded. So the 
two sides have differing understandings of the state of the session. 
(Consider that there may also have been changes in another media 
section.) Things will not go well until this is corrected.

I don't know if there is any document that specifies what to do in this 
situation. I think there are only two generic possibilities: drop the 
entire session (i.e., BYE), or start another O/A to try to fix this, 
perhaps by dropping the m= line. When following this latter course, 
there will be an extended period while the two sides are in 
disagreement, and no guarantee that the fix will work.

The simplest solution is to simply say that this is a protocol 
violation, and recovery is an implementation issue. While simple to 
write, this is perhaps not the best solution.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 Jan 2020 16:03:11 +0000

Hi,

...
    
    > write, this is perhaps not the best solution.

That is normally what we say.

However, if more text is needed I think it belongs to the data channel sdpneg draft. I don't think that each data channel usage draft shall have to describe how it is done.

Regards,

Christer