Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

[Job Snijders <[e-mail]>]

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