Hi Christian,
(cc on anima and core WG lists)
thanks for spelling out your reasoning steps - that's helpful. It all
looks as we intended in the draft
(draft-ietf-anima-constrained-join-proxy). Below are a few comments on
selected parts of your email:
When the join proxy discovers a stateful registrar, for the stateful
case it finds that:
<coaps://[IP_R]:p_R/R_path>;rt=brski
(AIU it discards R_path because AIU, the pledge will discover that on
its own through DTLS).
Correct, in the case the Registrar is discovered. It could also be
configured in some way, e.g. only as an IPv6 address and port. This
could be configured as network-wide data (this concept is used in Thread
mesh networks) or in a DHCPv6 option, or so.
which *could* be expressed in link format using similar terminology as
transport-indication as:
<jpy://[IP_R]:p_Rj>;rel="has-portforwarding";anchor="coaps://[IP_R]:p_R"
In this case, the JP doesn't really need the anchor information. We
would preferably not send anything that's not needed.
or maybe (with some handwaving)
<coaps://coaps-over-statelessudp.alpn.p_Rj.port.IP_R.6.service.arpa>;rel="has-unique-proxy";anchor="coaps://[IP_R]:p_R"
but I don't expect that you want to look up two things in a row or
This has somewhat higher complexity for the reader's minds needing to
parse this - and again information the JP doesn't need I think.
The JPs are not necessarily Link Format parsing adepts - they would
typically assume some "template" like form and get the IP address and
port out of that.
depend on the still experimental service.arpa thing, so a simpler
expression could be pretty much what you have (sans the coap part):
<jpy://[IP_R]:p_Rj>;rt=brski.jp
Small detail: we use brskip.rjp for advertising the JPY protocol
endpoint. Type "brski.jpy" could be an alternative name, but this might
be confused with "advertising the join proxy's service".
which can have semantics like this:
"There exists a resource of rt=brski (on a host/port I'm not telling
you, and on a path I'm not teling you either), and the indicated
Correct - it's not telling the original info for this resource in this
case, as the JP wouldn't use that. It might also not be accessible
externally even - e.g. in a Registrar deployment where only stateless
mode has been enabled/allowed.
There's the implicit assumption also that on the given host/port, the
path /.well-known/brski does exist and this doesn't need to be told
because it's well-known.
Note that there's nothing in the rt that really tells you *how* to talk
UDP to that resource -- that could be in the if=, but we don't need an
if= because the *how* is really clear from the scheme ("send a JPY
header and then data"). Funnily, had you decided to do UDP-over-CoAP,
the target URI there could have been a CoAP URI, but that discussion has
been had and it seems fine to go raw CBOR-over-UDP there.
Indeed there was a discussion some years ago, whether to use plain
coap:// instead of the "JPY message". I don't recall why but it went the
direction of the JPY message format.
There's a desire to minimize the overhead of this message because it
needs to fit, together with the largest Coap-over-DTLS message that we
can encounter, into the <= 1280 byte limit.
Esko
On Thu, Jul 17, 2025 at 04:05:50PM +0200, Esko Dijk wrote:
In terms of resources, there would only be a single root resource '/'
defined where some attribute (like rt) can indicate which protocol can be
sent to it packed into a JPY message.
A scheme definition can quite easily even say that there are no paths
and queries at all (or leave their semantics to be defined later).
Sorry for the wall of text; couldn't really express it shorter, but also
happy to chat during the hackathon (I'll be at gather.town).
BR
c
--
*IoTconsultancy.nl* | Email/Teams: [email protected] | +31 6
2385 8339
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
