A few points: * The abstract says this "updates" 7725, but does not have an Updates header. I tend to think that the abstract should replace with something like "adds to". However, see below. * Overall, the draft reads has a lot of history / context, and not much "new protocol elements." They should be more prominent (e.g., with distinct sections), and the explanatory text and references to the implementation draft should be minimised (note also that if it's a normative reference, it's going to hold up publication of this draft). * Is Section 3 just a summary of 7725? If so, it should be rewritten to make this clear, and avoid any 2119 keywords. Preferably, the section should be deleted, since it's just repeating 7725. * I don't see how the first two recommendations in Section 4 are going to be effective. They're not testable, they're only SHOULDs, and they're not very precise. If you want to refine the semantics of 451, you need to re-specify the status code (i.e., there should be a section with a title something like "451 (Unavailable For Legal Reasons) HTTP Status Code", and the document *would* need to update (or more likely, obsolete) 7725. However, that's *not* just "new protocol elements." * What is an "operator" in this context -- network operator, server operator? * Why is the requirement for blocking-authority a SHOULD? * What kind of URLs do you expect to be used in blocking-authority; is it the HTTP Web site of the jurisdiction, or that of the court? Which court, if there are multiple appeals? Or a page describing the judge? Or a URN? * I have every sympathy for the goals of RFC8280, but I don't see how Section 7 adds to this specification; it's an assessment that's important to do, but what value does recording the results in the specification have? Cheers, > On 3 Jul 2018, at 12: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. > > > > -- Mark Nottingham https://www.mnot.net/
