On 24/03/2017 17:07, Andy Bierman wrote:
On Fri, Mar 24, 2017 at 6:44 AM, Martin Bjorklund <[email protected]
<mailto:[email protected]>> wrote:
Robert Wilton <[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
