Bonjour Pascal, Let’s focus again on this draft.
Revision -12 has removed the specific semantic of the terms “amend” and “extend”, this should greatly facilitate the DISCUSs clearing by Roman. But there are still “amend” and “extend” in the text, notably in the titles of sections 4, 6.5, and 9 => replace them by “update”. There are also several occurrences of “extends” and “extended” in the text, which should also be replaced. The -12 also re-introduced section 6.1: * Suggest using “Leveraging the NS/NA Target Address to Advertise a prefix” as title * As this change RFC 4861 behavior (and not simply add a new value for a reserved field), this document must formally update RFC 4861 as well (i.e., abstract & meta-data) Regards -éric From: Pascal Thubert <[email protected]> Date: Friday, 6 June 2025 at 11:00 To: Roman Danyliw <[email protected]> Cc: The IESG <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: [6lo] Re: Roman Danyliw's Discuss on draft-ietf-6lo-prefix-registration-12: (with DISCUSS and COMMENT) Dear Roman Many thanks for your review! I feel I'm standing between the proverbial hammer and hard place. I trust you guys at the telechat discussed it. Sorry I could not attend, I was on the road at the time. Please see the proposed diffs in github Dear Roman · pthubert/6lo-prefix-registration@dde1a90<https://github.com/pthubert/6lo-prefix-registration/commit/dde1a903729546131610c7e18a838b2a3460e4e3> and my responses below: Le mer. 4 juin 2025 à 20:00, Roman Danyliw via Datatracker <[email protected]<mailto:[email protected]>> a écrit : Roman Danyliw has entered the following ballot position for draft-ietf-6lo-prefix-registration-12: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6lo-prefix-registration/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- ** As other ADs have balloted, [I-D.kuehlewind-update-tag] has no standing. Section 2.1 appears to state that “extends” and “amends” are synonyms for “updates”. I take that to mean that the processes associated with the “updates tag” apply. As such, the document is not self-consistent: The way I use the draft was pushed on us by IESG reviews one or 2 generations ago. Took some work to rewrite drafts at the time to comply. Note that I was perfectly happy with the "updates" tag as it stood 5 years ago. But now I'm utterly confused with what the IESG expects. Multiple IESG reviews insist on a "usual" meaning for "updates". "Usual" does not qualify well my perception of how "updates" is used. I have in mind that the lack of clarity of what constitutes an update is what triggered [I-D.kuehlewind-update-tag]. Do we have a better reference now? -- Section 5 says this documents extends RFC7400, but this document isn’t included in the “Updates meta-data” (RFC8929 is also noted as “extending” but is included in the list of documents referenced by the update tag) I agree it's not consistent. At the moment I expect to get a recommendation from the telechat on which drafts you expect to be mentioned in the "updates" tag. I removed RFC 8929. I also changed the way RFC 4861 is used to end the debate on whether signaling a prefix in the NS Target Address constitutes an update. Instead, I made it an address that matches the prefix so RFC 4861 is not updated. I'm still unclear whether extending a spec is considered as an update: e.g., draft_ancestor defines a field "reserved" to be ignored on receive. draft_new provides a behaviour. Meaning that the receiver will not ignore any more. This is a change of behavior. With the "new" terminology that's an "extends". Is it an update? Note that one review asked me to remove RFC 7400 from the "update" list and I was fine with that. Now it seems (I hope not?) that you're asking it back. In my past RFCs, I did not indicate RFC 7400 in my update tags.The IANA registry is a good source for all the bits, following an "update" list might be too much. -- The Updates meta-data tag and abstract say RFC6553 is updated, but the body of the text doesn’t explain how. There isn’t even a reference to it. True. I guess that one is an easy remove ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Dan Romascanu for the GENART review. ** Section 13.2. The registry field names used in Table 3 are not correct. Per https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#sixlowpan-capability-bits: -- s/Capability Bit/Bit/ -- s/Meaning/Description/ Done. I noticed that the "A" bit is called the "1" bit. A typo I guess. Specifically with the figure from RFC 7400 that I reproduced.I marked the 32 bits field "reserved". One review (Med) asked me for consistency with RFC 7400 so I should call it unassigned. OK, reluctantly I did, claiming that RFC 7400 called it unassigned in the text, but the process described was the usual one for "reserved". Now I'm getting comments that I should call it "reserved" because of other RFCs (including mine) that call it reserved. I'll make it Reserved again. Seems that the last reviewer wins, but the document potentially loses. I guess contradictions in reviewers expectations are part of the game, it's an imperfect world; and I applied my best judgement. take care, -- Pascal
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
