Shepherd's review of draft-ietf-mmusic-data-channel-sdpneg-11

Authors, WG,

I think this document is getting ready for publication request. As part of making the shepherd's write-up, I have the following comments, to be addressed in an updated document:

Issues:

1)      In section 1: add that also BFCP (Binary Floor Control Protocol)  is used in the same way as MSRP in examples.

2)      In 5.1.1.1, dcmap-stream-id = 1*DIGIT allows infinite length of this identifier, which seems inappropriate. I suggest providing a maximum length, maybe matching this to the unsigned 16 bit integer in SCTP (RFC 4960), in which case 1*5DIGIT should be sufficient.

3)      In 5.1.1.1, quoted-visible ABNF syntax is incorrect, missing "x" after "%" when defining hex characters. Change to:
quoted-visible  = %x21 / %x23-24 / %x26-7E ; VCHAR without " or %

4)      In 5.1.2.1, text below the example makes reference to MSRP subprotocol, but the example does not explicitly include any MSRP. The single example line uses "accept-types", which is admittedly related to MSRP, but I think this should be clarified to avoid confusion for readers not familiar with MSRP.

5)      In 5.2.2: It is unclear why you differentiate handling of offers and answers that contain both "max-retr" and "max-time", mandating to reject the offer but allowing it in the answer. I think allowing this asymmetry should either be motivated, or handling should be aligned between offer and answer.

6)      In section 6: several examples uses IP addresses that are not aligned with RFC 6890 (10.10.10.x), which must be changed.
Allowed ranges are 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), or 203.0.113.0/24 (TEST-NET-3).

7)      In Appendix A: same IP address issue as above, change from 79.97.215.79 to an address in the allowed range.

Nits:

1)      The date line in the document header is one character too long (beyond column 72)

2)      In section 1: s/In future data channels could/In the future, data channels could/

3)      In section 3: s/sending and receive data/sending and receiving data/

4)      At the very end of section 5.1.2.1: s/in the same document, which registers/in the same document that registers/

5)      In 5.2.4: s/other data channels which are now not included/other data channels that are now not included/

6)      In 5.2.5: s/channels are expected be closed now/channels are expected to be closed now/

7)      In 8.3: s/dcsa usage level only shall use/dcsa usage level only SHALL use/

8)      In Appendix A.1: s/either pass to the data channel stack the stream identifier to assign/either pass the stream identifier to the data channel stack to assign/

9)      In Appendix A.1: Why are two paragraphs starting with "For data channels negotiated" indented compared to other text? Is it supposed to be some kind of note?

Comments from others that are not addressed in -11:

1)      Christian Groves commented on Jan 20 that the example in Appendix A should contain an "a=dtls-id:..." attribute as per other examples in the draft.

2)      Paul Kyzivat commented on Jan 21 that a bullet in section 5.2.3 should be changed to:
o For accepted data channels, the agent MUST create peer instances
   for the data channels using the SCTP stream identifiers and
   channel parameters contained in the SDP offer.

Cheers,
/Bo
MMUSIC co-chair

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic