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

[Michael Richardson <[e-mail]>]

FYI.

--- Begin Message ---

   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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

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

--- End Message ---