...From listening to the recording of the meeting on Monday, Nov 13,2017: It seems that there is an impression that I feel the authors of the 5011-update draft are wrong choice to be documenting this. This is not meant to be a personal attack on the authors but a blanket comment on seeing operator-focused documents being produced without operator involvement. (Apologies if it is thought to be an ad hominum "attack".)
(Sub-point: It also seems that I've made the comment that ICANN hasn't been involved, which could be contradicted by messages I've sent, as well as Paul Hoffman. ICANN people have been reading and commenting on the document. What I'd like to stress is that ICANN has no special place regarding this document, I don't think that this document is something ICANN deserves "final" edit. Why this confusion exists, I'll explain further on.) Perhaps because I refrain from naming names of operators, my comments have been too vague. From data (meaning what's at the apex of TLD zones) I've collected over many years, I observe that only a handful of TLD operators have ever published a DNSKEY record with the revoked bit set. Within that handful, there are two operators (not two zones as each operator runs multiple zones) that publish a revoked key according to a detectable schedule, from this I have deduced that only two operators - at most - have *fully executed* Automated Updates in the course of normal operations. I write "at most" because I have only asked one of the operators for confirmation and received it, the other I have not. (Drilling deeper, with incomplete data on this, I have also polled delegations within ICANN-affliated TLDs and very rarely see revoked keys. Of course, without a sufficient history of data, this data would only lead to an under count on operators.) Related to my ICANN comment above, ICANN has not fully executed an Automated Updates key rollover yet. We are in the middle of our first roll with STD 69 semantics in mind. FWIW, I sent the names of the two operators in private email to Wes and Warren. For the curious, the two operators are principally operating ccTLDs in east Asia, also operating IDN ccTLDs. I.e., not ICANN is not one of them. My criteria for 5011-update being "operator influenced" would be to have those operators (the confirmed and the other possible one) participate in the review. They may not have a lot to say, but having an operator review and contribute to a document would go a long way to adding credibility in terms of "an operations document." I've made the comment in other contexts - any operational document written by researchers would benefit from an experienced operator's review. It isn't that Wes and Warren aren't qualified to write the document. I'm commenting on the legacy of documents written by protocol designers that are passed off as operations guidance. About 5 years ago, I did a study where I looked at DNSSEC operator guides (written by the IETF) versus parameter settings seen in the wild. (Results presented at RIPE, NANOG in 2012.) The comparison was interesting - some guidance in the document was followed, some was not. Interviewing an operator, they said (to paraphrase) we don't read the RFCs, we use tools and rely on default settings. This was an eye-opening moment for me. Since then I wondered what could be done to improve the usefulness of RFCs to operators and why I have begun to think of "return on investment" of documents. Is the IETF spending time (and the RFC editor) on documents that help the audience? Will this document help the audience?
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
