Re: [6lo] Roman Danyliw's No Objection on draft-ietf-6lo-ap-nd-18: (with COMMENT)

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Roman:

Many thanks for your review!

I'm publishing -19 to cover the proposed changes, in association with some more nits from the discussion with Benjamin
The diffs here may help you through your validation: https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd-19

For the  point-by-point discussion, please see below:

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I support Ben Kaduk’s DISCUSS position.
> 
> Thank you for this well written document.
> 
> A few nits as the key issues already appear to be covered in other ballots:
> 
> ** Section 4.1.  Typo. s/acertained/ascertained/

Fixed

> 
> ** Section 4.3.  Per “The type of cryptographic algorithm used in calculation
> Crypto-ID (see Table 2 in     Section 8.3 ).”, why not reference the
> sub-registry – “subregistry "Crypto-Type Subregistry" in the  Internet Control
> Message Protocol version 6 (ICMPv6) Parameters"?

This seems to match Benjamin's direction as well. Maybe:

"
   Crypto-Type:  8-bit unsigned integer.  The type of cryptographic
      algorithm used in calculation Crypto-ID indexed by IANA in the
      "Crypto-Type Subregistry" in the "Internet Control Message
      Protocol version 6 (ICMPv6) Parameters" (see Section 8.3).
"

This discussion is related to the points Benjamin and Alissa made on "IESG Approval" in the IANA section
"
   Assignment of new values for new Crypto-Type MUST be done through
   IANA with either "Specification Required" or "IESG Approval" as
   defined in BCP 26 [RFC8126].
"
The goal behind that is to enable the addition of Crypto-Types without the need of an RFC as long as the IANA registry contains enough information to use this specification as is for the new crypto type.
Suggestion to add after the text cited above:

"
   The "Defining specification" column indicates the document that
   defines the length and computation of the digital signature, which
   could be this for values defined through "IESG Approval".
"

Does that help? (adding Benjamin and Alissa to the "to" list.

> 
> ** Section 4.4.  In the description of the Digital Signature field, consider adding
> that the length of this variable length field is determined by the
> algorithm: OLD: The computation of the digital signature depends on
>       the Crypto-Type which is found in the associated CIPO.
> 
> NEW:
> The length and computation of the digital signature depends on
>       the Crypto-Type which is found in the associated CIPO.
> 

Yep : ) maybe depends -> depend? 

"
   Digital Signature:  A variable-length field containing a digital
      signature.  The length and computation of the digital signature
      depend on the Crypto-Type which is found in the associated CIPO.
      For the values of the Crypto-Type that are defined in this
      specification, and unless specified otherwise for a future value
      of the Crypto-Type, the signature is computed as detailed in
      Section 6.2.
"

> ** Section 4.4. Typo. s/ths/this/
> 
Could not find it, must be gone

Again, many thanks Roman.

I guess this doc is now close to RFC level. This and RFC 8505 modernize IPv6 ND and make it suitable for modern fabrics with wireless and overlays. 
I hope it takes off but we are missing energy at 6MAN. Would you have a hint on how to proceed? Could the IAB or the IESG influence the process?

All the best,

Pascal