Re: [Gen-art] [Softwires] Review: draft-ietf-softwire-stateless-4v6-motivation-04

[<[e-mail]>]

Dear Joel,

Thank you for the review. 

Please see inline. 

Cheers,
Med 

>-----Message d'origine-----
>De : [e-mail] 
>[mailto:[e-mail]] De la part de Joel M. Halpern
>Envoyé : vendredi 5 octobre 2012 17:15
>À : A. Jean Mahoney
>Cc : [e-mail]; [e-mail]; Yong Cui; 
>[e-mail]
>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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/softwires
>