[core] SID files and IANA

[Michael Richardson <[e-mail]>]

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