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 <j...@ntt.net> 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop