Re: [dhcwg] dhcpv6-24: vendor-specific issues
Ralph Droms <rdroms@cisco.com> Wed, 15 May 2002 17:28 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 NAA14685 for <dhcwg-archive@odin.ietf.org>; Wed, 15 May 2002 13:28:36 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA14802 for dhcwg-archive@odin.ietf.org; Wed, 15 May 2002 13:28:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14609; Wed, 15 May 2002 13:26:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14560 for <dhcwg@ns.ietf.org>; Wed, 15 May 2002 13:26:04 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14510 for <dhcwg@ietf.org>; Wed, 15 May 2002 13:25:45 -0400 (EDT)
Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-152.cisco.com [161.44.149.152]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA02962 for <dhcwg@ietf.org>; Wed, 15 May 2002 13:25:28 -0400 (EDT)
Message-Id: <4.3.2.7.2.20020515131449.03653718@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 15 May 2002 13:23:33 -0400
To: dhcwg@ietf.org
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: [dhcwg] dhcpv6-24: vendor-specific issues
In-Reply-To: <200205081514.g48FESQ19407@rotala.raleigh.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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
At 11:14 AM 5/8/2002 -0400, Thomas Narten wrote: > > Servers can interpret the meanings of multiple class specifications > > in an implementation dependent or configuration dependent manner, and > > so the use of multiple classes by a DHCP client should be based on > > the specific server implementation and configuration which will be > > used to process that User class option. > >This sure reads badly in the sense that it smells like >interoperability will not result. But I'm not sure what the intent of >the wording is here... Could someone clarify? The idea is to support additional flexibility and precision in identifying clients in some deployments. This situation anticipates that clients will be configured to send additional classing information and servers will have policies to select configuration information based on those classes. Because both the clients and server have been "managed" for this deployment, they will interoperate. A client that moves and tries to use a server that does not have policies for the classes specified by the client, or a client that does not supply the class specifications will get configuration information that is not selected on the basis of the client classes. > > 22.18. Vendor-specific Information option > > > > This option is used by clients and servers to exchange > > vendor-specific information. The definition of this information is > > vendor specific. The vendor is indicated in the enterprise-number > > field. Clients that do not receive desired vendor-specific > > information SHOULD make an attempt to operate without it, although > > they may do so (and announce they are doing so) in a degraded mode. > >This also reads badly and against interoperabilty. DHC clients should >never depend on vendor-specific options in order to function >correctly. This text is essentially copied directly from section 8.4 of RFC2132 (which, of course, doesn't necessarily make it a good idea). Perhaps the differentiation should be "enhanced operation" with the vendor-specific information versus "functioning operation" without? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] dhcpv6-24: vendor-specific issues Thomas Narten
- Re: [dhcwg] dhcpv6-24: vendor-specific issues Ralph Droms
- RE: [dhcwg] dhcpv6-24: vendor-specific issues Bernie Volz (EUD)