Original text:
11. <del> A string for identifying HTTP/2 is entered into the "Application- Layer Protocol Negotiation (ALPN) Protocol IDs" registry established in TLS-ALPN. This document establishes a registry for frame types, settings, and error codes.  These new registries appear in the new "Hypertext Transfer Protocol version 2 (HTTP/2)" section. </del> This revision of the document marks the <del> header field registered in RFC7540 obsolete. </del>  <del> This document registers the method for use in HTTP to avoid collisions with the ConnectionHeader. 11.1. This document creates two registrations for the identification of HTTP/2 (see discover-https) in the "Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry established in TLS-ALPN. The "h2" string identifies HTTP/2 when used over TLS: The "h2c" string identifies HTTP/2 when used over cleartext TCP: 11.2. </del>  <del> This document establishes a registry for HTTP/2 frame type codes. The "HTTP/2 Frame Type" registry manages an 8-bit space.  The "HTTP/2 Frame Type" registry operates under either of the "IETF Review" (RFC8126) or "IESG Approval" (RFC8126) policies. </del>  <del> New entries in this registry require the following information: </del>  <del> The entries in the following table are registered by this document. </del>  <del> 11.3. </del>  <del> This document establishes a registry for HTTP/2 settings.  The "HTTP/2 Settings" registry manages a 16-bit space.  The "HTTP/2 Settings" registry operates under the "Expert Review" policy (RFC8126). </del>  <del> New registrations are advised to provide the following information: </del>  <del> The entries in the following table are registered by this document. 11.4. This document establishes a registry for HTTP/2 error codes.  The "HTTP/2 Error Code" registry manages a 32-bit space.  The "HTTP/2 Error Code" registry operates under the "Expert Review" policy (RFC8126). Registrations for error codes are required to include a description of the error code.  An expert reviewer is advised to examine new registrations for possible duplication with existing error codes. Use of existing registrations is to be encouraged, but not mandated. New registrations are advised to provide the following information: The entries in the following table are registered by this document. 11.5. </del>  This section marks the <del> header field registered in RFC7540 as obsoleted.  The registration is updated to include the details as required by HTTP: 11.6. </del>  <del> This section registers the method in the "HTTP Method Registry" (HTTP). </del>  <del> 11.7. </del>  <del> RFC7540 registered an upgrade token.  This capability has been removed: see versioning. </del> 

Reviewer comments:
As noted in , we don't need to redo these. A backward reference will do. This cuts quite a bit of XML out of the document, which I'm happy about.
NAME I disagree; IANA hold the registration data, not the document. My understanding is that templates need only appear in the originally registering documents; if there's doubt about that, we should check with the IESG and IANA.
That is true, but the registrations point to specs. The IANA Considerations need to take care of updating these references.
That's a good point; I will shelve that and change to adding a note that says "references to RFC 7540 for X, Y, and Z are updated to point to this document".
Absolutely. It just doesn't need to list them individually; a simple statements such as "update the references to RFCxxxx to this document in Registry Foo" will suffice.
If that's all which is necessary, yes. Hint: section numbers might change, and you don't want to handle that during AUTH48.
The current IANA Considerations for H2 bis has several requests to IANA that seem to be appropriate for the original document, but not a bis now that the registries are already filled out. Shouldn't these be reworded to say "this document updates..." or explain that the references for registries should point to this document, rather than the old RFC?
I don't think this is a good idea. At the end of the day, the IANA registry should point to the updated document.

Revised text:
11.  This revision of the document marks the  <ins> header field and the </ins>  <ins> Upgrade token, both defined in RFC7540, as obsolete. </ins>  <ins> RFC7540 registered the </ins>  <ins> and </ins>  <ins> ALPN identifiers along with the </ins>  <ins> HTTP method.  RFC 7540 also established a registry for frame types, settings, and error codes.  These registrations and registries apply to HTTP/2, but are not redefined in this document. </ins>  <ins> [RFC Editor: please remove this paragraph.]  IANA is requested to update references in these registries to refer to this document.  The registration of the </ins>  <ins> method needs to be updated to refer to preface; all other section numbers have not changed. </ins>  <ins> 11.1. </ins> This section marks the  <ins> header field registered in RFC7540 as obsoleted.  This capability has been removed: see versioning.  The registration is updated to include the details as required by HTTP: </ins>  <ins> 11.2. </ins>  <ins> This section records the </ins>  <ins> upgrade token registered in RFC7540 as obsolete.  This capability has been removed: see versioning.  The registration is updated as follows: </ins>