Skip to main content

Last Call Review of draft-ietf-v6ops-siit-eam-01
review-ietf-v6ops-siit-eam-01-genart-lc-romascanu-2015-09-20-00

Request Review of draft-ietf-v6ops-siit-eam
Requested revision No specific revision (document currently at 03)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-09-22
Requested 2015-09-11
Authors Tore Anderson , Alberto Leiva
Draft last updated 2015-09-20
Completed reviews Genart Last Call review of -01 by Dan Romascanu (diff)
Genart Telechat review of -01 by Dan Romascanu (diff)
Secdir Last Call review of -01 by Phillip Hallam-Baker (diff)
Opsdir Last Call review of -01 by Ron Bonica (diff)
Assignment Reviewer Dan Romascanu
State Completed
Review review-ietf-v6ops-siit-eam-01-genart-lc-romascanu-2015-09-20
Reviewed revision 01 (document currently at 03)
Result Ready with Nits
Completed 2015-09-20
review-ietf-v6ops-siit-eam-01-genart-lc-romascanu-2015-09-20-00

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