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
- Re: [DNSOP] CDS and/or CDNSKEY Matthijs Mekking
- Re: [DNSOP] CDS and/or CDNSKEY Warren Kumari
- [DNSOP] CDS and/or CDNSKEY Matthijs Mekking
- Re: [DNSOP] CDS and/or CDNSKEY Warren Kumari
- Re: [DNSOP] CDS and/or CDNSKEY Paul Wouters
- Re: [DNSOP] CDS and/or CDNSKEY Dickson, Brian
- Re: [DNSOP] CDS and/or CDNSKEY Paul Wouters
- Re: [DNSOP] CDS and/or CDNSKEY Guangqing Deng
- Re: [DNSOP] CDS and/or CDNSKEY Matthijs Mekking
- Re: [DNSOP] CDS and/or CDNSKEY Tim Wicinski
- Re: [DNSOP] CDS and/or CDNSKEY Warren Kumari
- Re: [DNSOP] CDS and/or CDNSKEY Paul Wouters
- Re: [DNSOP] CDS and/or CDNSKEY Matthijs Mekking
- Re: [DNSOP] CDS and/or CDNSKEY Warren Kumari
- Re: [DNSOP] CDS and/or CDNSKEY Olafur Gudmundsson
- Re: [DNSOP] CDS and/or CDNSKEY Warren Kumari
- Re: [DNSOP] CDS and/or CDNSKEY Warren Kumari
- Re: [DNSOP] CDS and/or CDNSKEY Matthijs Mekking
- Re: [DNSOP] CDS and/or CDNSKEY Doug Barton
- Re: [DNSOP] CDS and/or CDNSKEY Paul Wouters
- Re: [DNSOP] CDS and/or CDNSKEY Doug Barton
- Re: [DNSOP] CDS and/or CDNSKEY Paul Hoffman
- Re: [DNSOP] CDS and/or CDNSKEY Doug Barton
- Re: [DNSOP] CDS and/or CDNSKEY Warren Kumari
- Re: [DNSOP] CDS and/or CDNSKEY Doug Barton
- Re: [DNSOP] CDS and/or CDNSKEY Paul Wouters
- Re: [DNSOP] CDS and/or CDNSKEY Mark Andrews
- Re: [DNSOP] CDS and/or CDNSKEY Olafur Gudmundsson
- Re: [DNSOP] CDS and/or CDNSKEY Alan Clegg
- Re: [DNSOP] CDS and/or CDNSKEY Paul Hoffman
- Re: [DNSOP] CDS and/or CDNSKEY Warren Kumari
- Re: [DNSOP] CDS and/or CDNSKEY Mark Andrews
- Re: [DNSOP] CDS and/or CDNSKEY Mark Andrews
- Re: [DNSOP] CDS and/or CDNSKEY Andrew Sullivan
- Re: [DNSOP] CDS and/or CDNSKEY Guangqing Deng
- Re: [DNSOP] CDS and/or CDNSKEY Mark Andrews
- Re: [DNSOP] CDS and/or CDNSKEY Ondřej Surý
- Re: [DNSOP] CDS and/or CDNSKEY Ondřej Surý
- Re: [DNSOP] CDS and/or CDNSKEY Ondřej Surý
- Re: [DNSOP] CDS and/or CDNSKEY Warren Kumari
- Re: [DNSOP] CDS and/or CDNSKEY Paul Wouters
- Re: [DNSOP] CDS and/or CDNSKEY Mark Andrews
- Re: [DNSOP] CDS and/or CDNSKEY Billy Glynn
- Re: [DNSOP] CDS and/or CDNSKEY Ondřej Surý
- Re: [DNSOP] CDS and/or CDNSKEY Ondřej Surý
- Re: [DNSOP] CDS and/or CDNSKEY Paul Wouters
- Re: [DNSOP] CDS and/or CDNSKEY Ondřej Surý
- Re: [DNSOP] CDS and/or CDNSKEY Wes Hardaker