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

[Ivaylo Petrov <[e-mail]>]

Hi Michael,

Thank you for the detailed explanation! I understand your concerns
now. Please find my comments below.

On Fri, Jan 10, 2020 at 4:14 AM Michael Richardson
<[e-mail]> wrote:
>
>
> {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)

I remember that during the discussion with IANA we considered that
the authors and the expert will be responsible for the running of the
pyang tool and IANA will only take the .sid file and store it. The .sid
files will be provided to IANA when there is a request to register the
.sid file - however that is done. Do you see an error in our reasoning
other that the fact that we might be burdening the authors too much?
Does this seem acceptable to you?

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

Yes, that issue does not seem obvious. Currently I don't see a
blocking issue with allocating SIDs for all YANG modules once
a draft is adopted,  so maybe this is truly our best way to avoid
problems.

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

--
Best regards,
Ivaylo