From memsvcs at arin.net Wed Nov 5 09:33:55 2003 From: memsvcs at arin.net (Member Services) Date: Wed, 5 Nov 2003 09:33:55 -0500 (EST) Subject: [ppml] ARIN XII Meeting Minutes and Webcast Archives Available Message-ID: ARIN recently concluded its twelfth Public Policy and Member Meetings held in Chicago, Illinois, October 22 - 24, 2003. Minutes of these meetings, as well as the presentations given and webcast archives of the two days of public policy meetings are now available on the ARIN website at: http://www.arin.net/library/minutes/ARIN_XII/index.html Member Services Department American Registry for Internet Numbers From memsvcs at arin.net Tue Nov 18 14:11:17 2003 From: memsvcs at arin.net (Member Services) Date: Tue, 18 Nov 2003 14:11:17 -0500 (EST) Subject: [ppml] Last Call for Comment: Policy Proposal 2003-15 Message-ID: <200311181911.OAA17423@ops.arin.net> The ARIN Advisory Council voted to forward the following policy proposal to the ARIN Board of Trustees for consideration. This is a last call for comments on this policy proposal prior to the ARIN Board of Trustees review. Comments received during this period will be included with the proposal when it is presented to the Board of Trustees for their consideration. Please send your comments to ppml at arin.net. This last call will expire at 23:59 EST on December 3, 2003. Member Services American Registry for Internet Numbers (ARIN) *** Last Call: Policy Proposal 2003-15: IPv4 Allocation Policy for the Africa Portion of the ARIN Region *** 1. Minimum Allocation. The minimum allocation size for ISPs from the African portion of the ARIN region is /22. 2. Allocation Criteria. a. The requesting organization must show the efficient utilization of an entire previously allocated /22 from their upstream ISP. This allocation (/22) may have been provided by an ISP's upstream provider(s), and does not have to be contiguous address space. The organization must meet the requirement of efficient use of 4 /24s. b. A multi-homed organization must show the efficient utilization of an entire previously allocated /23 from their upstream ISP. This allocation (/23) may have been provided by an ISP's upstream provider(s), and does not have to be contiguous address space. The organization must meet the requirement of efficient use of 2 /24s. 3. Utilization Reporting and Justification. All other ARIN policies regarding the reporting of justification information for the allocation of IPv4 address space will remain in effect. ********************************************************** Discussion: This proposal is the result of the discussion and agreement of those ISPs in the ARIN region that were in attendance at the AfriNIC meeting held in Johannesburg, South Africa, on September 17, 2003. This policy proposal is submitted with the intent it only be applied to the Africa portion of the ARIN region, i.e., those countries in Africa that are in the ARIN region. It is proposed the minimum allocation criteria and minimum allocation size for ISPs in Africa be modified. Specifically, the following modifications to IPv4 policy are proposed: 1. Change the minimum allocation size from a /20 to /22. 2. Change the ISP criteria for obtaining an allocation to the following. CRITERIA POINT 1 Current Criteria: The current IPv4 policy for ISPs calls for "the efficient utilization of an entire previously allocated /20 from their upstream ISP" in order to qualify for a /20 allocation from ARIN. Proposed Criteria: It is proposed the IPv4 policy for ISPs call for "the efficient utilization of an entire previously allocated /22 from their upstream ISP" in order to qualify for a /22 allocation from ARIN. CRITERIA POINT 2 Current Criteria: The current IPv4 multi-homed policy states "Multi-homed organizations that have efficiently utilized a /21 may be allocated a /20." Proposed Criteria: It is proposed the IPv4 multi- homed policy state that, "Multi-homed organizations that have efficiently utilized a /23 may be allocated a /22." Due to the emerging nature of Internet services in Africa and the economic environment, it is often not possible for ISPs to meet the current ARIN criteria for the smallest allocation size of a /20, or to obtain the IPv4 address space they need from an upstream provider in their area of operation. It is due to these reasons, and others listed below, that this proposal is submitted. Arguments for Policy Change * The economies of Africa and those of other countries in the ARIN region (United States and Canada) are not of the same scale. The number of Internet users inside Africa is much fewer than in the other countries in the ARIN region. Whereas it may be reasonable to expect that the user numbers in North America support an ISP's ability to meet the current ARIN IPv4 criteria, it is not reasonable in Africa. * Unable to meet the current criteria to obtain IPv4 address space from ARIN, and unable to obtain adequate address space from upstream providers; African ISPs must resort to solutions such as NAT, or sometimes are simply not able to provide services to customers due to the lack of IPv4 address space. Lack of adequate IPv4 address space may be slowing down the growth and development of the Internet in Africa. Proposed Timetable for Implementation It is requested this policy proposal be discussed on the ARIN public policy mailing list and at the ARIN public policy meeting in October 2003. It is further requested this policy proposal receive immediate attention of the ARIN Advisory Council and Board of Trustees following the October 2003 meeting for implementation before the close of the 2003 calendar year. Implementation of this policy change is critical to the growth and development of the Internet in the Africa portion of the ARIN region. ## END ## From memsvcs at arin.net Tue Nov 18 14:15:47 2003 From: memsvcs at arin.net (Member Services) Date: Tue, 18 Nov 2003 14:15:47 -0500 (EST) Subject: [ppml] Last Call for Comment: New ARIN Internet Resource Policy Evaluation Process Draft Message-ID: <200311181915.OAA18253@ops.arin.net> This is a last call for comments on the new ARIN Internet Resource Policy Evaluation Process draft. This draft takes into account comments made on the mailing list and at the previous two Public Policy Meetings. Comments received during this period will be presented to the Board of Trustees for their consideration. The new ARIN Internet Resource Policy Evaluation Process draft is available at the following url: http://www.arin.net/policy/draft_irpep.html Please send your comments to ppml at arin.net. This last call will expire at 23:59 EST on December 3, 2003. Member Services American Registry for Internet Numbers (ARIN) From memsvcs at arin.net Tue Nov 18 14:07:49 2003 From: memsvcs at arin.net (Member Services) Date: Tue, 18 Nov 2003 14:07:49 -0500 (EST) Subject: [ppml] Last Call for Comment: Policy Proposal 2003-5 Message-ID: <200311181907.OAA17005@ops.arin.net> The ARIN Advisory Council voted to forward the following policy proposal to the ARIN Board of Trustees for consideration. This is a last call for comments on this policy proposal prior to the ARIN Board of Trustees review. Comments received during this period will be included with the proposal when it is presented to the Board of Trustees for their consideration. Please send your comments to ppml at arin.net. This last call will expire at 23:59 EST on December 3, 2003. Member Services American Registry for Internet Numbers (ARIN) *** Last Call: Policy Proposal 2003-5: Distributed Information Server Use Requirements *** Background: RWhois, a distributed lookup service, was created in part to allow ISPs locally operate and control their own reassignment information. The purpose of placing this data in a RWhois server was two-fold: 1) Allow RIR staff to examine reassignment utilization 2) Allow access to the general public on reassignment information. Many ISPs have opted to use RWhois servers for their reassignment information over sending SWIPs to ARIN. But some of the ISPs who have selected to use RWhois servers for their reassignment information have not kept the servers operational 24x7, contents of the database up to-date, or are restricting access only to ARIN staff. This lack of a uniform set of operations of RWhois servers has resulted in confusion for end-users and ARIN staff. The following policy proposal will describe the set of minimal requirements of operating a RWhois server for those ISPs who decide to use RWhois to manage their IP reassignment information. In the future, there may be other distributed lookup services that ARIN may allow ISPs to use. These new services must be approved by ARIN before being allowed to serve as a repository for reassignment information. Policy Proposal: The proposed minimal requirements for an organization to setup a distributed information service to advertise reassignment information are: The distributed information service must be operational 24 hours a day, 7 days a week to both the general public and ARIN staff. The service is allowed reasonable downtime for server maintenance according to generally accepted community standards. The distributed information service must allow public access to reassignment information. The service may restrict the number of queries allowed per time interval from a host or subnet to defend against DDOS attacks, remote mirroring attempts, and other nefarious acts. The distributed information service must return reassignment information for the IP address queried. The service may allow for privacy protections for customers. Minimally, the service must provide only the person's name, city, state, zip code, and country. The service shall follow ARIN's privacy policy for publishing data in a public forum. The distributed information service may return results for non-IP queries. The distributed information service must respond to a query with the minimal set of attributes per object as defined by ARIN staff. The distributed information service may include optional attributes per object that are defined locally. The distributed information service must return results that are up-to-date on reassignment information. Public Policy Mailing List Discussion Summary There was no discussion about this proposal on PPML since the current version was posted. ## END ## From memsvcs at arin.net Tue Nov 18 14:05:34 2003 From: memsvcs at arin.net (Member Services) Date: Tue, 18 Nov 2003 14:05:34 -0500 (EST) Subject: [ppml] Last Call for Comment: Policy Proposal 2002-3 Message-ID: <200311181905.OAA16387@ops.arin.net> The ARIN Advisory Council voted to forward the following policy proposal to the ARIN Board of Trustees for consideration. This is a last call for comments on this policy proposal prior to the ARIN Board of Trustees review. Comments received during this period will be included with the proposal when it is presented to the Board of Trustees for their consideration. Please send your comments to ppml at arin.net. This last call will expire at 23:59 EST on December 3, 2003. Member Services American Registry for Internet Numbers (ARIN) *** Last Call: Policy Proposal 2002-3: Micro-Assignments for Multihomed Networks *** Multi-homed organizations may justify and obtain a block of address space with prefix length extending to /22 directly from ARIN. When prefixes are longer than /20, these micro-allocations or micro-assignments will be from a reserved block for that purpose. ## END ## From memsvcs at arin.net Tue Nov 18 14:07:05 2003 From: memsvcs at arin.net (Member Services) Date: Tue, 18 Nov 2003 14:07:05 -0500 (EST) Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 Message-ID: <200311181907.OAA16767@ops.arin.net> The ARIN Advisory Council voted to forward the following policy proposal to the ARIN Board of Trustees for consideration. This is a last call for comments on this policy proposal prior to the ARIN Board of Trustees review. Comments received during this period will be included with the proposal when it is presented to the Board of Trustees for their consideration. Please send your comments to ppml at arin.net. This last call will expire at 23:59 EST on December 3, 2003. Member Services American Registry for Internet Numbers (ARIN) *** Last Call: Policy Proposal 2003-3: Residential Customer Privacy *** An organization with downstream residential customers may substitute that organization's name for the customer's name, e.g. 'Private customer - XYZ Network', and the customer's street address may read 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block. ## END ## From memsvcs at arin.net Tue Nov 18 14:09:14 2003 From: memsvcs at arin.net (Member Services) Date: Tue, 18 Nov 2003 14:09:14 -0500 (EST) Subject: [ppml] Last Call for Comment: Policy Proposal 2003-13 Message-ID: <200311181909.OAA17169@ops.arin.net> The ARIN Advisory Council voted to forward the following policy proposal to the ARIN Board of Trustees for consideration. This is a last call for comments on this policy proposal prior to the ARIN Board of Trustees review. Comments received during this period will be included with the proposal when it is presented to the Board of Trustees for their consideration. Please send your comments to ppml at arin.net. This last call will expire at 23:59 EST on December 3, 2003. Member Services American Registry for Internet Numbers (ARIN) *** Last Call: Policy Proposal 2003-13: Six Month Supply of IP Addresses *** Proposal to allow members to choose to work on a 6-month cycle. After a subscriber has been a member of ARIN for one year they may choose to request a 6 month supply of IP addresses. ######################################## Discussion of the proposal by Michael Dillon: This is basically intended to reduce some of the administrative burden at both the subscriber/member and at ARIN. It means that members can choose to have, on average, two interactions with ARIN per year rather than 4. There is some benefit to the community in forcing newcomers to interact every 3 months because of the need to learn and gain experience, but beyond the first year, we should let people have more flexibility. This will also allow larger members with more bureaucratic internal processes to avoid internal address shortage crises. I have mentioned this on the ppml list before in the following paragraph: Here's what I mean. If your goal was to maximize the efficiency of address assignment, then you would eventually reach an upper limit for every netblock beyond which you can't improve efficiency. I'm assuming that is greater than 80% utilization. That means that when you reach 80% on your last netblock, you have already used up all possible addresses on previous netblocks so that you only have the last 20% of the most recent netblock to allocate. In fact, you probably have less than 20% because it is not possible to assign IPv4 addresses to 100% efficiency. Assuming that the allocation is based on 3 months of usage, i.e. 13 weeks, this means that you have no more than 2.6 weeks supply of addresses left when you submit your ARIN application. The .6 weeks will be used up by ARIN's 2-3 business days of turnaround time so you will only have 2 weeks to get these new addresses into your systems. The people who do this work also do other planned and break-fix operational work so they can't be expected to just drop everything and handle these new IP addresses every time. Timetable for implementation I suggest that this proposal should be implemented within 30 days of a decision by a members meeting. ## END ## From memsvcs at arin.net Tue Nov 18 14:08:28 2003 From: memsvcs at arin.net (Member Services) Date: Tue, 18 Nov 2003 14:08:28 -0500 (EST) Subject: [ppml] Last Call for Comment: Policy Proposal 2003-12 Message-ID: <200311181908.OAA17068@ops.arin.net> The ARIN Advisory Council voted to forward the following policy proposal to the ARIN Board of Trustees for consideration. This is a last call for comments on this policy proposal prior to the ARIN Board of Trustees review. Comments received during this period will be included with the proposal when it is presented to the Board of Trustees for their consideration. Please send your comments to ppml at arin.net. This last call will expire at 23:59 EST on December 3, 2003. Member Services American Registry for Internet Numbers (ARIN) *** Last Call: Policy Proposal 2003-12: IANA to RIR Allocation of IPv4 Address Space *** IANA to RIR Allocation of IPv4 Address Space This document describes the policies governing the allocation of IPv4 address space from the IANA to the Regional Internet Registries (RIRs). This document does not stipulate performance requirements in the provision of services by IANA to an RIR in accordance with these policies. Such requirements should be specified by appropriate agreements among the RIRs and ICANN. 1. Allocation Principles - The IANA will allocate IPv4 address space to the RIRs in /8 units. - The IANA will allocate sufficient IPv4 address space to the RIRs to support their registration needs for at least an 18 month period. - The IANA will allow for the RIRs to apply their own respective chosen allocation and reservation strategies in order to ensure the efficiency and efficacy of their work. 2. Initial Allocations Each new RIR shall, at the moment of recognition, be allocated a new /8 by the IANA. This allocation will be made regardless of the newly formed RIR's projected utilization figures and shall be independent of the IPv4 address space that may have been transferred to the new RIR by the already existing RIRs as part of the formal transition process. 3. Additional Allocations A RIR is eligible to receive additional IPv4 address space from the IANA when either of the following conditions are met. - The RIR's AVAILABLE SPACE of IPv4 addresses is less than 50% of a /8 block. - The RIR's AVAILABLE SPACE of IPv4 addresses is less than its established NECESSARY SPACE for the following 9 months. In either case, IANA shall make a single allocation of a whole number of /8 blocks, sufficient to satisfy the established NECESSARY SPACE of the RIR for an 18 month period. 3.1 Calculation of AVAILABLE SPACE The AVAILABLE SPACE of IPv4 addresses of a RIR shall be determined as follows: AVAILABLE SPACE = CURRENTLY FREE ADDRESSES + RESERVATIONS EXPIRING DURING THE FOLLOWING 3 MONTHS - FRAGMENTED SPACE FRAGMENTED SPACE is determined as the total amount of available blocks smaller than the RIR's minimum allocation size within the RIR's currently available stock. 3.2 Calculation of NECESSARY SPACE If the applying Regional Internet Registry does not establish any special needs for the period concerned, NECESSARY SPACE shall be determined as follows: NECESSARY SPACE = AVERAGE NUMBER OF ADDRESSES ALLOCATED MONTHLY DURING THE PAST 6 MONTHS * LENGTH OF PERIOD IN MONTHS If the applying RIR anticipates that due to certain special needs the rate of allocation for the period concerned will be greater than the previous 6 months, it may determine its NECESSARY SPACE as follows: A) Calculate NECESSARY SPACE as its total needs for that period according to its projection and based on the special facts that justify these needs. B) Submit a clear and detailed justification of the above mentioned projection (Item A). If the justification is based on the allocation tendency prepared by the Regional Internet Registry, data explaining said tendency must be enclosed. If the justification is based on the application of one or more of the Regional Internet Registry's new allocation policies, an impact analysis of the new policy/policies must be enclosed. If the justification is based on external factors such as new infrastructure, new services within the region, technological advances or legal issues, the corresponding analysis must be enclosed together with references to information sources that will allow verification of the data. If IANA does not have elements that clearly question the Regional Internet Registry's projection, the special needs projected for the following 18 months, indicated in Item A above, shall be considered valid. 4. Announcement of IANA Allocations When address space is allocated to a RIR, the IANA will send a detailed announcement to the receiving RIR. The IANA will also make announcements to all other RIRs, informing them of the recent allocation. The RIRs will coordinate announcements to their respective membership lists and any other lists they deem necessary. The IANA will make appropriate modifications to the "Internet Protocol V4 Address Space" page of the IANA website and may make announcements to its own appropriate announcement lists. The IANA announcements will be limited to which address ranges, the time of allocation and to which Registry they have been allocated. Public Policy Mailing List Discussion Summary There were two posts on PPML regarding this proposal; the three following paragraphs are from that discussion. This is a global policy proposal to define the policies under which the IANA will allocate IPv4 address space to the Regional Internet Registries (RIR). It has already appeared on the public policy agendas of the APNIC and RIPE NCC meetings. This policy proposal will also be discussed at the next LACNIC public policy meeting. Following discussion in all four regions, the proposal and discussion results will be forwarded to the ICANN ASO Address Council for review and submittal to the ICANN Board, as it is considered a global policy proposal. ## END ## From memsvcs at arin.net Tue Nov 18 14:10:14 2003 From: memsvcs at arin.net (Member Services) Date: Tue, 18 Nov 2003 14:10:14 -0500 (EST) Subject: [ppml] Last Call for Comment: Policy Proposal 2003-14 Message-ID: <200311181910.OAA17255@ops.arin.net> The ARIN Advisory Council voted to forward the following policy proposal to the ARIN Board of Trustees for consideration. This is a last call for comments on this policy proposal prior to the ARIN Board of Trustees review. Comments received during this period will be included with the proposal when it is presented to the Board of Trustees for their consideration. Please send your comments to ppml at arin.net. This last call will expire at 23:59 EST on December 3, 2003. Member Services American Registry for Internet Numbers (ARIN) *** Last Call: Policy Proposal 2003-14: Remove /13 Maximum Allocation *** Proposal to remove the maximum allocation statement from the current policy. ######################################## Discussion of the proposal: The statement is as follows. "ARIN allocates IP address prefixes no longer than /20. If allocations smaller than /20 are needed, ISPs should request address space from their upstream provider. The largest prefix ARIN allocates is a /13." By removing the statement, the policy would simply read, "ARIN allocates IP address prefixes no longer than /20. If allocations smaller than /20 are needed, ISPs should request address space from their upstream provider." By making this change, ARIN is provided greater flexibility to accommodate special situations that may come up with larger ISP. Some ISP are required to maintain multiple accounts to accommodate the growth of their networks. The policy also imposes the burden of having to create additional accounts when large transfers or acquisitions occur. The removal of this statement in no way changes the review process or the requirements by which ARIN allocates address space. If an application were submitted to ARIN for address space greater than a /13 it would be up to ARIN to review the request and approve or deny the application based on the legitimacy of the data. One final justification would be that no other Internet Registries found a need to implement a similar policy. Given the policies in place that provide ARIN with the tools to responsibly manage the limited address space. The current policy only limits ARIN's ability to better service the needs of its member organizations. Public Policy Mailing List Discussion Summary There were no comments posted to PPML regarding this proposal. ## END ## From owen at delong.com Tue Nov 18 16:13:11 2003 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Nov 2003 13:13:11 -0800 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 In-Reply-To: <200311181907.OAA16767@ops.arin.net> References: <200311181907.OAA16767@ops.arin.net> Message-ID: <2147483647.1069161191@dhcp157-233.corp.tellme.com> I still think this policy is a bad idea. I still think if anyone wants enough address space to get swipped (a /29 or larger), there's no reason they can't remain accountable for that address space. There are already multiple options for said person to protect their personal privacy: P.O. Boxes, Company Names (it's really easy to create a schedule C company) etc. This policy just serves to further allow for SPAMMERS to get anonymous IP blocks. Owen --On Tuesday, November 18, 2003 14:07 -0500 Member Services wrote: > The ARIN Advisory Council voted to forward the following policy > proposal to the ARIN Board of Trustees for consideration. > > This is a last call for comments on this policy proposal prior > to the ARIN Board of Trustees review. Comments received during > this period will be included with the proposal when it is presented > to the Board of Trustees for their consideration. > > Please send your comments to ppml at arin.net. This last call will > expire at 23:59 EST on December 3, 2003. > > > Member Services > American Registry for Internet Numbers (ARIN) > > > *** Last Call: Policy Proposal 2003-3: Residential Customer Privacy *** > > An organization with downstream residential customers may substitute > that organization's name for the customer's name, e.g. 'Private > customer - XYZ Network', and the customer's street address may read > 'Private Residence'. Each private downstream residential reassignment > must have accurate upstream Abuse and Technical POCs visible on the > WHOIS record for that block. > >## END ## -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Tue Nov 18 16:15:03 2003 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Nov 2003 13:15:03 -0800 Subject: [ppml] Last Call for Comment: Policy Proposal 2002-3 In-Reply-To: <200311181905.OAA16387@ops.arin.net> References: <200311181905.OAA16387@ops.arin.net> Message-ID: <2147483647.1069161303@dhcp157-233.corp.tellme.com> As is well known by now, I fully support this policy and look forward to it's implementation. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Rob.Vinson at networktelephone.net Tue Nov 18 17:09:13 2003 From: Rob.Vinson at networktelephone.net (Rob Vinson) Date: Tue, 18 Nov 2003 16:09:13 -0600 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-13 Message-ID: I like the sound of this one. I assume by this you mean getting a /19 at a time instead? Having recently received another /20, I can say it was the lengthiest review I've been through (my 5th one). We were at 88% allocated when I sent the initial email and it took 3 weeks of going back and forth. I in fact did run out of IP's while waiting for my request to be approved (we were doing a new product rollout). Oh the joy of trying to explain that one to the board and non-savvy VP's! We are also discussing a network-wide IP redesign. Internal allocations when we were young weren't as efficient as what's being done now and a /19 would give me the room to maneuver and clean up the routing tables. Anyhow my $.02 - thx ___________________________________________ Rob V >>> Network Design rob.vinson at networktelephone.net 888.432.4855 -----Original Message----- From: Member Services [mailto:memsvcs at arin.net] Sent: Tuesday, November 18, 2003 1:09 PM To: ppml at arin.net Subject: [ppml] Last Call for Comment: Policy Proposal 2003-13 The ARIN Advisory Council voted to forward the following policy proposal to the ARIN Board of Trustees for consideration. This is a last call for comments on this policy proposal prior to the ARIN Board of Trustees review. Comments received during this period will be included with the proposal when it is presented to the Board of Trustees for their consideration. Please send your comments to ppml at arin.net. This last call will expire at 23:59 EST on December 3, 2003. Member Services American Registry for Internet Numbers (ARIN) *** Last Call: Policy Proposal 2003-13: Six Month Supply of IP Addresses *** Proposal to allow members to choose to work on a 6-month cycle. After a subscriber has been a member of ARIN for one year they may choose to request a 6 month supply of IP addresses. ######################################## Discussion of the proposal by Michael Dillon: This is basically intended to reduce some of the administrative burden at both the subscriber/member and at ARIN. It means that members can choose to have, on average, two interactions with ARIN per year rather than 4. There is some benefit to the community in forcing newcomers to interact every 3 months because of the need to learn and gain experience, but beyond the first year, we should let people have more flexibility. This will also allow larger members with more bureaucratic internal processes to avoid internal address shortage crises. I have mentioned this on the ppml list before in the following paragraph: Here's what I mean. If your goal was to maximize the efficiency of address assignment, then you would eventually reach an upper limit for every netblock beyond which you can't improve efficiency. I'm assuming that is greater than 80% utilization. That means that when you reach 80% on your last netblock, you have already used up all possible addresses on previous netblocks so that you only have the last 20% of the most recent netblock to allocate. In fact, you probably have less than 20% because it is not possible to assign IPv4 addresses to 100% efficiency. Assuming that the allocation is based on 3 months of usage, i.e. 13 weeks, this means that you have no more than 2.6 weeks supply of addresses left when you submit your ARIN application. The .6 weeks will be used up by ARIN's 2-3 business days of turnaround time so you will only have 2 weeks to get these new addresses into your systems. The people who do this work also do other planned and break-fix operational work so they can't be expected to just drop everything and handle these new IP addresses every time. Timetable for implementation I suggest that this proposal should be implemented within 30 days of a decision by a members meeting. ## END ## From Stacy_Taylor at icgcomm.com Tue Nov 18 17:34:59 2003 From: Stacy_Taylor at icgcomm.com (Taylor, Stacy) Date: Tue, 18 Nov 2003 15:34:59 -0700 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 Message-ID: <5BDB545714D0764F8452CC5A25DDEEFA04DAE5AF@denexg21.icgcomm.com> Hi All, I disagree with Owen and heartily endorse this proposal. The onus of keeping these blocks abuse-free still lies with the upstream provider, who runs the risk of a blacklisted block if there is a spammer on it. My Mother's name and address should not be listed in the ARIN database. My college-aged daughter's name and address should not be listed in the ARIN database. XO /S -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Tuesday, November 18, 2003 1:13 PM To: ppml at arin.net Subject: Re: [ppml] Last Call for Comment: Policy Proposal 2003-3 I still think this policy is a bad idea. I still think if anyone wants enough address space to get swipped (a /29 or larger), there's no reason they can't remain accountable for that address space. There are already multiple options for said person to protect their personal privacy: P.O. Boxes, Company Names (it's really easy to create a schedule C company) etc. This policy just serves to further allow for SPAMMERS to get anonymous IP blocks. Owen --On Tuesday, November 18, 2003 14:07 -0500 Member Services wrote: > The ARIN Advisory Council voted to forward the following policy > proposal to the ARIN Board of Trustees for consideration. > > This is a last call for comments on this policy proposal prior > to the ARIN Board of Trustees review. Comments received during > this period will be included with the proposal when it is presented > to the Board of Trustees for their consideration. > > Please send your comments to ppml at arin.net. This last call will > expire at 23:59 EST on December 3, 2003. > > > Member Services > American Registry for Internet Numbers (ARIN) > > > *** Last Call: Policy Proposal 2003-3: Residential Customer Privacy *** > > An organization with downstream residential customers may substitute > that organization's name for the customer's name, e.g. 'Private > customer - XYZ Network', and the customer's street address may read > 'Private Residence'. Each private downstream residential reassignment > must have accurate upstream Abuse and Technical POCs visible on the > WHOIS record for that block. > >## END ## -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. From bicknell at ufp.org Tue Nov 18 18:03:17 2003 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 18 Nov 2003 18:03:17 -0500 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 In-Reply-To: <2147483647.1069161191@dhcp157-233.corp.tellme.com> References: <200311181907.OAA16767@ops.arin.net> <2147483647.1069161191@dhcp157-233.corp.tellme.com> Message-ID: <20031118230316.GA60238@ussenterprise.ufp.org> In a message written on Tue, Nov 18, 2003 at 01:13:11PM -0800, Owen DeLong wrote: > This policy just serves to further allow for SPAMMERS to get anonymous > IP blocks. There is a small, but vocal minority that wants to assert this claim. The real problem here is no one can point to hard data that supports this claim. That's no surprise now, since this is a brand new policy change. However, I strongly suggest that if the people who think this is a problem want to have any chance of changing it in the future then efforts should be made by the appropriate groups to try and track if there is an increase in spam from "anonymous" IP blocks. A much more interesting second order problem would be to track if complaints to the upstream parent of these "anonymous" blocks are more or less effective, on the average, than complaints directly to the block owner. That may be too hard to do, though. I highly doubt this will make any measurable change in fighting spam. Yes, it means you'll go directly to the upstream, rather than the end user, but I suspect that will be better in as many cases as it is worse. What I suspect happens now is some spammers are listed in whois. By receiving the complaints directly they can use that feedback to tailor their runs to not generate alarms. They can also reply to the direct complaints in a way that seems like action is being taken without actually doing anything, delaying the anti-spam services from declaring them a spammer. Without them listed the complaints will go directly to the upstream who can disconnect them without giving them the feedback loop, and (at least in a few cases) without the runaround. Back to my original point. Track it. Prove it. If in 6 months you can offer hard data spam has increased by a reasonable amount from these netblocks I'll be the first to consider changing my views. Without that data I won't. I suspect others are in the same boat. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From Stacy_Taylor at icgcomm.com Tue Nov 18 18:08:26 2003 From: Stacy_Taylor at icgcomm.com (Taylor, Stacy) Date: Tue, 18 Nov 2003 16:08:26 -0700 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 Message-ID: <5BDB545714D0764F8452CC5A25DDEEFA04DAE5B0@denexg21.icgcomm.com> Well said, Leo! XO /S -----Original Message----- From: Leo Bicknell [mailto:bicknell at ufp.org] Sent: Tuesday, November 18, 2003 3:03 PM To: ppml at arin.net Subject: Re: [ppml] Last Call for Comment: Policy Proposal 2003-3 In a message written on Tue, Nov 18, 2003 at 01:13:11PM -0800, Owen DeLong wrote: > This policy just serves to further allow for SPAMMERS to get anonymous > IP blocks. There is a small, but vocal minority that wants to assert this claim. The real problem here is no one can point to hard data that supports this claim. That's no surprise now, since this is a brand new policy change. However, I strongly suggest that if the people who think this is a problem want to have any chance of changing it in the future then efforts should be made by the appropriate groups to try and track if there is an increase in spam from "anonymous" IP blocks. A much more interesting second order problem would be to track if complaints to the upstream parent of these "anonymous" blocks are more or less effective, on the average, than complaints directly to the block owner. That may be too hard to do, though. I highly doubt this will make any measurable change in fighting spam. Yes, it means you'll go directly to the upstream, rather than the end user, but I suspect that will be better in as many cases as it is worse. What I suspect happens now is some spammers are listed in whois. By receiving the complaints directly they can use that feedback to tailor their runs to not generate alarms. They can also reply to the direct complaints in a way that seems like action is being taken without actually doing anything, delaying the anti-spam services from declaring them a spammer. Without them listed the complaints will go directly to the upstream who can disconnect them without giving them the feedback loop, and (at least in a few cases) without the runaround. Back to my original point. Track it. Prove it. If in 6 months you can offer hard data spam has increased by a reasonable amount from these netblocks I'll be the first to consider changing my views. Without that data I won't. I suspect others are in the same boat. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org From owen at delong.com Tue Nov 18 18:20:15 2003 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Nov 2003 15:20:15 -0800 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 In-Reply-To: <5BDB545714D0764F8452CC5A25DDEEFA04DAE5AF@denexg21.icgcomm.com> References: <5BDB545714D0764F8452CC5A25DDEEFA04DAE5AF@denexg21.icgcomm.com> Message-ID: <2147483647.1069168815@dhcp157-233.corp.tellme.com> Stacy, Note that this policy has no size limit, so, depending on the "residential" customer and the willingness of the upstream to condone abuse and risk blacklisting, it doesn't put much of an onus. As written, it is a blank check for abuse. Owen --On Tuesday, November 18, 2003 15:34 -0700 "Taylor, Stacy" wrote: > Hi All, > > I disagree with Owen and heartily endorse this proposal. > > The onus of keeping these blocks abuse-free still lies with the upstream > provider, who runs the risk of a blacklisted block if there is a spammer > on it. > My Mother's name and address should not be listed in the ARIN database. > My college-aged daughter's name and address should not be listed in the > ARIN database. > > XO > /S > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Tuesday, November 18, 2003 1:13 PM > To: ppml at arin.net > Subject: Re: [ppml] Last Call for Comment: Policy Proposal 2003-3 > > > I still think this policy is a bad idea. I still think if anyone wants > enough address space to get swipped (a /29 or larger), there's no reason > they can't remain accountable for that address space. There are already > multiple options for said person to protect their personal privacy: > > P.O. Boxes, > Company Names (it's really easy to create a schedule C company) > etc. > > This policy just serves to further allow for SPAMMERS to get anonymous > IP blocks. > > Owen > > > > --On Tuesday, November 18, 2003 14:07 -0500 Member Services > wrote: > >> The ARIN Advisory Council voted to forward the following policy >> proposal to the ARIN Board of Trustees for consideration. >> >> This is a last call for comments on this policy proposal prior >> to the ARIN Board of Trustees review. Comments received during >> this period will be included with the proposal when it is presented >> to the Board of Trustees for their consideration. >> >> Please send your comments to ppml at arin.net. This last call will >> expire at 23:59 EST on December 3, 2003. >> >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> *** Last Call: Policy Proposal 2003-3: Residential Customer Privacy *** >> >> An organization with downstream residential customers may substitute >> that organization's name for the customer's name, e.g. 'Private >> customer - XYZ Network', and the customer's street address may read >> 'Private Residence'. Each private downstream residential reassignment >> must have accurate upstream Abuse and Technical POCs visible on the >> WHOIS record for that block. >> >>## END ## -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From jsw at five-elements.com Tue Nov 18 18:35:49 2003 From: jsw at five-elements.com (Jeff S Wheeler) Date: Tue, 18 Nov 2003 18:35:49 -0500 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 In-Reply-To: <20031118230316.GA60238@ussenterprise.ufp.org> References: <200311181907.OAA16767@ops.arin.net> <2147483647.1069161191@dhcp157-233.corp.tellme.com> <20031118230316.GA60238@ussenterprise.ufp.org> Message-ID: <1069198549.732.1790.camel@intrepid.jsw.louisville.ky.us> On Tue, 2003-11-18 at 18:03, Leo Bicknell wrote: > What I suspect happens now is some spammers are listed in whois. > By receiving the complaints directly they can use that feedback to > tailor their runs to not generate alarms. They can also reply to > the direct complaints in a way that seems like action is being taken > without actually doing anything, delaying the anti-spam services > from declaring them a spammer. Without them listed the complaints > will go directly to the upstream who can disconnect them without > giving them the feedback loop, and (at least in a few cases) without > the runaround. As someone with direct experience in this field, I can state with some authority that spammers would much rather have complaints go directly to them than to their upstream transit providers. If a transit provider is a willing party to spam, as Owen DeLong states would be necessary to take advantage of 2003-3, that transitor expends resources to direct the complaints they receive to the customer responsible for the address space. 2003-3 will not have any appreciable impact on spam, because it is not to the spammers' advantage to direct complaints to their vendors. I'll leave it up to the readers to decide whether or not they would prefer to complain to transitors or spammers directly, but I do not believe any spammers will take advantage of this policy in the manner that has been suggested by Owen DeLong. Whether or not spammers actually take corrective action upon receipt of whois-based complaints depends entirely upon the level of organization of the spam shop, and their motives. However, it is usually a waste of time to complain to transitors who have already made the decision to condone spamming on their network. If the end-user of the address space is published, then complain to them. If you are dissatisfied with the results, then the blacklisting organizations are a better resource than abuse at transitor, who will either /dev/null your complaints; or simply forward them to the end-user again. -- Jeff S Wheeler From marla_azinger at eli.net Tue Nov 18 18:41:33 2003 From: marla_azinger at eli.net (Azinger, Marla) Date: Tue, 18 Nov 2003 15:41:33 -0800 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 Message-ID: <5BD887EB4A582A439038636F7A93A5A701E5A2C1@wava00s2kexch01.corp.pvt> I dont take this as a way to stop spam really....but I do feel that unless your customer falls into a dial pool or DSL pool of some sort that they should have to have their info swiped on WHOIS so that any abuse issues coming from their usage can be handled directly with that user first before getting the upstream provider involved. Marla ELI FRONTIER CITIZENS -----Original Message----- From: Taylor, Stacy [mailto:Stacy_Taylor at icgcomm.com] Sent: Tuesday, November 18, 2003 2:35 PM To: 'Owen DeLong'; ppml at arin.net Subject: RE: [ppml] Last Call for Comment: Policy Proposal 2003-3 Hi All, I disagree with Owen and heartily endorse this proposal. The onus of keeping these blocks abuse-free still lies with the upstream provider, who runs the risk of a blacklisted block if there is a spammer on it. My Mother's name and address should not be listed in the ARIN database. My college-aged daughter's name and address should not be listed in the ARIN database. XO /S -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Tuesday, November 18, 2003 1:13 PM To: ppml at arin.net Subject: Re: [ppml] Last Call for Comment: Policy Proposal 2003-3 I still think this policy is a bad idea. I still think if anyone wants enough address space to get swipped (a /29 or larger), there's no reason they can't remain accountable for that address space. There are already multiple options for said person to protect their personal privacy: P.O. Boxes, Company Names (it's really easy to create a schedule C company) etc. This policy just serves to further allow for SPAMMERS to get anonymous IP blocks. Owen --On Tuesday, November 18, 2003 14:07 -0500 Member Services wrote: > The ARIN Advisory Council voted to forward the following policy > proposal to the ARIN Board of Trustees for consideration. > > This is a last call for comments on this policy proposal prior > to the ARIN Board of Trustees review. Comments received during > this period will be included with the proposal when it is presented > to the Board of Trustees for their consideration. > > Please send your comments to ppml at arin.net. This last call will > expire at 23:59 EST on December 3, 2003. > > > Member Services > American Registry for Internet Numbers (ARIN) > > > *** Last Call: Policy Proposal 2003-3: Residential Customer Privacy *** > > An organization with downstream residential customers may substitute > that organization's name for the customer's name, e.g. 'Private > customer - XYZ Network', and the customer's street address may read > 'Private Residence'. Each private downstream residential reassignment > must have accurate upstream Abuse and Technical POCs visible on the > WHOIS record for that block. > >## END ## -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. From john at chagres.net Tue Nov 18 19:26:55 2003 From: john at chagres.net (John Brown) Date: Tue, 18 Nov 2003 17:26:55 -0700 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 In-Reply-To: <5BDB545714D0764F8452CC5A25DDEEFA04DAE5AF@denexg21.icgcomm.com>; from Stacy_Taylor@icgcomm.com on Tue, Nov 18, 2003 at 03:34:59PM -0700 References: <5BDB545714D0764F8452CC5A25DDEEFA04DAE5AF@denexg21.icgcomm.com> Message-ID: <20031118172655.A39457@alderaan.chagres.net> And why would your mother or daughter need more than a single IP address ?? Owen's comment was if its SWIP'd it should have valid contact data. Which I agree with. Pushing the problem to the service provider doesn't work. Many Many service providers do not respond to abuse complaints. And only if you happen to be in the "right club" do you get any sort of response. On Tue, Nov 18, 2003 at 03:34:59PM -0700, Taylor, Stacy wrote: > Hi All, > > I disagree with Owen and heartily endorse this proposal. > > The onus of keeping these blocks abuse-free still lies with the upstream > provider, who runs the risk of a blacklisted block if there is a spammer on > it. > My Mother's name and address should not be listed in the ARIN database. My > college-aged daughter's name and address should not be listed in the ARIN > database. > > XO > /S > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Tuesday, November 18, 2003 1:13 PM > To: ppml at arin.net > Subject: Re: [ppml] Last Call for Comment: Policy Proposal 2003-3 > > > I still think this policy is a bad idea. I still think if anyone wants > enough address space to get swipped (a /29 or larger), there's no reason > they can't remain accountable for that address space. There are already > multiple options for said person to protect their personal privacy: > > P.O. Boxes, > Company Names (it's really easy to create a schedule C company) > etc. > > This policy just serves to further allow for SPAMMERS to get anonymous > IP blocks. > > Owen > > > > --On Tuesday, November 18, 2003 14:07 -0500 Member Services > wrote: > > > The ARIN Advisory Council voted to forward the following policy > > proposal to the ARIN Board of Trustees for consideration. > > > > This is a last call for comments on this policy proposal prior > > to the ARIN Board of Trustees review. Comments received during > > this period will be included with the proposal when it is presented > > to the Board of Trustees for their consideration. > > > > Please send your comments to ppml at arin.net. This last call will > > expire at 23:59 EST on December 3, 2003. > > > > > > Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > *** Last Call: Policy Proposal 2003-3: Residential Customer Privacy *** > > > > An organization with downstream residential customers may substitute > > that organization's name for the customer's name, e.g. 'Private > > customer - XYZ Network', and the customer's street address may read > > 'Private Residence'. Each private downstream residential reassignment > > must have accurate upstream Abuse and Technical POCs visible on the > > WHOIS record for that block. > > > >## END ## > > > > -- > If this message was not signed with gpg key 0FE2AA3D, it's probably > a forgery. From john at chagres.net Tue Nov 18 19:28:44 2003 From: john at chagres.net (John Brown) Date: Tue, 18 Nov 2003 17:28:44 -0700 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 In-Reply-To: <20031118230316.GA60238@ussenterprise.ufp.org>; from bicknell@ufp.org on Tue, Nov 18, 2003 at 06:03:17PM -0500 References: <200311181907.OAA16767@ops.arin.net> <2147483647.1069161191@dhcp157-233.corp.tellme.com> <20031118230316.GA60238@ussenterprise.ufp.org> Message-ID: <20031118172844.B39457@alderaan.chagres.net> On Tue, Nov 18, 2003 at 06:03:17PM -0500, Leo Bicknell wrote: > > Back to my original point. Track it. Prove it. If in 6 months > you can offer hard data spam has increased by a reasonable amount Great then lets make the policy time based. If in 6 months there is a track and proof it goes away. Just like laws, some have sunset clauses, or must be renewed. > from these netblocks I'll be the first to consider changing my > views. Without that data I won't. I suspect others are in the > same boat. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org From bicknell at ufp.org Tue Nov 18 19:53:22 2003 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 18 Nov 2003 19:53:22 -0500 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 In-Reply-To: <20031118172844.B39457@alderaan.chagres.net> References: <200311181907.OAA16767@ops.arin.net> <2147483647.1069161191@dhcp157-233.corp.tellme.com> <20031118230316.GA60238@ussenterprise.ufp.org> <20031118172844.B39457@alderaan.chagres.net> Message-ID: <20031119005322.GA65363@ussenterprise.ufp.org> In a message written on Tue, Nov 18, 2003 at 05:28:44PM -0700, John Brown wrote: > Great then lets make the policy time based. If in 6 months there > is a track and proof it goes away. Just like laws, some have > sunset clauses, or must be renewed. The answer to that is simple. The policy was proposed, and passed without such a provision. The time to add to the policy has passed. Like laws, after they are passed you can't just magically and easily change them, you must go back through the whole process. You can always submit a policy request at the next meeting to change this policy. However, I'll go back to the comment I made to Owen. If you're going to change the policy, be that add a sunset provision or repeal it, having data will be useful. Given the level of support for the policy I suspect if it has been in place for 6 months and no one can offer hard evidence of harm that the rehashing of objections already raised will fall on deaf ears. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From dsinn at dsinn.com Tue Nov 18 20:38:35 2003 From: dsinn at dsinn.com (David Sinn) Date: Tue, 18 Nov 2003 17:38:35 -0800 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 In-Reply-To: <20031118172655.A39457@alderaan.chagres.net> Message-ID: I would actually take your statement further and say that many service providers are party to the abuse since it (often) pays the bills. Further, it is a red herring to argue that this will help/hinder/affect spammers and/or abuse. The vast majority of them can be ignored in they become an effect on the real world (I.E. subpoena). The reality is that there are innumerable ways to obfuscate your information in the real world, so why make an extension in the virtual one. If you have a need to protect/hide your personal information please see Owen's prior list and/or do a search via your preferred search engine. I heartily disagree with this proposal. David On 11/18/03 4:26 PM, "John Brown" wrote: > And why would your mother or daughter need more than a single > IP address ?? > > Owen's comment was if its SWIP'd it should have valid contact data. > > Which I agree with. > > Pushing the problem to the service provider doesn't work. Many Many > service providers do not respond to abuse complaints. And only if > you happen to be in the "right club" do you get any sort of response. > > > On Tue, Nov 18, 2003 at 03:34:59PM -0700, Taylor, Stacy wrote: >> Hi All, >> >> I disagree with Owen and heartily endorse this proposal. >> >> The onus of keeping these blocks abuse-free still lies with the upstream >> provider, who runs the risk of a blacklisted block if there is a spammer on >> it. >> My Mother's name and address should not be listed in the ARIN database. My >> college-aged daughter's name and address should not be listed in the ARIN >> database. >> >> XO >> /S >> >> -----Original Message----- >> From: Owen DeLong [mailto:owen at delong.com] >> Sent: Tuesday, November 18, 2003 1:13 PM >> To: ppml at arin.net >> Subject: Re: [ppml] Last Call for Comment: Policy Proposal 2003-3 >> >> >> I still think this policy is a bad idea. I still think if anyone wants >> enough address space to get swipped (a /29 or larger), there's no reason >> they can't remain accountable for that address space. There are already >> multiple options for said person to protect their personal privacy: >> >> P.O. Boxes, >> Company Names (it's really easy to create a schedule C company) >> etc. >> >> This policy just serves to further allow for SPAMMERS to get anonymous >> IP blocks. >> >> Owen >> >> >> >> --On Tuesday, November 18, 2003 14:07 -0500 Member Services >> wrote: >> >>> The ARIN Advisory Council voted to forward the following policy >>> proposal to the ARIN Board of Trustees for consideration. >>> >>> This is a last call for comments on this policy proposal prior >>> to the ARIN Board of Trustees review. Comments received during >>> this period will be included with the proposal when it is presented >>> to the Board of Trustees for their consideration. >>> >>> Please send your comments to ppml at arin.net. This last call will >>> expire at 23:59 EST on December 3, 2003. >>> >>> >>> Member Services >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> *** Last Call: Policy Proposal 2003-3: Residential Customer Privacy *** >>> >>> An organization with downstream residential customers may substitute >>> that organization's name for the customer's name, e.g. 'Private >>> customer - XYZ Network', and the customer's street address may read >>> 'Private Residence'. Each private downstream residential reassignment >>> must have accurate upstream Abuse and Technical POCs visible on the >>> WHOIS record for that block. >>> >>> ## END ## >> >> >> >> -- >> If this message was not signed with gpg key 0FE2AA3D, it's probably >> a forgery. From owen at delong.com Tue Nov 18 22:15:19 2003 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Nov 2003 19:15:19 -0800 Subject: [ppml] Policy Proposal -- Limit Scope of Anonymous Allocations Message-ID: <2147483647.1069182919@dhcp157-233.corp.tellme.com> Assuming 2003-3 will become policy (which, I suspect it will at this point), I propose the following policy: Any provider taking advantage of the residential customer privacy policy shall comply with the following restrictions on that policy: 1. Said provider must agree to address abuse complaints about any blocks which are assigned under that policy promptly. 2. No provider shall assign a block larger than a /27 under the privacy provisions of the policy. 3. No customer of a given provider shall be given more than one assignment under the policy, except, for a period of time not exceeding 90 days for the purpose of renumbering into a larger or smaller allocation (overlap for renumbering). 4. Any provider which has already assigned resources under the privacy policy which are in violation of these restrictions shall make reasonable effort to bring said assignments into compliance. No provider shall be discriminated against for future allocations on the basis of such violations until one year from the date these restrictions become effective. After that, no provider in violation of these restrictions shall receive additional resources from ARIN until such time as that provider complies. Argument in favor of this proposal: Ordinarily, I'd advocate waiting and seeing how the new policy impacts things before proposing an amendment. However, given the blank-check nature of the new policy and the long cycle-time on any policy change, I feel it is important to start this process immediately. As such, I am submitting this policy for consideration. The proposed timetable for implementation would be immediately upon adoption by the BOD, with phase-in as specified in the proposed policy. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From bicknell at ufp.org Tue Nov 18 22:42:33 2003 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 18 Nov 2003 22:42:33 -0500 Subject: [ppml] Policy Proposal -- Limit Scope of Anonymous Allocations In-Reply-To: <2147483647.1069182919@dhcp157-233.corp.tellme.com> References: <2147483647.1069182919@dhcp157-233.corp.tellme.com> Message-ID: <20031119034233.GA72987@ussenterprise.ufp.org> I'd like to compare two situations I see in the residential customer market space, and get some comments with respect to your concerns. Provider type #1: - Typically Cable Modem based. - Typically allows users 1-10 addresses, all assigned via DHCP. - Since addresses are assigned by DHCP never SWIP's space. - Since addresses are assigned by DHCP, users can hop addresses to hide their activities. - All requests must go to the ISP. Provider type #2: - Typically DSL based. - Typically assigns a /27-/32. - Typically SWIP's space. I bring this up because the discussion we've had pretty much only applies to provider type #2. Even if I accept your argument that we need to make them SWIP all space with real information, we've only solved part of the problem, right? For any policy that requires information for residential SWIP's to be truly effective wouldn't we also have to address the provider #1 case? To fix provider type #1, do we: - Not allow them to use DHCP to assign residential customers, mandating static assignments and SWIP's? - Mandate automated mechanisms to query the owner of a DHCP assigned address? - Do something I haven't considered? If the problem is really that important it would seem to me we need to fix both cases. That doesn't mean they need to be tied together (in the same policy), but rather that there should be proposals to address both issues. If it's not important to address the provider type #1, then why is it so important to address this for provider type #2? What is different about a user who has 8 IP's assigned via DHCP, and 8 IP's assigned via static routing? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From jsw at five-elements.com Tue Nov 18 23:04:09 2003 From: jsw at five-elements.com (Jeff S Wheeler) Date: Tue, 18 Nov 2003 23:04:09 -0500 Subject: [ppml] Policy Proposal -- Limit Scope of Anonymous Allocations In-Reply-To: <20031119034233.GA72987@ussenterprise.ufp.org> References: <2147483647.1069182919@dhcp157-233.corp.tellme.com> <20031119034233.GA72987@ussenterprise.ufp.org> Message-ID: <1069214649.733.1819.camel@intrepid.jsw.louisville.ky.us> On Tue, 2003-11-18 at 22:42, Leo Bicknell wrote: > To fix provider type #1, do we: > > - Not allow them to use DHCP to assign residential customers, > mandating static assignments and SWIP's? > - Mandate automated mechanisms to query the owner of a DHCP > assigned address? > - Do something I haven't considered? Owen DeLong says his concern is with spammers and spam tolerant transit vendors abusing the residential application for 2003-3. I don't see why we're bothering to debate how to deal with legitimate residential DHCP assignments. You might as well tell every dialup provider that they must stop using dynamic address pools on their portmasters while we're at it; or perhaps they should make their RADIUS accounting logs available via WHOIS to satisfy these concerns? No doubt everyone will have an easy time implementing this, just as victims of abuse will have an easy time querying temporally-based data in same WHOIS servers. All that seems unrealistic; and any policy mandating the above measures would be summarily ignored by providers of residential access. If the underlying issue is transitors and spammers abusing 2003-3, then why not stick to that concern? -- Jeff S Wheeler From Michael.Dillon at radianz.com Wed Nov 19 06:38:15 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 19 Nov 2003 11:38:15 +0000 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-5 Message-ID: >*** Last Call: Policy Proposal 2003-5: Distributed Information Server >Use Requirements *** >The distributed information service must return reassignment >information for the IP address queried. The service may >allow for privacy protections for customers. Minimally, the >service must provide only the person's name, city, state, >zip code, and country. The service shall follow ARIN's privacy >policy for publishing data in a public forum. This "minimal" specification conflicts with the residential privacy proposal. The text seems to assume that a customer is equivalent to a person whereas in the real world, customers are often companies. The purpose of having a minimal set of information rather than publishing everything, is to avoid facilitating physical attacks on individual persons. The distinction between a person and an organization is an important one and the language in the policy should not contribute to making this fuzzy. In addition, I assume that the intent of not including a street address was to avoid facilitating physical attacks on individuals. In that case, it is inappropriate to include a zip code since that narrows down the physical location to a small area in a city. In Canada, this area is approximately one side of a street in a single block or a single apartment building. From Michael.Dillon at radianz.com Wed Nov 19 06:57:08 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 19 Nov 2003 11:57:08 +0000 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 Message-ID: >Note that this policy has no size limit, so, depending on the >"residential" customer and the willingness of the upstream to condone >abuse and risk blacklisting, it doesn't put much of an onus. As far as I am aware, no ARIN policy places any onus directly on the recipients of a reassignment. The onus is only on the organizations who have a direct relationship with ARIN, namely the ISPs. In this policy proposal, the onus *IS* being put on the ISP, or upstream, to include correct contact information for the ISP's abuse and technical contacts. Those are the people with the ability to take direct action to stop abuse, e.g. disconnect the customer, and they also have access to the customer's identity, location, service provided, billing and payment history, etc. >As written, >it is a blank check for abuse. ARIN doesn't write checks for abuse so how can they write a blank one. ARIN is not the Internet police and ARIN is not the Internet court. If an anonymous residential customer of an ISP does bad things to your network and the ISP will not resolve the matter, then you should go to the real police and/or sue that ISP in the real courts. --Michael Dillon From bicknell at ufp.org Wed Nov 19 08:04:25 2003 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 19 Nov 2003 08:04:25 -0500 Subject: [ppml] Policy Proposal -- Limit Scope of Anonymous Allocations In-Reply-To: <1069214649.733.1819.camel@intrepid.jsw.louisville.ky.us> References: <2147483647.1069182919@dhcp157-233.corp.tellme.com> <20031119034233.GA72987@ussenterprise.ufp.org> <1069214649.733.1819.camel@intrepid.jsw.louisville.ky.us> Message-ID: <20031119130424.GA92838@ussenterprise.ufp.org> In a message written on Tue, Nov 18, 2003 at 11:04:09PM -0500, Jeff S Wheeler wrote: > If the underlying issue is transitors and spammers abusing 2003-3, then > why not stick to that concern? Owen's concern is that Spammers will use 2003-3 to hide their information. His real concern seems to be the hiding of information. My point is that 50% of the infrastructure (in concept, and I think roughly that in practice) already hides that information (via DHCP). The obvious question is, won't the spammers choose the 50% that doesn't require their information to be published to do their dirty deeds? If that's the case, did we gain anything by publishing Grandma's phone number? Alternatively, if we required this it is conceivable that providers who are doing static allocation today and SWIP's might switch to DHCP in an effort to give their customers privacy (a feature for which there is clearly consumer demand). Wouldn't that actually make things worse, since now not only do you not have the info, but the customer has some ability to jump around to different IP's via DHCP? I don't want us to write a policy that is the equivalent of this picture: http://linux01.org:2222/gfx/win98_with_firewall.jpg -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From ron at aol.net Wed Nov 19 08:15:49 2003 From: ron at aol.net (Ron da Silva) Date: Wed, 19 Nov 2003 08:15:49 -0500 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 In-Reply-To: <20031118172655.A39457@alderaan.chagres.net> References: <5BDB545714D0764F8452CC5A25DDEEFA04DAE5AF@denexg21.icgcomm.com> <20031118172655.A39457@alderaan.chagres.net> Message-ID: <20031119131549.GB19077@aol.net> On Tue, Nov 18, 2003 at 05:26:55PM -0700, John Brown wrote: > And why would your mother or daughter need more than a single > IP address ?? At one point, I had a DSL line with a /28 assignment which I used for a dozen or so devices in my house, some of which were used by my daugthers. I fail to understand why I should be required to publish any personal data associated with the use of that /28. My upstream ISP should proxy that data for me so that I don't get unsolicited intrusions in my personal life. -ron From jb at jbacher.com Wed Nov 19 10:00:08 2003 From: jb at jbacher.com (J Bacher) Date: Wed, 19 Nov 2003 09:00:08 -0600 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 Message-ID: <5.1.0.14.2.20031119083847.02fe8318@mail.jbacher.com> Owen: > Note that this policy has no size limit, so, depending on the > "residential" customer and the willingness of the upstream to condone > abuse and risk blacklisting, it doesn't put much of an onus. As written, > it is a blank check for abuse. If the upstream condones spam abuse, where is your data that supports that the upstream's client will adhere to your request? You made the comment at the meeting about wanting to use legal means to contact the client directly. I'll say it again, if you have a valid legal complaint, go through standard legal channels and file a complaint with the police. Owen: > Any provider taking advantage of the residential customer privacy policy > shall comply with the following restrictions on that policy: > 1. Said provider must agree to address abuse complaints about > any blocks which are assigned under that policy promptly. We've had the discussion about ARIN playing babysitter and enforcer for abuse. It doesn't scale. Marla: > I dont take this as a way to stop spam really....but I do feel that unless > your customer falls into a dial pool or DSL pool of some sort that they > should have to have their info swiped on WHOIS so that any abuse issues > coming from their usage can be handled directly with that user first before > getting the upstream provider involved. I don't want you to handle abuse complaints directly with my residential customers. As a zero tolerance for spam ISP, I want the prerogative to shut down that connection before I see chunks of my address space black listed. This policy does not prevent you from SWIPing your residential customer information. John: > And why would your mother or daughter need more than a single > IP address ??" We have residential accounts with a local area network that do not use a centralized firewall and that use personal firewalls and do not NAT or PAT. We have clients that work from home. I will not subject these clients' families to harassment and abuse. Jeff: > Owen DeLong says his concern is with spammers and spam tolerant transit > vendors abusing the residential application for 2003-3." And I say again, if the upstream is tolerant, where does anyone think that the client will be any more proactive in fixing the problem? The majority (99%) of our customer spammers are infected and are not sending spam intentionally. Because of our zero tolerance for spam, we track infected customers, advise them, and shut them down (regardless of the type of connection) if they fail to fix the problem within our required time period. -------------------------------- I realize that there are ARIN members that operate outside of the United States. However, being a company within the United States, I have an obligation to protect the privacy of my customer base. Thank you, Dave, for presenting this proposal. From owen at delong.com Wed Nov 19 13:13:48 2003 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Nov 2003 10:13:48 -0800 Subject: [ppml] Policy Proposal -- Limit Scope of Anonymous Allocations In-Reply-To: <20031119034233.GA72987@ussenterprise.ufp.org> References: <2147483647.1069182919@dhcp157-233.corp.tellme.com> <20031119034233.GA72987@ussenterprise.ufp.org> Message-ID: <2147483647.1069236828@imac-en0.delong.sj.ca.us> While I agree that the provider type 1 case would be nice to solve, I think it would be hard to do that. I'm open to suggestions on how we could do so and I would support a reasonable policy in such case. However, just because we can't solve the type 1 case does not mean, in my opinion, that we should NOT solve the type 2 case. As such, I think this proposal provides a reasonable compromise between the desire for residential privacy and abuse concerns. Do you have concerns that my proposal somehow eliminates necessary residential privacy? If so, please identify them. Thanks, Owen --On Tuesday, November 18, 2003 10:42 PM -0500 Leo Bicknell wrote: > > I'd like to compare two situations I see in the residential customer > market space, and get some comments with respect to your concerns. > > Provider type #1: > > - Typically Cable Modem based. > - Typically allows users 1-10 addresses, all assigned via DHCP. > - Since addresses are assigned by DHCP never SWIP's space. > - Since addresses are assigned by DHCP, users can hop addresses > to hide their activities. > - All requests must go to the ISP. > > Provider type #2: > > - Typically DSL based. > - Typically assigns a /27-/32. > - Typically SWIP's space. > > I bring this up because the discussion we've had pretty much only > applies to provider type #2. Even if I accept your argument that > we need to make them SWIP all space with real information, we've > only solved part of the problem, right? For any policy that requires > information for residential SWIP's to be truly effective wouldn't > we also have to address the provider #1 case? > > To fix provider type #1, do we: > > - Not allow them to use DHCP to assign residential customers, > mandating static assignments and SWIP's? > - Mandate automated mechanisms to query the owner of a DHCP > assigned address? > - Do something I haven't considered? > > If the problem is really that important it would seem to me we need > to fix both cases. That doesn't mean they need to be tied together > (in the same policy), but rather that there should be proposals to > address both issues. If it's not important to address the provider > type #1, then why is it so important to address this for provider > type #2? What is different about a user who has 8 IP's assigned > via DHCP, and 8 IP's assigned via static routing? > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From bicknell at ufp.org Wed Nov 19 13:33:09 2003 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 19 Nov 2003 13:33:09 -0500 Subject: [ppml] Policy Proposal -- Limit Scope of Anonymous Allocations In-Reply-To: <2147483647.1069236828@imac-en0.delong.sj.ca.us> <2147483647.1069182919@dhcp157-233.corp.tellme.com> References: <2147483647.1069182919@dhcp157-233.corp.tellme.com> <20031119034233.GA72987@ussenterprise.ufp.org> <2147483647.1069236828@imac-en0.delong.sj.ca.us> <2147483647.1069182919@dhcp157-233.corp.tellme.com> Message-ID: <20031119183309.GA6741@ussenterprise.ufp.org> In a message written on Wed, Nov 19, 2003 at 10:13:48AM -0800, Owen DeLong wrote: > However, just because we can't solve the type 1 case does not mean, in my > opinion, that we should NOT solve the type 2 case. I disagree. If we can't solve the problem, then increasing the burden on a particular subset of users (in this case ISP's and users who get static assignments) is a bad thing to do. I don't think they need to be solved in the same policy proposal, but we either need to close all the doors at roughly the same time, or close none at all. Otherwise we are just discriminating against a subset of people. You asked if I had problems with the policy as written: In a message written on Tue, Nov 18, 2003 at 07:15:19PM -0800, Owen DeLong wrote: > 1. Said provider must agree to address abuse complaints about > any blocks which are assigned under that policy promptly. If we're going to impose this criteria, it should be applied to all blocks (eg true of every assignment, allocation, and swip), and as such could be a stand alone policy. That said, I don't think ARIN should get involved in the abuse issue at all. As soon as "address abuse" appears in a policy ARIN must now define what is abuse, and what is an appropriate measure to address the abuse issues. Spam is not the only thing (some) people consider abuse. Everyone differs on what is an appropriate response. At the very minimum, if a policy is going to address the abuse issue a very detailed definition of abuse needs to be included, else it will be left to the ARIN staff to decide what is abuse, and that would be a very bad thing in my opinion. > 2. No provider shall assign a block larger than a /27 under the > privacy provisions of the policy. I have no idea why we would arbitrarily limit the size of a residential assignment. I have no idea what you, or anyone else does at home. Maybe you need a /24, and I see no issue with that if you can follow normal justification guidelines. > 3. No customer of a given provider shall be given more than one > assignment under the policy, except, for a period of time not > exceeding 90 days for the purpose of renumbering into a larger > or smaller allocation (overlap for renumbering). Using the word customer here is a bad idea. If I have a summer house and a winter house in two different states, but served by the same ISP I can't get an assignment for each under the privacy policy? I am after all one customer. The rich and famous are quite likely to want the privacy, and quite likely to want service at more than one residence. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From owen at delong.com Wed Nov 19 14:01:44 2003 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Nov 2003 11:01:44 -0800 Subject: [ppml] Policy Proposal -- Limit Scope of Anonymous Allocations In-Reply-To: <20031119130424.GA92838@ussenterprise.ufp.org> References: <2147483647.1069182919@dhcp157-233.corp.tellme.com> <20031119034233.GA72987@ussenterprise.ufp.org> <1069214649.733.1819.camel@intrepid.jsw.louisville.ky.us> <20031119130424.GA92838@ussenterprise.ufp.org> Message-ID: <2147483647.1069239704@imac-en0.delong.sj.ca.us> My argument is that that picture is a better start than no gate or hedges which is what 2003-3 is. Owen > I don't want us to write a policy that is the equivalent of this > picture: > > http://linux01.org:2222/gfx/win98_with_firewall.jpg > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Wed Nov 19 14:04:28 2003 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Nov 2003 11:04:28 -0800 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 In-Reply-To: <20031119131549.GB19077@aol.net> References: <5BDB545714D0764F8452CC5A25DDEEFA04DAE5AF@denexg21.icgcomm.com> <20031118172655.A39457@alderaan.chagres.net> <20031119131549.GB19077@aol.net> Message-ID: <2147483647.1069239868@imac-en0.delong.sj.ca.us> OK... I can see this for a /28, but what about a /24, /22, /21, or even a /13? There's NOTHING in the residential customer privacy policy to prevent ANY of those size allocations from being anonymous, and, nothing that prevents the ISP from "making up" residential customers to chew up space to justify more allocations. Hiding the data this way prevents ARIN from being able to do it's job and creates an invitation to abuse-friendly providers to do a land-grab of vast amounts of abuse-friendly space scattered far and wide throughout the IP space. Owen --On Wednesday, November 19, 2003 8:15 AM -0500 Ron da Silva wrote: > On Tue, Nov 18, 2003 at 05:26:55PM -0700, John Brown wrote: >> And why would your mother or daughter need more than a single >> IP address ?? > > At one point, I had a DSL line with a /28 assignment which I used > for a dozen or so devices in my house, some of which were used by > my daugthers. I fail to understand why I should be required to > publish any personal data associated with the use of that /28. > My upstream ISP should proxy that data for me so that I don't get > unsolicited intrusions in my personal life. > > -ron -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Wed Nov 19 14:13:48 2003 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Nov 2003 11:13:48 -0800 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 In-Reply-To: <5.1.0.14.2.20031119083847.02fe8318@mail.jbacher.com> References: <5.1.0.14.2.20031119083847.02fe8318@mail.jbacher.com> Message-ID: <2147483647.1069240428@imac-en0.delong.sj.ca.us> --On Wednesday, November 19, 2003 9:00 AM -0600 J Bacher wrote: > Owen: > > Note that this policy has no size limit, so, depending on the > > "residential" customer and the willingness of the upstream to condone > > abuse and risk blacklisting, it doesn't put much of an onus. As > written, > > it is a blank check for abuse. > > If the upstream condones spam abuse, where is your data that supports > that the upstream's client will adhere to your request? You made the > comment at the meeting about wanting to use legal means to contact the > client directly. I'll say it again, if you have a valid legal complaint, > go through standard legal channels and file a complaint with the police. > > The police do NOT handle CIVIL complaints. They only deal with CRIMINAL complaints. YOU CANNOT get the POLICE to deliver your CIVIL SUIT to a defendant for which you have no name or address information. Additionally, the ISP whose contact information you DO have cannot be held liable in your civil complaint against their customer in most cases. The latter is a good thing, but, this policy creates SERIOUS problems as long as both are true. > Owen: > > Any provider taking advantage of the residential customer privacy > policy > > shall comply with the following restrictions on that policy: > > 1. Said provider must agree to address abuse complaints about > > any blocks which are assigned under that policy promptly. > > We've had the discussion about ARIN playing babysitter and enforcer for > abuse. It doesn't scale. > This just requires the provider to agree to it. It doesn't place any onus on ARIN to enforce that beyond including it in the provider agreement when the space is ussed. However, since the provider has agreed to it, it gives them some culpability in the subsequent civil suit. > > Marla: > > I dont take this as a way to stop spam really....but I do feel that > unless > > your customer falls into a dial pool or DSL pool of some sort that they > > should have to have their info swiped on WHOIS so that any abuse issues > > coming from their usage can be handled directly with that user first > before > > getting the upstream provider involved. > > I don't want you to handle abuse complaints directly with my residential > customers. As a zero tolerance for spam ISP, I want the prerogative to > shut down that connection before I see chunks of my address space black > listed. This policy does not prevent you from SWIPing your residential > customer information. > I understand that you don't want to publish your customer information for a multitude of reasons advantageous to you and/or your customer. I also feel that it is not in the overall best interests of the internet for you to not do so. I am willing to compromise to /27s and smaller falling within this at a limit of 1 per customer. However, beyond that, I think this policy just creates problems we don't need. > > John: > > And why would your mother or daughter need more than a single > > IP address ??" > > We have residential accounts with a local area network that do not use a > centralized firewall and that use personal firewalls and do not NAT or > PAT. > > We have clients that work from home. I will not subject these clients' > families to harassment and abuse. > Fine... I believe they would be covered by a /27 or less worth of space, so, I don't think that's an issue with my proposed additional policy. > > Jeff: > > Owen DeLong says his concern is with spammers and spam tolerant transit > > vendors abusing the residential application for 2003-3." > > And I say again, if the upstream is tolerant, where does anyone think > that the client will be any more proactive in fixing the problem? The > majority (99%) of our customer spammers are infected and are not sending > spam intentionally. Because of our zero tolerance for spam, we track > infected customers, advise them, and shut them down (regardless of the > type of connection) if they fail to fix the problem within our required > time period. > -------------------------------- > Again... I don't expect the client to be more proactive, but, I expect to be able to issue legal service to the client. I don't expect to be able to SUE the upstream ISP for his customers abuse, since this is specifically prohibited in many places, and, since I don't want to see that precedent in the places where it is not prohibited. Do you? Would you rather I sue you instead of your client for your client's abuse? Do you want to see the law say specifically that I can? Sounds like a bad thing for ISPs to me. > I realize that there are ARIN members that operate outside of the United > States. However, being a company within the United States, I have an > obligation to protect the privacy of my customer base. > Really... Where exactly does that obligation come from? Why, exactly, do you think you have a legal obligation to not publish their information? I agree that you have an obligation to not do it without their permission, but, currently, you should be getting their permission prior to issuing a larger block of address space than a /29. I don't see how this fails to meet your obligations. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Stacy_Taylor at icgcomm.com Wed Nov 19 14:14:45 2003 From: Stacy_Taylor at icgcomm.com (Taylor, Stacy) Date: Wed, 19 Nov 2003 12:14:45 -0700 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 Message-ID: <5BDB545714D0764F8452CC5A25DDEEFA04DAE5B5@denexg21.icgcomm.com> You are forgetting the vigilance of ARIN staff in the below scenario. They would *never* take a simple "Residential Customer" record as justification for adequate utilization. /S -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Wednesday, November 19, 2003 11:04 AM To: Ron da Silva; ppml at arin.net Subject: Re: [ppml] Last Call for Comment: Policy Proposal 2003-3 OK... I can see this for a /28, but what about a /24, /22, /21, or even a /13? There's NOTHING in the residential customer privacy policy to prevent ANY of those size allocations from being anonymous, and, nothing that prevents the ISP from "making up" residential customers to chew up space to justify more allocations. Hiding the data this way prevents ARIN from being able to do it's job and creates an invitation to abuse-friendly providers to do a land-grab of vast amounts of abuse-friendly space scattered far and wide throughout the IP space. Owen --On Wednesday, November 19, 2003 8:15 AM -0500 Ron da Silva wrote: > On Tue, Nov 18, 2003 at 05:26:55PM -0700, John Brown wrote: >> And why would your mother or daughter need more than a single >> IP address ?? > > At one point, I had a DSL line with a /28 assignment which I used > for a dozen or so devices in my house, some of which were used by > my daugthers. I fail to understand why I should be required to > publish any personal data associated with the use of that /28. > My upstream ISP should proxy that data for me so that I don't get > unsolicited intrusions in my personal life. > > -ron -- If it wasn't crypto-signed, it probably didn't come from me. From jb at jbacher.com Wed Nov 19 14:25:31 2003 From: jb at jbacher.com (J Bacher) Date: Wed, 19 Nov 2003 13:25:31 -0600 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 In-Reply-To: <2147483647.1069239868@imac-en0.delong.sj.ca.us> References: <20031119131549.GB19077@aol.net> <5BDB545714D0764F8452CC5A25DDEEFA04DAE5AF@denexg21.icgcomm.com> <20031118172655.A39457@alderaan.chagres.net> <20031119131549.GB19077@aol.net> Message-ID: <5.1.0.14.2.20031119132420.0347aa80@mail.jbacher.com> At 11:04 AM 11/19/2003 -0800, Owen DeLong wrote: >OK... I can see this for a /28, but what about a /24, /22, /21, or even >a /13? There's NOTHING in the residential customer privacy policy to >prevent ANY of those size allocations from being anonymous, and, nothing >that prevents the ISP from "making up" residential customers to chew >up space to justify more allocations. And nothing to prevent companies from reporting abusive netblocks to blacklists or blocking them in the network. From bicknell at ufp.org Wed Nov 19 14:27:54 2003 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 19 Nov 2003 14:27:54 -0500 Subject: [ppml] Policy Proposal -- Limit Scope of Anonymous Allocations In-Reply-To: <2147483647.1069239704@imac-en0.delong.sj.ca.us> References: <2147483647.1069182919@dhcp157-233.corp.tellme.com> <20031119034233.GA72987@ussenterprise.ufp.org> <1069214649.733.1819.camel@intrepid.jsw.louisville.ky.us> <20031119130424.GA92838@ussenterprise.ufp.org> <2147483647.1069239704@imac-en0.delong.sj.ca.us> Message-ID: <20031119192753.GB8717@ussenterprise.ufp.org> In a message written on Wed, Nov 19, 2003 at 11:01:44AM -0800, Owen DeLong wrote: > My argument is that that picture is a better start than no gate or hedges > which is what 2003-3 is. I'll buy that, but if and only if you plan to put up a fence. But that goes back to my original question. With your proposal we have the gate. A fine start. Please propose the fence (all the DHCP based residential ISP's for which there is no info in whois) to go along with it (separate policy is fine). Without the fence the gate is something to find amusing and inconvenient. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From owen at delong.com Wed Nov 19 14:28:44 2003 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Nov 2003 11:28:44 -0800 Subject: [ppml] Policy Proposal -- Limit Scope of Anonymous Allocations In-Reply-To: <20031119183309.GA6741@ussenterprise.ufp.org> References: <2147483647.1069182919@dhcp157-233.corp.tellme.com> <20031119034233.GA72987@ussenterprise.ufp.org> <2147483647.1069236828@imac-en0.delong.sj.ca.us> <2147483647.1069182919@dhcp157-233.corp.tellme.com> <20031119183309.GA6741@ussenterprise.ufp.org> Message-ID: <2147483647.1069241324@imac-en0.delong.sj.ca.us> --On Wednesday, November 19, 2003 1:33 PM -0500 Leo Bicknell wrote: > In a message written on Wed, Nov 19, 2003 at 10:13:48AM -0800, Owen > DeLong wrote: >> However, just because we can't solve the type 1 case does not mean, in my >> opinion, that we should NOT solve the type 2 case. > > I disagree. If we can't solve the problem, then increasing the > burden on a particular subset of users (in this case ISP's and users > who get static assignments) is a bad thing to do. I don't think > they need to be solved in the same policy proposal, but we either > need to close all the doors at roughly the same time, or close none > at all. Otherwise we are just discriminating against a subset of > people. > But we're not increasing that burden. We're simply refusing to DECREASE it. The burden is already there today. 2003-3 reduces it for some subset. I'm proposing to reduce the scope of the subset for which 2003-3 reduces that burden. This is a good thing. > You asked if I had problems with the policy as written: > > In a message written on Tue, Nov 18, 2003 at 07:15:19PM -0800, Owen > DeLong wrote: >> 1. Said provider must agree to address abuse complaints about >> any blocks which are assigned under that policy promptly. > > If we're going to impose this criteria, it should be applied to all > blocks (eg true of every assignment, allocation, and swip), and as > such could be a stand alone policy. > I have no problem with that, but, I think it is particularly important to ANY block for which contact information is obscured. > That said, I don't think ARIN should get involved in the abuse issue > at all. As soon as "address abuse" appears in a policy ARIN must > now define what is abuse, and what is an appropriate measure to > address the abuse issues. Spam is not the only thing (some) people > consider abuse. Everyone differs on what is an appropriate response. > I disagree. By including this in the agreement, and taking no other action on it, ARIN merely creates a opportunity legal recourse against the ISP for failing to address downstream problems. No definition of abuse on ARINs part is necessary, the courts can sort that out between the Abusee and the ISP (and possibly the ISPs customer/abuser). > At the very minimum, if a policy is going to address the abuse issue > a very detailed definition of abuse needs to be included, else it will > be left to the ARIN staff to decide what is abuse, and that would be > a very bad thing in my opinion. > No. It is not left to the ARIN staff, because ARIN takes no action relative to the abuse and is not involved in the abuse process at all. It merely places a legal onus on the ISP receiving the allocation to accept responsibility for downstream abuse. After that, it's between the abusee and the ISP. >> 2. No provider shall assign a block larger than a /27 under the >> privacy provisions of the policy. > > I have no idea why we would arbitrarily limit the size of a residential > assignment. I have no idea what you, or anyone else does at home. > Maybe you need a /24, and I see no issue with that if you can follow > normal justification guidelines. > I have multiple /24s actually, and, they are SWIP'd. Frankly, if I were just a residence, I would have a hard time justifying more than a /27. However, since I run a business here as well, I have more space. I don't think that entitles me to pull my business under residential privacy provisions. I think allowing for anonymous /22s is a very bad idea. >> 3. No customer of a given provider shall be given more than one >> assignment under the policy, except, for a period of time not >> exceeding 90 days for the purpose of renumbering into a larger >> or smaller allocation (overlap for renumbering). > > Using the word customer here is a bad idea. If I have a summer > house and a winter house in two different states, but served by the > same ISP I can't get an assignment for each under the privacy policy? > I am after all one customer. The rich and famous are quite likely > to want the privacy, and quite likely to want service at more than > one residence. > The rich and famous don't need their ISP for privacy. They would register both under some corporation they own with a P.O. Box. Sorry, no sale as far as I'm concerned. Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From owen at delong.com Wed Nov 19 14:31:21 2003 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Nov 2003 11:31:21 -0800 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 In-Reply-To: <5BDB545714D0764F8452CC5A25DDEEFA04DAE5B5@denexg21.icgcomm.com> References: <5BDB545714D0764F8452CC5A25DDEEFA04DAE5B5@denexg21.icgcomm.com> Message-ID: <2147483647.1069241481@imac-en0.delong.sj.ca.us> As I read it, this policy virtually requires them to do so. There is nothing in this policy that requires the ISP to provide the information to ARIN, nor anything that requires ARIN to audit it. As such, any ISP that wanted to push the issue would likely be able to make the case that policy is on their side. I don't underestimate staff... They're great. I just don't want to tie their hands with this ill-conceived policy. Owen --On Wednesday, November 19, 2003 12:14 PM -0700 "Taylor, Stacy" wrote: > You are forgetting the vigilance of ARIN staff in the below scenario. > They would *never* take a simple "Residential Customer" record as > justification for adequate utilization. > /S > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Wednesday, November 19, 2003 11:04 AM > To: Ron da Silva; ppml at arin.net > Subject: Re: [ppml] Last Call for Comment: Policy Proposal 2003-3 > > > OK... I can see this for a /28, but what about a /24, /22, /21, or even > a /13? There's NOTHING in the residential customer privacy policy to > prevent ANY of those size allocations from being anonymous, and, nothing > that prevents the ISP from "making up" residential customers to chew > up space to justify more allocations. > > Hiding the data this way prevents ARIN from being able to do it's job > and creates an invitation to abuse-friendly providers to do a land-grab > of vast amounts of abuse-friendly space scattered far and wide throughout > the IP space. > > Owen > > > --On Wednesday, November 19, 2003 8:15 AM -0500 Ron da Silva > wrote: > >> On Tue, Nov 18, 2003 at 05:26:55PM -0700, John Brown wrote: >>> And why would your mother or daughter need more than a single >>> IP address ?? >> >> At one point, I had a DSL line with a /28 assignment which I used >> for a dozen or so devices in my house, some of which were used by >> my daugthers. I fail to understand why I should be required to >> publish any personal data associated with the use of that /28. >> My upstream ISP should proxy that data for me so that I don't get >> unsolicited intrusions in my personal life. >> >> -ron > > > > -- > If it wasn't crypto-signed, it probably didn't come from me. -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From db6906 at sbc.com Wed Nov 19 15:10:00 2003 From: db6906 at sbc.com (BARGER, DAVE (SBIS)) Date: Wed, 19 Nov 2003 14:10:00 -0600 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 Message-ID: <6CE0DC2F2ED2B94F80357B939C56740112D173F6@sbis0.sbcis.sbc.com> > "There is nothing in this policy that requires the ISP to provide the information to ARIN, nor anything that requires ARIN to audit it." ...and there SHOULDN'T BE. This policy is not intended to address ARIN audit policy. RFC2050 states: "ISPs are required to utilize address space in an efficient manner. To this end, ISPs should have documented justification available for each assignment. The regional registry may, at any time, ask for this information. If the information is not available, future allocations may be impacted. In extreme cases, existing loans may be impacted." ARIN can audit an ISPs utilization at anytime, and based on experience - they do it! > "Hiding the data this way prevents ARIN from being able to do it's job..." 2003-3 in no way prevents ARIN from doing there job. Again, they have RFC2050 as backup. > "...and creates an invitation to abuse-friendly providers to do a land-grab > of vast amounts of abuse-friendly space scattered far and wide throughout > the IP space." Yes, there will always be a minority who disregard the rules. These companies/individuals do so with absolute disregard for any/all policy. If they want to act in an unethical manner, they will do so. 2003-3 doesn't invite them to act badly. They already know how to do it. But again, RFC2050 pretty much gives ARIN free reign in auditing utilization, including revocation of current/provious allocations. Dave -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Wednesday, November 19, 2003 1:31 PM To: Taylor, Stacy; Ron da Silva; ppml at arin.net Subject: RE: [ppml] Last Call for Comment: Policy Proposal 2003-3 As I read it, this policy virtually requires them to do so. There is nothing in this policy that requires the ISP to provide the information to ARIN, nor anything that requires ARIN to audit it. As such, any ISP that wanted to push the issue would likely be able to make the case that policy is on their side. I don't underestimate staff... They're great. I just don't want to tie their hands with this ill-conceived policy. Owen --On Wednesday, November 19, 2003 12:14 PM -0700 "Taylor, Stacy" wrote: > You are forgetting the vigilance of ARIN staff in the below scenario. > They would *never* take a simple "Residential Customer" record as > justification for adequate utilization. > /S > > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Wednesday, November 19, 2003 11:04 AM > To: Ron da Silva; ppml at arin.net > Subject: Re: [ppml] Last Call for Comment: Policy Proposal 2003-3 > > > OK... I can see this for a /28, but what about a /24, /22, /21, or even > a /13? There's NOTHING in the residential customer privacy policy to > prevent ANY of those size allocations from being anonymous, and, nothing > that prevents the ISP from "making up" residential customers to chew > up space to justify more allocations. > > Hiding the data this way prevents ARIN from being able to do it's job > and creates an invitation to abuse-friendly providers to do a land-grab > of vast amounts of abuse-friendly space scattered far and wide throughout > the IP space. > > Owen > > > --On Wednesday, November 19, 2003 8:15 AM -0500 Ron da Silva > wrote: > >> On Tue, Nov 18, 2003 at 05:26:55PM -0700, John Brown wrote: >>> And why would your mother or daughter need more than a single >>> IP address ?? >> >> At one point, I had a DSL line with a /28 assignment which I used >> for a dozen or so devices in my house, some of which were used by >> my daugthers. I fail to understand why I should be required to >> publish any personal data associated with the use of that /28. >> My upstream ISP should proxy that data for me so that I don't get >> unsolicited intrusions in my personal life. >> >> -ron > > > > -- > If it wasn't crypto-signed, it probably didn't come from me. -- If it wasn't crypto-signed, it probably didn't come from me. From jb at jbacher.com Wed Nov 19 16:08:32 2003 From: jb at jbacher.com (J Bacher) Date: Wed, 19 Nov 2003 15:08:32 -0600 Subject: [ppml] Policy Proposal -- Limit Scope of Anonymous Allocations In-Reply-To: <2147483647.1069241324@imac-en0.delong.sj.ca.us> References: <20031119183309.GA6741@ussenterprise.ufp.org> <2147483647.1069182919@dhcp157-233.corp.tellme.com> <20031119034233.GA72987@ussenterprise.ufp.org> <2147483647.1069236828@imac-en0.delong.sj.ca.us> <2147483647.1069182919@dhcp157-233.corp.tellme.com> <20031119183309.GA6741@ussenterprise.ufp.org> Message-ID: <5.1.0.14.2.20031119150743.034df340@mail.jbacher.com> At 11:28 AM 11/19/2003 -0800, you wrote: >The rich and famous don't need their ISP for privacy. They would register >both under some corporation they own with a P.O. Box. Sorry, no sale as >far as I'm concerned. One doesn't need to be either rich or famous to use a PO Box. Unless PO Boxes in your part of the world are exhorbitantly expensive. From jb at jbacher.com Wed Nov 19 16:08:46 2003 From: jb at jbacher.com (J Bacher) Date: Wed, 19 Nov 2003 15:08:46 -0600 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 Message-ID: <5.1.0.14.2.20031119150839.034df340@mail.jbacher.com> At 11:13 AM 11/19/2003 -0800, you wrote: >Again... I don't expect the client to be more proactive, but, I expect to >be able to issue legal service to the client. I don't expect to be able >to SUE the upstream ISP for his customers abuse, since this is specifically >prohibited in many places, and, since I don't want to see that precedent in File a complaint. Get a subpeona. If today I don't need to provide an individual's address, you still have no method of harassing the customer direct. From owen at delong.com Wed Nov 19 17:29:33 2003 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Nov 2003 14:29:33 -0800 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 In-Reply-To: <5.1.0.14.2.20031119155933.03494ea0@mail.jbacher.com> References: <5.1.0.14.2.20031119150435.034a6278@mail.jbacher.com> <5.1.0.14.2.20031119083847.02fe8318@mail.jbacher.com> <5.1.0.14.2.20031119083847.02fe8318@mail.jbacher.com> <5.1.0.14.2.20031119150435.034a6278@mail.jbacher.com> <5.1.0.14.2.20031119155933.03494ea0@mail.jbacher.com> Message-ID: <2147483647.1069252173@dhcp157-233.corp.tellme.com> Again... the kind of subpoena you are talking about is for a CRIMINAL complaint. Law enforcement will not generate or act such a SUBPOENA for a CIVIL action. Especially if I want to make a small claims action against your customer. You are creating an additional burden against me if I want to sue your customer for their abusive damage to my network. My only recourse is to sue you as if you were responsible for that damage. Then, you come to court and say "no, that was my customer" and the judge dismisses it and I have virtually no recourse. In essence, you have raised the bar on my ability to use legal recourse such that in order to make a civil recovery of damages inflicted by your customer I have to take my case to superior court where I can get a substantial discovery process. This significantly raises my costs to obtain such a recovery and, in essence, shields your customer from smaller legal actions by making them impractical. Perhaps that is what you intend, but, I don't think ARIN policy should facilitate this. Owen --On Wednesday, November 19, 2003 16:00 -0600 J Bacher wrote: > At 01:44 PM 11/19/2003 -0800, you wrote: >> That's not true. Given a name and ZIP code, with a subpoena, it's >> reasonably easy to track someone down. With no name or any other > > That's my whole point. I "own" and am responsible for the activity for > that IP address. It's a piece of cake to present the subpeona to the > ISP. You don't even need a name. With a subpeona, law enforcement will > get all valid customer information, anyway. > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From jb at jbacher.com Wed Nov 19 18:01:58 2003 From: jb at jbacher.com (J Bacher) Date: Wed, 19 Nov 2003 17:01:58 -0600 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 In-Reply-To: <2147483647.1069252173@dhcp157-233.corp.tellme.com> References: <5.1.0.14.2.20031119155933.03494ea0@mail.jbacher.com> <5.1.0.14.2.20031119150435.034a6278@mail.jbacher.com> <5.1.0.14.2.20031119083847.02fe8318@mail.jbacher.com> <5.1.0.14.2.20031119083847.02fe8318@mail.jbacher.com> <5.1.0.14.2.20031119150435.034a6278@mail.jbacher.com> <5.1.0.14.2.20031119155933.03494ea0@mail.jbacher.com> Message-ID: <5.1.0.14.2.20031119165242.034cb4d8@mail.jbacher.com> At 02:29 PM 11/19/2003 -0800, you wrote: >Again... the kind of subpoena you are talking about is for a CRIMINAL >complaint. Law enforcement will not generate or act such a SUBPOENA >for a CIVIL action. Especially if I want to make a small claims action >against your customer. You are creating an additional burden against me >if I want to sue your customer for their abusive damage to my network. >My only recourse is to sue you as if you were responsible for that damage. >Then, you come to court and say "no, that was my customer" and the judge >dismisses it and I have virtually no recourse. If you file a CIVIL LAWSUIT are you telling me that you cannot obtain a subpoena for information and witnesses? And if you can't subpoena in a CIVIL LAWSUIT, how do you get anyone to show up in court? Small claims court? I could spend more money in the state of Illinois on a small claim that I would get in return. You can't sue today based upon ARIN's lack of requirement for a residential street address because you would have insufficient information. Yours is a moot point. From jb at jbacher.com Wed Nov 19 18:03:49 2003 From: jb at jbacher.com (J Bacher) Date: Wed, 19 Nov 2003 17:03:49 -0600 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 In-Reply-To: <2147483647.1069252173@dhcp157-233.corp.tellme.com> References: <5.1.0.14.2.20031119155933.03494ea0@mail.jbacher.com> <5.1.0.14.2.20031119150435.034a6278@mail.jbacher.com> <5.1.0.14.2.20031119083847.02fe8318@mail.jbacher.com> <5.1.0.14.2.20031119083847.02fe8318@mail.jbacher.com> <5.1.0.14.2.20031119150435.034a6278@mail.jbacher.com> <5.1.0.14.2.20031119155933.03494ea0@mail.jbacher.com> Message-ID: <5.1.0.14.2.20031119170213.03479c60@mail.jbacher.com> At 02:29 PM 11/19/2003 -0800, you wrote: >Again... the kind of subpoena you are talking about is for a CRIMINAL >complaint. Law enforcement will not generate or act such a SUBPOENA Again, you are making presumptions. Law enforcement in this state can serve divorce papers (though I'd be happy to double-check that this is -still- the case :). Last I heard a divorce was not a criminal matter. From bicknell at ufp.org Wed Nov 19 18:04:20 2003 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 19 Nov 2003 18:04:20 -0500 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 In-Reply-To: <2147483647.1069252173@dhcp157-233.corp.tellme.com> References: <5.1.0.14.2.20031119150435.034a6278@mail.jbacher.com> <5.1.0.14.2.20031119083847.02fe8318@mail.jbacher.com> <5.1.0.14.2.20031119083847.02fe8318@mail.jbacher.com> <5.1.0.14.2.20031119150435.034a6278@mail.jbacher.com> <5.1.0.14.2.20031119155933.03494ea0@mail.jbacher.com> <2147483647.1069252173@dhcp157-233.corp.tellme.com> Message-ID: <20031119230420.GA20916@ussenterprise.ufp.org> A question keeps going around in my head. If we assume the activity is not crimimal (because, if it is you should report it as criminal activity, and they have the means to find out the true identity of the source even if ARIN data allows anonymous records), what are you going to sue someone for in Civil court? I honestly can't think of a single civil suit that would make sense. Can you provide some examples? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From owen at delong.com Wed Nov 19 21:23:43 2003 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Nov 2003 18:23:43 -0800 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 In-Reply-To: <20031119230420.GA20916@ussenterprise.ufp.org> References: <5.1.0.14.2.20031119150435.034a6278@mail.jbacher.com> <5.1.0.14.2.20031119083847.02fe8318@mail.jbacher.com> <5.1.0.14.2.20031119083847.02fe8318@mail.jbacher.com> <5.1.0.14.2.20031119150435.034a6278@mail.jbacher.com> <5.1.0.14.2.20031119155933.03494ea0@mail.jbacher.com> <2147483647.1069252173@dhcp157-233.corp.tellme.com> <20031119230420.GA20916@ussenterprise.ufp.org> Message-ID: <2147483647.1069266223@dhcp157-233.corp.tellme.com> Yes, it probably also involves criminal activity. However, in many cases, it involves a level of criminal activity that leads law enforcement to respond "don't bother us with your petty problem". If I don't view the problem as petty, I should still be able to use my civil remedies even if law enforcement is unwilling to act on the criminal complaint. I hope this clarifies. Owen --On Wednesday, November 19, 2003 18:04 -0500 Leo Bicknell wrote: > > A question keeps going around in my head. If we assume the activity > is not crimimal (because, if it is you should report it as criminal > activity, and they have the means to find out the true identity of > the source even if ARIN data allows anonymous records), what are > you going to sue someone for in Civil court? > > I honestly can't think of a single civil suit that would make sense. > Can you provide some examples? -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From jsw at five-elements.com Wed Nov 19 21:34:01 2003 From: jsw at five-elements.com (Jeff S Wheeler) Date: Wed, 19 Nov 2003 21:34:01 -0500 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 In-Reply-To: <2147483647.1069266223@dhcp157-233.corp.tellme.com> References: <5.1.0.14.2.20031119150435.034a6278@mail.jbacher.com> <5.1.0.14.2.20031119083847.02fe8318@mail.jbacher.com> <5.1.0.14.2.20031119083847.02fe8318@mail.jbacher.com> <5.1.0.14.2.20031119150435.034a6278@mail.jbacher.com> <5.1.0.14.2.20031119155933.03494ea0@mail.jbacher.com> <2147483647.1069252173@dhcp157-233.corp.tellme.com> <20031119230420.GA20916@ussenterprise.ufp.org> <2147483647.1069266223@dhcp157-233.corp.tellme.com> Message-ID: <1069295641.797.2027.camel@intrepid.jsw.louisville.ky.us> On Wed, 2003-11-19 at 21:23, Owen DeLong wrote: > the problem as petty, I should still be able to use my civil remedies even > if law enforcement is unwilling to act on the criminal complaint. FYI, Owen DeLong and others, in most jurisdictions, the police are a criminal arm; where as the Sheriff is essentially an organization that exists to carry out the wishes of the courts. If you have ever neglected to pay your tax bill, it is the Sheriff who will send you a letter or knock on your door. Likewise, if someone supoenas your testimony in a court proceeding, the Sheriff will make sure you supply it. At the U.S. Federal level, the distinction is between the F.B.I., who are a police; and the U.S. Marshalls', who are a Sheriff organization. Hence the cool shields, or the equally keen wild-west badges. -- Jeff S Wheeler From Michael.Dillon at radianz.com Thu Nov 20 06:17:57 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 20 Nov 2003 11:17:57 +0000 Subject: [ppml] Policy Proposal -- Limit Scope of Anonymous Allocations Message-ID: >While I agree that the provider type 1 case would be nice to solve, I think >it would be hard to do that. I'm open to suggestions on how we could do >so and I would support a reasonable policy in such case. It's not up to ARIN to solve any of these cases. Therefore, there is no such thing as a reasonable policy in this context. The world does not need to know the identity of individuals using IP addresses and it does not need to know the physical location of individuals using IP addresses. All the world needs to know is which organization fulfills the stewardship role for any given range of IP addresses. If there are any abuse issues with a certain IP address, it is both necessary and suficient for ARIN's database to identify the organization to which they have delegated the stewardship role. --Michael Dillon From Michael.Dillon at radianz.com Thu Nov 20 06:40:13 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 20 Nov 2003 11:40:13 +0000 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 Message-ID: >and, nothing >that prevents the ISP from "making up" residential customers to chew >up space to justify more allocations. ARIN policies don't prevent anything. For that matter, neither do laws. We needed a way to document what behavior is acceptable to the community in relation to the management of IP addresses. The community of people with an interest in this area, created ARIN and its policies to document an orderly and fair process for managing the IP address space in North America. We have no special powers that allow us to use force or to prevent people from misbehaving. >Hiding the data this way prevents ARIN from being able to do it's job >and creates an invitation to abuse-friendly providers to do a land-grab >of vast amounts of abuse-friendly space scattered far and wide throughout >the IP space. This is utterly ridiculous. Let's take a real world example, namely my company. We assign blocks as large as /22 to customers. As you know, I believe that we should have the right to not publish any customer information unless the customer contact is ready, willing and able to act upon abuse complaints. In our case, we would not ask any of our customers to do this and would, in fact, remove the entire set of customer assignment information from our rwhois database so that all queries would return our company name. We don't ever want anybody to contact our customers directly. At the same time, we have signed an NDA with ARIN and provide them with lots of sensitive and confidential information about our customers and our network topology to justify our rather large IP address allocations. As you can see the two issues are disjoint. We want to hide data from the public and already do hide a lot by providing minimal information in rwhois. But we do not hide information from ARIN and bend over backwards to facilitate them in doing their job. Today, it is easy for network abusers to hide themselves in the mass of useless, inacurate SWIP data. The solution is not to create huge bureaucracies with stiff and complex publishing requirements. I believe we are better off if we simplify. Get rid of all the data currently in whois. Require the organizations with direct allocations from ARIN to publish contact information. Offer other organizations the option to also publish their own contact information if their upstream agrees to offload abuse issues to that organization. A simple policy with clear and unambiguous delegation of responsibility will remove the hiding places for spammers and their ilk. --Michael Dillon From ibaker at codecutters.org Thu Nov 20 07:11:24 2003 From: ibaker at codecutters.org (Ian Baker) Date: Thu, 20 Nov 2003 12:11:24 -0000 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 References: Message-ID: <069701c3af5f$6d84cec0$642fa8c0@codecutters.org> ----- Original Message ----- From: To: Sent: Thursday, November 20, 2003 11:40 AM Subject: Re: [ppml] Last Call for Comment: Policy Proposal 2003-3 > Today, it is easy for network abusers to hide themselves in the mass > of useless, inacurate SWIP data. The solution is not to create huge > bureaucracies with stiff and complex publishing requirements. I believe > we are better off if we simplify. Get rid of all the data currently > in whois. Require the organizations with direct allocations from ARIN > to publish contact information. Offer other organizations the option > to also publish their own contact information if their upstream > agrees to offload abuse issues to that organization. A simple policy > with clear and unambiguous delegation of responsibility will remove > the hiding places for spammers and their ilk. Hardly. From what you've just said, this provides them an /ideal/ hiding place (as you put it) - "Hello, Mr. Spammer. Do you want us to publish your contact information?" "No. I'd prefer that Spamhaus (or whoever) didn't find me this time around. Please force my millions of foreign victims to resort to expensive cross-border legal instruments" "Ah, that'd do nicely, sir - we can even reduce the funding for our AUP team without anyone being the wiser" Certainly not true in many cases, but it might be instructive to take an analogous look at German data protection law - just to see what /can/ happen. Regards, Ian Baker Webmaster, codecutters.org From Michael.Dillon at radianz.com Thu Nov 20 07:46:31 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 20 Nov 2003 12:46:31 +0000 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 Message-ID: >"Ah, that'd do nicely, sir - we can even reduce the funding for our AUP team >without anyone being the wiser" You seem to be saying that an ISP could be colluding with spammers by ignoring any abuse complaints about the spammer's IP addresses. This may indeed happen but it is not ARIN's job to do anything about it. ARIN is still publishing the contact information of the colluding ISP. They may be able to ignore complaints from 3rd parties but they won't be able to ignore complaints from their peers or their customers. It is trivial to identify the peers of a rogue ISP in order to file a complaint about the rogue. This all comes back to the purpose of the whois directory. It all started back in the days of the ARPAnet when someone decided that anyone who had a user account on an ARPAnet system should be listed in a central directory for some reason, probably related to funding for the network connections and the timesharing systems. The world has changed a lot since then and nowadays we seem to have no agreed purpose for the whois directory other than tradition. In my opinion, the directory is to identify contact points for people who can deal with networking issues like network abuse and misconfigured devices that cause problem for other people. And if that is the purpose, the directory should *ONLY* contain information for contacts that are ready, willing and able to receive communications about networking issues and act upon them. If an organization cannot meet that basic requirement, whatever the reason, then their information should *NOT* be listed in the directory. All the arguments that I have seen about whois are making unstated assumptions about the purpose of the whois directory. I think that is bad because we end up arguing at cross purposes about different things. We need to begin by agreeing on the foundation, i.e. what is the purpose of whois? I might be persuaded that whois should also serve some research or network forensic goal. Perhaps we really should publish all assignments down to a /29 level with a class-of-user and a city-of-service and city-for-billing. Some people would find it useful to distinguish between addresses used by residential users, companies, non-profit organizations, schools, etc. Some people would find it useful to know that the city-for-billing of address blocks used for spamming mostly clusters in a few counties of south Florida. But in order to do this we need to make a clear distinction of when contact information should be published and when only research information should be published. --Michael Dillon From jb at jbacher.com Thu Nov 20 09:07:32 2003 From: jb at jbacher.com (J Bacher) Date: Thu, 20 Nov 2003 08:07:32 -0600 (CST) Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 In-Reply-To: <069701c3af5f$6d84cec0$642fa8c0@codecutters.org> References: <069701c3af5f$6d84cec0$642fa8c0@codecutters.org> Message-ID: On Thu, 20 Nov 2003, Ian Baker wrote: > Hardly. From what you've just said, this provides them an /ideal/ hiding > place (as you put it) - > > "Hello, Mr. Spammer. Do you want us to publish your contact information?" > "No. I'd prefer that Spamhaus (or whoever) didn't find me this time around. > Please force my millions of foreign victims to resort to expensive > cross-border legal instruments" > "Ah, that'd do nicely, sir - we can even reduce the funding for our AUP team > without anyone being the wiser" With policy as it stands today, you may have no complete, valid information to do much of anything anyway. Retaining the client name doesn't help you. From ibaker at codecutters.org Thu Nov 20 10:14:20 2003 From: ibaker at codecutters.org (Ian Baker) Date: Thu, 20 Nov 2003 15:14:20 -0000 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 References: Message-ID: <075c01c3af78$fbdd8180$642fa8c0@codecutters.org> ----- Original Message ----- From: To: Sent: Thursday, November 20, 2003 12:46 PM Subject: Re: [ppml] Last Call for Comment: Policy Proposal 2003-3 > >"Ah, that'd do nicely, sir - we can even reduce the funding for our AUP > team > >without anyone being the wiser" > > You seem to be saying that an ISP could be colluding with > spammers by ignoring any abuse complaints about the spammer's > IP addresses. This may indeed happen but it is not ARIN's > job to do anything about it. Correct. Although it would help if someone didn't scrub the entire database that /does/ exist. > ARIN is still publishing the contact information of the > colluding ISP. They may be able to ignore complaints from > 3rd parties but they won't be able to ignore complaints > from their peers or their customers. It is trivial to > identify the peers of a rogue ISP in order to file a complaint > about the rogue. > > This all comes back to the purpose of the whois directory. > I might be persuaded that whois should also serve some > research or network forensic goal. Perhaps we really > should publish all assignments down to a /29 level with > a class-of-user and a city-of-service and city-for-billing. > Some people would find it useful to distinguish between > addresses used by residential users, companies, non-profit > organizations, schools, etc. Some people would find it > useful to know that the city-for-billing of address blocks > used for spamming mostly clusters in a few counties of > south Florida. But in order to do this we need to > make a clear distinction of when contact information > should be published and when only research information > should be published. All correct - we just disagree about the purpose. For /your/ purpose, you could happily get by with a very small subset of the data currently available. Wholesale erasure would not be a problem. For some of us, this would be undesirable, to say the least. Regards, Ian From ibaker at codecutters.org Thu Nov 20 10:42:36 2003 From: ibaker at codecutters.org (Ian Baker) Date: Thu, 20 Nov 2003 15:42:36 -0000 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 References: <069701c3af5f$6d84cec0$642fa8c0@codecutters.org> Message-ID: <079201c3af7c$ee5e0350$642fa8c0@codecutters.org> ----- Original Message ----- From: "J Bacher" To: Sent: Thursday, November 20, 2003 2:07 PM Subject: Re: [ppml] Last Call for Comment: Policy Proposal 2003-3 > On Thu, 20 Nov 2003, Ian Baker wrote: > > > Hardly. From what you've just said, this provides them an /ideal/ hiding > > place (as you put it) - > > > > "Hello, Mr. Spammer. Do you want us to publish your contact information?" > > "No. I'd prefer that Spamhaus (or whoever) didn't find me this time around. > > Please force my millions of foreign victims to resort to expensive > > cross-border legal instruments" > > "Ah, that'd do nicely, sir - we can even reduce the funding for our AUP team > > without anyone being the wiser" > > With policy as it stands today, you may have no complete, valid > information to do much of anything anyway. Unfortunately so. Although I have no real estimation of what percentage is junk. I would, however, suspect that the number is considerably lower than 100%. > Retaining the client name doesn't help you. I would disagree. Admittedly, I've only used it a /few/ times to track-down and then block particular spammers, but even something partially there is better than nothing at all. Not as good as guaranteed information, sure, (as though there was any such thing) but better than the equivalent of "somewhere in AT&T"! (No slur on AT&T or its users is intended - it's just an example of who would have to handle all complaints for (e.g.) Comcast in this Brave New World of minimal WHOIS. Regards, Ian Baker Webmaster, codecutters.org P.S. As a general comment on the origins of WHOIS, and not directed to any specific individual(s): " This server, together with the corresponding WHOIS Database can also deliver online look-up of individuals or their online mailboxes, network organizations, DDN nodes and associated hosts, and TAC telephone numbers. The service is designed to be user-friendly and the information is delivered in human-readable format. DCA strongly encourages network hosts to provide their users with access to this network service. WHO SHOULD BE IN THE DATABASE DCA requests that each individual with a directory on an ARPANET or MILNET host, who is capable of passing traffic across the DoD Internet, be registered in the NIC WHOIS Database. MILNET TAC users must be registered in the database." Source: RFC-954 From owen at delong.com Thu Nov 20 11:30:10 2003 From: owen at delong.com (Owen DeLong) Date: Thu, 20 Nov 2003 08:30:10 -0800 Subject: [ppml] Policy Proposal -- Limit Scope of Anonymous Allocations In-Reply-To: References: Message-ID: <2147483647.1069317010@imac-en0.delong.sj.ca.us> I agree that it is not necessary to know the identity of individuals using individual IP addresses or their physical location. However, we're not talking about that with 2003-3 or my proposal. We're talking about blocks of IP addresses, and, unless that organization also agrees to be legally liable for damages inflicted from those addresses, then the stewardship role is meaningless from a legal perspective. As such, additional granularity is necessary in the database for block allocations. Owen --On Thursday, November 20, 2003 11:17 AM +0000 Michael.Dillon at radianz.com wrote: >> While I agree that the provider type 1 case would be nice to solve, I > think >> it would be hard to do that. I'm open to suggestions on how we could do >> so and I would support a reasonable policy in such case. > > It's not up to ARIN to solve any of these cases. Therefore, there is > no such thing as a reasonable policy in this context. > > The world does not need to know the identity of individuals using > IP addresses and it does not need to know the physical location > of individuals using IP addresses. All the world needs to know is > which organization fulfills the stewardship role for any given > range of IP addresses. If there are any abuse issues with a > certain IP address, it is both necessary and suficient for ARIN's > database to identify the organization to which they have delegated > the stewardship role. > > > --Michael Dillon > > > > > > > > -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Michael.Dillon at radianz.com Thu Nov 20 12:25:50 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 20 Nov 2003 17:25:50 +0000 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 Message-ID: >WHO SHOULD BE IN THE DATABASE > DCA requests that each individual with a directory on an ARPANET or > MILNET host, who is capable of passing traffic across the DoD > Internet, be registered in the NIC WHOIS Database. MILNET TAC users > must be registered in the database." That's the RFC origins which I paraphrased earlier. But I also said that whois was apparently established for funding reasons, i.e. to identify the users of a resource that someone else was paying for as part of justifying that funding. Here is a DDN management bulletin regarding TAC users that might clarify this: http://www.phreak.org/archives/The_Hacker_Chronicles_II/network2/26.txt The way things stand now, there is no good documented reason whatsoever for having any sort of whois directory including ARIN's SWIP database. The only justifications in the documents are, 1) tradition, 2) the need for military research network users to justify their funding. We could always punt the problem in the general direction of the IETF and ICANN but, somehow I think we could come up with a more reasonable solution within ARIN. --Michael Dillon Here is some more whois history http://cs-www.ncsl.nist.gov/secalert/ddn/DCA_Circular.310-P115-1 http://www.digital-root.com/database/textfiles/guides/arpanet2.txt http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8708.mm.www/0045.html http://www-mice.cs.ucl.ac.uk/multimedia/misc/tcp_ip/8811.mm.www/0037.html http://www.phreak.org/archives/The_Hacker_Chronicles_II/network2/84.txt http://www.sri.ucl.ac.be/normes/rfc/ien103.txt From ibaker at codecutters.org Thu Nov 20 16:30:14 2003 From: ibaker at codecutters.org (Ian Baker) Date: Thu, 20 Nov 2003 21:30:14 -0000 Subject: [ppml] Last Call for Comment: Policy Proposal 2003-3 References: Message-ID: <007801c3afad$7eba08b0$642fa8c0@codecutters.org> ----- Original Message ----- From: To: Sent: Thursday, November 20, 2003 5:25 PM Subject: Re: [ppml] Last Call for Comment: Policy Proposal 2003-3 > >WHO SHOULD BE IN THE DATABASE > > > DCA requests that each individual with a directory on an ARPANET or > > MILNET host, who is capable of passing traffic across the DoD > > Internet, be registered in the NIC WHOIS Database. MILNET TAC users > > must be registered in the database." > > That's the RFC origins which I paraphrased earlier. But I also said > that whois was apparently established for funding reasons, i.e. to > identify the users of a resource that someone else was paying for > as part of justifying that funding. Here is a DDN management bulletin > regarding TAC users that might clarify this: > http://www.phreak.org/archives/The_Hacker_Chronicles_II/network2/26.txt > > The way things stand now, there is no good documented reason whatsoever > for having any sort of whois directory including ARIN's SWIP database. > The only justifications in the documents are, 1) tradition, 2) the need > for military research network users to justify their funding. We could > always punt the problem in the general direction of the IETF and ICANN > but, somehow I think we could come up with a more reasonable solution > within ARIN. I'd read that paragraph again, if I were you - the bit that starts with "designed to be user friendly" and continues "strongly encourages network hosts to provide their users with access". Now, you've just stated that "there is no good documented reason", and followed with "the only justifications in the documents", which is a bit self-contradictory for yourself and picky of me to point out. So, assuming that this searchable list can be considered a document, how about "WHOIS is very useful in fighting spam and other 'net abuse". There. That's published. http://www.google.co.uk/search?q=spam+whois&ie=UTF-8&oe=UTF-8&hl=en&meta= Gets you a "few" more. The number isn't readily quantifiable, so I've resorted to the Google/DejaNews archive - the first of such use published on Usenet (and retained) seems to be from 1990, with a total of around 126k in the archive. The discussion that we're having right now would appear to have surfaced on Usenet in 1989... Now, among the things that would be less than useful to people trying to trace spam (who, for example, have been unable to get a decent response from the quite probably overworked AUP team of a large ISP) is the prospect of deleting the entire contents and starting from scratch. All I'm saying is that - for the majority of the /users/ of said data, unintended , untidy, or otherwise - the idea that you proposed would make life a lot more difficult. There's proof enough outside of the US if you care to look into what can happen if information is dumped. This is, in any event, straying further and further from the actual proposal under discussion; which I would be happy to support. Regards, Ian Baker Webmaster, codecutters.org From cjw at groovy.com Fri Nov 21 00:31:22 2003 From: cjw at groovy.com (CJ Wittbrodt) Date: Thu, 20 Nov 2003 21:31:22 -0800 Subject: [ppml] Policy Proposal -- Limit Scope of Anonymous Allocations In-Reply-To: Message from J Bacher of "Wed, 19 Nov 2003 15:08:32 CST." <5.1.0.14.2.20031119150743.034df340@mail.jbacher.com> Message-ID: <200311210531.hAL5VMs65591@duchess.groovy.com> This may be true but in some places it can take close to a year to get one. I am not kidding, I lived it. It'd be fun to have to put off getting a connection because of the wait for a PO box.. ----CJ From: J Bacher Subject: Re: [ppml] Policy Proposal -- Limit Scope of Anonymous Allocations At 11:28 AM 11/19/2003 -0800, you wrote: >The rich and famous don't need their ISP for privacy. They would register >both under some corporation they own with a P.O. Box. Sorry, no sale as >far as I'm concerned. One doesn't need to be either rich or famous to use a PO Box. Unless PO Boxes in your part of the world are exhorbitantly expensive. From owen at delong.com Fri Nov 21 12:49:09 2003 From: owen at delong.com (Owen DeLong) Date: Fri, 21 Nov 2003 09:49:09 -0800 Subject: [ppml] Policy Proposal -- Limit Scope of Anonymous Allocations In-Reply-To: <200311210531.hAL5VMs65591@duchess.groovy.com> References: <200311210531.hAL5VMs65591@duchess.groovy.com> Message-ID: <2147483647.1069408149@imac-en0.delong.sj.ca.us> While there may be an extended wait for a P.O. Box at the local post office, there are usually alternatives that work just as well. Most Mailboxes Etc. and their ilk have boxes for rent. Usually if you go to the next nearest Post Offices, you can find boxes available. Finally, there are a number of mail forwarding services available which allow you to essentially anonymize your address. Owen --On Thursday, November 20, 2003 9:31 PM -0800 CJ Wittbrodt wrote: > > This may be true but in some places it can take close to a year to > get one. I am not kidding, I lived it. It'd be fun to have to put > off getting a connection because of the wait for a PO box.. > > ----CJ > > From: J Bacher > Subject: Re: [ppml] Policy Proposal -- Limit Scope of Anonymous > Allocations > At 11:28 AM 11/19/2003 -0800, you wrote: > >The rich and famous don't need their ISP for privacy. They would > register >both under some corporation they own with a P.O. Box. > Sorry, no sale as >far as I'm concerned. > > One doesn't need to be either rich or famous to use a PO Box. Unless > PO Boxes in your part of the world are exhorbitantly expensive. > -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From billd at cait.wustl.edu Fri Nov 21 15:04:51 2003 From: billd at cait.wustl.edu (Bill Darte) Date: Fri, 21 Nov 2003 14:04:51 -0600 Subject: [ppml] Reminder about Policy Proposal 2002-3 Message-ID: Hello all, I am the shephard for this policy proposal on the ARIN AC and will be gathering the comments pro and con. I would like to remind everyone, that the proposed policy, while succinct now, had as an adjunct when proposed, some other language. That language was associated with monitoring the impact of lowering the minimum allocation and assignment boundary for multihomed blocks to /22. Some, more than others, were/are concerned that there may be negative impact to the size of the routing table, the number of requests and therefore the amount of IP space, ARIN staff impact, etc. I would like to request everyone interested in this policy that thinks there will be negative impacts to identify them and also suggest means by which such impact might be measured. Also, I would be interested in the period over which you believe such assessment should be conducted before one might reasonably proclaim impact or lack thereof. I would like your considered and succinct recommendations related to this matter to be posted to this list at your earliest convenience. As always, I thank you for your participation in the ARIN public policy process and I am happy to hear from you on this or any other matter of concern to you. Happy Holidays to all! Bill Darte ARIN AC -----Original Message----- From: Member Services To: ppml at arin.net Sent: 11/18/03 1:05 PM Subject: [ppml] Last Call for Comment: Policy Proposal 2002-3 The ARIN Advisory Council voted to forward the following policy proposal to the ARIN Board of Trustees for consideration. This is a last call for comments on this policy proposal prior to the ARIN Board of Trustees review. Comments received during this period will be included with the proposal when it is presented to the Board of Trustees for their consideration. Please send your comments to ppml at arin.net. This last call will expire at 23:59 EST on December 3, 2003. Member Services American Registry for Internet Numbers (ARIN) *** Last Call: Policy Proposal 2002-3: Micro-Assignments for Multihomed Networks *** Multi-homed organizations may justify and obtain a block of address space with prefix length extending to /22 directly from ARIN. When prefixes are longer than /20, these micro-allocations or micro-assignments will be from a reserved block for that purpose. ## END ## From cjw at groovy.com Fri Nov 21 15:22:07 2003 From: cjw at groovy.com (CJ Wittbrodt) Date: Fri, 21 Nov 2003 12:22:07 -0800 Subject: [ppml] Policy Proposal -- Limit Scope of Anonymous Allocations In-Reply-To: Message from Owen DeLong of "Fri, 21 Nov 2003 09:49:09 PST." <2147483647.1069408149@imac-en0.delong.sj.ca.us> Message-ID: <200311212022.hALKM7s70459@duchess.groovy.com> Owen, I have to say that I don't feel that I should have to do this. I am paying my ISP for a service. That service includes them dealing with abuse complaints. My ISP is very happy to do that for me. I don't want my address and phone in the database. I don't think I should have to jump through hoops to anonymize my info. Besides that doesn't at all help the spam issue anyway. So we all anonymize ourselves and then there isn't even an ISP contact. Representing only myself here.. ---CJ From: Owen DeLong Subject: Re: [ppml] Policy Proposal -- Limit Scope of Anonymous Allocations --==========BBF1457510A2AAF3C20B========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline While there may be an extended wait for a P.O. Box at the local post = office, there are usually alternatives that work just as well. Most Mailboxes Etc. and their ilk have boxes for rent. Usually if you go to the next nearest Post Offices, you can find boxes available. Finally, there are a number of mail forwarding services available which allow you to essentially anonymize your address. Owen --On Thursday, November 20, 2003 9:31 PM -0800 CJ Wittbrodt=20 wrote: > > This may be true but in some places it can take close to a year to > get one. I am not kidding, I lived it. It'd be fun to have to put > off getting a connection because of the wait for a PO box.. > > ----CJ > > From: J Bacher > Subject: Re: [ppml] Policy Proposal -- Limit Scope of Anonymous > Allocations > At 11:28 AM 11/19/2003 -0800, you wrote: > >The rich and famous don't need their ISP for privacy. They would > register >both under some corporation they own with a P.O. Box. > Sorry, no sale as >far as I'm concerned. > > One doesn't need to be either rich or famous to use a PO Box. Unless > PO Boxes in your part of the world are exhorbitantly expensive. > --=20 If it wasn't crypto-signed, it probably didn't come from me. --==========BBF1457510A2AAF3C20B========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) iD8DBQE/vlAan5zKWQ/iqj0RAtKyAJ42tdbRDpt9gr7yXgHklsqPwi13zACeLQqa K4zDX+H1jczRb4GvXkdo3ls= =SCVg -----END PGP SIGNATURE----- --==========BBF1457510A2AAF3C20B==========--