Subject: [netmod] Are multiple revisions with the same date allowed?

From: Robert Wilton <[email-masked]>
Date: Mon, 30 Jan 2017 11:50:20 +0000

RFC 7950 doesn't state that the date associated with revision statements 
in a YANG module must be unique.

Hence, I presume that it is intentionally allowed to have multiple 
revision statements with the same date.  E.g. the following module is 
allowed (and passes pyang --lint):

module rev-example {
   namespace
     "urn:example";

   prefix ex;

   organization "";

   contact "";

   description "'";
   reference "IEEE 802.3-2015, unless dated explicitly";

   revision 2017-01-30 {
     description
       "A revision description";
     reference "";
   }

   revision 2017-01-30 {
     description
       "A different revision with the same date";
     reference "";
   }

}

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 30 Jan 2017 13:05:06 +0100

Rob,

since we are talking about _published_ modules, this is going to be
rare. Perhaps we could have allowed an optional time specification
here to handle this case (since multiple revisions with the same date
cause ambiguity) but then in most organizations this is unlikely to
happen (at least this is what we assumed).

/js

On Mon, Jan 30, 2017 at 11:50:20AM +0000, Robert Wilton wrote:
> RFC 7950 doesn't state that the date associated with revision statements in
> a YANG module must be unique.
> 
> Hence, I presume that it is intentionally allowed to have multiple revision
> statements with the same date.  E.g. the following module is allowed (and
> passes pyang --lint):
> 
> module rev-example {
>   namespace
>     "urn:example";
> 
>   prefix ex;
> 
>   organization "";
> 
>   contact "";
> 
>   description "'";
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

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

---

From: Robert Wilton <[email-masked]>
Date: Mon, 30 Jan 2017 12:20:48 +0000

Juergen,

Thanks.  This isn't something that we need - just something that I 
noticed when reading 7950.

I was more questioning whether it should be allowed, given that a 
(module name, revision date) pair should effectively uniquely identify a 
published module.  Conversely, having multiple revisions with the same 
date doesn't seem to cause any harm either - other than the ambiguity 
that you mention that module authors would be wise to avoid anyway.

Perhaps a statement could be added to 6087bis that revision dates for a 
module SHOULD be unique to avoid any potential ambiguity?

Rob

---

From: William Lupton <[email-masked]>
Date: Mon, 30 Jan 2017 12:50:36 +0000

RFC 7950 Section 7.1.9 says that “For every published editorial change, a new one SHOULD be added in front of the revisions sequence so that all revisions are in reverse chronological order.” So I think it probably SHOULD be an error if the revision dates aren’t monotonically decreasing (from top to bottom) but having two revisions with the same date doesn't seem to be ambiguous.

The practical issue, of course, is that per RFC 7950 Section 5.2, "The name of the file SHOULD be of the form: module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin’ )”, so if two revisions have the same revision date how are the files to be named?

Note that RFC 6087bis Section 5.8 says "However, whenever a new (i.e. changed) version is made available (e.g., via a new version of an Internet-Draft), the revision date of that new version MUST be updated to a date later than that of the previous version.” This is a requirement that revision dates in “available” versions are strictly increasing.

William

> On 30 Jan 2017, at 12:20, Robert Wilton <[email-masked]> wrote:
> 
> Juergen,
> 
> Thanks.  This isn't something that we need - just something that I noticed when reading 7950.
> 
> I was more questioning whether it should be allowed, given that a (module name, revision date) pair should effectively uniquely identify a published module.  Conversely, having multiple revisions with the same date doesn't seem to cause any harm either - other than the ambiguity that you mention that module authors would be wise to avoid anyway.
> 
> Perhaps a statement could be added to 6087bis that revision dates for a module SHOULD be unique to avoid any potential ambiguity?
> 
> Rob
> 
>