[Insipid] Requirement for Intermediaries to Update Session ID for other parties

Paul Giralt <pgiralt@cisco.com> Thu, 02 June 2016 04:03 UTC

Return-Path: <pgiralt@cisco.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 D104E12D0FD for <insipid@ietfa.amsl.com>; Wed, 1 Jun 2016 21:03:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level:
X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 mTok1tcXCD8V for <insipid@ietfa.amsl.com>; Wed, 1 Jun 2016 21:03:35 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90EB612D0E0 for <insipid@ietf.org>; Wed, 1 Jun 2016 21:03:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1826; q=dns/txt; s=iport; t=1464840215; x=1466049815; h=from:subject:date:message-id:to:mime-version; bh=8or+ReBzg2wq8z//jqO/hsffQBhiaPw3lvQFKOGNVxw=; b=Wcurjw+VHKpItQxhc+VeqDMIGSRLMDfJYM6TifKsKfKN9Zbg/+27tRJB fPkovYZJRRZxgjj+Wi++GygxAPxSNCndyuxTUSAGJVNT2cc3gMAq75+De xCjKBKn/N8F75svzbgNlbueVdvy0FvIOYIxevjSmBGeHE4d3hxVnX7bwW Q=;
X-Files: signature.asc : 842
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D8AQABr09X/5NdJa1egzq8Ag6BeodGO?= =?us-ascii?q?BQBAQEBAQEBZSeEb4EzAokhoDWPYpEdIw6GJ4F3glaFDII1K4IuBZg3gS+BfIp?= =?us-ascii?q?1CoFJFo0zhjOJGR4BQ4QJIIsuAQEB?=
X-IronPort-AV: E=Sophos;i="5.26,404,1459814400"; d="asc'?scan'208";a="108879045"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jun 2016 04:03:34 +0000
Received: from rtp-vpn1-510.cisco.com (rtp-vpn1-510.cisco.com [10.82.225.254]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u5243Xlt025012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <insipid@ietf.org>; Thu, 2 Jun 2016 04:03:34 GMT
From: Paul Giralt <pgiralt@cisco.com>
X-Pgp-Agent: GPGMail 2.6b2
Content-Type: multipart/signed; boundary="Apple-Mail=_7C2A04B4-759C-4A7D-BF53-5D359535300D"; protocol="application/pgp-signature"; micalg=pgp-sha512
Date: Thu, 2 Jun 2016 00:03:32 -0400
Message-Id: <EC7574F5-036F-4D93-94A3-02ECF80AD7C9@cisco.com>
To: insipid@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/insipid/R7DL5aEeGz--1iroK_Bo2DFCjzw>
Subject: [Insipid] Requirement for Intermediaries to Update Session ID for other parties
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 02 Jun 2016 04:03:38 -0000

INSIPID WG,

There are several references in the draft that indicate an Intermediary SHOULD update endpoints involved in a session if the session ID on one call leg changes, but it does not require it. Is there any reason why we should not change these to a MUST so that Intermediaries are required to update the Session ID for any participant it knows is out of sync?

If there are good reasons for leaving as a SHOULD, I’d like to hear them.

Thanks,
-Paul