draft-ietf-tsvwg-emergency-rsvp-03.txt and draft-ietf-nsis-qspec-17.txt

Hi all,

during the WGLC review comments for 
draft-ietf-dime-qos-attributes-02.txt and 
draft-ietf-dime-qos-parameters-01 we noticed that there is a mismatch 
regarding the IANA considerations for Resource Priority elements.

Section 5 of <draft-ietf-tsvwg-emergency-rsvp-03.txt> says:
"
   This document defines an ALRP Priority field in section 3.2 that
   contains a numerical value identifying the namespace of the
   application-level resource priority. The IANA already maintains the
   Resource-Priority Namespaces registry (under the SIP Parameters)
   listing all such namespace. However, that registry does not currently
   allocate a numerical value to each namespace. Hence, this document
   requests the IANA to extend the Resource-Priority Namespace registry
   in the following ways:
           - a new column should be added to the registry
           - the title of the new column should be "Namespace numerical
             Value *"
           - in the Legend, add a line saying "Namespace numerical
             Value = the unique numerical value identifying the
             namespace"
           - add a line at the bottom of the registry stating the
             following "* : [RFCXXX] " where XXX is the RFC number of
             the present document
           - allocate an actual numerical value to each namespace in
             the registry and state that value in the new "Namespace
             numerical Value *" column.
   A numerical value should be allocated immediately by IANA to all
   existing namespace. Then, in the future, IANA should automatically
   allocate a numerical value to any new namespace added to the registry. 

   [draft-ietf-nsis-qspec] also uses numerical values for Resource-
   Priority Namespaces. The request IANA to create a new registry to
   allocate numerical values to each namespace. We suggest that the
   approach above be followed instead (i.e. extend the existing
   registry) and that [draft-ietf-nsis-qspec] also makes use of the
   values defined in the new "Namespace numerical Value *" column of the
   extended existing Resource-Priority Namespace registry. In any case,
   the IANA should only do one of the two approaches (an not both). 
"

draft-ietf-nsis-qspec-17.txt says the following

"
   RPH Priority Parameter (8 bits):
   dsn namespace:
   The allocation policies are as follows:
   0-63: Standards Action
   64-255: Reserved
   drsn namespace:
   The allocation policies are as follows:
   0-63: Standards Action
   64-255: Reserved
   Q735 namespace:
   The following values are allocated by this specification:
   0-4: assigned as specified in Section 6.2.10:
   Q735 priority 4: q735.4
                 3: q735.3
                 2: q735.2
                 1: q735.1
                 0: q735.0
   The allocation policies for further values are as follows:
   5-63: Standards Action
   64-255: Reserved
   ets namespace:

   The following values are allocated by this specification:
   0-4: assigned as specified in Section 6.2.10:
   ETS priority 4: ets.4
                3: ets.3
                2: ets.2
                1: ets.1
                0: ets.0
   The allocation policies for further values are as follows:
   5-63: Standards Action
   64-255: Reserved
   wts namespace:
   The following values are allocated by this specification:
   0-4: assigned as specified in Section 6.2.10:
   WPS priority 4: wps.4   
                3: wps.3
                2: wps.2
                1: wps.1
                0: wps.0
   The allocation policies for further values are as follows:
   5-63: Standards Action
   64-255: Reserved
"

Clearly, there is a mismatch regarding the registration of the same 
values. I would therefore suggest that the authors get together and 
determine a solution.
In draft-ietf-dime-qos-parameters-01 we unfortunately need to refer to a 
registry and would therefore appreciate to have a resolution soon.

Furthermore, Ken posted a review of draft-ietf-dime-qos-parameters-01 to 
the DIME list that also points to an unnecessary constraint (in his 
view) regarding the usage of the priority parameters listed in Section 
6.2.10. Ken's review can be found at: 
http://www1.ietf.org/mail-archive/web/dime/current/msg02089.html

Ciao
Hannes