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

[<[e-mail]>]

Dear Joel,

Please see inline.

Cheers,
Med 

>-----Message d'origine-----
>De : Joel M. Halpern [mailto:[e-mail]] 
>Envoyé : vendredi 5 octobre 2012 17:52
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : A. Jean Mahoney; [e-mail]; [e-mail]; 
>Yong Cui; [e-mail]
>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, [e-mail] wrote:
>> 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
>>>
>