Re: [v6ops] Fw: New Version Notification for draft-xie-v6ops-framework-multi-domain-ipv6only-00.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 23 June 2022 01:47 UTC

Return-Path: <brian.e.carpenter@gmail.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 6D60DC14CF15 for <v6ops@ietfa.amsl.com>; Wed, 22 Jun 2022 18:47:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.985
X-Spam-Level:
X-Spam-Status: No, score=-8.985 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.876, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 bS9yQsJpCpqv for <v6ops@ietfa.amsl.com>; Wed, 22 Jun 2022 18:47:07 -0700 (PDT)
Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (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 2C4ACC14F73F for <v6ops@ietf.org>; Wed, 22 Jun 2022 18:47:07 -0700 (PDT)
Received: by mail-pl1-x62f.google.com with SMTP id m14so16883596plg.5 for <v6ops@ietf.org>; Wed, 22 Jun 2022 18:47:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=Fnh5/cLOalobsAQngVCV47mkDq35zPLPl98Cabqx1Q8=; b=XU8QgGBcwv5/noKh1Nt/JPbRcB3NUZBY+yhrmerWfAZ1NoveKwxBKMGxJYYIXvAvw/ w/UXD2M107SaKUESv9bEDXI9aYnusMkx2rNoYOKt+/0WO/23fUVAf5ZfB916VwkUMIuv r/Bl96U+YrS217IJzwLtXcgT6ytvQrJESugYNHBZqWpSCxEOiyTJn+cxjMC+dDKfa8G/ V3uA5nDsztt6H0yKfkRz6Hdw2znTJ1dzoQQnAsO7HBprndMz+6wRrI3LJzLZJGv8jbfo X2hqmQNWntAwDn9zWcMD5XtCdteWMbMYgCZMNdnpq956zuxms3g2A7tShTboQRDaEXZx Q5SA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=Fnh5/cLOalobsAQngVCV47mkDq35zPLPl98Cabqx1Q8=; b=CUpvDXbwbgguW8FpPRIMMpskaoPfHNnhHa2tZEBUu2UVEV0dDhe+1IRHpwQrbi3Vlo bz2Fu7VK0Tb2klT/3ntfRR9Af94pjCy45Yc6xEfNFspdGJ83XGM+zun8ANa22M4NsYLV hLe+ei5pBRtEQ05Qm7XeDf5iTubDuDZ3poJUzvrrqXLHCL3+6Zlv7ZLejt1wMP3SpfC0 Cj7nopgsSUNnKgt4Um45qQifWQ8k3PhU82QDfW8SNPHWuXc0fJFjA4CEP2B7qJ39bapT EvPwKm/tr3XkVu75/CxLa2e7IwNboqPAKYRxUJYyXjsQFBKDtZRF7B3kE+zSEw0otP8R zY5A==
X-Gm-Message-State: AJIora/yGRMW2xibeFDm6ZXSbzntW1QOtHBvwR6+Vt/y2Eb/UX5ZjuI9 GHka1jX9Km/dh2SSr9osEdE=
X-Google-Smtp-Source: AGRyM1s71A5xFl9lsadmr3kqOhmMTfML0N4Azqf06a+HclrAySlvSlYui8vMRkJnMKZ/Grq0U3lvuQ==
X-Received: by 2002:a17:902:ecc9:b0:163:f779:f97a with SMTP id a9-20020a170902ecc900b00163f779f97amr36173304plh.167.1655948826521; Wed, 22 Jun 2022 18:47:06 -0700 (PDT)
Received: from ?IPV6:2406:e003:1124:9301:80b2:5c79:2266:e431? ([2406:e003:1124:9301:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id e15-20020aa798cf000000b00525119428f8sm9888391pfm.209.2022.06.22.18.47.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Jun 2022 18:47:05 -0700 (PDT)
Message-ID: <fcefc629-849b-2d48-52b0-49c647fa3ccd@gmail.com>
Date: Thu, 23 Jun 2022 13:47:02 +1200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: Chongfeng XIE <xiechf@chinatelecom.cn>
Cc: list <v6ops@ietf.org>
References: <202206211427054870437@chinatelecom.cn> <CA+nkc8C89AmmrNS3ZkP=VVFt1fQ_8mHcz1YOMZi090V5Ofnbmg@mail.gmail.com> <2a300ad3-2da3-a911-4035-92f9e2481b80@gmail.com> <2022062309051226771415@chinatelecom.cn>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <2022062309051226771415@chinatelecom.cn>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/WlNIy_H_EidjvY9fYoOhdfWY1NE>
Subject: Re: [v6ops] Fw: New Version Notification for draft-xie-v6ops-framework-multi-domain-ipv6only-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: Thu, 23 Jun 2022 01:47:11 -0000

On 23-Jun-22 13:05, Chongfeng XIE wrote:
> Hi,Brian,
> Thank you for your comments and suggestion. I agree with you, this draft is mainly about underlay with IPv6 instead of dual-stack, meanwhile, the service can be dual-stack.  Based on your judicious suggestion, we  plan to limit the scope and change the name to,
> 
>             "Framework of Multi-domain IPv6-only Underlay Network and IPv4aaS"
> Do you think this is ok?

Yes, I think it makes the scope clear. However, I wonder whether the RFC Editor will like the complex acronym "IPv4aaS" in the title. Maybe it is even clearer as
             "Framework for Multi-domain IPv6-only Underlay Network and IPv4 as a Service"

Regards,

      Brian

> 
> Best regards
> Chongfeng
> 
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> xiechf@chinatelecom.cn
> 
>     *From:* Brian E Carpenter <mailto:brian.e.carpenter@gmail.com>
>     *Date:* 2022-06-22 06:14
>     *To:* Chongfeng XIE <mailto:xiechf@chinatelecom.cn>
>     *CC:* IPv6 Operations <mailto:v6ops@ietf.org>
>     *Subject:* Re: [v6ops] Fw: New Version Notification for draft-xie-v6ops-framework-multi-domain-ipv6only-00.txt
>     Hi,
>     I'd like to repeat my plea to *not* use the phrase "IPv6-only" in this way. It is a very misleading phrase because you do not propose to provide an IPv6-only service to users, but a dual stack service.
>     What you describe is an IPv6 underlay or an IPv6 transport network. It concerns internal choices by operators, not what the user sees. The title, file name, and Abstract of the draft should, in my opinion, carefully avoid the phrase "IPv6-only" to prevent irrational reactions. The objective is to provide dual-stack *service* without needing dual-stack infrastructure.
>     Something like:
>                     Framework of Multi-domain IPv6 Underlay Network
>                  draft-xie-v6ops-framework-multi-domain-ipv6-underlay-00
>     Abstract
>          Dual-stack deployments originally required both IPv4 and IPv6
>          transfer capabilities to be deployed in parallel.  For operators,
>          supporting only IPv6 infrastructure, with global IPv4 provided
>          as a an overlay service, is a preferable ultimate stage.  This
>          document specifies requirements and proposes a general framework
>          when deploying IPv6 as the underlay in a multi-domain network.
>     Regards
>          Brian Carpenter
>