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

[Michael Richardson <[e-mail]>]

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

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.

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