Esko Dijk <[email protected]> wrote: > So my point was that the draft could mention this implementation > aspect; preferably a DTLS client on the Pledge should use this; see the > motivation in https://datatracker.ietf.org/doc/html/rfc7925#section-15 > . The extension/option itself is defined in > https://datatracker.ietf.org/doc/html/rfc6066#section-4 . A value 2^9 > or 2^10 is a good choice for 6lowpan networks. If the client signals > this, the Registrar knows the size of the fragments to use for the > constrained network, even if it is located itself on a non-constrained > network without those MTU constraints.
So, I think you are saying that we need to say something about keeping the
DTLS handshake fragmentation size small enough that we can add the join-proxy
overhead.
Would a section 5.4: DTLS Considerations make sense?
5. BRSKI-EST Protocol . . . . . . . . . . . . . . . . . . . . . 6
5.1. Discovery, URIs and Content Formats . . . . . . . . . . . 6
5.2. Extensions to BRSKI . . . . . . . . . . . . . . . . . . . 8
5.3. Extensions to EST-coaps . . . . . . . . . . . . . . . . . 9
5.3.1. Pledge Extensions . . . . . . . . . . . . . . . . . . 9
5.3.2. Registrar Extensions . . . . . . . . . . . . . . . . 10
** 5.4 DTLS Considerations
Peter, we can't use Blockwise on the DTLS handshake, because that part is
outside of the CoAP header. We can only blockwise on the CoAP Payload.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
