Subject: Re: [Anima] [anima-wg/constrained-join-proxy] new protocol (#4)

From: Michael Richardson <[email-masked]>
Date: Tue, 10 Aug 2021 14:01:56 -0400

https://github.com/anima-wg/constrained-join-proxy/issues/4

peter van der stok <[email-masked]> wrote:
    > So it looks like this message type is a newly defined protocol format
    > over UDP, not a CoAP message as I initially expected. It should be
    > stated explicitly that this is a new protocol ; also e.g. this draft
    > could register a new protocol into IANA "Service Name and Transport
    > Protocol Port Number Registry" with a name and without a default port
    > number (there are many registered protocols there that do this). The
    > service name can make the service and its port discoverable through any
    > IETF defined means like DNS-SD, mDNS.  CoAP discovery doesn't seem
    > useful here because the new-protocol isn't CoAP.

    > For WG discussion: why isn't CoAP re-used to transport this CBOR
    > payload to the Registrar without having to define a new protocol?  (One
    > answer could be that using CoAP will add much more bytes as overhead,
    > e.g. to encode a URI path. And the URI path of the Registrar's
    > "join-proxy resource" would have to be discovered also, not just the
    > port. ) Or, do I have it wrong and was CoAP intended after all?

Did we investigate putting the pledge addr+port in as a DTLS extension,
into some part of the DTLS frame header which was not protected?

So, we have DTLS(CoAP(BRSKI)), and the stateless version of this is WRAP(X,DTLS(CoAP(BRSKI))).
I agree that maybe WRAP could have been CoAP.
WRAP is CBOR encoded.
I agree that things could have been CoAP rather than CBOR, but I don't think
it benefits.

In the absence of GRASP/ACP, I don't know how the Registrar is discovered by
the Join Proxy in a multi-hop network.  This needs to go into the
Applicability statement, I think.

We included that in RFC9031, see section 8.4.2, "JRC address", but your
application does not run 6tisch.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide