Dear Joao, On Wed, May 09, 2018 at 09:39:56AM +0200, Joao Damas wrote: > While I do agree with you that having implementations early on is a > very desirable requirement, though I would disagree with making it a > hard requirement (see the case of aggressive negative caching and how > it unfolded as an example), for any new idea brought to the IETF I > would like to point out a couple of things here: > > - there is an established way for drafts to progress to RFCs and > within the RFC levels. The progression from proposed to full Standard > absolutely requires implementations (plural)
>From a rhetoric perspective you are quite creative in making a _seemingly_ reasonable point: "why don't we kick the can down the road and require implementations on the 'proposed standard' -> 'internet standard' barrier?". But in my opinion you are misrepresenting the 'established way', this is reason for concern. The IETF TOA is a foundational document https://www.ietf.org/tao.html, let's look at section "A.5 Documents": """ IETF Standards Track specifications are not considered to be satisfactory standards until interoperable independent implementations have been demonstrated. (This is the embodiment of the "running code" slogan.) """ Now let's look at https://tools.ietf.org/html/draft-ietf-dnsop-kskroll-sentinel-12 and in the upper left corner we see: "Intended status: Standards Track". Publishing draft-ietf-dnsop-kskroll-sentinel as RFC on the Standards Track - without implementations - is, plainly said, not very IETF-like. But I'm happy to observe that the feedback received during WGLC was taken serious and at least one implementer got to work, with indications that more will follow. > - the issue is not specific to any give wg, it is an IETF-wide issue > and so the right place for discussion of improving this aspect of > standards development is the IETF list rather any specific wg list You seem to be attempting to move the elephant in the room to a different room (generalizing the issue to an IETF wide scope), this distracts from the issue at hand. Bert Hubert's talk about the "DNS Camel" should have made it clear to anyone that DNSOP itself has a problem. Each working group has to come up with strategies to maximize the quality of their publications; in the case of DNSOP one of the aspects of the solution is fairly obvious: require running code. This is not an IETF-wide issue. The IETF norm is to demonstrate interoperable independent implementations, and if you'd like to argue there should be an exception for the DNSOP working group, the onus is on you to take that discussion to the IETF list. > - in the specific case in the subject, there is funding available to > support final implementation of this idea on three code bases. This > won’t be released until we are past a successful last-call (because > that’s how it works) and so stalling this specific draft on behalf of > a way more general idea and discussion is actually having the opposite > effect of what the discussion’s goals are. It is delaying final > implementation. You may be holding the argument upside down: not having implementations delays having a high quality protocol specification, which delays RFC publication, which (in the diffusion of innovations theory) delays the early & late majority. When not even "innovators" and "early adaptors" can get behind a given draft, that draft is already in trouble. There is no need to _release_ said implementations to the public. The implementers are right to not publish releases containing features that have not yet been standardized. A common approach is to have implementations sit on feature/beta branches, so that you can demonstrate that there is interopability, to have discussion about how to test & validate that the implementation confirms to the protocol specification. Implementer feedback is crucial in constructing a protocol specification. If there are zero implementations of a concept a lot of the discussion about that concept is merely theoretical. This is not a chicken-egg situation. If someone believes this draft is good and serves a purpose benefical to the Internet community, they will attempt to implement the draft and during that development process feedback is collected which the working group can consider to either improver wording, remove non-essential parts, or re-architect the whole thing. Kind regards, Job _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop