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

[Tim Bray <[e-mail]>]

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 <[e-mail]> 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
> [e-mail] mailing lists by 2018-07-30. Exceptionally, comments may be
> sent to [e-mail] 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)