Fries, Steffen <steffen.fr...@siemens.com> wrote:
>> I thought I wrote a really nice ASCII art version of what documents
inherit from
>> RFC8366. I can't find it in my outbox... I wonder if I nuked the draft
by mistake.
>>
>> The short of it:
>> RFC8366 -> RFC8995 (voucher-request)
-> constrained-voucher (voucher-request, voucher)
-> brski-async-enroll (voucher-request)
> Would it make sense to also state the voucher for BRSKI-AE as it also
> uses the voucher and tries to argue for a new assertion type
> (agent-proximity)?
I am of two feelings here.
On the one hand, it would be IANA proceedurally simpler to include the new
assertion type into the 8366bis document.
On the other hand, this means having some kind of explanation in RFC8366bis
for the new choice, and that might force a lot of text to enter and get
reviewed.
Once RFC8366bis is published, then async-enroll can make use of the IANA
Considerations to allocate that new enum value. That won't slow async-enroll
down, because either way, it has to wait for RFC8366bis.
Where I'm a bit blurry is how stuff like the YANG in RFC8995, which uses
RFC8366 gets updated when IANA revises the module. I think, it mostly
doesn't matter because none of are generating code from YANG... AT THIS TIME.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
