tl:dr: https://github.com/anima-wg/anima-bootstrap/pull/41 https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-10&url2=https://raw.githubusercontent.com/anima-wg/anima-bootstrap/bill-atwood-comments/dtbootstrap-anima-keyinfra.txt or: https://goo.gl/pXNghv
William Atwood <[email protected]> wrote: > Section 1, para 3, lines 4-5. "is a minor extension to the voucher > format (see Section 3)." What "voucher format"? I guess that you mean > the voucher format defined in draft-ietf-anima-voucher. I suggest some > additional precision here. Added another reference to anima-voucher document at the end of the paragraph. > Lines 4-5. Why is this "minor extension" defined here, and not in > draft-ietf-anima-voucher? Would it not be better to have all (currently > known) voucher formats in one place? No, because anima-voucher is used by the RESTCONF work in the NETCONF WG, and they have no use for the voucher-request. > Section 2.3, para 2, line 1. "previously defined fields" Where are > these defined? Are they previously defined in this document? Are they > previously defined in some other document? (If so, give reference.) > In general, this paragraph and its two bullets might be understandable > by someone who is well familiar with X.509, but they are opaque to > someone who is not (i.e., this reviewer). I believe that your message so, I think that understanding something about PKIX (X509) and EST is unavoidable, and I don't think we should clutter the document explaining those parts. > Section 2.3, para 5, line 4. In this document, the string ".well-known" > appears variously as ".well-known", "./well-known", and "/.well-known". > If these are in fact intentional, then the differences should be > explained. Otherwise, a consistent form should be ensured throughout > the document. Given that I do not know what is correct, or if they are > intended to be different, I have not signaled these cases in my General > Comments. You will have to do a search to discover all the instances. ./well-known is a typo. I've put / in front of every use. /.well-known refers to rfc5785. RFC7030 (EST) all lives under /.well-known/est. I've added a reference to 5785 at the first use of /.well-known. > Section 2.6, para 1. I find this entire paragraph puzzling. I believe > that more text is required here, in the hope that the use cases will be > clearer. Perhaps the use cases need to be stated first, followed by the > allowed actions. Max, I have added a paragraph to explain the legacy situation that the "Cloud <t> There are transitional situations where devices may be deployed into legacy networks that use proprietary bootstrapping mechanisms based upon the base EST (<xref target="RFC7030"/>). The same device may also be deployed into an ANIMA environment. This may be due to incremental replacement of a legacy situation with ANIMA. </t> <t> There are additionally some greenfield situations involving an entirely new installation where a device may have some kind of management uplink that it can use (such as via 3G network for instance). In such a future situation, the device might use this management interface to learn that it should configure itself by to-be-determined mechanism (such as an Intent) to become the local registrar. </t> <t> In order to support this scenario, the Pledge MAY contact a well known URI of a cloud Registrar if a > Section 3, para 1, line 6. What is the meaning of > '"proximity-registrar-cert" leaf'? What is the leaf a leaf of? If this > refers to some YANG module, please cite the YANG module. So the title of the section is "Voucher-Request artifact", and the entire section is about the YANG module ietf-voucher-request. I have added one phrase: "defined in this section" > Section 3.2, Example (2). Does this example illustrate _a_ Registrar > voucher-request, or does it illustrate the Registrar voucher-request > that would be used to forward Example (1)? If the former, why is the > nonce identical? If the latter, it should be explained that certain > other fields are carried forward as well. The nonce, created-on and assertion are carried forward. I have changed the text to say: The 'prior-signed-voucher-request' leaf is populated with the Pledge's voucher-request (such as the prior example). The pledge's voucher-request, if a signed artifact with a CMS format signature is a binary object. In the JSON encoding used here it must be base64 encoded. The nonce, created-on and assertion is carried forward. serial-number is extracted from the pledge's Client Certificate from the TLS connection. See <xref target="RequestVoucherFromMASA"/>.</t></list></t> > Section 4.1, para 2, bullet 2, line 3. "may" -> "MAY" (This "may" > seems to be normative.) Yes, thank you. > Para 7, line 2. "should" -> "SHOULD" done. > Section 5, para 8, bullet 1. The reference to RFC6125 appears to be > normative, and so RFC 6125 should be added to the list of (normative) > references. Added. > Section 5.4, para 9. This paragraph gives a series of actions that are > described in the introductory material as "validation checks". However, > the first bullet is describing a renewal action, not a validation check. > I suggest that the phrase "The MASA validation checks before issuing a > voucher are as follows:" be replaced with "The MASA performs the > following actions and validation checks before issuing a voucher:" changed. > Section 5.8, para 2, line 1. "the following EST" (I have no idea where > these "following" items are. The subsequent subsections are clearly not > extensions, so I cannot determine what is being referenced here. Since > this is a "recommendation", it is important that it be clear to the > reader what is intended. Changed to: <t>The Pledge is also RECOMMENDED to implement the EST automation extensions described below. They Max, I think that this is a "SHOULD" > Para 2. This paragraph is quite opaque to me. I cannot follow the > logic of the sequence of statements. Does the second sentence imply > "one-at-a-time" operation, or something else? In the third sentence, > requests will "look the same" as what? Each other, something else? I think that I don't know which paragraph you are referring to. > Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 > Distinguished Professor Emeritus fax: +1 (514) 848-2830 Onward to your other editorial comments. -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
