Subject: Re: [Sip] Introducing the "new bis" - draft-ietf-sip-rfc2543bis-05

From: "James M. Polk" <[email-masked]>
Date: Thu, 01 Nov 2001 15:48:45 -0600

All

Comments inserted

At 07:45 PM 10/31/2001 -0500, Henning G. Schulzrinne wrote:
>"Rosen, Brian" wrote:
>> 
>> I have been, and am still very interested in being able to implement
>> what is called MultiLevel Priority and Pre-emption in SIP.  As you
>> may recall, Jim Polk has made several proposals on this subject.
>> 
>> The current priority levels are advisory, the values are not defined,
>> and the current definition allows additional tokens to be used. I would
>> like to propose that the next revision, bis-06 deprecate the current
>> token values and substitute the 791 values.  I believe that, as the old
>> ones are indeed advisory, that any existing implementations would not break.
>
>I'm opposed to that. The original values reflect "human communications
>priorities", not network priorities. The RFC 791 priorities are
>
>          111 - Network Control
>          110 - Internetwork Control
>          101 - CRITIC/ECP
>          100 - Flash Override
>          011 - Flash
>          010 - Immediate
>          001 - Priority
>          000 - Routine
>
>Unless you work for the military, they are essentially meaningless to
>normal users. Anybody know what ECP is :-)?
>
>Since we suffer no shortage of header names, I would suggest that we
>have two different sets, one new header for "communications resource
>priority" (based on RFC 791 and/or the ones suggested by Jim Polk) and
>the existing Priority header for "human precedence", using the existing
>naming scheme.

My past drafts's suggested Priority levels are the lower 5 of RFC791 with
nothing allowed to be above or of higher Priority than RFC791's 100 Flash
Override. I am open to including 110 and 111 from above as non-endstation to
non-endstation traffic (I admit I don't know what ECP is -- but the value does
coincide with 101110 EF in Diffserv as the highest priority and being backwards
compatible under their charter to TOS enabled networks) -- which the usage of
(all of this) should be in a separate ID from the bis doc. 

In fact, I suggest a complete semantics ID for this new "communications
resource priority" Header, potentially as a follow-on to my previous drafts on
the subject. I could move MLPP off to the side as an example of how to use it. 

This would be Standards Track doc, Brian, and you stated this would most likely
put it in the SIP WG (vs. SIPPING) -- how about it as a WG item officially? I
haven't submitted my v-02 of MLPP over SIP yet, and there's still time to make
these changes before the Nov 21st cutoff. I'd modify the name, of course.

This doc will state (as my previous ID's have) that it is *only* IP Domain
specific, relying on SLA's to continue (or how to modify the values) past a
Domain Border. Placing this new header in the bis doc also helps in making
reverse compatibility doable on this whole topic.

>
>Usually, the two are closely related, but may not necessarily be. For
>example, most calls, from a network perspective, may be "Routine", but I
>may well consider it "High" priority for the receiving user.
>
>I've heard that 791-style values are often assigned based on military
>rank, so it could even be that a four-star general makes a "non-urgent"
>call on a "Flash" circuit.

This would be an administrative issue within the Domain implementing these
features/functionalities.

>
>Changing names is not a good idea in general since existing
>implementations may translate them into local languages (and leave
>unrecognized names alone).
>
>> 
>> If that is not acceptable, I'd propose that we ADD the RFC 791 tokens
>> to the existing tokens, with language explaining what happened.
>> 
>> Brian
>> 
>
>> >
>> > Why was the list of priorities taken from RFC 2076 rather
>> > than from RFC 791?
>> > RFC 2076 was informational and copied the list from RFC 1327
>> > (which was
>> > obsoleted by RFC 2156), They addressed mapping between X.400
>> > and RFC 822, but
>> > RFC 822 did not mention any such values. RFC 791 (and
>> > appropriate existing
>> > telephony standards) should form the basis of the priority
>> > definition field
>> > in SIP.
>> >
>
>
>> > Also, there needs to be an explicit statement concerning the
>> > order of the
>> > present and the new values. There is no order specified for
>> > the current set.
>> > Different people would come to different conclusions about
>> > the relative order
>> > of "Routine" and "non-urgent". It needs to state that the
>> > current four values
>> > are in the descending order "emergency, urgent, routine, and
>> > non-urgent". The
>
>Good idea. That clearly is needed for any set.
>
>> > order of the 5 new values is as defined in RFC 791 and
>> > applicable standards.
>> > Also, there should be no defined relation between the current
>> > set and the new
>> > added set. It is not expected that they would be used
>> > together, but if they
>> > are, it is a local issue on how to handle them.
>> >
>
>-- 
>Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>
>_______________________________________________
>Sip mailing list  http://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

*************************************
"People generally demand more respect for their own rights than they are
willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike 
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com