Subject: [Rats] I-D Action: draft-ietf-rats-architecture-11.txt

From: [email-masked]
Date: Tue, 30 Mar 2021 09:48:08 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Remote ATtestation ProcedureS WG of the IETF.

        Title           : Remote Attestation Procedures Architecture
        Authors         : Henk Birkholz
                          Dave Thaler
                          Michael Richardson
                          Ned Smith
                          Wei Pan
	Filename        : draft-ietf-rats-architecture-11.txt
	Pages           : 49
	Date            : 2021-03-30

Abstract:
   In network protocol exchanges it is often useful for one end of a
   communication to know whether the other end is in an intended
   operating state.  This document provides an architectural overview of
   the entities involved that make such tests possible through the
   process of generating, conveying, and evaluating evidentiary claims.
   An attempt is made to provide for a model that is neutral toward
   processor architectures, the content of claims, and protocols.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rats-architecture/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-rats-architecture-11.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rats-architecture-11

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Mar 2021 12:58:07 -0400

> https://www.ietf.org/rfcdiff?url2=draft-ietf-rats-architecture-11

Thank you for Eliot Lear for rewriting the abstract and making the
introduction a bit gentler.  Eliot had suggested opening with a question, but
some in the design team felt that this was a bad idea, was almost
clickbait'ey.  We found the compromise to make the question implicit rather
than explicit.

During the IETF110 meetings, the use of the term "Handle" was objected to,
and we have changed the name to "Epoch ID", but we are not completely happy
with this term.  It was just less worst than all the other choices.
In particular, we expect that there may be one or more protocol documents
that explain how to implement this kind of freshness, and we are not
mandating that those documents use the term "Epoch ID".
(For instance, if based upon UUIDs, they might be "Epoch GUIDs"...)
We consider if we should add a disclaimer to that effect, but on the other
hand, every term is subject to amendment by future document.

The majority of the work here is the result of an editorial pass by Henk to
make sure all the text is self-consistent and grammatical.

We have a number of additional issues open, and Dave Thaler is working on
some text to normalize our treatment of Reference Values, Endorsements and
Appraisal Policy.  We think that we need to spend a consistent amount of
space and detail dealing with these three out-of-scope (for this document,
and for this charter)  concepts, and that for instance, "Endorsements" is out
of place in Section 8.

I am publishing this -11 as an interim document so that we can be sure that
we didn't make any merge mistakes, and so that Dave has a consistent basis on
which to do his additional work.

We have moved the next few Tuesday Morning "10am" (1400UTC) sessions to
Friday morning, "11am" (1500UTC) in to accomodate some other activities.
In particular, there is an April 13 session/presentation/announcement? from
Zigbee CHIP that might interest many of you.

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