Jay,
good points.
The relationship between the IETF and non-IETF groups has always been
worrisome; in some cases, we have seen things that looked as if someone
outside the IETF wanted to use the IETF as a tool to get the "community"
to endorse a position that couldn't be sold on its own merits, AND place
the IETF in a position where it couldn't insist on obvious weaknesses
in the protcol being repaired.
The discussions around Sun RPC and NFS focused around this issue; it is
also one of the things currently making the S/MIME debate so strident.
In other cases, the IETF community knows that it does not add significant
value to the process of getting a standard done; the IETF is aggressively
uninterested in specifying the number of pins on serial plugs or the
precedence of operators in the C language, to name two instances, although
both efforts are obviously important to our user community.
Recent instances are our non-involvement in the SET payment protocol and
our closing down of work on HTML.
(This is of course a fluid point, since the set of people in the IETF
community,
and therefore its expertise, changes over time - after all, the IPP *is*
part of the IETF community.)
The standards process is the process the IETF has that places a stamp
of approval on specifications. Obviously, we have to be careful what we
use it for.
The IETF should, IMHO, NOT standardize things in the following cases:
- The proposal is not going to be used in or around the Internet
- The proposal cannot be evaluated by IETF experts for lack of competence
- The proposal cannot be modified if the IETF community thinks that it
needs modification
- The proposal does not fit with IETF policy
The last one is a flexible point again; some examples include requiring use of
patented or encumbered technology when freely available alternatives
exist, mandating use of cleartext passwords, standardizing very complex
protocols when simpler solutions solve most of the problem.
It's a judgment call.
Since the bandwidth of those who have to do the judging (the IESG) is limited,
and since we know we're not infallible, we don't want this process to limit
publication of documents, even though we don't necessarily agree with them.
Therefore, RFC publication, which has a reputation as a stable reference,
is available for non-IETF documents in "informational" form. We sometimes
ask for review of informationals, but only attempt to block publication of
them when we regard the content as misleading (such as labelling itself
"Internet Standard") or that publication would lead to confusion in the
community (such as having a fight about 2 approaches in a WG, and the
"loser" being published before the "standard").
I've scheduled the Job MIB on my list of things to look at; let's hope
things get sorted out correctly!
Regards,
Harald T. Alvestrand