Re: NT 3.51 dhcp client and server ip address
Don Coolidge <dfc@apple.com> Wed, 04 December 1996 19:50 UTC
Received: from cnri by ietf.org id aa24454; 4 Dec 96 14:50 EST
Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa18581;
4 Dec 96 14:50 EST
Received: from reef.bucknell.edu by mail.bucknell.edu;
(5.65v3.2/1.1.8.2/17Jul96-0109PM)
id AA21298; Wed, 4 Dec 1996 14:38:42 -0500
Date: Wed, 4 Dec 1996 14:38:42 -0500
Message-Id: <aecaff670002100463db@[17.202.32.184]>
Errors-To: droms@bucknell.edu
Reply-To: dhcp-v4@bucknell.edu
Originator: dhcp-v4@bucknell.edu
Sender: dhcp-v4@bucknell.edu
Precedence: bulk
From: Don Coolidge <dfc@apple.com>
To: Multiple recipients of list <dhcp-v4@bucknell.edu>
Subject: Re: NT 3.51 dhcp client and server ip address
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4
Mime-Version: 1.0
>At 6:54 PM 12/3/96, Ted Lemon wrote: >>In general, it just seems like a bad idea to >>have multiple identifiers referring to the same object. > >Yeah - looks like we blew it by overloading the "identifier" field to also >act as the "return address" field. > >We can either fix it or leave it: > > * Fixing will delay the advancement to Draft Standard, as it would > represent a fairly basic change to the behavior of clients and > servers. > > * Leaving it leaves the problem with multiple identifiers for a single > server - as pointed out by Ted - unfixed. > >Discussion? > >- Ralph Leaving it as is simply postpones fixing Ted's problem, yes? And while fixing it would require reworking of some existing implementations, that would have to be done anyway when the problem is finally dealt with, as it must be eventually. Fixing it now frontloads that effort and leads more quickly to common interpretation of the spec and greater interoperability. I've worked at companies where not slipping a schedule often had greater priority than fixing known product problems. I have yet to see following that philosophy lead to anything other than trouble. In my opinion, we should deal with this known problem now and take the hit on Draft Standard status. -- Don Coolidge
- NT 3.51 dhcp client and server ip address Tim Rowe
- Re: NT 3.51 dhcp client and server ip address Tim Rowe
- Re: NT 3.51 dhcp client and server ip address Ted Lemon
- Re: NT 3.51 dhcp client and server ip address Ken Key
- Re: NT 3.51 dhcp client and server ip address Ted Lemon
- Re: NT 3.51 dhcp client and server ip address Shawn Mamros
- Re: NT 3.51 dhcp client and server ip address Matt Crawford
- Re: NT 3.51 dhcp client and server ip address Shawn Mamros
- Re: NT 3.51 dhcp client and server ip address Ken Key
- Re: NT 3.51 dhcp client and server ip address Ted Lemon
- Re: NT 3.51 dhcp client and server ip address Ralph Droms
- Re: NT 3.51 dhcp client and server ip address Don Coolidge
- Re: NT 3.51 dhcp client and server ip address Mike Carney - SunSoft Internet Engineering
- Re: NT 3.51 dhcp client and server ip address Ted Lemon
- Re: NT 3.51 dhcp client and server ip address Kim Kinnear
- RE: NT 3.51 dhcp client and server ip address Pratik Gupta
- RE: NT 3.51 dhcp client and server ip address Pratik Gupta
- Re: NT 3.51 dhcp client and server ip address Shawn Mamros
- Re: NT 3.51 dhcp client and server ip address Shawn Mamros
- Re: NT 3.51 dhcp client and server ip address Ken Key
- Re: NT 3.51 dhcp client and server ip address Ted Lemon
- Re: NT 3.51 dhcp client and server ip address Ted Lemon
- Re: NT 3.51 dhcp client and server ip address David Lapp
- Re: NT 3.51 dhcp client and server ip address Ken Key
- Re: NT 3.51 dhcp client and server ip address John M. Wobus
- Re: NT 3.51 dhcp client and server ip address Shawn Mamros
- Re: NT 3.51 dhcp client and server ip address Ted Lemon
- Re: NT 3.51 dhcp client and server ip address Ralph Droms
- Re: NT 3.51 dhcp client and server ip address David Lapp
- Re: NT 3.51 dhcp client and server ip address Ted Lemon