Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2012-08-22
04 (System) post-migration administrative database adjustment to the No Objection position for Robert Sparks
2012-08-22
04 (System) post-migration administrative database adjustment to the No Objection position for Adrian Farrel
2012-08-22
04 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2010-03-18
04 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2010-03-16
04 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2010-03-16
04 (System) IANA Action state changed to In Progress from Waiting on Authors
2010-03-15
04 (System) IANA Action state changed to Waiting on Authors from In Progress
2010-03-09
04 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2010-03-08
04 (System) IANA Action state changed to In Progress
2010-03-08
04 Amy Vezza IESG state changed to Approved-announcement sent
2010-03-08
04 Amy Vezza IESG has approved the document
2010-03-08
04 Amy Vezza Closed "Approve" ballot
2010-03-08
04 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2009-11-25
04 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2009-11-10
04 Alexey Melnikov [Ballot Position Update] Position for Alexey Melnikov has been changed to No Objection from Discuss by Alexey Melnikov
2009-11-10
04 Alexey Melnikov
[Ballot comment]
6.  Use of "group" and "mid"

  All the "m" lines of a session description that uses "group" MUST be
  identified with …
[Ballot comment]
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?
2009-11-10
04 Alexey Melnikov [Ballot discuss]
2009-11-10
04 Robert Sparks [Ballot Position Update] Position for Robert Sparks has been changed to No Objection from Discuss by Robert Sparks
2009-11-10
04 Alexey Melnikov
[Ballot comment]
6.  Use of "group" and "mid"

  All the "m" lines of a session description that uses "group" MUST be
  identified with …
[Ballot comment]
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?
2009-11-10
04 Alexey Melnikov
[Ballot discuss]
Updated as per IESG telechat discussion:

I have several relatively minor points that should be addressed before I can recommend approval of this …
[Ballot discuss]
Updated as per IESG telechat discussion:

I have several relatively minor points that should be addressed before I can recommend approval of this document:

1). DISCUSS DISCUSS

In general, I think it is wrong to point to an IANA registry established by a RFC obsoleted by the document. I think it would be much better to copy the original IANA considerations section to this document.

I would recommend just cutting & pasting the original IANA considerations.
2009-11-10
04 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu
2009-11-10
04 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss by Adrian Farrel
2009-11-10
04 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-11-10
04 (System) New version available: draft-ietf-mmusic-rfc3388bis-04.txt
2009-10-23
04 (System) Removed from agenda for telechat - 2009-10-22
2009-10-22
04 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2009-10-22
04 Dan Romascanu
[Ballot comment]
1. I am unconfortable with the following statement in the section that describes changes relative to RFC 3388.

  Given a semantics …
[Ballot comment]
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.
2009-10-22
04 Dan Romascanu [Ballot discuss]
2009-10-22
04 Alexey Melnikov
[Ballot comment]
6.  Use of "group" and "mid"

  All the "m" lines of a session description that uses "group" MUST be
  identified with …
[Ballot comment]
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?

  [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

This should probably be updated to point to TLS 1.2.
2009-10-22
04 Alexey Melnikov
[Ballot discuss]
Updated as per IESG telechat discussion:

I have several relatively minor points that should be addressed before I can recommend approval of this …
[Ballot discuss]
Updated as per IESG telechat discussion:

I have several relatively minor points that should be addressed before I can recommend approval of this document:

1). This is a minor point that can be addressed with an RFC Editor note:

In Section 4:

  A new "media stream identification" media attribute is defined.  It
  is used for identifying media streams within a session description.
  Its formatting in SDP [RFC4566] is described by the following BNF
  (Backus-Naur Form):

          mid-attribute      = "a=mid:" identification-tag
          identification-tag = token

I suspect you are using ABNF defined in RFC 5234, but this is not explicitly stated. This reference needs to be Normative.
(The reason why this matters is because there are other types of BNFs, some of which allow for implicit whitespaces between elements.)

Also, you should clarify where  is defined. I suspect it is defined in RFC 4566, but you need to be explicit.

2). In Section 5:

  A new "group" session-level attribute is defined.  It is used for
  grouping together different media streams.  Its formatting in SDP is
  described by the following BNF:


          group-attribute    = "a=group:" semantics
                                *(space identification-tag)

I didn't find  in RFC 4566. Should you just use SP or WSP instead?

          semantics          = "LS" / "FID" / semantics-extension
          semantics-extension = token

3). DISCUSS DISCUSS

In general, I think it is wrong to point to an IANA registry established by a RFC obsoleted by the document. I think it would be much better to copy the original IANA considerations section to this document.

I would recommend just cutting & pasting the original IANA considerations.
2009-10-22
04 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2009-10-22
04 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2009-10-22
04 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2009-10-22
04 Pasi Eronen [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen
2009-10-22
04 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2009-10-21
04 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2009-10-21
04 Robert Sparks
[Ballot comment]
There are uses of 2119 words to constrain other documents here that should
be edited out (The MUST in section 5, leading to …
[Ballot comment]
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.
2009-10-21
04 Robert Sparks
[Ballot discuss]
The example SDP at the top of page 11 (in version -03) should be
double-checked to make sure the final c and m …
[Ballot discuss]
The example SDP at the top of page 11 (in version -03) should be
double-checked to make sure the final c and m lines are in the
intended order.
2009-10-21
04 Robert Sparks [Ballot Position Update] New position, Discuss, has been recorded by Robert Sparks
2009-10-21
04 Dan Romascanu
[Ballot comment]
The OPS-DIR review by Mehmet Ersue raised a couple of issues which are non-blocking but still may be considered:

1.  Chapter 5.  Group …
[Ballot comment]
The OPS-DIR review by Mehmet Ersue raised a couple of issues which are non-blocking but still may be considered:

1.  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.


2. 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.
2009-10-21
04 Dan Romascanu
[Ballot discuss]
I am unconfortable with the following statement in the section that describes changes relative to RFC 3388.

  Given a semantics value, …
[Ballot discuss]
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?
2009-10-21
04 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu
2009-10-21
04 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2009-10-21
04 Adrian Farrel
[Ballot discuss]
Some minor issues that should be easy to clean up.

The Abstract and the Introduction should note "This document obsoletes
RFC 3388." …
[Ballot discuss]
Some minor issues that should be easy to clean up.

The Abstract and the Introduction should note "This document obsoletes
RFC 3388."
---
I find section 10 a little short of information. It *does* capture the
main functional difference between this I-D and RFC 3388, but if I run
a diff between the documents I see far more changes. These should be
explained in section 10; possibly just add "Rewrite the following
secitons for clarity...", "Add the following sections for additional
explanation...", and "update IP address in the example"
---
I think that in this revision of 3388, you shouldn't define the
attributes defined (sections 4 and 5) as "new". Please replace
OLD
  A new "media stream identification" media attribute is defined.
NEW
  This document defines the "media stream identification" media
  attribute.

etc. Which has the added benefit of removing a gratuitous passive voice.
---
Need to add a normative reference for the definition of the BNF you are
using. Then add citations in sections 5 and 6.
---
Section 12 needs some work.
Since you are obsoleting RFC 3388, presubaly you would like the registry
created by RFC 3388 to be updated to have a reference to this document.
Esepcially since section 5 says that this document defines the things in
the registry.
2009-10-21
04 Adrian Farrel [Ballot Position Update] New position, Discuss, has been recorded by Adrian Farrel
2009-10-21
04 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms
2009-10-20
04 Russ Housley
[Ballot discuss]
In the Gen-ART Review by Elwyn Davies on 17 October 2009, there was
  a question.  I think the question deserves an answer. …
[Ballot discuss]
In the Gen-ART Review by Elwyn Davies on 17 October 2009, there was
  a question.  I think the question deserves an answer.

  s9.4.2, last para:  How does the offerer know that the grouping is the
  cause of the error message? (This comment may be due to my lack of
  understanding of the minutiae of SDP).
2009-10-20
04 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2009-10-19
04 Alexey Melnikov
[Ballot comment]
6.  Use of "group" and "mid"

  All the "m" lines of a session description that uses "group" MUST be
  identified with …
[Ballot comment]
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?

  [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

This should probably be updated to point to TLS 1.2.
2009-10-19
04 Alexey Melnikov
[Ballot discuss]
I have several relatively minor points that should be addressed before I can recommend approval of this document:

1). This is a minor …
[Ballot discuss]
I have several relatively minor points that should be addressed before I can recommend approval of this document:

1). This is a minor point that can be addressed with an RFC Editor note:

In Section 4:

  A new "media stream identification" media attribute is defined.  It
  is used for identifying media streams within a session description.
  Its formatting in SDP [RFC4566] is described by the following BNF
  (Backus-Naur Form):

          mid-attribute      = "a=mid:" identification-tag
          identification-tag = token

I suspect you are using ABNF defined in RFC 5234, but this is not explicitly stated. This reference needs to be Normative.

Also, you should clarify where  is defined. I suspect it is defined in RFC 4566, but you need to be explicit.

2). In Section 5:

  A new "group" session-level attribute is defined.  It is used for
  grouping together different media streams.  Its formatting in SDP is
  described by the following BNF:


          group-attribute    = "a=group:" semantics
                                *(space identification-tag)

I didn't find  in RFC 4566. Should you just use SP or WSP instead?

          semantics          = "LS" / "FID" / semantics-extension
          semantics-extension = token

3). DISCUSS DISCUSS

In general, I think it is wrong to point to an IANA registry established by a RFC obsoleted by the document. I think it would be much better to copy the original IANA considerations section to this document.
2009-10-19
04 Alexey Melnikov
[Ballot comment]
6.  Use of "group" and "mid"

  All the "m" lines of a session description that uses "group" MUST be
  identified with …
[Ballot comment]
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?
2009-10-19
04 Alexey Melnikov
[Ballot discuss]
I have several relatively minor points that should be addressed before I can recommend approval of this document:

1). This is a minor …
[Ballot discuss]
I have several relatively minor points that should be addressed before I can recommend approval of this document:

1). This is a minor point that can be addressed with an RFC Editor note:

In Section 4:

  A new "media stream identification" media attribute is defined.  It
  is used for identifying media streams within a session description.
  Its formatting in SDP [RFC4566] is described by the following BNF
  (Backus-Naur Form):

          mid-attribute      = "a=mid:" identification-tag
          identification-tag = token

I suspect you are using ABNF defined in RFC 5234, but this is not explicitly stated. This reference needs to be Normative.

Also, you should clarify where  is defined. I suspect it is defined in RFC 4566, but you need to be explicit.

2). In Section 5:

  A new "group" session-level attribute is defined.  It is used for
  grouping together different media streams.  Its formatting in SDP is
  described by the following BNF:


          group-attribute    = "a=group:" semantics
                                *(space identification-tag)

I didn't find  in RFC 4566. Should you just use SP or WSP instead?

          semantics          = "LS" / "FID" / semantics-extension
          semantics-extension = token

3). DISCUSS DISCUSS

In general, I think it is wrong to point to an IANA registry established by a RFC obsoleted by the document. I think it would be much better to copy the original IANA considerations section to this document.
2009-10-19
04 Alexey Melnikov
[Ballot comment]
6.  Use of "group" and "mid"

  All the "m" lines of a session description that uses "group" MUST be
  identified with …
[Ballot comment]
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?
2009-10-19
04 Alexey Melnikov
[Ballot discuss]
1). This is a minor point that can be addressed with an RFC Editor note:

In Section 4:

  A new "media stream …
[Ballot discuss]
1). This is a minor point that can be addressed with an RFC Editor note:

In Section 4:

  A new "media stream identification" media attribute is defined.  It
  is used for identifying media streams within a session description.
  Its formatting in SDP [RFC4566] is described by the following BNF
  (Backus-Naur Form):

          mid-attribute      = "a=mid:" identification-tag
          identification-tag = token

I suspect you are using ABNF defined in RFC 5234, but this is not explicitly stated. This reference needs to be Normative.

Also, you should clarify where  is defined. I suspect it is defined in RFC 4566, but you need to be explicit.


5.  Group Attribute

  A new "group" session-level attribute is defined.  It is used for
  grouping together different media streams.  Its formatting in SDP is
  described by the following BNF:


          group-attribute    = "a=group:" semantics
                                *(space identification-tag)

I didn't find  in RFC 4566. Should you just use SP or WSP instead?

          semantics          = "LS" / "FID" / semantics-extension
          semantics-extension = token
2009-10-19
04 Alexey Melnikov [Ballot Position Update] New position, Discuss, has been recorded by Alexey Melnikov
2009-10-19
04 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2009-10-18
04 Cullen Jennings [Ballot Position Update] New position, Yes, has been recorded for Cullen Jennings
2009-10-18
04 Cullen Jennings Ballot has been issued by Cullen Jennings
2009-10-18
04 Cullen Jennings Created "Approve" ballot
2009-10-18
04 Cullen Jennings State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Cullen Jennings
2009-10-18
04 Cullen Jennings Placed on agenda for telechat - 2009-10-22 by Cullen Jennings
2009-10-14
04 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2009-10-12
04 Amanda Baber IANA comments:

As described in the IANA Considerations section, we understand this
document to have NO IANA Actions.
2009-10-08
04 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Tero Kivinen.
2009-10-03
04 Samuel Weiler Request for Last Call review by SECDIR is assigned to Tero Kivinen
2009-10-03
04 Samuel Weiler Request for Last Call review by SECDIR is assigned to Tero Kivinen
2009-09-30
04 Amy Vezza Last call sent
2009-09-30
04 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2009-09-30
04 Cullen Jennings State Changes to Last Call Requested from AD Evaluation by Cullen Jennings
2009-09-30
04 Cullen Jennings Last Call was requested by Cullen Jennings
2009-09-30
04 (System) Ballot writeup text was added
2009-09-30
04 (System) Last call text was added
2009-09-30
04 (System) Ballot approval text was added
2009-09-30
04 Cullen Jennings State Changes to AD Evaluation from Publication Requested by Cullen Jennings
2009-07-15
04 Cindy Morgan

    (1.a) Who is the Document Shepherd for this document? Has the
          Document Shepherd personally reviewed this version of …

    (1.a) Who is the Document Shepherd for this document? Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

    The document shepherd is Joerg Ott , co-chair
    of the MMUSIC WG.

    I have personally reviewed this document and consider it ready
    for publication.  Besides the textual review, the ID nits tool
    has not found any issues and the contained ABNF compiles.

    (1.b) Has the document had adequate review both from key WG members
          and from key non-WG members? Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

    The draft was motivated by an observed shortcoming of RFC 3388
    and the revision was developed based upon the needs observed.
    The draft received ample discussion and was properly reviewed.
    Also, the authors checked with implementers to determine that
    no backwards compatibility issues would arise in practice.
    The working group last call completed in January 2009 and
    no changes were needed as of this.  The documents depending
    on the draft are nearing completion and no further issues were found.

    (1.c) Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

    No.  The draft only provides a minor semantics revision of the
    semantics of an SDP attribute.  MMUSIC is the responsible
    WG for modifications to SDP.  The attribute is related to work
    in AVT and discussions took place with the authors in both WGs,
    ensuring interaction has happened with the appropriate people
    of the AVT WG.  No further review is deemed necessary.

    (1.d) Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of? For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it. In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here. Has an IPR disclosure related to this document
          been filed? If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

    No concerns.  No IPR disclosures filed.

    (1.e) How solid is the WG consensus behind this document? Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

    The draft has undergone Working Group Last Call (on the present
    version, -03) with no changes required.

    (1.f) Has anyone threatened an appeal or otherwise indicated extreme
          discontent? If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director. (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

    No.

    (1.g) Has the Document Shepherd personally verified that the
          document satisfies all ID nits? (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/). Boilerplate checks are
          not enough; this check needs to be thorough. Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

    Yes.  All checks pass.

    (1.h) Has the document split its references into normative and
          informative? Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state? If such normative references exist, what is the
          strategy for their completion? Are there normative references
          that are downward references, as described in [RFC3967]? If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

    Yes, the references are split.
    No, there are no dependencies on incomplete documents.

    (1.i) Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document? If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries? Are the IANA registries clearly identified? If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations? Does it suggest a
          reasonable name for the new registry? See [RFC5226]. If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

    The draft only changes the semantics of an existing RFC (RFC 3388).
    All IANA registrations are thus already in place.  No updates are
    needed.

    (1.j) Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

    The definitions are short (ABNF) and the ABNF checks pass

    (1.k) The IESG approval announcement includes a Document
          Announcement Write-Up. Please provide such a Document
          Announcement Write-Up? Recent examples can be found in the
          "Action" announcements for approved documents. The approval
          announcement contains the following sections:
          Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document. If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.
          Working Group Summary
            Was there anything in WG process that is worth noting? For
            example, was there controversy about particular points or
            were there decisions where the consensus was particularly
            rough?
          Document Quality
            Are there existing implementations of the protocol? Have a
            significant number of vendors indicated their plan to
            implement the specification? Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues? If
            there was a MIB Doctor, Media Type or other expert review,
            what was its course (briefly)? In the case of a Media Type
            review, on what date was the request posted?

    Proposed announcment text:

    Technical summary:

        The document refines the semantics of the grouping attribute
for the Session Description Protocol and will obsolete RFC 3388.

  In this specification, we define a framework to group "m" lines in
  SDP (Session Description Protocol) for different purposes.  This
  framework uses the "group" and "mid" SDP attributes, both of which
  are defined in this specification.  Additionally, we specify how to
  use the framework for two different purposes: for lip synchronization
  and for receiving a media flow consisting of several media streams on
  different transport addresses.

    Working Group summary:

        The MMUSIC WG has firm consenses on publishing this document
as Proposed Standard.

    Document quality:

    The document has received ample review and gone through two
working group last calls.  It is technically sound and stable.
       
    Personnel:

        The document shepherd is Joerg Ott, the responsible AD is
Cullen Jennings.
2009-07-15
04 Cindy Morgan Draft Added by Cindy Morgan in state Publication Requested
2009-07-15
04 Cindy Morgan [Note]: 'Joerg Ott (jo@netlab.tkk.fi) is the document shepherd' added by Cindy Morgan
2009-07-13
03 (System) New version available: draft-ietf-mmusic-rfc3388bis-03.txt
2009-01-13
02 (System) New version available: draft-ietf-mmusic-rfc3388bis-02.txt
2009-01-07
04 (System) Document has expired
2008-07-07
01 (System) New version available: draft-ietf-mmusic-rfc3388bis-01.txt
2008-06-14
00 (System) New version available: draft-ietf-mmusic-rfc3388bis-00.txt