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

[Brian E Carpenter <[e-mail]>]

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

    Brian

Geoffrey Sisson wrote:
> "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
> 


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