Last Call Review of draft-ietf-hip-dex-06
review-ietf-hip-dex-06-genart-lc-dupont-2018-02-26-00

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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

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