Design draft, misc. comments

<[email protected]> Fri, 23 Dec 2005 14:25:33 +0200
Newsgroups gmane.ietf.mobike
Message-ID <[email protected]>
- Section 1, "for example when using SecurID cards" -> "for example, 
  when using human-operated token cards" 

- Section 3.2: "Each peer selects one of its IP addresses as the
  preferred address which is used for subsequent communication."
  There's some conflict here. It's the initiator who selects
  which addresses are used for subsequent communication (except
  in relatively rare situations, ie. responder address changes).

- Section 4: "The MOBIKE protocol should be able to perform...":
  this text may need to be rewritten once we either come up 
  with a reasonable definition for "preferred address", or 
  get rid of the term completely.

- Section 4: The talk about "MOBIKE daemon" creates the impression
  that there typically would be both an "IKEv2 daemon" and
  "MOBIKE daemon", running as separate processes. While this is  
  not impossible, I would find it a very strange way to implement
  a relatively minor extension to IKEv2. (After all, if we implement 
  some other IKEv2 extension like draft-nir-ikev2-auth-lt,
  we don't call it the "Repeated Authentication Daemon" or something.)

- Section 5.1.4, 1st paragraph: closing parenthesis missing.

- Section 5.2.1, a couple of informative references might be 
  in order (UNSAF, MIDCOM, NSIS NATFW)

- Section 6.3: "The selected format needs to be flexible enough to
  include additional information in future versions of the protocol
  (e.g. to enable load balancing).  This may be realized with an
  reserved field, which can later be used to store additional
  information.  As there may arise other information which may have to
  be tied to an address in the future, a reserved field seems like a
  prudent design in any case."

  IMHO it would be quite difficult to design the protocol in a way 
  that would totally prevent future extensions from sending
  additional information. But currently we don't have any "reserved" 
  fields there (simply because they're not needed -- the normal 
  IKEv2 extension mechanisms will allow us to add more stuff later).

- References: should draft-ietf-mobike-protocol be normative?

Best regards,
Pasi