Original text:
address as well as source and destination port.  Therefore there can be at most one active paths/connection ID per 4-tuple. <del> The path management specified in section 9 of QUIC-TRANSPORT fulfills </del>  multiple goals: it directs a peer to switch sending through a new preferred path, and it allows the peer to release resources associated with the old path.  Multipath requires several changes to Manage the removal of paths that have been abandoned. As such this extension specifies a departure from the specification <del> of path management in section 9 of QUIC-TRANSPORT and therefore </del>  requires negotiation between the two endpoints using a new transport parameter, as specified in nego. using the same mechanisms. If validation succeed, the client can send non-probing, 1-RTT packets <del> on the new paths.  In contrast with the specification in section 9 of </del>  QUIC-TRANSPORT, the server MUST NOT assume that receiving non-probing packets on a new path indicates an attempt to migrate to that path. Instead, servers SHOULD consider new paths over which non-probing received for a sufficiently long path-idle delay, but SHOULD only release resource for the last available path if no traffic is received for the duration of the idle timeout, as specified in <del> section 10.1 of QUIC-TRANSPORT.  This means if all paths remain idle </del>  for the idle timeout, the connection is implicitly closed. Server implementations need to select the sub-path idle timeout as a

Reviewer comments:
Fix issue
I went ahead and replaced the references to RFC9000 by QUIC-TRANSPORT, and RFC9001 by QUIC-TLS. I have checked that this produced the expected XML V3.
RFC9000 is cited massively in the draft. It would be helpful to indicate to the reader where to look by indicating the section. Some change examples are provided below: and so on.
Side comment -- please see issue about the use of XML2RFC v3 syntax for links. We can do some of that, but not necessarily everywhere. We do expect that readers are familiar with QUIC V1. If we want to say "we are just in line with QUIC V1", then a global reference to RFC 9000 should suffice. If we want to say "please read this text in QUIC V1, we don't want to replicate here", then yes, we should refer to the specific section.
Thanks, Christian. That's the intent.
The draft is using old style references, such as "section 9 of {{RFC9000}}". Version 3 of XML2RFC defines a structure way to do that, such as: , which can be expressed in recent versions of Markdown as . The new style references don't change the text version much, but in the HTML rendering they generate direct references to the target section, which is nice for the readers.
Sorry, that's my fault because of my local build system. Will fix this for the next revision...
With the fixed references, it works now...

Revised text:
address as well as source and destination port.  Therefore there can be at most one active paths/connection ID per 4-tuple.  <ins> The path management specified in Section 9 of QUIC-TRANSPORT fulfills </ins> multiple goals: it directs a peer to switch sending through a new preferred path, and it allows the peer to release resources associated with the old path.  Multipath requires several changes to Manage the removal of paths that have been abandoned. As such this extension specifies a departure from the specification  <ins> of path management in Section 9 of QUIC-TRANSPORT and therefore </ins> requires negotiation between the two endpoints using a new transport parameter, as specified in nego. using the same mechanisms. If validation succeed, the client can send non-probing, 1-RTT packets  <ins> on the new paths.  In contrast with the specification in Section 9 of </ins> QUIC-TRANSPORT, the server MUST NOT assume that receiving non-probing packets on a new path indicates an attempt to migrate to that path. Instead, servers SHOULD consider new paths over which non-probing received for a sufficiently long path-idle delay, but SHOULD only release resource for the last available path if no traffic is received for the duration of the idle timeout, as specified in  <ins> Section 10.1 of QUIC-TRANSPORT.  This means if all paths remain idle </ins> for the idle timeout, the connection is implicitly closed. Server implementations need to select the sub-path idle timeout as a