[ppml] IPv6>>32

Owen DeLong owen at delong.com
Wed May 18 03:33:05 EDT 2005

> The problem or problems I see with this approach is that ISP's
> frequently have significant turnover in management folks as well
> as are bought out, merge or change ownership status i.e. going
> private or go public.  In such occurrences ISP Policy or knowledge
> thereof frequently changes and many times dramatically.  As such,
> continuity is lost or interpreted dramatically leaving ISP's actual
> customers at risk unnecessarily.
This is a business issue and a customer service issue between the
ISPs and their customers.  It is not part of address space stewardship,
and, is therefore out of scope for ARIN policy.

>> Personally, if we were
>> to codify it, then, the only codification I would accept would be
>> "on customer request".
>   I would agree this would be ONE way or addressing the issue.
> But given my above, perhaps not the best or necessary way..
I think it is absolutely necessary.  ARIN micromanaging the relationships
between customers and ISPs through address policy is a very slippery
slope.  The issue you raise is not an address policy issue, but, a
business relationship issue.

>> > Also agreed here.  Still under what criterion such IDR assignments
>> > are made needs to be delineated...
>> >
>> Why?  Why not leave it up to the ISP and customer to deterine within
>> the constraints of the existing policy?
>  No reason, as long as that policy is sufficiently delineated...
I believe it is sufficiently delineated, but, could use some clarification.

>> [snip] increasing SOHO users needing multiple space / possibly /56
>> > Also agreed here.  But it should be exacting as to form/language
>> > so that the policy is easily understood and far less subject to
>> > interpretation.
>> >
>> I think that clarification would be good, but, I don't think that
>> codification is necessary or desirable at this time.
> It's probably not desirable true, but I would say it is or is nearly
> necessary.
I think it's not only unnecessary, but, potentially harmful.

>> I think leaving
>> the decision between the LIR and end-site is the prudent approach right
>> now.
>   Having this decision as far down as possible is my personal preference
> as well.  I am not arguing that.  I do however believe a need to have some
> well defined guidelines and/or parameters contained and codified as
> part of the policy yet flexible, which is difficult to do at times and
> as a function of language, is and has been necessary for reasons
> or continuity and broad understanding.
Well... The current policy says exactly what we've described above, and, is
being implemented by ARIN staff at this time as we have described above.
As such, I can accept that some clarification may be necessary to ensure
that a wider audience concurs with this shared understanding, but, I don't
see any need to change the meaning of the policy or alter it's current
implementation in this particular area.

>> I agree that we should do what we can to make sure LIRs and end-sites
>> know what the policy allows and what options are available within the
>> policy.
>  Good.  But this *May* not be all that is needed.  Recommendations
> as to provide for what not to do may also be necessary, and I believe
> is given human nature.
I'm not sure I follow what you mean here.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050518/37fc3e35/attachment-0001.sig>

More information about the ARIN-PPML mailing list