Re: bozoproofing the net, was The Value of Reputation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]