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-15
Reviewer: Russ Housley
Review Date: 2023-08-09
Review Due Date: 2023-09-08 


A review from the IoT Directorate was requested on 2023-08-08.


Summary: Almost Ready


Major Concerns:

Abstract uses terms that are not defined until the reader is well
onto the document.  This can be avoided by talking about the concepts
at a much higher level.

Section 4.1, para 2: This paragraph is very confusing.  I suggest that
you have separate paragraphs for:

   1) The Join Proxy learns the IP address and port of the Registrar;
   2) The Pledge discovers one or more Join Proxy and then selects one;
   3) The Pledge sends a message to the Join Proxy; and
   4) The Join Proxy forwards the message to the Registrar, keeping the
      needed context to send a response back the the Pledge.

Only in Figure 2 do we see an traffic that goes to the Pledge.  The
above should probably be expanded to cover that too.

Section 4.2: This section is very confusing.  I think that a "context
payload" and "pledge_context_message" are the same thing, but after
reading it more than once, I am not sure.  Further, it is not context
provided by the pledge; rather, it is context made up by the Join Proxy
about the Pledge.  Also, the context is part of a message, not a message
in itself.

Section 5.2.3: I believe that the 6tisch discovery process can be used
by the Pledge to find an appropriate Join Proxy, and then DTLS is used
for the Pledge-to-Registrar traffic that is sent via the Join Proxy.
The current wording makes me doubt this understanding.


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.  I made this comment in
an earlier review and it was not addressed.  At a minimum, the Abstract
should make this point very clear.

Section 4.3: It would be helpful to put the discussion of the example
pledge_context_message structure in a separate subsection.


Nits:

Throughout: Please pick one spelling for Join Proxy.  I see all of the
following "Join Proxy", "join Proxy", "join proxy", "Join-Proxy".
Further, sometimes is is used with "Constrained" and other times it is
used with "constrained".  I kept asking myself if there was some meaning
that I was missing in these various different spellings.  If there is
a difference, please explain it in Section 2.

Section 1: I think there is a better way to talk about "new
(unconfigured) devices."  I can think of two possible ways to better
describe the devices.  One alternative is to talk about yet-to-be-
configured devices.  The other approach would be to talk abot devices
in their factory default configuration.

Section 1: s/other IP-over-foo networks/other IP networks/

Section 1: s/is pointed at/provided/

Section 1: s/Coap/CoAP/

Section 1: s/Registrar but several hops away,/Registrar, but several hops away,/

Section 1: s/non_storing/non-storing/

Section 2: It would be better to avoid talking about the "Join
Registrar/Coordinator (JRC)" twice.  Suggest dropping the first one,
and then replacing the second with:

   The term "Registrar" is used throughout this document instead of
   "Join Registrar/Coordinator (JRC)" as defined in [RFC8366].

Section 3: Why are there no capital letters in the section heading?

Section 3: s/IP-address/IP address/

Section 3, Figure 1: Nothing is labelled as a "Low-Power and Lossy
Network (LLN)".  The text talks about a LLN, but it is not there.

Section 3: s/Without routing/Without multi-hop routing,/

Section 5.1: s/if stateless operation /whether stateless operation/

Section 5.1.2: s/figure 10/Figure 10/

IDnits complains that there are 8 instances of too long lines in the
document, the longest one being 33 characters in excess of 72.

IDnits complains about an obsolete normative reference to RFC 6347,
which is obsoleted by RFC 9147.