Subject: [Sip] draft-ietf-sip-rph-new-namespaces

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Oct 2007 23:01:40 -0400

Keith asked me to review the draft; here are a few quick comments:

While the mechanics and namespaces defined seem relatively  
straightforward, it is hard to evaluate anything beyond the syntax  
and editorial issues without knowing something about what motivated  
the design. Why 50 namespaces and not 42 or 99? Is this based on some  
existing PSTN technology or is this an attempt to have 50 departments  
in the DoD share some resource, without declaring who is more  
important than the other fiefdom or assistant vice deputy director?  
Why priority values that are even only?

Depending on the motivation and background, there could well be other  
designs, such as 250 levels, where preemption is only within groups  
of 5. I'm not arguing that this is a better design, but it's hard to  
say anything even vaguely interesting without knowing the requirements.

The wording is somewhat redundant, with the same information repeated  
three times, but in slightly different ways. In particular, the  
notion of non-preemption across namespaces seems to be couched in  
caveats. It seems that preemption across namespaces is sometimes  
permitted and sometimes not, which makes it rather difficult to build  
an implementation for the namespace without either a lot of  
configuration options or special software versions for each policy.  
We have seen in other areas that excessive configurability leads to  
interoperability problems and code complexity. I have a hard time  
picturing how to build such a configurable system without a monster  
language and all kinds of strange interactions. What happens if  
namespace 30 can preempt namespace 28, and vice versa? What about  
circular preemption chains (30 -> 17 -> 10)? In those cases, do  
namespaces have absolute priority, i.e., any priority in 30 beats any  
priority in 28? You'd have to create a matrix with 250 by 250 entries

Paragraph breaks appear to be random, with a single thought split  
into three paragraphs (introduction).

I can't parse sentences such as "matter of local policy. However,  
this policy is a known requirement..." What policy? The local policy,  
undefined?

Henning

_______________________________________________
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, 31 Oct 2007 14:25:23 -0400

In line

 
> Why priority values that are even only?

Priority values are completely arbitrary.  If you wanted to, you could 
have priority values

YP17
42
-Pi
i
e

> priority in 28? You'd have to create a matrix with 250 by 250 entries

I guess I am reading it somewhat differently from you.

I read nothing that suggests that one namespace (as a whole)can preempt 
another namespace.  In fact that is explicitly forbidden.

What is discussed as a possibility (consistent with RFC 4412)is making two 
or more namespaces "equivalent".   For instance, if you make dsn-000001 
and dsn-00000A "equivalent" then dsn-000001.0 and dsn-00000A.0 would be 
completely equal in priority. 

Similarly dsn-000001.8 and dsn-00000A.8 would be completely equivalent in 
priority.

In this case dsn-000001.0 could neither preempt, not be preempted by, 
dsn-00000A.0.  But dsn-000001.0 could be preempted by EITHER dsn-000001.8 
OR by dsn-00000A.8.

And dsn-000001.8  neither preempt, not be preempted by, dsn-00000A.8.  But 
dsn-000001.8 could preempt EITHER dsn-000001.0 OR dsn-00000A.0

Janet

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 31 Oct 2007 16:49:47 -0500

> > Why priority values that are even only?

I am changing the priority-value range to be 0-9, so all currently 
envisioned priority-values are in this doc, for these namespaces.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 31 Oct 2007 17:57:32 -0400

On Oct 31, 2007, at 2:25 PM, Janet P Gunn wrote:
> Priority values are completely arbitrary.  If you wanted to, you  
> could have priority values
>
> YP17
> 42
> -Pi
> i
> e
>

I'm not concerned about the specific labels; it is hard to review a  
draft when one has no idea *why* things are being done. Why 10 levels  
as opposed to 5 or 7?

>
> I read nothing that suggests that one namespace (as a whole)can  
> preempt another namespace.  In fact that is explicitly forbidden.
>

The draft talks a lot about local policy.

> What is discussed as a possibility (consistent with RFC 4412)is  
> making two or more namespaces "equivalent".   For instance, if you  
> make dsn-000001 and dsn-00000A "equivalent" then dsn-000001.0 and  
> dsn-00000A.0 would be completely equal in priority.
>

I didn't find this in the draft, so maybe it should be called out  
more visibly.

> Similarly dsn-000001.8 and dsn-00000A.8 would be completely  
> equivalent in  priority.
>
> In this case dsn-000001.0 could neither preempt, not be preempted  
> by, dsn-00000A.0.  But dsn-000001.0 could be preempted by EITHER  
> dsn-000001.8 OR by dsn-00000A.8.
>
> And dsn-000001.8  neither preempt, not be preempted by, dsn-00000A. 
> 8.  But dsn-000001.8 could preempt EITHER dsn-000001.0 OR dsn-00000A.0
>

Again, without any notion of what all this is supposed to accomplish  
it's hard to do more than a syntax review and spell checking.

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 31 Oct 2007 17:42:28 -0500

Henning

DISA wants to have 50 new namespaces within their network. It seems 
the 2 we had in RFC 4412 weren't enough for their plans. Don't ask me 
why we didn't know about this long ago, but some within that 
organization had this planned many years ago.

In a nutshell, they want to be able to assign different RPH 
namespaces to different branches of service (army, navy, air force, 
marines) as well as have temporary assignments to individual units 
(say, one task force, which is separate than the branch of 
service).  They came up with 50 as a good number to have at their disposal.

They have also upped the number of priority-values needed, with each 
namespace having the same number (0 through 9).  The even numbers 
were there because those are the only ones they plan on using for the 
next several years. The old numbers are for future use.  This draft 
should account for all that is known to be planned.

I've tried to remove any new usage rules from this draft, but leave 
in a few reminders about section 8 of 4412, so someone just looking 
at this wouldn't see those rules not mentioned.

I have a -01 available that calls out (more clearly) the equivalency 
rules within section 8 of 4412.  This new version also reduces the 
reminders of this to within one section of the draft.

Does this help?

James

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 31 Oct 2007 20:04:03 -0400

James,

thanks for the explanation. I think it would be useful to identify  
who is asking for this and why, so that others can judge whether they  
can use the same namespace or not. I don't think we want some other  
draft in a year that has

foobar-00
through
foobar-49

Henning

On Oct 31, 2007, at 6:42 PM, James M. Polk wrote:

> the 2 we had in RFC 4412 weren't enough for their plans. Don't ask  
> me why we didn't know about this long ago, but some within that  
> They have also upped the number of priority-values needed, with  
> each namespace having the same number (0 through 9).  The even  
> numbers were there because those are the only ones they plan on  
> using for the next several years. The old numbers are for future  
> use.  This draft should account for all that is known to be planned.
>
> I have a -01 available that calls out (more clearly) the  
> equivalency rules within section 8 of 4412.  This new version also  
> reduces the reminders of this to within one section of the draft.
>
> Does this help?
>
> James
>
>>> And dsn-000001.8  neither preempt, not be preempted by,  
>>> dsn-00000A. 8.  But dsn-000001.8 could preempt EITHER  
>>> dsn-000001.0 OR dsn-00000A.0
>>