AW: More Comments on draft-ietf-mobike-design-02.txt (se ction 5)

hi maureen, 

thanks for the suggestions. i have incorporated them into the latest draft
version. 

ciao
hannes


> -----Ursprüngliche Nachricht-----
> Von: [email protected] [mailto:[email protected]] 
> Gesendet: Freitag, 28. Januar 2005 17:35
> An: [email protected]
> Betreff: [Mobike] More Comments on 
> draft-ietf-mobike-design-02.txt (section 5)
> 
> 
> 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
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
>