Bonjour Pascal, While the trick to avoid updating RFC 4861 is smart, it is also fitting a square peg into a round hole đ
Letâs keep it simple and revert back to the previous text in section 4 of version -12 and formally updating RFC 4861. Then resubmit and after a final check, I am approving the 2 6LO drafts (assuming that Roman clears his DISCUSS ballot of course) Regards -Ă©ric From: Pascal Thubert <[email protected]> Date: Saturday, 28 June 2025 at 12:38 To: Eric Vyncke (evyncke) <[email protected]> Cc: Roman Danyliw <[email protected]>, The IESG <[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) Hello Eric Many thanks! ... all done in github but the very last point on updating RFC 4861. This was actually removed based on one of the reviews, and the trick used was to retain the use of the NS/NA Target field to contain an address as opposed to a prefix. That address must be within the registered prefix but is not a prefix. The thought was that this way, there's no updating RFC 4861. 6.1 is actually replacing the section on updating RFC 4861. Maybe a rewrite of 6.1 to make it clearer that it is not an update is a better approach to match all demands? waiting for your feedback to publish all the best Pascal Le jeu. 26 juin 2025 Ă 14:40, Eric Vyncke (evyncke) <[email protected]<mailto:[email protected]>> a Ă©crit : 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]<mailto:[email protected]>> Date: Friday, 6 June 2025 at 11:00 To: Roman Danyliw <[email protected]<mailto:[email protected]>> Cc: The IESG <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[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 -- Pascal
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
