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 _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
