Re: [v6ops] WGLC: draft-ietf-v6ops-ipv6-deployment

Nick Buraglio <buraglio@es.net> Mon, 11 April 2022 18:14 UTC

Return-Path: <buraglio@es.net>
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 4A58B3A1852 for <v6ops@ietfa.amsl.com>; Mon, 11 Apr 2022 11:14:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=es.net
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 jRyVXzfcLV2y for <v6ops@ietfa.amsl.com>; Mon, 11 Apr 2022 11:14:19 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 EA22F3A184E for <v6ops@ietf.org>; Mon, 11 Apr 2022 11:14:18 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id h14so22982993lfl.2 for <v6ops@ietf.org>; Mon, 11 Apr 2022 11:14:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=es.net; s=esnet-google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=+W0cxcbfry60hyJhm2Vs+T1qxkuHo0F+PlH/dTEL9So=; b=TUT1zbtTXWJrPibk7Aw6H7GBX8n240l6ilS5E8yQ7OWtlgZQtUVzX1AdpTXLwvJhv3 aS9DWrelBH3ceKZWimwf1d3f2Aa/KphX7PcFdwAyUAxQIx6xpO2eQ3yKtZ5vagZARImR hiagoSBZFV1XdcCXDd3P5k00N0NFAQzm22OdbRCZBSRNI++QmZ9Rqrvby0i6taZ+Mnyr 9RdEvg3fZWhDtiqBPeMyMn7uR3UBWIDhdj3ZU8IPV0wVk5NzLY/xxWD76M2kPKoQURrN OAF19ttRXAxo6iUtBw7YXdGtdWOp/cn166rVc//Hv91cbHZgQYikxdFSWGGyIdeR91eT O56A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=+W0cxcbfry60hyJhm2Vs+T1qxkuHo0F+PlH/dTEL9So=; b=Fgqdp+6qBgArj/Q4jdve7zVLhZZuAA7JrsoB4jXYWbLneNSdgMxo0/Qb9H6+P86mNZ 1Ugv7LvC7dxmUcKTSO0/pw3dEiIsVa+6Gz8O6/ry8xwyjWxNHWZIL5V2r5Jche6woS15 DEZrLjpZyEFu/TLm/7m79WWXniBN4L9chgbJhTQUTaA3OX63YfhEhotE/t7sxNdSoPdE H47utpKuHViEFwxXKciHT7ADtPFjpPtaDPr+dCohqCjki6jhwll1JLyddFH4aCUiOmCn dkG7AZg4rJYY1rxeWsTx81mPM9gaTnTPBI5isDAP5T9UsRwOPR31Mg2uf4iZ/vIaWr6C hv6A==
X-Gm-Message-State: AOAM530K7gOYivL9g+4vCiUXf+eMFhAcUfE6tK5jjCbHHAccy08i++4l mXnnEjaRSuQSLGvqMeeyTwiBhSItb7AP13PV+//ibrrMh9ZDMPAIbo2UiYn1mWS3w4GxvWd9RRP nYSZQN3+CybgNZG0xHFfd4r7Lyd15LZX3YfNxmj7DGiq3g6A3v5Q01i0zhZicSg/3sIOJL1IEkS 1E/fbf3EM=
X-Google-Smtp-Source: ABdhPJzCY4Um8/pwru1H11B0gsZxbzMdBsu1jo6smQRZmTc+a7orDIYFPmEMsVe5xOJfOyuFEEoSP5+vl1U6dO1CuqY=
X-Received: by 2002:a05:6512:945:b0:44a:f03f:e8c9 with SMTP id u5-20020a056512094500b0044af03fe8c9mr22571066lft.163.1649700856098; Mon, 11 Apr 2022 11:14:16 -0700 (PDT)
MIME-Version: 1.0
References: <BL0PR05MB5316218855CC3A9E72035B79AEE59@BL0PR05MB5316.namprd05.prod.outlook.com> <fc22549a-22de-0895-dbbf-2691e19a150f@gmail.com> <A8A29F5D-2BA0-4368-913F-F7B0E772587E@consulintel.es> <202204102024081707127@chinatelecom.cn> <6D2586A4-E5EE-488B-91F2-470726A23DDA@employees.org> <173b0559-6399-bbb3-cec2-1b46d7e41605@gmail.com> <EC0662E5-2633-47C8-A704-6DEAE13F3A5B@employees.org> <674A0D42-817E-4A7A-90DA-F589E2615A19@gmail.com>
In-Reply-To: <674A0D42-817E-4A7A-90DA-F589E2615A19@gmail.com>
Reply-To: buraglio@es.net
From: Nick Buraglio <buraglio@es.net>
Date: Mon, 11 Apr 2022 13:14:04 -0500
Message-ID: <CAM5+tA9LtqpgMHpnjfeQ9v8w5bEO8P=7T_BG9Vkc7mP4NoThig@mail.gmail.com>
To: Fred Baker <fredbaker.ietf@gmail.com>
Cc: otroan@employees.org, v6ops@ietf.org
Content-Type: multipart/alternative; boundary="00000000000083eed905dc64e92f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/AlkuPnUY3ApKLBL5PHprUOyPliA>
Subject: Re: [v6ops] WGLC: draft-ietf-v6ops-ipv6-deployment
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 11 Apr 2022 18:14:25 -0000

On Mon, Apr 11, 2022 at 11:09 AM Fred Baker <fredbaker.ietf@gmail.com>
wrote:

>
>
> > On Apr 10, 2022, at 2:43 PM, otroan@employees.org wrote:
> >
> > There seems to be little agreement on what "IPv6 only" means (it's all
> about perspective) and there is even less for how to get there.
>
> I dunno. I would follow the dictionary on what the word "only" means.
> "IPv6-only", in my mind, means that IPv4 is turned off, at least in any
> equipment that natively switches IPv6. When folks talk about IPv4 as a
> service ("IPv4AAS"), in my mind that means that if IPv4 is switched at all,
> it is handled in a different way than IPv6.
>

> I get a little lost when people argue about what "IPv6-only" means. There
> aren't many choices.
>

I agree that "IPv6-only" should be defined in detail toward the beginning
of the document. My experience with migration to IPv6-only is exactly as
described in your prior email: It is interpreted as something being "taken
away" (IPv4), even though that is not the case, per se, and evokes an
emotional fight or flight response.  I don't know if it's useful or not,
but in much of the work I have been involved in we defined "IPv6-only" as
(paraphrasing): the disabling, lack of availability, or other absence of
IPv4 on a system, with access to IPv4 resources provided by an alternative,
intermediate mechanism.

>What I am saying is that the phrase "IPv6-only" has an immediate
*emotional* impact on the reader, and every time you use it, you repel
exactly the people we are trying to reach: enterprise and ISP operators >
whose entire job today depends on IPv4.

Agreed. Regardless of the definition, I have found that there is very much
ambiguity in what "IPv6-only" means in the context of operational network
functionality. The most common implication is that there will be no access
to IPv4, and that's not generally the case, which feels like it's addressed
in section 4.1, and specifically in section 5.

One other suggestion:

 > "As noted, the pandemic may have influenced the ICT industry including the
dynamic of the address allocations."

Not that we want another, different pandemic, it would probably be a good
idea to clarify that this was driven by the COVID-19 pandemic since this
document will be long-lived.



>
> https://www.google.com/search?q=definition+only
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
ᐧ