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. > > - > - 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. > > - > - 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...". > > - > - 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? 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? Bill
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
