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

[Suresh Krishnan <[e-mail]>]

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