Re: Last Call: <draft-sahib-451-new-protocol-elements-01.txt> (New protocol elements for HTTP Status Code 451) to Informational RFC

Shivan Kaul Sahib <shivankaulsahib@gmail.com> Tue, 03 July 2018 17:24 UTC

Return-Path: <shivankaul.1993@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8A2130F43; Tue, 3 Jul 2018 10:24:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_RED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 E9wkAyYwYijd; Tue, 3 Jul 2018 10:24:07 -0700 (PDT)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC81130FCF; Tue, 3 Jul 2018 10:24:06 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id q5-v6so2163790ljh.12; Tue, 03 Jul 2018 10:24:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=0xSIrHWSMbgWaYIDaA8nkodmZfz3hGfTKrySwhuXub0=; b=vUF4gvbjJoZXq+SvdFffMVeFnUtI7bJml5XWb2jG8UZWcirUScv+evjAZQnynqVJkc SsHSL0T8HEmUJUhySGBdDFAb/BRuFDiwhITKkLjUNte5n5G74/oYu36OJXaL7G523UDd +xLR41/RvhFAM9jO5OTzbFa9a4ItBGt3b3TWyBXU+5PZppNomir5tFZUtE2CijI8SlIg 5LnWcbeccrBQI+qR1vwYK54VVshi/rL6yj6l/CxhiokyL3b4lLKuPkp0wpcvtxVjoCbH dCFdvtKLfM8iSlUj1Jw30An3hTTvrCr/kSHqtk8MPD0AwART5tP5lnIa8593S20H/4Gc wVNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=0xSIrHWSMbgWaYIDaA8nkodmZfz3hGfTKrySwhuXub0=; b=hGaOyPUq6JC9C5dMrbUT6+uiHFfWPGpkLtyCTZCDm4dgZkeFoMw6QPVU6Yvx2ScbMk Urlnz1IDqpVQ8sN6VAtbPAsyQX0i3NxyvJe1yZGb6r7k0EXkpZdkBvmT9ZlE+q4A3xev HkwXpXDxIzQH9uohZahgZy1IFAWn39EE+ZfwTOtKGF+Jx2YDNiA53JvJ8ybGjrIJ5uHk 4YZvO0Y9d1VxJJej/KwyO2dXKMxNjNnQEvOpTWfpcqm0bNqPMo/WS+asD/QOml6Fygqt dGM8gSm1u9hIqIMWIpvOW7k9fjLn5qtYpugBX3mjDj7g7ZHiIAoly6O4K2nq8wg/xX3F 3OUQ==
X-Gm-Message-State: APt69E1EZ47uSYm4TZn20niA6D16ZLLbwIAk1xozyD/cdZeSFgK1p0dg ugFiiDBEvFlRYg6TO8RN4AVMQPU6eACw5G8x1Vg=
X-Google-Smtp-Source: ADUXVKLBt9Kgo543FZTppT5EavbwnSvVWgV8S1W0YqyIoP0veyF84PT1Zof1/3GNM0kESwWTCPKO9Fqk0PEnllV56Zc=
X-Received: by 2002:a2e:944e:: with SMTP id o14-v6mr19706340ljh.118.1530638644372; Tue, 03 Jul 2018 10:24:04 -0700 (PDT)
MIME-Version: 1.0
Sender: shivankaul.1993@gmail.com
Received: by 2002:a2e:9718:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 10:23:23 -0700 (PDT)
In-Reply-To: <CAOdDvNqSCWPtNM=08PA-NAO24gJ6LcOsxzsVwraRMu7ta086YA@mail.gmail.com>
References: <153054106529.16082.5456844530797164969.idtracker@ietfa.amsl.com> <CAOdDvNqSCWPtNM=08PA-NAO24gJ6LcOsxzsVwraRMu7ta086YA@mail.gmail.com>
From: Shivan Kaul Sahib <shivankaulsahib@gmail.com>
Date: Tue, 03 Jul 2018 10:23:23 -0700
X-Google-Sender-Auth: 5Wmgtd8TlGTfD-QMLGplBTVFqbQ
Message-ID: <CAG3f7Mj7k_xcGn7xKa2CDV2=ZtaowLFM+q2gK7yMK55V1U0BHg@mail.gmail.com>
Subject: Re: Last Call: <draft-sahib-451-new-protocol-elements-01.txt> (New protocol elements for HTTP Status Code 451) to Informational RFC
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: IETF Discussion Mailing List <ietf@ietf.org>, IETF-Announce <ietf-announce@ietf.org>, draft-sahib-451-new-protocol-elements@ietf.org, Alexey Melnikov <alexey.melnikov@isode.com>
Content-Type: multipart/alternative; boundary="000000000000ad71d805701b94c4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/BjZeRq-Ss8aDoF3ubv5AhmwWv5k>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jul 2018 17:24:11 -0000

Hi all,

This draft was created so as to make HTTP 451 more useful for:
- web platforms and websites that get legal requests to take down content
- researchers who are interested in using the code to get more information
about content takedown

The recommended "updates" are a result of talking to parties from both
groups. The reference IMPL_REPORT_DRAFT is the report of an investigation
into how HTTP 451 is being used currently (I'll update the draft to make it
an informative reference and reduce mention of it).

- Section 7 (human rights implications of HTTP 451) was added to show the
use of RFC8280's recommendations to examine a protocol that has human
rights impacts. At this stage of the process, however, it makes sense that
it is removed and perhaps published as a separate draft.

- The draft was discussed in the Human Rights Protocol Considerations
(HRPC) Research Group (as noted in the Abstract) and also briefly in the
HTTP WG.

- Regarding specificity of "legal demand": RFC 7725 opens with:

   "This document specifies a Hypertext Transfer Protocol (HTTP) status
   code for use when a server operator has received a legal demand to
   deny access to a resource or to a set of resources that includes the
   requested resource."

HTTP 451 is being used to block users who reside in the European Union by
websites that are not GDPR-compliant. There is no real "legal demand to
deny access" to the resource. The examples given by Tim ("any resources
that mention the existence of a certain person", etc) are all fine, as they
actually relate to the resource being denied.
Perhaps this is splitting hairs. However, in talking to server operators
actually implementing this status code, confusion leads to them not using
the status code when it would be beneficial (to users, to researchers) for
them to use it. If we think that the status code should be used for
compliance with *any law whatsoever*, even if the law doesn't actually
demand that the resource be taken down, then perhaps making that clear
would be helpful for people seeking to use the status code.

But Mark's point about this draft being "new protocol elements" and not "an
update to the RFC" makes sense. I will remove this point.

- Agreed about the "policy specified by the operator" point not adding
much. Updated.

- For "blocking-authority": Ideally this would link to a legal notice that
clearly mentions the blocking authority.

- Both "blocking-authority" and "geo-scope-block" are SHOULDs because the
draft is recommending elements. If there are good reasons for not having
these links (e.g. the specific government/court does not allow it) then
it's fine to not have them - some information about a block is better than
none (404). The original "blocked-by" is also a SHOULD.

- geo-scope-block was kept deliberately simple and limited to country-codes
so as to not make matters too complicated for web platforms seeking to do
the right thing by giving more information about a block. The
IMPL_REPORT_DRAFT reference provides some evidence of country-based
blocking. Also see https://transparency.automattic.com/country-block-list/.
Other major web platforms such as Reddit and GitHub similarly are forced to
block subreddits and repos in certain countries.

- Updated draft to provide less context and highlight the proposed elements
more.


Thanks,
Shivan

On Tue, Jul 3, 2018 at 7:51 AM, Patrick McManus <pmcmanus@mozilla.com>
wrote:

> From an HTTP pov: new response headers, such as the proposed
> geo-scope-block, would really benefit from a more rigorous syntax than is
> provided here..  see: sections 2 and 3 of https://httpwg.org/http-extens
> ions/draft-ietf-httpbis-variants.html#variants for how a current wg draft
> does it. Also, its composition of a list of country codes should probably
> be a MUST as Tim hints.
>
> Tim's concerns resonate with me as questions a WG really should debate and
> reach rough consensus on rather than this being an AD sponsored doc
> (especially as its a defacto update of a standards track document by an
> informational one). I'm not sure which WG - httpbis did not have a critical
> mass of interest in this in the past.
>
> -Patrick
>
>
>
> On Mon, Jul 2, 2018 at 10:17 AM, The IESG <iesg-secretary@ietf.org> wrote:
>
>>
>> The IESG has received a request from an individual submitter to consider
>> the
>> following document: - 'New protocol elements for HTTP Status Code 451'
>>   <draft-sahib-451-new-protocol-elements-01.txt> as Informational RFC
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final
>> comments on this action. Please send substantive comments to the
>> ietf@ietf.org mailing lists by 2018-07-30. Exceptionally, comments may be
>> sent to iesg@ietf.org instead. In either case, please retain the
>> beginning of
>> the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>    This draft recommends protocol updates to Hypertext Transfer Protocol
>>    (HTTP) status code 451 (defined by RFC7725) based on an examination
>>    of how the new status code is being used by parties involved in
>>    denial of Internet resources because of legal demands.  Also included
>>    is an analysis of HTTP 451 from a human rights perspective using
>>    guidelines from RFC8280.
>>
>>    Discussion of this draft is at https://www.irtf.org/mailman/listinfo/
>>    hrpc [1] and https://lists.ghserv.net/mailman/listinfo/statuscode451
>>    [2].
>>
>>
>>
>>
>> The file can be obtained via
>> https://datatracker.ietf.org/doc/draft-sahib-451-new-protocol-elements/
>>
>> IESG discussion can be tracked via
>> https://datatracker.ietf.org/doc/draft-sahib-451-new-protoco
>> l-elements/ballot/
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>>
>>
>>
>>
>