As a client (consumer of models), I do not want only the MUST -> SHOULD
change, IMO that would be worse than the current situation.
Regards,Reshad.
On Wednesday, September 27, 2023, 09:16:10 PM EDT, Kent Watsen
<[email protected]> wrote:
This was my thought as well, that it would be best to have the
smallest-possible draft update 6020/7950. That way, when someone follows the
“Updated” links, they’re not overloaded with material that could’ve been left
out.
Jason was saying that just doing MUST/SHOULD by alone isn’t great, that at
least the "rev:non-backwards-compatible” extension statement should be included
and, by extension I suppose, the rules for editing the revision history.
Presumably revision labels could be left out. IDK what minimal is possible.
K. // contributor
On Sep 27, 2023, at 7:06 PM, Rodney Cummings <[email protected]>
wrote:
It is easy to write a short RFC updating RFC 7950, changing one sentence from
MUST to SHOULD.
I agree. I found that I cannot enter a response to the poll, because I disagree
with both Option 1 and Option 2.
My concern is that there are many people out there who are implementing YANG,
but who do not follow discussions on this mailing list. I'm concerned that
there is a serious risk that those people will interpret the change from MUST
to SHOULD as "backward compatibility is irrelevant for YANG". We all know that
the concern is about bug fixes and so on, but without explaining that in a
short and focused manner (i.e., the short RFC described above), that will be
lost in the noise of the larger draft-ietf-netmod-yang-module-versioning change.
draft-ietf-netmod-yang-module-versioning is a great draft, but I think it
should move forward as an independent RFC, distinct from the MUST/SHOULD change.
Rodney Cummings
-----Original Message-----
From: netmod <[email protected]> On Behalf Of Jürgen Schönwälder
Sent: Tuesday, September 26, 2023 5:24 PM
To: Jason Sterne (Nokia) <[email protected]>
Cc: [email protected]
Subject: Re: [netmod] YANG Versioning: discussion around 7950 bis or errata
(from Key Issue #1)
It is easy to write a short RFC updating RFC 7950, changing one sentence from
MUST to SHOULD. This is inline with the goal to not change the language, i.e.,
to keep the version numbers.
/js
On Tue, Sep 26, 2023 at 03:00:19PM +0000, Jason Sterne (Nokia) wrote:
Hello NETMOD WG,
We've had a poll going for a few weeks to determine if we require YANG 1.2 for
allowing ("SHOULD NOT") NBC changes (see "Poll on YANG Versioning NBC
Approach").
As part of that, some discussion has happened on the list around
potentially doing an errata for RFC7950/6020 or a bis of 7950/6020 (if
rough consensus is reached for option 1 of the poll)
7-8 of us discussed this in the YANG Versioning weekly call group today.
First of all: this question of mechanics (errata vs bis vs Module Versioning
draft) is orthogonal to the poll. Let's first and separately resolve the poll
and confirm if we need YANG 1.2 or not (that's the fundamental question the
poll is resolving - everything else is a subsequent issue to be discussed).
We'll let the chairs confirm when/if rough consensus on the poll has been
reached.
But *if* the answer to the poll is option 1, then the weekly call group was
unanimous that we should not do an errata for RFC7950/6020 and we should not do
a 7950/6020 bis. We should just continue with the Module Versioning draft which
will update 7950 and 6020.
The primary reason is that we shouldn't just change MUST NOT to SHOULD NOT
without also tying it together with the mandatory top level
rev:non-backwards-compatible extension when an NBC change is done. Changing the
NBC rule to SHOULD NOT needs to be in the same RFC as the mandatory
rev:non-backwards-compatible tag.
Other reasons:
* an errata probably isn't correct since this isn't fixing an intent that
was present back when 7950 was written (it was clearly the intent at the time
to block NBC changes)
* a bis would be odd without actually introducing other changes to YANG and
changing the version (this discussion is all based on "if the answer to the
poll is option 1")
Jason (he/him)
_______________________________________________
netmod mailing list
[email protected]
https://www.i/
etf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C01%7C%7C22464d2aa09441
f1b1bd08dbbedf65ad%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638313
638956186415%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DgsZVlBTQtqJjR
tVXs%2Bze%2BrOanijgDEuCn93gbN9Jyw%3D&reserved=0
--
Jürgen Schönwälder Constructor University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://constructor.university/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
