Subject: [Yot] [Anima] documenting SID usage in IETF specification (fwd) Michael Richardson: [Anima] documenting SID usage in IETF specification

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

FYI.

Subject: [Anima] documenting SID usage in IETF specification
From: Michael Richardson <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Tue, 11 Sep 2018 16:25:49 -0400
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>

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

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

---

From: Michel Veillette <[email-masked]>
Date: Wed, 12 Sep 2018 15:06:03 +0000

Hi Michael

=== About " It appears that there might be a typo in ietf-core-sid-04, section 6.1.1:"

Error fixed in http://core-wg.github.io/yang-cbor/draft-ietf-core-sid-latest.txt

=== About your general question "HOW SHOULD SID VALUES BE DOCUMENTED IN RFCs"

It will make sense to optionally add them in the IANA Considerations section of each RFC.
The allocated range should be added  to the "RFC SID range assignment" sub-registry.
The allocated SIDs should be added  to the a new sub-registry to be added to "draft-ietf-core-sid".

I will add this second sub-registry to the next revision of "draft-ietf-core-sid" in case we want to proceed this way.

Regards,
Michel

-----Original Message-----
From: Yot <[email-masked]> On Behalf Of Michael Richardson
Sent: Tuesday, September 11, 2018 5:17 PM
To: [email-masked]
Subject: [Yot] [Anima] documenting SID usage in IETF specification (fwd) Michael Richardson: [Anima] documenting SID usage in IETF specification

FYI.

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 13 Sep 2018 09:25:34 +0200 (CEST)

Hi,

Michel Veillette <[email-masked]> wrote:

[...]

> It will make sense to optionally add them in the IANA Considerations

Is the intentation that this will done for *all* YANG modules
published in the IETF, or just for the YANG models from some WGs?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Sep 2018 09:58:24 +0200

> published in the IETF, or just for the YANG models from some WGs?

The sids are machine generated, no? If so, why can't we make IANA
maintain the sids? This way, sids can be created for YANG modules as
they are needed and we do not have to cast sids into RFCs just in case
they could be needed.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Michel Veillette <[email-masked]>
Date: Thu, 13 Sep 2018 15:04:37 +0000

=== About "Is the intention that this will done for *all* YANG modules"

Just some, this why say in my response, "optionally add them".
We should further qualify when SIDs are listed in an RFC.
For me, only when needed in the text of examples of this RFC.

=== About "why can't we make IANA maintain the sids"

The intent is to transfer the registry (i.e. https://comi.space/ or equivalent) under IANA control.
Having SIDs in a single location is less error prone.

As Juergen said " sids can be created for YANG modules as they are needed".
This is exactly the approach described in draft-ietf-core-sid  section 3 (".sid" file lifecycle)
https://tools.ietf.org/html/draft-ietf-core-sid-04#section-3

Regards,
Michel

-----Original Message-----
From: Yot <[email-masked]> On Behalf Of Juergen Schoenwaelder
Sent: Thursday, September 13, 2018 3:58 AM
To: [email-masked]
Subject: Re: [Yot] [Anima] documenting SID usage in IETF specification (fwd) Michael Richardson: [Anima] documenting SID usage in IETF specification

> published in the IETF, or just for the YANG models from some WGs?

The sids are machine generated, no? If so, why can't we make IANA maintain the sids? This way, sids can be created for YANG modules as they are needed and we do not have to cast sids into RFCs just in case they could be needed.

/js

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 13 Sep 2018 17:24:32 +0200

On Sep 13, 2018, at 09:58, Juergen Schoenwaelder <[email-masked]> wrote:
> maintain the sids?

The machine generation is eady for modules that don’t have a SID history.
Always generating SIDs at IANA would mean that IANA would need to maintain the SID history as well.
As I mentioned when discussion draft evolution, that may be finer grained than what IANA cares about.
So how do we feed the history to IANA?

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Sep 2018 16:29:47 -0400

> they are needed and we do not have to cast sids into RFCs just in case

For many modules that are used in another module it make sense not to
allocate things.

The problem right now is that the tooling is not yet reliable enough to pass
to IANA.  So we need some interim strategy.

---

From: Michel Veillette <[email-masked]>
Date: Thu, 13 Sep 2018 20:42:29 +0000

Hi Michael

As a first step, the sid.py plugin need to be added to the official pyang github project.
This imply that we need to fully support python 2.x and we need to produce the required stuff (e.g. documentation, ....).

For the python script used by comi.space (i.e. sid-registry.py), we need to find a home for it.
Which github account should be used for it?

Regards,
Michel

-----Original Message-----
From: Yot <[email-masked]> On Behalf Of Michael Richardson
Sent: Thursday, September 13, 2018 4:30 PM
To: Juergen Schoenwaelder <[email-masked]>
Cc: [email-masked]
Subject: Re: [Yot] [Anima] documenting SID usage in IETF specification (fwd) Michael Richardson: [Anima] documenting SID usage in IETF specification

    > they are needed and we do not have to cast sids into RFCs just in case

For many modules that are used in another module it make sense not to allocate things.

The problem right now is that the tooling is not yet reliable enough to pass to IANA.  So we need some interim strategy.

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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 14 Sep 2018 00:15:12 +0200

> Which github account should be used for it?

We could use core-wg.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Sep 2018 16:10:42 -0400

Michel Veillette <[email-masked]> wrote:
    > This imply that we need to fully support python 2.x and we need to
    > produce the required stuff (e.g. documentation, ....).

okay, I did that awhile ago:
      https://github.com/mcr/pyang/commit/d63fba1b801d149f60e17fc0e02819b22f037d8c

Shall I make a pull request against master for this?