Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

[Job Snijders <[e-mail]>]

Dear Warren,

On Fri, Apr 06, 2018 at 08:37:15AM -0400, Warren Kumari wrote:
> On Thu, Apr 5, 2018 at 1:15 PM, Job Snijders <[e-mail]> wrote:
> > While the chair notes awareness of the point I raised, I’d like the
> > be explicit to avoid any confusion.
> >
> > This document is *not* ready for publication. There is no
> > implementation report available for review and consideration.
> 
> [with absolutely no hats]

The authors of draft-ietf-dnsop-kskroll-sentinel (combined) have at
least 40 years of IETF experience. As such I'm not hesitant to hold them
to the highest standards. Cowboy hats notwithstanding. The protocol
specification will be better for it, and the working group will gain
experience.

> I get that you believe that this is wrong, but DNSOP currently has no
> requirement for there to be an implementation report (nor for there to
> be any implementations). 

The working group chair asked for feedback from the working group:

    tjw wrote:
    "Please review the draft and offer relevant comments.  If this does
    not seem appropriate please speak out. if someone feels the document
    is *not* ready for publication, please speak out with your reasons."
    (https://mailarchive.ietf.org/arch/msg/dnsop/TfW55JEhQOybvlFLcPjybU6ATVU)

Naturally, I did what was asked of me.

> The way to change this is by proposing that this change (done), having
> the discussion (ongoing) and then having the chairs declare consensus
> and that they will require this going forward. It would also be useful
> for there to be clarity about what exactly is required, and for what
> sort of documents (e.g how does one implement attrleaf? or SUDN?), and
> when this would go into effect.

While you are right that it is useful to define what is required for
what sort of document, but I'd like to observe that at this moment, we
are looking at a draft with 0 (zero, null, nada) implementations*, and
also no implementation report draft which stipulates what should be
tested. So your specific question is perhaps somewhat moot. Whatever the
answer is, it will be larger than zero.

    [* Petr was kind enough to provide the working group with an update
    on the progress of a knot implementation, he shared that knot is not
    compatible with the draft-ietf-dnsop-kskroll-sentinel-07 specification
    https://mailarchive.ietf.org/arch/msg/dnsop/ZJ9P7iXUfMoBEojCxVAsJTNs5_Y ]

> A number of people have told me that they wait until something becomes
> an RFC before being willing implement it (some of this may be because
> a significant number of adopted document have simply expired and not
> been published) - suddenly requiring implementations is a large
> change, and deciding it now and retroactively applying it to documents
> which were about cooked seems a little unreasonable. 

"Documents which were about cooked" ?!?! Is this some kind of special
pre-WGLC status? Perhaps the word we are looking for is 'undercooked'? :-)

I have trouble following the line of thought here. Perhaps you can share
your thought on why IDR doesn't seem troubled by these concerns? Companies that
apply "Won't implement until RFC"-policies risk staying behind on the
innovation curve. That is their choice.

I've not seen any attempt to retroactively apply common sense without
following proper process. The process to obsolete/deprecate published
RFCs is well known, and if someone chooses to write a deprecation draft
where the main reason is "lack of implementations" they are free to do
so?

IETF protocol specifications without implementations are worthless. The
IETF TOA lists the phrase "running code" five times. Section A.5 states:

    "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.)"
    source: https://www6.ietf.org/tao.html

draft-ietf-dnsop-kskroll-sentinel-07 targets "Standards Track". The
current state of draft-ietf-dnsop-kskroll-sentinel and my understanding
of the IETF slogan "rough consensus and running code" are incompatible.

> I'd also note that this somewhat disenfranchises participants who a:
> don't code and / or b: don't work for a vendor.

I fail to see what disenfranchisement you are referring to. Can you
elaborate? You don't need to have code abilities to create a protocol
specifications, but you'll need to work with protocol implementers. I'd
like to keep the IETF process as inclusive as possible.

> I'm (of course) fine if the WG / chairs decide that DNSOP needs
> implementations before progressing documents, but your wording makes
> it sound like you believe this this is already the case, and not
> simply your (strong) preference.

I am aware DNSOP does not have a policy of requiring implementations,
and I find this lack of policy regrettable. I believe this document is
not ready for WGLC, for the reasons I listed.

Kind regards,

Job