[Mobike] More Comments on draft-ietf-mobike-design-02.txt (section 5)

[Maureen.Stillman at nokia.com]

I just saw Pasi's message where he suggests some terminology changes.
Some of my nits below have to do with inconsistent terminology.  So you
need to settle on the new terms and just be consistent with then as Pasi
says.  Some of my nits will be relevant and others won't as a result.

Nit: 
1. Introduction

No effort is to be
   made to make protocols for IKEv1 [RFC2409] or old RFC2401
   architecture [RFC2401].

How about:

Mobike does not support IKEv1 [RFC2409] or old RFC2401
   architecture [RFC2401].

5.1 Indicating support for MOBIKE

I would introduce this section with the following (which I assume is
correct):

In order for MOBIKE to function correctly, both peers must support it.
We propose extensions to IKEv2 described below for MOBIKE support.  If
only one peer supports MOBIKE, then the peers will just run IKEv2.
Specifically, a node needs to be able to....


Nits to change below highlighted with *xxx*.  What is not a nit is the
use of the word movement.  Just because a node moves, doesn't mean that
it changes IP address.  We need another word.:

Note that the node could also attempt MOBIKE optimistically with the
   critical bit set to one when a movement has occurred.  The drawback
   of this approach is, however, that the an unnecessary MOBIKE message
   round is introduced on the first movement.

How about:

Note that the node could also attempt MOBIKE optimistically with the
   critical bit set (*text deleted*) when an address change has
occurred.  The drawback
   of this approach is, however, that the an unnecessary MOBIKE message
   *exchange* is introduced (* text deleted* ).

5.2 Changing a Preferred Address and Multihoming Support

   From MOBIKE's point of view multihoming support is integrated by
   supporting a peer address set rather than a single address and
   protocol mechanisms to change to use a new preferred IP address.
   From a protocol point of view each peer needs to learn the preferred
   address and the peer address set somehow, implicitly or explicitly.

Another nit in the last sentence: remove somehow:

Changing a Preferred Address and Multihoming Support

   From MOBIKE's point of view multihoming support is integrated by
   supporting a peer address set rather than a single address and
   protocol mechanisms to change to use a new preferred IP address.
   From a protocol point of view each peer needs to learn the preferred
   address and the peer address set *either* implicitly or explicitly.

Section 5.2.1

There is a shift in notation from calling something the preferred
address to calling it the primary address.  I will point out all the
places where this is the case, but you can just do a global edit.  It is
confusing and I'm not sure why you switched.  Did you mean for something
called a primary address to be different from the preferred address?
I'll assume they are the same in the nits below and change all the
primary addresses to preferred address. 

Original text:

MOBIKE does not include
   load balancing, i.e., only one IP address is set to a preferred
   address at a time and changing the preferred address typically
   requires some MOBIKE signaling.

Another option is to only communicate one address towards the other
   peer and both peers only use that address when communicating.  If
   this preferred address cannot be used anymore then an address update
   is sent to the other peer changing the primary address.

Change to:
MOBIKE does not *support*
   load balancing, i.e., only one IP address is set to the preferred
   address at a time and changing the preferred address typically
   requires some MOBIKE signaling.

Another option is to only communicate one address *to* the other
   peer and both peers only use that address when communicating.  If
   this preferred address cannot be used anymore then an address update
   is sent to the other peer changing the *preferred* address.

Original text:

the recover
   procedure.  The peer, whose IP address changed, must start recovery
   process and send the new IP address to the other peer.

Change to:
the *recovery*
   procedure.  The peer, whose IP address changed, must start *the*
recovery
   process and send the new IP address to the other peer.

Original text:

I thought that the last sentence here is confusing and should be
reworked.  I have suggestions below.  I also thought the one sentence
should go with the next paragraph.

The problems with IP address list are mostly in its complexity.


   Notification and recovery processes are more complex, as both end can
   recover from the IP address changes.  There is also possibilities
   that both ends tries to recover at the same time and this must be
   taken care in the protocol.

Change to:

The problems with IP address list are mostly in its complexity.
Notification and recovery processes are more complex. *Both ends* can
   recover from the IP address changes.  *However, both peers should not
attempt to recover at the same time or nearly the same time as it could
cause them to lose connectivity.  The Mobike protocol is required to
prevent this.*

Original Text: 

Please note that the discussed aspect is partially different from the
   question how many addresses to sent in a single MOBIKE message. 


Change to:

*The previous discussion is independent of the question of how many
addresses to send in a single MOBIKE message.*

More later.


-- Maureen