Hey Bill, you're right that I'm only kind of "grumpingly pointing things out" w/o any productive fixes suggested so below some attempts although I know stuff's been in flight for a bit so any changes are unlikely. Here's my best attempt
On Tue, Feb 3, 2026 at 5:58 AM Bill Fenner <[email protected]> wrote: > On Mon, Jan 26, 2026 at 5:17 PM Tony Przygienda <[email protected]> > wrote: > >> On Ron's urging ;-) I read draft-ietf-intarea-rfc8335bis and here are >> bunch of my comments while I admit this is bit out my usual roaming grounds >> ;-) >> >> >> - >> 1. The “L-bit” and the whole “directly connected” vs. “resides on >> proxy” is baffling for a long time in the doc and looks to me like a >> distinction w/o difference. I suggest maybe a better terminology and >> definitely a clear glossary with an earlier explanation of the terms. It’s >> confusing to call it a “proxy node” while the interface is still on the >> “proxy node”. Maybe the “local” bit should be called “proxy bit” or >> something to read it clearer. >> >> For better or for worse, it's been called the "Local" bit for 8 years. > I'm not sure that changing the terminology now is the right action. I'll > try to re-read these sections with a fresh eye to what can be clarified. > well, it's impossible to parse " * L (local): The L-bit is set if the probed interface resides on the proxy node. The L-bit is clear if the probed interface is directly connected to the proxy node. " First suggestion is to abandon the "resides" and only work with "attached" across the document as I show later in the glossary. Current glossary basically implies that the "probed interface" always "resides" on the proxy node (which can be the probed node) so what is this "directly connected" now all of a sudden? Suggestion for a simpler semantics " * L (local): Indicates that the probed interface is directly attached to the probed node and proxying is not allowed. " where "proxying" is a term down in the glossary that seems to me easier to parse than all those "proxy this" and "not proxy this" while sometimes the "proxy this" and "not proxy this" are the same thing ;-) > >> - >> - 2. Draft may have a roblem if the node has multiple interfaces with >> LLv6 only that are the same (which is allowed). Then if the L-bit is clear >> you cannot differentiate given the “MUST identify by address” since you >> need interface name as well in this case. AFAIS a clarification is needed >> that you can use both address *and* name with L bit clear than then >> have procedures to resolve ambiguity (e.g. interface name always takes >> precedence if address mismatches) . AFAIS the interface identification >> object however is allowed only once. >> >> Yes, you've identified a limitation of the original document: if > duplicate link-local addresses exist, you do not know which answer you are > receiving. Perhaps we could add a 4-byte numeric zone index to the encoded > IPv6 address, like the SNMP InetAddressIPv6z, but it's not at all clear > that this concept is widely implemented. Given that the compatibility rules > say that precisely one Interface Identification Object can be supplied, I > don't see how we can say that you can include multiple. > okey, yes, further limitation and possibility of confusion is if _two_ possibly probed nodes are attached to a proxy node and both of those hold interfaces with same LL ;-) Otherwise I see the cage of constraints that forced the current spec. > >> - >> - 3. Section 5 claims to clarify the language for “resides on” and >> “directly connected” but that does never really happen in the draft AFAIS. >> >> The reference to section 5 is trying to justify use cases, it's not > intended to be about the terminology. Do you think these terms need to be > clarified? Do you have other terms that you would prefer for these > concepts? The text in the document is > "Section 5 of this document describes scenarios in which this > characteristic is useful" and "this characteristic" refers to "The proxy > interface can reside on the same node... or it can reside on a [different] > node...". > To put it mildly the language is difficult to parse across the document, particularly the introduction, when one tries to apply reasonable English semantics. I suggest moving in glossary to a better ontology by differentiam specificam (while the fact that proxy node is either probed node or is a different thing contributes lots to the confusion of the language. same with proxy/no-proxy interface) and as I said abandon the "resides" language completely. Suggestion for minimal change " * Probing interface: The interface that sends the ICMP Extended Echo Request. * Probed interface: The interface whose status is being queried. * Probing node: The node upon which the probing interface is attached. * Probed node: The node to which the probed interface is attached. * Proxy: Term indicating that the probed node _may_ be attached to a (proxy) node attached to the (proxy) interface processing PROBE packets rather than being attached to the PROBE packet processing interface itself. * Proxy interface: The interface to which the ICMP Extended Echo Request message is sent. * Proxy node: The node to which the proxy interface is attached. Proxy node and probed node are directly connected or represent the same node. In case the probed interface is attached to the proxy node, the terms proxy node and probed node are equivalent. In the very special case of the probed interface being the one processing PROBE packets, proxy interface and probed interface are equivalent terms as well. " And the glossary is sorely needed before or at least at the start of the introduction section, otherwise it's unparsable. Or otherwise the introduction needs a picture and avoid all the "proxy" and "resides" language somehow. > >> - >> - 4. Generally I'm bit terrified of the whole thing acting as a “yang >> proxy”. The probing node could simply read the according Yang and if it >> cannot then the whole “proxy” is basically bypassing Yang security >> restrictions AFAIS? and yes, I understand, it's all "exigency" and "e'one >> already does it" but then the draft should be maybe bit more honest about >> it and deal with according security implications ? >> >> I find the terminology "yang proxy" to be confusing, since yang is a > language with which to model information, and not a protocol that can be > proxied, I imagine that you are suggesting that the model described by a > yang model should be queried using OpenConfig or Restconf or gnmi? > So I reread the thing carefully again. My first assumption that the proxy node may reach into Yang of the probed node (in case of them not being the same) via some routed protocol to figure out the state of the "probed interface" given RFC8343 was mentioned and I was thinking about interfaces not being on the same subnets. However, it seems that ARP/v6 cache is used only and then I ask myself how the ARP cache is populated if no packets were ever forwarded or if the probed interface is on a different subnet completely. It looks to me that the whole "proxying" is possibly only within the same subnet then? But then how does that make sense given a router cannot have 2 interfaces on the same subnet (bare some nasty tricks circumventing RFC1812 ;-) per se. If that's the case it bears mentioning AFAIS since "proxy node and probed node being directly connected" does imply that stuff can be routed although given it's ICMP it probably shouldn't. It shows I didn't have to implement or deploy it but on the other hand allows me to ask naive questions I guess ;-) > > The security considerations section starts with "By default, ICMP Extend > Echo functionality is disabled" - so, are we really bypassing network > management security restrictions by requiring that the administrator > explicitly enable this? > IMO yes, it's a backdoor possibly to get to yang information that the probing node was not supposed to get to. Otherwise the security section is well written and outlines the attack envelope well AFAIS. --- tony > > Bill > >
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
