Hi, Elwyn,
Thank you very much for your review, the comments and corrections. We
will make the corrections and try to upload the new version tomorrow.
Elwyn Davies 写道:
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
_http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html_).
Please resolve these comments along with any other Last Call comments
you may receive. It appears that this document has now been scheduled
for this week's IESG meeting also. Sorry for the slightly late last
call review. Too much holidaying I fear!
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.
Thank you very much for your kind help.
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.
The updated drafts reads:
4. Loss of information due to incompatible semantics between the IPv4
and IPv6 versions of headers and protocols. A partial remedy to
this is the proper attention to the details of the protocol
translation, for example the error codes mapping between ICMP and ICMPv6.
However, some semantic differences remain.
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).
lack of address mapping persistence discussed in Section 3.3 of [RFC4966].
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.
The new draft reads:
The IVI XLATE is a special dual-stack router, with two interfaces, one
to the IPv4 network and the other to the IPv6 network (it is also
possible to have a single interface configured with both IPv4 and IPv6
addresses). The IVI XLATE can support dynamic routing protocols in IPv4
and IPv6 address families, but in the above configuration, the static
routing configuration can be used.
s5.1 and s9: Do the multicast group addresses need to be allocated by
IANA?
No. We are using the normal IPv4 SSM group addresses (233.0.0.0/8) and
IPv6 SSM group addresses (ff3e:0:0:0:0:0:f000:0000/96).
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.
The modified draft reads:
Except the issues discussed above, we have not find special security
issues introduced by the IVI translation in our experiments.
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?
Agree. We will make the corrections.
Thank you very much!
Regards,
xing, congxiao
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
