Document: draft-ietf-6lo-updating-rfc-8928 Title: Fixing the C-Flag in EARO Reviewer: Samir Barguil Review result: Ready I have reviewed this document as part of the Operational Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of IETF drafts. Comments that are not addressed during the last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments like any other last call comments. This Internet-Draft proposes a correction to the specification of the Extended Address Registration Option (EARO), which is used in Address-Protected Neighbor Discovery for Low-Power and Lossy Networks (AP-ND), defined in RFC 8928. Specifically, it addresses an overlap in the bit positions allocated within the EARO flags field, where the C-flag (indicating a Crypto-ID in the Registration Ownership Verifier field) conflicted with the P-field defined later in RFC 9685. To resolve this, the document repositions the C-flag to a new bit position within the EARO flags field and requests IANA registration for this change, ensuring clear definitions and preventing future conflicts. Just have minor suggestions (Nits): Section 3. Updating RFC 8928: - "in the Figure 1" could be "in Figure 1". - "avoiding the overlapping definitions" is fine, but "resolving the overlap" or "eliminating the conflict" might be slightly more direct. Option fields of interest for this specification: r (reserved): - "All reserved field MUST ..." - "All reserved fields MUST be set..." . - "derived from the unicast prefix that is being registered" is a bit long. Perhaps "or derived from the registered unicast prefix." Table 1: - "RFC This and RFC 8928" - "RFC XXXX and RFC 8928" -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
