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

----- Original Message -----
From: "Andy Bierman" <andy@yumaworks.com>
Sent: Friday, March 24, 2017 6:07 PM

> 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 ;-)

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

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

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

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