Re: [core] discovery of Registrar by stateless Join-Proxy (was Re: Join-proxy information in the RD (Re: CoRE WG Virtual Interim 2022-09-14))

[Christian Amsüss <[e-mail]>]

Hello Michael,

> 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.

>     > 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.

While in theory these might be separate services (with the process
serving IP_R:p_Ra forwarding requests through some mechanism to
IP_R:5684), my impression is that this is most efficiently implemented
as one, and in particular that it is expected that only p_Ra (and not a
separate address) needs to be advertised.

>     > local service can take shortcus and only keep state after DTLS got
>     > established), might it not be a better option to just advertise that
>     > the CoAPS port has a an additional way in, say,
>     > `<coaps://[2001:db8:0:abcd::52]/>;jpy-port=7634` (abbreviated as
>     > `</>;jpy-port=7634`)?
> 
> We looked at ways which would allow us to insert the state information into
> the DTLS framing, like we can when CoAP is on the outside, but that couldn't
> be done in a way that didn't violate the crypto context of DTLS.

All the suggestions I've made purely relate to how this is discovered,
not any changes on the wire outside of discovery.

> 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.

BR
c

-- 
We are dreamers, shapers, singers, and makers.
  -- Elric