Re: [Tsv-art] [clue] Tsvart telechat review of draft-ietf-clue-datachannel-15

[Christer Holmberg <[e-mail]>]

Hi Joerg,

Thank You for the comments! Please see inline.
   
>    Reviewing this document for tsv-art, I don't see any any transport-specific
>    issues in the document, but a bunch of other (smaller) issues and nits came up.
>    
>    I am not sure that that the reference to a "SIP User Agent" as an entity is
>    strictly correct here. SIP User Agents are defined in RFC 3261 to carry out
>    SIP transactions. Just speaking about "User Agents" may be more accurate.
>    But this is just a side note.

I think it is good to have "SIP" there for clarity.
    
----

>    Section 3.2.3 defines behaviour in a negative way, i.e., via MUST NOT
>    statements, excluding all but one possibility. This could be problematic in
>    the future if another option gets added to SCTP usage, which would then
>    implicitly be allowed. It would be better if the behaviour was defined i
>     a positive way, i.e., using MUST.
  
In general I agree with you. But, in the case the base data channel spec mandates a set of SCTP extensions, and the text says that a couple of them must not be used for CLUE. I think that is the clearest way.

(And, if additional SCTP extensions are added to rtcweb-data-channel in the future, that could cause problems no matter if we use MUST or MUST NOT, depending on whether such extensions can be used with CLUE or not.)

----

>    Sect. 3.2.5, 2nd para: use "MUST" instead of "must" since this appears to
>    be normative, so RFC 2119 wording should be used.

The reason I use "must" is because the text is referencing requirements in another specification, i.e., the requirement is not defined or introduced by this draft. That is based on guidance I have received on earlier drafts.

----    

>    Sect. 3.2.7, 1st para: this appears t be normative language and thus
>    should use the RFC 2119 keywords.

As for your comment on 3.2.5, the text is simply referencing requirements defined elsewhere.

----
    
>    Sect. 3.3.1.1, table 1 + 2nd para after table 1: the text in the 2nd para
>    defines the value for the "application usage"; this should also be reflected
>    in table 1 since it seems that only one application usage is defined.
  
I don't know how I would get it into the table, as it is a generic description of an m- line for SCTP over DTLS.

I could of course copy/paste the table, indicate that it shows the m- line for CLUE, and replace "application usage" with "webrtc-datachannel". But, I am not sure that would make things more clear.

----
  
>    Sect. 3.3.1.2.: this again appears to be normative, so RFC 2119 language
>    should be used.
>    What does the sentence "A CLUE entity can choose any valid SCTP port
>    value." mean in this context?  Is a "valid SCTP port" value that of a
>    previously established SCTP connection within the context of the
>    SIP session? If such a match is desired it should be specified or a
>    reference to a peer document (draft-ietf-mmusic-sctp-sdp-26?) 
>    should be provided.
  
draft-ietf-mmusic-sctp-sdp specifies how the port is used, and the port range, so suggest adding a reference to draft-ietf-mmusic-sctp-sdp.

---

>    Sect. 3.3.2: NOTE statement: It is ok to have a note but this still is
>    somewhat normative. It should also be specified what happens if
>    the values _are_ set by the peer. What is the error handling?
>    Ignore? Reject the connection setup?
  
I guess we could allow two options: either discard the parameters, or reject the SDP and take proper actions to release the connection.

I am also ok "de-noting" the text.
  
----

>    Figure 1 is a nice example. But it would be even better if a complete
>    example with the SDP for the data channel setup (in the previous
>    or the same offer/answer exchange) be given. Makes life easier
>    for readers and implementers.
  
draft-ietf-clue-signaling contains more complete SDP examples, so I would suggest to add a reference there.

--------

    Editorial:

>    Don't just copy the first paragraph(s) from the introduction to create an abstract.

I will see if I can make the Abstract shorter.

----

>    3.2.2, 2nd para, 3rd line: "what" -> "which"
  
Will fix.

----

>    Sect. 3.3.1: the ref to the clue-signalling draft is missing a link (all other refs have one).
  
Not sure I understand. What do you mean by "missing a link"?

----
  
>    Fix the formatting of table 2 to avoid letter breaking from words.
  
Will do.



Thanks!

Regards,

Christer