Re: Working Group Last Call for draft-ietf-httpbis-legally-restricted-status

[Julian Reschke <[e-mail]>]

Some feedback below:

> 1.  Introduction
>
> ...
>
>    Feedback should occur on the [e-mail] mailing list.


(This should go in the boilerplate, not the actual spec text; and yes, 
the RFC production center will catch it)

> 3.  451 Unavailable For Legal Reasons
>
> ...
>
>    The use of the 451 status code implies neither the existence nor non-
>    existence of the resource named in the request.  That is to say, it
>    is possible that if the legal demands were removed, a request for the
>    resource still might not succeed.
> ...

Might be good if we could avoid talking about existence or non-existence 
of resources.

> 4.  Identifying Blocking Entities
>
>    As noted above, when an attempt to access a resource fails with
>    status 451, the entity blocking access might or might not be the
>    origin server.  There are a variety of entities in the resource-
>    access path which could choose to deny access, for example ISPs,
>    cache providers, and DNS servers.
> ...

If the access was blocked on the DNS level, how would the status code work?

Also: the example should use the link header field.


> 5.  Security Considerations
>
> 5.1.  451 Unavailable for Legal Reasons
>
>    The 451 status code is optional; clients cannot rely upon its use.
>    It is possible that certain legal authorities might wish to avoid
>    transparency, and not only demand the restriction of access to
>    certain resources, but also avoid disclosing that the demand was
>    made.

1) We don't need a nested subsection here. 2) Avoid use of lowercased 
BCP14 terms...

> 6.  IANA Considerations
>
>    The HTTP Status Codes Registry should be updated with the following
>    entry:
>
>    o  Code: 451
>
>    o  Description: Unavailable for Legal Reasons
>
>    o  Specification: [ this document ]

We'll need the IANA considerations for the new link relation as well.

Best regards, Julian