Re: [v6ops] Fwd: New Version Notification for draft-linkova-v6ops-ipmaclimi-00.txt

Joel Halpern <jmh@joelhalpern.com> Wed, 09 November 2022 22:31 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C258C14CE24 for <v6ops@ietfa.amsl.com>; Wed, 9 Nov 2022 14:31:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.808
X-Spam-Level:
X-Spam-Status: No, score=-2.808 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 BrTvZ-kJhLF1 for <v6ops@ietfa.amsl.com>; Wed, 9 Nov 2022 14:31:19 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB2EC14F730 for <v6ops@ietf.org>; Wed, 9 Nov 2022 14:31:19 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4N707C4N2nz6GZ4Z; Wed, 9 Nov 2022 14:31:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1668033079; bh=0kg7kXHqLNM5RBYcgwXt5YtXO99R25VE4v8/1ISMkKM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=NU/33SVkkrgGpk4gKEDLSPM5OBA9vzpig1a1jgeTB4iQ3nqHsm2TQVdJuIXIa8i8Q TbJwREkTe/HVL+ufHf0UCUxub7A38fyOazZcwX0SXW+BIqAGVk6VmaG5/E3I66PYzS KN34huJWGEcvF2IuOauwPyjGwveIbn34iJ20LMtI=
X-Quarantine-ID: <P2-3JHxAi6o8>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [31.133.149.170] (dhcp-95aa.meeting.ietf.org [31.133.149.170]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4N707B5wbGz6G9sB; Wed, 9 Nov 2022 14:31:18 -0800 (PST)
Content-Type: multipart/alternative; boundary="------------i7o5zwT0zpxOxSnpzxp9zze8"
Message-ID: <7d34a4ff-b0b5-7ca8-5eb8-075dce586084@joelhalpern.com>
Date: Wed, 09 Nov 2022 17:31:17 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2
Content-Language: en-US
To: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
Cc: V6 Ops List <v6ops@ietf.org>
References: <CAFU7BAQmSqaZhrQ0YH-1ryp2DfZH6z5B1icR=Wc_W=sdBExuEA@mail.gmail.com> <EE3F6D3C-EC05-4B23-917D-46BA7E49BC61@employees.org> <CAKD1Yr2ZonxFr2jX5bc6eNdPfixsjSheSRDTesaPxE_3WWPF0Q@mail.gmail.com>
From: Joel Halpern <jmh@joelhalpern.com>
In-Reply-To: <CAKD1Yr2ZonxFr2jX5bc6eNdPfixsjSheSRDTesaPxE_3WWPF0Q@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/TdDmEjB0Wdbu37DUT2OTxuY_c-g>
Subject: Re: [v6ops] Fwd: New Version Notification for draft-linkova-v6ops-ipmaclimi-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Nov 2022 22:31:24 -0000

Well-said.  Thank you Lorenzo and Jen.

Yours,

Joel

On 11/9/2022 10:15 AM, Lorenzo Colitti wrote:
> On Tue, Nov 8, 2022 at 2:13 PM Ole Troan 
> <otroan=40employees.org@dmarc.ietf.org> wrote:
>
>     A requirement like that would be perfectly fine in an RFQ. Less so
>     in an RFC.
>
>
> Ok, so then let's see *what* would be acceptable to put into an RFC.
>
> The draft says that the hardware must allow the operator to configure 
> the limits that the network places on the hosts, and should do 
> something reasonable when the limit is hit, such as drop the address 
> that was used least recently. I don't see how any of these statements 
> can be controversial and it makes sense for them to be in an RFC. 
> These hosts do exist (example: ChromeOS), and if a network operator 
> (example: Jen) wants to support them, then it should be possible to do so.
>
> The draft also says that if the network does not allow enough 
> addresses per client for current implementations, those 
> implementations will experience user-visible outages. As I see it, 
> that's simply a fact (those implementations do exist, and they do 
> fail), so I don't see how it could be controversial.
>
> The thing that there doesn't seem to be consensus on is whether the 
> IETF can/should place a minimum requirement on the number of addresses.
>
> Did I miss something?
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops