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

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Andy,

YANG packages are aimed at partly solving the problem you describe below.

In the -00 revision of the packages draft, it included SHA hashes* (YANG leaf “checksum”) of the included modules and packages so that a client can determine that its local copy of module@A.B.C<mailto:module@A.B.C> (or revision-date) exactly matches the one that the server is declaring that it is using in the YANG package definition.  You can see this in the -00 version (YANG Packages (ietf.org)<https://tools.ietf.org/id/draft-ietf-netmod-yang-packages-00.html>).

The checksum/hashes have been taken out of later revisions of the draft for two reasons:

  1.  At the time, we were not sure that we had a canonical representation of a YANG module, although possibly this has been mitigated by the YANG module versioning draft that effectively defines the file text of the published YANG module to be that canonical representation.
  2.  It was thought that it was too complex, and hence better deferred to an extension of future version of the YANG packages draft.  We also thought that we would need to get real security folks involved to check that we are really getting this right.

But either way, longer term, I think that a scheme along these lines this will probably be helpful.

Rob
// As an individual contributor


From: netmod <[e-mail]> On Behalf Of Andy Bierman
Sent: 03 March 2022 16:56
To: William Lupton <[e-mail]>
Cc: NetMod WG <[e-mail]>
Subject: Re: [netmod] iana-if-type.yang has multiple revisions with the same date



On Thu, Mar 3, 2022 at 1:25 AM William Lupton <[e-mail]<mailto:[e-mail]>> wrote:
Thanks Andy. What is the next step? Should I (or someone else) email [e-mail]<mailto:[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]<mailto:[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.