On 2020-03-30, 2:20 PM, "Martin Björklund" <[email protected]> wrote:
"Reshad Rahman (rrahman)" <[email protected]> wrote:
> On 2020-03-28, 4:41 AM, "Martin Björklund" <[email protected]> wrote:
>
> "Reshad Rahman (rrahman)" <[email protected]> wrote:
> > Hi,
> >
> > https://github.com/netmod-wg/yang-ver-dt/issues/45
> >
> > 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.
> >
> > We believe some IETF models may not follow linear history, this was
> > brought up (I think) for IDR. Modified semver allows for non-linear
> > history and also doesn't preclude linear history. So even if we end
up
> > having no IETF modules using branching, modified semver still works.
>
> With the clarifiactions and updates in
> draft-verdt-netmod-yang-module-versioning, non-linear versioning
> works without modified semver. So there is no technical reason to use
> modified semver in IETF modules.
>
> So are you proposing we use some other revision-label scheme (e.g. semver
2.0.0) for IETF modules?
>
> Or that IETF modules shouldn't use revision-labels?
That IETF shouldn't use revision labels.
The revision label allows a user to easily figure out whether 2 revisions are
(N)BC. Without the label, you always have to use tooling.
Regards,
Reshad.
I am all for using rev:nbc-changes or rev:editorial-changes (which I
think should be added) in IETF modules.
/martin
>
> Or do you have something else in mind?
>
> Regards,
> Reshad.
>
> I can reluctantly accept that modified smever is published as
> Experimental. But that doesn't mean that IETF modules should use it.
>
>
> /martin
>
>
> >
> > Regards,
> > Reshad.
> >
> >
> > On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman
(rrahman)"
> > <[email protected] on behalf of
> > [email protected]> 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 protected] on behalf of [email protected]> 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 protected]
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> >
> > _______________________________________________
> > netmod mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> >
>
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
