Hi Tim/Michael, > > On Jul 27, 2025, at 2:37 AM, Tim Wicinski via Datatracker <noreply@xxxxxxxx> wrote: > > Document: draft-ietf-anima-brski-cloud > Title: BRSKI Cloud Registrar > Reviewer: Tim Wicinski > Review result: Ready with Issues > > I've been asked by the DNS Directorate to do a follow-up review. I notice a > few things have not been addressed. > > Issues: > > Question: I asked this in my previous review, but it still needs to be > addresses: > > This document says it "Updates 8995" yet there is no section in the document > with the updates to 8955. This is usually the case. I had advised Michael of the same, and he did add it in the Introduction section, last paragraph, except, you will not see it referenced as [RFC8995], but rather [BRSKI]. One thing I did forget to mention to him was to the same for the Abstract, except there he does not need to provide an explanation. So a statement that says: “This document updates [BRSKI].” For the remainder of comments, I will let the authors respond. Thanks > > ### 1.1 Terminology > > You define Value Added Reseller (VAR), which is all well and good, but there > are more than one place where you say "value added reseller (VAR)" where VAR > should work, and you fail to capitalize the term in those places. > > I may be overly OCD, but any reason why terms are not sorted alphabetically? > > You define "Manufacturer", and explain the various nuances, but you don't > always capitalize the term in the document. > > ### Referencing > > In Russ Housley's GENART review, he called out how you use different ways of > referencing sections of an RFC, using both "Section X of [RFC]" and "[RFC], > Section X". I feel the authors should pick one (the former) and be consistent. > > Here is an example of how you reference sections of the BSKRI document: > > "Section X of..." > > This work is in support of [BRSKI], Section 2.7, which describes how > Registrar and the MASA is described by [BRSKI], Section 5.4. > and sign(VR-sign(N)) This is as described in [BRSKI], Section 3. > [BRSKI], Section 2.5.3, and the Pledge sends the CSR Attributes > According to [BRSKI], Section 2.7, the Pledge MUST use an Implicit > the considerations from [BRSKI], Section 10.7 apply. > TLS connection is required as explained in [BRSKI], Section 5.1. > in [BRSKI], Section 5.7. > > "BRSKI, Section ...." > > Provisional TLS: A mechanism defined in Section 5.1 of [BRSKI] > Section 5.9.2 of [BRSKI] specifies that the Pledge MUST send an EST > Provisional TLS procedures documented in Section 5.1 of [BRSKI], the > request message as outlined in Section 5.2 of [BRSKI], and sends the > TLS, as per Section 5.1 of [BRSKI]. > MUST perform voucher verification as per Section 5.6.1 of [BRSKI]. > Section 5.7 of [BRSKI] This telemetry returns allow for the Registrar > Step 10 is described in Section 5.9.4 of [BRSKI] as the Enrollment > infrastructure. Section 10.7 of [BRSKI] outlines additional > Sections 11.5 and 11.6 of [BRSKI] outline additional considerations > > These are all spelling/grammar/nits > > ### 1. Introduction > > s/are required which/are required, which/ > > s/provision products to be operate/provision products to operate/ > > ### 2 Architecture > > s/For use case one/For the first use case/ > > s/For use case two/For the second use case/ > > The two figures are very nice, but I would argue they should be placed after > each paragraph describing them, rather together. But I may be wrong. > > ### 2.1 Network Connectivity > > s/accomplish this, from routable IPv4 or IPv6 addresses/accomplish this, from > using routable IPv4 or IPv6 addresses/ > > ### 3.2. Cloud Registrar Processes Voucher Request Message > > s/redirect to owner EST/redirect to Owner EST/ > > ### 4.2. Bootstrap via Cloud Registrar and Owner EST Service > > s/attempts to authentiate/attempts to authenticate/ > > s/In step 3, the the Cloud Registrar/In step 3, the Cloud Registrar/ > > ### 8.2. Trust Anchors for Cloud Registrar > > s/is described in in / is described in / > > ### 1.2. Target Use Cases > > s/bootstraps it should be redirected/bootstraps, it should be redirected/ > > s/procedures define/procedures defined/ > > ### 7.1. Captive Portals > > s/all connections is also deployed./all connections are also deployed./ > > 8. Security Considerations > > s/operation of the MASA also apply to operation/operation of the MASA also > apply to the operation/ > > ### 8.2. Trust Anchors for Cloud Registrar > > s/need to include enough trust anchor/need to include enough trust anchors/ > > > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
