Re: [dhcwg] RFC3315 DECLINE definition

Ted Lemon <mellon@fugue.com> Thu, 09 February 2017 17:13 UTC

Return-Path: <mellon@fugue.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 7CAA3129C06 for <dhcwg@ietfa.amsl.com>; Thu, 9 Feb 2017 09:13:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-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 EKgpL3YiJVeR for <dhcwg@ietfa.amsl.com>; Thu, 9 Feb 2017 09:13:58 -0800 (PST)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 4955E129BFD for <dhcwg@ietf.org>; Thu, 9 Feb 2017 09:13:58 -0800 (PST)
Received: by mail-qt0-x234.google.com with SMTP id v23so10253142qtb.0 for <dhcwg@ietf.org>; Thu, 09 Feb 2017 09:13:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=NWJbXnULnKmkAkic3dFoIU/L06lOL1+0mhPHYUJW0kI=; b=huWGQn27SA0ljEDTEYRFAWNLts7qYUpxZUEtjNSH/noNj0SZCGqYePThnCCGw+dxOd BgOXSkWgb/Q6E4QIQb+p1wlmB/stnp0XwiZ6/i3zF4VugYCEmYpHqHTigwZv9eWmsj2K jGFWlAed4bV13JlMIlzWi7fydN+k4375eA+rmJasVbrtyI3AYsdsOi/4DjsPL9SAZlPA IXCVbG1fnc5P86mYsH4rkvq2MEY5p3dGl2x/ZqlsOpYq8Lz1yrn4KtrRiC4NkD72taHj 16mz99NJ9AUtWDQgZ5yFdXNcZfGHrxG0mFXU8rJmnWIdMhEtO08uDhlby8Zp8+S93hDJ VslA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=NWJbXnULnKmkAkic3dFoIU/L06lOL1+0mhPHYUJW0kI=; b=TZQr3Zg5PpiG+0r3aIi3NGJ54JUiWSxAl+PfNlwBwQT5Y+emvJEadXZpZMDrcEq9yM SbSLbgbSvsbjKRM7PjVwxMBKvkzilfv3kyiJDK4ZR5eA+Y2E+1CMW/RLENAassLHFZec Xkx7BkLZqm+rJHuELqEfHxyk5dDCg8uimmYWH8Ya+MJzWTNRprTvQQ86IH01kwhcrs8/ tDuN+WXzTlfzuCHEfLZ0EJTjH9botcAg+YOKZsPg0beCAT/+MuOP7QLInrmjHr8aBRzH 02C2VODjqsMqZr1MqzlgIqa93JBwdDeCnG8b5XGF/BE2yI3ev0Xr5rFQbzBCpFNPfWVD 7Ffg==
X-Gm-Message-State: AMke39kWS9PPKTRzn1kyQaLAYzqjoOeOJuZzdFsUgXjTgkK3VJFRWYox4gNPGnmp4PnTDA==
X-Received: by 10.200.47.152 with SMTP id l24mr3989131qta.212.1486660437417; Thu, 09 Feb 2017 09:13:57 -0800 (PST)
Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id k19sm9628843qtf.37.2017.02.09.09.13.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Feb 2017 09:13:56 -0800 (PST)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <9A870D5A-2447-48C8-BCE1-B40594E710FD@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CFF79974-4155-46DA-BB61-237E51123F3E"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Thu, 09 Feb 2017 12:13:54 -0500
In-Reply-To: <9142206A0C5BF24CB22755C8EC422E457AA18B5E@AZ-US1EXMB03.global.avaya.com>
To: "Mudric, Dusan (Dusan)" <dmudric@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> <0540D77C-E307-4B96-A53B-81599408C8F7@fugue.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>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/GkJPdztE0j82MP8466T9y56XPgQ>
Cc: dhcwg <dhcwg@ietf.org>, Bernie Volz <volz@cisco.com>
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: Thu, 09 Feb 2017 17:13:59 -0000

On Feb 9, 2017, at 11:47 AM, Mudric, Dusan (Dusan) <dmudric@avaya.com> wrote:
> The server can do the same validation. If the server does the validation, it will be a new feature and there will be a mix of servers that do and do-not provide this validation. The client either has to talk to the server that does provide the validation or do the validation itself.

So why is it easier to have the client do the validation than the server?   You're adding protocol to make this work, and in order for this to be useful, changes are required on the server anyway.   These changes are quite a bit more complex than the changes required to simply do whatever validation you are arguing should be done.   So why not do it the easy way instead of the hard way?
 
> This is the first problem statement. There are two more:
> -          Assignment of multiple IPV6 addresses, that the client cannot support

Then the client is broken.   Why not fix it instead of adding more protocol?

> -          A change of IPv6 address, that the client cannot handle

Again, the client is broken.   Why not fix it instead of adding more protocol?