Subject: [Gen-art] A *new* batch of IETF LC reviews - 2012-10-04

From: "A. Jean Mahoney" <[email-masked]>
Date: Thu, 04 Oct 2012 17:21:13 -0500

Hi all,

The following reviewers have assignments:

Reviewer          LC end        Draft

Dan Romascanu     2012-10-12    draft-ietf-dnsext-rfc6195bis-04 *

David Black       2012-10-16    draft-ietf-softwire-dslite-deployment-06

Elwyn Davies      2012-10-17    draft-ietf-karp-ospf-analysis-05

Francis Dupont    2012-10-17    draft-ietf-dhc-client-id-06

Joel Halpern      2012-10-17    draft-ietf-softwire-stateless-4v6-motivation-04

Kathleen Moriarty 2012-11-01    draft-gont-intarea-obsolete-eid-option-01

Suresh Krishnan   2012-10-29    draft-ietf-dnsext-rfc2671bis-edns0-09 **

* On the Oct 11 telechat. The LC ends after the telechat ;-)
** 2nd last call

I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

The standard template is included below.

Thanks,

Jean

-------------------------------------------------------------------

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:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 05 Oct 2012 11:14:41 -0400

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:

---

From: <[email-masked]>
Date: Fri, 5 Oct 2012 17:38:04 +0200

Dear Joel,

Thank you for the review. 

Please see inline. 

Cheers,
Med 

>-----Message d'origine-----
>De : [email-masked] 
>[mailto:[email-masked]] De la part de Joel M. Halpern
>Envoyé : vendredi 5 octobre 2012 17:15
>À : A. Jean Mahoney
>Cc : [email-masked]; [email-masked]; Yong Cui; 
>[email-masked]
>Objet : [Softwires] [Gen-art] Review: 
>draft-ietf-softwire-stateless-4v6-motivation-04
>

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"?

>for the reader who, after reading the base list, is looking for more 

Med: Point taken, I will see how to re-order the list to be aligned with the sections/sub-sections ordering.

>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."

>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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/softwires
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 05 Oct 2012 11:52:12 -0400

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

---

From: <[email-masked]>
Date: Mon, 8 Oct 2012 08:13:04 +0200

Dear Joel,

Please see inline.

Cheers,
Med 

>De : Joel M. Halpern [mailto:[email-masked]] 
>Envoyé : vendredi 5 octobre 2012 17:52
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : A. Jean Mahoney; [email-masked]; [email-masked]; 
>Yong Cui; [email-masked]
>Objet : Re: [Softwires] [Gen-art] Review: 

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. 

>such avoidance is highly desirable?

Med: Below a text proposal: 

OLD:

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?

>> Would it be better if I change "not altered in the path" 
>with "not altered in Service Provider's network"?
>>
>>>
>>> Minor issues:
>> Med: Point taken, I will see how to re-order the list to be 
>aligned with the sections/sub-sections ordering.
>>
>>>
>> NEW: "anycast-based schemes can be used for load-balancing 
>and redundancy purposes between nodes embedding the Stateless 
>IPv4/IPv6 interconnection function."
>>
>>
>>>
>> 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: