<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">I will add the observation that while we have a good rapport with larger RSPs, which tend to be the driver of most peaks in requests, under the current relationship there is a direct incentive to do so. As we do not have the concept of
bulk operations in our current system, an RSP submitting a change impacting a few hundred TLDs will need to submit several hundred change requests to effect the change. We make the offer to TLD operators that we will manage bulk operations on their behalf
by performing the repetitive submission process for them, as well as bulk-processing authorizations out-of-band when they are all by the same party.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This dynamic could change as our next generation root zone management platform will offer API access which should make the submission and approval process largely automatable by RSPs with large portfolios.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’ll also add another driver of bulk operations is policy changes so we work closely with our colleagues in the broader ICANN Org to mitigate any potential peaks when new policies are being implemented.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">As to how we implement these, we certainly do plan ahead to make sure our staffing can cope with the anticipating load by these activities. We have a small team, and just one person being on vacation in a given week could be problematic.
With usually at least a few weeks notice before these kinds of bulk operations are anticipated it allows is to confirm staffing, defer non-essential project work, bring in extra resources and so forth to manage the surge.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">kim<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">IFRT <ifrt-bounces@icann.org> on behalf of James Gannon <james@cyberinvasion.net><br>
<b>Date: </b>Wednesday, June 3, 2020 at 6:45 AM<br>
<b>To: </b>Peter Koch <pk@DENIC.DE>, "Wilhelm, Richard via IFRT" <IFRT@icann.org><br>
<b>Subject: </b>Re: [IFRT] peak loads by large 'routine' operations<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div id="__MailbirdStyleContent">
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">I know this has been discussed between the CSC and PTI, and the feedback we have gotten is that the relationship between PTI and the larger RSPs allow them to plan
for bulk changes and updates in advance so that the teams are able to align on workloads for such events etc.<o:p></o:p></span></p>
<blockquote style="border:none;border-left:solid windowtext 1.0pt;padding:0in 0in 0in 8.0pt;margin-left:0in;margin-top:15.0pt;margin-bottom:5.0pt">
<p style="margin-top:7.5pt"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:#AAAAAA">On 6/3/2020 2:32:56 PM, Peter Koch <pk@denic.de> wrote:<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;color:black">Dear fellow IFRT members,
<br>
<br>
I'd like to share an observation that is rather operational and may or <br>
may not be within the IFR scope (and might also not be new). It shouldn't <br>
fall into a void, so here it is: <br>
<br>
With approx. 1500 TLDs the net has seen some concentration, so that <br>
a single entity is responsible for or providing technical services <br>
to multiple TLDs, be that 100, 200 or more. Sometimes, contact <br>
details change, sometimes technical parameters change (like <br>
nameserver names or addresses) and in some cases parameters <br>
are changed regularly (DNSSEC key rollover). I've seen this happen <br>
in larger bundles and am wondering whether there is any noticable <br>
effect on workloads or infrastructure and how that might change <br>
if the bundles grow larger. I'm pretty confident everybody <br>
involved is aware of scaling effects and given that it's routine <br>
operation, no immediate risk should exist. <br>
<br>
Best regards, <br>
Peter <br>
_______________________________________________ <br>
IFRT mailing list <br>
IFRT@icann.org <br>
https://mm.icann.org/mailman/listinfo/ifrt <br>
<br>
_______________________________________________ <br>
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos).
You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
<o:p></o:p></span></p>
</div>
</blockquote>
</div>
</div>
</body>
</html>