Document: draft-xli-behave-ivi-05.txt
Reviewer: Elwyn Davies
Review Date: 4 January 2010
IETF LC End Date: 1 January 2010
IESG Telechat date: 7 January 2010

Summary: Generally this is nearly ready for informational status.  There are 
a number of minor issues that could do with some improvement of explanation as 
described below. It also needs a fair bit of attention from somebody whose 
mother tongue is English.  I have sent a file to the authors with lots 
of suggestions for this work.

Major issues: -

Minor issues:

s1.1, numbered item 4:
>
> A partial remedy to this is the proper attention to the details of the 
> protocol translation.
>
I think this needs more explanation.  I don't fully understand what is meant 
by this.

s1.1, numbered item 5:
>
> lack of address mapping persistence.
>
This needs a little more explanation (a pointer to the releant part of the 
NAT-PT deprecation draft would probably be adequate).

s3.2, numbered item 3:  The implication of this item is that the translator 
is also a router.  It would be a good idea to write a short paragraph about 
the hardware form of the translator.  The diagrams appear to describe a 
'two arm device' with an IPv4 interface and an IPv6 interface.  It doesn't 
really need routing capabilities although clearly it could be implemented as 
part of any machine that can access both networks (possibly on the same 
link if it can carry both IPv4 and IPv6). It probably overkill to use 
dynamic routing protocols to set up the links in most cases.

s5.1 and s9: Do the multicast group addresses need to be allocated by IANA?

s8. last paragraph:
>    In addition, the specific security issues for the IVI translator
>    implementation should be further studied and addressed during the
>    development of the IVI mechanisms.
>   
Given that IVI has been deployed and this document is now informational, this 
paragraph does not seem appropriate.  It needs to say what matters ahve 
arisen during the documented deployment.

Nits/editorial comments:

Figure 6:  need to expand IHL acronym

s6.1:  This should use official example IPv4 addresses (RFC 3330) - taken 
from 192.0.2.0/24 and example IP6 addresses from RFC 5156 (2001:DB8::) - 
Note s3.1 and s3.2 already use these addresses.

s8: need to expand uRPF acronym.

ss12, 13 and 14 (Appendices): These sections should use official example 
addresses (see note on s6.1).  (It might be possible to leave the 
example traces, but s12 MUST be example numbers.)

References:  Is it intended to maintain the IVI4 and IVI6 test homepages 
using numeric addresses?  Would it be possible to define a DNS name that 
maps to these addresses so that if they ever get changed the homepages could 
still work?