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

[Michael Richardson <[e-mail]>]

Hi, I've added [e-mail], and removed some of the direct CC's, because I
know those people are on the MLs.  I will also reply a few times with the
intention of splitting up the discussion into better threads.

Christian Amsüss <[e-mail]> wrote:
    > There are some aspects about both rt= that make me concerned:

    > * <coaps+jpy://[2001:db8:0:abcd::52]:7634>;rt=brski.rjp

    >   This indicates that there is a resource at the given URI that can be
    > interacted with in some way described by this resource type. But while
    > there may be also a resource there (in particular, the `/` resource of
    > the forward target), that's not what this line is making a statement
    > about. This line is making a statement about the transport endpoint
    > associated with the URI (which is a bit of a hack but does not disturb
    > the semantics of the remaining URI metadata ecosystem; at [1] I'm
    > developing terminology for that).

I agree that it's awkward.

    >   At the minimum, I think this should use a dedicated target attribute
    > rather than the rt=, as Resource Type semantics are (in all their

I don't have a problem with changing rt= to something else completely.

    > * Only partially related, the whole coaps+jpy scheme (which looks to me
    > really more like a generic semi-unidirectional UDP tunnel than anything
    > CoAP related) might not need registration at all.

It's not unidirectional!
I'm not able to parse "semi-" here, but I suspect that is what you are trying
to get at.  

    >   The relevant metadatum which is transported in this (AIU) is that for
    > some UDP port (eg. [2001:db8:0:abcd::52]:5684), there is an additional
    > UDP port (currently advertised as
    > `<coaps+jpy://[2001:db8:0:abcd::52]:7634>;rt=brski.rjp`) that has
    > equivalent destination semantics but does all the state-keeping and
    > unwrapping.

Yes, that's totally correct.
In practice, we can do whatever smells the least.
Our goal is simply to have a pure-RD mechanism for networks that want CoAP
and do not want GRASP or mDNS.

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

Yes, the Join Proxy probably has a ULA, and I expect the reply will be a ULA,
but there is nothing in the protocol that constrains that.  Yes, I use the
GUA documentation prefix in the examples.
(I actually started to write a draft in 6man creating a documentation prefix
in ULA-R space) 

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

    >   There is a downside compared to the current approach -- the
    > `?rt=brski*` does not offer all relevant information any more.
    > However, the registrar may still offer the `</>;jpy-port=7634` the line
    > even when it does not match the filters, given that query filtering is
    > generally optional, or offer it on any of the brski.* lines reported.

Yes, that's true.
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.

    > * In unrelated comments, I find it odd that the JP MUST implement both
    > and the registrar only SHOULD do stateless. I can well imagine a JP

I think that we changed this.... at least, I want to.

    >   I think that "JP may implement either, JR MUST support both" would be
    > better..

I did put that into my presentation for 114.
It's possible we didn't implement that conclusion into the ID.


-- 
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-