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 <william.atw...@concordia.ca> 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 <mcr+i...@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-



Attachment: signature.asc
Description: PGP signature

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Reply via email to