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
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art