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

On Wed, Jan 15, 2020 at 1:32 PM Carsten Bormann <cabo@tzi.org> wrote:

> On 2020-01-15, at 19:28, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> >
> >
> > Carsten Bormann <cabo@tzi.org> wrote:
> >> On 2020-01-13, at 19:11, Michael Richardson <mcr+ietf@sandelman.ca>
> >> wrote:
> >>>
> >>> o SIDs never change.
> >
> >> That may require a little bit of expansion.  SIDs do change while I’m
> >> editing the document on my laptop and not telling anyone else what I’m
> >> doing.  But at some time, they freeze.
> >
> > Actually, if things go well on your laptop, they don't.
> > You might add/delete leafs and so you might roll through the SIDs
> quickly,
> > and then, because you haven't published anything, decided to reset, but
> > that's your business :-)
>
> Exactly.
>
> My question really was if we can state unambiguously when it stops being
> my business.
>
> >> What is the specific event that makes a SID allocation immutable, even
> >> if the underlying identifier goes away (and maybe comes back later)?
> >
> >> What is the way we keep this memory?
> >
> > There is the .sid file which records the allocations.
> > You use --generate-sid-file (giving your allocation) to initialize the
> > process, which creates a .sid file.  You do this only once.
> >
> > You use --update-sid-file normally to allocate SID values from a YANG
> file.
> > It keeps track not to re-use elements after the leaf is deleted, and
> makes
> > sure to re-use numbers when the leaf has not changed.  Deleting and then
> > adding a leaf with the *same name* should wind up with the SID being
> reused.
>
> So when the development of a standard is completed, we hand IANA a SID
> file with dead SIDs in it?  Or how do we maintain the memory of those dead
> SIDs?  Are there boundaries through which a SID file can go that does
> remove dead SIDs?
>
> > The SID file is some JSON.
> > Here is an example:
> >
> https://github.com/anima-wg/constrained-voucher/blob/master/ietf-constrained-voucher-request%402019-09-01.sid
>
> Yes.  The file format is fine, the question is whether we give enough
> guidance on how to handle the evolution of “the” SID file for a YANG module.
>
> I think Andy Bierman has reminded us often enough that this is hard to get
> right.
> Sorry for playing a bad copy of Andy today.
>
>
:-)

There are so many ways to mess up things with SIDs...
I hope the pyang regression tests for  SIDs are ready for the task.
There are multiple YANG lint programs and they don't all agree or get
everything right.
There are no such programs for SID (e.g. to verify everything that is
supposed to
have a SID assigned actually got an assignment).

As a hypothetical, let's assume there are undetected bugs in a SID file
or across the entire set of SID files. How do they get corrected?
The SID file itself contains no metadata indicating it is a corrected
revision of a previous SID file.

This has already proven to be a problem for YANG, and it has the
deviation-stmt
which can be used in some cases to correct broken YANG in another YANG file.

A SID file is just a JSON instance file.
There are no defined mechanisms to correct a SID file from IANA or anywhere
else.
Perhaps a "sid-file-revision" field in the SID file would help.

Grüße, Carsten
>
>
Andy

> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>