[arin-ppml] 2015-2

Rudolph Daniel rudi.daniel at gmail.com
Thu Jun 4 10:29:48 EDT 2015


"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
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20150604/50ea994c/attachment-0001.html>


More information about the ARIN-PPML mailing list