Hi,
Regarding the first comment about transparency to upper layers, I agree that
this is a very limiting requirement but also think it is a crucial one for
backwards compatibility. So I do not think we can lighten it by defining a time
limit.
However, we can allow optimization features that rely on upper-layer protocols
(or applications) being aware of IP layer mobility as long as these are for
optimization only. This means that upper-layer protocols/applications that are
NOT aware of IP mobility will continue to work correctly but without extra
optimization that those which ARE aware will utilize.
In fact, I believe that we should modify the REQ2 to allow features that are
not transparent to upper layers as long as backwards compatibility is
maintained.
Regards,
/Danny
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of
Jong-Hyouk Lee
Sent: Friday, April 19, 2013 11:14
To: KIM, BYOUNG-JO J (BYOUNG-JO)
Cc: dmm@ietf.org; dmm-cha...@tools.ietf.org
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03
Hello, Byoung-Jo
Regarding your comments on the security text, for your comment 2, I do not
quite get you. Provide clear text expressing your concern then I will review
and try to reflect to the draft. For your comment 5, just you need to be sure
that the given text is about the general security consideration.
Cheers.
On Wed, Apr 17, 2013 at 9:44 PM, KIM, BYOUNG-JO J (BYOUNG-JO)
<macs...@research.att.com<mailto:macs...@research.att.com>> wrote:
Hi.
Below are my comments on the draft-ietf-dmm-requirements-03.
Overall, the draft has much to admire and agreeable on most points.
Kudos to the authors.
===================
Comment 1:
REQ2: Transparency to Upper Layers when needed
>> I would like to suggest that DMM must provide transparency to upper layers
>> for a limited time only when needed. Upper layer protocols or applications
>> that are unaware of IP layer mobility and IP address changes cannot be
>> supported indefinitely, without compromising the purpose of DMM. How much
>> time is of course another matter, but that can be discussed during design or
>> even dynamic.
In time, applications and upper layer protocols will have to be updated to
handle IP address changes by reconnect or other means, as long as DMM provides
temporary shield from packet losses or other disruptions and buy them time to
make preparations.
====================
Comment 2:
REQ6: Security considerations
>> I think the requirements described here may give the impression that DMM
>> excludes ephemeral security for the purpose of routing to the correct
>> entities, but not necessarily tied to service authorizations or identities.
>> Also, protection requirements beyond what current ISPs deal with for their
>> access routers seem unnecessary. DMM's own security should be limited to
>> risks that DMM adds to the access network, not the whole access network
>> security.
=====================
Comment 3:
REQ7: DMM should enable multicast solutions in flexible distribution scenario.
>> I lack the necessary knowledge on multicast but this seems like a feel-good
>> statement without a point. I suggest to drop this requirement or make a
>> clearer statement like "DMM should allow multicast to survive IP layer
>> mobility without packet loss", or more modestly, "DMM should not foreclose
>> multicast support during IP layer mobility.", etc..
====================
Comment 4:
5. Security Considerations
Distributed mobility management (DMM) requires two kinds of security
considerations: First, access network security that only allows a
legitimate mobile host/router to access the DMM service; Second, end-
to-end security that protects signaling messages for the DMM service.
>> Related to my Comment 2, "access network security" is confusing here, as it
>> often means allowing access to the network to begin with. DMM must assume
>> that is already done at least in the lower layer or even IP layer. It may or
>> may not offer DMM service to anyone or only to authorized devices/users. I
>> think DMM must cover the situation where the service is offered to anything
>> that asks for it, while ensuring the packets are not redirected to wrong
>> directions.
===================
Bests.
Byoung-Jo "J" Kim
AT&T Labs - Research
https://sites.google.com/site/macsbug/
On Apr 10, 2013, at 3:19 AM, Jouni Korhonen wrote:
> Folks,
>
> This mail starts a two week WGLC #2 for draft-ietf-dmm-requirements-03.
> The issues, even editorials, must be recorded into the Issue Tracker,
> otherwise they are likely to be neglected. We require minimum three
> reviews (that are more than one liners). The more the better, though.
>
> The WGLC ends on Wednesday 24rd April.
>
> - Jouni & Julien
> _______________________________________________
> dmm mailing list
> dmm@ietf.org<mailto:dmm@ietf.org>
> https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
dmm@ietf.org<mailto:dmm@ietf.org>
https://www.ietf.org/mailman/listinfo/dmm
--
RSM Department, TELECOM Bretagne, France
Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
#email: jonghyouk (at) gmail (dot) com
#webpage: http://sites.google.com/site/hurryon/
---------------------------------------------------------------------
A member of the Intel Corporation group of companies
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
