[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