Dave,
To paraphrase Ned, I am amazed how your perspective on the
importance of process changes depending on which side of an argument
you are on. In skimming through recent messages I thought you were
criticizing some WG participants for trying to delay approval of this
spec along procedural grounds, and now you are arguing, along
procedural grounds, that the spec must be apporved. You and have have
disagreed over the relative merits of a purely egalitarian approach to
accepting any standards proposals that has a constituiency, vs. one in
which the proposal is evaluated based on its merits and how it fits
into an overal architectural framework. I think I have been
consistent in my views on this topic.
As for the goals not being newborn, well that is a point of
contention. One of the problems I think we have here is that the
current spec does not do a good job of stating what its goals are, and
how it accomplishes them, expect as a delta to 1421. The problem with
that approach is that when one changes one aspect of a system, in
response to a specific percieved deficiency, there may be
ramifications to the rest of the system design. To make an analogy,
several years ago a (Hyatt?) hotel in Kansas City suffered a failure
of the structures supporting a walkway, killing and injuring a fair
numer of folks. The reason for the failure was that the architect
specified a means of attaching the supporting rods to the walkway that
was physically impossible, i.e., a detail that the architect didn't
really work out. The builders noticed this problem when time came to
construct the walkway and so they elected to devise their own
approach to solving the problem, which looked similar to what had been
architected. However, this modification, which appear to be quite
close to the original design, was not structually equivalent and thus
the walkway failed (on New Year's Eve, I think). The moral being that
small changes to address localized problems may have larger effects
that are not appreciated without the benefit of a more thorough
analysis. I worry that in the case of MIME-PEM, some of the changes
that have been made, which are not changes to supporty MIME, but
rather are changes to the functionality of PEM, have more global
effects than are ascribed to them. Without a more comprehensive model
of what problem is being solved, and how the proposal solves the
problem, I am not confident that we should progress the proposal.
I agree with your observation that other Internet standards
have been approved in the absence of comprehensive descriptions for
the problems being solved. But, as my mother always said, "just
because other people do it, that doesn't make it right." I am
especially sensitive to a lack of a good problem statement in a
security-relevant protocol, because there are many opportunities to
create security vulnerabilities due confusion between what security
services implementations provides and what users believe they are
getting. The discussion immediately above alludes to that point.
Finally, to be quite blunt, one IAB member and two IESG
members have told me over the last few weeks (without solicitation)
that they view the spec in question as very bad. The term "shit" was
used by at least one of these folks. I take this sort of concern,
espressed by experienced, knowledgable people, very seriously. I feel
bad that, due to other commitments, that I have not been able to work
more closely with the authors, especially Jim Galvin, to help resolve
some of the problems that probably contribute to this reaction. I
know that Jim has worked hard on this for some time and that the
current spec represents a serious effort to respond to many of the
comments that have been brought forth. Nonetheless, that doesn't mean
that the spec should be approved while there are serious concerns
about it.
As for the matter of the referendum, thanks for your input.
Steve