Subject: [dhcwg] Advancing draft-ietf-dhc-dynamic-shared-v4allocation-03.txt

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 13 Feb 2015 21:25:25 +0000

Hi:

So in working on the shepherding document for this draft, I found some issues that were introduced in the 03 draft (or perhaps also missed in the 02). I think before sending this on, these should be fixed. These are mostly minor, but because of the number of them I think it best to address them first and publish an 04 version.

- In section 4, last paragraph - "with one of the offers does not containing OPTION_V4_PORTPARAMS" should be replaced with "where a received offer does not contain OPTIION_V4_PORTPARAMS"?

- In section 5, list -  is the client allowed to send an instance of the OPTION_V4_PORTPARAMS in the DHCPDISCOVER? I think from later material it is, so should this be mentioned in #1?

And, for #2, shouldn't the "If the received OPTION_V4_PORTPARAMS ..." sentence appear before what the response must contain? And, would it not be better to say "The DHCPOFFER message is then encapsulated in ..."? Perhaps entire #2 should be:

2. DHCP 4o6 Servers that receive the DHCPDISCOVER message and support shared IPv4 addresses respond with a DHCPOFFER message as usual with the shared IPv4 address in the 'yiaddr' field and MUST add an OPTION_V4_PORTPARAMS option containing an available restricted port set. If the DHCPDISCOVER included an OPTION_V4_PORTPARAMS option containing a non-zero PSID-Len field, the DHCP  4o6 Server MAY allocate a port set of the requested size to the client (depending on policy).  The DHCPOFFER message is then encapsulated in the DHCPv4-response message and sent to the client.

And, for #3, why point out the "selected DHCP server's server identifier"? Isn't that normally added anyway? Shouldn't it just say the OPTION_V4_PORTPARAMs? (Remove "the selected DHCP server's server identifier and"?

For #4, I think it would be best to be clear that the OPTION_V4_PORTPARAMs MUST be sent in the DHCPACK?

For #5, perhaps "perform a final check" to "perform an in-use probe"? (This is more in line with what was used in section 6.)

For #6, why "MUST include the original client identifier"? Is this again a requirement above what is normal for clients? And, if this is important here, why not in the DHCPDISCOVER and DHCPREQUEST? 

The point with several of the above is just document what is NEWLY required for this shared IPv4 allocation to work; avoid mentioning things that are already standardize elsewhere (as that could confuse people as to why you mention it). If it is needed because it was not covered elsewhere, then it is OK to include.

- In section 5, last paragraph - "followedon condition" should be "followed on the condition"?

Also, would indicating that this is the INIT-REBOOT state from RFC 2131 make sense (yes, section 3.2 never says this, but it is used later and also easier for people to recognize?).

- In section 6, first paragraph - change "applying for a shared" should be "discovering for a shared"?

And, I don't really follow the sentence "The client retrieves a port set using the values contained in OPTION_V4_PORTPARMS", especially given the sentence which follows. Perhaps clarify from WHERE the client retrieves would help (is this from the DHCPOFFER/DHCPACK or from it stored "binding" information and thus related to the sentence that follows?

- In section 6.1, the first bullet has "e.g" instead of "e.g.".

- In section 8, last paragraph, would "ports reserved" be better than "ports saved"?

- In section 9.2, "CPE" is used. Perhaps best to just replace with "Customer Provided Equipment"? You could add to the Terminology section, but as only used once doesn't seem worth it. Perhaps "CPE" isn't the best term here and just client would be sufficient?

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, January 29, 2015 8:48 AM
To: [email-masked]
Cc: [email-masked]
Subject: [dhcwg] I-D Action: draft-ietf-dhc-dynamic-shared-v4allocation-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

        Title           : Dynamic Allocation of Shared IPv4 Addresses
        Authors         : Yong Cui
                          Qiong Sun
                          Ian Farrer
                          Yiu L. Lee
                          Qi Sun
                          Mohamed Boucadair
	Filename        : draft-ietf-dhc-dynamic-shared-v4allocation-03.txt
	Pages           : 13
	Date            : 2015-01-29

Abstract:
   This memo describes the dynamic allocation of shared IPv4 addresses
   to clients using DHCPv4.  Address sharing allows a single IPv4
   address to be allocated to multiple active clients simultaneously,
   each client being differentiated by a unique set of transport layer
   source port numbers.  The necessary changes to existing DHCPv4 client
   and server behavior are described and a new DHCPv4 option for
   provisioning clients with shared IPv4 addresses is included.

   Due to the nature of IP address sharing, some limitations to its
   applicability are necessary.  This memo describes these limitations
   and recommends suitable architectures and technologies where address
   sharing may be utilized.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dynamic-shared-v4allocation/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dhc-dynamic-shared-v4allocation-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dynamic-shared-v4allocation-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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