On Tue, Apr 5, 2022 at 8:45 AM Acee Lindem (acee) <acee= [email protected]> wrote:
> > > On 4/5/22, 11:37 AM, "Lsr on behalf of Jürgen Schönwälder" < > [email protected] on behalf of [email protected]> > wrote: > > On Tue, Apr 05, 2022 at 01:48:25PM +0000, Acee Lindem (acee) wrote: > > [wg-member] > > > > The thing is that most of the existing RFCs use inet:ip-address > rather inet:ip-address-no-zone. It would be better to if we could fix > inet:ip-address in RFC 6991 BIS to not include the zone similar to what was > done in the MIB (RFC 4001). However, we're getting the passive aggressive > treatment on this point. > > > > You either assume that all existing uses of inet:ip-address (inside > the IETF and outside the IETF) are wrong or you are willing to break > all the existing correct uses of inet:ip-address so that the type > matches your expectations. > > The existing YANG update rules are pretty clear that changing the > semantics of definitions is not allowed. Hence, all the WG could do > is to deprecate ip-address and to introduce ip-address-zone. > > The best outcome would be to fix ip-address to not include the zone, > introduce ip-address-zone, and deprecate ip-address-no-zone. My take all > the is that all the existing usages do not require zone and this would be a > fix as opposed to a change. > > I don't think this will harm our implementations. The type is still string. The pattern will change but that is handled by a library. Whatever pattern is used will get handled the same way. The same problem exists for 'date' and 'date-no-zone' types, but they are not used very much. But... Since import-without-revision is used most of the time, a module importing ietf-inet-types will get what? Very implementation-specific, that's what. Maybe both versions of ip-address present in the same server, maybe not. Acee > > /js > Andy > > -- > Jürgen Schönwälder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
