Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
As mentioned by the TSV-ART review (Thanks Magnus!) and confirmed by Danny Moses in his response to the TSV-ART review ("There were several discussions as to whether this draft should specify Socket extensions or provide guidelines for an API provided by the network stack to applications. The decision, eventually, was that since IETF does not specify the Socket API, we should not specify Socket extensions, but rather, provide guidelines for such functionality. "), I don't think this document should specify an socket API. Further I don't necessarily think the API approach taken is correct. First section 3.3. says: "IP address type selection is made on a per-socket granularity. Different parts of the same application may have different needs. For example, the control-plane of an application may require a Fixed IP Address in order to stay reachable, whereas the data-plane of the same application may be satisfied with a Session-lasting IP Address." However, Fixed IP Address (as defined in section 3.2) cannot be configured on a per socket-basis as the application needs the same IP address for multiple socket connections. Further, section 3.5. says. "Extending this further by adding more flags does not work when a request for an address of a certain type results in requiring the IP stack to wait for the network to provide the desired source IP prefix and hence causing the setsockopt() call to block until the prefix is allocated (or an error indication from the network is received)." However, later on section 6.1. it says: "setsc() MAY block the invoking thread if it triggers the TCP/IP stack to request a new IP prefix from the network to construct the desired source IP address." Therefore, I really don't understand why a new flag in setsockopt() can not be used. I propose to remove all socket API specifications from this document and only discuss requirements (as indicated by Danny). That would basically mean to remove sections 3.5, 4.1, and 6.
Please also note that address mobility is actually more a transport question that an application layer question. For TCP session-lasting addresses will always be more efficient if available while an application using TCP will always need to cover the case where an TCP connection fails or is interrupted and therefore the application needs to reconnect. However, in contrast QUIC supports IP address mobility and will survive changing IP addresses. I think that should be also clarified in the draft and it should be double-check if the use of the word application is always correct or if it should be replaced sometimes with e.g. transport system or a more general term.