... irrelevant discussion of falling walkways deleted ..
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.
Specifics please. What issues do you think need to be addessed, and how? What
additional prose needs to be added to the document to correct this problem?
We are now in working group last call. It is no longer time for glittering
generalities. It is time for specifics, preferably backed up with specific
recommendations for change.
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.
I agree with this assessment 100%. These standards need to be of high quality,
regardless of whether or not other standards in the past have been. However, I
find it quite difficult to reconcile this statement with the arguments you have
made defending the classic PEM specifications, where you effectively said that
since other standards weren't clear and precise you didn't need to be either.
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.
Then let me be equally blunt. If you have received comments like this from the
IESG and IAB and have failed to pass them on to the document authors at a
minimum if not the entire group, you have utterly failed in your role as
Working Group Chair. It is absolutely your responsibility to act as a conduit
between the the IAB and IESG and the Working Group, and to provide feedback of
this sort in a timely fashion to the authors to smooth the passage of these
documents through the process.
Every other Working Group Chair I have dealt with has provided this service to
the authors and to the group, and I go out of my way to provide it to the
authors in the groups that I chair, even when it interferes with my
responsibilities in other areas. I feel I owe this to the groups that I chair.
Moreover, it is also your responsibility to nail down such criticisms to
specific issues that can be addressed. It is also your responsibility to
interact with the IESG to whatever extent it takes to turn vague criticism into
specific recommendations for improvement. Calling these documents "shit" is not
productive. In fact, it is really pretty sleazy for you to hide behind the IESG
and IAB in order to be able to characterize the work of others this way.
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.
This just doesn't cut it. If you are too busy to perform the duties of your
position properly you should turn that position over to someone who can. The
IETF isn't exactly human-resource-rich, but I'm sure someone else could have
been found to chair this group.
Alternately, a co-chair could have been added to perform some of these duties.
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.
There is a big difference between "serious concerns" and innuendo and
handwaving. If there are specific issues to address, fine, let's address them.
Ned