SDP Descriptors for FLUTE
draft-ietf-rmt-flute-sdp-03

IANA has reviewed draft-ietf-rmt-flute-sdp-03 and has the following comments:

IANA understands that, upon approval of this document, there are four actions which IANA must complete.

First, in the proto code subregistry of the Session Description Protocol (SDP) Parameters registry located at:

http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml

two new proto codes will be registered as follows:

Type: proto
SDP Name: FLUTE/UDP
Reference: [ RFC-to-be ]

Type: proto
SDP Name: FLUTE/UDP/ESP
Reference: [ RFC-to-be ]

Second, in the att-field (both session and media level) of the Session Description Protocol (SDP) Parameters registry located at:

http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml

five attributes will be registered as follows:

Type: att-field (both session and media level)
SDP Name: flute-tsi
Reference: [ RFC-to-be ]

Type: att-field (both session and media level)
SDP Name: flute-ch
Reference: [ RFC-to-be ]

Type: att-field (both session and media level)
SDP Name: FEC-declaration
Reference: [ RFC-to-be ]

Type: att-field (both session and media level)
SDP Name: FEC-OTI-extension
Reference: [ RFC-to-be ]

Type: att-field (both session and media level)
SDP Name: content-desc
Reference: [ RFC-to-be ]

Third, in the att-field (media level only) of the Session Description Protocol (SDP) Parameters registry located at:

http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml

one new attribute will be registered as follows:

Type: att-field (media level only)
SDP Name: FEC
Reference: [ RFC-to-be ]

Fourth, in the Semantics for the "group" SDP Attribute subregistry of the Session Description Protocol (SDP) Parameters registry located at:

http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml

one new semantics entry will be registered as follows:

Semantics:Composite Session
Token: CS
Reference: [ RFC-to-be ]

IANA understands that these four actions are the only ones required
to be completed upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (SDP Descriptors for FLUTE) to Proposed Standard


The IESG has received a request from the Reliable Multicast Transport WG
(rmt) to consider the following document:
- 'SDP Descriptors for FLUTE'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-01-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies the use of SDP to describe the parameters
  required to begin, join, receive data from, and/or end FLUTE
  sessions.  It also provides a Composite Session SDP media grouping
  semantic for grouping media streams into protocol-specific sessions,
  such as multiple-channel FLUTE sessions.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-rmt-flute-sdp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-rmt-flute-sdp/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1938/

The IPR disclosure [1] is according to one of the authors still valid for the WG draft.
3rd party IPR disclosure was filed on 2012-11-12, waiting for the database to show it. 

[1] https://datatracker.ietf.org/ipr/517/

AD review:
Section 6.1., paragraph 1:

>    The "proto" sub-field of the media description field ("m=") describes
>    the transport protocol used.  This document registers two values:
>    "FLUTE/UDP" is a reference to FLUTE [I-D.ietf-rmt-flute-revised]
>    running over UDP/IP.  "FLUTE/UDP/ESP" is a reference to FLUTE
>    [I-D.ietf-rmt-flute-revised] running over UDP/IP and the session
>    security is achieved by means of IPsec/ESP in a transport mode
>    [RFC4303].

  Please add more explicit text where to add the parameters, i.e.,
  in the registry "Session Description Protocol (SDP) Parameters"
  under "proto", just to avoid any confusion, similar to Section 6.3.


Section 6.1.1., paragraph 1:

>    FLUTE media using the "FLUTE/UDP" or "FLUTE/UDP/ESP" proto value may
>    use the character "*" as their "fmt" value.  The "*" character
>    represents a wild card which indicates that miscellaneous and
>    unspecified MIME types are contained in the FLUTE session.
>    Alternatively a list of MIME types (file formats) may be given in the
>    "fmt" list.  These formats SHOULD be registered.  Use of an existing
>    MIME subtype for the format is encouraged.  If no MIME subtype
>    exists, it is RECOMMENDED that a suitable one is registered through
>    the IETF process as described in RFC4289 [RFC4289].

  What is the request for IANA? I cannot determine it.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

"draft-ietf-rmt-bb-flute-sdp-03" intended for publication in the "Proposed Standard" category.  The document provides a Session Description Protocol specification for the FLUTE protocol which is being published as a Proposed Standard.  The title page properly indicates the RFC type.

(2) Document Announcement Writeup

Technical Summary

This document specifies the use of the Session Description Protocol (SDP)to describe the parameters required to begin, join, receive data from, and/or end FLUTE sessions.  It also provides a Composite Session SDP media grouping semantic for grouping media streams into protocol-specific sessions, such as multiple-channel FLUTE sessions.

 
Working Group Summary

    There is consensus in the WG to publish these documents.  A WG Last Call including co-announcement on the MMUSIC mailing list, was conducted in April 2012.

Document Quality

The document quality is high.  As mentioned above, an earlier version of this document had been approved for publication and was held in the editor's queue until some changes in the final FLUTE specification required its updated and resubmission.  The FLUTE specification has now been finalized and this supporting document is ready for publication.

Brian Adamson is the Document Shepherd.
Martin Stiemerling is the Responsible Area Director.


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The Document Shepherd is Brian Adamson, who has personally reviewed this version of the document and believes it is ready for forwarding to the IESG for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

I have no concerns here. The document had adequate review both from key WG members and from key non-WG members.  A request was also posted on the MMUSIC mailing list during the last call and at other times since the document specifies a Session Description per that working group's mechanisms.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Because the document contains a Session Description Protocol (SDP) specification, a request for review was cross-posted to the MMUSIC mailing list.  No comments were received on the most recent revision.  However, this document has a long history, having been submitted for publication previously and had review from MMUSIC members at that time. 


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of?

I have no concerns for this document.  In fact, an earlier version of the document had been approved for publication and was awaiting completion of the FLUTE specification upon which it depends.  Some changes in the final revises FLUTE specification required a minor update to this document that is now being submitted for publication.  The current FLUTE document has been now been approved for publication.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed.

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.


(8) Has an IPR disclosure been filed that references this document?

The document has no IPR disclosures.


(9) How solid is the WG consensus behind this document?

This document represent a solid consensus of the RMT WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

No discontent has been expressed.


(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).

There were no errors.  The couple of warnings listed were identified as benign.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

This document may require an SDP Directorate review.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) 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 plan for their completion?

The document references the "draft-ietf-rmt-flute-revised-16" document that is in the final stages of IETF publication as a Proposed Standard RFC.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no downward references (once the "flute-revised" draft mentioned above is published).

(16) Will publication of this document change the status of any existing RFCs?

No existing RFCs will be affected.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document.


The IANA Considerations are complete with the SDTP parameters registry properly identified.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.


The document identifies Rod Walsh (EMail: roderick.walsh (at) tut.fi) for the registrations listed.  No registries requiring Expert Review are identified.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

None are applicable.