Last Call Review of draft-ietf-anima-constrained-join-proxy-05
review-ietf-anima-constrained-join-proxy-05-iotdir-lc-housley-2021-11-01-00

I reviewed this document as part of the IoT Directorate's effort to
IoT-related IETF documents being processed by the IESG.  These comments
were written primarily for the benefit of the Internet Area Directors.
Document authors, document editors, and WG chairs should treat these
comments just like any other IETF Last Call comments.

Document: draft-ietf-anima-constrained-join-proxy-05
Reviewer: Russ Housley
Review Date: 2021-11-01
Review Due Date: 2021-11-19


A review from the IoT Directorate was requested on 2021-11-01.


Summary: Almost Ready


Major Concerns:

Section 1: The first paragraph starts rather abruptly, and the first
sentence is a bit cumbersome.  I think it needs to begin with a bit
more background to define: 

  - Bootstrapping Remote Secure Key Infrastructure (BRSKI)
  - secure zero-touch bootstrap
  - pledge
  - registrar
  - proxy
  - IDevID certificate

Some of these are covered in Section 2, but not all of them.  The
alternaive is to provide a pointer early in Section 1 that an
understanding of the terms in Section 2 is assumed.

Then, the second paragraph says that "specified solutions use https and
may be too large in terms of code space or bandwidth required for
constrained devices."  This should cite those "specified solutions".
The last paragraph of Section 1 provides some of this, but it would
help for this information to be earlier in the section.


Minor Concerns:

Title: The title is "Constrained Join Proxy for Bootstrapping Protocols".
However, the Join Proxy is not constrained.  Rather, it is a Join Proxy
that is intended to support constrained Pledges.


Nits:

Abstract:  The reference to [RFC8995] should be replace with text.
References are not permitted in the Abstract.  In addition, CoAP
should be spelled out of give a bit more context.

Section 1:  I was surprised that "Enrolment" was used instead of
"Enrollment".  Apparently both spellings are okay. However, RFC 7030
and RFC 8559 both use the second spelling.  Consistency seems like
a good idea to me.

Section 1, 3rd para: s/artefacts/artifacts/

Section 1, 4th para says "new Pledge".  When is a Pledge not new?

Section 5.2: s/"new" JPY message/newly specified JPY message/
              
Section 7:
   The "Near" and "Remote" paragraphs are not properly indented. 
   s/{{I-D.ietf-ace-coap-est}}/[I-D.ietf-ace-coap-est]/
   s/{{I-D.ietf-anima-constrained-voucher}}/[I-D.ietf-anima-constrained-voucher]/

Section 7.1.1: s/CoAP discovery{#coap-disc}/CoAP discovery/