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

Brett Tate <brett@broadsoft.com> Fri, 24 October 2014 14:51 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 914A51A0AF1 for <insipid@ietfa.amsl.com>; Fri, 24 Oct 2014 07:51:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.08
X-Spam-Status: No, score=-0.08 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 9kB5uk2diZdx for <insipid@ietfa.amsl.com>; Fri, 24 Oct 2014 07:51:38 -0700 (PDT)
Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78A3F1A033B for <insipid@ietf.org>; Fri, 24 Oct 2014 07:51:38 -0700 (PDT)
Received: by mail-qc0-f174.google.com with SMTP id i8so844421qcq.33 for <insipid@ietf.org>; Fri, 24 Oct 2014 07:51:37 -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=UF9/VhGqhQj3HHZnQ4oKpAqTtideQc3R0Fb9XCKlU08=; b=BD6it+uY6bLsfIYWdMTx144POJARpH+znF7sn/OUyk9MMDOxSfc6eowuxaBf5EAkiX /40GMAtHaUefZQNzn2HLSjZYUN831DINo5tUG22gbnA70GRahp7obDq20zyNeO2JBrlC 114aQWk1mzMhGHnUqYt7VXz/aQGbaMDq4WVgfy7M77852TGO0oMQ28R/9o1u2W2c+QAT 8ZhDmosxElaKPEuheySsuGws1SPFmhv3XsrANbgLQXK9iYVurc1Kh+1Qq12+/4ZqArq7 0tqOQg29smpBOqjls3Ht7UR/d2HOEWBnzhmZR6SSe6JgkDqSFJERdzxWMkTwMNI713DT 0WUA==
X-Gm-Message-State: ALoCoQlk7cgfUZZEuR6pM+qmkTb8jowTj3CkafcPxi2Gw0nwAj7PuXd3yP6/leSicxhCGy8DqIAb
X-Received: by with SMTP id e5mr6531784qaw.48.1414162297101; Fri, 24 Oct 2014 07:51:37 -0700 (PDT)
From: Brett Tate <brett@broadsoft.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac/vmfI0m5CgOzI/QEqXYEBMnGZAtA==
Date: Fri, 24 Oct 2014 10:51:33 -0400
Message-ID: <d643e9d97d38374d7dc5f53ee8281949@mail.gmail.com>
To: draft-ietf-insipid-session-id@tools.ietf.org, insipid@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/insipid/P6c1w8t197VBKVD5FIQOusJwWGs
Subject: [Insipid] draft-ietf-insipid-session-id-10: comments
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: Fri, 24 Oct 2014 14:51:40 -0000


The following are a few comments concerning



Section 1 paragraph 4: "This procedures" should be "The procedures".

Section 6 paragraph 1: "be used the peer" should be "be used if the peer".

Section 7 paragraph 1: Since proxies cannot alter a Call-ID (without
becoming B2BUA), "proxies and" should potentially be removed from the
first sentence.

Section 7 paragraph 6: Concerning early dialogs, the CANCEL correlates to
the INVITE instead of a specific early dialog.  Thus the paragraph should
likely be reworded to always reflect the INVITE when CANCEL not traversing
a dialog.  For instance if received multiple 18x creating multiple early
dialogs and received Session-IDs {B1, A} and {B2, A}, the current
paragraph appears to recommend that the CANCEL include one of these within

Section 7 paragraph 7: Should potentially recommend what should occur when
B2BUA sends re-INVITE without SDP to obtain SDP to setup another session.
More specifically, should the re-INVITE contain a new 3PCC generated UUID?
The other options would be to resurrect the discarded UUID or use the
currently connected session's UUID.

Section 9.1: Concerning the SIP messages, the B2BUA appears to be a proxy.
Thus from a RFC 7092 perspective, I guess that it is a Proxy-B2BUA that
hasn't originated any requests.

Section 9.1: The F3 and F4 Via branch "z9hG4bKnashds8" should instead
reflect INVITE's Via branch.

Section 9.1: The F4 Contact or F5 Request-URI potentially need a different
ip-address (although maybe reflecting missing Record-Route without "lr").
F4 Contact reflects F3 Contact and doesn't match F5 Request-URI.

Section 9.1: Concerning F6, the B2BUA's Via header appears to be missing.
And existing Via should contain a received parameter.

Section 9.2: Should potentially clarify if the REFER is mid-dialog even if
section 9.9 is out-of-dialog REFER.

Section 9.3 bullet 2: I'm glad that the example isn't mandating sending a
request to update the Session-ID after transfer.  However you might want
to reword the last sentence since Alice won't remain "completely unaware"
of the transfer since Alice's device would notice the transfer caused
Session-ID modification when subsequent messaging occurs on the dialog.

Section 9.4 bullet 4: Potentially should clarify why this example is
quickly updating the Session-ID but section 9.3 example does not.

Section 9.8.1 figure 10: What should be the CANCEL session-id if Bob-1 had
sent two 18x creating two early dialogs with Session-IDs {B1x, A} and
{B1y, A}?

Section 10 paragraph 4: "following" should be "follow".

Section 10 paragraph 5: "rules for" should be "rules that".

Section 10 bullets: Some currently start upper case; others currently
start lower case.

Section 10 bullet 7: "include and" should be "include a"

Section 10 last bullet: Should potentially reword the bullet.  I'm not
sure if second sentence is indicating to ignore unknown parameters, remove
unknown parameters, or something else (like reiterating that the above
bullets do not apply to them).

Section 14.2 RFC5589: "RFC 5359" should be "RFC 5589".