Re: [netmod] Poll on YANG Versioning NBC Approach

2023-10-02 Thread Lou Berger
WG, Based on the very good discussion on list and the opinions recorded on the poll, the Chairs want to state that the WG has agreed to: "OPTION 1. Publish an RFC based on draft-ietf-netmod-yang-module-versioning that updates both YANG 1.0 (RFC 6020) and YANG 1.1 (RFC 7950) to allow YANG mod

Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)

2023-10-02 Thread Jason Sterne (Nokia)
Mandatory to be used by module authors. Tools can ignore them as you say. > -Original Message- > From: Jürgen Schönwälder > Sent: Monday, October 2, 2023 12:07 PM > To: Jason Sterne (Nokia) > Cc: Jan Lindblad (jlindbla) ; Kent Watsen > ; netmod@ietf.org > Subject: Re: [netmod] YANG Ver

Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)

2023-10-02 Thread Jürgen Schönwälder
RFC 7950 is clear that extensions must be designed such that they can be ignored by YANG parsers and tools. If you use 'mandatory, are you talking about 'mandatory' in an RFC 8407 sense (and not in an YANG language sense)? The difference here is between 'mandatory to use by module authors' versus

Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)

2023-10-02 Thread Jason Sterne (Nokia)
Hi guys, I think we'll need to be concrete about exactly which parts/extensions in Module Versioning we're talking about. And it will likely be a slightly different debate/discussion for each one. I think the top level rev:non-backwards-compatible extension (and it being mandatory) is importan

Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)

2023-10-02 Thread Sergio Belotti (Nokia)
+1 "Back to the minimal draft concept: I think opening up NBC changes as allowed (as "SHOULD NOT") without also trying in the rev:non-backwards-compatible marker as mandatory in the same draft would be a mistake and not move us forward. An important part of the versioning work is to bring expli

Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)

2023-10-02 Thread Jürgen Schönwälder
Jan, I am certainly not against documenting NBC changes. This can be done using extension statements. Whether such extensions are defined in the same document or not at the end is a procedural question. That said, any extensions that go beyond something that can be safely ignored (e.g., extension

Re: [netmod] [Editorial Errata Reported] RFC6991 (7647)

2023-10-02 Thread Jürgen Schönwälder
On Mon, Oct 02, 2023 at 02:20:04PM +, Rob Wilton (rwilton) wrote: > > Hence my proposal is to reject this erratum, but perhaps Jürgen you can > update your copy of rfc-6991bis to make these consistent please? And yes, I > appreciate that I need to finish processing my AD review of your doc.

Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)

2023-10-02 Thread Joe Clarke (jclarke)
I was going to say something similar. We agreed on a set of requirements ahead of the module versioning and other work that included a mechanism that would indicate that an NBC change had been made. Simply allowing them without it would more chaotic to consumers. Joe From: netmod on behalf

[netmod] [Errata Held for Document Update] RFC7317 (6245)

2023-10-02 Thread RFC Errata System
The following errata report has been held for document update for RFC7317, "A YANG Data Model for System Management". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6245 -- Status: Held for

Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)

2023-10-02 Thread Jan Lindblad (jlindbla)
Jürgen, WG, I agree that a document that updates 7950 would be the preferred solution here, rather than a bis or errata. I'm quite attracted, however, by the idea to bundle the softening of 7950 with the requirement to document any incompatibilities introduced. This way, we get something usefu

[netmod] [Errata Verified] RFC7951 (7020)

2023-10-02 Thread RFC Errata System
The following errata report has been verified for RFC7951, "JSON Encoding of Data Modeled with YANG". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7020 -- Status: Verified Type: Technical

Re: [netmod] [Editorial Errata Reported] RFC6991 (7647)

2023-10-02 Thread Rob Wilton (rwilton)
Hi, Looking at this erratum, I agree that it would be better that the module prefix is used consistently for references to other types within the same module, but the existing YANG is not wrong. In YANG, I generally expect prefixes are used when referencing data nodes or types in other importe

Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)

2023-10-02 Thread Reshad Rahman
+1 Jason. From an IETF process pov, yes the most expedient thing to do is to replace MUST with SHOULD. While this may be good for the IETF, it makes things worse for consumers/clients of YANG models: it'd allow NBC changes without any indication that NBC changes have been made! Regards,Reshad.

Re: [netmod] YANG Versioning: discussion around 7950 bis or errata (from Key Issue #1)

2023-10-02 Thread Jason Sterne (Nokia)
Hi Jurgen & WG, One thing that's clear to me: although the Key Issue #1 poll seems clear that we don't need YANG 1.2 to continue this versioning work (subject to confirmation from the chairs), more discussion is needed on the content of "the first YANG Versioning RFC" that we want to publish (i

[netmod] I-D Action: draft-ietf-netmod-yang-semver-12.txt

2023-10-02 Thread internet-drafts
Internet-Draft draft-ietf-netmod-yang-semver-12.txt is now available. It is a work item of the Network Modeling (NETMOD) WG of the IETF. Title: YANG Semantic Versioning Authors: Joe Clarke Robert Wilton Reshad Rahman Balazs Lengyel Jason Ster