Draft: draft-ietf-masque-connect-ip

Commentary: s / SHOULD / MUST/ regarding replying to add requests . Indicate that endpoints responding to ADDRESSREQUEST capsules SHOULD NOT send repeat non - assignments in future  capsules . Please wordsmith away . 
 IIUC the recipient of an ADDRESSREQUEST has to respond one way or another , using  .  , 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  , 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 do n'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 ca n't or wo n'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 do n'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 can not be satisfied ( i.e. , is rejected ) you get the rejection response that just committed . So I would expect a proxy that is being rate - limited to respond , just slowly . 
 please see 
 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 ADDRESS_REQUEST MUST reply . 
 I agree , I think that this should be upgraded to MUST that was missed after request / response IDs were . 
 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 ca n't specify until when the reply needs to come , so you always need to implement a logic to detect that you did n'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 should n'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 do n'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 did n't get a reply to your request . And again we do n'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 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 do n'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 do n'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 do n'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 .
Paragraph (version A):
Upon receiving the ADDRESS_REQUEST capsule, an endpoint SHOULD assign
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
SHOULD respond with a Assigned Address with a matching Request ID.
If the requested address was assigned, the IP Address and IP Prefix
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
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.
Paragraph (version B):
Upon receiving the ADDRESS_REQUEST capsule, an endpoint SHOULD assign
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
SHALL respond with a Assigned Address with a matching Request ID.  If
the requested address was assigned, the IP Address and IP Prefix
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
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.