This charter seems to fly in the fase of the traditional IETF charter style, wherein a WG was deemed to have a set end point. “Develop guidelines”, “publish documents” and “serve as a clearinghouse” are terms that engender more activity but don’t indicate progress. (A long time ago, in a government job, I was taught terms that guaranteed one would never fail a performance review - like “participate in” and so on. The terms here fall into the same category.)
Comment on … … item 1. Don’t attempt to list the functional roles name servers name servers fill. Most roles have never had formal definitions and in the industry “roles” have been used confusingly. E.g., many practitioners think “root servers” are the servers for a TLD or are the (authoritative) servers of any zone. While terminology can be refined and new definitions given, the confusion today means that the role labels don’t fit in the charter. To be more specific, what problems exist in the current state of DNS operations? (I believe there are quite a few.) The specific issues the WG is willing to look into should be enumerated. (A blanket charter is a bad idea - a restrictive charter can always be updated, a blanket allows for “make-work” items.) … item 2. DNSSEC is a clumsy protocol extension. Empirical evidence suggests that it is - (without a quantitative study, I’ll go out on a limb and say) most DNSSEC validation failures stem from operator or operations related errors than forged messages. What can be done is come up with a way to counter the “lack of a child knowing about the parent” in the assembling of the signed chain of trust. I.e., sending the key material from child to parent. Other needed improvement is to develop practices for debugging (SERVFAIL means what?), monitoring, and measurement. E.g., The RFC for DS hash algorithm 2 has a trigger in it for when algorithm 2 is well deployed - but there’s no means to discover that. (http://iepg.org/2012-03-ietf83/IETF83IEPGLewis.pdf, slide 23) See also “Crypto Alg Undertanding.” And another topic here - clear and understandable guidance on the parameters of DNSSEC - key lengths, durations, etc. … item 3 Again - something specific is needed. I am a loss here for suggestions. Hasn’t DNS been ready for IPv6 for a very long time? … item 4 and item 5 This is kind of like saying that one of my duties is “show up for work.” Isn’t #4 just saying the WG should act as WG? “Protocol maintenance” might just mean adding DNSSEC key algorithm numbers or it might mean a new zone transfer protocol. The latter is something I wouldn’t think this group is wanting to take on. (I had written that for 4, but then I saw 5 gave me the same impression. In the sense I do see 4 and 5 are different, if I have the same reaction, they are two general to be “good” charter items unless the goal is to have a never ending WG.) … item 6 Already commented on that. On Apr 3, 2014, at 17:39, Suzanne Woolf <suzworldw...@gmail.com> wrote: > Colleagues, > > Here is draft text for the new charter we've been talking about for DNSOP. ... _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
