Subject: [netconf] [Technical Errata Reported] RFC8525 (6484)

From: RFC Errata System <[email-masked]>
Date: Mon, 15 Mar 2021 02:04:02 -0700 (PDT)

The following errata report has been submitted for RFC8525,
"YANG Library".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6484

--------------------------------------
Type: Technical
Reported by: Jernej Tuljak <[email-masked]>

Section: 4

Original Text
-------------
     revision 2016-04-09 {
       description
         "Initial revision.";
       reference
         "RFC 7895: YANG Module Library";
     }

Corrected Text
--------------
     revision 2016-06-21 {
       description
         "Initial revision.";
       reference
         "RFC 7895: YANG Module Library";
     }

Notes
-----
Initial revision of ietf-yang-library YANG module was 2016-06-21, not 2016-04-09.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC8525 (draft-ietf-netconf-rfc7895bis-07)
--------------------------------------
Title               : YANG Library
Publication Date    : March 2019
Author(s)           : A. Bierman, M. Bjorklund, J. Schoenwaelder, K. Watsen, R. Wilton
Category            : PROPOSED STANDARD
Source              : Network Configuration
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

---

From: Martin Björklund <[email-masked]>
Date: Mon, 15 Mar 2021 10:24:11 +0100 (CET)

Hi,

Wow, this is obviously a bug.

I am not sure it can be fixed with an errata however.  Perhaps "hold
for document update"?

/martin

RFC Errata System <[email-masked]> wrote:
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 15 Mar 2021 09:37:36 +0000

Hi Martin,

I agree, hold for doc update seems appropriate.

Any other comments?

Regards,
Rob

> -----Original Message-----
> From: Martin Björklund <[email-masked]>
> Sent: 15 March 2021 09:24
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; j.schoenwaelder@jacobs-
> university.de; [email-masked]; Rob Wilton (rwilton)
> <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [netconf] [Technical Errata Reported] RFC8525 (6484)
> 
> Hi,
>

---

From: Jan Lindblad <[email-masked]>
Date: Mon, 15 Mar 2021 11:00:50 +0100

Rob, Martin,

Wouldn't changing the revision date be a massively non-backwards-compatible change?
Anyone might be importing this module by revision, and tools could be hardcoded towards the revision date, given that this is a pretty fundamental module.

What is the (technical) benefit of changing the date?

Best Regards,
/jan

---

From: Martin Björklund <[email-masked]>
Date: Mon, 15 Mar 2021 11:18:26 +0100 (CET)

> non-backwards-compatible change?

Note that this is in the revision history list.

> What is the (technical) benefit of changing the date?

The idea is that if we ever do a new version of this module, we fix
the revision history list in that new version.

/martin

---

From: Jan Lindblad <[email-masked]>
Date: Mon, 15 Mar 2021 11:32:28 +0100

Martin,

> Note that this is in the revision history list.

I understand. Do you consider changing the revision history a backwards compatible change that clients, servers and tools should reasonably be able to cope with?

> the revision history list in that new version.

Yes, the description of the idea was clear. I see some potential trouble doing this, and so far I haven't been able to think of any use case that would benefit from a change. Is there any?

Correct information is always nice, but changing module identification data also leads to confusion. I don't think we should change it unless someone can point to some benefits that outweigh the cost.

Best Regards,
/jan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 15 Mar 2021 11:42:50 +0100

For me, this is a bug fix that will help tools to find the correct
historic versions of the published YANG modules (if they want to do a
time travel into the module history). Note that the module with the
wrong date was never published, so we are not "changing module
identification data", this is really a simple straight forward bug fix
(if something like that exists in the IETF).

A more revelant question is whether we can build tooling to spot these
kind of errors in order to prevent them from happening again in the
future.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Martin Björklund <[email-masked]>
Date: Mon, 15 Mar 2021 11:46:30 +0100 (CET)

Jan Lindblad <[email-masked]> wrote:
> I understand. Do you consider changing the revision history a
> backwards compatible change that clients, servers and tools should
> reasonably be able to cope with?

Today we have:

  ietf-yang-library@2016-06-21:
     revision 2016-06-21 {
       description
         "Initial revision.";
     }

  ietf-yang-library@2019-01-04
     revision 2019-01-04 {
       description { ... }
     }
     revision 2016-04-09 {
       description
         "Initial revision.";
     }

I don't expect any tool to be able to cope with this in any meaningful
way.  The only reason we haven't seen this before is that tools don't
try to use "2016-04-09".

So yes, I think it is ok to do:

  ietf-yang-library@202X-XX-XX
     revision 202X-XX-XX {
       description { ... }
     }
     revision 2019-01-04 {
       description { ... }
     }
     revision 2016-06-21 {
       description
         "Initial revision.";
     }

(actually, not just "ok", but the right thing to do...)

/martin

> 
> >> Anyone might be importing this module by revision, and tools could be
> >> hardcoded towards the revision date, given that this is a pretty
> >> fundamental module.
> >> 
> Yes, the description of the idea was clear. I see some potential
> trouble doing this, and so far I haven't been able to think of any use
> case that would benefit from a change. Is there any?
> 
> Correct information is always nice, but changing module identification
> data also leads to confusion. I don't think we should change it unless
> someone can point to some benefits that outweigh the cost.
> 
> Best Regards,
> /jan
> 
> 
> >>> Hi Martin,
> >>>

---

From: Martin Björklund <[email-masked]>
Date: Mon, 15 Mar 2021 11:53:58 +0100 (CET)

> kind of errors in order to prevent them from happening again in the

I think that this would have to be somthing that integrates in the RFC
editor's current checking of YANG modules.  It is of course trivial to
check this provided that there exists a "repo" of published modules.
(and I *think* that the RFC editor actually has such a repo in the
form of a directory...)

/martin

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 15 Mar 2021 11:57:37 +0000

[Dropping the RFC editor for the moment]

Yes, I was basically thinking along the same lines as Martin.

I'm wondering whether we should consider doing an RFC8525-bis document with the specific aim of addressing this?

As an aside, this is also another example of why trying to version YANG modules via RFCs isn't necessary the ideal choice.  I.e., fixing that in a git repository of IETF YANG modules (although with the errata) would also seem like a pragmatic solution.

Regards,
Rob

> Sent: 15 March 2021 10:47
> To: [email-masked]
> Cc: Rob Wilton (rwilton) <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> > >>>>> Initial revision of ietf-yang-library YANG module was 2016-06-21,
> not
> > >>>> 2016-04-09.
> > >>>>>
> > >>>>> Instructions:
> > >>>>> -------------
> > >>>>> Author(s)           : A. Bierman, M. Bjorklund, J. Schoenwaelder,
> K.
> > >>>> Watsen, R. Wilton

---

From: Jernej Tuljak <[email-masked]>
Date: Mon, 15 Mar 2021 13:01:54 +0100

Hi,

> way.  The only reason we haven't seen this before is that tools don't

In this instance, the tool that tried to use "2016-04-09" was me, just 
to clear any potential doubts. Copied it verbatim from that revision 
history, then had tests inexplicably failing because of it.

> (actually, not just "ok", but the right thing to do...)

+1

Jernej

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 15 Mar 2021 13:02:59 +0100

> I'm wondering whether we should consider doing an RFC8525-bis document with the specific aim of addressing this?

This sounds like an overkill solution, an errata seems the way to
handle a little bug fix like this. I very doubt this affects many
implementations...

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 15 Mar 2021 09:16:40 -0700

On Mon, Mar 15, 2021 at 5:03 AM Juergen Schoenwaelder <
[email-masked]> wrote:

> > I'm wondering whether we should consider doing an RFC8525-bis document
> with the specific aim of addressing this?
> >
>

I strongly object to the introduction of YET ANOTHER module revision for
the YANG library,
just to fix something that has no impact on any real tools.  Only the first
revision-stmt actually
matters, and that is correct in this case.

This bug should be handled with a simple Errata correcting the revision
history.
The data string is clearly wrong and changing it has no impact at all on
modules that import ietf-yang-library.

/js

Andy

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 15 Mar 2021 16:34:56 +0000

I still think that “Hold for Document Update” is the right outcome for this errata.  I.e., this is a valid problem and should be fixed if a new version of the module is published.

But I’m opposed to using an errata to change a YANG module published in an RFC.  That would mean that there are now two revisions of the YANG module with the same date but different content.

Regards,
Rob

From: Andy Bierman <[email-masked]>
Sent: 15 March 2021 16:17
To: Juergen Schoenwaelder <[email-masked]>; Rob Wilton (rwilton) <[email-masked]>; Martin Björklund <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [netconf] [Technical Errata Reported] RFC8525 (6484)

On Mon, Mar 15, 2021 at 5:03 AM Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

I strongly object to the introduction of YET ANOTHER module revision for the YANG library,
just to fix something that has no impact on any real tools.  Only the first revision-stmt actually
matters, and that is correct in this case.

This bug should be handled with a simple Errata correcting the revision history.
The data string is clearly wrong and changing it has no impact at all on
modules that import ietf-yang-library.

/js

Andy

_______________________________________________
netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: Jan Lindblad <[email-masked]>
Date: Mon, 15 Mar 2021 17:53:52 +0100

Andy wrote:

> just to fix something that has no impact on any real tools. 

I don't strongly object to making changes in YANG Library, but I think any changes on this fundamental level need to have substantial technical merit to warrant the cost.

> Only the first revision-stmt actually matters, and that is correct in this case.

If the import-by-revision-or-derived YANG extension proposed by the versioning dt is approved and published as RFC, the revision history will start to play a role in the interpretation of module contents. That may actually be an argument for correcting or reconciling the misrepresented date in the module at next the YANG Library change.

> On 15 Mar 2021, at 17:34, Rob Wilton (rwilton) <[email-masked]> wrote:
> 

Now, that is a kind of change I would strongly object to.

/jan

> On Mon, Mar 15, 2021 at 5:03 AM Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]>> wrote:
> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/ <https://www.jacobs-university.de/>>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 15 Mar 2021 10:11:14 -0700

On Mon, Mar 15, 2021 at 9:34 AM Rob Wilton (rwilton) <[email-masked]>
wrote:

> I still think that “Hold for Document Update” is the right outcome for
> this errata.  I.e., this is a valid problem and should be fixed if a new
> version of the module is published.
>
>
>
> But I’m opposed to using an errata to change a YANG module published in an
> RFC.  That would mean that there are now two revisions of the YANG module
> with the same date but different content.
>
>
>

All Errata for YANG modules changes the YANG module.

I do not see why this needs to be held for update but that is OK.

Here is the text in the RFC

     revision 2019-01-04 {
       description
         "Added support for multiple datastores according to the
          Network Management Datastore Architecture (NMDA).";
       reference
         "RFC 8525 <https://tools.ietf.org/html/rfc8525>: YANG Library";
     }
     revision 2016-04-09 {
       description
         "Initial revision.";
       reference
         "RFC 7895 <https://tools.ietf.org/html/rfc7895>: YANG Module Library";
     }

The revision date of the 2nd entry is wrong.
This is not a valid revision that needs to be preserved in the future.
I do not see what real tools break if the date of a previous revision is
wrong.
It seems like we would have noticed before 2+ years if this broke real
tools.

Why would changing the 2016 date be an NBC change?
There is no machine usage of revision-stmt 2 - N in YANG whatsoever.

Andy

> Regards,
>
> Rob
>
>
>
>
>
> *From:* Andy Bierman <[email-masked]>
> *Sent:* 15 March 2021 16:17
> *To:* Juergen Schoenwaelder <[email-masked]>; Rob
> Wilton (rwilton) <[email-masked]>; Martin Björklund <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked]
> *Subject:* Re: [netconf] [Technical Errata Reported] RFC8525 (6484)
>
>
>
>
>
>
>