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