Hi Dapeng, >> >>> [as an individual contributor] >>> >>> I support the idea of “Exposing mobility state to mobile nodes and network >>> nodes” as described in our charter. >>> >>> For this particular draft, after some offline discussion with the authors, >>> I still have the following comments/suggestions: >>> >>> 1. Definition and distinction of "Fixed IP” and “Sustained IP” should be >>> clear, more clarification text would be helpful. >> >> After rounds of online and offline discussions, I'm still not clear where >> the issue is. >> Could you please explain what exactly is this issue with the current >> definitions? > Some information is not obvious from the draft text. More explanatory text > will at least help the application developer to know whether this is useful > for them.
> For example, as you said, HoA can either be “fixed IP” or “sustained IP”, > then when HoA become "fixed IP" and when it becomes "sustained IP"? When a HoA is called "fixed" vs "sustained" is already provided by the respective definitions in the I-D: - Fixed IP Address This is what standard Mobile IP provides with a Home Address (HoA). The mobile host is configures a HoA from a centrally-located Home Network. Both IP session continuity and IP address reachability are provided to the mobile host with the help of a router in the Home Network (Home Agent, HA). This router acts as an anchor for the IP address of the mobile host. - Sustained IP Address This type of IP address provides IP session continuity but not IP address reachability. It is achieved by ensuring that the IP address used at the beginning of the session remains usable despite the movement of the mobile host. The IP address may change after the termination of the IP session(s), therefore it does not exhibit persistence. A sustained IP address may be configured and maintained by using access network anchoring, corresponding network anchoring, or some other solution. If these definitions are not clear, please recommend improvement. If you are asking about "how the IP stack on the mobile node" configures such IP addresses, as you know this is not in the scope of this API document, but that'll be addressed by the protocol solutions in DMM. If you are asking about something else, please clarify that too. I tried to answer your question based on my understanding of what it might be. > Another example/question: Is there any “fixed IP” that does not belong to the > type of HoA? > What do you mean? > > In section 3.1: > “ The mobile host is configures a HoA from a centrally-located Home..”, do > you mean “The mobile host is configured a HoA from a centrally-located > Home..”? > Yes, it's a typo. (is configured with, or configures). > In section 3.1: > “Applications running as servers at a published IP address require a Fixed IP > Address.”.. > Is there any real-life example for this requirement? This is by definition, right? If you are running a server, you need need to publish its IP address (in DNS, for example). And you want that address to be "fixed" (i.e., not changing). And that's what we call "Fixed IP address" in this I-D. Please see the below links for real-life examples of how operators are already marketing such things: https://www.wireless.att.com/businesscenter/popups/general/custom-ip-addressing.jsp http://www.verizonwireless.com/businessportals/support/faqs/DataServices/faq_static_ip.html > Most server only need static public IP address instead of “fixed IP address” > (providing mobility) ? > Please see the examples on the links above. > In section 3.1: > “Enterprise applications that connect to an enterprise network via virtual > LAN require a Fixed IP Address.” can you explain the reason? > This is about Enterprise APN. Or, for example, what AT&T refers to as "customer-provided IP addresses". See the above link, and the below text: Customer-provided IP addresses: If you decide to provide your own IP address block for your mobile data configuration, you will essentially extend your company's wide area network to include the AT&T cellular network. This allows for simpler firewall configuration, as well as mobile device identification. > >> So that we can understand the residual unclarity in your mind, and we let >> other people also weigh in on the matter. >> >>> 2. Since we are trying to define API, opinion from application developers >>> or OS vendors would be helpful. We can invite some of those experts to join >>> the discussion. >> >> Sure. >> >>> 3. Agree with Jouni’s opinion regarding the IPR, the group need to evaluate >>> it. >> >> I really don't understand what exact "IPR evaluation" process you are >> referring to. >> I'm not familiar with such a thing in IETF. > [quote from Jouni’s mail] > “we need to evaluate what parts are covered by the declared IPR and whether > the WG agrees to keep those in the solution”.. > Yeah, I know. I also told Jouni that I don't know what exact process he's referring to. Anyways, if any of the chairs are referring to some IETF process, I'd like to know what that is. I'm not familiar with it. If there's such a thing, we need to make sure it's an official IETF process, and it'll be applied to all docs across the DMM, and already being applied across the IETF. Regards, Alper > > -- > Dapeng > >> >> Alper >> >> >>> >>> -- >>> Dapeng Liu >>> >>> 在 2015年4月4日 星期六，上午8:03，Jouni Korhonen 写道： >>> >>>> Folks, >>>> >>>> This email starts a two week adoption call for the I-D >>>> draft-yegin-dmm-ondemand-mobility-03 >>>> to confirm its adoption as a DMM WG document and as a basis for the >>>> technical solution. The call ends April 17th EOB PDT. >>>> >>>> Express your support or opposition to the mailing list. During the >>>> IETF92 meeting we got 10 voices for the adoption and 3 against. we >>>> expect at least the same amount of expressed opinions on the list. >>>> >>>> Notice that version -01 of this I-D had an IPR declared to it. See >>>> https://datatracker.ietf.org/ipr/2309/ >>>> >>>> - Jouni & Dapeng >>> >>> _______________________________________________ >>> dmm mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/dmm >> >
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
