Subject: [Gen-art] Gen-ART Review of draft-ietf-dnsext-dns-name-p-s-01

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 8 Dec 2005 20:59:44 -0600

I was selected as General Area Review Team reviewer for this specification
(for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

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. 

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 9 Dec 2005 07:40:19 -0600

Hi, Geoffey,

Thanks for the quick feedback.

Notes inline,

Spencer

> "Spencer Dawkins" <[email-masked]> wrote:
>>
> You're correct that all uppercase US-ASCII letters in the domain name
> have been converted to lowercase.  However, an uppercase letter may be
> encountered when incrementing (3.1.2.3 and 3.2.2.3) or decrementing
> (3.1.1.4 and 3.2.1.4) an octet.  For example, if an octet contains '@'
> and it gets incremented, the new value would be 'A'.  Similarly, if an
> octet contains '[' and it gets decremented, the new value would be
> 'Z'.  To maintain canonical sort order, these value must be skipped,
> i.e. increment('@') -> '[' and decrement('[') -> '@'.

If this is normal DNS-speak, I apologize for my lack of knowledge, but 
"skipped" confused me; I thought you were talking about skipping an octet in 
the domain name, but you are talking about redefining "increment" and 
"decrement" for specific octet values - did I understand correctly? If so, 
perhaps this could be a little more obvious - something like

   4.  Decrement the value of the least significant (right-most) octet
       of the least significant (left-most) label, repeating until the 
resulting octet does not
       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.  Continue to the next step.

Again, if everyone in DNS land knows what you meant, that's fine - it just 
confuses visitors :-)

> We avoided RFC 2119 key words in draft-ietf-dnsext-dns-name-p-s as we
> thought that otherwise things might get messy.  In view of your
> observations, perhaps it would make sense to drop Section 4.1 from the
> document altogether?

I'm sorry, I conflated two comments here. My real question was "when is it 
OK for the synthesized NSEC RR to NOT
reflect the RRset types that exist?". Your use of lower-case should makes 
sense to me, given the relationship between the two documents.

> I believe it shouldn't be too difficult for an implementation to adapt
> to the introduction of a longer label.  The predecessor/successor
> functions could be paramaterized to take into account the longest label
> in the zone.
>
> I would be reluctant to remove this optimisation as few zones contain
> labels that are even half the maximum label length, so that the savings
> in NXDOMAIN response size that might be realised by utilising this
> optimisation for these zones is not inconsiderable.

Murky thinking on my part - I agree with you here.

Thanks,

Spencer

---

From: Geoffrey Sisson <[email-masked]>
Date: Fri, 9 Dec 2005 13:00:20 GMT

> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Thank you for your time and effort in reviewing the document.

Note that the logic above isn't explicitly set out, as the derivation
has been generalised for possible modifications, in particular the
exclusive use of LDH ('letter-digit-hyphen') values.  This problem
doesn't arise in LDH as increment('9') -> 'a' and decrement('a') -> '9',
which sidesteps the uppercase issue altogether.

>    field as specified by Section 4.1.2 of [RFC4034].

draft-ietf-dnsext-dns-name-p-s is intended to compliment
draft-ietf-dnsext-dnssec-online-signing, which has been submitted for
publication as a standards track document.  Section 4.1 really only
expands upon paragraph eight of Section 2 of that document, which
says:

   Before answering a query with these records, an authoritative server
   must test for the existence of names between these endpoints.  If the
   generated NSEC would cover existing names (e.g. exampldd.com or
   *bizarre.example.com), a better increment or decrement function may
   be used or the covered name closest to the QNAME could be used as the
   NSEC owner name or next name, as appropriate.  If an existing name is
   used as the NSEC owner name, that name's real NSEC record MUST be
   returned.  Using the same example, assuming an exampldd.com

Thanks again.

Geoff

---

From: Geoffrey Sisson <[email-masked]>
Date: Wed, 14 Dec 2005 10:20:28 GMT

> Again, if everyone in DNS land knows what you meant, that's fine - it just 

Thanks for the suggested text; however I'd be concerned that it might
lead the reader to infer that results with uppercase values were
typical rather than atypical.

When drafting the document, I considered alternative wordings of this
item, but all seemed to have the effect of reducing rather than
enhancing clarity.

> reflect the RRset types that exist?".

draft-ietf-dnsext-dnssec-online-signing states: "if an existing name
is used as the NSEC owner name, that name's real NSEC record MUST be
returned".

Perhaps Section 4.1 should be modified as follows:

OLD:

   Before using the result of P(N) or P'(N) as the owner name of an NSEC
   RR in a DNS response, a name server should test to see whether the
   name exists.  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].  Implementors will
   likely find it simpler to use a non-synthesised NSEC RR.  For further
   details see Section 2 of [I-D.ietf-dnsext-dnssec-online-signing].

NEW:

   [I-D.ietf-dnsext-dnssec-online-signing] states: "if an existing name
   is used as the NSEC owner name, that name's real NSEC record MUST be
   returned".  Consequently, before using the result of P(N) or P'(N)
   as the owner name of an NSEC RR in a DNS response, a name server
   which implements [I-D.ietf-dnsext-dnssec-online-signing] will need
   to test to see whether the name exists.  If it does, either a
   standard non-synthesised NSEC RR may be used, or the synthesised
   NSEC RR will need to 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].  Implementors will likely find it simpler to use
   a non-synthesised NSEC RR.  For further details see Section 2 of
   [I-D.ietf-dnsext-dnssec-online-signing].

Regards

Geoff

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Dec 2005 11:41:40 +0100

The change you suggest reads OK, but please wait until
Margaret gives you guidance.

    Brian

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 14 Dec 2005 08:02:47 -0600

Hi, Geoffrey,

Agree with Brian that your suggested change for returning RRsets is good 
(and also agree that you should get guidance on changes from Margaret :-)

On the other area of my confusion...

> item, but all seemed to have the effect of reducing rather than

I understand this concern (with MY suggested text :-) - no one said writing 
was easy). If

    4.  Decrement the value of the least significant (right-most) octet
        of the least significant (left-most) label (if the resulting octet
        corresponds to uppercase US-ASCII letters, repeat until it
        does not), and then append the least significant (left-most)
        label with as many octets as possible of the maximum sort
        value.  Continue to the next step.

helps, please consider it (and discuss with Margaret if you like it); if it 
does not, then you have considered all of MY alternative wordings that seem 
to have the effect of reducing rather than enhancing clarity. ;-)

Just so you know - this week, Gen-ART is also reviewing a draft with 120 
pages of corrections to a 134-page standards-track  RFC, so I'm probably 
MORE sensitive to clarity issues than I will be for the next telechat - and 
perhaps I should apologize for that sensitivity!

Thanks, and best wishes for the telechat,

Spencer

---

From: Geoffrey Sisson <[email-masked]>
Date: Wed, 14 Dec 2005 15:52:38 GMT

Hi Spencer

Thanks again for your time and effort in reviewing this document.
Comment below (though not forgetting I'm to wait for further
guidance from Margaret).

> I understand this concern (with MY suggested text :-) - no one said writing 

:-)

> to have the effect of reducing rather than enhancing clarity. ;-)

Actually "repeat until" is overly-prescriptive.  Skipping values which
correspond with ASCII uppercase letters needn't (and probably
shouldn't) involve iterative increment/decrement operations.  If the
value of an octet after an increment/decrement operation corresponds to
an uppercase letter, then changing its value to the next sequential
non-uppercase value is sufficient.  For example:

	val--;
	if (val == 'Z') {
		val = '@';
	}

. . . rather than:

	val--;
	while (isupper(val) == TRUE) {
		val--;
	}

> perhaps I should apologize for that sensitivity!

Um . . . oh dear . . . good luck.

Regards

Geoff

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 14 Dec 2005 09:56:05 -0600

Hi, Geoffrey,

Quoting from a previous note,

>> was easy).

:-)

Thanks for thinking it over, though.

Spencer