Hi, Elwyn,
Thank you very much.
Elwyn Davies 写道:
Hi.
Version 07 addresses essentially all my previous comments - thanks for
the quick work!
I noticed a couple of remaining wording issues but these are trivial
editorial nits and will be taken care of during the RFC Editor process.
With the short notice, it was clearly infeasible to address the
suggestion of finding a DNS name to point at the IVI homepages instead
of the numeric addresses currently in the references [TEST4] and
[TEST6] in order to (hopefully) provide longer term stability. It
might be worth investigating if this can be addressed (sic) during the
publication process.
yes, we have added the names test4.ivi4.org and test6.ivi2.org for
[TEST4] and [TEST6], respective, thanks for the suggestions.
regards,
xing
Regards,
Elwyn
Xing Li wrote:
Hi, Jari,
Jari Arkko 写道:
If you have a possibility to update the draft based on Elwyn's
comments, please do so. I know it disturbs us a little bit to get
the document change during the review process, but I think it is
more valuable to promptly address the issues brought up by reviewers.
Thanks. We have uploaded a new version of the ivi draft.
Regards,
xing
A new version of I-D, draft-xli-behave-ivi-06.txt has been
successfuly submitted by Xing Li and posted to the IETF repository.
Filename: draft-xli-behave-ivi
Revision: 06
Title: The CERNET IVI Translation Design and Deployment for
the IPv4/IPv6 Coexistence and Transition
Creation_date: 2010-01-06
WG ID: Independent Submission
Number_of_pages: 23
Jari
Xing Li kirjoitti:
Hi, Elwyn,
Thanks for the advice.
Jari, please kindly inform us the next step action.
Thanks.
xing
Elwyn Davies 写道:
Xing Li wrote:
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.
Since this draft is on the IESG agenda for this week you should
check with Jari Arkko before sending in an updated draft before
the meeting.
The changes look good.
Regards,
Elwyn
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