Steve, et al,
Given how long this working group has been alive, it's facinating
to see the kinds of debates and confusion still under way. "Facinating"
however, does not mean that work is getting done.
At 11:07 AM 12/29/94, Steve Kent wrote:
articulated. There is more of a sense of this spec being a part of a
larger system, but the larger system is not completely designed.
Alas, much IETF work gets done by pieces. Or at least, the
successful work does. Waiting for all of the parts to the larger system is
intuitively reasonable, and in some scenarios even essential, but rarely
successful in the IETF. Wait for all the pieces to get designed and the
primary work will be waiting.
Some of the arguments that are taking place may be the result
of different participants viewing this spec as a solution to different
problems. If we don't agree on the set of problems being solved, then
we probably can't agree on the solutions.
And this happened for SNMP, MIME, and I'd guess other work. If the
core of such misunderstandings really means that the spec is just bloody
useless, then of course it must not be progressed. If, as I suspect is
true here, there is a clear core of utility and a whole lot of debate about
the boundaries and extensibilities, then it is essential to get the thing
out to a) use it for the core, and b) experiment with boundaries and
extensions. Debating these latter details now only serves to delay; the
debate is not productive.
So, where do we go from here? I have heard arguments that we
must advance this spec as is, or with very minor changes, because the
community desparately needs secure MIME email and if we don't have a
spec, then ad hoc solutions will be forthcoming. This is certainly a
Let me phrase the concern as a basic IETF working group point of
order, rather than in the more abstract analyses of competitive
alternatives: There are some specs on the table. They have been under
development for some time, with the support and guidance of the working
group. To the extent that the latest round of drafts do not reflect the
recent guidance given to the design team(s) then THOSE SPECIFIC POINTS need
to be resolved.
To the extent that new goals, old goals, or other general issues
are now being raised, I submit that they are entirely out of order. Old
goals presumably were debated and resolved a long time ago; otherwise there
would have been no reason to authorize and assist the specification
team(s); in any event, old goals are old business. New goals are for a new
working group (charter).
The current specifications are not newborn. They are the result of
incremental effort and review. The working group needs to treat them as
such, rather than debate philosophies of might-have-beens.
It may make sense to have parallel, incompatible secure email
protocols if the communities served are distinct, but to have
non-interoperable protocols for overlapping communities doesn't seem
so promising. (Ultimately, this is an issue for the security area
director to resolve.)
To get a better idea of what the WG feeling is on this topic,
I plan to hold a non-binding, electronic referendum. No, you won't
have to use secure email to "vote." I'll let you know what the two
Steve, I'm sorry, but this is the wrong question, at the wrong
time, and being asked almost certainly in the wrong way.
The only reasonable path, at this stage of working group effort, is
to review the current specs and either approve them or determine that there
are basic deficiencies that have been introduced in the current round of
writing (or were in earlier drafts and not resolved in the re-write.)
Since these documents represent the usual IETF working group style
of incremental effort, there is a prima facie case in their favor. The
usual means, then, of assessing final disposition is to issue a call to the
working group in a form which presumes acceptability and asks for
showstoppers. This is not particularly a matter of voting as it is a) to
see if there are technical criticism that block functional adequacy and b)
a constituency for the view of a).
Any other style of process, at this stage, serves only to delay and
dissipate the efforts of the group.
d/
--------------------
Dave Crocker
Brandenburg Consulting +1 408 246 8253
675 Spruce Dr. fax: +1 408 249 6205
Sunnyvale, CA 94086
dcrocker(_at_)mordor(_dot_)stanford(_dot_)edu