Subject: [Rats] Call for adoption of draft-voit-rats-attestation-results

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Fri, 12 Nov 2021 15:49:39 +0000

Hi,
As we ran out of time in IETF 112, we’ll start the call for adoption for https://datatracker.ietf.org/doc/draft-voit-rats-attestation-results/
On the mail list starting today and will close on Nov. 29.

Please provide feedback and comment to this thread, if you are in support please state if you are willing to contribute or review (or both) to the draft; otherwise, please post your concerns.

Thanks,
   Nancy
   (on behalf of the RATs chairs)

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 12 Nov 2021 17:23:59 +0000

A couple thoughts on this adoption call...

(1) During today's call, Laurence asked the adopted draft name *not* be draft-ietf-rats-attestation-results.  This because there will be other types of attestation results.   So I am proposing an adopted draft name would be: draft-ietf-rats-attestation-results-secure-interactions.  

(2) The slides providing context are here:

https://datatracker.ietf.org/meeting/112/materials/slides-112-rats-draft-voit-rats-attestation-results-00

Eric

From: RATS <[email-masked]> On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Friday, November 12, 2021 10:50 AM
To: [email-masked]
Subject: [Rats] Call for adoption of draft-voit-rats-attestation-results

Hi,

Thanks,

   Nancy

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 12 Nov 2021 18:59:45 +0000

hi Nancy, all,

Not surprisingly, I support adoption.  Both as a co-editor and as an
implementer.

cheers!

On Fri, Nov 12, 2021 at 3:49 PM Nancy Cam-Winget (ncamwing)
<ncamwing=[email-masked]> wrote:
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

-- 
Thomas

---

From: Simon Frost <[email-masked]>
Date: Mon, 15 Nov 2021 07:38:00 +0000

I support adoption of draft-ietf-rats-attestation-results-secure-interactions. (noting the name modification)

Thanks
Simon

From: Eric Voit (evoit) <[email-masked]>
Sent: 12 November 2021 17:24
To: [email-masked]
Subject: Re: [Rats] Call for adoption of draft-voit-rats-attestation-results

Eric

From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Friday, November 12, 2021 10:50 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Rats] Call for adoption of draft-voit-rats-attestation-results

Hi,

Thanks,
   Nancy

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Yogesh Deshpande <[email-masked]>
Date: Mon, 15 Nov 2021 10:06:46 +0000

Hello All,

I support adoption of draft-ietf-rats-attestation-results-secure-interactions with the new name(draft-ietf-rats-attestation-results-secure-interactions).

Regards,
Yogesh

From: RATS <[email-masked]> On Behalf Of Simon Frost
Sent: 15 November 2021 07:38
To: Eric Voit (evoit) <[email-masked]>; [email-masked]
Subject: Re: [Rats] Call for adoption of draft-voit-rats-attestation-results

Thanks
Simon

From: Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>>
Sent: 12 November 2021 17:24
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Rats] Call for adoption of draft-voit-rats-attestation-results

Eric

Hi,

Thanks,
   Nancy

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 15 Nov 2021 13:48:49 +0100

On 2021-11-12, at 16:49, Nancy Cam-Winget (ncamwing) <[email-masked]> wrote:
> 
> call for adoption for https://datatracker.ietf.org/doc/draft-voit-rats-attestation-results/

I believe this is an important piece of work in the overall RATS framework.
Clearly, Sections 4, 5, 6 need to be filled in, but that can be done during the WG work phase; the document is ready for WG adoption.
I agree with Eric’s idea to use a more specific name for the WG Internet-Draft.

Grüße, Carsten

---

From: Guy Fedorkow <[email-masked]>
Date: Mon, 15 Nov 2021 13:59:25 +0000

Hi Nancy,
  I support adoption of this work.
/guy

Juniper Business Use Only
From: RATS <[email-masked]> On Behalf Of Eric Voit (evoit)
Sent: Friday, November 12, 2021 12:24 PM
To: [email-masked]
Subject: Re: [Rats] Call for adoption of draft-voit-rats-attestation-results

[External Email. Be cautious of content]

Eric

Hi,
As we ran out of time in IETF 112, we'll start the call for adoption for https://datatracker.ietf.org/doc/draft-voit-rats-attestation-results/
On the mail list starting today and will close on Nov. 29.

Thanks,
   Nancy

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 15 Nov 2021 16:10:45 +0000

I echo the need for a name change. I would like to see more identity options supported beyond a cryptographic instance identifier. More work is needed to align with other adopted drafts such as the DAA draft.

From: RATS <[email-masked]> on behalf of Yogesh Deshpande <[email-masked]>
Date: Monday, November 15, 2021 at 2:07 AM
To: Simon Frost <[email-masked]>, "Eric Voit (evoit)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Rats] Call for adoption of draft-voit-rats-attestation-results

Hello All,

Regards,
Yogesh

Thanks
Simon

Eric

Hi,

Thanks,
   Nancy

---

From: Adam Wiethuechter <[email-masked]>
Date: Mon, 15 Nov 2021 15:31:58 -0500

I support the adopting of this document to the working group with the 
note from Eric that the name be changed to: 
draft-ietf-rats-attestation-results-secure-interactions.

On 11/12/21 10:49 AM, Nancy Cam-Winget (ncamwing) wrote:
>
> Hi,
>
> As we ran out of time in IETF 112, we’ll start the call for adoption 
> for 
> https://datatracker.ietf.org/doc/draft-voit-rats-attestation-results/ 
> <https://datatracker.ietf.org/doc/draft-voit-rats-attestation-results/>
>
> Please provide feedback and comment to this thread, if you are in 
> support please state if you are willing to contribute or review (or 
> both) to the draft; otherwise, please post your concerns.
>
> Thanks,
>
>    Nancy
>

-- 
73,
Adam Wiethuechter, Software Engineer
Critical Technologies Inc.
Desk: 1-315-793-0248x157
Cell: 1-315-552-4298

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 16 Nov 2021 00:33:59 +0000

Hi Ned,

From: Smith, Ned, November 15, 2021 11:11 AM

I echo the need for a name change. 

<eric> draft-ietf-rats-attestation-results-secure-interactions seems reasonable.  And if this is too many characters for the IETF tools, it will become draft-ietf-rats-ar-secure-interactions.

I would like to see more identity options supported beyond a cryptographic instance identifier. 

<eric> This draft neither designates (nor forces a selection) of any specific formats or domains of identities.   This is for a set purpose.  This purpose is that the Secure Interactions Model in Section 3.2 has been designed to be fully identity type/format agnostic.  

The direct result is that a specific identity defined outside of this draft can be verifiably established via the signature from the Attesting Environment (see section 3.2, step 4.3).   By verifiably, I mean that the signature includes its own identity as one of its encompassed objects (see step 2.1).  

Put another way, we have a general way of verifiably encapsulating Evidence.  This general way is supportable with your choice of Attesting Environment based identities.  See draft-voit-rats-trustworthy-path-routing, Section 4.2 for an instance of how to do this with TPM private LDevID key.

More work is needed to align with other adopted drafts such as the DAA draft. 

<eric> At this point I am assuming that specific identities like DAA's do not make their way into the draft.  This is for the reason above.  Normatively inventorying the set of identity formats is non-trivial, and best left to different efforts IMHO.  Do you have any examples from adopted drafts which are not aligned?  We would be happy to work through these.

Eric

From: RATS <[email-masked] <mailto:[email-masked]> > on behalf of Yogesh Deshpande <[email-masked] <mailto:[email-masked]> >
Date: Monday, November 15, 2021 at 2:07 AM
To: Simon Frost <[email-masked] <mailto:[email-masked]> >, "Eric Voit (evoit)" <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Rats] Call for adoption of draft-voit-rats-attestation-results

Hello All,

Regards,

Yogesh

From: RATS <[email-masked] <mailto:[email-masked]> > On Behalf Of Simon Frost
Sent: 15 November 2021 07:38
To: Eric Voit (evoit) <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Rats] Call for adoption of draft-voit-rats-attestation-results

Thanks

Simon

From: Eric Voit (evoit) <[email-masked] <mailto:[email-masked]> > 
Sent: 12 November 2021 17:24
To: [email-masked] <mailto:[email-masked]> 
Subject: Re: [Rats] Call for adoption of draft-voit-rats-attestation-results

Eric

From: RATS <[email-masked] <mailto:[email-masked]> > On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Friday, November 12, 2021 10:50 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: [Rats] Call for adoption of draft-voit-rats-attestation-results

Hi,

Thanks,

   Nancy

---

From: "Fuchs, Andreas" <[email-masked]>
Date: Tue, 16 Nov 2021 07:58:10 +0000

Hi Nancy,

I support this work.

Thanks,
Andreas

________________________________________
Von: RATS <[email-masked]> im Auftrag von Eric Voit (evoit) <evoit=[email-masked]>
Gesendet: Freitag, 12. November 2021 18:23
An: [email-masked]
Betreff: Re: [Rats] Call for adoption of draft-voit-rats-attestation-results

Eric

Hi,

Thanks,
   Nancy

---

From: "Panwei (William)" <[email-masked]>
Date: Tue, 16 Nov 2021 11:30:09 +0000

Hi,

I support the adoption of this draft.

Regards & Thanks!
Wei Pan (潘伟)

From: RATS [mailto:[email-masked]] On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Friday, November 12, 2021 11:50 PM
To: [email-masked]
Subject: [Rats] Call for adoption of draft-voit-rats-attestation-results

Hi,

Thanks,
   Nancy

---

From: "Stuart W. Card" <[email-masked]>
Date: Tue, 16 Nov 2021 10:47:35 -0500

I have quickly (not yet thoroughly) reviewed the draft and find it well 
written (more than ready for WG adoption).

The subject is of general interest to me @critical.com and of specific 
interest to me @axenterprize.com for potential application to the IETF 
Drone Remote Identification Protocol (DRIP).

The proposed scope limiting change to the draft name also makes sense.

> *From:*RATS <[email-masked] <mailto:[email-masked]>> *On 
> Behalf Of *Nancy Cam-Winget (ncamwing)
> *Sent:* Friday, November 12, 2021 10:50 AM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [Rats] Call for adoption of draft-voit-rats-attestation-results
> 
> Hi,
> 
> As we ran out of time in IETF 112, we’ll start the call for adoption for 
> both) to the draft; otherwise, please post your concerns...

-- 
-----------------------------------------
Stuart W. Card, PhD, Principal Engineer
AX Enterprize, LLC  www.axenterprize.com
4947 Commercial Drive, Yorkville NY 13495

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 16 Nov 2021 10:53:39 -0500

I will get signed up for rats later today and give my +1 on Stu's and 
Adam's endorsement.  I do not have time to read it.  Right now I am 
reviewing the draft NIST SP800-108r1 and working up my first round of 
comments which I need to also send to cfrg and saag.

Then I have DANCE at IATA involvement in DANE and getting things moving 
along in ICAO DWIG and TRON for this.

I bit off a lot in IETF 112...

On 11/16/21 10:47, Stuart W. Card wrote:
> I have quickly (not yet thoroughly) reviewed the draft and find it 
> well written (more than ready for WG adoption).
>
>> *From:*RATS <[email-masked] <mailto:[email-masked]>> 
>> *On Behalf Of *Nancy Cam-Winget (ncamwing)

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 16 Nov 2021 23:58:35 +0000

My responses should be interpreted as support for the adoption call.

Specific wording that appears to conflict with other adopted drafts includes:

  1.  Section 2.1 – Non-reputable Identity Evidence and subsequent use of ‘non-reputable’ in the context of identifying the Attester or an Attesting Environment. Given a DAA key as Attesting Environment identity, the objective is to allow reputable Attester instance identity but non-reputable Attester class identity. Section 2.2 “each set of Attestation Results must be provably and non-reputably bound to the identity of the original Attesting Environment” … “MUST include sufficient Identity Evidence to ensure that this Attesting Environment signature refers to the same Attesting Environment appraised by the Verifier”. The wording around non-reputable Attester identity seems sufficiently strong to conclude that attestation Evidence obtained via a DAA credential would not satisfy these requirements.
  2.  Section 2.2.1 describes various types of Attesting Environments (chip-hardware, target-environment, instance) where all except instance are mandatory. But the draft asserts that the definition of these identities will be defined by other drafts. The high level description of these identities indicates some could be class identifiers (something other than a cryptographic key). The gap is that the other adopted drafts (e.g. EAT) don’t define all of the identity types sufficiently IMO. That implies ‘other drafts’ can include ones not yet adopted potentially.

There may be others examples of misalignments, these are just a couple that jumped out at me.

Thanks,
Ned

From: RATS <[email-masked]> on behalf of "Eric Voit (evoit)" <evoit=[email-masked]>
Date: Monday, November 15, 2021 at 4:35 PM
To: "Smith, Ned" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Rats] Call for adoption of draft-voit-rats-attestation-results

Hi Ned,

Eric

From: RATS <[email-masked]<mailto:[email-masked]>> on behalf of Yogesh Deshpande <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 15, 2021 at 2:07 AM
To: Simon Frost <[email-masked]<mailto:[email-masked]>>, "Eric Voit (evoit)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] Call for adoption of draft-voit-rats-attestation-results

Hello All,

Regards,
Yogesh

From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Simon Frost
Sent: 15 November 2021 07:38
To: Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Rats] Call for adoption of draft-voit-rats-attestation-results

Thanks
Simon

Eric

Hi,

Thanks,
   Nancy

---

From: Michael Richardson <[email-masked]>
Date: Wed, 17 Nov 2021 07:52:27 -0500

Eric Voit \(evoit\) <evoit=[email-masked]> wrote:
    > <eric> draft-ietf-rats-attestation-results-secure-interactions seems
    > reasonable.  And if this is too many characters for the IETF tools, it
    > will become draft-ietf-rats-ar-secure-interactions.

+1

    > <eric> This draft neither designates (nor forces a selection) of any
    > specific formats or domains of identities.  This is for a set purpose.
    > This purpose is that the Secure Interactions Model in Section 3.2 has
    > been designed to be fully identity type/format agnostic.

    > The direct result is that a specific identity defined outside of this
    > draft can be verifiably established via the signature from the
    > Attesting Environment (see section 3.2, step 4.3).  By verifiably, I
    > mean that the signature includes its own identity as one of its
    > encompassed objects (see step 2.1).

    > Put another way, we have a general way of verifiably encapsulating
    > Evidence.  This general way is supportable with your choice of
    > Attesting Environment based identities.  See
    > draft-voit-rats-trustworthy-path-routing, Section 4.2 for an instance
    > of how to do this with TPM private LDevID key.

I feel that we should be adopting these documents as a set?
I am concerned if we have too many "abstract" drafts.
Implementers hate having to chose through different documents to figure out
what's what.  Reviewers too.

Could one of the documents have a diagram to explain how the documents fit
together?  Or should we be creating a roadmap document?
See, for instance: https://www.rfc-editor.org/rfc/rfc6071.html#section-2.1

For instance, what order should I read the documents in?
Even though this set is about one instance of attestation, the architecture
document could include a diagram as an example.

    > <eric> At this point I am assuming that specific identities like DAA's
    > do not make their way into the draft.  This is for the reason above.
    > Normatively inventorying the set of identity formats is non-trivial,
    > and best left to different efforts IMHO.  Do you have any examples from
    > adopted drafts which are not aligned?  We would be happy to work
    > through these.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 17 Nov 2021 14:28:32 +0100

Hi Michael,

comments in-line.

> what's what.  Reviewers too.

While I actively support to be cautious wrt volume of documents, on the 
one hand. On the other hand, the containerization of that content is 
exactly what we want in this case. Fast, precise, easy to digest, and 
well-understood Attestation Results content about secure interaction 
characteristics / the inherent trustworthiness of an Attester. That is a 
fundamental core principle that is per-design encoding agnostic and 
scales with various application scopes. I am very confident that both 
reviewer and implementers can be (and are) working with that.

> See, for instance: https://www.rfc-editor.org/rfc/rfc6071.html#section-2.1

That is something that I can really get behind at. We might still have 
to figure out the right place, but that should not stop us from drawing 
that map together. I know of various authors that maintain such maps 
(including me). Most of these maps are based on "the map" that Eric 
started a while ago. These maps are starting to get a bit crammed, if 
you are trying to fit them on one slide, meanwhile. So... yeah, we 
should curate that map and move it from slide decks to... idk, a 
wikipedia page for starters?

I am bringing that up, because Éric just proposed on the DRIP list to 
maybe curate complementary material in the form of content of a 
wikipedia page, because "not everyone reads RFC". He also noted that 
maintaining such a page that requires work, but also does creating a map 
of the RATS ecosystem and molding that into an RFC.

I am not saying that wikipedia is the ultimate idea here, but maybe it's 
a starting point to talk about the "where".

(and as an editor of the architecture I-D, I'd like to proactively 
highlight: hands off that architecture - that document has to move 
forward 😉)

Viele Grüße,

Henk

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 17 Nov 2021 15:00:36 +0000

Hi Michael,

> Eric Voit \(evoit\) <evoit=[email-masked] <mailto:evoit=[email-masked]> > wrote:

How about the latest proposal:  draft-ietf-rats-ar4si ?

> Implementers hate having to chose through different documents to 

> figure out what's what.  Reviewers too.

While I would love to see draft-voit-rats-trustworthy-path-routing adopted, I would like to see more than one implementation and some meaningful market adoption first.  Standardizing which is running mostly in lab settings seems premature.  Things are moving faster for draft-voit-rats-attestation-results as there is a need for multiple contexts (such as Confidential Compute).   And if we can agree on certain items, it will help those contexts from diverging.

> Could one of the documents have a diagram to explain how the documents 

> fit together?  Or should we be creating a roadmap document?

> See, for instance: 

> https://www.rfc-editor.org/rfc/rfc6071.html#section-2.1

> Even though this set is about one instance of attestation, the 

> architecture document could include a diagram as an example.

This is useful.  Here (or attached) is a revised view from the IETF 110 & IETF 112 views:

Whether we want to include the draft relationships explicitly in one or more of these drafts is something worthy of discussion.

Eric 

> ]     [email-masked] <mailto:[email-masked]>   http://www.sandelman.ca/        |   ruby on rails    [

> Michael Richardson <[email-masked] <mailto:[email-masked]> >   . o O ( IPv6 IøT consulting )

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 17 Nov 2021 21:12:10 +0000

Hi Ned,

From: Smith, Ned, November 16, 2021 6:59 PM

 

1.	Section 2.1 – Non-reputable Identity Evidence and subsequent use of ‘non-reputable’ in the context of identifying the Attester or an Attesting Environment. Given a DAA key as Attesting Environment identity, the objective is to allow reputable Attester instance identity but non-reputable Attester class identity. 

Yes, wording needs to be worked.  In DAA, perhaps the term DAA credential should be formally defined.  What DAA says now is "Attestation Evidence SHOULD be cryptographically associated with an identity document that is a randomised DAA credential." Additionally, perhaps the "Attester Identity ('attesterIdentity')"  principle in Section 5 should be refined to "Anonymous Attester Identity"?   In any case, DAA seems to have a more narrow definition of identity than draft-voit-rats-attestation-results.  In this draft, the non-reputable class itself be considered a form of identity.  So I think the *intent* of both sets of text don't conflict, even if we don't have all the terms right.  Also draft-voit-rats-attestation-results could easily import terms like "Anonymous Attester Identity" from DAA as being a valid form of identity.  Having the group being identified is quite useful.

Section 2.2 “each set of Attestation Results must be provably and non-reputably bound to the identity of the original Attesting Environment” … “MUST include sufficient Identity Evidence to ensure that this Attesting Environment signature refers to the same Attesting Environment appraised by the Verifier”. The wording around non-reputable Attester identity seems sufficiently strong to conclude that attestation Evidence obtained via a DAA credential would not satisfy these requirements.

I wouldn't make that conclusion.  In all cases, you need to relate the AR to the Attester.  But either:

*	the Attester can have an Anonymous unique identity to the Relying Party, which allows the AR to be accurately correlated
*	the evaluation is done simply on the class of identity of the Attester.  (In which case, replay issues can still be handled with a nonce.) 

2.	Section 2.2.1 describes various types of Attesting Environments (chip-hardware, target-environment, instance) where all except instance are mandatory. But the draft asserts that the definition of these identities will be defined by other drafts. The high level description of these identities indicates some could be class identifiers (something other than a cryptographic key). 

A key could be used to identify class.

The gap is that the other adopted drafts (e.g. EAT) don’t define all of the identity types sufficiently IMO. That implies ‘other drafts’ can include ones not yet adopted potentially.

I do think there are lots of aspects of identity which are not sufficiently covered in adopted or individual RATS drafts.  I see these as gaps rather than mis-alignments.  In the end I am hoping to see lots of owners of identity pick up the RATS architectures.  The more solutions we have which are not tied to specific identity formats, the better positioned we are.

Eric

Thanks,

Ned

From: RATS <[email-masked] <mailto:[email-masked]> > on behalf of "Eric Voit (evoit)" <evoit=[email-masked] <mailto:evoit=[email-masked]> >
Date: Monday, November 15, 2021 at 4:35 PM
To: "Smith, Ned" <[email-masked] <mailto:[email-masked]> >
Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Rats] Call for adoption of draft-voit-rats-attestation-results

Hi Ned,

 

 

Eric

From: RATS < <mailto:[email-masked]> [email-masked]> on behalf of Yogesh Deshpande < <mailto:[email-masked]> [email-masked]>
Date: Monday, November 15, 2021 at 2:07 AM
To: Simon Frost < <mailto:[email-masked]> [email-masked]>, "Eric Voit (evoit)" < <mailto:[email-masked]> [email-masked]>, " <mailto:[email-masked]> [email-masked]" < <mailto:[email-masked]> [email-masked]>
Subject: Re: [Rats] Call for adoption of draft-voit-rats-attestation-results

Hello All,

Regards,

Yogesh

From: RATS < <mailto:[email-masked]> [email-masked]> On Behalf Of Simon Frost
Sent: 15 November 2021 07:38
To: Eric Voit (evoit) < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]
Subject: Re: [Rats] Call for adoption of draft-voit-rats-attestation-results

Thanks

Simon

From: Eric Voit (evoit) < <mailto:[email-masked]> [email-masked]> 
Sent: 12 November 2021 17:24
To:  <mailto:[email-masked]> [email-masked]
Subject: Re: [Rats] Call for adoption of draft-voit-rats-attestation-results

 <https://datatracker.ietf.org/meeting/112/materials/slides-112-rats-draft-voit-rats-attestation-results-00> https://datatracker.ietf.org/meeting/112/materials/slides-112-rats-draft-voit-rats-attestation-results-00

Eric

From: RATS < <mailto:[email-masked]> [email-masked]> On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Friday, November 12, 2021 10:50 AM
To:  <mailto:[email-masked]> [email-masked]
Subject: [Rats] Call for adoption of draft-voit-rats-attestation-results

Hi,

As we ran out of time in IETF 112, we’ll start the call for adoption for  <https://datatracker.ietf.org/doc/draft-voit-rats-attestation-results/> https://datatracker.ietf.org/doc/draft-voit-rats-attestation-results/

Thanks,

   Nancy

---

From: Thomas Hardjono <[email-masked]>
Date: Fri, 19 Nov 2021 13:54:25 +0000

+1 

I support adoption of draft-voit-rats-attestation-results.

Best

--thomas

----------------

Hi,

Thanks,
   Nancy