Subject: [netmod] <CODE BEGINS> file "[email-masked]" or <CODE BEGINS> file "ietf-foo.yang"

From: Benoit Claise <[email-masked]>
Date: Thu, 23 Mar 2017 18:33:20 -0500

Dear all,

[Preparing the IETF hackathon]

https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis#section-4.2
What is the guideline regarding:
     <CODE BEGINS> file "[email-masked]"
     versus
     <CODE BEGINS> file "ietf-foo.yang"

Right now, we have a mix of behaviors.
This implies that the extracted YANG modules sometimes contains the 
revision, but not always.

Regards, Benoit

---

From: Kent Watsen <[email-masked]>
Date: Fri, 24 Mar 2017 01:32:54 +0000

Hi Benoit,

Section 4.2 of rfc6187bis says:

   The "<CODE BEGINS>" tag SHOULD be followed by a string 
   identifying the file name specified in Section 5.2 of 
   [RFC7950].

While Section 5.2 of RFC7950 says:

   The name of the file SHOULD be of the form:

     module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' )

   "module-or-submodule-name" is the name of the module or 
   submodule, and the optional "revision-date" is the latest
   revision of the module or submodule, as defined by the
   "revision" statement (Section 7.1.9).

While the SHOULD statements provide a recommendation, the
square-brackets "[]" impart no bias, and the text is ambiguous.
That is, is the revision-date optional *only* because the 
revision statement is optional within the module?  What is 
the recommendation for when the revision statement is present?
The RFC7950 text isn't clear.

My opinion is that RFC7950 errata should state that the file 
name SHOULD include the revision-date when the revision 
statement appears within the module.

Kent // contributor

-----ORIGINAL MESSAGE-----

Dear all,

Regards, Benoit

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Benoit Claise <[email-masked]>
Date: Fri, 24 Mar 2017 09:09:50 +0100

> statement appears within the module.
That makes sense.
Any other views?

Regards, Benoit

---

From: Robert Wilton <[email-masked]>
Date: Fri, 24 Mar 2017 13:40:00 +0000

>> statement appears within the module.

I don't feel strongly, but would it make more sense if instead 
rfc6187bis stated that the file name SHOULD include the revision date?  
I.e. 7950 states what the filename is allowed to look like and 6187bis 
states what they should look like for IETF produced models.

Thanks,
Rob

> .

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 24 Mar 2017 14:44:08 +0100 (CET)

> states what they should look like for IETF produced models.

+1

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 24 Mar 2017 10:07:13 -0700

> > states what they should look like for IETF produced models.

This is fine, but this there is a larger goal of library consistency that is
impacted by this guideline. (such as the github/YangModels/yang repo.

1) changing the filename for each revision is not git-friendly
(if one wants to track changes over releases)

2) many revisions are actually obsolete work-in-progress
so keeping every old file around will grow into a problem

3) almost every import is import-without-revision so compiling the
old obsolete modules quickly breaks as the new work-in-progress version
makes incompatible changes.

However, import-by-revision breaks if you only keep the latest revision
around,
so these problems have to be managed by the YANG librarians ;-)

> /martin
Andy

---

From: t.petch <[email-masked]>
Date: Fri, 24 Mar 2017 17:22:35 +0000

----- Original Message -----
From: "Martin Bjorklund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, March 24, 2017 1:44 PM

> > states what they should look like for IETF produced models.

Yes, and I would also like RFC6087bis to require the date on the file
statement, if present, to match that on the revision statement - I have
seen several I-D where this has not been the case.  Something a tool
could check.

Should the date be the most recent revision statement?  I cannot see why
not.

Will there always be a revision statement?  RFC7950 says SHOULD,
cardinality 0..n so not always.

Tom Petch

---

From: Robert Wilton <[email-masked]>
Date: Fri, 24 Mar 2017 18:35:48 +0000

On 24/03/2017 17:07, Andy Bierman wrote:
>
>
> On Fri, Mar 24, 2017 at 6:44 AM, Martin Bjorklund <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Robert Wilton <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     >
Perhaps this is a difference between a development version (maybe being 
worked on in a separate directory in git) vs a published version, and by 
published I mean any draft revision.

> so keeping every old file around will grow into a problem
For the YANG models in RFCs, I guess that they are effectively published 
forever in github.
But for drafts, I think that they can could be removed from github at 
the point that there is no other current draft that references them, 
which should be scriptable.

> makes incompatible changes.
Yes.

Perhaps YANG is missing an "import with revision X or greater" (given 
that revisions are expected to be backwards compatible)?

>
> However, import-by-revision breaks if you only keep the latest 
> revision around,
I agree.

>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/netmod>
>
>

---

From: t.petch <[email-masked]>
Date: Sun, 26 Mar 2017 10:30:23 +0100

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
Sent: Friday, March 24, 2017 6:07 PM

> > > >>       module-or-submodule-name ['@' revision-date] ( '.yang' /
'.yin'
> > )
revision
> so these problems have to be managed by the YANG librarians ;-)

So a single revision level is too crude (for at least some of these
issues) and we need a major/minor release identifier, the minor being
updated with each version of a draft, the major being constant from the
time of  the first draft-ngt-xxxbis to its publication as an RFC.

Tom Petch

> Andy

------------------------------------------------------------------------
--------

---

From: t.petch <[email-masked]>
Date: Tue, 28 Mar 2017 13:04:12 +0100

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
Sent: Friday, March 24, 2017 6:07 PM
'.yin'

Andy

In a quick trawl of 277 recently published IETF I-Ds with YANG modules
in them, I found 16 using import with revision.  Almost every?  Well,
nearly all.

Tom Petch

revision