Original text:
Upon receiving the ROUTE_ADVERTISEMENT capsule, an endpoint MAY start routing IP packets in that prefix to its peer.  4. IP packets are sent using HTTP Datagrams I-D.ietf-masque-h3-datagram.

Reviewer comments:
The current version of the draft contains the ROUTEADVERTISEMENT capsule but is missing the ROUTEREJECTION capsule. It's very common for networks to want to advertise routes such as "I can handle all of IPv4 space minus RFC 1918 space" and that becomes incredibly painful if you don't have a way to subtract prefixes. An alternate solution is to use an address start/address end encoding like , but if we want to use a prefix-based encoding we need a way to cut out holes from prefixes.
Oh, is that what the rejection capsule was for? I guess I'd just rather have the route advertisement itself provide a list of exceptions, rather than tying it to a separate capsule?
Yes, that would also work. This is just a matter of encoding.
The nice thing about the rejection capsule is it allows you to remove announcements that were previous present without having to re-send a full routing table. I would prefer keeping it, as it allows for more efficient transmission of information. (I disagree it's just a matter of encoding.)
Actually sending a full routing table seems like the safer way to go. And given you don’t do that very often, I don’t think we need to worry about overhead.
I will disagree with my co-author. I think the basic case for what in most cases are the equivalent to the default route for a host on a LAN segment would be good to have in a reasonable compact form. I think the question to ask here is if we in general need a mechanism to specify an IP prefix with one or more carved out sub-prefixes. I that requirement may apply to both advertising and rejecting/removing a prefix. In the removing maybe it is possible to specify the whole prefix without carve out sub-prefixes.
Maybe call with ROUTE_WITHDRAW instead of reject
ROUTE_WITHDRAW sounds good to me.

Revised text:
Upon receiving the ROUTE_ADVERTISEMENT capsule, an endpoint MAY start routing IP packets in that prefix to its peer. <ins> 3.2.4. 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: 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. The Internet Protocol Number for traffic for this route.  If the value is 0, all protocols are withdrawn for this prefix. 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. </ins> 4. IP packets are sent using HTTP Datagrams I-D.ietf-masque-h3-datagram.