[dhcwg] Review of draft-ietf-dhc-relay-agent-flags-02.txt
Thomas Narten <narten@us.ibm.com> Wed, 07 March 2007 14:24 UTC
Return-path: <dhcwg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOx3k-0002kP-5Z; Wed, 07 Mar 2007 09:24:04 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOx3j-0002kD-6J for dhcwg@ietf.org; Wed, 07 Mar 2007 09:24:03 -0500
Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOx3g-0006pO-S1 for dhcwg@ietf.org; Wed, 07 Mar 2007 09:24:03 -0500
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l27ENwub023095 for <dhcwg@ietf.org>; Wed, 7 Mar 2007 09:23:58 -0500
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l27ENwg0283300 for <dhcwg@ietf.org>; Wed, 7 Mar 2007 09:23:58 -0500
Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l27ENw4m020623 for <dhcwg@ietf.org>; Wed, 7 Mar 2007 09:23:58 -0500
Received: from cichlid (wecm-9-67-138-12.wecm.ibm.com [9.67.138.12]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l27ENvr3020594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <dhcwg@ietf.org>; Wed, 7 Mar 2007 09:23:58 -0500
Received: from cichlid (localhost.localdomain [127.0.0.1]) by cichlid (8.13.8/8.12.5) with ESMTP id l27ENvSI026953 for <dhcwg@ietf.org>; Wed, 7 Mar 2007 09:23:57 -0500
Message-Id: <200703071423.l27ENvSI026953@cichlid>
To: dhcwg@ietf.org
Date: Wed, 07 Mar 2007 09:23:57 -0500
From: Thomas Narten <narten@us.ibm.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Subject: [dhcwg] Review of draft-ietf-dhc-relay-agent-flags-02.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Errors-To: dhcwg-bounces@ietf.org
Here is my review of this document. I have not been following the discussion on this document, so this is a "fresh eyes" review. 2007-03-06 review of -02 (in AD evaluation state) Overall, I suspect this option is useful and a reasonable thing to do. However, I think the document itself could make a better case for why the option is needed. Some small text changes are probably all that is needed to acheive this. E.g., > In general, DHCP servers may also make subtle (and sometimes not so > subtle) changes in their processing algorithms depending on whether > or not the DHCP server received the message as a unicast packet from > the DHCP client directly, a broadcast packet from the DHCP client on > a locally connected network, or a unicast packet from a DHCP Relay > Agent which has forwarded on a packet broadcast from a DHCP client > connected to a network local to the DHCP Relay Agent. The document makes the general assertion above several times, but I would find it helpful for the document to provide at least one specific example. What would the server do differently and why/how does this option solve the problem? Later, the document says: > This option provides additional information to the DHCP server. The > DHCP server MAY use this information to make processing decisions > regarding the DHCP Client's packet which it is processing. For > instance, knowledge of the broadcast or unicast reception of a packet > by a DHCP relay agent is important when making the processing > decisions required to implement Load Balancing [RFC3074]. A single sentence here explaining how this information could actually be used would be helpful. (Why leave this to the reader to figure out?) > 4. DHCP Relay Agent Behavior > > A DHCP relay agent MUST include this suboption in every Relay Agent > Information Option [RFC3046] it adds to a forwarded DHCP request. In It seems to me like this MUST is too strong and unenforceable. Relay Agent options are already defined, and this is a new one, so this requirement is unenforceable. Moreover, why is this so important? In the absence of a compelling justification, SHOULD seems more appropriate. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] Review of draft-ietf-dhc-relay-agent-flag… Thomas Narten
- Re: [dhcwg] Review of draft-ietf-dhc-relay-agent-… Mark Stapp
- Re: [dhcwg] Review of draft-ietf-dhc-relay-agent-… Thomas Narten
- Re: [dhcwg] Review of draft-ietf-dhc-relay-agent-… Stig Venaas
- [dhcwg] Status of draft-ietf-dhc-relay-agent-flag… Jari Arkko
- [dhcwg] Re: Status of draft-ietf-dhc-relay-agent-… Mark Stapp
- Re: [dhcwg] Review of draft-ietf-dhc-relay-agent-… David W. Hankins
- Re: [dhcwg] Review of draft-ietf-dhc-relay-agent-… Mark Stapp