Re: [Insipid] Alissa Cooper's Discuss on draft-ietf-insipid-session-id-26: (with DISCUSS and COMMENT)

Brett Tate <brett@broadsoft.com> Wed, 17 August 2016 11:02 UTC

Return-Path: <brett@broadsoft.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A6B12D1C2 for <insipid@ietfa.amsl.com>; Wed, 17 Aug 2016 04:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
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=unavailable 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Yg3-ru8zK6h for <insipid@ietfa.amsl.com>; Wed, 17 Aug 2016 04:02:37 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 15BE712B04C for <insipid@ietf.org>; Wed, 17 Aug 2016 04:02:36 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id i5so224546886wmg.0 for <insipid@ietf.org>; Wed, 17 Aug 2016 04:02:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-transfer-encoding; bh=E9OAnZhGKgslbJC9+nG7vvlv+/AXpl2D/4qspFSB1bQ=; b=kDIjN8HUp4w74vcPZcAKF73qTzYDZEDN+rnhTssSDcZV1Chzd+w8e90M1jSskEj+8r 1U8EnDPzu7F99YJSHbd7YZw4IJ15JAWpSDnQXjJCGioNRkGD48/+8FfDSHzAEhF2+MF9 4wHf66r9W5p41D9GXhC5XsGa3IzhhdhYEcCt+vqnzC7xgDh6a1et26EFcdB3XGkRgTNP r4osh9zAWVonCx+VBTM7Y2bffROgej4QUquVuMbowPtW71mofDhoqeizPU1JM/ww9yHK HbdGkloilN0W2oKWcWAGK9iB72ECcQVyDva6iqnboqxPc8BGATK6hgw6y7PWseu2Vmcz RKtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc :content-transfer-encoding; bh=E9OAnZhGKgslbJC9+nG7vvlv+/AXpl2D/4qspFSB1bQ=; b=D20Yu5Ni4KiAcv2oSDKvmQ9e3dUqiM70n2vF5mCKRKLhRbSNhoSL8Vyztlze2QDn09 AJ2oLs8qxH9L56ceCICfhppXKRVqaKY6qtUhNCtBqA2Js4A/pNKjZBUskxoBuAu8J05j jvafPflj5mpONDdAQQSDxZPju/C1k1Fe+dOgJlueKkusSNqu6wA4LRxo+spS1aZXN/u3 7RRlBS8g1X/8zG7FjaO5fbrH8Ms2fQGoYh4d1rmbqcC+LopD6QTVmxFdamp8X0mtTqNR E3V8NOH45HFdXfqZc905+jFyYVF7D0yoPoEstAJijhcfcQ9ARyqHcdOVFXMybjLEjkvL J3kw==
X-Gm-Message-State: AEkoouuvHdQF5J1h6vivqn4PmOK3KVMCBCWMlsIIQLB7jtxcwtuvUhZXzFhTNjMKrdmqmntn0wAapO6u6VifhxrU
X-Received: by 10.25.5.205 with SMTP id 196mr6486970lff.6.1471431754375; Wed, 17 Aug 2016 04:02:34 -0700 (PDT)
From: Brett Tate <brett@broadsoft.com>
References: <147135877745.22972.7550246068971515295.idtracker@ietfa.amsl.com> <2377966D-0E2D-4C90-806A-8F82D8C2C33C@cisco.com>
In-Reply-To: <2377966D-0E2D-4C90-806A-8F82D8C2C33C@cisco.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKiO1LIgnN8R5bG+7YkV73fl+hTRAJt7og1npkBpqA=
Date: Wed, 17 Aug 2016 07:02:33 -0400
Message-ID: <df0f5f752ce03ef8fd19357d368a011e@mail.gmail.com>
To: "Paul Giralt (pgiralt)" <pgiralt@cisco.com>, Alissa Cooper <alissa@cooperw.in>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/insipid/HpRECAky4njFxhjSOkMXjMhfjPs>
Cc: draft-ietf-insipid-session-id@ietf.org, insipid@ietf.org, The IESG <iesg@ietf.org>, insipid-chairs@ietf.org, christer.holmberg@ericsson.com
Subject: Re: [Insipid] Alissa Cooper's Discuss on draft-ietf-insipid-session-id-26: (with DISCUSS and COMMENT)
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, 17 Aug 2016 11:02:40 -0000

Hi,

Reply is inline.

> -----Original Message-----
> From: insipid [mailto:insipid-bounces@ietf.org] On Behalf Of Paul Giralt
> (pgiralt)
> Sent: Tuesday, August 16, 2016 10:21 PM
> To: Alissa Cooper
> Cc: insipid-chairs@ietf.org; insipid@ietf.org; The IESG;
> draft-ietf-insipid-
> session-id@ietf.org; christer.holmberg@ericsson.com
> Subject: Re: [Insipid] Alissa Cooper's Discuss on
> draft-ietf-insipid-session-
> id-26: (with DISCUSS and COMMENT)
>
> Alissa,
>
> Thank you for the feedback. Please see inline…
>
> > On Aug 16, 2016, at 10:46 AM, Alissa Cooper <alissa@cooperw.in> wrote:
> >
> > Alissa Cooper has entered the following ballot position for
> > draft-ietf-insipid-session-id-26: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > Please refer to
> > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-insipid-session-id/
> >

<snip>

> > == Section 7 ==
> >
> > "The Session-ID header field value included in a CANCEL request MUST
> >   be identical to the Session-ID header field value included in the
> >   corresponding request."
> >
> > Does "corresponding request" mean original request, as in Section 6? I
> > think it would be clearer if the text said "original INVITE request"
> > both here and in Section 6.
> >
>
>
> As CANCEL only applies to an INVITE, I think it’s implied, but would
> be happy to change for clarity.

Although RFC 3261 section 9.1 recommends not sending CANCEL for other
requests, the RFC still allows sending CANCEL for non-INVITE requests (even
though section 9.2 renders it useless to do so for some requests).