RE: [dhcwg] I-D ACTION:draft-ietf-dhc-vendor-02.txt

"Richard Barr Hibbs" <> Wed, 19 May 2004 01:45 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id VAA04119; Tue, 18 May 2004 21:45:08 -0400 (EDT)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.20) id 1BQG5p-0004WW-Gq; Tue, 18 May 2004 21:42:01 -0400
Received: from ([] by with esmtp (Exim 4.20) id 1BQFmq-0001AS-9i for; Tue, 18 May 2004 21:22:24 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id VAA03227 for <>; Tue, 18 May 2004 21:22:21 -0400 (EDT)
Received: from ([] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQFmn-0007ck-HA for; Tue, 18 May 2004 21:22:21 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQFlt-0007YA-00 for; Tue, 18 May 2004 21:21:25 -0400
Received: from ([]) by ietf-mx with smtp (Exim 4.12) id 1BQFl4-0007UJ-00 for; Tue, 18 May 2004 21:20:34 -0400
Received: from unknown (HELO BarrH63p601) ( with login) by with SMTP; 19 May 2004 00:44:20 -0000
Reply-To: <>
From: "Richard Barr Hibbs" <>
To: <>
Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-vendor-02.txt
Date: Tue, 18 May 2004 17:54:04 -0700
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Importance: Normal
In-Reply-To: <>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit


here's an excerpt from section 3:

   "This option contains information corresponding to one or
   Enterprise Numbers.  Multiple instances of this option
may be
   present, and MUST be concatenated in accordance with RFC
3396 [4].
   An Enterprise Number SHOULD only occur once among all
instances of
   this option.  Behavior is undefined if an Enterprise
Number occurs
   multiple times.  The information for each Enterprise
Number is
   treated independently, regardless or whether it occurs in
an option
   with other Enterprise Numbers, or in a separate option."

While I agree that it is very difficult to specify
appropriate behavior of the server if a client sends
[apparently] ambiguous data (i.e., multiple instances of an
Enterprise Number), I'm becoming less and less favorably
disposed towards protocol behavior that is undefined or
implementation-dependent.  I'd prefer to see something like
the following:

   "An Enterprise Number MUST only occur once among all
instances of this
   option.  If an Enterprise Number occurs more than once,
despite this
   restriction, a DHCPv4 server SHOULD process only the LAST

I suggest this wording because I believe that the MUST is
what you really intend in this section, and the second
proposed sentence specifies what would happen if a client
violates the restriction.

I'm open to suggestions and other opinions about this,


dhcwg mailing list