Re: [Softwires] [Gen-art] Review: draft-ietf-softwire-stateless-4v6-motivation-04
Dear Joel, Please see inline. Cheers, Med -Message d'origine- De : Joel M. Halpern [mailto:j...@joelhalpern.com] Envoyé : vendredi 5 octobre 2012 17:52 À : BOUCADAIR Mohamed OLNC/OLN Cc : A. Jean Mahoney; softwires@ietf.org; gen-...@ietf.org; Yong Cui; draft-ietf-softwire-stateless-4v6-motivat...@tools.ietf.org Objet : Re: [Softwires] [Gen-art] Review: draft-ietf-softwire-stateless-4v6-motivation-04 Thank you for the prompt followup. Taking things out of order, if the Discussion section were called Limitations, I would have understood why it was there. It is not clear to me that the content actually describes limitations though. It describes design choices that need to be made in specifying and deploying statelessv4v6 solutions. Med: The points listed in that section are usually presented as limitations of the solution. If you noticed I said in my first answer limitations(?) because I disagree those points were limitations but rather open questions which depend on the design choices. On the packet preservation description text in section 3.3.2, I am not sure what assumptions the document makes. For good and appropriate reasons, the document does not describe. I believe tat the ability to avoid ALGs is dependent upon more specific choices of solution, beyond merely the stateless property. Would it be acceptable to weaken the statement in the document to one that notes that stateless solutions admit the possibility of solutions which do not require ALGs? And that such avoidance is highly desirable? Med: Below a text proposal: OLD: Facilitates service evolution: Since the payload of IPv4 packets is not altered in the path, services can evolve without requiring any specific function (e.g., Application Level Gateway (ALG)) in the Service Provider's network; NEW: Facilitates service evolution: Stateless solutions admit applications can be deployed without enabling any application- specific function (e.g., Application Level Gateway (ALG)) in the Service Provider's network. Avoiding ALGs is highly desirable. Better? Yours, Joel On 10/5/2012 11:38 AM, mohamed.boucad...@orange.com wrote: Dear Joel, Thank you for the review. Please see inline. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Joel M. Halpern Envoyé : vendredi 5 octobre 2012 17:15 À : A. Jean Mahoney Cc : softwires@ietf.org; gen-...@ietf.org; Yong Cui; draft-ietf-softwire-stateless-4v6-motivat...@tools.ietf.org Objet : [Softwires] [Gen-art] Review: draft-ietf-softwire-stateless-4v6-motivation-04 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-stateless-4v6-motivation-04 Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions Reviewer: Joel M. Halpern Review Date: 5-Oct-2012 IETF LC End Date: 17-Oct-2012 IESG Telechat date: 25-Oct-2012 Summary: This document is nearly ready for publication as an Informational RFC. Major issues: I may be misreading the first sub-paragraph in section 3.3.2. It seems to assert that no ALGs are necessary with stateless 4v6 solution as the payload of IPv4 packets is not altered in the path. This seems to make very strong assumptions on the end host behavior, which are not called out in the document. Med: I guess you are referring to this text: Facilitates service evolution: Since the payload of IPv4 packets is not altered in the path, services can evolve without requiring any specific function (e.g., Application Level Gateway (ALG)) in the Service Provider's network; The host behaviour is the same as for deployments where no NAT is enabled in the SP's network. Could you please clarify what is the issue with that text? Would it be better if I change not altered in the path with not altered in Service Provider's network? Minor issues: It is unfortunate that the elaborations on the motivations do not correlate with the initial list of those motivations. They are not in the same order, and do not use the same titles. This makes it harder for the reader who, after reading the base list, is looking for more explanation of item(i). Med: Point taken, I will see how to re-order the list to be aligned with the sections/sub-sections ordering. The description of the anycast capability (Section 3 bullet 5 and section 3.2.1 first bullet) is very unclear. Since packets are not addressed to the address translator, this reader is left confused as to what anycast capability is preserved by this and damaged by stateful NAT. A few additional words in section 3.2.1 would be helpful. Med
[Softwires] [Gen-art] Review: draft-ietf-softwire-stateless-4v6-motivation-04
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-stateless-4v6-motivation-04 Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions Reviewer: Joel M. Halpern Review Date: 5-Oct-2012 IETF LC End Date: 17-Oct-2012 IESG Telechat date: 25-Oct-2012 Summary: This document is nearly ready for publication as an Informational RFC. Major issues: I may be misreading the first sub-paragraph in section 3.3.2. It seems to assert that no ALGs are necessary with stateless 4v6 solution as the payload of IPv4 packets is not altered in the path. This seems to make very strong assumptions on the end host behavior, which are not called out in the document. Minor issues: It is unfortunate that the elaborations on the motivations do not correlate with the initial list of those motivations. They are not in the same order, and do not use the same titles. This makes it harder for the reader who, after reading the base list, is looking for more explanation of item(i). The description of the anycast capability (Section 3 bullet 5 and section 3.2.1 first bullet) is very unclear. Since packets are not addressed to the address translator, this reader is left confused as to what anycast capability is preserved by this and damaged by stateful NAT. A few additional words in section 3.2.1 would be helpful. The issues raised in section 4 of the document (Discussion) are interesting. But they do not seem related to the motivation for seeking a stateless v4v6 solution. They seem to be details of how such a solution might be built. Why is this section in this document? Nits/editorial comments: ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [Gen-art] Review: draft-ietf-softwire-stateless-4v6-motivation-04
Dear Joel, Thank you for the review. Please see inline. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Joel M. Halpern Envoyé : vendredi 5 octobre 2012 17:15 À : A. Jean Mahoney Cc : softwires@ietf.org; gen-...@ietf.org; Yong Cui; draft-ietf-softwire-stateless-4v6-motivat...@tools.ietf.org Objet : [Softwires] [Gen-art] Review: draft-ietf-softwire-stateless-4v6-motivation-04 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-stateless-4v6-motivation-04 Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions Reviewer: Joel M. Halpern Review Date: 5-Oct-2012 IETF LC End Date: 17-Oct-2012 IESG Telechat date: 25-Oct-2012 Summary: This document is nearly ready for publication as an Informational RFC. Major issues: I may be misreading the first sub-paragraph in section 3.3.2. It seems to assert that no ALGs are necessary with stateless 4v6 solution as the payload of IPv4 packets is not altered in the path. This seems to make very strong assumptions on the end host behavior, which are not called out in the document. Med: I guess you are referring to this text: Facilitates service evolution: Since the payload of IPv4 packets is not altered in the path, services can evolve without requiring any specific function (e.g., Application Level Gateway (ALG)) in the Service Provider's network; The host behaviour is the same as for deployments where no NAT is enabled in the SP's network. Could you please clarify what is the issue with that text? Would it be better if I change not altered in the path with not altered in Service Provider's network? Minor issues: It is unfortunate that the elaborations on the motivations do not correlate with the initial list of those motivations. They are not in the same order, and do not use the same titles. This makes it harder for the reader who, after reading the base list, is looking for more explanation of item(i). Med: Point taken, I will see how to re-order the list to be aligned with the sections/sub-sections ordering. The description of the anycast capability (Section 3 bullet 5 and section 3.2.1 first bullet) is very unclear. Since packets are not addressed to the address translator, this reader is left confused as to what anycast capability is preserved by this and damaged by stateful NAT. A few additional words in section 3.2.1 would be helpful. Med: What about this change? OLD: anycast-based schemes can be used for load-balancing and redundancy purposes. NEW: anycast-based schemes can be used for load-balancing and redundancy purposes between nodes embedding the Stateless IPv4/IPv6 interconnection function. The issues raised in section 4 of the document (Discussion) are interesting. But they do not seem related to the motivation for seeking a stateless v4v6 solution. They seem to be details of how such a solution might be built. Why is this section in this document? Med: We added this section because we received comments asking for having a section listing the main limitations(?) stateless solutions. It was a fair comment. Nits/editorial comments: ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] [Gen-art] Review: draft-ietf-softwire-stateless-4v6-motivation-04
Thank you for the prompt followup. Taking things out of order, if the Discussion section were called Limitations, I would have understood why it was there. It is not clear to me that the content actually describes limitations though. It describes design choices that need to be made in specifying and deploying statelessv4v6 solutions. On the packet preservation description text in section 3.3.2, I am not sure what assumptions the document makes. For good and appropriate reasons, the document does not describe. I believe tat the ability to avoid ALGs is dependent upon more specific choices of solution, beyond merely the stateless property. Would it be acceptable to weaken the statement in the document to one that notes that stateless solutions admit the possibility of solutions which do not require ALGs? And that such avoidance is highly desirable? Yours, Joel On 10/5/2012 11:38 AM, mohamed.boucad...@orange.com wrote: Dear Joel, Thank you for the review. Please see inline. Cheers, Med -Message d'origine- De : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la part de Joel M. Halpern Envoyé : vendredi 5 octobre 2012 17:15 À : A. Jean Mahoney Cc : softwires@ietf.org; gen-...@ietf.org; Yong Cui; draft-ietf-softwire-stateless-4v6-motivat...@tools.ietf.org Objet : [Softwires] [Gen-art] Review: draft-ietf-softwire-stateless-4v6-motivation-04 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-stateless-4v6-motivation-04 Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions Reviewer: Joel M. Halpern Review Date: 5-Oct-2012 IETF LC End Date: 17-Oct-2012 IESG Telechat date: 25-Oct-2012 Summary: This document is nearly ready for publication as an Informational RFC. Major issues: I may be misreading the first sub-paragraph in section 3.3.2. It seems to assert that no ALGs are necessary with stateless 4v6 solution as the payload of IPv4 packets is not altered in the path. This seems to make very strong assumptions on the end host behavior, which are not called out in the document. Med: I guess you are referring to this text: Facilitates service evolution: Since the payload of IPv4 packets is not altered in the path, services can evolve without requiring any specific function (e.g., Application Level Gateway (ALG)) in the Service Provider's network; The host behaviour is the same as for deployments where no NAT is enabled in the SP's network. Could you please clarify what is the issue with that text? Would it be better if I change not altered in the path with not altered in Service Provider's network? Minor issues: It is unfortunate that the elaborations on the motivations do not correlate with the initial list of those motivations. They are not in the same order, and do not use the same titles. This makes it harder for the reader who, after reading the base list, is looking for more explanation of item(i). Med: Point taken, I will see how to re-order the list to be aligned with the sections/sub-sections ordering. The description of the anycast capability (Section 3 bullet 5 and section 3.2.1 first bullet) is very unclear. Since packets are not addressed to the address translator, this reader is left confused as to what anycast capability is preserved by this and damaged by stateful NAT. A few additional words in section 3.2.1 would be helpful. Med: What about this change? OLD: anycast-based schemes can be used for load-balancing and redundancy purposes. NEW: anycast-based schemes can be used for load-balancing and redundancy purposes between nodes embedding the Stateless IPv4/IPv6 interconnection function. The issues raised in section 4 of the document (Discussion) are interesting. But they do not seem related to the motivation for seeking a stateless v4v6 solution. They seem to be details of how such a solution might be built. Why is this section in this document? Med: We added this section because we received comments asking for having a section listing the main limitations(?) stateless solutions. It was a fair comment. Nits/editorial comments: ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
