Hi,
OLD:
A new module revision MAY contain NBC changes, e.g., the semantics of
an existing data-node
definition MAY be changed in an NBC manner without requiring a new
data-node definition with
a new identifier.
NEW:
A new module revision SHOULD NOT contain NBC changes, e.g., the
semantics of an existing data-node
definition SHOULD NOT be changed in an NBC manner without requiring a
new data-node definition with
a new identifier.
This allows Option 4 since SHOULD NOT will require an exception review to
get an RFC published.
Andy
On Sun, Jul 23, 2023 at 5:11 PM Balázs Lengyel <balazs.leng...@ericsson.com>
wrote:
> Hello,
>
> I am writing this as
>
> - Balazs Lengyel one of the authors, but also as
>
> - an Ericsson guy and also as
>
> - a delegate of 3GPP, which requested a better versioning scheme in a
> reasonably
>
> fast timeline. 3GPP represents both vendors and operators, so in this
> last
>
> role I am sitting on both side of the fence.
>
> I strongly support option 1 - modifying 7950 to allow NBC changes and
>
> introducing something like Semver.
>
> - We need this soon and the other alternatives will take a longer time.
>
> - we need it for the current YANG models too, not just for YANG 1.2 or 2
> models
>
> - We are already today doing backwards incompatible updates. We would like
> to have
>
> that aligned with IETF.
>
> - as one of the authors I believe the work is ready and reasonably good
>
> - I believe adapting the tooling for a few new extensions is much less
> work
>
> than adapting to a new YANG version
>
> Option 2 will take a long time to specify, implement and roll out. During
> this time
>
> other non-standard solutions will proliferate; messy solutions, like just
>
> ignoring the current RFC7950 rules, will be used more and more.
>
> Option 3 just ignores the real world.
>
> NBC changes are happening. There are SDOs that value speed over final
> quality
>
> and role out a new version of the modules every few months. These can not
>
> live without some NBC changes.
>
> A more fine grained versioning system is required.
>
>
>
> Regards Balazs
>
>
>
> *From:* netmod <netmod-boun...@ietf.org> *On Behalf Of *Andy Bierman
> *Sent:* Thursday, 20 July, 2023 18:52
> *To:* Jason Sterne (Nokia) <jason.ste...@nokia.com>
> *Cc:* netmod@ietf.org
> *Subject:* Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes
> in YANG 1.0 & YANG 1.1 or not?
>
>
>
>
>
>
>
> On Wed, Jul 19, 2023 at 1:13 PM Jason Sterne (Nokia) <
> jason.ste...@nokia.com> wrote:
>
> We considered this approach as well in the weekly calls but in the end
> felt that was just dodging the problem. We have a set of “MUST” rules that
> we know need to occasionally be broken. Shouldn’t we officialize this so
> our behavior and documents match? (i.e. SHOULD NOT instead of MUST)?
>
>
>
> It isn’t just an IETF issue. These same exceptions occur in vendor models,
> 3GPP, etc. There are times when making the NBC change is the reasonable way
> to go.
>
>
>
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning#name-updating-a-yang-module-with
>
>
>
> I do not support these changes in any version of YANG.
>
> The advice to the community is non-specific and obviously not backward
> compatible with RFC 7950.
>
> The new advice is that any change at all in a YANG module is now allowed.
>
> Instead of normative rules, RFC 7950 simply advises whether the optional
> 'non-backwards-compatible' extension could be applied or not.
>
> This is not a good change, especially on top of YANG 1.1.
>
>
>
> I could see if specific MUST NOT rules were changed to SHOULD NOT instead.
>
> A blank check using the current "MAY" (3.1, para 2) is not a good idea.
>
>
>
>
>
> Jason
>
>
>
> Andy
>
>
>
>
>
> *From:* Andy Bierman <a...@yumaworks.com>
> *Sent:* Wednesday, July 19, 2023 1:13 PM
> *To:* Martin Björklund <mbj+i...@4668.se>
> *Cc:* Jason Sterne (Nokia) <jason.ste...@nokia.com>; netmod@ietf.org
> *Subject:* Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC changes
> in YANG 1.0 & YANG 1.1 or not?
>
>
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext
> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-688efc90f7cb3f03&q=1&e=d73d3aee-48a4-4fe9-b81b-56650cfeb8c6&u=http%3A%2F%2Fnok.it%2Fext>
> for additional information.
>
>
>
>
>
>
>
> On Tue, Jul 18, 2023 at 4:48 AM Martin Björklund <mbj+i...@4668.se> wrote:
>
> What about Option 4 - Pragmatic Adherence to Current RFC7950 Rules
>
>
>
>
>
> This is the approach I also suggested on the mailing list.
>
>
>
> - As it works today; the IETF *has* published bugfixed modules that break
> the
> rules. (and many vendors do this as well)
> - (Possibly) Introduce rev:non-backwards-compatible
>
> This would allow 6991bis to update date-and-time to follow the updated
> semantics for RFC3339 timestamps (which imo is the only reasonable
> thing to do - the consuequences of this change is handled by SEDATE).
>
>
>
>
>
> The important thing in each case is to consider
>
> the expected impact on the real world and real deployments.
>
>
>
> IMO a bugfix should be OK, even if the rules in RFC 7950 say it is an NBC
> change.
>
> But this is not the same thing as changing the rules in a new document to
> shift the
>
> implementation burden to the client.
>
>
>
> This is only an IETF issue and the burden should be on a WG to convince
> the IESG and IETF
>
> that making the NBC change is a bugfix and should be allowed as a special
> case.
>
>
>
>
>
>
> /martin
>
>
>
> Andy
>
>
>
>
> "Jason Sterne (Nokia)" <jason.ste...@nokia.com> wrote:
> > Hi all,
> >
> > At the request of the NETMOD chairs, and on behalf of the YANG
> Versioning weekly call group, here's a summary of Key Issue #1 for the
> versioning work (i.e. for the Module Versioning and YANG Semver WGLC).
> >
> > We'd like to suggest that the WG has a strong focus on deciding on this
> specific issue first. Then we'll move on to tackle other key issues. The
> idea is to try and avoid getting tangled in a web of multiple intertwined
> issues.
> >
> > Key Issue #1 is the following: Allow NBC changes in YANG 1.0 & YANG 1.1
> or not?
> >
> > For now please avoid debating other issues in this thread (e.g. multiple
> vs single label schemes, whether YANG semver is a good scheme, etc). Let's
> focus on K1 and work towards a WG decision.
> >
> > ###################################
> > K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not?
> >
> > Option 1 - Update RFC7950 to Allow NBC Changes
> > -----------------------------------------------------------------------
> > - Module Versioning modifies 7950 to allow NBC changes
> > - guidance that NBC changes SHOULD NOT be done (impact to user base)
> > - rev:non-backwards-compatible is a YANG extension
> > - introduction in published YANG does not impact current tooling
> (ignored until recognized)
> > PROS:
> > - address fundamental requirement of this versioning work (requirements
> doc)
> > - allows gradual adoption in the industry. YANG authors can immeditately
> start publishing with the new extensions.
> > - move faster to produce modules in the IETF (accept some
> errors/iteration)
> > - address the liaison from external standards bodies in a reasonable
> timeframe
> > - authors believe work is ready
> > - broad vendor support
> > - rough alignment with OpenConfig (use YANG 1.0 + OC Semver)
> > CONS:
> > - perception that we're "cheating" by not bumping our own spec's version
> > - Not fundamentally mandatory for clients or servers using YANG
> (mandatory for YANG claiming conformance to Module Versioning).
> >
> > Option 2 - RFC7950-bis: Publish a new version of the YANG language to
> allow NBC changes
> > -----------------------------------------------------------------------
> > - NBC changes only allowed in a new (future) version of YANG
> > - TBD: YANG 1.2 vs 2.0 (note YANG 1.1 isn't BC with YANG 1.0)
> > - Content = Module Versioning + YANG Semver + very limited YANG NEXT
> items
> > - rev:non-backwards-compatible tag is a language keyword
> > - consequence: any use of it breaks all YANG 1.0/1.1 tooling that
> hasn't been updated
> > - TBD how to handle small NBC changes in IETF in the short term (i.e.
> non conformance to 7950)?
> > - RFC6991 bis - change the use/meaning of ip-address (or change
> datetime)
> > - YANG date-and-time (because of SEDATE date string
> changes)
> >
> > PROS:
> > - address fundamental requirement of this versioning work (requirements
> doc)
> > - clear delineation of changes in the YANG language
> > - consistent with philosophy that version number changes for significant
> changes in a spec (avoids concern that YANG is changing without bumping the
> version of YANG)
> > - can do this with mandatory YANG keywords which helps increase
> conformance to the new rules
> > CONS:
> > - difficult to roll out in the industry. Tools need upgrading before
> they won't error on a YANG 1.2 module.
> > - Authors can't publish YANG 1.2 until their users have upgraded their
> tools. Everyone has to move at once.
> > - likely large delay in producing the work (unclear what would go into
> YANG 1.2, may not reach concensus easily on N items)
> > - delay in follow up work (Packages, Schema Comparison, Version
> Selection)
> > - continue dominating WG effort for longer (opportunity cost)
> >
> > Option 3 - Strict Adherence to Current RFC7950 Rules
> > -----------------------------------------------------------------------
> > - IESG will be unable to approve any RFCs that make any changes to IETF
> YANG modules that don't strictly conform to those rules
> > - RFC6991 bis would not be allowed to change the use/meaning of
> ip-address (or change datetime)
> > - YANG date-and-time couldn't change (related to SEDATE
> date string changes)
> > PROS:
> > - clear rules for entire industry including IETF
> > CONS:
> > - doesn't address agreed/adopted requirements of YANG versioning work
> > - incorrect assumption in tool chains, etc that NBC changes don't
> happen. Silent failures.
> >
> > Jason (he/him)
> >
>
> _______________________________________________
> 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
