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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <iesg-secretary@xxxxxxxx> 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@xxxxxxxx mailing lists by 2018-07-30. Exceptionally, comments may be
sent to iesg@xxxxxxxx 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)

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux