Subject: [core] SID files and IANA

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Jul 2019 22:42:22 -0400

{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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: ivaylo petrov <[email-masked]>
Date: Thu, 25 Jul 2019 09:56:15 -0400

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 <[email-masked]>
wrote:

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Jul 2019 10:58:32 -0400

As discussed in person, if SID files should be included in documents
in the way that YANG files are (wrapped in CODE BEGINS= pseudo wrapper),
then we need to say that in the document, and we probably need to
say tha the file extension should be .sid, and the filename probably
should match the yang module filename.

ivaylo petrov <[email-masked]> wrote:
    > 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.

While existing SID values are not changed, new ones may be allocated, and
it is up to the pyang --sid-* to do this against the .sid file, and so the
file needs to be available.

What is more than one entity does this to a particular module?
The locking can occur at the WG level for IETF streams, but there is a goal
to support processes in industry that are using SID not directly in IETF
protocols.

    > verify that this generation is acceptable.

Fair enough.

    > Given that draft-ietf-anima-constrained-voucher is past WGLC, I

draft-ietf-anima-bootstrapping-keyinfra is past WGLC, and at the IESG.
(That's non-constrained BRSKI)

draft-ietf-anima-constrained-voucher is not yet in WGLC, sadly.

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

I would like to ask for a new range in the IANA range, in this document then.
I need two 50 unit ranges, or a single larger block if you like.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Jul 2019 16:48:13 -0400

On 2019-07-25 9:56 a.m., ivaylo petrov wrote:
> 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.

I have opened a github issue against the draft asking for the allocation 
to be included.  I'd like to get the running code updated ASAP with the 
new values, and we'll have to respin our document and build new sid files.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Jul 2019 20:34:18 -0400

>> Given that draft-ietf-anima-constrained-voucher is past WGLC, I

{mcr: it's not past WGLC}

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

Michael Richardson <[email-masked]> wrote:
    > I have opened a github issue against the draft asking for the
    > allocation to be included.  I'd like to get the running code updated
    > ASAP with the new values, and we'll have to respin our document and
    > build new sid files.

I meant to paste this, but I hit send instead:
  https://github.com/core-wg/yang-cbor/issues/11