Re: [DMM] draft charter text updates in github..
Hi Jouni, Thanks for updating the charter, which is now v12! I'm fine with this version (at least my comments were resolved). Regards, -- Hidetoshi Yokota KDDI RD Laboratories, Inc. e-mail:yok...@kddilabs.jp (2014/06/14 20:20), Jouni Korhonen wrote: Folks, Another set of tweaks in github (v12): o reminders of Charlie's comments o Hidetoshi's comments o Georgios' comments Also milestones got postponed. There is still a bit of my own editing in the text so not everything got moved over letter by letter. - Jouni 6/13/2014 2:41 PM, Jouni Korhonen kirjoitti: Folks, New update (v9) available. I added most of the editorials from Charlie (thanks) and the red texts from Alper. The lot debated anchoring term (and milestone) is still there. The milestone does not mention anymore about preserving the mobility sessions and stuff. That would be up to the solution to define. - Jouni 6/6/2014 2:47 PM, Jouni Korhonen kirjoitti: Folks, Minor changes.. https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt IMHO..the charter as it is today, would allow pretty much any solution from legacy anchoring to herd of pigeons carrying IP.. ;-) I have put in editorial changes of my own and clear text proposals received from others. - Jouni ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] draft charter text updates in github..
Hi Jouni and all, Thanks for updating the charter, which is much tidy now. Sorry for my late response, but I have a couple of comments below: o With regard to enhanced mobility anchoring (mid-session anchor switching), there were a lot of discussions in the past as you know and eventually that idea was not fully accepted by the community. It's ok to handle it in DMM WG, but we also need convincing use cases and effectiveness. Re-anchoring LMAs/HAs with preserving IP address may not be so elegant and efficient. o I was not very sure why virtualization needs to be mentioned. There might have been some discussion about it, but do we really need it in the charter? The DMM solutions should not distinguish between physical or virtualised networking functions. However, whenever applicable, clarifications for specific networking function deployment models are in scope and encouraged. o The fourth paragraph mentions UP/CP separation, but the last sentence is about IP address change, which is described in the fifth paragraph. That sentence may be fit there. In contrast to existing IETF standard IP mobility protocols, mobility management signalling paths and end user traffic forwarding paths may differ; those mobility related functions may be located in separate network nodes. Solutions may also specify the selection between the care-of addresses and home address(es)/prefix(es) for different application use cases. Regards, -- Hidetoshi Yokota KDDI RD Laboratories, Inc. e-mail:yok...@kddilabs.jp (2014/06/13 20:41), Jouni Korhonen wrote: Folks, New update (v9) available. I added most of the editorials from Charlie (thanks) and the red texts from Alper. The lot debated anchoring term (and milestone) is still there. The milestone does not mention anymore about preserving the mobility sessions and stuff. That would be up to the solution to define. - Jouni 6/6/2014 2:47 PM, Jouni Korhonen kirjoitti: Folks, Minor changes.. https://github.com/jounikor/dmm-re-charter/blob/master/recharter_draft.txt IMHO..the charter as it is today, would allow pretty much any solution from legacy anchoring to herd of pigeons carrying IP.. ;-) I have put in editorial changes of my own and clear text proposals received from others. - Jouni ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] draft charter text updates in github..
Hi Jouni and all, With regard to the milestone, it looks getting more aggressive. If we think of the current pace of creating the problem statement and requirements documents, submitting the I-Ds to IESG by next March doesn't seem to be very realistic... Just a few other comments below: (2014/06/14 8:53), Jouni wrote: On Jun 14, 2014, at 2:37 AM, Charles E. Perkins wrote: Hello Jouni, Thanks for incorporating some of my suggested revisions. Follow-up below... On 6/13/2014 3:41 AM, Jouni Korhonen wrote: /* What about RFC 5568 (FMIP)? */ There is the ..such as.. so I think there is no really need to lost all possible MIP6 variations. FMIP is particularly important when developing solutions that are aimed at localizing handover signaling, and I think it deserves particular mention, at the cost of adding ten or fifteen more characters to the charter text. Okay. Then Why not RFC5949 for PMIP? ;-) /* What does eventually mean?? */ erm.. removed.. Well, it's still there. So, maybe, the other dozen or so D'oh. revisions that didn't make it into charter revision #9 were intended to be included also...? I'll await further follow-up until I can see whether my other comments were rejected or simply overlooked. Please take a look. Hmm.. seems i did not include the comments in the milestones part.. my mistake. In particular, misuse of the definite article the can be interpreted to restrict development to a single solution. And, as has been discussed, I think that the dmm WG is very likely to develop a suite of smoothly interacting solutions. Moreover, it should be observed that on a single mobile node, different applications might require different treatment for their end-point IP address. This might also encourage further use of multiple IPv6 addresses by a single mobile node, which in my opinion is a positive feature. Or it could elevate the importance of proper treatment for flow mobility. Is it just me, or do other people prefer RFC 6275 to RFC6275? Spaces are cheap.. will add those. Many RFCs don't have a space between them, but it should be ok. Regards, -- Hidetoshi - Jouni Also, the suggested dates for chartered work items seem quite unrealistic to me. ;-) +3 months? That would at least enable some believability. I noticed that part of the charter fit nicely in my 80-column (vi) text window, and part of the charter does not fit nicely. I could also fix that if desired. Fixed. Thanks! For convenience, I attached the rfcdiff output from my previous text of the charter compared to today's version #9. If doing so is not helpful, please let me know. Regards, Charlie P. Diff dmm_charter-Jun10,2014.txt - dmm_charter-Jun10,2014b.txt.htm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Call for WG Adoption of a current practices and gap analysis document
Hi all, Sorry for my last minute comment. In comparing the two documents, [1] gives a detailed analysis of 3GPP technologies, but may be too much focused on one SDO. [2] analyzes WiFi networks as well as 3GPP, which provides somewhat a good balance for an IETF document by mentioning multiple access technologies. If I have to pick only one, [2] draft-liu-dmm-best-practices-gap-analysis-01 is good for the base document. Regards, -- Hidetoshi (2012/12/20 5:25), Jouni Korhonen wrote: Folks, We are unfortunately slipping our milestone, our (chairs) apologies for that. The next step is to select a current practices and gap analysis document to serve as the basis for the future WG document. We consider two documents on this topic to choose from: [1] draft-zuniga-dmm-gap-analysis-02 [2] draft-liu-dmm-best-practices-gap-analysis-01 and we as a WG need to decide which one is going to form the _basis_ for the WG document. Please voice your preference either for [1] or for [2] on the mailing list. We would appreciate if you can also provide a one-liner justification for your selection. The chairs will determine if there is (rough) consensus from active WG participants to proceed with selecting one document against the other. The call starts today 19th Dec 2012 and ends by 10th Jan 2013. We have a longer three week call now due the holiday season in between. - Jouni Julien ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
