AT IETF98 (Chicago) I was request by the WG to present the draft-moses-dmm-dhcp-ondemand-mobility draft to the dhc group and have them review the DHCPv6 aspects of this draft.
At IETF99 (Prague), I presented the draft and receive very useful comments and correction. The new draft includes all the changes as a result of that review. I am including in this email, the list of comments that were raised and the actions taken to improve the draft. I hope that after this important milestone was achieved, the draft will be adopted by the dmm WG. The following comments/questions were raised regarding the DHCP OnDemand draft (draft-moses-dmm-dhcp-ondemand-mobility): 1. Replace the status code name from NoAddrsAvail to NoPrefixAvail 2. The description of the server's behavior in response to an unrecognized encapsulated option in section 3 is wrong - fix it. 3. Clarify the correlation of the service types and the lifetime attribute (especially for Fixed address types). 4. Correct the fields of the Anchor Preference option 5. Remove the definition of the Anchor Preference option. It is not needed. 6. Check capital letters for keywords (MUST, SHOULD, MAY) 7. Fix section 2 - RFC8174 (wording was updated). See RFC8156 - for example. 8. Draft does not mention the Confirm and Rebind messages which are relevant for mobility support. Actions: 1. Replace the status code from NoAddrsAvail to NoPrefixAvail: Done. 2. Correct description of server's behavior when receiving an unrecognized option: Replaced the original text: "A server that does not support this option will discard it as well as the IA_PD Prefix option that had this option encapsulated in one of its IAprefix-options field. If a client does not receive the requested prefix, it must resend the request without the desired IPv6 Continuity Service option since it is not supported by the server. In this case, the requesting device (host or router) cannot assume any IP continuity service behavior for that prefix." With: "A server that does not support this option will ignore it and respond without taking into account the desired session continuity service. The response will not include the Continuity Service option encapsulated in the IAprefix-options field of the IA_PD prefix option. The missing Continuity Service option in the response serves as an indication to the client that this feature is not supported by the server. It MAY use the allocated prefix (knowing it does not necessarily support the desired Continuity service), or perform any other action." 3. Clarify the correlation of the service types and the lifetime attribute: Adding section 3.1 to clarify the correlation between Session continuity services and 'lifetime': 3.1 Correlation between Session Continuity Service and lifetime values The values to be used in the Preferred-lifetime and Valid-lifetime fields in the IA Prefix Option are out of the scope of this specification and left to implementation. It is recommended to provide longer lifetime values for Fixed and Session-lasting prefixes compared to the lifetime values of Non-persistent and Graceful-replacement prefixes because the network has guaranteed their validity regardless of the link to which the host is attached. For clients using Graceful-replacement services, the network MAY obsolete a Prefix and allocate a new one from time to time especially in a mobility-related event. On such occasions, the network SHOULD provide a graceful period (lifetime) in which the obsoleted prefix can still be used and a new (longer) lifetime with the new prefix. It is not recommended to use 0xFFFFFFFFFF (infinity) values for the lifetime of Fixed prefixes. Even though they are fixed, it is still safer to Rebind periodically. The lifetime value can be relatively long to reduce message exchange overhead. Section 18.2 of 3633bis - Client Behavior: "A client uses the Solicit message to discover DHCP servers configured to assign leases or return other configuration parameters on the link to which the client is attached. A client uses Request, Renew, Rebind, Release and Decline messages during the normal life cycle of addresses and delegated prefixes. When a client detects it may have moved to a new link, it uses Confirm if it only has addresses and Rebind if it has delegated prefixed (and addresses)..." Section 3.1 also has some clarifications regarding the client's operation after moving to a new link: "Section 18.2 - Client Behavior of ietf-dhc-rfc3315bis specifies that when a client detects it may have moved to a new link, it uses Rebind if it has delegated prefixes. It is worth clarifying that a client does not HAVE to Rebind the prefixes if they are Fixed or Session-lasting prefixes." 4. Correct the fields of the Anchor Preference option: Since the Anchor Preference option is not needed (see next comment) it has been removed from the draft. 5. Remove the definition of the Anchor Preference option. It is not needed: Done. 6. Check capital letters for keywords (MUST, SHOULD, MAY): Done. Hope I did not miss any... 7. Fix section 2 - RFC8174 (wording was updated). See RFC8156 - for example: Done. Added reference to RFC8174 and updated the wording. 8. Draft does not mention the Confirm and Rebind messages which are relevant for mobility support: That is correct. The draft is about a new option and it does not affect any existing messages. However as described in this email, Rebind will be mention is the description of the need to rebind after a mobility event. Thanks, 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 dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
