[ppml] IPv6>>32

[Owen DeLong]

> 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.

Owen
-------------- 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.sig>