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 <tbray@xxxxxxxxxxxxxx> wrote: > 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: > > 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 > 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. > 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. > > > > 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)
