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

From: S Moonesamy <[email-masked]>
Date: Mon, 02 Jul 2018 08:21:35 -0700

Hello,
At 07:17 AM 02-07-2018, The IESG 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
>[email-masked] mailing lists by 2018-07-30. Exceptionally, comments may be

In the Introduction Section:

   "[RFC7725] was standardized by the IETF in February 2016.  It defined
    HTTP status code 451 ..."

Is the status code which was standardized or does the IETF standardize a RFC?

Are there justifications for the first two recommendations in Section 4?

Shouldn't this draft update RFC 7725 given that it is recommending 
protocol updates?

Was this draft discussed in an IETF Working Group?

Section 7 of the draft is about RFC 7725 instead of this draft.

Regards,
S. Moonesamy

---

From: Tim Bray <[email-masked]>
Date: Mon, 2 Jul 2018 22:17:01 -0700

I object to the publication of this draft in its current form. While I have
specific objections, my largest issue is that RFC7725, as it stands, is
carefully nonspecific as to the form and content of the legal issue that is
motivating the refusal of access, beyond saying that the receipt of a
“legal demand” has occurred.  451 can currently be used when denying access
in a wide variety of legal scenarios. I believe that this is serving a
useful purpose, and that imposing ex-post-facto fine tuning on what “legal
demand” can mean would yield no real benefit and exclude current behaviors
that have positive effect.  Put even shorter: RFC7725 is working as
intended.

Specific comments on the draft:

   1. Section 1: “This draft attempts to explicate the protocol
   recommendations arising out of that investigation.”  Perhaps it’s because
   I’ve been busy and not playing close attention, but issuing RFCs to
   “explicate the protocol recommendations” of other RFCs seems like an
   uncommon practice. Also, the word “explicate” sounds pretentions.
   2. Section 3, 1st bullet point. “A server can return status code 451 to
   indicate that it is denying access to a resource or multiple resources on
   account of a legal demand”  Q: Can a single instance of an HTTP status
   codes apply to multiple resources?  I’ve never used one that way, just
   wondering if it’s possible.
   3. Section 3, 1st bullet point. “the RFC's description does not make it
   clear that the resource being denied access to must be directly mentioned
   in the legal demand”. That's right, because such a specific limitation was
   never contemplated.
   4. Section 4, 1st bullet point: “HTTP 451 SHOULD NOT be used by an
   operator to deny access to a resource on the basis of a legal demand that
   is not specific to the requested resource.”  Why is this a good idea?  If I
   decide to respect a legal demand that I not give access to any resources
   that mention the existence of a certain person, or which are sourced from a
   subdomain of example.com, or from a server whose geographic location
   within the Vatican City, why should I not be able to use 451?  Maybe I’m
   missing something the author of the draft thinks is obvious, in which case
   an example of a “legal demand that is not specific to the requested
   resource” would be helpful.
   5. 2nd bullet point: “HTTP 451 SHOULD NOT be used by an operator to deny
   access to a resource on the basis of a policy specified by the operator (as
   opposed to a legal demand being placed on the operator).”  7725 already
   says that this is to be used in response to a “legal demand”, so what value
   would this change add.  For what it's worth, I'm OK with someone using 451
   in a case where the party is in fear of legal consequences even if they
   haven’t received that demand yet.
   6. 3rd bullet point. The proposal for a new rel=“blocking-authority”
   Link header seems reasonable.
   7. 4th bullet point. Is it actually true that 451 is being
   “increasingly” used in a geographic-block context?  I hadn’t observed that
   but could believe it given evidence.  Anyhow, the proposal for having the
   451 response body include a geographic-scope header might be helpful, but
   the draft is lacking details on the header syntax, which would reduce its
   usefulness for automated processing.
   8. I don’t really understand what Section 7 is for. How would it be
   helpful for implementors?  The assertion in 7.19 about the assumption
   behind the development of 7725 is unwarranted; RFCs say what they say, not
   what some external party thinks what they meant when they said it.

On Mon, Jul 2, 2018 at 7:17 AM, The IESG <[email-masked]> wrote:

> sent to [email-masked] 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-
> protocol-elements/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 3 Jul 2018 15:45:22 +1000

A few points:

* The abstract says this "updates" 7725, but does not have an Updates header. I tend to think that the abstract should replace with something like "adds to". However, see below.

* Overall, the draft reads has a lot of history / context, and not much "new protocol elements." They should be more prominent (e.g., with distinct sections), and the explanatory text and references to the implementation draft should be minimised (note also that if it's a normative reference, it's going to hold up publication of this draft).

* Is Section 3 just a summary of 7725? If so, it should be rewritten to make this clear, and avoid any 2119 keywords. Preferably, the section should be deleted, since it's just repeating 7725.

* I don't see how the first two recommendations in Section 4 are going to be effective. They're not testable, they're only SHOULDs, and they're not very precise. If you want to refine the semantics of 451, you need to re-specify the status code (i.e., there should be a section with a title something like "451 (Unavailable For Legal Reasons) HTTP Status Code", and the document *would* need to update (or more likely, obsolete) 7725. However, that's *not* just "new protocol elements."

* What is an "operator" in this context -- network operator, server operator?

* Why is the requirement for blocking-authority a SHOULD?

* What kind of URLs do you expect to be used in blocking-authority; is it the HTTP Web site of the jurisdiction, or that of the court? Which court, if there are multiple appeals? Or a page describing the judge? Or a URN?

* I have every sympathy for the goals of RFC8280, but I don't see how Section 7 adds to this specification; it's an assessment that's important to do, but what value does recording the results in the specification have? 

Cheers,

> On 3 Jul 2018, at 12:17 am, The IESG <[email-masked]> wrote:
> 
> 
> sent to [email-masked] instead. In either case, please retain the beginning of
> https://datatracker.ietf.org/doc/draft-sahib-451-new-protocol-elements/ballot/
> 
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Patrick McManus <[email-masked]>
Date: Tue, 3 Jul 2018 10:51:23 -0400

>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-
extensions/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

---

From: Shivan Kaul Sahib <[email-masked]>
Date: Tue, 3 Jul 2018 10:23:23 -0700

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 <[email-masked]>
wrote:

> 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.
>

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 3 Jul 2018 18:56:42 +0100

Hi Patrick,

A couple of questions:

On 03/07/2018 15:51, Patrick McManus wrote:
> 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-extensions/draft-ietf-httpbis-variants.html#variants 
> <https://httpwg.org/http-extensions/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.

If not in HTTPBIS, then where? I don't see energy in creating a new WG 
to work on this.

Is it better to publish this document than not publish it at all?

Best Regards,
Alexey
> -Patrick
>
>
> On Mon, Jul 2, 2018 at 10:17 AM, The IESG <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     [email-masked] <mailto:[email-masked]> mailing lists by 2018-07-30.
>     Exceptionally, comments may be
>     sent to [email-masked] <mailto:[email-masked]> instead. In either
>     case, please retain the beginning of
>     <https://www.irtf.org/mailman/listinfo/>
>        hrpc [1] and
>     https://lists.ghserv.net/mailman/listinfo/statuscode451
>     <https://lists.ghserv.net/mailman/listinfo/statuscode451>
>        [2].
>
>
>
>
>     <https://datatracker.ietf.org/doc/draft-sahib-451-new-protocol-elements/>
>
>     <https://datatracker.ietf.org/doc/draft-sahib-451-new-protocol-elements/ballot/>
>
>

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 03 Jul 2018 11:20:54 -0700

On 3 Jul 2018, at 10:56, Alexey Melnikov wrote:

>> 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.
>

There was a lot of active discussion that went into RFC 7725 becoming a 
standard: if there is not enough energy to discuss a draft that is meant 
to update this standard, then that's a good indication of what to do 
with the draft.

> Is it better to publish this document than not publish it at all?

It would be better to not even consider publishing it until it has had 
much more discussion. Tim's statement earlier is spot on: RFC7725 is 
working as intended. Any proposed update to that standard either must 
have as much (hard-fought) consensus or should be dropped.

---

From: S Moonesamy <[email-masked]>
Date: Tue, 03 Jul 2018 13:53:54 -0700

Hi Alexey,
>Is it better to publish this document than not publish it at all?

The draft needs more work [1] before a decision about publication is taken.

Regards,
S. Moonesamy

1. Reviews are useful to catch the usual issues so that the Last Call 
is not too difficult.

---

From: [email-masked]
Date: Tue, 03 Jul 2018 20:47:18 -0400

On Mon, 02 Jul 2018 22:17:01 -0700, Tim Bray said:
>    within the Vatican City, why should I not be able to use 451? 

Amen to that.  If anything, it's *vastly* more likely that the legal demand
won't be specific to just that one object, but will cover a large number of
objects (possibly into the thousands or millions).  There's no sense in
allocating a return code for the presumably rare "a request was made to block
exactly one object" case, and not allocate one for "a request was made to block
every object of type FOO".  For example, I've never seen Google reply with
"exactly one response was filtered" - if there's *any* hits, there's usually
*multiple* hits.

Perhaps "on the basis of a legal demand that is not directly applicable to
the specific requested resource" would be better?  Or other wording that makes
it clearer that 451 can be used for any case where you have an object that you
can't serve up?

On Tue, 03 Jul 2018 10:23:23 -0700, Shivan Kaul Sahib said:
> deny access" to the resource.

If they can't provide access to a EU resident because they aren't GDPR
compliant (and thus have an actual legal exposure to penalties if they 
provide access anyhow), they have two choices:

1) Deny access
2) Face the legal exposure.

You're going to have a really hard time explaining how a "Deny access to this
copyrighted information or face legal consequences" takedown notice is a legal
demand, and "Don't allow access that involves non-GDPR compliant data or face
legal consequences" isn't a legal demand.  Maybe a lawyer understands the
difference, but it's a strong bet that the person who has to actually maintain
the list of 451-blocked objects won't.

> would be helpful for people seeking to use the status code.

I'll note that "demand that the resource be taken down" is subtly different
from "demand that the resource not be available" (in particular, if it's being
made *conditionally* unavailable to some users, but potentially still accessible
to other users).

This part of the draft is problematic as well:

      demand.  Note that while the introduction of [RFC7725] mentions
      that the legal demand for denial of access should be related to
      the resource being requested, the RFC's description does not make
      it clear that the resource being denied access to must be directly
      mentioned in the legal demand.

That's because in most countries, when the legal document arrives, it quite
likely *won't* itemize 48,374 separate URLs to fulfill a "directly mentioned"
requirement. It will have terms like "any and all documents concerning
<specific definition of documents involved>".  And that's because if the legal
document says:

"Block access to https://www.example.com/this_data_is_banned.txt"

all they have to do is rename it to 'this-data-is-banned.txt", fix links to it,
and we're playing whack-a-mole.  And it's guaranteed they can rename the file
and fix the links faster than you can go back to the judge and get a new order
signed.  Especially the 7th or 8th time in a 48 hour time span.  So the legal
order will often *not* "directly mention" the resource, but will instead give a
*description* of the object sufficiently specific to allow identification of
same.

Overall, I'm having a *really* hard time seeing how redefining 451 to only
apply to resources that have been directly identified in the legal demand
improves the situation over RFC7725.

---

From: Shivan Kaul Sahib <[email-masked]>
Date: Tue, 3 Jul 2018 18:24:40 -0700

Hi,

The intention of the draft asking for resource identification in the legal
demand was *not* to say that the resource has to be named - like I said,
the Vatican example was fine.
In any case, as previously mentioned I've updated the doc to recommend only
the geographical scope and the blocking authority headers. Would love if
folks have specific feedback about the two additional headers and how they
should be served.

Unfortunately, can't upload the updated doc until later this month.

On Tue, Jul 3, 2018 at 5:47 PM <[email-masked]> wrote:

> >    4. Section 4, 1st bullet point: â€œHTTP 451 SHOULD NOT be used by an
> >    is not specific to the requested resource.â€   Why is this a good
> idea?  If I

---

From: Barry Leiba <[email-masked]>
Date: Wed, 4 Jul 2018 15:34:02 +0900

I have to agree with Tim here.  I'll note that 7725 was also going to
be AD-sponsored (by me), but ultimately went to HTTPbis.  It had a
*lot* of discussion in the process, and I did not agree to sponsor it
at first.  It was more than three years in the making.

I think it's a bad idea to AD-sponsor this attempt at updating it.  I
also think a major strong point of 7725 is that what it specifies is
simple and very general, and does *not* try to specify details of what
"legal restrictions" means, or what kinds of legal issues are
appropriate.

Please do not send this to the IESG.  I would much rather see this not
published, and to leave 7725 as it stands, with the community
consensus that it has.

Barry

On Tue, Jul 3, 2018 at 1:17 AM, Tim Bray <[email-masked]> wrote:
> motivating the refusal of access, beyond saying that the receipt of a “legal
> demand” has occurred.  451 can currently be used when denying access in a
> wide variety of legal scenarios. I believe that this is serving a useful
> purpose, and that imposing ex-post-facto fine tuning on what “legal demand”
> can mean would yield no real benefit and exclude current behaviors that have
> positive effect.  Put even shorter: RFC7725 is working as intended.
>
> Section 1: “This draft attempts to explicate the protocol recommendations
> arising out of that investigation.”  Perhaps it’s because I’ve been busy and
> not playing close attention, but issuing RFCs to “explicate the protocol
> recommendations” of other RFCs seems like an uncommon practice. Also, the
> word “explicate” sounds pretentions.
> Section 3, 1st bullet point. “A server can return status code 451 to
> account of a legal demand”  Q: Can a single instance of an HTTP status codes
> apply to multiple resources?  I’ve never used one that way, just wondering
> if it’s possible.
> Section 3, 1st bullet point. “the RFC's description does not make it clear
> that the resource being denied access to must be directly mentioned in the
> legal demand”. That's right, because such a specific limitation was never
> contemplated.
> Section 4, 1st bullet point: “HTTP 451 SHOULD NOT be used by an operator to
> deny access to a resource on the basis of a legal demand that is not
> specific to the requested resource.”  Why is this a good idea?  If I decide
> to respect a legal demand that I not give access to any resources that
> mention the existence of a certain person, or which are sourced from a
> subdomain of example.com, or from a server whose geographic location within
> the Vatican City, why should I not be able to use 451?  Maybe I’m missing
> something the author of the draft thinks is obvious, in which case an
> example of a “legal demand that is not specific to the requested resource”
> would be helpful.
> 2nd bullet point: “HTTP 451 SHOULD NOT be used by an operator to deny access
> to a resource on the basis of a policy specified by the operator (as opposed
> to a legal demand being placed on the operator).”  7725 already says that
> this is to be used in response to a “legal demand”, so what value would this
> change add.  For what it's worth, I'm OK with someone using 451 in a case
> where the party is in fear of legal consequences even if they haven’t
> received that demand yet.
> 3rd bullet point. The proposal for a new rel=“blocking-authority” Link
> header seems reasonable.
> 4th bullet point. Is it actually true that 451 is being “increasingly” used
> in a geographic-block context?  I hadn’t observed that but could believe it
> given evidence.  Anyhow, the proposal for having the 451 response body
> include a geographic-scope header might be helpful, but the draft is lacking
> details on the header syntax, which would reduce its usefulness for
> automated processing.
> I don’t really understand what Section 7 is for. How would it be helpful for
> implementors?  The assertion in 7.19 about the assumption behind the
> development of 7725 is unwarranted; RFCs say what they say, not what some
> external party thinks what they meant when they said it.
>
>
>

---

From: S Mooensamy <[email-masked]>
Date: Wed, 04 Jul 2018 03:01:43 -0700

Hi Shivan,
At 10:23 AM 03-07-2018, Shivan Kaul Sahib wrote:
>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).

I read the IRTF implementation report.  The observations from the 
commercial service returned 526 hosts returning a "451".  The few 
hosts I tested returned a "451" only.  However, it was not clear 
whether it was an incorrect implementation of the "451" specification 
or the status code was used as a "403".

For what it is worth, the author of the 1953 book commented that the 
book was not about censorship.

>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.

There were two media groups from the United States which blocked 
access from the European Union to their news sites.  There is a paper 
which argued that it was more about exiting that market instead of 
legal obstacles.

The draft has a normative reference to an erratum.  In 2008, it was 
stated that 'there may be a temptation to use errata to "fix" 
protocol design errors, rather than publishing new RFCs that update 
the erroneous documents'.

Regards,
S. Moonesamy

---

From: [email-masked]
Date: Thu, 05 Jul 2018 12:11:45 -0400

Unfortunately, that's not my reading of this text:

> "HTTP 451 SHOULD NOT be used by an operator to deny access to a resource on
> the basis of a legal demand that is not specific to the requested resource.

A legal request to block "anything from East Wombat" isn't specific to the
requested resource. It may cover that resource, and 38,915 other resources.

If a news item saying "all people in <insert town you are in> should seek
immediate shelter from an oncoming tornado", would you call that *specific to
you* (which it isn't, as it covers every other person in the town as well), or
merely *applicable* to you?

That's why I suggested "not applicable to the requested resource".

---

From: Matthew Kerwin <[email-masked]>
Date: Fri, 6 Jul 2018 12:48:02 +1000

> requested resource. It may cover that resource, and 38,915 other resources.

It still specifies the requested resource.  Is the specificity of the
specification ambiguous?  It's not like it says "...not specific
specifically to the requested resource."

> merely *applicable* to you?

I'd say it's specific to me, and not to my friend the next town over.
I'm not *that* special.

> That's why I suggested "not applicable to the requested resource".

That seems to resolve an ambiguity that I hadn't seen to be present before this.

Cheers
-- 
  Matthew Kerwin
  https://matthew.kerwin.net.au/