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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 






On Wed, Nov 13, 2013 at 10:23 AM, cb.list6 <cb.list6@xxxxxxxxx> wrote:
On Wed, Nov 13, 2013 at 8:17 AM, Noel Chiappa <jnc@xxxxxxxxxxxxxxxxxxx> wrote:
>     On Nov 13, 2013, at 10:49 AM, Ole Troan <otroan@xxxxxxxxxxxxx> 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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]