Hello Antony,

Thanks for the good work.  You just said this is our last chance to
suggest change so here is my last try.

Currently in draft-ietf-dmm-requirements-02 this Req2 Transparency reads:

REQ2:  Transparency to Upper Layers when needed

DMM solutions MUST provide transparent mobility support above the IP
 layer when needed.  Such transparency is needed, for example, when,
 upon change of point of attachment to the Internet, an application
flow cannot cope with a change in the IP address.  Otherwise, support
for maintaining a stable home IP address or prefix during handovers
may be declined.

This last 'declined' sounds IMHO as if this 'support' were requested in
the first place.  But this request assumes maybe a solution is in place
(like Mobile IP or so).  I'd rather use the word 'impossible', instead
of 'declined', and 'is' instead of 'may be'.

Motivation: The motivation of this requirement is to enable more
efficient use of network resources and more efficient routing by not
 maintaining context at the mobility anchor when there is no such
need.

I agree with the motivation, although it sounds just a bit strange to
me.  Maybe it is strange to me because I myself assume Mobile IP :-)

Maybe another motivation is like this: "it is hardly feasible to modify
all applications deployed (see the large number of applications in the
Deering's hourglass model [xx]) such that to support change in IP
address or prefix above IP layer without restarting the applications
during an ongoing flow (e.g. audio call).  This motivates to propose
changes at a single point which is the IP layer instead (the waist of
the hourglass)."

Thanks,

Alex

Le 03/08/2012 19:07, h chan a écrit :
How about the following:

The DMM solutions MUST provide transparency above the IP layer when
needed. Such transparency is needed, for example, upon change of
point of attachment to the Internet for the application flows that
cannot cope with a change of IP address. Otherwise the support to
maintain a stable home IP address or prefix during handover may be
declined.

Or

The DMM solutions MUST enable transparency above the IP layer. Such
transparency is needed, for example, upon change of point of
attachment to the Internet for the application flows that cannot cope
with a change of IP address. Otherwise the support to maintain a
stable home IP address or prefix during handover may be declined.

H Anthony Chan

-----Original Message----- From: Alexandru Petrescu
[mailto:[email protected]] Sent: Thursday, August 02, 2012
11:39 AM To: h chan Cc: [email protected] Subject: Re: [DMM] Comment on
Req2 transparency for DMM

H Anthony,

Yes, this reflects Sri's and my suggestion about removal of MN/MR
qualifier.  I agree with the idea of the new text as you put it.

Then, if I re-read just like that, there still seems to be some
difficulty to my brain to understand:

Le 01/08/2012 23:35, h chan a écrit :
The DMM solutions MUST provide transparency above the IP layer
when needed, such as upon change of point of attachment to the
Internet, for the application flows that cannot cope with a change
of IP address. Otherwise the support to maintain a stable home IP
address or prefix during handover may be declined.

I don't understand the last phrase - the 'otherwise' relates to the
first MUST?  Or to the latter 'cannot'?

But this may be just nitpicking on the use of language.  I agree
with the direction of the idea and thank you for having provided the
 modification.

Alex




_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm

Reply via email to