Subject: [Anima] Resending: Call for adoption: draft-richardson-anima-jose-voucher

From: Toerless Eckert <[email-masked]>
Date: Thu, 1 Jul 2021 18:33:35 +0200

[apologies for mixing up june with july. resending to be formally correct. Thanks Bill!]

This emails starts a two week call for adoption for draft-richardson-anima-jose-voucher
The adoption call does end when July 14 has passed for everyone on planet earth.

Justification:

This draft is a core normative dependency for the ANIMA WG document
draft-ietf-anima-brski-async-enroll (BRSKI-AE). It does effectively
not constitute new work, but was separated out during development
of that draft so that the jose-signed-voucher can more easily be
referenced and reused by other work in the IETF that may not need to
inherit, refer to the whole BRSKI-AE solution.

Toerless, for the ANIMA chairs.

On Thu, Jul 01, 2021 at 08:44:08AM +1200, Brian E Carpenter wrote:
> > The JSON Compact Serialization is examplained in section 3.1 or section 
> 7.1
> 
> examplained?? A great word, but not in my dictionary.
> 
> Mainly I can't understand this draft because it's way outside my expertise, but it seems necessary so I would support adoption.
> 
> Regards
>    Brian
> 
> On 30-Jun-21 12:30, Michael Richardson wrote:
> > 
> > I have reposted draft-richardson-anima-jose-voucher.
> > It's very short.  Most of the document is examples.
> > 
> > Can we adopt this so that it does not keep brski-async-enroll from
> > progressing when the time comes?
> > 
> > [email-masked] wrote:
> >     > Name:		draft-richardson-anima-jose-voucher
> >     > Revision:	01
> >     > Title:		JOSE signed Voucher Artifacts for Bootstrapping Protocols
> >     > Document date:	2021-06-23
> >     > Group:		Individual Submission
> >     > Pages:		15
> >     > Html:           https://www.ietf.org/archive/id/draft-richardson-anima-jose-voucher-01.html
> >     > Diff:           https://www.ietf.org/rfcdiff?url2=draft-richardson-anima-jose-voucher-01
> > 
> >     > Abstract:
> >     > This document describes a serialiation of the RFC8366 voucher format
> >     > to a JSON format is then signed using the JSON Object Signing and
> >     > Encryption mechanism described in RFC7515.
> > 
> > 
> > --
> > Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
> >            Sandelman Software Works Inc, Ottawa and Worldwide

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 1 Jul 2021 22:05:49 +0200

Here is what i would like to see fixed in the draft for adoption
(no idea what hat i am wearing - contributor and/or chair)

and also some questions.

Line numbers from nits

> 13	   This document describes a serialiation of the RFC8366 voucher format
> 14	   to a JSON format is then signed using the JSON Object Signing and
> 15	   Encryption mechanism described in RFC7515.

Welcome to the club of people too lazy to use spell checkers.

(1) suggested replacement text to provide better context setting:

RFC8366 defines a digital artefact called voucher as a YANG-defined JSON
document that has been signed using a Cryptographic Message Syntax (CMS) structure.
This memo introduces a variant of the voucher structure in which CMS is
replaced by the JSON Object Signing and Encryption (JOSE) mechanism described in RFC7515
to better support use-cases in which JOSE is preferred over CMS.

(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).
 
> 51	Table of Contents
> 
> 53	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
> 54	   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
> 55	   3.  JSON Web Signatures . . . . . . . . . . . . . . . . . . . . .   3
> 56	     3.1.  Unprotected Header  . . . . . . . . . . . . . . . . . . .   4
> 57	     3.2.  Protected Header  . . . . . . . . . . . . . . . . . . . .   4
> 58	   4.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   4
> 59	   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
> 60	   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
> 61	     6.1.  Media-Type Registry . . . . . . . . . . . . . . . . . . .   4
> 62	       6.1.1.  application/voucher-jose+json . . . . . . . . . . . .   4
> 63	   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
> 64	   8.  Changelog . . . . . . . . . . . . . . . . . . . . . . . . . .   5
> 65	   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
> 66	     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
> 67	     9.2.  Informative References  . . . . . . . . . . . . . . . . .   6
> 68	   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .   7
> 69	     A.1.  Example Voucher Request (from Pledge to Registrar)  . . .   7
> 70	     A.2.  Example Parboiled Voucher Request (from Registrar to
> 71	           MASA) . . . . . . . . . . . . . . . . . . . . . . . . . .   9
> 72	     A.3.  Example Voucher Result (from MASA to Pledge, via
> 73	           Registrar)  . . . . . . . . . . . . . . . . . . . . . . .  12
> 74	   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15
> 
> 76	1.  Introduction
> 
> 78	   [RFC8366] describes a voucher artifact used in [RFC8995] and
> 79	   [RFC8572] to transfer ownership of a device to from a manufacturer to
> 80	   an owner.  That document defines the base YANG module, and also the
> 81	   initial serialization to JSON [RFC8259], with a signature provided by
> 82	   [RFC5652].

(3) I like to avoid playing "can you remember that RFC number", by prefacing newly
introduced RFC numbers with their title or otherwise better known abbreviations.

"A Voucher Artifact for Bootstrapping Protocols", [RFC8366] describes a voucher
artifact used in i"Bootstrapping Remote Secure Key Infrastructure (BRSKI)", [RFC8995] and
"Secure Zero Touch Provisioning (SZTP)" RFC8572] to transfer ownership of a
device from a manufacturer to an owner.  That document defines the base YANG module,
 and also the initial mapping to "The JavaScript Object Notation (JSON) Data Interchange Format",
[RFC8259], with a signature provided by "Cryptographic Message Syntax (CMS)", [RFC5652].

Sure, thats a mouthfull of name dropping, but beter than numbers bingo.

Likewise full titles would be better for following instances, like CBOR, but i'l
not comment on all places, you get the idea.

(4) Also note the replacement of serialization to mapping as you use mapping in th
following paragraphs. Not sure what the best word is, but lets use it consistently.

> 84	   Other work, [I-D.ietf-anima-constrained-voucher] provides a mapping
> 85	   of the YANG to CBOR [RFC8949] with a signature format of COSE
> 86	   [RFC8812].
> 
> 88	   This document provides an equivalent mapping of JSON format with the
> 89	   signature format in JOSE format [RFC7515].

(5) Here a quick reason why this document exist should be. Something like:

The encoding specified in this document is required for [I-D.ietf-anima-brski-async-enroll]
and may be required and/or preferred in other use-cases, for example when
JOSE is already used in other parts of the use-case, but CMS is not.

> 91	   This document does not extend the YANG definition of [RFC8366] at

(6) Would s/extend/change/ be correct ? "change" would be better if correct.
If "change" is not correct, then i am missing something.

> 92	   all, but accepts that other efforts such as
> 93	   [I-D.richardson-anima-voucher-delegation],
> 94	   [I-D.friel-anima-brski-cloud], and
> 95	   [I-D.ietf-anima-brski-async-enroll] do.  This document supports
> 96	   signing any of the extended schemas defined in those documents and
> 97	   any new documents that may appear after this one.

(7) How will any scheme select which type of voucher to use in between "cms" or "jose" ?

Seems to me we are implying and maybe should write out somehing like this:

With the availability of different encoded vouchers, it is up to the
specification of how the voucher is transported to indicate/decide which voucher format
is used/carried. There is no provison across the different voucher formats
that a receiver could safely recognize which format it uses unless
additional context is provided. For example, [RFC8995] provides this context via
the  MIME-Type for the voucher payload.

(i hope this is a correct assessment).

I think this document might be the first one that warrants this warning given
how this seems like the first new voucher format defined by itself without
being tied to a use-case - like constrained-voucher is really constrained-brski,
although the same note would make sense there too. Or we also split that
up...

> 109	   [RFC7515] defines two serializations: the JWS Compact Serialization
> 110	   and the JWS JSON Serialization.  This document restricts itself to
> 111	   the JWS Compact Serialization (JWT) format.

(8) ...because ... ?!

> 113	   The [RFC8366] JSON structure consists of a nested map, the outer part
> 114	   of which is:
> 
> 116	   { "ietf-voucher:voucher" : { ..some items }}

(9) is "some items" the "inner part" ? If so then maybe use that term bcause
you are also using "outer part", so i would wonder where the "inner part" is
if it wasn't showing up in the structure.

> 118	   this is considered the JSON payload as described in [RFC7515] section
> 119	   3.

(10) It is actually called the JWS payload if i read rfc7515 correctly, and i
wonder if this whole draft would also not more correctly be called draft-richardson-anima-jws-voucher

> 121	   The JSON Compact Serialization is examplained in section 3.1 or
> 122	   section 7.1, and works out to:
> 
> 124	         BASE64URL(UTF8(JWS Protected Header)) || '.' ||
> 125	         BASE64URL(JWS Payload) || '.' ||
> 126	         BASE64URL(JWS Signature)
> 
> 128	   Note that this results in a long base64 content (with two
> 129	   interspersed dots).  The content is transmitted within the HTTPS
> 130	   session in this base64 format, even though HTTP can accomodate binary
> 131	   content.  This is done to be most convenient for available JWT
> 132	   libraries, and for humans who are debugging.

(11) Is there anything that constrains these objects to HTTP(s) ? 
If not, then maybe rephrase to "When using HTTP/HTTPs, the voucher is transmitted in the base64 ..."

> 134	   There are a number of attributes.  They are:
> 
> 136	3.1.  Unprotected Header
> 
> 138	   There is no unprotected header in the Compact Serialization format.
> 
> 140	3.2.  Protected Header
> 
> 142	   The standard "typ" and "alg" values described in [RFC7515] are
> 143	   expected in the protected headers.
> 
> 145	   It remains to be determined (XXX), what values, if any, should go
> 146	   into the "typ" header, as in the [RFC8995] use cases, there are
> 147	   additional HTTP MIME type headers to indicate content types.
> 
> 149	   The "alg" should contain the algorithm type such as "ES256".
> 
> 151	   If PKIX [RFC5280] format certificates are used then the [RFC7515]
> 152	   section 4.1.6 "x5c" certificate chain SHOULD be used to contain the
> 153	   certificate and chain.  Vouchers will often need all certificates in
> 154	   the chain, including what would be considered the trust anchor
> 155	   certificate because intermediate devices (such as the Registrar) may
> 156	   need to audit the artifact, or end systems may need to pin a trust
> 157	   anchor for future operations.  This is consistent with [RFC8995]
> 158	   section 5.5.2.

I'll have to hink about this more once its WG draft ;-)

> 160	4.  Privacy Considerations
> 
> 162	   The Voucher Request reveals the IDevID of the system that is
> 163	   onboarding.

> 165	   This request occurs over HTTPS, however the Pledge to Registrar
> 166	   transaction is over a provisional TLS session, and it is subject to
> 167	   disclosure via by a Dolev-Yao attacker (a "malicious
> 168	   messenger")[onpath].  This is explained in [RFC8995] section 10.2.

(12) I am not quite clear what belongs here and what belongs into other
documents, but the way i see it: 

This document does not change any privacy considerations over rfc8366 AFAIK
as long as they belong to the voucher payload. Only the JOSE header is
new. So it would be good to make such a statement (no change, not aware of
privacy considerations for the jose header).

On the other hand, it looks to me as if the Dolev-Yao attack (please add a
reference for it) is not mentioned by name in 8366 nor 8995, so it
is perfectly fine to have the section here, but it should be written
somehwat more independent of 8995. E.g.: Instead of "The Voucher Request,
write "When transporting vouchers over a non-confidential path, the voucher
(independent of CMS or JOSE signature) reveals the ..."

(13) There should be a section "Updates to rfc8366" which just two sentences:

This document adds the new JOSE (JWS ?) signature option to vouchers.

This document adds privacy considerations for transporting vouchers.

> 
> 170	5.  Security Considerations
> 
> 172	   The issues of how [RFC8366] vouchers are used in a [RFC8995] system
> 173	   is addressed in

EOUTOFCOFFEE ?

> 211	8.  Changelog

Yes, please maintain that ;-)

> 
> 319	   The following is an example request sent from a Pledge to the
> 320	   Registrar.  This example is from the Siemens reference Registrar

(14)                ^ using [RFC8995]
> 321	   system.

> 388	A.2.  Example Parboiled Voucher Request (from Registrar to MASA)

(15) If you want to keep "parboiled", please add a reference to where an
explanation is what it means.

THE END

Thanks again for this work, folks

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 2 Jul 2021 08:53:18 +1200

1) I've already supported adoption.

2)

> 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

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 2 Jul 2021 02:56:25 +0200

[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

-- 
---
[email-masked]

---

From: "Fries, Steffen" <[email-masked]>
Date: Fri, 2 Jul 2021 06:29:47 +0000

Hi Toerless,

I support the adoption. 
As you wrote we are using the approach  in BRSKI-AE and depend on it. 

Best regards
Steffen

> -----Original Message-----
> From: Anima <[email-masked]> On Behalf Of Toerless Eckert
> Sent: Donnerstag, 1. Juli 2021 18:34
> To: [email-masked]
> Subject: [Anima] Resending: Call for adoption: draft-richardson-anima-jose-
> voucher
> 
> draft-ietf-anima-brski-async-enroll (BRSKI-AE). It does effectively not
> constitute new work, but was separated out during development of that
> draft so that the jose-signed-voucher can more easily be referenced and
> reused by other work in the IETF that may not need to inherit, refer to the
> whole BRSKI-AE solution.
> 
> > Mainly I can't understand this draft because it's way outside my expertise,
> but it seems necessary so I would support adoption.
> >
> > Regards
> >    Brian
> >
> > >     > Html:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Farchive%2Fid%2Fdraft-richardson-anima-jose-voucher-
> 01.html&amp;data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C71f7e76fd85f40dce8cf08d93cae052
> 4%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6376075403975495
> 87%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=7Yt2Vz%2B08zpg
> mqlAyb2QALaDG39BE%2FOhV50LM7TgQI4%3D&amp;reserved=0
> > >     > Diff:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Frfcdiff%3Furl2%3Ddraft-richardson-anima-jose-voucher-
> 01&amp;data=04%7C01%7Ccef9763c-149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C71f7e76fd85f40dce8cf08d93cae052
> 4%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6376075403975495
> 87%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=uMWeN1Gjlf%2
> Fv85Yzub2Ja028U3XFRTccTOuuhDi%2Bc0o%3D&amp;reserved=0
> > >
> > >     > Abstract:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Fanima&amp;data=04%7C01%7Ccef9763c-
> 149c-4881-b9c2-
> 5fedc277663a%40ad011.siemens.com%7C71f7e76fd85f40dce8cf08d93cae052
> 4%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C6376075403975495
> 87%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=FSFejSDPrB9Ylw
> bPpJy8uXfH6cGkqq9Q3VxDLaBKVwM%3D&amp;reserved=0

---

From: Michael Richardson <[email-masked]>
Date: Sun, 04 Jul 2021 14:22:02 -0400

> (1) suggested replacement text to provide better context setting:

Accepted.

    > i am never quite sure what the strict requirements are for such a

Sure, that works for me.
I agree with Brian, that it is hard to say what form of Updates we care
about.
It is not Amends.
It is not quite Extends.
It is mostly in the See Also.

ps: RFC editor will prefer "artifact" over "artefact" :-)

https://github.com/mcr/anima-jose-voucher/commit/66d39393d1d3ccbcb0e74674e10ea6599288eb28

---

From: Michael Richardson <[email-masked]>
Date: Sun, 04 Jul 2021 14:28:56 -0400

> draft, voucher can have CMS or JOSE.

It's not "extends" though.  We don't change the YANG, and we don't change the CMS.
This would be akin to say that UDP extends TCP, when it just lives next to it.

    > Agreed ?

Well, at this point, we only get to say "Updates" or Not.  And clearly we do
need to say "Updates", and we can add text somewhere to explain what it updates.

    > of update this RFC will be.

Yes, that's what we are obligated to do now anyway.

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 6 Jul 2021 01:25:23 +0000

I support the adoption without my chair hat. This is an useful work for extending the voucher format. 

However, with my chair hat on, I am a little bit concern regarding to whether we have enough expertise to do this well within ANIMA WG. By the definition of ANIMA, we are focusing on autonomic procedures in network operation and management. I am not sure whether we can get enough reviewers to guarantee the quality of this type of format definition.

The authors may suggest or abstract more experts to enrich ANIMA expertise so that we shall have more confidence to complete this type of work well.

Regards,

Sheng

> From: Anima <[email-masked]> On Behalf Of Brian E Carpenter
> Sent: Friday, July 2, 2021 4:53 AM
> To: Toerless Eckert <[email-masked]>; [email-masked];
> [email-masked]
> Subject: Re: [Anima] Resending: Call for adoption:
> draft-richardson-anima-jose-voucher
> 
> > (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."
> 
> If you think this is unsatisfactory, support
> https://datatracker.ietf.org/doc/draft-kuehlewind-update-tag/
> 
>    Brian
> 
> 
> https://www.ietf.org/mailman/listinfo/anima

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Jul 2021 09:24:02 -0400

Sheng Jiang <[email-masked]> wrote:
    > However, with my chair hat on, I am a little bit concern regarding to
    > whether we have enough expertise to do this well within ANIMA WG. By
    > the definition of ANIMA, we are focusing on autonomic procedures in
    > network operation and management. I am not sure whether we can get
    > enough reviewers to guarantee the quality of this type of format
    > definition.

ANIMA is chartered to work on BRSKI extensions.
If the WG chairs would prefer to move that work to another WG (IOTOPS for
instance), then I'm sure that a discussion with the ADs could occur.

This document just uses JOSE.  It doesn't extend it in anyway.
You don't need to know JOSE much, anymore than you have to know CMS or COSE (less).
It also doesn't extend RFC8366, but all the experts on that document are in
this WG.

An option that the WG could consider is if it wants to merge this work into
an RFC8366bis.  There are positives and negatives about such a thing.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Jul 2021 08:33:35 +1200

> >I am not sure whether we can get

I think we have a way to do that, which is to ask both Gen-ART and the
Security area for early reviews, right after adoption. This is a problem
for many WGs when they touch a security topic.

Regards
   Brian

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 8 Jul 2021 01:40:41 +0000

> It also doesn't extend RFC8366, but all the experts on that document are in

[SJ] It sounds good enough for me.

> An option that the WG could consider is if it wants to merge this work into an
> RFC8366bis.  There are positives and negatives about such a thing.

[SJ] I don't hold a preference now. It is up to the authors.

Sheng

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 16 Jul 2021 03:06:59 +0200

Dear ANIMA WG, authors

All:

Thanks for the discussion about adoption of subject draft.
I have not seen any rejection to adoption but support.
ANIMA WG is hereby adopting the draft (see below for further justification).

Authors:

Please attempt to solve as many as possible of the textual details brought
up during the adoption call and then submit to datatracker (whenever it
permits it) a new revision as draft-ietf-anima-jose-voucher,
a chair will then accept it as a WG group draft.

All:

Wrt. to the discussions how to adopt, those seem to be subject to WG
chair decisions, so let me explain why i concluded the above:

-> ask for adoption in ANIMA or other WG based on best expertise:

   I don't think there is another WG better suited to adopt. Not only
   is JOSE concluded, but JOSE is also just one "tool" component utilized in the draft,
   whereas ANIMA is the solution group.

   In my past experience including RFC8366, its most often better to 
   let the solution WG lead work on a solution draft. Iotops is another solution
   group, but in my past tracking of it not better than ANIMA, especially given how
   ANIMA is chartered with BRSKI extensions.

   The important thing already mentioned on the thread: we need to seek review
   from whatever group is the best expert for individual component
   questions, and i think we learned how to do this better through the
   past years of ANIMA charter round 1 review than we did originally.

-> Adopt individually or make part of rfc8366:

   We had discusssions about this in the constrained BRSKI design team call,
   and it seems very much as if the target delivery lines for the rfc8366bis and
   the JOSE voucher RFC can easily be quite different, JOSE voucher for
   example something that could be done very quickly, whereas rfc8366bis
   might want to linger around longer.

   Given how our experience with ANIMA round 1 was that we coalesced a lot
   of work into way too few RFC and given how this made review very
   painfull and slow (both WG, IETF and IESG), lets try to modularize
   work better now.

   What is the worst that can happen ? We could figure out later that we wanted to
   merge the JOSE voucher work back into rfc8366bis. So what ?! No harm done!

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 16 Jul 2021 07:44:24 +0200

On 2021-07-16, at 03:06, Toerless Eckert <[email-masked]> wrote:
> 
> Iotops is another solution
>   group,

Actually No.

From their charter [1]:

> Revision, updates, and extensions to work from existing WGs will be done in those WGs. Where new work may be needed, IOTOPS will help identify candidate venues within IETF for their development.

So you are doing the right thing here.

Grüße, Carsten

[1]: https://datatracker.ietf.org/wg/iotops/about/

---

From: Michael Richardson <[email-masked]>
Date: Fri, 16 Jul 2021 12:49:07 -0400

> a chair will then accept it as a WG group draft.

Do you want me to post identical text as -00 (and then -01 with suggestions),
or do you want me post richardson-02 with suggestions, and then identical -00?

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 17 Jul 2021 00:03:19 +0200

No need for a that only differ by name, or further pre-WG-adoption version.

Cheers
   Toerless

-- 
---
[email-masked]