Re: WG adoption for draft-yegin-ondemand-mobility-03

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

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

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

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.

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

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