Document: draft-ietf-v6ops-renumbering-procedure-01
Reviewer: Michael Patton
Date: July 21, 2004

Summary: This draft is basically ready for publication, but has nits that
	 should be fixed before publication.

This was one of the best drafts I've ever read.  It was clear except
for a few minor quibles, see below.  The only substantive quibble I
have is with the title.  Since, as the draft points out, actual
details will vary from network to network, these details are glossed
over a bit.  Therefore, I'd suggest replacing the word "Procedures"
with the word "Techniques"...I think that makes the title a bit more
honest.  But, I wouldn't object to it as-is, just think it would be
better with this change.


In the first paragraph there are nested quotes, they should use
different quoting according to the English usage I learned in school.
That is to say, in ASCII it should read:
   The Prussian military theorist Carl von Clausewitz [Clausewitz]
   wrote, "Everything is very simple in war, but the simplest thing is
   difficult.  These difficulties accumulate and produce a friction,
   which no man can imagine exactly who has not seen war.  ...  So in
   war, through the influence of an 'infinity of petty circumstances'
   which cannot properly be described on paper, things disappoint us and
   we fall short of the mark." Operating a network is aptly compared to
   conducting a war.  The difference is that the opponent has the futile
   expectation that homo ignoramus will behave intelligently.
I changed exactly two characters.


In the second paragraph it talks about the phrase "make before break"
as coming from mobility, but this term is much older and comes from
standard switching (that's electrical switches and relays :-) usage.
I learned it in 1973 from a book that was so old it was falling
apart.  The term is almost certainly over half a century old, probably
a lot more than that.

The third paragraph notes that this updates RFC2072.  Shouldn't that
be called out in the head somewhere?

In the Terminology does "Network element" include end systems?  Since
in some other documents it does and in others it does not, I'd suggest
they indicate which usage they mean.  From my reading of the document
the authors intend that end hosts are NOT Network elements, and I
think that should be indicated in the terminology section.  Probably
best done by have a definition for host or end system and then saying
explicitly that Network element does NOT include these.


In Appendix A, there is no reason at the step where you change the RR
to the new value that you shouldn't also change it back to the longer
TTL.  The given procedure waits to change the TTL.  There is no
benefit to that, making one change is probably better.



Typos
-----

Third paragraph of the Intro:
      "a few of many areas" => "a few of the many areas"

2.2.1 paragraph 5:
      "either TSIG, and SIG(0)" => "either TSIG or SIG(0)"

2.2.2 at the very end, the period at the end of the last sentence is
      in the wrong place.

5. last paragraph:
   "Another problem becomes from the fact" =>
   "Another problem comes from the fact"

Appendix A has a couple of typos in the paragraph:
   Assume the use of NOTIFY [RFC1996] and IXFR [RFC1995] to transfer
   updated information from the primary DNS server to any secondary
   servers; this is a very quick update process, and the actual time to
   update of information is not considered significant.
which should read:
   Assuming the use of NOTIFY [RFC1996] and IXFR [RFC1995] to transfer
   updated information from the primary DNS server to any secondary
   servers; this is a very quick update process, and the actual time to
   update information is not considered significant.