Subject: [core] FW: Extension to YANG Catalog.org for YANG Schema Identifier (SID)

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 28 Jan 2022 14:44:04 +0000

This discussion regarding SIDs started in the context on YANG Catalog but has subsequently evolved onto my "discuss" topic on https://datatracker.ietf.org/doc/draft-ietf-core-sid.  Hence copying my response to core, along with a couple of replies.

Regards,
Rob

-----Original Message-----
From: Rob Wilton (rwilton) 
Sent: 27 January 2022 18:52
Subject: RE: Extension to YANG Catalog.org for YANG Schema Identifier (SID)

> -----Original Message-----
> From: Michael Richardson <[email-masked]>
> Sent: 27 January 2022 14:21
> 
> Carsten Bormann <[email-masked]> wrote:
>     > Adding a second set of SIDs in a different range,
>     > maybe, but I’m not sure that will work so great, because packages
>     > operate on modules, not on SID files, so it will be hard to find out
>     > which of multiple SID files for a module a system actually knows.
> 
> And, I think, even if we did such a thing, that it would probably require a
> YANG
> module revision/version.

This is really the discuss topic.  Perhaps it might help if I try and attend one of the CORE interim meetings?

I still don't understand exactly what the SIDs represent.  I thought that they were intended to be a numeric equivalent to the fully qualified path to the data node in the module schema, i.e. I was expecting to be able to map them equivalently to how I would map a YANG identifier which is automatically scoped to version of the YANG module that is "implemented" by the server.  But as soon as you start bringing module revision/versions into the equation then they stop being numeric equivalents to the YANG identifiers, and instead they are start representing the tuple of (path, set of module revisions).

I might be missing something, but it feels like this is introducing a lot of additional complexity.

Thanks,
Rob

> 
> My understanding is that Yang catalog already has YANG module version as a
> primary key.
> 
> --
> Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 28 Jan 2022 14:45:09 +0000

-----Original Message-----
From: Michael Richardson <[email-masked]> 
Sent: 27 January 2022 22:32
To: Rob Wilton (rwilton) <[email-masked]>
Subject: Re: Extension to YANG Catalog.org for YANG Schema Identifier (SID)

    > attend one of the CORE interim meetings?

Perhaps....  I'd want Andy there too.

    > I still don't understand exactly what the SIDs represent.  I thought
    > that they were intended to be a numeric equivalent to the fully
    > qualified path to the data node in the module schema, i.e. I was
    > expecting to be able to map them equivalently to how I would map a YANG
    > identifier which is automatically scoped to version of the YANG module
    > that is "implemented" by the server.  But as soon as you start bringing
    > module revision/versions into the equation then they stop being numeric
    > equivalents to the YANG identifiers, and instead they are start
    > representing the tuple of (path, set of module revisions).

I think that you have an accurate view.
If there was YANG module "butter @ 2020-10-01", and it had attributes:
   land-o-lakes: text    SID: 1
   parkay: text          SID: 2
   chives: integer       SID: 3

and then we created a new revision: "butter @ 2022-01-10", which obsoletes
"parkay", and adds a new attribute "garlic":
   garlic: integer       SID: 4

A server which wanted to use garlic would have to determine that it had the
revision that included garlic, right?

So the Yang Catalog just needs to include the revision, which I think it
already doeds.

I feel that this email should probably go to the list?

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 28 Jan 2022 14:45:42 +0000

-----Original Message-----
From: Carsten Bormann <[email-masked]> 
Sent: 27 January 2022 23:09
To: Michael Richardson <[email-masked]>
Subject: Re: Extension to YANG Catalog.org for YANG Schema Identifier (SID)

> revision that included garlic, right?

The observation that is more interesting to me at the moment is that with this kind of allocation/deprecation policy, software that converts between YANG SIDs and YANG names does not need to be aware of the module versions in place.

I’ll call an allocation/deprecation policy that has this property “benign”.

Now there may be reasons to want a more aggressive deprecation/allocation policy.  E.g., someone sees garlic as a valid substitute of parkay (I have no idea what that is, and it has the wrong type, but ignore that for the moment), so they might want to allocate 2 to parkay in @2022-01-10.  That would destroy the desirable property provided by the benign policy.

I understand Rob’s discuss essentially as a question whether we shouldn’t strive to obtain this property by creating all preconditions for that.  That property may be more important than properties we could derive from more aggressive policies.

Note that there will always be a small crack in that picture:
Someone could, independently from whoever is authoritative for the module, create their own SID file for a module (particularly likely with legacy modules or modules from vendors fast asleep).  This would not create a dependency on module revisions, but it would stop the mapping from being a bijection.  I think this state of affairs is still more desirable than a dependency on revisions.

So I’m leaning towards proposing to resolve the remaining discuss by being more strict, cultivating a bijection with the occasional jump-the-gun accident (which then will be painful). 

Grüße, Carsten