The Session Description Protocol (SDP) Grouping Framework
RFC 5888
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
Lars Eggert No Objection
(Cullen Jennings; former steering group member) Yes
(Adrian Farrel; former steering group member) (was Discuss) No Objection
(Alexey Melnikov; former steering group member) (was Discuss) No Objection
6. Use of "group" and "mid" All the "m" lines of a session description that uses "group" MUST be identified with a "mid" attribute whether they appear in the group line(s) or not. If a session description contains at least one "m" line that has no "mid" identification the application MUST NOT perform any grouping of media lines. The last sentence: is there any interaction with draft-ietf-mmusic-sdp-capability-negotiation-10.txt here? 9.1.1. Example [Example omitted] Since alignment of "m" lines is performed based on matching of nth lines, the first stream had "mid:1" in the INVITE and "mid:2" in the 200 OK. Therefore, the application MUST ignore every "mid" and "group" lines contained in the SDP. Last sentence: is this done because of use in SIP, or because of "mid" mismatch in the 200 OK response?
(Dan Romascanu; former steering group member) (was Discuss) No Objection
1. I am unconfortable with the following statement in the section that describes changes relative to RFC 3388. Given a semantics value, [RFC3388] used to restrict "m" line identifiers to only appear in a single group using that semantics. That restriction has been lifted. From conversations with implementers, it seems that the lifting of this restriction is unlikely to cause backwards compatibility problems. The authors fail to make a crisp statement that no backwards compatibility problems would appear. This seems to be not an implementation but a deployment issue, and it is not clear what is the recommendation here for an operator. If compatibility problems do show up what are the symptoms or the impact? It may be a 'corner' situation but more clarity in the text could help. The OPS-DIR review by Mehmet Ersue raised a couple of issues which are non-blocking but still may be considered: 2. Chapter 5. Group Attribute It is unclear to me what the following statement actually means: "Further semantics MUST be defined in a standards-track document." The document in review _is_ a standards-track document and if necessary the further semantics can be defined in this document. 3. I support Alexey's DISCUSS at #3. I also think that it is not appropriate to point to an IANA registry established by a RFC obsoleted by this document. The document should include the original IANA considerations from RFC3388 and a note that this has already been done.
(Jari Arkko; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Pasi Eronen; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) (was Discuss) No Objection
There are uses of 2119 words to constrain other documents here that should be edited out (The MUST in section 5, leading to Dan's question, is a good example). I _think_ the MUST in the example section 9.1.1 (which let to Alexey's comment) is another example, but I'm not sure if this is attempting to note a consequence of some other requirement or to actually state a new requirement. If it's the former, where is the actual requirement? If the latter, it's in the wrong place.
(Ron Bonica; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
(Tim Polk; former steering group member) No Objection