[dhcwg] draft-ietf-dhc-agentoptions-device-class-02.txt
Thomas Narten <narten@us.ibm.com> Fri, 02 November 2001 11:55 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29489 for <dhcwg-archive@odin.ietf.org>; Fri, 2 Nov 2001 06:55:40 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA15569 for dhcwg-archive@odin.ietf.org; Fri, 2 Nov 2001 06:55:42 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA15453; Fri, 2 Nov 2001 06:47:50 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA15428 for <dhcwg@optimus.ietf.org>; Fri, 2 Nov 2001 06:47:49 -0500 (EST)
Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29413 for <dhcwg@ietf.org>; Fri, 2 Nov 2001 06:47:46 -0500 (EST)
Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id fA2Blms04343; Fri, 2 Nov 2001 06:47:48 -0500
Message-Id: <200111021147.fA2Blms04343@cichlid.adsl.duke.edu>
To: Rich Woundy <rwoundy@cisco.com>, doug@yas.com
cc: dhcwg@ietf.org
Date: Fri, 02 Nov 2001 06:47:48 -0500
From: Thomas Narten <narten@us.ibm.com>
Subject: [dhcwg] draft-ietf-dhc-agentoptions-device-class-02.txt
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
The IESG discussed this document yesterday, and has two comments on it. First, the title of this document "Addition of Device Class to Agent Options" suggests that it is a general option, i.e., one that could support multiple device classes. In practice, it is a "DOCSIS device type" option. It might be better to do one of the following: 1) turn it into a more general option, by, for example, adding a "Device Class" type to the option value, so that other types of device classes could later be defined. Right now, this isn't possible. To define a new device class, one would need to assign a new Relay Agent Option and define the new option. Doing this would also potentially conserve Relay Agent Option numbers (a one-byte field). Do we expect there to me more in the future? 2) narrow the language to make it clear that is an option that only applies to DOCSIS. I think changing the title to something like "The DOCSIS Device Class DHCP Relay Agent Option" would do the trick. The second issue concerns the security considerations section: > The security considerations section doesn't specify how the implied > trust relationship can be done in practice. Thus it doesn't provide > sufficient info for an implementor. > > This can be handled by addition a reference to the relay options spec > e.g. at the end of the first paragraph in section 3. These are the only two issues that were raised. Once they are resolved, I expect approval of the document. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] draft-ietf-dhc-agentoptions-device-class-… Thomas Narten
- [dhcwg] Re: draft-ietf-dhc-agentoptions-device-cl… Rich Woundy
- Re: [dhcwg] Re: draft-ietf-dhc-agentoptions-devic… Thomas Narten