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?
pvds =>
Agree with your suggestion. Terminology reduction is always good.
==>
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?
NEW ==>
The term "installation IP_address" refers to an address out of the set
of addresses which are routable over the whole installation network.
==>
3. Sec 4.
in an LLN mesh can be
LLN doesn't seem to be defined anywhere.
NEW==>
the Pledge (P), in a Low-Power and Lossy Network (LLN) mesh
{{RFC7102}} can be more than one hop away from the Registrar (R)
==>
Ignoring Carsten's remark about being badly defined.
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.
pvds==>
Thanks, is clearer; changed as suggested in both figures
==>
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?
NEW==>
After replacing the 5th "content" element with the DTLS payload of the
response message and leaving all other array elements unchanged, the
Registrar returns the response message.
==>
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?
pvds==>
Yes, I addedd:
NEW==>
However, this means that message elements are consistently added to
earlier defined elements to avoid ambiguities.
==>
==>
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.
pvds==>
I see your point and put discovery section before 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?
NEW==>
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. It depends on the type of installation
which discovery mechanisms are offered. It can be imagined that
manufacturers provide the pledge/join-proxy with more than one
discovery mechanism. The pledge/join-proxy can try one after the other
mechanism untill success is reached. Alternatively, at installation a
switch is set to determine the discovery mechanism.
==>
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?
pvds==>
This section has seen several structures, where this last structure
seemed to give the best results to generate readable text
==>
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.
NEW==>
In some installations, level 2 protection is provided between all
member pairs of the mesh. In such an enviroment encryption of the CBOR
array is unnecessay because the level 2 protection already provides it.
==>
---
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 :-)
pvds==>
changed to american spelling convention
==>
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: "."
pvds==>
thanks, done
==>
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: "."
pvds==>
done
==>
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
pvds==>
corrected
==>
Section: 8, draft text:
All of the concerns in [RFC8995] section 4.1 apply.
Warning: Consider using all the.
Suggested change: "All the"
pvds==>
also removed
==>
Regards,
Rob
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
