Re: [Anima] Genart last call review of draft-ietf-anima-constrained-join-proxy-09

[Peter van der Stok <[e-mail]>]

  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.