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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux