Re: [DNSOP] [Ext] Re: draft-wkumari-dnsop-internal and DNAME

2018-01-05 Thread Brian Dickson
[Attribution of the following quotes to Joe and Petr omitted...] > > However, I think the more general idea that queries for internal names > > should be leaked towards unknown AS112 operators is problematic. As an > > end-user I would prefer my leaked queries to be jealously hoarded by one > >

Re: [DNSOP] I-D Action: draft-ietf-dnsop-let-localhost-be-localhost-02.txt

2018-01-05 Thread Petr Špaček
On 18.12.2017 10:24, Mike West wrote: > This draft addresses a few nits that were raised in conversation on the > -01. Changelog > at  > https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-02#appendix-B.1. Good read. My feeling is that it could even go to WGLC if you wish. --

Re: [DNSOP] 4035 3.1.4.1 erratum? dig ds root-servers.net @X.root-servers.net

2018-01-05 Thread 神明達哉
At Thu, 4 Jan 2018 08:12:26 +1100, Mark Andrews wrote: > The reply also has to work for STD13 clients which already know > about the child zone. The NODATA response is the correct one despite > it requiring more work for a DNSSEC client. Section 2.2.1.1 of RFC 3658 also explains

Re: [DNSOP] [Ext] Re: draft-wkumari-dnsop-internal and DNAME

2018-01-05 Thread Warren Kumari
... so, after the reception this document received in Singapore (IETF100) I've decided to abandon doing this work in the IETF. I may still push it in the ICANN world, but not sure I have the stomach for that. Sorry for wasting people's / the WGs time, W On Fri, Jan 5, 2018 at 6:55 AM, Petr

Re: [DNSOP] [Ext] Re: draft-wkumari-dnsop-internal and DNAME

2018-01-05 Thread Petr Špaček
On 12.11.2017 04:26, Joe Abley wrote: > On Nov 12, 2017, at 10:51, Kim Davies > wrote: > > We haven't studied what would be involved, but I feel confident in >> predicting the whole exercise would be non-trivial. > > It seems to me that you

Re: [DNSOP] draft-wkumari-dnsop-internal and DNAME

2018-01-05 Thread Stephane Bortzmeyer
On Sun, Nov 12, 2017 at 10:50:51AM +0800, Kim Davies wrote a message of 32 lines which said: > Allowing DNAME records in the root zone is adding a new concept into > root zone management that hasn't been catered to before. Just one of > the many things that would need to