Subject: [Iot-directorate] Iotdir last call review of draft-ietf-anima-constrained-join-proxy-05

From: Russ Housley via Datatracker <[email-masked]>
Date: Mon, 01 Nov 2021 11:51:22 -0700

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-voucher]/

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 01 Nov 2021 15:33:58 -0400

> that is intended to support constrained Pledges.

We expect that in a LLN mesh that constrained devices will be providing proxy
service to new devices.

How can we make this point clearer?

Thank you for the rest of your comments, and Peter and I will work on them this week.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Russ Housley <[email-masked]>
Date: Mon, 1 Nov 2021 15:43:18 -0400

> How can we make this point clearer?

I think that the Introduction needs to define Join Proxy, and in that paragraph you can say more about the nature of the device that is expected to provide this function.

Russ

---

From: Peter van der Stok <[email-masked]>
Date: Tue, 02 Nov 2021 09:29:39 +0100

HI Russ,

thanks for the comments.

Below some partial reactions.

Peter
Russ Housley via Datatracker schreef op 2021-11-01 19:51:

> => Concern is understood.
> 
> => I will try to balance the text in sections 1 and 2.
> 
> => will put in a "for example, ...."
> 
> Minor Concerns:
> 
> => 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:
> 
> => Ok
> => this is new to me, thanks. will change.
> 
> => Ok
> => will try to avoid tautologies.
> 
> => see the point. will think up text.
> 
> Section 7:
> => Oopst, this needs mkd engineering.
> 
> => missed that one as well.
> 
> => thanks, will let you know when the "new" version is available.
> 
> Peter
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Peter van der Stok <[email-masked]>
Date: Tue, 02 Nov 2021 12:34:10 +0100

HI Russ,

Many thanks again for the review.

I think all issues have been handled in the text now stored in the 
anima-wg github:
https://github.com/anima-wg/constrained-join-proxy.

Clicking on "Review by Russ Housley"  [1]will show the diff.

Many thanks,

Peter

>> => thanks, will let you know when the "new" version is available.

Links:
------
[1] 
https://github.com/anima-wg/constrained-join-proxy/commit/2cfa2677594aea2c289791ec5bd2ac4aa088322d

---

From: Russ Housley <[email-masked]>
Date: Tue, 2 Nov 2021 15:40:54 -0400

Based on the notes below, it looks like you have understood my commends and handled them.

Russ

> On Nov 2, 2021, at 4:29 AM, Peter van der Stok <[email-masked]> wrote:
> 
> HI Russ,
> 
> thanks for the comments.
> 
>> => as Michael wrote: to be handled in section 1, telling that a pledge after enrollment can become a join proxy.
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/anima <https://www.ietf.org/mailman/listinfo/anima>

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 3 Nov 2021 03:50:59 +0000

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 <[email-masked]>
> Sent: Tuesday, November 2, 2021 2:51 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Iotdir last call review of
> draft-ietf-anima-constrained-join-proxy-05
> 
> Reviewer: Russ Housley
> IoT-related IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the Internet Area
> Directors.
> 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:
> 
> alternaive is to provide a pointer early in Section 1 that an understanding
> of the terms in Section 2 is assumed.
> 
> 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:
> 
> However, the Join Proxy is not constrained.  Rather, it is a Join Proxy that
> is intended to support constrained Pledges.
> 
> 
> Nits:
> 
> References are not permitted in the Abstract.  In addition, CoAP should
> be spelled out of give a bit more context.
> 
> and RFC 8559 both use the second spelling.  Consistency seems like a
> good idea to me.
>