On Fri, Mar 24, 2017 at 6:44 AM, Martin Bjorklund <m...@tail-f.com> wrote:
> Robert Wilton <rwil...@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 >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
