Re: [netmod] Revision labels for submodules

[Andy Bierman <[e-mail]>]

Hi,

On Wed, May 13, 2020 at 8:50 AM Sterne, Jason (Nokia - CA/Ottawa) <
[e-mail]> 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.
>
> It is possible to manage the "packaging" of submodules and modules out of
> band or other mechanisms.
>
>
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


> > -----Original Message-----
> > From: Reshad Rahman (rrahman) <[e-mail]>
> > Sent: Tuesday, May 12, 2020 9:46 AM
> > To: Sterne, Jason (Nokia - CA/Ottawa) <[e-mail]>; Martin
> > Björklund <[e-mail]>
> > Cc: [e-mail]
> > Subject: Re: [netmod] Revision labels for submodules
> >
> > Hi Jason,
> >
> > On 2020-05-09, 12:52 PM, "Sterne, Jason (Nokia - CA/Ottawa)"
> > <[e-mail]> wrote:
> >
> >     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 is now mandated in section 3 of draft-ietf-netmod-yang-module-
> > versioning-00.
> >
> >
> >     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.
> > Because of include by revision, the module would have to change to
> include
> > a different revision of a sub-module.
> >
> > Regards,
> > Reshad.
> >
> >     Jason
> >
> >     > -----Original Message-----
> >     > From: Martin Björklund <[e-mail]>
> >     > Sent: Saturday, May 9, 2020 11:54 AM
> >     > To: [e-mail]
> >     > Cc: [e-mail]; Sterne, Jason (Nokia - CA/Ottawa)
> >     > <[e-mail]>
> >     > Subject: Re: [netmod] Revision labels for submodules
> >     >
> >     > "Reshad Rahman (rrahman)" <[e-mail]> wrote:
> >     > > Hi,
> >     > >
> >     > > On 2020-05-08, 5:12 PM, "Martin Björklund" <[e-mail]>
> > wrote:
> >     > >
> >     > >     Hi,
> >     > >
> >     > >     "Reshad Rahman (rrahman)" <[e-mail]> 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.
> >     > >
> >     > >     > 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).
> >     > >
> >     > >     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.
> >     > >
> >     > > 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.
> >     >
> >     > Why not?
> >     >
> >     >
> >     > /martin
> >     >
> >     >
> >     > >
> >     > > Regards,
> >     > > Reshad.
> >     > >
> >     > >     /martin
> >     > >
> >     > >
> >     > >
> >     > >     >
> >     > >     > Regards,
> >     > >     > Reshad.
> >     > >     >
> >     > >     > On 2020-03-27, 5:44 PM, "netmod on behalf of Reshad Rahman
> >     > (rrahman)"
> >     > >     > <[e-mail] on behalf of
> >     > >     > rrahman=[e-mail]> 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)"
> >     > >     >     <[e-mail] on behalf of
> >     > >     >     rrahman=[e-mail]> 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"
> >     > >     >         <[e-mail] on behalf of
> [e-mail]>
> > 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
> >     > >     >             [e-mail]
> >     > >     >             https://www.ietf.org/mailman/listinfo/netmod
> >     > >     >
> >     > >     >
> >     > >     >         _______________________________________________
> >     > >     >         netmod mailing list
> >     > >     >         [e-mail]
> >     > >     >         https://www.ietf.org/mailman/listinfo/netmod
> >     > >     >
> >     > >     >
> >     > >     >     _______________________________________________
> >     > >     >     netmod mailing list
> >     > >     >     [e-mail]
> >     > >     >     https://www.ietf.org/mailman/listinfo/netmod
> >     > >     >
> >     > >     >
> >     > >
> >     > >
> >
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>