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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 05 Feb 2020 14:46:59 -0800

Roman Danyliw has entered the following ballot position for
draft-ietf-6lo-ap-nd-18: No Objection

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-6lo-ap-nd/

----------------------------------------------------------------------
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/

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

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

** Section 4.4. Typo. s/ths/this/

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 Feb 2020 10:51:25 +0000

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

Fixed

> 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

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