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

[Michael Richardson <[e-mail]>]

{AD+Chair action requested below}

Ivaylo Petrov <[e-mail]> wrote:
    >> This example raises an interesting point. "ietf-voucher" have been
    >> defined without considering a possible constrained implementation and
    >> have no SID list or .sid file included in RFC 8366. SIDs has been
    >> assigned after the fact, as allowed by
    >> https://tools.ietf.org/html/draft-ietf-core-sid-07#section-3. If we
    >> include a SID list or .sid file for
    >> "[e-mail]", part of the SIDs  will be in
    >> a RFC, the rest won't. To avoid such situation, we should rely entirely
    >> on an IANA registry for all .sid files defined by RFCs.

    mcr> I am still uncertain how this is going to work.

I think that the major issue is that I am still not convinced that IANA is
prepared to operate pyang itself.  Conversations at IETF105 and IETF106 did
not convince me that they (IANA) completely understood what they are being
asked to do.
For instance, I'm not convinced that there is a support process for IANA to
get bugs fixed in the sid.py module.

(I would be pleased to be convinced otherwise)

    ivaylo> IP: Let me try to summarize how the sid range obtaining and
    ivaylo> allowaction process is currently defined and please let me know
    ivaylo> if it is still not clear enough or if you have any
    ivaylo> concerns. After that I share some thoughts for module updates.

Yes, I understand the early allocation process.

    ivaylo> - the RFC is already published - then as it is specified in sec 6.3.2 ,
    ivaylo> the experts will check that there is an RFC and the registration will
    ivaylo> be done upon request.

Early Allocations are done for a limited period of time, IANA is allowed to
reclaim the space if the document does not proceed.

If when an author asks for early allocation for a YANG module that references
other modules which are already published, then there are multiple things that could
happen:

1) IANA could do a permanent allocation for the referenced modules, entering
   the sid file in as well.
   {this may cause a recursion quite deep initially}

2) IANA could do an early allocation for the referenced modules, marking them
   as such, and potentially reclaiming.

(1) has the problem that it may cause a bunch of pollution.
(2) has the problem that the referenced allocation will need to be reference
    counted for all/any documents that reference it.

I suspect that the problem will be short-lived pain, and that doing (1) is
the right thing, and that we might want to take the hit in WG and Expert
Review in a proactive manner.  (I am happy to help here)

But, there is also:

(3) a document could ask for an early SID allocation, referencing a YANG
    module which is in another WG, or worse, not yet adopted, and therefore
    not subject to Early Adoption rules!
    This may be a problem we do not to fix (Just get the document adopted),
    but I think that we should be clear about this.


My recommendation is that all YANG modules, upon being *ADOPTED* by a WG,
have a SID allocation done.  Yes, the document will get revised, but the
SID system is designed to deal with this.

I think that doing this requires an IESG and IANA decision.
I think that getting through this before March is important.

The CORE WG has had a series of virtual interims (I see none scheduled, I
assume that is an oversight), and maybe we could invite IANA and a couple of
IESG ADs to confer and get clarity here.

    > If this is done, the situation where a module M1 is updated and it is
    > used by another module M2 would not cause issues as it is should match
    > the case where the SIDs are generated for the first time. On the other
    > hand, if someone else generates a .sid file that includes the extra
    > values that come from the new version of module M1, this is not going
    > to cause real issues as there could be two SID values that represent
    > the same YANG item, which means that the .sid file for M1 can still be
    > updated.

Agreed!

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