Re: [Gen-art] [Anima] Genart last call review of draft-ietf-anima-constrained-join-proxy-09
Hi Michael, I liked the reference to RFC6550 because it shows that other RFCs provide the same modes; and it was argued to standardize only one mode. Peter Michael Richardson schreef op 2022-04-11 20:04: The document defines a mechanism to assign a Device (Pledge) to a (anima) domain, represented by a Registrar, using an intermediate node (e.g. 6LR) called constrained Joint Proxy. Once that the Pledge is enrolled to the network, it can take the role of a Joint Proxy. While what you write is not false: once enrolled, a node can take on the role of join proxy. But, it makes it sound like the purpose of enrollment is to become a join proxy. The purpose of enrollment is to carry out the revenue generating portion of the network... becoming a join proxy is a burden, it's about "paying it forward" https://en.wikipedia.org/wiki/Pay_it_forward Additional Comments/Questions: * Which are the differences between a "Circuit-proxy" and a "stateful constrained join Proxy"? I understand that both are stateful join proxy Mostly they are two terms for almost the same thing. Properly implemented, they are indistinguishable from outside. Internally, a circuit proxy involves two actual sockets, with an application space loop to copy A->B and B->A. For TCP, there are some complexities if you chose to implement TCP urgent alerts. A stateful xxx proxy would be NAT44, occuring at the network rather than application layer. NEW This document standardizes the CoAP/DTLS (method 4). The specified constrained Join Proxy extends the circuit proxy by using coaps DTLS ports, by choosing the DTLS destination address and by specifying a stateful and a stateless mode. The stateful and stateless modes have the same purpose as the storing and non_storing Modes of Operations (MOP) of RPL {{RFC6550}}. Is this OK? I think that this is a bit of a Ines-specific answer. I'm not sure that making allusions to RFC6550 here is helpful for the general reader. Maybe: The stateful and stateless modes differ in the way that they store the state required to forward the return packet to the pledge. Similar to the difference between storing and non_storing Modes of Operations (MOP) in RPL {{RFC6550}}. In the stateful method, the return forward state is stored in the join proxy. In the stateless method, the return forward state is stored in the network.___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [Anima] Genart last call review of draft-ietf-anima-constrained-join-proxy-09
> The document defines a mechanism to assign a Device (Pledge) to a > (anima) domain, represented by a Registrar, using an intermediate node > (e.g. 6LR) called constrained Joint Proxy. Once that the Pledge is > enrolled to the network, it can take the role of a Joint Proxy. While what you write is not false: once enrolled, a node can take on the role of join proxy. But, it makes it sound like the purpose of enrollment is to become a join proxy. The purpose of enrollment is to carry out the revenue generating portion of the network... becoming a join proxy is a burden, it's about "paying it forward" https://en.wikipedia.org/wiki/Pay_it_forward > Additional Comments/Questions: > * Which are the differences between a "Circuit-proxy" and a "stateful > constrained join Proxy"? I understand that both are stateful join proxy Mostly they are two terms for almost the same thing. Properly implemented, they are indistinguishable from outside. Internally, a circuit proxy involves two actual sockets, with an application space loop to copy A->B and B->A. For TCP, there are some complexities if you chose to implement TCP urgent alerts. A stateful xxx proxy would be NAT44, occuring at the network rather than application layer. > NEW > This document standardizes the CoAP/DTLS (method 4). The specified > constrained Join Proxy extends the circuit proxy by using coaps DTLS > ports, by choosing the DTLS destination address and by specifying a > stateful and a stateless mode. The stateful and stateless modes have > the same purpose as the storing and non_storing Modes of Operations > (MOP) of RPL {{RFC6550}}. > Is this OK? I think that this is a bit of a Ines-specific answer. I'm not sure that making allusions to RFC6550 here is helpful for the general reader. Maybe: The stateful and stateless modes differ in the way that they store the state required to forward the return packet to the pledge. Similar to the difference between storing and non_storing Modes of Operations (MOP) in RPL {{RFC6550}}. In the stateful method, the return forward state is stored in the join proxy. In the stateless method, the return forward state is stored in the network. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works|IoT architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ signature.asc Description: PGP signature ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [Anima] Genart last call review of draft-ietf-anima-constrained-join-proxy-09
Hi Ines, Many thanks for your review. Please see inline comments below. Greetings, Peter Reviewer: Ines Robles Review result: On the Right Track I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at https://trac.ietf.org/trac/gen/wiki/GenArtfaq. Document: draft-ietf-anima-constrained-join-proxy-09 Reviewer: Ines Robles Review Date: 2022-04-08 IETF LC End Date: 2022-04-08 IESG Telechat date: Not scheduled for a telechat Summary: The document defines a mechanism to assign a Device (Pledge) to a (anima) domain, represented by a Registrar, using an intermediate node (e.g. 6LR) called constrained Joint Proxy. Once that the Pledge is enrolled to the network, it can take the role of a Joint Proxy. I understand that the document is going currently under modifications, new text is being proposed into the Mailing List (e.g. updates on section 4, etc.), and the open issues are being tracked into github [https://github.com/anima-wg/constrained-join-proxy/issues/] Pvds==> Thanks for taking into account the github contents ==> Additional Comments/Questions: * Which are the differences between a "Circuit-proxy" and a "stateful constrained join Proxy"? I understand that both are stateful join proxy entities, right? (Maybe the difference is in the constrained level?). In the abstract states that they replace each other. Maybe a better description could be: "instead of having only stateful join proxy (Circuit-proxy) mode, this spec also include the stateless join proxy mode", is this correct? Pvds ==> At the end of section 2 NEW This document standardizes the CoAP/DTLS (method 4). The specified constrained Join Proxy extends the circuit proxy by using coaps DTLS ports, by choosing the DTLS destination address and by specifying a stateful and a stateless mode. The stateful and stateless modes have the same purpose as the storing and non_storing Modes of Operations (MOP) of RPL {{RFC6550}}. Is this OK? ==> 2- Terminology Section: 2.1- It mentions JCR, but in the text is used "Registrar", thus, it could be mentioned here that both refers to the same. Pvds==> NEW In this document, the term "Registrar" is used throughout instead of "Join Registrar/Coordinator (JRC)". ==> 2.2- Other terms such as TOFU, MASA and imprint are never used through the document [Maybe it should be described (in SEC. section?) how these terms are related in this document (if applicable)]. Pvds==> Right, very good. They are removed ==> 2.3- Additionally, it would be nice to include the definition of the: a) "constrained Joint Proxy" [smth similar what RFC9030 defines?]; pvds==> NEW The "Constrained Join Proxy" enables a pledge that is multiple hops away from the Registrar, to securely execute the BRSKI protocol {{RFC8995}} over a secure channel. ==> b) "Stateful and Stateless mode" (the text from the introduction could be moved to this section); * c) circuit-proxy (refer to RFC8995?) pvds==> see text end of section 2 ==> * What happens when a joint-proxy restart in a stateful mode during a joining message flow? Pvds==> That is a new aspect for me; see below ==> * Just for better understanding: E.g. If a Pledge participates in two different use cases, meaning two different domains, then is it possible that the Pledge become Stateful and Stateless Join Proxy (in different domains)?. I understand that this is possible, but not useful, since the device will include the specification complexity of both modes. Thus, I could think that it is recommended to select the same mode for all the domains that a device join? This could be a decision point whether to become or not a joint proxy? (Although, at the end of the day it could be defined by the use case requirements/available network resources). * Section 5, Page 6: "..A Join Proxy MAY implement both, with an unspecified mechanism to switch between the two modes." I understand that it refers to one single domain, I do not understand the meaning of "unspecified mechanism". Maybe it should read: "the mechanism to switch between modes is not in the scope of this document" ? Pvds==> NEW A Join Proxy MAY implement both. A mechanism to switch between modes is out of scope of this document. It is recommended that a Join Proxy uses only one of these modes at any given moment during an installation lifetime. ==> * Section 5.1, Page 6: "...The Join Proxy maintains a 4-tuple array to translate the DTLS messages received from the Registrar and forwards it back to the .." Translate the DTLS message to what? Please clarify. pvds==> NEW The Join Proxy stores the 4-tuple array of the messages received from the Registrar and copies it back to the header of the message re