On Demand Mobility Management

Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.

Alissa Cooper Discuss

Discuss (2019-02-21 for -16)
(1) There are a bunch of places in this document that place normative requirements on "the IP stack" or "IP stacks." This seems too broad to me -- aren't these meant to apply to IP stacks that implement the new API? It seems like RFC 5014 was more careful in its use of normative language and I think that care is warranted here as well.

(2) RFC 7721 defines a bunch of address types that are somewhat overlapping with the definitions here. RFC 4941 and RFC 8064 provide recommendations for configuration of different address types. How do the address types and recommendations in this document intersect with the address types and recommendations in those documents?
Comment (2019-02-21 for -16)
Please address the Gen-ART review comments.

= Section 3.2 =

"A Fixed IP address is an address with a guarantee to be valid for a
   very long time"

This seems vague. What is a very long time?

= Section 5.1 =

"Applications using the new On-Demand functionality MUST be aware that
   they may be executed in legacy environments that do not support it."

This should not be a normative recommendation.

= Section 7 =

This section needs to discuss the privacy and security implications of the different address types (see, e.g., RFC 7721 Sections 3 and 4).

Mirja Kühlewind Discuss

Discuss (2019-02-20 for -16)
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 (2019-02-20 for -16)
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.

Suresh Krishnan Yes

Deborah Brungard No Objection

(Ben Campbell) No Objection

Alexey Melnikov No Objection

Comment (2019-02-21 for -16)
Thank you for this document.

I don't mind presence of socket API, but I would like to point out that it is not very friendly to platforms (e.g. Windows) where sockfd type is not "int".

Alvaro Retana No Objection

Comment (2019-02-20 for -16)

Don't put references in the Abstract: s/[RFC7333]/RFC7333

s/new concep/new concept

In §5: s/Backwards compatibility support is REQUIRED/Backwards compatibility support is required     In this case, you're not specifying anything, just stating a fact, so Normative language is not needed.

Ignas Bagdonas No Record

Roman Danyliw No Record

Benjamin Kaduk No Record

Warren Kumari No Record

Barry Leiba No Record

Adam Roach No Record

Martin Vigoureux No Record

Éric Vyncke No Record

Magnus Westerlund No Record