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 |