Re: [MMUSIC] [IANA #267864] [Fwd: WGLC: draft-ietf-mmusic-rfc2326bis-22]

[Magnus Westerlund <magnus.westerlund at ericsson.com>]

Many thanks for the comments,

Please see inline for clarifications on how we intended to resolve the
raised comments.

Michelle Cotton via RT skrev:
> 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?

Yes, those registries are intended to remain as there might still be
developments for RTSP 1.0.

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

The registries for RTSP 2.0 should go to a file page to make it clear
that they are different registries. I will clarify the introduction to
the section.

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

This seems to be correct.

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

No, but we can clarify that it intended to be reasonably short, no more
than a paragraph. Is that a problem?

 Should
> the indication of whether or not the feature tag applies to clients, servers or 
> proxies be provided as a matrix, or simply text?

If a matrix isn't to much problem I think that would useful.

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

The table can be simplified and is sufficient with method name,
directionality, and reference. Will add such a table in section 22.2.3.


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

No, "extension-code" in the ABNF is to define the syntax allowed for
future values. It requires no IANA action.

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

Name, description and reference are clearly sufficient.

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

No, that seems sufficient.

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

Will clarify which items that goes into the registry and what the
columns will be.

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

All these fields will not be needed in the registry. Will reduce this to
name and reference.

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

Yes.

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

Instead of definition, I think a short description is appropriate.

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

There are initial values, will clarify which they are and what columns
needs to be included in the registry: Name, short description and
reference.

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

Yes.

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

The policy is Specification required, not Standards action.

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

Yes. will provide clarified registration data.

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

Yes, will provide clarified initial values.

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

There is a syntax that can be included. Also I can reformat the initial
values into a table to be clearer

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

Will include reference to the syntax element and its decription.

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

Will clarify with reference for definition of the element the registry
applies.

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

Yes.

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

Yes, but I think we need to clarify that RFC 2326 are applicable for
range and control also.

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

Yes.

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: magnus.westerlund at ericsson.com
----------------------------------------------------------------------