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

[Ivaylo Petrov <[e-mail]>]

Hello Michael,

See my comment below.

Best regards,
Ivaylo

On Wed, Dec 25, 2019 at 12:50 AM Michael Richardson <[e-mail]>
wrote:

>
> {trying to clear out my inbox}
>
> Michel Veillette <[e-mail]> laments:
>     > The file "[e-mail]" is constructed
> with
>     > an "import ietf-voucher" and a "uses v:voucher-artifact-grouping".
> For
>     > this reason, part of the "yang-data voucher-constrained-artifact" is
>     > defined in "ietf-voucher" with SIDs assigned within the scope of this
>     > module.
>
>     > 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.
>
> I am still uncertain how this is going to work.
>

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

* In order for a draft author to obtain a SID range from IANA prior to
publication, the person needs to convince the chairs or AD that this early
allocation is needed as described in RFC7120. After that this request can
be forwarded to the designated experts that will approve it and it will be
reflected on the IANA registry.
If the author does not want to go through the trouble of early allocation
there are two cases:
  - the RFC is already published - then as it is specified in sec 6.3.2 ,
the experts will check that there is an RFC and the registration will be
done upon request.
  - the RFC is being processed by IANA right before publication - then the
same procedure is triggered by IANA as if the RFC is already published and
another party requests the range.
* Once the author has the range, he can generate the .sid file. Once there
is a published RFC or IANA is processing a document that is ready for
publication, the experts will be contacted and after that the .sid file
will be added to "IETF SID Registry”. I can see how it could be difficult
to generate the .sid file if you don't have the range, but for me this can
be achieved with appropriate instructions to the RFC editor.

I am not sure to correctly understand the citation in your email, so please
forgive me if I have completely missing the point, but for me it should
either be covered by what I have written so far or it should be related to
updating a YANG module. For me it is simpler if a module is updated to have
its .sid file updated as well (provided it has one).

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.

>
> I have not seen any progress on:
>   1) https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/
>   2) https://datatracker.ietf.org/doc/draft-ietf-core-sid/
>
> At IETF105, it seemed that the documents were unstuck, and would progress
> to WGLC soon.  Is there something holding this up other than author time?
>
> IP: I believe that this is resolved now.


> I think that allocations were made for ietf-anima-constrained-voucher, but
> I
> guess that was in the github version only.
>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>