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.
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
