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

[Ivaylo Petrov <[e-mail]>]

Hello Michael,

See my answers below

On Fri, Jan 17, 2020 at 12:34 AM Michael Richardson
<[e-mail]> wrote:
>
>
> {Trying to answer several emails in this thread at once.}
>
> Ivaylo wrote:
>     >> Thank you very much for the discussion. It brings a lot of interesting
>     >> perspectives on the problem how to make sure SIDs are most usable for
>     >> people and make it difficult to make mistakes.
>     >>
>     >> I believe there are a few important points that need to be agreed upon
>     >> before we accept how to fix anything. Here are my assumptions:
>
> "Petrov's Three Laws of SID allocation":
> [in the spirit of: https://en.wikipedia.org/wiki/Three_Laws_of_Robotics]
>
>     >> 1. we don't want to waste too much SIDs while creating SID modules
>
> I would have preferred if you hadn't made this the first point.

It was unordered list, I just wanted to be able to refer to the
different points.
I should have made that clear.

>
>
>     >> 2. we want SIDs to be as stable as possible
>     >> 3. we don't want to unpleasantly surprise people with the way SIDs
>     >> need to be used as compared to only using YANG modules.
>
>     andy> YANG module development has proven to be a messy process.
>     andy> It is the exception, not the rule, that a module stays stable from draft-00
>     andy> to RFC.
>
> So, again, I advocate that at WGLC, that the WG consider if they wish to
> remove and/or renumber any SID values that have been allocated since WG Adoption.
> (Of course, we might being doing a BIS document, so there is history before)

Sounds good to me.

>
> I see Carsten's point about the sid-file-revision could lead to people being
> attached to particular lineages.  I don't think that is as likely; but I'm
> not going to die on this hill.  It's JSON, we could add it later if we needed
> it, but it would be better to specify what it is.  I am happy with an integer
> that increments.  I think that the SID writer should probably insert it's
> name, revision, the date it ran, who ran it, the phase of the moon, and the
> current cost of a .org domain, into the file if it changes anything.

The cost of .org domain could indeed be useful :) While I can surely agree that
we should allow name, tool version and date to be inserted, I don't think this
information should be mandatory. For some YANG modules it might be fine for
 people to write by hand the .sid files (although I don't think this
is ever a good idea).

>
>     >> My question is what happens currently with an implementation that uses
>     >> a version of YANG module that has been present inside a draft, but
>     >> have differences with the version in the final RFC that is published
>     >> from the draft?
>
>     andy> The implementor is on their own, just like now for YANG,
>     andy> and just like MIB modules for 30+ years.  Vendors know that
>     andy> implementing a work-in-progress is dangerous.  WGs should know
>     andy> that publishing an RFC with zero implementation experience for the
>     andy> technology in the draft is going to produce an inferior result.
>
> I think that you intended to identify a tussle here, but maybe it was rather subtle?
>
> On the one hand: work-in-progress can be dangerous to implement.
> On the other hand: having no implementation feedback produces inferior
>        results.
>
> The discussion we are having here is how to enhance the stability of the spec
> in order to reduce cost/risk of early implementations, while at the same time
> allowing the WG to regret (and reverse) early decisions.
>
> I think that the flow I have suggested works: allocate at adoption time,
> remove dead-wood at WGLC, and make renumbering a WGLC consideration.
>
>     andy> Only the RFC versions of MIB or YANG modules is ever recorded by IANA.
>     andy> The work-in-progress versions are extracted from drafts.
>     andy> The YangModels github repo stores these modules.
>
> Andy, should sid files be included in <CODE BEGINS> then along with YANG
> modules?  We don't say anything about that, I think.  I hadn't thought about this.

I agree with that.

>
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [
>
>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core

--
Best regards,
Ivaylo