Voucher extension registry #79
Conversation
|
@mcr I'm unable to review this or understand this without further context. Why not use one of the design team calls to go over this? That would be very useful. I very much doubt at this point that we need the registry defined by this PR, but obviously you do so I must be missing some hugely important point. There are 2 different extendibility reasons in general:
In both cases I don't see a need for any registry or the need to include data elements any differently in the voucher than the way we've defined so far. |
|
Esko Dijk ***@***.***> wrote:
@mcr I'm unable to review this or understand this without further
context. Why not use one of the design team calls to go over this? That
would be very useful.
I intend to, but I only managed to finish this last night :-)
I also intend to discuss this Thursday, if there is time.
I very much doubt at this point that we need the registry defined by
this PR, but obviously you do so I must be missing some hugely
important point.
That's how RFC8520 did it, and I'm proposing that in draft-richardson-netmod-atrest-extensions.
There are 2 different extendibility reasons in general:
1. vendor-specific, private extensions just to send data to the Pledge
(no public definitions required of the data fields)
a) Vendor can define a YANG module, ask for SID values, or use the 60,000 to 99,999 range.
b) ... (me re-reads RFC9595...) damn, I thought we made allowance for using
PEN values. We should do that.
c) for JSON serialization, no big problem, just do vendor.example:foobar as
the map key.
2. IETF-defined voucher extensions (assume we can just spin another
RFC to do these, just like 8366bis does?)
Yes, we can just spin this again, and that's the YANG way.
RFC8520 didn't do this, as it turns out, and I wish I hadn't spent three
years sorting that out, and had just noticed and done what 8520 did.
In both cases I don't see a need for any registry or the need to
include data elements any differently in the voucher than the way we've
defined so far.
…--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] ***@***.*** http://www.sandelman.ca/ | ruby on rails [
|
|
@mcr So let's discuss in one of the Tuesday calls or otherwise IETF (if agenda/time permits). Just wanted to note that with CBOR vouchers with SIDs, it's also possible to add a few string-key / value pairs as well i.e. mix SIDs and string-keys. This allows the "vendor.example:foobar" key also. It's just not very efficient. The range 60,000 to 99,999 is Experimental Use which formally seems to disallow use by a vendor for its products, although in practice it wouldn't hurt. Maybe the range 2550-2600 could be allocated to vendor-specific usage in both vouchers and voucher-requests. Or alternatively allocate a single SID in the 2450-2499 range and a single SID in the 2500-2549 range for holding a container (map) of vendor-specific keys/values. The latter would be easier to understand and easier to avoid encoding mistakes. |
| IANA is asked to create a registry of extensions as follows: | ||
|
|
||
| Registry name: Voucher Extensions | ||
| Registry policy: Standards Action |
There was a problem hiding this comment.
| Registry policy: Standards Action | |
| Registry policy: First Come First Served |
| Items within that list are strings (in JSON serialization), or integers (in CBOR serialization), as defined by the Voucher Extension Registry. | ||
|
|
||
| Extensions are full YANG moduals, which are subject to SID allocation process described in {{RFC9254}}. | ||
| When serialized the extensions are placed in a sub-map in the value section. |
There was a problem hiding this comment.
Oops, misunderstood. Maybe
| When serialized the extensions are placed in a sub-map in the value section. | |
| When an extension is serialized, the extension is placed in a sub-map in the value section. |
| The "extensions" list attribute definied in this model allows for new standard extensions to be defined. | ||
| Items within that list are strings (in JSON serialization), or integers (in CBOR serialization), as defined by the Voucher Extension Registry. | ||
|
|
||
| Extensions are full YANG moduals, which are subject to SID allocation process described in {{RFC9254}}. |
There was a problem hiding this comment.
| Extensions are full YANG moduals, which are subject to SID allocation process described in {{RFC9254}}. | |
| Extensions are full YANG modules, which are subject to the SID allocation process described in {{RFC9254}}. |
| @@ -84,6 +84,17 @@ RFCEDITOR: please replace XXXX with the RFC number assigned. | |||
| Future work MAY create verification requirements based on | |||
| this node."; | |||
| } | |||
|
|
|||
| leaf-list extensions { | |||
| type string { | |||
There was a problem hiding this comment.
If it's a list of strings, how do we envision the CBOR serialization?
Formally it also have to be strings. It would be strange to put SID integer values in string e.g. [ "123", "456" ] ?
close #74