Hi Andy,
On this specific point:
Note that with multiple release trains and the new SERMVER, it is likely
that multiple [name, date, label] tuples resolve to the same [name, date] pair,
making the uniqueness problem even worse.
The module versioning draft explicitly disallows this. Even when using
revision-labels/Semver there is a requirement that they are separate revision
modules with unique revision dates.
Specifically, it contains this text:
In addition, this document uses the following terminology:
o YANG module revision: An instance of a YANG module, uniquely
identified with a revision date, with no implied ordering or
backwards compatibility between different revisions of the same
module.
This document clarifies [RFC7950] and [RFC6020] to explicitly allow
non-linear development of YANG module and submodule revisions, so
that they MAY have multiple revisions that directly derive from the
same parent revision. As per [RFC7950] and [RFC6020], YANG module
and submodule revisions continue to be uniquely identified by their
revision date, and hence all revisions of a given module or submodule
MUST have unique revision dates.
And for revision labels:
Revision labels MUST be unique amongst all revisions of a
module or submodule.
Regards,
Rob
// As an author/contributor.
From: netmod <[email protected]> On Behalf Of Andy Bierman
Sent: 01 March 2022 14:49
To: William Lupton <[email protected]>
Cc: NetMod WG <[email protected]>
Subject: Re: [netmod] iana-if-type.yang has multiple revisions with the same
date
On Tue, Mar 1, 2022 at 4:54 AM William Lupton
<[email protected]<mailto:[email protected]>> wrote:
All,
Sorry if (as is quite likely) this is a duplicate.
I noticed from https://yangcatalog.org/private-page/BBFYANGPageCompilation.html
that there's a (long-standing?) problem in
iana-if-type.yang<https://www.iana.org/assignments/yang-parameters/[email protected]>:
it has multiple revision statements with the same date:
revision 2018-06-28 {
description
"Registered ifType 294.";
}
revision 2018-06-28 {
description
"Registered ifType 293.";
}
This has presumably happened as a result of an automated update script that
doesn't check for this case (*)? From a quick scan, I didn't see anything in
RFC 7950 banning duplicate revision dates, but RFC 8407 section 4.8 says "If
the module contents have changed, then the revision date of that new module
version MUST be updated to a date later than that of the previous version" and
of course yangdump-pro is checking this.
I think that this should be fixed. What's the best way to achieve this?
I think this issue should be resolved as well.
The YANG library identifies each module by a [name, date] tuple.
The <get-schema> operation uses this tuple to identify a specific revision to
retrieve.
The import-by-revision mechanism uses this tuple to identify a specific
revision to import.
If this [name, date] tuple is not unique, then it cannot be mapped to a single
module revision.
Note that with multiple release trains and the new SERMVER, it is likely
that multiple [name, date, label] tuples resolve to the same [name, date] pair,
making the uniqueness problem even worse.
This is quite significant if a client reads the YANG library from a server
and decides it already has the module cached (based on the [name, date] tuple,
as defined in the standard. Then it will not use the <get-schema> operation
to retrieve the module from the server.
YANG artifacts and SID files also rely on this [name, date] tuple uniqueness.
Even with the new versioning drafts, it is impossible for the client to know
"Do you mean the REAL module foo, version xxxx-xx-xx, or your private version?"
Thanks,
William
Andy
(*) In the rare event that multiple changes are made in the same day, perhaps
the second change should be (strictly wrongly) assigned to the following day.
In theory this could cause revision dates to run far into the future but in
practice I don't think this will happen :).
_______________________________________________
netmod mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
