Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts

[Martin Björklund <[e-mail]>]

Andy Bierman <[e-mail]> wrote:
> On Sun, Jun 4, 2023 at 7:01 AM Kent Watsen <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> >
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> >
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> >