Subject: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

From: Jouni Korhonen <[email-masked]>
Date: Tue, 1 Dec 2015 10:07:25 -0800

Folks,

This mail starts two week WGLC for the I-D:
	https://tools.ietf.org/html/draft-ietf-dmm-ondemand-mobility-01

The WGLC ends 12/15/2015.

Provide your reviews and comments to the mailing list. For the better 
tracking of issues and proposed changed use the Issue Tracker to submit 
your issues/proposals.

- Jouni & Dapeng

---

From: Dave Dolson <[email-masked]>
Date: Wed, 2 Dec 2015 16:41:44 +0000

(I haven't paid close attention to the list, so apologies if I'm raising old issues.)

1. Was the term "Nomadic" discussed? To me, a nomadic thing moves around, but in this draft, Nomadic IP addresses do not move around; they are replaced. "Ephemeral IP Address" might convey the idea more clearly.

2. I know this is really picky, but it wouldn't hurt to spell out "REQUIRE" in IPV6_REQ_FIXED_IP etc.
 - IPV6_REQUIRE_FIXED_IP in parallel with IPV6_PREFER_SRC_PUBLIC

3. There is a "TDB" in section 3.4. "TBD: Disallow this case?"  This needs to be resolved. I suggest the most restrictive flag applies.

4. Must resolve "Application of this solution to IPv4 is TBD." 
 - clearly the socket option is IPV6_something, but...
 - there is uncharted territory surrounding IPv4-mapped-IPv6 addresses (https://tools.ietf.org/html/rfc4291#section-2.5.5.2 ), when socket option IPV6_V6ONLY is false.
 - I think the goal should be that the API *does* apply to IPv4 via IPv4-mapped-IPv6 addresses, while acknowledging that the operating system or network may not be able to fulfill the request.
    - I.e., permit the application to request constraints on IPv4, but also expect the application to try for a relaxed address if the initial request fails.
 - I see no need to support the API with AF_INET sockets, since AF_INET6 can be used with IPV6_ONLY=false and IPv4-mapped-IPv6 addresses.

5. The error codes are not clearly defined. What is the errno for failure of setsockopt() and others?

6. I'm unclear on when the on-demand resolution occurs? I don't think it can be done at the time of setsockopt(); as I understand it, the addresses are resolved later, at connect() or listen(). I'm not sure about this, but it should be explained. If the resolution is done at connect() time, is a new errno required?

7. Some socket interfaces are not mentioned. What about sendto(), sendmsg(), which are not connection-oriented?

8. In section 4.1, support for legacy applications does not really say how to support legacy applications.
 - my opinion: the default (lacking new socket options) should be to require Fixed for listen() and Sustained for connect(), and Nomadic/Ephemeral for non-connected datagrams.

-Dave

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Tuesday, December 01, 2015 1:07 PM
To: [email-masked]; Jouni; Dapeng Liu
Subject: [DMM] WGLC #1 for draft-ietf-dmm-ondemand-mobility-01

Folks,

- Jouni & Dapeng

_______________________________________________
dmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmm