Re: [netmod] Revision label in filename

[Andy Bierman <[e-mail]>]

On Sat, May 9, 2020 at 4:07 AM tom petch <[e-mail]> wrote:

> From: netmod <[e-mail]> on behalf of Reshad Rahman
> (rrahman) <rrahman=[e-mail]>
> Sent: 08 May 2020 15:13
>
> Hi,
>
> We discussed using something along the lines of
> module-or-submodule-name['@'date]['#'revision-label].yang. Questions to the
> WG:
> 1) Is there a need for both date and revision-label or is one of them
> enough?
>
> <tp>
> One of them is quite enough and since the date is embedded in many systems
> it would be wrong to change it.  The module name is the primary identifier
> of this bundle of definitions but it was decided that as and when there was
> a change therein then the date would provide a unique identifier for a
> particular version; nothing more is needed.  Arguably the date is more
> complex than is warranted but it has worked.  Indeed that format is now
> used and understood by such as IANA and the RFC Editor.
>
>

+1

This would be a very disruptive change with little to no value.


> If you want to record more detailed semantics of the relationships between
> different versions, then put it somewhere else and leave the identifier
> alone, let the identifier be an identifier and not be overloaded with
> semantics.
>
> Tom Petch
>
>
Andy


>
>
>
>
>
>
>
> 2) If we have both, what's the impact of having "#revision-label" on
> implementations which search by date?
>
> 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/50
>
>             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
>
>     We agree that there is an impact on searching by date. We put this in
> to have the ability to search by revision-label, otherwise we can search
> just by date for a module which uses revision-label.
>     We had also discussed using different limiter for the label and have
> something along the lines of:
> module-or-submodule-name['@'date]['#'revision-label].yang
>     It'd seem that updating 7950 would be a good idea whichever way we go.
>
>     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
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>