Ballot for draft-ietf-mmusic-data-channel-sdpneg
Yes
No Objection
Note: This ballot was opened for revision 25 and is now closed.
Thank you for addressing my DISCUSSes and comments.
I agree with the other comments on Labels, but will let others carry the positions....
I agree with Magnus about UTF-8 in quoted strings for labels.
In Section 2, please use the exact boilerplate from RFC 8174.
I agree with Magnus’s DISCUSS. Please use the full BCP 14 boilerplate from RFC 8174, rather than abridging it. — Section 5.1.1 — Within an 'a=dcmap:' attribute line's 'dcmap-opt' value only one 'maxretr-opt' parameter or one 'maxtime-opt' parameter MAY be present. Both MUST NOT be present. Lower case “may” here, please. The MUST NOT is the normative bit. — Section 9 subsections — Instances of “IESG Chairs” should just say “IESG”.
Section 4 The mechanism in this document only applies to the Session Description Protocol (SDP) [I-D.ietf-mmusic-rfc4566bis] when used together with the SDP offer/answer mechanism [RFC3264]. Declarative usage of SDP is out of scope of this document, and is thus undefined. nit: this text doesn't actually scope itself to "this mechanism" or the RTCWeb data channel, and seems to be saying that all declarative SDP is undefined, globally. Section 5.1.7 The ordered parameter is optional and takes two values: "true" for ordered and "false" for unordered delivery with "true" as the default value. Any other value is ignored and default "ordered=true" is assumed. [...] This seems to be saying that offers or answers that do not conform to the ABNF will be special-cased as being ignored (instead of rejected) when they appear where ordering-value should appear. It's not clear to me why we need a special case here, since in Section 8 we explicitly say that peers MUST close the relevant data channel when such error cases occur. Section 5.1.8 If we chase links to draft-ietf-rtcweb-data-channel we find that larger values indicate higher priority. Do we want to short-circuit that and say so explicitly here? Section 5.2 Each of these attributes is represented by one new attribute line, and it includes the contents of a media-level SDP attribute already defined for use with this (sub)protocol in another IETF (Internet Engineering Task Force) document. [...] Do we need to limit the data-channel subprotocols to those specified by the IETF? Or is it just the media-level SDP attributes that we are trying to maintain change control over? The detailed offer/answer procedures for the dcsa attribute are dependent on the associated sub-protocol. If no offer/answer procedures exist for the sub-protocol when used outside of the dcsa attribute, no specification is needed for use with dcsa. The IANA registration procedures for the WebSocket Subprotocol Name Registry (Section 9.1) do not strictly require a specification of the offer/ answer procedures for the sub-protocol when used with dcsa. If the sub-protocol has defined offer/answer procedures when used outside of dcsa, such a specification is encouraged to ensure interoperability. If the sub-protocol has defined offer/answer procedures when used outside of dcsa, but no specification exists for the offer/answer procedures for the sub-protocol when used with dcsa, implementations SHOULD assume the use of the default values for all otherwise- negotiable and applicable sub-protocol parameters. I'm not entirely sure I understand what this paragraph is trying to say. The first sentence is clear, but the second sentence seems to be saying that if there are no O/A procedures for a given subprotocol outside the datachannel, it's just a free for all and I can use it in the data channel and make up my own procedures for using the dcsa attribute. I understand that IANA doesn't require a specification for the subprotocol when allocating the subprotocol name, but that just means that there may not be a specification available whether or not I want to use it with dcsa -- the IANA registry doesn't care directly about use with dcsa. If a subprotocol has defined O/A procedures outside of dcsa, doesn't that basically mean there's a specification? Why do we need to go out of our way to encourage a specification in that case (and is it a specification of the O/A semantics when the subprotocol is used outside dcsa or with dcsa)? In the last sentence, I think we're talking about using defaults for parameters that are not explicitly negotiated using dcsa, but we don't actually say that. Section 5.2.1 Note however that not all SDP attributes are suitable as a "a=dcsa:" parameter. IANA SDP parameters contains the lists of IANA (Internet Assigned Numbers Authority) registered session and media level or media level only SDP attributes. Am I supposed to infer that these are the attributes that are suitable for a=dcsa: parameters? As opposed to the data channel "a=dcmap:" attribute parameters, these parameters are subject to offer/answer negotiation following the procedures defined in the subprotocol specific documents. I am not sure where we really say that the a=dcmap: parameters are not subject to O/A negotiation. Section 6.1 SCTP stream identifiers associated with data channels that have been negotiated using DCEP MUST NOT be included in SDP offers and answers. This sentence appears as a dedicated paragraph and is duplicated at the end of the previous paragraph; presumably we only need one copy thereof... Section 6.2 If an SDP answer contains both of these parameters then the offerer MUST treat the associated SDP offer/answer failed. nit: "as failed", I think. Section 6.4 We only mention that the dcmap-stream-id, max-retr, and max-time values need to match the offer, leaving the ordering/subprotocol/label/priority to be omitted because they are conveyed at the SCTP layer? Perhaps we should state explicitly that they need to be absent... Section 6.6 Do we want to say anything about the appropriate response to receiving changed values for the SDP attributes/attribute values is to close the corresponding data channel? Section 6.6.1 It seems like the second bullet point only makes sense after the first has completed, as the tsvart reviewer noted? Specifically, the "; or" at the end of the first bullet point doesn't seem to make much sense. Section 9.3 If existing media attributes are used in a datachannel subprotocol specific way (Section 5.2.1), then a new dcsa usage level MUST be defined for the existing media attribute. [...] I'm not entirely sure that I understand what this means, though I'm not really an expert in SDP. Appendix A.1 I'm not sure that I know what "glare situations" are; is there a reasonable reference to include? Which set of stream identifiers is owned by which endpoint is determined by convention or other means. (specific to the application?) Note:For data channels negotiated via different protocol from DCEP, no convention is defined by default. That seems a bit misleading, since Section 6.1 says that the even/odd split applies to the SDP O/A negotiation case.
A couple of nits: s7: are examples for SDP offer correct? c= addrtype IP6 is listed twice there. s9.2.1, s9.2.2: s/IESG Chairs/IESG
Thanks for addressing my issues.
Thanks for quickly addressing the comments from the TSV-ART review regarding interactions with SCTP (and thanks Micheal T. for the review!)! One minor, more editorial comment on max-time parameter: draft-ietf-rtcweb-data-protocol says "This life-time starts when providing the user message to the protocol stack.". While a reference to draft-ietf-rtcweb-data-protocol is given respectively, I would recommend to also clarify in this draft which time frame is meant given this time frame includes and end-to-end delays. As a side note: not sure it is necessary to expand IETF (Internet Engineering Task Force) (see sec 5.2) in an IETF RFC but the RFC editor might tell you...