Re: [Insipid] draft-ietf-insipid-session-id-10: comments

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 05 February 2015 17:36 UTC

Return-Path: <prvs=7478fd3c12=pkyzivat@alum.mit.edu>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD051A0469 for <insipid@ietfa.amsl.com>; Thu, 5 Feb 2015 09:36:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_n_RP7ccbO0 for <insipid@ietfa.amsl.com>; Thu, 5 Feb 2015 09:36:08 -0800 (PST)
Received: from alum-mailsec-scanner-5.mit.edu (alum-mailsec-scanner-5.mit.edu [18.7.68.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8BF1A0377 for <insipid@ietf.org>; Thu, 5 Feb 2015 09:36:08 -0800 (PST)
X-AuditID: 12074411-f79fa6d000006b8a-d6-54d3aa07dbfd
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id C1.FA.27530.70AA3D45; Thu, 5 Feb 2015 12:36:07 -0500 (EST)
Received: from Paul-Kyzivats-MacBook-Pro.local (c-50-138-229-151.hsd1.ma.comcast.net [50.138.229.151]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id t15Ha7Uf030480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <insipid@ietf.org>; Thu, 5 Feb 2015 12:36:07 -0500
Message-ID: <54D3AA06.1090200@alum.mit.edu>
Date: Thu, 05 Feb 2015 12:36:06 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: insipid@ietf.org
References: <em32fce56d-0ab2-4aee-a146-2d54c0220de7@sydney>
In-Reply-To: <em32fce56d-0ab2-4aee-a146-2d54c0220de7@sydney>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IRYndR1GVfdTnEYPtvWYv5958xOTB6LFny kymAMYrbJimxpCw4Mz1P3y6BO+P+0+fMBV84Klbd/8LUwNjN3sXIySEhYCJx5e0lRghbTOLC vfVsXYxcHEIClxkljmz+yQ7h/GWSaL7ZxAxSxSugLXH11k4gm4ODRUBVovugIEiYTUBLYs6h /ywgtqhAssSarZPYIcoFJU7OfAIWFxEQkfh9dwpYXFjAUWLmqwYmkDFCAtYSG74agYQ5BWwk mt89AythFjCT6NraxQhhy0tsfzuHeQIj/ywkU2chKZuFpGwBI/MqRrnEnNJc3dzEzJzi1GTd 4uTEvLzUIl1TvdzMEr3UlNJNjJDgE9zBOOOk3CFGAQ5GJR7eB7svhQixJpYVV+YeYpTkYFIS 5W2efzlEiC8pP6UyI7E4I76oNCe1+BCjBAezkgjvnWagHG9KYmVValE+TEqag0VJnJdvibqf kEB6YklqdmpqQWoRTFaPg0Pgy8dznxgFLr3p/sooxZKXn5eqJMGrtgJolGBRanpqRVpmTglC AxMHJ8g6LimR4tS8lNSixNKSjHhQzMYXA6MWJMUDdEkzSDtvcUFiLlAUovUUo6KUOG8ESEIA JJFRmgc3FpZ2XjGKA/0tzNsFUsUDTFlw3a+ABjMBDZa9eAFkcEkiQkqqgbHQwmd2WfV8BpWn dUf9tU0z3qXzfj/cw5EUdsynY8fi0qUSogX+JxyYy4T7Dr97quHx4EHlzhkiUXL23mo/p01K d52w5/2TvXxOraw9ak79UwP3xZZu1Jj9+ZPxqf3FKuK38w+xHGJhEL63SH/artbVy4LqFQM+ 2ExUvl929Mz2PM3/7s9LTJVYijMSDbWYi4oTAcXlPeYWAwAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/insipid/K-Od3byyzZhJx1CczXNAeeO1f4Y>
Subject: Re: [Insipid] draft-ietf-insipid-session-id-10: comments
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 05 Feb 2015 17:36:10 -0000

On 2/4/15 7:15 PM, Paul E. Jones wrote:
> Brett,

>> From an intermediary perspective, it is irrelevant why something on each
>> side decided to change the supplied UUID. My understanding is that the
>> draft requires (or will require) the intermediary to track the change so
>> that it MAY/SHOULD/MUST be used when the intermediary generates
>> (instead of
>> relays) subsequent requests and responses associated with the "session".
>
> That would be true of intermediaries like PBXes that are switching calls
> from one leg to another. It's only in situations where the intermediary
> is going to do something that causes endpoints to have the wrong value
> that they need to ensure they convey the right value.  If the SBC is not
> in the business of switching call legs from one device to another like a
> PBX does, it would not have to maintain this state at all.

I think *most* B2BUAs will sometimes need to originate messages. E.g.,
- send a BYE to terminate a session by policy
- send a session timer refresh.

Any B2BUA that will ever originate a message needs to maintain this state.

	Thanks,
	Paul K