Hi Pascal, Thanks for sharing that change proposal. I confirm that it addresses my concerns and I would clear my DISCUSS position once it is posted.
I would suggest waiting for confirmation from other ADs before you post though, to make sure there is no back/forth :-) Thanks, Ketan On Fri, Jun 6, 2025 at 2:33 PM Pascal Thubert <[email protected]> wrote: > 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]
