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

Hadriel Kaplan <hadriel.kaplan@oracle.com> Wed, 31 July 2013 11:04 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 2A68711E8172 for <insipid@ietfa.amsl.com>; Wed, 31 Jul 2013 04:04:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.578
X-Spam-Level:
X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.020, 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 gX75vQxKJNxx for <insipid@ietfa.amsl.com>; Wed, 31 Jul 2013 04:04:32 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6A621F9654 for <insipid@ietf.org>; Wed, 31 Jul 2013 04:04:31 -0700 (PDT)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6VB4S2i020458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 31 Jul 2013 11:04:29 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6VB4R54020696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Jul 2013 11:04:28 GMT
Received: from abhmt118.oracle.com (abhmt118.oracle.com [141.146.116.70]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r6VB4R7e013441; Wed, 31 Jul 2013 11:04:27 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 04:04:27 -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: <51F8E5F3.6050101@alum.mit.edu>
Date: Wed, 31 Jul 2013 07:04:24 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <B610A79F-3E85-4ABC-9898-541F630905E7@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>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.1508)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: 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 11:04:39 -0000

On Jul 31, 2013, at 6:24 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> Well, the point of doing the work was to get an id that would survive e2e, in spite of b2buas, for use in *some* way or ways. If it is likely not to survive e2e, for whatever reason, then ISTM there is no point in progressing the work.

Sure there is: for the use-cases people have in mind.   Afaict, that's mostly around correlating multiple SIP dialogs of the same conference or 3PCC scenario, and applying policies on such matching cases.  Those use-cases don't actually need true, world-wide end-to-end survival.  They only need to survive through *some* B2BUAs, not all; and only in/across some domains, not all; and only in certain scenarios, not all.

The goal has never really been to simply "get an ID that would survive e2e" - it's been to get something we could use for some *purpose*.  I believe an e2e identifier would be quite useful for a troubleshooting purpose, and so long as it was used for only that then the odds of someone wanting to change it would be minimized.  But if people use it for other purposes, then each and every purpose it is used for expands the scenarios and likelihood in which someone would need to change it and no longer make it truly e2e.  That's *ok* - it just means it's not going to be as useful for troubleshooting as it could have been, is all.  It's not doom and gloom.


> The fact that you are only offering a "hunch" about survivability doesn't make it a strong justification for giving up on the work. We aren't likely to get any definitive answers. But maybe we can solicit opinions from those who might have influence over the survivability of the session id. Maybe we can ensure that it will survive if we promise not to use it for anything useful.

How can we promise not to use it for anything useful?  We already know some people want to use it for things that are useful *for them*.

-hadriel