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; softwi...@ietf.org; gen-art@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 : softwi...@ietf.org; gen-art@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 >>> softwi...@ietf.org >>> https://www.ietf.org/mailman/listinfo/softwires >>> > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
