Subject: [dhcwg] Please review draft-ietf-pcp-dhcp, particularly section 5.

From: Ted Lemon <[email-masked]>
Date: Tue, 18 Mar 2014 12:06:18 -0400

I've requested an IETF Last call on this document, so now's the time for any last tweaks.   I mention section 5 because the way it uses distinct options of the same type seems innovative and possibly not ideal.

https://datatracker.ietf.org/doc/draft-ietf-pcp-dhcp/

Thanks!

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 18 Mar 2014 22:11:56 +0000

Hi:

If we are to allow this (multiple instances of the same option), I think it would be prudent to clarify that RFC 3396 does NOT apply for this option for DHCPv4. I think this is the first option we have that cannot use this? (I'm not sure 3396 was even prepared for this situation, but I could be wrong.)

This will place special requirements on both servers and clients (servers not to split, clients not to combine).

Note that http://www.arkko.com/tools/allstats/citations-rfc3396.html is useful to see which options are defined to be concatenation-requiring options.

For DHCPv6, this is less of an issue but certainly again an unusual (the first?) case - excepting IA_*, IAADDR/IAPREFIX, and vendor options.

(I would hope the PCP WG has a sufficiently strong motivation for needing these multiple PCP server instances.)

For DHCPv6, it is also a bit odd to have:

   If an IPv4 address is retrieved by
   the DHCPv6 server, the corresponding IPv4-mapped IPv6 address is
   included in the OPTION_PCP_SERVER DHPCv6 option.

(BTW: Note the typo here - DHPCv6?)

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Tuesday, March 18, 2014 12:06 PM
To: DHC WG
Subject: [dhcwg] Please review draft-ietf-pcp-dhcp, particularly section 5.

Thanks!

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