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

Brett Tate <brett@broadsoft.com> Wed, 23 March 2016 16:31 UTC

Return-Path: <brett@broadsoft.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8FB1C12D6D3 for <insipid@ietfa.amsl.com>; Wed, 23 Mar 2016 09:31:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id BiNE17EDYMun for <insipid@ietfa.amsl.com>; Wed, 23 Mar 2016 09:31:18 -0700 (PDT)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 07DCE12D51E for <insipid@ietf.org>; Wed, 23 Mar 2016 09:31:18 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id c63so51386389iof.0 for <insipid@ietf.org>; Wed, 23 Mar 2016 09:31:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:thread-index:date:message-id:subject:to; bh=j5imxJwgfCifD7SxVf85uYujf7wNsOsJ9757jyaPDQM=; b=eMFXmKO9pNhAZnpmzjySW7H17JNlUyxNql3eiuOomOfPvW2dcz+F85FMXNMwbs+Vlm Hr1tM/0svflazL1+RM9gvT2iKPkgev/ChFv2Pg7jTNHFcBD6AzUZ16kQ4AuPZlsMbyXo guVZl5rm2shsBI4awQoE9i7j1eaZhZ9gcZ8cGcM6iYsfkpgFo9yN8Zwq6mdLpXVrFUah oMO30Fqx/wG3uCI4MXAJTd1M8jEOVGwHr+JgUa/rp8n+Pfzs9a9/Tmap/AkKQVJEgq9X DCtvRUYr+lRW0KWQ0TXinXbMnN6d9AgFsNZ8UbdtNtGCvaV30Wf7y37eH/OFqpmfLkO8 PT7A==
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; bh=j5imxJwgfCifD7SxVf85uYujf7wNsOsJ9757jyaPDQM=; b=YFiIsYIFv5c6vz/JDLVcxSDHr6LytSOEVIdlOjXzfNVtSf0IDVJQtX06qBQlLdDokk /ZfRKbu+08yhJmP71eoBynGfYJu/hqKyVdhXG3of7yCTktN/2VuhSJVU6U9022thvsbJ mB50+gDxBd6CmIhSrExPVcL9Imf+Fzr1VrQehHjoPwefoZVIj1dBLepvUoasF+lLOUa9 oUnVpRh/W9uzWRxf3s/M3lsq5ZNqn5yPxCsOmDOQiIPUgybuqzk6o+tov0nHSpipr98q KsqsQFYotg/qYbwcZGyeYbRDlNk6Lk65gs6zqF9DNKKsv5j7vQaupYumfU7hJjcJIY6e ZBkw==
X-Gm-Message-State: AD7BkJItr70UQoSCr9BEJS9jbtY5zwDZgodmg2bsM7GY+gPBwPOIkbrGlwYx0UIuKdDLErMK5dZ7l1PEoRQ5uyvq
X-Received: by with SMTP id k17mr4705359igf.46.1458750672208; Wed, 23 Mar 2016 09:31:12 -0700 (PDT)
From: Brett Tate <brett@broadsoft.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdGFIWLTvE1vK9SPTqqWnSCzBFOezg==
Date: Wed, 23 Mar 2016 12:31:10 -0400
Message-ID: <a5651cb4f7f651b17933b0693c6bd456@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/2R--fWgaobMLYmUXT3UVTGTHoys>
Subject: [Insipid] draft-ietf-insipid-session-id-18: comments and questions
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 23 Mar 2016 16:31:21 -0000


Sorry about the delay.

The following are some comments and questions concerning



1) Section 2 paragraph 3:  To remove compliance ambiguity (e.g. if section
6 or 7 must be followed), please add something like the following to the
paragraph: The "endpoint" definition's "generally located" exclusion
allows intermediaries to originate and terminate SIP messages without an
endpoint being part of the session or transaction.

2) Section 6 paragraph 2 and bullet 1: The text is vague concerning if the
"MUST NOT change" only applies to the endpoint originating the request.

3) Section 6 paragraph 6 and section 7 last paragraph: If not intentional,
"must" is lowercase.

4) Section 6 paragraph 6: CANCEL usage isn't limited to INVITE requests.
Thus potentially should reword so that it applies to the transaction being

5) Section 6 paragraph 8: Should something similar to this paragraph be
added to section 7?  For instance, it is currently ambiguous if section 7
paragraph 6, section 7 paragraph 12, or something else applies if
intermediary receives message without Session-ID when there are cached
values for the dialogs.  One aspect of the ambiguity is contained within
comment 14.

6) Section 7 paragraph 10: CANCEL usage isn't limited to INVITE requests.
Thus potentially should reword so that it applies to the transaction being

7) Section 7 last paragraph: Append something like the following: "if they
maintain knowledge of the session identifier".

8) Section 8: Concerning paragraph 1 statement "To ensure that all
endpoints and intermediaries involved in a session agree upon the current
session identifier", following the process does not guarantee it.  There
is too much potential for race conditions to guarantee it (e.g. see RFC
6141 section 4.8).  Please add a statement within this section to indicate
that following this document does not provide a way to ensure that all
endpoints and intermediaries involved in a session will agree upon the
current session identifier.

9) Section 8 bullets: Concerning the MUST 'include this new UUID as the
"remote" parameter for any subsequent messages' statements, it isn't clear
concerning the impacts when an intermediary relays a received Session-ID.
For instance, are the bullets indicating that the intermediary MUST fix
the remote UUID when relaying requests/responses?  I think that they
should be reworded or a paragraph added to help interpret the bullets.

10) Section 8 bullet 1: As I mentioned within 1/6/2016 email (linked
below), I'd prefer CANCEL and its response not be able to update the
session identifier.  Does anyone know the precise timing concerning when
481 should be sent for late CANCEL?  For instance, it looks like RFC 6026
Timer L means that a device should still return 200 for CANCEL up to 64*T1
after having sent 2xx for INVITE (even if already received ACK).  This
would mean that a CANCEL can be 64*T1 seconds late and cause a session
identifier change.  The behavior appears to be similar within 3xx-6xx
response to INVITE situation; however the default timer to forget the
transaction appears to be smaller and I'm not sure what should occur for
late CANCEL if return 2xx.  Allowing CANCEL to update things also appears
to conflict with RFC 6141 section 3.3 "SHOULD return 2xx" since the
desired impact of CANCEL is to cause a 487 response for the cancelled
transaction (which appears would undo the CANCEL changes).


11) Section 8 bullet 2: In my opinion, 3xx (for instance 305) should be
handled like 4xx-6xx.  If the 305 was generated for security/overload
reasons, it seems like an exposure to comply with the bullet's mandate.
However since mid-dialog 3xx isn't well defined (mentioned within RFC
5057), I don't have a strong opinion on the topic.

12) Section 8 bullet 3: Clarify the last sentence since unsure what
"latest UUID value" means: stored UUID or request's UUID.

13) Section 8 bullet 4: Concerning ACK for 3xx, I have the same comment as
bullet 2.

14) Section 8 bullet 5: Allowing failure responses to update the cached
UUID is a little odd (although it provides a value for ACK).  It can
potentially cause a disagreement concerning session identifier.  Unless
clarify within the draft, it also adds ambiguity when attempting multiple
mid-dialog locations per RFC 3263.

If there were multiple failure responses causing resubmit with higher
cseq, the last change is cached on intermediary.  If session identifier is
subsequently missing from 2xx response (or other final response), the
intermediary will have a cached UUID which does not get relayed to the
endpoint (except maybe when section 7 paragraph 12 is applicable).

Concerning devices that attempt multiple mid-dialog locations per RFC
3263, I guess that they will decide how to correlate potentially
conflicting values associated with multiple responses (such as 503, 482,
and other response or timeout) since they can select a specific branch to
honor similar to if outside of dialog.  Their decision might conflict with
how other intermediaries which saw the responses might interpret what
should be the current session identifier.  Concerning re-INVITE, I'm not
really sure what remote UUID to include within the ACKs of non-winning
branches.  For instance if receive 2xx for branch A and then receive 503
for branch B (i.e. both requests sent before 2xx received), branch A is
obviously the desired winner.  Should the late 503 cause an update of the
stored UUID?  If not, should remote UUID within ACK reflect 503's value or
stored UUID?