<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 17/07/2019 16:40, Job Snijders
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACWOCC-onm5hQjoxgqoXQKGJ1o1EZH=XFrppHta9p+RbAbm3Fg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div>
<div dir="ltr">
<div>(recognising that this thread is less and less about
M&A and more and more about 2019-04. I apologize for
having contributed to a conflation of the two policy
proposals. I hope the AC will recontextualize these
comments)</div>
</div>
</div>
</blockquote>
<p>I hope this is not an attempt to take the AC to disregard the
most comments contrary to IPv6 transfers and only take into
account those manifested in favor in order to pass this proposal.
Perhaps I just misunderstood and AC will take all comments into
consideration.<br>
</p>
<p>Kind regards<br>
Fernando<br>
</p>
<blockquote type="cite"
cite="mid:CACWOCC-onm5hQjoxgqoXQKGJ1o1EZH=XFrppHta9p+RbAbm3Fg@mail.gmail.com">
<div>
<div><br>
On Tue, Jul 16, 2019 at 12:39:54PM -0400, Joe Provo wrote:<br>
> > 1/ Currently the ARIN RPKI TAL is measurably less
deployed than any of<br>
> [snip]<br>
> <br>
> I fail to understand bringing this back into it. You were
flatly asked<br>
> when the TAL issue is resolved, would this policy still
be needed and<br>
> your answer was yes, because of desire [citation<br>
> <a
href="https://lists.arin.net/pipermail/arin-ppml/2019-April/066381.html"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.arin.net/pipermail/arin-ppml/2019-April/066381.html</a>].<br>
<br>
</div>
</div>
<div>
<div>
<div dir="auto">
My intention was to bring up as a real example where a RIR's
policy leads to tangible operational issues. In the email
you reference, my observation is that that RIRs evolve over
time and may perform excellent, or perhaps regress. This is
the nature of any organization - staff, board, and zeitgeist
all change over time. Heck, even the legal environment or
risk profile can change, forcing a RIR's hand to make
certain choices; this in turn influences the choices
operators may make.</div>
<br>
Since a RIR's 'performance' (for lack of better wording) is
not fixed but rather is a variable, I think the concept of a
“lock-in” may have downsides in some scenarios.</div>
</div>
<div>
<br>
<div dir="auto">
> Registry shopping is counter to ICP-2 and I assert a Bad
Thing for the Internet as a whole.</div>
<div dir="auto"><br>
</div>
</div>
<div>
<div dir="auto">Can I ask you to explain to me in layman’s words
how or where ICP-2 suggests choice of RIR (transfers /
mobility) explicitly was not a goal? </div>
<div>
<br>
<div dir="auto">
Even if resource lock-in was an objective, isn't strange
that the implementation of that idea depends on a single
emerging technology (IPv6), where a resource transfer
blockage is used as the enforcement mechanism to prevent
"registry shopping"? Do we accept as an extreme outcome that
ARIN maybe one day mostly is an IPv6 resource registry
(meaning the other types of Number Resources are managed
elsewhere)?</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">Kind regards,</div>
<div dir="auto"><br>
</div>
<div dir="auto">Job</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
</pre>
</blockquote>
</body>
</html>