Thank you kindly for your very timely review!
Gyan Mishra via Datatracker <noreply@xxxxxxxx> wrote:
> Minor issues: As this is a architecture specification should this be
> standards track. Normative language should then be applied where
> applicable.
The WG had this discussion a few times back in 2019 and 2020 when the
document started.
Some thread references:
https://mailarchive.ietf.org/arch/msg/rats/sPzJnnvvtWNNuVGO2IQ6-WWj6b4/
https://mailarchive.ietf.org/arch/msg/rats/QcXqeEPg-AZOjuH5-WPH2MXJCu0/
I thought that our -01 charter was clearer about this, but it is not:
https://datatracker.ietf.org/doc/charter-ietf-rats/01/
I thought it said "Created Informational Track Architecture" somewhere... but
I can't find that in the revisions to the charter.
In general, this document makes no normative statements about bits on the
wire. Someone writing code does not need to read it actually :-)
Rather, it specifies requirements that other documents are required to
answer. We worked hard to avoid BCP14 keywords.
Finally, the trend in the IETF is that Architectures are not standards track.
However: I have no problem if the consensus of the IESG is that this should
be standards track.
> As the architecture of rats is related to security a lot
> of what is in the security considerations to me seems part of the
> architecture and maybe should be moved to the body of the document or
> appendix.
I'm usually of the opinion that Security Considerations ought to be all back
references to content in the document, so in that I personally agree with you.
In many places we got that right, but I agree that we didn't get it perfect.
> Section 3 describes the environment of an attester. Section
> 3.2 clearly describes a layered environment, however section 3.3
> describes a composite environment using a carrier grade router as an
> example. I think here the composite should be described just as is
> done in the layer environment section but not referencing an
> environment use case that may not be applicable to RAT.
I guess I don't really follow what you are suggesting here.
> So within a
> carrier grade router chassis the backplane communication is all done
> vendor proprietary no external elements so I don’t see how trust comes
> into play as well as the backplane communication is hardware bus
> elements for backplane throughput for the LC and then as well router OS
> software component for the backplane communication. I think maybe
> choosing a better example that applies to RAT composite environment
> would be better.
Yes, the way in which the Evidence is relayed is vendor proprietary, but the
the Evidence and/or Attestation Results are then relayed to an external verifier.
> Nits/editorial comments: Throughout the document there are acronyms
> used and the acronyms have not been expanded. Few words like ROM, BIOS,
> TEEP, TLS, CWT, JWT, X.509, TPM etc
We argued over ROM, BIOS, X509 and found that they were in the RFC editors list.
I'm sure that we also missed a few others, and I'm sure that the RPC will
catch that. Were there TLAs that you particularly found difficult to figure
out?
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
Attachment:
signature.asc
Description: PGP signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
