reposting to the right group. tony

---------- Forwarded message ---------
From: Tony Przygienda <[email protected]>
Date: Mon, Jan 26, 2026 at 9:03 AM
Subject: some loose comments on draft-ietf-intarea-rfc8335bis
To: 6man WG <[email protected]>


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.
   -
   - 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.
   -
   - 3. Section 5 claims to clarify the language for “resides on” and
   “directly connected” but that does never really happen in the draft AFAIS.
   -
   - 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 ?
   -
   - thanks
   -
   - --- tony
_______________________________________________
Int-area mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to