Thanks David! I will apply your changes to the next version. On 10/17/12 9:11 PM, "Black, David" <david.bl...@emc.com> wrote:
>Yiu, > >Thank you for your responses - most of them look fine, and in >particular anything that I don't comment on here is acceptable to me. > >> [YL] In 2.2, we will add: >> >> "Note that reassembly at Tunnel Exit-Point is resource >> intensive. A large number of B4 may terminate on the same AFTR. If >>many B4 >> fragment the packets, it would increase sufficient load to the AFTR for >> reassembly. We recommend the operator should increase the MTU size of >>the IPv6 >> network between B4 and AFTR to avoid fragmentation." > >I would change "is" to "may be" in the first line. > >> >[5] Section 2.8 discusses IPv4 accounting at the AFTR, but notes that >> >"the AFTR does not have detailed customer identity information." Does >> >that create a theft of service possibility? If so, that possibility >> >should be mentioned as a security consideration. Also, Section 2.8 >> >ought to be expanded with a sentence or two explaining why the AFTR >> >does not have that identity information, and in particular to explain >> >whether and why it is unreasonable in some or all cases to expect >> >that customer identity information be provided to the AFTR as part >> >of provisioning each customer's softwire. >> >> [YL] Good catch. Actually I believe AFTR "does" have both IPv4 and IPv6 >>to >> identify the customer. I suggest we remove >> >> "but it will potentially introduce some additional complexity because >> the AFTR does not have detailed customer identity information." > >That's definitely an easy way to address that issue, and it's fine with >me. > >> >Section 2.3 on MTU Considerations could usefully mention MTU discovery >> >techniques, as possibilities for customer IPv4 traffic to adapt to a >> >smaller IPv4 MTU. If this is done, it would be useful to mention >> >RFC 4821 in addition to the mention of RFC 1191 in RFC 6333. >> >> [YL] We would consider RFC 4821. However, the challenge is I don't have >> information how many current OS support RFC 4821. Since DS-lite is a >> transition technology, it would be unreasonable to ask the OS company to >> implement RFC 4821 for DS-lite. > >That's ok - this was a nit. > >> >- Are one or both types of logging recommended? >> >> [YL] We tempted to recommend source-specific log. However, some >>regulators >> require to use both and the regulations vary country from country, this >>is >> why we left it open and let the operators to decide. > >Please add a version of your explanation to the draft. > >> >In Section 2.7, I'm having a hard time understanding which traffic is >> >intended to be subject to the Outgoing Policies and the Incoming >>Policies. >> >Expanding each of those two bullets to explain what traffic is subject >> >to each class of policies would help. >> >> [YL] Does this help? >> >> Outgoing Policies apply to packets originating from B4 to IPv4 network. >> Incoming Policies apply to packets originating from IPv4 network to B4. > >Yes, that's clearer, although the B4 is not the network endpoint for any >of that traffic. I suggest: > >Outgoing Policies apply to packets originating from behind the B4 with >a destination on the IPv4 network. > >Incoming Policies apply to packets originating from the IPv4 network to >a destination behind the B4. > >Thanks, >--David > > >> -----Original Message----- >> From: Lee, Yiu [mailto:yiu_...@cable.comcast.com] >> Sent: Wednesday, October 17, 2012 8:46 PM >> To: Black, David; roberta.magli...@telecomitalia.it; >>ca...@mcsr-labs.org; >> christian.jacque...@orange.com; mohamed.boucad...@orange.com; >>gen-...@ietf.org >> Cc: softwires@ietf.org; i...@ietf.org; Ralph Droms >> Subject: Re: Gen-ART review of draft-ietf-softwire-dslite-deployment-06 >> >> Hi David, >> >> Thanks very much for review the draft. Comments inline. >> >> Thanks, >> Yiu >> >> On 10/15/12 7:10 PM, "Black, David" <david.bl...@emc.com> wrote: >> >> >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-softwire-dslite-deployment-06 >> >Reviewer: David L. Black >> >Review Date: October 15, 2012 >> >IETF LC End Date: October 16, 2012 >> >IESG Telechat Date: October 25, 2012 >> > >> >Summary: >> > >> >This draft is on the right track but has open issues, described in the >> >review. >> > >> >This is a generally well-written draft that expands considerably on >>the brief >> >deployment considerations for DS-Lite in Appendix A of RFC 6333. The >>draft >> >is clear and reasonably well-written, and a significant improvement on >>that >> >RFC 6333 Appendix, although an understanding of RFC 6333 is necessary >>to >> >understand this draft, which seems completely reasonable. >> > >> >The B4 and AFTR acronyms are clever - kudos to whomever came up with >> >those. >> > >> >I found five open issues, all of which are minor. >> > >> >Minor Issues: >> > >> >[1] Ironically, the first issue is that something should be said about >> >the relationship of this draft to Appendix A of RFC 6333. It probably >> >suffices to say that this draft expands on the material in that >>Appendix, >> >as I see no need to specify that this draft updates RFC 6333 solely to >> >change non-normative material in an Appendix. >> >> [YL] In "Overview", we will add: >> >> "This document expands Appendix A of RFC6333 and discusses various >> DS-Lite deployment considerations for operators." >> >> > >> >[2] The MTU increase technique in Section 2.2 is a "may", which is >> >consistent with Section 5.3 of RFC 6333. OTOH, Section 2.2 of this >> >draft should also discuss the AFTR resource exhaustion concern that >> >described in Section 6.3 of RFC 6333, as that is a potential >> >operational reason for an ISP to increase MTU size (e.g., if customer >> >sourcing of large IPv4 packets is not sufficiently rare). >> >> [YL] In 2.2, we will add: >> >> "Note that reassembly at Tunnel Exit-Point is resource >> intensive. A large number of B4 may terminate on the same AFTR. If >>many B4 >> fragment the packets, it would increase sufficient load to the AFTR for >> reassembly. We recommend the operator should increase the MTU size of >>the IPv6 >> network between B4 and AFTR to avoid fragmentation." >> >> > >> >[3] Section 2.7 refers to "the AFTR's internal interface". There may >>be >> >two internal interfaces, the physical IPv6 interface (outer header) and >> >the tunnel's IPv4 interface (inner header). The text should be >>clarified >> >to indicate which interface is involved - it appears that the AFTR's >> >physical IPv6 interface is intended in this section. >> >> [YL] We replace "internal" to "IPv6" >> >> > >> >[4] Section 2.7 cites RFC 6333 for use of DHCPv6 with DS-Lite. RFC >>6334 >> >should be cited - either in addition to or instead of RFC 6333. >> >> [YL] Fixed >> >> > >> >[5] Section 2.8 discusses IPv4 accounting at the AFTR, but notes that >> >"the AFTR does not have detailed customer identity information." Does >> >that create a theft of service possibility? If so, that possibility >> >should be mentioned as a security consideration. Also, Section 2.8 >> >ought to be expanded with a sentence or two explaining why the AFTR >> >does not have that identity information, and in particular to explain >> >whether and why it is unreasonable in some or all cases to expect >> >that customer identity information be provided to the AFTR as part >> >of provisioning each customer's softwire. >> >> [YL] Good catch. Actually I believe AFTR "does" have both IPv4 and IPv6 >>to >> identify the customer. I suggest we remove >> >> "but it will potentially introduce some additional complexity because >> the AFTR does not have detailed customer identity information." >> >> > >> >Nits: >> > >> >Section 2.3 on MTU Considerations could usefully mention MTU discovery >> >techniques, as possibilities for customer IPv4 traffic to adapt to a >> >smaller IPv4 MTU. If this is done, it would be useful to mention >> >RFC 4821 in addition to the mention of RFC 1191 in RFC 6333. >> >> [YL] We would consider RFC 4821. However, the challenge is I don't have >> information how many current OS support RFC 4821. Since DS-lite is a >> transition technology, it would be unreasonable to ask the OS company to >> implement RFC 4821 for DS-lite. >> >> > >> >Section 2.4 should define "lawful intercept". It would be helpful to >> >cite a reference for this concept if something appropriate can be >>found. >> >> [YL] We will find whether there is any reference to this concept. If we >> can't find any, we would add an explanation in the draft. >> >> > >> >Section 2.5: >> >- Are one or both types of logging recommended? >> >> [YL] We tempted to recommend source-specific log. However, some >>regulators >> require to use both and the regulations vary country from country, this >>is >> why we left it open and let the operators to decide. >> >> >- Last paragraph on p.4, "timestamped log" is not a good verb phrase. >> > "maintain a timestamped log of" would be a better replacement. >> >> [YL] Fixed >> >> >- Last paragraph in section, where is the batch file sent? >> >> [YL] We will add: >> >> "The files may be compressed before transferring to a repository server >> to better utilize bandwidth and storage." >> >> >> > >> >In Section 2.7, I'm having a hard time understanding which traffic is >> >intended to be subject to the Outgoing Policies and the Incoming >>Policies. >> >Expanding each of those two bullets to explain what traffic is subject >> >to each class of policies would help. >> >> [YL] Does this help? >> >> Outgoing Policies apply to packets originating from B4 to IPv4 network. >> Incoming Policies apply to packets originating from IPv4 network to B4. >> >> >> >> > >> >Section 3.2.2.2 uses 192.0.0.2/32 as an example IP address for the >> >B4. That section should also cross-reference Section 5.7 on RFC 6333 >> >on IP address assignment to B4s, as other IP addresses may be used. >> >> [YL] Added the cite. >> >> > >> >idnits 2.12.13 found a tiny nit - draft-ietf-pcp-base is now at >> >version 28. >> >> [YL] Fixed. >> >> > >> >Thanks, >> >--David >> >---------------------------------------------------- >> >David L. Black, Distinguished Engineer >> >EMC Corporation, 176 South St., Hopkinton, MA 01748 >> >+1 (508) 293-7953 FAX: +1 (508) 293-7786 >> >david.bl...@emc.com Mobile: +1 (978) 394-7754 >> >---------------------------------------------------- >> > >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
