Diff: dmm_charter-Jun10,2014b.txt - dmm_charter-v9.txt

94 lines changed or deleted

-- 
Hidetoshi Yokota

KDDI R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

-- =20
Hidetoshi Yokota

KDDI R&D Laboratories, Inc.
e-mail:yokota=40kddila=
bs.jp
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F
dmm mailing list
dmm=40ietf.org
https://www.iet=
f.org/mailman/listinfo/dmm

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

-- 
Regards,
Charlie P.
      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 R&D Laboratories, Inc.
e-mail:yokota@kddilabs.jp

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.

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

- 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