michael
On Sun, Jul 27, 2025 at 12:56 PM Michael Richardson <mcr+ietf@xxxxxxxxxxxx> wrote:
Thank Tim for the re-review.
Tim Wicinski via Datatracker <noreply@xxxxxxxx> wrote:
> ### 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?
Huh... it looks alphabetical to me: EST, Local, Manufacturer, Owner, OEM, Provisional...
ah, so OEM < Owner. fixed.
moved Cloud VAR Registrar to be in the Cs, rather than amended VAR.
> You define "Manufacturer", and explain the various nuances, but you
> don't always capitalize the term in the document.
I've upcased them all, but not sure they all should be.
Thanks
> ### 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.
fixed to always use the kramdown mechanism.
I assumed RPC would decided upon a consistent view.
There are some places where it's Section X and Y of [Z], and I left it that way.
You are correct - the RPC will have their say. I was just noticing it.
moving this up away from the nits:
> 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.
So you'd move them out of the Architecture which is trying to explain why
there are different requirements, into the Protocol solution?
You aren't wrong. I don't know, because I know the document too well.
Section 4 also has more detailed time-sequence diagrams.
Actually, more like putting each one after each paragraph in the Architecture section which describes them.
"For use case one, ...." then the diagram. Same for "For use case two...."
does that make more sense? it's a six of one and when I was reviewing it just the back and forth could be
avoided some. I will go with whatever the consensus says.
thanks!
tim
changes at:
https://github.com/anima-wg/brski-cloud/pull/246
> 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/
okay.
> ### 2 Architecture
> s/For use case one/For the first use case/
> s/For use case two/For the second use case/
fixed
> ### 2.1 Network Connectivity
> s/accomplish this, from routable IPv4 or IPv6 addresses/accomplish
> this, from using routable IPv4 or IPv6 addresses/
fixed.
> ### 3.2. Cloud Registrar Processes Voucher Request Message
> s/redirect to owner EST/redirect to Owner EST/
fixed.
> ### 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/
fixed.
> ### 8.2. Trust Anchors for Cloud Registrar
> s/is described in in / is described in /
fixed.
> ### 1.2. Target Use Cases
> s/bootstraps it should be redirected/bootstraps, it should be
> redirected/
> s/procedures define/procedures defined/
fixed.
> ### 7.1. Captive Portals
> s/all connections is also deployed./all connections are also deployed./
fixed.
> 8. Security Considerations
> s/operation of the MASA also apply to operation/
operation of the MASA also apply to the operation/
fixed
> ### 8.2. Trust Anchors for Cloud Registrar
> s/need to include enough trust anchor/need to include enough trust
> anchors/
fixed.
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
