Re: [dhcwg] RFC3315 DECLINE definition

Andre Kostur <akostur@incognito.com> Fri, 10 February 2017 21:34 UTC

Return-Path: <akostur@incognito.com>
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 9682D129C53 for <dhcwg@ietfa.amsl.com>; Fri, 10 Feb 2017 13:34:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=incognito-com.20150623.gappssmtp.com
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 14z1MBItdKAG for <dhcwg@ietfa.amsl.com>; Fri, 10 Feb 2017 13:34:30 -0800 (PST)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D90A0129C4A for <dhcwg@ietf.org>; Fri, 10 Feb 2017 13:34:29 -0800 (PST)
Received: by mail-yw0-x236.google.com with SMTP id v200so28653117ywc.3 for <dhcwg@ietf.org>; Fri, 10 Feb 2017 13:34:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=incognito-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iQNU14iUu4yXhKZ5EKhKSKCOc7sAUTUJHQZ7z3Xi9fQ=; b=trfmZk9AAHgZcbu8LrQ0vpDadFEQb8JvaQ7lhAZayB1NC/2LncwQ/khMP/VYC+6a28 70XdyvtWN8dxt+5KtpYRx4X0FgbXDxqUxZ+SBagNBULXR/2BGIBx3UkqXJeVZoFJA+Ix 7ELjg8Mpdmx/h0y9sH4IRIM1bMt1RmKKmoQ8g1PzAvg4SjX8O5VDXKWyw7qRiYjiLORH VYw6z7dtyFmh0SIGZa5ajSuXrVXBylSTDhSZYad9cyv4HD3TffnpduLn69F1WlGwkL43 qapgiUiEE/bllFPiLjrGg4urQk/mSDMSstBxGIOkK5gYH39eESp8aQ0t9beqRByPEsRC P5KQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iQNU14iUu4yXhKZ5EKhKSKCOc7sAUTUJHQZ7z3Xi9fQ=; b=DpukNJY/tXlPgh0kCQRukKYzTqUKIlfr8hGyFmJfUMYYhQhfl70k78xJ+d31VKVXCX eH6mi53Y4SZjZGjNDecF1t/W08QToGQwhfdgGgKxPJenjeHkAzLuIZJRYsFrfor8/FGy SREzEfzj3NIpKeqEDEFgRGH7wE1GLbDTYogGdLRIon2lNLYkbYcNZKXeNfEfQ30t67Fl W07WKIpefY9IpqVXLZtMjsqCDfgq4WoT7brhCDLZ7OA7wuFrwzPmCBY5YJQ6rz+eyv4J OeZKAX9uqp6X1jx182bg6/87rNXhKGQOCPozI6dWehvbMYe0zhR5ejfY+7mbNwYVKy9j Xziw==
X-Gm-Message-State: AMke39kpWpwNFE8lLEB3mDi3Q9GKQsm1S5NcTuKJKRYX+jjK8c4i1nQZg4gRZrpzLx4rve9l/T3O6acIEdwlbCCM
X-Received: by 10.13.196.129 with SMTP id g123mr8251178ywd.17.1486762468878; Fri, 10 Feb 2017 13:34:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.113.5 with HTTP; Fri, 10 Feb 2017 13:34:28 -0800 (PST)
In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA19187@AZ-US1EXMB03.global.avaya.com>
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> <9142206A0C5BF24CB22755C8EC422E457AA189F9@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>
From: Andre Kostur <akostur@incognito.com>
Date: Fri, 10 Feb 2017 13:34:28 -0800
Message-ID: <CAL10_Bpy+4Eb4wUwuy5YkKaOO+69o0Ombej7n_ApCg1Gw-r0QQ@mail.gmail.com>
To: "Mudric, Dusan (Dusan)" <dmudric@avaya.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/eRzn9MidTEIp3JUU-vQMET4Tesc>
Cc: dhcwg <dhcwg@ietf.org>
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:34:31 -0000

On Fri, Feb 10, 2017 at 12:30 PM, Mudric, Dusan (Dusan)
<dmudric@avaya.com> wrote:
> DHCPv6 is then very light weight:

Well.. I suspect a bunch of us DHCP implementers may not agree with
that statement.

> - address assignment is not a part of the protocol,

Where did you get this idea from?  DHCPv6 assigns addresses all day
long.  What the client does with that assignment is up to the client.

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

How the client selects which address to use? Nope.  The protocol
doesn't care, nor should it.  The server determines what its willing
to ADVERTISE to the client and sends it off.  The client REQUESTs what
it wants.  The server REPLYs to complete the "contract" that the
client may use those addresses named in the REPLY for the specified
Valid Lifetime.  This allows different clients to choose different
methods for selecting an address.

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

It does not appear that anybody else here understands why you keep
hammering on this point.  You have not said why this is a problem
beyond "I want to".  A common implementation is that the server holds
aside the ADVERTISEd addresses for a short while (maybe a few minutes,
maybe 10s of seconds, its an implementation detail).  If the client
doesn't come back and REQUEST it, then release it back to the pool.
In an address space that's 2^64 in size, who cares if a handful of
addresses are being held aside for clients that have not yet come to
REQUEST them.  This worked perfectly fine even in the IPv4 cases where
the address space is much smaller (possibly 10s of addresses).

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

Nope.  And the admin may be intentionally doing so.  Not for the
protocol to decide.

> Did I get it correctly?

No.


I have to ask: what's the motivation behind asking these questions?
There seems to be a more fundamental misunderstanding underlying this
line of questioning.

-- 
Andre Kostur