Hello Ketan: Many thanks for your quite valid points. On whether to use "updates" vs. update_tag, I'll do as I'm asked based on the IESG consensus. I'll add that I'm unsure whether extending a draft (e.g., by defining more flags in a fields previously specified), which IMHO constitutes an "extends", is an "update" as well, and if so, whether that the updated RFC should be listed in the title page under the "updates" tag.
Le mar. 3 juin 2025 à 09:52, Ketan Talaulikar via Datatracker < [email protected]> a écrit : > 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. > It is optimized for 6lo situations and works in all P2P, P2MP, NBMA and broadcast environments that I can fathom, in conjunction, when needed, with a subnet gateway protocol like RPL or RIFT. More touchy is the case of coexistence of ND and SND in a broadcast environment. RFC 8929 (proxy ND for SND clients) enables to connect SND-only stuffs over an ND-only backbone and form a single subnet. But the full interaction has not been fully studied. Maybe RFC 8929 used by nodes over the backbone is enough, maybe not. Without a proxy, how to setup the routers so an SND-only and an ND-only nodes can speak was not specified. There's more discussion in draft-ietf-6man-ipv6-over-wireless and I believe that's where this discussion belongs since it is really the what_is_snd<_for> doc. Whatever I write here may cause endless discussions. Even saying it's 6lo only (define 6lo?). Suggestion: Let us have that discussion in 6MAN, not here, over draft-ietf-6man-ipv6-over-wireless, not this, and let us retain the ambiguity here. > > Note: Likely RFC 9685 also had the same ambiguity > All specs do. Saying you can do this does not mean you can do only this. SND is optimized for low power and supports NBMA. Does not mean that it can not do powered P2P or broadcast links. > > <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. > > Please have that discussion at IESG level and I'll comply with your decision. Note that the current form comes from IESG members recommendations a few years ago. take care, -- Pascal
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
