Standards Classification and Reality Problem Statement (was Re: Not a problem statement [ was Re: Killing old/slow groups - transition thinking)

[James Kempf]

> James, reading your note, it seems that you believe that
> all (most?) of the problems in the IETF stem from a single
> root cause -- that ID's have become "the standard" to which
> people implement and _that_ is because of market pressures
> (a competes with b so if a gets the thing done before b then
> a wins a battle in the market) and personal pressures (i want
> the self-satisfaction of being the author of the id/rfc/...).
>

No, not at all. I was only responding to Brian's comment about this being a
problem statement list, not a solutions list (my original note was solutions
oriented). Thus, the note was an attempt to state what I think the problem is
with the front-loading of people's perceptions regarding what is and isn't a
standard.

There are other problems I've seen, I should probably try to post as complete a
characterization of them.

> _If_ that's a fair characterization of your note, then there
> is nothing we can do but tweak a few things here and there.
> We _can_not_ remove the market pressures (we can not force
> companies not to sell/deploy id-based stuff) and we can not
> get rid of the personal/self-satisifaction issues (even if you
> remove my name from the draft, I'll know I wrote it and I'll
> tell everyone...)
>

I wasn't meaning to suggest that we try to change reality, but rather that we
modify the IETF standards classification to match it. "Engineering" is, after
all, our middle name, and engineering is all about being practical and coming up
with things that people use. The DS and S parts of the IETF standards
classification are currently fairly useless to most customers of IETF standards.
We should either figure out a way to make them useful or drop them in favor of a
classification system that matches the market's perception of what is a useful
classification.

            jak