IETF Logo Mail Archive

Re: [Acme] Terms of service agreement changes

Jacob Hoffman-Andrews <jsha@eff.org> Wed, 17 August 2016 17:19 UTC

Return-Path: <jsha@eff.org>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140C912D505 for <acme@ietfa.amsl.com>; Wed, 17 Aug 2016 10:19:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.249
X-Spam-Level:
X-Spam-Status: No, score=-8.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJ21ZoTTOdUU for <acme@ietfa.amsl.com>; Wed, 17 Aug 2016 10:18:52 -0700 (PDT)
Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC3312D94C for <acme@ietf.org>; Wed, 17 Aug 2016 10:18:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=ZkdRDkU8jwu1fuGXuRLsRJ/GZxOvsJpEVWCsnFkS6b8=; b=XAUXsdurZiuPs9QKGhMNt+2ONL9qcFelSns3/oSyYmGLex6p0//5KRdjpDPzmXIqrBm+0IzqDeY8DVOSMcw1wq51tEd37nTtkYulj+QWRWjTESLZwIBgneamgDGyEz7ZkIWn6+l07NTCWhVEimSH8OORCbzHZb35e8iFXo9sA24=;
Received: ; Wed, 17 Aug 2016 10:18:52 -0700
To: acme@ietf.org
References: <627b7240-a9db-7259-6d38-1bad24f80856@eff.org> <20160807123428.GA10284@andover.lhh.devever.net> <CAL02cgQZucvbNCmiTk5Vkn1D3V7VH3F0m5NtXX9GdqznPMtgLw@mail.gmail.com> <CANUQDChYC6zF0VHZ5LcdSxjsc8t6C36hRJx_b8JUUOUVbn8huA@mail.gmail.com> <CAL02cgRHwOHGgLeZLOeEDx3K0EwtfokYkcja4adq3xw0xAj5CQ@mail.gmail.com> <02d7023e-98f6-bd87-f35d-65fb44e62098@eff.org> <20160809194229.GI8744@hex.shelbyville.oz> <801db366-377f-ea94-6b6b-7dd8e2f0c108@eff.org> <cf5a59f2-e8f4-1324-29e7-3977db34f2a2@eff.org> <CABcZeBNZMMxQ6MH_XBPDO2qHHL=MJwGTgzj68sjFNR+m7ik86A@mail.gmail.com> <65fd7564-dda8-883a-662a-21b23f46eb11@eff.org> <CABcZeBO0iAmn0eMROGvwjL3W2ff0LRj0NOHiZSu2_tri-cvA0A@mail.gmail.com> <79122325-9d27-0cae-8858-4efafeee8360@eff.org> <CABcZeBNDnkBwxVHHwVperc-0=O5nJDc1Ute9VnDMedq+HZJTrg@mail.gmail.com>
From: Jacob Hoffman-Andrews <jsha@eff.org>
Message-ID: <575599a0-20e8-1bb1-b21a-26cf1c39d251@eff.org>
Date: Wed, 17 Aug 2016 10:18:50 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CABcZeBNDnkBwxVHHwVperc-0=O5nJDc1Ute9VnDMedq+HZJTrg@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/_haQe5Me0pfaTsXpER8F6fHibaI>
Subject: Re: [Acme] Terms of service agreement changes
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Aug 2016 17:19:00 -0000

On 08/17/2016 10:11 AM, Eric Rescorla wrote:
>     Can you tell me more about what you find confusing? Is it just the MUST?
> 
> The whole text.
>     If so, I'm happy to change it to a SHOULD, with the understanding that
>     the server is likely to reject such requests.
> 
> 
> Again, I'd like to step back from the text a bit. It's not a matter of
> MUST versus SHOULD
> but about what behavior on the part of the client would be needed to be
> compliant. For
> instance, can it send this PDU without ever prompting the user for consent.

Can you propose an alternate text? My intent is not to alter the current
state of things with regards to user consent, but merely to simplify the
protocol. What is the text that, for you, would indicate the exact same
things about user consent as the current draft?

v2.23.0 | Report a Bug | By Email