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 protected]> 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: > > 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: >> 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 users >> I 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 >> >> changed 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 >>> <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 >> 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 deleted >> >> 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. >> >> Figure 2 is redrawn >> >> s4.2.1, para after bullets: Please expand acronym CoA on first use. >> >> Corrected >> >> s4.2.1, para before Fig 3: s/It allows reducing the amount/It allows the >> reduction of the amount/ >> >> Corrected >> >> Figure 4: Oh, dear! Boring old 'xxx' for tunnels. :-( But I guess it should >> have a key again. >> >> Figure 4 is redrawn >> >> s4.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 >> <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" >> >> 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/ >> >> corrected >> >> 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. >> >> added as suggested >> >> s5.8, para 1: s/to enable multicast solutions to be developed/to allow the >> development of multicast solutions/ >> >> corrected >> >> s5.8, para 2: s/insta ces/instances/ >> >> corrected >> >> >> >> 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 >> 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./ >> >> corrected >> >> s5.9, bullet 2: s/requires to expose/requires the exposure of/ >> >> The entire sentence is rewritten >> >> There 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/ >> >> corrected >> >> s6: 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 <mailto:[email protected]> >> *Sent:* Thursday, September 18, 2014 12:00 PM >> *To:* General area reviewing team <mailto:[email protected]> ; >> [email protected] >> <mailto:[email protected]> >> *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 users >> I 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 >>> <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 >> 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 >> <http://tools.ietf.org/html/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/ >> >> >> >> >> >> > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
