Design draft, return routability

- "Finally it would be possible not to execute return routability
  checks at all.  In case of indirect change notifications we only
  move to the new preferred address after successful dead-peer
  detection (i.e., a response to a DPD test) on the new address, 
  which is already a return routability check."

  Confusing text; we don't execute return routability checks at
  all, but we do it already. And what exactly are the indirect
  change notifications we're talking about here?

- "but potential attacks are possible if a return
  routability check does not include some kind of a nonce." 

  A return routability check verifies that the peer can receive 
  messages sent to this address. If the message doesn't do this, 
  then IMHO it's not a return routability check at all. So I'd 
  rewrite this section to say something like "A successful IKEv2 
  informational exchange itself does not perform a return 
  routability check because ... and thus a nonce is needed ...".

- The text about different levels of return routability checks is
  very confusing. A return routability check should verify the IKEv2
  peer can receive packets sent to the given address; a check that
  just verifies that "someone can receive packets at the given
  address" is something quite different! I'd suggest removing most
  of this text.

- Section 5.5.1: Again, confusing text: if some other protocol wants
  to know "can remote entity A receive packets sent to X?", MOBIKE
  might be able to provide information that "remote entity B can
  receive packets sent to X" -- but this is not very useful unless we
  can also know that A and B are the same entity (with some reasonable
  definition of "sameness").  I'd suggest shortening this text and 
  stating that this was deemed complex, not absolutely needed, and 
  thus beyond the scope.

Best regards,
Pasi