> From: Michael Richardson <[email protected]> > Sent: Montag, 5. Juli 2021 00:17 > Fries, Steffen <[email protected]> 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. Yes true. Having the option doing it via an IANA considerations will be simpler for other drafts like async-enroll extending the assertions in the voucher.
> 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 <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
