Andy Bierman <a...@yumaworks.com> wrote: > On Sun, Jun 4, 2023 at 7:01 AM Kent Watsen <kent+i...@watsen.net> wrote: > > > As an individual contributor and faithful YANG custodian, I cannot > > support work that changes YANG-semantics without versioning YANG itself. > > As Andy wrote before: > > > > The only correct way to remove MUST/MUST NOT from the "YANG contract" > > is to introduce a new YANG language version (1.2), and make a new > > contract. > > > > I want this work to move forward in the form of a quick (limited-scope) > > rfc7950-bis. One idea would to support just this YANG-next issue > > <https://github.com/netmod-wg/yang-next/issues/70>
I think you meant https://github.com/netmod-wg/yang-next/issues/49. > > and then mark the > > versioning extension as "critical". That said, I believe that an even > > better versioning-solution can be had if integrated into the YANG-language > > directly. > > > > > IMO the parsing of YANG files to produce a conceptual data model > is a critical component of the language itself. Any statements that > affect this conversion step MUST be regular statements. > An extension is (by definition) an external statement that is not part of > the YANG language. > Critical extensions are not a good design choice. I strongly agree. Allowing the language to drastically change (like in this example) by just defining a critical extension is not a good idea. Basically, anyone can define their own extension that changes YANG to whatever, and still claim conformance. > Just add real statements > instead. > > IMO most of the yang-next issues are not interesting or valuable, > so a long WG process to go through this entire list is a non-starter. > The problem is that everyone will have their own pet-issues that they think are critical... > There are 3 critical changes that need to be made. > - change "status" so deprecated and obsolete definitions are > correct ... for example I don't think this is critical ... > - introduce new instance-identifier data type based on RFC 7951 definition > - introduce new identityref data type based on RFC 7951 definition ... but I do agree with these! /martin > > > > > > Kent > > > > > Andy > > > > > > > > On May 22, 2023, at 6:20 PM, Kent Watsen <kent+i...@watsen.net> wrote: > > > > NETMOD WG, > > > > The chairs are extending this WGLC by two weeks (now ending June 5) in > > order to ensure adequate review, since this is important work, and a solid > > consensus is needed. > > > > Kent and Lou > > > > > > > > On May 8, 2023, at 6:49 PM, Kent Watsen <kent+i...@watsen.net> wrote: > > > > Dear NETMOD WG, > > > > This message begins a joint two-week WGLC for > > draft-ietf-netmod-yang-semver-11 and > > draft-ietf-netmod-yang-module-versioning-09 > > ending on Monday, May 22nd. Neither draft has IPR declared. Here are the > > direct links to the HTML version for these drafts: > > > > - https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-11 > > - > > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09 > > > > Positive comments, e.g., "I've reviewed this document and believe it is > > ready for publication", are welcome! This is useful and important, even > > from authors. Objections, concerns, and suggestions are also welcomed at > > this time. > > > > Thank you, > > Kent and Lou (chairs) > > > > > > > > > > > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
