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