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

[Hannes Tschofenig <Hannes.Tschofenig at gmx.net>]

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



_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis