Dear Ketan and all I proposed to diff that removed the Extends and Amends thingy as Github · pthubert/6lo-prefix-registration@dde1a90 <https://github.com/pthubert/6lo-prefix-registration/commit/dde1a903729546131610c7e18a838b2a3460e4e3>. The change also modifies the way RFC 4861 si used (the target address is notw a full address from the registered prefix) so that RFC 4861 is not updated. Could you please have a look and let me know if that fixes your issues?
all the best Pascal Le jeu. 5 juin 2025 à 18:55, Ketan Talaulikar via Datatracker < [email protected]> a écrit : > Ketan Talaulikar 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: > ---------------------------------------------------------------------- > > Thanks to the author and the WG for this very useful extension for Prefix > Discovery in 6LoWPAN. > > I am updating my DISCUSS post the telechat in two ways: (a) removed my > previous > question for clarification of whether this extension is narrowly scoping to > 6LoWPAN (and related scenarios) alone or generically for all of IPv6 ND > deployments, and (b) clarified my position on the other discuss (see > below). > > This document is setting the "update" RFC metadata on 7 RFCs 4861 (base > IPv6 > ND), 6550 (RPL), 6553, 8505 (6LoWPAN ND which btw does not update 4861), > 8928, > 8929 , 9010. > > For the record, none of the RFCs from 6Lo (and related space/WGs) updated > base > ND RFC 4861 until very recently RFC9685 did that by "updating" a whole > host of > RFCs just like this document is trying to do. > > Now this draft references draft-kuehlewind-update-tag and uses its > terminology > of ammend/extend (but curiously not "also see"). I have no issue with the > use > or referencing on this term in the body of the text. My query is whether > extending those terms from draft-kuehlewind to reflect on the existing > "updates" RFC metadata (which is not what draft-kuehlewind proposes) is > correct. i.e., is this a normal protocol extension using available bits, > fields, TLVs OR is it a change (or bugfix) of the base specification > itself. > > I do also have doubts on the claim that it amends RFC4861 (I believe it > amends > RFC8505 instead). > > I could be wrong and request the INT ADs to correct me. > > > > > > -- Pascal
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
