Re: [saag] Fwd: Last Call: Recognising RFC1984 as a BCP

[John C Klensin <[e-mail]>]

Stephen,

One more comment and then I think I would like to be recorded as
not being in favor of reclassification, especially one done this
way, but will move on.

--On Wednesday, August 12, 2015 13:25 +0100 Stephen Farrell
<[e-mail]> wrote:

>> Changing the status seems to fill a well-needed gap, and I
>> suspect that it’s just a rationalization to be able to
>> make the political statement. If someone should argue in the
>> future for the IETF to support nastiness, that’s the
>> time to confirm that we have consensus not to do that, and to
>> write that down in the form of an IETF BCP. In other words, I
>> don’t buy this as a justification.
> 
> So we disagree about that, which is fine. I do think some
> insurance here is a worthwhile goal. I hope that you do agree
> that this is something about which reasonable folks can
> reasonably disagree?

Sure.  But if "insurance" is the motivation, I note that it does
not appear as motivation in the
"status-change-rfc1984-to-best-current-practice-00" writeup.
More important, I question what effect you think it would have.
Anything said in any RFC, regardless of status, can be
overridden by a replacement RFC if the latter gets consensus.
We have no policies or procedures that could be used to prevent
an I-D from being posted and discussed even if it contradicted
an existing BCP (or, for that matter, proposed a protocol that
would work only with changes in the speed of light).    So, in
particular...

>...
> I also think that if any new mandatory key escrow proposals do
> reach the IETF, then it will not simply be one person
> proposing an I-D. It'd likely be a whole bunch of companies
> and an industry consortium all pushing for doing something bad
> because their customers/govts say they have to, so I would
> prefer that we had the discussion now while we can do that
> without the commercial pressures that would be involved if we
> did wait until a crowd turn up with those bad ideas.

So we either maintain 1984 in its current status or we promote
it to BCP.  Then, in a few years, that "whole bunch of companies
and industry consortium" come along and say "we want to do this
and we want to do it in the IETF".  More likely (and consistent
with the above), they say "we are being forced by our
governments and customers to do this and we think that, if we
can do it in the IETF, the community can help to find a way to
do it that maximizes interoperability and minimizes damage even
though you and we would rather not have it happen at all".
Certainly the debate that followed would be "interesting" and
probably heated.  Certainly some people would cite 1984 (whether
it was a BCP or just Informational).  However, unless we had
gone completely nuts by then, I'd assume (or at least hope) that
we could have an intelligent discussion in which the moral
purity of avoiding that sort of work would be weighed against
minimization of damage to the working Internet.  

At the risk of being slightly pessimistic but very pragmatic, if
the relevant bunch of companies collectively employed (or
supported) a significant fraction of the IESG and were
determined to make the IETF take the work on, I'd predict that
either we've have an open, and more or less clean-slate,
discussion of the issues and tradeoffs or we'd end with with
enough sponsor/employer-forced resignations to paralyze the IESG
for an extended period.... and that whether 1984 was or was not
a BCP would have no effect on those scenarios at all.

As I suggested in a slightly different context a few days ago, I
hope that, if we are ever faced with the option of "helping"
people by getting them disconnected from the Internet because
they can't access it in the way we would like, we consider those
tradeoffs rather carefully.  Again, faced with that choice, 1984
(regardless of status) would be useful input, but it is hard to
imagine a classification decision made today (one way or the
other) changing the outcome significantly.

> But that's the thing about insurance in cases like this where
> there's no good way to estimate the probability of bad
> outcomes: we won't know for sure we need it until it's too
> late.

Again, I might feel differently about this if I saw real
"insurance" value and the ability to insure against future
changes in our environment.   But, again following your
description above, I'd expect, at best, the following sequence
of events:

 (1)
	draft-PeopleWhoWorkForABunchOfCompanies-Enforcing-Key-Es
	crow-00 gets posted, updating several X.509, TLS,
	S/Mime, and other specs.
 (2) You, SAAG, and/or the IESG say "you can't do that, it
	violates RFC 1984, which is a BCP".
 (3)
	draft-PeopleWhoWorkForABunchOfCompanies-Enforcing-Key-Es
	crow-01 gets posted, adding to the earlier text "updates
	1984" and explaining that the circumstances that
	justified it have changed.

then, maybe,

 (4) You, or your successor, try to assign that draft to
	a WG that is loyal to 1984 and hostile to the idea of
	key escrow or some other example of badness.  
 (5) A Bunch of Companies (or people working for them)
	appeal that decision as preempting any realistic
	community discussion that could lead to consensus and,
	in the process and, as part of the appeal, demand that
	none of a list of specific ADs be allowed to be
	responsible for the WG that should be created because
	they had already shown themselves as unalterably opposed
	and rigid about the outcome.

Regardless of the outcome of that appeal, the IETF and the
Internet probably lose.   If things get sufficiently nasty,
those companies say, possibly without bothering to appeal or
waiting for the outcome if they do, "the IETF has become
unresponsive to the operational realities of the Internet, we
know where we can have a discussion of these issues and develop
standards".   Then they withdraw all support for IETF
participation, all sponsorship of meetings, etc., and take their
work to the ITU.   That would leave us in a state of grace
because we didn't violate our 1984-enshrined principles.  It
would also leave us out of business.

Now I wouldn't expect scenarios nearly that dramatic to unfold,
partially because I think we are, as a group, more sensible than
to get trapped in that sort of situation.  But the point is that
your "insurance" does nothing to constrain the decision in the
way I'd assume you would like, nor would it mitigate the
consequences.  

Indeed, if that bunch of companies, etc., are what you are
concerned about, we are probably better off without 1984 as a
BCP.  With its current status, the IESG and the community are in
a very strong position to say "We have a set of principles,
described in RFC 1984, that say we don't intend to do that sort
of work. Do you really think circumstances have changed enough
that we should either revisit the principles or make an
exception, and if so how?".   It seems to me that could be the
beginning of a healthy discussion.  By contrast, if a BCP can be
used to justify a "we can't do that work under any
circumstances" position, it guarantees an adversarial
interaction, probably with exactly the companies whose support
and products we need to keep working and to continue to be
credible.

    john