Re: [core] progressing ietf-core-yang-cbor and ietf-core-sid

[Andy Bierman <[e-mail]>]

On Thu, Jan 16, 2020 at 9:47 AM Carsten Bormann <[e-mail]> wrote:

> On 2020-01-16, at 13:50, Andy Bierman <[e-mail]> wrote:
> >
> > There is a significant amount of metadata needed to generate a SID file,
> > starting with all the previous YANG revisions or SID files, and when/if
> > the SID files have been reset vs. updated with preserved numbers.
>
> Well, specifically, the current YANG module and the previous SID file; not
> the entire history of the universe.
>
> The need for the previous SID file means that there needs to be a single
> lineage; SID files cannot be independently progressed.  This calls for
> central entity (or a blockchain :-).
> What we need to define unambiguously is who that entity is.
> One we are at the IANA, the Designated Expert (DE) can play this role.
> But we need to define the process leading up to this.
> (Yes, that process will evolve, and we probably also need to allow
> exceptions.
> But there must be strong guide rails that work for the vast majority of
> cases.)
>
> Adding a version number to the SID file could indeed help with
> accidents/disasters.
> But it could also lead to people thinking they can get away with
> concurrent lineages; thinking that version numbers will fix any fallout.
> That would be a disaster on its own, most likely leading to permanent
> universe splits.
> So I’m not so sure we want to open that Pandora’s box.
>
>

We already opened Pandora's box by attempting to create a 1-flat-number
globally unique, multi-module,
multi-owner object identifier. I think YANG is quite different than the MAC
address example of success
in this endeavour because YANG modules need the numbers assigned in the
development phase,
not the manufacturing phase.

YANG has many features that make it easier on the writer and harder on the
tool maker,
such as no order dependencies, but is has some guardrails. No matter how
the writer may
possibly alter or refactor a YANG module, nothing unintentional can change
the YANG identifier for
any defined data node.  SID has no such guardrails.

I think there is a practical solution for deployment, which does not
require the use of the
centrally maintained SID files, which is not realistic for 4 reasons:
  - no way to apply changes to an incorrect SID file (without a
sid-file-identifier)
  - no way for vendors to apply deviations on any YANG modules, e,.g
deviation { not-supported; }
  - the SID file generation depends on the specific revisions of all
modules imported
    and submodules included by the target YANG module
  - vendors are already failing to deploy YANG modules from a central
source model.
    The NETCONF and RESTCONF protocols have robust mechanisms to discover
and
    retrieve the actual YANG files used by the server, and vendors rely on
this feature.
    Some vendors need model branching and other complexity that make SID
assignment even harder
    (see
https://tools.ietf.org/html/draft-ietf-netmod-yang-versioning-reqs-02)

CORECONF (and SID in general) needs a SID file retrieval mechanism.
Perhaps based on YANG Data Instance Files
https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-06
A server will make the URI of this resource known somehow, which can be
used if needed,
before a client starts using SIDs.

In addition, or instead of listing YANG modules, the data is SID files,
maybe 1 super-SID-file JSON object.
It is not realistic that a client will be able to use all global SID files
based on the YANG module name
and revision date, especially in the development phase. The IANA SID file
may be useful after the YANG
module is very stable.

More solution details:
  - The WG or vendor can maintain an informal public archive of SID files.
  - The YangModels repo update process should include SID files.
https://github.com/YangModels/yang
  - Vendors still need the public SID file for the starting point, or maybe
use it unchanged
  - The SID files need <CODE BEGINS> support and probably some tool changes
in the ID-submission process
  - IANA will only archive the RFC version, just like YANG modules.



Grüße, Carsten
>


Andy