Subject: [Anima] Review of draft-ietf-anima-voucher-02

From: Sheng Jiang <[email-masked]>
Date: Mon, 15 May 2017 09:45:08 +0000

Hi, authors of draft-ietf-anima-voucher,

I am doing a thorough review as the document shepherd with my ANIMA chair hat on. Please address the below comments so that we could process this document further. I cannot claim myself a security expert, so extra security expert review is needed, either in WGLC or IESG review stage.

Firstly, there is report that this document has warnings or errors returned by YANG validation. Please

Secondly, please check the references and normative words. This document has a "MUST not", which is not an accepted usage according to RFC 2119. RFC6066 & RFC5652 has been quota in the document, but not defined; and normative reference to an Informational RFC 2315.

Thirdly, there are 19 question marks in the document. Most of these are discussed and reach conclusions, I believe. Please remove these question marks and relevant text. If there are still open questions, please discuss in mailing list and address them, before we could process WGLC.

In section 2, The quota from Konrad Lorenz should be put into quotation marks.

"This document describes vouchers in detail."It is better to give a reference to the specific section 4.

In definition of Domain CA, "Optionally, it certifies all elements." What does the term "element" mean? This term does not appear anywhere else in the document.

In definition of MASA, "It does not track ownership." It is not clear for me, whether the MASA is technically not be able to track ownership or in the commercial deployment model, it MUST NOT/SHOULD NOT track ownership. There is no enough description or discussion on the relationship between the MASA and device ownership.

A few inconsistent for capital abbreviation, such as cn-id, dns-id, etc.

A few DISCUSS & EDNOTE from editor notes should be removed.

The normative words in design consideration seems odd for me. The design consideration means not protocol definition neither behavior specification although security consideration may be specification in my eyes. It should not have normative words.

Typo: "informative", "informative"; "Circustance", "Circumstances"; "maintanence", "maintenance"; hardware security modules (HSMs), Hardware Security Modules (HSMs).

Regards,

Sheng

---

From: Michael Richardson <[email-masked]>
Date: Mon, 15 May 2017 10:12:15 -0400

> I am doing a thorough review as the document shepherd with my ANIMA

okay.  We'll work through these on Tuesday (tomorrow).

    > A few DISCUSS & EDNOTE from editor notes should be removed.

Well, they are there to keep us from advancing the document with issues
unresolved :-)

    > The normative words in design consideration seems odd for me. The
    > design consideration means not protocol definition neither behavior
    > specification although security consideration may be specification in
    > my eyes. It should not have normative words.

Perhaps naming it Design Considerations is the error.
I don't see the normative words there as wrong; they need to be there.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-