Russ, many thanks for your review and kindly replies. It is good for authors and ANIMA WG.
Best regards,
Sheng
> -----Original Message-----
> From: Russ Housley via Datatracker <noreply@xxxxxxxx>
> Sent: Tuesday, November 2, 2021 2:51 AM
> To: iot-directorate@xxxxxxxx
> Cc: anima@xxxxxxxx; draft-ietf-anima-constrained-join-proxy.all@xxxxxxxx;
> last-call@xxxxxxxx
> Subject: Iotdir last call review of
> draft-ietf-anima-constrained-join-proxy-05
>
> 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
>
> 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-vouch
> er]/
>
> Section 7.1.1: s/CoAP discovery{#coap-disc}/CoAP discovery/
>
>
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
