Subject: [Sip] Namespace registration for SIP RPH

From: "Berg, Dennis" <[email-masked]>
Date: Wed, 2 Jul 2003 11:50:05 -0400

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?

I would like to see the process conform to RFC 2434, "Guidelines for Writing
IANA Considerations Sections in RFCs",  which suggests that "One way to
insure community review of prospective assignments is to have the requester
submit a document for publication as an RFC".   We have a new ID,
http://www.ietf.org/internet-drafts/draft-mcgregor-ieprep-bridging-bcp-00.tx
t
<http://www.ietf.org/internet-drafts/draft-mcgregor-ieprep-bridging-bcp-00.t
xt> , that proposes a different structure to cover what you have in B.3 for
GETS.  If you are dropping Appendix B from your ID, we do not have to
further work that here.

But, it does raise the question, if there should be an RFC developed for a
RPH namespace to serve GETS, what working group should this be done under -
SIP, ieprep?

Dennis Berg

CSC

[email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 02 Jul 2003 22:29:05 -0400

Berg, Dennis wrote:

> 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. 

Correct.

> 
>  
> 
> (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.)

Not really. The notion was that the protocol element itself would not 
express handling procedures, i.e., something like

Resource-Handling: ;preemption=yes ;priority=strict

would be encoding policy in the element itself. The algorithm has to be 
described somewhere, after all, if this is to be useful. Clearly, a 
description can say "it is up to the implementation/local administrative 
policy/local drunk driving laws/today's lottery numbers whether 
preemption is allowed".

> concluded that assignments of namespaces should not be included in your 
> RPH ID.  I think that this is the right conclusion, particularly if the 

You must be referring to a different exchange of emails than I remember. 
The exchange was in reference to currently ill-defined namespaces, such 
as the ETS/TDR/etc. namespace. While I don't see this as a big issue 
(I'm happy to include namespaces or not), I was primarily concerned 
about any registrations that, due to external gating conditions, would 
delay the progress of the draft.

I would find it useful to include these initial registration if only to 
set an example of how we envision registrations to look like, while 
people are still paying attention to this.

> namespace registrations our of your ID, i.e. all of Appendix B?

I believe you misread our email exchange.

> 
>  
> 
> I would like to see the process conform to RFC 2434, "Guidelines for 
> Writing IANA Considerations Sections in RFCs",  which suggests that "One 
> way to insure community review of prospective assignments is to have the 
> requester submit a document for publication as an RFC".   We have a new 
> ID, 
> http://www.ietf.org/internet-drafts/draft-mcgregor-ieprep-bridging-bcp-00.txt, 
> that proposes a different structure to cover what you have in B.3 for 

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

> 
>  
> 
> But, it does raise the question, if there should be an RFC developed for 
> a RPH namespace to serve GETS, what working group should this be done 
> under - SIP, ieprep?

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.

_______________________________________________
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