Re: RFC7725bis new elements

> Blocking Authority.
> 1. While it makes sense to identify the Blocking Entity with a URI -
> presumably it has an online presence - the nature of the Blocking Authority
> could be any of multiple levels of government or a trade association or the
> operator of a building complex or almost any other imaginable entity. I
> think that this is best described in textual human-readable form so as to
> be actually useful to the party whose access is being blocked. 7725 already
> provides a place to put this information and illustrates it with an
> (admittedly whimsical) example.
> 2. I haven't seen much in the way of evidence to suggest that this would
> be adopted if it were specified. Maybe I just missed it?
>

This errata outlined why "blocked-by" in RFC 7725 was confusing for
implementers: https://www.rfc-editor.org/errata/eid5181.
"blocking-authority" seemed like a good idea because there is often a
distinction between the entity who mandates the block and the entity doing
the blocking, which is probably why implementations varied between the two.
https://tools.ietf.org/html/draft-irtf-pearg-censorship-04#section-4.1 goes
into some depth regarding the various points of control a censor exercises.

In terms of adoption: at the time the new protocol elements draft was
introduced, Automattic and GitHub had recently started serving 451 and the
draft incorporated informal feedback from engineers on their policy teams.
I can try to reach out to them if they'd still be interested.

>
> Geographical Scope of Block
> 1. I don't think country codes are going to do it, given that this could
> be done at the regional or municipal level, or the scope might be expressed
> by geofencing.
> 2. Same as before - what evidence do we have that this would be adopted
> were it provided?
>

The country code vs something more expressive was debated for a bit. It
seemed that most blocks were country-scoped - governments interested in
censoring often have dedicated ministries for this sort of stuff:
https://tools.ietf.org/html/draft-irtf-pearg-censorship-04#section-3. Given
that 451 is often used by service providers (at least, the largest
centralized deployments) trying to proactively provide more information,
and the fact that the implementation report (
https://tools.ietf.org/html/draft-451-imp-report-00) found that the
information provided in the status code response varied heavily in the
quality of the information provided, the decision was made to keep it
simple, if coarse. Happy to hear suggestions about this, though (for that
matter, about anything else in the draft.)

In addition, like mentioned above, one of the main implementers at the time
was Automattic, and they'd been using 451 to report country-scoped blocks
documented here: https://transparency.automattic.com/country-block-list, so
it seemed immediately useful.