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

[Barry Leiba <[e-mail]>]

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 <[e-mail]> 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 <[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)