Draft: draft-ietf-taps-interface

Commentary: Adding this issue from Fernando via the TAPS list : The terminology employed in this subsection seems a bit confusing , or at least deviates from what we normally use in v6 - circles . I suggest taking a look at RFC7721 -- certainly not flawless , but it was 6man 's shot to try to agree on terminology . For example , I do n't think we use " permanent " and " stable " interchangeably . e.g. the " Local " in " useTemporaryLocalAddress " might be misleading to some . -- e.g. could be interpreted as related with link - locals or ULAs . Aside , I believe there 's much more to dig regarding address properties . e.g. , we have given it a shot at : e.g. , the choice of ipv6 addresses has more than one dimension ... and there are tradeoffs involved , which IMHO deserve discussion . And aside from the regular address systems normally configure , if one were to specify an API one would probably want to provide a mechanism for apps to be able to request sole / single - use addresses ( .e.g . , one address per app or container ) . 
 " Local " has a meaning in the TAPS context , I do n't think we need to change it for universalization with the full set of IPv6 terminology . There 's also not much point in going all the way down the rabbithole for this particular property , given that we do n't do so for any other -- this document is meant as a universal interface to networking for the future , not an unbounded treatise on the future of networking . That said , the linked draft does seem to address the issues here and it 's fairly alive , so no harm in adding an informative reference to it . 
 I agree with the comments of and
Paragraph (version A):
This property allows the application to express a preference for the
use of temporary local addresses, sometimes called "privacy"
addresses RFC8981.  Temporary addresses are generally used to prevent
linking connections over time when a stable address, sometimes called
"permanent" address, is not needed.  There are some caveats to note
when specifying this property.  First, if an application Requires the
use of temporary addresses, the resulting Connection cannot use IPv4,
because temporary addresses do not exist in IPv4.  Second, temporary
local addresses might involve trading off privacy for performance.
For instance, temporary addresses can interfere with resumption
mechanisms that some protocols rely on to reduce initial latency.
Paragraph (version B):
This property allows the application to express a preference for the
use of temporary local addresses, sometimes called "privacy"
addresses RFC8981.  Temporary addresses are generally used to prevent
linking connections over time when a stable address, sometimes called
"permanent" address, is not needed.  There are some caveats to note
when specifying this property.  First, if an application Requires the
use of temporary addresses, the resulting Connection cannot use IPv4,
because temporary addresses do not exist in IPv4.  Second, temporary
local addresses might involve trading off privacy for performance.
For instance, temporary addresses (e.g., RFC8981) can interfere with
resumption mechanisms that some protocols rely on to reduce initial
latency.