[ppml] Question RE: Draft 2 of proposal for ip assignment with sponsorship

[william at elan.net]

It is not "necessary" for isp to sponsor and you should consider my proposal
as backup/alternate approach as somebody else already working on successor 
to 2002-3/2002-7. 

The reasons for this approach is that with some companies I talked to that 
were against previous proposals, they were most concerned about possible 
abuse if small netblocks are given by ARIN and they feel that only  
ISP can best deal with this situation and know if they need to accept 
customer or not. Most of my proposals deals with how to prevent abuse  and 
I'd venture to say I'v gone as far as can possibly be without having to 
put ARIN be the judge of what abuse is which is what they want to avoid. 

And as I said in the beginning this is "compromise" approach, it bridges 
gap in between some large isps, that do not want to give up their control 
of ip assigments and companies that want to be completely independent of 
them and deal only with arin on ip assignments. This still allows ISPs 
some control over how ips are given but allows changing of backbone 
providers and keeping your ip block. This may bring support of some that 
apposed previous proposals because but would obviously loose support of 
some as well.

As far as your ISP choosing to participate or not to participate in
sponsorship, this would be up to you, but you might loose potential or 
actual customers if you do not and with telecom as competitive as it is, 
this might make a difference. And I don't think its much of a headache, 
most being asked is the same ISP already does when it gets request for IP 
block from a customer (and I'm sure those who would refer customer to ARIN 
would most likely already looked at their request for ip block), /24 is 
already includes as automatic minimum with no justification and most 
other being asked is that ISPs keep good records on who their customers 
are which any good ISP should already anyway.

Now I'm going to list additional positive points me and somebody else made 
about this approach in the email two weeks ago:
  1. ARIN is not put in the position of having to verify multihoming,
     having two sponsors makes sure of that.
  2. Presumably existing arin members would filter out some companies that
     really do not need this separate ip block and make sure and make sure
     that some technical requirements exist for the assignment.
  3. It is still possible for company thatlgot this associative membership
     to move to another isp and keep the ip block, but they would need to
     make sure their new isp is willing to sponsor them.
  4. ARIN has records on who sponsors are and in case of billing problems
     or if it receives reports that address or some other whois info is not
     kept up to date, it can ask for assistance of their sponsors to get in
     touch with right people.
  5. In the event an org discontinues service, the ISP can notify
     ARIN.  In the event the org does not get a new sponsor, ARIN
     can notify the other sponsor that the assignment is no longer
     valid.  This should take care of the issue some have that an
     org could get an assignment and then stop multihoming
  6. I disagree that getting small IP blocks is hampered by this.
     The sponsors would have to agree to announce the block and the
     block could be smaller then a /24 thus conserving the address
     pool.  Since the block may not be contiguous with other blocks,
     there is no aggregation possible and both sponsors would be
     announcing the block to the world
  (Note: 5,6 are by Steve Rolapp, post on Feb 14th)

On Thu, 27 Feb 2003, Marla Azinger wrote:

> Hello-  I know I've missed alot of the discussion between the last
> conference and up to this point...so please bear with me and the question I
> have...
> 
> Why is it necessary for an ISP to "sponsor" this?  So far...sponsorship
> sounds like more of a headache than anything...I'm sure I'm missing
> something because up to this point...I would just say my company isnt going
> to participate in order to avoid...basically...all of it...we'v done fine
> without this until now...
> 
> I guess what I'm missing here is...how is a smaller telecom company that
> provides internet access supposed to benefit from "sponsoring" this?  Is
> there a benefit...or is this a bandaid for integrity issues?  I'm sure
> there's a good list of reasons I'm missing...like I said I've missed most of
> the discussion up to this point...but could someone provide a short and to
> the point list of how we'd benefit from "sponsoring" this?
> 
> Thank you for your patience and time
> Marla
> ELI IP Analyst
> 
> 
> 
> 
> I would rather not see this language. The policy states that ISP A or ISP B
> must inform ARIN
> when this happens. I know we can't depend on this to work, but if we build
> in a backup, why even
> ask ISP A or ISP B to inform ARIN of this change?
> 
> Jim
> >
> > I think some sort of language saying that ARIN will do audits of the
> > assignments from time to time is needed.  Or perhaps when you
> > pay your
> > annual renewal fee, you should have to provide proof along
> > with it that
> > you are still connected to more than 1 upstream.  Basically
> > something that
> > will prevent someone from being multihomed today, get a micro
> > assignment,
> > and then drop their second provider while keeping their micro
> > assignment.
> >
> > Forrest
> >
> > On Wed, 26 Feb 2003 william at elan.net wrote:
> >
> > >
> > > I'v made a 2nd draft for proposal for ip micro-assignment
> > with sponsorship.
> > > It does not format well to be posted in the email as text
> > but you can
> > > review it online at:
> > >
> > >
> > http://www.elan.net/~william/arin_proposal_for_micro_assignmen
> > ts_with_sponsorship.htm
> > >
> > > If you have any futher suggestions please feel free to
> > email me or otherwise
> > > discuss it on this list. If there are no suggestions for
> > addition to the
> > > current text, this will be the proposal I will send to
> > Richard Jimmerson
> > > end of this week.
> > >
> > > ----
> > > William Leibzon
> > > Elan Communications
> > > william at elan.net
> > >
> >
> >