ietf-rats-wg / rats-endorsements

Other
0 stars 0 forks source link

Section 6.2 comments #25

Closed nedmsmith closed 5 days ago

nedmsmith commented 1 month ago

Section 6.2 first paragraph: "We currently assume that Reference Value Providers and Endorsers typically provide the same information" This sentence seems to contradict what is stated above since RVPs provide "reference" or "possible" state claimsets while Endorsers provide "actual" state claimsets.

This line: "clients ... are generally on devices that are not constrained nodes" is not commonly agreed upon as there are many cases of embedded verifiers, BMCs and so forth. The conclusion that scalability of verifiers "is not a significant concern" to RATS is not true or that it is not "typical".

The following paragraph seems to reinforce my point.

This may be writing style. But the first paragraph should introduce what will be described in subsequent paragraphs, rather than contradict them.

The last two paragraphs seem more focused on complexity than scalability. Maybe they belong in section 6.1? BTW: If this is intended as a security considerations section it shouldn't be a subsection heading. Othewise, this section seems to be about complexity hence it's heading might be more reflective of this.

Section 6 isn't so much about formats as it is about complexity and scalability. It is possible to use different formats to encode simple things or a single format to encode complex things.

dthaler commented 3 weeks ago

Section 6.2 first paragraph: "We currently assume that Reference Value Providers and Endorsers typically provide the same information" This sentence seems to contradict what is stated above since RVPs provide "reference" or "possible" state claimsets while Endorsers provide "actual" state claimsets.

Sounds like a misreading. The "same" means "across many clients", not that a RVP and an Endorser provide the same information. Will reword to be clearer.

This line: "clients ... are generally on devices that are not constrained nodes" is not commonly agreed upon as there are many cases of embedded verifiers, BMCs and so forth.

The above is a misquote. The word "and" (missing from the above quote) is significant as "clients" is not the subject of the "are generally". It says that RVPs and Endorsers are generally on devices that are not constrained nodes. You didn't mention any disagreement regarding those roles. (I'm not sure what a BMC is.)

[nms] BMC is Baseboard Management Controller

RVPs and Endorsers are generally servers or services rather than "devices". The idea could be conveyed more succinctly by "...Verifier), and are generally services on unconstrained nodes...."

The conclusion that scalability of verifiers "is not a significant concern" to RATS is not true or that it is not "typical".

The text never says that scalability of verifiers is not a significant concern. Indeed as you mention the second paragraph says it is, which I think we all agree on.

The following paragraph seems to reinforce my point.

This may be writing style. But the first paragraph should introduce what will be described in subsequent paragraphs, rather than contradict them.

I don't believe there is any contradiction. It seems you might have missed the word "and".

[nms] Maybe. A one sentence paragraph with multiple parts is hard to parse.

The last two paragraphs seem more focused on complexity than scalability. Maybe they belong in section 6.1? BTW: If this is intended as a security considerations section it shouldn't be a subsection heading. Othewise, this section seems to be about complexity hence it's heading might be more reflective of this.

Code space does affect scalability in terms of scale down to constrained nodes with limited space, so code complexity is one aspect of scalability.

Section 6 isn't so much about formats as it is about complexity and scalability. It is possible to use different formats to encode simple things or a single format to encode complex things.

dthaler commented 3 weeks ago

Fixed in draft-02

dthaler commented 5 days ago

I believe this is fixed in the latest draft. Please reopen (with explanation of what is remaining) if you disagree.