Dear Yoshi, We've just posted a new revision (-14) addressing all your comments.
Thanks! Carlos On Thu, Oct 24, 2019 at 9:38 AM Yoshifumi Nishida <[email protected]> wrote: > Hi Carlos, > Thanks for the response. I put my comments in lines. > > On Fri, Oct 18, 2019 at 4:20 AM CARLOS JESUS BERNARDOS CANO < > [email protected]> wrote: > >> Dear Yoshifumi, >> >> Thanks a lot for the review. Please check inline below for some comments >> from my side. >> >> On Mon, Oct 14, 2019 at 9:57 AM Yoshifumi Nishida via Datatracker < >> [email protected]> wrote: >> >>> Reviewer: Yoshifumi Nishida >>> Review result: Almost Ready >>> >>> This document has been reviewed as part of the transport area review >>> team's >>> ongoing effort to review key IETF documents. These comments were written >>> primarily for the transport area directors, but are copied to the >>> document's >>> authors and WG to allow them to address any issues raised and also to >>> the IETF >>> discussion list for information. >>> >>> When done at the time of IETF Last Call, the authors should consider this >>> review as part of the last-call comments they receive. Please always CC >>> [email protected] if you reply to or forward this review. >>> >>> Summary: This document is almost ready for publication as an >>> informational RFC, >>> but it will be better to clarify the following points. >>> >>> 1: The examples shown in the draft look behave conveniently. >>> For examples, in the figure 3 case, the flow is somehow terminated >>> before >>> the MN moves and is re-initiated after the movement has finished. >>> However, I >>> believe there should be the cases where applications don't aware of >>> network >>> changes and transmit data while migrating, which may cause packet >>> drops, >>> delays and timeouts, etc. I think this draft should clarify the >>> treatments >>> of these cases. Is it out of scope of the draft? Or, do some >>> components >>> generate ICMP messages to give some hints to the applications, or >>> provide >>> buffering features to mitigate the side effects? >>> >> >> [Carlos] I guess you mean Figure 4, right? In that figure, we try to >> explain what would happen if there is no actual mobility support, meaning >> that a communication flow does not need such mobility support. This might >> happen because the flow stops before the movement (as shown in the figure) >> or also because the application can deal with the mobility itself (no >> mobility at the IP layer). We don't explicitly mention that second case >> because it is not in the scope of the draft (IP mobility). We can better >> clarify the scope in the text. >> > > Sorry for confusion. Yes, the data flow is explained in Figure 4. > What I wanted to mention was how the flow can stop it without mobility > support. If there's no mobility support, the app should not be able to know > when network change will happen. So, I am thinking that in some cases, the > flow may not able to stop before the movement. > I am guessing this case would be a major case than the case described in > the draft. > Or, is there any available approach here? > >> >> >>> >>> 2: Page 8: >>> "A MN will need to choose which IP prefix/address to use for each flow >>> according to whether it needs IP mobility support or not." >>> >>> -> It seems to me that the draft implicitly suggests the use of >>> draft-ietf-dmm-ondemand-mobility here. >>> If so, I think it would be better to state more explicitly. Or, >>> do we >>> have other options? >>> >> >> [Carlos] We can definitely add an explicit reference to >> draft-ietf-dmm-ondemand-mobility, but I'd mention it as an example. I don't >> have another option in mind, but we can leave it open. >> > > Yes, referring as an example is fine. I just thought if this approach can > be used, then it might be better to explain it explicitly. > >> >> >>> 3: Page 10: >>> "the initial anchor remains the anchor and forwards traffic" >>> >>> -> could be "anchor remains and the anchor.."? >>> >> >> [Carlos] Maybe "mobility anchor remains playing that role and forwards >> traffic"? >> > > Works for me. Thanks! > -- > Yoshi > -- Special Issue "Beyond 5G Evolution": https://www.mdpi.com/journal/electronics/special_issues/beyond_5g
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
