[6lo] Éric Vyncke's Discuss on draft-ietf-6lo-ap-nd-13: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-6lo-ap-nd-13: 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-6lo-ap-nd/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for the work put into this document. I found the document easy to
read. Please find below a trivial-to-fix DISCUSS (and I am requesting a reply
and/or action on this one) plus some non-blocking COMMENTs and NITs.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

-- Section 4.4 --
The length of the reserved field is not specified. Or am I missing something
obvious ?


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

== COMMENTS ==

-- Section 4.2 --
While status is set to 0 when sending a NS, what is the expected behavior of a
receiver ?

-- Section 4.3 and 4.4 --
Why is the Pad Length field a 8-bit field while the actual padding will always
be less than 8 bytes. Suggest to make it a 3 or 4 bits field and extend the
reserved field.

-- Section 6.1 --
About "Nonce option MUST contain a random Nonce value that was never used with
this device", how can it be done? Keeping a local history? Giving some
operational hints would bee welcome. Especially, when there are multiple 6LR in
the LLN: how can they synchronize the nonce?

-- References --
Is there a reason why the crypto algorithms RFC 7748 and 8032 are not normative?

== NITS ==

-- Section 2.2 --
To be honest, I am not a big fan of simply announcing concepts and referring to
many other RFCs. Suggest to mention which terms and concepts are defined in
each document. Else, the current section 2.2 mostly forces the readers to read
all the references.

-- Section 6 --
s/may use a same Crypto-ID/may use the same Crypto-ID/ ?