[arin-ppml] Draft Policy 2009-1: Transfer Policy ? Revisedandforwarded to the Board
Ted Mittelstaedt
tedm at ipinc.net
Tue May 5 20:59:14 EDT 2009
> -----Original Message-----
> From: David Farmer [mailto:farmer at umn.edu]
> Sent: Tuesday, May 05, 2009 4:28 PM
> To: Ted Mittelstaedt
> Cc: 'arin ppml'
> Subject: Re: [arin-ppml] Draft Policy 2009-1: Transfer Policy
> ? Revisedandforwarded to the Board
>
> I don't think it was a procedural trick at all. I think it
> was a premature proposal, ill-timed, and it was very awkward
> to deal with reinstituting a sunset that hadn't actually been
> eliminated yet. There were also some issues with how the new
> PDP works, that I think made it cleaner for the AC to abandon
> it and reintroduce a new proposal if needed after dealing
> with 2009- 1.
>
It would have been even cleaner to retain the sunset in 2009-1
and avoid the appearance of thwarting the original proposal.
> While I'm not sure a proposal to reintroduce a sunset would
> gain consensus. Note: The show of hands last week was 24 in
> favor of removing the sunset and 19 against removing it.
> However, I believe a proposal to reintroduce a sunset would
> now be in order. I have been personally thinking about if I
> should reintroduce such a proposal and when.
>
> I have given much thought to the whole issue of a sunset
> since the introduction of 2009-1and believe if it were
> reintroduced it should have a specific date associated with
> it. Further, I agree with Scott that something around 5
> years or so from now is about right, with a minimum of 3
> years after IANA free pool exhaustion.
>
> I have been thinking about December 31st, 2014, as a sunset
> date. Hopefully IPv6 will have succeeded by then or we will
> have some kind of new way of thinking about all of this,
> maybe both. Further, this is far enough after a Fall 2014
> Public Policy Meeting to implement policy to extend it or
> replace it with new policy.
>
> One of the many reasons I supported removing the sunset as it
> was in 2008-6, without a specific date there could be some
> really unfortunate timing created. By picking a specific
> date you can do a much better job of eliminating those timing issues.
>
> As for when to reintroduce it, we could do it now, but I know
> for a fact that many people are really tired of the whole
> issue.
I think many people are resigned to the sunset idea being thwarted
and figure the Board has "won" this round. The show of hands was
a recognition that if the membership voted to retain the sunset the
Board would override them anyway and simply further damage the
trust of the proposal process.
It would go a long way toward rebuilding trust
for an AC member who voted to get rid of the sunset to reintroduce
a sunset proposal now. By ignoring this and saying that we should
wait your just reinforcing the image that the Board is going to get
it's way no matter what. Also, a sunset clause's maximum usefulness
is that of a deterrent against speculation and the longer you
wait the less effective it will be.
Right now, people are familiar with the discussion so there isn't
a need to rehash the entire thing. And if people are tired of it,
then they are much less likely to want to rehash the whole thing.
> It might be more effective to wait a while, at least
> one policy cycle, maybe until IANA exhaustion, or maybe all
> the way until
> 2013 or 2014. By waiting until at least IANA exhaustion we
> could insure we set the right date and not need to change it again.
>
I think that there isn't anything wrong with the 2014 date. As
you said, this is far enough after a Fall 2014 Public Policy
Meeting to implement policy to extend it or replace it with new policy.
Keep in mind I never supported any of the transfer proposals prior to
2008-6 and I -only- supported 2008-6 because of the sunset, as a way
of shutting up the clamor from the pro-transfer camp without causing
permanent damage, and I didn't and don't support 2009-1 section 8.3
When I supported 2008-6 it never had occurred to me that anyone would
change the sunset after implementation, if it had I wouldn't have
supported it either.
My feeling has always been that talk of a transfer market is very
misguided, that there's plenty of "mineable" IPv4 in allocations
already made that have been abandonded, and our reclamation efforts
should focus there first.
As Kevin said, the existence of a transfer market complicates reclamation.
Prior to 2009-1, if ARIN staff contacted an org, perhaps as a result of
the POC cleanup efforts, and mentioned that a block they had didn't have
a valid POC, it might have resulted in the org saying "You mean we are still
paying for that, I thought we gave that back to you years ago"
Post 2009-1, if ARIN does that the org will not hand it back, they will
demand to keep it then go hawking it off on the "used IPv4 block" market.
Lest you laugh, I just ran across a block last month that still had my own
org's POC
on it, that we abandonded back to 2004. It consisted of a /23 assigned to
us
by Verizon in 1995, and I had to go through a lot of rigamarole with Level 3
for them to file a delete SWIP on it. We had NOT been paying anyone, either
Verizon or
ARIN, for this block. If you don't believe me I can give you the
ARIN-assigned
trouble ticket numbers regarding that case.
Some of these large networks are -extremely- disorganized and don't know
what
they have. Level-3 had got that from acquision of Genuity which had got it
from acquision of Verizon Data Services. It was extremely obvious talking
to
Level 3 that they had no idea of what holdings they had which originated
from
the Genuity acquisition since the bloc was not in any of their current
schemes.
Prior to the transfer market, the ARIN hostmaster could have quietly handled
this with Level 3 and perhaps aggregated it with adjacent blocks, also
abandonded.
The transfer market makes that impossible since the Level 3 peons have no
authority to give up assets, and a /23 is not large enough for someone in
Level 3 with authority to bother with selling it. As Kevin said, ultimately
the transfer market is going to work against reclamation.
Ted
More information about the ARIN-PPML
mailing list