Subject: [dhcwg] Review of draft-ietf-dhc-option-guidelines

From: Jiangsheng <[email-masked]>
Date: Thu, 11 Aug 2011 08:16:44 +0000

Hi, all,

As agreed in the IETF 81 meeting, I have reviewed draft-ietf-dhc-option-guidelines and have below comments.

Overall, this guideline is very useful. If it was published, it should be recommended in DHC WG charter page.

1. The very first and maybe the most important comment is: it is better to separate DHCPv4 and DHCPv6. It means we should have two dedicated drafts for DHCPv4 and DHCPv6. DHCPv4 and DHCPv6 are similar, but two different protocols. Some of discussions may be common between them, some of discussion may have very different base. Combining this discussion may harmful. Section 9, "option size" is an example. The option size requirements for DHCPv4 and DHCPv6 are different.

Separating them would make the discussion more explicitly and targeting right readers. Say, one who is designing a new DHCPv6 option would not care how this may relevant to a DHCPv4 option.

Furthermore, if DHCPv4 option space has freeze or will freeze, guidelines for new DHCPv4 option may be meaningless.

2. In the introduction section, this draft mentioned support for unknown options. It is unclear for me, at least from the draft contents, how this can happen? It may be possible to add new option at the server side, how the client support it?

3. The section 2, "when to use DHCP" does not mentioned "IP address configuration", which is the most important usage of DHCP. Unless this text is dedicate for new DHCP option (the current text does not claim so), IP address configuration should be added.

4. Disagree on the order of "when to use DHCP". The current text suggests using DHCP is first because client want information. But, in my understanding, network administration want to push/enforce some configuration is the most important requirements.

5. The draft states, in section 2, "the client still reserves the right to ignore values received via DHCP". That's right. But this may be at their own risk to be rejected by network administration. This kind of observation should also mentioned. Otherwise, the above next may be misleading: client can ignore DHCP configuration without any effect.

6. At the end of section 4, there are some rules how to organize values in the option. There should be more, such as the order of fixed size values, the order of multiple variable sized values.

7. section 5, using the conclusion as title can be more explicit: "avoid conditional formatting". This also looks like the title of section 6.

8. the title of section 6 has a typo: avoid alciasing/aliasing

9. "in the case where the server is configured with all formats, DHCP option space is wasted on option contents that are redundant". This is not necessary true - usage of sub-option can reduce the dhcp option type to be only 1. Although the usage of sub-option is not recommended in the next section. The readers may have question here. Suggest to add one sentence for sub-option and refer to next section.

10. Title of section 7 is misleading. It looks like it will introduce several new formats in this section. Suggest to change as "consideration on creating new formats".

11. in Section 9, the discussion regarding to DHCPv6 cannot draw the conclusion "prefer option formats...in the SMALLEST form factor". Be clear, I do agree the conclusion, but not the analysis.

12. That the address is better than FQDN is a bad example for we should separate DHCPv4 and DHCPv6 discussion. FQDN has become favourite over IPv6 address in many recent DHCPv6 option design. We have RFC6334, draft-ietf-mif-dhcpv6-route-option and etc. The FQDN is more flexible and may benefit in load-balance scenarios.

13. This draft says nothing about option orders, which is also important. The principle should be not give any specific order when design a new DHCP option. The option should be allowed to appear any place in the DHCP message. The only exception is security option(s). They need to perform algorithm over all other options. They may be allowed to located at the end.

14. draft-ietf-dhc-secure-dhcpv6 should be mentioned in the security consideration section. If it deployed, some threats, like man-in-middle can be prevented since it introduced an data integrity protection for DHCPv6 messages.

15. The text regarding to fixed/variable length options in security consideration section looks mis-located for me. They are not security relevant.

Best regards,

Sheng