Ketan Talaulikar has entered the following ballot position for draft-ietf-6lo-prefix-registration-11: 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 have a couple of points that I would like to discuss to get some clarity on this document. <discuss-1> It is not clear if the specifications in this document are scoped only for 6LO deployment scenarios or are being made generically applicable/available for all of IPv6 ND deployment/usage even in "usual" networks across the Internet. The document claims to update RFC4861 but previous documents RFC 6775 and 8505 seem to be (at least to me) narrowly scoped to 6LO. Note: Likely RFC 9685 also had the same ambiguity <discuss-2> This document claims to be updating a host of existing RFCs using the logic/argument presented in draft-kuehlewind-update-tag. That individual draft does not have IETF consensus and so I do not think it is appropriate to apply its rationale for the "update" tag for IETF RFCs. I have no objections on anyone using the terms (amend & extend) to clarify relationship with existing RFCs. However, this document also uses those terms along with the "updates" term and has a long list of document that it is claiming to "update". Note: I am aware of at least one RFC 9685 that did similar actions and was approved by the previous IESG. Nevertheless, I would like to discuss this within the current IESG. My concerns with such usage is that it obfuscates the meaning of "update" tag and will makes the problem highlighted by draft-kuehlewind even worse. I worry how its application for a protocol like BGP will turn out to be. _______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
