Last Call Review of draft-ietf-dmm-best-practices-gap-analysis-07
review-ietf-dmm-best-practices-gap-analysis-07-genart-lc-davies-2014-10-21-00

Request Review of draft-ietf-dmm-best-practices-gap-analysis
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-10-28
Requested 2014-09-11
Authors Dapeng Liu, Juan-Carlos Zúñiga, Pierrick Seite, Anthony Chan, Carlos Bernardos
Draft last updated 2014-10-21
Completed reviews Genart Last Call review of -07 by Elwyn Davies (diff)
Genart Telechat review of -08 by Elwyn Davies (diff)
Assignment Reviewer Elwyn Davies 
State Completed
Review review-ietf-dmm-best-practices-gap-analysis-07-genart-lc-davies-2014-10-21
Reviewed rev. 07 (document currently at 09)
Review result Almost Ready
Review completed: 2014-10-21

Review
review-ietf-dmm-best-practices-gap-analysis-07-genart-lc-davies-2014-10-21

  
  
    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

] 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/