Re: [gnso-ff-pdp-may08] Confused and Frustrated about the process

[Dave Piscitello <dave.piscitello@xxxxxxxxx>]

This thread is quickly taking us back to an earlier, unreconciled situation.

My $.02.

We do not yet share a common understanding of the problem.  (I think we are 
close but are struggling with the last yard)

Without a common understanding of the problem, we are the proverbial blind men 
studying an elephant.  No consensus view of the elephant emerged from that 
working group.

We don't need a consensus and we don't need to identify a single, KILLER 
solution. If the DNS and registration services were a single, for-profit 
company, and we were the tiger team tasked with "fixing the problem", we could 
define a solution and force-feed it on the community. That's not the current 
condition, so let's stop imagining we can make it so.

We are studying a complex issue on behalf of a large and diverse community. We 
are 2 dozen people, with diverse perspectives, motivations, experience, and 
knowledge sets. It's natural that we won't see the elephant in the same way. 
But in theory, we are a microcosm of the global community. We are struggling to 
collectively wrap our heads around this issue, and in doing so, we are slowly 
and painfully building a more complete picture of the issue than any of us had 
2 months ago. At this point, we can serve the community best by acting like a 
blind man who invites his peers to touch the part of the elephant he had 
touched. If we continue to do this, our collective understanding of what the 
elephant is will continue to improve and hopefully will match the real thing.

Enough with the analogy. I went back this weekend and scanned many of the WG 
email threads.

We need to report back to the community, via the GNSO, on a number of study 
questions.
I think we are much closer than we might think, Using what we have already 
discussed, and taking the time to tease out complete proposals (with pros and 
cons) from multiple threads, we can achieve the following:


 *   improve the community's appreciation for the problems fast flux attacks 
pose,
 *   identify a set of solutions that could be implemented,
 *   expose the issues these solutions raise for both those who would implement 
and those who will be affected by their implementation

The report should accurately and thoroughly present all input and concerns from 
all the members.

That's a sizable accomplishment but it is a sizable task.

On 8/18/08 1:43 AM, "Marc Perkel" <marc@xxxxxxxxxx> wrote:

Hi Mike,

I can't accept that. It's a very defeatist position. You can't solve problems 
taking that position.

Mike O'Connor wrote:
Hi Marc,

Sorry about the sluggish reply.  I removed my Fast Flux hat and donned my 
Minnesota Ultra High Speed Broadband Taskforce hat after our call yesterday and 
kinda took a vacation from Fast Flux for a while.

Let me expand on the "tech" part of your note as a way to explain what the 
trouble is.

Let's say somebody handed you some electronics to fix and just after you dug 
into the burnt part, they started saying "oh, by the way" (not unlike the way 
Dilbert's pointy-haired boss does).

Oh, by the way, there are 250 more of these things that don't work either... 
and,
If I do a good job on the first one we can look at the others. Nothing wrong 
with fixing 250 problems if it needs done.

Oh, by the way, this is the control module for the emergency shut-down system 
in a nuclear reactor... and,
Shouldn't be a problem here in that the system would be limited to very new 
domains only.

Oh, by the way, the last time we fixed one of these, it killed a bunch of 
people and the guy that fixed it was thrown in jail afterward...
That's the difference between doing it right and doing it wrong. Good 
engineering and testing would eliminate that.

Maybe you would take a different approach to fixing it?
I would - yes.

Nobody is saying "don't solve important problems."  We're saying "let's 
understand the problem before we try to fix it."
You're limiting yourself to a sequential solution when that isn't the best way 
to do it. I have to again object. Sometimes you have to look at solutions as a 
way of understanding the problem. Or you might determine there are no solutions 
in which case you can skip wasting time understanding the problem first.

Hang in there.  We're going to make a heck of a contribution with this effort.  
I just want to avoid the "ready, fire, aim" problem.  No sense of adventure, 
that's me.
All I'm asking is that you not stop the solution process. I've thrown out a lot 
of ideas and I'm waiting for objections that can't be handled.

I've proposed that some of the whois type data be made available through a DNS 
protocol. I'm not hearing a reason not to do that.

I've suggested that we establish some kind of standard communication method so 
that people like me who can detect a problem can report the problem o those who 
need to know about it through automation.

These are key components that will likely be necessary in any solution after we 
figure out the details of the problem.

I can write up a detailed plan of precisely how to implement such a system. But 
I would like to at least have a discussion about these concepts (DNS data, 
automated reporting) just to see if there's any objections even to these 
general concepts,