John K., et al,
Feliz año nuevo; Selamat tahun baru.
I do believe
that it is not desirable to create standards that would give a
gift of either technology or justification to those who would
use them to fragment the network. I believe it is especially
I suspect we will not find anyone in the IETF who thinks otherwise. Certainly
my own reaction to your statement, here, was "Yes!! Absolutely Correct!"
Then I tried to consider the implications of the statement, in the current
context, and I realized that I have no idea what pragmatic import it has.
I have no idea how to apply this caveat to the DKIM work.
DKIM is DKIM. As a technology it has a specific intent and its core is
well-defined -- and actually pretty simple -- with well-understood properties.
The core is similar to a number of technologies that have been in use for at
least 15 years.
So I need to ask that you express your concern as a specific recommendation for
changes to the DKIM charter text, lest this thread be merely
comforting-but-irrelevant (or, worse, -distracting) to the DKIM effort.
On the matter of insisting that specifications document various alerts and
caveats, again we are faced with a dilemma. After all, who could possibly
object to the task of educating potential users of a technology about its
weaknesses?
Yet an open-ended requirement for such warnings a) to my knowledge has no
empirically demonstrated efficacy, and b) often has the real effect of
providing a large barrier with long delays.
That is, we insist on including such discussions out of a sense of professional
responsibility, rather than out of any knowledge that such discussions in IETF
specifications have real utility for the success of those specifications.
The real impact of this barrier is to delay gaining exactly the field experience
that will demonstrate *real* efficacy and *real* problems, rather than imagined
ones.
(It seems to me that this underscores the problematic change in the process of
trying to do work in the IETF, namely that we should raise any and all barriers
based on fear, rather than find ways to facilitate efforts so they gain
field-experience.)
People and companies with those sorts of motivations will
undoubtedly do their thing regardless of what we do. But we
don't need to help them or provide them with justification via
"we are just following the standard".
There are legitimate technical weaknesses in any technology. It is essential to
be aware of them and decide whether they need to be addressed with changes to
the specification of that technology.
However, that is quite different from attempting to engage in analysis of the
psychosocial vagaries that can lead to abuse of an otherwise-legitimate
technology.
The IETF has neither the mandate nor the community skill at conducting such
analyses. Our efforts to perform such analyses is usually marked by an
amateurish FUD ogre and diffusion of constructive effort.
And I still believe that we should do this work.
That's good to hear.
I just believe
that the work should include some real discussion, and analysis
of workarounds, about how uses of the technology that are
interoperability-hostile, or global-communications-hostile, can
Again: This sounds eminently reasonable, until I start to realize that I do not
know what you mean.
If there is agreement on what you say above (I think there
probably is) and it can be documented, then some explicit
warnings about that experience and its applicability would
satisfy most or all of my concerns.
Again: Please translate this into a specific recommendation for charter
language, with appropriate modifications to the schedule. Please include an
explanation for the intended benefit of the work item and the basis for
believing that the benefit will be realized.
d/
--
Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf