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

From: "Brian Haberman" <[email-masked]>
Date: Wed, 30 Sep 2015 06:09:30 -0700

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.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

* Why does the word "foo" appear in the middle of Section 4?

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

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 30 Sep 2015 23:19:53 +0000

Hi Brian,
   Thanks for your comments. Please see responses inline.

> https://datatracker.ietf.org/doc/draft-ietf-conex-destopt/

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.

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.

> 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

---

From: Brian Haberman <[email-masked]>
Date: Wed, 30 Sep 2015 19:41:47 -0400

Suresh,
     Looks good to me.

Brian

> On Sep 30, 2015, at 7:19 PM, Suresh Krishnan <[email-masked]> wrote:
> 
> Hi Brian,