Re: [dhcwg] dhcpv6-24: vendor-specific issues
Thomas Narten <narten@us.ibm.com> Wed, 15 May 2002 20:34 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 QAA21630 for <dhcwg-archive@odin.ietf.org>; Wed, 15 May 2002 16:34:49 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA29922 for dhcwg-archive@odin.ietf.org; Wed, 15 May 2002 16:35:04 -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 QAA29870; Wed, 15 May 2002 16:33:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29841 for <dhcwg@ns.ietf.org>; Wed, 15 May 2002 16:33:29 -0400 (EDT)
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 QAA21575 for <dhcwg@ietf.org>; Wed, 15 May 2002 16:33:13 -0400 (EDT)
Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g4FKVtm04658; Wed, 15 May 2002 16:31:55 -0400
Message-Id: <200205152031.g4FKVtm04658@cichlid.adsl.duke.edu>
To: Ralph Droms <rdroms@cisco.com>
cc: dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6-24: vendor-specific issues
In-Reply-To: Message from Ralph Droms <rdroms@cisco.com> of "Wed, 15 May 2002 13:23:33 EDT." <4.3.2.7.2.20020515131449.03653718@funnel.cisco.com>
Date: Wed, 15 May 2002 16:31:55 -0400
From: Thomas Narten <narten@us.ibm.com>
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
Ralph Droms <rdroms@cisco.com> writes: > 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. I think my issue is more with the wording than the intent. TO be sure I understand, the User Class option is one that is configured by the end user. I.e., to say "accounting", "engineering", etc. In that case, the server processing shouldn't be "implementation specific" or "vendor specific". Another confusing part. The text is talking about multiple occurances of the option. How this is dealt with shouldn't be configuration specific... We don't get interoperability that way... On rereading this, one thing that is missing is discussion about how the client sets the value. Is it really "opaque data"? Shouldn't this be a utf-8 string (for ease of configuration)? Also, the server should treat them as opaque values in conjunction with its configuration-specific data. This is not stated. Does this help clarify my concern? > > > 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? yes. It should not be implied that things "may not work well" if the server doesn't support the option. Rather, when it is supported, there maybe enhanced operation. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [Dhcwg] Re: Change to 'seconds' field in DHCP mes… Ralph Droms
- RE: [Dhcwg] Re: Change to 'seconds' field in DHCP… Bernie Volz (EUD)
- [dhcwg] RE: Change to 'seconds' field in DHCP mes… Ralph Droms
- Re: [Dhcwg] Re: Change to 'seconds' field in DHCP… Ted Lemon
- Re: [Dhcwg] Re: Change to 'seconds' field in DHCP… Ralph Droms
- Re: [Dhcwg] Re: Change to 'seconds' field in DHCP… Ted Lemon
- Re: [Dhcwg] Re: Change to 'seconds' field in DHCP… Ted Lemon
- Re: [Dhcwg] Re: Change to 'seconds' field in DHCP… Ralph Droms
- Re: [Dhcwg] Re: Change to 'seconds' field in DHCP… Ralph Droms
- Re: [Dhcwg] Re: Change to 'seconds' field in DHCP… Ted Lemon
- [dhcwg] Changes to remove "client-link-local-addr… Ralph Droms
- Re: [dhcwg] Changes to remove "client-link-local-… Ted Lemon
- Re: [dhcwg] Changes to remove "client-link-local-… Ralph Droms
- Re: [dhcwg] Changes to remove "client-link-local-… Ted Lemon
- Re: Re[2]: [dhcwg] Lease database storage in DHCP… Thomas Narten
- Re: [dhcwg] Assigning DHCPv6 option codes Thomas Narten
- Re: [dhcwg] dhcpv6-24: randomization delay before… Thomas Narten
- Re: [dhcwg] dhcpv6-24: randomization delay before… Thomas Narten
- Re: [dhcwg] dhcpv6-24: movement detection and Con… Thomas Narten
- Re: [dhcwg] dhcpv6-24: use of anycast Thomas Narten
- Re: [dhcwg] dhcpv6-24: use of anycast Thomas Narten
- Re: [dhcwg] dhcpv6-24: vendor-specific issues Thomas Narten
- Re: [dhcwg] status of draft-ietf-dhc-agent-subnet… Thomas Narten
- Re: [dhcwg] status of draft-ietf-dhc-agent-subnet… Thomas Narten
- Re: [dhcwg] DHC WG charter Thomas Narten
- Re: [dhcwg] DHC WG charter Thomas Narten
- RE: [dhcwg] DHC WG charter Ralph Droms
- Re: [dhcwg] DHC WG charter Thomas Narten
- Re: [dhcwg] DHC WG charter Ralph Droms
- Re: [dhcwg] Agenda items for IETF-59, Seoul Naiming Shen
- Re: [dhcwg] *DRAFT* minutes from WG meeting in Se… Naiming Shen
- Re: [dhcwg] dhc wg last call on "DHCP Relay Agent… Thomas Narten