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

[Kent Watsen <[e-mail]>]

> 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.