Tony,
Your fourth point is not an objection to this draft. It is an objection to RFC
8335.
That ship has already sailed. Not only has the RFC been published, but many
vendors are shipping the code.
Ron
________________________________
From: Tony Przygienda <[email protected]>
Sent: Monday, January 26, 2026 8:16 PM
To: [email protected] <[email protected]>
Subject: [Int-area] Fwd: some loose comments on draft-ietf-intarea-rfc8335bis
reposting to the right group. tony
---------- Forwarded message ---------
From: Tony Przygienda <[email protected]<mailto:[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]<mailto:[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]
