Re: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-sipcore-priority-00

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 14 November 2012 16:05 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFEF021F858E for <sipcore@ietfa.amsl.com>; Wed, 14 Nov 2012 08:05:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.391
X-Spam-Level:
X-Spam-Status: No, score=-0.391 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqVhJM1y-VQH for <sipcore@ietfa.amsl.com>; Wed, 14 Nov 2012 08:05:25 -0800 (PST)
Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 4C55121F84CF for <sipcore@ietf.org>; Wed, 14 Nov 2012 08:05:25 -0800 (PST)
Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by QMTA11.westchester.pa.mail.comcast.net with comcast id PQu01k0031ei1Bg5BU5Qre; Wed, 14 Nov 2012 16:05:24 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id PU5Q1k00T3ZTu2S3kU5Q6l; Wed, 14 Nov 2012 16:05:24 +0000
Message-ID: <50A3C142.5050002@alum.mit.edu>
Date: Wed, 14 Nov 2012 11:05:22 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: "Roy, Radhika R CIV (US)" <radhika.r.roy.civ@mail.mil>
References: <05b001cdc13a$8a8f3f40$9fadbdc0$@cisco.com> (dwing@cisco.com) <201211130233.qAD2XQUZ938095@shell01.TheWorld.com> <EDC0A1AE77C57744B664A310A0B23AE202D3002D95@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <071401cdc1b9$abbf8ba0$033ea2e0$@cisco.com> <50A2BB2B.2040301@alum.mit.edu> <8486C8728176924BAF5BDB2F7D7EEDDF4865E763@ucolhp9h.easf.csd.disa.mil>
In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF4865E763@ucolhp9h.easf.csd.disa.mil>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-sipcore-priority-00
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Nov 2012 16:05:26 -0000

Roy,

On 11/14/12 7:44 AM, Roy, Radhika R CIV (US) wrote:
> Hi, Paul:
>
> It is not true. We are suffering for not fixing (a) because of
> incompatibility in implementations from the SIP application layer to the
> IP/MPLS network (RSVP, DiffServ DSCP code points) layer along with dealings
> of emergency (E911) calls.
>
> We have to see all RFCs as I mentioned to an email to Adam that our
> explanations and semantics of RFC 3261 must be consistent with respect to
> other RFCs as well:
>
> "RFCs 4411 and 4412, 5478, 6433, 6061, 5031, and 3689 need to be seen for
> some guidance before explaining the labels so that terminologies and
> definitions do not overlap or contradict."

IMO what you are talking about is different from (a).

What (a) is about is the meaning of each individual priority value - 
they way that they differ from one another. I'm not aware of any reports 
of problems due to this lack, though there certainly could be some. (I 
was of the opinion that Priority:emergency was suitable for use in the 
psap-callback case, but others hypothesized that this would cause 
confusion. This is why we are preparing for the definition of a new 
value. But that is the *only* case I have heard of where the meaning of 
the Priority values has come up.)

What you are talking about is the difference between Priority and 
Resource-Priority. Resource-Priority and all the things built around it 
are *extensions* to SIP. If you find it difficult to distinguish the 
responsibilities of the extensions from those of the core, then I would 
consider that an inadequacy of the extension, not of the core.

Perhaps the ECRIT docs need to document further what the role is for the 
Resource-Priority header in emergency calls. But that is separate from 
*this* draft.

	Thanks,
	Paul (as co-chair)

> BR/Radhika
>
> -----Original Message-----
> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf
> Of Paul Kyzivat
> Sent: Tuesday, November 13, 2012 4:27 PM
> To: sipcore@ietf.org
> Subject: Re: [sipcore] Proposal: Call for adoption & WGLC:
> draft-roach-sipcore-priority-00
>
> (as individual)
> ....
> nobody is currently suffering for lack of a fix for (a).
> ....
> 	Thanks,
> 	Paul
>
>