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"? > > > > I'm not sure how to interpret it (no

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 interpret it (not even sure

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 DN

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 think is the most imp

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 actually quite a good example of another p

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 allocated from the IANA

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 not passed tests > of g

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 in the past fe

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 05:29:1

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 extending the > protocol outside

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 implementations to re

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 before we head to WG

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 reference implementation,

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 ... > > MS D'oh! Tony. -- f.anthony.n.finch

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] > https://www.theinquirer.net/inquirer/news/3021536/ibm-teams-with-global-cyber-alliance-to-launch-quad9-a-free-publ

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.finchhttp://dotat.at/ - I xn--zr8h punycode Lundy, Fastnet: Cyclonic 4 or 5. Moderate or rough, occasionally very roug

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 COTS: Nominum Quad9 is using powerdns dnsdi

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 ad

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 (defi

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 OpenDNS Quad9 > COTS: Nominum

Re: [DNSOP] raising the bar: requiring implementations

Bert, On Wed, Mar 28, 2018 at 05:24:33PM +0200, bert hubert wrote: > 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 > > probl

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 w

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 OpenDNS Quad9 > COTS: Nominum Those can

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. -- f.anthony.n.finchh

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 wrote: > > I'd raise the bar

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). Wel

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 o

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 10:5

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 additi

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 camel'

[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 he