Re: IESG review of RFC Editor documents

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

 



> Keith,
> 
> > These days, for a protocol specification to be of "reasonable use" on a 
> > wide scale it needs to avoid causing harm.  
> 
> First, something can be of reasonable use while still causing harm. 
> Fossil based fuels prove that. 

Interesting analogy.  Though I'll note that there are different approaches 
to the use of fossil fuels in different parts of the world, one of which 
is "use as much as you can afford and we'll do our best to keep prices low
for the whole country" and another is "tax the worst wastage of fossil 
fuels and use the taxes to fund public transportation which has less impact
on the environment", and the latter is at least arguably saner.  

In other words, if some practice causes harm when that practice is 
widespread, then _some_ kind of caution or restraint might be in order.
Pretending that the problem doesn't exist doesn't seem wise.

>  And while I agree that there are certain 
> areas where causing harm to others needs to be considered (such as 
> UDP-based protocols that lack well known congestion avoidance 
> algorithms), we as a community cannot be so risk averse that we drive 
> development elsewhere.

I disagree with the statement as writen, but more importantly, with the 
implications of the statement.  IETF cannot possibly be a home for all
protocol development on the Internet.  There are simply too many protocols.
After all the Internet is supposed to be a general-purpose communications
framework that can support an arbitrary number of applications.

So a lot of protocol development will always be done outside of IETF, 
and this is a Good Sign.  If we ever get to the point that protocol 
development can only be done within IETF (perhaps because the network
imposes so many constraints that IETF is the only place they can be 
sorted out), we will have failed miserably.

Furthermore there will always be vendors who prefer to "let the market
decide" which protocol will be used than to "let IETF decide" for reasons
that have nothing to do with IETF being too risk averse.  Any vendor which 
has a substantial lead in market share will in general prefer to deploy 
first and later insist that IETF (or other standards-making body) either
rubber-stamp or fix the bugs in its "de facto" standard - thus ensuring
that they keep the competition in catch-up mode.  There's nothing new 
about that, it's been happening for years.

I'd also argue that much of the value that IETF adds (if it is doing its
job right) consists of risk minimization - specifically minimizing the 
risk that customers who invest in deploying IETF standards will have 
substantial incentive to have to completely discard that investment 
within a short time.

Now, clearly there's such a thing as being too risk averse, but I don't
think that's our main problem.  I am more concerned that we don't pay 
attention to some substantial risks until very late in our processes - 
when it's too late to fix the problems.

> Similarly, SOCKS went quite far before the IETF ever got a look at it. 
> Why?  Because we are no longer viewed as a place where development can 
> seriously take place.  Risk averse. 

Maybe the problem is not just being risk averse, but our development style.
Something tells me that having random, unstructured conversations for
months on end and gaining consensus by exhaustion are not good ways 
to do protocol development.  And only after the WG is exhausted do we
do any serious external review.  But it's not fair to blame the reviewers
for being too risk averse  when the WG failed to pay attention to those
risks in the first place.

Now the *perception* might be that we're too risk averse, just because
we take so long to get protocols out the door.  But while there are 
lots of ways to speed up the process, to simply be less risk adverse is
to fail to do our jobs.

> You know that thing about running 
> code?  Taken too far we fail what I think part of our mission is, which 
> is to be a place to collaborate, because everyone will have shown up 
> with their respective running code, only to fight over whose running 
> code (if anybody's) will become the standard.  See, for instance, the 
> XMPP/IMPP wars.

Those wars would have cropped up anywhere else that didn't simply 
cave in to pressure from one faction.   You can't force people to agree,
particularly when they think they gain a competitive advantage from
not agreeing.

> > Publishing crap dilutes the value of the RFC series, and makes it more 
> > difficult for the public to recognize the good work that IETF does.  It 
> > also costs money which could be better put to other uses.
> 
> This was never the series' intent.  

Face it, there's no way that the RFC series could have continued to be 
the Engineering Notebook for the Internet for all this time.  The Internet 
has long since become too large and too diverse.  The RFC series structure
could never have accommodated it.  Maybe something like a Wiki, but even
that's a stretch.  For that matter, no matter what the structure, there 
would always be people who didn't want to go along with that.  Heck, we
can't even get everyone to agree on the structure of domain names, and 
those are far, far simpler and with obvious advantages to uniformity.

The truth is that we've long since abandoned the original intent of the
RFC series, and appropriately so.  Except as a historical note the original
intent is scarcely relevant now.

> We've attempted to warp it into 
> this, and the result has been The Official Dogma, with a corresponding 
> lack of development within the IETF. 

Oh, BS.  The change in the RFC series hasn't hindered development a whit.
If you don't want to jump through the minimal hoops required to get your
protocol published as Informational or Experimental, there are plenty of 
other ways to publicly document your protocol.

> If we want to allow for REAL 
> innovation WITHIN the IETF, then you have to let some crap through, and 
> you have to trust the RFC Editor and others to hold the bar at some level.

non sequitor.
 
--
Power corrupts; Powerpoint corrupts absolutely. 	- Vint Cerf


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