I've already commented on this before being assigned the SecDir review, but I'll add further comment here.

Basically, I object to handling this as an AD-sponsored Informational document, which updates a working group product that is Standards Track.  I also object to complicating a protocol element that was intentionally devised as very simple.

That said, I don't object to everything in the document, and if the 2119 key words were removed we could salvage things.  Looking at the recommendations in Section 4:

- I object to the first recommendation on the grounds that it makes no sense that I can determine, and whatever sense I do try to make of it seems wrong.  If the legal demand is "don't return any information about pangalactic gargle-blasters (PGBs)," does that meet the specificity requirement for (1) the Wikipedia page on PGBs, (2) an Amazon listing for a PGB for purchase, (3) a blog post about "The "Hitchhiker's Guide to the Galaxy" that mentions intergalactic drinks, (4) *any* web page that has the string "pangalactic gargle-blaster" in it, regardless of the other content?  If the legal demand is not to provide any content whatsoever to users outside the solar system, such that every request from Alpha Centauri gets a 451, why should we not use 451 for that?  Please let's strike this recommendation.

- The second recommendation is simply not necessary: RFC 7725 is clear on this, and if operators are doing otherwise there's no reason to think that a sentence in an Informational document will change anything.  Let's please strike this one as well.

- The third and fourth recommendations, and the link relation definition and header that go with them, are benign enough: we can see whether they get deployed or not.  If we removed the "SHOULD"s and made it clear that this is suggested as a means to add more information, and is not part of the standard, I'd not object to registering them and including the recommendations.

In Section 7.2, I suggest a change such as this:

OLD
   HTTP 451 is used as a response when the client requests a resource
   that's unavailable because of legal reasons.  Consequentially, there
   are potential privacy (and anonymity) ramifications if there is
   leakage of who accessed what resource.
NEW
   With any HTTP request, there are potential privacy and anonymity
   ramifications if there is leakage of who accessed what resource.
   HTTP 451 is used as a response when the client requests a resource
   that's unavailable because of legal reasons.  Consequentially, the
   privacy and anonymity ramifications may be even more significant.
END

I find Section 7.11 to be vague to the point of being content-free, and, therefore, pointless.

In 7.14, the draft says, "Objective of this draft is to increase reliability by making it clearer what a good HTTP 451 response looks like."  That looks like marketing, and, to my eyes, looks wrong, as well... or, at least, if that's the objective, I think the draft has failed here.  I'd strike that sentence.  (By the way, in general it's good to avoid referring to a document as "this draft", because that designation becomes obsolete if the draft becomes an RFC.  Better to say "this document".)

In 7.16, there's nothing specific about the 451 response code here.  I guess you could say, "All HTTP transactions are susceptible to leakage unless they are protected by encryption, such as through the use of HTTPS."

-- 
Barry