Re: [dhcwg] We can change the world in a 1000 ways (IPv4 over IPv6)

[Chris Grundemann <[e-mail]>]

On Wed, Nov 13, 2013 at 10:23 AM, cb.list6 <[e-mail]> wrote:

> On Wed, Nov 13, 2013 at 8:17 AM, Noel Chiappa <[e-mail]>
> wrote:
> >     On Nov 13, 2013, at 10:49 AM, Ole Troan <[e-mail]>
> wrote:
> >
> >     > is there a problem here, or should we just accept that sometimes
> the
> >     > IETF will generate ten sets of publications solving more or less
> the
> >     > same problem?
> >
> > This has been a longstanding issue in the IETF (and its predecessors, I'd
> > have to check some of these dates) - going back to HEMS/SGMP, OSPF/IS-IS,
> > etc.
>

This *is* a problem. Not debilitating, but a problem none the less.

We all know what happens to the man with two watches...


> > My long-standing personal position is that the IETF is pretty good at
> > _producing and vetting_ designs, but less good at _chosing_ from similar
> > alternatives. I think it's better if, when we can't agree, to let the
> users
> > decide which works best for them.
> >
> > Yes, yes, I know, this is in some ways painful - resources get wasted on
> > duplicate efforts; some users wind up with investments in standards that
> > dead-end (think Betamax, etc); etc. But at the same time, making a
> choice can
> > produce lengthy, extensive painful politics and wrangling, too. So there
> are
> > down-sides both ways.
> >
> > My bottom line: we're not infinitely smart, and have only limited
> > foresight. Some things you can only learn by trying things.
> >
>
> +1.  The IETF does not engineer the internet.  The internet emerges
> from various independent actors greedily optimizing for themselves.
> The best the IETF can do is facilitate collaboration for these
> self-optimizing actors and document some of what is learned.
>

We can do better.

This entire discussion seems to me to tie directly into two things which
are getting more attention lately but still need considerable effort:

1) Operator engagement - to help add context, requirements, and challenges
for deployment. Knowing more of the real-world constraints will help
provide yard-sticks to measure competing proposals against.
2) Network complexity metrics - to help gauge the quantitative differences
in competing proposals. Having a set of measurements and metrics to use
when comparing both standards and code would change this decision process
completely.

Working down those two paths may just provide the solution to this
long-standing problem.

$0.02
~Chris


>
> CB
> >         Noel
>

-- 
@ChrisGrundemann
http://chrisgrundemann.com