Document: draft-ietf-ipv6-unique-local-addr-06.txt
Review: Michael A. Patton
Date: 11 oktober 2004 

Summary
    * This draft is basically ready for publication, but has nits that
	should be fixed before publication.
One of the comments is a "must fix" as it's an inconsistency.  I know
what they mean, as, I suspect, most readers will.  But, it's an
inconsistency and needs to be fixed.  All the rest are simple typos or
minor suggestions for improvement.



The last paragraph of Section 3.2 is self-contradictory.  It says this
document only defines the centrally assigned addresses and that the
centrally assigned addresses are defined in another document.  I
believe it meant to say that this document only defines the locally
assigned addresses.



Minor comments, not enough to require a rev of the document...but since
the preceding does, these could be considered as well.

In section 3,2 where it describes the "Two assignment methods", I
would suggest use of the terms "guaranteed unique" and
"probabilistically unique" to describe their properties.  I could
offer specific wording, if desired.

This document references RFC1750 (as [RANDOM]).  A new version (which
I understand to be greatly improved) is in development (currently it's 
draft-eastlake-randomness2-08.txt).  If that's almost ready to go, I'd
suggest making this draft reference that.  But, it's a normative
reference, so I don't recommend holding this document up very long
waiting for it.  Perhaps if draft-eastlake-randomness2 makes it into
the front of the RFC Editor queue before this one comes out the end
an RFC number can be assigned and used in the RFC version of this
draft.

In section 3.2.3 second paragraph.  To be pedantic it's not the fact
that the IDs are chosen randomly that makes collisions possible, but
rather the fact that they are chosen independently.  I'm sure that
this difference probably won't matter to most readers, but the lead in
on that paragraph could be changed to "Since global IDs are chosen
independently, ..." to make it slightly more rigorously correct.

In the fourth paragraph of Section 4.0, the grouping on the long
sentence is ambiguous and can result in two distinct meanings being
deduced (and the several typos don't help).  One of those meanings is
clearly nonsense to anyone with routing clue, but just to be sure
nobody uses that meaning, I suggest this rewording:

   If BGP is being used at the site border with an ISP, the default
   BGP configuration must filter out any Local IPv6 address prefixes,
   both incoming and outgoing.  It must be set both to keep any Local
   IPv6 address prefixes from being advertised outside of the site as
   well as to keep these prefixes from being learned from another
   site.  The exception to this is if there are specific /48 or longer
   routes created for one or more Local IPv6 prefixes.

I don't actually think that [POPUL] is a Normative reference, since
it's only used in "why we think this is sufficient" contexts.  The
reference isn't used in "how to implement" contexts.


typos
-----

Section 2.0 "described in this document been proposed"
	 => "described in this document has been proposed"

Section 3.2 "a allocation authority" => "an allocation authority"

The last sentence of the second paragraph of section 3.2.1 is
nonsensical.  I tried several times to figure out what point was
trying to be made so that I could offer suitable replacement text, but
I just couldn't grok it.

Section 3.2.3 "will chose the same" => "will choose the same"

Section 3.2.3 "where N is the number connections"
	   => "where N is the number of connections"

Section 8.0 "This type of addresses" => "This type of address"

Section 8.0 "reachable any point in time"
	 => "reachable at any point in time"