Re: [netmod] iana-if-type.yang has multiple revisions with the same date

On Tue, Mar 1, 2022 at 4:54 AM William Lupton <wlupton@broadband-forum.org>
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/iana-if-type@2021-06-21.yang>:
> 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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>