AD review 02: minor level comments - part one

[mcr]

Minor level comments:

(2) p 3, sec 1.2. Target Use Cases

The pledge is not expected to know which of these two situations it
is in. The pledge determines this based upon signals that it
receives from the Cloud Registrar. The Cloud Registrar is expected
to make the determination based upon the identity presented by the
pledge.

Rather than "which of these two situations", perhaps it would be clearer as "which of the two situatations described in sections 1.2.1 and 1.2.2 below"

(3) p 4, sec 2. Architecture

Finally, when bootstrapping against an owner Registrar, this
Registrar may interact with a backend CA to assist in issuing
certificates to the pledge. The mechanisms and protocols by which
the Registrar interacts with the CA are transparent to the pledge and
are out-of-scope of this document.

Possibly this paragraph and the previous one would be better in the reverse order. In particular, it is unclear to me whether using ESP services constitutes "bootstrapping against an owner Registrar", or wheher the third paragraph ony covers the "Cloud Registrar may redirect the pledge to an owner Registrar" case.

(4) p 8, sec 3.1.3. Pledge Issues Voucher Request

After the pledge has established a full TLS connection with the Cloud
Registrar and has verified the Cloud Registrar PKI identity, the
pledge generates a voucher request message as outlined in BRSKI
section 5.2, and sends the voucher request message to the Cloud
Registrar.

What is meant by a "full TLS connection"?

(5) p 8, sec 3.2. Cloud Registrar Handles Voucher Request

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. The Registrar MAY also 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 an
onboarding failure, and indicate this to the operator.

I'm slightly surprised that it is only a MAY for including the Retry-After header rather than SHOULD.

NOTE: split this issues into two and moved the ADs last comment to issue #147