Christian Amsüss <christ...@amsuess.com> wrote:
    >> It's not unidirectional!  I'm not able to parse "semi-" here, but I
    >> suspect that is what you are trying to get at.

    > What I meant was "duplex, but one side can only reply to traffic
    > initiated by the other"; I think we're in agreement here.

There are situations in DTLS where more than one "reply" packet has to be sent 
by the
server, or where it needs to initiate an interaction.   But, you are right
that the tunnel can only be initiated via the pledge.

    >> > Given that this only works locally (if it were run > separately,
    >> that separte entity would need to keep state, whereas the
    >>
    >> I'm not sure what you mean, "only works locally" Do you mean it only
    >> works on the localhost, on the link-local, or in the local
    >> (autonomous) network?

    > What I meant by "working locally" was that the UDP endpoint that is the
    > server in the JPY protocol typically resides on the same host as the
    > one UDP endpoint that server in CoAPS -- in figures 2 and 3, this is
    > the case by both being IP_R:something.

yes, you are right: the mechanism is easiest to implement inside of the
Registrar itself, as it an put the extra state into the DTLS context.
But, it could also be done with a stateful join proxy :-)

    >> The join-proxy is the thing looking for this resource, not the
    >> (pledge) end node.  The pledge can tunnel a RD through the COAPS to
    >> get a list of things.

    > Outside of all the .jp and .rjp proxy addresses, can you give an
    > example of the concrete resources the pledge would want to discover
    > at/through the join proxy? In section 6.2.1 it discovers transport, but
    > I suppose at a later step it will want to discover a path for a
    > concrete resources (dunno, maybe an rt=brski.es or brski.rv), where
    > would it currently learn that?

    > These lines might be a good starting point to work out a more concrete
    > example with a `;jpy-port=...` option.

I think that this is in the other thread now.

--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-



Attachment: signature.asc
Description: PGP signature

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Reply via email to