Re: [core] Join-proxy information in the RD (Re: CoRE WG Virtual Interim 2022-09-14)

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

Hello Michael, CoRE, and join-proxy authors,

On Tue, Sep 13, 2022 at 10:22:24PM +0200, Michael Richardson wrote:
> thank you for bringing this up again.

I've had a few comments around this which I somehow failed to deliver to
the right people -- this was primarily assembled in the context
reviewing the use of rt=, but the comments necessitated widening the
scope. Some questions embedded, answering which might help getting
progres here.

---

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

  At the minimum, I think this should use a dedicated target attribute
  rather than the rt=, as Resource Type semantics are (in all their
  vagueness) still about a concrete resource and not about the protocol
  endpoint identified with that URI. However, see below around coaps+jpy
  for additional suggestions that'd make this obsolete.

* Similarly, the query for ?rt=brski.jp returns a resource, when it is
  actually asking for a transport endpoint. Moreover, there *are*
  resources available that the pledge likely will need to discover (any
  of the brski.rv/vs/es). Before I can make any good statements or
  suggesions here, how is it currenlty envisioned that the pledge will
  find these resources?

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

  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. Given that this only works locally (if it were run
  separately, that separte entity would need to keep state, whereas the
  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`)?

  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.

* 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
  that doesn't gain anything from stateless (because its platform only
  provides an `accept()` based API that has per-ciient state anyway),
  but if I implemented an embedded JP, I'd very much prefer to only do
  stateless mode (to keep code size small and testable), violating the
  MUST on implementing both and moreover depending on the JR to
  implement the SHOULD.

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

[1]: https://www.ietf.org/archive/id/draft-ietf-core-transport-indication-01.html#name-using-uris-to-identify-prot

BR
c

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom