Hi Authors, Thanks for addressing most of my comments. I still have a question on two of the comments.
> On Sep 4, 2024, at 4:42 AM, Owen Friel (ofriel) <ofr...@cisco.com> wrote: > > Hi Mahesh, > All these issues have been addressed in the github repo. We raised individual > issues 156-166 for each of your comments below if you want to check the > specific text: > > https://github.com/anima-wg/brski-cloud/issues?q=is%3Aissue+is%3Aclosed > <https://github.com/anima-wg/brski-cloud/issues?q=is%3Aissue+is%3Aclosed> > > You can expect a draft-10 shortly. > Thanks, > Owen > > From: Mahesh Jethanandani <mjethanand...@gmail.com> > Sent: Wednesday, August 21, 2024 1:41 AM > To: draft-ietf-anima-brski-cloud....@ietf.org > Cc: anima@ietf.org; anima-cha...@ietf.org > Subject: Additional AD review > > Hi Authors, > > Thanks for posting an update for the draft, and addressing the AD review > comments of Rob Wilton. Since the changes were extensive, a second review was > warranted. I expect some responses for the COMMENTs but it would be nice if > you addressed the NITs also. > > ------------------------------------------------------------------------------- > COMMENT > ------------------------------------------------------------------------------- > > Overall comments: > > Please run a spell checker of choice to fix all the spelling errors in the > document, which there are plenty. The second has to with inconsistent use of > terms. Examples include "Owner Registrar" and "owner Registrar”, “pledge” and > “Pledge”, “bootstrap” and “Bootstrap". It helps to be consistent in your use > of the terms. [mj] I see that you have changed most instances of “Pledge" to “pledge" while changing “owner” to “Owner”, and keeping “Registrar" with a capital letter. I would have expected that you would have made all instances of “pledge” “Pledge” to distinguish it from the word “pledge”, meaning a promise. At the same time, I can see that you have used lowercase “pledge” and “registrar” in the [BRSKI] specification. To clean this out, choose one of the capitalizations (uppercase would be my preference, but I will let you decide), and apply it uniformly across the document. For example, in the terminology section, Figures 1 and 2, I see “Pledge” and in Section 9.1 title “Security Updates for the Pledge”. > > Specific comments: > > Section 1, paragraph 3 > > To support enrolment of pledges without such an owner based access > > network, the mechanisms of BRSKI Cloud are required which assume that > > Pledge and Registrar simply connect to the Internet. The Internet > > ("Cloud") connected Registrar will then determine ownership of the > > Pledge and redirect the Plege to its owners Registrar. > > I will admit I have not gone through the BRSKI specification. What happens if > the URI of the Cloud Registrar is shutdown or moved? Is that covered by > BRSKI, or is that outlined somewhere in this document? [mj] I was looking for text that addresses this question in the updated document. Could you point me to it? Thanks. > > Section 1.2.1, paragraph 1 > > A pledge is bootstrapping from a location with no local domain > > Registrar (for example, the small site or teleworker use case with no > > local infrastructure to provide for automated discovery), and needs > > to discover its owner Registrar. The Cloud Registrar is used by the > > pledge to discover the owner Registrar. The Cloud Registrar > > redirects the pledge to the owner Registrar, and the pledge completes > > bootstrap against the owner Registrar. > > Covered in the overall comments, but repeated here. What is the difference > between "Owner Registrar" and "owner Registrar"? If they are the same, can we > be consistent in its usage? Same for pledge and Pledge. > > Section 2, paragraph 3 > > For use case one, as described in Section 1.2.1, the Cloud Registrar > > redirects the pledge to an owner Registrar in order to complete > > bootstrap with the owner Registrar. When bootstrapping against an > > owner Registrar, this Registrar will interact with a CA to assist in > > issuing certificates to the pledge. This is illustrated in Figure 1. > > > It is not clear which registrar is "this Registrar". Is it the Cloud > Registrar or the owner Registrar? > > Section 2, paragraph 3 > > For use case two, as described Section 1.2.2, the Cloud Registrar > > issues a voucher itself without redirecting the pledge to an owner > > Registrar, the Cloud Registrar will inform the pledge what domain to > > use for accessing EST services in the voucher response. In this > > model, the pledge interacts directly with the EST service to enrol. > > The EST service will interact with a CA to assist in issuing > > certificated to the pledge. This is illustrated in Figure 2. > > > s/cerfificated/a cerficate/ > > Section 3.1.2, paragraph 1 > > According to [BRSKI], Section 2.7, the pledge MUST use an Implicit > > Trust Anchor database (see EST [RFC7030]) to authenticate the Cloud > > Registrar service. The pledge MUST establish a mutually > > authenticated TLS connection with the Cloud Registrar. Unlike the > > procedures documented in BRSKI section 5.1, the pledge MUST NOT > > establish a provisional TLS connection with the Cloud Registrar. > > > Please add a definition or a reference to "provisional TLS connection"? > > Section 3.2, paragraph 2 > > If the request is correct and the Registrar is able to handle it, but > > unable to determine ownership, then it MUST return a 401 Unauthorized > > response to the pledge. This signals to the Pledge that there is > > currently no known owner domain for it, but that retrying later might > > resolve this situation. In this scenario, the Registrar SHOULD > > include a Retry-After header that includes a time to defer. A pledge > > with some kind of indicator (such as a screen or LED) SHOULD consider > > this a bootstrapping failure, and indicate this to the operator. > > > Thanks for addressing Rob's comment and changing the MAY to a SHOULD. But you > left the rest of the paragraph as is, and now the following sentence does not > make sense. What failure condition are you referring to? Also, wnen you do > add a SHOULD, the follow-on question is, what happens if the Retry-After > header is not included? > > Section 3.3.1, paragraph 2 > > The pledge MUST restart its bootstrapping process by sending a new > > voucher request message (with a fresh nonce) using the location > > provided in the HTTP redirect. The pledge SHOULD attempt to validate > > the identity of the Cloud Registrar specified in the 307 response > > using its Implicit Trust Anchor Database. If validation of this > > identity succeeds using the Implicit Trust Anchor Database, then the > > pledge MAY accept a subsequent 307 response from this Cloud > > Registrar. The pledge MAY continue to follow a number of 307 > > redirects provided that each 307 redirect target Registrar identity > > is validated using the Implicit Trust Anchor Database. However, if > > validation of a 307 redirect target Registrar identity using the > > Implicit Trust Anchor Database fails, then the pledge MUST NOT accept > > any further 307 responses from the Registrar, MUST establish a > > provisional TLS connection with the Registar, and MUST validate the > > identity of the Registrar using standard BRSKI mechanisms. > > > In case of validation failure, it is not clear which Registrar it MUST > establish a provisional TLS connection with. The original Cloud Registrar, > one of the intermediate Cloud Registrar, or the last Cloud Registrar it was > able to validate? > > Section 4.1, paragraph 1 > > This flow illustrates the Bootstrap via Cloud Registrar and Owner > > Registrar use case. A pledge is bootstrapping in a remote location > > with no local domain Registrar. The assumption is that the owner > > Registrar domain is accessible, and the pledge can establish a > > network connection with the owner Registrar. This may require that > > the owner network firewall exposes the owner Registrar on the public > > internet. > > > What is "Bootstrap", and how is it different from bootstrap? > > No reference entries found for these items, which were mentioned in the text: > [RFC6066] and [RFC8994]. > > ------------------------------------------------------------------------------- > NIT > ------------------------------------------------------------------------------- > > All comments below are about very minor potential issues that you may choose > to > address in some way - or ignore - as you see fit. Some were flagged by > automated tools (via https://github.com/larseggert/ietf-reviewtool > <https://github.com/larseggert/ietf-reviewtool>), so there > will likely be some false positives. There is no need to let me know what you > did with these suggestions. > > "Abstract", paragraph 1 > > To this, this document defines how to contact a well-known Cloud > > Registrar, and two ways in which the new device may be redirected > > towards the operator maintained infrastructure. The Cloud Registrar > > enables discovery of the operator maintained infrastructure, and may > > enable establishment of trust with operator maintained infrastructure > > that does not support BRSKI mechanisms. > > > s/To this, this document/This document/ > > Section 1, paragraph 4 > > This work is in support of [BRSKI], Section 2.7, which describes how > > a pledge > > > > MAY contact a well-known URI of a Cloud Registrar if a > > local Registrar cannot be discovered or if the pledge's > > target use cases do not include a local Registrar. > > > Why the EOL or break in the sentence? > > Section 1.1, paragraph 3 > > Local Domain: The domain where the pledge is physically located and > > bootstrapping from. This may be different to the pledge owner's > > domain. > > > s/different to/different from/ > > Reference [RFC6125] to RFC6125, which was obsoleted by RFC9525 (this may be on > purpose). > > > Section 1.2.2, paragraph 1 > > ly, it can also be used long-term as an security-equivalent solution in whic > > ^^ > Use "a" instead of "an" if the following word doesn't start with a vowel > sound, > e.g. "a sentence", "a university". > > Section 2, paragraph 2 > > s/cerfificated/a cerficiate/ It also also possible that the Cloud Registrar > > ^^^^^^^^^ > Consider adding a comma between these intensifiers. > > Section 2, paragraph 3 > > f this document. The architectures shows the Cloud Registrar and MASA as bei > > ^^^^^ > You should probably use "show". > > Section 2.2, paragraph 1 > > d operations that take place. Section Section 4 outlines the exact sequence > > ^^^^^^^^^^^^^^^ > Possible typo: you repeated a word. > > Section 8, paragraph 1 > > strar that is operated by a VAR, or it it has been redirected to an Owner > > Reg > > ^^^^^ > It seems you either mean "it is", "if it", "it" or there is a comma missing. > > Mahesh Jethanandani > mjethanand...@gmail.com <mailto:mjethanand...@gmail.com>
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
