Carsten's review (issue #629) points an issue with the current draft: on one hand, we never say that only the client can open a new path; on the other hand, we do not say what happens if the client and the server open a new path simultaneously. We have two options: state that we inherit the restriction from RFC 9000 and that only the client can open new paths; or, explain what happens if the server tries to open a path.
Mandating that only the client creates paths is the simplest solution, even if it is not the most satisfactory. We could simply simply write that "attempts by servers to open paths is not supported. It is likely to fail if the client is behind a NAT, and would result in undefined behavior if client and server simultaneously try to open the same path ID." We would then rely on future extensions, such as peer-to-peer coordinated NAT traversal, to lift that restriction.
Carsten's review (issue #629) points an issue with the current draft: on one hand, we never say that only the client can open a new path; on the other hand, we do not say what happens if the client and the server open a new path simultaneously. We have two options: state that we inherit the restriction from RFC 9000 and that only the client can open new paths; or, explain what happens if the server tries to open a path.
Mandating that only the client creates paths is the simplest solution, even if it is not the most satisfactory. We could simply simply write that "attempts by servers to open paths is not supported. It is likely to fail if the client is behind a NAT, and would result in undefined behavior if client and server simultaneously try to open the same path ID." We would then rely on future extensions, such as peer-to-peer coordinated NAT traversal, to lift that restriction.