Re: [dnsext] perhaps we should reintroduce "resimprove"

Edward Lewis <Ed.Lewis@neustar.biz> Wed, 15 February 2012 21:55 UTC

Mime-Version: 1.0
Message-Id: <a06240808cb61d7e260b4@[192.168.129.195]>
In-Reply-To: <CACU5sDnS1L0Tyd4S38uU78nMDpuC8tBgYM+3jwrmFDCTBjMhDg@mail.gmail.com>
References: <4F33E1A6.4030902@isc.org> <CACU5sDnS1L0Tyd4S38uU78nMDpuC8tBgYM+3jwrmFDCTBjMhDg@mail.gmail.com>
Date: Wed, 15 Feb 2012 16:48:58 -0500
To: dnsext@ietf.org
From: Edward Lewis <Ed.Lewis@neustar.biz>
Cc: ed.lewis@neustar.biz
Subject: Re: [dnsext] perhaps we should reintroduce "resimprove"
Precedence: list
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

At 12:11 -0800 2/15/12, Mohan Parthasarathy wrote:

>RFC 4035, "3.1.3.2.  Including NSEC RRs: Name Error Response" has the
>following text towards the end:
>
>    Note that this form of response includes cases in which SNAME
>    corresponds to an empty non-terminal name within the zone (a name
>    that is not the owner name for any RRset but that is the parent name
>    of one or more RRsets).
>
>I don't see anything clarified in the dnssec-bis-updates document
>regarding this. Could you clarify what you meant by "DNSSEC
>specification clarified non-terminal names as existing but empty" ?

Does RFC 4592, section 2.2 help?

Probably what was meant was that DNSSEC forced a clearer 
understanding of empty non-terminals among other issues, which 
spawned RFC 4592 and the words there updating what is meant by 
"existence."

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

[dnsext] perhaps we should reintroduce "resimprov… paul vixie
Re: [dnsext] perhaps we should reintroduce "resim… Andrew Sullivan
Re: [dnsext] perhaps we should reintroduce "resim… Frederico A C Neves
Re: [dnsext] perhaps we should reintroduce "resim… Andrew Sullivan
Re: [dnsext] perhaps we should reintroduce "resim… Andrew Sullivan
Re: [dnsext] perhaps we should reintroduce "resim… Warren Kumari
Re: [dnsext] perhaps we should reintroduce "resim… Stephane Bortzmeyer
Re: [dnsext] perhaps we should reintroduce "resim… paul vixie
Re: [dnsext] perhaps we should reintroduce "resim… W.C.A. Wijngaards
Re: [dnsext] perhaps we should reintroduce "resim… Florian Weimer
Re: [dnsext] perhaps we should reintroduce "resim… Olafur Gudmundsson
Re: [dnsext] perhaps we should reintroduce "resim… Nicholas Weaver
Re: [dnsext] perhaps we should reintroduce "resim… Paul Hoffman
Re: [dnsext] perhaps we should reintroduce "resim… Evan Hunt
Re: [dnsext] perhaps we should reintroduce "resim… Olafur Gudmundsson
Re: [dnsext] perhaps we should reintroduce "resim… Blacka, David
Re: [dnsext] perhaps we should reintroduce "resim… Olafur Gudmundsson
[dnsext] Ghost domain names Edward Lewis
Re: [dnsext] perhaps we should reintroduce "resim… Blacka, David
Re: [dnsext] perhaps we should reintroduce "resim… Olafur Gudmundsson
Re: [dnsext] Ghost domain names Florian Weimer
Re: [dnsext] perhaps we should reintroduce "resim… Mohan Parthasarathy
Re: [dnsext] perhaps we should reintroduce "resim… Edward Lewis
Re: [dnsext] perhaps we should reintroduce "resim… Paul Vixie
Re: [dnsext] perhaps we should reintroduce "resim… Mohan Parthasarathy
Re: [dnsext] perhaps we should reintroduce "resim… Mark Andrews
Re: [dnsext] perhaps we should reintroduce "resim… Mohan Parthasarathy