Re: [DNSOP] CDS and/or CDNSKEY

Warren Kumari <warren@kumari.net> Tue, 08 October 2013 20:22 UTC

Return-Path: <warren@kumari.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876B121F9CF5 for <dnsop@ietfa.amsl.com>; Tue, 8 Oct 2013 13:22:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83saa89EmNzl for <dnsop@ietfa.amsl.com>; Tue, 8 Oct 2013 13:22:35 -0700 (PDT)
Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183A121F9CE3 for <dnsop@ietf.org>; Tue, 8 Oct 2013 13:22:29 -0700 (PDT)
Received: from dhcp-220-73.meetings.nanog.org (dhcp-220-73.meetings.nanog.org [199.187.220.73]) by vimes.kumari.net (Postfix) with ESMTPSA id DF35D1B401DC; Tue, 8 Oct 2013 16:22:28 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Warren Kumari <warren@kumari.net>
In-Reply-To: <525466A5.6000006@dougbarton.us>
Date: Tue, 08 Oct 2013 13:22:29 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <A1CA88FF-4008-477B-A917-0AAE37AF927B@kumari.net>
References: <5243DCAB.80507@nlnetlabs.nl> <311D023E-9425-416E-B3E6-96F3347F162B@kumari.net> <52451D58.5040107@nlnetlabs.nl> <FC382AE9-C360-47B3-B1B6-35276C624AAC@kumari.net> <524D9B65.30704@teamaol.com> <52543899.3090801@dougbarton.us> <alpine.LFD.2.10.1310081408570.7675@bofh.nohats.ca> <52545387.2010607@dougbarton.us> <24BAD69C-F0AA-4F33-8A3D-536494864D34@vpnc.org> <525466A5.6000006@dougbarton.us>
To: Doug Barton <dougb@dougbarton.us>
X-Mailer: Apple Mail (2.1510)
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] CDS and/or CDNSKEY
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Oct 2013 20:22:40 -0000

On Oct 8, 2013, at 1:10 PM, Doug Barton <dougb@dougbarton.us> wrote:

> On 10/08/2013 12:52 PM, Paul Hoffman wrote:
>> On Oct 8, 2013, at 11:48 AM, Doug Barton <dougb@dougbarton.us> wrote:
>> 
>>> However I think a reasonable conclusion from the stalemates that have arisen from all of the previous attempts over the years would be, "There is no agreement on how to proceed, so we should not proceed."
>> 
>> That is the opposite of the feeling that I got from the DNSOP meeting in Berlin.
> 
> ... and yet, there is a larger world outside the select few able to attend the meetings. :)  One could even reasonably argue that the opinion of those who do attend the meetings is of questionable statistical validity due to volunteer bias.
> 
>>> But have we any evidence that if created, this mechanism will be used?
>> 
>> IIRC, there were at least a few TLD operators at the DNSOP WG in Berlin who indicated they would strongly consider it.
> 
> Translated, "The idea does not suck so much that we feel comfortable rejecting it out of hand, but we have no real interest in it."
> 
>>> I personally don't subscribe to the "If we build it, they will come" school of engineering. We have too many counterexamples in the DNS already.
>> 
>> That's fine; neither you or I (currently) run a TLD and we don't have to think about it yet. This is for the people do run TLDs, and the multitude who are going to be doing so soon.
> 
> ... which leads back to my previously expressed concern that the gTLD RRA framework may specifically prevent this kind of child-to-parent signaling from being possible.

Which is why the draft specifically talks about parental agents:
Parental Agent: "The entity that the child has relationship with,
      to change its delegation information."

and Appendix A has:
For example in many of the TLD cases there is the RRR model
   (Registry, Registrar and Registrant).  The Registry operates DNS for
   the TLD, the Registrars accept registrations and place information
   into the Registries database.  The Registrant only communicates with
   the Registrar; frequently the Registry is not allowed to communicate
   with the Registrant.  In that case as far as the registrant is
   concerned the Registrar == Parent.


Basically the 50'000ft view is:
In many regulatory environments (the polite way of saying where ICANN says "No!") the *registrar* will fetch the CDS / CDNSKEY and will push the updated records into the *registry* through existing mechanisms (like EPP).

W

> 
> To save everyone time and further responses, I've seen all the counter-arguments, and have followed the most recent thread in addition to the previous ones. I stand by my analysis that this is a solution in search of a problem, and that limited resources could be better spent elsewhere; for whatever that analysis is worth.
> 
> Doug
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 

--
"Have you got any previous convictions?"

"Well, I dunno... I suppose I used to believe very firmly that a penny saved is a penny earned--"
-- Terry Pratchett