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

[Jürgen Schönwälder]

If compilers can pick different revisions and this results in
different interpretations of YANG definitions then thigns are
broken.

/js

On Wed, Nov 15, 2023 at 10:30:49PM +, Jason Sterne (Nokia) wrote:
> Hi all,
> 
> A poll at IETF118 was roughly split on recommended-min.
> 
> We discussed this in the weekly YANG versioning call and feel we should:
> 1) keep recommended-min-date in the Module Versioning draft
> 2) add recommended-min-label (or similar name) in the YANG Semver draft.
> They would be mutually exclusive inside a single import statement.
> 
> As defined in Module Versioning, the recommended-min is informational only. 
> Compilers/tools are not required to use the recommended-min as a constraint.
> 
> We don't believe this causes any new incompatibility issues wrt RFC7950.
> 
> RFC7950 section 5.1.1 says the following:
> 
>If a module is not imported with a specific revision, it is undefined 
> which revision is used.
> 
> So clients, servers and tools can pick whatever revision they want. Two 
> different tools may pick different revisions.
> 
> In section 5.6.5 RFC7950 says the following:
> 
>If a server lists a module C in the "/modules-state/module" list from
>"ietf-yang-library" and there are other modules Ms listed that import
>C without specifying the revision date of module C, the server MUST
>use the definitions from the most recent revision of C listed for
>modules Ms.
> 
> Recommended-min does not affect conformance and is not mandatory. So a 
> server, toolchain, etc can continue to select the "most recent revision" even 
> if that revision is older than the recommended-min.
> 
> Jason
> 
> 
> > -Original Message-
> > From: Jürgen Schönwälder 
> > Sent: Thursday, October 26, 2023 4:23 AM
> > To: Andy Bierman 
> > Cc: Joe Clarke (jclarke) ; Jason Sterne
> > (Nokia) ; netmod@ietf.org
> > Subject: Re: [netmod] Updated Content of Module Versioning - T8
> > (recommended-min for imports)
> > 
> > 
> > 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.
> > 
> > 
> > 
> > Well, yes, import-by-revision is broken. However, changing the way how
> > imports work changes the YANG language. So it is important to know
> > which version of the YANG language tools implement. For this we have
> > language version numbers.
> > 
> > /js
> > 
> > On Wed, Oct 25, 2023 at 02:44:26PM -0700, Andy Bierman wrote:
> > > On Wed, Oct 25, 2023 at 12:03 PM Joe Clarke (jclarke)  > > 40cisco@dmarc.ietf.org> 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 use.
> > > >
> > > >
> > > >
> > >
> > > +1
> > >
> > > The YANG author should know if their module depends on imported 
> > > definitions
> > > from a specific revision.
> > > IMO the min-revision is needed in this case, and SHOULD be present.
> > > There is a big difference between "module will compile" and "module will
> > > work as intended".
> > >
> > > Tools that do not understand the extension will resolve the import as they
> > > > normally would, which may lead to a failure at compile time (e.g., for a
> > > > missing node).
> > > >
> > >
> > > This extension MUST be ignored if the 'revision-date' statement is present
> > > in the import-stmt.
> > >
> > >
> > > >
> > > > Joe
> > > >
> > >
> > > Andy
> > >
> > >
> > > >
> > > >
> > > > *From: *netmod  on behalf of Jürgen
> > Schönwälder
> > > > 
> > > > *Date: *Wednesday, October 25, 2023 at 14:45
> > > > *To: *Jason Sterne (Nokia) 
> > > > *Cc: *netmod@ietf.org 
> > > > *Subject: *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 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
> > > > versioning requirements draft:
> > > > 

[netmod] [IANA #1288604] Re: IANA YANG Parameters repository

[Amanda Baber via RT]

Hi Mahesh, Jernej, all,

We've repaired lines 191 and 213:

https://www.iana.org/assignments/yang-parameters

Thank you!

If any other issues come up, you can reach us at i...@iana.org, which is 
heavily monitored.

Best regards,

Amanda Baber
IANA Operations Manager

On Wed Nov 15 22:09:20 2023, mjethanand...@gmail.com wrote:
> iana-iss...@iana.org 
> 
> The issue is specific to line 191 and 213 of the module.
> 
> > On Nov 15, 2023, at 7:05 AM, Jernej Tuljak 
> > wrote:
> >
> > Hi,
> >
> > I detected a syntactically invalid YANG file among those available at
> > "https://www.iana.org/assignments/yang-parameters/yang-
> > parameters.xhtml".
> >
> > Does anyone know how to report this to them? Is
> > "https://www.iana.org/form/complaint; an appropriate channel for
> > something like this?
> >
> > The actual file is "https://www.iana.org/assignments/yang-
> > parameters/ietf-te-topology-st...@2020-08-06.yang". Whatever
> > extracted it from the RFC mishandled '<' and '>' characters and
> > replaced them with XML character entity references, including some
> > inside XPath expressions.
> >
> > Jernej
> >
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> 
> Mahesh Jethanandani
> mjethanand...@gmail.com

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Jason Sterne (Nokia)]

Hi all,

A poll at IETF118 was roughly split on recommended-min.

We discussed this in the weekly YANG versioning call and feel we should:
1) keep recommended-min-date in the Module Versioning draft
2) add recommended-min-label (or similar name) in the YANG Semver draft.
They would be mutually exclusive inside a single import statement.

As defined in Module Versioning, the recommended-min is informational only. 
Compilers/tools are not required to use the recommended-min as a constraint.

We don't believe this causes any new incompatibility issues wrt RFC7950.

RFC7950 section 5.1.1 says the following:

   If a module is not imported with a specific revision, it is undefined which 
revision is used.

So clients, servers and tools can pick whatever revision they want. Two 
different tools may pick different revisions.

In section 5.6.5 RFC7950 says the following:

   If a server lists a module C in the "/modules-state/module" list from
   "ietf-yang-library" and there are other modules Ms listed that import
   C without specifying the revision date of module C, the server MUST
   use the definitions from the most recent revision of C listed for
   modules Ms.

Recommended-min does not affect conformance and is not mandatory. So a server, 
toolchain, etc can continue to select the "most recent revision" even if that 
revision is older than the recommended-min.

Jason


> -Original Message-
> From: Jürgen Schönwälder 
> Sent: Thursday, October 26, 2023 4:23 AM
> To: Andy Bierman 
> Cc: Joe Clarke (jclarke) ; Jason Sterne
> (Nokia) ; netmod@ietf.org
> Subject: Re: [netmod] Updated Content of Module Versioning - T8
> (recommended-min for imports)
> 
> 
> 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.
> 
> 
> 
> Well, yes, import-by-revision is broken. However, changing the way how
> imports work changes the YANG language. So it is important to know
> which version of the YANG language tools implement. For this we have
> language version numbers.
> 
> /js
> 
> On Wed, Oct 25, 2023 at 02:44:26PM -0700, Andy Bierman wrote:
> > On Wed, Oct 25, 2023 at 12:03 PM Joe Clarke (jclarke)  > 40cisco@dmarc.ietf.org> 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 use.
> > >
> > >
> > >
> >
> > +1
> >
> > The YANG author should know if their module depends on imported definitions
> > from a specific revision.
> > IMO the min-revision is needed in this case, and SHOULD be present.
> > There is a big difference between "module will compile" and "module will
> > work as intended".
> >
> > Tools that do not understand the extension will resolve the import as they
> > > normally would, which may lead to a failure at compile time (e.g., for a
> > > missing node).
> > >
> >
> > This extension MUST be ignored if the 'revision-date' statement is present
> > in the import-stmt.
> >
> >
> > >
> > > Joe
> > >
> >
> > Andy
> >
> >
> > >
> > >
> > > *From: *netmod  on behalf of Jürgen
> Schönwälder
> > > 
> > > *Date: *Wednesday, October 25, 2023 at 14:45
> > > *To: *Jason Sterne (Nokia) 
> > > *Cc: *netmod@ietf.org 
> > > *Subject: *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 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
> > > versioning requirements draft:
> > > https://www.ietf.org/archive/id/draft-ietf-netmod-yang-versioning-reqs-
> 08.html#name-no-good-way-to-specify-whic
> > > >
> > > > Based on previous WG LC discussions, we already changed from a
> > > revision-or-derived extension (that did affect conformance & what a tool
> > > could/should use), to a weaker recommended-min in order to avoid further
> > > changes to the YANG language & conformance rules.  The recommended-min
> is
> > > pretty much purely a documentation tag that helps users of the modules
> > > understand what versions of imports might be best to use (e.g. when
> > > supporting multiple modules in a server, or constructing a "package" of
> > > modules that work together).
> > > >
> > > > We could instead just say to put this information into a description
> > > field in the module. 

Re: [netmod] IANA YANG Parameters repository

[Mahesh Jethanandani]

iana-iss...@iana.org 

The issue is specific to line 191 and 213 of the module.

> On Nov 15, 2023, at 7:05 AM, Jernej Tuljak  wrote:
> 
> Hi,
> 
> I detected a syntactically invalid YANG file among those available at 
> "https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml;.
> 
> Does anyone know how to report this to them? Is 
> "https://www.iana.org/form/complaint; an appropriate channel for something 
> like this?
> 
> The actual file is 
> "https://www.iana.org/assignments/yang-parameters/ietf-te-topology-st...@2020-08-06.yang;.
>  Whatever extracted it from the RFC mishandled '<' and '>' characters and 
> replaced them with XML character entity references, including some inside 
> XPath expressions.
> 
> Jernej
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


Mahesh Jethanandani
mjethanand...@gmail.com






___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Andy Bierman]

On Wed, Nov 15, 2023 at 1:35 PM Jason Sterne (Nokia) 
wrote:

> Hi all,
>
>
>
> We discussed this in the weekly YANG versioning call. There have been
> concerns expressed on the list about weakening the format specified as a
> SHOULD in RFC7950 and about the time it may take for the ecosystem of tools
> to be updated. There is not any clear consensus that we should keep the new
> label-based filename recommendation.
>
>
>
> So we’re proposing to remove this new filename convention from the Module
> Versioning draft. That means there would be no particular standardized way
> of putting a label (yang semver label) in the module filename. We’d stick
> with the RFC7950 my-mod...@2023-10-14.yang format for now (or of course
> the format without any label or date: my-module.yang).
>
>
>


thank you.
The recent simplifications in this work make it better (IMO).
Look forward to implementing the RFC.


> If anyone feels that you can’t live without the new filename format
> specified (e.g. my-mod...@3.0.1.yang) now is the time to speak up.
> Otherwise we’ll remove it from the next iteration of Module Versioning.
>
>
>
> Jason
>
>
Andy


>
>
> *From:* Andy Bierman 
> *Sent:* Wednesday, October 25, 2023 4:28 PM
> *To:* Jürgen Schönwälder ; Jason
> Sterne (Nokia) ; netmod@ietf.org
> *Subject:* Re: [netmod] Updated Content of Module Versioning - T7
> (Filename changes)
>
>
>
>
>
> *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 Wed, Oct 25, 2023 at 11:49 AM Jürgen Schönwälder <
> jschoenwaelder@constructor.university> 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 disruptive to introduce yet another file-naming pattern.
>
> It would also be another NBC change forced on YANG 1.1 tools.
>
>
>
>
>
> /js
>
>
>
> Andy
>
>
>
> 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.
> >
> > 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 can see that 'primary identifier' isn't great. Maybe something more
> like "to uniquely identify the version of the module" or similar.
> >
> > Jason
> >
> > > -Original Message-
> > > From: Jürgen Schönwälder 
> > > Sent: Wednesday, October 25, 2023 2:32 PM
> > > To: Jason Sterne (Nokia) 
> > > Cc: netmod@ietf.org
> > > Subject: Re: [netmod] Updated Content of Module Versioning - T7
> > > (Filename changes)
> > >
> > >
> > > 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.
> > >
> > >
> > >
> > > 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] ( '.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).
> > >
> > > Words like 'primary identifier' confuse me.
> > >
> > > /js
> > >
> > > On Wed, Oct 25, 2023 at 06:22:57PM +, Jason Sterne (Nokia) wrote:
> > > > 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-module@2023-01-
> > > 06.yang
> > > >
> > > > Module versioning currently says the following format is RECOMMENDED
> > > (if the file has a revision label):  my-module#3.1.2.yang
> > > >
> > > > I'd recommend we remove that from Module Versioning, but add it to
> the
> > > YANG Semver draft (where all revision label text will be located - it
> is all
> > > being removed from Module Versioning).
> > > >
> > > > We could potentially say it more like this:
> > > >
> > > >   If a revision has an associated yang-semver-label, and if the
> publisher
> > > >  wishes to use the label in the filename as the primary identifier
> for the
> > > >  version of the module instead of the revision date, then it is
> > > >   RECOMMENDED to put the yang-semver-label into the filename as
> > > follows:
> > > >
> > > >  module-or-submodule-name ['#' yang-semver-label] ( 

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

[Jason Sterne (Nokia)]

Hi all,

We discussed this in the weekly YANG versioning call. There have been concerns 
expressed on the list about weakening the format specified as a SHOULD in 
RFC7950 and about the time it may take for the ecosystem of tools to be 
updated. There is not any clear consensus that we should keep the new 
label-based filename recommendation.

So we’re proposing to remove this new filename convention from the Module 
Versioning draft. That means there would be no particular standardized way of 
putting a label (yang semver label) in the module filename. We’d stick with the 
RFC7950 my-mod...@2023-10-14.yang format for 
now (or of course the format without any label or date: my-module.yang).

If anyone feels that you can’t live without the new filename format specified 
(e.g. my-mod...@3.0.1.yang) now is the time to 
speak up. Otherwise we’ll remove it from the next iteration of Module 
Versioning.

Jason

From: Andy Bierman 
Sent: Wednesday, October 25, 2023 4:28 PM
To: Jürgen Schönwälder ; Jason Sterne 
(Nokia) ; netmod@ietf.org
Subject: Re: [netmod] Updated Content of Module Versioning - T7 (Filename 
changes)


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 Wed, Oct 25, 2023 at 11:49 AM Jürgen Schönwälder 
mailto:jschoenwaelder@constructor.university>>
 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 disruptive to introduce yet another file-naming pattern.
It would also be another NBC change forced on YANG 1.1 tools.


/js

Andy

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.
>
> 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 can see that 'primary identifier' isn't great. Maybe something more like 
> "to uniquely identify the version of the module" or similar.
>
> Jason
>
> > -Original Message-
> > From: Jürgen Schönwälder 
> > mailto:jschoenwaelder@constructor.university>>
> > Sent: Wednesday, October 25, 2023 2:32 PM
> > To: Jason Sterne (Nokia) 
> > mailto:jason.ste...@nokia.com>>
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] Updated Content of Module Versioning - T7
> > (Filename changes)
> >
> >
> > 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.
> >
> >
> >
> > 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] ( '.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).
> >
> > Words like 'primary identifier' confuse me.
> >
> > /js
> >
> > On Wed, Oct 25, 2023 at 06:22:57PM +, Jason Sterne (Nokia) wrote:
> > > 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-module@2023-01-
> > 06.yang>
> > >
> > > Module versioning currently says the following format is RECOMMENDED
> > (if the file has a revision label):  my-module#3.1.2.yang
> > >
> > > I'd recommend we remove that from Module Versioning, but add it to the
> > YANG Semver draft (where all revision label text will be located - it is all
> > being removed from Module Versioning).
> > >
> > > We could potentially say it more like this:
> > >
> > >   If a revision has an associated yang-semver-label, and if the publisher
> > >  wishes to use the label in the filename as the primary identifier for the
> > >  version of the module instead of the revision date, then it is
> > >   RECOMMENDED to put the yang-semver-label into the filename as
> > follows:
> > >
> > >  module-or-submodule-name ['#' yang-semver-label] ( '.yang' / '.yin' )
> > >
> > >E.g., acme-router-module#2.0.3.yang
> > >
> > >   YANG module (or submodule) files may be identified using either the
> > >   revision-date (as per [RFC8407] section 3.2) or the revision label.
> > 

[netmod] IANA YANG Parameters repository

[Jernej Tuljak]

Hi,

I detected a syntactically invalid YANG file among those available at 
"https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml;.


Does anyone know how to report this to them? Is 
"https://www.iana.org/form/complaint; an appropriate channel for 
something like this?


The actual file is 
"https://www.iana.org/assignments/yang-parameters/ietf-te-topology-st...@2020-08-06.yang;. 
Whatever extracted it from the RFC mishandled '<' and '>' characters and 
replaced them with XML character entity references, including some 
inside XPath expressions.


Jernej

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] A YANG model for Power Management

[Ron Bonica]

Folks,

Please review and comment on:

A YANG model for Power Management
draft-li-ivy-power-01

 Ron


Juniper Business Use Only
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod