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]> 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]> > *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]> 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]
