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

[Michael Richardson <[e-mail]>]

    > 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   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [