From memsvcs at arin.net Thu Aug 12 10:35:38 2004 From: memsvcs at arin.net (Member Services) Date: Thu, 12 Aug 2004 10:35:38 -0400 (EDT) Subject: [ppml] Deadline for Policy Proposals - August 21 Message-ID: <200408121435.KAA24452@ops.arin.net> The ARIN XIV Public Policy Meeting will take place October 20-21, 2004, in Reston, Virginia. New policy proposals must be submitted by 23:59 EST on Saturday, August 21, 2004, in order to be considered by the ARIN Advisory Council for possible inclusion on the ARIN XIV agenda. This is in accordance with ARIN's Internet Resource Policy Evaluation Process, which indicates that proposed policies must be submitted at least 60 days prior to the meeting. Those who wish to propose new ARIN number resource policies or modifications to existing ARIN number resource policies must submit a completed Policy Proposal Template. The template must be submitted via e-mail to policy at arin.net. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/ipep.html The Policy Proposal Template can be found at: http://www.arin.net/policy/irpep_template.html Regards, Member Services American Registry for Internet Numbers (ARIN) From Michael.Dillon at radianz.com Thu Aug 12 11:01:01 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Thu, 12 Aug 2004 16:01:01 +0100 Subject: [ppml] Deadline for Policy Proposals - August 21 In-Reply-To: <200408121435.KAA24452@ops.arin.net> Message-ID: >The ARIN XIV Public Policy Meeting will take place October 20-21, >2004, in Reston, Virginia. New policy proposals must be submitted by >23:59 EST on Saturday, August 21, 2004, in order to be considered Just out of curiosity, has anyone at all submitted any new policy proposals since the last meeting? The list has been very quiet since then. ------------------------------------------------------- Michael Dillon Capacity Management, 66 Prescot St., London, E1 8HG, UK Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 http://www.radianz.com Voted "Best Network Provider 2004" Waters Magazine From einarb at arin.net Thu Aug 12 12:08:37 2004 From: einarb at arin.net (Einar Bohlin) Date: Thu, 12 Aug 2004 12:08:37 -0400 Subject: [ppml] Deadline for Policy Proposals - August 21 In-Reply-To: Message-ID: Hi Michael, > Just out of curiosity, has anyone at all submitted any new > policy proposals since the last meeting? We have not received any new policy proposals since the last meeting. Regards, Einar Bohlin - Policy Analyst, ARIN einarb at arin.net +1 703 227-9867 - > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On Behalf Of > Michael.Dillon at radianz.com > Sent: Thursday, August 12, 2004 11:01 AM > To: ppml at arin.net > Subject: Re: [ppml] Deadline for Policy Proposals - August 21 > > >The ARIN XIV Public Policy Meeting will take place October 20-21, > >2004, in Reston, Virginia. New policy proposals must be submitted by > >23:59 EST on Saturday, August 21, 2004, in order to be considered > > > The list has been very quiet since then. > > ------------------------------------------------------- > Michael Dillon > Capacity Management, 66 Prescot St., London, E1 8HG, UK > Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com > Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 > > http://www.radianz.com > Voted "Best Network Provider 2004" Waters Magazine From John.Sweeting at teleglobe.com Thu Aug 19 17:36:56 2004 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Thu, 19 Aug 2004 17:36:56 -0400 Subject: [ppml] FW: [arin-council] IANA to RIR IPv6 Allocation Message-ID: <1797AB680DD0D2118987009027178032132DC926@camtmms01.Teleglobe.CA> I am submitting the following proposal IAW ARIN's Internet Resource Policy Evaluation Process. In the interest of all I would like to disclose up front that the information used to prepare this template was provided by ARIN staff. ############################################ Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 1. Policy Proposal Name: Allocation of IPv6 Address Space by the Internet Assigned Numbers Authority (IANA) Policy to Regional Internet Registries 2. Author a. name: John Sweeting b. email: john.sweeting at teleglobe.com c. telephone: 703-766-3042 d. organization: ARIN Advisory Council 3. Proposal Version: 1 4. Submission Date: 8/17/04 5. Proposal type: new, global 6. Policy term: permanent 7. Policy statement: 1. Minimum Allocation Size. The minimum size of any allocation of IPv6 address space from IANA to an RIR is prefix length /12. If this address space is not sufficient to meet the needs of an RIR for a projected 18 month period, IANA shall allocate to that RIR the address space for which it can provide justification. 2. Reservation of Unicast Address space. 2.1 IANA. By RFC 3513 the IANA has been allocated the range of IPv6 addresses beginning at binary value 001 (prefix length /3) for its allocations of unicast address space. In order to support regional aggregation of IPv6 address space IANA shall establish a reservation of a prefix length of /6 from this space for each established RIR and for each emerging RIR. Allocations to each RIR will be from the appropriate reservation. 2.2. RIRs. Each RIR may apply its own respective chosen allocation and reservation strategy in order to meet the needs of its community and to ensure the efficiency and efficacy of its work. Such reservations made by an RIR will be considered as being allocated by that RIR when that RIR applies for an allocation of address space from the IANA. 3. Initial Allocation. 3.1. Upon implementation of this policy IANA shall allocate to each established RIR a /12 from the reservation established for each particular RIR. 3.2. Upon recognition of an RIR by ICANN that RIR shall receive a /12 from the reservation set aside for that RIR. 4. Subsequent Allocation. An RIR shall be eligible for an allocation of at least a minimal allocation from the IANA when its current holdings are less than 50% of its 18 month requirement or when it has less than 180 days of holdings available. The IANA shall evaluate the requested allocation using a set of administrative procedures that are mutually agreed to by the IANA and the NRO. This set of procedures shall be enacted within 30 days of the implentation of this policy. 5. Announcement of IANA allocations to the RIRs 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 IANA will make appropriate modifications to the "Internet Protocol V6 Address Space" page of the IANA website and may make announcements to only its own global announcement lists. The IANA announcements will be limited to which address ranges, the time of allocation and to which Registry they have been allocated. 8. Rationale: The current IANA allocation policy for IPv6 is an interim policy that was promulgated in 1999. Operational experience has demonstrated the current minimum allocation size is too small; that the built in reservation system that must be followed by the RIRs does not allow for efficient and effective management of the resource by the RIR; and does not provide for an well known evaluation criteria. This document does not stipulate performance requirements in the provision of services by IANA to an RIR in accordance with the policy. Such requirements should be specified by appropriate agreements between the NRO and ICANN. 9. Timetable for implementation: Thirty days after ratification by the ICANN Board of Directors in accordance with the global policy development process. 10. Meeting presenter: Elected AC Member or the President of ARIN. END OF TEMPLATE ################################################ From billd at cait.wustl.edu Thu Aug 19 18:00:42 2004 From: billd at cait.wustl.edu (Bill Darte) Date: Thu, 19 Aug 2004 17:00:42 -0500 Subject: [ppml] Policy Proposal: Address Space for Multiple Discrete Networks Message-ID: <50C9C45A7E8DCE41A19F7A94715BABFD02A336@kronos.cait.wustl.edu> I am submitting the following proposal IAW ARIN's Internet Resource Policy Evaluation Process. In the interest of all I would like to disclose up front that the information used to prepare this template was provided by ARIN staff. ############################################ Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 1. Policy Proposal Name: Address Space for Multiple Discrete Networks 2. Author a. name: Bill Darte b. e-mail: billd at cait.wustl.edu c. telephone: 314 935-7575 d. organization: ARIN Advisory Council 3. Proposal Version: 1 4. Submission Date: August 18, 2004 5. Proposal type: Replace existing Policy 2001-6 6. Policy term: Permanent 7. Policy statement: Organizations with multiple discrete networks desiring to request new or additional address space under a single Organization ID must meet the following criteria: (1) The organization shall be a single entity and not a consortium of smaller independent entities. (2) The organization must have compelling criteria for creating discrete networks. Examples of a discrete network might include: * Regulatory restrictions for data transmission, * Geographic distance and diversity between networks, * Autonomous multi-homed discrete networks. (3) The organization must keep detailed records on how it has allocated space to each location, including the date of each allocation. (4) When applying for additional space from ARIN, the organization must show greater than 50% utilization for both the last block allocated by ARIN, and their allocations from ARIN as a whole. If an organization is unable to meet this 50% criteria, the organization must not have a /20 or shorter prefix available when requesting additional space. (5) The organization may not allocate additional address space to a location until each of that location's address blocks are 80% utilized. (6) The organization should notify ARIN at the time of the request their desire to apply this policy to their account. This policy supersedes policy 2001-6. 8. Rationale: a. Contradictions contained within policy 2001-6 have been removed and replaced with clear, concise text. b. Much of the procedural language contained in 2001-6 has been removed and replaced with policy language. c. 2001-6 made it difficult for smaller organizations to qualify as they were frequently unable to meet the 50% criteria before needing additional space for existing or new locations. The new policy utilization structure now allows both smaller and larger organizations to qualify. 9. Timetable for Implementation: 30 days after ratification of the policy by the ARIN BoT 10. Meeting presenter: ARIN AC member END OF TEMPLATE ############################################ From sandyg at skat.usc.edu Thu Aug 19 18:36:00 2004 From: sandyg at skat.usc.edu (sandyg) Date: Thu, 19 Aug 2004 15:36:00 -0700 (PDT) Subject: [ppml] Privacy of Reassignment Information Message-ID: I am submitting the following proposal IAW ARIN's Internet Resource Policy Evaluation Process. In the interest of all I would like to disclose up front that the information used to prepare this template was provided by ARIN staff. ############################################ Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 1. Policy Proposal Name: Privacy of Reassignment Information 2. Author a. name: Sanford George b. e-mail: sandyg at usc.edu c. telephone: 213-740-1473 d. organization: ARIN AC 3. Proposal Version: 1 4. Submission Date: 8/17/04 5. Proposal type: modify 6. Policy term: permanent 7. Policy Statement: ISPs may choose whether or not to designate reassignment information 'public'. Reassignment information that is not designated 'public' will be available only to ARIN, the entity that created it, and that entity's upstream organizations. The maintenance of the accuracy of the data that is submitted whether it is public or private is the responsibility of the submitting ISP. 8. Rationale: Increasing concern about protection of private information on the Internet has been expressed by many parts of the community. There have been numerous policy proposals over the last several years attempting to protect various portions of the displayed information. Concern has been expressed specifically about the requirement to publicly register customer assignments, which are often regarded by ISPs and customers as private information. By publicly displaying reassignment information, the ISP is in some respects displaying its customer lists and other information that may be considered of a proprietary business interest. 9. Timetable for implementation: 30 days after the ratification of the policy by the ARIN Board of Trustees 10. Meeting presenter: Sanford George END OF TEMPLATE ################################## From plzak at arin.net Fri Aug 20 08:01:41 2004 From: plzak at arin.net (Ray Plzak) Date: Fri, 20 Aug 2004 08:01:41 -0400 Subject: [ppml] FW: [address-policy-wg] Re: IANA to RIR IPv6 Allocation Message-ID: <20040820120143.1A2F6CF39E@mercury.arin.net> -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Wilfried Woeber, UniVie/ACOnet Sent: Friday, August 20, 2004 7:50 AM To: address-policy-wg at ripe.net Cc: ipv6-wg at ripe.net; woeber at cc.univie.ac.at Subject: [address-policy-wg] Re: IANA to RIR IPv6 Allocation I've got one comment here on section 7. paragraph 4. "Subsequent Allocation": While the wording might be sufficiently clear for a native speaker by referring to "set of administrative procedures....", I am missing clear guidance for the IANA that there should _not_ be any incentive or responsibilty to consult with other groups, entities or third parties (irrespective of their, say, credibility for e.g. protocol development or technical specifications) which would require extending that 30 day period. My proposal would be that IANA would have to perform the subsequent allocation within this 30 day period, even if they might not be able to obtain advice or an expertise (for whatever reason) from any other party they might have decided to ask for advice. Wilfried ( https://cert.aco.net/ ) _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...there's no place like 127.0.0.1 (or ::1/128 ?) From: David Kessens To: Jeroen Massar Date: Fri, 20 Aug 2004 01:48:52 -0700 CC: ipv6-wg at ripe.net Subject: Re: [ipv6-wg at ripe.net] FW: [arin-council] IANA to RIR IPv6 Allocation Jeroen, On Fri, Aug 20, 2004 at 09:25:59AM +0200, Jeroen Massar wrote: > For people not on the arin-council (not likely ;) or the ppml at arin > lists: All policy discussions for the RIPE region are now conducted at the RIPE policy working group maillist: address-policy-wg at ripe.net David Kessens --- > -----Forwarded Message----- > From: "Sweeting, John" > To: 'ppml at arin.net' > Subject: [ppml] FW: [arin-council] IANA to RIR IPv6 Allocation > Date: Thu, 19 Aug 2004 17:36:56 -0400 > > I am submitting the following proposal IAW ARIN's Internet Resource Policy > Evaluation Process. In the interest of all I would like to disclose up front > that the information used to prepare this template was provided by ARIN > staff. > > > ############################################ > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 > > 1. Policy Proposal Name: Allocation of IPv6 Address Space by the Internet > Assigned Numbers Authority (IANA) Policy to Regional Internet Registries > > 2. Author > > a. name: John Sweeting > b. email: john.sweeting at teleglobe.com > c. telephone: 703-766-3042 > d. organization: ARIN Advisory Council > > 3. Proposal Version: 1 > > 4. Submission Date: 8/17/04 > > 5. Proposal type: new, global > > 6. Policy term: permanent > > 7. Policy statement: > > 1. Minimum Allocation Size. > > The minimum size of any allocation of IPv6 address space from IANA to an RIR > is prefix length /12. If this address space is not sufficient to meet the > needs of an RIR for a projected 18 month period, IANA shall allocate to that > RIR the address space for which it can provide justification. > > 2. Reservation of Unicast Address space. > > 2.1 IANA. By RFC 3513 the IANA has been allocated the range of IPv6 > addresses beginning at binary value 001 (prefix length /3) for its > allocations of unicast address space. In order to support regional > aggregation of IPv6 address space IANA shall establish a reservation of a > prefix length of /6 from this space for each established RIR and for each > emerging RIR. Allocations to each RIR will be from the appropriate > reservation. > > 2.2. RIRs. Each RIR may apply its own respective chosen allocation and > reservation strategy in order to meet the needs of its community and to > ensure the efficiency and efficacy of its work. Such reservations made by > an RIR will be considered as being allocated by that RIR when that RIR > applies for an allocation of address space from the IANA. > > 3. Initial Allocation. > > 3.1. Upon implementation of this policy IANA shall allocate to each > established RIR a /12 from the reservation established for each particular > RIR. > > 3.2. Upon recognition of an RIR by ICANN that RIR shall receive a /12 from > the reservation set aside for that RIR. > > > 4. Subsequent Allocation. > > An RIR shall be eligible for an allocation of at least a minimal allocation > from the IANA when its current holdings are less than 50% of its 18 month > requirement or when it has less than 180 days of holdings available. The > IANA shall evaluate the requested allocation using a set of administrative > procedures that are mutually agreed to by the IANA and the NRO. This set of > procedures shall be enacted within 30 days of the implentation of this > policy. > > > 5. Announcement of IANA allocations to the RIRs > > 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 IANA will make appropriate modifications to the "Internet Protocol V6 > Address Space" page of the IANA website and may make announcements to only > its own global announcement lists. The IANA announcements will be limited > to which address ranges, the time of allocation and to which Registry they > have been allocated. > > > 8. Rationale: > > The current IANA allocation policy for IPv6 is an interim policy that was > promulgated in 1999. Operational experience has demonstrated the current > minimum allocation size is too small; that the built in reservation system > that must be followed by the RIRs does not allow for efficient and effective > management of the resource by the RIR; and does not provide for an well > known evaluation criteria. This document does not stipulate performance > requirements in the provision of services by IANA to an RIR in accordance > with the policy. Such requirements should be specified by appropriate > agreements between the NRO and ICANN. > > > 9. Timetable for implementation: Thirty days after ratification by the ICANN > Board of Directors in accordance with the global policy development process _______________________________________________ From rdasilva at va.rr.com Fri Aug 20 09:49:13 2004 From: rdasilva at va.rr.com (da Silva, Ron) Date: Fri, 20 Aug 2004 09:49:13 -0400 Subject: [ppml] Privacy of Reassignment Information Message-ID: <5D200A6BB92BB54F8E2FED8E4A28D763020FB092@RRMAILER.rr.com> > 7. Policy Statement: > > ISPs may choose whether or not to designate reassignment information > 'public'. Reassignment information that is not designated 'public' will be > available only to ARIN, the entity that created it, and that entity's > upstream organizations... By "upstream" organizations, I presume this pertains to address allocations or delegations not any topological significance? -ron From plzak at arin.net Fri Aug 20 13:57:51 2004 From: plzak at arin.net (Ray Plzak) Date: Fri, 20 Aug 2004 13:57:51 -0400 Subject: [ppml] FW: [ipv6-wg@ripe.net] RE: [address-policy-wg] Re: IANA to RIR IPv6 Allocation Message-ID: <20040820175752.48DACCF39E@mercury.arin.net> -----Original Message----- From: Iljitsch van Beijnum [mailto:iljitsch at muada.com] Sent: Friday, August 20, 2004 8:38 AM To: Ray Plzak Cc: ; Subject: Re: [ipv6-wg at ripe.net] RE: [address-policy-wg] Re: IANA to RIR IPv6 Allocation On 20-aug-04, at 14:01, Ray Plzak wrote: > Wilfried, > I've forwarded your comment to the ARIN ppml. Ray, as long as you're forwarding, maybe you'll find my comment to the RIPE list from a week and a half ago of interest: > The Number Resource Organisation (NRO) has published a proposal for a > policy for the allocation of IPv6 address space from the IANA to the > RIRs. It is intended that this proposed policy should be agreed by all > RIRs' open policy fora and then approved by the ASO and ICANN as a > global policy. Reserving a /6 for each RIR seems like the other extreme to me. In IPv4 we have around 220 /8s that have been given out to RIRs pretty much one at a time in the past. In IPv6 we effectively have 8 /6s. This means that as a percentage of total available space, the RIRs get more than 25 times more IPv6 space than they've been given IPv4 space in the past, even though a v4 /8 will accommodate at most 16.8M end-user assignments (less in practice) while a v6 /6 allows for AT LEAST 4.4T (yes, that's 10^12) end-user assignments. Now I can see SOME value in trying to have relatively large RIR blocks, but cutting up all non-reserved space so aggressively really doesn't have any upsides, and we never know whether we're going to need any really large blocks in the future. Also, doubling every time is ok for a while, but it pretty much guarantees that you're going to have way too much space on your hands at some point. A more reasonable policy would be: - reserve a /12 for each RIR now (a 4 bit boundary makes DNS delegations easier, I think a /8 is too much but that might work also) - then, for every delegation, give RIRs enough space to each to last a year comfortably - evaluate whether a new delegation is needed every 3 or 4 months, making the time of new delegations easy to predict From william at elan.net Fri Aug 20 14:32:44 2004 From: william at elan.net (william(at)elan.net) Date: Fri, 20 Aug 2004 11:32:44 -0700 (PDT) Subject: [ppml] Privacy of Reassignment Information In-Reply-To: Message-ID: This is really bad policy proposal. It disallows ability to do proper research on the ip allocations, including geographical mapping of ip usage, mapping of activity by organization type, etc. It significantly helps bad guys avoid responsibility and makes tracking them down much more difficult. It disallows ability to do public audits of arin and that it is making proper size allocations and assignments. It disallows ability for ISPs to confirm who customer is when request for BGP route from new customer comes in and this may result is improper routing decisions. Also disallows ability for ISP to know when customer should be referred to ARIN because of large space that they may have with different ISP already and thus may increase segmentation of ip space. And at the same time this gains no technical advantage as all swips still have to be registered and maintained in the database same way. This also goes against policies established by other RIRs which require reassignment information be entered in their DBs and this is at the time when we're trying to get policies of RIRs to be more similar and more unified. I'll be sure to add a lot more comments about above problems in detail when we're actually discussing this, right now I just don't have time for more. > Date: Thu, 19 Aug 2004 15:36:00 -0700 (PDT) > From: sandyg > To: ppml at arin.net > Subject: [ppml] Privacy of Reassignment Information > > I am submitting the following proposal IAW ARIN's Internet Resource Policy > Evaluation Process. In the interest of all I would like to disclose up > front that the information used to prepare this template was provided by > ARIN staff. > > ############################################ > > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 > > 1. Policy Proposal Name: Privacy of Reassignment Information > > 2. Author > a. name: Sanford George > b. e-mail: sandyg at usc.edu > c. telephone: 213-740-1473 > d. organization: ARIN AC > > 3. Proposal Version: 1 > > 4. Submission Date: 8/17/04 > > 5. Proposal type: modify > > 6. Policy term: permanent > > 7. Policy Statement: > > ISPs may choose whether or not to designate reassignment information > 'public'. Reassignment information that is not designated 'public' will be > available only to ARIN, the entity that created it, and that entity's > upstream organizations. The maintenance of the accuracy of the data that is > submitted whether it is public or private is the responsibility of the > submitting ISP. > > 8. Rationale: > > Increasing concern about protection of private information on the Internet > has been expressed by many parts of the community. There have been numerous > policy proposals over the last several years attempting to protect various > portions of the displayed information. Concern has been expressed > specifically about the requirement to publicly register customer > assignments, which are often regarded by ISPs and customers as private > information. > > By publicly displaying reassignment information, the ISP is in some respects > displaying its customer lists and other information that may be considered > of a proprietary business interest. > > > 9. Timetable for implementation: 30 days after the ratification of the > policy by the ARIN Board of Trustees > > 10. Meeting presenter: Sanford George > > END OF TEMPLATE > ################################## From william at elan.net Fri Aug 20 20:33:35 2004 From: william at elan.net (william(at)elan.net) Date: Fri, 20 Aug 2004 17:33:35 -0700 (PDT) Subject: [ppml] Amendment to Residential Customer Privacy Policy Message-ID: Template: ARIN-POLICY-PROPOSAL-TEMPLATE-1.0 1. Policy Proposal Name: Residential Customer Privacy Policy 2. Author name: William Leibzon a. e-mail: william at elan.net b. telephone: 206-600-4982 (voice-mail pager only) c. organization: Elan Networks 3. Proposal Version: 1.0 4. Submission Date: 08-20-04 5. Proposal type: modify 6. Policy term: permanent 7. Policy statement: An organization with downstream residential customer who is not engaged in business activities 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 be less then or equal to 128 ips and have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block. 8. Rationale: The intent of residential customer privacy was to allow private citizens to have privacy and safety in their personal life while being able to request and use more then 8 ip addresses with residenial dsl line. However soon after implementation it became clear that some of the ip blocks being designated as "Private customer" are being used for business purposes which is clearly seen by size of such reassignments as 69.111.160.0/22. While it is not unexpected that some people may run business (including internet businesses) from their home, the laws regard such activity as being similar to running business from small office and usually require such businesses to receive a license from appropriate local or state agency and to disclose the activity to the public, as such different privacy rules apply in these situations. This policy replaces current residential customer privacy 2003-3 and requires that ISPs only designate reassignment whois data as "Private Customer" if no business activity is involved with use of the ip block. The limit for the reassignment is set to 128 ips as larger number of computers in one residence is likely an indication of business activity (as an example currently telephone companies allow up to 4 residential telephone lines and if somebody needs larger number of telephone lines to his home, those must be purchased as business telephone lines). Additionally the amendment fixes small grammer error in current policy text that involves incorrect use of plural and singular tenses. 9. Timetable for implementation: 30 days or less after approval by BoT 10. Meeting presenter: to be designated by ARIN staff or by ARIN AC (policy author most likely will be enable to come to next ARIN meeting). END OF TEMPLATE From Michael.Dillon at radianz.com Mon Aug 23 04:42:48 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Mon, 23 Aug 2004 09:42:48 +0100 Subject: [ppml] Privacy of Reassignment Information In-Reply-To: Message-ID: > This is really bad policy proposal. It disallows ability to do proper > research on the ip allocations, including geographical mapping of ip usage, > mapping of activity by organization type, etc. It significantly helps > bad guys avoid responsibility and makes tracking them down much more > difficult. It disallows ability to do public audits of arin and that > it is making proper size allocations and assignments. It disallows > ability for ISPs to confirm who customer is when request for BGP route > from new customer comes in and this may result is improper routing > decisions. Also disallows ability for ISP to know when customer should be > referred to ARIN because of large space that they may have with different > ISP already and thus may increase segmentation of ip space. It doesn't really disallow most of these things. It just requires people to contact the upstream ISP and ask for the information. If there is a legitimate use for the information then it will still be available. Basically, there is no consensus in the community defining the whois database and its purpose. Only vague traditions based upon a completely different environment in the historical ARPANET. Unfortunately this policy makes no attempt to define legitimate uses for information but then, we've seen in the past that more detailed policy proposals have not made it past the ARIN meeting. That's politics for you... Michael Dillon From william at elan.net Mon Aug 23 07:09:18 2004 From: william at elan.net (william(at)elan.net) Date: Mon, 23 Aug 2004 04:09:18 -0700 (PDT) Subject: [ppml] Privacy of Reassignment Information In-Reply-To: Message-ID: On Mon, 23 Aug 2004 Michael.Dillon at radianz.com wrote: > > This is really bad policy proposal. It disallows ability to do proper > > research on the ip allocations, including geographical mapping of ip usage, > > mapping of activity by organization type, etc. It significantly helps > > bad guys avoid responsibility and makes tracking them down much more > > difficult. It disallows ability to do public audits of arin and that > > it is making proper size allocations and assignments. It disallows > > ability for ISPs to confirm who customer is when request for BGP route > > from new customer comes in and this may result is improper routing > > decisions. Also disallows ability for ISP to know when customer should be > > referred to ARIN because of large space that they may have with different > > ISP already and thus may increase segmentation of ip space. > > It doesn't really disallow most of these things. It just requires > people to contact the upstream ISP and ask for the information. If > there is a legitimate use for the information then it will still > be available. No, that just means the information is not going to be available for those who need it. I wonder how UUNET is going to act if I ask it to be a pal and open its database so I could find how many users it has and in what locations. And anyway, asking 1000+ ISPs things like that is no way to gather statistical data, the system must be automated and allow for data to be collected quickly (not waiting for so many humans to answer) and to allow step to be repeated in the future when necessary or confirmed by independent researcher. Nor do I think UUNET is going to confirm that their new assignment and customer is Scott Ritcher or answer how luch the assignment block is. But whois data would have most likely shown that with OptIn Yada Yada name and tell others to be concerned. And these are just two of the problems I mention and others are also impossible if being dependent on ISPs (i.e. like for audits, it defeats its purpose to ask ISP that got new ip block to tell me what allocations it had before so I could confirm that had used enough space to qualify for it). P.S. Apologies to UUNET/MCI people on this list if you see using your company name as anything but an example. -- William Leibzon Elan Networks william at elan.net From memsvcs at arin.net Mon Aug 23 17:02:46 2004 From: memsvcs at arin.net (Member Services) Date: Mon, 23 Aug 2004 17:02:46 -0400 (EDT) Subject: [ppml] Policy proposals - AC to conduct initial review Message-ID: ARIN received four policy proposal templates by the August 21 deadline: Amendment to Residential Customer Privacy Policy http://www.arin.net/mailing_lists/ppml/2765.html IANA to RIR IPv6 Allocation http://www.arin.net/mailing_lists/ppml/2758.html Address Space for Multiple Discrete Networks http://www.arin.net/mailing_lists/ppml/2759.html Privacy of Reassignment Information http://www.arin.net/mailing_lists/ppml/2760.html In accordance with the ARIN Internet Resource Policy Evaluation process the ARIN Advisory Council will conduct an initial review and make a decision within ten working days. For each proposal the AC will choose one of the following: 1) support the proposal as is, 2) work with the author to clarify, divide or combine one or more policy proposals, or 3) not support the policy proposal. If the AC supports a proposal or reaches an agreement to work with the author, then the proposal will be posted as a formal policy proposal to the Public Policy Mailing List and it will be presented at the Public Policy Meeting. If the AC does not support a proposal, then the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposed policy will be considered closed. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/ipep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) From gregm at datapro.co.za Tue Aug 24 19:08:27 2004 From: gregm at datapro.co.za (Gregory Massel) Date: Wed, 25 Aug 2004 01:08:27 +0200 Subject: [ppml] Privacy Legislation and new proposals affecting residential privacy Message-ID: <008001c48a2f$441c7c30$0a1929c4@groglet> Hello PPML In discussions of the privacy of residential customer information, please consider that the reach of this extends beyond ARIN itself. Various countries have enacted, or are in the process of enacting, privacy legislation. Eg. In South Africa (which presently falls within the ARIN service region), the chapter 2 of the constitution entrenches every person's rights to privacy. To further entrench individual's privacy rights beyond this general provision the Law Commission has been drafting privacy legislation that will protect personal information. It is quite likely that in the future it will be illegal for South African ISPs to publish residential customers' names and address information in the whois database. Although not strictly an issue for ARIN, it may be worth taking into consideration legislative requirements outside of the ARIN region as these demonstrate the result of extensive international consultation regarding policies of this nature. In particular, I draw your attention to the case of the EU region: http://europa.eu.int/information_society/topics/ecomm/all_about/todays_framework/privacy_protection/index_en.htm In particular, "Article 12 of the Privacy and Electronic Communications Directive therefore grants subscribers of all forms of electronic communication services (fixed or mobile telephony, e-mail) the right to decide for themselves whether they want to be in a public directory." The threats posed to individuals whose privacy is not entrenched are extensive. I have heard arguments that this could be used as a means of safeguarding spammers and fraudsters, however, I urge you to consider the most basic legal principle of "Innocent until proven guilty." It seems extremely drastic to have to compromise the privacy of the innocent in order to make the process of tracing the guilty simpler. It also seems drastic that even the name and residential address of a spammer/fraudster be made public before that person has been prosecuted lawfully and afforded the dignity of defending the charges against him/her and a fair trial in which he/she is judged and found guilty. One might also want to consider the risks of backlash from organisations such as the Electronic Frontier Foundation that campaign for online privacy should policies be amended to require the publishing of residential customer information. Regards Gregory Massel From anne at apnic.net Tue Aug 24 19:39:21 2004 From: anne at apnic.net (Anne Lord) Date: Wed, 25 Aug 2004 09:39:21 +1000 Subject: [ppml] Privacy Legislation and new proposals affecting residential privacy In-Reply-To: <008001c48a2f$441c7c30$0a1929c4@groglet> Message-ID: <5.1.0.14.0.20040825093058.041f99a0@imap.apnic.net> Hi Gregory, It may be of interest to others to know that at the last APNIC meeting a proposal 'Privacy of customer assignment records' was approved. The full details of the proposal, all discussions, minutes and presentations can be found at this URL. http://www.apnic.net/docs/policy/proposals/prop-007-v001.html The policy will not be implemented until the end of September. For anyone interested, there will be a project implementation update at the next APNIC meeting (next week) which will be available by webcast and live transcripts. See: http://www.apnic.net/meetings/18/ for more details. Regards, Anne APNIC Secretariat At 01:08 AM 25/08/2004 +0200, Gregory Massel wrote: >Hello PPML > >In discussions of the privacy of residential customer information, please >consider that the reach of this extends beyond ARIN itself. > >Various countries have enacted, or are in the process of enacting, privacy >legislation. > >Eg. In South Africa (which presently falls within the ARIN service region), >the chapter 2 of the constitution entrenches every person's rights to >privacy. To further entrench individual's privacy rights beyond this general >provision the Law Commission has been drafting privacy legislation that will >protect personal information. It is quite likely that in the future it will >be illegal for South African ISPs to publish residential customers' names >and address information in the whois database. > >Although not strictly an issue for ARIN, it may be worth taking into >consideration legislative requirements outside of the ARIN region as these >demonstrate the result of extensive international consultation regarding >policies of this nature. > >In particular, I draw your attention to the case of the EU region: >http://europa.eu.int/information_society/topics/ecomm/all_about/todays_framework/privacy_protection/index_en.htm > >In particular, "Article 12 of the Privacy and Electronic Communications >Directive therefore grants subscribers of all forms of electronic >communication services (fixed or mobile telephony, e-mail) the right to >decide for themselves whether they want to be in a public directory." > >The threats posed to individuals whose privacy is not entrenched are >extensive. > >I have heard arguments that this could be used as a means of safeguarding >spammers and fraudsters, however, I urge you to consider the most basic >legal principle of "Innocent until proven guilty." It seems extremely >drastic to have to compromise the privacy of the innocent in order to make >the process of tracing the guilty simpler. It also seems drastic that even >the name and residential address of a spammer/fraudster be made public >before that person has been prosecuted lawfully and afforded the dignity of >defending the charges against him/her and a fair trial in which he/she is >judged and found guilty. > >One might also want to consider the risks of backlash from organisations >such as the Electronic Frontier Foundation that campaign for online privacy >should policies be amended to require the publishing of residential customer >information. > >Regards >Gregory Massel From Michael.Dillon at radianz.com Wed Aug 25 05:43:37 2004 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 25 Aug 2004 10:43:37 +0100 Subject: [ppml] Privacy Legislation and new proposals affecting residential privacy In-Reply-To: <5.1.0.14.0.20040825093058.041f99a0@imap.apnic.net> Message-ID: Let's not forget that there have been other proposals regarding privacy of the whois directory entries. In particular, I presented this proposal http://www.arin.net/policy/2004_4.html last year but it was rejected by a very small subset of ARIN members who were at the poorly attended meeting in Vancouver. This upcoming meeting at Reston should have a much larger subset of ARIN members present and if people feel that some of the ideas in my previous proposal should be incorporated into ARIN policy, then you should say so on this list. The ARIN Advisory Council can and will modify the current proposals before submitting them to a members vote. However they don't do this based on their own whims, rather they pay attention to the comments expressed on this mailing list. In particular, there have been comments that the current privacy proposal will make life difficult for researchers. If you read the full text of my previous proposal you will see that I attempted to provide for reasonable research activities without compromising the right on individuals to privacy. This is an important issue because today, there are no clear rules about what must be in a whois directory. Many of us do business in multiple legal jurisdictions and the temptation is there to simply stop publishing all whois data entirely because it may violate the law in one or more of the countries in which we operate. ARIN would have no recourse in this instance because ARIN has no policies that justify the whois directory. In fact, the activities of SPAM chasers such as William Leibzon could easily be used in court to set a precedent banning whois entirely. I'm not attacking William here or saying anything about the legitimacy of his activities, just that he does mine the whois directory and he works aggressively to get whois entries corrected according to his understanding of the scope and purpose of the whois directory. I don't agree with all of William's views as to the purpose and scope of the whois directory and I don't think that the overall ISP community agrees with this view either. And I would urge each and every one of you to review this issue internally with your legal and regulatory people and not just make your decisions based on personal prejudices. We clearly have to change the nature of whois but we do have some leeway in how we do this. I do agree with William that any data published in the whois directory should be accurate, that there should be a mechanism to test and report on the accuracy of the information, and that the directory should point to contact people within an ISP who is responsible for dealing with network problems including network abuse. The current proposal, unfortunately, doesn't address any of these issues and merely makes it entirely optional for an ISP to publish whois information at all. If the current proposal passes, my organization will shut down our rwhois server. It's an ancient piece of software that is a royal pain to deal with and we'll be happy to see the end of it. We will cease to publish any whois data at all beyond the top level records showing the allocations received by ARIN. We will provide ARIN with a complete database of all our internal whois data (no /29 boundary) on demand any time they ask, possibly by providing a .CSV file on a password protected secure http server so they can pick up the latest daily dump whenever they want it. How many of you will do the same? ------------------------------------------------------- Michael Dillon Capacity Management, 66 Prescot St., London, E1 8HG, UK Mobile: +44 7900 823 672 Internet: michael.dillon at radianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 http://www.radianz.com Voted "Best Network Provider 2004" Waters Magazine From william at elan.net Wed Aug 25 07:28:41 2004 From: william at elan.net (william(at)elan.net) Date: Wed, 25 Aug 2004 04:28:41 -0700 (PDT) Subject: [ppml] Privacy Legislation and new proposals affecting residential privacy Message-ID: On Wed, 25 Aug 2004 Michael.Dillon at radianz.com wrote: > Let's not forget that there have been other proposals regarding privacy of > the whois directory entries. In particular, I presented this proposal > http://www.arin.net/policy/2004_4.html last year but it was rejected by a > very small subset of ARIN members who were at the poorly attended meeting > in Vancouver. This upcoming meeting at Reston should have a much larger > subset of ARIN members present and if people feel that some of the ideas > in my previous proposal should be incorporated into ARIN policy, then you > should say so on this list. The ARIN Advisory Council can and will modify > the current proposals before submitting them to a members vote. Doubt that, they've already discussed it privately for a while, see few glimps in the published minutes of AC meetings ... But that that does not mean the proposal would pass in next meeting and if does not than they could/would modify it, although I'm hoping it could be dropped entirely for something better. > However they don't do this based on their own whims, rather they pay > attention to the comments expressed on this mailing list. I've not seen much of that either... > In particular, there have been comments that the current privacy proposal > will make life difficult for researchers. If you read the full text of my > previous proposal you will see that I attempted to provide for reasonable > research activities without compromising the right on individuals to > privacy. Well, not really... At least what you proposed would not have helped researches if swip information becomes optional. That is not to say that you had did not have good ideas or that your proposal was bad - it was step in the right direction. I think there needs to be entire new section and set of policies on whois that covers database purpose, what information must be put there, privacy directions regarding this information, availability and accuracy of data and protection of data from misuse. > This is an important issue because today, there are no clear rules about > what must be in a whois directory. Many of us do business in multiple > legal jurisdictions and the temptation is there to simply stop publishing > all whois data entirely because it may violate the law in one or more of > the countries in which we operate. ARIN would have no recourse in this > instance because ARIN has no policies that justify the whois directory. In > fact, the activities of SPAM chasers such as William Leibzon could easily > be used in court to set a precedent banning whois entirely. I'm not Perhaps partly based on my remarks, you seem to be of the opinion that I'm some big anti-spammer and constantly bug ARIN and go through their data. That is not accurate, I've done very little of direct spammer chasing unlike numerous other people (from organizations such as spamhaus, those associated with spews - whoever they are :), spamcop or many people at NANAI or SPAM-L), but I do know some of these people and what they use. I'm primarily involved with providing tools and help on how to find the information people need and I've also made number of posts educating on what people can and can not do and if they cant what is the approriate political body to contact or what are appropriate steps to change the policy. And I've always advocated following the law and and letting correct organations and law enforcement know about abuse and having them handle the problems and limiting direct anti-spammer activities to something like investigative reporting done by journalists. My personal involvement and research was actually only limited to whois entries entered directly at the top level (i.e. ARIN and other RIR assignments & allocations), so current privacy policies proposed would not really effect any of that. But having seen what kind of data real spam researches are using and how they do it, I can tell you that SWIP data is being used quite a bit and is very helpfull. And despite some of the contact information not always being accurate the majority of them are. And most important the organization data that ISPs enter as to who they allocated the block to is even more accurate and a lot more helpfull - this is not surprising as that is company officially client of that ISP and it must be real entity to be able to pay its bills (those cases where such info is not accurate usually do not last long, maybe these are exactly the cases when ISP does not get paid :) Almost all my involvement had been with research on the protocol level (i.e. at IETF) or policies issues (i.e. at ARIN) as I get involved when I think existing protocol has security issues that can not be corrected without some necessary changes/additions and similarly on policies side. > attacking William here or saying anything about the legitimacy of his > activities, just that he does mine the whois directory and he works > aggressively to get whois entries corrected according to his understanding > of the scope and purpose of the whois directory. I've never corrected any whois entry - ARIN that did after its own extensive research on each case. I did prior research as to if there is exists situation where whois data (on the top level, i.e. direct ARIN or IANA allocation) is or is not accurate and it so happens I was right every time when I concluded it was not (that just shows I have pretty good understanding on what is not good data and that unlike others I do not make 100s reports to ARIN and overload their staff and only do reports after extensive investigation into each case). > I don't agree with all of William's views as to the purpose and scope of > the whois directory and I don't think that the overall ISP community > agrees with this view either. The purpose of the whois directory should not be exclusive to what ISPs want or what ISPs agree to. This is a global directory that has lot wider use than only in the ISP community in deciding their own tech issues, that is exactly the point I've been trying to make all around. Unfortunetly ARIN itself is not really a global North-American wide policy group and its dominated by ISPs, which means these issue are not being clearly understood from the perspective of others who may use the data and despite ARIN policy meetings being open (and this mailing list), there are very few people there (or I suspect on this list) who are not representing organization that is ISP (or research or govermental institution) that is receiving services from ARIN. This includes me as well as I represent ISP or other I probably would not have gotten involved in the first place ... > And I would urge each and every one of you to review this issue internally > with your legal and regulatory people and not just make your decisions > based on personal prejudices. We clearly have to change the nature of > whois but we do have some leeway in how we do this. > > I do agree with William that any data published in the whois directory > should be accurate, that there should be a mechanism to test and report on > the accuracy of the information, and that the directory should point to > contact people within an ISP who is responsible for dealing with network > problems including network abuse. The current proposal, unfortunately, > doesn't address any of these issues and merely makes it entirely optional > for an ISP to publish whois information at all. > > If the current proposal passes, my organization will shut down our rwhois > server. It's an ancient piece of software that is a royal pain to deal > with and we'll be happy to see the end of it. We will cease to publish any > whois data at all beyond the top level records showing the allocations > received by ARIN. We will provide ARIN with a complete database of all our > internal whois data (no /29 boundary) on demand any time they ask, > possibly by providing a .CSV file on a password protected secure http > server so they can pick up the latest daily dump whenever they want it. > > How many of you will do the same? And the above is exactly the kind thing I'm afraid many other ISPs would do which will inevitably seriously decrease value of the whois directory. -- William Leibzon Elan Networks william at elan.net