Edward Lewis <edward.le...@icann.org> writes: Ed,
Sorry for the delay in a response. Too many recent deadlines and vacations... > 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".) I do understand that it wasn't anything personal. > 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. I think this is where the biggest misconception may lie about the purpose of our document. The document is structured as a mathematically defined security line that you MUST NOT cross, not as operational guidance. We even state so multiple times in the document and I do hope that a future document (authored by someone else) comes out as a BCP or informational document that truly does give good advice, from a publishers point of view, about the best way to use RFC5011 and suggested timing mechanisms for key-rolling things like the root and other domains. This document is a security analysis result, however, and it may be that you might think this was actually the wrong group to submit it through? [good story about operators not reading RFCs...] > 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. I sure wish we had a better answer to this problem, as it's been plaguing the O&M section of the IETF for decades (forever?). Unfortunately, I suspect that there isn't nearly enough "real operator content" here (IETF) to attract the attention of operators. It still looks and feels and smells like a protocol engineer camp, and if you're an operator and have the choice of spending time and a travel budget toward an IETF or toward a *OG/RIPE, it's much more likely you'll head toward the dedicated operational camps. I'm not sure that means we shouldn't produce work out of the O&M area though, as we have a lot of people from operator companies that are here as proxies at least. -- Wes Hardaker USC/ISI _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop