Subject: [BEHAVE] review of draft-ietf-behave-v6v4-framework-07

From: "David Harrington" <[email-masked]>
Date: Thu, 11 Mar 2010 00:29:18 -0500

Hi,

Here is a review of the v6v4 framework document. These are all
editorial in nature. The document struck me as being very good
quality.

section 1.1

6NET should have a reference.

section 1.3

"Peer-to-peer file exchange applications" talks about getting content
from servers, which seems to imply a client-server relationship.
Should this be 
s/They tend to prefer to ask for content from servers/
They tend to prefer to ask for content from peers/

section 1.4

The Transition Phase (2010 through 2011) paragraph uses capitalized
SHOULDs to encourage organizations to deploy IPv6. The Preparation
Phase and Post-Transition Phase use lowercase shoulds to encourage
organizations to not force their customers/users to upgrade equipment.
Since these are both phase recommendations, shouldn't the
capitalization be consistent?

section 3.2.1

s/IPv6 notes/IPv6 nodes/

section 3.2.2
s/from the IPv6 side it doesn't support/from the IPv6 side; it doesn't
support/

section 3.3
s/handing/handling/

section 4
"For the IPv4
   parts of the network, [RFC4213]'s recommendation holds: bringing
IPv6
   up in those domains, moving production to it, and then taking down
   the now-unnecessary IPv4 service when economics warrant remains the
   least risk approach to transition."
I found this difficult to parse, although it is parseable. IPv4
addresses
are most likely to "run out" in areas other than North America and
Europe. I think it would be easier for non-native English speakers to
read this if it were rewritten:
"For the IPv4
   parts of the network, [RFC4213]'s recommendation holds. Bring IPv6
   up in those domains, move production to it, and then take down
   the now-unnecessary IPv4 service when economics warrant. This 
    approach to transition entails the least risk."

s/, as shown in Figure 15,//
"   During the coexistence phase, as shown in Figure 15, one expects a
   combination of hosts - IPv6-only gaming devices and handsets, older
   computer operating systems that are IPv4-only, and modern mainline
   operating systems that support both, as well as a combination of
   applications including ones that are IPv4-only and modern
   applications that support both."
I don't think figure 15 shows this combination of hosts and
applications and networks; it doesn't mention gaming device or
handsets or old operating systems ...
This could be improved by saying 
"Figure 15 shows that, during the coexistence phase, one expects a
combination of hosts, applications, and networks. Hosts might include
IPv6-only gaming devices [...]. Applications might oinclude [...].
Networks might include [...].

Section 5
I am a little concerned with mentioning unsolved problems that may
never become RFCs (i.e. never get beyond being expired internet
drafts). Do we really need to mention these in the framework?

Section 6:
"... no new assignments or registries are
   required, or if those assignments or registries are created during
   the RFC publication process. "
If no new assignments are required, what does "those assignments"
refer to?

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: Xing Li <[email-masked]>
Date: Mon, 15 Mar 2010 21:42:13 +0800

Hi, David,

Thanks. We will incorporate your comments in the next revision.

Regards,

xing, congxiao

David Harrington 写道:
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>
>

---

From: Xing Li <[email-masked]>
Date: Tue, 23 Mar 2010 08:04:14 +0800

Hi, David,

Thank you very much. We have uploaded a new version and addressed your 
comments. Some notes are inline.

> capitalization be consistent?

Since this is informative document. We have changed SHOULDs to shoulds.

> If no new assignments are required, what does "those assignments"

We believe the "Note to RFC Editor:" will be removed during the 
IETF-editing process.

Regards,

xing, congxiao