Subject: [Gen-art] Gen-art review of draft-xli-behave-ivi-05.txt

From: Elwyn Davies <[email-masked]>
Date: Mon, 04 Jan 2010 23:40:56 +0000

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.

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?

---

From: Jari Arkko <[email-masked]>
Date: Tue, 05 Jan 2010 00:56:08 +0100

Thank you for your review!

On quick scan the issues that you raise seem valid ones, and should be 
addressed by the authors.

Jari

Elwyn Davies kirjoitti:
> 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.
>>
> 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.
>
> 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:
>
> 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?
>

---

From: Xing Li <[email-masked]>
Date: Tue, 05 Jan 2010 21:54:15 +0800

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.

> file to the authors with lots of suggestions for this work.

Thank you very much for your kind help.
> I think this needs more explanation. I don't fully understand what is 
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.

> the NAT-PT deprecation draft would probably be adequate).

lack of address mapping persistence discussed in Section 3.3 of [RFC4966].

> IPv6). It probably overkill to use dynamic routing protocols to set up 
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 

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).
> 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.
> the homepages could still work?
Agree. We will make the corrections.

Thank you very much!

Regards,

xing, congxiao

---

From: Xing Li <[email-masked]>
Date: Tue, 05 Jan 2010 21:55:36 +0800

Hi, Jari,

> addressed by the authors.

Thanks. We will make the corrections and try to upload the new version 
tomorrow.

Best regards,

xing

>> 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:
>>>
>> This needs a little more explanation (a pointer to the releant part 
>> of the NAT-PT deprecation draft would probably be adequate).
>>
>> 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.
>>
>> DNS name that maps to these addresses so that if they ever get 
>> changed the homepages could still work?
>>
>
>

---

From: Elwyn Davies <[email-masked]>
Date: Thu, 07 Jan 2010 09:53:24 +0000

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.

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 写道:
>>>>>> 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!
>>>>>>
>>>>>> 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.
>>>>>
>>>>>>> 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.
>>>>>> This needs a little more explanation (a pointer to the releant 
>>>>>> part of the NAT-PT deprecation draft would probably be adequate).
>>>>>
>>>>>> 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.
>>>>>
>>>>>>
>>>>> 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:
>>>>>> informational, this paragraph does not seem appropriate. It needs 
>>>>>> to say what matters ahve arisen during the documented deployment.
>>>>>
>>>>> Except the issues discussed above, we have not find special 
>>>>> security issues introduced by the IVI translation in our experiments.
>>>>>>
>>>>>> Nits/editorial comments:
>>>>>>
>>>>>> 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 
>>>>>> example addresses (see note on s6.1). (It might be possible to 
>>>>>> leave the example traces, but s12 MUST be example numbers.)
>>>>>>
>>>>>> homepages using numeric addresses? Would it be possible to define 
>>>>>> a DNS name that maps to these addresses so that if they ever get

---

From: Xing Li <[email-masked]>
Date: Tue, 12 Jan 2010 19:30:21 +0800

Hi, Elwyn,

Thank you very much.

Elwyn Davies 写道:
> 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

>>> 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.
>>
>> 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.
>>
>>>>>> Thank you very much for your review, the comments and 
>>>>>> corrections. We will make the corrections and try to upload the 
>>>>>> new version tomorrow.
>>>>> check with Jari Arkko before sending in an updated draft before 
>>>>> the meeting.
>>>>>
>>>>> The changes look good.
>>>>>
>>>>> Regards,
>>>>> Elwyn
>>>>>>
>>>>>>
>>>>>> Elwyn Davies 写道:
>>>>>>> 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 
>>>>>>> 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.
>>>>>>
>>>>>>>
>>>>>> 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:
>>>>>>> informational, this paragraph does not seem appropriate. It 
>>>>>>> needs to say what matters ahve arisen during the documented 
>>>>>>> deployment.
>>>>>>
>>>>>>> - 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.
>>>>>>>
>>>>>>> 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?
>>>>>>>
>>>>>>>