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

[Andy Bierman <[e-mail]>]

On Fri, Mar 4, 2022 at 10:00 AM Rob Wilton (rwilton) <[e-mail]>
wrote:

> 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 (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.
>
>
>

I was going to mention the checksums. I am aware they were taken out.

I have understood for years that YANG conformance at the module-level,
which is baked into the module itself, is a broken architecture.

Conformance should be based on use-cases, for which YANG module boundaries
are irrelevant.  The key to package management is that it replaces
individual file management.
How do YANG 1.1 compliant systems which only know about YANG modules work
with newer systems that know about packages.  Managing the interaction
details
at both the module and package level seems complicated.

IMO a new YANG version number is needed to make the sort of changes proposed
in the versioning work. There are existing issues, e.g.:

- the behavior for 'deprecated' and 'obsolete' has been broken from the
start
   and only a new YANG version can really fix it
- a standard module (or package) should be able to use deviations to alter
  a module for its own use-cases, but this violates a MUST NOT in YANG 1.1
- All extensions are purely optional in YANG 1.1, which could be fixed in a
new YANG version
- YANG packages could be mandatory for the new YANG version, allowing
   conformance requirements to be properly expressed





Rob
>
> // As an individual contributor
>
>
>
>
>


Andy



> *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]>
> 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.
>
>