Re: [dhcwg] dhc-addr-notification: input required on the client behaviour

Sheng JIANG <shengjiang@bupt.edu.cn> Wed, 10 January 2024 01:50 UTC

Return-Path: <shengjiang@bupt.edu.cn>
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 863E5C169506; Tue, 9 Jan 2024 17:50:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pn4hDxMuXWlU; Tue, 9 Jan 2024 17:50:30 -0800 (PST)
Received: from smtpbg153.qq.com (smtpbg153.qq.com [13.245.218.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 280A1C151092; Tue, 9 Jan 2024 17:50:26 -0800 (PST)
X-QQ-mid: bizesmtp62t1704851415teremyz3
Received: from SJ-Uni ( [221.223.103.235]) by bizesmtp.qq.com (ESMTP) with id ; Wed, 10 Jan 2024 09:50:13 +0800 (CST)
X-QQ-SSF: 01400000000000J0Z000000A0000000
X-QQ-FEAT: znfcQSa1hKaRZxJ/y7rSMmmhhaZQiKvTkNrIsJ+OcwzfgzlWvW23MBJ8ev+TA HGmcqRVsSdzgbCeY46Iq5NBvFn2OLOmRmBiStRGdlHOl/UyVt5cmDbqFLYYVM5DFOqXJs0Y xs+mWQQzzZ0icvh69b98XOxgHmyV9zJ9/ca7LbQnENhRT2dbzRNcJiuXAaSfxRkht7Qn5RJ QMQmMh51qpGpT1RqITxlOkGJbJTxoRfUFeY/hrsnKY8YeDJkmcUX8eayhMKNWyfQqPkOE0m 1JmN1na33xSXtYwvwqLSI9BTfA6LFmKQa4r/WatJ6ZboN9KIhVJnK9ouydEnDELtiwdXUwL x1Ld631JeNvRL+5dZVmIBKAVD68SYkmkSMGMFDVKPGQdTR4xS/liz33i26Z/H9OzYniBcrW
X-QQ-GoodBg: 2
X-BIZMAIL-ID: 7096292759715146340
Date: Wed, 10 Jan 2024 09:50:14 +0800
From: Sheng JIANG <shengjiang@bupt.edu.cn>
To: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>, warren <warren@kumari.net>
Cc: dhcwg <dhcwg@ietf.org>, draft-ietf-dhc-addr-notification <draft-ietf-dhc-addr-notification@ietf.org>, Ted Lemon <mellon@fugue.com>
References: <CAFU7BASCOHV_HQriarduvEjs5hUMwt3Qad+31AVwTjb=GQdmmQ@mail.gmail.com>, <CAPt1N1=mhYdCNg3r9qU+7oStpD34bHWqFMo0AzVA5BJo5v=iVw@mail.gmail.com>, <CAHw9_iJErpjX3BizFRjCKLJOsTXVCHBcQdzZQeTGgEKTYAEd4w@mail.gmail.com>, <CAKD1Yr2O5nPRxSDK58Vg7GVKVOf9P+RisYcH2A-d_sf_Ob9M7g@mail.gmail.com>
X-Priority: 3
X-GUID: 9A6EA2BD-D2A2-4B8D-9ABD-78DE3CBBDA6A
X-Has-Attach: no
X-Mailer: Foxmail 7.2.25.228[cn]
Mime-Version: 1.0
Message-ID: <8C9C4594DE358545+202401100950132921106@bupt.edu.cn>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
X-QQ-SENDSIZE: 520
Feedback-ID: bizesmtp:bupt.edu.cn:qybglogicsvrsz:qybglogicsvrsz4a-1
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/_kZPp8Ywa4b7_MnQxdCkPmepRkA>
Subject: Re: [dhcwg] dhc-addr-notification: input required on the client behaviour
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Dynamic Host Configuration <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: Wed, 10 Jan 2024 01:50:34 -0000

+1. It is the right choice. It has to stop somewhere. We cannot give infinitely consideration to the corner cases with little possibilities. I should make the major cases covered well and avoid too much complexities. 


Cheers,



Sheng JIANG



>+1. Avoiding a small amount of extra multicast traffic in these unusual



>situations (misconfiguration, rollback) doesn't seem worth complicating the



>implementation and increasing the risk of implementation bugs.



>



>If the network has really serious problems with these packets (e.g., DHCPv6



>server catches fire when it receives them) then relying on implementations



>not to send them doesn't seem like a good strategy anyway.



>



>On Wed, Jan 10, 2024 at 1:42 AM Warren Kumari <warren@kumari.net> wrote:



>



>>



>>



>>



>>



>> On Tue, Jan 09, 2024 at 10:07 AM, Ted Lemon <mellon@fugue.com> wrote:



>>



>>> On Tue, Jan 9, 2024 at 4:15 AM Jen Linkova <furry13@gmail.com> wrote:



>>>



>>>> Would the group be OK if -08 contains Bernie's proposal?



>>>>



>>>> Not speaking for the group, obviously, but I think this is the right



>>> choice. Anything else is an unnecessarily complicated protocol fix to a



>>> configuration mistake.



>>>



>>



>>



>> Yup / +1.



>> If the "failure mode" was more harmful then I'd have a different view, but



>> seeing as it is a trivial amount of traffic (and in a weird corner case), I



>> think that it's the right solution….



>>



>> W



>>



>>