[ppml] Comment on "Policy Proposal 2006-1" (Residential Privacy modification)
marla.azinger at frontiercorp.com
Wed Oct 11 15:14:40 EDT 2006
Very well said William.
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
Sent: Wednesday, October 11, 2006 11:32 AM
To: Sam Weiler
Cc: ppml at arin.net
Subject: Re: [ppml] Comment on "Policy Proposal 2006-1" (Residential
On Tue, 10 Oct 2006, Sam Weiler wrote:
> On Wed, 4 Oct 2006, william(at)elan.net wrote:
>> (in fact for US even 5 letter code is not specific - zip
>> codes follow density as well so rural territories have very large
>> areas covered by same zipcode).
> In Montreal, I presented some results derived from the US Census
> bureau's ZCTA files (not quite the same as ZIP codes, but pretty
> close, and pleasantly easy to get to). From my observations,
> ZIP code density is not particularly even.
Its due to some special zip codes (i.e. for a university, government
district) which would have few or no residential users. But for
residential or normal city area they generally match except cases
when smallcommunities are just way too far apart. But even then its
not like dozen houses - its always measured in thousands of residents
for each postal office. Now what does happen is that few areas have
lost population but still retained separate zip code - now managed
from some other post office.
But actually there is no point in arguing about these rare corner
cases - the proposal before was to make 3 digits of zip code required
(including for US zip codes), which would make it possible to only
include general geographic area if somebody is worried.
>> Regarding city this is indeed an issue for rural areas where city
>> may include only a dozen households (in many states they would not
>> even allow to incorporate in this case). I agree that this needs
>> to be addressed and there is actually a very simple solution by
>> allowing County name to be entered in case this is unincorporated
>> area (which is in fact exactly what is being done right now) as
>> well as if the city itself is smaller then say 1000 residents -
>> we can even do it by just renaming "city" field to "city/locality"
>> and leaving it to the discretion of the ISP if the are entering
>> actual city name there or name of local territorial unit (township,
>> borrough, county, etc) if user has privacy concerns.
> I'm glad you agree that these small areas need to be dealt with.
They are in a way already dealt with in practice, i.e. if you ever
bothered to check, you'd see that it hapenns regular that large
nearby city is entered instead of small suburban town or country
name for rural area [would have been easier if I they actually
added 'County' at the end instead of me having to guess it based
on zip code]. This way of dealing with the issue just never been
officialized by arin policies.
> First, as noted above, the issue is the same for ZIP codes and small
> Second, I have concerns that specifying the details of such a policy
> would be intractable, particularly given the twenty-six different
> "countries" in ARIN's service region, some of which are likely to do
> their own thing with respect to postal codes.
I'm sure policy can be worked out to account for it (i.e. postal
code entry requirement is 3 letters/digits except when country has
no postal code or its postal code is 3 letters or less in which case
entering it is not required). And do note that nobody from those
countries has spoken - so don't presume that you can assume the
residential privacy has the same issues there.
> Thirdly, I'm concerned that even setting a threshhold to the size of
> the area identified, even if we agree that it's tractable to use such
> a threshhold, will wind up providing too little privacy for the end
And as I've noted I'm concerned that policy proposal justification
is being made due to corner cases that are < 0.01% of arin db
(and not even by those actually impacted or ISPs serving them) but
proposal is done in such a way that would have very very wide scale
difference for everyone else.
william at elan.net
PPML mailing list
PPML at arin.net
More information about the ARIN-PPML