Hi Pascal, Thanks for the quick response. As I said, I saw no issues in the technical specification itself and I found it very useful for the 6LoWPAN (but also other environments).
Both of my points were more to the other ADs in the IESG and to be clear this is just a discussion and not a "block" per-se. Please check inline below. On Tue, Jun 3, 2025 at 7:11 PM Pascal Thubert <[email protected]> wrote: > 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. > KT> Perhaps so. I am not asking for use for general deployment to be precluded or even prohibited. I was thinking about a clear scoping in this spec to the 6LoWPAN space (plus other similar scenarios). We'll see what the rest of the IESG and Eric as the responsible AD has to say. > > >> >> 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. > KT> I am very aware of this fact. I am also comfortable with it. There is the world/industry beyond the IETF where technology actually gets deployed. My point was that the document should be scoped for the primary deployment scenario for which the spec is being defined. > > >> >> <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. > KT> Ack. IMHO this kind of "updates" is broken. But I am still a newbie AD ;-) Thanks, Ketan > > take care, > > -- > Pascal >
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
