Re: [dhcwg] Review of draft-ietf-dhc-relay-agent-flags-02.txt
Thomas Narten <narten@us.ibm.com> Tue, 13 March 2007 12:45 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 1HR6Nv-00013c-P3; Tue, 13 Mar 2007 08:45:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR6Nu-00013V-J4 for dhcwg@ietf.org; Tue, 13 Mar 2007 08:45:46 -0400
Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR6Ns-0003vP-A0 for dhcwg@ietf.org; Tue, 13 Mar 2007 08:45:46 -0400
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l2DCkUb3019157 for <dhcwg@ietf.org>; Tue, 13 Mar 2007 08:46:30 -0400
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l2DCiReb248116 for <dhcwg@ietf.org>; Tue, 13 Mar 2007 08:44:27 -0400
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l2DCiQrG032441 for <dhcwg@ietf.org>; Tue, 13 Mar 2007 08:44:27 -0400
Received: from cichlid.raleigh.ibm.com (sig-9-48-32-138.mts.ibm.com [9.48.32.138]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l2DCiPgF032415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Mar 2007 08:44:26 -0400
Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.8/8.12.5) with ESMTP id l2DCiOl5000429; Tue, 13 Mar 2007 06:44:25 -0600
Message-Id: <200703131244.l2DCiOl5000429@cichlid.raleigh.ibm.com>
To: Mark Stapp <mjs@cisco.com>
Subject: Re: [dhcwg] Review of draft-ietf-dhc-relay-agent-flags-02.txt
In-reply-to: <45F5C1A8.6090208@cisco.com>
References: <200703071423.l27ENvSI026953@cichlid> <45F5C1A8.6090208@cisco.com>
Comments: In-reply-to Mark Stapp <mjs@cisco.com> message dated "Mon, 12 Mar 2007 14:10:00 -0700."
Date: Tue, 13 Mar 2007 06:44:24 -0600
From: Thomas Narten <narten@us.ibm.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
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
> 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? I think they (and the IETF as a whole, as I don't think the IETF LC has happened) will probably be able to evaluate it better with the extra sentence (btw, what will it be?). But is it critical? No. Also, since it only takes 2 minutes to submit a revised ID (once you have the text), I think its often less work to just do so than have a discussion about whether to. :-) > >> 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? Well, for one thing, the above text makes its sound like a protocol violation to implement the spec, but choose not to send the option (e.g., even if configured to do so for some reason). That seems a bit strong to me. Thomas _______________________________________________ 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