Re: [netmod] <CODE BEGINS> file "ietf-foo@2016-03-20.yang" or <CODE BEGINS> file "ietf-foo.yang"

On 24/03/2017 17:07, Andy Bierman wrote:
>
>
> On Fri, Mar 24, 2017 at 6:44 AM, Martin Bjorklund <mbj@tail-f.com 
> <mailto:mbj@tail-f.com>> wrote:
>
>     Robert Wilton <rwilton@cisco.com <mailto:rwilton@cisco.com>> wrote:
>     >
>     >
>     > On 24/03/2017 08:09, Benoit Claise wrote:
>     > > On 3/24/2017 2:32 AM, Kent Watsen wrote:
>     > >> 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.
>     > > That makes sense.
>     > > Any other views?
>     >
>     > 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.
>
>     +1
>
>
> 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)
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.

>
> 2) many revisions are actually obsolete work-in-progress
> 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.

>
> 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.
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,
> so these problems have to be managed by the YANG librarians ;-)
I agree.

>
>
>
>
>     /martin
>
>
> Andy
>
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org <mailto:netmod@ietf.org>
>     https://www.ietf.org/mailman/listinfo/netmod
>     <https://www.ietf.org/mailman/listinfo/netmod>
>
>