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

"Paul E. Jones" <> Tue, 31 March 2015 03:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 70B091A8AD9 for <>; Mon, 30 Mar 2015 20:22:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.113
X-Spam-Status: No, score=-0.113 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iCyTu5a5v3R9 for <>; Mon, 30 Mar 2015 20:22:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA52F1A8AA2 for <>; Mon, 30 Mar 2015 20:22:23 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.9/8.14.9) with ESMTP id t2V3MLFr018397 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Mar 2015 23:22:21 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dublin; t=1427772142; bh=nrSm4Kk0WFito0DH6oEwIxlgEoZ91LksVoYYzsZ75Ks=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=S1VpETQCvbOMWXsLfliA4smSwrVgaHxzYsCmvwGKo5eT9IOpXChQ1UXQJNz7+KYxK gRFU9NOMhxGND9pImzNAyVmybp+89RJwOh54Ugih24FSHeJ6W3M3Qolt7aY5CJS7oX Num+JRhLvgzZyPMCXyYJzqAVh4oJtDtFX0b0b0fE=
From: "Paul E. Jones" <>
To: Brett Tate <>,,
Date: Tue, 31 Mar 2015 03:22:36 +0000
Message-Id: <em67abb241-0d49-48c0-b810-ca7c9b3bae7c@sydney>
In-Reply-To: <>
User-Agent: eM_Client/6.0.21372.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Insipid] draft-ietf-insipid-session-id-14: comments and questions
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: "Paul E. Jones" <>
List-Id: SIP Session-ID discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 Mar 2015 03:22:27 -0000


Thanks for the feedback.  I will try to incorporate your suggestions, 
resolve identified issues, etc. and address input I received from 
others.  I'll try to get a new draft out this week.


------ Original Message ------
From: "Brett Tate" <>
Sent: 3/30/2015 9:19:06 AM
Subject: draft-ietf-insipid-session-id-14: comments and questions

>The following are some comments concerning
>Sorry about the delay.
>General comment: I find the concepts of endpoint and intermediary
>confusing within the draft. For instance if a proxy/B2BUA decides to
>reject an INVITE during call setup, does section 6 or section 7 apply? 
>assume that section 6 applies (if it didn't relay the related request).
>If the proxy/B2BUA rejects a mid-dialog request (while acting as an
>intermediary for the session), section 7 applies. Adding something to
>section 2 to clarify ambiguity might help. If a device which can act as
>endpoint or intermediary rejects a re-INVITE for an unknown dialog by
>sending 481, should it do so following section 6 or section 7?
>General comment: I find the use of UA within draft occasionally 
>concerning if it includes or excludes intermediaries such as B2BUA and
>proxy's UAS when it is used.
>Section 5 paragraph 2: What does "accepted" mean? For instance, does
>returning a failure response such as 407 or 401 mean that you accepted 
>session? Should adjust text to remove the ambiguity.
>Section 5 paragraph 2: Should potentially remove "UA-generated" since 
>next paragraph mentions that it can be generated by a proxy.
>Section 5 paragraph 7: In my opinion, the MUST should be changed to 
>(along with similar changes elsewhere); however since I guess the 
>group disagrees... Should add text somewhere concerning the impacts of
>race conditions, retries, CANCEL, authentication, overload, et cetera 
>the "most recently received UUID" algorithm. For instance if "most
>recently received UUID" was processed as a retry, it potentially isn't 
>best choice for inclusion as the remote-uuid. Since CANCEL can contain 
>older UUID, it potentially isn't the best choice for inclusion as the
>remote-uuid. Because of race conditions, the "most recently received
>UUID" is not necessarily the most recent UUID sent by the remote 
>If a device returns 500 because lower CSeq, it seems strange that the 
>MUST update the stored UUID. If the "most recently received UUID" 
>passed authentication (i.e. returning 401, 407, or 403), should the
>request (or the related ACK) still be allowed to alter the stored UUID?
>If an overloaded device returns a failure response (such as 503), is 
>overloaded device actually supposed to still update the stored UUID to 
>compliant with this mandate? If this draft is mandating an overloaded
>server process an unauthenticated request to update stored information, 
>should be mentioned within section 11.
>Section 6 paragraph 2: Should clarify authentication behavior. For
>instance, RFC 3261 allows the challenger to behave mostly stateless 
>as by not retrying 401/407); however this draft currently appears to
>mandate maintaining additional information and perform related
>Section 6 paragraph 3: What is the intended impact of the paragraph if
>received 3xx-6xx (such as 302, 401, 407, 422, 488, or 503) for INVITE
>during call setup and it causes sending related subsequent INVITE? For
>instance, does it require the subsequent out-of-dialog INVITE to 
>the updated remote-uuid (instead of null)? I wasn't sure if there was 
>leeway for the endpoint to think that the INVITEs are part of different
>communication sessions (from remote endpoint perspective).
>Section 6 paragraph 7: "shall" potentially should be "SHALL".
>Section 7 paragraph 3: The paragraph potentially should clarify the
>forking interaction (such as the aggregation concept mentioned in RFC 
>section 16.7) since only 1 of the potentially many Session-ID headers 
>be relayed. For instance, the Session-ID of the selected "communication
>session" (sent within response) might be forked to all of the
>"communication sessions" (if received within subsequent transaction).
>Section 7 paragraph 3: If the intermediary knows it is relaying the
>request to a different session, can it fix the remote-uuid (such as
>changing it to null)?
>Section 7 last paragraph: Change "were last received by an endpoint" to
>"it last sent towards an endpoint".
>Section 9 paragraph 2: Concerning statement that the section is
>non-normative, be aware that the section does contain some MUST 
>might not be in conflict).
>Section 9.3 last bullet: replace "include" with "includes".
>Section 14.2: Potentially should add the rest of the RFC 3725 title.