[arin-ppml] 2015-2
David Huberman
David.Huberman at microsoft.com
Thu Jun 4 10:37:29 EDT 2015
Yes RD. I can think of two interesting (and very different) scenarios where this plays out every day:
1) Companies either abandon transfer requests with ARIN, or they don't even submit them. ARIN staff have done good work addressing the former, in hopes it will remedy the latter. But there are thousands of block registrations in ARIN Whois which are not accurate, and which have been reported to ARIN as transferred, but remain in the wrong name. ARIN transfer policy was too strict, and ARIN procedures too bureaucratic, and thus legitimate transfers of blocks were ignored.
2) Many companies (including big internet names you use every day) have already bought IPv4 addresses (or “the first right of refusal” and other types of contracts) for the future needs beyond 2 years. Big companies have locked up their /8s. ARIN won’t process those transfers. The IP address registrations remain in legacy holders’ names, even though the legacy holders have sold them off.
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Rudolph Daniel
Sent: Thursday, June 4, 2015 7:30 AM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] 2015-2
"Ignoring a request by a seller of address space to update the contact information to that of a buyer means the registry will no longer reflect reality, thereby defeating the point of the registry."
Regards,
-drc
(ICANN CTO, but speaking only for myself. Really.)>>>
Think you are correct....but, it is ever ignored?
RD
On Jun 3, 2015 11:37 PM, <arin-ppml-request at arin.net> wrote:
Send ARIN-PPML mailing list submissions to
arin-ppml at arin.net
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.arin.net/mailman/listinfo/arin-ppml
or, via email, send a message with subject or body 'help' to
arin-ppml-request at arin.net
You can reach the person managing the list at
arin-ppml-owner at arin.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-PPML digest..."
Today's Topics:
1. Re: On USG 'granting of rights' (was: ARIN-PPML 2015-2)
(Adam Thompson)
2. Re: Registry functioning (was: Re: ARIN-PPML 2015-2)
(David Conrad)
3. Re: Registry functioning (Matthew Kaufman)
4. Re: ARIN-PPML 2015-2 (Matthew Kaufman)
----------------------------------------------------------------------
Message: 1
Date: Wed, 03 Jun 2015 22:06:11 -0500
From: Adam Thompson <athompso at athompso.net>
To: William Herrin <bill at herrin.us>,Seth Johnson
<seth.p.johnson at gmail.com>
Cc: "arin-ppml at arin.net List" <arin-ppml at arin.net>
Subject: Re: [arin-ppml] On USG 'granting of rights' (was: ARIN-PPML
2015-2)
Message-ID: <0F7BE842-C8E3-4667-B1A7-45C219E536B3 at athompso.net>
Content-Type: text/plain; charset="utf-8"
Also, the Canadian province of Quebec has civil law based on French civil law, not English like the rest of Canada. Considering that nearly half of all major Canadian corporations have their headquarters there... I don't have to draw that picture, I think. IIRC, there's no (e.g.) adverse possession concept, among other things. IANAL, can't explain all the differences.
-Adam
On June 3, 2015 5:38:08 PM CDT, William Herrin <bill at herrin.us> wrote:
>On Wed, Jun 3, 2015 at 6:24 PM, Seth Johnson <seth.p.johnson at gmail.com>
>wrote:
>> If it's copyright, the judge won't do that. There's no such thing as
>> an "exclusive right to use" in copyright.
>
>Hi Seth,
>
>IP addresses are definitely not copyrights. Or trademarks, patents or
>trade secrets. So far as I know, they're not any kind of
>*intellectual* property whose existence derives from statute and, in
>the U.S., from the Constitution itself.
>
>I suspect they're Common Law *Intangible* Property which is something
>else entirely. At least they are in common law jurisdictions which
>includes all of the U.S. and Canada and if I'm not mistaken everywhere
>else in the ARIN region as well.
>
>Much of Europe operates on Roman Civil Law rather than English Common
>Law. The legal foundations over there are so different I couldn't
>begin to speculate how IP addresses fit.
>
>Regards,
>Bill Herrin
>
>
>--
>William Herrin ................ herrin at dirtside.com bill at herrin.us
>Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
>_______________________________________________
>PPML
>You are receiving this message because you are subscribed to
>the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>Unsubscribe or manage your mailing list subscription at:
>http://lists.arin.net/mailman/listinfo/arin-ppml
>Please contact info at arin.net if you experience any issues.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20150603/9a6751a5/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 3 Jun 2015 20:29:49 -0700
From: David Conrad <drc at virtualized.org>
To: John Curran <jcurran at arin.net>
Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
Subject: Re: [arin-ppml] Registry functioning (was: Re: ARIN-PPML
2015-2)
Message-ID: <78C72AE5-9985-4FDB-A13B-29F82801DD2E at virtualized.org>
Content-Type: text/plain; charset="windows-1252"
John,
>> If the community defines a policy that violates the trust the community has placed in ARIN, then I definitely am advocating that ARIN not follow that policy (community defined or not). For example, if the community defines a policy that requires ARIN to (say) "confiscate" IPv4 addresses from AfriNIC, then yes, I would advocate ARIN not follow the community-developed policy. Would you, as ARIN's CEO, say that policy must be followed?
>
> In our particular policy development process, there is a specific check where the Board
> confirms that the policy advances ARIN's mission, does not create unreasonable fiduciary
> or liability risk, is be consistent with ARIN's Articles of Incorporation, Bylaws, and all
> applicable laws and regulations.
Ironically, I had written a sentence that said "Please don't say 'our policy process wouldn't allow something like that' -- this is a hypothetical intended to be something easily identifiable as just wrong.", but deleted it as I felt it was obvious and didn't need to be said.
> Ergo, I would hope that a policy that violates the ARIN?s mission (including the trust of the community) would not be ratified
And my point has been that policies that damage the registration database are in violation of the mission of any of the Regional Internet Registries and should not be proposed, accepted, or ratified.
>> However, as you may have noted, I strongly believe that _if those transfers still occur despite ARIN policy, the registry must still accurately reflect that transfer_.
>
> Okay, I think I see the area of disconnect, and it is with respect to the above point.
>
> Is it correct to say that you simply feel registry should always be updated if address
> holder wishes (and even if they disregard policy, fail to enter an agreement pay the
> transfer fee, etc?)
>
> Or are you saying that we should deny such transfers, but if somehow effectively
> ?possession? of the address block moves to another party despite lack of transfer,
> that the registry has to eventually reflect reality?
I'm not sure I see the the distinction you're making between the two. My opinion on whether ARIN should deny (presumably out of policy) transfers is not particularly relevant. Ignoring that, my answer to both would be 'yes'.
Simply, I believe the registry needs to reflect reality as accurately as possible. As I've said before, the point of the registry is help ensure uniqueness and to facilitate the identification of contacts to support network operations, help track down sources of abuse, etc. Ignoring a request by a seller of address space to update the contact information to that of a buyer means the registry will no longer reflect reality, thereby defeating the point of the registry.
Regards,
-drc
(ICANN CTO, but speaking only for myself. Really.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20150603/b07a9785/attachment-0001.bin>
------------------------------
Message: 3
Date: Wed, 03 Jun 2015 20:31:38 -0700
From: Matthew Kaufman <matthew at matthew.at>
To: John Curran <jcurran at arin.net>
Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
Subject: Re: [arin-ppml] Registry functioning
Message-ID: <556FC69A.6040703 at matthew.at>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 6/3/2015 3:06 PM, John Curran wrote:
> On Jun 3, 2015, at 5:48 PM, Matthew Kaufman <matthew at matthew.at
> <mailto:matthew at matthew.at>> wrote:
>> ...
>> You could certainly argue (and I might) that the records of legacy
>> assignments were in fact entrusted to ARIN to keep, and keep updated
>> *whether or not the community drafted policy that said such updates
>> were disallowed*
>
> Noting just one of the significant problems with that argument being
> that at the time
> of ARIN?s formation, the actual applicable registry policy was RFC
> 2050 (having been
> finished just a year earlier with folks like David Conrad and Jon
> Postel as authors) -
And strangely after many legacy addresses had already been allocated.
> it states that those obtaining addresses via transfer must "meet the
> same criteria as
> if they were requesting an IP address directly from the Internet
> Registry."
Yes, the word "transfer" appears exactly once, and undefined, in RFC2050.
The same RFC says that one of the three goals is to "document address
space allocation and assignment" - as it says "this is necessary to
ensure uniqueness and to provide information for Internet trouble
shooting at all levels". It is this latter goal that will no longer be
met if organizations are forced to "transfer" without "transferring".
>
> I.E., If we were maintain the exact status quo that such parties had
> prior to ARIN?s
> formation, recognized ARIN is entrusted to maintain that, then folks
> probably would
> not like the result - today?s transfer policy is more lenient than the
> transfer policy at
> that point in time.
>
That's one possible conclusion.
> (Thank an ARIN Advisory Council member when you next see them for all
> of their
> efforts getting useful transfer policy in the Number Resource Policy
> Manual! :-)
>
We'll see.
Matthew Kaufman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/20150603/343a9845/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 03 Jun 2015 20:37:07 -0700
From: Matthew Kaufman <matthew at matthew.at>
To: Jason Schiller <jschiller at google.com>
Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
Subject: Re: [arin-ppml] ARIN-PPML 2015-2
Message-ID: <556FC7E3.5050601 at matthew.at>
Content-Type: text/plain; charset=utf-8; format=flowed
On 6/3/2015 9:19 AM, Jason Schiller wrote:
> There are two classes of address users on the Internet.
>
> 1. Those whose need for IP addresses does not grow
>
> 2. Those whose need for IP addresses continues to grow
>
> In the case of the first camp, there is no competitive disadvantage if
> someone else buys all the
> available IPv4 addresses.
>
> In the case of the second camp, if your organization can buy enough
> IPv4 addresses to make it
> through until the date when wide spread IPv6 adoption occurs, or at
> least have a longer time
> horizon of addresses than your competitors then there is no business
> impact of running out
> of IPv4.
>
> On the other hand if you don't have enough IPv4 addresses to make it
> through until the
> date when wide spread IPv6 adoption occurs, and you run out before
> your competitors
> you risk losing growth going forward if there is IPv4-only content
> that your transit customers
> desire, or if there is an IPv4-only customer base your service want to
> serve.
>
>
> You don't need an unlimited supply, you only need either enough to get
> you through transition
> or more than your competitor (which ever is less).
>
>
> I don't think it is safe to assume that all companies who need
> addresses for growth have already
> secured enough to get them through transition. (If that was the case
> we wouldn't be having this
> discussion.)
>
> Certainly some organizations have decided not to complete below board
> transfers that they cannot
> currently justify under ARIN policy. Certainly some have decided not
> to secure a future in IPv4
> addresses because the risk is too high. Certainly some have limited
> their activities because of
> the level of risk, lack of transparency in pricing, uncertainty about
> IPv6 adoption time lines,
> uncertainty about the customer measurable impact of CGN, and a dozen
> other things.
>
>
> Nor do I think it is safe to assume that all the IPv4 addresses that
> could be made available have
> already been made available.
>
>
> Given that it is likely that there are organization that have not
> secured enough IPv4 addresses
> to get them through wide spread IPv6 adoption.
>
> Given that it is likely that there are still more IPv4 addresses
> available on the market for the
> right price.
>
> Given that there is always the possibility that IPv4 addresses could
> be returned and made
> available through the current mechanisms.
>
> Is it good for the community to legitimize and reduce the risk of
> below board transfers
> and futures for organizations that desire more addresses than they can
> justify for the
> next two years growth thereby supporting and encouraging the behavior
> where
> organizations who are willing to spend more cash now get preferential
> access to IPv4
> addresses for potential future need over organizations that need
> addresses now
> (or in the next two year time horizon)?
>
>
Do you believe that allowing the transfers proposed in 2015-2 would
significantly do what you say is good for the community above?
Matthew Kaufman
------------------------------
_______________________________________________
ARIN-PPML mailing list
ARIN-PPML at arin.net
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 120, Issue 28
******************************************
More information about the ARIN-PPML
mailing list