----- Original Message ----- From: "Andy Bierman" <a...@yumaworks.com> Sent: Friday, March 24, 2017 6:07 PM
> 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 ;-) 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 > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
