Re: RMON document advancement

[Andy Bierman <ietf@andybierman.com>]

David Kessens wrote:

> On Fri, Dec 23, 2005 at 10:43:03AM -0800, C. M. Heard wrote:
>  
>
> > > > > > > On Fri, 23 Dec 2005, Andy Bierman wrote:
> > > > > > >              
> > Andy> [T]here are basically 2 choices:
> > Andy>   1) silent option: don't ask, don't advance
> > Andy>   2) nuclear option: document all the ways multi-phase MIB 
> > Andy>      standards level has hampered, influenced, and even
> > Andy>      damaged IETF NM standards quality
> > Andy> 
> > Andy> I refuse to be the only author on the nuclear option draft.
> > Andy> It might set into motion a series of events I don't have
> > Andy> enough time for.
> >
> >    
> >
> > > > > > > On Fri, 23 Dec 2005, David B Harrington wrote:
> > > > > > >              
> > David> I vote no document. Let's use what resources we have to work
> > David> on network management issues rather than producing documents
> > David> about IETF internal processes.
> >
> > It is hard to argue with that.  Especially the part about "it might
> > set into motion a series of events I don't have enough time for."
> > Sometimes internal process documents are useful, or even necessary,
> > but they sure eat up a lot of energy that could be spent elsewhere.
> >    
>
> I have to disagree here. We have a serious problem in IETF that the
> people who do the real work are not interested in doing anything in
> the area of process improvement. The problem with that is that we end
> up with a bunch of people who are only interested in process &
> procedures who are determined to improve our processes by adding more
> features & procedures instead of cutting them (ironically, cutting
> unnecessary options & features used to be one of the old IETF core
> values). And if you don't go out to vote, you won't be able to
> complain about the result that will include more requirements and
> framework documents, mandatory sections and other things that you can
> spend a lot of time on but that do little to improve the overall
> quality and throughput of IETF.
>
> Basically, we are in a serious need for some people to finally have
> the courage to actually go for the nuclear option to make sure that
> the agenda for process reform gets set the proper way (eg. we discuss
> making things simpler instead of more complicated).
>
>  

Here's the problem.
This is a volunteer organization.
I know several old-timers who have voted with their feet
by simply walking away from the IETF forever.

It is difficult to tell other volunteers they are off in the weeds
and need to cease and desist.  It is more polite to ignore them
and go on with your own work.

There is no substitute for operational experience.
Those without it tend to do 2 things:
 1) Ignore real problems because, in theory, they shouldn't be problems 
at all
 2) Solve problems that don't exist because, in theory, problems should 
be there

Lately we have seen people running amok in category (2).
I've worked at ISO-9000 companies that didn't take procedures
as seriously as the IETF these days.  The US military would be
comfortable with all the red tape, but computer geeks like me hate it.

> My personal somewhat radical opinion is that we should do away with
> any categorization of our documents and make them self-explanatory:
> for example, if one describes an experiment, then just say so in the
> abstract.
>  

Effectively, the categories are lost to the world-at-large.
Even pros like us ignore the BCP and STD numbers and
only remember the RFC numbers. 

I don't like the idea of making it even harder to tell the difference
between an IETF standard and an individual submission.  As long
as the IETF insists on being a Vanity Press for the Internet, we
need to distinguish these documents from standards.


> David Kessens
>  

Andy

> ---
>
>
>
>