Hi Tim,On Jul 27, 2025, at 6:19 PM, Tim Wicinski <tjw.ietf@xxxxxxxxx> wrote:
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].”
Actually, in the abstract, it can just say "This document updates RFC8995" (no references in the Abstracts are allowed).
You are right. No references allowed, so just:
“This document updates RFC8995.”
Thanks. 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/
>
>
>
|
