On Mon, Jul 24, 2023 at 4:41 PM Christian Hopps <cho...@chopps.org> wrote:
> > Balázs Lengyel <balazs.lengyel=40ericsson....@dmarc.ietf.org> writes: > > > Hello Andy, > > > > I assume you are referring to the sentence “A new module revision MAY > > contain NBC changes” from the versioning draft. > > > > IMHO the authors agree that NBC changes are bad. They should be > > allowed but discouraged. > > That's what "SHOULD NOT" means. > > Indeed. https://datatracker.ietf.org/doc/html/rfc2119 It is clear that 'SHOULD NOT' is the correct term and 'MAY' does not even apply here. > Would a sentence like > > > > “A new module revision MAY but SHOULD NOT contain NBC changes … ” > > > > be OK ? > > > > I think the MAY part is also needed< because that is what we are > > introducing as new compared to 7950. > > IMO using both MAY and SHOULD NOT is confusing and unnecessary. "SHOULD > NOT" allows a thing while discouraging it. > > Thanks, > Chris. > > Andy > > > > be agreeable? > > > > Regards Balazs > > > > > > > > From: Andy Bierman <a...@yumaworks.com> > > Sent: Sunday, 23 July, 2023 17:26 > > To: Balázs Lengyel <balazs.leng...@ericsson.com> > > Cc: Martin Björklund <mbj+i...@4668.se>; netmod@ietf.org > > Subject: Re: [netmod] YANG Versioning: Key Issue #1 - Allow NBC > > changes in YANG 1.0 & YANG 1.1 or not? > > > > > > > > > > > > > > > > On Sun, Jul 23, 2023 at 5:08 PM Balázs Lengyel < > > balazs.leng...@ericsson.com> wrote: > > > > Hello Andy, > > > > In 3GPP we have endless debates about what is a bugfix. If the > > functionality will not work it is a bugfix. If it works in a bad > > way it is or maybe not a bugfix. If it works just in an ugly way > > is it a bugfix? > > > > Conclusion: it is not possible to define clear criteria about > > what is a bug and what is an improvement. > > > > > > > > > > > > It is easy to change MAY to SHOULD NOT in the versioning draft. > > > > > > > > IMO changing MUST NOT to MAY is unacceptable. > > > > The versioning draft is attempting to completely toss out all of the > > YANG update rules. > > > > Changing the normative text to SHOULD NOT instead of MAY does not > > require any specification of a bugfix. > > > > > > > > > > > > Regards Balazs > > > > > > > > > > > > Andy > > > > > > > > > > > > From: netmod <netmod-boun...@ietf.org> On Behalf Of Andy Bierman > > Sent: Wednesday, 19 July, 2023 10:13 > > To: Martin Björklund <mbj+i...@4668.se> > > 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 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 > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
