Re: [dhcwg] Review of draft-ietf-dhc-relay-agent-flags-02.txt

Mark Stapp <mjs@cisco.com> Mon, 12 March 2007 21:10 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 1HQrmY-0006ak-Mi; Mon, 12 Mar 2007 17:10:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQrmX-0006X9-DT for dhcwg@ietf.org; Mon, 12 Mar 2007 17:10:13 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQrmM-0007zP-Bp for dhcwg@ietf.org; Mon, 12 Mar 2007 17:10:13 -0400
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 12 Mar 2007 14:10:02 -0700
X-IronPort-AV: i="4.14,275,1170662400"; d="scan'208"; a="120474058:sNHT46432548"
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l2CLA14i001661; Mon, 12 Mar 2007 14:10:01 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2CLA11T010198; Mon, 12 Mar 2007 21:10:01 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 14:10:01 -0700
Received: from [10.21.153.241] ([10.21.153.241]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 14:10:01 -0700
Message-ID: <45F5C1A8.6090208@cisco.com>
Date: Mon, 12 Mar 2007 14:10:00 -0700
From: Mark Stapp <mjs@cisco.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Thomas Narten <narten@us.ibm.com>
Subject: Re: [dhcwg] Review of draft-ietf-dhc-relay-agent-flags-02.txt
References: <200703071423.l27ENvSI026953@cichlid>
In-Reply-To: <200703071423.l27ENvSI026953@cichlid>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Mar 2007 21:10:01.0253 (UTC) FILETIME=[CC16F550:01C764EA]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3192; t=1173733801; x=1174597801; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mjs@cisco.com; z=From:=20Mark=20Stapp=20<mjs@cisco.com> |Subject:=20Re=3A=20[dhcwg]=20Review=20of=20draft-ietf-dhc-relay-agent-fl ags-02.txt |Sender:=20; bh=1Zi5YWEJ0RkwRcszRY62ut5TcbckZzzVy2guqvYXo8I=; b=KsH41F6xI13KSs2tDn6Gc7YavO6DqVpfLsDp+nzR2ol6AX1p+gLwm/zoWRZP+Y6kED5mGMJB By/aARIGvvhahOMw7C21aQyt1cYTqUpcVDmq96ZCBoLfGDj266Hy4q+Y;
Authentication-Results: sj-dkim-4; header.From=mjs@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Cc: dhcwg@ietf.org
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

Thomas,
Thanks for the comments.

Some questions inline...

Thomas Narten wrote:
> 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?)
>

Since the wg last-call is over, I'm not sure quite what the right thing 
to do is. Do you feel that the iesg will not be able to evaluate this 
draft without another revision, containing one extra sentence?

>> 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.
> 
> 

the intention here wasn't to introduce some sort of ... unfunded 
mandate. it was just to make it clear what support for the standard 
would mean. if an implementation doesn't support the (eventual) 
standard, then of course it's not going to be including this suboption. 
an implementation that claims compliance needs to obey section 4. an 
implementation that isn't compliant ... probably won't. Is there 
something here that's different from any of the other suboptions (or 
options) that have been developed individually?

-- Mark

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg