Re: [dhcwg] RFC3315 DECLINE definition
Andre Kostur <akostur@incognito.com> Fri, 10 February 2017 16:25 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 328061299E1
for <dhcwg@ietfa.amsl.com>; Fri, 10 Feb 2017 08:25:24 -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 mz_sJWHZSomx for <dhcwg@ietfa.amsl.com>;
Fri, 10 Feb 2017 08:25:22 -0800 (PST)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com
[IPv6:2607:f8b0:4002:c05::22a])
(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 77020129577
for <dhcwg@ietf.org>; Fri, 10 Feb 2017 08:25:22 -0800 (PST)
Received: by mail-yw0-x22a.google.com with SMTP id v200so23873438ywc.3
for <dhcwg@ietf.org>; Fri, 10 Feb 2017 08:25:22 -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:content-transfer-encoding;
bh=H+lYkFkUfuAzOshjEvN+3FM6G/qULH/nmxDeUrfoWxI=;
b=eJ3lVidEJHM5E+7LcqOws/sWUqFv01OUBswTIa9AypDMClVuDDn3Gwxi/rahX6ODNv
tXYkDtT1g+Iy3d4V+VWTJNpovOfV7uMzlhqf4ySsCno++lkpdGMhTEMghSh99Akn82UQ
LQOEgwi0p7yx3MBD2CixiZv0t0dIjDXZQO33yAoGvVtbfO+1sgwzTVf6fjlFtbTZMnRW
ZWGX9qE4x2IIKSuDBK86aQPWjYzSStqAI97JHceOxsRuXWJlIr4feugOIcIzGOcf1PSj
Rs6o3CvD0rvvguZqPidhQftHV3amFZar/9SJBy7+m8xaj/6e5VZQ7iEOAvsN2x+j/eEg
4NRg==
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:content-transfer-encoding;
bh=H+lYkFkUfuAzOshjEvN+3FM6G/qULH/nmxDeUrfoWxI=;
b=DF6vXWI4uPJBOkCxybJoclkvIsMa0HsX9NlQsOZhYEqUb42hJzYEq2IkXuwHqdmSga
Jkh21OGMAcfIJF7ScQlaSk6vlpzlb8Qhq2jz/NfCR48sRVu8AOjN6p0VI3V86xj7Y597
ywNsVv0xJDBdzozPEHtiFFEl9kZhLtDSRh6BCfBff3pU3eS8+UigG3wSxjuNBh/0eypB
ZhO9LAS3GPNb+FxTtjqxfgIxCggv8BdNohjvhThPaq2GZpL2+4XFPZFqoLZGqAuNxWB/
TrZkji+T9ak8Tf2e0+qYLJ3HoXQnRARt2mvGBHK87JMA2oyin2rDv7KR5FLbG5ZhCJxq
V2Bw==
X-Gm-Message-State: AMke39l2mb0cY+ogoyNxVSuOTTeFJdmvwmtFXKBJULqXMZl7LiTrsf4h/HaUe2vlzkJS9bL71UY5n6MQ3s43RLhs
X-Received: by 10.13.196.129 with SMTP id g123mr7199124ywd.17.1486743921304;
Fri, 10 Feb 2017 08:25:21 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.113.5 with HTTP; Fri, 10 Feb 2017 08:25:20 -0800 (PST)
In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA18ED6@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>
From: Andre Kostur <akostur@incognito.com>
Date: Fri, 10 Feb 2017 08:25:20 -0800
Message-ID: <CAL10_BqFTSbhe6krvTUz1VnLw0pQGodPRrt8c39sNcMhRUqvQw@mail.gmail.com>
To: "Mudric, Dusan (Dusan)" <dmudric@avaya.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/zUTxDlUKoTt48TUxy_GN4VRRfww>
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 16:25:24 -0000
On Fri, Feb 10, 2017 at 6:35 AM, Mudric, Dusan (Dusan) <dmudric@avaya.com> wrote: > - If the key feature of the stateful DHCPv6 is the address assignment, why > there is no any address validation? You need to be clear on what you mean by "address validation". (Oh, and DHCPv6 is responsible for both address and prefix assignment) > - Why is the human intervention a part of the protocol? Why the protocol > requires an administrator not to make mistakes? Everything is susceptible to human error. You need to have more specific use-cases to get anywhere near this question. Also, the protocol does not mandate configuration management. Perhaps your DHCP server has the capability of comparing its configuration with that on a router to look for certain potential configuration mismatches. But that's a quality of implementation issue, not a protocol issue. > - Why the client must assign every address offered by the server? Why should > the client save the advertised leases for every IAADDR in IA’s, if the > status code is STATUS_Success? It doesn't have to. The client can pick and choose, preferably at the ADVERTISE/REQUEST stage. The server ADVERTISEs a dozen addresses, the client decides that it wants only 1 of them and REQUESTs it. Or a less well-behaved client could REQUEST them all, but only actually configure one of them on an interface. > - Why the client must use the address that does not match any of the router > prefixes? The router may not be advertising any prefixes, so the client doesn't know any different. (Nor should it) > - Why the client is not interworking with ND protocol? Be more specific. ND covers a lot of ground. > - Why the client does not return the address it does not use? Talk to your client vendor. The client can return addresses by protocol. Either by not REQUESTing it in the first place (though this isn't returning an address, it's just not claiming it), or by RELEASEing it. > - Why is DECLINE message associated with only one error code (DAD failed)? No use-case has been presented that the DHC working group has agreed upon that a DECLINE for other reasons is the appropriate response. -- Andre Kostur
- [dhcwg] RFC3315 DECLINE definition Mudric, Dusan (Dusan)
- Re: [dhcwg] RFC3315 DECLINE definition Bernie Volz (volz)
- Re: [dhcwg] RFC3315 DECLINE definition Mudric, Dusan (Dusan)
- Re: [dhcwg] RFC3315 DECLINE definition Bernie Volz (volz)
- Re: [dhcwg] RFC3315 DECLINE definition Mudric, Dusan (Dusan)
- Re: [dhcwg] RFC3315 DECLINE definition Bernie Volz (volz)
- Re: [dhcwg] RFC3315 DECLINE definition Mudric, Dusan (Dusan)
- Re: [dhcwg] RFC3315 DECLINE definition Bernie Volz (volz)
- Re: [dhcwg] RFC3315 DECLINE definition Bernie Volz (volz)
- Re: [dhcwg] RFC3315 DECLINE definition Mudric, Dusan (Dusan)
- Re: [dhcwg] RFC3315 DECLINE definition Mudric, Dusan (Dusan)
- Re: [dhcwg] RFC3315 DECLINE definition Ted Lemon
- Re: [dhcwg] RFC3315 DECLINE definition Simon Hobson
- Re: [dhcwg] RFC3315 DECLINE definition Mudric, Dusan (Dusan)
- Re: [dhcwg] RFC3315 DECLINE definition Ted Lemon
- Re: [dhcwg] RFC3315 DECLINE definition Mudric, Dusan (Dusan)
- Re: [dhcwg] RFC3315 DECLINE definition Ted Lemon
- Re: [dhcwg] RFC3315 DECLINE definition Mudric, Dusan (Dusan)
- Re: [dhcwg] RFC3315 DECLINE definition Andre Kostur
- Re: [dhcwg] RFC3315 DECLINE definition Ted Lemon
- Re: [dhcwg] RFC3315 DECLINE definition Mudric, Dusan (Dusan)
- Re: [dhcwg] RFC3315 DECLINE definition Mudric, Dusan (Dusan)
- Re: [dhcwg] RFC3315 DECLINE definition Ted Lemon
- Re: [dhcwg] RFC3315 DECLINE definition Mudric, Dusan (Dusan)
- Re: [dhcwg] RFC3315 DECLINE definition Ted Lemon
- Re: [dhcwg] RFC3315 DECLINE definition Simon Hobson
- Re: [dhcwg] RFC3315 DECLINE definition Mudric, Dusan (Dusan)
- Re: [dhcwg] RFC3315 DECLINE definition Mudric, Dusan (Dusan)
- Re: [dhcwg] RFC3315 DECLINE definition Andre Kostur
- Re: [dhcwg] RFC3315 DECLINE definition Ted Lemon
- Re: [dhcwg] RFC3315 DECLINE definition Andre Kostur
- Re: [dhcwg] RFC3315 DECLINE definition Simon Hobson
- Re: [dhcwg] RFC3315 DECLINE definition Tim Chown
- Re: [dhcwg] RFC3315 DECLINE definition Mudric, Dusan (Dusan)
- Re: [dhcwg] RFC3315 DECLINE definition Andre Kostur
- Re: [dhcwg] RFC3315 DECLINE definition Mudric, Dusan (Dusan)
- Re: [dhcwg] RFC3315 DECLINE definition Simon Hobson
- Re: [dhcwg] RFC3315 DECLINE definition Simon Hobson
- Re: [dhcwg] RFC3315 DECLINE definition Andre Kostur
- Re: [dhcwg] RFC3315 DECLINE definition Mudric, Dusan (Dusan)
- Re: [dhcwg] RFC3315 DECLINE definition Andre Kostur
- Re: [dhcwg] RFC3315 DECLINE definition Simon Hobson
- Re: [dhcwg] RFC3315 DECLINE definition Mudric, Dusan (Dusan)
- Re: [dhcwg] RFC3315 DECLINE definition Andre Kostur
- Re: [dhcwg] RFC3315 DECLINE definition Mudric, Dusan (Dusan)
- Re: [dhcwg] RFC3315 DECLINE definition Simon Hobson
- Re: [dhcwg] RFC3315 DECLINE definition Mudric, Dusan (Dusan)
- Re: [dhcwg] RFC3315 DECLINE definition Ted Lemon
- Re: [dhcwg] RFC3315 DECLINE definition Mudric, Dusan (Dusan)
- Re: [dhcwg] RFC3315 DECLINE definition 김우태 (Network Innovation Projec)
- Re: [dhcwg] RFC3315 DECLINE definition Chuck Anderson