Really Need Configurable Behavior?

[nibanks]

Right now the transport parameter allows for configurable behavior as such:

* 0: The node is willing to provide address observations to its peer, but is not
  interested in receiving address observations itself.
* 1: The node is interested in receiving address observations, but it is not
  willing to provide address observations.
* 2: The node is interested in receiving address observations, and it is willing
  to provide address observations.

It's obviously simpler to implement if it's just always on (if supported). What is the desire behind supporting a configurable behavior like this, considering these frames will be exchanged so infrequently? I understand servers might not need addresses from the client, but it would want to support sending them. But the implementation cost (IMO) isn't worth saving a few bytes from the client.

My preference would be a zero payload TP that indicates I support sending and receiving the addresses.

[marten-seemann]

In addition to public servers not being interested in receiving address observations, you might not be able to do so either, for example if you're the endpoint of a CONNECT-UDP connection.

You will know that this is the case, since you're the client who established the CONNECT-UDP connection, and you'd set the corresponding mode for the address discovery extension.

[nibanks]

That makes sense. I think we'll ultimately not be able to simplify this further. Though, I did have one thought: What if it was simplified and you only actually sent something if you could? What is the impact of not sending an observed address, even if the peer wants you to (and thinks you should) send it?