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

[Andy Bierman <[e-mail]>]

On Thu, Mar 3, 2022 at 1:25 AM William Lupton <[e-mail]>
wrote:

> Thanks Andy. What is the next step? Should I (or someone else) email
> [e-mail], or can we assume that the relevant IANA person will
> already have seen this discussion?
>
>
It seems that RFC 8407 already says what to do (use a different
revision-date).
We combine the revision-stmt so there is only 1 revision entry instead of 2.

It is too late to do anything about this module.

I am interested in the OPS issues:
The client MUST be able to produce the same[*] schema tree as the server
in order to have an accurate model of the server's YANG API.

 1) server uses implementation-specific mechanisms (e.g. search path)
     to select the modules it will advertise in its yang-library
 2) client reads the yang-library, which provides all the [name,date] tuples
     and other info needed
 3a) client can use cached yang-library data and locally obtained YANG files
 3b) client can use <get-schema> (IFF supported by the server) to retrieve
the YANG files

[*] same can mean a later revision if specific schema definitions have not
changed

Issues:

1) Is there ANY uniqueness guarantee that [name, date] is GLOBALLY unique.
A: Yes according to RFC 7950, but not really in implementations.
A: No, if revision-label is added and the same revision-date is used in
multiple release trains.

So if a client cannot rely on [name, date] uniqueness, then it does not
really know if
step 3a or step 3b is required.

This is currently a solved problem using proprietary means
(e.g., client hacked to know which one, based on server testing).

But now there are more system components, not just a server,
such as YANG Data Instance Files and YANG SID Files.
If the [name, date] tuples are not globally unique here,
then these standards do not work.


Andy







> On Tue, 1 Mar 2022 at 14:49, Andy Bierman <[e-mail]> wrote:
>
>>
>> I think that this should be fixed. What's the best way to achieve this?
>>>
>>
>> I think this issue should be resolved as well.
>>
>