[ppml] IPv4 "Up For Grabs" proposal

[Ted Mittelstaedt]

>-----Original Message-----
>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
>James Jun
>Sent: Thursday, July 05, 2007 11:00 AM
>To: 'ARIN PPML'
>Subject: Re: [ppml] IPv4 "Up For Grabs" proposal
>
>
>> Either you want the RIR's to keep track of IPv4 forever
>
>You are confused.  RIR's keep track of their subscriber numbering resources
>(in IPv4 and IPv6).  Legacy owners who are not members of the RIR
>are beyond
>the scope of RIR responsibility.
>

Let me demonstrate:

# whois -h whois.arin.net 199.248.255.0

OrgName:    Leatherman Tool Group, Inc
OrgID:      LTG
Address:    12106 NE Ainsworth Circle
City:       Portland
StateProv:  OR
PostalCode: 97220
Country:    US

NetRange:   199.248.255.0 - 199.248.255.255
CIDR:       199.248.255.0/24
NetName:    LEATHERMAN
NetHandle:  NET-199-248-255-0-1
Parent:     NET-199-0-0-0-0
NetType:    Direct Assignment
NameServer: NS.FTA.COM
NameServer: NS01.SAVVIS.NET
Comment:
RegDate:    1994-10-11
Updated:    2004-05-05

RTechHandle: BCO-ARIN
RTechName:   O'Brien, Byron
RTechPhone:  +1-503-546-9929
RTechEmail:  hostmaster at hcorp.com

# ARIN WHOIS database, last updated 2007-07-04 19:10
# Enter ? for additional hints on searching ARIN's WHOIS database.
news#

I guarenteee to you that Leatherman Tool Group IS NOT paying ARIN a dime,
has NEVER paid them a dime.  Yet, ARIN is still tracking this so ARIN
obviously considers this legacy holder still their responsibility.

>If you want your policy proposal to have any chance of consideration, you
>will have better luck submitting such proposal to the NRO for global
>adoption and provide input to the IANA.  Ignorantly assuming that somehow
>legacy holders are ARIN responsibility just because they are in ARIN region
>is not helpful.
>
>
>
>> - in which case
>> the legacy holders could simply choose to never adopt IPv6 and the
>> Internet
>> would be stuck in dual-stack mode forever
>
>Who cares if they choose to not adopt IPv6?  People can continue to run
>Arcnet and Token Ring as long as they have a need to, same goes for
>IPv4->IPv6.  It is *their* responsibility as operator of their own network
>to ensure that their customers and majority of Internet public as whole can
>get to their services -- which means, they will be the ones responsible for
>dual-stacking, not you

No, sorry it does not work that way.  The reason is that when "their"
customers
cannot connect to a service one of my customers is fielding, their customer
may in fact complain to them, but my customer is going to complain to me
also.  If I want to retain my customer I'm going to have to do whatever it
takes
to allow the legacy network to connect to me, because there's always another
ISP somewhere that will claim they will allow my customer to service the
customer on the legacy network.  (even if it isn't true)

By the time my customer finds the truth out he's left me and gone to the
other ISP (and probably left that ISP and gone to yet another one)

The same thing happened when Verizon.net started doing their "caller ID
call-back"
e-mail which is definitely NOT compliant to the RFCs.  WE had to change to
be
compliant with them, even though they were the ones breaking the rules,
because
customers don't care who is right, they just want you to "fix it" and they
don't
care that your fix might be the wrong thing to do.

>(which by the way you still haven't even received
>your IPv6 block from ARIN, why are you even advocating crazy rules when you
>don't even care about IPv6?) or anyone else.
>

Letting legacy holders get away witout funding the RIR that tracks them is
in my opinion, far crazier than any rules I've proposed.  Yet, you accept
it.

>
>
>> - or you must agree that at some
>> point the RIR's stop keeping track of it.  If you do agree the RIR's stop
>> keeping track of it at some point, then what conditions must exist for
>> that
>> point to be reached?
>
>RIR's are already not keeping track of legacy holders, simply because they
>are not members controlled by the RIR.

Wrong, as I illustrated above.

Ted