Reviewer: Michael Richardson Review result: Ready I am the assigned IoT-Directorate reviewer for 1draft-ietf-hip-dex I reviewed the -11 version. I did not identify any technical problems or gaps. The introduction tells that I won't understand this without a good understanding of RFC7401 (HIPv2). I went ahead anyway, given that I did know HIPv1 (RFC5201) and IKEv2. While it is clear that I could not implement without knowing 7401, I did find that I could understand most of the goals, the compromises that were made to reduce the complexity for constrained environments. I did go back and read 7401 in the end to fill in a few gaps. Particularly I really needed to understand RFC7343 HITs of the new type, and I did not manage to understand that part. I observe that a new ECDH type of HIT is defined, but I did understand how these values would be exchanged/stored or looked up. I would appreciate a use case or two which has been sufficiently built-out so that I can see the whole picture. If ECDH HITs come from DNS (via AAAA records) for instance, then I'd appreciate an understanding if/how the constrained device is able to leverage DNSSEC. In particular, I'd like to know what kind of applications are ruled out by lack of PFS, and if a kind of PFS can be restored by rotating HITs in DNS. Would this document play well with draft-ietf-ipsecme-implicit-iv? I am unclear if the diet nature of DEX is more about: (1) constrained/challenged networks (2) constrained/slow CPUs (3) systems with very minimal amounts of flash (1) networks have often very small packet sizes, and I would appreciate understanding the total frame sise of each I1/R1/I2/R2, and any impact that fragment assembly might have on the statelessness of the I1/R1 exchange. I know that HIP has be profiled for use in 802.15.9, and I assume that HIP DEX is even better, but the lack of PFS might be a show stopper. (2) slow/sleepy CPUs are not going away, but the amount of available flash on rather cheap, small and sleepy devices is now in the multiple megabytes, so it is unclear if further code simplications are worthwhile. My questions should not stop the document from advancing. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
