Reviewer: Russ Housley
Review result: On the Right Track
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
=> Concern is understood.
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.
=> I will try to balance the text in sections 1 and 2.
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.
=> will put in a "for example, ...."
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.
=> as Michael wrote: to be handled in section 1, telling that a pledge after enrollment can become a join proxy.
and a pledge is "constrained".
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.
=> Ok
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.
=> this is new to me, thanks. will change.
Section 1, 3rd para: s/artefacts/artifacts/
=> Ok
Section 1, 4th para says "new Pledge". When is a Pledge not new?
=> will try to avoid tautologies.
Section 5.2: s/"new" JPY message/newly specified JPY message/
=> see the point. will think up text.
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]/
=> Oopst, this needs mkd engineering.
Section 7.1.1: s/CoAP discovery{#coap-disc}/CoAP discovery/
=> missed that one as well.
=> thanks, will let you know when the "new" version is available.
Peter
_______________________________________________
Anima mailing list
Anima@xxxxxxxxhttps://www.ietf.org/mailman/listinfo/anima