Subject: [Sip] re: WGLC: resource priority

From: "Ken Carlberg" <[email-masked]>
Date: Thu, 15 Jan 2004 08:50:34 -0500

My apologies for the tardy comments on this thread.

> From: Rohan Mahy <[email-masked]> 
> Date: Wed, 31 Dec 2003 13:42:01 -0800
>
> 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.

I'll agree with Mike Pierce on this.  The header is just a vessel
designed to facilitate carrying a variety of values.  Specifications and
descriptions of behavior should not be in this draft.

> 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'm not thrilled about a registration template in this document at this
time.  My feeling is that should be addressed by subsequent document(s)
since the form of the registration is outside the scope of the header.  

As an example, I would take issue with line three above "Organization
responsible for Change Control".  On the surface, this implies
versioning of the namespace, which we don't have in the R-P header
format, and continued control by that organization.  Outside of who is
right or wrong on that point of discussion, it seems to me that its out
of scope of the definition of the header.

> would also consider including Section B.1 as section 9.4, B.2 -> 9.5, 
> B.3 -> 9.6

Given what I've stated above, I'd like section B to stay outside of the
body of the draft.  The items listed in that section are only an example
to consider.

Also, my preference would be to remove section A.  I think its helpful
for the drafts initial introduction to the group, but in the end, it's a
bit of overkill for the final document.

Regards,

-ken

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 15 Jan 2004 17:22:18 -0500

Janet P Gunn                                                                                              
                      /FED/CSC                 To:      <[email-masked]>                                                      
                                               cc:      [email-masked], [email-masked]                                           
                      01/15/2004 12:16         Subject: Re: [Sip] re: WGLC: resource priority(Document link: Janet P Gunn)      
                      PM                                                                                                        

I support Mike on this one.

The Resource Priority Header is the "protocol", not the "policy".  What
policy will be evoked in a particular Administrative Domain, by a
particular RPH namespace:value will be the subject of an SLA between
relevant parties.  Restrictions on the extent of the policy  (for instance
that it not be the instrument for DoS attacks) are already in the document.

Janet

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

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
----------------------------------------------------------------------------------------

                      <Mpierce1                                                                                                 
                      @aol.com>                To:      <[email-masked]>, <[email-masked]>                                       
                                               cc:                                                                              
                      01/14/2004 09:25         Subject: Re: [Sip] re: WGLC: resource priority                                   
                      PM                                                                                                        

In a message dated 12/31/2003 4:46:50 PM Eastern Standard Time,
[email-masked] writes:

IANA registration of each namespace, but those references are currently
appropriate sections.

[MAP] I believe this document should be limited to the definition of the
data (header) and leave detailed behaviour and procedures to other
documents that define specific services/capabilities which use it. It
should not specify detailed behaviour for specific priority values. The
references to IANA registration are thin because they only describe what
IANA needs to deal with - assigning an ordered set of names for the
priority levels for each "namespace".

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.

[MAP] While it may not be normal for a proxy to modify or delete an RP
header, there may be services defined using this header that are based on
proxies doing exactly that. For example, an originator tries to place a
call using a high priority header. The proxy authenticates, determines tha
the user is only authorized a lower priority level, automatically lowers it
by changing the RP header, and forwards the call on its way, without
requiring the UA to retry the call. Other documents would describe various
operations, possibly including some cases in which a proxy can not modify
the RP header.

Mike Pierce

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 15 Jan 2004 12:16:40 -0500

Janet

                                                                                                                                 
                      <Mpierce1                                                                                                  

Mike Pierce

---

From: Alex Audu <[email-masked]>
Date: Mon, 19 Jan 2004 14:13:59 -0600

Hi,

The questions I had while reading this draft were mostly along the points Rohan has listed.
There were attempts to describe behavior (section 4.5 User Agent Client Behavior, 4.6 User
Agent Server Behavior, and 4.6 Proxy Behavior), but these sections were very silent regarding
what actions these elements would take to prevent or ease congestion based on assigned
priority values.

Another issue that needs to be addressed is: what should be the behavior of these devices
to ensure low priority events/requests don't get starved out of processing resources?

I was also a bit confused by the fact that you seemed to be addressing authorization
issues within priority specifications (section 4.3, and 4.6 and 5.0 for example).  I think it
will be better to decouple authorization issues from this document and leave such issues
to drafts devoted to authorzation. Besides, authorization processing should have passed
before prioritization.

Lastly, is 417 (Unknown Resource-Priority) a new error code? I assume it is since it is not
in rfc 3261.   If so, can we make the name more generic,..like Unknown Value (or Parameter)?
This will aid re-use of this code, instead of it being limited to priority handling alone.

Regards,
Alex.

Rohan Mahy wrote:

> 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.
>
> 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?
> 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 [?]