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

On Fri, Mar 24, 2017 at 6:44 AM, Martin Bjorklund <mbj@tail-f.com> wrote:

> Robert Wilton <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)

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

> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>