[DMM] Alissa Cooper's Discuss on draft-ietf-dmm-ondemand-mobility-16: (with DISCUSS and COMMENT)

[Alissa Cooper <[e-mail]>]

Alissa Cooper 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:
----------------------------------------------------------------------

(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:
----------------------------------------------------------------------

= 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).