Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis

Ted Lemon <mellon@fugue.com> Wed, 20 March 2024 00:19 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6422CC151082 for <ipv6@ietfa.amsl.com>; Tue, 19 Mar 2024 17:19:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20230601.gappssmtp.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 4POLuc_wCoZT for <ipv6@ietfa.amsl.com>; Tue, 19 Mar 2024 17:19:28 -0700 (PDT)
Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (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 37860C15154E for <ipv6@ietf.org>; Tue, 19 Mar 2024 17:19:27 -0700 (PDT)
Received: by mail-qv1-xf2c.google.com with SMTP id 6a1803df08f44-6904a5d71abso31128826d6.1 for <ipv6@ietf.org>; Tue, 19 Mar 2024 17:19:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1710893967; x=1711498767; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DHJzaRwch0xGpOwvCPM37yKsgNXdihBAQVGw2BICr6w=; b=vQ5KJjFPT9AgXDUa/hVG2oxVoEApQbGeNePaJhyITKWapoJvGvQ8iyNWAQPOv4gLG2 EhcLjAPS+PIoY0B+A1s1Kct/odCJkee65lMI07XNfVSneKX2m0KKnWqn5ETRMTMZI+ho 0JympQuA+U8ucxyqRZEasGOvkrwtAhUrWGXMMUIwlTxkxUXG138k+wSHjeGckgX13q3v gz7gzkbo8ADiOXr/AWy1EmHIak/545YF7wV2v4kP1yfhlCSU6NP5p2+V0rA//qia9756 wxiepH4AF7VmiiK2BZ0A7sE/rN7MqgUbf6C/ag62vcJsCCAxfzLNWKjvVKM/FT+wWHAT nt9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710893967; x=1711498767; 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=DHJzaRwch0xGpOwvCPM37yKsgNXdihBAQVGw2BICr6w=; b=K3EmyQfa6jwlVLQsqqVkf5XY8DPRC76R9HmuZ8xA8vPka8LrSM/YgRObIEeDyosEz2 1fOWnFEh2IoukeY8R+u14F6cES2/QKYDBgFd3Rd7ro3ImzkCZ5uLyO7eAHdXh70Vu9CC waG9rpUjgrrsEqqjU+ovcRgEvuXP/M4T3Xn+wumd7C891KARbD1meX5gWG1t7plfQwLn ViKfRv1Yk75wTuZVU5fDrDyWku4TLNRDUzPW+s60Vxfn/KbT4IHzYQQiW6bTRabWzpne lGfiGSRyEzawcK/SxwBX7ucpnUPnWMKyERJHF1k0XaIUgfWO99BE+52xvdF4RCSXhGrW /eiQ==
X-Forwarded-Encrypted: i=1; AJvYcCVkvzlyEhRVKEE9jLGEwU/aMtPiQcaXOn4j+C0DLuTLXtrxDPHW+5Lkx5oUV6T14t4IZI+eWAFVHkSeADAs
X-Gm-Message-State: AOJu0YwliLt1pvewdKZsegehLu7ZHsMuj4ZLZgLXfSt2yI1bXJkya/j2 6BPV/mry2MUj3VEFTRgorKXkNGrzxmk+T6MJXj4slIKpNq1VuA6psOq3uS46TPiZQek9sov4U3r KrgbuFxR4pqJJeGjLoMjHE2EBHA0ACFZA+Ars7A==
X-Google-Smtp-Source: AGHT+IHgbr6xvohhlH1DFgmfWIypKE760DkmpsTyTchjmWyYydZdtAGvjECz2+EYpN0pqboe2g3sf3l+OE2BI41Jb7A=
X-Received: by 2002:ad4:5f8c:0:b0:690:d26a:cde2 with SMTP id jp12-20020ad45f8c000000b00690d26acde2mr717394qvb.16.1710893966932; Tue, 19 Mar 2024 17:19:26 -0700 (PDT)
MIME-Version: 1.0
References: <df333346-f108-3782-0ff5-4bd85d7b49ac@gmail.com> <015F13BE-32F7-4C8B-8C86-C9153FE9C9E9@employees.org> <CAPt1N1mr+YLQjHf6wKK__-K1-Rywtg0K03DpwZZRz6USHOKfhA@mail.gmail.com> <39de45b5-eca1-d627-dac2-abe47f2e7bca@gmail.com> <CAPt1N1nwVSo=D9PXGAj9Hi5RUAK46aR_3P3kCLByDYXSN-UomA@mail.gmail.com> <645a37c1-6d3c-af54-e9ff-c743f07293b6@gmail.com> <CACMsEX-rXO6CWwmBy81AaAUBr7seZugVjVjUZSOxMia9VcnVpw@mail.gmail.com> <CAPt1N1nwoOa2PGMXYKh4GUxPCdonjV_5ymRdaDH3fxg34EmBww@mail.gmail.com> <CACMsEX9tfwvhKyxu52k2VYai8K3eN4wOMwetX60FW427d4s8Mg@mail.gmail.com>
In-Reply-To: <CACMsEX9tfwvhKyxu52k2VYai8K3eN4wOMwetX60FW427d4s8Mg@mail.gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Wed, 20 Mar 2024 10:18:49 +1000
Message-ID: <CAPt1N1km9BY+8LS7=9V6O1bRJHkKkHWL2EV5T0PmSkAbF-4g0A@mail.gmail.com>
To: Nick Buraglio <buraglio@forwardingplane.net>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, IPv6 List <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000025d6ce06140c8b8b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Mkxcb-Clq6XKnUCwNQdyDFer9rA>
Subject: Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2024 00:19:30 -0000

On Tue, Mar 19, 2024 at 11:32 PM Nick Buraglio <buraglio@forwardingplane.net>
wrote:

> Agreed, happiness should not determine success. From what I have seen
> (which is admittedly limited) moving from experimental to a "higher level"
> RFC is typically accompanied by something like a deployment status
> document, e.g. the SRv6 deployment status doc here
> https://datatracker.ietf.org/doc/html/draft-matsushima-spring-srv6-deployment-status
>

I think it's really important  to distinguish between "this draft solves a
problem" and "this draft solves a problem that can't be solved already" and
"this experiment has succeed and we can promote the document to
informational or standards-track."

I think we can all agree that this draft solves a problem. I think it
solves exactly one problem: allowing sites to keep stable internal
addressing in the face of renumbering by ISPs and/or changing ISPs.

However, this problem can be addressed the way 7084 currently solves it: by
numbering the internal network with a stable ULA and hosting services on
addresses within that ULA rather than on a temporary GUA provided by the
ISP.

Problems NPTV6 does not solve:

* MHMP (although it solves some aspects)
* Internal address privacy

So I don't actually think this document does anything useful for the
Internet community. I don't mind that there is a document that describes
NPTv6, but I don't think it should be standards track or informational, and
I don't think IETF documents should normatively reference it.

Regarding experiments, at least from a scientific perspective, an
experiment needs to have a control group. If we wanted to know whether
NPTv6 solved the problem in an easier way than dual ULA/GUA, we would want
to set up an experiment where some sites continued to use IPv4, some used
NPTv6, and some used ULA/GUA. As far as I know, no such experiment has been
done, and no such comparison has been documented.

I think the presentation Paulo has just done is the most interesting, but
what we are not seeing is an answer to the question "how's it going, what
problems do you have, etc."