Re: [dhcwg] RFC3315 DECLINE definition

Simon Hobson <linux@thehobsons.co.uk> Fri, 10 February 2017 21:44 UTC

Return-Path: <linux@thehobsons.co.uk>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFF9129C5A for <dhcwg@ietfa.amsl.com>; Fri, 10 Feb 2017 13:44:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ovp17gq4jDwy for <dhcwg@ietfa.amsl.com>; Fri, 10 Feb 2017 13:44:48 -0800 (PST)
Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [81.174.135.208]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07FCE1294A9 for <dhcwg@ietf.org>; Fri, 10 Feb 2017 13:44:48 -0800 (PST)
X-Quarantine-ID: <XsdMXlN1EMvp>
X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk
X-Amavis-Alert: BAD HEADER SECTION, Header line longer than 998 characters: References: <91[...]
Received: from simons-macbookpro.lan (magpiehouse.plus.com [80.229.10.150]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 5DA0114366 for <dhcwg@ietf.org>; Fri, 10 Feb 2017 21:44:39 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Simon Hobson <linux@thehobsons.co.uk>
In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA19187@AZ-US1EXMB03.global.avaya.com>
Date: Fri, 10 Feb 2017 21:44:38 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <6497B49C-AE2C-4C2E-9C13-B8E8764A64B7@thehobsons.co.uk>
References: <9142206A0C5BF24CB22755C8EC422E457AA186B9@AZ-US1EXMB03.global.avaya.com> <531b6fa753a441c19f1d47958f20b659@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18717@AZ-US1EXMB03.global.avaya.com> <240e4b5573614422a42abec328872c0b@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA18746@AZ-US1EXMB03.global.avaya.com> <fd3365190bd445b1ad00a7d8043530dd@XCH-ALN-003.cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA188B2@AZ-US1EXMB03.global.avaya.com> <6792EF5E-8C1F-4D3B-BC6D-8D2EA011BF31@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1890A@AZ-US1EXMB03.global.avaya.com> <36880D80-601D-42BF-92F1-3E1B3A59A8FD@cisco.com> <9142206A0C5BF24CB22755C8EC422E457AA1892A@AZ-US1EXMB03.global.avaya.com> <15160861-4D37-4A5E-900A-8AD688218EEF@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA1898F@AZ-US1EXMB03.global.avaya.com> <C16D3614-AD9E-4AB3-915B-5288DB0EB239@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA189BD@AZ-US1EXMB03.global.avaya.com> <9142206A0C5BF24CB22755C8EC422E457A A189F9@AZ-US1EXMB03.global.avaya.com> <A3AFA8FF-FDEF-4058-814A-E687D5CC2969@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA18ABB@AZ-US1EXMB03.global.avaya.com> <A023117A-2B06-4660-88B9-9AB183F05B66@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA18B12@AZ-US1EXMB03.global.avaya.com> <B2511278-5D7A-40E0-AC4A-60784C101A80@fugue.com> <9142206A0C5BF24CB22755C8EC422E457AA18B5E@AZ-US1EXMB03.global.avaya.com> <36E8C88B-82EA-41FE-AB55-55F9CD110664@thehobsons.co.uk> <9142206A0C5BF24CB22755C8EC422E457AA18ED6@AZ-US1EXMB03.global.avaya.com> <CAL10_BqFTSbhe6krvTUz1VnLw0pQGodPRrt8c39sNcMhRUqvQw@mail.gmail.com> <9142206A0C5BF24CB22755C8EC422E457AA1906F@AZ-US1EXMB03.global.avaya.com> <CAL10_BorkqQXZUOFWarj_+275u1z9L9Xtkse=RQjGnOeFveNJg@mail.gmail.com> <9142206A0C5BF24CB22755C8EC422E457AA19187@AZ-US1EXMB03.global.avaya.com>
To: dhcwg <dhcwg@ietf.org>
X-Mailer: Apple Mail (2.1510)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/a70QsgWLCa15-m4Ma4Qz97rHl0o>
Subject: Re: [dhcwg] RFC3315 DECLINE definition
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Feb 2017 21:44:50 -0000

"Mudric, Dusan (Dusan)" <dmudric@avaya.com> wrote:

> DHCPv6 is then very light weight:
> - address assignment is not a part of the protocol,

How do you come to that idea ? The primary function of DHCP is to provide IP addresses.

> - address selection is not part of the protocol, and

Correct. The job of DHCP is to issue addresses - it can't know in advance what any client might want to use it for.

> - if the client, using its own logic to select from the offered addresses (not part of the protocol), does not select some or any, the protocol should not report that to the server, and

There can be multiple servers, and no client is obliged to accept an offer that doesn't meet it's requirements. For example, a VoIP phone might be configured to only accept an offer which includes options to configure the telephony aspects of the device.
It's not that uncommon to have two servers on a network - one "general IT" one, and one embedded in the PBX. The phones will only take leases from the PBX, and the PBX will ignore clients other than the phones.
The DHCP protocol specification cannot account for all such eventualities.

> - the fact that this kind of protocol can leave a device unreachable does not matter to the protocol that assigns the address.

"Doesn't matter" isn't the right way to describe it. That there are cases where things won't work is inherent in any general purpose protocol required to work in a flexible manner, with a wide range of network topologies and clients, etc.