Skip to main content

Last Call Review of draft-ietf-opsec-dhcpv6-shield-04
review-ietf-opsec-dhcpv6-shield-04-opsdir-lc-schoenwaelder-2014-11-24-00

Request Review of draft-ietf-opsec-dhcpv6-shield
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2014-12-01
Requested 2014-11-18
Authors Fernando Gont , Will (Shucheng) LIU , Gunter Van de Velde
I-D last updated 2014-11-24
Completed reviews Genart Last Call review of -04 by Ben Campbell (diff)
Secdir Last Call review of -04 by Hannes Tschofenig (diff)
Opsdir Last Call review of -04 by Jürgen Schönwälder (diff)
Assignment Reviewer Jürgen Schönwälder
State Completed
Request Last Call review on draft-ietf-opsec-dhcpv6-shield by Ops Directorate Assigned
Reviewed revision 04 (document currently at 08)
Result Has nits
Completed 2014-11-24
review-ietf-opsec-dhcpv6-shield-04-opsdir-lc-schoenwaelder-2014-11-24-00
Hi,

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
operational area directors.  Document editors and WG chairs should
treat these comments just like any other last call comments.

As far as I can tell, the document is ready to be published from a
technical point of view. Since similar filters are known to be useful
for DHCPv4, I assume that this specification will also be useful for
DHCPv6. I am not sure, though, why this is proposed as a Best Current
Practice (BCP) RFC. The cousing, RFC 6105, is Informational. I guess
this points down to OPSEC charter text that says "The OPSEC WG is will
not write or modify protocols." But taking the charter politics aside
for a moment, it seems strange to publish a document using phrases
such as "claim compliance with this specification" as BCP.

Editorial nits:

- I do not like the two 'aforementioned' in the abstract and the
  second may even not be accurate (or one needs a very liberal
  definition of mechanism). Here is an attempt of a rewrite:

   This document specifies a mechanism for protecting hosts connected to
   a switched network against rogue DHCPv6 servers.  It
   is based on DHCPv6 packet-filtering at the layer-2 device
   at which the packets are received.  A similar mechanism has
   been widely deployed in IPv4 networks ('DHCP snooping'), and hence it
   is desirable that similar functionality be provided for IPv6
   networks.

- Section 5 is titled "DHCPv6-Shield Implementation Advice". It uses
  RFC2129 MUST language and talks about criteria for compliance. Is
  "Advice" really the right word for this? Sounds a bit soft for what
  are actually implementation requirements.

- At the end of section 7, s/address. spoofing/address spoofing/

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <

http://www.jacobs-university.de/

>