AW: More Comments on draft-ietf-mobike-design-01.txt

hi maureen, 

thanks for the review and sorry for my late response. please find my
comments inline:

> -----Ursprüngliche Nachricht-----
> Von: [email protected] [mailto:[email protected]] 
> Gesendet: Freitag, 14. Januar 2005 22:45
> An: [email protected]
> Betreff: [Mobike] More Comments on draft-ietf-mobike-design-01.txt
> 
> 
> Thanks for your prompt response to my comments.  Again, 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.
> 
> 3.3 Multihomed laptop scenario
> 
> ... in order to sent IP packets...
> 1) Should be ...in order to send IP packets...

ok. 

> 
> Some of these
>    interfaces might connected to a network over the time 
> depending on a
>    number of reasons (e.g., cost, availability of certain link layer
>    technologies, user convenience).  
> 2) A number of different
>    interfaces can be activated over the time depending on
>    policies, e.g., cost, availability of certain link layer
>    technologies and user convenience.  Note that a policy for 
> selecting
> a network interface based on cost, etc. is out of scope for Mobike.
> 
> I'm concerned that some people might think that Mobike does 
> some of this
> policy management and network selection if we don't point out 
> explicitly
> that it does not.  Thus I have included the extra sentence above.
> 
you are certainly right. thanks for clarification. 



> For example, the user can
>    disconnect himself from the fixed Ethernet, and then use the office
>    WLAN, and then later leave the office and start using GPRS 
> during the
>    trip to home.  At home he might again use again WLAN.
> 
> 3) Just fixing nits here.
> For example, the user can
>    disconnect himself from the fixed Ethernet, use the office
>    WLAN, and then later leave the office and start using GPRS 
> during the
>    trip home.  At home he might again use WLAN. 
> 
ok. 

> 4. Framework
> 4) I suggest that you put the last part of the section up front.  It
> does a nice job of setting up the framework.  Then the framework is
> explained.  Here is the last paragraphs in the framework with nits
> fixed.  I took the last bullet that I thought was too long 
> and split it
> up and fixed nits.
> 
> 4) 4. Framework
> Although the interaction with other protocols to determine 
> the preferred
> address and preferred address set is important for MOBIKE
>    to operate correctly the working group is chartered to 
> consider this
>    aspect out of scope.  The working group will develop a MOBIKE
>    protocol with the following functionality:
>    o  Ability to inform a peer about the peer address set
>    o  Ability to inform a peer about the preferred address
>    o  Ability to test connectivity along a path and thereby 
> to detect an
>       outage in order to fall back to another address, 
> thereby making it
> the           new preferred address
>    o  Ability to change the peer address set
>    o  Ability to deal with Network Address Translation devices
> 
> The technical details of these functions are discussed below.

sounds good for me. 

> 
> 5) Now comes the text that was the start of the framework 
> section and I
> have fixed some nits.  Here is the original text (2 
> paragraphs) followed
> by my changes:
> 
> Initially, when a MOBIKE peer starts and executes the initial
> protocol exchange with its MOBIKE peer it needs to setup a peer
> address set based on the available addresses.  It might 
> want to make
> this peer address set available to the other peer.  The Initiator
> does not need to explicitly indicate its preferred address since
>  already using its preferred address.  The outgoing IKEv2 and MOBIKE
>  messages use this preferred address as the source IP address and
>   expects incoming signaling messages to be addressed to 
>  this address.
> 
>    Interaction with other protocols at the MOBIKE host is required to
>    build the peer address set and the preferred address.  In 
> some cases
>    the peer address set is available before the initial 
> protocol run and
>    does not change during the lifetime of the IKE-SA.  The preferred
>    address might change due to policy reasons.  In many other 
> cases, as
>    motivated in Section 3 the peer address set is modified 
> (by adding or
>    deleting addresses) and the preferred address needs to be 
> changed as
>    well.

> 
> ------------- my suggested edits --------------------------------
> 
> When a MOBIKE peer initiates a 
>    protocol exchange with its MOBIKE peer it needs to define a peer
>    address set based on the available addresses.  Optionally, it can
> make
>    a peer address set available to the other peer.  The Initiator
>    does not need to explicitly indicate its preferred address since it
> is
>    already using its preferred address.  The outgoing IKEv2 and MOBIKE
>    messages use this preferred address as the source IP address and
>    expects incoming signaling messages to be sent to this address.
> 
>    Interaction with other protocols at the MOBIKE host is required to
>    build the peer address set and the preferred address.  In 
> some cases
>    the peer address set is available before the initial protocol
> exchange and
>    does not change during the lifetime of the IKE-SA.  The preferred
>    address might change due to policy reasons.  Section 3 describes
> three scenarios in which the peer address set is modified (by 
> adding or
>    deleting addresses).  In these scenarios the preferred 
> address needs
> to be changed as well.

with minor modifications i have incorporated your suggestions. 

> 
> 6) Another nit just above the picture
> 
> Testing other paths might also be useful to notice when a disconnected
> path is operational again.
> 
> How about:
> Optionally, periodic testing of other paths might be useful 
> to determine
> when a disconnected path becomes operational.

sounds good. 

> 
> 7) This paragraph below needs to be moved to the security 
> considerations
> section.  It needs to be worded differently and solutions need to be
> discussed, but I'll get to that when I send comments later on security
> considerations.  Here is the paragraph to move:
> 

fine with me. 

btw, the security consideration section is one of the sections that need
more meat. 


> In addition to the above-listed functionality security is important
>    to the working group.  For example, the ability to prevent flooding
>    attacks based on announcing someone else's address needs 
> to be dealt
>    with.
> 
> 8) I would delete the paragraph below.  Comparing MOBIKE to other
> protocols is a complex topic and this one sentence is neither
> technically informative nor complete.  It will just raise a lot of
> questions and cause a lot of confusion and argument.  I don't think it
> belongs in a framework document.  If you are just trying to 
> say that In
> Mobike both the IKE-SA and IPsec SAs addresses are affected by the
> change in address, then just say that only.  Here is the paragraph to
> delete.
> 
> Note that MOBIKE is somewhat different compared to, for example, SCTP
>    mobility since both the IKE-SA and the IPsec SA is affected by the
>    change of addresses.
> 
i think you are right. we stay on safe ground if we do not provide a
comparision with other proposals. 

however, in discussions with sctp folks i noticed that they this particular
issue causes some confusion.
how should we reflect this aspect in the document? 




> More later.  Thanks for your prompt response to my first set of
> comments.
this time it took a bit longer...
 

ciao
hannes

> 
> -- Maureen
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
>