William Atwood <> 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
          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.
          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.
          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 
                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"


    > 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.


    > 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:"


    > 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 <>, Sandelman Software Works
 -= IPv6 IoT consulting =-

Attachment: signature.asc
Description: PGP signature

Anima mailing list

Reply via email to