Subject: the solution to the ietf problem

From: Edward Lewis <[email-masked]>
Date: Mon, 25 Nov 2002 10:20:30 -0500

If you opened this message because you thought that the subject was
might be accurate, you *just* might be susceptible to spam.  I
thought I might just float this idea.  (I'm not sure it has any
merit, but if it does, I'll deny that it was just my idea.)

I used to believe that the IESG was supposed to function like a
conference program committee.  With that perspective, everything was
running well.  Apparently my belief was wrong.

My recent observation is that some WG's are jammed with a lot of
conjectural activity - stuff that is research.  My hypothesis is that
we should be able to remove all non-schedulable, researchy,
innovation-needing work from IETF WGs and move them to activity in
the IRTF.

One of my observations about research is that it is difficult to
schedule, difficult to keep to a time line.  I think this is due to
research's nature - if it was known how long it would take to achieve
an innovation, the work wouldn't be research.  Perhaps this is what
bogs down WG's - they've gotten lost in researching a problem.

WG's should stick to discussing things that are needed for
interoperability.  If only one person wants to try something, there's
no need for it to be part of a WG.  In DNS, the most likely reason
why an experimental idea might enter the WG is to be able to get an
IANA-assigned protocol number.  That's a lousy reason to demand WG
resources.

If the IETF is too large, it needs to be cleaved.  Cleaving according
to layers is a bad thing.  Cleaving by interests is a bad thing.
Cleaving is in general an obstacle to both interoperbility and
architectural considerations.

Perhaps we could cleave according to the maturity of ideas.  Perhaps
to the IRTF we should push research-needing ideas - things that are
potential solutions to problems, studies of operations (performance,
for example), development of new approaches to architectures, etc.
The IETF could rescope to discussing work items that involve multiple
independent implementations that hope to interoperate.

I'll stop there in case this appears to be a dead end.

PS - I apologize if this in any way copies someone else's mail.  I
haven't been able to catch up with all of the input last week.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer