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