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

Brett Tate <brett@broadsoft.com> Mon, 30 March 2015 13:19 UTC

Return-Path: <brett@broadsoft.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id C625F1ACE83 for <insipid@ietfa.amsl.com>; Mon, 30 Mar 2015 06:19:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.721
X-Spam-Status: No, score=0.721 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id cECimP4d7wlf for <insipid@ietfa.amsl.com>; Mon, 30 Mar 2015 06:19:09 -0700 (PDT)
Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C23121A8927 for <insipid@ietf.org>; Mon, 30 Mar 2015 06:19:08 -0700 (PDT)
Received: by qgep97 with SMTP id p97so187366351qge.1 for <insipid@ietf.org>; Mon, 30 Mar 2015 06:19:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type; bh=Qfwa/cTWXKkX4ed88CYZLYWozhw+oeyDjKEa4TPFyyU=; b=dsZZrCe3mxsdfpuXUDz2dRI6W8C7+g+YEAcMmw7Eb9H3SFnV7cYE/0J3qYr57VhLBQ 9bPmbAugbQ8GPdkT95vAfBGED0b7arHSvLcRSLHfo1MZOdtV7yc95Ddp5IbvzS5tFzHE Z1PBD69ydMwzKbB7DB3X/Cct4z2Mee2GDznQPUk2E7hggQ1k3z7ZaP6YMZoJyJiDBhRj CP7hZQTIBG89iZd4zwpwcRmjGBJuklXwy3+Hw5sVMpkorlQD1B1WllVBGRL0ZBaGD6gb j98li0R3bFYb+1QrjG9SGyYO/H1HkrOiHBAn3sldqWJlqnxI4pjMINy6etYAvTCTfvPx ZHWA==
X-Gm-Message-State: ALoCoQnLynCSZMuZcdz8oNi1TSLxOKq/PNSs+vyL4Ms5NdCRt6yt7/FR7bVIfpA3KpU05PQvjRvd
X-Received: by with SMTP id w39mr1196591qge.28.1427721547804; Mon, 30 Mar 2015 06:19:07 -0700 (PDT)
From: Brett Tate <brett@broadsoft.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdBq6ycJicU0Wab+Rxm5Fkff2tXn/w==
Date: Mon, 30 Mar 2015 09:19:06 -0400
Message-ID: <928f56e17e98f35e671871af351c80c7@mail.gmail.com>
To: insipid@ietf.org, draft-ietf-insipid-session-id@tools.ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/insipid/zEMlPGbIJTkojl9OygQ5aK1TY5g>
Subject: [Insipid] draft-ietf-insipid-session-id-14: comments and questions
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Mon, 30 Mar 2015 13:19:10 -0000


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?  I
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 ambiguous
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 the
session?  Should adjust text to remove the ambiguity.

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

Section 5 paragraph 7: In my opinion, the MUST should be changed to SHOULD
(along with similar changes elsewhere); however since I guess the working
group disagrees... Should add text somewhere concerning the impacts of
race conditions, retries, CANCEL, authentication, overload, et cetera upon
the "most recently received UUID" algorithm.  For instance if "most
recently received UUID" was processed as a retry, it potentially isn't the
best choice for inclusion as the remote-uuid.  Since CANCEL can contain an
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 endpoint.
If a device returns 500 because lower CSeq, it seems strange that the UAS
MUST update the stored UUID.  If the "most recently received UUID" hasn't
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 the
overloaded device actually supposed to still update the stored UUID to be
compliant with this mandate?  If this draft is mandating an overloaded
server process an unauthenticated request to update stored information, it
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 (such
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 contain
the updated remote-uuid (instead of null)?  I wasn't sure if there was any
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 3261
section 16.7) since only 1 of the potentially many Session-ID headers will
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 (although
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.