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: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 (define major). It should be
acceptable for other organizations or just persons to contribute a reference
implementation.
It depends on the topic of the draft of course, esp. where in operations
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
because:
* A full-fledged nameserver is somewhat different from a toy
implementation in performance and scalability (this point is from
experience with a bad implementation of a draft)
* The rest of us want to see proof that it can be implemented (not just
a promise or mention of implementation) and play with it and observe
operational characteristics _freely_, and determine whether a draft
will really improve things in the way it says it will. E.g., take all
the multiple-answer drafts that are making the rounds.. in Singapore
there was a presentation of a grand matrix of them, but who knows how
they actually perform?
It's 2018. We aren't living in the dark ages with a single DNS
implementation.
If a draft is for nameserver software to implement, and if the authors
cannot implement it by themselves, they can persuade one of the open
source vendors to do so. If they are unable to persuade any, that should
be enough consensus about how significant that draft is. Speaking for
myself, we in our DNS implementation add support for several drafts
early in the draft stage because they look necessary or interesting, or
because we want to know how they behave early on.
Mukund
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
