Hi Marco, On Feb 11, 2015, at 2:28 PM, Marco Liebsch wrote:
> Hi Alper, > > I could join only the last 5min of the call and could not participate in the > discussion, nor in the > draft selection, which does not mean I disagree with the agreement. > OK. I've recorded anyone I spotted at the meeting. > One clarifying question. The scope of WI1-4 has been clearly described and > the selected > draft is about extending socket API to enable smart application with picking > a suitable > address type (WI1). In case multiple addresses of type sustained are > configured, is it > up to the lower stack implementation to pick one? Yes. This, I believe, is in line with the RFC 5014. > That means only the available types > are exposed to applications through the socket API, correct? > No. If the requested type IP address is not available on the stack, then the stack will make an attempt to configure an IP address for the requested type. We explained that on the I-D, and also covered on the slides: http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf > I understand retrieval of a new type and associated IP address is covered by > a separate work item. > Can a trigger for such request come from the application via the extended > socket? Yes. > That means in any case an application can request the address type it needs > and > the stack will retrieve it from the network. In such case, the kern may > report to the > application the status of such IP address configuration, e.g. in case of > failure. Yes, covered in the I-D. > A more simplistic approach is to allow applications to use only the types, > which > are available on the mobile and exposed to the application. This is "on-demand" mobility. It'd be inefficient to do any of these: - always configure all types of IP addresses and maintain them, just in case some app requests it, - fail an app because the requested type IP address is not already configured (even though it could be configured dynamically). > Which operation > do you have in mind? > Latter. Please take a look at the I-D, we explain it there. The I-D is a short reading. Alper > Thanks, > marco > > > > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alper Yegin > Sent: Mittwoch, 11. Februar 2015 12:43 > To: dmm@ietf.org > Subject: Re: [DMM] Mobility Exposure and Selection WT call > > Hello, > > Yesterday's call was attended by: Danny, Byoung-Jo Kim, Jouni, Seil, Sergio > Figueiredo, Marco, and Alper. > > Slides can be found at: > yegin.org/NGMobility/DMM_WG_Exposure_Selection_WT-Call3.pptx > > WT agreed to use draft-yegin-dmm-ondemand-mobility as the baseline for item#1 > (the API). > A revision of the draft will also include a new section to cover backward > compatibility (Danny will provide the draft text). > Comments on the draft are welcome. > > The next call will be about items #2/#3 (IP address configuration > enhancements associated with the API). > We intend to schedule that one in about 2 weeks. > > Alper > > > > > > > > On Feb 9, 2015, at 9:59 AM, Alper Yegin wrote: > > > Folks, > > See below for the Webex details. > Remember, the call is on Tue, Feb 10, at 4pm CET. > And don't forget to read the documents in the reading list prior to the call. > > Attendees shall read the following material before the call so that we can > directly jump to the discussions: > > 1. http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf > 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf > 3. https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/ > 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf > 5. http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 > > > > Alper > > > > > > DMM - Mobility Exposure and Selection WT > Tuesday 10 February 2015 > 16:00 | Europe Time (Paris, GMT+01:00) | 1 hr 30 min > > Join WebEx meeting > Meeting number: > 641 085 326 > Meeting password: > dmm1911 > > Join by phone > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) > Access code: 641 085 326 > Toll-free calling restrictions > > Add this meeting to your calendar. > > Can't join the meeting? Contact support. > > IMPORTANT NOTICE: Please note that this WebEx service allows audio and other > information sent during the session to be recorded, which may be discoverable > in a legal matter. By joining this session, you automatically consent to such > recordings. If you do not consent to being recorded, discuss your concerns > with the host or do not join the session. > <WebEx_Meeting.ics> > > > On Jan 27, 2015, at 11:12 AM, Alper Yegin wrote: > > > Poll is closed, and majority selected the following date for the call: > > Feb 10, 4pm CET. > 1,5hr call. > > Please mark your calendars. > > In this call, we'll aim making progress on the I-D for item#1 (an API for > source address selection). > > Attendees shall read the following material before the call so that we can > directly jump to the discussions: > > 1. http://www.ietf.org/proceedings/91/slides/slides-91-dmm-4.pdf > 2. http://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf > 3. https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/ > 4. http://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf > 5. http://tools.ietf.org/html/draft-liu-dmm-mobility-api-02 > > > Alper > > > > > > > > On Jan 23, 2015, at 3:28 PM, Alper Yegin wrote: > > > Folks, > > Please mark your availability on the following doodle for our next DMM WG > Mobility Exposure and Selection WT call: > > http://doodle.com/7xgcr8x6cgxnbzur > > Register your availability no later than the end of Monday (Jan 26). > > Alper > > >
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
