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

From: [email-masked] (Noel Chiappa)
Date: Wed, 13 Nov 2013 11:17:37 -0500 (EST)

On Nov 13, 2013, at 10:49 AM, Ole Troan <[email-masked]> 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.

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.

	Noel

---

From: "cb.list6" <[email-masked]>
Date: Wed, 13 Nov 2013 09:23:40 -0800

> 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.

CB

---

From: Chris Grundemann <[email-masked]>
Date: Wed, 13 Nov 2013 10:42:36 -0700

> > have to check some of these dates) - going back to HEMS/SGMP, OSPF/IS-IS,

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

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

> 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

-- 
@ChrisGrundemann
http://chrisgrundemann.com