ietf
[Top] [All Lists]

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

2013-11-13 11:42:56
On Wed, Nov 13, 2013 at 10:23 AM, cb.list6 
<cb(_dot_)list6(_at_)gmail(_dot_)com> wrote:

On Wed, Nov 13, 2013 at 8:17 AM, Noel Chiappa 
<jnc(_at_)mercury(_dot_)lcs(_dot_)mit(_dot_)edu>
wrote:
    On Nov 13, 2013, at 10:49 AM, Ole Troan 
<otroan(_at_)employees(_dot_)org>
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