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

hi maureen, 

thanks for the review. please find some comments inline: 
 
> 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.
> 

i see. i tried to avoid to perform a copy-and-paste but sometimes it is
necessary for editorial reasons. 


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

i wanted to include an example to make it clearer. however, your suggestions
also seems to be fine for me. thanks./ 

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

true. 

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

sounds good as well./ 

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


also fine with me./ 
 

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

you are certainly right. i have reused one of my nsis figure where the cr is
a special node. i will fix it./ 

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

ok. 

> 
> Let me know if you have questions.
> 
thanks for your suggestions. 
i will incorporate them into the next version of the draft. 

ciao
hannes

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