[dhcwg] dhcpv6-24: vendor-specific issues

Thomas Narten <narten@us.ibm.com> Wed, 08 May 2002 15:15 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 LAA11938 for <dhcwg-archive@odin.ietf.org>; Wed, 8 May 2002 11:15:07 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05408 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:15:15 -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 LAA05222; Wed, 8 May 2002 11:14: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 LAA05196 for <dhcwg@optimus.ietf.org>; Wed, 8 May 2002 11:14:05 -0400 (EDT)
Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11775 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:13:55 -0400 (EDT)
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g48FE464028160 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:14:04 -0400
Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48FE4Q143940 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:14:04 -0400
Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g48FESQ19407 for <dhcwg@ietf.org>; Wed, 8 May 2002 11:14:28 -0400
Message-Id: <200205081514.g48FESQ19407@rotala.raleigh.ibm.com>
To: dhcwg@ietf.org
Date: Wed, 08 May 2002 11:14:28 -0400
From: Thomas Narten <narten@us.ibm.com>
Subject: [dhcwg] dhcpv6-24: vendor-specific issues
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

>    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?

> 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.

Thomas

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg