On Tue, Mar 1, 2022 at 4:54 AM William Lupton <[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] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
