Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1)

From: [email-masked]
Date: Fri, 12 Nov 2004 09:53:52 EST

Corey,

Thanks for the great analysis of the situation and the suggestions. I agree 
almost completely with what you suggested. I'll follow this up with a few minor 
points on your suggestions. But first, some comments on your questions, which 
might help understand why this approach was taken.

In a message dated 11/11/2004 6:12:39 PM Eastern Standard Time, 
[email-masked] writes:

> 1. Why support multiple namespace/priority (n-p) values in a single 
> message, in one or more R-P headers?  And if supported, should not the 
> n-p values in the message equate to the same priority level (for 
> example, dsn.flash and q735.1 would be equal)?  Would it not be better 
> to support only one n-p value per message, and recommend that a 
> proxy/gateway between networks supporting two different namespaces 
> handle mapping n-p values?
> ---- There may be/are networks which would support multiple levels.  The 
> draft is not dictating that there must be multiple levels.
> ---- As for having the n-p levels be "equal", James cited a GETS call 
> with a specific precedence which becomes a Routine call on the DSN.
> ---- Having a proxy/gateway mapped between namespaces is an viable 
> alternative.
> 

While it is a little hard to describe specific cases for the use of multiple 
namespaces, I believe it could be used, such as a GETS call originated in a 
military network that normally uses only the dsn namespace. The caller, knowing 
that the call will likely go outside the dsn, might be able to specify both 
dsn=flash and ETS=3. It is not possible to say that they "equal", since they are 
two separately defined lists of priorities which have no direct relationship. 
In one application, only the dsn namespace would have an effect while the 
call remains within the private network (DOD) for which it was defined. When the 
call gets to a PSTN gateway to jump into the "public" network, the dsn 
namespace/priority is discarded, since the "public" network does not support it. At 
the GW, the ETS namespace/priority is converted to the appropriate PSTN 
signaling which that netwrok supports. Note that in this case, the PSTN signaling 
does not have any further signaling of this value beyond the initial call setup 
message, which is why the SIP signaling would not include this R-P header in 
anything beyond the INVITE.

When an ETS call from the public network enters the dsn, it could be mapped 
to Routine or to some higher priority level if the PSTN signaling provided that 
information. That will be determine by the administrator of the network and 
what the GW is told to do. It certainly can't be defined in the R-P header 
draft.

Another application is a gateway between two networks which each use the R-P 
header but with different definitions. Lets say between the US DOD network 
with 5 values and another country's military network when that other country uses 
only 3 levels. The GW must map between the two sets according to a mutually 
agreed mapping. In each network, only one R-P header is used.

I believe it was agreed long ago that the R-P header draft should not try to 
define the interoperation/mapping between different namespaces. I think this 
approach should remain, since any attempt to define relationships would be 
overly complex and may conflict with what network operators want to do.

The first example above, with two namespaces being carried, is the reason why 
the required mode of operation in the dsn is that unknown namespaces are 
simply ignored and passed on. Known namespaces with unknown priorities need to be 
treated as errors, but not necessarily by failing a call.

Mike Pierce
Artel

_______________________________________________
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: Fri, 12 Nov 2004 10:32:59 -0500

Multiple namespaces.

It is highly likely that an NS/EP (National Security/Emergency
Preparedness) call will carry both the ets and wps namespaces.  This is
because you can not determine ahead of time whether the call will progress
to a WIRELINE gateway (in which case the mapping associated with the ets
namespace is needed) or to a WIRELESS gateway (in which case the mapping
associated with the wps namespace is needed).  We initially tired to define
a single namespace that would work for both situations, but were unable to,
given the constraints on namespace structure.

There is also the POSSIBILITY of a call (within one of the military
networks) carrying both the ets namespace and one of the MLPP based
namespaces (especially a call that is expected to terminate on the Public
network where the MLPP based namespace could be dropped while the ets
namespace is retained).  But this situation is still hypothetical.

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]                                
                      Sent by:                 cc:                                                                             
                      sip-bounces              Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1)  

                      11/12/2004 09:53                                                                                         
                      AM                                                                                                       

Corey,

Thanks for the great analysis of the situation and the suggestions. I agree
almost completely with what you suggested. I'll follow this up with a few
minor points on your suggestions. But first, some comments on your
questions, which might help understand why this approach was taken.

While it is a little hard to describe specific cases for the use of
multiple namespaces, I believe it could be used, such as a GETS call
originated in a military network that normally uses only the dsn namespace.
The caller, knowing that the call will likely go outside the dsn, might be
able to specify both dsn=flash and ETS=3. It is not possible to say that
they "equal", since they are two separately defined lists of priorities
which have no direct relationship. In one application, only the dsn
namespace would have an effect while the call remains within the private
network (DOD) for which it was defined. When the call gets to a PSTN
gateway to jump into the "public" network, the dsn namespace/priority is
discarded, since the "public" network does not support it. At the GW, the
ETS namespace/priority is converted to the appropriate PSTN signaling which
that netwrok supports. Note that in this case, the PSTN signaling does not
have any further signaling of this value beyond the initial call setup
message, which is why the SIP signaling would not include this R-P header
in anything beyond the INVITE.

When an ETS call from the public network enters the dsn, it could be mapped
to Routine or to some higher priority level if the PSTN signaling provided
that information. That will be determine by the administrator of the
network and what the GW is told to do. It certainly can't be defined in the
R-P header draft.

Another application is a gateway between two networks which each use the
R-P header but with different definitions. Lets say between the US DOD
network with 5 values and another country's military network when that
other country uses only 3 levels. The GW must map between the two sets
according to a mutually agreed mapping. In each network, only one R-P
header is used.

I believe it was agreed long ago that the R-P header draft should not try
to define the interoperation/mapping between different namespaces. I think
this approach should remain, since any attempt to define relationships
would be overly complex and may conflict with what network operators want
to do.

The first example above, with two namespaces being carried, is the reason
why the required mode of operation in the dsn is that unknown namespaces
are simply ignored and passed on. Known namespaces with unknown priorities
need to be treated as errors, but not necessarily by failing a call.

Mike Pierce
Artel _______________________________________________

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 15 Nov 2004 15:33:28 -0500

The .03 draft (and I think also the .04 draft) had a paragraph that said
   "Namespaces do not describe how they relate to other existing
   namespaces, as each namespace is independent of other registrations."

It doesn't seem to be in .05

Maybe it, or something like it, should be put back in.

Janet

                                                                                                                 
                      David R Oran                                                                               
                      <oran                    To:      "James M. Polk" <[email-masked]>                       
                      @cisco.com>              cc:      [email-masked], [email-masked], [email-masked]        
                      Sent by:                 Subject: Re: [Sip] -resource-priority-05.txt: Comments and        
                      sip-bounces              Recommendations (1)                                               

                      11/15/2004 02:43                                                                           
                      PM                                                                                         

On Nov 15, 2004, at 2:01 PM, James M. Polk wrote:

> Where is "mapping between namespaces" specified in the document now?
>
> I do not believe there is such a sentence/comment/statement, and there
> should not be one, so why was this brought up?
>
If somebody reads the doc expecting to see something and it isn't
there, two possibilities obtain:
(a) they don't "get it"
(b) a reasonable person might think that function a natural one to be
handled, but that's not the approach we took in designing this beastie.

The case at hand seems closer to (b) than (a), so I see no harm in
saying that namespaces are orthogonal as far as the specification is
concerned, and while it may be possible to map behavior between
namespaces, this document doesn't tell you how, and that's intentional.

Dave.

> At 03:22 PM 11/12/2004 -0500, [email-masked] wrote:
>> In a message dated 11/12/2004 11:58:14 AM Eastern Standard Time,
>> [email-masked] writes:
>>
>>
>>> Can we just add a sentence to the draft saying mapping between
>>> namespaces is out of scope and it should be addressed separately?
>>
>>
>> Yes, such a statement would be fine, but it should be along with a
>> statement that all interrelationship between namespaces is out of
>> scope.
>>
>> Mike
> cheers,
> James
>                                *******************
>                 Truth is not to be argued... it is to be presented
>
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 15 Nov 2004 16:20:00 -0600

>It doesn't seem to be in .05

see (the new) section 7.1 about the warnings of multiple namespaces

>Maybe it, or something like it, should be put back in.

see above

>                       David R 
> Oran 
>                       @cisco.com>              cc: 
> [email-masked], [email-masked], [email-masked]
>                       11/15/2004 
> 02:43 

cheers,
James

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

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 15 Nov 2004 17:57:51 -0500

7.1 starts with

"The only rules stipulated here regarding more than one namespace in
   a SIP message are:"

followed by a bulleted list..

May be it could be made stronger by saying, after the list, "Except for
these rules,  namespaces do not describe how they relate to other existing
namespaces."

"Only" should cover it, but if it isn't clear to some readers...

Janet

                                                                                                                 
                      "James M. Polk"                                                                            
                      <jmpolk                  To:      Janet P Gunn/FED/CSC@CSC, David R Oran <[email-masked]>  
                      @cisco.com>              cc:      [email-masked], [email-masked], [email-masked],   
                      Sent by:                 [email-masked]                                                  
                      sip-bounces              Subject: Re: [Sip] -resource-priority-05.txt: Comments and        
                                               Recommendations (1)                                               
                                                                                                                 
                      11/15/2004 05:20                                                                           
                      PM                                                                                         

see above

cheers,
James

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

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 16 Nov 2004 12:36:25 -0500

05 is being rewritten as 06.

The point about independance of namespaces has been made.

Let's see what comes out in 06 before spending time on dissecting the fine
points of 05, which will almost certainly be OBE.

Janet

                                                                                                                 
                      Mpierce1                                                                                   
                      @aol.com                 To:      [email-masked], Janet P Gunn/FED/CSC@CSC,              
                                               [email-masked]                                                    
                      11/16/2004 12:17         cc:      [email-masked], [email-masked], [email-masked]    
                      PM                       Subject: Re: [Sip] -resource-priority-05.txt: Comments and        
                                               Recommendations (1)                                               

I don't read anything in 7.1 as saying what the previous versions said.
What I think is needed is a very clear statement something like "neither
this document nor namespaces specify the interrelationship or interworking
between namespaces, such as mapping from one namespace to another at domain
boundaries". That was my understanding of the previous agreement.

As a result, the first bullet in Section 7.1, which states "There MUST be
one order of priorities a SIP element has to process to", while talking
about multiple namespaces in a message, seems to be wrong (or
misunderstood), since it seems to require something about the relationship.
In fact the example following this bullet list is trying to say something
about the "acceptable" ways that the SIP element may process multiple
namespaces. The part about what is "not acceptable" is not needed. The
examples of incorrect order within each individual namespace are not
allowed even without multiple namespaces.

Since the document should say that it does not address interworking between
namespaces, it should not contain this material.

I don't know what the second bullet is trying to say.

The third bullet is obvious, I thought, according to the rules of SIP. If
not, this statement could be worded better.

Section 7.1 should be deleted completely and replaced with a single
statement something like I proposed above.

( I guess this will start a long series of e-mails on what I find wrong in
-05.)

Mike Pierce

---

From: "Nguyen, An" <[email-masked]>
Date: Fri, 12 Nov 2004 11:55:02 -0500

Mike,
 
I agree with you that it would be overly complex to address all possible
mappings between namespaces in this draft. Mappings between namespaces
issues should be specifically addressed in different documents. Can we just
add a sentence to the draft saying mapping between namespaces is out of
scope and it should be addressed separately? Otherwise, we would never get
this draft published.
 
An

[Nguyen, An]  From: [email-masked] [mailto:[email-masked]]
Sent: Friday, November 12, 2004 9:54 AM
To: [email-masked]; [email-masked]
Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations
(1)

Corey, 

While it is a little hard to describe specific cases for the use of multiple
namespaces, I believe it could be used, such as a GETS call originated in a
military network that normally uses only the dsn namespace. The caller,
knowing that the call will likely go outside the dsn, might be able to
specify both dsn=flash and ETS=3. It is not possible to say that they
"equal", since they are two separately defined lists of priorities which
have no direct relationship. In one application, only the dsn namespace
would have an effect while the call remains within the private network (DOD)
for which it was defined. When the call gets to a PSTN gateway to jump into
the "public" network, the dsn namespace/priority is discarded, since the
"public" network does not support it. At the GW, the ETS namespace/priority
is converted to the appropriate PSTN signaling which that netwrok supports.
Note that in this case, the PSTN signaling does not have any further
signaling of this value beyond the initial call setup message, which is why
the SIP signaling would not include this R-P header in anything beyond the
INVITE. 

When an ETS call from the public network enters the dsn, it could be mapped
to Routine or to some higher priority level if the PSTN signaling provided
that information. That will be determine by the administrator of the network
and what the GW is told to do. It certainly can't be defined in the R-P
header draft. 

Another application is a gateway between two networks which each use the R-P
header but with different definitions. Lets say between the US DOD network
with 5 values and another country's military network when that other country
uses only 3 levels. The GW must map between the two sets according to a
mutually agreed mapping. In each network, only one R-P header is used. 

The first example above, with two namespaces being carried, is the reason
why the required mode of operation in the dsn is that unknown namespaces are
simply ignored and passed on. Known namespaces with unknown priorities need
to be treated as errors, but not necessarily by failing a call. 

Mike Pierce 
Artel

---

From: "Nguyen, An" <[email-masked]>
Date: Fri, 12 Nov 2004 11:55:02 -0500

Mike,

An

Corey, 

Mike Pierce 
Artel