Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Andy Bierman <[e-mail]>]

On Tue, Apr 12, 2022 at 7:45 AM Kent Watsen <[e-mail]> wrote:

>
>
> For me, the only sensible option (other than accepting that types are
> named the way they are) is to introduce ip-address-with-zone and to
> deprecate ip-address and stop there. Yes, this means coexistance of
> inet:ip-address and ip-address-with-zone until YANG is getting
> replaced.
>
>
> As a contributor, this seems to be the most reasonable "by the rules"
> option.  There's nothing wrong with introducing a more-explicit label and
> deprecating a less-explicit label.   Having more explicit labels seems to
> be general goodness (e.g., more readable tree-diagrams) while not impacting
> CLI usability.  Deprecating less-explicit labels enables tooling to move
> existing non-explicit label uses to the more-explicit labels.
>
> It is easy to empathize with those seeing this as a bug-fix, but there's
> no clean way to assume a particular definition is what was universally
> intended and used.  It's additionally difficult to support an approach
> that breaks the rules that we are charged to defend.
>
> Level-upping, is there any takeaway modeling advice coming out of this?
> There's a historical trend to define base types with a
> broad value-space assuming uses will refine the value space as needed.
> This trend seems well-reasoned, and yet here we are. Should there be advice
> indicating that if a value space is faceted, a union of more-explicit types
> is better (e.g., inet:host)?  If there is a type that is the union of
> "-with-zone" and "-without-zone", would it better to call it
> "ip-address-with-or-without-zone" or just "ip-address"?  [PS: I'm assuming
> that -with-zone" requires a zone, i.e., it's not optional]
>
> PS: As a chair, consensus seems elusive.   Roughly 10 people have provided
> opinions with a nearly 50/50 split between the "follow the rules" and "do
> what's 'right'" camps.
>
>
One extreme is to say "the typedef says what it is. Too bad you have to
rewrite 100s of YANG modules."

The other extreme is to say "Nobody supports the zone index, so change the
typedef to match
what the users actually want, right now."

The middle ground is to say "Nobody is reporting a bug that their client is
setting a zone index
and our server is doing the wrong thing, so there is no real problem to
solve here".

The compromise is to say "You have 2 years to change to a new typedef if you
really need a zone index."

Perhaps nobody is right.
Perhaps there is only a least worst solution and no good solution.
There is not enough objective criteria to pick the best one.




> K.
>

 Andy

_______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>