Draft:  draft-ietf-dnsext-dns-name-p-s-01
Reviewer: Spencer Dawkins [spencer@mcsr-labs.org]
Review Date: Thursday 12/8/2005 9:00 PM CST
LC Date: 12/06/05
Telechat Date: 12/15/2005

Summary: This document is definitely on the right track for publication as 
Experimental. I should add that it is very well-organized and mostly clearly 
written (oh, that all Internet Drafts might be so). I especially appreciate 
the work that went into the examples (including the introduction of P(N) and 
S(N) notation).

I have a few comments that might be considered during IETF Last Call. These 
comments follow.

Thanks,

Spencer

I was confused when I read in section 3. "Derivations":

   These derivations assume that all uppercase US-ASCII letters in N
   have already been replaced by their corresponding lowercase
   equivalents.

and then, a few paragraphs later, in section 3.1.1. "Derivation of DNS Name 
Predecessor":

   4.  Decrement the value of the least significant (right-most) octet
       of the least significant (left-most) label, skipping any values
       that correspond to uppercase US-ASCII letters, and then append
       the least significant (left-most) label with as many octets as
       possible of the maximum sort value.

Where did the uppercase US-ASCII letters come from? (I thought they had 
already been replaced)... There is similar text in 3.1.2, 3.2.1, and 3.2.2 
(they are pretty much symmetrical), and further into 4.2. If (3) said 
"lowercase have already been replaced by uppercase", all this would make 
perfect sense to me - am I misunderstanding?

In section 4.1. "Test for Existence", why is the following text saying 
"should reflect"? I'm wandering around "should/SHOULD" and "must/MUST" here. 
If it IS "should/SHOULD", when is it OK for the synthesized NSEC RR to NOT 
reflect the RRset types that exist?

   If it does, either a standard non-synthesised NSEC RR
   should be used, or the synthesised NSEC RR should reflect the RRset
   types that exist at the NSEC RR's owner name in the Type Bit Map
   field as specified by Section 4.1.2 of [RFC4034].

Section 4.5.1. "Restriction of Effective Maximum DNS Name Length" worries 
me - the text correctly states the possibility that you'll get a longer name 
via dynamic DNS/zone transfer, and if this can happen, I would think that 
it's better to disallow the optimization.