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.
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.
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
