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

[Frank Kastenholz]

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/...).

_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...)

Frank Kastenholz




At 09:35 AM 12/13/2002 -0800, James Kempf wrote:
>> Possibly that's because we don't know which problem we are trying
>> to solve; see the name of this mailing list.
>>
>
>The problems we are trying to solve, as I see it, are the following;
>
>    - Increasing formalization of the WG ID "status" as being preordained for
>standards track, despite official IETF policy
>      and ID template language to the contrary, as a result of:
>
>        . Publicity by document authors and editors that they have achieved WG
>ID "status" in an attempt to lock in their
>          authorship and basic ideas.
>
>        . Implementation and interoperatability testing of WG ID drafts, based
>partly on the assumption by others as a result
>          of authors' media campagin that the draft, will, in fact, become
>standard, and also in some cases to the authors funding
>          for outside implementations in an effort to get a broadly distributed
>code-base buy-in that will make it hard to
>         remove the draft from WG status.
>
>        . The underlying market need, which is behind the standardization effort
>in the first place, for a solution, and, in many cases a
>          solution right away. People doing products are willing to put up with
>some churn in the spec if they feel the need is great
>          enough, what the IETF considers to be formally the case is of little
>importance, especially the DS and S classifications.
>
> - The result of the above is the hardening of the design by the time the ID
>becomes WG draft around the original idea of the authors
>      with little opportunity for WG input, especially with respect to
>architectural changes that might make the resulting design a better
>      fit with the Internet architecture in general.
>
>  - Lack of requirement for interoperability when a draft becomes PS means that
>many years may go by with informal agreement
>     about interoperability or even a lack thereof in certain areas, because for
>many IETF standards, PS is in reality the final phase
>     and really what most customers of IETF standards care about.
>
>    - Draft Standard and Standard have little or no meaning for customers of
>IETF standards. They are
>      kind of a historical recognition,  and therefore of little practical use
>for day to day engineering.
>
>In summary, the process has become considerably more front-loaded since the
>original standards classification scheme was developed.
>
>                        jak