Hi Michael, > The Proxy-Scheme option is set to "coap". > Do I even need this?
I don't think we can use the Proxy-Scheme (or the Proxy-Uri) Option here. The reason is that it is meant for a CoAP forward-proxy, that is a proxy that receives a CoAP request and creates another fresh/new CoAP request again, based on the received request payload and the included Proxy-Uri option or alternatively the included Proxy-Scheme option plus other Uri-* options. But, in our case here the proxy does not even create a new CoAP request. Rather, it takes the payload bytes only and sends these over UDP to the Registrar's DTLS port. (If the Registrar is a local process, the UDP I mention here is just local communication.) So a CoAP forward proxy seems really not appropriate and it should be a CoAP reverse proxy instead. See 5.7.3. of RFC 7252. Using a reverse proxy means you can just remove the Proxy-Scheme option. Esko -----Original Message----- From: core <core-boun...@ietf.org> On Behalf Of Michael Richardson Sent: Monday, October 24, 2022 03:58 To: anima@ietf.org; c...@ietf.org Subject: [core] ANIMA constrained-join proxy revision to use CoAP Hi, the -13 version of draft-ietf-anima-constrained-join-proxy is posted now. Here is the diff: https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-constrained-join-proxy-12&url2=draft-ietf-anima-constrained-join-proxy-13&difftype=--html The -13 is created from a series of pull requests which are not merged, but he parts where I change the "JPY" to a CoAP header are at: https://github.com/anima-wg/constrained-join-proxy/pull/42 Some questions to the CoAP experts. The Proxy-Scheme option is set to "coap". Do I even need this? It costs 6 bytes, I think, assuming that "coap" is a four byte string, and not code for a enumerated type. If not, I'd have no options, and the additional overhead of CoAP vs custom CBOR would be two bytes. Christian said two weeks ago that we didn't need Uri-Host or Uri-Path options. I think that we will be running on a custom port. (But, RFC9031 thought it needed them. Was that wrong?) The Registrar's DTLS stack might need to send more than one reply in response to a single DTLS "POST". This is buried in the DTLS state machine, and might be related to DTLS handshake fragmenting headers, or to rekeys, or... Is that going to be a problem, and is POST still the right method? Appendix A has some details on the CoAP header, which I'd like a review. Did I even get it halfway right? -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
