Re: [Sip] Comments of Resource Priority header

[Henning Schulzrinne <hgs@cs.columbia.edu>]

Mpierce1@aol.com wrote:


> 4.2 "Unknown namespace" error: The sentence with "it MAY serve ... if 
> and only if" seems strange. The "if and only if" appears to be 
> indicating a "MUST" situation. The rest of the sentence is confusing, 
> since it is saying that it depends on "if the request would ... 
> experience treatment no different than a non-labeled request", but the 
> whole point of the sentence is that it's treated "as if it had no 
> priority indication", that is, is non-labeled. Also, it seems that there 
I rephrased it, but basically the intent was that if, at the time of 
arrival of the request, labeled and non-labeled requests are treated the 
same, there doesn't seem to be a point to say "sorry, don't know this 
(but it wouldn't make any difference in any event)". In other words, 
under normal, no-overload operations conditions, where all requests are 
served, there is no need to reject requests that have the wrong label.

I don't think treating unknown namespaces the same as no R-P is right if 
the treatment differs. Rather than being routed into some inferior 
corner of the network if I guessed the wrong namespace, I should be told 
that I should be using a different namespace.

> The 2nd paragraph (beginning "If an unknown resource ...") continue to 
> be a problem, since it seems to mandate an impossible operation: the 
> element must make a decision based on the operation that should have 
> occurred for a namespace that it does not recognize. It must be assumed 
> that the phrase "or would get a different treatment" intends to say 
> "than if the namespace were recognized". This second paragraph should be 
> deleted.
I disagree. It simply says that if the treatment is different I ask for 
X, but you don't know X, and if the current treatment for some 
priorities is better than for default, I should be given a chance to 
apply for this better treatment rather than being silently sent into the 
long queue.


> The description in the 2nd paragraph would not be the allowed operation 
> in any case that I am aware of. For any use of this Resource-Priority 
> header, the user specifies the appropriate priority value for the call 
> being attempted. Therefore, no device (UAC) is allowed to reattempt a 
> failed call at a different (presumably higher) level. If the call is 
> rejected due to the attempted unauthorized use of a level or if the call 
> is blocked when attempted at a particular level, the only option is to 
> notify the user of this fact. If the user decides to reattempt the call 
> with a higher level, the UAC can not prevent this. But no UAC can be 
> allowed to automatically use a higher level.
While I can see that 'upgrading' priority is unlikely to be useful 
(although maybe human nature...), changing namespaces will be common.

> In any case, the rules for use of this Resource-Priority header should 
> be left to documents describing specific uses (namespaces).
This is just a MAY and simply describes UAC behavior.

> B.1 Reference to "critic-ecp" should be added before "flash-override" in 
> the list. The reference to "critic-ecp" should be deleted from the 2nd 
> paragraph since it was added to the 1st. A relative order needs to be 
> explicitly specified as requires by Section 12. This should specify that 
> "Routine" is the default. The following is suggested for the 1st paragraph:
>
> This document defines the namespace "dsn". The namespace "dsn" (Defense 
> Switched Network) contains the following priority values in the relative 
> order listed: "critic-ecp", "flash-override", "flash", immediate", 
> "priority", "and "routine", with "critic-ecp as the highest and 
> "routine" as the lowest. The default is "routine".
Maybe you and James can get together and figure out whether critic-ecp 
exists or not. He told me to remove it; I'm not familiar enough with the 
DSN to make the call.

> B.3 and B.4
> There is a confusion here since GETS and TDR are really the same thing. 
> These can not be split into separate namespaces.
Again, please discuss with my co-author. He insisted on two.

> Since the IANA considerations states that "the registration must 
> indicate the default", it is not possible to have a namespace with only 
> one value. It is necessary to define a second value which can be 
> designated as the default even if that value is never used in signaling.
Noted.

> B.4 The current defined value is incorrect. "Authorized_emergency" is 
> not the same as 911 or 112 calls placed by the general public. 
> "Authorized emergency" belongs with GETS. In the previous drafts, 
> authorized emergency and 911 were intended as two distinct values within 
> one namespace that covered GETS-type calls, 911-type calls, and normal 
> calls (i.e., the regular "public network").
>
> I believe the correct approach is to define a single namespace for the 
> "public network" environment with the following values (at a minimum):
> - Authorized emergency (GETS, etc.)
> - Public emergency (911, 112, etc.)
> - Normal
> Of course, "normal" is the default. Further, I know that there are some 
> who believe that multiple "Authorized emergency" levels are needed, 
> similar to what is defined for the Wireless Priority System mentioned in 
> Section 3.
>
> If this issue of the definition of multiple values to support authorized 
> emergency (GETS or TDR), public emergency calling (e.g., 911), and 
> various other priority schemes that might reside in the same "public" 
> network can't be quickly resolved, these should be removed from this 
> draft, to be added later by IANA registration.
Since this doesn't seem like a topic that is likely to be resolved soon, 
I would agree that punting on all of them seems the right thing. I don't 
want to further delay this while this is being hashed out by third parties.

> B.4 I'm not sure why the second paragraph under B.4 for the Defense Red 
> Switched Network was added. (This should have been a new section 
> number.) If kept, it also should specify that "Routine" is the default. 
Section heading was omitted by accident; added.



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip