[ppml] Collapsing Residential and Business Privacy (ease of use) Was: Re: Privacy of Non-Residential Reassignments in Public Whois
At 02:58 AM 4/19/2006, Owen DeLong wrote:
>Content-Type: text/plain; charset=us-ascii; format=flowed
>*** PGP Signature Status: unknown
>*** Signer: Unknown, Key ID = 0x0FE2AA3D
>*** Signed: 4/19/2006 2:58:09 AM
>*** Verified: 4/19/2006 9:43:13 AM
>*** BEGIN PGP VERIFIED MESSAGE ***
>--On April 19, 2006 2:18:52 AM -0400 Martin Hannigan <hannigan at renesys.com> =
> > At 12:25 PM 4/10/2006, Divins, David wrote:
> >> Due to popular demand....Attempt number 3 at an accurate Subject :-)
> > During the XVII meeting, I talked to the author of the residential
> > concerns over residential and business privacy.
> > My suggestion to the AC (and proposers) regarding
> > proposals would be a rewrite to accomplish the following:
> > - eliminate differentiation between residential and business
>I strongly oppose this provision. There is no reason to remove
>address accountability from business orgs.
How would you do this?
[ snip ]
> > - creating a confidential/undercover registration clause to allow
> > LEA to mask registrations for investigative, intelligence,
> > or other purposes as long as they identify these to ARIN
> > staff AND ARIN is able to handle such information per FISA, Title III.
> > CALEA, and other applicable regulations (IANAL). This
> > follows a concept invoked by DMV's related to license plates.
> > (and a memory jogging by Heather Skanks - thank you!)
>Sorry, I just don't see a need for this. The black hats have plenty
>of IP space from DoD and lots of other sources and they're plaing
>on their own networks anyway. This just provides another layer of
>headache to ISPs and doesn't benefit the community in any way.
>Convenience at concealment for government ops. is the last thing
>I want to see expanded under the current administration.
I meant to say they would inform their provider. Providers who have
customers who have such a need are already set up to function this
way and would merely be a workflow issue for them, if not simply
legitimizing the inaccuracies they are already sending.
Martin Hannigan (c) 617-388-2663
Renesys Corporation (w) 617-395-8574
Member of Technical Staff Network Operations
hannigan at renesys.com