Source-Specific Media Attributes in the Session Description Protocol (SDP)
RFC 5576

[Ballot comment]
Please consider these editorial comments raised by Francis Dupont in
  the Gen-ART Review on 5-Feb-2009.

  Nits/editorial comments:
  - Abstract page 1: The Session Description Protocol -> ... (SDP)
  - 3 page 4: receivers (who may never -> receivers (which may never
  - 3 page 4 (twice): i.e. -> i.e.,
  - 4 page 5: synchronizaton -> synchronization
  - 9 page 12: defintion -> definition
  - 10 page 12: 0 - 2**32 - 1 -> 0 .. 2**32 - 1
  - 12.3 page 15: gropuing -> grouping
  - Authors' page 18: NJ  07601, US -> NJ 07601, USA

[Ballot comment]
Please consider these editorial comments raised by Francis Dupont in
  the Gen-ART Review on 5-Feb-2009.

  Nits/editorial comments:
  - Abstract page 1: The Session Description Protocol -> ... (SDP)
  - 3 page 4: receivers (who may never -> receivers (which may never
  - 3 page 4 (twice): i.e. -> i.e.,
  - 4 page 5: synchronizaton -> synchronization
  - 9 page 12: defintion -> definition
  - 10 page 12: 0 - 2**32 - 1 -> 0 .. 2**32 - 1
  - 12.3 page 15: gropuing -> grouping
  - Authors' page 18: NJ  07601, US -> NJ 07601, USA

[Ballot discuss]
Section 10:

ssrc-group-attr = "ssrc-group:" semantics *(SP ssrc-id)

The text points at RFC 3388 for the definition of "semantics". However RFC 3388 definition is:

semantics          = "LS" | "FID"

Based on the IANA rules it is clear that this rule should in fact be:

semantics          = "LS" | "FID" | token
token as defined by RFC 4566. Based on this is seems approriate that this is converted into consistent ABNF and put into this document. It can also be limited to the semantics actually defined. Resulting in:

semantics          = "FEC" / "FID" / token
token =

IANA Last Call comments:


Action #1:

Upon approval of this document, IANA will make the following
assignments in the "att-field (media level only)" registry at
http://www.iana.org/assignments/sdp-parameters

Type SDP Name Reference
---- ------------------ ---------
att-field (media level only)
ssrc [RFC-mmusic-sdp-source-attributes-02]
ssrc-group [RFC-mmusic-sdp-source-attributes-02]


Action #2:

Upon approval of this document, IANA will create the following new
registry at http://www.iana.org/assignments/sdp-parameters:

Registry Name: att-field (source level)
Reference: [RFC-mmusic-sdp-source-attributes-02]
Registration Procedures: Specification Required

Initial contents of this registry:
Type SDP Name Reference
---- ------------------ ---------
att-field (source level)
cname [RFC-mmusic-sdp-source-attributes-02]
previous-ssrc [RFC-mmusic-sdp-source-attributes-02]
fmtp [RFC-mmusic-sdp-source-attributes-02]


Action #3:

Upon approval of this document, IANA will create the following new
registry at http://www.iana.org/assignments/sdp-parameters:

Registry Name: Semantics for the "ssrc-group" SDP Attribute
Reference: [RFC-mmusic-sdp-source-attributes-02]
Registration Procedure: Standards Action

Initial contents of this registry:
Semantics Token Reference
------------------- ----- ---------
Flow Identification FID [RFC-mmusic-sdp-source-attributes-02]
Forward Error Correction FEC [RFC-mmusic-sdp-source-attributes-02]


We understand the above to be the only IANA Actions for this document.

-- Document Shepherd Write-Up for:
--- draft-ietf-mmusic-sdp-source-attributes-02.txt

The procedures described in RFC 4858 are being used for the MMUSIC Internet-Draft titled "Source-Specific Media Attributes in the Session Description Protocol (SDP)", draft-ietf-mmusic-sdp-source-attributes-02.txt,
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-source-attributes-02.

Requested Publication Status: Proposed Standard
Document Shepherd: Jean-Francois Mule (jf.mule@cablelabs.com)

--------------------------------------------------------------------
--- (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?

Jean-Francois Mule, MMUSIC co-chair (jf.mule@cablelabs.com) is the Document Shepherd. He has personally reviewed this version of the Internet-Draft. This Internet-Draft document is ready for forwarding to the IESG for publication.


--- (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?

Yes.

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

--- (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.
No concerns.

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 based on Nov 14 search:
Total number of IPR disclosures found: 0
Total number of documents searched: 2
Search result on draft-ietf-mmusic-sdp-source-attributes, "Source-Specific Media Attributes in the Session Description Protocol (SDP)"
No IPR disclosures related to draft-ietf-mmusic-sdp-source-attributes have been submitted
Search result on draft-lennox-mmusic-sdp-source-attributes, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", that was replaced by draft-ietf-mmusic-sdp-source-attributes, "Source-Specific Media Attributes in the Session Description Protocol (SDP)"
No IPR disclosures related to draft-lennox-mmusic-sdp-source-attributes have been submitted


--- (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?

There is good consensus for publication.

--- (1.f)
Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize 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, draft-09 checked against idnits 2.10.02.
There are 2 warnings for references which seem fine to the document shepherd (one is on the use of RFCXXX when IANA registers the new SDP attributes and one is for the use of the RFC 3978 boilerplate). The latter can be updated when IESG or Last Call comments are addressed.


--- (1.h)
Has the document split its references into normative and
informative?
Yes.

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?
No.

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].
No.

--- (1.i)
Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document?
Yes.

If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries?
Yes.
Are the IANA registries clearly identified?
Yes.

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 [RFC2434]. If the
document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG Evaluation?
This document creates 2 new SDP registries and the IANA sections in 12.2 and 12.3 of the Internet-Draft are fine.


--- (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?

Yes, checked abnf with http://www.apps.ietf.org/abnf.html and there are 3 undefined rules which are defined in other RFCS.


--- (1.k)
The IESG approval announcement includes a Document
Announcement Write-Up.

Here is the proposed Document Announcement Write-Up:

Technical Summary
This document defines a general SDP Capability Negotiation framework. It also specifies how to provide attributes and transport protocols as capabilities and negotiate them using the framework.

Working Group Summary
The MMUSIC Working Group has consensus to publish this document as a Proposed Standard.

Document Quality
This mechanism feels an important gap in SDP. In particular, it allows the description of specific media sources in SDP messages for RTP Single-Source Multicast [I-D.ietf-avt-rtcpssm]. SSM needs to ensure that receivers' RTP Synchronization Source Identifiers (SSRCs) do not collide with those of media senders.


Personnel
The Document Shepherd is Jean-Francois Mule, and the Responsible Area Director is Cullen Jennings.