[Rats] status of draft-ietf-rats-architecture-09.txt

[Michael Richardson <[e-mail]>]

[e-mail] wrote:
    > 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-09.html

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


Hi, the RATS architecture design team has posted this -09 version.
Here is a graph of tickets (issues and pull requests):
   http://www.sandelman.ca/tmp/mcrcapture/2949.2021-02-05/capture1.png

The WGLC in November resulted in a number of substantive reviews.
One from Guy resulted in around 50 issues raised.
The review from Thomas and Simon at ARM resulted in fewer tickets, but many
difficult issues.  One of which was to change the ordering of the sections,
and we posted -08 after doing that, so the diff above is after the
re-ordering.
The reordering raised the question: to what extent should we use Terminology
prior to defining it? Mostly, yes to forward references, but should it be Capitalized?

Sections on Freshness have been reworked, and the examples (diagrams) in the
appendix A have been reworked, revised, checked, rechecked, etc.
This is associated with new text in the Security Considerations about how
things can go wrong, and what other aspects are important.
(TLS or other equivalent schemes can bring needed non-reordering guarantees, for instance)

https://github.com/ietf-rats-wg/architecture/issues currently shows 23 open issues.
13 are wontfix issues that I will be dealing with in this email.
 4 are has-pull-request issues on relatively minor points that we will iron out,

We think that -09 is largely complete, that the Shepherd write up can
complete, and that it is time for the AD review to start.
We leave it up to the WG chairs to decide if they need another WGLC.
(My opinion is no)

Issues we won't fix:
https://github.com/ietf-rats-wg/architecture/issues/151
Endorsements definition is too narrow given PR150 clarification
   A place where we had some disagreement is to the extent that the
   *INFORMATIONAL* *ARCHITECTURE* document needs to specify how Endorsements
   work, given that Endorsements were not generally in scope for
   standardization at this pass of the RATS Architecture.
   We decided that this discussion was a rathole, and thus wontfix.

https://github.com/ietf-rats-wg/architecture/issues/158
Endorser / Endorsement optional optimization?
   created term: 'reference value provider', but did not fix entire issue
   consitent with above.

https://github.com/ietf-rats-wg/architecture/issues/171
Attester definition (Guy)
   we think that other edits deal with this concern.

https://github.com/ietf-rats-wg/architecture/issues/174
Reference use Case -- Roles (Guy)
   the use case/terminology change addressed this concern

https://github.com/ietf-rats-wg/architecture/issues/175
Network Endpoint Assessment (Guy)
   We declined to insert a forward reference here

https://github.com/ietf-rats-wg/architecture/issues/176
3.2. Confidential Machine Learning (ML) Model Protection (Guy)
   We agree that ML is not different than other software, people think
   confidential data needs to be "encrypted", but that confidential code needs
   to be obfuscated. In fact, both just require confidentiality protection, with
   a similar solution.

https://github.com/ietf-rats-wg/architecture/issues/177
Definition of Relying Party in confidential ML model use case
   see above

https://github.com/ietf-rats-wg/architecture/issues/181
TAM/TEE use case
   The TAM is not doing the conducting, cf TEEP transport spec

https://github.com/ietf-rats-wg/architecture/issues/204
5.2 background-check model plumbing
   We didn't agree with changing the model.

https://github.com/ietf-rats-wg/architecture/issues/205
5.2 - RP format issues
   The industry already has multiple formats today. Multiple is important,
   expanding the set indefinitely is not intended or good, but if someone (like
   another SDO) does add another one, RATS can accommodate it.
   "should [attack surface] be compared in all the other variations in this
   document" -> if there's an important requirement that falls out of it
   yes. But I don't know of one. "how do you know it's even true" -> not sure
   what "it" refers to but if it is "minimizing code footprint", then it's true
   that 2 parsers is generally more code than 1 parser (the onus of showing
   otherwise would be on the person arguing that 2 parsers is less code than 1
   parser). "should this one be deleted" -> no.

https://github.com/ietf-rats-wg/architecture/issues/213
8.2 Endorsements
   We didn't understand what we should change, and concluded so.

https://github.com/ietf-rats-wg/architecture/issues/214
8.3 Attestation Results
   Asks why we have split Relying Party and Verifier, because in a number
   of cases, the RP could make the determination itself.  But the reason
   for the split is due to scaling and heterogeniuty.  We decided that
   the text was clear enough.

https://github.com/ietf-rats-wg/architecture/issues/266
use of "entity" and "Artifact" in the Terminolgy Section
   We discussed the use of Artifacts and Entities in the Terminology, given
   that we actually don't really those terms again.
   But, it is precisely because we define more specific terms in those
   sections that we never have to use those words again.



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


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