Hi,
This is my AD review for draft-ietf-anima-constrained-join-proxy-06.
Thanks for this document. I found it pleasant to read and only had minor
comments.
1.
Abstract:
This intermediary node is known as a
"constrained Join Proxy". An enrolled Pledge can act as a Join
Proxy.
Is a constrained Join Proxy and Join Proxy the same thing, or is one a subtype
of the other? I.e., would it be clearer to say that an enrolled Pledge can act
as a constrained Join Proxy?
2. Sec 2.
The term
"installation IP_address" refers to the set of addresses which are
routable over the whole installation network.
Is it referring to the set of addresses, or just one out of the set of
addresses?
3. Sec 4.
in an LLN mesh can be
LLN doesn't seem to be defined anywhere.
4. Sec 5.1, figure 2.
IP_P:p_P = Link-local IP address and port of Pledge (DTLS Client)
IP_R:5684 = Routable IP address and coaps port of Registrar
IP_Ja:P_J = Link-local IP address and join-port of Join Proxy
IP_Jb:p_Rb = Routable IP address and client port of Join Proxy
Really just a nit, but I assume that this is a naming scheme here, but I didn't
find it that intuitive, specifically for differentiating between a link-local
and routable IP address for the Join Proxy. E.g., I was wondering if IP_Jl:
and IP_Jr might be clearer., but I'll leave this entirely to the authors
discretion.
5. Sec 5.3.
The
Registrar replaces the 5th "content" element with the DTLS payload of
the response message and leaves all other array elements unchanged.
Possibly you could be more explicit that the message is sent back?
6. Sec 5.3
When additions are added to the array in later versions of this
protocol, any additional array elements (i.e., not specified by
current document) MUST be ignored by a receiver if it doesn't know
these elements. This approach allows evolution of the protocol while
maintaining backwards-compatibility. A version number isn't needed;
that number is defined by the length of the array.
So, presumably new elements can be added, but never removed again afterwards?
7. Sec 6.
| Ports | Join Proxy needs |Join Proxy and Registrar|
| | discoverable join-port |need discoverable |
| | | join-ports |
+-------------+----------------------------+------------------------+
At the point that I read this, I didn't understand why discoverable ports are
needed for both the Join Proxy and Registrar for the stateless mode. I think
that led me to the separate question as to whether it wouldn't make more sense
to have the section on Discovery before the comparison section.
8. Sec 7.
Three discovery cases are discussed: Join Proxy discovers Registrar,
Pledge discovers Registrar, and Pledge discovers Join Proxy. Each
discovery case considers three alternatives: CoAP discovery, GRASP
discovery, and 6tisch discovery.
When reading this, it wasn't entirely clear to me under what circumstances the
different discovery mechanisms would be used. Is it also possible that for
some networks multiple discovery mechanisms may be available, or would it
always be the case that only one would be deployed?
Finally, given the way that the options fall out, I did wonder if the document
might be more readable if the 2-dimensional array of options was described the
other way. I.e., grouped primarily by whether CoAP or GRASP or 6tisch
discovery is being used?
9. Sec 8.
Another possibility is to use level 2 protection between Registrar
and Join Proxy.
I don't understand what is meant by this.
---
Minor spelling and grammar warnings from an automated tool.
Spellings:
aplication,
neighbour,
neighbouring,
Obviously neighbour isn't a spelling mistake, but flagging in case the intent
is to be using American English :-)
Grammar Warnings:
Section: 7.1.2, draft text:
Autonomic Network Join Proxies MUST support GRASP discovery of Registrar as
described in section 4.3 of [RFC8995] .
Warning: Don't put a space before the full stop.
Suggested change: "."
Section: 7.2.1, draft text:
The discovery of the coaps Registrar, using coap discovery, by the Pledge
follows sections 6.3 and 6.5.1 of [I-D.ietf-anima-constrained-voucher]..
Warning: Two consecutive dots
Suggested change: "."
Section: 7.3.1, draft text:
Port numbers are assumed to be the default numbers 5683 and 5684 for coap and
coaps respectively (sections 12.6 and 12.7 of [RFC7252] when not shown in the
response.
Warning: Unpaired symbol: ')' seems to be missing
Section: 8, draft text:
All of the concerns in [RFC8995] section 4.1 apply.
Warning: Consider using all the.
Suggested change: "All the"
Regards,
Rob
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
