[Speaking as an individual]

My disposition on these two errata is as follows:

> On Jun 5, 2026, at 2:02 PM, Kent Watsen <[email protected]> wrote:
> 
> NETMOD / Mahesh,
> 
> In applying the RFC 7950 errata on the "yang2" document, I discovered two 
> errata never closed:
> 
> https://errata.rfc-editor.org/eid7021

Reject:

§5.1.1 already explicitly covers republishing a module with an updated import 
statement. The omission from §11 does not prohibit this action, and the claim 
(in the Notes section) that it prevents migration is incorrect — unpinned 
imports resolve automatically to the latest revision (which contain the new 
enum definition), and pinned imports are updated as a deliberate new 
publication already sanctioned by §5.1.1. No gap exists that requires 
correction.

> https://errata.rfc-editor.org/eid8784

HDU:

The errata correctly identifies an implementation risk — the asymmetric 
monitoring problem is real and non-obvious. But the fix should happen at two 
levels:

Normative text (wherever leafref-in-union dynamic constraints live) should 
explicitly state that creation of a matching instance also triggers 
reinterpretation.
The example should then be updated to illustrate both directions consistently

Adding "must" to an example via errata, without touching the normative section, 
would leave a normative/example mismatch in the other direction.

Suggested update to the note section:

The errata correctly identifies that the example is misleading about the scope 
of dynamic monitoring required for leafref within a union. However, the 
proposed fix introduces normative language ("must") into an example section, 
which is inappropriate for errata. The correct resolution is a document update 
that: 

strengthens the normative text governing leafref-within-union dynamic 
revalidation to explicitly cover both target-removal and target-creation 
events, and 
updates the example to reflect both directions. 

The yang2 document should address this as part of its update.

Cheers.

> 
> Can we verify or reject these now?
> 
> Kent
> 
> _______________________________________________
> netmod mailing list -- [email protected]
> To unsubscribe send an email to [email protected]


Mahesh Jethanandani
[email protected]






_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to