Dear Ketan I can publish further revisions, no problem. But I believe that this is a better base considering the issues raised. Please see: Diff: draft-ietf-6lo-prefix-registration-12.txt - draft-ietf-6lo-prefix-registration-13.txt <https://author-tools.ietf.org/iddiff?url1=draft-ietf-6lo-prefix-registration-12&url2=draft-ietf-6lo-prefix-registration-13&difftype=--html>
all the best; Pascal Le ven. 6 juin 2025 à 12:08, Ketan Talaulikar <[email protected]> a écrit : > 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 >> > -- Pascal
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
