Subject: [Sip] re: WGLC: resource priority

From: Rohan Mahy <[email-masked]>
Date: Wed, 31 Dec 2003 13:42:01 -0800

Hi,

Below is my review of resource-priority. Detailed comments are below, 
but I have a few general ones:

1. There is no normative description of the behavior of SIP devices 
which receive a particular priority value.  Some specifications needs 
to either specify detailed behavior for specific priority values, or 
the detailed semantics of those values.  I think this belongs in the 
IANA registration of each namespace, but those references are currently 
very thin.  I made some specific comments to this end in the 
appropriate sections.

2. Also, I am curious what the semantics of this header mean in the 
context of SUB/NOT.  Can someone provide an example that makes sense?

3. Finally, the document shows that proxies can modify, insert, and 
delete the RP header. I don't think this is a good idea. Where 
cooperating UAs and proxies need to agree on an RP value, I believe the 
session policy mechanism can be used.  A proxy can reject the message 
for policy reasons (use a lower/higher/specific resource-value) and the 
UA can retry the request with these new values.

thanks,
-rohan

--------------

detailed comments:

put TOC at the beginning

section 2

suggest
...telephone circuits, IP bandwidth  ^reservations or allocations^...

remove or motivate references to presence

section 3:

"   Implementations MAY change the value offered in the request; in some
    environments, the response value is known to be the same as in the
    request."   ???  what does that mean ???

BNF is wrong (your current syntax would require a leading comma).  do 
this instead:

Resource-Priority = "Resource-Priority" HCOLON Resource-value

Accept-Resource-Priority = "Accept-Resource-Priority" HCOLON
			[Resource-value *(COMMA Resource-value)]

check consolidated bnf for reuse of terms

also, the case of Resource-value is highly unusual.

reword this, it is awkward:

"        We require that even namespaces with only one priority
         value list that value to avoid problems if additional
         priority values are added later."

There may be multiple resource values or, equivalently, multiple
    Resource-Priority header /fields/field values/.

what does it mean to "support" a particular Resource-value?

our current method list is:
INV ACK CAN BYE REG OPT PRA
SUB NOT UPD MSG REF INF PUB

what does RP mean in a SUB or NOT?

where is section 4.2?

section 4.3

add comma here please...
Elements receiving
    requests with namespaces or priority values that they do not
    understand  ^,^ act according to the rules in the next section.

section 4.4:  you should introduce the resource-priority option tag 
(just the tag) back in section 3

section 4.7:  i don't think a proxy should be able to insert, delete, 
or modify the RP header.  This makes it impossible to use e2e on the RP 
headers, which I think will be required.

section 9-12:

option-tags are always lowercase by convention

you should add a note to the RFC editor asking for RFCXXXX to be 
replaced with the RFC number of this document.

please make section 9 be IANA considerations  (start with the text in 
section 12), then under this, create section 9.1 (formerly section 9) 
to register the new headers, section 9.2 (formerly section 10) to 
register the resource-priority header, section 11 becomes 9.3.

include a registration template  (for example)

Namespace:
Description:
Organization Responsible for Change Control of this Namespace:
Priority values (ordered from least priority to greatest priority):
Default priority:
Preempt or Prioritize:
Document Containing Normative Description:
Section Containing Normative Description:
Additional security requirements:

I would also consider including Section B.1 as section 9.4, B.2 -> 9.5, 
B.3 -> 9.6
(IANA will be happy if all the work they have to do is consolidated 
under a single 1st-level section heading).

in any case for the initial registrations, please fill in the template 
for each one; for example:

Namespace: q735
Description: ITU Q.735.3 Multi-level precedence and preemption in SS7
Organization Responsible for Change Control of this Namespace: ITU-T
Priority values (ordered from least priority to greatest priority): 4, 
3, 2, 1, 0
Default priority: 4
Preempt or Prioritize: prioritize
Document Containing Normative Description: ITU-T Q.735.3 [3]
Section Containing Normative Description: ??
Additional security requirements: none

Namespace: dsrn
Description: United States Defense Red Switched Network
Organization Responsible for Change Control of this Namespace: US 
Department of Defense?
Priority values (ordered from least priority to greatest priority):
   routine, priority, immediate, flash, flash-override, 
flash-override-override
Default priority: routine
Preempt or Prioritize: preempt
Document Containing Normative Description: FIPS XXXX ??  [?]
Section Containing Normative Description: ??
Additional security requirements: All implementations must follow the 
certificate management guidelines specified in xxxx [?]