On 7/30/2015 2:37 PM, Wessels, Duane wrote:
On Jul 30, 2015, at 11:18 AM, Michael StJohns <m...@nthpermutation.com> wrote:
Data is only useful if you've got a plan for when you get it and if you
understand that perfect knowledge is impossible.
Sure, but I would claim that describing how to get the data and the plan for
when you get it are different things and
probably only one of these is appropriate for an IETF mailing list.
DW
Is that an indirect way of asking me to shut up and go away?
This is a mailing list for figuring out protocols for use in the
operation of DNS. One of the basic principles of protocol design is
first figuring out how it will be used or what purpose it is
fulfilling. So *I* would claim that arguing against pursuing an idea
on the basis that it doesn't actually help with the operation of the DNS
*because* you don't know what to do with the data when you get it is a
reasonable set of discussions for this list.
The main argument that I mostly agree with is that "more data is good",
with the caveat that there's always a cost for more data and not always
paid by those who benefit from the data (cf advertising stats collection
in your browser). The main argument I disagree with is "this will help
us to decide when to roll the root". I don't see it - and the
arguments are using generalities rather than numbers so they're a bit
slippery to analyze in a rigorous manner.
So the cost benefit analysis comes down to: Is doing this because "more
data is good" sufficient reason to proceed? If not, is there sufficient
evidence that this will provide us with information that will help us to
decide when to roll the root in a timely (e.g. next year, not next
decade) manner? At what point do we abandon the effort because its "too
late" to roll the root?
Let's first get a clean statement of need from the root operators and
ICANN - what they want to collect, why, what they want to do with it,
and when do they need it including drop dead dates?; and *then* let's
build a protocol (or DNS extension or a mass emailing if that's what it
takes to actually get the data).
Later, Mike
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
