[ppml] Collapsing Residential and Business Privacy (ease ofuse) Was: Re: Privacy of Non-Residential Reassignments inPublic Whois

[Divins, David]

Thank you!

Yes, yes, and Yes.

The below post is much more concise than I have been.

-dsd 


David Divins
Principal Engineer
ServerVault Corp.
(703) 652-5955
-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of
Robert Bonomi
Sent: Friday, April 21, 2006 2:53 PM
To: ppml at arin.net
Subject: Re: [ppml] Collapsing Residential and Business Privacy (ease
ofuse) Was: Re: Privacy of Non-Residential Reassignments inPublic Whois


> Date: Fri, 21 Apr 2006 10:15:25 -0700
> From: "Azinger, Marla" <marla_azinger at eli.net>
> To: <ppml at arin.net>
> Subject: Re: [ppml] Collapsing Residential and Business Privacy (ease
of
> 	use) Was: Re: Privacy of Non-Residential Reassignments in
> 	Public Whois
>
> I can support the need for some Residential changes.  But not 
> commercial and not this way.
>
> I can not nor will not support the "collapse" and inclusion of 
> Business/ Commercial into this  policy.  If you work as a hostmaster 
> or ipadmin as I do you will have the unpleasant experience of how even

> a /29 can be used for spam or other abuse issues.  If its being used 
> for commercial purposes then it should be visible who is using it.
>
> As for the residential person that is running a office out of the
house.  
> Cant we just make it simple and allow this type of scenerio to publish

> a PO Box address instead of their home address?
>
> Moving the size from /30 to /29 is irresponsible and moves us a little

> further from fighting abuse in a proactive manner and closer to 
> reactive manner.  This is not how I choose to work daily.  I do 
> everything possible to fight abuse issues proactively.
>
> So no, I do not support the following suggested policy changes:
> - eliminate differentiation between residential and business
> - designate /29's and smaller as private
> - reduction of NA postal codes to 3 characters
> - 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!)
>
>
> Thank you
> Marla Azinger
> Frontier Communications
>

Folks,

  Watching the on-going discussion on this matter, it seems to me that
something _very_ fundamental has been overlooked.  As in, the
'fundamental purpose' of address-block delegations.  Which is to
identify the entity that is 'responsible' for activities emmenating from
that address-block.

  In the case of PI space, there' no question as to who that party is,
and one of the requirements for getting/keeping PI space is (or *should*
be) 'publicly admitting' that you _are_ reponsible for that space.

  As for PA space ....

  *IF* the ultimate assignee of that address block is willing to take
responsibility for those activities, then they have to be willing to
stand up and say  "I'm responsibile, and _here_ is how you can contact
me".  That includes, at a minimum, a working phone number, and a valid
snail-mail address.

  IF =NOT=, then all 'responsibility' lies with the penultimate assignee
-- the ISP (or, in rare cases, 'other party') that delegated that
sub-block to the end-user -- and the name should be simply something
like:
     {{provider}} Customer {{id no.}}
with *all* other information being that of that immediate 'upstream'
entity.
Note: if  one actually uses the '{{'/'}}' (or something similar) around
the provider name, it becomes 'trivial' to mechanically parse for
whether or not the 'responsible' party is the end-user.

      Side-bar: a direct corollary of this -- if you, as the end-user,
do _not_ 
    claim 'responsibility' for your network, you are authorizing your
upstream 
    to do whatever "management" of the datastream out of your network is

    'desirable' for the world at large.  e.g. if you're spewing spam, or
virus-
    attacks, or something else maloderus, the uptsream can (and should)
drop 
    filters in for that odiferous traffic; _then_ notify you to 'clean
up your 
    act'.  And pull the filters only after you've shown that you've done
it. 
    That _is_, after all, only what a 'responsible' end-user would do,
upon 
    receipt of notice of such activity originating from said end-user's 
    network.


  From that viewpoint, the argument about a /30 vs a /29, vs a /19 (or
what- ever), is entirely moot -- there is _always_ a clearly-identified
'responsible'
party for the address-block.  It is entirely up to the individual
provider to decide at what size-point, *if*any*, they require the
end-user to 'take responsibility' themselves.  Some providers could
require that every user regardless of size, 'take responsibility' for
their 'network'; while others could allow anyone, again 'regardless of
size', to remain 'private'.  In the grand scheme of things, it -doesn't-
make any difference, as long as you have the means to reach the
'responsible' party.

  It also renders moot the law-enforcement issue -- they can simply
"request" to be shown only as a provider 'customer'.  *OR*,  if they
have a fully functioning 'front' operation, they can use the
name/address/etc.
for that front -- since contact with the 'front' -will- put people in
contact with the 'responsible' party.

  Lastly, in the case of needing to take legal action, you can simply
name the provider _and_ "John Doe, a.k.a.{{provider}} Customer {{id
no.}}", subpoena the provider record for the identity of that customer,
amend the suit to include John Doe' real name and drop the provider.


  As for 'geo-location' services, address-block 'whois' info is largely
meaningless to start with.  For starters, IBM's  "corporate" address in
Deleware (or even 'headquarters' in NY) says nothing about where their
network equipment is.  And, anybody who is maintaining 'geographically
diverse' back-up sytems -- especially on as smaller scale, using PA
address-space -- may have networks in 'remote' parts of the country,
with the _same_ address-block contact-address info.  I'm sorry, but
trying to 'preserve accuracy' for geo-location services is a straw-man,
at best.
*UNLESS* (and this just occurred to me) you're only talking about cross-
checking address information on the registration for conistency -- e.g. 
street-address matches zipcode, zipcode matches phone-number, etc.

    Sidebar: cross-checking phone numbers (of 'smaller' operations) is
getting
    _very_ problematic.  with 'unlimited' long-distance, more and more
people 
    are _keeping_ their old cell-phone numbers when they move.  On a
telephone
    list  I was dealing with recently, I had "Washington D.C. area"
phone 
    numbers in area-codes 612, 619, 770, 303, 414, 816, 208, 510, 641,
and 419,
    as well as the usual D.C., Maryland, and Virgina suspects.  These
were 
    numbers that have been associated with D.C. addresses for at least
the past
    2-3 years.


_______________________________________________
PPML mailing list
PPML at arin.net
http://lists.arin.net/mailman/listinfo/ppml