The Session Description Protocol (SDP) Grouping Framework
draft-ietf-mmusic-rfc3388bis-04

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?

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.

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.