On 25/06/2014 12:12 am, "Tim Wicinski" <[email protected]> wrote:
>(I am merging two of Paul Hoffman's messages into one reply. I hope I am >not muddling the message) Doing my own leap frog as well. > > > >Speaking as co-chair, Mr. Hoffman is absolutely correct on this point - >we are more than OK with half-baked ideas being hand-waved and a solid >discussion happening on the list. > >That's fine: it is supposed to be a consensus document and we aren't >there yet. My hope is that DNSOP doesn't become too DNSEXT-like where if >the -00 for a proposal isn't universally loved, it is destroyed instead >of worked on. To be clear, I'm not immediately reaching for a hatchet (a pint perhaps ;). That said rumour mill preceded the draft and I felt somewhat disappointed by the -00. However I am driven by stability, robustness, and 'accuracy' of the system, thus any 'improvements' must be that with zero detractors compared to the current system. I will invest some time sooner rather than later to dive deeper into the document and highlight places that seem sketchy to me, or even just a little bit nuts. (ie For me, the second "con" is a rather large bump to the system - but could well be implementation specific) I don't see this so much as a question of being universally loved, but more in the realms of it being technically appropriate for the aspects of protocol function and DNS efficiencies given what we suggest here does have a strong bearing on the (big "G") global internet operations. So my first, and biggest, criticism of the draft would be the lack of a clear and specific problem statement that this document addresses, or aims to address. I appreciate that this is half-baked as an answer and thats why its worth bring here, however if the problem definition itself is half baked then we really do have issues. Case in point: the second paragraph of the Intro suggests that the target is the 'somewhat inefficient' cache construction. Can we get some metrics to truly define these inefficiencies? You can also read into the "Pro's" that latency, DoS, centralised monitoring, junk/negative caching, and lack of DNSSEC validation are all "issues". Are these the problems that _this_ draft is specifically addressing? and can we use those as metrics? Or are there other problems that the authors have in mind but haven't documented here for fear of being called a heretic? There are no porcelain angels here - if there is a problem you see (even a political one that makes technical life a pain) please call it out. > >> My hope is that DNSOP doesn't become too DNSEXT-like where if the -00 >>for a proposal isn't universally loved, it is destroyed instead of >>worked on. > >We as chairs do not have that mind set. My personal feeling is to >figure out what parts do seem to be useful and have some interest, and >guide discussions along those lines. We may be also completely >delusional, but I'd like to keep believing otherwise for a little while >longer. I'm fine for the discussion and will happily participate. Cheers Terry
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
