[arin-ppml] Additional modifications to Section 8.3 related to ASN's and legacy addresses

[Martin Hannigan]

On Wed, May 23, 2012 at 4:19 PM, John Curran <jcurran at arin.net> wrote:
> On May 23, 2012, at 3:46 PM, Martin Hannigan wrote:
>
>> John,
>>
>> The intention is to place the communities right to know above the
>> transfer parties right to privacy with respect to legacy number
>> resources and legacy ASN's. It would also be useful for you in order
>> to provide all of us with relevant data as to how a market is
>> operating to the standards we are setting. I know the latter is
>> probably easily accomplished even with confidentiality restrictions in
>> place, but the former is much harder without a policy standard. Is
>> there a better way to do such a thing? In the absence of a needs test
>> for legacy nr/asn's for example, I don't see a lot of need for
>> confidentiality requirements.
>
> Martin -
>
>  Implementing the policy proposal as written is quite possible,
>  but I wanted to highlight that providing this information to
>  the recipient happens presently and the recipient who does not
>  qualify has ability to share this information with current holder
>  as desired (or if required by any agreement between the parties.)
>
>  ARIN providing this information directly to the current address
>  holder may require us sharing information about the applicant
>  which is highly sensitive and to do so at the exact moment that
>  applicant/intended recipient and current address holder are
>  potentially ending their relationship.
>
>  ARIN providing this information only the applicant/intended
>  recipient and having the intended recipient keep everyone in
>  the pending transaction informed because its required per their
>  transaction document would be administratively easier and not
>  having ARIN providing one party's detailed network information
>  to another.  I do not know, however, if that approach meets your
>  policy goals; it may not be an effective option depending on the
>  problem you're trying to address.
>


John,

Thanks. I'm going to take a different track on this based on your
feedback and others. Separating 8.3 from the discussion and leaving it
intact will allow us to focus on [8.4] a non-legacy discussion which
may turn out to be simpler overall.

Best,

-M<