Subject: Re: [Gen-art] Gen-art LC review of draft-ietf-dmm-best-practices-gap-analysis-07

From: "H Anthony Chan" <[email-masked]>
Date: Sat, 11 Oct 2014 00:16:44 -0500

Elwyn,

Thank you for your review. We have revised and uploaded version -08 with the following changes:

Applicability to Mobile IPv4?  It appears from the early sections that this draft is pretty much concentrated on Mobile IPv6 (see the first para of s3 which mentions v6 RFCs exclusively and IPv4 seems to be mentioned in only a very limited way later) although this is not stated.  To avoid wasting people's time, it would be useful to put a few words about the relevance or otherwise of this draft to Mobile IPv4 work in the introduction (and maybe the title?) before we get to s5.3 where there is more clarity.

The following is appended to the end of first paragraph in the introduction:
The analysis is primarily
   towards IPv6 deployment, but can be seen to also apply to IPv4
   whenever there are IPv4 counterparts equivalent to the IPv6 mobility
   protocols.

s6:  I don't know if there is any extra security risk in adding extra MAs etc that might allow a malicious party to offer spurious MA and so to redirect traffic inappropriately.  I don't know enough about this problem space to know how well this is mitigated already.  Might be worth a mention? (maybe would affect s5.8 if so).  

The first sentence in Section 6 in version -07 was
6.  Security Considerations

   Distributed mobility management systems encounter same security

   threats as existing centralized IP mobility protocols.  

It is changed in version -08 to:
6.  Security Considerations

   The deployment of DMM using existing IP mobility protocols raises
   similar security threats as those encountered in centralized mobility
   management systems.  

It is no longer referring to DMM systems in general. 

s1: For the uninitiated, a explanation of what a mobility anchor is would be helpful.  Quoting some (or even all) of the first para of RFC 7333 would do the trick nicely.

The first paragraph is changed to:
1.  Introduction

   Existing network-layer mobility management protocols have primarily
   employed a mobility anchor to ensure connectivity of a mobile node by
   forwarding packets destined to, or sent from, the mobile node after
   the node has moved to a different network.  The mobility anchor has
   been centrally deployed in the sense that the traffic of millions of
   mobile nodes in an operator network is typically managed by the same
   anchor.  This centralized deployment of mobility anchors to manage IP
   sessions poses several problems.  In order to address these problems,
   a distributed mobility management (DMM) architecture has been
   proposed.  This document investigates whether it is feasible to
   deploy current IP mobility protocols in a DMM scenario in a way that
   can fulfill the requirements as defined in [RFC7333].  It discusses
   current deployment practices of existing mobility protocols and
   identifies the limitations (gaps) in these practices from the
   standpoint of satisfying DMM requirements.  The analysis is primarily
   towards IPv6 deployment, but can be seen to also apply to IPv4
   whenever there are IPv4 counterparts equivalent to the IPv6 mobility
   protocols.

s1, para 1: s/pose several problems/poses several problems/

changed as suggested

s2, last para: s/without the reliance on centrally deployed/without reliance on centrally deployed/

changed to
without relying on centrally deployed mobility anchors to manage
   IP mobility sessions.

s3, para 1: 
Although these two are centralized approaches,Two? Three items are mentioned in the previous sentence, but maybe the Host approach and Proxy extension is supposed to be considered as a single scheme.  Maybe something like:
      "Although these approaches are centralized,.."
would avoid the confusion.

changed as suggested

s3, two instances paras after bullet #3:
OLD

   the
   forwarding management (FM)function is both ends of tunneling at the
   HA and the MN. [MAG in second case]
NEW:
   the forwarding management (FM) function involves both ends of the tunnel
   between the HA and the MN.  [MAG in second case]

changed to:the   Forwarding Management (FM) function resides in both ends of the   tunnel at the HA and the MN. s3, last para: s/MAP also has FM function/MAP also provides the FM function/

corrected s4.2, para after Figure 1: Probably best to s/In the figure/In Figure 1/ just 
to be totally clear.

corrected s4.2, 2nd para after Figure 1:   IP mobility protocols can be used to provide inter-access mobility
   support to usersI don't know if 'inter-access mobility' is acceptable jargon but I would suggest 
adding 'mode', 'method' or 'technology' -- thus
IP mobility protocols can be used to provide inter-access mode mobility
   support to userschanged to   IP mobility protocols can be used to provide heterogeneous network   mobility support to users, e.g., handover from Wi-Fi to cellular   access.  s4.2.1, para 2:Note
   that some of these mechanisms [SDO-3GPP.23.402] have been defined in
   other standards organizations.It is not clear what 'some' refers to here:  It could refer to the mechanisms 
that are noted as not specified [implied, by the IETF?] or someting earlier in the 
paragraph or stuff in Figure 2 (BT/RO modes?).  Please clarify.

Sentenced is deletedFigure 2:  I like the 'zzzz' :-) I guess this is supposed to signify a tunnel but it 
would be appropriate to have a key for '(o)' and 'zzzz'!  I take it CN1/CN2 are 
'Correspondent Nodes' (per section 2) but it might be useful to reinforce this in 
the key also. 

Figure 2 is redrawns4.2.1, para after bullets: Please expand acronym CoA on first use.Correcteds4.2.1, para before Fig 3: s/It allows reducing the amount/It allows the reduction of the amount/
CorrectedFigure 4: Oh, dear! Boring old 'xxx' for tunnels. :-(  But I guess it should have a key again.Figure 4 is redrawns4.2.2, para after Fig 4: s/Similar to/In a similar way to/
Corrected
s4.2.2, 2nd para after Fig 4: s/the LMA runtime assignment [RFC6463]/the support 
the LMA runtime assignment described in [RFC6463]/; Correcteds/is mainly aimed for/is mainly aimed at/

will change in version 09 to "is mainly used for"s4.3, para 1: Is there a suitable overview reference for the EPS architecture?  Might be useful here.

added reference [SDO-3GPP.23.402]s4.3, para before Fig 6: ... or at the macro, ...I have no idea what this means.deleted these words

Figures 6 and 7: Something has gone wrong with the layout here. (Non-ASCII characters?) 

corrected

s4.3, Figure 7 and para before it (and earlier): I think PGW and P-GW, also SGW and S-GW, are supposed to be acronyms for the same thing. Please make this consistent. (PGW is used elsewhere as well).

changed to PGW

s4.3, para after Fig 7: I think eNB needs expansion [Thank you 3GPP for the heavy duty acronym soup!] 

defined acronym for enhanced Node B

Figure 8: Is "H(e)NB" the same as "HeNB"? Be good to be consistent if so; If not what is the difference? 

Changed to 
HeNB

s4.3, last para: s/specially/especially/

corrected

s5, general: Indexing the gaps:  For the purposes of clarity, future discussion and possible solutions, it would probably be worth assigning serial numbers to the identified gaps  in the same way as the requirements are indexed (maybe even linking them to the relevant req by calling gaps related to REQ#0 something like GAP#0-1, GAP#0-2 etc.) There are also a couple of places, notably the end of s5.2, where it is not quite clear whether items (like the last para of s5.2) are separate gaps or part of the previous one. Numbering the gaps might help to concentrate the text on linking together (or separating) problems into well-defined sets. 

s5.1, para 1: s/enable/make it possible for/; s/single/a single/

corrected

s5.1, first bullet: s/this may also require to transfer/this may also require the transfer of/ 

corrected

s5.1, para after 2nd bullet: s/therefore providing/thereby providing/ 

corrected

s5.1, 2nd para after 2nd bullet:
OLD: where the mobility client natively knows each anchor associated to each mobility sessions.
NEW: where the mobility client natively knows the anchor associated with each of its mobility sessions.

corrected

s5.1, 3rd para after 2nd bullet: s/to allow dynamically discovering the presence of nodes/to allow the dynamic discovery of the presence of nodes/;    

corrected

s/to allow selecting a node/to allow the selection of a node/  

will change in version 09

and...OLD: There are though some mechanisms that could help discovering anchors, such as the Dynamic Home Agent Address Discovery (DHAAD)NEW: However, there are some mechanisms that could help to discover anchors, such as the Dynamic Home Agent Address Discovery (DHAAD)

changed

Additionally: 
Does DHAAD deserve a reference?

added reference [RFC6275]

s5.1, last para: I have suggested some changes to make this clearer (I hope):
OLD: Also note that REQ1 is such that the data plane traffic can avoid suboptimal route. Distributed processing of the traffic is then needed only in the data plane. The needed capability in distributed processing therefore should not contradict with centralized control plane. Other control plane solutions such as charging, lawful interception, etc. should not be limited. Yet combining the control plane and data plane forwarding management (FM) function may limit the choice to distributing both data plane and control plane together. In order to enable distributing only the data plane without distributing the control plane, a gap is to split the forwarding management function into the control plane (FM-CP) and data plane (FM-DP).
NEW: Also note that REQ1 is intended to prevent the data plane traffic taking a suboptimal route. Distributed processing of the traffic is then, hopefully, needed only in the data plane. Provision of this capability for distributed processing should not conflict with the use of a centralized control plane. Other control plane solutions such as charging, lawful interception, etc. should not be constrained by the DMM solution. On the other hand combining the control plane and data plane forwarding management (FM) function may limit the choice of solutions to those that distribute both data plane and control plane together. In order to enable distribution of only the data plane without distributing the control plane,it would be necessary to split the forwarding management function into control plane (FM-CP) and data plane (FM-DP) components; there is currently a gap here.

changed to
   GAP1-4:  Also note that REQ1 is intended to prevent the data plane
            traffic from taking a suboptimal route.  Distributed
            processing of the traffic may then be needed only in the
            data plane.  Provision of this capability for distributed
            processing should not conflict with the use of a centralized
            control plane.  Other control plane solutions such as
            charging, lawful interception, etc.  should not be
            constrained by the DMM solution.  On the other hand
            combining the control plane and data plane forwarding
            management (FM) function may limit the choice of solutions
            to those that distribute both data plane and control plane
            together.  In order to enable distribution of only the data
            plane without distributing the control plane, it would be
            necessary to split the forwarding management function into
            the control plane (FM-CP) and data plane (FM-DP) components;
            there is currently a gap here.

s5.2, para 1: s/flexibility on determining/flexibility in determining/; s/whether or not use/whether or not to use/

changed

s5.2, para 1:
 It only enables the two following functions:I am not sure what 'it' refers to here. Is this the functionality that is needed to implement REQ1? Or what? 

Changed to:
The following two functions are also
   needed:

s5.2, 1st bullet: s/which uses/which use/

corrected

s5,2, 1st para after bullets: s/to indicate the IP stack/to indicate to the IP stack/ 

corrected

s5,2, 1st para after bullets: 
mobility support is required or not in.Either the 'in' is redundant or there is a phrase missing at the end. 

delete
"in"

s5.2, next to last para: s/there exist these individual efforts that/these individual efforts and they/ 

changed to
Although these individual efforts exist and they could be
            considered as attempts to fix the gap, there is no solution
            adopted as a work item within any IETF working group.

s5.4, para 2: s/nothing prevent/nothing prevents/; 

corrected

s/functions with in IP mobility/functions within IP mobility/ 

corrected

s5.4, last para: s/going into the direction/going in the direction/

corrected

s5.5: s/the needed mobility management/the necessary mobility management/ 

corrected

s5.6, bullet 6: s/of forwarding path/of the forwarding path/ 

corrected

s5.6, para after bullets: s/the above list of operation/how, or whether, they support the above list of operation/ 
correcteds5.7: Everything after the first sentence is either 'motherhood and apple pie' or statements
 of things that allegedly work.  No gaps are identified - so everything except the first sentence 
could probably be replaced with:
   Any solutions that are intended to fill in gaps identified in this document 
   need to meet this requirement.  At present, it does not appear that using
   existing solutions to support DMM has introduced any new security issues.  

added as suggesteds5.8, para 1: s/to enable multicast solutions to be developed/to allow the development of multicast solutions/

correcteds5.8, para 2: s/insta ces/instances/

corrected Section 5.9 is revised to5.9.  Summary   We next list the main gaps identified from the analysis performed   above:   GAP1-1:  Existing solutions only provide an optimal initial anchor            assignment, a gap being the lack of dynamic anchor change/            new anchor assignment.  Neither the HA switch nor the LMA            runtime assignment allows changing the anchor during an            ongoing session.  MOBIKE allows change of GW but its            applicability has been scoped to a very narrow use case.   GAP1-2:  The MN needs to be able to perform source address selection.            Proper mechanism to inform the MN is lacking to provide the            basis for the proper selection.   GAP1-3:  Currently, there is no efficient mechanism specified by the            IETF that allows the dynamic discovery of the presence of            nodes that can play the role of anchor, discover their            capabilities and allow the selection of the most suitable            one.  However, the following mechanisms could help            discovering anchors:            Dynamic Home Agent Address Discovery (DHAAD): the use of the            home agent (H) flag in Router Advertisements (which            indicates that the router sending the Router Advertisement            is also functioning as a Mobile IPv6 home agent on the link)            and the MAP option in Router Advertisements defined by            HMIPv6.   GAP1-4:  While existing network-based DMM practices may allow the            deployment of multiple LMAs and dynamically select the best            one, this requires to still keep some centralization in the            control plane, to access the policy database (as defined in            RFC5213).  Although [I-D.ietf-netext-pmip-cp-up-separation]            allows a MAG to perform splitting of its control and user            planes, there is a lack of solutions/extensions that support            a clear control and data plane separation for IETF IP            mobility protocols in a DMM context.   GAP2-1:  The information of which sessions at the mobile node are            active and are using the mobility support need to be            transferred to or shared with the network.  Such mechanism            has not been defined.   GAP2-2:  The mobile node needs to simultaneously use multiple IP            addresses with different properties.  There is a lack of            mechanism to expose this information to the mobile node            which can then update accordingly its source address            selection mechanism.   GAP2-3:  The handling of mobility management has not been to the            granularity of an individual session of a user/device            before.  The combination of session identification and user/            device identification may be lacking.   GAP6-1:  Mobility management protocols have not thoroughly documented            how, or whether, they support the following list of            operation and management considerations:            *  A DMM solution needs to consider configuring a device,               monitoring the current operational state of a device,               responding to events that impact the device, possibly by               modifying the configuration and storing the data in a               format that can be analyzed later.            *  A DMM solution has to describe in what environment and               how it can be scalably deployed and managed.            *  A DMM solution has to support mechanisms to test if the               DMM solution is working properly.            *  A DMM solution is expected to expose the operational               state of DMM to the administrators of the DMM entities.            *  A DMM solution, which supports flow mobility, is also               expected to support means to correlate the flow routing               policies and the observed forwarding actions.            *  A DMM solution is expected to support mechanisms to check               the liveness of the forwarding path.            *  A DMM solution has to provide fault management and               monitoring mechanisms to manage situations where update               of the mobility session or the data path fails.            *  A DMM solution is expected to be able to monitor the               usage of the DMM protocol.            *  DMM solutions have to support standardized configuration               with NETCONF [RFC6241], using YANG [RFC6020] modules,               which are expected to be created for DMM when needed for               such configuration.   GAP6-2:  Management information base (MIB) objects are currently            defined in [RFC4295] for MIPv6 and in [RFC6475] for PMIPv6.            Standardized configuration with NETCONF [RFC6241], using            YANG [RFC6020] modules is lacking. s5.9, bullet 1: s/to very narrow use case./to a very narrow use case./

correcteds5.9, bullet 2: s/requires to expose/requires the exposure of/

The entire sentence is rewrittenThere is a lack of
            mechanism to expose this information to the mobile node
            which can then update accordingly its source address
            selection mechanism.

 s5.9, bullet 3: s/allows to dynamically discover/allows the dynamic discovery of/

corrected s5.9, bullet 5: s/may allow to deploy/may allow the deployment of/

correcteds6: s/encounter same security/encounter the same security/
Entire sentenced has been rewritten  
   The deployment of DMM using existing IP mobility protocols raises
   similar security threats as those encountered in centralized mobility
   management systems.  

H Anthony Chan

From: Elwyn Davies 
Sent: Thursday, September 18, 2014 12:00 PM
To: General area reviewing team ; [email-masked] 
Subject: Gen-art LC review of draft-ietf-dmm-best-practices-gap-analysis-07

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at 

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. 

Please resolve these comments along with any other Last Call comments 
you may receive. 

Document: draft-ietf-dmm-best-practices-gap-analysis-07.txt
Reviewer:  Elwyn Davies
Review Date: 2014-09-18
IETF LC End Date: 2014-09-25
IESG Telechat date: (if known) -

Summary:  Almost ready.  A couple of minor issues (one almost editorial and one may be due to my lack of knowledge of the current state of Mobile IPv6 security) and mostly a lot of minor language nits.  I think there might be some point in numbering the identified gaps to facilitate future discussion.

Major issues: 
None

Minor issues: 
Applicability to Mobile IPv4?  It appears from the early sections that this draft is pretty much concentrated on Mobile IPv6 (see the first para of s3 which mentions v6 RFCs exclusively and IPv4 seems to be mentioned in only a very limited way later) although this is not stated.  To avoid wasting people's time, it would be useful to put a few words about the relevance or otherwise of this draft to Mobile IPv4 work in the introduction (and maybe the title?) before we get to s5.3 where there is more clarity.

s6:  I don't know if there is any extra security risk in adding extra MAs etc that might allow a malicious party to offer spurious MA and so to redirect traffic inappropriately.  I don't know enough about this problem space to know how well this is mitigated already.  Might be worth a mention? (maybe would affect s5.8 if so).    

Nits/editorial comments: 
s1: For the uninitiated, a explanation of what a mobility anchor is would be helpful.  Quoting some (or even all) of the first para of RFC 7333 would do the trick nicely.

s1, para 1: s/pose several problems/poses several problems/

s2, last para: s/without the reliance on centrally deployed/without reliance on centrally deployed/

s3, para 1: 
Although these two are centralized approaches,Two? Three items are mentioned in the previous sentence, but maybe the Host approach and Proxy extension is supposed to be considered as a single scheme.  Maybe something like:
      "Although these approaches are centralized,.."
would avoid the confusion.

s3, two instances paras after bullet #3:
OLD

   the
   forwarding management (FM)function is both ends of tunneling at the
   HA and the MN. [MAG in second case]
NEW:
   the forwarding management (FM) function involves both ends of the tunnel
   between the HA and the MN.  [MAG in second case]

s3, last para: s/MAP also has FM function/MAP also provides the FM function/

s4.2, para after Figure 1: Probably best to s/In the figure/In Figure 1/ just 
to be totally clear.

s4.2, 2nd para after Figure 1:   IP mobility protocols can be used to provide inter-access mobility
   support to usersI don't know if 'inter-access mobility' is acceptable jargon but I would suggest 
adding 'mode', 'method' or 'technology' -- thus
IP mobility protocols can be used to provide inter-access mode mobility
   support to users
s4.2.1, para 2:Note
   that some of these mechanisms [SDO-3GPP.23.402] have been defined in
   other standards organizations.It is not clear what 'some' refers to here:  It could refer to the mechanisms 
that are noted as not specified [implied, by the IETF?] or someting earlier in the 
paragraph or stuff in Figure 2 (BT/RO modes?).  Please clarify.

Figure 2:  I like the 'zzzz' :-) I guess this is supposed to signify a tunnel but it 
would be appropriate to have a key for '(o)' and 'zzzz'!  I take it CN1/CN2 are 
'Correspondent Nodes' (per section 2) but it might be useful to reinforce this in 
the key also. 

s4.2.1, para after bullets: Please expand acronym CoA on first use.

s4.2.1, para before Fig 3: s/It allows reducing the amount/It allows the reduction of the amount/

Figure 4: Oh, dear! Boring old 'xxx' for tunnels. :-(  But I guess it should have a key again.

s4.2.2, para after Fig 4: s/Similar to/In a similar way to/

s4.2.2, 2nd para after Fig 4: s/the LMA runtime assignment [RFC6463]/the support 
the LMA runtime assignment described in [RFC6463]/; s/is mainly aimed for/is mainly aimed at/

s4.3, para 1: Is there a suitable overview reference for the EPS architecture?  Might be useful here.

s4.3, para before Fig 6: ... or at the macro, ...I have no idea what this means.

Figures 6 and 7:  Something has gone wrong with the layout here.  (Non-ASCII characters?)

s4.3, Figure 7 and para before it (and earlier): I think PGW and P-GW, also SGW and S-GW, are 
supposed to be acronyms for the same thing. Please make this consistent. (PGW is used elsewhere 
as well).

s4.3, para after Fig 7: I think eNB needs expansion [Thank you 3GPP for the heavy duty acronym soup!]

Figure 8: Is "H(e)NB" the same as "HeNB"? Be good to be consistent if so; If not what is the difference?

s4.3, last para: s/specially/especially/

s5, general: Indexing the gaps:  For the purposes of clarity, future discussion and possible solutions, 
it would probably be worth assigning serial numbers to the identified gaps  in the same way as the 
requirements are indexed (maybe even linking them to the relevant req by calling gaps related to 
REQ#0 something like GAP#0-1, GAP#0-2 etc.)  There are also a couple of places, notably the end of s5.2, 
where it is not quite clear whether items (like the last para of s5.2) are separate gaps or part of the 
previous one.  Numbering the gaps might help to concentrate the text on linking together (or separating) 
problems into well-defined sets. 

s5.1, para 1: s/enable/make it possible for/; s/single/a single/

s5.1, first bullet: s/this may also require to transfer/this may also require the transfer of/

s5.1, para after 2nd bullet: s/therefore providing/thereby providing/

s5.1, 2nd para after 2nd bullet:
OLD:
   where the mobility
   client natively knows each anchor associated to each mobility
   sessions.
NEW:
   where the mobility
   client natively knows the anchor associated with each of its mobility
   sessions.

s5.1, 3rd para after 2nd bullet: s/to allow dynamically discovering the presence of nodes/to allow
   the dynamic discovery of the presence of nodes/; 
   s/to allow selecting a node/to allow the selection of a node/
 and...
OLD:
   There are though some mechanisms
   that could help discovering anchors, such as the Dynamic Home Agent
   Address Discovery (DHAAD)
NEW:
   However, there are some mechanisms
   that could help to discover anchors, such as the Dynamic Home Agent
   Address Discovery (DHAAD)
Additionally: Does DHAAD deserve a reference?

s5.1, last para:  I have suggested some changes to make this clearer (I hope):
OLD:
   Also note that REQ1 is such that the data plane traffic can avoid
   suboptimal route.  Distributed processing of the traffic is then
   needed only in the data plane.  The needed capability in distributed
   processing therefore should not contradict with centralized control
   plane.  Other control plane solutions such as charging, lawful
   interception, etc. should not be limited.  Yet combining the control
   plane and data plane forwarding management (FM) function may limit
   the choice to distributing both data plane and control plane
   together.  In order to enable distributing only the data plane
   without distributing the control plane, a gap is to split the
   forwarding management function into the control plane (FM-CP) and
   data plane (FM-DP).
NEW:
   Also note that REQ1 is intended to prevent the data plane traffic taking a 
   suboptimal route.  Distributed processing of the traffic is then, hopefully,
   needed only in the data plane.  Provision of this capability for distributed
   processing should not conflict with the use of a centralized control
   plane.  Other control plane solutions such as charging, lawful
   interception, etc. should not be constrained by the DMM solution.  On the other hand combining the control
   plane and data plane forwarding management (FM) function may limit
   the choice of solutions to those that distribute both data plane and control plane
   together.  In order to enable distribution of only the data plane
   without distributing the control plane,it would be necessary to split the
   forwarding management function into control plane (FM-CP) and
   data plane (FM-DP) components; there is currently a gap here.

s5.2, para 1: s/flexibility on determining/flexibility in determining/;
s/whether or not use/whether or not to use/

s5.2, para 1: It only enables the two following functions:I am not sure what 'it' refers to here.  Is this the functionality that is needed to implement REQ1? Or what?

s5.2, 1st bullet: s/which uses/which use/

s5,2, 1st para after bullets: s/to indicate the IP stack/to indicate to the IP stack/

s5,2, 1st para after bullets: 
mobility support is required or not in.Either the 'in' is redundant or there is a phrase missing at the end.

s5.2, next to last para:
s/there exist these individual efforts that/these individual efforts and they/ 

s5.4, para 2: s/nothing prevent/nothing prevents/; s/functions with in IP mobility/functions within IP mobility/

s5.4, last para: s/going into the direction/going in the direction/

s5.5: s/the needed mobility management/the necessary mobility management/

s5.6, bullet 6: s/of forwarding path/of the forwarding path/

s5.6, para after bullets: s/the above list of operation/how, or whether, they support the above list of operation/

s5.7: Everything after the first sentence is either 'motherhood and apple pie' or statements
 of things that allegedly work.  No gaps are identified - so everything except the first sentence 
could probably be replaced with:
   Any solutions that are intended to fill in gaps identified in this document 
   need to meet this requirement.  At present, it does not appear that using
   existing solutions to support DMM has introduced any new security issues.  

s5.8, para 1: s/to enable multicast solutions to be developed/to allow the development of multicast solutions/

s5.8, para 2: s/insta ces/instances/

s5.9, bullet 1: s/to very narrow use case./to a very narrow use case./

s5.9, bullet 2: s/requires to expose/requires the exposure of/

s5.9, bullet 3: s/allows to dynamically discover/allows the dynamic discovery of/

s5.9, bullet 5: s/may allow to deploy/may allow the deployment of/

s6: s/encounter same security/encounter the same security/

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 14 Oct 2014 20:26:36 +0100

Hi, Anthony.

These changes look good.  I have run through all the changes in -08 and 
there are (IMO) a couple of minor nits left:

s3, two instances paras after bullet #3 [2nd cut!]:
OLD

    the Forwarding Management (FM) function resides in both ends of the 
tunnel
    between the HA and the MN.  [MAG in second case]

NEW:
    the Forwarding Management (FM) function is distributed between the 
ends of the tunnel
    between the HA and the MN.  [MAG in second case]

[Missed this one in -07]

s4.2, 2nd para after Figure 1: s/Two kind/Two kinds/

s4.2, 3rd para after Figure 1: "flattening mobile networks" -- this 
piece of jargon could do with a definition or at least a pointer to a 
reference.

s4.2.1, para 2, last sentence: s/in IETF/in IETF standards/ [or "documents"]

Figure 2: Still needs a (small) key to indicate "==== <- tunnel"
Similarly for Figures 3 and 4.

s4.2.1, 2nd para after Figure 3:
s/some form of route optimization/a form of route optimization/

s4.2.1, 4th para after Figure 3:
s/used to help distributing/used to help with distributing/

s5.2, GAP2-3: The para formatting doesn't match the other GAPs.

On 11/10/14 06:16, H Anthony Chan wrote:
> Applicability to Mobile IPv4?  It appears from the early sections that
> this draft is pretty much concentrated on Mobile IPv6 (see the first
> para of s3 which mentions v6 RFCs exclusively and IPv4 seems to be
> mentioned in only a very limited way later) although this is not
> stated.  To avoid wasting people's time, it would be useful to put a few
> words about the relevance or otherwise of this draft to Mobile IPv4 work
> in the introduction (and maybe the title?) before we get to s5.3 where
> there is more clarity.
> s6:  I don't know if there is any extra security risk in adding extra
> MAs etc that might allow a malicious party to offer spurious MA and so
> to redirect traffic inappropriately.  I don't know enough about this
> problem space to know how well this is mitigated already.  Might be
> worth a mention? (maybe would affect s5.8 if so).
> 6.Security Considerations
>
> 6.Security Considerations
>
> s1: For the uninitiated, a explanation of what a mobility anchor is
> would be helpful.  Quoting some (or even all) of the first para of RFC
> 7333 would do the trick nicely.
> 1.Introduction
> the node has moved to a different network.The mobility anchor has
> anchor.This centralized deployment of mobility anchors to manage IP
> sessions poses several problems.In order to address these problems,
> proposed.This document investigates whether it is feasible to
> can fulfill the requirements as defined in [RFC7333].It discusses
> standpoint of satisfying DMM requirements.The analysis is primarily
>> Although these two are centralized approaches,
> Two? Three items are mentioned in the previous sentence, but maybe the
> Host approach and Proxy extension is supposed to be considered as a
> single scheme.  Maybe something like:
> changed to:
> Forwarding Management (FM) function resides in both ends of the
> tunnel at the HA and the MN.
>
>
>
> s4.2, 2nd para after Figure 1:
>>     IP mobility protocols can be used to provide inter-access mobility
>>     support to users
> I don't know if 'inter-access mobility' is acceptable jargon but I would suggest
> IP mobility protocols can be used to provide heterogeneous network
> mobility support to users, e.g., handover from Wi-Fi to cellular
> access.
>
> s4.2.1, para 2:
>> Note
>>     that some of these mechanisms [SDO-3GPP.23.402  <http://tools.ietf.org/html/draft-ietf-dmm-best-practices-gap-analysis-07#ref-SDO-3GPP.23.402>] have been defined in
>>     other standards organizations.
> It is not clear what 'some' refers to here:  It could refer to the mechanisms
> Sentenced is deleted
> Figure 2 is redrawn
> Figure 4 is redrawn
> the LMA runtime assignment described in [RFC6463  <http://tools.ietf.org/html/rfc6463>]/;
>
> Corrected
>
> s/is mainly aimed for/is mainly aimed at/
>
> will change in version 09 to"is mainly used for"
>
> added reference  [SDO-3GPP.23.402]
>
> s4.3, para before Fig 6:
>
>> ... or at the macro, ...
>
> I have no idea what this means.
>
> deleted these words
> s4.3, Figure 7 and para before it (and earlier): I think PGW and P-GW,
> also SGW and S-GW, are supposed to be acronyms for the same thing.
> Please make this consistent. (PGW is used elsewhere as well).
> changed to PGW
> s5, general: Indexing the gaps:  For the purposes of clarity, future
> discussion and possible solutions, it would probably be worth assigning
> serial numbers to the identified gaps  in the same way as the
> requirements are indexed (maybe even linking them to the relevant req by
> calling gaps related to REQ#0 something like GAP#0-1, GAP#0-2 etc.)
> There are also a couple of places, notably the end of s5.2, where it is
> not quite clear whether items (like the last para of s5.2) are separate
> gaps or part of the previous one. Numbering the gaps might help to
> concentrate the text on linking together (or separating) problems into
> well-defined sets.
> s5.1, 3rd para after 2nd bullet: s/to allow dynamically discovering the
> presence of nodes/to allow the dynamic discovery of the presence of nodes/;
> corrected
> and...OLD: There are though some mechanisms that could help discovering
> anchors, such as the Dynamic Home Agent Address Discovery (DHAAD)NEW:
> However, there are some mechanisms that could help to discover anchors,
> such as the Dynamic Home Agent Address Discovery (DHAAD)
> changed
> Additionally:
> OLD: Also note that REQ1 is such that the data plane traffic can avoid
> suboptimal route. Distributed processing of the traffic is then needed
> only in the data plane. The needed capability in distributed processing
> therefore should not contradict with centralized control plane. Other
> control plane solutions such as charging, lawful interception, etc.
> should not be limited. Yet combining the control plane and data plane
> forwarding management (FM) function may limit the choice to distributing
> both data plane and control plane together. In order to enable
> distributing only the data plane without distributing the control plane,
> a gap is to split the forwarding management function into the control
> plane (FM-CP) and data plane (FM-DP).
> NEW: Also note that REQ1 is intended to prevent the data plane traffic
> taking a suboptimal route. Distributed processing of the traffic is
> then, hopefully, needed only in the data plane. Provision of this
> capability for distributed processing should not conflict with the use
> of a centralized control plane. Other control plane solutions such as
> charging, lawful interception, etc. should not be constrained by the DMM
> solution. On the other hand combining the control plane and data plane
> forwarding management (FM) function may limit the choice of solutions to
> those that distribute both data plane and control plane together. In
> order to enable distribution of only the data plane without distributing
> the control plane,it would be necessary to split the forwarding
> management function into control plane (FM-CP) and data plane (FM-DP)
> components; there is currently a gap here.
> changed to
>
> GAP1-4:Also note that REQ1 is intended to prevent the data plane
> traffic from taking a suboptimal route.Distributed
> data plane.Provision of this capability for distributed
> control plane.Other control plane solutions such as
> charging, lawful interception, etc.should not be
> constrained by the DMM solution.On the other hand
> together.In order to enable distribution of only the data
>>   It only enables the two following functions:
> I am not sure what 'it' refers to here. Is this the functionality that
> is needed to implement REQ1? Or what?
> Changed to:
>
>> mobility support is required or not in.
> Either the 'in' is redundant or there is a phrase missing at the end.
> delete
> "in"
> s5.6, para after bullets: s/the above list of operation/how, or whether,
> they support the above list of operation/
>
> corrected
>
> added as suggested
> Section 5.9 is revised to
>
> 5.9.Summary
>
> We next list the main gaps identified from the analysis performed
> above:
>
> GAP1-1:Existing solutions only provide an optimal initial anchor
> assignment, a gap being the lack of dynamic anchor change/
> new anchor assignment.Neither the HA switch nor the LMA
> runtime assignment allows changing the anchor during an
> ongoing session.MOBIKE allows change of GW but its
> applicability has been scoped to a very narrow use case.
>
> GAP1-2:The MN needs to be able to perform source address selection.
> Proper mechanism to inform the MN is lacking to provide the
> basis for the proper selection.
>
> GAP1-3:Currently, there is no efficient mechanism specified by the
> IETF that allows the dynamic discovery of the presence of
> nodes that can play the role of anchor, discover their
> capabilities and allow the selection of the most suitable
> one.However, the following mechanisms could help
> discovering anchors:
>
> Dynamic Home Agent Address Discovery (DHAAD): the use of the
> home agent (H) flag in Router Advertisements (which
> indicates that the router sending the Router Advertisement
> is also functioning as a Mobile IPv6 home agent on the link)
> and the MAP option in Router Advertisements defined by
> HMIPv6.
>
> GAP1-4:While existing network-based DMM practices may allow the
> deployment of multiple LMAs and dynamically select the best
>
>
>
> one, this requires to still keep some centralization in the
> control plane, to access the policy database (as defined in
> RFC5213).Although [I-D.ietf-netext-pmip-cp-up-separation]
> allows a MAG to perform splitting of its control and user
> planes, there is a lack of solutions/extensions that support
> a clear control and data plane separation for IETF IP
> mobility protocols in a DMM context.
>
> GAP2-1:The information of which sessions at the mobile node are
> active and are using the mobility support need to be
> transferred to or shared with the network.Such mechanism
> has not been defined.
>
> GAP2-2:The mobile node needs to simultaneously use multiple IP
> addresses with different properties.There is a lack of
> GAP2-3:The handling of mobility management has not been to the
> granularity of an individual session of a user/device
> before.The combination of session identification and user/
> device identification may be lacking.
>
> GAP6-1:Mobility management protocols have not thoroughly documented
> how, or whether, they support the following list of
> operation and management considerations:
>
> *A DMM solution needs to consider configuring a device,
> monitoring the current operational state of a device,
> responding to events that impact the device, possibly by
> modifying the configuration and storing the data in a
> format that can be analyzed later.
>
> *A DMM solution has to describe in what environment and
> how it can be scalably deployed and managed.
>
> *A DMM solution has to support mechanisms to test if the
> DMM solution is working properly.
>
> *A DMM solution is expected to expose the operational
> state of DMM to the administrators of the DMM entities.
>
> *A DMM solution, which supports flow mobility, is also
> expected to support means to correlate the flow routing
> policies and the observed forwarding actions.
>
>
>
> *A DMM solution is expected to support mechanisms to check
> the liveness of the forwarding path.
>
> *A DMM solution has to provide fault management and
> monitoring mechanisms to manage situations where update
> of the mobility session or the data path fails.
>
> *A DMM solution is expected to be able to monitor the
> usage of the DMM protocol.
>
> *DMM solutions have to support standardized configuration
> with NETCONF [RFC6241], using YANG [RFC6020] modules,
> which are expected to be created for DMM when needed for
> such configuration.
>
> GAP6-2:Management information base (MIB) objects are currently
> defined in [RFC4295] for MIPv6 and in [RFC6475] for PMIPv6.
> Standardized configuration with NETCONF [RFC6241], using
> YANG [RFC6020] modules is lacking.
>
>
>
> The entire sentence is rewritten
>
> There is a lack of
> *From:* Elwyn Davies <mailto:[email-masked]>
> *Sent:* Thursday, September 18, 2014 12:00 PM
> *To:* General area reviewing team <mailto:[email-masked]> ;
> [email-masked]
> <mailto:[email-masked]>
> *Subject:* Gen-art LC review of
> draft-ietf-dmm-best-practices-gap-analysis-07
>
> Summary:  Almost ready.  A couple of minor issues (one almost editorial
> and one may be due to my lack of knowledge of the current state of
> Mobile IPv6 security) and mostly a lot of minor language nits.  I think
> there might be some point in numbering the identified gaps to facilitate
> future discussion.
>
> Major issues:
> None
>
> Minor issues:
> Applicability to Mobile IPv4?  It appears from the early sections that
> this draft is pretty much concentrated on Mobile IPv6 (see the first
> para of s3 which mentions v6 RFCs exclusively and IPv4 seems to be
> mentioned in only a very limited way later) although this is not stated.
> To avoid wasting people's time, it would be useful to put a few words
> about the relevance or otherwise of this draft to Mobile IPv4 work in
> the introduction (and maybe the title?) before we get to s5.3 where
> there is more clarity.
>
> s6:  I don't know if there is any extra security risk in adding extra
> MAs etc that might allow a malicious party to offer spurious MA and so
> to redirect traffic inappropriately.  I don't know enough about this
> problem space to know how well this is mitigated already.  Might be
> worth a mention? (maybe would affect s5.8 if so).
>
> Nits/editorial comments:
> s1: For the uninitiated, a explanation of what a mobility anchor is
> would be helpful.  Quoting some (or even all) of the first para of RFC
> 7333 would do the trick nicely.
>
>> Although these two are centralized approaches,
> Two? Three items are mentioned in the previous sentence, but maybe the
> Host approach and Proxy extension is supposed to be considered as a
> single scheme.  Maybe something like:
> s4.2, 2nd para after Figure 1:
>>     IP mobility protocols can be used to provide inter-access mobility
>>     support to users
> I don't know if 'inter-access mobility' is acceptable jargon but I would suggest
> s4.2.1, para 2:
>> Note
>>     that some of these mechanisms [SDO-3GPP.23.402  <http://tools.ietf.org/html/draft-ietf-dmm-best-practices-gap-analysis-07#ref-SDO-3GPP.23.402>] have been defined in
>>     other standards organizations.
> It is not clear what 'some' refers to here:  It could refer to the mechanisms
> the LMA runtime assignment described in [RFC6463  <http://tools.ietf.org/html/rfc6463>]/; s/is mainly aimed for/is mainly aimed at/
>
> s4.3, para before Fig 6:
>> ... or at the macro, ...
> I have no idea what this means.
>
>
>
>>   It only enables the two following functions:
> I am not sure what 'it' refers to here.  Is this the functionality that is needed to implement REQ1? Or what?
>
>> mobility support is required or not in.
> Either the 'in' is redundant or there is a phrase missing at the end.
>
> s5.2, next to last para:

---

From: Jari Arkko <[email-masked]>
Date: Thu, 30 Oct 2014 14:34:33 +0200

Thanks for your review(s) Elwyn! Much appreciated. (Authors, have you seen the remaining nits list below?)

Jari

On 14 Oct 2014, at 22:26, Elwyn Davies <[email-masked]> wrote:

> Hi, Anthony.
> 
> These changes look good.  I have run through all the changes in -08 and there are (IMO) a couple of minor nits left:
> 
>   the Forwarding Management (FM) function resides in both ends of the tunnel
>   the Forwarding Management (FM) function is distributed between the ends of the tunnel
> s4.2, 3rd para after Figure 1: "flattening mobile networks" -- this piece of jargon could do with a definition or at least a pointer to a reference.
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art