Early Review of draft-ietf-dhc-relay-server-security-02
review-ietf-dhc-relay-server-security-02-intdir-early-korhonen-2017-01-25-00

Request Review of draft-ietf-dhc-relay-server-security
Requested rev. no specific revision (document currently at 05)
Type Early Review
Team Internet Area Directorate (intdir)
Deadline 2017-02-03
Requested 2017-01-18
Requested by Suresh Krishnan
Other Reviews Secdir Last Call review of -03 by Catherine Meadows (diff)
Genart Last Call review of -03 by Francis Dupont (diff)
Genart Telechat review of -03 by Francis Dupont (diff)
Review State Completed
Reviewer Jouni Korhonen
Review review-ietf-dhc-relay-server-security-02-intdir-early-korhonen-2017-01-25
Posted at https://mailarchive.ietf.org/arch/msg/int-dir/bzJQXqsS5vvXCk98pY7-gMzR1J8
Reviewed rev. 02 (document currently at 05)
Review result Not Ready
Draft last updated 2017-01-25
Review closed: 2017-01-25

Review
review-ietf-dhc-relay-server-security-02-intdir-early-korhonen-2017-01-25

Disclaimer: I have not followed recent DHC discussions to the extent that the existence this document was new to me.

Issues:

My issues with the document are the following. First, it actually updates a great deal of RFC3315 (Section 21.1) while there is RFC3315bis in progress. Why the DHCPv6 part of this document is not directly contributed to RFC3315bis work? There's even author overlap so there must be a good reason. Second, if there is a reason to keep the content of this document separate from RFC3315 body of work, at least this specification should then target to update RFC3315bis and not RFC3315.

Other smaller nits:

o This document updates both RFC3315(bis) and RFC1542. Those are not reflected in the document title page and abstract. 

o I would separate the new recommendation text for DHCPv4 and DHCPv6 into their own respective section. Having just a one-liner statement "also applies to DHCPv4 [RFC1542].." is kind of confusing in a middle of very DHCPv6 specific text. I recon the DHCPv4 section would be short, but definitely more clear in that way.

o Although it should be obvious, but I would explicitly point it out in the Security Considerations that the security model here is hop-by-hop. If there are multiple relays then there will be multiple IPsec tunnels as well.

o Section 14:  s/section 14,/Section 14,

o