Change:
one or more IP addresses to its peer, and then respond with an ADDRESS_ASSIGN capsule to inform the peer of the assignment.  For each Requested Address, the receiver of the ADDRESS_REQUEST capsule <del> SHOULD respond with a Assigned Address with a matching Request ID. If the requested address was assigned, the IP Address and IP Prefix </del> <ins> SHALL respond with a Assigned Address with a matching Request ID.  If the requested address was assigned, the IP Address and IP Prefix </ins> Length fields in the Assigned Address response SHALL be set to the assigned values.  If the requested address was not assigned, the IP Address SHALL be all-zero and the IP Prefix Length SHALL be the maximum length (0.0.0.0/32 or ::/128) to indicate that no address was <del> assigned.  Note that other Assigned Address entries that do not correspond to any Request ID can also be contained in the same ADDRESS_ASSIGN response. </del> <ins> assigned.  These address rejections SHOULD NOT be included in subsequent ADDRESS_ASSIGN capsules.  Note that other Assigned Address entries that do not correspond to any Request ID can also be contained in the same ADDRESS_ASSIGN response. </ins> If an endpoint receives an ADDRESS_REQUEST capsule that contains zero Requested Addresses, it MUST abort the IP proxying request stream.

Discussion:
s/SHOULD/MUST/ regarding replying to add requests. Indicate that endpoints responding to ADDRESSREQUEST capsules SHOULD NOT send repeat non-assignments in future ADDRESSASSIGN capsules. Please wordsmith away.
IIUC the recipient of an ADDRESSREQUEST has to respond one way or another, using ADDRESSASSIGN. Via , it is possible to reject a request and send a "null response" back. Per ADDRESSASSIGN Technically, the address was never given, so sending a "null address" just once and then never sending it again is probably a good move - it limits the commitment to remember full details and reduces capsule transfer size. Endpoints that try to send a complete list of addresses in every ADDRESSASSIGN, including the null ones, might find they could get aboused, because its a lot simpler to send a short request with a unique request ID, than to respond to it. Probably nothing needs to change in the protocol but adding some considerations for implementers might be nice.
That's fair, we should say that the all-zero addresses don't need to be repeated in future capsules
Preferences for SHOULD NOT be repeated vs MUST NOT be repeated?
If an endpoint sends a polite ADDRESS_REQUEST that is well formed but the receiver can't or won't action it, there's no feedback. Since capsules are sent reliably, we can depend on them making it to the peer, but not necessarily being procesed. If the request is blackholed, should it, for example, ever be retried? There's a difference between a proxy refusing to do something and it temporarily being unable to do it (possibly due to resource constraints or rate limiting).
I don't think we currently have support for an ADDRESS_REQUEST capsule not being replied-to. The current language is written with the expectation that every REQUEST gets a RESPONSE. SO I would expect that if the request cannot be satisfied (i.e., is rejected) you get the rejection response that NAME just committed. So I would expect a proxy that is being rate-limited to respond, just slowly.
NAME please see URL
Thanks! makes it clearer how to assertively respond, which is good. However, the text IP addresses to its peer, and then respond with an ADDRESSASSIGN capsule to inform the peer of the assignment. This SHOULD is a bit hairy.

Maybe it would be clear to split these out and state that a receiver of an ADDRESSREQUEST MUST reply.
I agree, I think that this should be upgraded to MUST that was missed after request/response IDs were added.
Agreed. I'd be supportive of a MUST along the lines of: Though we need to wordsmith it better
Not sure if a MUST really helps here. I guess there is no way to force an endpoint to reply and we also can't specify until when the reply needs to come, so you always need to implement a logic to detect that you didn't get reply. To be honest that also a point where I'm not fully happy with . So far my assumption was rather that you can of course nicely ask for an address. But as soon as you get an address_assign you should assume that the list is complete and work with rather that than speculatively waiting for a potentially update that may or may not come. Sending a reject as specified in makes the situation less ambiguous but in the end it shouldn't really change much because it always better to start sending quickly with an address that you got assigned than to wait and hope for another address.
Why not? Peer could reset the stream, or time out the entire connection. That is what the point of a MUST is.
If you get a bunch of addresses assigned that you don't want to use and they're decide to not use the connect, I guess you should close it. however, if you use it, there is no point in closing it just because you didn't get a reply to your request. And again we don't send when a reply should or must be send. So there is no final deadline when you could close a stream.
The whole reason we added request IDs was to remove the requirement to timeout. This does not work if we allow the peers to simply not respond. The contract here needs to be that reach request gets a response, like HTTP. If a peer breaks that, you close the stream -- like HTTP.
I don't think it's the same. If you send two requests which each one IP address and you only get one reply, you can use the IP you got and everything is fine. In http if you don't get a reply, you connection simply broken.

Yes, it would make things easier if you can guarantee that you always get a reply but I don't think there is a good way to enforce that; or even trying to enforce it, creates more limitation than it might help.
I think its easier to built a client if it knows whether to expect responses in the protocol or not. This will govern how it approaches cases where it does or does not get a timely response, for some measure of timely. These might be (and probably are) implementations choices that should be pointed out. There's lots of reasons a client might detect something was slow, when in fact it was serviced as fast as possible. Imagine I run a proxy that might, for reasons that are outside of its control, have delays servicing one address request out of a few. If clients are going to be "smart" and make opaque decisions, then it could adversely affect my operations.