Re: [DNSOP] raising the bar: requiring implementations

At Fri, 6 Apr 2018 04:35:44 +, Evan Hunt wrote: > > At Thu, 5 Apr 2018 13:46:29 -0400, > > tjw ietf wrote: > > > > > What is work: An "informational" document being used as standard is people > > > taking a submitted (expired) draft as "standard"? > > > >

Re: [DNSOP] raising the bar: requiring implementations

On Thu, Apr 05, 2018 at 01:31:37PM -0700, 神明達哉 wrote: > At Thu, 5 Apr 2018 13:46:29 -0400, > tjw ietf wrote: > > > What is work: An "informational" document being used as standard is people > > taking a submitted (expired) draft as "standard"? > > I'm not sure how to

Re: [DNSOP] raising the bar: requiring implementations

On Wed, Mar 28, 2018 at 05:24:33PM +0200, bert hubert wrote: > allow the one remaining closed source DNS implementation Really? I'm so pleased we have not only candidate censors of what is going to be published by the WG but also census-takers who have determined then number and types of

Re: [DNSOP] raising the bar: requiring implementations

At Thu, 5 Apr 2018 13:46:29 -0400, tjw ietf wrote: > What is work: An "informational" document being used as standard is people > taking a submitted (expired) draft as "standard"? I'm not sure how to interpret it (not even sure if it's a question to me)...but I guess what I

Re: [DNSOP] raising the bar: requiring implementations

What is work: An "informational" document being used as standard is people taking a submitted (expired) draft as "standard"? Tim On Thu, Apr 5, 2018 at 1:39 PM, 神明達哉 wrote: > At Wed, 4 Apr 2018 11:22:33 +0200, > Petr Špaček wrote: > > > >> This is

Re: [DNSOP] raising the bar: requiring implementations

At Wed, 4 Apr 2018 11:22:33 +0200, Petr Špaček wrote: > >> This is actually quite a good example of another problem: > >> Client-subnet was documented for Informational purposes; it was > >> already in wide use in the public internet and had an EDNS opt code > >> codepoint

Re: [DNSOP] raising the bar: requiring implementations

On 29.3.2018 22:59, Phillip Hallam-Baker wrote: > On Thu, Mar 29, 2018 at 3:18 PM, Suzanne Woolf > wrote: > > > Should we refuse to document such things because they’re not in > well-known open source codebases, or have otherwise

Re: [DNSOP] raising the bar: requiring implementations

On 29.3.2018 22:05, Mukund Sivaraman wrote: > On Thu, Mar 29, 2018 at 03:18:45PM -0400, Suzanne Woolf wrote: >> >> On Mar 28, 2018, at 11:19 AM, Mukund Sivaraman wrote: >> >>> On Wed, Mar 28, 2018 at 10:55:13AM -0400, tjw ietf wrote: I would say that most things we have adopted

Re: [DNSOP] raising the bar: requiring implementations

I can agree with the argument that if implemented in a major open-source DNS implementation it would weigh in more to the discussion, but limiting to is far too restricting in my opinion. Best regards, Matthijs On 03/28/2018 09:48 PM, Mukund Sivaraman wrote: On Wed, Mar 28, 2018 at

Re: [DNSOP] raising the bar: requiring implementations

On Thu, Mar 29, 2018 at 3:18 PM, Suzanne Woolf wrote: > > Should we refuse to document such things because they’re not in well-known > open source codebases, or have otherwise not passed tests of goodness? > > It’s not a rhetorical question. Given that people are

Re: [DNSOP] raising the bar: requiring implementations

On Thu, Mar 29, 2018 at 03:18:45PM -0400, Suzanne Woolf wrote: > > On Mar 28, 2018, at 11:19 AM, Mukund Sivaraman wrote: > > > On Wed, Mar 28, 2018 at 10:55:13AM -0400, tjw ietf wrote: > >> I would say that most things we have adopted in the past few years do have > >> some

Re: [DNSOP] raising the bar: requiring implementations

On Mar 28, 2018, at 11:19 AM, Mukund Sivaraman wrote: > On Wed, Mar 28, 2018 at 10:55:13AM -0400, tjw ietf wrote: >> I would say that most things we have adopted in the past few years do have >> some implementations to reference. >> Not when drafts are adopted, but generally

Re: [DNSOP] raising the bar: requiring implementations

On Wed, Mar 28, 2018 at 2:45 PM, Paul Vixie wrote: > > i'm in general agreement with each of the assertions made at each layer of > quoting above, but i have two quibbles. > > first, they aren't reference implementations. not even BIND, which for > many years i called a

Re: [DNSOP] raising the bar: requiring implementations

Cisco On 3/29/18, 8:12 AM, "DNSOP on behalf of Tony Finch" wrote: Frederico A C Neves wrote: > On Wed, Mar 28, 2018 at 04:46:52PM +0100, Tony Finch wrote: > > > > ... I have probably missed several ...

Re: [DNSOP] raising the bar: requiring implementations

Arsen STASIC wrote: > > Quad9 is using powerdns dnsdist as loadbalancer and powerdns recursor and > unbound [0], [1] > > [0] https://www.makeuseof.com/tag/quad9-dns-overview/ > [1] >

Re: [DNSOP] raising the bar: requiring implementations

Frederico A C Neves wrote: > On Wed, Mar 28, 2018 at 04:46:52PM +0100, Tony Finch wrote: > > > > ... I have probably missed several ... > > MS D'oh! Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Lundy, Fastnet: Cyclonic 4 or 5.

Re: [DNSOP] raising the bar: requiring implementations

* Tony Finch [2018-03-28 16:46 (+0100)]: bert hubert wrote: Well to allow the one remaining closed source DNS implementation some room, authoritative services: Akamai Amazon Cloudflare Dyn Google Verisign recursive services: Google OpenDNS Quad9

Re: [DNSOP] raising the bar: requiring implementations

Also, this "Camel" in the presentation may have been a mythological beast, but the real and existing DNS Camels that struggle with their backs breaking under the weight of DNS are the DNS implementations, especially the open source ones that are underfunded and understaffed. If someone wants to

Re: [DNSOP] raising the bar: requiring implementations

On Thu, Mar 29, 2018 at 01:18:36AM +0530, Mukund Sivaraman wrote: > it applies. If it is nameserver territory, I absolutely want to see an > implementation in *any* of the major DNS implementations. By major, I > mean the popular ones (e.g., PowerDNS, NSD, Unbound, Knot, etc.) This is Sorry, that

Re: [DNSOP] raising the bar: requiring implementations

On Wed, Mar 28, 2018 at 05:29:18PM +0200, Matthijs Mekking wrote: > As mentioned in the meeting, I am in favor of requiring implementations > before drafts become standards. > > However, I would be opposed to limit acceptable implementations to the few > major open source DNS implementations

Re: [DNSOP] raising the bar: requiring implementations

On Wed, Mar 28, 2018 at 04:46:52PM +0100, Tony Finch wrote: > bert hubert wrote: > > > > Well to allow the one remaining closed source DNS implementation some room, > > authoritative services: Akamai Amazon Cloudflare Dyn Google Verisign > recursive services: Google

Re: [DNSOP] raising the bar: requiring implementations

Matthijs Mekking wrote: On 03/28/2018 05:19 PM, Mukund Sivaraman wrote: On Wed, Mar 28, 2018 at 10:55:13AM -0400, tjw ietf wrote: I would say that most things we have adopted in the past few years do have some implementations to reference. Not when drafts are adopted, but generally before

Re: [DNSOP] raising the bar: requiring implementations

On Wed, Mar 28, 2018 at 3:46 PM, Tony Finch wrote: > bert hubert wrote: >> >> Well to allow the one remaining closed source DNS implementation some room, > > authoritative services: Akamai Amazon Cloudflare Dyn Google Verisign > recursive services: Google

Re: [DNSOP] raising the bar: requiring implementations

bert hubert wrote: > > Well to allow the one remaining closed source DNS implementation some room, authoritative services: Akamai Amazon Cloudflare Dyn Google Verisign recursive services: Google OpenDNS Quad9 COTS: Nominum ... I have probably missed several ... Tony.

Re: [DNSOP] raising the bar: requiring implementations

An enterprise company with rather large zone which update often are "highly interested" in MIXFR. But we may be the exception rather than the rule. Tim On Wed, Mar 28, 2018 at 11:24 AM, bert hubert wrote: > On Wed, Mar 28, 2018 at 08:49:39PM +0530, Mukund Sivaraman

Re: [DNSOP] raising the bar: requiring implementations

On 03/28/2018 05:19 PM, Mukund Sivaraman wrote: On Wed, Mar 28, 2018 at 10:55:13AM -0400, tjw ietf wrote: I would say that most things we have adopted in the past few years do have some implementations to reference. Not when drafts are adopted, but generally before we head to WGLC I've always

Re: [DNSOP] raising the bar: requiring implementations

On Wed, Mar 28, 2018 at 08:49:39PM +0530, Mukund Sivaraman wrote: > I'd raise the bar even higher, to see complete implementation in a major > open source DNS implementation when it applies. Sometimes implementation > problems are very revealing (client-subnet should have gone through > this).

Re: [DNSOP] raising the bar: requiring implementations

On Wed, Mar 28, 2018 at 10:55:13AM -0400, tjw ietf wrote: > I would say that most things we have adopted in the past few years do have > some implementations to reference. > Not when drafts are adopted, but generally before we head to WGLC I've > always wanted to see someone > who implemented the

Re: [DNSOP] raising the bar: requiring implementations

I would say that most things we have adopted in the past few years do have some implementations to reference. Not when drafts are adopted, but generally before we head to WGLC I've always wanted to see someone who implemented the option in some manner. But yes, agree. On Wed, Mar 28, 2018 at

Re: [DNSOP] raising the bar: requiring implementations

I would love to see a hard requirement for implementations & implementation reports (like IDR has) in the charter or in the working group house rules. Early implementations (perhaps even during the hackathon) can reveal implications that might have been missed while designing the draft. In

Re: [DNSOP] raising the bar: requiring implementations

On 24.3.2018 12:07, Job Snijders wrote: > Dear DNSOP, > > I'd like to share some pointers from the working group that governs the > BGP protocol, IDR, on requiring implementations before drafts can > advance towards RFC publication. Raising the bar for publication will > take weight off the

[DNSOP] raising the bar: requiring implementations

Dear DNSOP, I'd like to share some pointers from the working group that governs the BGP protocol, IDR, on requiring implementations before drafts can advance towards RFC publication. Raising the bar for publication will take weight off the camel's back. The IDR policy and rationale is outlined