Hi Peter, Sounds good –could I reverse the order, i.e. look at the diffs in the new I-D first and then complain? (I may skip the complaining part if everything looks ok ;-) )
Esko From: Anima <[email protected]> On Behalf Of Peter van der Stok Sent: Monday, March 21, 2022 10:25 To: Rob Wilton (rwilton) <[email protected]> Cc: [email protected]; [email protected] Subject: Re: [Anima] AD review for draft-ietf-anima-constrained-join-proxy-06 Hi Rob, thanks for the review and the encouragements. Below my reactions on your points. When you agree with the proposed changes, and nobody else complains, I will submit the new I-D at the end of this week. Greetings, Peter Rob Wilton (rwilton) schreef op 2022-03-18 15:44: 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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/anima
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
