Re: [Insipid] Will the identifier pass unchanged through B2BUAs?

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 31 July 2013 16:50 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA33921E80CB for <insipid@ietfa.amsl.com>; Wed, 31 Jul 2013 09:50:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.387
X-Spam-Level:
X-Spam-Status: No, score=-0.387 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRIhG2YL5FJc for <insipid@ietfa.amsl.com>; Wed, 31 Jul 2013 09:50:26 -0700 (PDT)
Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id E76B121E808D for <insipid@ietf.org>; Wed, 31 Jul 2013 09:50:20 -0700 (PDT)
Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta12.emeryville.ca.mail.comcast.net with comcast id 71lw1m0081wfjNs014qJPj; Wed, 31 Jul 2013 16:50:18 +0000
Received: from dhcp-4066.meeting.ietf.org ([130.129.64.102]) by omta23.emeryville.ca.mail.comcast.net with comcast id 74o31m00q2CN8kq8j4o6xo; Wed, 31 Jul 2013 16:48:15 +0000
Message-ID: <51F93FC3.40206@alum.mit.edu>
Date: Wed, 31 Jul 2013 18:48:03 +0200
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Hadriel Kaplan <hadriel.kaplan@oracle.com>
References: <51F7A26B.1000704@ericsson.com> <C6504F53-FAF0-4DBF-811D-DD7960961B2B@oracle.com> <51F8BA2B.3030100@nostrum.com> <3CC43D36-9B37-4D86-AA71-5CE33BC13590@oracle.com> <51F8D216.50904@nostrum.com> <7F18DCB7-0B1A-44CE-A6B3-BDF514EBF717@oracle.com> <51F8E5F3.6050101@alum.mit.edu> <B610A79F-3E85-4ABC-9898-541F630905E7@oracle.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE91746@VOEXM31W.internal.vodafone.com> <72B7836E-BA8A-4473-8A3D-2FD391AB62FC@oracle.com>
In-Reply-To: <72B7836E-BA8A-4473-8A3D-2FD391AB62FC@oracle.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1375289418; bh=V+sJ07+5S132LFYoN7xkxAB0dgIRQpI6BF5C9Pa2Wz8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=h2dNwyLX/Dqhcgr5HDLmMfu+1m326kH31ws678oc3LGhVC9rUbPTQBpVC7d/27mLT UajtGMffjiQXZQUsSHQIH8yenbxDZ3DJO0EWAJVwc+IR7PKuGA3jXrFLEoCi8HbLBd kxWzDylpb7uCK4c8PdHSjXhxY1q5uAIaJHX40/ufuvMpfPdJ8CT6tTD6Te64H7Ern+ hZJYp0lMqRNmyrHMTn8zBVOEsSgh/5bpY5Sw5wlDGrvapFt3zd9BDTk1+HlN8E2J4Q gmPQHUtSXw4VZNrkDb8JVOmiwBmp0h3k98GerQy34dd9vLfIrKTFidAToz+U3pAn+D VnRi2TU2l9exQ==
Cc: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>, "insipid@ietf.org" <insipid@ietf.org>
Subject: Re: [Insipid] Will the identifier pass unchanged through B2BUAs?
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/insipid>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jul 2013 16:50:32 -0000

On 7/31/13 4:33 PM, Hadriel Kaplan wrote:
>
> On Jul 31, 2013, at 8:01 AM, "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com> wrote:
>
>> The question from Gonzalo was about REQ3:
>>
>> REQ3: The solution must require that the identifier, if present, pass
>> unchanged through SIP B2BUAs or other intermediaries.
>>
>> My interpretation was that 1) the solution document must contain the text "SIP B2BUAs or other intermediaries MUST NOT change the Session-ID header field value." and 2) no future drafts/RFCs are allowed to specify that a SIP B2BUA or intermediary may change the Session-ID header field value.
>
> Right.  It's kinda silly requirement wording, but yes ISTM that a statement in a solution document stating "SIP B2BUAs or other intermediaries MUST NOT change the Session-ID header field value", would indeed satisfy REQ3.
>
>
>> This is simplistic but I think it meets REQ3. The discussion on Gonzalo's question seems to me to be about a different requirement along the lines of "how the Session-ID header field is generated and used must be compared with generation and use of header fields that a SIP B2BUA or other intermediary removes or modifies to ensure that a SIP B2BUA or other intermediary does not have any reason to remove the Session-ID: header field."
>
> Yup.  Basically a "why do we think the MUST statement generated by REQ3 would actually be followed or not".

Because if they don't follow it then any product that wants to claim 
conformance to a feature that requires session-id will fail in the 
presence of such B2BUA. If those features are themselves valuable, then 
people will demand products that conform to them.

Yes, I know that is naive, but its all the leverage we have.

	Thanks,
	Paul