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

Suresh Krishnan <> Wed, 30 September 2015 23:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4DB501ACC8D; Wed, 30 Sep 2015 16:20:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vwp0FyoEmCIM; Wed, 30 Sep 2015 16:19:59 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 43C9C1ACC8C; Wed, 30 Sep 2015 16:19:56 -0700 (PDT)
X-AuditID: c618062d-f79ef6d000007f54-34-560c0e928e5f
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id EC.77.32596.29E0C065; Wed, 30 Sep 2015 18:32:18 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Wed, 30 Sep 2015 19:19:55 -0400
From: Suresh Krishnan <>
To: Brian Haberman <>, The IESG <>
Thread-Topic: Brian Haberman's Discuss on draft-ietf-conex-destopt-09: (with DISCUSS and COMMENT)
Thread-Index: AQHQ+4FB4tQNUvzqqEOgswG8zQ11rA==
Date: Wed, 30 Sep 2015 23:19:53 +0000
Message-ID: <>
References: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyuXRPiO4kPp4wg90v5C1m9vxjtDj38DKT xaFrPxktHj5Kt3h/6gu7RffqX+wWM/5MZHZg91iy5CeTx8zjX1g8Zhx7yR7AHMVlk5Kak1mW WqRvl8CVsfsCS8Fm6YpF/34wNjCeFeti5OSQEDCR+HbxOBOELSZx4d56ti5GLg4hgaOMEk3N HSwQznJGidlLmllBqtiAOjbs/AzWISLgLvHi02RGkCJmgflMEkf/XWYGSQgLJEk87J3NDFGU LHHl7ic2CFtPYtX1lewgNouAqsSZXRuAajg4eAV8JY5OzgcJCwk4SrxfvpMFxGYEuuj7qTVg u5gFxCVuPZkPdamAxJI955khbFGJl4//sULYShJzXl9jhqjXkViwG2Its4C2xLKFr8HivAKC EidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypGjtLi1LLcdCODTYzAODomwaa7g3HPS8tDjAIc jEo8vAsucoUJsSaWFVfmHmKU5mBREufdv+R+qJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZG VrVsg91Wp230JqdVbTn8r4rlb9bh4vX13s7CyUElgc9mLv2yv3/TZWEu/XWH6/ZMkL3EKdhu f05q9r5exhvJoTY6sSkf7CcnZWckff5tmTHv9+XW6u352tExcq5mbWJ1UvmvE6N4Vd1tko4+ DDW8ecTzoOLXmcf7WMy2HZ2y2jlk5gnv23eVWIozEg21mIuKEwFcsNCAhAIAAA==
Archived-At: <>
Cc: "" <>, "" <>, "" <>, "" <>
Subject: Re: [conex] Brian Haberman's Discuss on draft-ietf-conex-destopt-09: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Congestion Exposure working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Sep 2015 23:20:01 -0000

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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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?

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.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> * 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 


         8-bit identifier of the type of option. The option identifier
         for the ConEx destination option will be allocated by the IANA.


         8-bit identifier of the type of option. Set to the value TBA1.