Comments on draft-ietf-mobike-design-01.txt

Most of my comments are nits, although some are more substantial.  Take
what you think is helpful.  I didn't have time to review the whole
document in one sitting so more comments will come later.

 Available address:

      This definition is reused from
      [I-D.arkko-multi6dt-failure-detection] and refers to addresses
      which are available by an peer.  A few conditions must hold before
      an address in such a state.

1) I don't understand this.  I read the i-d referenced above and I did
understand that.  I think you need to replace this with more of that i-d
text.  I'm not sure how much of it to cut and paste.  What is here is
just too brief IMHO.

Peer Address Set:

      A subset of locally operational addresses that will sent
      communicated to another peer.  A policy available at the peer
      indicates which addresses to include in the peer address set.
      Such a policy might be impacted by manual configuration or by
      interaction with other protocols which indicate newly available
      addresses.  Note that the addresses in the peer address set might
      change over time.

2) Confusing.  The problem is that the word peer is ambiguous.  I fixed
it by actually labeling the two peers as peer A and peer B.  Here is a
suggestion:
 
We denote the two peers in this Mobike session by peer A and peer B.  A
peer address set is a subset of locally operational addresses of peer A
that are sent to peer B.  A policy available at peer A indicates which
addresses to include in the peer address set.  Such a policy might be
impacted by manual configuration or by interaction with other protocols
which indicate new (note: newly is not a word) available addresses.  
      

   3.1  Mobility Scenario

   Figure 1 shows a break-before-make mobility scenario where a mobile
   node attaches to, for example a wireless LAN, to obtain connectivity
   to some security gateway.  This security gateway might connect the
   mobile node to a corporate network, to a UTMS network or to some
   other network.

3) You mean UMTS, not UTMS, but wouldn't it be better to say 3G network?

Since only MOBIKE is relevant
   for this discussion the end-to-end communication between the MN and
   some destination server is not shown in Figure 1.

4) ... Since only MOBIKE communication from the MN to the gateway is
relevant for this discussion the end-to-end communication between the MN
and
some destination is not shown in Figure 1. (Two changes: a) add from the
MN to the gateway and b) delete server in destination server, doesn't
have to be a server)

As a result, some form
   of protocol exchange, denoted as 'MOBIKE Address Update',
5) As a result, a
   protocol exchange, denoted by 'MOBIKE Address Update',
(OK, very picky)

The protocol messages will
   travel along a new path whereby the old path and the new path will
   meet at the cross-over router.
6) There is really no technical significance of "meeting" at some router
labeled CR and calling it a cross over router (and we don't really know
what a cross over router is).  I would just label it as R instead of CR
and say:
The protocol messages will travel along a new path.

Potential future path through the network
                     (if Peer A and Peer B chance their preferred
                      address)

                     Figure 2: Multihoming Scenario
7) ... if Peer A and Peer B change (chance should be change)

Note, that the load-balancing inside one IKE SA is not provided by
   the MOBIKE protocol.  Each client uses only one of the available IP
   addresses at a given point in time.
8) Note that Mobike does not support load balancing between multiple IP
addresses.  That is, each peer uses only one of the available IP
addresses at a given point in time. (this is clearer to me, also you
switch from using the word peer to using the word client)

Let me know if you have questions.

-- Maureen