Subject: Re: [Sip] re: WGLC: resource priority

From: [email-masked]
Date: Thu, 15 Jan 2004 12:13:14 EST

Regarding IANA Considerations:

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

> 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:
> 
> 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?
> Priority values (ordered from least priority to greatest priority):
>    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 [?]
> 

I presume that, if these namespaces are registered by inclusion in this RFC, 
then change control continues to be under control of the IETF, by revision of 
this RFC. (In fact, the text indicates that changes "should not" occur.)

Other namespaces registered later are under change control of whoever 
registers them. (It isn't clear to me who can register new namespaces, and how.)

The IANA considerations and registration information should only contain what 
is needed for the registration. "Preempt or Prioritize" is not needed as part 
of the registration. It is a detail to be described in other RFCs or 
documents for the particular application. For example, some service might require that 
either be done depending on other conditions. In addition, there may be 
preferential treatments that would not be classified as either "preempt" or 
"prioritize", as described in my draft on the subject. Note that Section 2 of this 
draft lists 4 treatments, some of which I would not classify as being either 
"preempt" or "prioritize".

The security requirements depend on the application, so the registration 
should not make normative statements about what "MUST" be done.

Further, in Section 12, I believe it is necessary that the registration 
indicate the relative precedence levels (as shown in the above suggested template), 
not "may". It doesn't seem to make sense to not require specifying order, but 
yet require a default.

I continue to believe that every namespace must have at least two priority 
values defined. The statements in Section 3 indicate otherwise. A namespace with 
only one value (which therefore must be the default) would be useless.

Mike Pierce

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 15 Jan 2004 11:51:22 -0800

On Thursday, January 15, 2004, at 09:13 AM, [email-masked] wrote:
> I presume that, if these namespaces are registered by inclusion in 
> this RFC, then change control continues to be under control of the 
> IETF, by revision of this RFC. (In fact, the text indicates that 
> changes "should not" occur.)

Please do not confuse the change control of the *registration* with the 
change control of the *normative behavior*.  Only the change control of 
the registration is under the control of the IETF. Obviously if you 
change the normative behavior in a separate document, you need to 
change the registration to point at the changes behavior.

Recall that the IANA registration serves two purposes: 1) to prevent 
namespace conflicts, and 2) to allows implementors to find the 
documents relevant to any namespaces which interest them.

> The IANA considerations and registration information should only 
> contain what is needed for the registration. "Preempt or Prioritize" 
> is not needed as part of the registration. It is a detail to be 
> described in other RFCs or documents for the particular application. 
> For example, some service might require that either be done depending 
> on other conditions. In addition, there may be preferential treatments 
> that would not be classified as either "preempt" or "prioritize", as 
> described in my draft on the subject. Note that Section 2 of this 
> draft lists 4 treatments, some of which I would not classify as being 
> either "preempt" or "prioritize".

Can you provide an existence proof of a separate type of treatment?

> The security requirements depend on the application, so the 
> registration should not make normative statements about what "MUST" be 
> done.

That should be purely at the discretion of the registrar of each 
namespace.  If additional security requirements are warranted then they 
can certainly be included.  If there are no additional requirements or 
requirements are deferred to other documents then the registration 
should indicate that.

> Further, in Section 12, I believe it is necessary that the 
> registration indicate the relative precedence levels (as shown in the 
> above suggested template), not "may". It doesn't seem to make sense to 
> not require specifying order, but yet require a default.
> I continue to believe that every namespace must have at least two 
> priority values defined. The statements in Section 3 indicate 
> otherwise. A namespace with only one value (which therefore must be 
> the default) would be useless.

agreed to both.

thanks,
-rohan

---

From: "Ken Carlberg" <[email-masked]>
Date: Thu, 15 Jan 2004 17:09:32 -0500

>> namespace. If additional security requirements are warranted then 
>> they can certainly be included. If there are no additional 
>> requirements or requirements are deferred to other documents then 
>> the registration should indicate that.
>
registration 
> indicate the relative precedence levels (as shown in the above
suggested 
> template), not "may". It doesn't seem to make sense to not require 
> specifying order, but yet require a default.
otherwise. 
> A namespace with only one value (which therefore must be the default) 
> would be useless.
>
> agreed to both.

I disagree on the latter part that every namespace must have two
"priority" values.  If one has a binary "on/off" NameSpace Value, and
the "off" means that the message is to be treated the same as if the R-P
never existed, then I don't see why an additional Value must exist.  Its
counter to the age old practice of be conservative in what you send.

An example of such a binary condition is if I wanted to have a namespace
that mapped to the binary NS/EP codepoint of T1.631.

-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: Rohan Mahy <[email-masked]>
Date: Thu, 15 Jan 2004 17:46:52 -0800

Ken,

The binary namespace you described has TWO values.  (ON and OFF)

thanks,
-rohan