Peter, On Wed, May 18, 2022 at 2:06 AM Peter van der Stok <[email protected]> wrote:
> HI Esko, Spencer, > > I will add a sentence in at the end of section 5.3. > > It is recommended to use the block option [RFC7959] and make sure that the > block size allows the addition of the JPY header without violating MTU > sizes. > > thanks for the reminder, > Oh, thank you! Best, Spencer > Peter > > Spencer Dawkins at IETF schreef op 2022-05-17 17:31: > > Hi, Esko, > > On Tue, May 17, 2022 at 4:37 AM Esko Dijk <[email protected]> > wrote: > > Hi Peter, Spencer, > > > > For some more detail on Peter's 'No' answer: > > > I was expecting that answer. 😉 > > Thanks for the additional details! > > > > > Since the Pledge communicates (link-local) with the Join Proxy using > DTLS-over-UDP on a network that is likely 6LoWPAN (1280 byte MTU limit) > mesh, it could happen in theory that the Pledge sends out a DTLS handshake > UDP packet with a length that brings the carrying IPv6 packet length at > 1280. > > In this case the DTLS record size is also something close to 1280. (We > never did the exact calculations.) > > > > This may pose a problem for the stateless Join Proxy that appends a few > bytes to the DTLS record (to relay it further to the Registrar) so the > total length of the IPv6 packet sent to Registrar could exceed 1280. (And > the Join Proxy is still on the mesh network with 1280 byte MTU). > > But in any case in the constrained-voucher draft we have written about > this: > > > https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher#section-6.7 > > > > So even though we don't know for sure it is a problem, as we haven't done > the calculations in detail, it's preemptively solved by recommending the > Pledge to break up the handshake into smaller parts. Then, the Join Proxy > doesn't need to do anything special anymore and it always works. > > That also helps with performance on the mesh network due to reduction of > 6LoWPAN fragmentation. > > > @Spencer do you think the Constrained Join Proxy draft should mention the > potential issue also? E.g. a reference to above section 6.7 is easy to > make. > > > The reference you described is exactly what I was thinking of (I was more > familiar with COAP before blockwise transfer was specified in > https://datatracker.ietf.org/doc/rfc7959/, but I knew it had been > standardized). > > If you can preemptively avoid a potential problem by adding a reference to > the document and section you provided, without slowing this document down, > that would be great. > > And thanks again for a quick response to a really late directorate review. > > (I know we're not talking about > https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher, > but I didn't see RFC 7959 listed as a reference there, and it seems like > that should be normative. But do the right thing, of course! > > Best, > > Spencer > > > > > Regards > > Esko > > > > *From:* Anima <[email protected]> *On Behalf Of * Peter van der Stok > *Sent:* Tuesday, May 17, 2022 10:22 > *To:* Spencer Dawkins <[email protected]> > *Cc:* [email protected]; [email protected]; > [email protected]; [email protected] > *Subject:* Re: [Anima] Tsvart last call review of > draft-ietf-anima-constrained-join-proxy-10 > > > > Hi Spencer, > > thanks for your kind words. > > Indeed the answer is no. (at least for the coming 20 years). > > Greetings and thanks, > > Peter > > Spencer Dawkins via Datatracker schreef op 2022-05-17 01:09: > > Reviewer: Spencer Dawkins > Review result: Ready > > This document has been reviewed as part of the transport area review team's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the > document's > authors and WG to allow them to address any issues raised and also to the > IETF > discussion list for information. > > When done at the time of IETF Last Call, the authors should consider this > review as part of the last-call comments they receive. Please always CC > [email protected] if you reply to or forward this review. > > This is a well-written specification. My only question - and I expect the > answer will be "no" - is whether there is any concern that sizes of the > resources that are being passed around might exceed the MTU between the > pledge > and the registrar, and whether there should be a mention of this > possibility in > the specification. > > Best, > > Spencer > >
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
