Thank you, Adnan and Pascal, for authoring this document. Both with and without my “responsible AD hat”, I have reviewed the draft (see below) and strongly support the adoption of this correcting draft by the 6LO WG.
During my review, I have the following comments (mainly about shortening the I-D ;-) ) that can be ignored of course and are based on similar ‘correcting’ publications (RFC 9710 and 9748): 1. Title: s/Moving the C Flag in EARO/Fixing the C-Flag in EARO/ 2. Also suggest to use everywhere C-flag and P-field or at least be consistent 3. Please add a mostly empty security section ‘This document does not introduce new security issues as compared to RFC 8928.” 4. Abstract: s/by explicitly specifying the bit position for the “C” flag/by updating the bit position for the C-flag/ 5. Abstract: I would remove everything after `This clarification ensures...` 6. Section 1: (perhaps extreme) but I would simply remove the first 3 paragraphs... 7. Section 1: s/initially defined the “C” flag in EARO later on [RFC9685<https://www.rfc-editor.org/info/rfc9685>]/initially defined the “C” flag in EARO in bit position 3; later [RFC9685<https://www.rfc-editor.org/info/rfc9685>]/ 8. Section 1: make `This specification updates [RFC8928<https://www.rfc-editor.org/info/rfc8928>] ...`on its own paragraph 9. Section 2: (perhaps extreme also) can be completely removed, i.e., there is no need to explain what EARO is 10. Section 3: the sentence `The "Address-Protected Neighbor Discovery for Low-Power and Lossy Networks"<https://www.rfc-editor.org/info/rfc8928> [RFC8928<https://www.rfc-editor.org/info/rfc8928>] was ... registered with [RFC8505<https://www.rfc-editor.org/info/rfc8505>].` can also be removed 11. Section 3: s/In [RFC8928<https://www.rfc-editor.org/info/rfc8928>], the "C" flag is shown/In [RFC8928<https://www.rfc-editor.org/info/rfc8928>], the "C" flag is specified/ this is actually a specification ;-) 12. Section 3: in the same vein `it does not explicitly specify the bit number` is not really correct as the figure is quite explicit 13. Section 3: suggest to write that Figure 1 of this I-D replaces the RFC 8928 figure 1 14. Section 3: there is no Status field in Fig 1, so no need for `Status: Defined in [RFC8505<https://www.rfc-editor.org/info/rfc8505>]. ` 15. Section 3: add a reference where the P-field is defined 16. Section 4.1: use this I-D in addition to RFC 8928 the reference in the added row in the IANA registry 17. Section 5: to be removed ;-) 18. Sections 6 & 7: to be updated based on the above deletions (if they are accepted by the authors & WG) Thanks again Regards -éric From: Carles Gomez Montenegro <carles.gomez=40upc....@dmarc.ietf.org> Date: Tuesday, 15 April 2025 at 09:52 To: 6lo@ietf.org <6lo@ietf.org> Subject: [6lo] Re: Call for adoption of draft-ietf-6lo-updating-rfc-8928 Apologies, we meant that the call for adoption will end on the 22nd of *April*, EOB. Cheers, Shwetha and Carles On Tue, 15 Apr 2025 at 09:46, Carles Gomez Montenegro <carles.go...@upc.edu<mailto:carles.go...@upc.edu>> wrote: Dear 6lo WG, This message starts a call for WG adoption of draft-ietf-6lo-updating-rfc-8928-00. (Link: https://datatracker.ietf.org/doc/draft-ietf-6lo-updating-rfc-8928) This document aims to fix a mistake with the C flag in EARO in RFC 8928. As this is a short document, the call will end on the 22nd of May, EOB. Please state whether you are in favor of adopting this document. Also, comments and reviews of the document will be very much appreciated. Thanks, Shwetha and Carles
_______________________________________________ 6lo mailing list -- 6lo@ietf.org To unsubscribe send an email to 6lo-le...@ietf.org
