Re: [conex] Brian Haberman's Discuss on draft-ietf-conex-destopt-09: (with DISCUSS and COMMENT)

Brian Haberman <brian@innovationslab.net> Wed, 30 September 2015 23:41 UTC

Return-Path: <brian@innovationslab.net>
X-Original-To: conex@ietfa.amsl.com
Delivered-To: conex@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5EF1ACD04; Wed, 30 Sep 2015 16:41:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 j7-rlgpQ2GJ0; Wed, 30 Sep 2015 16:41:50 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D9BA1ACD15; Wed, 30 Sep 2015 16:41:50 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id D78508816D; Wed, 30 Sep 2015 16:41:49 -0700 (PDT)
Received: from [192.168.1.8] (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id AE1B3328081A; Wed, 30 Sep 2015 16:41:49 -0700 (PDT)
References: <20150930130930.15603.87942.idtracker@ietfa.amsl.com> <E87B771635882B4BA20096B589152EF63A97695B@eusaamb107.ericsson.se>
Mime-Version: 1.0 (1.0)
In-Reply-To: <E87B771635882B4BA20096B589152EF63A97695B@eusaamb107.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <0BD5F0DE-4C37-4DE5-B174-13B5A7AEE87B@innovationslab.net>
X-Mailer: iPad Mail (13A404)
From: Brian Haberman <brian@innovationslab.net>
Date: Wed, 30 Sep 2015 19:41:47 -0400
To: Suresh Krishnan <suresh.krishnan@ericsson.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/conex/7MgptSyX5nKjyZbTItv0oblMCBM>
Cc: "draft-ietf-conex-destopt.ad@ietf.org" <draft-ietf-conex-destopt.ad@ietf.org>, The IESG <iesg@ietf.org>, "conex@ietf.org" <conex@ietf.org>, "conex-chairs@ietf.org" <conex-chairs@ietf.org>, "draft-ietf-conex-destopt@ietf.org" <draft-ietf-conex-destopt@ietf.org>
Subject: Re: [conex] Brian Haberman's Discuss on draft-ietf-conex-destopt-09: (with DISCUSS and COMMENT)
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Congestion Exposure working group discussion list <conex.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/conex>, <mailto:conex-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/conex/>
List-Post: <mailto:conex@ietf.org>
List-Help: <mailto:conex-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/conex>, <mailto:conex-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Sep 2015 23:41:51 -0000

Suresh,
     Looks good to me.

Brian

> On Sep 30, 2015, at 7:19 PM, Suresh Krishnan <suresh.krishnan@ericsson.com>; wrote:
> 
> Hi Brian,
>   Thanks for your comments. Please see responses inline.
> 
>> On 09/30/2015 09:09 AM, Brian Haberman wrote:
>> Brian Haberman has entered the following ballot position for
>> draft-ietf-conex-destopt-09: 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-conex-destopt/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> I support the publication of this document given the need for
>> experimentation in this area. However, there is one point that I would
>> like to discuss...
>> 
>> Section 3 contains R-1 which says that this marking "needs to be visible
>> to all ConEx-capable nodes on the path." Additionally, Section 5 says
>> that the choice of using an IPv6 Destination Option precludes
>> non-ConEx-capable devices from having to deal with the extension header.
>> However, RFC 2460 clearly says that Destination Options are not inspected
>> by intermediate devices. We all know that a variety of intermediate
>> devices ignore the rule in 2460.  Given that, I would like this document
>> to explicitly state that it does not abide by the rule in 2460 so that
>> implementations that do follow 2460 but want to support this approach
>> know to update all their extension header processing code.
> 
> Makes perfect sense. Will this additional text at the end of Section 3 work?
> 
> NEW:
> Please note that the IPv6 specification [RFC2460] does not require or 
> expect intermediate nodes to inspect destination options such as the 
> ConEx destination option. This implies that ConEx-aware intermediate 
> nodes following this specification will need updated extension header 
> processing code to be able read the destination options.
> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> * Why does the word "foo" appear in the middle of Section 4?
> 
> There was some issue with submitting the XML source into the ID 
> submission tool instead of the text document that resulted in the loss 
> of formatting as well as this text appearing between -08 and -09. Will 
> remove in new version.
> 
>> 
>> * Do you want the Option Type description in Section 4 to have a value =
>> TBD construct so that the IANA-assigned value can be inserted?
> 
> Sounds good. Replaced the value with TBA1 as described in the IANA 
> considerations.
> 
> OLD:
> 
>         8-bit identifier of the type of option. The option identifier
>         for the ConEx destination option will be allocated by the IANA.
> 
> NEW:
> 
>         8-bit identifier of the type of option. Set to the value TBA1.
> 
> Thanks
> Suresh
>