Re: [netmod] Updated Content of Module Versioning - T8 (recommended-min for imports)

On Wed, Oct 25, 2023 at 12:03 PM Joe Clarke (jclarke) wrote: > This is the reason that, for me, I’d want the extension to be outside the > description in something that is machine-readable. Tools that do > understand this extension could make a better decision about which module > revision to

Re: [netmod] Updated Content of Module Versioning - T7 (Filename changes)

On Wed, Oct 25, 2023 at 11:49 AM Jürgen Schönwälder wrote: > I strongly disagree. You can add additional file names, you can't > soften the existing SHOULD to a conditional SHOULD. > > +1 Getting tools to handle the file naming patterns defined in RFC 7950 took a long time. It would be

Re: [netmod] Updated Content of Module Versioning - T8 (recommended-min for imports)

This is the reason that, for me, I’d want the extension to be outside the description in something that is machine-readable. Tools that do understand this extension could make a better decision about which module revision to use. Tools that do not understand the extension will resolve the

Re: [netmod] Updated Content of Module Versioning - T8 (recommended-min for imports)

See draft-schoenw-netmod-yang-relaxed-versioning-00.txt. A proper solution without bumping the YANG version number is impossible. If the YANG version number can't be touched, then all you can do is to document the NBC changes - and wait for a YANG next project to fix the rest. /js On Wed, Oct

Re: [netmod] Updated Content of Module Versioning - T8 (recommended-min for imports)

Can you clarify what you'd recommend then if we don't have it? For example: - IETF module A needs to import ietf-yang-types to use hex-string (only added in the 2013-07-15 version) Use import but without a revision substatement? (i.e. avoid import by specific revision)? Add something to the

Re: [netmod] Updated Content of Module Versioning - T7 (Filename changes)

I strongly disagree. You can add additional file names, you can't soften the existing SHOULD to a conditional SHOULD. /js On Wed, Oct 25, 2023 at 06:45:31PM +, Jason Sterne (Nokia) wrote: > Sure - I'd be OK with adding some wording here that makes it clear the 7950 > recommendation remains.

Re: [netmod] Updated Content of Module Versioning - T7 (Filename changes)

Sure - I'd be OK with adding some wording here that makes it clear the 7950 recommendation remains. i.e. you SHOULD use my-module@2023-01-06 as per 7950, but if you elect to not use that format, and want to use a label in the filename, then this format is RECOMMENDED: my-module#3.0.2.yang. I

Re: [netmod] Updated Content of Module Versioning - T8 (recommended-min for imports)

I am strongly against this. The import statement is used by tools. Adding a recommendation for humans that existing and conforming tools will not understand just causes confusion. /js On Wed, Oct 25, 2023 at 06:41:19PM +, Jason Sterne (Nokia) wrote: > Hi all, > > Starting a dedicated thread

[netmod] Updated Content of Module Versioning - T8 (recommended-min for imports)

Hi all, Starting a dedicated thread for T8 recommended-min for imports These are my own personal opinions (not those of the authors/contributors). It has been discussed before that import by a specific revision is somewhat broken (not recommended). It is mentioned in section 2.5 of the

Re: [netmod] Updated Content of Module Versioning - T7 (Filename changes)

It needs to be clear that the existing text in section 5.2 remains untouched. YANG modules and submodules are typically stored in files, one "module" or "submodule" statement per file. The name of the file SHOULD be of the form: module-or-submodule-name ['@' revision-date] (

[netmod] Updated Content of Module Versioning - T7 (Filename changes)

Hi all, Starting a dedicated thread for T7 Filename changes. These are my own personal opinions (not those of the authors/contributors). RFC7950 says that the filename format SHOULD be my-mod...@2023-01-06.yang Module versioning currently says the following