To a smaller audience, I got this bounce message from AMS - perhaps Jiang's email address should be updated?
<[email protected]> (expanded from <expand-draft-ietf-anima-constrained-join-proxy....@virtual.ietf.org>): host mx5.huawei.com[124.71.93.234] said: 551 5.1.1 < [email protected]>: Recipient address rejected: Failed recipient validation check.: host 127.0.0.1[127.0.0.1] said: 554 5.7.1 recipient verify from ldap failed (in reply to RCPT TO command) (in reply to RCPT TO command) Best, Spencer On Tue, May 17, 2022 at 10:31 AM Spencer Dawkins at IETF < [email protected]> wrote: > 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
