Hello Dirk, Thanks for the comments. Please see below.
On Mar 19, 2015, at 7:09 PM, <[email protected]> wrote: > Dear Alper and co-authors, > Thanks for your work! > IMO the draft is clearly written and ready for adoption though some questions > and comments came to my mind: > > In the Intro Mobile IP is referenced to both client and Proxy MIP > In the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944], > – but in the remaining PMIP functional elements (MAG, LMA) are never > mentioned … silly question: so do you propose to apply the solution only to > client MIP based approaches or do you implicitly assume for mobility unaware > hosts/devices that the IP stack on MAG is addressed instead? I suggest to add > a clarification in the beginning … API applies to both CMIP and PMIP hosts. We don't mention MAG or LMA, as those details are not related to the "API". > > P.4: > A sustained IP address may be configured and maintained by using > access network anchoring, corresponding network anchoring, or some > other solution. > I suggest to add a reference here (RFC7429 defining Anchoring Function) or > explain with “allocating to a mobile node an IP > address analogous to CoA at FA in MIP by selecting an anchor router > for relaying the traffic” or similar … Very good idea, will do. > > P.5: > Applications running as servers at a published IP address require a > Fixed IP Address. Long-standing applications (e.g., an SSH session) > may also require this type of address. Those applications could use > a Sustained IP Address, but that can produce sub-optimal results if > the mobile host ends up far from the anchor gateway. > The latter sentence sounds to me as such sub-optimality will not happen in > case of Fixed IP Address – isn’t it even worse when the host already starts > far from the centrally-located Home Network …? > Right, it can be….. But depending on the deployment, a centralized HA may be in a better position to serve long sessions than an AR at the edge (because of scalability, and also funneling traffic "in&out" may not suit the AR well, as its uplink may not be provisioned with enough capacity). Anyways, we should massage the text, .. will propose something. > then the IP stack shall fail the associated socket request. > => then the IP stack shall fail to fulfil/meet/comply with the associated > socket request. > P.6: > - Determination of a default address type when an application does > not make any explicit indication, whether it already supports the > required API or it is just a legacy application. > Do you refer here to the below mentioned Socket API-based interface … > [RFC5014]? > Otherwise I suggest to add some explanatory words on the required API. We are referring to the API we are defining in this I-D. Will clarify in the text. > > P.7: > More than one of these flags may be set on the same socket. In that > case, an IP address compliant with any one of them shall be selected. > TBD: Disallow this case? > Since here we have requirements instead of preferences unavailability of the > required address type would force configuration of compliant address – but > some applications can accept several types (for different planes CP/DP or > with different priority). Question is what would be the additional effort for > forced configuration vs. gain by ‘more optimal’ performance? > My guess: allow, but introduce priority for selection > > Where should the priority come from? The spec shall state it? > In addition few nits detected: > P.2: > despite the mobile host chaging its point of attachment within the IP > => despite the mobile host changing its point of attachment within the IP > P.3: > session continuity and IP address reachability should be be provided > => session continuity and IP address reachability should be provided > P.4: > The mobile host is configures a HoA from a centrally-located Home > => The mobile host configures a HoA from a centrally-located Home > Thanks! Thank you! Alper > Best Regards > Dirk > > > From: dmm [mailto:[email protected]] On Behalf Of Alper Yegin > Sent: Mittwoch, 18. März 2015 10:54 > To: [email protected] > Subject: [DMM] WG adoption for draft-yegin-ondemand-mobility-03 > > Hello DMM WG members, > > As you remember, WT#1 came to an agreement to propose the following I-D as > the baseline for the API piece: > > http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-03.txt > > We'll be proposing its adoption in Dallas. > > FYI, and here's your chance to voice any input in advance. > > Cheers, > > Alper > >
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
