Original text:
4.2.3. <del> The ROUTE_ADVERTISEMENT capsule allows an endpoint to communicate to its peer that it is willing to route traffic to a given prefix.  This indicates that the sender has an existing route to the prefix, and notifies its peer that if the receiver of the ROUTE_ADVERTISEMENT capsule sends IP packets for this prefix in HTTP Datagrams, the sender of the capsule will forward them along its preexisting route. This capsule uses a Capsule Type of 0xfff102.  Its value uses the following format: </del>  <del> IP Version of this route advertisement.  MUST be either 4 or 6. </del>  <del> IP address of the advertised route.  If the IP Version field has value 4, the IP Address field SHALL have a length of 32 bits.  If the IP Version field has value 6, the IP Address field SHALL have a length of 128 bits. </del>  <del> The number of bits in the IP Address that are used to define the prefix of the advertised route.  This MUST be lesser or equal to the length of the IP Address field, in bits.  If the prefix length is equal to the length of the IP Address, this route only allows sending packets to a single destination address.  If the prefix length is less than the length of the IP address, this route allows sending packets to any destination address that falls within the prefix. </del>  The Internet Protocol Number for traffic that can be sent to this <del> prefix.  If the value is 0, all protocols are allowed. </del>  Upon receiving the ROUTE_ADVERTISEMENT capsule, an endpoint MAY start <del> routing IP packets in that prefix to its peer. If an endpoint receives multiple ROUTE_ADVERTISEMENT capsules, all of the advertised routes can be used.  For example, multiple ROUTE_ADVERTISEMENT capsules are necessary to provide routing to both IPv4 and IPv6 hosts.  Routes are removed using ROUTE_WITHDRAWAL capsules. </del>  <del> 4.2.4. </del>  <del> The ROUTE_WITHDRAWAL capsule allows an endpoint to communicate to its peer that it is not willing to route traffic to a given prefix.  This capsule uses a Capsule Type of 0xfff103.  Its value uses the following format: </del>  <del> IP Version of this route withdrawal.  MUST be either 4 or 6. IP address of the withdrawn route.  If the IP Version field has value 4, the IP Address field SHALL have a length of 32 bits.  If the IP Version field has value 6, the IP Address field SHALL have a length of 128 bits. The number of bits in the IP Address that are used to define the prefix of the withdrawn route.  This MUST be lesser or equal to the length of the IP Address field, in bits. </del>  <del> The Internet Protocol Number for traffic for this route.  If the value is 0, all protocols are withdrawn for this prefix. </del>  <del> Upon receiving the ROUTE_WITHDRAWAL capsule, an endpoint MUST stop routing IP packets in that prefix to its peer.  Note that this capsule can be reordered with DATAGRAM frames, and therefore an endpoint that receives packets for routes it has rejected MUST NOT treat that as an error. </del>  <del> ROUTE_ADVERTISEMENT and ROUTE_WITHDRAWAL capsules are applied in order of receipt: if a prefix is covered by multiple received ROUTE_ADVERTISEMENT and/or ROUTE_WITHDRAWAL capsules, only the last received capsule applies as it supersedes prior ROUTE_ADVERTISEMENT and ROUTE_WITHDRAWAL capsules for this prefix. </del>  5.

Reviewer comments:
This PR is one potential way to It simplifies route exchanges by going with NAME 's suggestion of sending the entire routing table each time something changes. It could be somewhat inefficient in some cases, but it becomes easier to reason about than what's currently in the draft when overlapping prefixes are involved.
This is interesting, but I'd prefer to wait to do this until after we post a -00 version. NAME is that OK with you?
I'd prefer we figure this out before -00, because this would be a pretty significant non-compatible change and I'd like to implement -00
NAME you nearly convinced me in the call that we rather want to announce ranges separately but I forgot why. Can you outline your reasoning again?
NAME my argument was that we shouldn't have two different ways to set routes, one that gives a table and one that gives a single route. If we go to only have a table, then it's fine.
I know saw the discussion in and support this approach. Also if we agree on this approach, I also think we should merge it before we submit -00
NAME I think we're ready to merge this PR
As discussed in , turning a sequence of ROUTEADVERTISEMENT and ROUTEWITHDRAWAL capsules into a functional routing table isn't as simple as initially expected. This is because two separate capsules can describe prefixes that are distinct but overlap. We should simplify the design or better explain the caveats.
I think this looks good enough to include in the -00.

Revised text:
4.2.3.  <ins> The ROUTE_ADVERTISEMENT capsule (see iana-types for the value of the capsule type) allows an endpoint to communicate to its peer that it is willing to route traffic to a set of IP address ranges.  This indicates that the sender has an existing route to each address range, and notifies its peer that if the receiver of the ROUTE_ADVERTISEMENT capsule sends IP packets for one of these ranges in HTTP Datagrams, the sender of the capsule will forward them along its preexisting route.  Any address which is in one of the address ranges can be used as the destination address on IP packets originated by the receiver of this capsule. </ins>  <ins> The ROUTE_ADVERTISEMENT capsule contains a sequence of IP Address Ranges. </ins>  <ins> IP Version of this range.  MUST be either 4 or 6. </ins>  <ins> Inclusive start and end IP address of the advertised range.  If the IP Version field has value 4, these fields SHALL have a length of 32 bits.  If the IP Version field has value 6, these fields SHALL have a length of 128 bits.  The Start IP Address MUST be strictly lesser than the End IP Address. </ins> The Internet Protocol Number for traffic that can be sent to this  <ins> range.  If the value is 0, all protocols are allowed. </ins> Upon receiving the ROUTE_ADVERTISEMENT capsule, an endpoint MAY start  <ins> routing IP packets in these ranges to its peer. </ins>  <ins> Each ROUTE_ADVERTISEMENT contains the full list of address ranges. If multiple ROUTE_ADVERTISEMENT capsules are sent in one direction, each ROUTE_ADVERTISEMENT capsule supersedes prior ones.  In other words, if a given address range was present in a prior capsule but the most recently received ROUTE_ADVERTISEMENT capsule does not contain it, the receiver will consider that range withdrawn. </ins>  <ins> If multiple ranges using the same IP protocol were to overlap, some routing table implementations might reject them.  To prevent overlap, the ranges are ordered; this places the burden on the sender and makes verification by the receiver much simpler.  If an IP Address Range A precedes an IP address range B in the same ROUTE_ADVERTISEMENT capsule, they MUST follow these requirements: </ins>  <ins> IP Version of A MUST be lesser or equal than IP Version of B </ins>  <ins> If the IP Version of A and B are equal, the IP Protocol of A MUST be lesser or equal than IP Protocol of B. </ins>  <ins> If the IP Version and IP Protocol of A and B are both equal, the End IP Address of A MUST be strictly lesser than the Start IP Address of B. </ins>  <ins> If an endpoint received a ROUTE_ADVERTISEMENT capsule that does not meet these requirements, it MUST abort the stream. </ins> 5.