--On Tuesday, August 11, 2015 16:17 +1200 Brian E Carpenter
<brian.e.carpenter@xxxxxxxxx> wrote:
>...
> The whole point is *symbolic*. What we (the IETF) thought in
> 1995/96 is what we think now, and the choice of RFC number was
> not accidental. Promoting it to BCP, consistently with RFC
> 2026 as I pointed out before, reinforces that nothing in the
> last 20 years has changed the underlying logic.
Sure. I don't think you will find many people who will disagree
with that and I certainly won't be one of them. If anything the
problem has gotten more complex and more important.
Parts of what is said below have been raised by others. I'm
writing this note because I may be able to contribute a slightly
different take on it.
However, for symbolic acts, I think it is important to be clear
about what we are trying to accomplish and how (or if) a
particular move will help with that. As part of that, we
should, at least IMO, be clear in our own minds that the
symbolism is a political/sociological move and far less an
engineering one. In that regard, most of 1984 sticks fairly
close to the engineering. For example "key escrow is a bad idea
because it creates extra security holes" (a reasonable, but not
exact paraphrase) is, in large part, a component of a technical
vunerability assessment rather than exclusively a
political-symbolic one.
If we want to make political statements, the various chess game
analogies apply: it it important to figure out and be explicit
about (at least internally), not only what our goal is but who
the audience is and how various parts of it are likely to
respond. We also, I believe, need to be as explicit about
goals and intentions as possible lest we effectively leave it up
to others to interpret things in their own way.
That leads me to a few conclusions, fwiw....
(1) If the goal of reclassifying this to a BCP is simply to
guide IETF protocol development, I don't think that is
necessary. We haven't had a proposed standards track spec in
more years than I can remember that advocates any of the things
that RFC 1984 argues against. As far as I know, we haven't even
had an independent submission to the RFC Editor advocating such
things. I believe that such a proposal would get very harsh
treatment and that anyone who would be inclined to seriously
initiate either effort knows that (or would find our with
remarkable swiftness). In that sense, RFC 1984 is part of the
IETF culture. Making it a BCP won't make it more so or create a
stronger bar in practice to the work it discourages.
Reclassification may have some symbolic impact outside the IETF
community and its work, but that is a different objective.
(2) If our goal is to make a sociopolitical statement, e.g., by
calling additional attention to the statements in RFC 1984, it
is the worst possible example of justifying a change and calling
attention to it by making a note in the datatracker. We'd be
far better off doing even a rudimentary retrospective (most of
the needed thoughts are already in the tracker justification),
including an explanation of the move and/or what we expect to
accomplish, publishing it in the RFC Series, changing the status
of 1984 as part of its approval process, and then giving both
the new document and 1984 the same BCP number.
(3) Finally, there is the goal question of who we expect to
influence and what the effects might be. It is probably a mark
of 1984's success that it is common knowledge and generally
accepted around the IETF, so changing its status is unlikely to
contribute to our knowledge. If the hope is to influence
governments who are nervous about strong encryption and/or
believe they have the right and maybe even the obligation to spy
on traffic within and across their countries, the odds of our
having a significant positive are, I believe, fairly low. Think
about a legislator standing up in West Snoopovia and saying "the
IETF says we should stop worrying about snooping and encourage
individuals to use encryption strong enough that we can't break
it" and how much influence such a statement is likely to have.
if we could say confidently that our pushing 1984 in the
political sphere might be beneficial in some places and would
otherwise have no ill effects, it would clearly be worth doing
anyway. But suppose the hypothetical government of West
Snoopovia responds by considering the reclassification and
associated publicity to be an attack on them and their policies
(whether that was actually correct or not). That would not
improve the lot of their citizens. It might provide the
incentive (or at least the excuse) for even more restrictive
policies, aggressive surveillance, or even cutting more of their
population off from the Internet -- policies exactly counter to
our presumed desires unless we think that making things worse is
the precondition for improvement or even revolution. The
situation would also give them some additional excuse for
standing up in various international forums and making the claim
that, since the IETF is obviously a puppet of powers and
policies hostile to them and the independence of national
policies, the only acceptable outcome is to more Internet
standards work to some appropriate international body or treaty
organization in which they have a voice rather than having
things rigged against them. Whether that effort succeeded or
not, we probably don't need more countries subscribing to it as
a policy or having what seem to them and like-minded countries
like proof that the IETF is the wrong solution going forward.
We really don't need that, nor do the citizens of West
Snoopovia need us to make a statement whose effect, in their
hands, is to make an already bad situation worse.
So the question that comes directly after "what are we trying to
accomplish?" is "given that it might have costs, are they worth
it?" I'm
having a lot of trouble getting to an unambiguously positive
answer.
best,
john