D116 Design draft, misc. comments

[issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html
 working copy of document:
 http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt]

[email protected] writes:
> - Section 1, "for example when using SecurID cards" -> "for example, 
>   when using human-operated token cards" 

Done.

> - 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).

In mobike-protocol it is initiator. Here we also describe other
options. No conflict, we simply do not fully support that scenario in
current protocol (i.e. responder preference is ignored). 

> - 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.

Again disagree. This is not describing only the current protocol, but
also design choises behind the current protocol. That means we need to
describe things in more general ways than what current protocol
document requires.

> - 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.)

True. Perhaps MOBIKE module would be better term. Changed to MOBIKE
module. 

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

Fixed. 

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

Sure, give RFC / Internet-draft names, I will add them. 

> - 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).

Actually we do. We have notification data, that is either empty of
fixed length, which means we can add stuff to it. 

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

I do not think so. It is not mandatory to read current protocol to
understand why we ended up there, and what other options were
considered and rejected. 
-- 
[email protected]