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
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
