Single organizations with multi-homed, discrete networks (fwd)

[Andrew Dul]

Hi David,

Thanks for you comments, you have valid points regarding the criteria that
I proposed.  The primary reason that I thought it was necessary to attach
criteria was to encourage address space conservation, and not to promote
wasteful usage.  Additional comments inline.

On Thu, 17 May 2001, David R Huberman wrote:

> 
> In response, I found I agreed with all of the requirements, but none of
> the criteria statements.
> 
> to wit:
>  
> > Criteria for the policy to apply:
> > 
> > * The organization must have a compelling criteria for creating discrete
> > networks. (Examples: regulatory restrictions, geographic diversity, etc)
> 
> That's not ARIN's business.
> 
> ARIN does not nor should not be involved with organization's business
> plans. 
> 
> "Why are you designing your network like this?"
> "Because we are."
> 
> And that's that.
> 
> Please do not try and make ARIN into more than what it is! We should not
> require ARIN's stamp-of-approval on major design issues.
> 

I see what you mean, but ARIN already makes judgments about what is and
isn't appropriate usage of IP space.  The first criteria was designed to
prevent organizations from just deciding that "X" usage was justification
for routing a /20.  I can envision some real abuses (wastes of space) that
could result if any usage was OK, but hopefully the utilization
requirements hopefully would restrict additional allocations.  Perhaps
this criteria isn't needed.

 
> > * Applies only to new and existing ARIN allocations after organization has
> > requested this policy to apply to their account.
> 
> I don't see why this is necessary to state in a policy. Organizations
> either aggregate their address space or they don't. As ARIN hostmasters
> consider any given request, the existence or lack thereof of such
> aggregation needs to be taken into account.
> 

I added this requirement so an organization couldn't go to ARIN and ask
for 16 /20's for their individual networks on an initial allocation.  
This would be a huge waste of IP space if the organization never had plans
to use that space in an efficient manner nor return to ARIN in the future
for additional space.  I also wanted to maintain the idea of "slow-start"
to prevent wasteful usage of IP space, similar to the RIPE assignment
window idea.

 
> > * Multiple maintainers per organization will not be allowed after
> > implementation.
> 
> Absolutely disagree. It's my prerogative to use the current policy
> framework to the greatest benefit of my company. While in most cases, a
> sensible individual can look at a company's numbering goals and state that
> using multiple maintainer ID's and ARIN accounts is both inadvisable and
> entirely unnecessary, that's not always 100% the case.
>

My initial thought was that this policy would cover all the cases where
one would want to open multiple maintainers.  If the policy covered those
cases then there probably wouldn't be a need for multiple maintainers.  I
wasn't advocating that organizations which already had multiple
maintainers should be forced to convert, only that after the time the
policy was in place it wouldn't be necessary to allow for multiple
maintainers.