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

Brett Tate <> Mon, 09 February 2015 18:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5BA8C1A6F38 for <>; Mon, 9 Feb 2015 10:47:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.08
X-Spam-Status: No, score=-0.08 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1u42CTRLZkHB for <>; Mon, 9 Feb 2015 10:47:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 56AFE1A6F07 for <>; Mon, 9 Feb 2015 10:46:58 -0800 (PST)
Received: by with SMTP id q107so11935689qgd.8 for <>; Mon, 09 Feb 2015 10:46:57 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=NABDTsmNc3EeOtC1LiA9Q/q69QZklubJ1JEKOznd6b4=; b=Q7/Ixv1dAmpOnmZukp5Y8mvju37WyePId58iitpnd3427C35BSdLCyDBpu4uKTXLS0 byumFqpqi/Q6dVP8Mdeg1aSyaEgoAISkVCPdJNBcmXoDBUjs1v2epvk7OubH4xmBLYYq q7mmrQmyZ8vpK1KW3F0p/IzH9aQbTssoNrvCR1Dp7lQ05yhQDft4nspVhp1nuWPa6iLA 5lcW7L0X+kcqdvhiU8ZWPHbXf1veREAwWCwYFZVSDUoiQxkL0v1R8f67i8+nEGGoXArG zUGkVnGJWa9ZLzwrLSz6S5tS4W+DXP+Yx36+dI8xtAHdTGCMVazJiWIbT904Mu9OCxxZ C1ww==
X-Gm-Message-State: ALoCoQl2TjddnvBKMl2AWdIOZUja/icKazyEti5DQlQELDPRzWozuRFoKK+4TeiOOjnD2gtZEogH
X-Received: by with SMTP id c2mr32131123qaa.48.1423507617600; Mon, 09 Feb 2015 10:46:57 -0800 (PST)
From: Brett Tate <>
References: <> <em32fce56d-0ab2-4aee-a146-2d54c0220de7@sydney>
In-Reply-To: <em32fce56d-0ab2-4aee-a146-2d54c0220de7@sydney>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJ1pYVJ2Vt0B3RdJFFz2Qd8csPw+5udY1+Q
Date: Mon, 09 Feb 2015 13:46:56 -0500
Message-ID: <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Insipid] draft-ietf-insipid-session-id-10: comments
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: Mon, 09 Feb 2015 18:47:20 -0000


Thanks for the response; reply is inline.

> >A B2BUA can generate requests and responses on behalf of
> >both sides. In my opinion, section 7 covers some individual
> >situations; however, it appears to be missing the general
> >case of tracking remote/local UUIDs and then using the UUIDs
> >when generating (instead of relaying) subsequent requests
> >and responses associated with the "session".
> This is largely purposeful.  We do not want intermediaries
> really getting involved in the exchange of UUID values.

Sounds great to me.  If that is really true, add something like the
following paragraph to section 7.

"Intermediaries MAY track the Session Identifier values associated with a
transaction and dialog.  However since it is NOT REQUIRED (and because of
other reasons), they MAY provide inaccurate Session-ID values when
generating related requests and responses."

> If an intermediary is responding on behalf of an endpoint,
> then what the text currently says that "if it knows" the
> UUID value of the opposite endpoint, includes it.  Otherwise,
> it either uses the NULL value or fabricates a value.

What section and paragraph says that?

> In what way would you like to see the text re-worded, keeping
> in mind that we want B2BUAs to take a hands-off approach as
> much as possible.

Sounds great to me.  If the draft is clear about that (such as by adding the
mentioned paragraph), I'll quit being concerned about the race conditions,
CANCEL, et cetera which will make it impossible (when mid-dialog Session-ID
changes occur) for intermediaries to know the correct Session-ID values for
use when subsequently generating (instead of relaying) requests and
responses.  Endpoints have the ambiguity issue; however at least one of the
UUIDs would be accurate.