Subject: [Anima] documenting SID usage in IETF specification

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Sep 2018 16:25:49 -0400

tl;dr> ****  HOW SHOULD SID VALUES BE DOCUMENTED IN RFCs?  ****

BACKGROUND:

The ANIMA WG is using https://tools.ietf.org/html/draft-ietf-core-yang-cbor-06
(expired in August, I hope it will be updated soon) and
https://tools.ietf.org/html/draft-ietf-core-sid-04 to encode RFC8366
defined vouchers in CBOR.  They are then signed with CMS or COSE.

We have been using the sid.py pyang extension created by Michel Veillette
to allocate the sid from the YANG definitions.  We have two questions.

QUESTIONS:
1) as one can see at:
   https://tools.ietf.org/html/draft-ietf-anima-constrained-voucher-02#section-6.1.2

After the traditional dump of the yang tree view, we are showing the
resulting assignments in a table in the ID (slightly edited from above):

      SID Assigned to
   --------- --------------------------------------------------
     1001150 module ietf-constrained-voucher-request
     1001154 data .../voucher
     1001155 data .../assertion
     1001156 data .../created-on
     1001157 data .../domain-cert-revocation-checks
     1001158 data .../expires-on
     1001159 data .../idevid-issuer
     1001160 data .../last-renewal-date
     1001161 data .../nonce
     1001162 data .../pinned-domain-cert
     1001163 data .../prior-signed-voucher-request
     1001164 data .../proximity-registrar-cert
     1001165 data .../proximity-registrar-subject-public-key-info
     1001166 data .../serial-number

the 1001150:50 space of SIDs was assigned by comi.space.  This display was
produced originally by minor editing of the result of the --list-sids option
to the sid.py plugin.    The allocation does not start at 1001150 because
some IDs are used to number the YANG modules that were included.

We are among the first users of the sid.py plugin, and the (re-)numbering of
all of the include modules in this way is likely a mistake, which has not
been solved.  Before I solve the underlying problems and fix the output to
produce what I think I want, we felt it was important to ask the WG...

****
        HOW SHOULD SID VALUES BE DOCUMENTED IN RFCs?
****

I'm not enthusiastic about including the .sid files only, but it could be
done, and we could say that they are normative, while --list-sid style above
is not.

SHOULD ietf-core-sid say something about this?

2) Given that https://tools.ietf.org/html/draft-ietf-core-sid-04#section-6.1
   allocates the first 1,000,000 to IANA,   then comi.space has
   started to give out entries > 1,000,000 it seems that comi.space ought
   to get the 1,000,000 -> 1,999,999 "mega-range" assigned to it.

   The question is, what should a document that has allocated a range from
   comi.space do it's in IANA Considerations?

   If ietf-core-sid could be advanced sooner, and IANA could create the
   registry,  we could ask for an early allocation value in the 100,000 ->
   999,999 range from IANA.

   Alternatively, ietf-core-sid-04 could allocate a range to our document
   in the section 6.1.2  "RFC SID range assignment" sub-registry.

3) It appears that there might be a typo in ietf-core-sid-04, section 6.1.1:

  o  The range of 100,000 to 999,999 is reserved for standardized YANG
      modules.  The IANA policy for future additions to this sub-
      registry is "Specification Required" [RFC5226].  Allocation within
      this range requires publishing of the associated ".yang" and
      ".sid" files in the YANG module registry.

   +-------------+---------------+------------------------+
   | Entry Point | Size          | IANA policy            |
   +-------------+---------------+------------------------+
   | 0           | 1,000         | IETF review            |
   | 1,000       | 59,000        | RFC required           |
   | 60,000      | 40,000        | Experimental use       |
   | 100,000     | 1,000,000,000 | Specification Required |
   +-------------+---------------+------------------------+
                   ^^^^^^^^^^^^^-- seem to be too many zeros

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 12 Sep 2018 00:12:30 +0200

> SHOULD ietf-core-sid say something about this?

Yes, we should have a common way of handling SID allocations in RFCs.

draft-ietf-core-sid sounds like a natural way to place this, but what goes into what document is often a question of who has time to write something at a particular point in time.  So let’s discuss this with the authors.

In any case, this probably should stay at the level of a suggestion more than prescribing a normative way of doing things — the conventions we use for this may evolve faster than the rest of the technical content of draft-ietf-core-sid.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Sep 2018 19:09:59 -0400

> Yes, we should have a common way of handling SID allocations in RFCs.

It's not just allocations, but presentation.

    > draft-ietf-core-sid sounds like a natural way to place this, but what
    > goes into what document is often a question of who has time to write
    > something at a particular point in time.  So let’s discuss this with
    > the authors.

agreed.

    > In any case, this probably should stay at the level of a suggestion
    > more than prescribing a normative way of doing things — the conventions
    > we use for this may evolve faster than the rest of the technical
    > content of draft-ietf-core-sid.

I don't want a prescription either, but rather a BCP that evolves.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Sep 2018 16:32:39 -0700

On Tue, Sep 11, 2018 at 3:12 PM, Carsten Bormann <[email-masked]> wrote:

> draft-ietf-core-sid sounds like a natural way to place this, but what goes
> into what document is often a question of who has time to write something
> at a particular point in time.  So let’s discuss this with the authors.
>
> In any case, this probably should stay at the level of a suggestion more
> than prescribing a normative way of doing things — the conventions we use
> for this may evolve faster than the rest of the technical content of
> draft-ietf-core-sid.
>
>
You probably want to make a clear distinction between Internet Drafts with
volatile SID assignments
and RFCs with permanent SID assignments.

Do you want early implementation (of modules using SID)  to be as painful
as possible or as seamless as possible?
Renumbering SID assignments may be extremely disruptive to actual
deployments.
Correctness of a SID file within a source document is not the same thing as
correctness of all SID files
across an entire administrative domain.

I agree the administration of SID assignments is out of scope for CORE WG
but punting
the problem to vendors or operators will not be good enough.

Grüße, Carsten

Andy

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

---

From: Peter van der Stok <[email-masked]>
Date: Wed, 12 Sep 2018 17:15:25 +0200

Hi all,

The numbering of the SIDs in our case should be as stable as possible
after publication as RFC.
A permanent assignment of the numbers, like the content-format numbers,
would be very much appreciated.
Using the same already allocated numbers for other RFCs would be quite
disastrous.

Maintenance of (part of) the comi.space by a organisation like IANA
could be a possibility.

Peter
Andy Bierman schreef op 2018-09-12 01:32:

>> draft-ietf-core-sid sounds like a natural way to place this, but what goes into what document is often a question of who has time to write something at a particular point in time.  So let's discuss this with the authors.
>> 
>> In any case, this probably should stay at the level of a suggestion more than prescribing a normative way of doing things -- the conventions we use for this may evolve faster than the rest of the technical content of draft-ietf-core-sid.
> 
> You probably want to make a clear distinction between Internet Drafts with volatile SID assignments 
> Do you want early implementation (of modules using SID)  to be as painful as possible or as seamless as possible? 
> Renumbering SID assignments may be extremely disruptive to actual deployments. 
> Correctness of a SID file within a source document is not the same thing as correctness of all SID files 
> I agree the administration of SID assignments is out of scope for CORE WG but punting 
>> https://www.ietf.org/mailman/listinfo/core [1]
> 
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

Links:
------
[1] https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 12 Sep 2018 18:14:58 +0200

> On Sep 12, 2018, at 17:15, Peter van der Stok <[email-masked]> wrote:
> 
> Hi all,
> 
> The numbering of the SIDs in our case should be as stable as possible after publication as RFC.
> A permanent assignment of the numbers, like the content-format numbers, would be very much appreciated.
> Using the same already allocated numbers for other RFCs would be quite disastrous.

Yes, I think that part is clear.

What Andy pointed out is that we also need to have an idea of how to evolve a draft in a way that minimizes damage from changing those numbers during the development of that draft.  So we need to start allocating and managing SID numbers early in their lifetime, at least from the point of time when a draft is becoming an “implementation draft” (as opposed to just an idea that wants to be discussed).  That is not something we have traditionally done with IANA registrations, which are traditionally considered a scarce resource and thus should only be assigned to finished (or near-finished, hence “early allocations”) protocols.

My proposal would be:

— have a more explicit way of designating drafts as Implementation Drafts.   Basically, any SIDs allocated before that are without protection,  but once we have an Implementation Draft, the SIDs used in that will not be re-used.  (Intermediate versions between Implementation Drafts would again have any new SIDs in unprotected state until another Implementation Draft is declared.)

— have a way to include the SID file in the document (draft, RFC).  This is not beautiful, but unless we invent another representation for that information, that is the interchangeable form.  (If we do invent another representation, maybe we should always use that?)

Grüße, Carsten

> 
> Maintenance of (part of) the comi.space by a organisation like IANA could be a possibility.
> 
> Peter

---

From: Andy Bierman <[email-masked]>
Date: Wed, 12 Sep 2018 09:32:10 -0700

On Wed, Sep 12, 2018 at 9:14 AM, Carsten Bormann <[email-masked]> wrote:

> What Andy pointed out is that we also need to have an idea of how to
> evolve a draft in a way that minimizes damage from changing those numbers
> during the development of that draft.  So we need to start allocating and
> managing SID numbers early in their lifetime, at least from the point of
> time when a draft is becoming an “implementation draft” (as opposed to just
> an idea that wants to be discussed).  That is not something we have
> traditionally done with IANA registrations, which are traditionally
> considered a scarce resource and thus should only be assigned to finished
> (or near-finished, hence “early allocations”) protocols.
>
> My proposal would be:
>
> — have a more explicit way of designating drafts as Implementation
> Drafts.   Basically, any SIDs allocated before that are without
> protection,  but once we have an Implementation Draft, the SIDs used in
> that will not be re-used.  (Intermediate versions between Implementation
> Drafts would again have any new SIDs in unprotected state until another
> Implementation Draft is declared.)
>
> — have a way to include the SID file in the document (draft, RFC).  This
> is not beautiful, but unless we invent another representation for that
> information, that is the interchangeable form.  (If we do invent another
> representation, maybe we should always use that?)
>
>
Thanks for summarizing the issue and also for a very practical solution.
The SID file needs to be included in the I-Ds and the RFC.
The Implementation Draft idea sounds like the old discussions about
"working group snapshots"
but it very useful info to know the difference:

   - the module and SID assignments are not stable at all and MAY change at
any time in the future
   - the module and SID assignments are from an Implementation Draft and
SHOULD remain the same in future revisions
   - the module and SID assignments are from an RFC and MUST remain the
same in future revisions

Grüße, Carsten
Andy

> something at a particular point in time.  So let's discuss this with the
> authors.
> >>
> more than prescribing a normative way of doing things — the conventions we
> use for this may evolve faster than the rest of the technical content of
> draft-ietf-core-sid.
> >>
> >>
> >> Do you want early implementation (of modules using SID)  to be as
> painful as possible or as seamless as possible?