On Tue, Apr 12, 2022 at 7:45 AM Kent Watsen <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
