The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption
draft-ietf-dhc-relay-agent-flags-03

[Ballot comment]
From the Gen-ART review by Gonzalo Camarillo...

  The acronym DHCP should be expanded on its first use in the title
  and in the abstract.

  Last line of the first paragraph of the Introduction: The period
  should go after the references:

    OLD:
    DHCP Server.  [RFC2131] [RFC2132] [RFC3046]

    NEW:
    DHCP Server  [RFC2131] [RFC2132] [RFC3046].
              ^                              ^

IANA Last Call Comment:

[ Question: would you want an IANA sub-registry to hold
  the list of flags? ]

Upon approval of this document, the IANA will make the
following assignments in the "BOOTP AND DHCP PARAMETERS"
registry located at

http://www.iana.org/assignments/bootp-dhcp-parameters

sub-registry "DHCP Agent Sub-Option Codes - per [RFC3046]"

Code Sub-Option Description Reference
----- ----------------------- ---------
[tbd] DHCP Relay Flags [RFC-dhc-relay-agent-flags-03]

We understand the above to be the only IANA Action for
this document.

1) Have the chairs personally reviewed this version of the ID and do
  they believe this ID is sufficiently baked to forward to the IESG
  for publication?

Yes and yes.
 
2) Has the document had adequate review from both key WG members and
  key non-WG members? Do you have any concerns about the depth or
  breadth of the reviews that have been performed?

It has been reviewed by several key WG members. The draft itself
is very simple, and it has been agreed in the WG that this is the
solution to an issue raised with draft-ietf-dhc-server-override.
Namely a mail from David Hankins in response to the IETF last call
on draft-ietf-dhc-server-override-03.txt pointing out that DHCP
server needs to know whether message from client was unicast or
broadcast.
 
3) Do you have concerns that the document needs more review from a
  particular (broader) perspective (e.g., security, operational
  complexity, someone familiar with AAA, etc.)?

No
 
4) Do you have any specific concerns/issues with this document that
  you believe the ADs and/or IESG should be aware of? For example,
  perhaps you are uncomfortable with certain parts of the document,
  or whether there really is a need for it, etc., but at the same
  time these issues have been discussed in the WG and the WG has
  indicated it wishes to advance the document anyway.

No

5) How solid is the WG consensus behind this document?  Does it
  represent the strong concurrence of a few individuals, with others
  being silent, or does the WG as a whole understand and agree with
  it?

The consensus is solid, many people have been involved in discussing
how to solve this problem, and agree on the solution. Also a decent
number of people supported this document during wglc, and none
opposed it.

6) Has anyone threatened an appeal or otherwise indicated extreme
  discontent?  If so, please summarize what are they upset about.

No
 
7) Have the chairs verified that the document adheres to _all_ of the
  ID nits?  (see http://www.ietf.org/ID-nits.html).

Copyright notices and disclaimer should be updated from RFC 3978 to
4748, required from February 1st? Copyright year is 2006. The
idnits tool (http://tools.ietf.org/tools/idnits/) also claims that
there is an additional embedded copyright, but I'm unable to find
any.
 
8) For Standards Track and BCP documents, the IESG approval
  announcement includes a writeup section with the following
  sections:

  - Technical Summary

The document specifies a relay agent suboption that a relay agent
must include in the relay agent information option. The suboption
contains flags that an agent can use to provide the server
information about a client that would otherwise not be available
to the server. This document also specifies one flag for this
option to tell the server whether the client messages was sent as
unicast or broadcast. This flag is useful when server override as
specified in draft-ietf-dhc-server-override-04 is used.

  - Working Group Summary

An issue with server override and server not being able to know
whether the client message was unicast or broadcast (to
distinguish between renew and rebind) was brought up in response
to IETF last call of draft-ietf-dhc-server-override-03 in February
2006. After discussions in the wg in February and March it was
concluded that some relay agent sub-option was needed for this.
This draft was adopted as a wg item after verifying consensus
on the wg mailing list in June 2006. WGLC was done in September
2006. Several people supported this document and none were
against. There were some editorial comments. This new revision
has been changed to accomodate those comments.

  - Protocol Quality

The protocol specified in this document specifies a new DHCPv4
relay agent suboption. The specification of this protocol is
pretty simple, and should be trivial to implement.