Subject: Re: [netmod] Revision labels for submodules

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 8 May 2020 13:49:53 +0000

Hi,

This came up during this week's meeting. We briefly discussed whether there's a need to version sub-modules or can we restrict versioning to modules only. We would like to hear from the WG on this, especially those with experience managing sub-modules.

For completeness, below is an update from Jason in github:
My initial reaction is that we should not preclude the use of revision label with a submodule. Submodules have their own version today. The trick is to define (or explicitly say it is out of scope) whether a module version must change if any underlying submodule versions change. That gets difficult if you consider simply moving a leaf from one sub-module to another (without changing anything else about it - its context, etc).

Regards,
Reshad.

On 2020-03-27, 5:44 PM, "netmod on behalf of Reshad Rahman (rrahman)" <[email-masked] on behalf of rrahman=[email-masked]> wrote:

    Hi,
    
    https://github.com/netmod-wg/yang-ver-dt/issues/49
    
            o  3.3
            
                Submodules MUST NOT use revision label schemes that could be confused
                with the including module's revision label scheme.
            
              Hmm, how do I ensure that this MUST NOT is handled correctly?  What
              exactly does "could be confused with" mean?
    
    Good point. What was meant by that the label space for modules and sub-modules are orthogonal.  e.g. the sub-module and module both have the same label, it shouldn't be inferred that the 2 are related. 
    We'll change/clarify the text.
    
    Regards,
    Reshad.
    
    On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" <[email-masked] on behalf of rrahman=[email-masked]> wrote:
    
        Hi Martin,
        
        We've opened issues to track your review comments (see below). Will kick off separate therads for each issue.
        
        https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling
        
        Regards,
        Reshad.
        
        On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" <[email-masked] on behalf of [email-masked]> wrote:
        
            Hi,
            
            Here are my review comments of
            draft-verdt-netmod-yang-module-versioning-01.

            o  3.1.1
            
                o  In statements that have any data definition statements as
                   substatements, those data definition substatements MAY be
                   reordered, as long as they do not change the ordering or any "rpc"
                   "input" substatements.
            
              I think this needs to capture that no descendant statements to
              "input" can be reordered.  Same for "output" (note, "input" and
              "output" in both "rpc" and "action").

            o  3.3
            
                All revision labels that match the pattern for the "version"
                typedef in the ietf-yang-semver YANG module MUST be interpreted as
                YANG semantic version numbers.
            
              I don't think this is a good idea.  Seems like a layer violation.
              What if my project use another dialect of semver, that wouldn't be
              possible with this rule.  I think this needs to be removed.

            o  3.3
            
                Submodules MUST NOT use revision label schemes that could be confused
                with the including module's revision label scheme.
            
              Hmm, how do I ensure that this MUST NOT is handled correctly?  What
              exactly does "could be confused with" mean?

            o  3.3
            
                  In the filename of a YANG module, where it takes the form: module-
                  or-submodule-name ['@' revision-label] ( '.yang' / '.yin' )
            
              Should this section update 5.2 of RFC 7950?  I know that 5.2 just
              says "SHOULD".  But existing tools implement this SHOULD, and they
              need to be updated to handle this new convention.
            
              But I wonder if this a good idea.  It means that a tool that looks
              for a module with a certain revision date cannot simply check the
              filenames, but need to parse all available modules (wijust to find the 

            o  3.4
            
                 leaf imperial-temperature {
                   type int64;
                   units "degrees Fahrenheit";
                   status deprecated {
                     rev:status-description
                       "Imperial measurements are being phased out in favor
                        of their metric equivalents.  Use metric-temperature
                        instead.";
                   }
                   description
                     "Temperature in degrees Fahrenheit.";
                 }
            
              I don't think rev:status-description is necessary / worth it.  This
              can easily be written with the normal description statement instead:
            
                 leaf imperial-temperature {
                   type int64;
                   units "degrees Fahrenheit";
                   status deprecated;
                   description
                       "Imperial measurements are being phased out in favor
                        of their metric equivalents.  Use metric-temperature
                        instead.
            
                        Temperature in degrees Fahrenheit.";
                 }

            o  3.5
            
              The example modules should be legal YANG modules.  Use e.g. 
              "urn:example:module" as namespace.
            
              Also, the modules are missing the last "}", which confuses the
              "rfcstrip" tool.

            o 4.1.1
            
                Alternatively, the first example could have used the revision label
                "1.0.0" instead, which selects the same set of revisions/versions.
            
                import example-module {
                  rev:revision-or-derived 1.0.0;
                }
            
              Shouldn't this be s/1.0.0/2.0.0/g ?

            o  5
            
              I think the module name "ietf-yl-revisions" should be changed to
              "ietf-yang-library-revisions".   "yl" is not a well-known acronym.

            o  5.2.2
            
              Wouldn't it be better if the leaf "deprecated-nodes-implemented" and
              "obsolete-nodes-absent" were of type "boolean" rather than type
              "empty"?

            o  7.1
            
              The text says:
            
                All IETF YANG modules MUST include revision-label statements for all
                newly published YANG modules, and all newly published revisions of
                existing YANG modules.  The revision-label MUST take the form of a
                YANG semantic version number [I-D.verdt-netmod-yang-semver].
            
              I strongly disagree with this new rule.  IETF modules use a linear
              history, so there are no reasons to use "modified semver".
            
              It is ok to use rev:nbc-changes if needed, though.

            o 7.1.1
            
              There is a missing " in:
            
               4.  For status "obsolete", it is RECOMMENDED to keep the "status-
                   description" information, from when the node had status
                   "deprecated, which is still relevant.
             HERE  -----------^

            o  8
            
              s/CODE ENDS>/<CODE ENDS>/

            o Both YANG modules
            
              All extensions should specify the grammar; i.e., in which statements
              they can be present and which substatements they can have.

            /martin
            
            _______________________________________________
            netmod mailing list
            [email-masked]
            https://www.ietf.org/mailman/listinfo/netmod

        _______________________________________________
        netmod mailing list
        [email-masked]
        https://www.ietf.org/mailman/listinfo/netmod

    _______________________________________________
    netmod mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Björklund <[email-masked]>
Date: Fri, 08 May 2020 23:12:15 +0200 (CEST)

Hi,

"Reshad Rahman (rrahman)" <[email-masked]> wrote:
> Hi,
> 
> This came up during this week's meeting. We briefly discussed whether
> there's a need to version sub-modules or can we restrict versioning to
> modules only. We would like to hear from the WG on this, especially
> those with experience managing sub-modules.

Yes I think this is needed.  At tail-f, there are several modules with
many submodules.  These modules always use include by revision, and
always the main module is always uddated when any submodule is
updated.  It doens't make much sense IMO to not use include by
revision.

> My initial reaction is that we should not preclude the use of revision
> label with a submodule. Submodules have their own version today. The
> trick is to define (or explicitly say it is out of scope) whether a
> module version must change if any underlying submodule versions
> change. That gets difficult if you consider simply moving a leaf from
> one sub-module to another (without changing anything else about it -
> its context, etc).

Why would this be difficult?  The revision date is updated on any
editorial change (see 7.1.9 of RFC 7950).  So if a leaf gets moved
from submodule A to submodule B, then their revisions are udpated, and
hence the module's include-by revision is udpated, and hence the
module's revision ois updated.

/martin

> 
> Regards,
> Reshad.
> 
> On 2020-03-27, 5:44 PM, "netmod on behalf of Reshad Rahman (rrahman)"
> <[email-masked] on behalf of
> rrahman=[email-masked]> wrote:
> 
>     Hi,
>     
>     Good point. What was meant by that the label space for modules and
>     sub-modules are orthogonal.  e.g. the sub-module and module both have
>     the same label, it shouldn't be inferred that the 2 are related.
>     On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)"
>     <[email-masked] on behalf of
>     rrahman=[email-masked]> wrote:
>     
>         Hi Martin,
>         
>         We've opened issues to track your review comments (see below). Will
>         kick off separate therads for each issue.
>         
>         On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund"
>         <[email-masked] on behalf of [email-masked]> wrote:
>         
>             Hi,
>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 8 May 2020 22:24:37 +0000

Hi,

On 2020-05-08, 5:12 PM, "Martin Björklund" <[email-masked]> wrote:

    Hi,

    

I think what Jason meant is that by moving a leaf between submodules, it's possible the module's schema didn't change.
So yes revision date is updated, but you can't blindly update the revision-label.

Regards,
Reshad.

    /martin

---

From: Martin Björklund <[email-masked]>
Date: Sat, 09 May 2020 17:53:37 +0200 (CEST)

"Reshad Rahman (rrahman)" <[email-masked]> wrote:
> I think what Jason meant is that by moving a leaf between submodules,
> it's possible the module's schema didn't change.

Why not?

/martin

>     >                 Submodules MUST NOT use revision label schemes that could
>     >                 be
>     >                 confused
>     >               Hmm, how do I ensure that this MUST NOT is handled
>     >               correctly?
>     >               What
>     >                    reordered, as long as they do not change the ordering
>     >                    or
>     >                    any "rpc"
>     >                    "input" substatements.
>     >             
>     >               What if my project use another dialect of semver, that
>     >               wouldn't
>     >               be
>     >                 Submodules MUST NOT use revision label schemes that could
>     >                 be
>     >                 confused
>     >               Hmm, how do I ensure that this MUST NOT is handled
>     >               correctly?
>     >               What
>     >                   In the filename of a YANG module, where it takes the
>     >                   form:
>     >                   module-
>     >               Should this section update 5.2 of RFC 7950?  I know that
>     >               5.2
>     >               just
>     >               says "SHOULD".  But existing tools implement this SHOULD,
>     >               and
>     >               they
>     >               But I wonder if this a good idea.  It means that a tool
>     >               that
>     >               looks
>     >               for a module with a certain revision date cannot simply
>     >               check
>     >               the
>     >               filenames, but need to parse all available modules (wijust
>     >               to
>     >               find the
>     >             
>     >             
>     >             
>     >             o  3.4
>     >             
>     >               I don't think rev:status-description is necessary / worth
>     >               it.
>     >               This
>     >                 Alternatively, the first example could have used the
>     >                 revision
>     >                 label
>     >               Wouldn't it be better if the leaf
>     >               "deprecated-nodes-implemented"
>     >               and
>     >                 All IETF YANG modules MUST include revision-label
>     >                 statements
>     >                 for all
>     >                 existing YANG modules.  The revision-label MUST take the
>     >                 form
>     >                 of a

---

From: Martin Björklund <[email-masked]>
Date: Sat, 09 May 2020 17:57:15 +0200 (CEST)

> > So yes revision date is updated, but you can't blindly update the

Aha, I think I understand what you mean.  And in light of Tom's
comment in the other thread, I think that using 'revision-label' in
the module and not in sub-modules makes sense.  sub-modules can still
use the date, and be included by revision (date).

/martin

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Sat, 9 May 2020 16:52:06 +0000

Hi Martin,

Your approach sounds good to me. I was forgetting about the "editorial" level of change (e.g. the 3rd part of SemVer).  So I agree that moving a leaf would be an editorial change in both submodules.

But what if a module is not doing include by revision? It may indeed make sense to include by revision but it isn't mandated. For sake of argument here what if the module itself didn't change at all in this case?

It *feels* like the right thing to do here is to consider the module overall to have an editorial change.

The revision statement of sub-modules has a scope of the file (the sub-module). It isn't clear to me whether the revision of a *module* has a scope that includes all sub-modules or if it is just a scope of the module file. But we could clarify that as part of this work.

Jason

> -----Original Message-----
> From: Martin Björklund <[email-masked]>
> Sent: Saturday, May 9, 2020 11:54 AM
> To: [email-masked]
> Cc: [email-masked]; Sterne, Jason (Nokia - CA/Ottawa)
> <[email-masked]>
> Subject: Re: [netmod] Revision labels for submodules
> 
> >     >         https://github.com/netmod-wg/yang-ver-
> dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling
> >     >
> >     >         Regards,
> >     >         Reshad.
> >     >

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 12 May 2020 13:46:21 +0000

Hi Jason,

On 2020-05-09, 12:52 PM, "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]> wrote:

    Hi Martin,

    But what if a module is not doing include by revision? It may indeed make sense to include by revision but it isn't mandated. For sake of argument here what if the module itself didn't change at all in this case?
It is now mandated in section 3 of draft-ietf-netmod-yang-module-versioning-00.

    The revision statement of sub-modules has a scope of the file (the sub-module). It isn't clear to me whether the revision of a *module* has a scope that includes all sub-modules or if it is just a scope of the module file. But we could clarify that as part of this work.
Because of include by revision, the module would have to change to include a different revision of a sub-module.

Regards,
Reshad.
    
    Jason

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 12 May 2020 18:33:41 +0000

Hi,

On 2020-05-09, 11:57 AM, "Martin Björklund" <[email-masked]> wrote:

    
That works and simplifies things.

Regards,
Reshad.
    
    /martin

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 13 May 2020 15:50:07 +0000

Hi guys,

As someone who is heavily involved in the development of an extensive YANG model comprised of submodules, I'm not a fan of mandating that include by revision is mandatory for submodules. It may indeed be a good idea (so perhaps SHOULD is fine) but I can see it causing problems on the implementation side. 

The primary development of a data model may be distributed out to submodules and the main module may only be a top level container for the submodules (and rarely touched). This would suddenly create an ordering dependency in the release process that requires the main module file to systematically be updated after all development of the submodules is halted. Then the results of the submodules has to be used to then go update the module. Solvable - yes, but folks who work on large scale projects will know that suddenly requiring that type of development process change isn't as easy as it may sound on paper.

It is possible to manage the "packaging" of submodules and modules out of band or other mechanisms.

OpenConfig, for example, uses submodules but does not currently include by version. I'm not proposing this is ideal. But I think we should leave it as acceptable.

Rgds,
Jason

> From: Reshad Rahman (rrahman) <[email-masked]>
> Sent: Tuesday, May 12, 2020 9:46 AM
> To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>; Martin
> Björklund <[email-masked]>
> Cc: [email-masked]
>     Your approach sounds good to me. I was forgetting about the "editorial"
> level of change (e.g. the 3rd part of SemVer).  So I agree that moving a leaf
> would be an editorial change in both submodules.
> 
>     But what if a module is not doing include by revision? It may indeed make
> sense to include by revision but it isn't mandated. For sake of argument here
> what if the module itself didn't change at all in this case?
>     The revision statement of sub-modules has a scope of the file (the sub-
> module). It isn't clear to me whether the revision of a *module* has a scope
> that includes all sub-modules or if it is just a scope of the module file. But we
> could clarify that as part of this work.
>     > >     >     sub-modules are orthogonal.  e.g. the sub-module and module
> both
>     > have
>     > >     >                    substatements, those data definition substatements
> MAY
>     > >     >                    be
>     > >     >               I think this needs to capture that no descendant
> statements
>     > >     >               to
>     > >     >               "input" can be reordered.  Same for "output" (note,
> "input"
>     > >     >               and
>     > >     >               can easily be written with the normal description
> statement
>     > >     >               instead:
>     > >     >
>     > >     >               "obsolete-nodes-absent" were of type "boolean" rather
> than
>     > >     >               type
>     > >     >               "empty"?
>     > >     >
>     > >     >
>     > >     >             o  7.1
>     > >     >
>     > >     >               The text says:
>     > >     >

---

From: Andy Bierman <[email-masked]>
Date: Wed, 13 May 2020 09:21:24 -0700

Hi,

On Wed, May 13, 2020 at 8:50 AM Sterne, Jason (Nokia - CA/Ottawa) <
[email-masked]> wrote:

> Hi guys,
>
> As someone who is heavily involved in the development of an extensive YANG
> model comprised of submodules, I'm not a fan of mandating that include by
> revision is mandatory for submodules. It may indeed be a good idea (so
> perhaps SHOULD is fine) but I can see it causing problems on the
> implementation side.
>
> The primary development of a data model may be distributed out to
> submodules and the main module may only be a top level container for the
> submodules (and rarely touched). This would suddenly create an ordering
> dependency in the release process that requires the main module file to
> systematically be updated after all development of the submodules is
> halted. Then the results of the submodules has to be used to then go update
> the module. Solvable - yes, but folks who work on large scale projects will
> know that suddenly requiring that type of development process change isn't
> as easy as it may sound on paper.
>
I agree with you about SHOULD instead of MUST.
The client should rely on the YANG library data for submodule revisions,
since the include-by-revision is usually not used.

It does seem like a good idea for main module conformance  to lock down the
submodule revisions expected for a specific main module revision.

OpenConfig, for example, uses submodules but does not currently include by
> version. I'm not proposing this is ideal. But I think we should leave it as
> acceptable.
>
> Rgds,
> Jason
>
>
Andy

> >     It *feels* like the right thing to do here is to consider the module
> overall
> > to have an editorial change.
> >
> > Because of include by revision, the module would have to change to
> include
> > a different revision of a sub-module.
> >
> > Regards,
> > Reshad.
> >
> >     Jason
> >
> >     > >     > This came up during this week's meeting. We briefly
> discussed
> > whether
> >     > >     > there's a need to version sub-modules or can we restrict
> versioning
> > to
> >     > >     many submodules.  These modules always use include by
> revision,
> > and
> >     > >     > My initial reaction is that we should not preclude the use
> of
> > revision
> >     > >     > change. That gets difficult if you consider simply moving
> a leaf
> > from
> >     > >     > one sub-module to another (without changing anything else
> about
> > it -
> >     > >     > its context, etc).
> >     > >
> >     > >     from submodule A to submodule B, then their revisions are
> udpated,
> > and
> >     > >     >                 Submodules MUST NOT use revision label
> schemes that
> > could
> >     > >     >                 be
> >     > >     >                 confused
> >     > >     >     On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad
> Rahman
> >     > (rrahman)"
> >     > >     >         We've opened issues to track your review comments
> (see
> >     > >     >         below). Will
> [email-masked]>
> > wrote:
> >     > >     >                 o In statements that have any data
> definition statements
> >     > >     >                 as
> >     > >     >                 All revision labels that match the pattern
> for the
> >     > >     >                 "version"
> >     > >     >                 typedef in the ietf-yang-semver YANG
> module MUST be
> >     > >     >                 interpreted as
> >     > >     >               I don't think this is a good idea.  Seems
> like a layer
> >     > >     >               violation.
> >     > >     >                 Submodules MUST NOT use revision label
> schemes that
> > could
> >     > >     >                 be
> >     > >     >                 confused
> >     > >     >                   or-submodule-name ['@' revision-label] (
> '.yang' /
> >     > >     >                   '.yin' )
> >     > >     >
> >     > >     >                        "Imperial measurements are being
> phased out in
> >     > >     >                        favor
> >     > >     >                        "Imperial measurements are being
> phased out in
> >     > >     >                        favor
> >     > >     >               The example modules should be legal YANG
> modules.  Use
> > e.g.
> >     > >     >               Also, the modules are missing the last "}",
> which confuses
> >     > >     >               the
> >     > >     >               "rfcstrip" tool.
> >     > >     >
> >     > >     >
> >     > >     >             o 4.1.1
> >     > >     >
> >     > >     >                 "1.0.0" instead, which selects the same
> set of
> >     > >     >                 revisions/versions.
> >     > >     >
> >     > >     >                 import example-module {
> >     > >     >               I think the module name "ietf-yl-revisions"
> should be
> >     > >     >               changed to
> >     > >     >               "ietf-yang-library-revisions".  "yl" is not
> a well-known
> >     > >     >               acronym.
> >     > >     >
> >     > >     >
> >     > >     >             o  5.2.2
> >     > >     >
> >     > >     >                 newly published YANG modules, and all
> newly published
> >     > >     >                 revisions of
> >     > >     >               I strongly disagree with this new rule.
> IETF modules use a
> >     > >     >               linear
> >     > >     >                4.  For status "obsolete", it is
> RECOMMENDED to keep the
> >     > >     >                "status-
> >     > >     >                    description" information, from when the
> node had
> >     > >     >                    status
> >     > >     >               All extensions should specify the grammar;
> i.e., in which
> >     > >     >               statements
> >     > >     >               they can be present and which substatements
> they can
> > have.
> >     > >     >
> >     > >     >
> >     > >     >
> >     > >     >             /martin
> >     > >     >

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 13 May 2020 16:46:14 +0000

Hi Jason,

On 2020-05-13, 11:50 AM, "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]> wrote:

    Hi guys,

    The primary development of a data model may be distributed out to submodules and the main module may only be a top level container for the submodules (and rarely touched). This would suddenly create an ordering dependency in the release process that requires the main module file to systematically be updated after all development of the submodules is halted. Then the results of the submodules has to be used to then go update the module. Solvable - yes, but folks who work on large scale projects will know that suddenly requiring that type of development process change isn't as easy as it may sound on paper.
<RR> I can see why you wouldn't want to modify all your include by-revision statements. But you would still need to update the module revision-label based on changes done in the included submodules.

Regards,
Reshad.

    
    Rgds,
    Jason

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 13 May 2020 17:30:05 +0000

So that's the part I'm not sure of.

If a leaf moves between submodules, and the module file doesn't change in any way (as we've said is possible and should be allowed), do we mandate that the module version changes?  This is up to us to define IMO

(A) the module version has a scope that includes the module and all submodules
(B) the module version has a scope that is just the module file contents

I'm on the fence between those two. (A) could make sense but it does mean that someone comparing two versions of the just the module file itself may see no difference whatsoever between them except the addition of a new version statement.

Jason

> Sent: Wednesday, May 13, 2020 12:46 PM
>     As someone who is heavily involved in the development of an extensive
> YANG model comprised of submodules, I'm not a fan of mandating that
> include by revision is mandatory for submodules. It may indeed be a good
> idea (so perhaps SHOULD is fine) but I can see it causing problems on the
> implementation side.
> 
> systematically be updated after all development of the submodules is halted.
> Then the results of the submodules has to be used to then go update the
> module. Solvable - yes, but folks who work on large scale projects will know
> that suddenly requiring that type of development process change isn't as
> easy as it may sound on paper.
> <RR> I can see why you wouldn't want to modify all your include by-revision
> statements. But you would still need to update the module revision-label
> based on changes done in the included submodules.
> 
> Regards,
> Reshad.
> 
>     OpenConfig, for example, uses submodules but does not currently include
> by version. I'm not proposing this is ideal. But I think we should leave it as
> acceptable.
> 
>     Rgds,
>     Jason
> 
>     >     > >     > On 2020-03-27, 5:44 PM, "netmod on behalf of Reshad
> Rahman
>     >     > (rrahman)"
>     >     > >     >                 Submodules MUST NOT use revision label schemes
> that
>     > could
>     >     > >     >                 be
>     >     > >     >                 confused
>     >     > >     >                 o In statements that have any data definition
> statements
>     >     > >     >                 as
>     >     > >     >                 typedef in the ietf-yang-semver YANG module MUST
> be
>     >     > >     >                 interpreted as
>     >     > >     >                 Submodules MUST NOT use revision label schemes
> that
>     > could
>     >     > >     >                 be
>     >     > >     >                 confused
>     >     > >     >               The example modules should be legal YANG modules.
> Use
>     > e.g.
>     >     > >     >               Also, the modules are missing the last "}", which
> confuses
>     >     > >     >               the
>     >     > >     >               "rfcstrip" tool.
>     >     > >     >
>     >     > >     >
>     >     > >     >             o 4.1.1
>     >     > >     >
>     >     > >     >                 newly published YANG modules, and all newly
> published
>     >     > >     >                 revisions of
>     >     > >     >               I strongly disagree with this new rule.  IETF modules
> use a
>     >     > >     >               linear
>     >     > >     >                4.  For status "obsolete", it is RECOMMENDED to keep
> the
>     >     > >     >                "status-
>     >     > >     >               All extensions should specify the grammar; i.e., in
> which
>     >     > >     >               statements

---

From: Jan Lindblad <[email-masked]>
Date: Wed, 13 May 2020 21:57:46 +0200

Jason,

The versions may be logically the same, but they are not the same IMO.
A client doing config work may not care about this difference, but tools doing other things might.

/jan

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 13 May 2020 20:51:35 +0000

Hi Jason,

Is your question of option A v/s B just for the case where the schema represented by the module does not change?

If the schema changes, even if the module didn't change, the revision-label has to be updated to indicate the change.
If the schema didn't change, I'd go with editorial revision-label update as (I think) Martin suggested.

Regards,
Reshad.

On 2020-05-13, 1:30 PM, "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]> wrote:

    

    Jason

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 13 May 2020 21:25:05 +0000

The example we've been using to discuss this is an editorial type change in 2 submodules (moving a leaf between them with no changes to their definition or the schema). 

But if we consider an example where schema actually changes (in a part that is defined in a submodule), then it does seem reasonable that the module version should also change.

So (A) is probably the right answer here.  But it does have a potentially confusing consequence: two YANG files could be identical except for an extra revision statement. It may appear that someone incorrectly bumped a version when there was no change, until you notice that "oh, this module includes submodules - one of those must have changed".

Jason

> Sent: Wednesday, May 13, 2020 4:52 PM
> Is your question of option A v/s B just for the case where the schema
> represented by the module does not change?
> 
> If the schema changes, even if the module didn't change, the revision-label
> has to be updated to indicate the change.
>     If a leaf moves between submodules, and the module file doesn't change
> in any way (as we've said is possible and should be allowed), do we mandate
> that the module version changes?  This is up to us to define IMO
> 
>     I'm on the fence between those two. (A) could make sense but it does
> mean that someone comparing two versions of the just the module file itself
> may see no difference whatsoever between them except the addition of a
> new version statement.
> 
>     Jason
> 
> halted.
>     >     It is possible to manage the "packaging" of submodules and modules
> out
>     > of band or other mechanisms.
>     >
>     >     > level of change (e.g. the 3rd part of SemVer).  So I agree that moving
> a
>     > leaf
>     >     >     But what if a module is not doing include by revision? It may
> indeed
>     > make
>     >     > sense to include by revision but it isn't mandated. For sake of
> argument
>     > here
>     >     > module). It isn't clear to me whether the revision of a *module* has
> a
>     > scope
>     >     > that includes all sub-modules or if it is just a scope of the module
> file.
>     > But we
>     >     >     > > On 2020-05-08, 5:12 PM, "Martin Björklund"
> <[email-masked]>
>     >     > wrote:
>     >     >     > >
>     >     >     > >     Hi,
>     >     >     > >
>     >     >     > >     Yes I think this is needed.  At tail-f, there are several
> modules
>     > with
>     >     >     > >     always the main module is always uddated when any
> submodule
>     > is
>     >     >     > >     > label with a submodule. Submodules have their own
> version
>     >     > today. The
>     >     >     > >     > change. That gets difficult if you consider simply moving a
> leaf
>     >     > from
>     >     >     > >     hence the module's include-by revision is udpated, and
> hence
>     > the
>     >     >     > > So yes revision date is updated, but you can't blindly update
> the
>     >     >     > > revision-label.
>     >     >     >
>     >     >     > Why not?
>     >     >     >
>     >     >     >
>     >     >     > /martin
>     >     >     >
>     >     >     >
>     >     >     > >
>     >     >     > > Regards,
>     >     >     > > Reshad.
>     >     >     > >
>     >     >     > >     /martin
>     >     >     > >
>     >     >     > >
>     >     >     > >
>     >     >     > >     >
>     >     >     > >     > Regards,
>     >     >     > >     > Reshad.
>     >     >     > >     >
> schemes
> schemes
>     >     >     > >     >                   In the filename of a YANG module, where it
> takes
>     > the
>     >     >     > >     >                   form:
>     >     >     > >     >                   module-
>     >     >     > >     >                   or-submodule-name ['@' revision-label] ( '.yang'
> /
>     >     >     > >     >                   '.yin' )
>     >     >     > >     >
>     >     >     > >     >               Should this section update 5.2 of RFC 7950?  I
> know
>     > that
>     >     >     > >     >               5.2
>     >     >     > >     >               just
>     >     >     > >     >                        "Imperial measurements are being phased out
> in
>     >     >     > >     >                        favor
>     >     >     > >     >                        "Imperial measurements are being phased out
> in
>     >     >     > >     >                        favor
> modules.
>     >     >     > >     >               I think the module name "ietf-yl-revisions" should
> be
>     >     >     > >     >               changed to
>     >     >     > >     >               "ietf-yang-library-revisions".  "yl" is not a well-
> known
>     >     >     > >     >               acronym.
>     >     >     > >     >
>     >     >     > >     >
>     >     >     > >     >             o  5.2.2
>     >     >     > >     >
>     >     >     > >     >                 existing YANG modules.  The revision-label MUST
> take
>     > the
>     >     >     > >     >                 form
>     >     >     > >     >                 of a
>     >     >     > >     >                    description" information, from when the node
> had
>     >     >     > >     >                    status
>     >     >     > >     >               they can be present and which substatements they
> can
>     >     > have.
>     >     >     > >     >
>     >     >     > >     >
>     >     >     > >     >
>     >     >     > >     >             /martin
>     >     >     > >     >
>     >     >     > >     >

---

From: Andy Bierman <[email-masked]>
Date: Wed, 13 May 2020 14:51:50 -0700

On Wed, May 13, 2020 at 2:25 PM Sterne, Jason (Nokia - CA/Ottawa) <
[email-masked]> wrote:

> The example we've been using to discuss this is an editorial type change
> in 2 submodules (moving a leaf between them with no changes to their
> definition or the schema).
>
> But if we consider an example where schema actually changes (in a part
> that is defined in a submodule), then it does seem reasonable that the
> module version should also change.
>
> So (A) is probably the right answer here.  But it does have a potentially
> confusing consequence: two YANG files could be identical except for an
> extra revision statement. It may appear that someone incorrectly bumped a
> version when there was no change, until you notice that "oh, this module
> includes submodules - one of those must have changed".
>
>
Some tools might be sensitive to changes that could be considered editorial.
The YANG to SID mapping algorithm comes to mind as a tool sensitive to
moving data definitions between submodules.

IMO any change at all (except maybe change in insignificant whitespace)
should cause
2 revisions to be different (and require different revision dates and
revision labels).

Jason
Andy

> > If the schema didn't change, I'd go with editorial revision-label update
> as (I
> > think) Martin suggested.
> >
> > Regards,
> > Reshad.
> >
> >     > submodules and the main module may only be a top level container
> for
> > the
> >     > module. Solvable - yes, but folks who work on large scale projects
> will
> > know
> >     > by version. I'm not proposing this is ideal. But I think we should
> leave it
> > as
> >     > acceptable.
> >     >
> >     >     Rgds,
> >     >     Jason
> >     >
> >     >     > To: Sterne, Jason (Nokia - CA/Ottawa) <
> [email-masked]>;
> >     > Martin
> >     >     >     Your approach sounds good to me. I was forgetting about
> the
> >     > "editorial"
> >     >     > It is now mandated in section 3 of
> draft-ietf-netmod-yang-module-
> >     >     > versioning-00.
> >     >     >
> >     >     >
> >     >     >     The revision statement of sub-modules has a scope of the
> file (the
> >     > sub-
> >     >     >     > >     > modules only. We would like to hear from the
> WG on this,
> >     >     > especially
> >     >     >     > >     updated.  It doens't make much sense IMO to not
> use
> > include by
> >     >     >     > >     revision.
> >     >     >     > >
> >     >     >     > >     > For completeness, below is an update from
> Jason in
> > github:
> >     >     >     > >     > trick is to define (or explicitly say it is
> out of scope)
> > whether a
> >     >     >     > >     > module version must change if any underlying
> submodule
> >     > versions
> >     >     >     > >     > one sub-module to another (without changing
> anything
> > else
> >     > about
> >     >     > it -
> >     >     >     > >     > its context, etc).
> >     >     >     > >
> >     >     >     > >     Why would this be difficult?  The revision date
> is updated on
> > any
> >     >     >     > >     editorial change (see 7.1.9 of RFC 7950).  So if
> a leaf gets
> > moved
> >     >     >     > > I think what Jason meant is that by moving a leaf
> between
> >     >     > submodules,
> >     >     >     > >     >                 with the including module's
> revision label
> > scheme.
> >     >     >     > >     >
> >     >     >     > >     >               Hmm, how do I ensure that this
> MUST NOT is
> > handled
> >     >     >     > >     >               correctly?
> >     >     >     > >     >               What
> >     >     >     > >     >     Good point. What was meant by that the
> label space for
> >     >     > modules and
> >     >     >     > >     >     sub-modules are orthogonal.  e.g. the
> sub-module and
> >     > module
> >     >     > both
> >     >     >     > have
> >     >     >     > >     >     the same label, it shouldn't be inferred
> that the 2 are
> >     > related.
> >     >     >     > >     >         On 2020-03-10, 3:31 PM, "netmod on
> behalf of Martin
> >     >     > Björklund"
> >     >     >     > >     >                    substatements, those data
> definition
> > substatements
> >     >     > MAY
> >     >     >     > >     >                    be
> >     >     >     > >     >                    reordered, as long as they
> do not change the
> >     > ordering
> >     >     >     > >     >                    or
> >     >     >     > >     >                    any "rpc"
> >     >     >     > >     >                    "input" substatements.
> >     >     >     > >     >
> >     >     >     > >     >               "input" can be reordered.  Same
> for "output"
> > (note,
> >     >     > "input"
> >     >     >     > >     >               and
> >     >     >     > >     >                 All revision labels that match
> the pattern for the
> >     >     >     > >     >                 "version"
> >     >     >     > >     >                 typedef in the
> ietf-yang-semver YANG module
> > MUST
> >     > be
> >     >     >     > >     >                 interpreted as
> >     >     >     > >     >               I don't think this is a good
> idea.  Seems like a layer
> >     >     >     > >     >               violation.
> >     >     >     > >     >               What if my project use another
> dialect of semver,
> > that
> >     >     >     > >     >               wouldn't
> >     >     >     > >     >               be
> >     >     >     > >     >               possible with this rule.  I
> think this needs to be
> >     > removed.
> >     >     >     > >     >
> >     >     >     > >     >
> >     >     >     > >     >             o  3.3
> >     >     >     > >     >
> >     >     >     > >     >                 Submodules MUST NOT use
> revision label
> > schemes
> >     > that
> >     >     > could
> >     >     >     > >     >                 be
> >     >     >     > >     >                 confused
> >     >     >     > >     >                 with the including module's
> revision label
> > scheme.
> >     >     >     > >     >
> >     >     >     > >     >               Hmm, how do I ensure that this
> MUST NOT is
> > handled
> >     >     >     > >     >               correctly?
> >     >     >     > >     >               What
> >     >     >     > >     >               says "SHOULD".  But existing
> tools implement this
> >     > SHOULD,
> >     >     >     > >     >               and
> >     >     >     > >     >               they
> >     >     >     > >     >               need to be updated to handle
> this new
> > convention.
> >     >     >     > >     >
> >     >     >     > >     >               But I wonder if this a good
> idea.  It means that a
> > tool
> >     >     >     > >     >               that
> >     >     >     > >     >               looks
> >     >     >     > >     >               for a module with a certain
> revision date cannot
> > simply
> >     >     >     > >     >               check
> >     >     >     > >     >               the
> >     >     >     > >     >               filenames, but need to parse all
> available modules
> >     > (wijust
> >     >     >     > >     >               to
> >     >     >     > >     >               find the
> >     >     >     > >     >
> >     >     >     > >     >
> >     >     >     > >     >
> >     >     >     > >     >             o  3.4
> >     >     >     > >     >
> >     >     >     > >     >                         of their metric
> equivalents.  Use
> >     >     >     > >     >                         metric-temperature
> >     >     >     > >     >               I don't think
> rev:status-description is necessary /
> > worth
> >     >     >     > >     >               it.
> >     >     >     > >     >               This
> >     >     >     > >     >                         of their metric
> equivalents.  Use
> >     >     >     > >     >                         metric-temperature
> >     >     >     > >     >                 Alternatively, the first
> example could have used
> >     >     >     > >     >                 "1.0.0" instead, which selects
> the same set of
> >     >     >     > >     >                 revisions/versions.
> >     >     >     > >     >
> >     >     >     > >     >                 import example-module {
> >     >     >     > >     >                   rev:revision-or-derived
> 1.0.0;
> >     >     >     > >     >                 }
> >     >     >     > >     >
> >     >     >     > >     >               Shouldn't this be
> s/1.0.0/2.0.0/g ?
> >     >     >     > >     >
> >     >     >     > >     >
> >     >     >     > >     >             o  5
> >     >     >     > >     >
> >     >     >     > >     >               I think the module name
> >     >     >     > >     >               "obsolete-nodes-absent" were of
> type "boolean"
> >     > rather
> >     >     > than
> >     >     >     > >     >               type
> >     >     >     > >     >               "empty"?
> >     >     >     > >     >
> >     >     >     > >     >
> >     >     >     > >     >             o  7.1
> >     >     >     > >     >
> >     >     >     > >     >               The text says:
> >     >     >     > >     >
> >     >     >     > >     >                 All IETF YANG modules MUST
> include revision-
> > label
> >     >     >     > >     >                 statements
> >     >     >     > >     >                 for all
> >     >     >     > >     >               I strongly disagree with this
> new rule.  IETF
> > modules
> >     > use a
> >     >     >     > >     >               linear
> >     >     >     > >     >               history, so there are no reasons
> to use "modified
> >     > semver".
> >     >     >     > >     >
> >     >     >     > >     >                4.  For status "obsolete", it
> is RECOMMENDED to
> > keep
> >     > the
> >     >     >     > >     >                "status-