Subject: Re: [Sip] -RP-05.txt: section 7.1 on priority-value interleaving

From: "James M. Polk" <[email-masked]>
Date: Wed, 17 Nov 2004 15:47:37 -0600

Section 7.1 is merely to give examples to readers that show the order 
within a namespace must be maintained regardless of how many other 
namespaces exist (that are supported) by that SIP element.

The section also provides examples of how the orders can be in multiple 
combinations of groupings, as long as the overall order within each 
namespace is not changed.

          Foo.3        Foo.3       Bar.C
          Foo.2        Bar.C       Foo.3
          Foo.1   or   Foo.2   or  Foo.2
          Bar.C        Bar.B       Foo.1
          Bar.B        Foo.1       Bar.B
          Bar.A        Bar.A       Bar.A

In each of these examples from section 7.1, the order of Foo.* remains the 
same (3 then 2 then 1), as does the order for Bar.* (C then B then A). 
Where each individual priority-value is relative to the other namespace 
priority-values is NOT specified (i.e where 3 fits into C,B,A, or where B 
fits into 3,2,1). The interleaved order of multiple namespaces is up to 
implementations and local policy to decide.

The only aspect you are PREVENTED from doing in this regard (to comply with 
this spec - whenever that is) is reordering priority-values within the same 
namespace no matter how many namespaces are supported.

 From a slightly different angle, you can consider two priority-values from 
two namespaces equivalent. The example given is:

      Bar.C    (highest priority)
  Foo.3  Bar.B <= these 2 are considered equivalent)
  Foo.2  Bar.A <= these 2 are considered equivalent)
      Foo.1    (lowest priority)

In this case, you can use some other indication to determine within your 
network if Foo.3 is to be treated above or below Bar.B - or you can leave 
them as identical in treatment.

other answers below

At 04:13 PM 11/17/2004 -0500, Janet P Gunn wrote:
>Technical question about ordering of the namespaces and values
>
>One approach we have used (in WPS) is
>
>a) When the resource pool is relatively small (e.g., radio traffic
>channels) we serve the  queue based on priority order first, and time stamp
>second.

ok

>b) When the resource pool is large (e.g. landline trunk groups) we  serve
>the queue (amongst all and only the "labeled" calls) by time stamp, without
>regard for the actual priority level.

the order of priority-value cannot change - if you wish to comply with this 
specification (once it becomes one). I know you plan on primarily using 1 
of your 5 priority levels. Within the same level, you can use whatever you 
want to apply whatever policy/treatment you want and still comply with this 
spec (once it becomes one).

>Does the text in section 7.1 PREVENT me from serving SIP messages WITH
>regard to BOTH the namespace and value  (and timestamp) in some contexts,
>and with regard to ONLY the namespace (and timestamp), but NOT the value in
>other contexts?

no prevention here

>I can foresee work arounds if it does prevent it,

it doesn't

>but I would be happier if
>that behavior were NOT prevented.

it's not

Are you happier?

>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.
>----------------------------------------------------------------------------------------
>
>
>
>
> 
>
>                       "James M. 
> Polk" 
>
>                       <jmpolk                  To:      [email-masked] 
 >
>                       @cisco.com>              cc: 
> [email-masked], Janet P Gunn/FED/CSC@CSC, [email-masked],
>                                                [email-masked], Dean Willis 
> <[email-masked]>, [email-masked],
>                       11/17/2004 03:36         "Pete Babendreier" 
> <[email-masked]>, "Scott Morrison"
>                       PM                       <[email-masked]> 
 >
>                                                Subject: Re: [Sip] 
> -RP-05.txt: section 7.1 and (rough) consensus debate
> 
>
>
>
>
>
>At 08:03 AM 11/17/2004 -0500, [email-masked] wrote:
> >In a message dated 11/16/2004 7:42:29 PM W. Europe Standard Time,
> >[email-masked] writes:
>
>snip
>
>Mike, pay attention to the ordering of two namespaces in the section -
>there are ZERO dependencies between namespaces, just that the order within
>each namespace MUST be maintained regardless of where one value from one
>namespace is places in relative priority order to one or more from another
>namespace. Implementors MUST have one order - no matter how many namespaces
>are supported at a server/endpoint - to relieve confusion of which is
>prioritized over or under another. This is the same rule that applies
>within a namespace: there MUST be one order of priority, period (No
>wildcards) to ensure interoperability.
>
>snip
>
>cheers,
>James
>
>                                 *******************
>                  Truth is not to be argued... it is to be presented

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

_______________________________________________
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: Wed, 17 Nov 2004 17:04:29 -0500

Yes, I am happier.

Janet

                                                                                                                             
                      "James M. Polk"                                                                                        
                      <jmpolk                  To:      Janet P Gunn/FED/CSC@CSC                                             
                      @cisco.com>              cc:      [email-masked], Dean Willis <[email-masked]>,          
                                               [email-masked], [email-masked], "Pete Babendreier" <[email-masked]>,    
                      11/17/2004 04:47         [email-masked], "Scott Morrison" <[email-masked]>, [email-masked]         
                      PM                       Subject: Re: [Sip] -RP-05.txt: section 7.1 on priority-value  interleaving    

Are you happier?

cheers,
James

                                *******************

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 18 Nov 2004 14:48:05 -0500

That would help with one of my concerns too- that for some resources we
need to prioritize based on the value and for other resources we only care
about the namespace.

                                                                                                                             
                      "James M. Polk"                                                                                        
                      <jmpolk                  To:      [email-masked], Janet P Gunn/FED/CSC@CSC                           
                      @cisco.com>              cc:      [email-masked], [email-masked], [email-masked],             
                      Sent by:                 [email-masked], [email-masked], [email-masked], [email-masked]   
                      sip-bounces              Subject: Re: [Sip] -RP-05.txt: section 7.1 on priority-value  interleaving    

                      11/18/2004 01:34                                                                                       
                      PM                                                                                                     

At 06:31 AM 11/18/2004 -0500, [email-masked] wrote:

>since it is permissible for an entity to give two levels the same
>treatment. For example, in the DSN, Flash and Flash Override may get the
>same treatment for packet transport at core routers while other entities
>may treat them different (endpoints or edge routers).

this is a good point, I will adjust the text to reflect this

>The above requirement is too important to "hide" in a section about
>multiple namespaces.
>
>The second paragraph above, and the text that shows relationships between
>different namespaces remains confusing since there is a clear agreement
>that there is no relationship between namespaces.

yet some remained confused until they saw examples of various combinations
that didn't violate the rule.

>This text clearly implies that there is a relationship. If someything
>needs to be said to explain this to people, then let's work on text to
>address the problem. I believe that the current text will just further
>confuse others (not me). I'm not confused by it because I know the truth.
>Others won't.
>
>Mike Pierce
>

cheers,
James

                                *******************