[DMM] Mirja Kühlewind's Discuss on draft-ietf-dmm-ondemand-mobility-16: (with DISCUSS and COMMENT)

[Mirja Kühlewind <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dmm-ondemand-mobility-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dmm-ondemand-mobility/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.