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

Brett Tate <brett@broadsoft.com> Tue, 27 October 2015 13:34 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46591A88FF for <insipid@ietfa.amsl.com>; Tue, 27 Oct 2015 06:34:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.279
X-Spam-Level:
X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcfpA0P4WQ8H for <insipid@ietfa.amsl.com>; Tue, 27 Oct 2015 06:34:01 -0700 (PDT)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (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 03D851A892F for <insipid@ietf.org>; Tue, 27 Oct 2015 06:34:01 -0700 (PDT)
Received: by wicfv8 with SMTP id fv8so162685109wic.0 for <insipid@ietf.org>; Tue, 27 Oct 2015 06:33:59 -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 :content-type; bh=kKMFMH8TA+8rh9ec9Fp3hsb7VbDNRypBCtpQIdiaPMk=; b=ScJi/6fPIq1R180a4h1/Tof4Mu/cxjBH8pFsJi8mXYsw5G7P5W29iIMBVh1lenNfix +nbUuww6e+TFYQQswgdVPIDFiLV9HxzCoIyI0womjMKV+IIDDmCrf1G4nGqBzL8n2Qlg QFdGlOjBNuAj+ghoLNQakPjY5fbrg6OaOMN9iBgs+NdT3h2ek1dTSuxhnSY85okpdyC7 XUS+UMC9/N7bieLlHiBGB2q8cZCmRAi2B4QZUTd8lYCdRtqfcozhGiPp9pT68PBN5Kh5 UkVnBbuUOJr4fTCi7/XJyRpyrPp2rINemYxf4e0QiChLso9/00i35F+7mZbvlbXmVzQI J1Ig==
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=kKMFMH8TA+8rh9ec9Fp3hsb7VbDNRypBCtpQIdiaPMk=; b=UGojoFbB6rlS5659SwL+NfwVbvXVx42JY8cVMnvkyktR27Wb9OOMSuryhcZYpw7ag/ DZYvd9Qt5OdwNzvOSvLiA1F/+zDhhdSpZ0ImddkbctoNj8AEo60jj2ZXLxFvtxOCfRLc cEfMhMazzHU4KA+aOffygBVV8AI/hvlQUGfDdC1WEGWVMsa/QypMdR23vmOLNQl7x7fh ODZzFBHrhU2e2davlNsP7yrgI1HentfUGhQlQwVc1i/Faeg0pi27lCEWcvG14UpNFoHa XVGd6/59xS5Q/fASX+Mq0ooJaJ2T0bfq4jakMpzDopZxiE/DmosjrDvCJl3oMSa2TzyI rprA==
X-Gm-Message-State: ALoCoQlA+K+fp3Kegyoai+UbvaKprC13Sl17Q6q5Gid51KClkgxo8AtXRfXbZony+7L3aR05kQAL
X-Received: by 10.180.198.142 with SMTP id jc14mr27206229wic.64.1445952839547; Tue, 27 Oct 2015 06:33:59 -0700 (PDT)
From: Brett Tate <brett@broadsoft.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdEQvB5+MBAL2uD0TrqyrYJkQapUOg==
Date: Tue, 27 Oct 2015 09:33:58 -0400
Message-ID: <3bf34e81cbea8ff946214b81b51787ad@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/ZPZs-Z7BTRSphp3WPt9-u7yN-C8>
Subject: Re: [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: Tue, 27 Oct 2015 13:34:03 -0000

Hi,

Thanks for the response; reply is inline.


> >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.
>
> I'm not sure which section you're referring to (but
> I'm sure it wasn't the terminology section).

Yes; I was referring to the conventions section.  The new paragraph attempts
to clarify the draft's use of endpoint and intermediary which impacts if a
device should follow section 6 or section 7.


> If a proxy rejects an INVITE with 407, it would
> follow Section 7 since it is not an endpoint.

I assume that was also your answer for "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?"

Does this draft classify redirect servers as endpoints or intermediaries
(i.e. do they need to follow section 6 or 7)?  If it matters, some redirect
servers only generate 3xx or failure responses.  However, there are others
which may additionally act as a proxy or B2BUA within some situations.


> >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.
>
> You're talking about the aggregated response section?
> I think we need to leave 2xx out of that.  I'm not
> sure how disagregated media fits into that.

"If the intermediary aggregates several responses from different
endpoints, as described in Section 16.7 of [RFC3261], the
intermediary MUST"

Since 2xx wasn't explicitly excluded from the above mandate, someone might
think that the MUST applies to the aggregation of 2xx responses for
"disaggregated media" situation.

However, leaving text as-is is good enough for me.


> >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 intermediaries?
>
> Paragraph 5 places a requirement on PBXes --
> that's the main focus.  If they transfer a call,
> they need to properly convey Session-ID headers.

Paragraph 5 currently appears to apply to more than PBXs.  Thus I'm
attempting to understand the impacts in relation to some of the optional
things within section 7.

"Intermediary devices that transfer a call, such as by joining
together two different "call legs", MUST properly construct a
Session-ID header field that contains the correct UUID values and
correct placement of those values."

What does "MUST properly construct" mean?  For instance, does it mean that
the intermediary "MUST include a Session-ID header" or "MUST include correct
UUIDs if constructing Session-ID"?  Does it also mean that it can fix a
received Session-ID before relaying it?

If it means "MUST include a Session-ID header", when does the mandate apply
(during call setup or during the transfer process)?