Hi Toerless, I don't think we have to explain why particular CoAP Options are not included in the request - there are many CoAP Options we don't use. And in principle we also don't need to motivate our design choices extensively in the draft. We can just define the positive example of what we do use, as written in the current text of the draft. So what we currently use is a "regular" CoAP request to the reverse-proxy (i.e. the Registrar-Proxy). I say "regular" in quotes because it is a regular request but to a resource that is a special case in CoAP Uri-Path option encoding (the root resource /).
The Registrar-Proxy indeed selects the "next" destination which is the Registrar. (This often called 'next leg' or '2nd leg' in the CoRE WG.) Esko -----Original Message----- From: Toerless Eckert <[email protected]> Sent: Thursday, October 27, 2022 19:58 To: Michael Richardson <[email protected]> Cc: Esko Dijk <[email protected]>; [email protected]; [email protected] Subject: Re: [Anima] [core] ANIMA constrained-join proxy revision to use CoAP Can we make sure that the text does explain why the field is not inclueded, and explain that the packet MUST be rejected if it was included ? Seems like: Field is not included and would cause rejection of the packet if it was present, because it is inappropriate for the initiator to choose the next hop after the proxy not only because the Pledge would not know it, but because it is also not appropriate for security purposes for the Pledge to choose it. Do i correctly understand this ? Cheers Toerless On Wed, Oct 26, 2022 at 07:38:12PM +0200, Michael Richardson wrote: > > Esko Dijk <[email protected]> wrote: > > Yes, the assumption is still that a CoAP request made to the root > > resource (/) is valid and can be encoded by including 0 Uri-Path > > Options. > > Well, the word from the Oct.12 meeting was that we didn't need it. > > > Since the proposed CoAP message does not contain any Uri-Path > > option, it should be directed to the root resource. There could also be > > cases where the Registrar would configure another resource (e.g. /j or > > /join or whatever) and in such case a Uri-Path option would be needed. > > Okay, but I'd like to not do that :-) > > > I'm not 100% sure if for a resource at the root (/), one Uri-Path > > Option with 0 length is needed or if 0 Uri-Path Options can be used. > > Or if both methods would be valid. > > I'm hoping that Carsten or Christian will express an opinion. > > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima -- --- [email protected] _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
