I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-hip-dex-06.txt Reviewer: Francis Dupont Review Date: 20180224 IETF LC End Date: 20180226 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - ToC page 3: you use the US spelling of Acknowledgments in the ToC and the English one (acknowledgements) in the technical body. Even when it is not very consistent I believe this follows RFC 7401 choice so I am fine with this. - 2.1 page 6: please add/move to RFC 8174 which updates RFC 2119 fixing the keyword case silly issue. - 2.2 page 6: perhaps "sort" should be added here? - 2.3 page 7 (twice): (c.f. Section 3) -> (see Section 3) or simply (Section 3) - 4.1.3.2 page 16 (at end of line): e.g. -> e.g., - 5.3.3 page 25: I don't believe the critical property for random value is to be "uniformly distributed" (for instance I could have put "unpredictable"). I leave this to the security directorate who should propose a better wording if they don't like the current one... - 5.3.4 page 26: same comment. - 6.1 page 27: this section does not really explain what is the puzzle (it only stands the equation to verify) but I remember the explaination was before with a reference to 6.1 so I have no concern. - 6.2.1 sender 3 page 27: hidden dependency on the sort definition for HOST_g/HOST_l so gl/lg keys. Yes it is in 6.3 but 6.3 is after. - 6.3 pages and 30: sort is used page 29 and defined after page 30, this is why IMHO the question to move the definition to 2.2 notation is a good one... - 6.3 page 30: / is not associative so ceil(L/RHASH_len/8) is bad. The text shows it must be ceil(L/(RHASH_len/8)) (vs ceil((L/RHASH_len)/8)) - 6.5 1. page 31: Otherwise, it must drop the packet. -> MUST - 6.6 1. page 33: the system should process the R1 packet -> or SHOULD or (I prefer) the system processes the R1 packet - 6.6 8. page 34: The R1 packet may have the A-bit set -> can (not better from a language point of view but clearer and BTW used for instance in 6.10...) - 6.6 13. page 34: it may either resend an I1 packet -> MAY? (cf 11.) - 6.7 5. page 36: Otherwise, the system should process the received I2 -> or SHOULD or (better) processes (and drop -> drops) - 6.7 15. page 37: If the A-bit is set, the Initiator's HIT is anonymous and should not be stored permanently. -> IMHO SHOULD NOT or directly MUST NOT - 6.9 page 39: If a NOTIFY packet is received in state I2-SENT, this packet may be an I2 reception acknowledgement of the optional -> replace "may be" by "can be" or (better) "is" - 7 page 40: Please put "If a Responder is not under high load, #K SHOULD be 0." in its own paragraph (i.e. add a break before "If"). It makes clearer this sentence is a requirement when the text before is the rationale. - 8 page 40: " either supports HIP DEX or HIPv2 must be able to detect" -> MUST or "has to" - 8 pages 40 and 41: I think that the first and last paragraphs of section 8 say the same thing. Should you keep both? - 9 page 41: I'd like to see a formal proof of the DEX protocol. I believe you share this wish as you cite SIGMA. - 9 page 42: I'd like to go further and recommend (lower case) the use of a RNG (vs PRNG) when available (hopefully no longer an exception). - 9 page 42: Hence, HIP DEX HITs should not be use -> SHOULD or ought to? Thanks Francis.Dupont@fdupont.fr