<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none"><!--P{margin-top:0;margin-bottom:0;} .ms-cui-menu {background-color:#ffffff;border:1px rgb(171, 171, 171) solid;font-family:"Segoe UI WPC","Segoe UI",Tahoma,"Microsoft Sans Serif",Verdana,sans-serif;font-size:12pt;color:rgb(51, 51, 51);} .ms-cui-menusection-title {display:none;} .ms-cui-ctl {vertical-align:text-top;text-decoration:none;color:rgb(51, 51, 51);} .ms-cui-ctl-on {background-color:rgb(230, 235, 239);opacity: 0.8;} .ms-cui-img-cont-float {display:inline-block;margin-top:2px} .ms-cui-smenu-inner {padding-top:0px;} .ms-owa-paste-option-icon {margin: 2px 4px 0px 4px;vertical-align:sub;padding-bottom: 2px;display:inline-block;} .ms-rtePasteFlyout-option:hover {background-color:rgb(230, 235, 239) !important;opacity:1 !important;} .ms-rtePasteFlyout-option {padding:8px 4px 8px 4px;outline:none;} .ms-cui-menusection {float:left; width:85px;height:24px;overflow:hidden}.wf {speak:none; font-weight:normal; font-variant:normal; text-transform:none; -webkit-font-smoothing:antialiased; vertical-align:middle; display:inline-block;}.wf-family-owa {font-family:'o365Icons'}@font-face { font-family:'o365IconsIE8'; src:url('prem/15.0.888.16/resources/styles/office365icons.ie8.eot?#iefix') format('embedded-opentype'), url('prem/15.0.888.16/resources/styles/office365icons.ie8.woff') format('woff'), url('prem/15.0.888.16/resources/styles/office365icons.ie8.ttf') format('truetype'); font-weight:normal; font-style:normal;}@font-face { font-family:'o365IconsMouse'; src:url('prem/15.0.888.16/resources/styles/office365icons.mouse.eot?#iefix') format('embedded-opentype'), url('prem/15.0.888.16/resources/styles/office365icons.mouse.woff') format('woff'), url('prem/15.0.888.16/resources/styles/office365icons.mouse.ttf') format('truetype'); font-weight:normal; font-style:normal;}.wf-family-owa {font-family:'o365IconsMouse'}.ie8 .wf-family-owa {font-family:'o365IconsIE8'}.ie8 .wf-owa-play-large:before {content:'\e254';}.notIE8 .wf-owa-play-large:before {content:'\e054';}.ie8 .wf-owa-play-large {color:#FFFFFF/*$WFWhiteColor*/;}.notIE8 .wf-owa-play-large {border-color:#FFFFFF/*$WFWhiteColor*/; width:1.4em; height:1.4em; border-width:.1em; border-style:solid; border-radius:.8em; text-align:center; box-sizing:border-box; -moz-box-sizing:border-box; padding:0.1em; color:#FFFFFF/*$WFWhiteColor*/;}.ie8 .wf-size-play-large {width:40px; height:40px; font-size:30px}.notIE8 .wf-size-play-large {width:40px; height:40px; font-size:30px}--></style>
</head>
<body>
<div style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>As the author of this proposal, and having encountered the real-world consequences of existing 8.4 anti-flip language, I support #3 as the cleanest, simplest approach that best promotes Whois accuracy.</p>
<p> </p>
<p>ARIN is a registry, not a regulator. Let's write policy that promotes accuracy in Whois, please.</p>
<p> </p>
<div>
<div name="divtagdefaultwrapper" style="margin: 0px; font-family: calibri,arial,helvetica,sans-serif;">
<div style="margin: 0px;"><font face="Calibri,sans-serif" size="2"><span style="font-size: 11pt;"><b>David R Huberman</b></span></font></div>
<div style="margin: 0px;"><font face="Calibri,sans-serif" size="2"><span style="font-size: 11pt;">Microsoft Corporation</span></font></div>
<div style="margin: 0px;"><font face="Calibri,sans-serif" size="2"><span style="font-size: 11pt;">Senior IT/OPS Program Manager (GFS)</span></font></div>
</div>
</div>
<div style="color: #282828;">
<hr tabindex="-1" style="width: 98%; display: inline-block;">
<div id="divRplyFwdMsg" dir="ltr"><font color="#000000" face="Calibri, sans-serif" style="font-size: 11pt;"><b>From:</b> Bill Darte <billdarte@gmail.com><br>
<b>Sent:</b> Wednesday, March 5, 2014 7:00 AM<br>
<b>To:</b> arin-ppml@arin.net; David Huberman; Owen DeLong<br>
<b>Subject:</b> ARIN Draft Policy 2014-2 Improved 8.4 Anti-Flip Language</font>
<div> </div>
</div>
<div>
<div dir="ltr">On Feb. 21 I sent the message (far below) to PPML asking the community to support one of 3 alternatives or propose new language which makes one or the other better, or a completely new wording which they believe accomplishes the goal of producing
policy language that is needed, technically sound and improves existing policy in the 8.4 Inter-RIR transfer realm.
<div><br>
</div>
<div>Summary of feedback so far:</div>
<div>2 persons supporting #2 with the removal of "and its subsidiaries". There was some support for the extended language of "and its subsidiaries having been operational for a minimum of xx months" in order to mitigate the rinse-repeat abuse that might accrue
through new shell subsidiaries.</div>
<div><br>
</div>
<div>There was some support for the alternative language expressed in #3 at the PPC in Atlanta and at the ARIN AC meeting on Feb 20. This language simply restricts the transfer of the block having been received...which would allow other existing blocks or
components to be transferred. One view against #3 was expressed as "<span style="font-family: arial,sans-serif; font-size: 13px;">An org that currently has a /8 can obtain the resources it needs and sell off the /8 out of region a few chunks at a time by
backfilling with new space from the ARIN region.". A rejoinder to this was expressed pointing out that other existing language in 8.4 states...."</span><span style="color: #000000; line-height: 1.5em; font-family: arial,helvetica,sans-serif; font-size: 12px; background-color: transparent;">Source
entities within the ARIN region will not be eligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs first."</span></div>
<div><span style="font-family: arial,sans-serif; font-size: 13px;"><<< end summary >>>></span></div>
<div><br>
</div>
<div><span style="font-family: arial,sans-serif; font-size: 13px;"><br>
</span> </div>
<div><span style="font-family: arial,sans-serif; font-size: 13px;">It is important that I receive a significant measure of support FOR or AGAINST continuing to work on this Draft and before the ARIN AC meeting on Mar 20, I would like to have better language
to propose if we are to make this Draft a Recommended Draft prior to the </span><span style="font-family: arial,sans-serif; font-size: 13px;">April </span><span style="font-family: arial,sans-serif; font-size: 13px;">PPM in Chicago. </span></div>
<div><span style="font-family: arial,sans-serif; font-size: 13px;"><br>
</span> </div>
<div><span style="font-family: arial,sans-serif; font-size: 13px;">I would be grateful for your feedback as early as possible.</span></div>
<div><span style="font-family: arial,sans-serif; font-size: 13px;"><br>
</span> </div>
<div><font face="arial, sans-serif">bd</font></div>
<div><font face="arial, sans-serif"><br>
</font> </div>
<div>
<div><<<<<<<<< earlier email sent to PPML on Feb 21 >>>>>>>>>>>>>>></div>
<div><span style="font-family: arial,sans-serif; font-size: 13px;">At the Advisory Council's meeting of Feb 20, discussion about Draft Policy <span style="background-color: #ffffcc;">2014</span>-<span style="background-color: #ffffcc;">2</span> concluded that
there is a real issue with transfer restrictions of address blocks between RIR jurisdictions for organizations having received a different block of addresses from ARIN within the last 12 months (per existing policy).</span>
<div style="font-family: arial,sans-serif; font-size: 13px;"><br>
</div>
<div style="font-family: arial,sans-serif; font-size: 13px;">The current Draft Policy language is as follows with only the last sentence being added from what is current ARIN policy:</div>
<div style="font-family: arial,sans-serif; font-size: 13px;">"Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request.
This restriction does not include M&A transfers. Restrictions related to recent receipt of blocks shall not apply to inter-RIR transfers within the same organization and its subsidiaries."<br>
</div>
<div style="font-family: arial,sans-serif; font-size: 13px;"><br>
</div>
<div style="font-family: arial,sans-serif; font-size: 13px;">The last sentence of this language was added to mitigate the problems related by the author in the problem statement and from experience. The author supported this change, however, some concern has
been expressed on the PPML and within the AC about the possibility of 'rinse and repeat' abuse associated with the ease of establishing new subsidiaries and using those transfers to get around the restrictions of the existing transfer policy.</div>
<div style="font-family: arial,sans-serif; font-size: 13px;"><br>
</div>
<div style="font-family: arial,sans-serif; font-size: 13px;">Three alternatives were primarily discussed and I wish to elicit feedback from the community relative to each.</div>
<div style="font-family: arial,sans-serif; font-size: 13px;"><br>
</div>
<div style="font-family: arial,sans-serif; font-size: 13px;">1. Use the existing last sentence as is and ask ARIN staff to be particularly watchful for seeming abuse and to bring such back to the community through regular Policy Experience Reports. There was
discussion about this option suggesting that by the time abuse was recognized and reported, and given limited existing free pool stocks and the extended policy development cycle....this option may be moot.</div>
<div style="font-family: arial,sans-serif; font-size: 13px;"><br>
</div>
<div style="font-family: arial,sans-serif; font-size: 13px;"><span style="background-color: #ffffcc;">2</span>. Remove the clause 'and its subsidiaries' or modify it in such a way as to mitigate the risk of a laundering of addresses through fraudulent transfers,
but this may still potentially limit the utility to organizations who may have complex organizational structures in use internationally.</div>
<div style="font-family: arial,sans-serif; font-size: 13px;"><br>
</div>
<div style="font-family: arial,sans-serif; font-size: 13px;"><font face="arial, sans-serif">3. T</font><span style="font-size: small;">ake an alternative tack and simply restrict transfers on a per-block rather than a per-organization basis. e.g. 'No block
acquired within the past 24 months would be eligible for transfer.' (The time frame is of course an arbitrary number at this point.)</span></div>
<div style="font-family: arial,sans-serif; font-size: 13px;"><font face="arial, sans-serif"><br>
</font> </div>
<div style="font-family: arial,sans-serif; font-size: 13px;"><font face="arial, sans-serif">If you believe this Draft Policy is improved most significantly by one of the above alternatives, or through another alternative you can pose....I, and the community
would benefit from your input. Thanks,</font></div>
<div style="font-family: arial,sans-serif; font-size: 13px;"><font face="arial, sans-serif"><br>
</font> </div>
<div style="font-family: arial,sans-serif; font-size: 13px;"><font face="arial, sans-serif">Bill Darte</font></div>
<div style="font-family: arial,sans-serif; font-size: 13px;"><font face="arial, sans-serif">Policy Shepherd for <span style="background-color: #ffffcc;">2014</span>-<span style="background-color: #ffffcc;">2</span> and </font></div>
<div style="font-family: arial,sans-serif; font-size: 13px;"><font face="arial, sans-serif">Advisory Council member</font></div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>