Re: Proposed Statement on "HTTPS everywhere for the IETF"

John C Klensin <> Wed, 03 June 2015 22:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 03D051B302B for <>; Wed, 3 Jun 2015 15:49:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1dkNMOiyf-vD for <>; Wed, 3 Jun 2015 15:49:38 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7BE601B3003 for <>; Wed, 3 Jun 2015 15:49:38 -0700 (PDT)
Received: from [] ( by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1Z0HTc-00087T-Vx; Wed, 03 Jun 2015 18:49:36 -0400
Date: Wed, 03 Jun 2015 18:49:31 -0400
From: John C Klensin <>
To: Stephen Farrell <>,
Subject: Re: Proposed Statement on "HTTPS everywhere for the IETF"
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Jun 2015 22:49:40 -0000

Hmm.  Let me try to make my main point in another way, and then
I'll follow my own advice and drop back out of this

--On Wednesday, June 03, 2015 22:08 +0100 Stephen Farrell
<> wrote:

> On 03/06/15 21:42, John C Klensin wrote:
>> So how modest and minor do you really think it is?
> It's minor in terms of impact on users and current web content.
> But less so perhaps as setting the default we want to use for
> other cases in future as those arise. And it impacts on tooling
> as well (e.g. the URLs in the boilerplate produced by xml2rfc,
> and in the tracker) and it impacts on the secretariat in minor
> ways (URLs embedded in mails they send out).
> The above and the fact that we do have a set of IETF folks
> who seemingly don't like any of this are I think reason enough
> for the iesg to solicit comment before just adopting something
> like this, or just putting it in place without that.
> Personally, I do wish we didn't have to have essentially
> the same points discussed over and over, but it seems we
> do.

Let me suggest a bit of cost-analysis arithmetic.  IESG and
other community members regularly complain that there are too
few thoughtful and competent reviews of standards track specs on
Last Call.   This topic has generated a lot of messages, plus
even more messages associated with the (probably inevitable)
spinoffs and side-threads.  It is possible that many of the
people commenting just like process arguments and wouldn't be
doing useful work anyway but, from looking at the names, I don't
think that is generally true.  To pick a completely arbitrary
number, assume that, had this thread not started, 10% of the
comments (or even 10% of the respondent count) might instead
have gone into reviews of standards-track technical specs.
Would you think the discussion worth it?  Would your answer
change is the question hypothesized 20%?  5%?

The question is rhetorical, but the issue of allocation of
resources is not.   Unlike the references to existing materials
that have been the focus of most of the comments, some of the
examples you give really could have consequences for
accessibility of materials in the future.  The point is that
change --both discussing the changes and making them-- has
costs.  Even if I saw much more positive value in this proposed
action than I happen to do (I do see some, and am not opposed,
but...), I don't think you have made a persuasive case that the
costs of discussing and making the change are worth it in terms
of opportunity costs within the community and its workload.

I sometimes wish the community were willing to give the IESG a
lot more flexibility to just make decisions, that the IESG were
willing to take the responsibility that goes with that rather
than feeling a need to ask questions (but know that they would
be held accountable for getting things wrong), and that there
were convenient and efficient ways for the community to express
the equivalent of a "no confidence" vote in the IESG (not
individuals) if things got sufficiently out of synch.