<html xmlns:v="urn:schemas-microsoft-com:vml" 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=us-ascii"><meta name=Generator content="Microsoft Word 12 (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;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 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";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
        {mso-style-priority:99;
        mso-style-link:"Plain Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.5pt;
        font-family:"Calibri","sans-serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";}
span.PlainTextChar
        {mso-style-name:"Plain Text Char";
        mso-style-priority:99;
        mso-style-link:"Plain Text";
        font-family:"Calibri","sans-serif";}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoPlainText>The policy proposal addresses many of the current “tensions” arising out of the legacy resource trading market.  It recognizes, in policy, the practical reality that attempting to extend ARIN’s existing policies designed for numbers under contract with ARIN (where ARIN has direct control) to legacy numbers that are not under contract with ARIN (where ARIN has no direct control) has its limits and is currently producing (possibly) unintended consequences that I believe are undesirable for the community.  <o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText style='margin-left:.5in'>E.g., Increasing inaccuracies in the WHOIS databases; and limiting ARIN members’ access to “off-contract” legacy numbers (while still remaining compliant with policy) due to burdens imposed on both the source and the recipient under the current 8.3 transfer policy (where the needs justification requirements impose a cap of 24 months’ supply that supplants the recipient’s own business judgment on how best to use its capital to manage  the risks to its business presented by the depletion of the RIR free pool of unallocated IPv4 numbers).<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>I like many aspects of the proposal, but I do have some questions for Martin and others about it.    <o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>8.4.3 Needs Assessments and Utilization Requirements<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>    Needs assessments and utilization requirements for legacy number resources and ASN's are waived.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><i>[[What’s your view on whether the recipient should be required to execute an RSA or LRSA as a condition for ARIN to update the database where the requirements of 8.4.4-8.4.5 are otherwise met?]]  <o:p></o:p></i></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>8.4.4 Registry Services<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>ARIN will insure that all parties to a legacy number resource or ASN transfer agree to provide and maintain accurate WHOIS contact data in compliance with WHOIS policy. Transfers shall not be completed until all submitted WHOIS update data has been verified as accurate.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>8.4.5. Chain of Custody Validation<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>No resources may be transferred without a verifiable chain of custody demonstrating that a party desiring to transfer a resource is the legitimate holder of such a resource and is eligible to transfer the resource. Upon confirmation of a valid chain of custody of a resource, ARIN will certify that resource as transferable. ARIN will maintain this certification on file for future reference.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><i>[[Very good addition to the process.   Who do you think should perform the chain of custody validation to satisfy this requirement?  Is this an ARIN direct responsibility, something that would be performed by a qualified third-party under certain standards, or both?]]<o:p></o:p></i></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>8.4.6 Flawed Custody and Fraudulent Applications<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>ARIN will reclaim resources that fail chain of custody certifications or are deemed to have been fraudulently obtained and presented for transfer.<o:p></o:p></p><p class=MsoPlainText>Such reclaimed resources will be immediately placed on an Abandoned Resources List and in escrow. The list shall be made available to the public.<o:p></o:p></p><p class=MsoPlainText><i><o:p> </o:p></i></p><p class=MsoPlainText><i>[[This one concerns me.   Specifically, the part about reclaiming resources that fail the chain of custody search.  It may be that the requestor isn’t the rightful holder, but some other entity may still have a strong claim to the numbers.  In addition, many who make claims to legacy numbers are acting in good faith, but may just not be able to sufficiently demonstrate via supporting documentation an unbroken chain of custody.  <o:p></o:p></i></p><p class=MsoPlainText><i><o:p> </o:p></i></p><p class=MsoPlainText><i>This could chill the willingness of some legacy holders (those with less than perfect, but still reasonable, claims to the legacy numbers) to use the ARIN process for fear that they will lose their numbers in the event that the chain of custody validation fails. Numbers in this category may either be traded outside the ARIN process or simply remain dormant and unused.  <o:p></o:p></i></p><p class=MsoPlainText><i><o:p> </o:p></i></p><p class=MsoPlainText><i>Like a typical critic, I see the flaws in 8.4.6 but I don’t yet have a better alternative to propose that balances the need to re-purpose abandoned numbers without extinguishing the rights entities have in their legacy numbers.   A fair, independent, and transparent processes to appeal reclamation decisions and resolve competing claims to contested legacy numbers prior to declaring them abandoned might help.  I’m interested in other’s thoughts on this point.]]<o:p></o:p></i></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoNormal>* * *<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b><span style='font-size:12.0pt;color:#404040'>Marc Lindsey<o:p></o:p></span></b></p><p class=MsoNormal><span style='font-size:10.0pt;color:#686667'>Levine, Blaszak, Block & Boothby, LLP<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;color:#686667'>2001 L Street, NW Suite 900<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;color:#686667'>Washington, DC 20036<o:p></o:p></span></p></div></body></html>