Mahesh
On Sun, Jul 27, 2025 at 4:43 AM Mahesh Jethanandani <[email protected]> wrote: > Hi Tim/Michael, > > > > > On Jul 27, 2025, at 2:37 AM, Tim Wicinski via Datatracker < > [email protected]> 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].” > Actually, in the abstract, it can just say "This document updates RFC8995" (no references in the Abstracts are allowed). Also, normally when an RFC updates a previous RFC, there will be a section which is "Updates to RFC 8995" but I know in this case the updates are clarifications, so it less obvious. I was going to leave that to the IESG, et al. Thanks tim > > 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/ > > > > > > >
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
