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. >> >> >> >> >> >
- Re: Last Call: <draft-sahib-451-new-protocol-elem… S Moonesamy
- Re: Last Call: <draft-sahib-451-new-protocol-elem… Mark Nottingham
- Re: Last Call: <draft-sahib-451-new-protocol-elem… Tim Bray
- Re: Last Call: <draft-sahib-451-new-protocol-elem… Patrick McManus
- Re: Last Call: <draft-sahib-451-new-protocol-elem… Paul Hoffman
- Re: Last Call: <draft-sahib-451-new-protocol-elem… Alexey Melnikov
- Re: Last Call: <draft-sahib-451-new-protocol-elem… Shivan Kaul Sahib
- Re: Last Call: <draft-sahib-451-new-protocol-elem… S Moonesamy
- Re: Last Call: <draft-sahib-451-new-protocol-elem… Shivan Kaul Sahib
- Re: Last Call: <draft-sahib-451-new-protocol-elem… valdis.kletnieks
- Re: Last Call: <draft-sahib-451-new-protocol-elem… Barry Leiba
- Re: Last Call: <draft-sahib-451-new-protocol-elem… S Mooensamy
- Re: Last Call: <draft-sahib-451-new-protocol-elem… valdis.kletnieks
- Re: Last Call: <draft-sahib-451-new-protocol-elem… Matthew Kerwin