Re: [core] SID files and IANA

[ivaylo petrov <[e-mail]>]

Hello Michael,

I am sure Michelle will let us know if that is their understanding as well,
but here are my answers.

I believe that we had agreed with IANA that it is possible to use RFC7120
early allocation process for SID allocation. This means that when there is
enough interest and the document is stable enough etc, you can request SID
range allocation as described in 6.3. Alternatively, your range can be
allocated during IANA consideration review.

Now about how your SID file gets to IANA (point 1), my understanding is
that you can include your SID file in your document so that it can be added
automatically to the IANA registry after the process is followed (expert
review, etc). Alternatively, if you want to add your SID file after the RFC
is published (your point 3), you should contact IANA with all the necessary
information. After an expert review, your allocation could be handled.

About your point 2), there is no way to change existing SIDs that has
already been published. Now for the file, as it points to a yang module, if
there is a new version of the yang file, which is already guarded, I don't
see any problem for anyone to request updating of the SID file. This will
not change any existing SIDs, just possibly add new ones. For that reason I
am not sure locking is needed. Please let me know if you know of a specific
case where that might be.

Then about your point 4), IANA is not going to do the generation. This is
something the authors will have to do I am afraid. The experts will have to
verify that this generation is acceptable.

Given that draft-ietf-anima-constrained-voucher is past WGLC, I personally
don't see any problem to add it to the initial SID range allocations (sec
6.3.3) with a new range (as IANA is not responsible for the mega range that
you have mentioned). That being said, I want to be sure that the SID draft
will not be delayed in case that draft is delayed for any reason, so maybe
we will need to discuss.

Best regards,
Ivaylo



On Wed, Jul 24, 2019 at 10:42 PM Michael Richardson <[e-mail]>
wrote:

>
> {Michelle told me to CC her, but I'm not sure if this is the email she
> wanted
> me to use}
>
> As https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/
> and https://datatracker.ietf.org/doc/draft-ietf-core-sid/
>
> approach WGLC, Panos, Peter and I have been wondering in our editing of
> https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-voucher/
>
> we have struggled a bit with the SID generation process.
>
> draft-ietf-core-sid says:
> 6.4.1.  Structure
>
>    Each entry in this registry must include:
>
>    o  The YANG module name.  This module name must be present in the
>       "Name" column of the "YANG Module Names" registry.
>
>    o  A link to the associated ".yang" file.  This file link must be
>       present in the "File" column of the "YANG Module Names" registry.
>
>    o  The link to the ".sid" file which defines the allocation.
>
>    o  The number of actually allocated SIDs in the ".sid" file.
>
>    The ".sid" file is stored by IANA.
>
>
> It is this the last part that I think is not well enough defined.
> 1) How does the file get to IANA?  Is it published in the RFC
>    along with the initial YANG module?    This clearly only
>    works for YANG modules that come to IANA via RFC, and the SID
>    IANA Considerations makes it clear that SIDs will be allocated
>    via a hierarchial process of mega-ranges.
>
> 2) Does the sid file need some kind of advisory locking process,
>    such that only a single internet-draft effort can update things
>    to make bis versions of YANG modules.
>
> 3) What is the process going to be to generate SID allocations for
>    existing YANG modules that IANA already has?
>
> 4) Clearly we need to get sid.py upstreamed to pyang, and I expect to
>    take another stab at doing this, but we need to take this process
>    into account into when IANA is ready to take allocations.
>
> 5) https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-voucher/
>    got two 50 SID ranges from comi.space, in the 1,000,000->2,000,000
> space.
>    We'd ask for an early registration, but we can't until the registry
>       is created
>    a) I'd like to know if we are going to allowed to keep this allocation,
>       and if not, I'd like to know now please.
>
>    b) can we go into the 6.3.3 initial registry?  Either with the
>       current allocation, or with a new allocation.
>
>    c) time is pretty important here...
>
>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
>