Original text:
2.2.8. If a request target URI uses HTML form parameters in the query string <del> as defined in HTMLURL, the "@query-param" derived component allows addressing of individual query parameters.  The query parameters MUST be parsed according to HTMLURL, resulting in a list of ("nameString", "valueString") tuples.  The REQUIRED "name" parameter of each component identifier contains the "nameString" of a single query parameter as a String value.  Several different named query parameters MAY be included in the covered components.  Single named parameters MAY occur in any order in the covered components. </del>  The component value of a single named parameter is the "valueString" <del> of the named query parameter defined by HTMLURL, which is the value after percent-encoded octets are decoded.  Note that this value does not include any leading "?" characters, equals sign "=", or separating "&" characters.  Named query parameters with an empty "valueString" are included with an empty string as the component value. </del>  If a query parameter is named as a covered component but it does not occur in the query parameters, this MUST cause an error in the

Reviewer comments:
Changes the reference to HTMLURL to use one of the newly-registered permanent anchors. Previously two different section anchors had been used, but I'm not sure how to put both of them into the references section. Is there a syntax for multiple target URLs?
I would know how to do that in RFCXML. Maybe it's good enough to tune in AUTH48.
Comment by NAME Thanks to Tommy for detailed shepherd write up, that tells me you have discussed this already. Seems obvious that the HTMLURL reference needs to be normative, so we might need to reference a snapshot of this instead. See the following text in the IESG statement: URL I'd like to get this fixed before starting the Last Call.
A permanent anchor has been requested of the WHATWG: URL
This has been implemented by the WHATWG in URL , so we just need to move our references to use the new permanent anchors.
Note that the question of stable anchors is somewhat orthogonal to the issue of stable specs. A stable anchor doesn't help if the thing being linked to changes.
NAME while true, as the target document is a "living standard" there is no way to guarantee a specific version. Nor is that reason to believe that the document is "unstable" in the way an I-D is. At the very least, implementors will be able to find the information they need at the referenced anchors.
Yes, I agree with that. I just wanted to mention that this might not address the AD feedback.

Revised text:
2.2.8. If a request target URI uses HTML form parameters in the query string  <ins> as defined in the "application/x-www-form-urlencoded" section of HTMLURL, the "@query-param" derived component allows addressing of individual query parameters.  The query parameters MUST be parsed according to the "application/x-www-form-urlencoded parsing" section of HTMLURL, resulting in a list of ("nameString", "valueString") tuples.  The REQUIRED "name" parameter of each component identifier contains the "nameString" of a single query parameter as a String value.  Several different named query parameters MAY be included in the covered components.  Single named parameters MAY occur in any order in the covered components. </ins> The component value of a single named parameter is the "valueString"  <ins> of the named query parameter defined by "application/x-www-form- urlencoded parsing" section of HTMLURL, which is the value after percent-encoded octets are decoded.  Note that this value does not include any leading "?" characters, equals sign "=", or separating "&" characters.  Named query parameters with an empty "valueString" are included with an empty string as the component value. </ins> If a query parameter is named as a covered component but it does not occur in the query parameters, this MUST cause an error in the