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

"Paul E. Jones" <> Fri, 25 September 2015 01:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E6DF71B2FF9 for <>; Thu, 24 Sep 2015 18:18:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.813
X-Spam-Status: No, score=-0.813 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 QL3CTyplBHwg for <>; Thu, 24 Sep 2015 18:18:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D49A71B300B for <>; Thu, 24 Sep 2015 18:18:31 -0700 (PDT)
Received: from [] ( [] (may be forged)) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id t8P1ISSH002072 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Sep 2015 21:18:29 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dublin; t=1443143909; bh=dSgwBUPsPbGGPVVE8sz9DEXtheXkcFGeHM5RBaLbrxQ=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=EHJPYp8i5HWcCx6WEu4mob8G2RFzMlyMWq4fKNGClnuE5x227nIj2lBeZgSnG/Ift WdMIiemBeNnCXbgU/fKpP4Vcvt67m2TOO19M0j58gE689zQ2F2Y8zMjff+yCx4CzzG xUvgLdvpXIFRcPuZyeBWDw8eL1JAQeFG4Byzl4KU=
From: "Paul E. Jones" <>
To: Brett Tate <>,,
Date: Fri, 25 Sep 2015 01:18:33 +0000
Message-Id: <em823b7488-7bd9-4952-b3ab-8e3c06e9033f@sydney>
In-Reply-To: <>
User-Agent: eM_Client/6.0.23181.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 ( []); Thu, 24 Sep 2015 21:18:29 -0400 (EDT)
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: Fri, 25 Sep 2015 01:18:41 -0000


We're trying to close on these last comments and do some editorial work. 
  Please me reply inline...

>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 
>endpoint or intermediary rejects a re-INVITE for an unknown dialog by
>sending 481, should it do so following section 6 or section 7?

Yes, this would be useful.  And it goes along with your next issue.

>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.

I've made an attempt to address this confusion and to be more consistent 
in terminology, adding some language to Section 2 as you suggest, as 

>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.

Prior to seeing your message, I saw that and was equally confused.  I 
think the intent was to refer to sessions that are terminated.  And I do 
mean terminated, since sessions that are not terminated might include 
provisional responses with a null UUID.  I changed the language.  See if 
it makes more sense when I post the draft soon.

>Section 5 paragraph 2: Should potentially remove "UA-generated" since 
>next paragraph mentions that it can be generated by a proxy.

Indeed, that's confusing.  And a lot of the procedure is replicated in 
the section on intermediary procedures.  I've shortened this section a 

>  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.

Whew!  OK, that's a lot to chew on. :)

First, I removed the text in section 5, since that (too) was redundant.  
However, I don't think that addresses your more serious concern w.r.t. 
race conditions.

Most messages will be coming in sequentially.  There are possibilities 
that an intermediary throws back an error message with a "null" UUID.  
So, what I did was add text to section 6 that said the endpoint needs to 
take note of non-null values.  If the value is null, that might just be 
a stateless intermediary returning an error, because it doesn't know 
what the other end's UUID value is.

I think that will address part of the issue.  Maybe that and other 
changes help to close all of them; not sure.  Have a look at the new 
draft and tell me what you think.

>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

I see value in keeping that state.  This is in line with also 
maintaining the UUID value even in the face of getting a 3xx, too.  We 
want this to effectively persist from the moment the user lifts the 
handset and makes a call to the moment the user hangs up the phone.

>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).

For any of those, the local UUID would be retained.  The remote-UUID is 
not retained, because the peer changed (or potentially will change).  
I've added a new paragraph to the endpoint procedure section to explain 

>Section 6 paragraph 7: "shall" potentially should be "SHALL".
To be consistent with the rest of the text, I changed it to MUST.

>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 
>session" (sent within response) might be forked to all of the
>"communication sessions" (if received within subsequent transaction).

Good catch.  For that, I propose that the intermediary set the 
"local-uuid" value to "null".

>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)?
For the response aggregation case, definitely.  For what other cases are 
you thinking that should happen?

>Section 7 last paragraph: Change "were last received by an endpoint" to
>"it last sent towards an endpoint".

Changed it!

>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).
I changed MUST to something else.  No normative language.

>Section 9.3 last bullet: replace "include" with "includes".


>  Section 14.2: Potentially should add the rest of the RFC 3725 title.

Wow, that's an impressive catch when you're looking at reference titles. 
  I fixed that!

We'll have a new revision posted within a day or so.