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

[Brian Haberman <[e-mail]>]

Suresh,
     Looks good to me.

Brian

> On Sep 30, 2015, at 7:19 PM, Suresh Krishnan <[e-mail]> 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
>