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

[Andy Bierman <[e-mail]>]

On Thu, Jan 16, 2020, 3:17 PM Michael Richardson <[e-mail]>
wrote:

>
>     mcr> Revisions to the YANG which deprecate leafs and therefore create
>     mcr> deprecated
>     mcr> SID values are different: deployed code might still be using them.
>     mcr> (If we are revising published YANG, then certainly can never reset
>     mcr> the SID process!)
>
> Andy Bierman <[e-mail]> wrote:
>     andy> IMO there should be no concept of conformance status for a SID
> file.
>     andy> It would be unwise to recover SIDs of obsolete YANG definitions.
>     andy> It is safer to just burn the wasted range and keep range
> assignments
>     andy> small.
>
> I think that we are in agreement here.
>
>     andy> Do SID files need to be identified by a 3-tuple {module-name,
>     andy> module-revision, sid-file-revision }
>
>     andy> foo@2020-01-15.1 -> { foo, 2020-01-15, 1 }
>
> seems right to me.
>
>     andy> I think a robust CORECONF client needs to know the 3-tuples of
> all the
>     andy> SID files used by a server.
>     andy> It is not enough just to know module@revision-date. We want to
> be able
>     andy> to
>     andy> rely on centralized (common) SID files and not have to retrieve
> each
>     andy> one
>     andy> from each server (because they doctored the real SID file or
> replaced
>     andy> it with their own).
>
> I think that you are saying that SID requires changes to the YANG module
> meta
> data which I think is available in some YANG (meta-)module?
> If we all agree that SID values can be deprecated, but never reused (And I
> do
> not hear anyone saying otherwise), then the highest sid-file-revision is
> always the correct one.
>
> If we revise the module, and we get a new module-revision, I do not think
> that we reset the sid file, nor do we reset the sid-file-revision.  Do you
> concur?
>
>
> I think only the last sid file and the new module revision are needed,
> like Carsten said.
>

The sid revision would start at 1 for each module, revision date.
I still think it is useful to be able to correct a sid file with errors.
All code has bugs and there will be bugs found that will require edits to
the sid file.

Andy


--
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>