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

On Wed, Jan 15, 2020 at 4:17 PM Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> Carsten Bormann <cabo@tzi.org> wrote:
>     >> Yes, if we evolved the design during WG processing, then we could
> well
>     >> have dead SIDs.  We could, at WGLC or IESG approval, edit the SID
> file
>     >> and mark them as useable again.  (If there were no running code, we
>     >> could reset the SID file entirely at that point) The SID file
>     >> maintains the memory of the dead values for only as long as we want
> it
>     >> to.
>
>     > This paragraph is exactly reflecting my nightmares about this.  We
>     > could do a lot of things, if we wanted to.  What are our unambiguous,
>     > not-to-be-missed instructions that make this fool-proof?
>
> We will screw up, but the fools are often brilliant in their ability to get
> around fool-proofing :-)
>
>     > I would expect that we get rid of dead SIDs about as often as we
> revoke
>     > TCP port number assignments, i.e., essentially never.  But this
>     > requires getting around the cognitive dissonance of just having
>     > “wasted” a SID value (*): With very strongly worded instructions, I’d
>     > assume.
>
>     > Grüße, Carsten
>
>     > (*) (Note that there are way more SIDs than there are TCP ports.)
>
> The time when we are most likely to create dead SID values is during the
> development of running code between WG Adoption and WGLC.
> I think it is reasonable thing to decide, with some communication among
> implementers to reset/re-allocate.
>
> Revisions to the YANG which deprecate leafs and therefore create deprecated
> SID values are different: deployed code might still be using them.
> (If we are revising published YANG, then certainly can never reset the SID
> process!)
>

IMO there should be no concept of conformance status for a SID file.
It would be unwise to recover SIDs of obsolete YANG definitions.
It is safer to just burn the wasted range and keep range assignments small.

Do SID files need to be identified by a 3-tuple {module-name,
module-revision, sid-file-revision }

   foo@2020-01-15.1  -> { foo, 2020-01-15, 1 }

If the sid-file-revision is missing then it defaults to '1'.
Hopefully SID files will be correct and updated revisions will not be
needed.

I think a robust CORECONF client needs to know the 3-tuples of all the SID
files used by a server.
It is not enough just to know module@revision-date.  We want to be able to
rely on centralized (common) SID files and not have to retrieve each one
from each server (because they doctored the real SID file or replaced it
with their own).

Andy

> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>