[ppml] Collapsing Residential and Business Privacy (ease of use) Was: Re: Privacy of Non-Residential Reassignments in Public Whois

[Robert Bonomi]

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