> 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.
K.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
