Subject: [Sip] Re: Namespace registration for SIP RPH

From: [email-masked]
Date: Wed, 2 Jul 2003 23:04:22 EDT

In a message dated 7/2/2003 11:52:47 AM Eastern Standard Time, 
[email-masked] writes (to Henning):

> Draft-ietf-sip-resource-priority-00.txt, Section 12, IANA Considerations, 
> asks not only for registration of the basic components of the RPH, i.e., 
> namespace, ordered labels for priority, and a default, but adds that "the 
> registration MUST describe how SIP elements should treat requests from that 
> namespace, e.g., whether preemption or only preferential queuing are allowed.".  This 
> requirement really amounts to a service description of the way the namespace 
> is to be used.  
>  
> (As just a note, this position seems to be diametrically opposed to previous 
> discussions in ieprep (when the ID was under submission there) that seemed 
> to stress the protocol/policy distinction, in which the use of the namespace 
> for a service as a matter of policy.  However, I am glad to see the change.)
>  
> As I read the exchange between Mike Pierce and you on 24/25 June, you 
> concluded that assignments of namespaces should not be included in your RPH ID.  I 
> think that this is the right conclusion, particularly if the namespace value 
> assignments have to have an accompanying service description.  
> Am I correct in my understanding that you have agreed to take all the 
> namespace registrations our of your ID, i.e. all of Appendix B?
> 

Dennis,

I agree that we should be very careful on how much we try to put in the R-P 
header document or require to be submitted with a registration with regards to 
procedures (preemption, preferential queuing, etc.) These can be described 
separately, and in fact, do not really need to be in any RFC or registration if 
they are local actions. I agree that the header definition should be limited to 
just that, but we've been pushed into describing some of the procedures for 
the use of the header.

My comments about definition of namespaces was to not include ones for ETS, 
GETS, TDR, 911, etc since there is a lot of uncertainty on what values were 
needed and how several namespaces would relate. On the other hand "Assured 
Service" (based on MLPP) is very clear so should be included.

Mike Pierce

---

From: "Berg, Dennis" <[email-masked]>
Date: Thu, 3 Jul 2003 11:28:11 -0400

Henning Schulzrinne wrote:
As discussed, B.3 will be dropped since it is currently insufficiently 
well defined to be documented.

[Berg, Dennis] Ok, we will then submit an ID to address the ETS namespace.
Henning Schulzrinne wrote:
I think the goal should be that namespace registrations primarily 
require domain expertise, not protocol expertise. Thus, the important 
part is that the constituency for the namespace is well-represented in 
the review.
[Berg, Dennis] Fully agree.

---

From: "Berg, Dennis" <[email-masked]>
Date: Thu, 3 Jul 2003 11:52:59 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 02, 2003 11:04 PM
To: Berg, Dennis; [email-masked]
Cc: [email-masked]; Gunn, Janet
Subject: Re: Namespace registration for SIP RPH

Draft-ietf-sip-resource-priority-00.txt, Section 12, IANA Considerations,
asks not only for registration of the basic components of the RPH, i.e.,
namespace, ordered labels for priority, and a default, but adds that "the
registration MUST describe how SIP elements should treat requests from that
namespace, e.g., whether preemption or only preferential queuing are
allowed.".  This requirement really amounts to a service description of the
way the namespace is to be used.   

As I read the exchange between Mike Pierce and you on 24/25 June, you
concluded that assignments of namespaces should not be included in your RPH
ID.  I think that this is the right conclusion, particularly if the
namespace value assignments have to have an accompanying service
description.   
Am I correct in my understanding that you have agreed to take all the
namespace registrations our of your ID, i.e. all of Appendix B? 

Dennis, 

I agree that we should be very careful on how much we try to put in the R-P
header document or require to be submitted with a registration with regards
to procedures (preemption, preferential queuing, etc.) These can be
described separately, and in fact, do not really need to be in any RFC or
registration if they are local actions. I agree that the header definition
should be limited to just that, but we've been pushed into describing some
of the procedures for the use of the header. 

Mike Pierce 

[Berg, Dennis] 

What document is then the "official" service description for the DSN
namespace?  Henning references RFC 791 in the B1  DSN namespace section.
That reference does not seem to be the most appropriate. James Polk in this
requirements references the ITU document (ITU-T Recommendation I.255.3
(1990), "Multilevel precedence and preemption service (MLPP)") which would
seem more relevant and complete.