Reviewer: Russ Housley Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-anima-brski-cloud-13 Reviewer: Russ Housley Review Date: 2025-02-21 IETF LC End Date: 2025-02-28 IESG Telechat date: Unknown Summary: Almost Ready Major Concerns: Section 2: I am confused by Figure 1 and Figure 2. The point of BRSKI is to provide trust anchors and certificates to the Pledge. None of the arrows go to the Pledge. I am guessing that more text is needed about these figures to explain what is being shown and not shown. Minor Concerns: The header indicates that this document updates RFC 8995, but the Abstract does not to mention this situation, which it should. Likewise, the Introduction should explain the nature of the update to RFC 8995. The fourth paragraph of the Introduction seems like an easy place to do so. Section 2.2: At the end of the first paragraph, it says: "This can be useful if the Subject must ..." What is this? Also, I think that it would be better to say: This mechanism can be useful if the subject is require by the CA ... Section 4.1: The text says: "... using artifacts created during the manufacturing process ...". Is thins the IDevID certificate and the trust anchors that were installed at the factory. If so, it seems easy to say so. If not, please provide a pointer to the list of these artifacts in the BRSKI document. Section 5: In the last paragraph, another possibility would be a redirect. For example, if two companies merge, one server could redirect to another as long as the appropriate trust anchors are in place. Section 7.3: The text says: "... Pledge should check ... but should always ...". Please reword. I do not think you mean SHOULD. Yet, the reader does not get the sense that things do not work if something else is done. Nits: Global: Some bullets end with a punctuation mark, but other do not. Please put the appropriate punctuation mark at the end of each bullet. Section 1: The text at the end of the first paragraph says: "This is also called enrollment." What is this? I suggest: This bootstrapping process is also called enrollment. Section 1.2: I had to read the paragraph after the bullets several times to get the point. I suggest: In both uses cases, the use of BRSKI in many small sites, such as teleworkers working from home, with minimum expectations of the network infrastructure at those sites. Section 1.2: The text says: "The VAR then sells devices to other entities, such as enterprises, and records this." What is recorded? Where is the recorded information sent? I think it is sent to the Cloud Registrar. Section 1.2: Several paragraphs begin with "In this use case". However, this section is talking about "two high-level use cases". Please be clear which of the two is being discussed. For example, you could say: "In the first use case". Section 2.2: s/The EST server may/The EST server MAY/ Section 3.1.2: s/[BRSKI], Section 5.1,/Section 5.1 of [BRSKI]/ Section 3.1.2: s/IPv6 link local IP address/link local IPv6 address/ Section 3.1.2: s/BRSKI section 5.2/Section 5.2 of [BRSKI]/ Section 3.2: s/The Cloud Registrar must/The Cloud Registrar MUST/ Section 3.3.1: s/[BRSKI], Section 5.1,/Section 5.1 of [BRSKI]/ Section 3.3.2: s/BRSKI section 5.6.1/Section 5.6.1 of [BRSKI]/ Section 4.2: The figure includes: | 5a. /voucher_status POST success | |------------------------------------------------>| | ON FAILURE 5b. /voucher_status POST | Please be consistent. 5a has the "success" at the end, but 5b. hae "ON FAILURE" at the front. Please put them both at the front ot both at the end, and please use the same case conventions. Also, can Step 4 and Step 5 be swapped? It does not seem that Section 5: The text says: [BRSKI], Section 10.7 and Section 11.5 and 11.6 detail some additional considerations about device vs manufacturer life span. Please reword. It seems that a reference to Section 10.7 of [BRSKI] is better suited to the previous paragraph. The Sections 11.5 and 11.6 have to do with maintaining trust. Please be more specific. Section 7.1: s/[RFC8952] section 1/Section 1 of [RFC8952]/ Section 7.1: s/[RFC9525], Section 6.3/Section 6.3 of [RFC9525]/ (two places) Section 7.3: s/must be accounted for/need to be considered/ Section 8: s/may be operated/might be operated/ Section 8.1: s/via DHCP)/via DHCP.)/ Section 8.2: s/a last resort)/a last resort.)/ Section 8.2: s/(WebPKI) anchor/(WebPKI) trust anchor/ Section 8.2: s/WebPKI anchors/WebPKI trust anchors/ Section 8.4: Fix the reference "{bootstrapping-with-no-owner-registrar}" Section 8.4: s/[BRSKI] sections 7.3 and 11/Sections 7.3 and 11 of [BRSKI]/ (two places) IDnits points out some outdated references: == Outdated reference: A later version (-13) exists of draft-ietf-anima-rfc8366bis-12 -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
