[DMM] New version of draft-ietf-dmm-ondemand-mobility

["Moses, Danny" <[e-mail]>]

Hi all,
I have upload a new version (17) of the draft.


Here is a summary of the changes to the draft after analyzing the different Last Call review and comments:

Changes from Rev-16 to Rev-17

1.      Remove the reference to section 4 of RFC7333 in the Abstract. Leave the reference to RFC7333.

2.      Reorder 2 paragraphs in the Introduction (section 1):

The original order was:

*        The paragraph starting with: "Mobile IP is designed to provide..."

*        The paragraph starting with: "In reality not every application..."

*        The paragraph starting with: "Achieving session continuity and IP address reachability..."

The new order is:

*        The paragraph starting with: "Mobile IP is designed to provide..."

*        The paragraph starting with: "Achieving session continuity and IP address reachability..."

*        The paragraph starting with: "In reality not every application..."

3.      Remove '(' and ')' from last paragraph of section 3.1

4.      Improve the normative requirements on "the IP stack" or "IP stacks":

*        Section 5.1, replace 'MUST' with 'should'.

*        Section 5.2, modify "New IP stacks" to "New IP stacks (that implement On Demand functionality).

5.      Improve the Security Threats description

Improve the Security Consideration section as recommended by Daniel Migault.




Changes from Rev-15 to Rev-16

1.      In the Abstract, add a reference to RFC 7333 which details the inefficiencies in current mobility services implementation which lead to the new work in DMM and specifically this document: Add to '...The network providing the same type of service to any mobile host and any application running on the host yields inefficiencies.' the text - ' as described in section 4 of RFC 7333.'

2.      Accepted the text change in section 1: replaced 'It should be noted that in' to 'In'.

3.      Align the style of the lists in section 1 and section 3 (using the style that was used in section 3).

4.      Add 'on demand' in section one: replace 'This document proposes a solution for applications running on mobile hosts to indicate whether they need session continuity...' with -

'This document proposes a solution for applications running on mobile hosts to indicate when establishing the network connection ('on demand') whether they need session continuity...'

5.      Maintain the order of type of addresses in section 3.3 (now 3.4 after adding a section before 3.1). Change:

'At any point of time, a mobile host may have a combination of IP addresses configured. Zero or more Non-persistent, zero or more Session-lasting, zero or more Fixed and zero or more Graceful-Replacement IP addresses...', to:

'At any point of time, a mobile host may have a combination of IP addresses configured. Zero or more Fixed, zero or more Session-lasting, zero or more Non-persistent and zero or more Graceful-Replacement IP addresses...'.

6.      Updated section 2 to the most updated format and added a reference to RFC 8174

7.      Corrected the typo in section 4.1: replaced 'secsc(' with 'setsc('

8.      Corrected the 'getsc()' typo in several places: replaced 'getsc()' with 'setsc()'

9.      Clarified the process of requesting and assigning the desired mobile service to applications by adding a new section - 3.1 High-level Description.

10.   Maintain consistency. Replace all occurrences on 'on demand' and OnDemand' to 'On-Demand'. And all 'IP v6' to 'IPv6'

11.   Simplify the use-case described in section 5.4. Change:

'However, if an application sets a specific option using setsockopt() with one of the flags specified in [RFC5014] and also selects a source IP address using setsc() and bind() the IP address that was generated by setsc() and bound using bind() will be the one used by traffic generated using that socket and options set by setsockopt() will be ignored'

To:

'However, if an application erroneously performs a combination of (1) use setsockopt() to set a specific option (using one of the flags specified in [RFC5014]) and (2) selects a source IP address type using setsc() and bind(), the IP stack will fulfill the request specified by (2) and ignore the flags set by (1).'

12.   The only comments I am still debating on are:

a.      The IANA-related comment.

b.      The security-related comment

I would appreciate you inputs.

Regards,
Danny

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.