Hi Dirk,

Thanks a lot for the feedback. Please see inline below.

On Wed, 2018-03-07 at 12:54 +0000, [email protected] wrote:
> Dear Carlos and co-authors, all,
> thanks for the improvements!
> I think the draft is quite well written and provides a good approach
> to real distribution of functionalities in DMM. What might be made
> clearer is the difference between partially and fully DMM you have
> introduced.
> See also as mentioned below in the list of detected nits:
> 
> Figs. 2 - 4: exhibiting ? instead of ' on Data packet Flow part ...

OK, fixed in -02.

> 
> p. 5: Home-CPA [I assume it means the same as H-CPA defined in ch. 2:
> I suggest to use one acronym only].

Agre, fixed.

> PMIPv6 DMM extenstions => PMIPv6 DMM extensions
> the entities that participates => the entities that participate
> p. 8: Also, the CMD send a PBA => Also, the CMD sends a PBA
> p.10: This procedure reflect => This procedure reflects
> address OS taken  => address is taken [??]

Thanks, all fixed.

> p.12: Partial DMM architecture - I wonder whether this should be
> introduced as new term in ch. 2 e.g.

Thanks, we have rewritten it a bit.

> 
> Partial DMM architecture. DMM architecture based on PMIP where MAGs
> and LMAs are distributed in Data Plane but Control Plane of LMA is
> centralized in CMD [if I understood correctly]
> Further more when fully DMM solutions are mentioned (later) - is that
> the (only) difference? Should one describe that in more detail?

We have rewritten the text to avoid the use of "Partial DMM".

>  
> of the mobile selecting       => of the mobile node selecting

Fixed.

> p.13: HSS [why not using 3GPP-independent term CMD here?] - same on 

When used as an example, I prefer to keep it. 

> p.15 ...
> p.15: mn1dgw2/mn1dgw1 [not used in Fig.6, shouldn't it say
> mn1mar2/mn1mar1 instead?]

Fixed.

> the serving MAAR (MAAR1) => the serving MAAR (MAAR2) [right? Since
> MAAR2 is the actual S-MAAR of MN1 in Fig. 6]

Right, fixed.

> consider by 3GPP => considered by 3GPP
> p.20: This field MUST be set to 34.=> This field MUST be set to
> 33.[according to format above unless an 8-bit Reserved field is
> included as in other formats ...]
> p.23: on the serving distributed gateway => on the S-MAAR [another
> left-over by previous version ...] 
> p.25: we describe =>  we describe
> p.27: ot the operators => of the operators

All fixed.

> both solution apply the same signalling scheme => meaning full and
> partial or rather operation of the solution in both (of mentioned
> multiple) domains here?

Meaning the solution in both domains. We have clarified it.

> p.28: then stop the BCE => then stops the BCE
> p.30: mobile edge computing (MEC) =>  multi-access edge computing
> (MEC) [as defined by ETSI which is explicitly mentioned!]
> edge ir the => edge or the [edge near the?]

All fixed.

Thanks a lot!

Carlos

> 
> Thanks and best regards
> Dirk
> -----Original Message-----
> From: dmm [mailto:[email protected]] On Behalf Of Carlos Jesús
> Bernardos Cano
> Sent: Dienstag, 6. März 2018 23:18
> To: [email protected]
> Subject: [DMM] [Fwd: I-D Action: draft-bernardos-dmm-pmipv6-dlif-
> 01.txt]
> 
> Hi,
> 
> We have submitted a revised version of our draft addressing the
> comments we got in Singapore:
> 
> - Added some statements about which model from draft-ietf-dmm-
> deployment-models our solution follows (addressing a comment received
> from Sri).
> - Added some text relating to draft-ietf-dmm-ondemand-mobility
> (addressing a comment received from Danny).
> 
> Additionally, we added some terminology from draft-ietf-dmm-
> deployment- models and other minor changes.
> 
> In Singapore we got quite good support of the document. I'd like to
> request feedback/reviews from the WG.
> 
> Thanks!
> 
> Carlos

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

Reply via email to