[Gen-art] Gen-ART review of draft-ietf-v6ops-siit-eam-01

["Romascanu, Dan (Dan)" <[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.



For more information, please see the FAQ at



http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq



Document: draft-ietf-v6ops-siit-eam-01

Reviewer: Dan Romascanu

Review Date: 9/20/15

IETF LC End Date: 9/22/15

IESG Telechat date: (if known)



Summary:



This is very well written document. I liked the problem statement and the examples which were very useful for the easy understanding of the problem and of the solution. There are a few minor issues that may be just nits or easy editorial issues. I suggest these to be discussed between the authors and the RFC Editor before the document is published.



Major issues:



Minor issues:



Nits/editorial comments:



1.       In the second paragraph of the Introduction I suggest s/The Explicit Address Mapping Table does not replace/Translation using the Explicit Address Mapping Table does not replace/

2.       In section 2 I would suggest s/doing so may result in a new set of undesired properties/doing so may result in a new set of undesired consequences/

3.       Section 3.2:

   When translating a packet between IPv4 and IPv6, an SIIT
   implementation MUST individually translate each IP address it
   encounters in the packet's IP headers (including any IP headers
   contained within ICMP errors) according to Section 3.3.  See
   Section 4 for certain exceptions to this rule.



       As we are talking about exceptions to the rule, is not SHOULD more appropriate than MUST?



4.       Sections 4.2.1 and 4.2.2 present two alternative approaches for hairpinning support. Yet, the opening sentence in 4.2.1. a keyworded MUST, while the opening sentence in 4.2.2. does not:



   When the simple hairpinning feature is enabled, the translator MUST

   behave according to the following rules when translating from IPv4 to

   IPv6:



   When the intrinsic hairpinning feature is enabled, the translator

   behaves as follows when receiving an IPv6 packet:



   It seems that either MUST is to be used in both, either in none.





Regards,



Dan