Re: [v6ops] Roman Danyliw's No Objection on draft-ietf-v6ops-ipv6-deployment-08: (with COMMENT)

Paolo Volpato <paolo.volpato@huawei.com> Wed, 26 October 2022 15:10 UTC

Return-Path: <paolo.volpato@huawei.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 A8742C1522B9; Wed, 26 Oct 2022 08:10:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.634
X-Spam-Level:
X-Spam-Status: No, score=-3.634 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URG_BIZ=0.573, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 0P7KUUKFWgy1; Wed, 26 Oct 2022 08:10:39 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAB80C1522B7; Wed, 26 Oct 2022 08:10:38 -0700 (PDT)
Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4MyBx13tvJz67xJM; Wed, 26 Oct 2022 23:07:01 +0800 (CST)
Received: from fraeml740-chm.china.huawei.com (10.206.15.221) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Wed, 26 Oct 2022 17:10:35 +0200
Received: from fraeml740-chm.china.huawei.com ([10.206.15.221]) by fraeml740-chm.china.huawei.com ([10.206.15.221]) with mapi id 15.01.2375.031; Wed, 26 Oct 2022 17:10:35 +0200
From: Paolo Volpato <paolo.volpato@huawei.com>
To: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>
CC: "draft-ietf-v6ops-ipv6-deployment@ietf.org" <draft-ietf-v6ops-ipv6-deployment@ietf.org>, "v6ops-chairs@ietf.org" <v6ops-chairs@ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>, "fredbaker.ietf@gmail.com" <fredbaker.ietf@gmail.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Thread-Topic: Roman Danyliw's No Objection on draft-ietf-v6ops-ipv6-deployment-08: (with COMMENT)
Thread-Index: AQHY6Ax9aNfhpdjT+0GQzfqlDfeXhK4fPO3Q
Date: Wed, 26 Oct 2022 15:10:35 +0000
Message-ID: <100ca5306cb04e42896aac6817a6a385@huawei.com>
References: <166665932268.5786.15440895026242205786@ietfa.amsl.com>
In-Reply-To: <166665932268.5786.15440895026242205786@ietfa.amsl.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.202.20.68]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/9IJOfbPZRR4IJnX9ZWqBtNEfGg4>
Subject: Re: [v6ops] Roman Danyliw's No Objection on draft-ietf-v6ops-ipv6-deployment-08: (with COMMENT)
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, 26 Oct 2022 15:10:42 -0000

Hi Roman,

Thank you for your thoughtful review.
Please find our replies inline, marked as [PV].
We will apply these changes in the next revision.

Best regards
Giuseppe & Paolo

-----Original Message-----
From: Roman Danyliw via Datatracker <noreply@ietf.org> 
Sent: Tuesday, October 25, 2022 2:55 AM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-v6ops-ipv6-deployment@ietf.org; v6ops-chairs@ietf.org; v6ops@ietf.org; v6ops-chairs@ietf.org; draft-ietf-v6ops-ipv6-deployment@ietf.org; fredbaker.ietf@gmail.com; fredbaker.ietf@gmail.com
Subject: Roman Danyliw's No Objection on draft-ietf-v6ops-ipv6-deployment-08: (with COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-v6ops-ipv6-deployment-08: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-deployment/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Section 2.1.1.
   It clearly derives
   from the allocation of addresses made in the early days of the
   Internet by the most advanced countries.

“Most advanced” in what sense.  Recommend alternative language.

[PV] Ok. For example, we may omit the words "by the most advanced countries".

** Section 2.1.1.
   The next table compares the IPv4 addresses per capita ratio of a
   certain country with relative adoption of IPv6, expressed as the
   number of IPv6 capable users in the considered country.

I don’t understand how the second column of Figure 1 is calculated.  For the
USA, “IPv6 deployments” = 47.1%

Turning to the raw data in [POTAROO2], for the USA:
-- Internet Users = 256169053
-- v6 users = 135675677
-- population = 338635004

Calculating the ratios in different ways doesn’t produce a 47% figure:
V6 users / Internet Users = ~53%
V6 users / population = ~40%

[PV] The data we have taken from the distribution files of [POTAROO2] refer to January 1, 2022. 
If you take a different distribution file it is likely that the measurement is slightly different.
We will put the exact date in the table.
We are also thinking to update all the statistics before the final publication as a RFC. In this way we will include the latest information available.

** Section 2.3.  Figure 3.  Are these values the percentages of all website
which are accessible over v6 or the total volume of web traffic which is v6?

[PV] It is the former (v6 accessible websites). We will specify it in the next version of the draft.

** Section 2.3..
   If we consider that the big content providers (such as
   Google, Facebook, Netflix) generate more than 50% of the total mobile
   traffic [SNDVN], and in some cases even more up to 65% ([ISOC1]
   [HxBld]), the percentage of content accessible over IPv6 is clearly
   more relevant than the number of enabled IPv6 websites.

What percentage of that 50% of all mobile traffic is v6?  It would be ideal to
connect that 50% metric to Figure 3 (i.e., the text currently cautions that the
Figure 3 numbers don’t look so big, because it consists of all website; next it
argues that the top sites generate most of the content; the ideal closing
narrative would then to show how much of that 50% that relates to v6 usage).

[PV] We fully agree on your point. It would be interesting to have these data but we did not find any more detailed statistics.
We may consider to highlight this point in the draft.

** Section 2.4.  I appreciate these country-specific narratives linking
government policy decisions to adoption.  However, these seem a bit anecdotal. 
 I’m only vaguely familiar with what’s happening in the US.  Linking the US
adoption of IPv6 to US OMB’s mandate for federal systems would benefit from
more text.  What’s the link to carriers, enterprises and non-profit behavior? 
In 2010, OMB directed all external .gov services to be IPv6 native
(https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/assets/egov_docs/transition-to-ipv6.pdf).
 A decade later in 2020, OMB is still trying with a mandate for 20% of
IPv6-only by FY23 for all assets
(https://www.whitehouse.gov/wp-content/uploads/2020/11/M-21-07.pdf)

[PV] We believe that it is worth mentioning the government IPv6 policies for the different countries.
We are aware that their application may also be affected by other factors but, despite that, it can be an incentive to IPv6 progression.
We will double-check the text to avoid misunderstandings.


** Section 3.2.  Kuddos on doing an updated survey.  Given that global trends
have largely been discussed up to this section, it would be value to convey the
regional nature of this survey.  If I understand Appendix A correctly, these
are results are from a population of “service providers in the European region.”

[PV] This is indicated in the first paragraph of section 3.2. 
We may evaluate to highlight it also in the section title.

** Section 3.4.  Thanks for explicitly mentioning the “Industrial Internet.”   
The current text doesn’t provide any measurements, survey data or citations,
but it is under the “survey” section (Section 3.*).  What is the basis of the
analysis?

[PV] We can change the title of section 3, to include both surveys and other observations on IPv6 deployment, otherwise we can move section 3.4 into a new section, independent of the surveys.

** Section 3.6.  Same comment as above.  No disagree with what’s said here. 
However, this section is nested under “IPv6 survey” (Section 3).  Is there
measurement or survey data that can be added to bolster this text?

[PV] Same as above.

** Section 4.  Is there any way to connect these deployment scenarios to the
deployment assessments done by sector in Section 3?

[PV] We already mentioned that Dual-Stack, for example, is the most deployed IPv6 solution according to the survey in section 3, in particular in carriers' networks.
We will revise this section to highlight further cross-references between sections 3 and 4.

** Section 5.  What is the basis of this sections of challenges?  How was this
list of challenges validated with the specific verticals/sectors outlined in
the subsequent sections?

[PV] This section on challenges was validated during the discussions among the co-authors, on the v6ops mailing list and during some presentations at public events (e.g. RIPE meetings). In addition, some inputs were taken from the replies to the surveys listed in the two Appendixes. We also received some suggestions during the IETF meetings.

** Section 5.1.1.  This section could be clearer on identifying the specific
challenges given that this is in the “Common IPv6 Challenges” section (Section
5.*)

[PV] We'll revise to better highlight the specific challenges.

** Section 5.1.1.
   On
   average, looking at the global statistics, the IPv6 traffic
   percentage is currently around 40%.

Please cite this figure.

[PV] Ok, we'll add a reference to the previous section.

** Section 5.1.1.
   As highlighted earlier, all
   major content providers have already implemented Dual-Stack access to
   their services and most of them have implemented IPv6-only in their
   Data Centers.

I’m not following which citation that might be.  Could it be repeated here.

[PV] Ok, we'll add a reference to the previous section.

** Section 5.1.2.  This section would benefit from being more concise on the
challenge.  My reading of the text is that it is (1) no business case; and (2)
limited training.

[PV] Ok, we will review it.

** Section 5.1.2.
   As pointed out in
   Section 3, enterprises may benefit deploying IPv6 in their public-
   facing services.

-- I didn’t see these advantages outlined in Section 3.0 or 3.3 (the section
specific to enterprises). -- Doesn’t the subsequent text of “ Enterprises ...
do not have the business requirement or technical justification to transit to
IPv6.”  This seems to conflict.

[PV] Ok, we will review and eventually omit this reference.

** Section 5.1.2.
   In most
   cases, the enterprise engineers and technicians do not know well how
   IPv6 works and the problem of application porting to IPv6 looks quite
   difficult, even if technically the issue is not overly complicated.

I would be careful making a value judgement (“not overly complicated”).

[PV] We'll reword accordingly.

** Section 5.1.2.
  This creates an unfortunate cycle where misinformation about the
   complexity of the IPv6 protocol and unreasonable fears about security
   and manageability combine with the perceived lack of urgent business
   needs to prevent adoption of IPv6.

More value judgement language (“unreasonable fears”).  Strongly recommend
rewording this text.

[PV] We'll reword accordingly.

** Section 5.1.2
As the most promising protocol for network evolution, IPv6 ...

Is that too strong of a statement?

[PV] We'll reword accordingly.

** Section 5.1.2.  The last two paragraphs discuss cloud, AI, OT, and IIoT. 
None of this text appears related to IPv6 challenges.  It reads more like
opportunities with IPv6.

[PV] Same as above.

** Section 5.1.4.

   It can be noted that most of the user devices (e.g. smartphones) are
   already IPv6-enabled since so many years.

Please state this less colloquially.

[PV] Ok.

** Section 5.2.  Editorial.

   There are important IPv6 complementary solutions related to
   Operations, Administration and Maintenance (OAM) that look not so
   complete compared to IPv4

Is there a way to say “not so complete” less colloquially?

[PV] Ok, we'll provide different wording.

** Section 5.2.  Editorial.
OLD
   This is
   because some IPv6 products are not field-proven as for IPv4

NEW
This is because some IPv6 products are not as field-proven as for IPv4

[PV] Sure, thanks.

** Section 5.2.

   For example, YANG is the configuration language for networking but in
   the real world the data modeling may be still vendor dependent.

I’m not able to comment on real-world deployment and use of YANG.  What isn’t
clear to me how YANG penetration and implementation is a proxy for IPv6 support.

[PV] That was a general consideration, but not being bound to IPv6 we can omit it.

** Section 5.2.
   Deploying IPv6 requires it as policies
   and procedures have to be adjusted in order to successfully plan and
   complete an IPv6 transition.

This sentence doesn’t parse.

[PV] We'll reword it.

** Section 5.2. Typo.  s/few extensive researches and measurement campaigns/few
comprehensive measurement campaigns/

[PV] Ok, thanks.