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
