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

[Esko Dijk <[e-mail]>]

Hi Christian,

Sorry for having missed the discussion. Here some additional notes:

You mention that this usage is a bit strange, as it doesn't seem to be about resource type of any particular resource:
>
> * <coaps+jpy://[2001:db8:0:abcd::52]:7634>;rt=brski.rjp

What the JP wants to discover here is not one particular resource, but "any resources for doing Constrained BRSKI" in combination with requesting a particular access protocol (scheme: coaps+jpy) for these.  Maybe this combination makes it weird, but it seems to work ok.
Note that the "any resources" do not need to be named individually, that would be unnecessary, as the JP only relays DTLS frames to it and does not actually use those resources. The Pledge does that.
Another reason these "resources" do not need to be named specifically, is that these are well-known resources. Since these reside at well-known URI paths they do not need explicit discovery.  Only the fact that they exist at the endpoint matters.

The following response would maybe alleviate your concerns:
* <coaps+jpy://[2001:db8:0:abcd::52]:7634/.well-known/brski>;rt=brski.rjp

But it would be more bytes for no additional value - semantics are the same.

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

I sent an ANIMA email with considerations about why this is, I was wondering too. Here is the mail: https://mailarchive.ietf.org/arch/msg/anima/57-KoigPOQtfjt8fCjvm2aKhrCo/
In short, if we want a network operator to determine stateless vs stateful JP type we need it to be like written currently.
If we want a device vendor to determine stateless vs stateful JP type, and the network must always adapt to this choice, we need to write it like you suggest.

>
> the `?rt=brski*` does not offer all relevant information any more

I also sent a mail about why a '?rt=brski*' would be needed, see https://mailarchive.ietf.org/arch/msg/anima/KbWQKsfFVbTWMijjm1WxCUG6908/ . 
This is only in case the JP wants to discover which of stateful/stateless are supported in the current network, in a single query, see case 3. The individual resources /rv, /vs etc. it never needs.
Btw the Pledge also doesn't need to discover any BRSKI resources: it just uses the /.well-known/brski ones. Section 6.5.1 of draft-ietf-anima-constrained-voucher also says the Pledge SHOULD NOT do discovery for the EST resources as it's more efficient to just use the well-known ones.

Regards
Esko


-----Original Message-----
From: core <[e-mail]> On Behalf Of Christian Amsüss
Sent: Wednesday, September 14, 2022 18:07
To: Michael Richardson <[e-mail]>
Cc: Marco Tiloca <marco.tiloca=[e-mail]>; [e-mail] WG ([e-mail]) <[e-mail]>; [e-mail]
Subject: Re: [core] Join-proxy information in the RD (Re: CoRE WG Virtual Interim 2022-09-14)

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