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.boucadair@orange.com wrote:
> Dear Joel,
>
> Thank you for the review.
>
> Please see inline.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : softwires-bounces@ietf.org
>> [mailto:softwires-bounces@ietf.org] De la part de Joel M. Halpern
>> Envoyé : vendredi 5 octobre 2012 17:15
>> À : A. Jean Mahoney
>> Cc : softwires@ietf.org; gen-art@ietf.org; Yong Cui;
>> draft-ietf-softwire-stateless-4v6-motivation@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
>>