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 protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
