[arin-ppml] ARIN-prop-173 Revisions to M&A TransferRequirements(Updated Version)

[McTim]

Hi,

On Thu, Jul 5, 2012 at 4:31 PM,  <sandrabrown at ipv4marketgroup.com> wrote:
> <SNIP>
> from the proposal:
>>>>>>>>>>>>>>>>>
> Transfers under
> this Section 8.2 shall not be contingent upon the new entity's
> justification of need for the transferred numbers.
>
> <<<<<<<<<<<<<<<<<<<<<<<
>
>
> I support Marc Lindsay's proposal.  It woud be a significant improvement
> over the current 8.2.  While I was with Nortel, we avoided transferring
> any legacy blocks that were in the names of Bay Networks, Xylogics,
> Synoptics, and other past acquisitions, as it made no sense to go
> through needs assessment as part of that process.
>
> Also, as I have posted in the past, I believe the accuracy of the
> registration database is the most important duty of the ARIN Advisory
> Council, and this will help the AC to fulfill that duty.
>

Responsibilities of the AC are listed here:

https://www.arin.net/about_us/ac_requirements.html

I'm not sure I would put accuracy of WHOIS data on their plate as
well, the list is long enough I would think.


> Think of the numerous companies that are partially using their blocks,
> have no intention of monetizing those blocks, and they, under the
> current 8.2 policy, would have to prove their needs assessment to
> justify keeping addresses in order to update their registration.

this seems to be a trivial requirement to me...YMMV.


>
> At present, I don't think they will come forward, and risk being told to
> aggregate internally generating tons of engineering and operational
> work,


Do RIRs tell folk how to number their network? I think this is a red-herring.

 and thus, the ARIN database would remain out of date.  While ARIN
> often promises to behave reasonably, and has historically tried to make
> its own rules work, this case would require something secret like a
> fictitious needs assessment, and I have only heard that to be in
> Microsoft and Cerner's copies of the ARIN Manual.
>

What case are you referring to above?

> Mr. Lindsay's proposal will help to overcome this problem.
>
> <SNIP>
> from the proposal:
>>>>>>>>>>>>>>>>>
> 8.2.1 If the transfer request pertains to non-legacy numbers or legacy
> numbers governed by an LRSA or RSA at the time such transfer request is
> first submitted to ARIN, the new entity shall be required to execute, in
>
> its own name, an RSA covering the transferred numbers, and pay the
> applicable registration fees.
> <<<<<<<<<<<<<<<<<<<<<<<
>
> This new proposal will not totally overcome the problem for those under
> LRSA.  It continues to punish those

how so?


 who have consumed the ARIN koolaid
> and have mistakenly signed an LRSA.  If their ARIN records are
> incorrect, and they update the transfer information, it will further
> punish them by converting their LRSA to an RSA.  Perhaps that aspect can
> be fixed in the proposal.
>
> As a sidenote, this is a good problem for ARIN to address.  We at IPv4
> Market Group have many times been asked by companies contemplating sales
> of IPv4 assets if they should first do an 8.2 transfer and we have to
> tell them no, due to the punitive wording of 8.2.  They are much better
> off to leave their registrations incorrect until they can arrange a
> sale, and this is not in the best interest of an accurate Internet.


So now we see the heart of the matter.  Your concern over the accuracy of
WHOIS data takes a back seat to profit via the sale of v4 resources
(and your commission presumably).

8.1 and 8.2 are, at the moment clauses I can grok at first reading.
I can't say the same for this proposal.


-- 
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A
route indicates how we get there."  Jon Postel