Thank Tim for the re-review. Tim Wicinski via Datatracker <[email protected]> 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.
> ### 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.
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.
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 <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
