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

Brett Tate <brett@broadsoft.com> Wed, 07 October 2015 13:29 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 01CB11A8821 for <insipid@ietfa.amsl.com>; Wed, 7 Oct 2015 06:29:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.579
X-Spam-Status: No, score=-0.579 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 PlrX7scWjASG for <insipid@ietfa.amsl.com>; Wed, 7 Oct 2015 06:29:35 -0700 (PDT)
Received: from mail-wi0-f174.google.com (mail-wi0-f174.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 4938C1A014A for <insipid@ietf.org>; Wed, 7 Oct 2015 06:29:35 -0700 (PDT)
Received: by wicgb1 with SMTP id gb1so211505123wic.1 for <insipid@ietf.org>; Wed, 07 Oct 2015 06:29:33 -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=QjCb7/NSGjgB4L1fXIkDOzw+0TAc0UwxyE80ulZTvP0=; b=Ccru0ZfffdP20wY6VgK3urB28NJc95frK3FPLOw0Y+j8oLjc1OhV6SIVza+aCbsVLA w6NtShr6In/MFz2K9WaIJrSuY4iVq1opm2VmvpCsOoxhh9GBpbR/a+lDiNAtkX1plf5h lg1NWQQcVimCB/0yK9qNdpWU+BGPhl2KG6f65zcQ7VF59YvKEP0SgCr43qZfQQXAZqmV d353zGnIrOdiWM9gdsTZZGhgmaLOmAHUJzCrJtUM3SsJqzPD5iIpfbvWE39U9XHJfgDV T+KbGgm8NkiTdkBoPZf1kluLnt+v0SkASBYgqslz1OzZnoqx9vrkCIH+6VDW/pu6JXiO KsfQ==
X-Gm-Message-State: ALoCoQkXcWtpAueAQ+e9KZPBe4FrSFrEIdRU//mv5G2GYv4KzeVATxXhUZ8Tb2D0r7CBIIaMvZ5M
X-Received: by with SMTP id bl9mr22537953wib.85.1444224573762; Wed, 07 Oct 2015 06:29:33 -0700 (PDT)
From: Brett Tate <brett@broadsoft.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdEBBAOLc2jKw5IIQkmgtc+W2zdJJQ==
Date: Wed, 7 Oct 2015 09:29:33 -0400
Message-ID: <de5a4a04fa8abf9206a7445ffb2c347c@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/VTDP-TOfmfA96PE2jUBGSN-LPL0>
Subject: [Insipid] draft-ietf-insipid-session-id-15: 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: <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, 07 Oct 2015 13:29:37 -0000


The following are some comments and questions concerning

Additional comments/questions were sent on October 2 as part of
draft-ietf-insipid-session-id-14 discussion.




Section 2 paragraph 3: I'm not confident that I'm interpreting the
paragraph correctly.  If during call setup a device that typically acts as
a proxy or B2BUA rejects the INVITE with a failure responses (such as 407,
422, 403, 421, 400, et cetera) instead of relaying the request, should it
follow section 6 or section 7?  For instance within RFC 3665 section 3.2
F2, should the proxy follow section 6 or section 7 when sending the 407
response?  It was the final hop for the request (and Alice might not try
again with Proxy-Authorization); however I'm not sure if this
paragraph/draft classifies the proxy as an endpoint within this situation.
My current interpretation is that the proxy follows section 7.

Section 2 paragraph 3: If it matters, there are devices which can behave
as both endpoints and intermediaries from the perspective of this
paragraph/draft.  There are situations where a request will need to be
processed without complete information to know if section 6 or section 7
should apply.  This can occur when receive a request for unknown dialog.
I guess that the implementer will decide if better to follow section 6 or
section 7 within such situations.

Section 5 paragraph 6: Concerning "that send provisional responses" within
the last sentence, "provisional" can be removed (or become "provisional
and other") since not limited to provisional responses.

Section 6 paragraph 4: Within sentence 1, 5xx is potentially missing from
"3xx and 4xx" discussion.

Section 7 paragraph 4: You might want to explicitly exclude 2xx from the
mandate.  For instance, it looks like the current wording could
potentially apply to "disaggregated media" which was a topic discussed in
March 2013.

Section 7 paragraph 5: What is the relationship of paragraph 5 to
paragraphs 6 and 7?  For instance, does the MUST within paragraph 5 cause
MAY within paragraphs 6 and 7 to become MUST for such transferring

Section 7 paragraph 9: "of am endpoint" should be "of an endpoint".

Section 7 paragraph 10" "previous two paragraph" should be "previous two