Skip to main content

Last Call Review of draft-ietf-dhc-relay-id-suboption-
review-ietf-dhc-relay-id-suboption-secdir-lc-harkins-2009-10-16-00

Request Review of draft-ietf-dhc-relay-id-suboption
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-10-20
Requested 2009-10-03
Authors Bharat Joshi , D.T.V. Ramakrishna Rao , Mark Stapp
I-D last updated 2009-10-16
Completed reviews Genart Last Call review of -11 by Ben Campbell (diff)
Genart Last Call review of -11 by Ben Campbell (diff)
Secdir Last Call review of -?? by Dan Harkins
Assignment Reviewer Dan Harkins
State Completed
Request Last Call review on draft-ietf-dhc-relay-id-suboption by Security Area Directorate Assigned
Completed 2009-10-16
review-ietf-dhc-relay-id-suboption-secdir-lc-harkins-2009-10-16-00
  Hi,

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

  This draft defines a sub-option of DHCP's Relay Information Option
to identify relay agents. It is straightforward, easy to read, and
provides good use cases to justify the need for this sub-option. I
think it is ready for publication modulo a couple of minor issues.

  The Security Considerations mentions that security issues with the
Relay Information Option are discussed in RFC 3046 and RFC 4030 but I
think it might be a good idea to be a bit more specific and mention the
security considerations of the draft in question, even if all it did
was say something like, "This memo defines a sub-option of the Relay
Information Option and therefore is subject to the security considerations
of RFC 3046 and RFC 4030...."

  The draft defines two types of identifiers to populate this new
sub-option, one uses the DHCP Unique Identifier (DUID) and the other is
a simple ASCII string. For interoperability purposes, I think one of those
should be mandatory-to-implement (I suggest DUID).

  regards,

  Dan.