Re: [netmod] YANG filenames in module versioning

[Robert Varga <[e-mail]>]

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:
- [e-mail] is the actual file
- foo.yang is the symlink to the latest version

Perhaps the draft should define the module#label.yang as a secondary 
name, recommending tools make both [e-mail] 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 <[e-mail]> *On Behalf Of *Andy Bierman
> *Sent:* Wednesday, May 24, 2023 8:29 PM
> *To:* Robert Varga <[e-mail]>
> *Cc:* [e-mail]
> *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 <[e-mail] 
> <mailto:[e-mail]>> 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 differently
> 
> if 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 trains
> 
> on 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 
> should
> 
> be 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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/netmod
>     <https://www.ietf.org/mailman/listinfo/netmod>
>