IETF Logo Mail Archive

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

Lorenzo Colitti <lorenzo@google.com> Wed, 09 November 2022 15:16 UTC

Return-Path: <lorenzo@google.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 2BB27C1524A1 for <v6ops@ietfa.amsl.com>; Wed, 9 Nov 2022 07:16:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -22.609
X-Spam-Level:
X-Spam-Status: No, score=-22.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 A5HN3liPSWEc for <v6ops@ietfa.amsl.com>; Wed, 9 Nov 2022 07:16:00 -0800 (PST)
Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 83A81C1524D2 for <v6ops@ietf.org>; Wed, 9 Nov 2022 07:15:57 -0800 (PST)
Received: by mail-vs1-xe35.google.com with SMTP id l190so16848473vsc.10 for <v6ops@ietf.org>; Wed, 09 Nov 2022 07:15:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=nGEPMh3Yr+Bw2HXBF01x1gVDknWnrPcm/y6UJp+6JUE=; b=qV4z0W5/2UblFxyu6vt2LSOO1ry5rY3g4yxjEgZE5nwYdoLxMzasa3ugpXLzGhsbOa sFIet+HM8KgQvwyCGz+JdeBn543lNX+vZ16P4IM5JLwo1HS6W5b81N9qSCFs8rWFaC8V Xa4wdvIB963oG+4+AjGRVyoftfAm0+v2ntqJSA/GXQu9/NVMmAdUktxa1e0OzuvTWy5a bL/k71PijCNzvwNf3pdjg0jgTD3XOkpBBlk8EHDSU+Sftp8RxKqeUy5sb2prmqfMTujo HWBCiUVdTbqQMGfJIdFT0uyvs/taD3l1bcTs2efoYA9yPiWABMWcybz3hT3n0SP53gtV a8jw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nGEPMh3Yr+Bw2HXBF01x1gVDknWnrPcm/y6UJp+6JUE=; b=XD4EiaX8sj/sQ68lk9jEMYujgrY99bS2jhMn7EdjcYMrqCYt/J9Tq5k6yMoNlWXfzD MsTmg41wM0Uavaih8h50dNmSpJLg0t9iOS2u4Boaiuovo6iOySS5TGMfhToJIUiV/osM pOX0JXVkZwV6EGAhaqiyI+xHgfLucMZAm1GlONv/nutv0JG0M5fuUJkEuO7as/+9wb5M goJTKo+g4LbCey+68Y+70yXq8aVSXRIJe1PjCtUTiBgWnL4qr42DUdshV7NL/wfiKHLM rCIBYQCUlIPKLnxvY9TTBQCOTX9FUcSLr3dNZK/bNfgHNtuoNU2/hn8Fmur7+ayC8VFX JotQ==
X-Gm-Message-State: ACrzQf3Z5pqlgxYCO0FuvFSgZLyV/7gdl7MySaw5RtPtkSzg94WLy5ci cUfq89WbAIi1QuUgK3ToAW81IF4XBIGph9BMZyOwdQ==
X-Google-Smtp-Source: AMsMyM6bFlf60wrdjRiLIFiMzViyqWEbxz1L3b1ofi33xh5rwbg9Q/p3C6zkbqJ+5H+BgPD2ty4aTr4nho2Y+8JCXzo=
X-Received: by 2002:a05:6102:55a0:b0:3aa:3ea8:4907 with SMTP id dc32-20020a05610255a000b003aa3ea84907mr1000685vsb.79.1668006955978; Wed, 09 Nov 2022 07:15:55 -0800 (PST)
MIME-Version: 1.0
References: <CAFU7BAQmSqaZhrQ0YH-1ryp2DfZH6z5B1icR=Wc_W=sdBExuEA@mail.gmail.com> <EE3F6D3C-EC05-4B23-917D-46BA7E49BC61@employees.org>
In-Reply-To: <EE3F6D3C-EC05-4B23-917D-46BA7E49BC61@employees.org>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Wed, 09 Nov 2022 15:15:43 +0000
Message-ID: <CAKD1Yr2ZonxFr2jX5bc6eNdPfixsjSheSRDTesaPxE_3WWPF0Q@mail.gmail.com>
To: Ole Troan <otroan=40employees.org@dmarc.ietf.org>
Cc: Jen Linkova <furry13@gmail.com>, V6 Ops List <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000018e87705ed0b22bc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/O3rxv0rsAKz5UlWBlL6B_s3EiKQ>
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 15:16:01 -0000

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?

v2.23.0 | Report a Bug | By Email