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

[Andy Bierman <[e-mail]>]

On Thu, Jan 16, 2020, 3:34 PM 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.
>
>     >> 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



I agree with this plan.


> 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.
>
>     >> 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?
>

It is a delicate balance.
Vendors are not supposed to complain when the draft changes and running
code has to be rewritten.
.

>
> 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.
>
>
>
>


Yes. They are code components

Andy


> --
> ]               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
>