Subject: Re: [Gen-art] Gen-art review of draft-ietf-v6ops-addcon-07.txt

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Wed, 4 Jun 2008 11:43:54 +0200

Dear Elwyn,

The just submitted draft-ietf-v6ops-addcon-08 has the following changes
injected based on your review. Please let me know if you see further
open items.

********

 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 wait for direction from your document shepherd or AD before
posting a new version of the draft.

Document: draft-ietf-v6ops-addcon-07.txt
Reviewer: Elwyn Davies
Review Date: 6 May 2008
IESG Telechat date: 08 May 2008

Summary:
This document looks to be in fairly good shape but there are a number of
areas where  it really needs attention from an editor with English
mother tongue - IMO this ought to be done before it goes to the RFC
Editor as in some cases they make it technically unclear.  There are
also a couple of places (notably around ULAs) where there is some FUD in
the document that is (apparently) not tied to specific issues.  This is
undesirable as a prospective user has no idea whether these alleged
issues affect his/her network.

Comments:
s1: Needs a little additional explanation of 'interface-id'.

GV> WAS:
GV> and the 'interface-id'.
GV> CHANGED TO:
GV> and the 'interface-id' (the identification of the interface within a
subnet).

s1, bullet 3 (near end): s/traffic storm and level/potential traffic
storms and the level/  No further mention of traffic storms is made in
the document... should it be to give some hints on subnet sizing? 

GV> WAS:
GV> Even though there is no broadcast for the IPv6 protocol, there is
still need to 
GV> consider the number of devices in a given subnet due to traffic
storm and level of 
GV> traffic generated by hosts.
GV> CHANGED TO:
GV> REMOVED this bullet

s2.1, para 2: s/may thus have two addresses/may thus have two or more
addresses/ 

GV> WAS:
GV> may thus have two addresses
GV> CHANGED TO:
GV> may thus have two or more addresses

s2.2, para3: 'Using a random chosen ULA address will be conform in case
   (a) provide suboptimal aggregation capability, while in case (c)
   there will be overconsumption of address space.'  This sentence is
not good English and I don't understand what it is trying to say
regarding case (a).

GV> WAS:
GV> Using a random chosen ULA address will be conform in case (a)
provide suboptimal 
GV> aggregation capability, while in case (c) there will be
overconsumption of address 
GV> space.
GV> CHANGED TO:
GV> Using random chosen ULA addresses will provide in case (a)
suboptimal aggregation
GV> capabilities, while in case (c) a /48 ULA address is larger then the
less-than-/48 
GV> prefix and will hence result in address space overconsumption.

s2.2, last para: '   The usage of ULAs should be carefully considered
even when not
   attached to the IPv6 Internet as some IPv6 specifications were
   created before the existence of ULA addresses.' This piece of FUD is
not terribly helpful - do we have any idea what pieces of specification
might conflict or (at least) work differently when using ULAs - or are
you effectively just repeating what has been said already?

GV> Note from Gunter Van de Velde: 
GV> Source address selection with multicast addresses might for example
go wrong as 
GV> the ULA is selected due to longest match. If this stream would hit
any other networks 
GV> in anyway, then things might break. For clarity sake and to avoid
FUD perception the 
GV> para has been removed

GV> WAS:
GV> The usage of ULAs should be carefully considered even when not
attached to the IPv6 
GV> Internet as some IPv6 specifications were created before the
existence of ULA 
GV> addresses.
GV> CHANGED TO:
GV> REMOVE para

s3.3, para 3: Ir would be useful to explain why the u and g bits might
come back to bite us in future or provide a reference which discusses
why they are relevant at all.

GV> WAS:
GV> When assigning a subnet prefix of more then 70 bits, according to
RFC4291 [26] "u" and 
GV> "g" bits (respectively the 71st and 72nd bit) need to be taken into
consideration and 
GV> should be set correctly.  In currently implemented IPv6 protocol
stacks, the relevance GV> of the "u" (universal/local) bit and "g" (the
individual/group) bit are marginal and GV> typically will not show an
issue when configured wrongly, however future 
GV> implementations may turn out differently.

GV> CHANGED TO:
GV> When assigning a subnet prefix of more then 70 bits, according to
RFC4291 [26] "u" and 
GV> "g" bits (respectively the 71st and 72nd bit) need to be taken into
consideration and GV> should be set correct.  
GV> The "u" (universal/local) bit is the 71st bit of IPv6 address and is
used to determine GV> whether the address is universally or locally
administered. If 0, the IEEE, through the GV> designation of a unique
company ID, has administered the address. If 1, the address is 
GV> locally administered. The network administrator has overridden the
manufactured address 
GV> and specified a different address.

GV> The "g" (the individual/group) bit is the 72st bit and is used to
determine whether the GV> address is an individual address (unicast) or
a group address (multicast). If "0", the 
GV> address is a unicast address. If "1", the address is a multicast
address. 

GV> In current IPv6 protocol stacks, the relevance of the "u" and "g"
bit is marginal and 
GV> typically will not show an issue when configured wrongly, however
future 
GV> implementations may turn out differently if they would be processing
the "u" and "g" GV> bit in IEEE like behavior.

s3.3.1.1, last para:  'No additional
   dependencies for the subnet prefix while the EUI-64 and IID
   dependencies will be discussed later in this document.' I cannot
parse this sentence.  It probably needs 'There are..' added to the front
and some additional wordsmithing (maybe like the last sentence of
3.3.1.2).

GV> WAS:
GV> No additional dependencies for the subnet prefix while the EUI-64
and IID dependencies 
GV> will be discussed later in this document.

GV> CHANGED TO:
GV> There is no additional dependency for the subnet prefix with the
exception of the 
GV> EUI-64 and an IID dependency. These will be discussed later in this
document.

s4.2: RFC 3041 has been obsoleted by RFC 4941.  I believe this covers
the same ground needed here.

GV> WAS:
GV> Existing references to RFC3041
GV> CHANGED TO:
GV> New References to RFC4941

sA.2.1.1: References to LIR/RIR allocation policies would be useful.

GV> Done

Editorial:
General: idnits reports several out of date references.

GV> Done

General: s/Global Unique Address(es)/Globally Unique Address(es)/

GV> Done

General: Need to use (modified) title case for section headings 

GV> Done

Reference format: The RFC Editor now insists on symbolic references
rather than numeric.  You may wish to choose the symbols and modify refs
appropriately. 

GV> Added in the document:
GV> <?rfc symrefs="yes" ?>

s1, last para: s/is provider/is either provider/

GV> Done

s2.1, para 2: s/operative/operational/

GV> Done

s2.2, para 6: Expand RPF acronym.

GV> Done

s2.3: Expand RIR acronym.

GV> Done

s2.4.2, para 2: Expand HD acronym.

GV> Done

s3.2, last para: s/for different then/with other than/

GV> Done

s3.3, para 1: s/futile benefit/little benefit/

GV> Done

s3.3.1.1, last para: expand EUI-64 and IID. (IID is expanded later in
s4)

GV> Done

s3.3.2, last para: s/eventhough/even though/

GV> Done

s3.3.3, last para: Not good english: replace with 'Note that the
definition of ISATAP does not support multicast.'

GV> Done

s3.3.4: s/The 126/126/

GV> Done

sA.1.1, last para: expand GLOP, ASN, BGP

GV> GLOP is not an acronym, but I added reference to RFC where GLOP is
defined
GV> Expanded on both BGP and ASN

sA.2.1.1: Expand LIR

GV> Done

sA.2.1.4: s/thumb rules/rules of thumb/

GV> Done

-----Original Message-----
From: Elwyn Davies [mailto:[email-masked]] 
Sent: Tuesday, May 06, 2008 7:52 PM
To: General Area Review Team
Cc: Mary Barnes; gunter (mailer list); Chip Popoviciu (cpopovic);
[email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Gen-art review of draft-ietf-v6ops-addcon-07.txt

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 wait for direction from your document shepherd or AD before
posting a new version of the draft.

Document: draft-ietf-v6ops-addcon-07.txt
Reviewer: Elwyn Davies
Review Date: 6 May 2008
IESG Telechat date: 08 May 2008

Summary:
This document looks to be in fairly good shape but there are a number of
areas where  it really needs attention from an editor with English
mother tongue - IMO this ought to be done before it goes to the RFC
Editor as in some cases they make it technically unclear.  There are
also a couple of places (notably around ULAs) where there is some FUD in
the document that is (apparently) not tied to specific issues.  This is
undesirable as a prospective user has no idea whether these alleged
issues affect his/her network.

Comments:
s1: Needs a little additional explanation of 'interface-id'.
s1, bullet 3 (near end): s/traffic storm and level/potential traffic
storms and the level/  No further mention of traffic storms is made in
the document... should it be to give some hints on subnet sizing? 
s2.1, para 2: s/may thus have two addresses/may thus have two or more
addresses/ s2.2, para3: 'Using a random chosen ULA address will be
conform in case
   (a) provide suboptimal aggregation capability, while in case (c)
   there will be overconsumption of address space.'  This sentence is
not good English and I don't understand what it is trying to say
regarding case (a).

s2.2, last para: '   The usage of ULAs should be carefully considered
even when not
   attached to the IPv6 Internet as some IPv6 specifications were
   created before the existence of ULA addresses.' This piece of FUD is
not terribly helpful - do we have any idea what pieces of specification
might conflict or (at least) work differently when using ULAs - or are
you effectively just repeating what has been said already?

s3.3, para 3: Ir would be useful to explain why the u and g bits might
come back to bite us in future or provide a reference which discusses
why they are relevant at all.

s3.3.1.1, last para:  'No additional
   dependencies for the subnet prefix while the EUI-64 and IID
   dependencies will be discussed later in this document.' I cannot
parse this sentence.  It probably needs 'There are..' added to the front
and some additional wordsmithing (maybe like the last sentence of
3.3.1.2).

s4.2: RFC 3041 has been obsoleted by RFC 4941.  I believe this covers
the same ground needed here.

sA.2.1.1: References to LIR/RIR allocation policies would be useful.

Editorial:
General: idnits reports several out of date references.
General: s/Global Unique Address(es)/Globally Unique Address(es)/
General: Need to use (modified) title case for section headings
Reference format: The RFC Editor now insists on symbolic references
rather than numeric.  You may wish to choose the symbols and modify refs
appropriately. 
s1, last para: s/is provider/is either provider/

s2.1, para 2: s/operative/operational/

s2.2, para 6: Expand RPF acronym.

s2.3: Expand RIR acronym.

s2.4.2, para 2: Expand HD acronym.

s3.2, last para: s/for different then/with other than/

s3.3, para 1: s/futile benefit/little benefit/

s3.3.1.1, last para: expand EUI-64 and IID. (IID is expanded later in
s4)

s3.3.2, last para: s/eventhough/even though/

s3.3.3, last para: Not good english: replace with 'Note that the
definition of ISATAP does not support multicast.'

s3.3.4: s/The 126/126/

sA.1.1, last para: expand GLOP, ASN, BGP
sA.2.1.1: Expand LIR

sA.2.1.4: s/thumb rules/rules of thumb/

_

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art