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

[Geoffrey Sisson <[e-mail]>]

"Spencer Dawkins" <[e-mail]> wrote:

> >> 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?
> >
> > 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 :-)

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.

> >> 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].
> >
> > 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?".

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

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