Subject: [MMUSIC] [Fwd: WGLC: draft-ietf-mmusic-rfc2326bis-22]

From: Magnus Westerlund <[email-masked]>
Date: Wed, 23 Sep 2009 13:34:29 +0200

Hi,

Michelle has earlier promised me a review of this documents IANA
section. As it is now in WG last call in MMUSIC I would appreciate if it
could happen by the end of the WG last call the 19th of October.

The reason we want early review is that the document contains a quite
extensive IANA section that is 17 pages long that creates a large number
of registries.

Thanks

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

Subject: WGLC: draft-ietf-mmusic-rfc2326bis-22
From: Joerg Ott <[email-masked]>
To: [email-masked]
Cc: Jean-Francois Mule <[email-masked]>, Magnus Westerlund <[email-masked]>, Martin Stiemerling <[email-masked]>
Date: Sun, 20 Sep 2009 19:19:18 +0300

Folks,

as agreed in Stockholm, we are issuing working group last
call on the revised RTSP spec, draft-ietf-mmusic-rfc2326bis-22
heading for Proposed Standard.
(http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-22)

The WGLC will expire in four weeks, on 19 Oct 2009.

We know that this is a long spec, the more important is it
to receive thorough review by the community.  While we have
three volunteer reviewers (thanks again!), we urge everyone
who cares to provide detailed feedback.

Please review the document and post your comments to the
MMUSIC list and/or the authors.

Thanks,
Joerg

MMUSIC co-chair

---

From: "Michelle Cotton via RT" <[email-masked]>
Date: Mon, 28 Sep 2009 13:57:49 +0000

Magnus, 

I hope this review helps..
We will officially review this document in IETF Last Call.  Hopefully these comments will assist in getting 
the document's IANA section close to perfect.

Best regards,

Michelle
IANA

IANA COMMENTS:

IANA has examined draft-ietf-mmusic-rfc2326bis-22. While the IANA 
Considerations in Section 22 are very helpful and quite detailed, IANA has some 
comments and questions about the draft.

General questions for the authors:
IANA notes that four registries for RTSP v1.0 are located at: 
http://www.iana.org/assignments/rtsp-parameters/rtsp-parameters.xhtml. IANA 
would like to confirm that these registries (Headers, Methods, Option Tags and 
Status Codes) are to remain in place for compatibility purposes. Is this 
correct?

The structure of the RTSPv1.0 registry was to provide a single repository for 
all RTSP parameter registries. One possibility for the new RTSP v2.0 registry 
is to simply create a new file/repository for the v2.0 parameters. Another 
possibility is to simply extend the existing repository to contain both v1.0 
and v2.0 parameters. Which of these options is preferred by the authors?

Upon approval of this document, IANA understands that there are to be four 
major actions completed by the IANA:

1] the creation of 18 new registries (see below) in a registry location to be 
determined;
2] the registration of three new, permanent URI schemes (in 
http://www.iana.org/assignments/uri-schemes.html); and,
3] the registration of three new SDP attributes (in 
http://www.iana.org/assignments/sdp-parameters)
4] the registration of a Media Type for text/parameters (in MIME Media Types 
registry located at: http://www.iana.org/assignments/media-types/index.html.

Part 1:
=======

IANA understands that eighteen new registries are to be created.

1.1 A new registry called RTSP v2.0 feature-tags. The description of the 
contents of the registry is in section 22.1.1 of the draft document. IANA 
understands that future registrations are to be done on a first come, first 
served basis. IANA also understands that there are four initial values to be 
initially registered and that these are documented in section 22.1.3 of the 
draft. For each item in the RTSP v2.0 feature-tags registry, IANA understands 
that four fields will be registered:

- the name of the feature tag (with rules for the creation of the name 
documented in section 22.1.2);
- a description of the feature tag (a simple text string); 
- a indication of whether or not the feature tag applies to clients, servers or 
proxies (non-exclusively). and,
- a reference for the source of the registry value (e.g. RFC, etc.)

QUESTION TO AUTHORS: Is there a limit on the length of the description? Should 
the indication of whether or not the feature tag applies to clients, servers or 
proxies be provided as a matrix, or simply text?

1.2 A new registry called RTSP v2.0 Methods. The description of the meaning of 
RTSP Methods, the content of the registry, is in section 13 of the draft 
document. IANA understands that future registrations are to be done IETF 
Standards Action only. IANA also understands that there are ten initial values 
to be initially registered and that these are documented in section 13 of the 
draft. 

QUESTION TO AUTHORS: Should this registry mimic the presentation of Table 7 in 
Section 13 of the draft document? If so, could the authors ensure that the 
table column headings have full descriptions and provide any advice about which 
fields should be in the registry and which are simply guidance for the reader 
of the draft?

1.3 A new registry called RTSP v2.0 Status Codes. IANA understands the 
description of RTSP v2.0 Status Codes to be "A status code is the three digit 
number used to convey information in RTSP response messages." IANA also 
understands that future registrations are to be done through IETF Standards 
Action only. IANA also understands that there are 46 initial values to be 
initially registered and that these are to be extracted from the ABNF 
documentation for "Status-Code" in section 20.2.2 of the draft. For each item 
in the RTSP v2.0 Status Codes registry, IANA understands that three fields will 
be registered:

- the three digit status code; 
- the meaning of the status code; and,
- a reference for the source of the registry value.

QUESTION TO AUTHORS: IANA is unsure how to handle the value "extension-code." 
Is a separate registration for "setension-code" required?

1.4 A new registry called RTSP v2.0 Headers. IANA intends to use the 
description provided in section 22.4.1 of the document for this registry. IANA 
understands that future registrations are to be done using Expert Review. IANA 
also understands that there are 68 initial values to be initially registered 
and that these are to be extracted from Section 16 (57 values) and Section 
22.4.3 (11 values) of the draft. 

QUESTION TO AUTHORS: For each item in the RTSP V2.0 Headers registry, what 
values are recorded? The name, descirption, and reference sufficient, or 
should there be other fields for each entry in the registry?

1.5 A new registry called RTSP v2.0 Accept-Credentials policies. IANA 
understands the description of RTSP v2.0 Accept-Credentials policies to be 
defined in Section 22.5.1 of the document. IANA also understands that future 
registrations are to be done through IETF Standards Action only. IANA also 
understands that there are three initial values to be initially registered and 
that these are "Any" "Proxy" and "User" 

QUESTION TO AUTHORS: Beside the name of the Accept-Credentials value and a 
reference to where it is defined, are there any other fields that should be in 
this registry based on the definitions in Section 19.3.1 of the document?

1.6 A new registry called RTSP v2.0 Accept-Credentials hash algorithms. IANA 
understands the description of RTSP v2.0 Accept-Credentials hash algorithms to 
be the first sentence of text in Section 22.5.2 of the document. IANA also 
understands that future registrations are to be done through IETF Standards 
Action only. IANA also understands that there are no initial values to be 
registered upon approval of the document. 

QUESTION TO AUTHORS: If there were items in this registry, what fields would be 
registered for each item (name, reference, etc.)?

1.7 A new registry called RTSP v2.0 Cache Directive Extensions. IANA 
understands the description of RTSP v2.0 Cache Directive Extensions to be the 
first paragraph of the text in section 22.6 of the document. IANA also 
understands that future registrations are to be done through IETF Standards 
Action only. IANA also understands that there are 10 initial values to be 
registered upon approval of the document and that these are identified in 
section 22.6 of the document. For each item in the RTSP v2.0 Cache Directive 
Extensions registry, IANA understands that four fields will be registered:

- the name of the directive;
- the definition of the value;
- specification if it is a request or response directive; and,
- a reference for the source of the registry value.

1.8 A new registry called RTSP v2.0 Media Properties. IANA understands the 
description of RTSP v2.0 Media Propoerties to be the text in section 22.7.1 of 
the document. IANA also understands that future registrations are to be done 
using a designated expert. IANA also understands that there are ten initial 
values to be registered upon approval of the document and that these are 
identified in section 16.28 of the document. For each item in the RTSP v2.0 
Media Properties registry, IANA understands that three fields will be 
registered:

- the name of the media property;
- a contact name for the property;
- the description of the media property; and, 
- a reference for the source of the registry value.

QUESTION TO AUTHORS: IANA understands that the property values identified in 
Section 16.28 are to be registered but not the property groups. Is this 
correct? 

1.9 A new registry called RTSP v2.0 Notify Reason Values. IANA understands the 
description of RTSP v2.0 Status Codes to be the first two sentences of the text 
in section 22.8.1 of the document. IANA also understands that future 
registrations are to be done using a designated expert. IANA also understands 
that there are three initial values to be registered upon approval of the 
document and that these are to be extracted from the values defined in the 
Notify-Reas-val ABNF in Section 20.2.3. For each item in the RTSP v2.0 Notify 
Reason Values registry, IANA understands that four fields will be registered:

- the Notify Reason Value;
- the definition of the value;
- a contact name; and,
- a reference for the source of the registry value.

1.11 A new registry called RTSP v2.0 Range Header formats. IANA understands 
the description of RTSP v2.0 Range Header formats to be the first sentence of 
text in Section 22.9 of the document. IANA also understands that future 
registrations are to be done through IETF Standards Action only. IANA also 
understands that there are no initial values to be registered upon approval of 
the document. 

QUESTION TO AUTHORS: If there were items in this registry, what fields would be 
registered for each item (name, description, reference, etc.)?

1.12 A new registry called RTSP v2.0 Terminate-Reason Header Redirection 
Reasons. IANA understands the description of RTSP v2.0 Terminate-Reason Header 
Redirection Reasons to be the first two sentences of the text in section 16.50 
of the document. IANA also understands that future registrations are to be 
done using a designated expert. IANA further understands that there are two 
initial values to be registered upon approval of the document and that these 
are in section 22.10.1 of the document. For each item in the RTSP v2.0 
Terminate-Reason Header Redirection Reasons registry, IANA understands that 
three fields will be registered:

- the Terminate-Reason Header Redirection Reason;
- the description of the reason; and,
- a reference for the source of the registry value.

1.13 A new registry called RTSP v2.0 Terminate-Reason Header Parameters. IANA 
understands the description of RTSP v2.0 Terminate-Reason Header Parameters to 
be the first two sentences of the text in section 16.50 of the document. IANA 
also understands that future registrations are to be done through IETF 
Standards Action only. IANA further understands that there are two initial 
values to be registered upon approval of the document and that these are in 
section 22.10.2 of the document. For each item in the RTSP v2.0 Terminate-
Reason Header Parameters registry, IANA understands that four fields will be 
registered:

- the Terminate-Reason Header Parameter;
- the description of the parameter; 
- a contact name; and,
- a reference for the source of the registry value.

1.14 A new registry called RTSP v2.0 RTP-Info header parameters. IANA 
understands the description of RTSP v2.0 RTP-Info header parameters to be 
extracted from section 16,43 of the document IANA also understands that future 
registrations are to be done using a designated expert. IANA further 
understands that there are two initial values to be registered upon approval of 
the document and that these are in section 22.11.3 of the document. For each 
item in the RTSP v2.0 RTP-Info header parameters registry, IANA understands 
that four fields will be registered:

- the RTP-Info header parameter value;
- the description of the value; 
- a contact name; and,
- a reference for the source of the registry value.

1.15 A new registry called RTSP v2.0 Seek-Style Policies. IANA understands the 
description of RTSP v2.0 Seek-Style Policies to be extracted from section 16.45 
of the document New registry values require specification and a designated 
expert. IANA further understands that there are three initial values to be 
registered upon approval of the document and that these are in section 22.12.3 
of the document. For each item in the RTSP v2.0 Seek-Style Policy registry, 
IANA understands that four fields will be registered:

- the Seek-Style Policy value;
- the description of the value; 
- a contact name; and,
- a reference for the source of the registry value.

1.16 A new registry called RTSP v2.0 Transport Protocol Specification. New 
registry values require speficiation and a designated expert. IANA also 
understands that there are 12 initial values to be registered upon approval of 
the document and that these are in section 22.13.1 of the document. For each 
item in the RTSP v2.0 Transport Protocol Specification, IANA understands that 
four fields will be registered:

- the RTSP v2.0 Transport Protocol Specification value;
- the description of the value;
- a contact name; and,
- a reference for the source of the registry value

QUESTION TO AUTHORS: Is there a description for the RTSP v2.0 Transport 
Protocol Specification available?

1.17 A new registry called RTSP v2.0 Transport Modes. New registry values 
require IETF Standards Action. IANA also understands that there a single 
initial value to be registered upon approval of the document and that this is 
in section 22.13.2 of the document. For each item in the RTSP v2.0 Transport 
Modes, IANA understands that four fields will be registered:

- the RTSP v2.0 Transport Mode value;
- the description of the value;
- a contact name; and,
- a reference for the source of the registry value

QUESTION TO AUTHORS: Is there a description for the RTSP v2.0 Transport Modes 
available?

1.18 A new registry called RTSP v2.0 Transport Parameters. New registry values 
require Specification and a Designated Expert. IANA also understands that 
there are no initial values to be registered upon approval of the document. 

QUESTION TO AUTHORS: Is there a description for the RTSP v2.0 Transport 
Parameters available? If there were items in this registry, what fields would 
be registered for each item (name, description, reference, etc.)?

Part 2:
=======

IANA understands that, upon approval of this document, three new URI schemes 
would be registered in the Permanent URI scheme registry located at: 
http://www.iana.org/assignments/uri-schemes.html -- these three URIs are:

2.1 URI Scheme Name: rtsp
URI Scheme Description: Real-time Streaming Protocol (RTSP)
Reference: TBD

2.2 URI Scheme Name: rtsps
URI Scheme Description: RTSP over TLS
Reference: TBD

2.3 URI Scheme Name: rtspu
URI Scheme Description: RTSP over unreliable datagram transport

Part 3:
=======

IANA understands that, upon approval of this document, three new SDP attributes 
would be registered in the Session Description Protocol (SDP) Parameters 
regristry located at http://www.iana.org/assignments/sdp-parameters. These 
three entries would be placed in the "- att-field (both session and media 
level)" registry. The attributes are:

3.1 SDP name: range
Reference: TBD

3.2 SDP name: control
Reference: TBD

3.3 SDP name: mtag
Reference: TBD

Part 4:
=======

IANA understands that, upon approval of this document, a single entry is to be 
added to the MIME Media Types registry located at: 
http://www.iana.org/assignments/media-types/index.html.

This entry would be added to the "text" Media Type and would add a new Subtype 
of "parameters"

The reference would be TBD.

IANA understands that the creation of eighteen new registries and these three 
other actions are all the IANA actions required upon approval of this document.