Re: [ippm] Suresh Krishnan's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT)

[<[e-mail]>]

Suresh,

I am responding to all comments.  Once I get agreement from you, I will create a new version and then maybe you can review & remove the DISCUSS.

My comments inline.

Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
[phone]

--------------------------------------------
On Tue, 4/11/17, Suresh Krishnan <[e-mail]> wrote:

 Subject: Suresh Krishnan's Discuss on draft-ietf-ippm-6man-pdm-option-09: (with DISCUSS and COMMENT)
 To: "The IESG" <[e-mail]>
 Cc: [e-mail], "Al Morton" <[e-mail]>, "Bill Cerveny" <[e-mail]>, [e-mail], [e-mail], [e-mail]
 Date: Tuesday, April 11, 2017, 12:08 PM
 
 > Suresh Krishnan has entered the following ballot position for draft-ietf-ippm-6man-pdm-option-09:  Discuss
 
 
> 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-ippm-6man-pdm-option/
 
 
 
 ---
> * Section 3.2.1.
>The option length seems to be wrong here. This will make the parser
>parse incorrectly onto a following option or worse. I think this MUST be
>set to 10 instead of 16 (Or some field is missing from the description of
>the option)

 > 8-bit unsigned integer. Length of the option, in octets, excluding
 > the Option Type and Option Length fields. This field MUST be set to
 > 16.

Thank you.  Will fix.


>* Section 3.2.1.
> The option does not seem to state an alignment requirement, but I think
>one is required to properly align the multi-byte PSN and Delta fields.
>Can you please specify one.

I can add the wording to this section to say that per RFC2460,
the alignment is:

 2n    means any 2-octet offset from the start of the header.


>* Section 5

>The IANA considerations section needs to be more specific as you are
>requesting a specific type of option.

>e.g. This draft requests an Destination Option Type assignment with
>  the act bits set to 00 and the chg bit set to 0 from the ...

Fine.


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

> * Section 1.6  (Nalini: Find where this is in the new draft)

> I am not sure where this inference comes from. Can you please clarify?

> It is likely that an IPv6 packet containing PDM will be dropped if using
> IPv6 transition technologies.

This is now section 1.3.   I was meaning to discuss translation issues.
How is this proposed wording?

NEW
----
It is possible that an IPv6 packet containing PDM may be dropped if using
IPv6 transition technologies.  For example, an implementation using a translation 
technique (IPv6 to IPv4) which does not support or recognize the
IPv6 Destination Options extension header may simply drop the packet
rather than translating it without the extension header.


>* Section 3.1

>This text is not correct as the PDM option is not an implementation of
>the Destination options *header*.

>The IPv6 Performance and Diagnostic Metrics Destination Option (PDM) is
>an implementation of the Destination Options Header.

> Suggest rewording to 

>The IPv6 Performance and Diagnostic Metrics Destination Option (PDM) is
>implemented as an IPv6 Option carried in the Destination Options Header.

Fine.