[Changing subject so it's easier for me to count adoption replies later]
a) Just because this draft does not extend ONE part of rfc8366 (YANG), it does
extend the second
normative part of rfc8366, which is the encoding: rfc8366 only has CMS, with
this update
draft, voucher can have CMS or JOSE.
Citing Mirjams draft:
"Some other groups
^^^^^^^^^^^^^^^^^ that is us, ANIMA ?!
use the update tag to define optional extensions
^^^^^^^^^^^^^^^^^^^^^^^^^^ that is our situation
or use of extension points in the current protocol. "
Agreed ?
Given how Mirjams draft is not going anywhere fast, my (13)
was proposing to simply have that short, two line "rfc8366 update"
chapter saying what is being updates (optional new signing encoding
and new privacy considerations). This qualifies exactly what type
of update this RFC will be.
Cheers
Toerless
On Fri, Jul 02, 2021 at 08:53:18AM +1200, Brian E Carpenter wrote:
> 1) I've already supported adoption.
>
> 2)
>
> > (2) Up to the point where an AD or other higher power might have objections,
> > i really would like to see this document marked as an Update to RFC8366 so
> > that we have a breadcrump trail from RFC8366 to this document (personally
> > i am never quite sure what the strict requirements are for such a marking).
>
> The draft says:
> "This document does not extend the YANG definition of [RFC8366] at all, but
> accepts that other efforts such as [I-D.richardson-anima-voucher-delegation],
> [I-D.friel-anima-brski-cloud], and [I-D.ietf-anima-brski-async-enroll] do."
>
> I think that's very hard to interpret as "updates" since it explicitly says
> "does not extend".
>
> If you think this is unsatisfactory, support
> https://datatracker.ietf.org/doc/draft-kuehlewind-update-tag/
>
> Brian
>
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
