Re: [Insipid] draft-ietf-insipid-session-id-14: comments and questions

"Paul Giralt (pgiralt)" <> Wed, 06 January 2016 15:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2DD801A8768 for <>; Wed, 6 Jan 2016 07:31:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NRnffAjoEboE for <>; Wed, 6 Jan 2016 07:31:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B22E21A875C for <>; Wed, 6 Jan 2016 07:30:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3773; q=dns/txt; s=iport; t=1452094259; x=1453303859; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=otGAbqVCPJy7zCxegtouSzKXV+4bFsB09fxcYN9wyJI=; b=c/tVkcG7fJ2QZ76PHnGp95buxoVPE++urZBSJNGtdmAfd8fSpUBRLKih IXuayDW/Lf1Q9ZEBTOGrOSq9eDabXQbPgja7/Nz2oA/aX9dKGbJ81AKg0 odGwTtCq4wCn3N5yEbs+I8VfUfiNaD9oHzx+sdKU+9ocjRF4B1wf/9tXB Q=;
X-Files: signature.asc : 842
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.20,529,1444694400"; d="asc'?scan'208";a="623276516"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jan 2016 15:30:57 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u06FUuCs030531 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Jan 2016 15:30:57 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 6 Jan 2016 10:30:55 -0500
Received: from ([]) by ([]) with mapi id 15.00.1104.009; Wed, 6 Jan 2016 10:30:55 -0500
From: "Paul Giralt (pgiralt)" <>
To: Brett Tate <>
Thread-Topic: [Insipid] draft-ietf-insipid-session-id-14: comments and questions
Thread-Index: AdFIk7nfMWCbSOSJWUGyzP+voiqgxgALWjoA
Date: Wed, 06 Jan 2016 15:30:55 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_FD6487BF-FF65-4235-AA2A-2A9B49066C8A"; protocol="application/pgp-signature"; micalg="pgp-sha512"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [Insipid] draft-ietf-insipid-session-id-14: comments and questions
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Session-ID discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Jan 2016 15:31:05 -0000

> I'm glad to hear others within the working group agree that the draft (with
> or without Paul Giralt's proposed changes) provides no way to avoid
> intermediaries from sending inaccurate Session-ID values when generating
> related requests and responses.  Similarly, the draft provides no way to
> avoid endpoints from sending inaccurate remote uuid values when generating
> requests and responses (although Paul Giralt's proposed change provides some
> consistency concerning responses).

I still think the situations under which there are inaccurate Session-IDs are very isolated. When an error occurs, there will likely be some further action taken after the error that either ends up tearing down the call or retries and succeeds. Either way, the loss of end-to-end Session-ID agreement is short-lived and there is still enough information contained in the Session-ID’s to be able to effectively troubleshoot most, if not all, issues.

Also, Section 7 already contains this text in an attempt to maintain Session-ID consistency: "If an intermediary can determine that an endpoint might not have received a current, correct Session-ID field, the Intermediary SHOULD attempt to provide the correct Session-ID header field to the endpoint such as by sending a re-INVITE message.”

> The inability of intermediaries to avoid sending inaccurate Session-ID
> values when generating related requests and responses has been why I
> occasionally ask for the limitation to be explicitly mentioned within the
> draft and why I occasionally raise issues with the draft's MUST statements.

I’m okay with adding some text mentioning there are situations where the Session-ID may get out of sync and perhaps even giving an example. If we move forward with the proposed changes, I will evaluate any MUST statements to ensure they are still a MUST.

> The draft currently allows intermediaries (excluding maybe any which might
> be required to track the uuids) to not add Session-ID when generating
> (instead of relaying) requests and responses.  This is because the draft
> prefers no Session-ID instead of one which might cause a non-desired uuid
> change.  I'm not sure if Paul Giralt intends to change this aspect of the
> draft.

I had no intention of changing this aspect of the draft.