On 30/05/2023 17.23, Jason Sterne (Nokia) wrote:
(changing subject for a dedicated thread on the filename)What the draft was mainly trying to achieve (IMO) wrt filename was to have a standard format/separator (#) when using a revision-label.i.e. **if** anyone is to use a revision-label, then it should be done with <module-name>#<revision-label>.yang.(and some users will indeed like to manage module versions using revision labels instead of dates – probably most over the long term)I’m not sure that {date, label} is a required tuple to identify a version of a module. I see the “keys” more as {module-name, label} OR {module-name,date}.
And therein lies a bit of the problem :)As it currently stands, https://datatracker.ietf.org/doc/html/rfc7950#section-5.2 provides a SHOULD -- and this draft updates it with an incompatible RECOMMENDED.
The incompatibility stems from the amount of available metadata, which tools based on filesystem storage can glean from the file name:
- RFC7950 makes metadata available for efficient lookup by revision- draft-ietf-netmod-yang-module-versioning makes metadata available for efficient lookup by label
The obvious problem for tools is that they need to support both concurrently -- and the question then becomes: which of the two should be used? :)
I think symlinks would be a good answer, in the way it's done in https://github.com/YangModels/yang/tree/main/standard/ietf/RFC:
- f...@date.yang is the actual file - foo.yang is the symlink to the latest versionPerhaps the draft should define the module#label.yang as a secondary name, recommending tools make both mod...@data.yang and module#label.yang available?
(where {module-name, label} could theoretically allow multiple revisions in a single day, although for now we haven’t changed the 7950 requirement that every module has a unique date)
Actually that requirement has already been relaxed, i.e. you can have multiple revisions of any module which (after applying conformance) only defines typedefs/groupings for the purposes of using those in another module.
This includes ietf-inet-types.yang (obviously), but also ietf-keystore.yang when the server does not advertize central-keystore-supported feature.
RFC7895 section 2.1.2 already allows for that, RFC8525's "import-only-module" list makes it explicit.
Regards, Robert
Jason *From:*netmod <netmod-boun...@ietf.org> *On Behalf Of *Andy Bierman *Sent:* Wednesday, May 24, 2023 8:29 PM *To:* Robert Varga <n...@hq.sk> *Cc:* netmod@ietf.org*Subject:* Re: [netmod] Joint WGLC on "semver" and "module-versioning" drafts*CAUTION:*This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.On Tue, May 16, 2023 at 11:10 AM Robert Varga <n...@hq.sk <mailto:n...@hq.sk>> wrote:On 09/05/2023 00.49, Kent Watsen wrote: > Dear NETMOD WG, > > This message begins a joint two-week WGLC for draft-ietf-netmod-yang-semver-11 and draft-ietf-netmod-yang-module-versioning-09> ending on Monday, May 22nd. Neither draft has IPR declared. Here are the direct links to the HTML version for these drafts:> > - https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-11 <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-11> > - https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09 <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09> > > Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome! This is useful and important, even from authors. Objections, concerns, and suggestions are also welcomed at this time. Hello, I have reviewed the module-versioning draft and overall it looks fine (well, aside from the incoming pain :), but we'll cope with that in due time). One concern I have is with https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09#name-file-names <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-09#name-file-names>, which changes file naming. Previously the canonical file name included revision -- and now that information is lost. While I understand the desire for descriptive names, which are a boon for humans, the until the entire ecosystem adopts labels, this change is either-or -- and hence tools have to pick which metadata is more important: label or revision. Would it be possible to define a format which contains *both* the label and revision, so as not to pick favorites? This is an example of an important detail that could be solved differentlyif a new YANG language version was used. In YANG 1.1 the revision-date is optional.In YANG 1.2, both the revision-date and label could be mandatory. It is common practice to release YANG changes in multiple release trainson the same day. So the {date, label} is the unique identifier for the YANG file,not some combination of optional parts. IMO the file name you suggest shouldbe the mandatory-to-implement canonical file name format for YANG 1.2.*/[>>JTS:] /*…snipped out the comments on doing this work in YANG 1.0/1.1 vs another version of YANG…Thanks, Robert Andy _______________________________________________ netmod mailing list netmod@ietf.org <mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
