Re: FYI: DNSOPS presentation

[Jason Livingood <jason_livingood@cable.comcast.com>]

This thread seems to have died out (on dnsops as well).  But I will note
that it appears to be on the agenda at the upcoming ISOC IPv6 workshop (from
16:30 - 18:00 - see
https://www.isoc.org/isoc/conferences/registration/index.php?id=7ce20e4c88b7
e328).  It is also addressed in a short whitepaper some colleagues and I put
together in advance of that meeting (available at
http://www.comcast6.net/IPv6_DNS_Whitelisting_Concerns_20100416.pdf)

Jason


On 4/2/10 3:17 PM, "Jason Livingood" <jason_livingood@cable.comcast.com>
wrote:

> I agree with what James just posted.
> 
> Since this has hopped over to v6ops from dnsops, I thought I'd post here what
> I wrote over there, as I think it's important as we're working on solutions
> w/o a clear agreement on the problem:
> 
> It seems that have the cart before the horse, so to speak.  IMHO, we need to
> do the following (and there's no reason they cannot occur rapidly):
> 
> 1 - Develop a clear problem statement that outlines (1) how "broken" users
> are defined and (2) what effects this "brokenness" has on these end users
> (or other parts of the Internet).
> 
> 2 - Describe all the various methods and tactics by which end user
> "brokenness" can be detected.  This may include website-based detection,
> DNS-query-based detection, or a variety of other methods.
> 
> 3 - Then, after we have agreement on Problem Definition and Problem
> Detection, we can measure the problem to understand what the scope or scale
> of the problem is.
> 
> 4 - After we understand Problem Definition, Problem Detection, and Problem
> Scope, then you can arrive at possible solutions.  Seems like in this case
> we sort of *started* here, which concerns me and I think we need to be
> careful that discussion thus far does not constrain development of a full
> list of Solution Options.  I further believe we will need to encourage the
> pursuit of multiple solutions simultaneously.  Lastly, just because end user
> software upgrades may be difficult doesn't mean we shouldn't do them and
> shouldn't focus just as much energy on those than other options.
> 
> Jason