Carsten Bormann <[email protected]> wrote: > IP address in the authority than the request address). For brski.rjp, > this appears to be about discovering an entry point for a protocol that > I don’t seem to fully understand the description for.
> I didn’t try to obtain a deep understanding of the protocol before
> writing this, but I would prefer if the language used for the
> description were understandable for other registrants in this registry,
> i.e., discussing resources, not ports (port numbers?).
I think that it is a fair complaint that the way that we use brski.rjp is a
bit weird.
We aren't discoverying a thing we are going to speak *CoAP* or *CoAPS* to,
but rather something to which we are going to speak this stateless protocol
to. (Having a good name for it might be a good idea)
Section 5.3 describes the protocol, but basically the Join Proxy encapsulate
DTLS
messages from the Pledge in some CBOR:
JPY_message =
[
ip : bstr,
port : int,
family : int,
index : int
content : bstr
]
This is solving the identical problem as RFC9031
https://www.rfc-editor.org/rfc/rfc9031#name-statelessness-of-the-jp
but in the case of RFC9031, the security layer (OSCORE) is inside of CoAP,
so one can use the CoAP token to store the state.
In our case, the CoAP is *inside* the security layer (DTLS), so we can't do
that.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
