IETF Logo Mail Archive

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

Hadriel Kaplan <hadriel.kaplan@oracle.com> Wed, 31 July 2013 14:34 UTC

Return-Path: <hadriel.kaplan@oracle.com>
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 62DC621E811D for <insipid@ietfa.amsl.com>; Wed, 31 Jul 2013 07:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.579
X-Spam-Level:
X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 uSXKo3DDuOeH for <insipid@ietfa.amsl.com>; Wed, 31 Jul 2013 07:33:53 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id A003C21F962D for <insipid@ietf.org>; Wed, 31 Jul 2013 07:33:53 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6VEXomr031145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 31 Jul 2013 14:33:51 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6VEXn18025948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Jul 2013 14:33:50 GMT
Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6VEXnoA026029; Wed, 31 Jul 2013 14:33:49 GMT
Received: from dhcp-1322.meeting.ietf.org (/130.129.19.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 31 Jul 2013 07:33:49 -0700
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Hadriel Kaplan <hadriel.kaplan@oracle.com>
In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE91746@VOEXM31W.internal.vodafone.com>
Date: Wed, 31 Jul 2013 10:33:47 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <72B7836E-BA8A-4473-8A3D-2FD391AB62FC@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>
To: "Dawes, Peter, Vodafone Group" <Peter.Dawes@vodafone.com>
X-Mailer: Apple Mail (2.1508)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "insipid@ietf.org" <insipid@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
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 14:34:00 -0000

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".

-hadriel

v2.23.0 | Report a Bug | By Email