From info at arin.net Tue Aug 5 14:19:40 2008 From: info at arin.net (Member Services) Date: Tue, 05 Aug 2008 14:19:40 -0400 Subject: [arin-ppml] NRPM version 2008.3 - New Policy Implementation Message-ID: <489899BC.9000705@arin.net> On 8 July 2008 the ARIN Board of Trustees, acting on the recommendation of the Advisory Council and noting that the Internet Resource Policy Evaluation Process had been followed, adopted the following policy proposals: Policy Proposal 2008-1: SWIP support for smaller than /29 assignments Policy Proposal 2007-21: PIv6 for legacy holders with RSA and efficient use These policies have been incorporated into version 2008.3 of the ARIN Number Resource Policy Manual (NRPM). NRPM version 2008.3 is effective 5 August 2008 and supersedes previous versions. See Appendix A of the NRPM for information regarding changes to the manual. The NRPM can be found at: http://www.arin.net/policy/nrpm.html Appendix A can be found at: http://www.arin.net/policy/nrpm_changelog.html Regards, Member Services American Registry for Internet Numbers (ARIN) From awahid at cwgo.com Wed Aug 6 12:04:33 2008 From: awahid at cwgo.com (Aamir Wahid) Date: Wed, 06 Aug 2008 12:04:33 -0400 Subject: [arin-ppml] ARIN-PPML Digest, Vol 38, Issue 1 Message-ID: <956719248@mail.cwgo.com> From bmanning at vacation.karoshi.com Thu Aug 7 01:00:12 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 7 Aug 2008 05:00:12 +0000 Subject: [arin-ppml] [Remco.vanMook@eu.equinix.com: [address-policy-wg] new policy idea for PA allocations] Message-ID: <20080807050012.GC13934@vacation.karoshi.com.> how does this idea strike your fancy? ----- Forwarded message from Remco van Mook ----- X-Original-To: address-policy-wg at lists.ripe.net Thread-Topic: new policy idea for PA allocations From: "Remco van Mook" Dear all, I want to hear your feedback on an idea that I've been playing with for a while - it has to do with the way the RIR allocates blocks of space to an approved IPv4 PA allocation request. Currently that's very simple. Once the request is approved for, say, a /15, you get a single routable block of space, a /15. But what do we do when the RIR does not have that size block anymore? Allocate multiple blocks to that request (so, for example, 2 /17s, 1 /18, 5 /19s and 2 /20s)? What I would suggest is that we set into policy that the RIR, in cases like this, allocates a single best-fit routable block of IPv4 space. So, if the request is for a /12 and the biggest block the RIR has left is a /14, you get a /14. The rationale behind this is quite simple: the requester is not going to be happy to get a bunch of /24s from all over the swamp space to fill his request, and at the same time we remove the risk that a single request is able to wipe out the entire RIR reserves. Smaller requests can still be fulfilled and the LIRs that need more space simply need to come back more often - the 80% usage rule still applies. As long as the RIR has a supply from IANA, this rule will have no operational impact as far as I can see. Let me know what you think. Best, Remco ----- End forwarded message ----- From randy at psg.com Thu Aug 7 01:28:44 2008 From: randy at psg.com (Randy Bush) Date: Thu, 07 Aug 2008 14:28:44 +0900 Subject: [arin-ppml] [Remco.vanMook@eu.equinix.com: [address-policy-wg] new policy idea for PA allocations] In-Reply-To: <20080807050012.GC13934@vacation.karoshi.com.> References: <20080807050012.GC13934@vacation.karoshi.com.> Message-ID: <489A880C.6040005@psg.com> bmanning at vacation.karoshi.com wrote: > how does this idea strike your fancy? a significant step forward in complexity and kink randy From kkargel at polartel.com Thu Aug 7 09:18:59 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 7 Aug 2008 08:18:59 -0500 Subject: [arin-ppml] [Remco.vanMook@eu.equinix.com: [address-policy-wg] new policy idea for PA allocations] In-Reply-To: <489A880C.6040005@psg.com> References: <20080807050012.GC13934@vacation.karoshi.com.> <489A880C.6040005@psg.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A109CF@mail> It sounds like a reduction in complexity to me.. You go to the store to buy one item and get the biggest one they have in your color.. That meets your immediate needs and if you need more you go back to the store.. Sounds simple to me.. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Randy Bush Sent: Thursday, August 07, 2008 12:29 AM To: bmanning at vacation.karoshi.com Cc: ppml at arin.net Subject: Re: [arin-ppml] [Remco.vanMook at eu.equinix.com: [address-policy-wg] new policy idea for PA allocations] bmanning at vacation.karoshi.com wrote: > how does this idea strike your fancy? a significant step forward in complexity and kink randy _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3107 bytes Desc: not available URL: From marla.azinger at frontiercorp.com Thu Aug 7 10:47:14 2008 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Thu, 7 Aug 2008 10:47:14 -0400 Subject: [arin-ppml] policy idea for PA allocations] In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A109CF@mail> References: <20080807050012.GC13934@vacation.karoshi.com.> <489A880C.6040005@psg.com> <70DE64CEFD6E9A4EB7FAF3A063141066A109CF@mail> Message-ID: <2E2FECEBAE57CC4BAACDE67638305F104811957FE6@ROCH-EXCH1.corp.pvt> Its an interesting idea. I wonder how much it would increase the number of requests the ARIN staff ends up processing per week though. Given most likely the Utilization percentile rule would be met much faster given the requestor may end up with a much smaller size then they needed to get. This could have two effects that I see right away. One, distribution lasts a smidge longer and spreads the remaining addresses out to a smidge more larger of requestors. Two ARIN staff gets an increase in the number of requests due to requestors coming back much faster than before due to decreased sizes that are granted. I know this idea has alot more angles to it that can be pulled out of it. But those are the first two that jump out at me. Its possible that this idea would be favorable to the smaller entities requesting space but it could also end up not really making much of a difference at all. If this gets moved into a policy proposal I'll spend more analysis time on it. Cheers Marla Azinger -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel Sent: Thursday, August 07, 2008 6:19 AM To: ppml at arin.net Subject: Re: [arin-ppml] [Remco.vanMook at eu.equinix.com: [address-policy-wg] new policy idea for PA allocations] It sounds like a reduction in complexity to me.. You go to the store to buy one item and get the biggest one they have in your color.. That meets your immediate needs and if you need more you go back to the store.. Sounds simple to me.. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Randy Bush Sent: Thursday, August 07, 2008 12:29 AM To: bmanning at vacation.karoshi.com Cc: ppml at arin.net Subject: Re: [arin-ppml] [Remco.vanMook at eu.equinix.com: [address-policy-wg] new policy idea for PA allocations] bmanning at vacation.karoshi.com wrote: > how does this idea strike your fancy? a significant step forward in complexity and kink randy _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From kkargel at polartel.com Thu Aug 7 11:06:20 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 7 Aug 2008 10:06:20 -0500 Subject: [arin-ppml] policy idea for PA allocations] In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F104811957FE6@ROCH-EXCH1.corp.pvt> References: <20080807050012.GC13934@vacation.karoshi.com.><489A880C.6040005@psg.com> <70DE64CEFD6E9A4EB7FAF3A063141066A109CF@mail> <2E2FECEBAE57CC4BAACDE67638305F104811957FE6@ROCH-EXCH1.corp.pvt> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A109D6@mail> I am not privy to ARIN operational procedure, but even if it created more requests it sounds like it would make for less work as staff would avoid quilting patchwork blocks together to meet the request quantity. Sounds like an easier algorythm to automate or script. -----Original Message----- From: Azinger, Marla [mailto:marla.azinger at frontiercorp.com] Sent: Thursday, August 07, 2008 9:47 AM To: Kevin Kargel; ppml at arin.net Subject: RE: [arin-ppml] policy idea for PA allocations] Its an interesting idea. I wonder how much it would increase the number of requests the ARIN staff ends up processing per week though. Given most likely the Utilization percentile rule would be met much faster given the requestor may end up with a much smaller size then they needed to get. This could have two effects that I see right away. One, distribution lasts a smidge longer and spreads the remaining addresses out to a smidge more larger of requestors. Two ARIN staff gets an increase in the number of requests due to requestors coming back much faster than before due to decreased sizes that are granted. I know this idea has alot more angles to it that can be pulled out of it. But those are the first two that jump out at me. Its possible that this idea would be favorable to the smaller entities requesting space but it could also end up not really making much of a difference at all. If this gets moved into a policy proposal I'll spend more analysis time on it. Cheers Marla Azinger -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel Sent: Thursday, August 07, 2008 6:19 AM To: ppml at arin.net Subject: Re: [arin-ppml] [Remco.vanMook at eu.equinix.com: [address-policy-wg] new policy idea for PA allocations] It sounds like a reduction in complexity to me.. You go to the store to buy one item and get the biggest one they have in your color.. That meets your immediate needs and if you need more you go back to the store.. Sounds simple to me.. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Randy Bush Sent: Thursday, August 07, 2008 12:29 AM To: bmanning at vacation.karoshi.com Cc: ppml at arin.net Subject: Re: [arin-ppml] [Remco.vanMook at eu.equinix.com: [address-policy-wg] new policy idea for PA allocations] bmanning at vacation.karoshi.com wrote: > how does this idea strike your fancy? a significant step forward in complexity and kink randy _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3107 bytes Desc: not available URL: From randy at psg.com Thu Aug 7 12:07:08 2008 From: randy at psg.com (Randy Bush) Date: Fri, 08 Aug 2008 01:07:08 +0900 Subject: [arin-ppml] [Remco.vanMook@eu.equinix.com: [address-policy-wg] new policy idea for PA allocations] In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A109CF@mail> References: <20080807050012.GC13934@vacation.karoshi.com.> <489A880C.6040005@psg.com> <70DE64CEFD6E9A4EB7FAF3A063141066A109CF@mail> Message-ID: <489B1DAC.7060907@psg.com> Kevin Kargel wrote: > > It sounds like a reduction in complexity to me.. You go to the store to buy > one item and get the biggest one they have in your color.. That meets your > immediate needs ab definito, it does not meet your needs. randy From randy at psg.com Thu Aug 7 12:10:43 2008 From: randy at psg.com (Randy Bush) Date: Fri, 08 Aug 2008 01:10:43 +0900 Subject: [arin-ppml] policy idea for PA allocations] In-Reply-To: <2E2FECEBAE57CC4BAACDE67638305F104811957FE6@ROCH-EXCH1.corp.pvt> References: <20080807050012.GC13934@vacation.karoshi.com.> <489A880C.6040005@psg.com> <70DE64CEFD6E9A4EB7FAF3A063141066A109CF@mail> <2E2FECEBAE57CC4BAACDE67638305F104811957FE6@ROCH-EXCH1.corp.pvt> Message-ID: <489B1E83.10301@psg.com> Azinger, Marla wrote: > Its an interesting idea. I wonder how much it would increase the > number of requests the ARIN staff ends up processing per week though. bingo, the same amount of space is allocated but the number of tcp exchanges to do it goes up dramatically. the real underlying philosophy is the classic one. treat the customer / member like an evil fool and create phony barriers and you will make the internet a better place. randy From michael.dillon at bt.com Thu Aug 7 12:44:43 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 7 Aug 2008 17:44:43 +0100 Subject: [arin-ppml] policy idea for PA allocations] In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A109D6@mail> Message-ID: > I am not privy to ARIN operational procedure, but even if it > created more requests it sounds like it would make for less > work as staff would avoid quilting patchwork blocks together > to meet the request quantity. Sounds like an easier > algorythm to automate or script. Operational procedure? Changing algorithms? Isn't this really a process matter for the BoT, not a policy matter? If anyone seriously thinks that this is a good idea, then they should put it in the ARIN suggestion box on the website and see what the staff have to say first. --Michael Dillon From bicknell at ufp.org Thu Aug 7 13:46:28 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 7 Aug 2008 13:46:28 -0400 Subject: [arin-ppml] [Remco.vanMook@eu.equinix.com: [address-policy-wg] new policy idea for PA allocations] In-Reply-To: <20080807050012.GC13934@vacation.karoshi.com.> References: <20080807050012.GC13934@vacation.karoshi.com.> Message-ID: <20080807174628.GA24495@ussenterprise.ufp.org> I would like to see ARIN staff provide some input. While I can see the resulting allocations of how they fill a /8, I don't have any idea how that process works in real time. How they chop it up, manage requests of different sizes, reserve blocks, etc. If there is one thing I have learned about "making things easier for staff" ideas, its going to staff first. Usually the first assessment of this being "more or less" work for staff is 100% wrong. The first question is simple: If the policy stays as-is, what does staff intend to do when they get a request larger than they can provide in a single block? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From Lee.Howard at stanleyassociates.com Thu Aug 7 13:46:56 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 7 Aug 2008 13:46:56 -0400 Subject: [arin-ppml] policy idea for PA allocations] In-Reply-To: Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40AD56146@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com > Sent: Thursday, August 07, 2008 12:45 PM > To: ppml at arin.net > Subject: Re: [arin-ppml] policy idea for PA allocations] > > > I am not privy to ARIN operational procedure, but even if > it created > > more requests it sounds like it would make for less work as staff > > would avoid quilting patchwork blocks together to meet the request > > quantity. Sounds like an easier algorythm to automate or script. > > Operational procedure? Changing algorithms? > > Isn't this really a process matter for the BoT, not a policy matter? > > If anyone seriously thinks that this is a good idea, then > they should put it in the ARIN suggestion box on the website > and see what the staff have to say first. It sounds like a proposal for an allocation/assignment policy to me. Changing the policy from "We give you what you need" to "We give you the single closest match we have" would be a IRPEP item. IMHO, and I haven't asked the rest of the Board. Not sure how I'd vote if it came to the Board. For external use only. Do not eat soap. OK! Lee > > --Michael Dillon > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From michael.dillon at bt.com Thu Aug 7 14:09:40 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 7 Aug 2008 19:09:40 +0100 Subject: [arin-ppml] [Remco.vanMook@eu.equinix.com: [address-policy-wg]new policy idea for PA allocations] In-Reply-To: <20080807174628.GA24495@ussenterprise.ufp.org> Message-ID: > The first question is simple: If the policy stays as-is, what > does staff intend to do when they get a request larger than > they can provide in a single block? Today, as you know, staff reserves neighboring blocks in case the same ISP comes back in 6 months for more. That way they increase the size of an existing block by aggregating neighboring CIDR blocks. There was one instance where I asked for a /16 and it was approved, but they gave me two /17 blocks instead. The first /17 filled out was previously reserved and filled out a /15. The second /17 was from a completely different /8. Staff don't seem to be anal about this, i.e. they give you blocks that add up to what was approved. One would think that they would continue this behavior when they run out of big blocks. --Michael Dillon From darden at armc.org Thu Aug 7 14:17:39 2008 From: darden at armc.org (Darden, Patrick S.) Date: Thu, 7 Aug 2008 14:17:39 -0400 Subject: [arin-ppml] [Remco.vanMook@eu.equinix.com:[address-policy-wg]new policy idea for PA allocations] In-Reply-To: Message-ID: As usual, Michael is spot on: http://www.arin.net/policy/nrpm.html#six1 "6.3.4. Aggregation Wherever possible, address space should be distributed in a hierarchical manner, according to the topology of network infrastructure. This is necessary to permit the aggregation of routing information by ISPs, and to limit the expansion of Internet routing tables. This goal is particularly important in IPv6 addressing, where the size of the total address pool creates significant implications for both internal and external routing. IPv6 address policies should seek to avoid fragmentation of address ranges. Further, RIRs should apply practices that maximize the potential for subsequent allocations to be made contiguous with past allocations currently held. However, there can be no guarantee of contiguous allocation." --Patrick Darden -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]On Behalf Of michael.dillon at bt.com Sent: Thursday, August 07, 2008 2:10 PM To: ppml at arin.net Subject: Re: [arin-ppml] [Remco.vanMook at eu.equinix.com:[address-policy-wg]new policy idea for PA allocations] > The first question is simple: If the policy stays as-is, what > does staff intend to do when they get a request larger than > they can provide in a single block? Today, as you know, staff reserves neighboring blocks in case the same ISP comes back in 6 months for more. That way they increase the size of an existing block by aggregating neighboring CIDR blocks. There was one instance where I asked for a /16 and it was approved, but they gave me two /17 blocks instead. The first /17 filled out was previously reserved and filled out a /15. The second /17 was from a completely different /8. Staff don't seem to be anal about this, i.e. they give you blocks that add up to what was approved. One would think that they would continue this behavior when they run out of big blocks. --Michael Dillon _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From Daniel_Alexander at Cable.Comcast.com Thu Aug 7 16:40:32 2008 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Thu, 7 Aug 2008 16:40:32 -0400 Subject: [arin-ppml] [Remco.vanMook@eu.equinix.com: [address-policy-wg] newpolicy idea for PA allocations] In-Reply-To: <20080807050012.GC13934@vacation.karoshi.com.> References: <20080807050012.GC13934@vacation.karoshi.com.> Message-ID: <997BC128AE961E4A8B880CD7442D948006445642@NJCHLEXCMB01.cable.comcast.com> Is the goal of the thought to throttle demand or to stretch out available supply? By itself, it would not change either. The idea would need to incorporate a time restriction, in addition to the single best fit, in order for it to change anything other than creating more application requests. To use the example below, an organization needs a /15, but the only blocks left are 2 /17s, 1 /18, 5 /19s and 2 /20s. If the idea became policy, an organization shows it needs a /15 for the next 12 months. ARIN would allocate the /17. That would accommodate the org for an average of three months. Three months later, all things the same, they would apply again for a /15 for the next 12 months. They would get a /17, and so the loop continues. 12 months later, they would have a /15, but through submitting ten applications instead of one. By only restricting allocations to a single best fit, it does not change demand or the IP consumption rate. It only changes how many times an organization has to go to the well for a drink. A single best fit proposal would also need to say that x is the only allocation the org can have for x months, in order to also control the frequency of allocations made. -Dan -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of bmanning at vacation.karoshi.com Sent: Thursday, August 07, 2008 1:00 AM To: ppml at arin.net Subject: [arin-ppml] [Remco.vanMook at eu.equinix.com: [address-policy-wg] newpolicy idea for PA allocations] how does this idea strike your fancy? ----- Forwarded message from Remco van Mook ----- X-Original-To: address-policy-wg at lists.ripe.net Thread-Topic: new policy idea for PA allocations From: "Remco van Mook" Dear all, I want to hear your feedback on an idea that I've been playing with for a while - it has to do with the way the RIR allocates blocks of space to an approved IPv4 PA allocation request. Currently that's very simple. Once the request is approved for, say, a /15, you get a single routable block of space, a /15. But what do we do when the RIR does not have that size block anymore? Allocate multiple blocks to that request (so, for example, 2 /17s, 1 /18, 5 /19s and 2 /20s)? What I would suggest is that we set into policy that the RIR, in cases like this, allocates a single best-fit routable block of IPv4 space. So, if the request is for a /12 and the biggest block the RIR has left is a /14, you get a /14. The rationale behind this is quite simple: the requester is not going to be happy to get a bunch of /24s from all over the swamp space to fill his request, and at the same time we remove the risk that a single request is able to wipe out the entire RIR reserves. Smaller requests can still be fulfilled and the LIRs that need more space simply need to come back more often - the 80% usage rule still applies. As long as the RIR has a supply from IANA, this rule will have no operational impact as far as I can see. Let me know what you think. Best, Remco ----- End forwarded message ----- _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From kkargel at polartel.com Thu Aug 7 16:59:36 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 7 Aug 2008 15:59:36 -0500 Subject: [arin-ppml] [Remco.vanMook@eu.equinix.com: [address-policy-wg]newpolicy idea for PA allocations] In-Reply-To: <997BC128AE961E4A8B880CD7442D948006445642@NJCHLEXCMB01.cable.comcast.com> References: <20080807050012.GC13934@vacation.karoshi.com.> <997BC128AE961E4A8B880CD7442D948006445642@NJCHLEXCMB01.cable.comcast.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A109F0@mail> Personally I don't see the benefit to stretching anything out, it just prolongs the agony and the inevitable. My suggestion is to just keep going, do the best we can the way we are doing it now, and when the well runs dry it is dry. People have been well forwarned and when the need is here maybe then v6 will get more attention. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Alexander, Daniel Sent: Thursday, August 07, 2008 3:41 PM To: ppml at arin.net Subject: Re: [arin-ppml] [Remco.vanMook at eu.equinix.com: [address-policy-wg]newpolicy idea for PA allocations] Is the goal of the thought to throttle demand or to stretch out available supply? By itself, it would not change either. The idea would need to incorporate a time restriction, in addition to the single best fit, in order for it to change anything other than creating more application requests. To use the example below, an organization needs a /15, but the only blocks left are 2 /17s, 1 /18, 5 /19s and 2 /20s. If the idea became policy, an organization shows it needs a /15 for the next 12 months. ARIN would allocate the /17. That would accommodate the org for an average of three months. Three months later, all things the same, they would apply again for a /15 for the next 12 months. They would get a /17, and so the loop continues. 12 months later, they would have a /15, but through submitting ten applications instead of one. By only restricting allocations to a single best fit, it does not change demand or the IP consumption rate. It only changes how many times an organization has to go to the well for a drink. A single best fit proposal would also need to say that x is the only allocation the org can have for x months, in order to also control the frequency of allocations made. -Dan -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3107 bytes Desc: not available URL: From Lee.Howard at stanleyassociates.com Thu Aug 7 17:07:52 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 7 Aug 2008 17:07:52 -0400 Subject: [arin-ppml] [Remco.vanMook@eu.equinix.com: [address-policy-wg]newpolicy idea for PA allocations] In-Reply-To: <997BC128AE961E4A8B880CD7442D948006445642@NJCHLEXCMB01.cable.comcast.com> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40AD564D2@CL-S-EX-1.stanleyassociates.com> > To use the example below, an organization needs a /15, but > the only blocks left are 2 /17s, 1 /18, 5 /19s and 2 /20s. If > the idea became policy, an organization shows it needs a /15 > for the next 12 months. > ARIN would allocate the /17. That would accommodate the org > for an average of three months. Three months later, all > things the same, they would apply again for a /15 for the > next 12 months. They would get a /17, and so the loop > continues. 12 months later, they would have a /15, but > through submitting ten applications instead of one. I don't know if this potential proposal is a good idea or not, but isn't the point of it that by the time the org uses half of their qualification (three months later), ARIN would be completely out? Org qualifies for /15 but gets /17. During that three months, the other /17, /18, and many of the /19s are assigned to others. Org qualifies for a /15 or /16 but gets a /19. Maybe a month later they can get a /22, but by that point IPv4 is gone. The goal (I think) would be to distribute the last assignments among more organizations, so that one well-timed mammoth application does deplete the remaining pool, meaning Mammoth ISP is the only one who growsv4 that year/ever again. Mostly playing devil's advocate. Lee From mack at exchange.alphared.com Thu Aug 7 17:03:59 2008 From: mack at exchange.alphared.com (mack) Date: Thu, 7 Aug 2008 16:03:59 -0500 Subject: [arin-ppml] new policy idea for PA allocations Message-ID: <6F2FFD7C10F788479E354B84294036C425AF8CF6@EXCH-MBX.exchange.alphared.local> This seems to be an operational issue with ambiguous policy guidance. Section 4.1.5 allows staff the flexibility to do what is necessary. There is no clear cut policy as to what staff should do when a single block cannot be allocated. It would probably be better to let staff attempt to balance deaggregation, increased requests, and equity of distribution than try to micro-manage it via the policy process. $.02 ------------------ Previous Message ----------------------- Message: 2 Date: Thu, 7 Aug 2008 05:00:12 +0000 From: bmanning at vacation.karoshi.com Subject: [arin-ppml] [Remco.vanMook at eu.equinix.com: [address-policy-wg] new policy idea for PA allocations] To: ppml at arin.net Message-ID: <20080807050012.GC13934 at vacation.karoshi.com.> Content-Type: text/plain; charset=us-ascii how does this idea strike your fancy? ----- Forwarded message from Remco van Mook ----- X-Original-To: address-policy-wg at lists.ripe.net Thread-Topic: new policy idea for PA allocations From: "Remco van Mook" Dear all, I want to hear your feedback on an idea that I've been playing with for a while - it has to do with the way the RIR allocates blocks of space to an approved IPv4 PA allocation request. Currently that's very simple. Once the request is approved for, say, a /15, you get a single routable block of space, a /15. But what do we do when the RIR does not have that size block anymore? Allocate multiple blocks to that request (so, for example, 2 /17s, 1 /18, 5 /19s and 2 /20s)? What I would suggest is that we set into policy that the RIR, in cases like this, allocates a single best-fit routable block of IPv4 space. So, if the request is for a /12 and the biggest block the RIR has left is a /14, you get a /14. The rationale behind this is quite simple: the requester is not going to be happy to get a bunch of /24s from all over the swamp space to fill his request, and at the same time we remove the risk that a single request is able to wipe out the entire RIR reserves. Smaller requests can still be fulfilled and the LIRs that need more space simply need to come back more often - the 80% usage rule still applies. As long as the RIR has a supply from IANA, this rule will have no operational impact as far as I can see. Let me know what you think. Best, Remco ----- End forwarded message ----- -- LR Mack McBride Network Administrator Alpha Red, Inc. From jim at tgasolutions.com Thu Aug 7 17:30:46 2008 From: jim at tgasolutions.com (Jim McBurnett) Date: Thu, 7 Aug 2008 17:30:46 -0400 Subject: [arin-ppml] new policy idea for PA allocations Message-ID: I agree. A policy should be a guideline but the staff needs latitude for irregularities that can not be predicted by something that takes on as many facets as the internet. Thanks, Jim Please forgive the typos, Sent from my blackberry handheld. ----- Original Message ----- From: arin-ppml-bounces at arin.net To: arin-ppml at arin.net Sent: Thu Aug 07 17:03:59 2008 Subject: Re: [arin-ppml] new policy idea for PA allocations This seems to be an operational issue with ambiguous policy guidance. Section 4.1.5 allows staff the flexibility to do what is necessary. There is no clear cut policy as to what staff should do when a single block cannot be allocated. It would probably be better to let staff attempt to balance deaggregation, increased requests, and equity of distribution than try to micro-manage it via the policy process. $.02 ------------------ Previous Message ----------------------- Message: 2 Date: Thu, 7 Aug 2008 05:00:12 +0000 From: bmanning at vacation.karoshi.com Subject: [arin-ppml] [Remco.vanMook at eu.equinix.com: [address-policy-wg] new policy idea for PA allocations] To: ppml at arin.net Message-ID: <20080807050012.GC13934 at vacation.karoshi.com.> Content-Type: text/plain; charset=us-ascii how does this idea strike your fancy? ----- Forwarded message from Remco van Mook ----- X-Original-To: address-policy-wg at lists.ripe.net Thread-Topic: new policy idea for PA allocations From: "Remco van Mook" Dear all, I want to hear your feedback on an idea that I've been playing with for a while - it has to do with the way the RIR allocates blocks of space to an approved IPv4 PA allocation request. Currently that's very simple. Once the request is approved for, say, a /15, you get a single routable block of space, a /15. But what do we do when the RIR does not have that size block anymore? Allocate multiple blocks to that request (so, for example, 2 /17s, 1 /18, 5 /19s and 2 /20s)? What I would suggest is that we set into policy that the RIR, in cases like this, allocates a single best-fit routable block of IPv4 space. So, if the request is for a /12 and the biggest block the RIR has left is a /14, you get a /14. The rationale behind this is quite simple: the requester is not going to be happy to get a bunch of /24s from all over the swamp space to fill his request, and at the same time we remove the risk that a single request is able to wipe out the entire RIR reserves. Smaller requests can still be fulfilled and the LIRs that need more space simply need to come back more often - the 80% usage rule still applies. As long as the RIR has a supply from IANA, this rule will have no operational impact as far as I can see. Let me know what you think. Best, Remco ----- End forwarded message ----- -- LR Mack McBride Network Administrator Alpha Red, Inc. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From Daniel_Alexander at Cable.Comcast.com Fri Aug 8 11:20:07 2008 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Fri, 8 Aug 2008 11:20:07 -0400 Subject: [arin-ppml] [Remco.vanMook@eu.equinix.com: [address-policy-wg]newpolicy idea for PA allocations] In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40AD564D2@CL-S-EX-1.stanleyassociates.com> References: <997BC128AE961E4A8B880CD7442D948006445642@NJCHLEXCMB01.cable.comcast.com> <369EB04A0951824ABE7D8BAC67AF9BB40AD564D2@CL-S-EX-1.stanleyassociates.com> Message-ID: <997BC128AE961E4A8B880CD7442D9480064D81F4@NJCHLEXCMB01.cable.comcast.com> Don't get me wrong, I wasn't trying to dismiss the thought, but was playing a little devil's advocate myself. Back in May I offered up some thoughts along a similar line. What you say is true, provided the "best fit" allocation made to organization X provides an adequate window of time for other organizations to get to the remaining reserves. This would leave little or nothing left by the time org X comes back, as you mention. The problem comes in when you have an org that can justify a /12, and is only given a /17. This scenario is where you would need a time requirement restricting future allocations for some number of months. Without a time restriction, there is nothing to prevent that org from submitting applications every other day and depleting what's left before anyone else can get to it. -Dan -----Original Message----- From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com] Sent: Thursday, August 07, 2008 5:08 PM To: Alexander, Daniel; ppml at arin.net Subject: RE: [arin-ppml] [Remco.vanMook at eu.equinix.com: [address-policy-wg]newpolicy idea for PA allocations] > To use the example below, an organization needs a /15, but the only > blocks left are 2 /17s, 1 /18, 5 /19s and 2 /20s. If the idea became > policy, an organization shows it needs a /15 for the next 12 months. > ARIN would allocate the /17. That would accommodate the org for an > average of three months. Three months later, all things the same, they > would apply again for a /15 for the next 12 months. They would get a > /17, and so the loop continues. 12 months later, they would have a > /15, but through submitting ten applications instead of one. I don't know if this potential proposal is a good idea or not, but isn't the point of it that by the time the org uses half of their qualification (three months later), ARIN would be completely out? Org qualifies for /15 but gets /17. During that three months, the other /17, /18, and many of the /19s are assigned to others. Org qualifies for a /15 or /16 but gets a /19. Maybe a month later they can get a /22, but by that point IPv4 is gone. The goal (I think) would be to distribute the last assignments among more organizations, so that one well-timed mammoth application does deplete the remaining pool, meaning Mammoth ISP is the only one who growsv4 that year/ever again. Mostly playing devil's advocate. Lee From kkargel at polartel.com Fri Aug 8 15:00:28 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 8 Aug 2008 14:00:28 -0500 Subject: [arin-ppml] [Remco.vanMook@eu.equinix.com:[address-policy-wg]newpolicy idea for PA allocations] In-Reply-To: <997BC128AE961E4A8B880CD7442D9480064D81F4@NJCHLEXCMB01.cable.comcast.com> References: <997BC128AE961E4A8B880CD7442D948006445642@NJCHLEXCMB01.cable.comcast.com><369EB04A0951824ABE7D8BAC67AF9BB40AD564D2@CL-S-EX-1.stanleyassociates.com> <997BC128AE961E4A8B880CD7442D9480064D81F4@NJCHLEXCMB01.cable.comcast.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A109F7@mail> Yeah, but let's say you are the local small town gas station.. You are running close to empty so your pumps only put out 3 gallons at a time and you have 60 gallons left. There is a line of cars at the pump, some boy scouts who need to make money for camp with their lawn mower are waiting patiently and washing windows, your mom is at the back of the line. On top of all this you remember you didn't fill your suburban this morning.. Do you let the banker who is at the head of the line buy all 60 gallons for an exhorbitant fee or do you spread it out around town?? I'm not saying one is better than the other, but you do have choices to make.. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Alexander, Daniel Sent: Friday, August 08, 2008 10:20 AM To: Howard, W. Lee; ppml at arin.net Subject: Re: [arin-ppml] [Remco.vanMook at eu.equinix.com:[address-policy-wg]newpolicy idea for PA allocations] Don't get me wrong, I wasn't trying to dismiss the thought, but was playing a little devil's advocate myself. Back in May I offered up some thoughts along a similar line. What you say is true, provided the "best fit" allocation made to organization X provides an adequate window of time for other organizations to get to the remaining reserves. This would leave little or nothing left by the time org X comes back, as you mention. The problem comes in when you have an org that can justify a /12, and is only given a /17. This scenario is where you would need a time requirement restricting future allocations for some number of months. Without a time restriction, there is nothing to prevent that org from submitting applications every other day and depleting what's left before anyone else can get to it. -Dan -----Original Message----- From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com] Sent: Thursday, August 07, 2008 5:08 PM To: Alexander, Daniel; ppml at arin.net Subject: RE: [arin-ppml] [Remco.vanMook at eu.equinix.com: [address-policy-wg]newpolicy idea for PA allocations] > To use the example below, an organization needs a /15, but the only > blocks left are 2 /17s, 1 /18, 5 /19s and 2 /20s. If the idea became > policy, an organization shows it needs a /15 for the next 12 months. > ARIN would allocate the /17. That would accommodate the org for an > average of three months. Three months later, all things the same, they > would apply again for a /15 for the next 12 months. They would get a > /17, and so the loop continues. 12 months later, they would have a > /15, but through submitting ten applications instead of one. I don't know if this potential proposal is a good idea or not, but isn't the point of it that by the time the org uses half of their qualification (three months later), ARIN would be completely out? Org qualifies for /15 but gets /17. During that three months, the other /17, /18, and many of the /19s are assigned to others. Org qualifies for a /15 or /16 but gets a /19. Maybe a month later they can get a /22, but by that point IPv4 is gone. The goal (I think) would be to distribute the last assignments among more organizations, so that one well-timed mammoth application does deplete the remaining pool, meaning Mammoth ISP is the only one who growsv4 that year/ever again. Mostly playing devil's advocate. Lee _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3107 bytes Desc: not available URL: From Matthew.Wilder at telus.com Fri Aug 8 16:26:49 2008 From: Matthew.Wilder at telus.com (Matthew Wilder) Date: Fri, 8 Aug 2008 13:26:49 -0700 Subject: [arin-ppml] [Remco.vanMook@eu.equinix.com:[address-policy-wg]newpolicyidea for PA allocations] In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A109F7@mail> References: <997BC128AE961E4A8B880CD7442D948006445642@NJCHLEXCMB01.cable.comcast.com><369EB04A0951824ABE7D8BAC67AF9BB40AD564D2@CL-S-EX-1.stanleyassociates.com><997BC128AE961E4A8B880CD7442D9480064D81F4@NJCHLEXCMB01.cable.comcast.com> <70DE64CEFD6E9A4EB7FAF3A063141066A109F7@mail> Message-ID: <4C80F17364FE2E4C93053BE9D01DB47909341AE3@BCMSG111.corp.ads> As the last email here mentions, this is really a matter of spreading out truly the last of the IP Address wealth. If there is enough for the banker to get his fill and everyone else before the banker comes back again, any change in policy will probably be nothing more than a wasteful exercise in itself. If people agree that it is the scenario in question that raises concern (banker getting the last of the gas) then maybe there is a place for a policy given the following condition. Condition: Projections show that a RIR's available pool of addresses is due to exhaust in approximately 12 months or less. Policy that activates upon this condition: The RIR begins to satisfy each ISP's 3 month requirement of IP Addresses, as opposed to their 6 or 12 month projections. Implications: In theory, as long as requests do not irrationally accelerate (which can itself be encouraged) then the last of the IP Addresses won't be entirely consumed by as large allocations. This policy would result in a somewhat greater level of fragmentation during the final allocations, but delays the timing of the increased fragmentation from other suggestions. -MW -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel Sent: Friday, August 08, 2008 12:00 PM To: ppml at arin.net Subject: Re: [arin-ppml][Remco.vanMook at eu.equinix.com:[address-policy-wg]newpolicyidea for PA allocations] Yeah, but let's say you are the local small town gas station.. You are running close to empty so your pumps only put out 3 gallons at a time and you have 60 gallons left. There is a line of cars at the pump, some boy scouts who need to make money for camp with their lawn mower are waiting patiently and washing windows, your mom is at the back of the line. On top of all this you remember you didn't fill your suburban this morning.. Do you let the banker who is at the head of the line buy all 60 gallons for an exhorbitant fee or do you spread it out around town?? I'm not saying one is better than the other, but you do have choices to make.. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Alexander, Daniel Sent: Friday, August 08, 2008 10:20 AM To: Howard, W. Lee; ppml at arin.net Subject: Re: [arin-ppml] [Remco.vanMook at eu.equinix.com:[address-policy-wg]newpolicy idea for PA allocations] Don't get me wrong, I wasn't trying to dismiss the thought, but was playing a little devil's advocate myself. Back in May I offered up some thoughts along a similar line. What you say is true, provided the "best fit" allocation made to organization X provides an adequate window of time for other organizations to get to the remaining reserves. This would leave little or nothing left by the time org X comes back, as you mention. The problem comes in when you have an org that can justify a /12, and is only given a /17. This scenario is where you would need a time requirement restricting future allocations for some number of months. Without a time restriction, there is nothing to prevent that org from submitting applications every other day and depleting what's left before anyone else can get to it. -Dan -----Original Message----- From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com] Sent: Thursday, August 07, 2008 5:08 PM To: Alexander, Daniel; ppml at arin.net Subject: RE: [arin-ppml] [Remco.vanMook at eu.equinix.com: [address-policy-wg]newpolicy idea for PA allocations] > To use the example below, an organization needs a /15, but the only > blocks left are 2 /17s, 1 /18, 5 /19s and 2 /20s. If the idea became > policy, an organization shows it needs a /15 for the next 12 months. > ARIN would allocate the /17. That would accommodate the org for an > average of three months. Three months later, all things the same, they > would apply again for a /15 for the next 12 months. They would get a > /17, and so the loop continues. 12 months later, they would have a > /15, but through submitting ten applications instead of one. I don't know if this potential proposal is a good idea or not, but isn't the point of it that by the time the org uses half of their qualification (three months later), ARIN would be completely out? Org qualifies for /15 but gets /17. During that three months, the other /17, /18, and many of the /19s are assigned to others. Org qualifies for a /15 or /16 but gets a /19. Maybe a month later they can get a /22, but by that point IPv4 is gone. The goal (I think) would be to distribute the last assignments among more organizations, so that one well-timed mammoth application does deplete the remaining pool, meaning Mammoth ISP is the only one who growsv4 that year/ever again. Mostly playing devil's advocate. Lee _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From JOHN at egh.com Fri Aug 8 17:42:22 2008 From: JOHN at egh.com (John Santos) Date: Fri, 8 Aug 2008 17:42:22 -0400 Subject: [arin-ppml] [Remco.vanMook@eu.equinix.com:[address-policy-wg]newpolicyidea for PA allocations] In-Reply-To: <4C80F17364FE2E4C93053BE9D01DB47909341AE3@BCMSG111.corp.ads> Message-ID: <1080808170724.43090B-100000@Ives.egh.com> (Not sure if I should top-post or bottom-post as this thread seems to be a mixture!) There may be other ways of fullfilling the same goal (which, as I understand it, is preventing one large allocation from consuming all the remaining address space.) As the bigger chunks get allocated, requests start getting filled by allocating/assigning multiple smaller chunks. (Someone reported this has already happened, but in that case, one of the smaller chunks was contiguous with one of their existing allocations. That shouldn't count in this scenario.) My suggestion is putting an upper limit on the number of "chunks" that will be issued to satisfy a request. The requests would be filled on a first-come/first-served on a best effort basis, but no more than X "chunks". I think X=4 would probably be appropriate, but that's just a gut feeling. Say there are 1 /8, 3 /12's, 15 /16's and 240 /20's left. Some one requests a /14, they get a 1/4 of 1 of the /12's, or however the staff would handle this now. Someone asks for a /16, they just get it. Sometime later, the last /8 is gone, or split up, and someone needs a /10. They get the last 3 /12's and one /16. (If someone asked for a /8, instead they get the same thing.) Now ARIN's down to a handful of /16's and loads of smaller blocks. If someone requests a /10, they get 4 /16's, not everything that's left. It seems to me this might be easier for the staff to handle; they just go through their normal allocation procedure, but after hitting the 4th time through the loop trying to satisfy the request, they stop. It seems to me this is a policy, not an operational matter, since it answers the question "What do we do when someone requests an allocation larger than (or of the same order of magnitude) as the remaining available address space?" Do we want pure first-come/first-served, or do we want some kind of "everybody gets a little bit" policy? Whether any of these schemes actually work depends on the latency and queue depth. If the latency and queue depth are 0, the requester just keeps filing requests until they got all the space they need or ARIN runs out completely. If they have to wait some period (either a few days or weeks while the allocation procedure executes, or several months to a year if a minumum "can't request more" period expires, then others will get a chance to put in their requests. If the queue depth is non-zero, then at least those others in queue, even with a minimal request interval, will get their (partial) allocations. I don't understand how the rules about requesting more space apply in this circumstance (I though you had to wait at least 6 months, but maybe you just have to wait until you can demonstrate usage of your supposed 6-month supply.) And I have no idea what the queue depth is (how many people/organizations have filed requests for allocations that have not yet been fulfilled) at any given moment. I hope this suggestion doesn't just muddy the waters. -- John On Fri, 8 Aug 2008, Matthew Wilder wrote: > As the last email here mentions, this is really a matter of spreading out truly the last of the IP Address wealth. If there is enough for the banker to get his fill and everyone else before the banker comes back again, any change in policy will probably > be nothing more than a wasteful exercise in > itself. If people agree that it is the scenario in question that raises concern (banker getting the last of the gas) then maybe there is a place for a policy given the following condition. > > Condition: > Projections show that a RIR's available pool of addresses is due to exhaust in approximately 12 months or less. > > Policy that activates upon this condition: > The RIR begins to satisfy each ISP's 3 month requirement of IP Addresses, as opposed to their 6 or 12 month projections. > > Implications: > In theory, as long as requests do not irrationally accelerate (which can itself be encouraged) then the last of the IP Addresses won't be entirely consumed by as large allocations. This policy would result in a somewhat greater level of fragmentation dur > ing the final allocations, but delays the > timing of the increased fragmentation from other suggestions. > > -MW > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel > Sent: Friday, August 08, 2008 12:00 PM > To: ppml at arin.net > Subject: Re: [arin-ppml][Remco.vanMook at eu.equinix.com:[address-policy-wg]newpolicyidea for PA allocations] > > Yeah, but let's say you are the local small town gas station.. You are running close to empty so your pumps only put out 3 gallons at a time and you have 60 gallons left. There is a line of cars at the pump, some boy scouts who need to make money for ca > mp with their lawn mower are waiting > patiently and washing windows, your mom is at the back of the line. On top of all this you remember you didn't fill your suburban this morning.. Do you let the banker who is at the head of the line buy all 60 gallons for an exhorbitant fee or do you spr > ead it out around town?? > > I'm not saying one is better than the other, but you do have choices to make.. > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Alexander, Daniel > Sent: Friday, August 08, 2008 10:20 AM > To: Howard, W. Lee; ppml at arin.net > Subject: Re: [arin-ppml] > [Remco.vanMook at eu.equinix.com:[address-policy-wg]newpolicy idea for PA allocations] > > > Don't get me wrong, I wasn't trying to dismiss the thought, but was playing a little devil's advocate myself. Back in May I offered up some thoughts along a similar line. > > What you say is true, provided the "best fit" allocation made to organization X provides an adequate window of time for other organizations to get to the remaining reserves. This would leave little or nothing left by the time org X comes back, as you ment > ion. > > The problem comes in when you have an org that can justify a /12, and is only given a /17. This scenario is where you would need a time requirement restricting future allocations for some number of months. > Without a time restriction, there is nothing to prevent that org from submitting applications every other day and depleting what's left before anyone else can get to it. > > -Dan > > -----Original Message----- > From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com] > Sent: Thursday, August 07, 2008 5:08 PM > To: Alexander, Daniel; ppml at arin.net > Subject: RE: [arin-ppml] [Remco.vanMook at eu.equinix.com: > [address-policy-wg]newpolicy idea for PA allocations] > > > > To use the example below, an organization needs a /15, but the only > > blocks left are 2 /17s, 1 /18, 5 /19s and 2 /20s. If the idea became > > policy, an organization shows it needs a /15 for the next 12 months. > > ARIN would allocate the /17. That would accommodate the org for an > > average of three months. Three months later, all things the same, they > > > would apply again for a /15 for the next 12 months. They would get a > > /17, and so the loop continues. 12 months later, they would have a > > /15, but through submitting ten applications instead of one. > > I don't know if this potential proposal is a good idea or not, but isn't the point of it that by the time the org uses half of their qualification (three months later), ARIN would be completely out? > > Org qualifies for /15 but gets /17. During that three months, the other /17, /18, and many of the /19s are assigned to others. > Org qualifies for a /15 or /16 but gets a /19. Maybe a month later they can get a /22, but by that point IPv4 is gone. The goal (I think) would be to distribute the last assignments among more organizations, so that one well-timed mammoth application do > es deplete the remaining pool, meaning > Mammoth ISP is the only one who growsv4 that year/ever again. > > Mostly playing devil's advocate. > > Lee -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From info at arin.net Mon Aug 11 12:13:28 2008 From: info at arin.net (Member Services) Date: Mon, 11 Aug 2008 12:13:28 -0400 Subject: [arin-ppml] Deadline for Policy Proposals - 16 August 2008 Message-ID: <48A06528.7060009@arin.net> The ARIN XXII Public Policy Meeting will take place 15-16 October 2008 in Los Angeles. New policy proposals must be submitted by 23:59 EDT, 16 August 2008, in order to be considered by the ARIN Advisory Council for possible inclusion on the ARIN XXII agenda. The ARIN Internet Resource Policy Evaluation Process requires 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 policies must submit a Policy Proposal Template. Send the template via e-mail to policy at arin.net. The Policy Proposal Template can be found at: http://www.arin.net/policy/irpep_template.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) From owen at delong.com Thu Aug 14 17:23:07 2008 From: owen at delong.com (Owen DeLong) Date: Thu, 14 Aug 2008 14:23:07 -0700 Subject: [arin-ppml] Fwd: Proposed Revision to 2007-14 References: <48A48053.9070709@sprunk.org> Message-ID: <24F7948C-5D0A-43DB-8A53-C671FA790F81@delong.com> Here is a revised 2007-14. It attempts to incorporate the feedback received from ARIN XXI and the mailing list up to this point as well as feedback from ARIN staff and other contributors. ================================================ Policy Proposal 2007-14 Resource Review Process Author: Owen DeLong, Stephen Sprunk Proposal Version: 3.0 Date: 14 August 2008 Proposal type: modify Policy term: permanent Policy statement: Add the following to the NRPM: Resource Review 1. ARIN may review the current usage of any resources covered by an ARIN RSA within the terms of that RSA. The organization shall cooperate with any request from ARIN for reasonable related documentation. 2. ARIN may conduct such reviews: a. when any new resource is requested, b. whenever ARIN has reason to believe that the resources were originally obtained fraudulently, or c. at any other time without having to establish cause unless a prior review has been completed in the preceding 24 months. 3. ARIN shall communicate the results of the review to the organization. 4. Organizations found by ARIN to be substantially out of compliance with current ARIN policy shall be requested or required to return resources as needed to bring them into (or reasonably close to) compliance. 4a. The extent to which an organization may remain out of compliance shall be based on the reasonable judgment of the ARIN staff and shall balance all facts known, including the organizations utilization rate, available address pool, and other factors as appropriate so as to avoid forcing returns which will result in near-term additional requests or unnecessary route de-aggregation. 4b. To the extent possible, entire blocks should be returned. Partial address blocks shall be returned in such a way that the portion retained will comprise a single aggregate block. 5. If the organization does not voluntarily return resources as requested, ARIN may revoke any resources issued by ARIN as required to bring the organization into overall compliance. ARIN shall follow the same guidelines for revocation that are required for voluntary return in the previous paragraph. 6. Except in cases of fraud, or intentional violations of policy, an organization shall be given a minimum of six months to effect a return. ARIN shall negotiate a longer term with the organization if ARIN believes the organization is working in good faith to substantially restore compliance and has a valid need for additional time to renumber out of the affected blocks. 7. ARIN shall continue to maintain the resource(s) while their return or revocation is pending, except any maintenance fees assessed during that period shall be calculated as if the return or revocation was complete. 8. Legacy resources in active use, regardless of utilization, are not subject to revocation by ARIN. pursuant to this subsection. However, the utilization of legacy resources shall be considered during a review to assess overall compliance. 9. In considering compliance with policies which allow a timeframe (such as a requirement to assign some number of prefixes within 5 years) failure to comply cannot be measured until after the timeframe specified in the applicable policy has elapsed. Blocks subject to such a policy shall be assumed in compliance with that policy until such time as the specified time since issuance has elapsed. Delete NRPM sections 4.1.2, 4.1.3, 4.1.4 Remove the sentence "In extreme cases, existing allocations may be affected." from NRPM section 4.2.3.1. Rationale: Under current policy and existing RSAs, ARIN has an unlimited authority to audit or review a resource holder's utilization for compliance at any time and no requirement to communicate the results of any such review to the resource holder. This policy attempts to balance the needs of the community and the potential for abuse of process by ARIN in a way that better clarifies the purpose, scope, and capabilities of ARIN and codifies some appropriate protections for resource holders while still preserving the ability for ARIN to address cases of fraud and abuse on an expedited basis. The intended nature of the review is to be no more invasive than what usually happens when an organization applies for additional resources. Additionally, paragraph 2c prevents ARIN from doing excessive without-cause reviews. The authors believe that this update addresses the majority of the feedback received from the community to date and addresses most of the concerns expressed. Owen From info at arin.net Fri Aug 15 10:41:24 2008 From: info at arin.net (Member Services) Date: Fri, 15 Aug 2008 10:41:24 -0400 Subject: [arin-ppml] ARIN Board Adopts Policy Proposal 2007-17: Legacy Outreach and Partial Reclamation Message-ID: <48A59594.3020508@arin.net> On 11 August 2008 the ARIN Board of Trustees adopted the following policy proposal as amended by the ARIN Advisory Council: 2007-17: Legacy Outreach and Partial Reclamation The AC removed the following sentence: "ARIN should reject any transaction which staff judges is not in the interests of the community." The AC replaced that sentence with: "Transactions should only be accepted under this policy if they are in the interests of the community (e.g. they improve aggregation or result in a net reclamation of space)." 2007-17 will be implemented no later than 15 November 2008 Policy proposal texts are available at the Policy Proposal Archive which can be found at: http://www.arin.net/policy/proposal_archive.html Regards, Member Services Department American Registry for Internet Numbers (ARIN) From info at arin.net Fri Aug 15 10:44:31 2008 From: info at arin.net (Member Services) Date: Fri, 15 Aug 2008 10:44:31 -0400 Subject: [arin-ppml] Fwd: Proposed Revision to 2007-14 In-Reply-To: <24F7948C-5D0A-43DB-8A53-C671FA790F81@delong.com> References: <48A48053.9070709@sprunk.org> <24F7948C-5D0A-43DB-8A53-C671FA790F81@delong.com> Message-ID: <48A5964F.2080401@arin.net> Policy Proposal 2007-14: Resource Review Process has been revised. This proposal is open for discussion on this mailing list and will be on the agenda at the upcoming ARIN Public Policy Meeting. The current policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_14.html Regards, Member Services American Registry for Internet Numbers (ARIN) Owen DeLong wrote: > Here is a revised 2007-14. It attempts to incorporate the > feedback received from ARIN XXI and the mailing list up > to this point as well as feedback from ARIN staff and > other contributors. > > ================================================ > > Policy Proposal 2007-14 > Resource Review Process > > Author: Owen DeLong, Stephen Sprunk > > Proposal Version: 3.0 > > Date: 14 August 2008 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Add the following to the NRPM: > > Resource Review > > 1. ARIN may review the current usage of any resources covered > by an ARIN RSA within the terms of that RSA. The organization > shall cooperate with any request from ARIN for reasonable related > documentation. > > 2. ARIN may conduct such reviews: > > a. when any new resource is requested, > > b. whenever ARIN has reason to believe that the resources were > originally obtained fraudulently, or > > c. at any other time without having to establish cause unless a prior > review has been completed in the preceding 24 months. > > 3. ARIN shall communicate the results of the review to the organization. > > 4. Organizations found by ARIN to be substantially out of compliance > with current ARIN policy shall be requested or required to return > resources as needed to bring them into (or reasonably close to) > compliance. > > 4a. The extent to which an organization may remain out of compliance > shall be based on the reasonable judgment of the ARIN staff and shall > balance all facts known, including the organizations utilization rate, > available address pool, and other factors as appropriate so as to avoid > forcing returns which will result in near-term additional requests or > unnecessary route de-aggregation. > > 4b. To the extent possible, entire blocks should be returned. Partial > address blocks shall be returned in such a way that the portion retained > will comprise a single aggregate block. > > 5. If the organization does not voluntarily return resources as > requested, ARIN may revoke any resources issued by ARIN as required to > bring the organization into overall compliance. ARIN shall follow the > same guidelines for revocation that are required for voluntary return in > the previous paragraph. > > 6. Except in cases of fraud, or intentional violations of policy, an > organization shall be given a minimum of six months to effect a return. > ARIN shall negotiate a longer term with the organization if ARIN > believes the organization is working in good faith to substantially > restore compliance and has a valid need for additional time to renumber > out of the affected blocks. > > 7. ARIN shall continue to maintain the resource(s) while their return or > revocation is pending, except any maintenance fees assessed during > that period shall be calculated as if the return or revocation was > complete. > > 8. Legacy resources in active use, regardless of utilization, are not > subject to revocation by ARIN. pursuant to this subsection. However, the > utilization of legacy resources shall be considered during a review to > assess overall compliance. > > 9. In considering compliance with policies which allow a timeframe (such > as a requirement to assign some number of prefixes within 5 years) > failure to comply cannot be measured until after the timeframe specified > in the applicable policy has elapsed. Blocks subject to such a policy > shall be assumed in compliance with that policy until such time as the > specified time since issuance has elapsed. > > Delete NRPM sections 4.1.2, 4.1.3, 4.1.4 > > Remove the sentence "In extreme cases, existing allocations may be > affected." from NRPM section 4.2.3.1. > > Rationale: > > Under current policy and existing RSAs, ARIN has an unlimited authority > to audit or review a resource holder's utilization for compliance at > any time > and no requirement to communicate the results of any such review to the > resource holder. > > This policy attempts to balance the needs of the community and the > potential for abuse of process by ARIN in a way that better clarifies > the purpose, scope, and capabilities of ARIN and codifies some > appropriate > protections for resource holders while still preserving the ability for > ARIN to address cases of fraud and abuse on an expedited basis. > > The intended nature of the review is to be no more invasive than > what usually happens when an organization applies for additional > resources. Additionally, paragraph 2c prevents ARIN from doing > excessive without-cause reviews. > > The authors believe that this update addresses the majority of the > feedback received from the community to date and addresses > most of the concerns expressed. > > Owen > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > From info at arin.net Mon Aug 18 10:35:03 2008 From: info at arin.net (Member Services) Date: Mon, 18 Aug 2008 10:35:03 -0400 Subject: [arin-ppml] Policy Proposal: Emergency Transfer Policy for IPv4 Addresses Message-ID: <48A98897.8080408@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision via the PPML. If a proposal is not accepted, 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 proposal will be closed. The AC will assign shepherds in the near future. ARIN will provide the names of the shepherds to the community via the PPML. In the meantime, the AC invites everyone to comment on this proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Emergency Transfer Policy for IPv4 Addresses Author: Bill Darte Proposal Version: 1.0 Submission Date: August 15, 2008 Proposal type: New Policy term: Temporary Policy statement: 8.2.1 Emergency Transfer Policy for IPv4 Addresses For a period of 3 years from policy implementation, transfer of ARIN IPv4 addresses between two entities in the ARIN region, without the active involvement of ARIN as an intermediary, will be considered legitimate and will be documented accordingly under the following conditions: 1. Transfer takes place from a holder of IPv4 addresses recognized by ARIN as the legitimate and exclusive holder of those resources. 2. Transfer takes place to a recipient that has documented operational need in accordance with current ARIN policy and that signs an RSA with ARIN covering those resources in advance of transfer. 3. Transfer of addresses takes place in such a way that the original contiguous block(s) are not disaggregated into more than 4 resultant network blocks each being greater than or equal to the current minimum sizes specified in applicable ARIN policy. 4. Transfer is complete and unrestricted and is supported by documentation that ARIN deems satisfactory. Rationale: In order for ARIN to fulfill its mission and to facilitate a continuing supply of IPv4 address resources to its service community when ARIN resources are no longer adequate, and to preserve the integrity of documentation and ARIN services for those resources, this policy may be implemented. Its intent is to preserve the current tradition of need-based allocation/assignments for those still needing IPv4 resources during a transition period as the industry adopts IPv6. This policy is not intended to create a 'market' for such transfers and does not introduce or condone the monetization of address resources or a view of addresses as property. It does recognize that organizations making available unused or no longer needed address resources may incur certain costs that might be compensated by those acquiring the resources. This policy is intended to be transient and light-weight and does not encourage a sustained or continuing role for IPv4, but rather helps to mitigate a transitional crisis that may emerge while the industry adopts IPv6 in accordance with the recommendation of ARIN's Board of Trustees. Timetable for implementation: This policy, once ratified by the ARIN Board of Trustees, would be implemented when either the free-pool of IANA addresses is exhausted or IPv4 address resources in the ARIN Region reaches a threshold of scarcity recognized by the ARIN Board of Trustees as requiring this policy implementation. From info at arin.net Mon Aug 18 10:38:53 2008 From: info at arin.net (Member Services) Date: Mon, 18 Aug 2008 10:38:53 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal Message-ID: <48A9897D.50209@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision via the PPML. If a proposal is not accepted, 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 proposal will be closed. The AC will assign shepherds in the near future. ARIN will provide the names of the shepherds to the community via the PPML. In the meantime, the AC invites everyone to comment on this proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Whois Integrity Policy Proposal Author: Heather Schiller Proposal Version: 1 Submission Date: August 15, 2008 Policy statement: To ensure the integrity of information in the ARIN WHOIS Database a resource must be under an RSA (either legacy or traditional) in order to update the WHOIS record. ARIN will not update historical information in the ARIN Whois Database until the resource holder can prove the organization's right to the resource. Rationale: ARIN currently maintains WHOIS and in-addr.arpa delegation records in a best-effort fashion. In many cases ARIN does not have a formal agreement with the legacy resource holders. Legacy records are frequently out of date and have become an increasingly popular target for hijackers. Having up to date contact information and a formal relationship with legacy record holders would assist ARIN and ISP's in ensuring these records are maintained accurately. A similar policy was successfully adopted in the APNIC region. (http://www.apnic.net/policy/proposals/prop-018-v001.html) Timetable for implementation: Within sixty (60) days of approval - with notification to current POC email addresses listed on historical assignments, or as soon as reasonable for ARIN staff. From Keith at jcc.com Mon Aug 18 10:50:34 2008 From: Keith at jcc.com (Keith W. Hare) Date: Mon, 18 Aug 2008 10:50:34 -0400 Subject: [arin-ppml] Whois Integrity Policy Proposal -- What is proof and how big is the problem? Message-ID: The Whois Integrity Policy Proposal says: ARIN will not update historical information in the ARIN Whois Database until the resource holder can prove the organization's right to the resource. What documentation will be required for an organization to prove their right to a resource? The APNIC proposal provided some statistics about how many organizations might be affected by their proposal. Are there any counts available for ARIN? Keith ______________________________________________________________ Keith W. Hare JCC Consulting, Inc. keith at jcc.com 600 Newark Road Phone: 740-587-0157 P.O. Box 381 Fax: 740-587-0163 Granville, Ohio 43023 http://www.jcc.com USA ______________________________________________________________ From JOHN at egh.com Mon Aug 18 11:53:54 2008 From: JOHN at egh.com (John Santos) Date: Mon, 18 Aug 2008 11:53:54 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <48A9897D.50209@arin.net> Message-ID: <1080818114257.27224B-100000@Ives.egh.com> On Mon, 18 Aug 2008, Member Services wrote: > Policy statement: > > To ensure the integrity of information in the ARIN WHOIS Database a > resource must be under an RSA (either legacy or traditional) in order to > update the WHOIS record. ARIN will not update historical information in > the ARIN Whois Database until the resource holder can prove the > organization's right to the resource. Which is it, the resource must be under an RSA, or the holder must be able to prove their right to the resource? These are not the same thing. > > > Rationale: > > ARIN currently maintains WHOIS and in-addr.arpa delegation records in a > best-effort fashion. In many cases ARIN does not have a formal > agreement with the legacy resource holders. Legacy records are > frequently out of date and have become an increasingly popular target > for hijackers. Having up to date contact information and a formal > relationship with legacy record holders would assist ARIN and ISP's in > ensuring these records are maintained accurately. A similar policy was > successfully adopted in the APNIC region. > (http://www.apnic.net/policy/proposals/prop-018-v001.html) By requiring an RSA, this policy in fact does not implement the rationale, but actively subverts it. *MY* whois information is currently up-to-date and accurate for my legacy /24, but under this policy, I could not update it in the future if my company offices move or if someone else were to take over the POC roles, or if, as has happened in the past, our telephone area code or postal zip code were to change. > > Timetable for implementation: > > Within sixty (60) days of approval - with notification to current POC > email addresses listed on historical assignments, or as soon as > reasonable for ARIN staff. I already get an annual email requiring that I visit the ARIN web site and update the contact info or confirm that it is unchanged. What does this policy bring to the table that that's not already there? A bigger stick? -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From info at arin.net Mon Aug 18 13:04:50 2008 From: info at arin.net (Member Services) Date: Mon, 18 Aug 2008 13:04:50 -0400 Subject: [arin-ppml] Policy Proposal 2008-3: Community Networks IPv6 Allocation - Revised Message-ID: <48A9ABB2.6030508@arin.net> Policy Proposal "2008-3: Community Networks IPv6 Allocation" has been revised. This proposal is open for discussion on this mailing list and will be on the agenda at the upcoming ARIN Public Policy Meeting. The current policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2008_3.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2008-3 Community Networks IPv6 Allocation Author: Joshua King Date: 18 August 2008 Proposal type: new Policy term: permanent Policy statement: [Add Section 2.8 to the NRPM.] 2.8 Community Network A community network is a generic reference to any network that is operated by a group of people living in a particular local area organized for the purposes of delivery or provision of free or low-cost network services to the residents of an incorporated or unincorporated regional municipality, city, town, village, rural municipality, township, county, district or other municipality or other such geographic space, however designated. Legal responsibility for the network as a whole must be held by an organization either possessing federal non-profit status or fiscally sponsored by a non-profit organization. [Modify 6.5.8.1b as follows.] b. qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect or be a Community Network as defined in Section 2.8, with allocation criteria defined in section 6.5.9. [Add Section 6.5.9 to the NRPM.] 6.5.9 Community Network Allocations 6.5.9.1. Initial assignment size Organizations defined as Community Networks under section 2.8 are eligible to receive a direct assignment. The minimum size of the assignment is /48. Organizations requesting a larger assignment must provide documentation of the characteristics of the Community Network's size and architecture that require the use of additional subnets. An HD-Ratio of .94 with respect to subnet utilization within the network must be met for all assignments larger than a /48. These assignments shall be made from a distinctly identified prefix and shall be made with a reservation for growth of at least a /44. This reservation may be assigned to other organizations later, at ARIN's discretion. 6.5.9.2. Subsequent assignment size Additional assignments may be made when the need for additional subnets is justified. Justification will be determined based on a detailed plan of the network's architecture and the .94 HD-Ratio metric. When possible, assignments will be made from an adjacent address block. 6.5.9.3. Number of customers Community Networks seeking an allocation must demonstrate that they provide for a user base of at least 100 through connectivity to homes and businesses, public facilities, public access points, or mobile users. Community Networks with user bases of under 200 must also submit a plan for doubling their service base over the next year. Rationale: There are currently a number of projects globally that aim to develop community network infrastructure and related technologies. These are usually coordinated by volunteer-run, grassroots organizations which lack many of the resources of traditional internet service providers and other network operators. They have diverse goals, including public policy, software development, and implementation of community services and resources. Many of them provide services free of charge, and thus lack any paying user base. However, in order to create and maintain community networks that are often composed of hundreds if not thousands of inexpensive consumer-grade network devices, a significant amount of address space will be required. Current-generation workarounds to this problem, such as NAT, not only make it difficult to develop next-generation decentralized network technology by segmenting the community's architecture from the Internet as a whole, but will cease to be as viable a stopgap as the Internet moves towards IPv6 integration. Community-based, volunteer-run organizations that are operated with an eye towards the public good often do not have the resources to qualify as an LIR under the current policy. They are often multi-homed networks utilizing multiple, relatively inexpensive consumer-grade internet uplinks and lacking the funds to meet the qualifications for an IPv4 allocation, but which wish an avenue to develop future IPv6 capability for their constituent users. By establishing a procedure by which these organizations can seek to acquire the resources they require for further development, ARIN can reach out to this active community and establish a small but definite space for them in the future of Internet. Timetable for implementation: Immediate. From info at arin.net Mon Aug 18 13:09:15 2008 From: info at arin.net (Member Services) Date: Mon, 18 Aug 2008 13:09:15 -0400 Subject: [arin-ppml] Policy Proposal 2008-4: Minimum Allocation in the Caribbean Region - Revised Message-ID: <48A9ACBB.8010805@arin.net> Policy Proposal "Policy Proposal 2008-4: Minimum Allocation in the Caribbean Region" has been revised. This proposal is open for discussion on this mailing list and will be on the agenda at the upcoming ARIN Public Policy Meeting. The authors requested it be stated that the changes were strictly formatting and adding NRPM section numbers. The current policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2008_4.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2008-4 Minimum Allocation in the Caribbean Region Author: Cathy Aronson and Paul Andersen Proposal Version: 2008-4.02 Date: 18 August 2008 Proposal type: new Policy term: renewable Policy statement: Add the following as section 4.8 of NRPM: 4.8. Minimum Allocation. The minimum IPv4 allocation size for ISPs from the Caribbean portion of the ARIN region is /22. 4.8.1. Allocation Criteria. * 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. * 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. * Utilization Reporting and Justification. All other ARIN policies regarding the reporting of justification information for the allocation of IPv4 and IPv6 address space will remain in effect. Rationale: ARIN staff have noted that organizations in the Caribbean region have problems meeting the current criteria due to the fact that the population in the region is smaller than that of Canada and the US. There is also a lack of competition with many countries in the region faced with a monopoly or duopoly situation in terms of transport providers. To spur development in the region a similar proposal was passed in this region for the portion of the African region that ARIN administered prior to the formation of AfriNIC. This proposal seeks a similar outcome. Timetable for implementation: immediate Revisions Made: * 2008-4.02 - Minor edit to specify proposed NRPM section number From info at arin.net Mon Aug 18 14:37:24 2008 From: info at arin.net (Member Services) Date: Mon, 18 Aug 2008 14:37:24 -0400 Subject: [arin-ppml] Call for Nominations: ARIN Board, AC, and NRO NC Message-ID: <48A9C164.3020800@arin.net> You have until 17:00 ET, this Wednesday 20 August to submit nominations for the ARIN Board of Trustees (2 open seats) and Advisory Council (5 open seats). This is also your last chance to nominate candidates for the one (1) open Number Resource Organization (NRO) Number Council seat. This is your opportunity to have an impact on ARIN's policy-making process. Nomination forms and election information are available through ARIN Election Headquarters at: https://app.arin.net/election/ All nominees are subject to the Nomination and Appointment Conflict of Interest List at: http://www.arin.net/elections/electionguidelines.html#conflicts The initial slate of candidates will be posted online on 11 September 2008. Online voting for the Board and Advisory Council will begin on the last day of the ARIN XXII Public Policy and Members Meetings in October. This year, the ARIN Board of Trustees will appoint the NRO NC representative from the ARIN region, voting on candidates nominated by the community. Now is also a good time for members to check with ARIN Member Services to make certain that they have a designated member representative (DMR) eligible to vote in the upcoming election. Direct any questions to Member Services at info at arin.net. Regards, Member Services American Registry for Internet Numbers (ARIN) From vixie at isc.org Mon Aug 18 15:29:51 2008 From: vixie at isc.org (Paul Vixie) Date: Mon, 18 Aug 2008 19:29:51 +0000 Subject: [arin-ppml] Call for Nominations: ARIN Board, AC, and NRO NC In-Reply-To: Your message of "Mon, 18 Aug 2008 14:37:24 -0400." <48A9C164.3020800@arin.net> References: <48A9C164.3020800@arin.net> Message-ID: <63074.1219087791@nsa.vix.com> as chair of this year's nomcom let me reach out to everybody -- democracy requires participation, not just a high voter turnout, but a strong slate of candidates. if you havn't nominated somebody yet, please think about who you know and who might be a good member of the ARIN Board, ARIN AC, or NRO NC. self nominations are also allowed. let's show each other and the world how strong ARIN's community representation and participation really is. re: > Date: Mon, 18 Aug 2008 14:37:24 -0400 > From: Member Services > User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) > To: arin-ppml at arin.net > Subject: [arin-ppml] Call for Nominations: ARIN Board, AC, and NRO NC > Sender: arin-ppml-bounces at arin.net > X-Vix-MailScanner-Information: Please contact the ISP for more information > X-Vix-MailScanner: Found to be clean > X-Vix-MailScanner-From: arin-ppml-bounces at arin.net > > You have until 17:00 ET, this Wednesday 20 August to submit nominations > for the ARIN Board of Trustees (2 open seats) and Advisory Council (5 > open seats). This is also your last chance to nominate candidates for > the one (1) open Number Resource Organization (NRO) Number Council seat. > This is your opportunity to have an impact on ARIN's policy-making process. > > Nomination forms and election information are available through ARIN > Election Headquarters at: > > https://app.arin.net/election/ > > All nominees are subject to the Nomination and Appointment Conflict of > Interest List at: > > http://www.arin.net/elections/electionguidelines.html#conflicts > > The initial slate of candidates will be posted online on 11 September > 2008. Online voting for the Board and Advisory Council will begin on the > last day of the ARIN XXII Public Policy and Members Meetings in October. > > This year, the ARIN Board of Trustees will appoint the NRO NC > representative from the ARIN region, voting on candidates nominated by > the community. > > Now is also a good time for members to check with ARIN Member Services > to make certain that they have a designated member representative (DMR) > eligible to vote in the upcoming election. Direct any questions to > Member Services at info at arin.net. > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From tedm at ipinc.net Mon Aug 18 16:02:24 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 18 Aug 2008 13:02:24 -0700 Subject: [arin-ppml] Call for Nominations: ARIN Board, AC, and NRO NC In-Reply-To: <63074.1219087791@nsa.vix.com> Message-ID: As an old political hand please accept my amendment of your statement: "...turnout, but a strong slate of candidates..." to the following: "...turnout, but a slate of strong candidates..." I don't care if only a single person is running, as long as they are the -right- person, it is much more preferable than a large slate of fools. Any observer of the US Congress should be familiar with the second set... Ted > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Paul Vixie > Sent: Monday, August 18, 2008 12:30 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Call for Nominations: ARIN Board, > AC, and NRO NC > > > as chair of this year's nomcom let me reach out to everybody > -- democracy requires participation, not just a high voter > turnout, but a strong slate of candidates. if you havn't > nominated somebody yet, please think about who you know and > who might be a good member of the ARIN Board, ARIN AC, or NRO > NC. self nominations are also allowed. let's show each > other and the world how strong ARIN's community > representation and participation really is. > > re: > > > Date: Mon, 18 Aug 2008 14:37:24 -0400 > > From: Member Services > > User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) > > To: arin-ppml at arin.net > > Subject: [arin-ppml] Call for Nominations: ARIN Board, AC, > and NRO NC > > Sender: arin-ppml-bounces at arin.net > > X-Vix-MailScanner-Information: Please contact the ISP for more > > information > > X-Vix-MailScanner: Found to be clean > > X-Vix-MailScanner-From: arin-ppml-bounces at arin.net > > > > You have until 17:00 ET, this Wednesday 20 August to submit > > nominations for the ARIN Board of Trustees (2 open seats) > and Advisory > > Council (5 open seats). This is also your last chance to nominate > > candidates for the one (1) open Number Resource Organization (NRO) > > Number Council seat. This is your opportunity to have an impact on > > ARIN's policy-making process. > > > > Nomination forms and election information are available > through ARIN > > Election Headquarters at: > > > > https://app.arin.net/election/ > > > > All nominees are subject to the Nomination and Appointment > Conflict of > > Interest List at: > > > > http://www.arin.net/elections/electionguidelines.html#conflicts > > > > The initial slate of candidates will be posted online on 11 > September > > 2008. Online voting for the Board and Advisory Council will > begin on > > the last day of the ARIN XXII Public Policy and Members Meetings in > > October. > > > > This year, the ARIN Board of Trustees will appoint the NRO NC > > representative from the ARIN region, voting on candidates > nominated by > > the community. > > > > Now is also a good time for members to check with ARIN > Member Services > > to make certain that they have a designated member representative > > (DMR) eligible to vote in the upcoming election. Direct any > questions > > to Member Services at info at arin.net. > > > > Regards, > > > > Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed > to the ARIN > > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage > > your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > -- > > This message has been scanned for viruses and > > dangerous content by MailScanner, and is > > believed to be clean. > > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From kmedcalf at dessus.com Tue Aug 19 12:04:11 2008 From: kmedcalf at dessus.com (Keith Medcalf) Date: Tue, 19 Aug 2008 12:04:11 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <48A9897D.50209@arin.net> Message-ID: <83bdbd29a0719344bbdfc3ad74251a96@mail.dessus.com> This is a really stupid idea and I, for one, am completely against it. My Legacy /24 registration data is up-to-date. If the intention is that I not update it anymore then the proper course of action is to note that the resources are "delegated" outside of the ARIN system (by the US DoC or DDNNIC for example) and then REMOVE PUBLIC VISIBILITY of all my personal information. I sure the Legacy resource holders can come up with a completely separate system to monitor those resources -- and without needing to use EXTORTION to get it going. > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > Sent: Monday, 18 August, 2008 10:39 > To: arin-ppml at arin.net > Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal > > ARIN received the following policy proposal. In accordance > with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and > being placed on > ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal at their next > regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as written. If the AC accepts the > proposal, > it will be posted as a formal policy proposal to PPML and it will be > presented at a Public Policy Meeting. > > 2. Not accept the proposal. If the AC does not accept > the proposal, > the AC will explain their decision via the PPML. If a proposal is not > accepted, 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 proposal will be closed. > > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this > proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their > deliberations. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > Policy Proposal Name: Whois Integrity Policy Proposal > > Author: Heather Schiller > > Proposal Version: 1 > > Submission Date: August 15, 2008 > > Policy statement: > > To ensure the integrity of information in the ARIN WHOIS Database a > resource must be under an RSA (either legacy or traditional) > in order to > update the WHOIS record. ARIN will not update historical > information in > the ARIN Whois Database until the resource holder can prove the > organization's right to the resource. > > > Rationale: > > ARIN currently maintains WHOIS and in-addr.arpa delegation > records in a > best-effort fashion. In many cases ARIN does not have a formal > agreement with the legacy resource holders. Legacy records are > frequently out of date and have become an increasingly popular target > for hijackers. Having up to date contact information and a formal > relationship with legacy record holders would assist ARIN and ISP's in > ensuring these records are maintained accurately. A similar > policy was > successfully adopted in the APNIC region. > (http://www.apnic.net/policy/proposals/prop-018-v001.html) > > Timetable for implementation: > > Within sixty (60) days of approval - with notification to current POC > email addresses listed on historical assignments, or as soon as > reasonable for ARIN staff. > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From oberman at es.net Tue Aug 19 13:27:16 2008 From: oberman at es.net (Kevin Oberman) Date: Tue, 19 Aug 2008 10:27:16 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: Your message of "Tue, 19 Aug 2008 12:04:11 EDT." <83bdbd29a0719344bbdfc3ad74251a96@mail.dessus.com> Message-ID: <20080819172716.2FFF74501A@ptavv.es.net> Keith, I think you are mis-reading the proposal and I think the wording needs some serious work as I am not sure that you are. I believe that this proposal is an attempt to prevent the hijacking of legacy space. There have been to cases of such hijacking that have gotten a fair amount of attention and another that was confusion over who owned a legacy block. These all resulted from modification of ARIN records for legacy spaces by people who should not have been able to modify it, but were able to do so due to the lack of confirmed data on legacy space. I do not think that this is an effort to make life difficult for legacy holders (including my employer), but to prevent the theft of their address space. Heather, can you clarify? (Seems that Verizon Business was involved in one to the cases I mentioned...not as a hijacker, of course.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > Date: Tue, 19 Aug 2008 12:04:11 -0400 > From: "Keith Medcalf" > Sender: arin-ppml-bounces at arin.net > > > This is a really stupid idea and I, for one, am completely against it. > > My Legacy /24 registration data is up-to-date. If the intention is that I not update it anymore then the proper course of action is to note that the resources are "delegated" outside of the ARIN system (by the US DoC or DDNNIC for example) and then REMOVE PUBLIC VISIBILITY of all my personal information. > > I sure the Legacy resource holders can come up with a completely separate system to monitor those resources -- and without needing to use EXTORTION to get it going. > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > > Sent: Monday, 18 August, 2008 10:39 > > To: arin-ppml at arin.net > > Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal > > > > ARIN received the following policy proposal. In accordance > > with the ARIN > > Internet Resource Policy Evaluation Process, the proposal is being > > posted to the ARIN Public Policy Mailing List (PPML) and > > being placed on > > ARIN's website. > > > > The ARIN Advisory Council (AC) will review this proposal at their next > > regularly scheduled meeting. The AC may decide to: > > > > 1. Accept the proposal as written. If the AC accepts the > > proposal, > > it will be posted as a formal policy proposal to PPML and it will be > > presented at a Public Policy Meeting. > > > > 2. Not accept the proposal. If the AC does not accept > > the proposal, > > the AC will explain their decision via the PPML. If a proposal is not > > accepted, 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 proposal will be closed. > > > > The AC will assign shepherds in the near future. ARIN will provide the > > names of the shepherds to the community via the PPML. > > > > In the meantime, the AC invites everyone to comment on this > > proposal on > > the PPML, particularly their support or non-support and the reasoning > > behind their opinion. Such participation contributes to a thorough > > vetting and provides important guidance to the AC in their > > deliberations. > > > > The ARIN Internet Resource Policy Evaluation Process can be found at: > > http://www.arin.net/policy/irpep.html > > > > Mailing list subscription information can be found at: > > http://www.arin.net/mailing_lists/ > > > > Regards, > > > > Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > ## * ## > > > > Policy Proposal Name: Whois Integrity Policy Proposal > > > > Author: Heather Schiller > > > > Proposal Version: 1 > > > > Submission Date: August 15, 2008 > > > > Policy statement: > > > > To ensure the integrity of information in the ARIN WHOIS Database a > > resource must be under an RSA (either legacy or traditional) > > in order to > > update the WHOIS record. ARIN will not update historical > > information in > > the ARIN Whois Database until the resource holder can prove the > > organization's right to the resource. > > > > > > Rationale: > > > > ARIN currently maintains WHOIS and in-addr.arpa delegation > > records in a > > best-effort fashion. In many cases ARIN does not have a formal > > agreement with the legacy resource holders. Legacy records are > > frequently out of date and have become an increasingly popular target > > for hijackers. Having up to date contact information and a formal > > relationship with legacy record holders would assist ARIN and ISP's in > > ensuring these records are maintained accurately. A similar > > policy was > > successfully adopted in the APNIC region. > > (http://www.apnic.net/policy/proposals/prop-018-v001.html) > > > > Timetable for implementation: > > > > Within sixty (60) days of approval - with notification to current POC > > email addresses listed on historical assignments, or as soon as > > reasonable for ARIN staff. > > > > > > > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From ppml at rs.seastrom.com Tue Aug 19 14:36:24 2008 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Tue, 19 Aug 2008 14:36:24 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <20080819172716.2FFF74501A@ptavv.es.net> (Kevin Oberman's message of "Tue, 19 Aug 2008 10:27:16 -0700") References: <20080819172716.2FFF74501A@ptavv.es.net> Message-ID: <867iacam3b.fsf@seastrom.com> Keith, Kevin... Kevin's observations are spot-on. As a legacy space holder who has not yet signed a legacy RSA (but intends to)... As a person who has been involved in unwinding unauthorized changes to the whois database on innocent parties' number resources (both address blocks and ASNs)... I support this proposal. I wasn't involved in this proposal's drafting, but I believe it is in the best interests of all concerned (*even* for those who elect not to sign a legacy RSA) to require an action that is prima facie evidence of fraud if it is undertaken by people who are not truly authorized to do so before updating number resources data. This is not an attempt at a shake-down for $100/year legacy RSA fee, it is an attempt to better protect the assignment records for number resources that are currently assigned to you or your organization. ---Rob (member of, but not speaking for, the AC) "Kevin Oberman" writes: > Keith, > > I think you are mis-reading the proposal and I think the wording needs > some serious work as I am not sure that you are. > > I believe that this proposal is an attempt to prevent the hijacking of > legacy space. There have been to cases of such hijacking that have > gotten a fair amount of attention and another that was confusion over > who owned a legacy block. These all resulted from modification of ARIN > records for legacy spaces by people who should not have been able to > modify it, but were able to do so due to the lack of confirmed data on > legacy space. > > I do not think that this is an effort to make life difficult for legacy > holders (including my employer), but to prevent the theft of their > address space. > > Heather, can you clarify? (Seems that Verizon Business was involved in > one to the cases I mentioned...not as a hijacker, of course.) > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman at es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > > >> Date: Tue, 19 Aug 2008 12:04:11 -0400 >> From: "Keith Medcalf" >> Sender: arin-ppml-bounces at arin.net >> >> >> This is a really stupid idea and I, for one, am completely against it. >> >> My Legacy /24 registration data is up-to-date. If the intention is that I not update it anymore then the proper course of action is to note that the resources are "delegated" outside of the ARIN system (by the US DoC or DDNNIC for example) and then REMOVE PUBLIC VISIBILITY of all my personal information. >> >> I sure the Legacy resource holders can come up with a completely separate system to monitor those resources -- and without needing to use EXTORTION to get it going. >> >> > -----Original Message----- >> > From: arin-ppml-bounces at arin.net >> > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services >> > Sent: Monday, 18 August, 2008 10:39 >> > To: arin-ppml at arin.net >> > Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal >> > >> > ARIN received the following policy proposal. In accordance >> > with the ARIN >> > Internet Resource Policy Evaluation Process, the proposal is being >> > posted to the ARIN Public Policy Mailing List (PPML) and >> > being placed on >> > ARIN's website. >> > >> > The ARIN Advisory Council (AC) will review this proposal at their next >> > regularly scheduled meeting. The AC may decide to: >> > >> > 1. Accept the proposal as written. If the AC accepts the >> > proposal, >> > it will be posted as a formal policy proposal to PPML and it will be >> > presented at a Public Policy Meeting. >> > >> > 2. Not accept the proposal. If the AC does not accept >> > the proposal, >> > the AC will explain their decision via the PPML. If a proposal is not >> > accepted, 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 proposal will be closed. >> > >> > The AC will assign shepherds in the near future. ARIN will provide the >> > names of the shepherds to the community via the PPML. >> > >> > In the meantime, the AC invites everyone to comment on this >> > proposal on >> > the PPML, particularly their support or non-support and the reasoning >> > behind their opinion. Such participation contributes to a thorough >> > vetting and provides important guidance to the AC in their >> > deliberations. >> > >> > The ARIN Internet Resource Policy Evaluation Process can be found at: >> > http://www.arin.net/policy/irpep.html >> > >> > Mailing list subscription information can be found at: >> > http://www.arin.net/mailing_lists/ >> > >> > Regards, >> > >> > Member Services >> > American Registry for Internet Numbers (ARIN) >> > >> > >> > ## * ## >> > >> > Policy Proposal Name: Whois Integrity Policy Proposal >> > >> > Author: Heather Schiller >> > >> > Proposal Version: 1 >> > >> > Submission Date: August 15, 2008 >> > >> > Policy statement: >> > >> > To ensure the integrity of information in the ARIN WHOIS Database a >> > resource must be under an RSA (either legacy or traditional) >> > in order to >> > update the WHOIS record. ARIN will not update historical >> > information in >> > the ARIN Whois Database until the resource holder can prove the >> > organization's right to the resource. >> > >> > >> > Rationale: >> > >> > ARIN currently maintains WHOIS and in-addr.arpa delegation >> > records in a >> > best-effort fashion. In many cases ARIN does not have a formal >> > agreement with the legacy resource holders. Legacy records are >> > frequently out of date and have become an increasingly popular target >> > for hijackers. Having up to date contact information and a formal >> > relationship with legacy record holders would assist ARIN and ISP's in >> > ensuring these records are maintained accurately. A similar >> > policy was >> > successfully adopted in the APNIC region. >> > (http://www.apnic.net/policy/proposals/prop-018-v001.html) >> > >> > Timetable for implementation: >> > >> > Within sixty (60) days of approval - with notification to current POC >> > email addresses listed on historical assignments, or as soon as >> > reasonable for ARIN staff. >> > >> > >> > >> > >> > _______________________________________________ >> > PPML >> > You are receiving this message because you are subscribed to >> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> > Unsubscribe or manage your mailing list subscription at: >> > http://lists.arin.net/mailman/listinfo/arin-ppml >> > Please contact info at arin.net if you experience any issues. >> > >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From randy at psg.com Tue Aug 19 14:41:17 2008 From: randy at psg.com (Randy Bush) Date: Tue, 19 Aug 2008 11:41:17 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <867iacam3b.fsf@seastrom.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> Message-ID: <48AB13CD.2030903@psg.com> > I wasn't involved in this proposal's drafting, but I believe it is in > the best interests of all concerned (*even* for those who elect not to > sign a legacy RSA) to require an action that is prima facie evidence > of fraud if it is undertaken by people who are not truly authorized to > do so before updating number resources data. This is not an attempt > at a shake-down for $100/year legacy RSA fee, it is an attempt to > better protect the assignment records for number resources that are > currently assigned to you or your organization. as i read it, legacy holders are required to sign the egregious rsa to get the benefit (the $100 does not bother me). can you say, "no way?" randy From clifford at hdn.net Tue Aug 19 14:48:17 2008 From: clifford at hdn.net (Clifford) Date: Tue, 19 Aug 2008 14:48:17 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <48AB13CD.2030903@psg.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> Message-ID: <4a23a0620808191148j237eee54hd40ef358043a847a@mail.gmail.com> Can someone explain the details of the Verizon incident? Thanks C. On Tue, Aug 19, 2008 at 2:41 PM, Randy Bush wrote: > > I wasn't involved in this proposal's drafting, but I believe it is in > > the best interests of all concerned (*even* for those who elect not to > > sign a legacy RSA) to require an action that is prima facie evidence > > of fraud if it is undertaken by people who are not truly authorized to > > do so before updating number resources data. This is not an attempt > > at a shake-down for $100/year legacy RSA fee, it is an attempt to > > better protect the assignment records for number resources that are > > currently assigned to you or your organization. > > as i read it, legacy holders are required to sign the egregious rsa to > get the benefit (the $100 does not bother me). can you say, "no way?" > > randy > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleibrand at internap.com Tue Aug 19 14:48:03 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 19 Aug 2008 11:48:03 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <48AB13CD.2030903@psg.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> Message-ID: <48AB1563.4050309@internap.com> Randy, How does APNIC deal with this whole issue of historical addresses? What do you think of their policy? (I've been following sig-policy, but I'm still not quite sure I understand what the current policy is.) -Scott Randy Bush wrote: >> I wasn't involved in this proposal's drafting, but I believe it is in >> the best interests of all concerned (*even* for those who elect not to >> sign a legacy RSA) to require an action that is prima facie evidence >> of fraud if it is undertaken by people who are not truly authorized to >> do so before updating number resources data. This is not an attempt >> at a shake-down for $100/year legacy RSA fee, it is an attempt to >> better protect the assignment records for number resources that are >> currently assigned to you or your organization. > > as i read it, legacy holders are required to sign the egregious rsa to > get the benefit (the $100 does not bother me). can you say, "no way?" > > randy > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From ppml at rs.seastrom.com Tue Aug 19 14:55:37 2008 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Tue, 19 Aug 2008 14:55:37 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <48AB13CD.2030903@psg.com> (Randy Bush's message of "Tue, 19 Aug 2008 11:41:17 -0700") References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> Message-ID: <86skt0ltqu.fsf@seastrom.com> Randy Bush writes: >> I wasn't involved in this proposal's drafting, but I believe it is in >> the best interests of all concerned (*even* for those who elect not to >> sign a legacy RSA) to require an action that is prima facie evidence >> of fraud if it is undertaken by people who are not truly authorized to >> do so before updating number resources data. This is not an attempt >> at a shake-down for $100/year legacy RSA fee, it is an attempt to >> better protect the assignment records for number resources that are >> currently assigned to you or your organization. > > as i read it, legacy holders are required to sign the egregious rsa to > get the benefit (the $100 does not bother me). can you say, "no way?" If you drive a car which has a reputation for being difficult to steal, you benefit from the lower theft rate on that vehicle both in your auto insurance rates and the likelihood that anyone will try to hork it, even if you persist in leaving an ignition key under the floor mat. I believe there is a deterrent value in making a prospective space-thief create more of a paper trail as part of his criminal enterprise. The benefit of that deterrent accrues to everyone regardless of whether he has executed the legacy RSA or not, because it raises the bar across the board. ---Rob From randy at psg.com Tue Aug 19 14:57:24 2008 From: randy at psg.com (Randy Bush) Date: Tue, 19 Aug 2008 11:57:24 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <48AB1563.4050309@internap.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <48AB1563.4050309@internap.com> Message-ID: <48AB1794.5080509@psg.com> > How does APNIC deal with this whole issue of historical addresses? i think it would be best to hear from the apnic secretariat on this. but my understanding is that one joins as an Associate Member (AU172/year) and signs an agreement which does not play games the holder's rights. but, as i said, the secretariat would better speak to this. i suspect it would be useful if someone collected the policies of all five registries. randy From randy at psg.com Tue Aug 19 14:58:37 2008 From: randy at psg.com (Randy Bush) Date: Tue, 19 Aug 2008 11:58:37 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <86skt0ltqu.fsf@seastrom.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <86skt0ltqu.fsf@seastrom.com> Message-ID: <48AB17DD.6020009@psg.com> > If you drive a car which has a reputation for being difficult to > steal, you benefit from the lower theft rate on that vehicle both in > your auto insurance rates and the likelihood that anyone will try to > hork it, even if you persist in leaving an ignition key under the > floor mat. > > I believe there is a deterrent value in making a prospective > space-thief create more of a paper trail as part of his criminal > enterprise. The benefit of that deterrent accrues to everyone > regardless of whether he has executed the legacy RSA or not, because > it raises the bar across the board. i agree. then remove the requirement to sign the egregious rsa. to drive a car, i do not assign title to the dmv randy From plzak at arin.net Tue Aug 19 14:58:35 2008 From: plzak at arin.net (Ray Plzak) Date: Tue, 19 Aug 2008 14:58:35 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <48AB1563.4050309@internap.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <48AB1563.4050309@internap.com> Message-ID: Scott, The current APNIC policy is found at http://www.apnic.net/policy/historical-resource-policies.html. It has been in effect since 19 Jan 2005. Ray > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Scott Leibrand > Sent: Tuesday, August 19, 2008 14:48 > To: Randy Bush > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Whois Integrity Policy > Proposal > > Randy, > > How does APNIC deal with this whole issue of historical addresses? > What > do you think of their policy? (I've been following sig-policy, but I'm > still not quite sure I understand what the current policy is.) > > -Scott > > Randy Bush wrote: > >> I wasn't involved in this proposal's drafting, but I believe it is > in > >> the best interests of all concerned (*even* for those who elect not > to > >> sign a legacy RSA) to require an action that is prima facie evidence > >> of fraud if it is undertaken by people who are not truly authorized > to > >> do so before updating number resources data. This is not an attempt > >> at a shake-down for $100/year legacy RSA fee, it is an attempt to > >> better protect the assignment records for number resources that are > >> currently assigned to you or your organization. > > > > as i read it, legacy holders are required to sign the egregious rsa > to > > get the benefit (the $100 does not bother me). can you say, "no > way?" > > > > randy > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Tue Aug 19 15:03:33 2008 From: owen at delong.com (Owen DeLong) Date: Tue, 19 Aug 2008 12:03:33 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <48AB17DD.6020009@psg.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <86skt0ltqu.fsf@seastrom.com> <48AB17DD.6020009@psg.com> Message-ID: <6F3EC098-E629-4567-B441-14672DDBE24F@delong.com> > i agree. then remove the requirement to sign the egregious rsa. to > drive a car, i do not assign title to the dmv The car is property. The license plate number is not. You do not own the license plate number. You own the web server or router or whatever host the IP is on. You do not own the integer assigned to the host. Integers are not property any more than license plate numbers are property. The Vehicle code clearly states that the DMV can change your license plate number if they choose to do so. ARIN doesn't have force of law like the DMV does, so, ARIN needs to do it through contracts instead. The RSA does not give ARIN title to your servers or any other property. It does, however, acknowledge that integers are not property and that what you are receiving from ARIN is a unique registration that ARIN (and by extension the other RIRs and ICANN) will not register those same numbers to someone else so long as you continue to meet the other terms of the agreement. You are in that state whether you sign the RSA or not. What, exactly, is it you find so egregious about the legacy RSA? Owen From ppml at rs.seastrom.com Tue Aug 19 15:03:46 2008 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Tue, 19 Aug 2008 15:03:46 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <48AB17DD.6020009@psg.com> (Randy Bush's message of "Tue, 19 Aug 2008 11:58:37 -0700") References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <86skt0ltqu.fsf@seastrom.com> <48AB17DD.6020009@psg.com> Message-ID: <86d4k4ltd9.fsf@seastrom.com> Randy Bush writes: >> If you drive a car which has a reputation for being difficult to >> steal, you benefit from the lower theft rate on that vehicle both in >> your auto insurance rates and the likelihood that anyone will try to >> hork it, even if you persist in leaving an ignition key under the >> floor mat. >> >> I believe there is a deterrent value in making a prospective >> space-thief create more of a paper trail as part of his criminal >> enterprise. The benefit of that deterrent accrues to everyone >> regardless of whether he has executed the legacy RSA or not, because >> it raises the bar across the board. > > i agree. then remove the requirement to sign the egregious rsa. to > drive a car, i do not assign title to the dmv Or fix the RSA... you didn't say anything about having a problem with the apnic's AU$172/year membership fee, and said in so many words that the $100 wasn't the problem... how about we just fix what you (and presumably other people as well) find odious about the RSA so that it can be an effective tool with more uptake? Policy proposals, ACSPs, and on-the-side concrete suggestions welcome. ---rob From randy at psg.com Tue Aug 19 15:05:13 2008 From: randy at psg.com (Randy Bush) Date: Tue, 19 Aug 2008 12:05:13 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <86ej4kltei.fsf@seastrom.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <86skt0ltqu.fsf@seastrom.com> <48AB17DD.6020009@psg.com> <86ej4kltei.fsf@seastrom.com> Message-ID: <48AB1969.7070109@psg.com> Robert E. Seastrom wrote: > Randy Bush writes: > >>> If you drive a car which has a reputation for being difficult to >>> steal, you benefit from the lower theft rate on that vehicle both in >>> your auto insurance rates and the likelihood that anyone will try to >>> hork it, even if you persist in leaving an ignition key under the >>> floor mat. >>> >>> I believe there is a deterrent value in making a prospective >>> space-thief create more of a paper trail as part of his criminal >>> enterprise. The benefit of that deterrent accrues to everyone >>> regardless of whether he has executed the legacy RSA or not, because >>> it raises the bar across the board. >> i agree. then remove the requirement to sign the egregious rsa. to >> drive a car, i do not assign title to the dmv > > Or fix the RSA... you didn't say anything about having a problem with > the apnic's AU$172/year membership fee, and said in so many words that > the $100 wasn't the problem... how about we just fix what you (and > presumably other people as well) find odious about the RSA so that it > can be an effective tool with more uptake? i thought that might be a path until arin put their lawyer on the stage at arin and he took an unbelievably aggressive position, including are you now or have you ever been an evil legacy space holder. i am too old to push water uphill. randy From owen at delong.com Tue Aug 19 15:11:58 2008 From: owen at delong.com (Owen DeLong) Date: Tue, 19 Aug 2008 12:11:58 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <48AB1969.7070109@psg.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <86skt0ltqu.fsf@seastrom.com> <48AB17DD.6020009@psg.com> <86ej4kltei.fsf@seastrom.com> <48AB1969.7070109@psg.com> Message-ID: <8929677D-5909-48EF-A709-95B30780F09C@delong.com> Uh, from APNIC's web site: http://www.apnic.net/policy/historical-maintain-guide.html The resource holder contacts APNIC. If the organisation is an existing APNIC member, the organisation can contact APNIC hostmasters directly by email or phone. If the organisation as an APNIC non-member account or has no previous relationship with APNIC, the resource holder should complete the form: ftp://ftp.apnic.net/apnic/docs/historical-maintain-form.txt ftp://ftp.apnic.net/apnic/docs/historical-maintain-form.txt #[ADDITIONAL INFORMATION]# 1. What changes would you like made to the resource registration? Example: Please change the tech-c and admin-c to KX99-AP. 2. This application is subject to the following conditions: - Non members of APNIC will be required to sign an APNIC non-member agreement and pay an annual account fee of AU$127. (Note: there is no limit to the number of separate historical resources that may be maintained under a single account) - All resources updated under this procedure will become subject to current APNIC resource registration policies. Do you agree to these conditions? (yes/no): Randy, In what way, exactly do you believe this leaves you with rights that the RSA takes away from you? Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Tue Aug 19 15:17:44 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 19 Aug 2008 12:17:44 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <48A9897D.50209@arin.net> Message-ID: <2AE38E3E91A74E938A2094F4C216E6A0@tedsdesk> This is one of those proposals from the "smack them with a sledgehammer" camp. I definitely understand the feeling behind it, really I do. But honestly, people, this isn't First Grade where the entire class gets punished just because one kid is throwing spitballs. I would definitely support a proposal that yanked a whois record for a legacy block that has been proven to be abandoned. For example, if ARIN gets a decently documented complaint that a block has become hijacked by spammers, and does a REASONABLE amount of effort to contact the legacy holder (at minimum, contacting the upstream AS that is advertising the block) and fails to get any kind of response that would allow them to correct the WHOIS record so that the IP holder can then be contacted by the complainant, why then fine, pull the whois until an RSA is signed. But this proposal basically assumes every legacy holder who has not signed an RSA, even if they are minding their own business and keeping their network clean, into the persona-non-grata camp. There's plenty of spammers out there who are claiming themselves to be opt-in e-mail promoters who are operating from blocks under an RSA. If you really want to reduce spam, go after those people and leave the legacy holders alone who AREN'T spamming but just happen to have not signed an RSA. Ted Mittelstaedt > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > Sent: Monday, August 18, 2008 7:39 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal > > > ARIN received the following policy proposal. In accordance > with the ARIN Internet Resource Policy Evaluation Process, > the proposal is being posted to the ARIN Public Policy > Mailing List (PPML) and being placed on ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal at > their next regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as written. If the AC accepts the > proposal, it will be posted as a formal policy proposal to > PPML and it will be presented at a Public Policy Meeting. > > 2. Not accept the proposal. If the AC does not accept > the proposal, the AC will explain their decision via the > PPML. If a proposal is not accepted, 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 proposal will be closed. > > The AC will assign shepherds in the near future. ARIN will > provide the names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this > proposal on the PPML, particularly their support or > non-support and the reasoning behind their opinion. Such > participation contributes to a thorough vetting and provides > important guidance to the AC in their deliberations. > > The ARIN Internet Resource Policy Evaluation Process can be > found at: http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > Policy Proposal Name: Whois Integrity Policy Proposal > > Author: Heather Schiller > > Proposal Version: 1 > > Submission Date: August 15, 2008 > > Policy statement: > > To ensure the integrity of information in the ARIN WHOIS > Database a resource must be under an RSA (either legacy or > traditional) in order to update the WHOIS record. ARIN will > not update historical information in the ARIN Whois Database > until the resource holder can prove the organization's right > to the resource. > > > Rationale: > > ARIN currently maintains WHOIS and in-addr.arpa delegation > records in a best-effort fashion. In many cases ARIN does > not have a formal agreement with the legacy resource holders. > Legacy records are frequently out of date and have become an > increasingly popular target for hijackers. Having up to date > contact information and a formal relationship with legacy > record holders would assist ARIN and ISP's in ensuring these > records are maintained accurately. A similar policy was > successfully adopted in the APNIC region. > (http://www.apnic.net/policy/proposals/prop-018-v001.html) > > Timetable for implementation: > > Within sixty (60) days of approval - with notification to > current POC email addresses listed on historical assignments, > or as soon as reasonable for ARIN staff. > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From vixie at isc.org Tue Aug 19 15:25:55 2008 From: vixie at isc.org (Paul Vixie) Date: Tue, 19 Aug 2008 19:25:55 +0000 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: Your message of "Tue, 19 Aug 2008 11:41:17 MST." <48AB13CD.2030903@psg.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> Message-ID: <84171.1219173955@nsa.vix.com> > as i read it, legacy holders are required to sign the egregious rsa to > get the benefit (the $100 does not bother me). can you say, "no way?" > > randy speaking for a moment as president of ISC, i signed the LRSA as soon as it was available, since ISC corporate counsel and i found it non-egregious, and we liked our rights better under the agreement than they were before. so, egregiousness may be in the mind of the beholder. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From ppml at rs.seastrom.com Tue Aug 19 15:31:58 2008 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Tue, 19 Aug 2008 15:31:58 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <48AB1969.7070109@psg.com> (Randy Bush's message of "Tue, 19 Aug 2008 12:05:13 -0700") References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <86skt0ltqu.fsf@seastrom.com> <48AB17DD.6020009@psg.com> <86ej4kltei.fsf@seastrom.com> <48AB1969.7070109@psg.com> Message-ID: <861w0kls29.fsf@seastrom.com> Randy Bush writes: > i thought that might be a path until arin put their lawyer on the stage > at arin and he took an unbelievably aggressive position, including are > you now or have you ever been an evil legacy space holder. i am too old > to push water uphill. So what you're saying is that on all the stuff we've had to respectfully agree to disagree on in past years, if I'd only had "J.D." after my name you would have rolled over and let me have my way with only a little griping on the side? Off to Amazon to order up an LSAT prep book, stat! -r From tedm at ipinc.net Tue Aug 19 15:32:35 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 19 Aug 2008 12:32:35 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <83bdbd29a0719344bbdfc3ad74251a96@mail.dessus.com> Message-ID: <0C17A994D2D14D60A5EC8117DD3D5A45@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Keith Medcalf > Sent: Tuesday, August 19, 2008 9:04 AM > To: Member Services > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Whois Integrity > Policy Proposal > > > > This is a really stupid idea and I, for one, am completely against it. > > My Legacy /24 registration data is up-to-date. If the > intention is that I not update it anymore then the proper > course of action is to note that the resources are > "delegated" outside of the ARIN system (by the US DoC or > DDNNIC for example) and then REMOVE PUBLIC VISIBILITY of all > my personal information. > > I sure the Legacy resource holders can come up with a > completely separate system to monitor those resources -- and > without needing to use EXTORTION to get it going. > I'm sure they can, too. It will undoubtedly come with it's own version of an RSA, and as it will be costly to administer, whoever will administer it will want to charge a fee for signing up with it. Thus, how exactly would this legacy resource holder system be any different than what the legacy resource holders have right now with the ARIN legacy RSA? Oooohhh, I get it! What they have right now is administered by ARIN and since we all know that ARIN is run by the devil incarnate, it MUST be BAD!!!! (ignore that man behind the curtain there who is giving any legacy holders free whois in the current arin database) Please get real, Keith. The fact that your maintaining your /24 registration is enough of an argument to shoot this ill-advised proposal down, there's no need to start dragging in loaded terms and turning it into an emotional free-for-all Ted > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > > Sent: Monday, 18 August, 2008 10:39 > > To: arin-ppml at arin.net > > Subject: [arin-ppml] Policy Proposal: Whois Integrity > Policy Proposal > > > > ARIN received the following policy proposal. In accordance > > with the ARIN > > Internet Resource Policy Evaluation Process, the proposal is being > > posted to the ARIN Public Policy Mailing List (PPML) and > > being placed on > > ARIN's website. > > > > The ARIN Advisory Council (AC) will review this proposal at > their next > > regularly scheduled meeting. The AC may decide to: > > > > 1. Accept the proposal as written. If the AC accepts the > > proposal, > > it will be posted as a formal policy proposal to PPML and it will be > > presented at a Public Policy Meeting. > > > > 2. Not accept the proposal. If the AC does not accept > > the proposal, > > the AC will explain their decision via the PPML. If a > proposal is not > > accepted, 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 proposal will be closed. > > > > The AC will assign shepherds in the near future. ARIN will > provide the > > names of the shepherds to the community via the PPML. > > > > In the meantime, the AC invites everyone to comment on this > > proposal on > > the PPML, particularly their support or non-support and the > reasoning > > behind their opinion. Such participation contributes to a thorough > > vetting and provides important guidance to the AC in their > > deliberations. > > > > The ARIN Internet Resource Policy Evaluation Process can be > found at: > > http://www.arin.net/policy/irpep.html > > > > Mailing list subscription information can be found at: > > http://www.arin.net/mailing_lists/ > > > > Regards, > > > > Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > ## * ## > > > > Policy Proposal Name: Whois Integrity Policy Proposal > > > > Author: Heather Schiller > > > > Proposal Version: 1 > > > > Submission Date: August 15, 2008 > > > > Policy statement: > > > > To ensure the integrity of information in the ARIN WHOIS Database a > > resource must be under an RSA (either legacy or > traditional) in order > > to update the WHOIS record. ARIN will not update historical > > information in > > the ARIN Whois Database until the resource holder can prove the > > organization's right to the resource. > > > > > > Rationale: > > > > ARIN currently maintains WHOIS and in-addr.arpa delegation > > records in a > > best-effort fashion. In many cases ARIN does not have a formal > > agreement with the legacy resource holders. Legacy records are > > frequently out of date and have become an increasingly > popular target > > for hijackers. Having up to date contact information and a formal > > relationship with legacy record holders would assist ARIN > and ISP's in > > ensuring these records are maintained accurately. A similar > > policy was > > successfully adopted in the APNIC region. > > (http://www.apnic.net/policy/proposals/prop-018-v001.html) > > > > Timetable for implementation: > > > > Within sixty (60) days of approval - with notification to > current POC > > email addresses listed on historical assignments, or as soon as > > reasonable for ARIN staff. > > > > > > > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed > to the ARIN > > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage > > your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From tedm at ipinc.net Tue Aug 19 15:38:46 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 19 Aug 2008 12:38:46 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <861w0kls29.fsf@seastrom.com> Message-ID: <94B54BD8F98A49CCA418B1DF10D6D851@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Robert E. Seastrom > Sent: Tuesday, August 19, 2008 12:32 PM > To: Randy Bush > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Whois Integrity > Policy Proposal > > > > Randy Bush writes: > > > i thought that might be a path until arin put their lawyer on the > > stage at arin and he took an unbelievably aggressive position, > > including are you now or have you ever been an evil legacy space > > holder. i am too old to push water uphill. > > So what you're saying is that on all the stuff we've had to > respectfully agree to disagree on in past years, if I'd only > had "J.D." after my name you would have rolled over and let > me have my way with only a little griping on the side? > > Off to Amazon to order up an LSAT prep book, stat! > Now, now, Randy DID say that he found the aggressive position unbelievable. Strange how he seems to be believing it though. Oh well. I wonder if that has something to do with being too old to push water uphill? ;-) Ted From sdean at bard.edu Tue Aug 19 15:57:21 2008 From: sdean at bard.edu (Stewart Dean) Date: Tue, 19 Aug 2008 15:57:21 -0400 Subject: [arin-ppml] Address Range transfer question Message-ID: <48AB25A1.2050700@bard.edu> Once upon a time, we acquired the use of 12 Class C address ranges from PSINet, which was went under and had some of its property acquired by Cogentco in 2002. Shortly before it did, I got a signed letter from the PSINet Manager of Shared Services which stated: "In accordance with the ARIN database, and the contract signed by your organization at the start of service with PSINet, these blocks were purchased by Bard College from PSINet 192.246.224.0 BARD-NET1 ..... through ..... 192.246.235.9 BARD-NET12" These now show up in the ARIN WHOIS like this: OrgName: Performance Systems International Inc. OrgID: PSI Address: 1015 31st St NW City: Washington StateProv: DC PostalCode: 20007 Country: US NetRange: 192.246.0.0 - 192.246.255.255 CIDR: 192.246.0.0/16 NetName: NETBLK-PSINET-C2 NetHandle: NET-192-246-0-0-1 Parent: NET-192-0-0-0-0 NetType: Direct Allocation NameServer: NS.PSI.NET NameServer: NS2.PSI.NET Comment: RegDate: 1992-10-23 Updated: 2002-08-08 RTechHandle: PSI-NISC-ARIN RTechName: IP Allocation RTechPhone: +1-877-875-4311 RTechEmail: ipalloc at cogentco.com OrgAbuseHandle: COGEN-ARIN OrgAbuseName: Cogent Abuse OrgAbusePhone: +1-877-875-4311 OrgAbuseEmail: abuse at cogentco.com OrgNOCHandle: ZC108-ARIN OrgNOCName: Cogent Communications OrgNOCPhone: +1-877-875-4311 OrgNOCEmail: noc at cogentco.com OrgTechHandle: IPALL-ARIN OrgTechName: IP Allocation OrgTechPhone: +1-877-875-4311 OrgTechEmail: ipalloc at cogentco.com OrgName: Bard College OrgID: BARDCO Address: Henderson Computer Center Address: P.O. Box 5000 City: Annandale StateProv: NY PostalCode: 12504 Country: US NetRange: 192.246.229.0 - 192.246.229.255 CIDR: 192.246.229.0/24 NetName: BARD-NET6 NetHandle: NET-192-246-229-0-1 Parent: NET-192-246-0-0-1 NetType: Reassigned Comment: RegDate: 1993-08-09 Updated: 2000-09-15 RTechHandle: SD203-ARIN RTechName: Dean, Stewart RTechPhone: +1-845-758-7475 RTechEmail: sdean at bard.edu OrgTechHandle: IPTEC15-ARIN OrgTechName: IPTech OrgTechPhone: +1-845-758-7475 OrgTechEmail: iptech at bard.edu OrgTechHandle: IPBIL1-ARIN OrgTechName: IPBill OrgTechPhone: +1-845-758-7183 OrgTechEmail: ipbill at bard.edu We are hoping we can get these ranges directly assigned to us so they appear like the two Class Cs we are directly assigned, which look like this: OrgName: Bard College OrgID: BARDCO Address: Henderson Computer Center Address: P.O. Box 5000 City: Annandale StateProv: NY PostalCode: 12504 Country: US NetRange: 192.76.239.0 - 192.76.239.255 CIDR: 192.76.239.0/24 NetName: BARD1 NetHandle: NET-192-76-239-0-1 Parent: NET-192-0-0-0-0 NetType: Direct Assignment NameServer: NS1.BARD.EDU NameServer: MERCURY.BARD.EDU NameServer: SHELL.BARD.EDU NameServer: BARD.POINTNORTHNETWORKS.COM Comment: RegDate: 1990-10-08 Updated: 2008-03-12 RAbuseHandle: IPADM392-ARIN RAbuseName: IPAdmin RAbusePhone: +1-845-758-7495 RAbuseEmail: ipadmin at bard.edu RNOCHandle: IPBIL1-ARIN RNOCName: IPBill RNOCPhone: +1-845-758-7183 RNOCEmail: ipbill at bard.edu RTechHandle: IPTEC15-ARIN RTechName: IPTech RTechPhone: +1-845-758-7475 RTechEmail: iptech at bard.edu OrgTechHandle: IPTEC15-ARIN OrgTechName: IPTech OrgTechPhone: +1-845-758-7475 OrgTechEmail: iptech at bard.edu OrgTechHandle: IPBIL1-ARIN OrgTechName: IPBill OrgTechPhone: +1-845-758-7183 OrgTechEmail: ipbill at bard.edu Can this be done? Do we have any rights? Has anyone done this? What sort of burnt offering are required? -- ==== Stewart Dean, Unix System Admin, Henderson Computer Resources Center of Bard College, Annandale-on-Hudson, New York 12504 sdean at bard.edu voice: 845-758-7475, fax: 845-758-7035 From Keith at jcc.com Tue Aug 19 16:43:29 2008 From: Keith at jcc.com (Keith W. Hare) Date: Tue, 19 Aug 2008 16:43:29 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal Message-ID: <0abb7555d9b24146027faafdf138432e48ab3060@jcc.com> > Policy statement: > > To ensure the integrity of information in the ARIN WHOIS > Database a resource must be under an RSA (either legacy or > traditional) in order to update the WHOIS record. ARIN will > not update historical information in the ARIN Whois Database > until the resource holder can prove the organization's right > to the resource. What constitutes proof of an organization's right to the resources? Is signing a legacy RSA sufficient or is additional documentation necessary? > > Rationale: > > ... > Legacy records are frequently out of date and have become an > increasingly popular target for hijackers. Either there is data behind this statement or it is hype. If there is data, it would helpful to have it. > Having up to date > contact information and a formal relationship with legacy > record holders would assist ARIN and ISP's in ensuring these > records are maintained accurately. I tend to agree that having up to date contact information is useful, but how does this proposal help more than an ongoing program to verify the legacy resource holder contact information? The way this policy is written now, I am opposed to it. There is insufficient documentation that it solves a problem that actually exists. Keith Hare JCC Consulting, Inc. From sleibrand at internap.com Tue Aug 19 16:55:31 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 19 Aug 2008 13:55:31 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <0abb7555d9b24146027faafdf138432e48ab3060@jcc.com> References: <0abb7555d9b24146027faafdf138432e48ab3060@jcc.com> Message-ID: <48AB3343.9000605@internap.com> The way I read it, the proof of right to use the resource is established (through existing procedures) at the time the LRSA is signed, and the LRSA constitutes documentation of that relationship. -Scott Keith W. Hare wrote: > >> Policy statement: >> >> To ensure the integrity of information in the ARIN WHOIS >> Database a resource must be under an RSA (either legacy or >> traditional) in order to update the WHOIS record. ARIN will >> not update historical information in the ARIN Whois Database >> until the resource holder can prove the organization's right >> to the resource. > > What constitutes proof of an organization's right to the resources? Is > signing a legacy RSA sufficient or is additional documentation > necessary? > >> Rationale: >> >> ... >> Legacy records are frequently out of date and have become an >> increasingly popular target for hijackers. > > Either there is data behind this statement or it is hype. If there is > data, it would helpful to have it. > >> Having up to date >> contact information and a formal relationship with legacy >> record holders would assist ARIN and ISP's in ensuring these >> records are maintained accurately. > > I tend to agree that having up to date contact information is useful, > but how does this proposal help more than an ongoing program to verify > the legacy resource holder contact information? > > The way this policy is written now, I am opposed to it. There is > insufficient documentation that it solves a problem that actually > exists. > > Keith Hare > JCC Consulting, Inc. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From vixie at isc.org Tue Aug 19 17:06:40 2008 From: vixie at isc.org (Paul Vixie) Date: Tue, 19 Aug 2008 21:06:40 +0000 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: Your message of "Tue, 19 Aug 2008 13:52:28 MST." <48AB328C.6010606@rancid.berkeley.edu> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> Message-ID: <1698.1219180000@nsa.vix.com> > ... I can't speak authoritatively, but I have heard that there are > institutions who are being advised not to sign the legacy RSA because of > various provisions in the contract. no doubt the people offering this hearsay advice are acting on hearsay advice. > ... I have also heard that said counsels are more concerned with some of > the provisions in the LRSA than they are regarding the uncertainty of the > status of their legacy resources. ... i'd like PPML to hear from those counsels directly, or to hear their words, literally. > ... I won't engage in an argument as to whether they are correct or not, > nor can I speak for the general counsel of my own institution. ... that makes us even, since i won't engage in speculative arguments. here are some facts as i know them from ISC's counsel. he said "do you think you'll ever want to do any of the things that this document says you mustn't do?" and i said, that basically amounts to selling the address space on e-bay, and no, that's not a right i think ISC has today, so promising not to do it costs us nothing. he then said "is there a risk that the original allocator could come back on you with more egregious implied terms if you don't have this document signed with their successor in interest?" and i answered, that's basically the USG and while i don't think they remember allocating this to us, i have no idea what'll happen when the IANA IPv4 pool runs out, and i can't rule out the possibility that people without paperwork will be screwed. so this lawyer, who works for ISC and is a real person that i know, not just some counsel that i heard somebody else describe, spoke the following words to me, that i heard with my own ears, i didn't just hear from somebody else that these words were spoken. he said "then go ahead and sign it." if anyone else has a first hand account of something a corporate counsel said when presented with the LRSA, or if some corporate counsel wants to speak in their own words, then i think it's something PPML should hear. on the other hand stories about what some counsel might've told somebody else are not advancing this debate at all. > SPEAKING FOR MYSELF ONLY: I think the LRSA (or at least the idea of it) > is the right thing to do, and I especially want to support ARIN and the > services it provides. I also think that it may not be feasible to ask > institutions that are bound by certain state and federal guidelines to > necessarily be able to get on board with the LRSA without some extensive > review and discussion. Because the policy, as currently written, does > not specifically address how institutions with legacy resources (or more > commonly, a mix of legacy and non-legacy resources) would authenticate > themselves to update whois information in the absence of a signed LRSA, I > *cannot* support this policy until such provisions are better fleshed > out. that's a fair assessment. i'm sure that heather would appreciate it if you and others offered specific text or specific changes to address that concern. > It may be possible, as part of ARIN membership, to establish an authentic > list of resources for which the ARIN member is responsible and allow > updating of whois information for those resources. It may also be > possible to create a bare-bones option to pay the $100 fee for record > maintenance for a certain list of resources without affecting the legal > status of those resources and without binding the resources to the > contract. In the current LRSA, if you stop paying the fees, your > resources are revoked. In the alternative scheme with a bare-bones > contract, if you stop paying, your whois account is locked and you cannot > make changes. This fits better with the spirit of the proposal as a > preventative measure against hijacking, rather than adding another > "stick" for legacy holders. this paragraph sounds worthy of a policy proposal in and of itself. are you game? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From michael at rancid.berkeley.edu Tue Aug 19 16:52:28 2008 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Tue, 19 Aug 2008 13:52:28 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <84171.1219173955@nsa.vix.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> Message-ID: <48AB328C.6010606@rancid.berkeley.edu> On 08/19/08 12:25, Paul Vixie wrote: >> as i read it, legacy holders are required to sign the egregious rsa to >> get the benefit (the $100 does not bother me). can you say, "no way?" >> >> randy > > speaking for a moment as president of ISC, i signed the LRSA as soon as it > was available, since ISC corporate counsel and i found it non-egregious, > and we liked our rights better under the agreement than they were before. > > so, egregiousness may be in the mind of the beholder. Unfortunately, some of those beholders appear to be general counsels of legacy holders, including major US universities and state agencies. I can't speak authoritatively, but I have heard that there are institutions who are being advised not to sign the legacy RSA because of various provisions in the contract. I have also heard that said counsels are more concerned with some of the provisions in the LRSA than they are regarding the uncertainty of the status of their legacy resources. I won't engage in an argument as to whether they are correct or not, nor can I speak for the general counsel of my own institution. I believe that there will be a more concrete and specific statement on the part of US universities coming out of EDUCAUSE or some similar organization in the future, as there is much discussion of the topic in that community. SPEAKING FOR MYSELF ONLY: I think the LRSA (or at least the idea of it) is the right thing to do, and I especially want to support ARIN and the services it provides. I also think that it may not be feasible to ask institutions that are bound by certain state and federal guidelines to necessarily be able to get on board with the LRSA without some extensive review and discussion. Because the policy, as currently written, does not specifically address how institutions with legacy resources (or more commonly, a mix of legacy and non-legacy resources) would authenticate themselves to update whois information in the absence of a signed LRSA, I *cannot* support this policy until such provisions are better fleshed out. It may be possible, as part of ARIN membership, to establish an authentic list of resources for which the ARIN member is responsible and allow updating of whois information for those resources. It may also be possible to create a bare-bones option to pay the $100 fee for record maintenance for a certain list of resources without affecting the legal status of those resources and without binding the resources to the contract. In the current LRSA, if you stop paying the fees, your resources are revoked. In the alternative scheme with a bare-bones contract, if you stop paying, your whois account is locked and you cannot make changes. This fits better with the spirit of the proposal as a preventative measure against hijacking, rather than adding another "stick" for legacy holders. michael From arin-ppml at westbrook.com Tue Aug 19 17:20:09 2008 From: arin-ppml at westbrook.com (E. Westbrook) Date: Tue, 19 Aug 2008 15:20:09 -0600 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <1698.1219180000@nsa.vix.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> Message-ID: <6905ba860808191420q7ef912fctefac281fb1fc4b7@mail.gmail.com> Full disclosure: I am a non-RSA legacy holder, and I appreciate the opportunity to comment here. For the moment, I'll constrain these remarks to the suitability of this proposal's language to its stated purpose and avoid conflating that with the pros or cons of legacy RSA conversion itself. Referring to the active paragraph of the proposal: To ensure the integrity of information in the ARIN WHOIS Database a > resource must be under an RSA (either legacy or traditional) in order to > update the WHOIS record. ARIN will not update historical information in the > ARIN Whois Database until the resource holder can prove the organization's > right to the resource. > I find in these two sentences an implicit assumption that resource holders cannot authenticate themselves sufficiently for whois updating purposes without being under an RSA. I find this assumption faulty. Since there are arguably many reliable mechanisms for authenticating a resource holder (thus satisfying the stated motivation of the proposal), it would either be ignorant or disingenuous to assert that it can only be done via an RSA. In fact, I fail to see how an RSA, in and of itself, would even satisfy the stated motivation at all. Secondly, unless I'm unaware of another affected group, I believe the only resource holders that are not already under an RSA (and therefore affected by this language) are exclusively the set of non-RSA legacy holders. Therefore, the only possible result of this language that I can currently fathom would be, in effect, the forcible conversion of non-RSA legacy holders into RSA participants, under the misguided assertion of increased whois update confidence. Consequently, I'm afraid that I must conclude this proposal is either fundamentally flawed at best, or a strong-arm sales tactic at worst. I therefore oppose this language and recommend the same to others. I invite corrections of any misunderstandings under which I might be speaking. Best regards, E. Westbrook -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Tue Aug 19 17:26:04 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 19 Aug 2008 14:26:04 -0700 Subject: [arin-ppml] Address Range transfer question In-Reply-To: <48AB25A1.2050700@bard.edu> Message-ID: To put it simply, no, you can't do that. For starters, ISP's like cogent are allocated blocks Customers like Bard College that did not meet the minimum requirements for direct allocations were assigned parts of these blocks by their ISPs Your original 192.76.239.0/24 was directly allocated to you by ARIN (or it's predicessor) before the minimum allocation requirements were put into place. It is a "legacy allocation" Your 192.246.229.0/24 was ASSIGNED to you by PSInet. It was NOT "sold" to you. PSInet had no legal authority to "sell" blocks to customers at the time, and in fact, NEVER had such authority. (what they thought they had is a different matter of course) Cogentco took over the psinet name and for whatever reason is still using it. At that time they got the blocks allocated to psinet, which included your assignment. The only way to give you the 192.246.229.0/24 would be for Cogent to give back the ENTIRE 192.246.0.0/16 to ARIN and for ARIN to split it up. That won't happen, trust me. Basically, if you want to get your own block, (I am assuming you have a total of 4 /24's somewhere) you can request a /22 from ARIN. You will need to turn back in your legacy /24's to ARIN and your assigned /24's to cogent. Yes, you will need to renumber. You get a year to run both the new and old blocks to complete your renumber. You also will need to be multihomed, and you will need to register your own AS number to be multihomed. You also will need to begin paying the yearly fees to ARIN for the portable block. If you have the SLIGHTEST interest in doing this I would advise you to do it IMMEDIATELY. Once IPv4 runs out in a few years, people like you who want small IPv4 allocations will be frozen out of the process. The reason is that any "brokers" of IPv4 that come about will be dealing with large, expensive, allocations not small-fry /22's. Ted > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Stewart Dean > Sent: Tuesday, August 19, 2008 12:57 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Address Range transfer question > > > Once upon a time, we acquired the use of 12 Class C address > ranges from PSINet, > which was went under and had some of its property acquired by > Cogentco in 2002. Shortly before it did, I got a signed > letter from the PSINet Manager of Shared > Services which stated: > "In accordance with the ARIN database, and the contract > signed by your > organization at the start of service with PSINet, these > blocks were purchased by > Bard College from PSINet > 192.246.224.0 BARD-NET1 > ..... through ..... > 192.246.235.9 BARD-NET12" > > These now show up in the ARIN WHOIS like this: > > OrgName: Performance Systems International Inc. > OrgID: PSI > Address: 1015 31st St NW > City: Washington > StateProv: DC > PostalCode: 20007 > Country: US > > NetRange: 192.246.0.0 - 192.246.255.255 > CIDR: 192.246.0.0/16 > NetName: NETBLK-PSINET-C2 > NetHandle: NET-192-246-0-0-1 > Parent: NET-192-0-0-0-0 > NetType: Direct Allocation > NameServer: NS.PSI.NET > NameServer: NS2.PSI.NET > Comment: > RegDate: 1992-10-23 > Updated: 2002-08-08 > > RTechHandle: PSI-NISC-ARIN > RTechName: IP Allocation > RTechPhone: +1-877-875-4311 > RTechEmail: ipalloc at cogentco.com > > OrgAbuseHandle: COGEN-ARIN > OrgAbuseName: Cogent Abuse > OrgAbusePhone: +1-877-875-4311 > OrgAbuseEmail: abuse at cogentco.com > > OrgNOCHandle: ZC108-ARIN > OrgNOCName: Cogent Communications > OrgNOCPhone: +1-877-875-4311 > OrgNOCEmail: noc at cogentco.com > > OrgTechHandle: IPALL-ARIN > OrgTechName: IP Allocation > OrgTechPhone: +1-877-875-4311 > OrgTechEmail: ipalloc at cogentco.com > > OrgName: Bard College > OrgID: BARDCO > Address: Henderson Computer Center > Address: P.O. Box 5000 > City: Annandale > StateProv: NY > PostalCode: 12504 > Country: US > > NetRange: 192.246.229.0 - 192.246.229.255 > CIDR: 192.246.229.0/24 > NetName: BARD-NET6 > NetHandle: NET-192-246-229-0-1 > Parent: NET-192-246-0-0-1 > NetType: Reassigned > Comment: > RegDate: 1993-08-09 > Updated: 2000-09-15 > > RTechHandle: SD203-ARIN > RTechName: Dean, Stewart > RTechPhone: +1-845-758-7475 > RTechEmail: sdean at bard.edu > > OrgTechHandle: IPTEC15-ARIN > OrgTechName: IPTech > OrgTechPhone: +1-845-758-7475 > OrgTechEmail: iptech at bard.edu > > OrgTechHandle: IPBIL1-ARIN > OrgTechName: IPBill > OrgTechPhone: +1-845-758-7183 > OrgTechEmail: ipbill at bard.edu > > We are hoping we can get these ranges directly assigned to us > so they appear > like the two Class Cs we are directly assigned, which look like this: > > OrgName: Bard College > OrgID: BARDCO > Address: Henderson Computer Center > Address: P.O. Box 5000 > City: Annandale > StateProv: NY > PostalCode: 12504 > Country: US > > NetRange: 192.76.239.0 - 192.76.239.255 > CIDR: 192.76.239.0/24 > NetName: BARD1 > NetHandle: NET-192-76-239-0-1 > Parent: NET-192-0-0-0-0 > NetType: Direct Assignment > NameServer: NS1.BARD.EDU > NameServer: MERCURY.BARD.EDU > NameServer: SHELL.BARD.EDU > NameServer: BARD.POINTNORTHNETWORKS.COM > Comment: > RegDate: 1990-10-08 > Updated: 2008-03-12 > > RAbuseHandle: IPADM392-ARIN > RAbuseName: IPAdmin > RAbusePhone: +1-845-758-7495 > RAbuseEmail: ipadmin at bard.edu > > RNOCHandle: IPBIL1-ARIN > RNOCName: IPBill > RNOCPhone: +1-845-758-7183 > RNOCEmail: ipbill at bard.edu > > RTechHandle: IPTEC15-ARIN > RTechName: IPTech > RTechPhone: +1-845-758-7475 > RTechEmail: iptech at bard.edu > > OrgTechHandle: IPTEC15-ARIN > OrgTechName: IPTech > OrgTechPhone: +1-845-758-7475 > OrgTechEmail: iptech at bard.edu > > OrgTechHandle: IPBIL1-ARIN > OrgTechName: IPBill > OrgTechPhone: +1-845-758-7183 > OrgTechEmail: ipbill at bard.edu > > Can this be done? Do we have any rights? Has anyone done > this? What sort of > burnt offering are required? > > -- > ==== > Stewart Dean, Unix System Admin, Henderson Computer Resources > Center of Bard College, Annandale-on-Hudson, New York 12504 > sdean at bard.edu voice: 845-758-7475, fax: 845-758-7035 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From tedm at ipinc.net Tue Aug 19 17:39:21 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 19 Aug 2008 14:39:21 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <1698.1219180000@nsa.vix.com> Message-ID: <73A02464ADAB46F8BC192E111BB225E2@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Paul Vixie > Sent: Tuesday, August 19, 2008 2:07 PM > To: Michael Sinatra > Cc: Randy Bush; arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Whois Integrity > Policy Proposal > > they remember allocating this to us, i have no idea what'll > happen when the IANA IPv4 pool runs out, and i can't rule out > the possibility that people without paperwork will be > screwed. I think that you can count on this happening, almost certainly. Nobody putting money down for a set of Ebay IP addresses is going to put any money down for addresses that have ANY murkiness in their ownership. Assuming of course that we are all stupid enough to ever allow buying and selling of IP addresses. Ted From mueller at syr.edu Tue Aug 19 17:49:34 2008 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 19 Aug 2008 17:49:34 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <6905ba860808191420q7ef912fctefac281fb1fc4b7@mail.gmail.com> References: <20080819172716.2FFF74501A@ptavv.es.net><867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com><84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu><1698.1219180000@nsa.vix.com> <6905ba860808191420q7ef912fctefac281fb1fc4b7@mail.gmail.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9011DCA54@SUEXCL-02.ad.syr.edu> This corresponds to my assessment of the proposal, too. I would like to hear from the proposer. Is the purpose of this proposal to: a) prevent hijacking of address blocks or b) to pressure all address block holders to sign an RSA? ________________________________ Therefore, the only possible result of this language that I can currently fathom would be, in effect, the forcible conversion of non-RSA legacy holders into RSA participants, under the misguided assertion of increased whois update confidence. Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From bicknell at ufp.org Tue Aug 19 18:17:41 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 19 Aug 2008 18:17:41 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <6905ba860808191420q7ef912fctefac281fb1fc4b7@mail.gmail.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> <6905ba860808191420q7ef912fctefac281fb1fc4b7@mail.gmail.com> Message-ID: <20080819221741.GA54400@ussenterprise.ufp.org> In a message written on Tue, Aug 19, 2008 at 03:20:09PM -0600, E. Westbrook wrote: > I find in these two sentences an implicit assumption that resource > holders cannot authenticate themselves sufficiently for whois updating > purposes without being under an RSA. I find this assumption faulty. I agree in part, and disagree in part. The exact same authentication can be done to provide a one time update to a record, or as a precurser to signing an (L)RSA and then doing the update. Thus, on the first update I must agree with the letter of your remarks. However, there are two factors that cause me to disagree with the conclusion you draw. I am not a lawyer, so I cannot be sure this is the case, but my understanding is that if there were no written contract and the requester comitted fraud ARIN would have very limited civil court recourse. The best action ARIN could get would be to convince an appropriate DA to file criminal fraud charges. With a contract ARIN has direct civil fraud remedies available. The other issue is how to keep these records up to date over time. One of the tools ARIN uses is yearly billing contact; if someone fails to pay the bills the information ARIN has to track down the owner should be at most 18 months old. There is a much greater chance of things like postal mail forwarding continuing to work, old records being available, etc. Since I believe billing requires a contract, the LRSA is the appropriate contact in this place. The alternative is for ARIN to do the complete re-authentication on every request, which could be costly, time consuming, and annoying for both parties. Lastly, it's not a primary concern but I assume the act of authenticating the resource holders however it is done today takes staff time. Since many legacy holders pay no fees they are being subsubsidized by other ARIN members. The $100 a year hopefully covers the cost of authenticating the legacy holder, providing them whois and in-addr.arpa services, this forum for discussion, and so on so the playing field is much more level than it is today. Again, I don't see how billing can be done without some sort of contract, and the LRSA is an appropriate contract. If people have issues with the LRSA I think it's totally appropriate to propose changes. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From farmer at umn.edu Tue Aug 19 18:11:01 2008 From: farmer at umn.edu (David Farmer) Date: Tue, 19 Aug 2008 17:11:01 -0500 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <8929677D-5909-48EF-A709-95B30780F09C@delong.com> References: <20080819172716.2FFF74501A@ptavv.es.net>, <48AB1969.7070109@psg.com>, <8929677D-5909-48EF-A709-95B30780F09C@delong.com> Message-ID: <48AAFEA5.5292.50799BB@farmer.umn.edu> An HTML attachment was scrubbed... URL: From bill at herrin.us Tue Aug 19 18:29:11 2008 From: bill at herrin.us (William Herrin) Date: Tue, 19 Aug 2008 18:29:11 -0400 Subject: [arin-ppml] Address Range transfer question In-Reply-To: References: <48AB25A1.2050700@bard.edu> Message-ID: <3c3e3fca0808191529k6f412c75s7fe213a73953a948@mail.gmail.com> On Tue, Aug 19, 2008 at 5:26 PM, Ted Mittelstaedt wrote: > Your 192.246.229.0/24 was ASSIGNED to you by PSInet. > It was NOT "sold" to you. PSInet had no legal authority > to "sell" blocks to customers at the time, and in > fact, NEVER had such authority. Ted, If 192.246.229.0/16 was at the time a legacy block (given the range in which it falls, I assume it was) then the legal situation is a lot more murky. No legal structure existed which would preclude PSInet from disposing of its legacy IP addresses in whatever manner it saw fit. Stewart, What is less murky is ARIN's responsibility to Bard College for 192.246.229.0/24: none whatsoever. To whatever extent PSI had the right to make such a sale, it was due to the -lack- of a contract with ARIN. The results are, thus, not binding on ARIN in any way, shape or form. And ARIN has made it very clear that they will not honor such alleged transfers. On the other hand, in theory those 12 class C's constitute a /21 and a /22 which are not necessarily invalid end-user assignments under current policy. If you can justify their use under today's ARIN policy, Bard College may be able to ask ARIN to assign the blocks as if new under the existing policies. Particularly if you can get Cogent to sign a letter to the effect that they "don't oppose" the assignment. I suggest contacting ARIN staff directly at their email or phone number to inquire about whether they're willing to assign those specific prefixes in response to an otherwise valid request for an end-user address assignment. They're pretty nice people and if the assignments would reasonably meet current policy, I suspect they'll be accommodating on the details. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From michael at rancid.berkeley.edu Tue Aug 19 18:38:32 2008 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Tue, 19 Aug 2008 15:38:32 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <1698.1219180000@nsa.vix.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> Message-ID: <48AB4B68.5060803@rancid.berkeley.edu> On 08/19/08 14:06, Paul Vixie wrote: [snip] > if anyone else has a first hand account of something a corporate counsel said > when presented with the LRSA, or if some corporate counsel wants to speak in > their own words, then i think it's something PPML should hear. > > on the other hand stories about what some counsel might've told somebody > else are not advancing this debate at all. I knew I'd regret bringing it up in this manner, and I don't want to get into a vacuous debate. I agree that statements like those have not done much to advance the debate about the LRSA, but they were intended to support my larger point: A lot of us on PPML don't have the ability to sign the LRSA, regardless of whether or not we want to do so. Moreover, even if our GCs ultimately agree to do it, the process takes a long time. I am hoping that the feedback can be made to ARIN counsel in a more more concrete manner by those (unlike me) actually qualified to do so. (Frankly, I am as interested in hearing concrete concerns as you are.) In the absence of that, I do not think it is good policy to force the LRSA or the regular RSA as the only fleshed-out means by which we can update our whois information. >> It may be possible, as part of ARIN membership, to establish an authentic >> list of resources for which the ARIN member is responsible and allow >> updating of whois information for those resources. It may also be >> possible to create a bare-bones option to pay the $100 fee for record >> maintenance for a certain list of resources without affecting the legal >> status of those resources and without binding the resources to the >> contract. In the current LRSA, if you stop paying the fees, your >> resources are revoked. In the alternative scheme with a bare-bones >> contract, if you stop paying, your whois account is locked and you cannot >> make changes. This fits better with the spirit of the proposal as a >> preventative measure against hijacking, rather than adding another >> "stick" for legacy holders. > > this paragraph sounds worthy of a policy proposal in and of itself. are > you game? Yes. I think the point of such a policy would be to define mechanisms by which resource holders could authenticate themselves to make updates for a period of time. They could be according to the following mechanisms: 1. Via an RSA 2. Via LRSA 3. As a fee-paying ARIN member in good standing, via the mechanism described above. 4. As a non-member paying a separate fee, to be determined by ARIN, for the services of: (a) authenticating the institution's claim to the resources; and (b) maintaining whois information and in-addr.arpa, and allowing updates. This could either go as a separate proposal or be merged with Heather's. Does this make sense? From farmer at umn.edu Tue Aug 19 19:03:01 2008 From: farmer at umn.edu (David Farmer) Date: Tue, 19 Aug 2008 18:03:01 -0500 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <1698.1219180000@nsa.vix.com> References: <20080819172716.2FFF74501A@ptavv.es.net>, >, <1698.1219180000@nsa.vix.com> Message-ID: <48AB0AD5.2062.5373589@farmer.umn.edu> On 19 Aug 2008 Paul Vixie wrote: > ... > > ... I have also heard that said counsels are more concerned with some of > > the provisions in the LRSA than they are regarding the uncertainty of the > > status of their legacy resources. ... > > i'd like PPML to hear from those counsels directly, or to hear their words, > literally. > > ...if anyone else has a first hand account of something a corporate counsel said > when presented with the LRSA, or if some corporate counsel wants to speak in > their own words, then i think it's something PPML should hear. Remember Michael was talking about University and State Government counsel not necessarily corporate counsel, there are many differences in these organizations. Not the least of which is that Universities and State Governments are bureaucracies that are frequently 100 to 200 years old and have special immunities in the law. The contractual risk profile for them is completely different than the typical resource holder, legacy or otherwise. However, ARIN counsel seems to understand the unique legal issues of Universities and State Agencies. He even stated in the Denver session on the LRSA, that he can work with Universities and State Agencies to find proper language for the typical legal issues Universities and State Agencies have. ======================================================= David Farmer Email: farmer at umn.edu Office of Information Technology Networking & Telecomunication Services University of Minnesota Phone: 612-626-0815 2218 University Ave SE Cell: 612-812-9952 Minneapolis, MN 55414-3029 FAX: 612-626-1818 ======================================================= From arin-ppml at westbrook.com Tue Aug 19 19:06:16 2008 From: arin-ppml at westbrook.com (Eric Westbrook) Date: Tue, 19 Aug 2008 17:06:16 -0600 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <20080819221741.GA54400@ussenterprise.ufp.org> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> <6905ba860808191420q7ef912fctefac281fb1fc4b7@mail.gmail.com> <20080819221741.GA54400@ussenterprise.ufp.org> Message-ID: <48AB51E8.70201@westbrook.com> Thanks for responding. My followup remarks are inline below. Leo Bicknell wrote: > I am not a lawyer, so I cannot be sure this is the case, but my > understanding is that if there were no written contract and the > requester comitted fraud ARIN would have very limited civil court > recourse. The best action ARIN could get would be to convince an > appropriate DA to file criminal fraud charges. With a contract > ARIN has direct civil fraud remedies available. Since this proposal purports to thwart fraudulent whois changes made by illegitimate entities (with no "right to the resource"), no such civil benefit is derived by having the legitimate holder under contract. > The other issue is how to keep these records up to date over time. > One of the tools ARIN uses is yearly billing contact; if someone > fails to pay the bills the information ARIN has to track down the > owner should be at most 18 months old. There is a much greater > chance of things like postal mail forwarding continuing to work, > old records being available, etc. Since I believe billing requires > a contract, the LRSA is the appropriate contact in this place. This point does nothing to support the suggestion that an RSA improves whois integrity. Furthermore, it fails to be a compelling reason for RSA conversion in any case, since without a contract, there is no "tracking down" at all required for billing, as there is no billing. > The alternative is for ARIN to do the complete re-authentication > on every request, which could be costly, time consuming, and annoying > for both parties. I think this is a key point of confusion -- personally, I fail to see a difference in effort (or confidence) between authenticating that someone is the resource holder of record, and that someone is the contract holder of record. > Lastly, it's not a primary concern but I assume the act of > authenticating the resource holders however it is done today takes > staff time. Since many legacy holders pay no fees they are being > subsubsidized by other ARIN members. The $100 a year hopefully > covers the cost of authenticating the legacy holder, providing them > whois and in-addr.arpa services, this forum for discussion, and so > on so the playing field is much more level than it is today. Again, I > don't see how billing can be done without some sort of contract, and the > LRSA is an appropriate contract. I'm quite sure that reason alone would be sufficient for ARIN to wish for RSAs across the board. But I'm afraid it's irrelevant to this proposal, as it certainly has nothing to do with whois integrity. Thanks again, Eric Westbrook From bill at herrin.us Tue Aug 19 19:12:31 2008 From: bill at herrin.us (William Herrin) Date: Tue, 19 Aug 2008 19:12:31 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <86d4k4ltd9.fsf@seastrom.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <86skt0ltqu.fsf@seastrom.com> <48AB17DD.6020009@psg.com> <86d4k4ltd9.fsf@seastrom.com> Message-ID: <3c3e3fca0808191612x5d84942dyb935b30e1c673aaf@mail.gmail.com> On Tue, Aug 19, 2008 at 3:03 PM, Robert E. Seastrom wrote: > Or fix the RSA... you didn't say anything about having a problem with > the apnic's AU$172/year membership fee, and said in so many words that > the $100 wasn't the problem... how about we just fix what you (and > presumably other people as well) find odious about the RSA so that it > can be an effective tool with more uptake? Robert, I'd favor this approach. What I find odious about the LRSA is that the legacy addresses revert to ARIN upon intentional termination of the contract instead of reverting to the status-quo control by the legacy registrant. The LRSA should be structured so that it serves as a strong check on ARIN's -future- actions with repspect to the legacy registrations. It doesn't make the grade. A properly motivated ARIN board would have sufficient legal wiggle room to do just about anything they wanted to the legacy registrants with no recourse on the registrants part, exactly as is the case for modern end-user registrants. Give the legacy registrant the power to terminate the contract and the possibility of adverse action by ARIN can never become a serious threat. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Tue Aug 19 19:12:47 2008 From: owen at delong.com (Owen DeLong) Date: Tue, 19 Aug 2008 16:12:47 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <48AAFEA5.5292.50799BB@farmer.umn.edu> References: <20080819172716.2FFF74501A@ptavv.es.net>, <48AB1969.7070109@psg.com>, <8929677D-5909-48EF-A709-95B30780F09C@delong.com> <48AAFEA5.5292.50799BB@farmer.umn.edu> Message-ID: <1906DF0A-68BA-4704-8032-289A2F1D1A2D@delong.com> > I can't and won't try to speak for Randy. But, read the APNIC non- > member agreement; > > http://www.apnic.net/docs/corpdocs/non-membership-agreement.html > > There seems to be a lot less egregious legal language in it. I'm > not sure that there is a significant difference in actual rights, > but it sure seems nicer. I'm not sure if this is an artifact of the > difference in US and Australian legal systems, difference in lawyers > or what. But reading this agreement, I get a completely different > feeling than reading the ARIN LRSA. > Duly noted. > Also note, it is mute on the Property issues, while I think this is > a bogus issue personally, others do not think it is a bogus issue. > (A side-note on why I think this is a bogus issue; I've spent much > of the the last couple years working on getting Fiber IRUs for my > institution, a very expensive long-term right-to-use. But not > actually a property-right at least by most normal definitions. So, > I'm comfortable with the idea of a right-to-use rather than a normal > property right, others may not be as comfortable with the concept) > One comment I will make, the LRSA is very clear and strong that > there is not a property-right, but it does not seem equally clear > and strong in defining what the actual right-to-use entails. > Fiber IRUs are the right to use a tangible physical asset. As I understand it (and this is my own understanding, not something I have clarified with ARIN counsel, so, I could be wrong)... In the case of ARIN (or any other RIR) registration services, that's not what you are getting. You are getting a promise from the RIR that they (and the other cooperating registries) will not give the same number to somebody else so long as you live up to your side of the RSA. That's it. No rights in the numbers are conveyed. You can put any integer you want into any system you want at any time. Neither ARIN, nor anyone else has any ability to restrict where you use the number 2, 5320, 123.45.67.8, or any other integer of any length, nor do they have any right to restrict in any way the number of places you use any given integer. However, the internet depends on integers used for the purpose of numbering globally reachable hosts being unique, so, ARIN and the other RIRs provide a service of issuing numbers to cooperating parties in a way that assures no other cooperating party is given the same number. For the most part, ISPs choose to route a given number only to the party that received that number from the appropriate RIR. All of that, however, is the result of cooperation and is not a contractual or legal right to use anything. I hope this clarifies the extent and depth to which numbers are not and cannot be property and the exact nature of what you are or are not getting with an RSA. The RSA is an agreement for REGISTRATION SERVICES and is not a right to use. > I think the LRSA is fundamentally the right idea. I'm not sure > about the T&Cs, but I'm not going to do contract negotiation in a > public forum, and especially not this forum as it is a policy > forum. I am trying to work with ARIN counsel on a few issues, that > is where contract negotiation should happen. > Sure, although, appropriate feedback on policy-related issues in that contract would be appreciated. > Maybe one suggestion for the proposal, allow an alternate process to > update Legacy records, that doesn't actually require the LRSA or > RSA. It should be procedurally egregious, but yet plausible > measures to prevent hijacking, like have to do a full vetting of > proof of ownership each time and maybe a 30 day public notice or > something. In other words, in the long run it is much easier to do > the LRSA or RSA, but not an absolute requirement. > Well... Personally, I'd favor an alternative method for updates that provided a non-egregious plausible process for authentication and update. It should be just thorough enough to provide adequate safeguard against hijacking and no more egregious than that. I don't believe that punitive approaches (deliberately making it harder to not sign the (L)RSA are appropriate. > I'm not sure it would be good for the community for Legacy Resource > Holders to not be able to legitimately update their records some > how, if they can find their way to signing the LRSA. It might > prevent hijacking, but it does nothing to promote accuracy in the > database. > I think it would be very bad for the community if that became the case. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Tue Aug 19 19:16:04 2008 From: bill at herrin.us (William Herrin) Date: Tue, 19 Aug 2008 19:16:04 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <0C17A994D2D14D60A5EC8117DD3D5A45@tedsdesk> References: <83bdbd29a0719344bbdfc3ad74251a96@mail.dessus.com> <0C17A994D2D14D60A5EC8117DD3D5A45@tedsdesk> Message-ID: <3c3e3fca0808191616p64d61448r84f390a9b0963a30@mail.gmail.com> On Tue, Aug 19, 2008 at 3:32 PM, Ted Mittelstaedt wrote: >> I sure the Legacy resource holders can come up with a >> completely separate system to monitor those resources -- and >> without needing to use EXTORTION to get it going. > > I'm sure they can, too. It will undoubtedly come with it's own > version of an RSA, and as it will be costly to administer, whoever > will administer it will want to charge a fee for signing up with > it. Thus, how exactly would this legacy resource holder system be > any different than what the legacy resource holders have right now > with the ARIN legacy RSA? It would be terminable in the event of a dispute. The practical effect of the LRSA language is that its not terminable by the registrant. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From randy at psg.com Tue Aug 19 19:16:05 2008 From: randy at psg.com (Randy Bush) Date: Tue, 19 Aug 2008 16:16:05 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <48AB51E8.70201@westbrook.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> <6905ba860808191420q7ef912fctefac281fb1fc4b7@mail.gmail.com> <20080819221741.GA54400@ussenterprise.ufp.org> <48AB51E8.70201@westbrook.com> Message-ID: <48AB5435.2070908@psg.com> you seem to get the message and are articulating it well. though it is not a pretty one. when my son was five or so, he moved some cows from one pasture to another. he came back and reported "you know, it is easier to move them from in front with a can of grain than from behind with a stick." i know many folk far older who have not learned that lesson. arin would seem not to have. power, force, coercion, extortion, ... not very good motivators. gedanken experiment: if we wanted to have a carrot-rich stick-free relationship with legacy holders and whois registrants, what might we do (other than shoot testosteronic lawyers:)? randy From michael at rancid.berkeley.edu Tue Aug 19 19:33:39 2008 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Tue, 19 Aug 2008 16:33:39 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <48AB4B68.5060803@rancid.berkeley.edu> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> <48AB4B68.5060803@rancid.berkeley.edu> Message-ID: <48AB5853.9030200@rancid.berkeley.edu> On 08/19/08 15:38, Michael Sinatra wrote: > 3. As a fee-paying ARIN member in good standing, via the mechanism > described above. > 4. As a non-member paying a separate fee, to be determined by ARIN, for > the services of: (a) authenticating the institution's claim to the > resources; and (b) maintaining whois information and in-addr.arpa, and > allowing updates. > > This could either go as a separate proposal or be merged with Heather's. > Does this make sense? I have submitted to ARIN a separate proposal that I believe does not step on Heather's, and it defines an alternative mechanism for legacy holder authentication. We could decide to combine the policies or keep them separate (or trash one or both of them). Keep your email client tuned to PPML! michael From JOHN at egh.com Tue Aug 19 19:39:08 2008 From: JOHN at egh.com (John Santos) Date: Tue, 19 Aug 2008 19:39:08 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <1906DF0A-68BA-4704-8032-289A2F1D1A2D@delong.com> Message-ID: <1080819193213.27224A-100000@Ives.egh.com> Exclusivity *IS* a right. Saying that ARIN promises it won't assign the same number to someone else and then saying that no rights are provided is nonsense. If no right is provided, then ARIN could break its promise any time it wanted to. (For some reason, the message I'm trying to reply to didn't quote properly. Probably something to do with bogus formatting. If you can't figure out what I'm replying to, then try using an RFC-compliant mail client in the future.) -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From tvest at pch.net Tue Aug 19 19:45:55 2008 From: tvest at pch.net (Tom Vest) Date: Tue, 19 Aug 2008 19:45:55 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <48AB5435.2070908@psg.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> <6905ba860808191420q7ef912fctefac281fb1fc4b7@mail.gmail.com> <20080819221741.GA54400@ussenterprise.ufp.org> <48AB51E8.70201@westbrook.com> <48AB5435.2070908@psg.com> Message-ID: Hi Randy, What carrot(s) would you suggest, that would not have the effect of making "faithful" (i.e., complete, accurate, and timely) participation in whois purely optional for all time thereafter? What carrots could the RIRs offer to encourage "purely optional" participation without the cost of such offerings effectively representing a big stick applied to other community members? Honestly curious about this, as I am having trouble imagining the kind of simple, obvious solutions that you and others seem to suggest are within our grasp... Thanks, TV On Aug 19, 2008, at 7:16 PM, Randy Bush wrote: > you seem to get the message and are articulating it well. though it > is > not a pretty one. > > when my son was five or so, he moved some cows from one pasture to > another. he came back and reported "you know, it is easier to move > them > from in front with a can of grain than from behind with a stick." > > i know many folk far older who have not learned that lesson. arin > would > seem not to have. power, force, coercion, extortion, ... not very > good > motivators. > > gedanken experiment: if we wanted to have a carrot-rich stick-free > relationship with legacy holders and whois registrants, what might > we do > (other than shoot testosteronic lawyers:)? > > randy > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From randy at psg.com Tue Aug 19 19:49:50 2008 From: randy at psg.com (Randy Bush) Date: Tue, 19 Aug 2008 16:49:50 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> <6905ba860808191420q7ef912fctefac281fb1fc4b7@mail.gmail.com> <20080819221741.GA54400@ussenterprise.ufp.org> <48AB51E8.70201@westbrook.com> <48AB5435.2070908@psg.com> Message-ID: <48AB5C1E.7080802@psg.com> > What carrot(s) would you suggest, that would not have the effect of > making "faithful" (i.e., complete, accurate, and timely) participation > in whois purely optional for all time thereafter? i am hoping folk will be more comfortable with approaches reached as a community as opposed to pontification by old s. but one hint: authentication can be handled technically randy From vixie at isc.org Tue Aug 19 20:06:21 2008 From: vixie at isc.org (Paul Vixie) Date: Wed, 20 Aug 2008 00:06:21 +0000 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: Your message of "Tue, 19 Aug 2008 15:38:32 MST." <48AB4B68.5060803@rancid.berkeley.edu> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> <48AB4B68.5060803@rancid.berkeley.edu> Message-ID: <28787.1219190781@nsa.vix.com> > > this paragraph sounds worthy of a policy proposal in and of itself. > > are you game? > > Yes. I think the point of such a policy would be to define mechanisms by > which resource holders could authenticate themselves to make updates for > a period of time. They could be according to the following mechanisms: > > 1. Via an RSA > 2. Via LRSA > 3. As a fee-paying ARIN member in good standing, via the mechanism > described above. > 4. As a non-member paying a separate fee, to be determined by ARIN, for the > services of: (a) authenticating the institution's claim to the resources; > and (b) maintaining whois information and in-addr.arpa, and allowing > updates. > > This could either go as a separate proposal or be merged with > Heather's. Does this make sense? without taking a position on the merits of the proposal or of those alternatives, i think it makes sense as a separate proposal for now. (competing/overlapping proposals can be trivially merged if desired.) -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From jay at impulse.net Tue Aug 19 20:23:21 2008 From: jay at impulse.net (Jay Hennigan) Date: Tue, 19 Aug 2008 17:23:21 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <48AB5435.2070908@psg.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> <6905ba860808191420q7ef912fctefac281fb1fc4b7@mail.gmail.com> <20080819221741.GA54400@ussenterprise.ufp.org> <48AB51E8.70201@westbrook.com> <48AB5435.2070908@psg.com> Message-ID: <48AB63F9.6030001@impulse.net> Randy Bush wrote: > gedanken experiment: if we wanted to have a carrot-rich stick-free > relationship with legacy holders and whois registrants, what might we do > (other than shoot testosteronic lawyers:)? Offer the legacy holders the opportunity to shoot said lawyers. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From vixie at isc.org Tue Aug 19 20:42:54 2008 From: vixie at isc.org (Paul Vixie) Date: Wed, 20 Aug 2008 00:42:54 +0000 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: Your message of "Tue, 19 Aug 2008 19:12:31 -0400." <3c3e3fca0808191612x5d84942dyb935b30e1c673aaf@mail.gmail.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <86skt0ltqu.fsf@seastrom.com> <48AB17DD.6020009@psg.com> <86d4k4ltd9.fsf@seastrom.com> <3c3e3fca0808191612x5d84942dyb935b30e1c673aaf@mail.gmail.com> Message-ID: <34567.1219192974@nsa.vix.com> > From: "William Herrin" > ... > What I find odious about the LRSA is that the legacy addresses revert > to ARIN upon intentional termination of the contract instead of > reverting to the status-quo control by the legacy registrant. i think that differential rights for legacy holders presumes two things that most people would argue just as strongly about, and as such, the presumption isn't a no-brainer. thing 1: that legacy addresses are property and that a legacy holder owns them in perpetuity and has rights of use and/or disposal/sale that supercede the interests of the larger community. thing 2: that non-legacy holder are disadvantaged since they received fewer rights with their allocations than legacy holders did. i do personally hold either the "thing 1" or the "thing 2" view, and so to me, uniqueness against competing allocations or merely against competing utilization (perhaps by stronger or larger parties elsewhere in the world) is a community-level right -- we all have it because the community agrees that we all have it. i don't distinguish in my mind between the rights i have to legacy space vs. non-legacy space, because all of those rights are whatever the community agrees to protect, and while various individuals have begged differential relief in this area, i've seen no consensus for it. but to close the loop on what i mean by "the community", let's continue: > The LRSA should be structured so that it serves as a strong check on > ARIN's -future- actions with repspect to the legacy registrations. It > doesn't make the grade. A properly motivated ARIN board would have > sufficient legal wiggle room to do just about anything they wanted to the > legacy registrants with no recourse on the registrants part, exactly as > is the case for modern end-user registrants. Give the legacy registrant > the power to terminate the contract and the possibility of adverse action > by ARIN can never become a serious threat. let me start by arguing the opposite. if you think that address holders are a necessary check+balance on ARIN misbehaviour, then you should be arguing that ALL address holders must have this role, legacy and non-legacy alike. let me finish by saying that ARIN's policies are what the community makes. there's no way for the board or AC or staff, or any national government, to ram policies down the community's throat, or withhold approval or execution of policies that the community has created. if LRSA is wrong, then submit a policy process to fix it. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From bicknell at ufp.org Tue Aug 19 20:59:53 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 19 Aug 2008 20:59:53 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <48AB51E8.70201@westbrook.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> <6905ba860808191420q7ef912fctefac281fb1fc4b7@mail.gmail.com> <20080819221741.GA54400@ussenterprise.ufp.org> <48AB51E8.70201@westbrook.com> Message-ID: <20080820005953.GA65851@ussenterprise.ufp.org> In a message written on Tue, Aug 19, 2008 at 05:06:16PM -0600, Eric Westbrook wrote: > > The other issue is how to keep these records up to date over time. > > One of the tools ARIN uses is yearly billing contact; if someone > > fails to pay the bills the information ARIN has to track down the > > owner should be at most 18 months old. There is a much greater > > chance of things like postal mail forwarding continuing to work, > > old records being available, etc. Since I believe billing requires > > a contract, the LRSA is the appropriate contact in this place. > > This point does nothing to support the suggestion that an RSA improves > whois integrity. Furthermore, it fails to be a compelling reason for > RSA conversion in any case, since without a contract, there is no > "tracking down" at all required for billing, as there is no billing. I disagree. When people or businesses relocate there is often a period of around a year of mail forwarding. If ARIN sends a paper bill and it is received with a forward sticker on it that serves as a reminder to the resource holder to privide ARIN updated address information for BOTH billing and whois. If there is no billing, there is no reminder. I am a firm believer that to have a billing relationship there must be a contract. I do not necessarily believe that contract must be the legacy RSA; ARIN could develop another type of contract if the community felt that was necessary. However the legacy RSA does fill the role of a contract, and is available right now. I would be happy to discuss changes to the legacy RSA or an entirely different contract, but having no contract is unacceptable to me. > > The alternative is for ARIN to do the complete re-authentication > > on every request, which could be costly, time consuming, and annoying > > for both parties. > > I think this is a key point of confusion -- personally, I fail to see a > difference in effort (or confidence) between authenticating that someone > is the resource holder of record, and that someone is the contract > holder of record. There is no difference in making that determination /one time/. Consider two scenarios: 1) Bob works for XYZ corp and processes an update to a legacy record. Bob provides proof he works for xyz, xyz's letter where they received the space, and a copy of his passport to authenticate. 2) Bob gets hit by a bus. 3) Ted goes to update XYZ corps information, and must toally reauthenticate. Ted supplies all the same paperwork again, which is reviewed again by ARIN staff. -vrs- A) Bob works for XYZ corp and processes an update to a legacy record. Bob provides proof he works for xyz, xyz's letter where they received the space, and a copy of his passport to authenticate. Bob requests a digital certificate from ARIN for the companies role account. (http://www.arin.net/CA/) Bob places it in a lockbox at work. B) Bob gets hit by a bus. C) Ted gets the certificate from the lock box, sends an update to ARIN, which is authenticated by the certificate automatically by machine with no human intervention. Step 3 is a manual, staff intensive step (that's likely to also be intensive for Ted). Step C is a fully machine automated process. For update #1 you are totally correct, there is no difference, for updates 2..N, there is possibly a large difference. The goal here is to make it easier for BOTH sides to update information, with a goal to keep the information more up to date. It is stale information that attracks the hijackers and allows them to be most successful. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From tvest at pch.net Tue Aug 19 21:29:47 2008 From: tvest at pch.net (Tom Vest) Date: Tue, 19 Aug 2008 21:29:47 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <48AB5C1E.7080802@psg.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> <6905ba860808191420q7ef912fctefac281fb1fc4b7@mail.gmail.com> <20080819221741.GA54400@ussenterprise.ufp.org> <48AB51E8.70201@westbrook.com> <48AB5435.2070908@psg.com> <48AB5C1E.7080802@psg.com> Message-ID: <635046C2-85BA-471C-84DA-02D8C0E4D12F@pch.net> On Aug 19, 2008, at 7:49 PM, Randy Bush wrote: >> What carrot(s) would you suggest, that would not have the effect of >> making "faithful" (i.e., complete, accurate, and timely) >> participation >> in whois purely optional for all time thereafter? > > i am hoping folk will be more comfortable with approaches reached as a > community as opposed to pontification by old s. > > but one hint: authentication can be handled technically > > randy Okay I think I get that; hierarchical resource certification would make "faithful" (i.e., complete, accurate, and timely) participation in whois less onerous for resource holders, and less costly for all parties. But in order for that to translate into durably useful, *public* whois, wouldn't that entail that the certification mechanism be irreversibly anchored at some level where the public access part of the equation is assured (i.e., so that there is no chance of it devolving into a bilateral/reciprocal trust model at some later date)? I was under the impression that the resource certification implementation currently under development is agnostic on just this point... but I'm no expert & would be happy to be corrected. Thanks, TV From grpjl at iastate.edu Tue Aug 19 21:22:26 2008 From: grpjl at iastate.edu (Paul Lustgraaf) Date: Tue, 19 Aug 2008 20:22:26 CDT Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal Message-ID: <200808200122.UAA27703@rv.its.iastate.edu> I second these sentiments and also oppose the proposal. Paul Lustgraaf > I find in these two sentences an implicit assumption that resource holders > cannot authenticate themselves sufficiently for whois updating purposes > without being under an RSA. I find this assumption faulty. Since there are > arguably many reliable mechanisms for authenticating a resource holder (thus > satisfying the stated motivation of the proposal), it would either be > ignorant or disingenuous to assert that it can only be done via an RSA. In > fact, I fail to see how an RSA, in and of itself, would even satisfy the > stated motivation at all. > > Secondly, unless I'm unaware of another affected group, I believe the only > resource holders that are not already under an RSA (and therefore affected > by this language) are exclusively the set of non-RSA legacy holders. > > Therefore, the only possible result of this language that I can currently > fathom would be, in effect, the forcible conversion of non-RSA legacy > holders into RSA participants, under the misguided assertion of increased > whois update confidence. Consequently, I'm afraid that I must conclude this > proposal is either fundamentally flawed at best, or a strong-arm sales > tactic at worst. > > I therefore oppose this language and recommend the same to others. > > I invite corrections of any misunderstandings under which I might be > speaking. > > Best regards, > E. Westbrook Paul Lustgraaf "Change is inevitable. Progress is not." Network Engineer Iowa State University Information Technology Services grpjl at iastate.edu Ames, IA 50011 515-294-0324 From kloch at kl.net Tue Aug 19 23:13:43 2008 From: kloch at kl.net (Kevin Loch) Date: Tue, 19 Aug 2008 23:13:43 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <48AB5435.2070908@psg.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> <6905ba860808191420q7ef912fctefac281fb1fc4b7@mail.gmail.com> <20080819221741.GA54400@ussenterprise.ufp.org> <48AB51E8.70201@westbrook.com> <48AB5435.2070908@psg.com> Message-ID: <48AB8BE7.1010100@kl.net> Randy Bush wrote: > > gedanken experiment: if we wanted to have a carrot-rich stick-free > relationship with legacy holders and whois registrants, what might we do > (other than shoot testosteronic lawyers:)? Allow them to transfer/sell their legacy blocks the same way they can sell their legacy domain names (no strings attached). Allow them to subdivide the blocks up to whatever the current ARIN minimum allocation size is (currently /20). Exclude utilization as a reason the delegation could be revoked. I would like to see a provision to revoke delegations based on intentionally false (and refusal to correct) whois data. Do this for legacy blocks and not (yet) ARIN issued blocks and you should quickly find out who de facto controls which legacy blocks. You would probably need an outside dispute resolution process for disputes over who really has the rights to some of those blocks... - Kevin From tedm at ipinc.net Wed Aug 20 00:34:14 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 19 Aug 2008 21:34:14 -0700 Subject: [arin-ppml] Address Range transfer question In-Reply-To: <3c3e3fca0808191529k6f412c75s7fe213a73953a948@mail.gmail.com> Message-ID: > -----Original Message----- > From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf > Of William Herrin > Sent: Tuesday, August 19, 2008 3:29 PM > To: Ted Mittelstaedt > Cc: Stewart Dean; arin-ppml at arin.net > Subject: Re: [arin-ppml] Address Range transfer question > > > On Tue, Aug 19, 2008 at 5:26 PM, Ted Mittelstaedt > wrote: > > Your 192.246.229.0/24 was ASSIGNED to you by PSInet. > > It was NOT "sold" to you. PSInet had no legal authority > > to "sell" blocks to customers at the time, and in > > fact, NEVER had such authority. > > Ted, > > If 192.246.229.0/16 was at the time a legacy block (given the > range in which it falls, I assume it was) then the legal > situation is a lot more murky. That is true. > No legal structure existed > which would preclude PSInet from disposing of its legacy IP > addresses in whatever manner it saw fit. > Nothing precluded PSInet from SAYING anything that they wanted. Wether a letter that they wrote to Bard College would be accepted by the rest of the community, -particularly- by the people running Whois at the time, is a different matter entirely. I do not believe that it would have been. And, quite obviously, NEITHER did ARIN since it proceeded to allocate the entire block that contained the /24's that PSInet supposedly disposed of to Bard, to cogentco. Of course, all of this is interesting historical speculation, nothing more. You may disagree but I believe that the important thing is for Stewart to understand that letters that were written by allocatees pre-RIR have practically NO legal weight today. We are very likely going to see more of this, of people trotting out 15 year old documents and such that claim they have a stake on a piece of the IPv4 landscape, in the future. I don't think it is wise to encourage it, as it distracts from the more important discussion of how to best proceed forward. Stewart could spend the next year e-mailing and writing various people attempting to try to stake claim on these numbers - and for what? To avoid a renumber, a very simple thing. If he simply does as I recommended and proceeds forward with abandoning his existing holdings and getting a fresh block, he will be done before he knows it. And not only that but he will have a contiguous block and can make some logical routing arraingements, such as advertising aggregated routes inside his network. > > On the other hand, in theory those 12 class C's constitute a > /21 and a /22 which are not necessarily invalid end-user > assignments under current policy. If you can justify their > use under today's ARIN policy, Bard College may be able to > ask ARIN to assign the blocks as if new under the existing > policies. Particularly if you can get Cogent to sign a letter > to the effect that they "don't oppose" the assignment. > William, those 12 "class Cs" are part of 192.246.0.0 - 192.246.255.255 which constitutes a total of 256 "class Cs" according to Stewart. As Cogent has undoubtedly requested and obtained additional IPv4 blocks from ARIN since that assignment, those PSInet IPv4 numbers have been included in their utilization mathmatics. In short, they had to justify utilization of all the IP numbers that were part of the block that were NOT assigned to Bard to get more of them. I would be amazed if Cogent was given further assignments from ARIN while allowing a total of 244 /24's to sit unused. I would assume those subnets are assigned to other customers. Why would Cogent be willing to break up a nice, clean /16 that they can advertise with a single routing entry, into multiple advertisements, just so they can slide these 12 subnets out of their allocation? Ted From bill at herrin.us Wed Aug 20 00:47:53 2008 From: bill at herrin.us (William Herrin) Date: Wed, 20 Aug 2008 00:47:53 -0400 Subject: [arin-ppml] Address Range transfer question In-Reply-To: References: <3c3e3fca0808191529k6f412c75s7fe213a73953a948@mail.gmail.com> Message-ID: <3c3e3fca0808192147v6b12c980x70725c8440ac2923@mail.gmail.com> On Wed, Aug 20, 2008 at 12:34 AM, Ted Mittelstaedt wrote: > Why would Cogent be willing to break up a nice, clean /16 > that they can advertise with a single routing entry, into > multiple advertisements, just so they can slide these 12 > subnets out of their allocation? Ted, Perhaps their original documentation justifying the transfer from PSI was faulty, since there appear to be a set of legal documents indicating a different disposition for at least some of the addresses. Perhaps Cogent doesn't want to have to dig up the original opposing documents. Perhaps there weren't any; the PSI breakup was pretty fuzzy. Perhaps Cogent doesn't want to fall afoul of what tends to happen to large corporations in legislatures when colleges get pissed off. Perhaps Cogent's best course of action is to ink a deal that lets them keep announcing the /16 and keep the (large) customer in exchange for indicating approval of the "correction" to the address records. Perhaps I'm dead wrong. But it is at least an avenue that Stewart can explore, one that might yield his desired result. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tedm at ipinc.net Wed Aug 20 01:33:52 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 19 Aug 2008 22:33:52 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <48AB5435.2070908@psg.com> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Randy Bush > Sent: Tuesday, August 19, 2008 4:16 PM > To: Eric Westbrook > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Whois Integrity > Policy Proposal > > > you seem to get the message and are articulating it well. > though it is not a pretty one. > > when my son was five or so, he moved some cows from one > pasture to another. he came back and reported "you know, it > is easier to move them from in front with a can of grain than > from behind with a stick." > What do you do about the few cows who are just ornery, and aren't going to move with the grain, just to honk you off? Ted From tedm at ipinc.net Wed Aug 20 01:40:52 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 19 Aug 2008 22:40:52 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <3c3e3fca0808191616p64d61448r84f390a9b0963a30@mail.gmail.com> Message-ID: <2206BBF878134726886456368BCA2A87@tedsdesk> > -----Original Message----- > From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf > Of William Herrin > Sent: Tuesday, August 19, 2008 4:16 PM > To: Ted Mittelstaedt > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Whois Integrity > Policy Proposal > > > On Tue, Aug 19, 2008 at 3:32 PM, Ted Mittelstaedt > wrote: > >> I sure the Legacy resource holders can come up with a completely > >> separate system to monitor those resources -- and without > needing to > >> use EXTORTION to get it going. > > > > I'm sure they can, too. It will undoubtedly come with it's own > > version of an RSA, and as it will be costly to administer, whoever > > will administer it will want to charge a fee for signing up > with it. > > Thus, how exactly would this legacy resource holder system be any > > different than what the legacy resource holders have right now with > > the ARIN legacy RSA? > > It would be terminable in the event of a dispute. The > practical effect of the LRSA language is that its not > terminable by the registrant. So then, is a legacy holder wants to opt out of it due to disputing it, they can. In which case the legacy holder system admin would pull their names out from their system and it seems your right back where you started with the same problem. How is that better? What is the point of signing a contract that has no teeth? Ted From Lee.Howard at stanleyassociates.com Wed Aug 20 08:18:17 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 20 Aug 2008 08:18:17 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <48AB8BE7.1010100@kl.net> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40AFE6AD1@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Loch > Sent: Tuesday, August 19, 2008 11:14 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Whois Integrity > Policy Proposal > > Randy Bush wrote: > > > > gedanken experiment: if we wanted to have a carrot-rich stick-free > > relationship with legacy holders and whois registrants, > what might we > > do (other than shoot testosteronic lawyers:)? > > Allow them to transfer/sell their legacy blocks the same way > they can sell their legacy domain names (no strings > attached). Allow them to subdivide the blocks up to whatever > the current ARIN minimum allocation size is (currently /20). Are you advocating or gedankening? > Exclude utilization as a reason the delegation could be > revoked. See section 10(b) of the LRSA: (b) ARIN will take no action to reduce the services provided for Included Number Resources that are not currently being utilized by the Legacy Applicant. Also, the LRSA says that if there's a conflict between ARIN policies and the LRSA, the LRSA wins. Absent an LRSA, the community could change the rules for legacy holders. Lee From Lee.Howard at stanleyassociates.com Wed Aug 20 08:26:10 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 20 Aug 2008 08:26:10 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <3c3e3fca0808191612x5d84942dyb935b30e1c673aaf@mail.gmail.com> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40AFE6AED@CL-S-EX-1.stanleyassociates.com> > The LRSA should be structured so that it serves as a strong > check on ARIN's -future- actions with repspect to the legacy > registrations. It doesn't make the grade. A properly > motivated ARIN board would have sufficient legal wiggle room > to do just about anything they wanted to the legacy > registrants with no recourse on the registrants part, exactly The LRSA says ARIN won't take your legacy address space based on a lack of utilization. Section 10b. It also says that in any conflicts between ARIN policies and the LRSA, the LRSA wins. (b) ARIN will take no action to reduce the services provided for Included Number Resources that are not currently being utilized by the Legacy Applicant. Lee > as is the case for modern end-user registrants. Give the > legacy registrant the power to terminate the contract and the > possibility of adverse action by ARIN can never become a > serious threat. > > Regards, > Bill Herrin > > > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From kkargel at polartel.com Wed Aug 20 09:30:22 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 20 Aug 2008 08:30:22 -0500 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: References: <48AB5435.2070908@psg.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10A2D@mail> And what are you going to do about the greedy cow that runs forward, stomps the kid to mush and takes the whole bucket of grain for herself? Kevin -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt Sent: Wednesday, August 20, 2008 12:34 AM To: 'Randy Bush'; 'Eric Westbrook' Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Randy Bush > Sent: Tuesday, August 19, 2008 4:16 PM > To: Eric Westbrook > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Whois Integrity Policy > Proposal > > > you seem to get the message and are articulating it well. > though it is not a pretty one. > > when my son was five or so, he moved some cows from one pasture to > another. he came back and reported "you know, it is easier to move > them from in front with a can of grain than from behind with a stick." > What do you do about the few cows who are just ornery, and aren't going to move with the grain, just to honk you off? Ted _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3107 bytes Desc: not available URL: From info at arin.net Wed Aug 20 10:47:27 2008 From: info at arin.net (Member Services) Date: Wed, 20 Aug 2008 10:47:27 -0400 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives Message-ID: <48AC2E7F.1070806@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At their following meeting the AC will accept or not accept the proposal. 3. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision via the PPML. If a proposal is not accepted, 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 proposal will be closed. The AC will assign shepherds in the near future. ARIN will provide the names of the shepherds to the community via the PPML. In the meantime, the AC invites everyone to comment on this proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Whois Authentication Alternatives Author: Michael Sinatra Proposal Version: 1 Submission Date: August 19, 2008 Proposal type: new Policy term: permanent Policy statement: In addition to current processes ARIN has to authenticate holders of historical resources, ARIN will also allow holders of resources to authenticate themselves for the purposes of updating WHOIS information for a given resource according to the following mechanism: A holder of resources not governed by any type of RSA (i.e. legacy or regular) may work with ARIN staff to establish an inventory of those resources legitimately maintained by the holder. ARIN staff will work to authenticate each resource claimed by the holder. Upon successful completion of the authentication process, the holder will be entitled to make updates to whois information for those resources for a period of one year, with an option for renewal. For ARIN non-members, ARIN will charge a maintenance fee to recover costs associated with the authentication process and whois maintenance. For ARIN members, the fee will be waived or discounted at ARIN's discretion. Renewal is automatic pending the payment of maintenance or membership fees. Failure to pay fees will result in the whois information being "locked," and updates to the information will not be possible. Successful authentication and the payment of membership and/or maintenance fees does not confer any rights upon the holder such as those that would be granted by an RSA (legacy or regular). Rationale: ARIN needs to protect whois data from hijacking, but the current mechanisms for authenticating holders (especially legacy holders) are limited. The current method, signing a Legacy RSA, may not be a viable option in the near term for such legacy holders for a variety of legal reasons. In the interest of: (a) protecting whois data; (b) keeping whois up-to-date for the Internet community; and (c) recovering costs associated with WHOIS and in-addr.arpa delegation, an alternative authentication mechanism needs to be established for holders of historical resources. This proposal does not intend to discount either type of RSA, and it attempts to specifically stay out of the way of the RSAs. NOTE: This proposal assumes the existence of some form of policy such as that proposed by the "Whois Integrity Policy Proposal." Timetable for implementation: Immediate From randy at psg.com Wed Aug 20 10:51:59 2008 From: randy at psg.com (Randy Bush) Date: Wed, 20 Aug 2008 07:51:59 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10A2D@mail> References: <48AB5435.2070908@psg.com> <70DE64CEFD6E9A4EB7FAF3A063141066A10A2D@mail> Message-ID: <48AC2F8F.9030308@psg.com> Kevin Kargel wrote: > And what are you going to do about the greedy cow that runs forward, stomps > the kid to mush and takes the whole bucket of grain for herself? let the black helicopters take care of it. in my dotage, i try to find the positive path and not all the fud. randy From bill at herrin.us Wed Aug 20 12:34:00 2008 From: bill at herrin.us (William Herrin) Date: Wed, 20 Aug 2008 12:34:00 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <34567.1219192974@nsa.vix.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <86skt0ltqu.fsf@seastrom.com> <48AB17DD.6020009@psg.com> <86d4k4ltd9.fsf@seastrom.com> <3c3e3fca0808191612x5d84942dyb935b30e1c673aaf@mail.gmail.com> <34567.1219192974@nsa.vix.com> Message-ID: <3c3e3fca0808200934o4017bfb0s744e1e73d0d0d396@mail.gmail.com> On Tue, Aug 19, 2008 at 8:42 PM, Paul Vixie wrote: >> From: "William Herrin" >> The LRSA should be structured so that it serves as a strong check on >> ARIN's -future- actions with repspect to the legacy registrations. It >> doesn't make the grade. A properly motivated ARIN board would have >> sufficient legal wiggle room to do just about anything they wanted to the >> legacy registrants with no recourse on the registrants part, exactly as >> is the case for modern end-user registrants. Give the legacy registrant >> the power to terminate the contract and the possibility of adverse action >> by ARIN can never become a serious threat. > > let me start by arguing the opposite. if you think that address holders are > a necessary check+balance on ARIN misbehaviour, then you should be arguing > that ALL address holders must have this role, legacy and non-legacy alike. Paul, On another day I may well make that argument. Today I have a different focus. The focus is this: If you (meaning ARIN) believe it desirable to bring the legacy registrants into the fold, you really have two options: 1. Do it substantially on their terms. 2. Do it by soliciting sufficient legal authority for ICANN from the USG so that "the community," by way of ARIN, can force the issue. Pick your poison. We can argue about it on PPML for the next ten years but the bottom line is this: the legacy registrants will come into the fold either when they're forced to or when they see an offer they like. At the moment, you haven't enough authority to force the issue without making a mess that hurts you and the community as much as or more than it hurts the legacy registrants. And you haven't made the legacy registrants an offer they like. > let me finish by saying that ARIN's policies are what the community makes. > there's no way for the board or AC or staff, or any national government, to > ram policies down the community's throat, or withhold approval or execution > of policies that the community has created. if LRSA is wrong, then submit > a policy process to fix it. As I recall, the community's involvement with the LRSA started and stopped with proposing that one exist. From there it was taken behind closed doors and ratified in substantially the same form as it was first presented. And frankly that's probably OK. It isn't within the purview of the public policy process to write ARIN's contract documents. The best any of us can really do is draw your attention to clauses that might be improved. On Wed, Aug 20, 2008 at 1:40 AM, Ted Mittelstaedt wrote: >> > Thus, how exactly would this legacy resource holder system be any >> > different than what the legacy resource holders have right now with >> > the ARIN legacy RSA? >> >> It would be terminable in the event of a dispute. The >> practical effect of the LRSA language is that its not >> terminable by the registrant. > > So then, is a legacy holder wants to opt out of it due > to disputing it, they can. In which case the legacy > holder system admin would pull their names out from > their system and it seems your right back where you started > with the same problem. > > How is that better? Because it tends not to happen. The system admin has a pretty good idea which behaviors will cause more than a handful of registrants to jump ship, so he avoids those behaviors even when he really really doesn't want to. It's called "checks and balances." It helps keep people honest. > What is the point of signing a contract that has no teeth? Excellent question but it cuts both ways. With the LRSA, we know what teeth bite the registrant if he doesn't uphold his end: he loses his addresses. What teeth bite ARIN if they don't uphold theirs? What's ARIN's penalty for trying to skirt the edge of what the contract allows? Without as strong a penalty as the registrant faces for failing to uphold his end, the LRSA is lopsided even before you consider the beneficial status the legacy registrant holds if he signs no contract. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Lee.Howard at stanleyassociates.com Wed Aug 20 13:26:57 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 20 Aug 2008 13:26:57 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <3c3e3fca0808200934o4017bfb0s744e1e73d0d0d396@mail.gmail.com> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40AFE6F5F@CL-S-EX-1.stanleyassociates.com> Bill Herrin carved the following in cuneiform on clay tablets: > What teeth bite ARIN if they > don't uphold theirs? What's ARIN's penalty for trying to > skirt the edge of what the contract allows? Can you provide some examples of what an evil ARIN could do that isn't covered in the LRSA? My experience is such that I trust ARIN more than some people, so I have a paucity of imagination. Extra points if you suggest terms of enforcement. Lee From vixie at isc.org Wed Aug 20 14:13:22 2008 From: vixie at isc.org (Paul Vixie) Date: Wed, 20 Aug 2008 18:13:22 +0000 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: Your message of "Wed, 20 Aug 2008 12:34:00 -0400." <3c3e3fca0808200934o4017bfb0s744e1e73d0d0d396@mail.gmail.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <86skt0ltqu.fsf@seastrom.com> <48AB17DD.6020009@psg.com> <86d4k4ltd9.fsf@seastrom.com> <3c3e3fca0808191612x5d84942dyb935b30e1c673aaf@mail.gmail.com> <34567.1219192974@nsa.vix.com> <3c3e3fca0808200934o4017bfb0s744e1e73d0d0d396@mail.gmail.com> Message-ID: <16328.1219256002@nsa.vix.com> > If you (meaning ARIN) believe it desirable to bring the legacy > registrants into the fold, you really have two options: > > 1. Do it substantially on their terms. > 2. Do it by soliciting sufficient legal authority for ICANN from the > USG so that "the community," by way of ARIN, can force the issue. > > Pick your poison. as a signator of LRSA in my day job, i just can't agree that this is the choice ARIN faces. and without taking a position on whether ICANN is a relevant authority or a past successor in interest to USG on addresses, i think your given two choices are oversimplified. > We can argue about it on PPML for the next ten years but the bottom > line is this: the legacy registrants will come into the fold either > when they're forced to or when they see an offer they like. At the > moment, you haven't enough authority to force the issue without making > a mess that hurts you and the community as much as or more than it > hurts the legacy registrants. if the will of the community was that the issue be forced, then we could discuss its practicalities. however, that's not evidenced, so let's not. > And you haven't made the legacy registrants an offer they like. you're acting like i was the only one who signed it on advice of dayjob counsel. there hasn't been a stampede, i'll grant that, but other than a few folks on PPML some of whom misunderstood the terms and changed their minds after they learned the details, there hasn't been a revolt, either. > > ... > > As I recall, the community's involvement with the LRSA started and > stopped with proposing that one exist. From there it was taken behind > closed doors and ratified in substantially the same form as it was first > presented. > > And frankly that's probably OK. It isn't within the purview of the public > policy process to write ARIN's contract documents. The best any of us can > really do is draw your attention to clauses that might be improved. while PPML is meant substantially to discuss the NRPM, it's in my opinion quite reasonable to propose changes to the LRSA here as well, even if the process for getting ideas from the mailing list into the contract language are a bit fuzzy. the LRSA is online, i recommend that folks who think it sends the wrong message or misconveys the community's interests download it, post the text they think is bad, and post proposed replacement text, with reasoning for the change. if on the other hand your complaint is not generalizable -- it's for your own reasons as a legacy holder that you do not want to sign it -- then that's probably something to negotiate with staff rather than trying to get community consensus about it. > On Wed, Aug 20, 2008 at 1:40 AM, Ted Mittelstaedt wrote: > > What is the point of signing a contract that has no teeth? > > Excellent question but it cuts both ways. With the LRSA, we know what > teeth bite the registrant if he doesn't uphold his end: he loses his > addresses. What teeth bite ARIN if they don't uphold theirs? What's > ARIN's penalty for trying to skirt the edge of what the contract allows? lawsuits, i expect. but can you explain ARIN's likely motives for skirting? > Without as strong a penalty as the registrant faces for failing to uphold > his end, the LRSA is lopsided even before you consider the beneficial > status the legacy registrant holds if he signs no contract. my own dayjob counsel told me that it would be better to have known rights than unknown rights, as long as i didn't care about selling the address space on e-bay. is that the elephant in this room? are some legacy holders objecting to having RSA-like restrictions on selling their space, and are therefore rejecting the LRSA on that basis, but not willing to say so here? if so, that's kinda rotten, and maybe somewhat pessimistic. i don't expect that any transfer policy (along the lines of 2008-2 or similar) will offer differential rights to LRSA vs. RSA, and i think it would be wrong for legacy holders to ask for differential transfer rights, that would show a "land rush" mentality around resources that were granted by the community for the community's good. legacy, LRSA, and RSA all share fate with regard to prospective "paid transfer" or any other kind of transfer. so i'm at wit's end trying to understand what rights a legacy holder thinks they can preserve by not signing an LRSA. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From tedm at ipinc.net Wed Aug 20 14:25:08 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 20 Aug 2008 11:25:08 -0700 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: <48AC2E7F.1070806@arin.net> Message-ID: <622D234811B54D0DB630E804F029A274@tedsdesk> Am I correct in assuming that this proposal presumes that legacy holders who have NOT signed an RSA will not be permitted to modify their whois data, unless they have gone through this "authentication process"? I wasn't aware that legacy holders, today, are not permitted to update their whois data with ARIN unless they have signed a Legacy RSA. Is that true? I am not happy with the verbage: "...This proposal assumes the existence of some form of policy such as that proposed by the "Whois Integrity Policy Proposal..." The proposer is asking that we consider a "meta" policy proposal, that is, a proposal that applies to a proposal under consideration. I disagree with this. I would prefer the proposer of this proposal should instead work with the authors of the current proposals under consideration, such as the "Whois Integrity Policy Proposal" to incorporate his ideas into the existing proposals, rather than submitting a meta-proposal. Or if those authors refuse to do that, then he can submit a competing proposal that does the same thing that an existing proposal does, plus his modifications. Ted > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > Sent: Wednesday, August 20, 2008 7:47 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Policy Proposal: Whois Authentication > Alternatives > > > ARIN received the following policy proposal. In accordance > with the ARIN Internet Resource Policy Evaluation Process, > the proposal is being posted to the ARIN Public Policy > Mailing List (PPML) and being placed on ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal at > their next regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as written. If the AC accepts > the proposal, it will be posted as a formal policy proposal > to PPML and it will be presented at a Public Policy Meeting. > > 2. Postpone their decision regarding the proposal until > the next regularly scheduled AC meeting in order to work with > the author. The AC will work with the author to clarify, > combine or divide the proposal. At their following meeting > the AC will accept or not accept the proposal. > > 3. Not accept the proposal. If the AC does not accept > the proposal, the AC will explain their decision via the > PPML. If a proposal is not accepted, 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 proposal will be closed. > > The AC will assign shepherds in the near future. ARIN will > provide the names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this > proposal on the PPML, particularly their support or > non-support and the reasoning behind their opinion. Such > participation contributes to a thorough vetting and provides > important guidance to the AC in their deliberations. > > The ARIN Internet Resource Policy Evaluation Process can be > found at: http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: Whois Authentication Alternatives > > Author: Michael Sinatra > > Proposal Version: 1 > > Submission Date: August 19, 2008 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > In addition to current processes ARIN has to authenticate > holders of historical resources, ARIN will also allow holders > of resources to authenticate themselves for the purposes of > updating WHOIS information for a given resource according to > the following mechanism: > > A holder of resources not governed by any type of RSA (i.e. > legacy or regular) may work with ARIN staff to establish an > inventory of those resources legitimately maintained by the > holder. ARIN staff will work to authenticate each resource > claimed by the holder. Upon successful completion of the > authentication process, the holder will be entitled to make > updates to whois information for those resources for a period > of one year, with an option for renewal. For ARIN > non-members, ARIN will charge a maintenance fee to recover > costs associated with the authentication process and whois > maintenance. For ARIN members, the fee will be waived or > discounted at ARIN's discretion. Renewal is automatic > pending the payment of maintenance or membership fees. > Failure to pay fees will result in the whois information > being "locked," and updates to the information will not be possible. > > Successful authentication and the payment of membership > and/or maintenance fees does not confer any rights upon the > holder such as those that would be granted by an RSA (legacy > or regular). > > Rationale: > > ARIN needs to protect whois data from hijacking, but the > current mechanisms for authenticating holders (especially > legacy holders) are limited. The current method, signing a > Legacy RSA, may not be a viable option in the near term for > such legacy holders for a variety of legal reasons. In the > interest of: (a) protecting whois data; (b) keeping whois > up-to-date for the Internet community; and > (c) recovering costs associated with WHOIS and in-addr.arpa > delegation, an alternative authentication mechanism needs to > be established for holders of historical resources. This > proposal does not intend to discount either type of RSA, and > it attempts to specifically stay out of the way of the RSAs. > > NOTE: This proposal assumes the existence of some form of > policy such as that proposed by the "Whois Integrity Policy Proposal." > > Timetable for implementation: Immediate > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From michael at rancid.berkeley.edu Wed Aug 20 14:40:01 2008 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Wed, 20 Aug 2008 11:40:01 -0700 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: <622D234811B54D0DB630E804F029A274@tedsdesk> References: <622D234811B54D0DB630E804F029A274@tedsdesk> Message-ID: <48AC6501.2000304@rancid.berkeley.edu> Thanks, Ted. On 08/20/08 11:25, Ted Mittelstaedt wrote: > Am I correct in assuming that this proposal presumes that > legacy holders who have NOT signed an RSA will not be > permitted to modify their whois data, unless they have > gone through this "authentication process"? Yes, if the "Whois Integrity Policy" and the policy are adopted. > I wasn't aware that legacy holders, today, are not permitted > to update their whois data with ARIN unless they have signed > a Legacy RSA. Is that true? It is not currently true. It *appears* that it would be made true if the "Whois Integrity Policy" were adopted. > I am not happy with the verbage: > > "...This proposal assumes the existence of some form of > policy such as that proposed by the "Whois Integrity Policy Proposal..." Are you not happy with the verbiage or are you not happy with the assumption itself? > The proposer is asking that we consider a "meta" policy proposal, > that is, a proposal that applies to a proposal under consideration. > I disagree with this. I wouldn't call it a meta proposal, but your general impression is correct. > I would prefer the proposer of this proposal should instead work with the > authors of the current proposals under consideration, such as > the "Whois Integrity Policy Proposal" to incorporate his ideas > into the existing proposals, rather than submitting a meta-proposal. > Or if those authors refuse to do that, then he can submit a > competing proposal that does the same thing that an existing > proposal does, plus his modifications. The proposal was submitted in order to express language that would allow me, and perhaps others, to support Heather's proposal. I'd actually argue that the proposals be combined, but I don't know Heather's view on this and do not wish to speak for her. (She has not yet responded to the thread on her proposal, so I don't know if she's aware of the comments.) If Heather wants to take language from my proposal and incorporate it into hers, then I'll happily withdraw my proposal. The intent of my proposal was to give the AC additional language that would make a general whois integrity proposal more palatable for legacy holders who are trying to work out issues with their GCs and the LRSA. I leave it up to the AC to ultimately decide with to do with it, but I think we'd all like to see input from PPML, as you have done. michael From arin-ppml at westbrook.com Wed Aug 20 14:47:44 2008 From: arin-ppml at westbrook.com (Eric Westbrook) Date: Wed, 20 Aug 2008 12:47:44 -0600 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <16328.1219256002@nsa.vix.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <86skt0ltqu.fsf@seastrom.com> <48AB17DD.6020009@psg.com> <86d4k4ltd9.fsf@seastrom.com> <3c3e3fca0808191612x5d84942dyb935b30e1c673aaf@mail.gmail.com> <34567.1219192974@nsa.vix.com> <3c3e3fca0808200934o4017bfb0s744e1e73d0d0d396@mail.gmail.com> <16328.1219256002@nsa.vix.com> Message-ID: <6905ba860808201147pe7d4423o8cddcce685baeb45@mail.gmail.com> First, a brief rebuttal on a disagreement to one of my prior points. On Tue, Aug 19, 2008 at 6:59 PM, Leo Bicknell wrote: Bob requests a digital certificate from ARIN for the companies role account. > (http://www.arin.net/CA/) Bob places it in a lockbox at work. Great idea. I think most would agree that widespread use of digital certificates would enhance whois integrity. Bad news, though -- an RSA isn't required to use the already existing digital certificate mechanism described at the URL you pointed out. I just registered mine, in fact. Thanks. Therefore, my previous points about the non-necessity of an RSA for whois integrity stand firm. but having no contract is unacceptable to me. There we go. This is the real elephant in the room, isn't it. I originally entered this conversation, perhaps naively, actually expecting the debate to be about the proposal's stated purpose. It's clearly not. In fact, I haven't once heard even speculation that it's an actual problem. No hard numbers of fraud occurrences, no damage figures, not even any guesses. So it would seem that, as posed, this proposal is either a solution in search of a problem, or a trojan horse for RSA mandating. So, on the matter of this proposal, since legacy contract assimilation is clearly separate from, and unnecessary for, improving whois integrity, I would conclude confidently that this particular proposal cannot be seen as having merit in any rational context and must be rejected. That said, it does seem to me that some proposal, *perhaps one as simple as requiring use of the existing digital certificate facilities*, to improve whois integrity would probably have noteworthy merit. I do see a new proposal on the list regarding whois authentication. It seems to depend on this one, so I believe it's moot. Please notice that I am not, in this thread, arguing for nor against legacy RSA assimilation, nor am I making any points about the merits of the current LRSA itself. I probably will at some point, but not here. It's obviously a topic that requires debate (and is receiving it, even if potentially off-topic in this thread). It should receive that debate. But please, I would ask you all, do not dishonor this community by attempting to accomplish whichever goals you have on that issue through dubious, meritless, or disingenuine attachment to unrelated, more simply solvable, or otherwise conflated issues. It should stand alone as the question it deserves to be -- even if some people might not like the consensus that emerges when it's asked straight up. My "no" recommendation on this proposal remains firm. None of the benefits sought are achieved by the mechanism proposed. $0.02, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Wed Aug 20 14:55:35 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 20 Aug 2008 11:55:35 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <3c3e3fca0808200934o4017bfb0s744e1e73d0d0d396@mail.gmail.com> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin > Sent: Wednesday, August 20, 2008 9:34 AM > To: Paul Vixie > Cc: Randy Bush; arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Whois Integrity > Policy Proposal > > If you (meaning ARIN) believe it desirable to bring the > legacy registrants into the fold, you really have two options: > > 1. Do it substantially on their terms. > 2. Do it by soliciting sufficient legal authority for ICANN > from the USG so that "the community," by way of ARIN, can > force the issue. > There is a 3rd option, one that ARIN is currently employing: 3) make their non-participation in the fold, irrelevant. When the Internet has switched to IPv6 then there will be no more legacy holders "out of the fold" I'm not saying that "do nothing" is preferable, only that it is an option. > > We can argue about it on PPML for the next ten years In ten years IPv4 will be well on it's way to becoming irrelevant and so will the legacy holders. (if they don't adopt IPv6) > > On Wed, Aug 20, 2008 at 1:40 AM, Ted Mittelstaedt > wrote: > >> > Thus, how exactly would this legacy resource holder > system be any > >> > different than what the legacy resource holders have > right now with > >> > the ARIN legacy RSA? > >> > >> It would be terminable in the event of a dispute. The practical > >> effect of the LRSA language is that its not terminable by the > >> registrant. > > > > So then, is a legacy holder wants to opt out of it due > > to disputing it, they can. In which case the legacy > > holder system admin would pull their names out from > > their system and it seems your right back where you started > with the > > same problem. > > > > How is that better? > > Because it tends not to happen. The system admin has a pretty > good idea which behaviors will cause more than a handful of > registrants to jump ship, so he avoids those behaviors even > when he really really doesn't want to. It's called "checks > and balances." It helps keep people honest. > > > What is the point of signing a contract that has no teeth? > > Excellent question but it cuts both ways. With the LRSA, we > know what teeth bite the registrant if he doesn't uphold his > end: he loses his addresses. What teeth bite ARIN if they > don't uphold theirs? What's ARIN's penalty for trying to > skirt the edge of what the contract allows? Without as strong > a penalty as the registrant faces for failing to uphold his > end, the LRSA is lopsided even before you consider the > beneficial status the legacy registrant holds if he signs no contract. > ARIN isn't an address user. If you think about it you will realize that ARIN has no real interest in taking back addresses from legacy holders who are using them. What are the legacy holders doing with large blocks of addresses that they have? Assigning them to customers. If ARIN "takes away" a block of addresses from a legacy holder, those customers will still need addresses. Where are they going to get them? From non-legacy holders. And the non-legacy holders now need more addressing and they get it from ARIN. And so you have just succeeded in moving a block of addresses in a big circle, you have taken it from the customers of a legacy holder and given it to a non-legacy holder who just gives them back to the same customers that you took them from in the first place. In short, you have gained absolutely nothing. This behavior will not create IPv4 addresses out of thin air. ARIN only has an interest in taking IPv4 addresses away from legacy holders who are sitting on them and who are NOT using them. And, this interest also aligns with the interests of everyone else on the Internet, including I might add, other legacy holders who happen to have assigned out all their allocation and need more numbers. And I would assume that legacy holders who are doing that (basically engaging in speculation of IPv4) are not interested in signing ANYTHING either a LRSA or an alternative registry run by legacy holders, because they don't want to draw attention to what they are doing. The $64,000 question here is one of motive. You speak of both the legacy holders and ARIN having incentives to violate the LRSA. What are those incentives? What motive exists for either side to violate the LRSA? And in addition the Legacy holders can always opt to sign a regular RSA -instead- of a LRSA if the LSRA is so bad. You may as well ask what are the penalties to ARIN for violating a regular RSA with a regular allocator? Ted From michael at rancid.berkeley.edu Wed Aug 20 15:00:34 2008 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Wed, 20 Aug 2008 12:00:34 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <6905ba860808201147pe7d4423o8cddcce685baeb45@mail.gmail.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <86skt0ltqu.fsf@seastrom.com> <48AB17DD.6020009@psg.com> <86d4k4ltd9.fsf@seastrom.com> <3c3e3fca0808191612x5d84942dyb935b30e1c673aaf@mail.gmail.com> <34567.1219192974@nsa.vix.com> <3c3e3fca0808200934o4017bfb0s744e1e73d0d0d396@mail.gmail.com> <16328.1219256002@nsa.vix.com> <6905ba860808201147pe7d4423o8cddcce685baeb45@mail.gmail.com> Message-ID: <48AC69D2.2040900@rancid.berkeley.edu> On 08/20/08 11:47, Eric Westbrook wrote: > That said, it does seem to me that some proposal, /perhaps one as simple > as requiring use of the existing digital certificate facilities/, to > improve whois integrity would probably have noteworthy merit. I do see > a new proposal on the list regarding whois authentication. It seems to > depend on this one, so I believe it's moot. What the second proposal does is to allow for a non-(L)RSA mechanism for authentication, in the event that more substantial authentication is deemed appropriate by the ARIN community. One way that it might happen is for the current "Whois Integrity" proposal to be adopted. However, the language could be easily changed so that the proposal stands on its own, by simply requiring more authentication for whois updates. Even if it doesn't stand on its own, it's not moot. It removes the reliance on the RSAs for authentication, which appears to be what you want. On the digital cert issue, I leave that to ARIN staff as an implementation issue, but it is what I had in mind as the method by which folks would continue to make updates after their non-RSA authentication. michael From tedm at ipinc.net Wed Aug 20 15:41:45 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 20 Aug 2008 12:41:45 -0700 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: <48AC6501.2000304@rancid.berkeley.edu> Message-ID: > -----Original Message----- > From: Michael Sinatra [mailto:michael at rancid.berkeley.edu] > Sent: Wednesday, August 20, 2008 11:40 AM > To: Ted Mittelstaedt > Cc: 'Member Services'; arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Whois > Authentication Alternatives > > > Thanks, Ted. > > On 08/20/08 11:25, Ted Mittelstaedt wrote: > > Am I correct in assuming that this proposal presumes that legacy > > holders who have NOT signed an RSA will not be permitted to modify > > their whois data, unless they have gone through this > "authentication > > process"? > > Yes, if the "Whois Integrity Policy" and the policy are adopted. > > > I wasn't aware that legacy holders, today, are not > permitted to update > > their whois data with ARIN unless they have signed a Legacy > RSA. Is > > that true? > > It is not currently true. It *appears* that it would be made true if > the "Whois Integrity Policy" were adopted. > > > I am not happy with the verbage: > > > > "...This proposal assumes the existence of some form of > > policy such as that proposed by the "Whois Integrity > Policy Proposal..." > > Are you not happy with the verbiage or are you not happy with the > assumption itself? > The assumption. > > The proposer is asking that we consider a "meta" policy > proposal, that > > is, a proposal that applies to a proposal under consideration. I > > disagree with this. > > I wouldn't call it a meta proposal, but your general > impression is correct. > > > I would prefer the proposer of this proposal should instead > work with > > the authors of the current proposals under consideration, > such as the > > "Whois Integrity Policy Proposal" to incorporate his ideas into the > > existing proposals, rather than submitting a meta-proposal. Or if > > those authors refuse to do that, then he can submit a competing > > proposal that does the same thing that an existing proposal > does, plus > > his modifications. > > The proposal was submitted in order to express language that > would allow > me, and perhaps others, to support Heather's proposal. I'd actually > argue that the proposals be combined, but I don't know > Heather's view on > this and do not wish to speak for her. (She has not yet responded to > the thread on her proposal, so I don't know if she's aware of the > comments.) If Heather wants to take language from my proposal and > incorporate it into hers, then I'll happily withdraw my proposal. > I think you should have taken Heathers proposal, add your ideas, and submitted it as a competing proposal to Heathers. > The intent of my proposal was to give the AC additional language that > would make a general whois integrity proposal more palatable > for legacy > holders who are trying to work out issues with their GCs and > the LRSA. I know. The problem here is that one of the main reasons for signing the LRSA is to get whois integrity. Keep in mind that the ARIN community did not give up the right to go after legacy numbering that non-LRSA legacy signatories hold, after the termination of the availability of the LRSA next year. In short, the LRSA is a defence by legacy holders that the community isn't going to come after their holdings. Your and Heather's proposals basically take away the reason a legacy holder has to sign the LRSA in the first place. The LRSA availability sunsets next year. I would vote to oppose any attempt to extend it's availability after the availability sunsets. As a fee-paying member I would prefer at that time to see ARIN go after the legacy holders who aren't under LRSA and take away IPv4 that they are not using or advertising. By then the Legacy holders who haven't signed the LRSA will have had enough time to look at the LRSA to sign it and there is no point in holding out that particular carrot any more. Ted From bill at herrin.us Wed Aug 20 15:41:50 2008 From: bill at herrin.us (William Herrin) Date: Wed, 20 Aug 2008 15:41:50 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40AFE6F5F@CL-S-EX-1.stanleyassociates.com> References: <3c3e3fca0808200934o4017bfb0s744e1e73d0d0d396@mail.gmail.com> <369EB04A0951824ABE7D8BAC67AF9BB40AFE6F5F@CL-S-EX-1.stanleyassociates.com> Message-ID: <3c3e3fca0808201241k77c1f45do506deb38e5f55719@mail.gmail.com> On Wed, Aug 20, 2008 at 1:26 PM, Howard, W. Lee wrote: > Bill Herrin carved the following in cuneiform on clay tablets: >> What teeth bite ARIN if they >> don't uphold theirs? What's ARIN's penalty for trying to >> skirt the edge of what the contract allows? > > Can you provide some examples of what an evil ARIN could do > that isn't covered in the LRSA? Howard, An "evil" ARIN eh? Hmm, let's see... 4.d.ii. You host a whistleblower site on the IP addresses through which classified information is leaked. Having broken the law in a manner associated with the IP addresses, an evil ARIN is permitted to cancel your registration, at which point the IP addresses revert to ARIN's control. 6.b. An evil ARIN could reinterpret 6b. Means 1 or 2, not 1 and 2. Since it's 2013 and all end-user maintenance fees have increased to $50k/year (the money redistributed to help the poor backbones cope with the IPv4 route explosion in the wake of IPv6's failure) that includes the legacy maintenance fee. Now the onus is on the registrant to successfully bring action under 14.c, which requires him to attend 15.l. arbitration in Washington DC. And then having gone to that time and expense, he has to actually convince the arbitrator that 6b really does require ARIN to meet BOTH criteria 1 and 2. 14.a. An evil ARIN could simply give 30 days' notice to the legacy registrant that they are terminating the LRSA agreement at the end of the current annual period. No cause; they're simply not offering renewal. The termination was not per 14.c, so per 14.e. the address revert to ARIN. Want another? I can keep going for a while. > My experience is such that > I trust ARIN more than some people, so I have a paucity of > imagination. The courts are full of good, trustworthy people suing each other over broken promises. Stuff happens. Priorities change. Even with the best intentions, perceptions of "fair" drift apart. A good system is resilient in the face of that drift. > Extra points if you suggest terms of enforcement. Have termination for any cause other than non-communication, non-payment or unlawful action specifically against ARIN to cause control of the addresses to revert to the current status quo, similar to the results of having successfully completed 14.c. Also, 14c and 14f are in conflict. The number resources can't resume the status they had prior to the legacy agreement if questionable sections (like 9) survive the contract's termination. In an ordinary contract of adhesion like this, the ambiguity would be resolved against the drafter (ARIN). The LRSA specifically excludes that in 15i. On Wed, Aug 20, 2008 at 2:13 PM, Paul Vixie wrote: > you're acting like i was the only one who signed it on advice of dayjob > counsel. there hasn't been a stampede, i'll grant that, but other than a > few folks on PPML some of whom misunderstood the terms and changed their > minds after they learned the details, there hasn't been a revolt, either. Paul, No, there hasn't been a stampede. Nor a revolt. I think that's because many (perhaps most) of the legacy registrants think that the LRSA was a strong step in the right direction. Now take the next step and the one after that, and you may actually see the stampede. Which, IMO, would be a good thing. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From sdean at bard.edu Wed Aug 20 16:02:17 2008 From: sdean at bard.edu (Stewart Dean) Date: Wed, 20 Aug 2008 16:02:17 -0400 Subject: [arin-ppml] Address Range transfer question In-Reply-To: <01DF9DF7F38D429D85CDC9F336978E9A@tedsdesk> References: <01DF9DF7F38D429D85CDC9F336978E9A@tedsdesk> Message-ID: <48AC7849.60007@bard.edu> My deep thanks to everyone who responded. The signal to noise ratio on this list is the highest I've ever seen. Even the disagreement is is thoughtfully argued based on experience, and the wisdom quotient is very high. Your answers put me way ahead. When I first started trying to understand what was going on with ARIN (started by the ARIN transfer survey, which didn't explain the substance or background of any of the questions), I felt like I'd wandered in Chinese water torture...a whole lot of blahblahblah without any sense of where it was leading or why they (whoever they are) are doing this. I now understand they are in the unenviable position of annoying everyone as they try to burn off enough fog to survey and begin regulation of the territory. Nothing much was previously charted or regulated so they are trying to make some kind of start....and virtually anything they do will annoy someone. Right now, I am getting my ducks in a row before contacting ARIN...and I now have a much better idea of what challenges/opportunities are involved, and what I might do about them......... Thanks -- ==== Stewart Dean, Unix System Admin, Henderson Computer Resources Center of Bard College, Annandale-on-Hudson, New York 12504 sdean at bard.edu voice: 845-758-7475, fax: 845-758-7035 From bicknell at ufp.org Wed Aug 20 16:02:45 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 20 Aug 2008 16:02:45 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <6905ba860808201147pe7d4423o8cddcce685baeb45@mail.gmail.com> References: <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <86skt0ltqu.fsf@seastrom.com> <48AB17DD.6020009@psg.com> <86d4k4ltd9.fsf@seastrom.com> <3c3e3fca0808191612x5d84942dyb935b30e1c673aaf@mail.gmail.com> <34567.1219192974@nsa.vix.com> <3c3e3fca0808200934o4017bfb0s744e1e73d0d0d396@mail.gmail.com> <16328.1219256002@nsa.vix.com> <6905ba860808201147pe7d4423o8cddcce685baeb45@mail.gmail.com> Message-ID: <20080820200245.GA59630@ussenterprise.ufp.org> In a message written on Wed, Aug 20, 2008 at 12:47:44PM -0600, Eric Westbrook wrote: > I originally entered this conversation, perhaps naively, actually > expecting the debate to be about the proposal's stated purpose. It's > clearly not. In fact, I haven't once heard even speculation that it's > an actual problem. No hard numbers of fraud occurrences, no damage > figures, not even any guesses. So it would seem that, as posed, this > proposal is either a solution in search of a problem, or a trojan > horse for RSA mandating. Unfortunately there is a lack of hard numbers. There have been a number of groups that have tried to track hijacked netblocks over the years, entering "hijacked netblocks" in google will find plenty. ARIN does much of its work on them behind closed doors, and for good reason. ARIN actually tries to get criminal and civil prosecution of the fraudsters. More than a few ISP folks will tell you in the halls about cases where a customer came to them with a funny looking block, they referred it to ARIN and soon after that person no longer had the block. I believe many of these are from hijacking. ARIN has stood up in several meetings when asked about hijackings and has always said the same thing, far more attempts are made to hijack legacy space than ARIN assigned space; and the primary reason is the contact information for the legacy space was either never fully filled out in the first place, or points all to sources that are now gone. People have in fact registered lapsed domains because they can then send e-mail from the address in whois, I believe in one case they even got the phone company to assign them an old phone number (it wasn't in use anymore, so they could just request it). Most importantly, if it has become fallow there is no one to notice someone else announcing the space! While I don't have a hard number (x blocks were hijacked last year), and I can't tell you the economic impact (how much did it cost arin? for that matter, how much does it cost the net as a whole if spammer gets to use a hijacked block for 3 months?) I believe both are significant enough we should do something about it. A contract is about "I do something for you, you do something for me." ARIN is taking the time and effort to verify paperwork in this case, and vouch to the rest of the world, via whois, that you are the proper holder of the resource in question. That you have a right to use the unique integers, and no one else does. I believe anyone who derives that benefit should have both a contract, and pay the cost recovery portion of that service at a minimum. I said "a contract" because to me it does not have to be the current RSA or LRSA. It could be a different kind of contract; but at the minimum it has to state the rights and obligations on both sides. Part of the reason we are in this mess is because early on someone decided not to write some of this stuff down. Courts hate oral/implied contracts. They want to see there was a meeting of the minds, and writing it down is the best way. In this case I think the LRSA meets all of my requirements, but that does not mean some other contract couldn't meet it as well. I'm also open to the idea that there are other ways to solve this problem. This proposal to me does not need to be the end all be all. > That said, it does seem to me that some proposal, perhaps one as > simple as requiring use of the existing digital certificate > facilities, to improve whois integrity would probably have noteworthy > merit. I do see a new proposal on the list regarding whois > authentication. It seems to depend on this one, so I believe it's > moot. The question I would ask then is if such a propsoal should be required? If only 10% of the legacy holders opted to get a digital certificate that's good, but it leaves 90% of the problem. Can, and/or should ARIN mandate upgraded security, such as digital certificates? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From JOHN at egh.com Wed Aug 20 16:15:43 2008 From: JOHN at egh.com (John Santos) Date: Wed, 20 Aug 2008 16:15:43 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <198BCFC5-80E8-40EB-B79F-80CEDA2B0D52@delong.com> Message-ID: <1080820154603.27224A-100000@Ives.egh.com> On Tue, 19 Aug 2008, Owen DeLong wrote: > > On Aug 19, 2008, at 4:39 PM, John Santos wrote: > > > > > > > Exclusivity *IS* a right. Saying that ARIN promises it won't assign > > the > > same number to someone else and then saying that no rights are > > provided > > is nonsense. If no right is provided, then ARIN could break its > > promise > > any time it wanted to. > > > Not quite. No rights to the number are provided. Nothing prevents > anyone else from using the number. It just prevents ARIN from > registering the number to someone else. (As things currently > stand, it also happens to prevent other RIRs from registering it > as well, but, that's cooperation, not a right). > > Sure, if ARIN registers the number to another party as well, they > have violated their contract with you (if you have an RSA), and > you then have the right to sue them for breach of contract. However, > the contract doesn't convey a right. Right: n. That which a person has a just claim to; power, privilege, etc. that belongs to a person by law, nature or tradition. Sure sounds like a right to me. ARIN would be breaching its contract with the Dept. of Commerce or IANA or whatever historically gave it the right to allocate address space that was not *already* allocated to legacy holders, not with me, as I have no contract with ARIN. However, if I were to sign an LRSA (or get on of the company officers to sign it), ARIN could sieze my address space tomorrow. Why? Because although I easily qualify for a class C (what I was allocated 16? years ago), I don't have nearly enough usage to qualify for a /22, which is the minimum permitted under current rules. Unless it has changed, the LRSA says I have to qualify under the current rules to keep my space. Don't go saying I should be getting my space from my ISP or from RFC1918... Most of my hosts fall into what is described as "Catagory 3" in RFC1918. And I must not understand the meaning of the word "static" in the term "Verizon Business FIOS static address", since they informed us two days ago that our "static" addresses are changing at midnight on Sept 11. And no, they can't tell us what the new addresses are, but if we just keep following the telephone support system's prompts, we'll eventually get disconnected, "thank you, your call is important to us." Fortunately, it is only 5/8th's of our externally visible addresses that are affected... I'm not annoyed. :-( [... stuf about mail formating; this one looks fine.] > > Owen -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From tedm at ipinc.net Wed Aug 20 16:27:35 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 20 Aug 2008 13:27:35 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <20080820200245.GA59630@ussenterprise.ufp.org> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Leo Bicknell > Sent: Wednesday, August 20, 2008 1:03 PM > To: Eric Westbrook > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Whois Integrity > Policy Proposal > > > People have in fact registered lapsed domains because they > can then send e-mail from the address in whois, I believe in > one case they even got the phone company to assign them an > old phone number (it wasn't in use anymore, so they could > just request it). Most importantly, if it has become fallow > there is no one to notice someone else announcing the space! > Now this is a case for vigilantie volunteerism!! We need a guy to sit there and do this - register these lapsed domains, setup POC's for them then send ARIN an e-mail returning the legacy space!!! People do this vigilantee volunteerism for spammers when they setup blacklists, why not this? Come on, folks get with it!!! ;-) Seriously, why doesen't ARIN have an employee that has this assigned to them as their full time job - the finding and returning to the address pool of fallow legacy assignments. Ted From JOHN at egh.com Wed Aug 20 17:28:27 2008 From: JOHN at egh.com (John Santos) Date: Wed, 20 Aug 2008 17:28:27 -0400 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: Message-ID: <1080820172429.27224A-100000@Ives.egh.com> On Wed, 20 Aug 2008, Ted Mittelstaedt wrote: > > > > -----Original Message----- > > From: Michael Sinatra [mailto:michael at rancid.berkeley.edu] > > Sent: Wednesday, August 20, 2008 11:40 AM > > To: Ted Mittelstaedt > > Cc: 'Member Services'; arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal: Whois > > Authentication Alternatives > > > > > > Thanks, Ted. > > > > On 08/20/08 11:25, Ted Mittelstaedt wrote: > > > Am I correct in assuming that this proposal presumes that legacy > > > holders who have NOT signed an RSA will not be permitted to modify > > > their whois data, unless they have gone through this > > "authentication > > > process"? > > > > Yes, if the "Whois Integrity Policy" and the policy are adopted. > > > > > I wasn't aware that legacy holders, today, are not > > permitted to update > > > their whois data with ARIN unless they have signed a Legacy > > RSA. Is > > > that true? > > > > It is not currently true. It *appears* that it would be made true if > > the "Whois Integrity Policy" were adopted. > > > > > I am not happy with the verbage: > > > > > > "...This proposal assumes the existence of some form of > > > policy such as that proposed by the "Whois Integrity > > Policy Proposal..." > > > > Are you not happy with the verbiage or are you not happy with the > > assumption itself? > > > > The assumption. > > > > The proposer is asking that we consider a "meta" policy > > proposal, that > > > is, a proposal that applies to a proposal under consideration. I > > > disagree with this. > > > > I wouldn't call it a meta proposal, but your general > > impression is correct. > > > > > I would prefer the proposer of this proposal should instead > > work with > > > the authors of the current proposals under consideration, > > such as the > > > "Whois Integrity Policy Proposal" to incorporate his ideas into the > > > existing proposals, rather than submitting a meta-proposal. Or if > > > those authors refuse to do that, then he can submit a competing > > > proposal that does the same thing that an existing proposal > > does, plus > > > his modifications. > > > > The proposal was submitted in order to express language that > > would allow > > me, and perhaps others, to support Heather's proposal. I'd actually > > argue that the proposals be combined, but I don't know > > Heather's view on > > this and do not wish to speak for her. (She has not yet responded to > > the thread on her proposal, so I don't know if she's aware of the > > comments.) If Heather wants to take language from my proposal and > > incorporate it into hers, then I'll happily withdraw my proposal. > > > > I think you should have taken Heathers proposal, add your ideas, and > submitted > it as a competing proposal to Heathers. > > > The intent of my proposal was to give the AC additional language that > > would make a general whois integrity proposal more palatable > > for legacy > > holders who are trying to work out issues with their GCs and > > the LRSA. > > I know. The problem here is that one of the main reasons for > signing the LRSA is to get whois integrity. Keep in mind that > the ARIN community did not give up the right to go after legacy numbering > that non-LRSA legacy signatories hold, after the termination of > the availability of the LRSA next year. > > In short, the LRSA is a defence by legacy holders that the community > isn't going to come after their holdings. Your and Heather's proposals > basically take away the reason a legacy holder has to sign the LRSA in > the first place. > > The LRSA availability sunsets next year. I would vote to oppose any > attempt to extend it's availability after the availability sunsets. As > a fee-paying member I would prefer at that time to see ARIN go after the > legacy > holders who aren't under LRSA and take away IPv4 that they are not using > or advertising. By then the Legacy holders who haven't signed the LRSA > will have had enough time to look at the LRSA to sign it and there is > no point in holding out that particular carrot any more. So the LRSA "carrot" seems to be "We won't hit you with this stick". Sounds like the Piranha Brothers to me. > > Ted > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From bicknell at ufp.org Wed Aug 20 17:49:45 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 20 Aug 2008 17:49:45 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: References: <20080820200245.GA59630@ussenterprise.ufp.org> Message-ID: <20080820214944.GA68125@ussenterprise.ufp.org> In a message written on Wed, Aug 20, 2008 at 01:27:35PM -0700, Ted Mittelstaedt wrote: > Seriously, why doesen't ARIN have an employee that has this > assigned to them as their full time job - the finding and > returning to the address pool of fallow legacy assignments. While I'm not above likely the idea of returning the blocks to the free pool, the sad truth is many of these blocks are in active use and simply no one has ever updated whois. I believe staff expends a ton of effort tracking this down /when they need to/, but thus far have not expended the effort to just do it for all "because they can". Page 24 of my presentation in St Louis: http://www.arin.net/meetings/minutes/ARIN_XVIII/PDF/thursday/WHOIS_Bicknell.pdf 70 POC records have UUCP e-mail addresses. 69 POC records have BITNET e-mail addresses. I looked at the time, all were on "legacy" records. The 5 I spot checked were all still in use. In all probability, that's 139 legacy networks that don't even have a valid e-mail address. On page 16 we see that a full 10% of /all POC's in the database/ were last updated /before ARIN existed/! That's over 17,000 individual entries that really should be verified. Even if it took only 5 minutes to make a phone call or send and e-mail, read the reply and check the record that's still a half a man-year just to do the basic checks. If only 5% then needed an hour of work to track down the holder that's another 4+ man YEARS of work. If we really wanted ARIN to go back and verify all of these old entires I could see them adding 3-4 staff and the process taking 2-3 years. Who's going to pay for that? The good people who've been paying their bill every year for the last 10 years providing free service to all the people who can't even keep a valid e-mail on file? -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From tedm at ipinc.net Wed Aug 20 18:01:50 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 20 Aug 2008 15:01:50 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <20080820214944.GA68125@ussenterprise.ufp.org> Message-ID: <45CCCC621955471A92E7A88287CFC675@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Leo Bicknell > Sent: Wednesday, August 20, 2008 2:50 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Whois Integrity > Policy Proposal > > >On page 16 we see that a full 10% of /all POC's in the database/ were last updated /before ARIN >existed/! That's over 17,000 individual entries that really should be verified. Even if it took >only 5 minutes to make a phone call or send and e-mail, read the reply and check the record that's >still a half a man-year just to do the basic checks. If only 5% then needed an hour of work to track >down the holder that's another 4+ man YEARS of work. I just finished sending a policy proposal in defining this very process. Hopefully in a few days we will see it and people will feel there is some merit. A very light grooming can be automated and ARIN should be able to be trusted to use discretion to attempt verification of the larger blocks. >If we really wanted ARIN to go back and verify all of these old entires I could see them adding 3-4 >staff and the process taking 2-3 years. Who's going to pay for that? The good people who've been >paying their bill every year for the last 10 years providing free service to all the people who can't >even keep a valid e-mail on file? We either pay for it this way or we pay for it by cleaning up messes caused by criminals hijacking blocks. Which do you prefer? Ted From bicknell at ufp.org Wed Aug 20 18:06:29 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 20 Aug 2008 18:06:29 -0400 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: <1080820172429.27224A-100000@Ives.egh.com> References: <1080820172429.27224A-100000@Ives.egh.com> Message-ID: <20080820220629.GA69278@ussenterprise.ufp.org> In a message written on Wed, Aug 20, 2008 at 05:28:27PM -0400, John Santos wrote: > So the LRSA "carrot" seems to be "We won't hit you with this stick". > Sounds like the Piranha Brothers to me. There is no carrot for the resource holder. Society sets up rules that are good for all. We register cars, land, people, stocks, and all sorts of other stuff so society as a whole can take stock, determine rights, privileges and/or ownership. If you could avoid the cost, time, and hassle of doing any of the above you would. Don't have to renew your license plates every year, excellent! Don't have to send in any ARIN paperwork, bonus! However, you should be peeved when someone else gets to opt out of the system you use. When someone does a hit and run on your car, and you find they have no license plate to write down as they drive away you want them to be punished for not having properly registered their car. When someone sends you a 5G DOS attack you want network contacts so you can make it stop. This is far from a new problem. This is no different than a town suffering from the tragedy of the commons developing rules for who could graze and when, but then only applying them to half the towns people. It's no surprise the other half of the towns people like to be able to graze whenever they want, and even in some cases openly mock the townspeople who are trying to keep their animals off the commons. However, the end result is still a bare commons, and all of the animals die. That can happen here; when IPv4 runs out the motivation to hijack a legacy block will increase exponentially. Legacy holders may find themselves being hijacked at faster and faster rates. I have no doubt they will then come back to ARIN looking for a solution, and I fear the solution will be to abandon the IPv4 field as barren and destitute. I suspect the half of the towns people who set decent rules and tried to preserve the commons will be relatively unsympathetic at that point in time that those who have avoided participating in society and openly mocked them are now receiving their just rewards. There is no carrot for the individual. There is a need for the greater good. Unfortunately this is only enforced by sticks. Any carrot offered is only furthering a privileged class and codifying its nature. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From JOHN at egh.com Wed Aug 20 18:16:09 2008 From: JOHN at egh.com (John Santos) Date: Wed, 20 Aug 2008 18:16:09 -0400 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: <20080820220629.GA69278@ussenterprise.ufp.org> Message-ID: <1080820181257.27224A-201000@Ives.egh.com> So don't call it a carrot! (Not you Leo, you seem to be honestly refering to it as a stick, but others have explicitly refered to it as a carrot, when in fact it is just a offer to temporarily refrain from hitting us (legacy holders) with a stick.) -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 -------------- next part -------------- In a message written on Wed, Aug 20, 2008 at 05:28:27PM -0400, John Santos wrote: > So the LRSA "carrot" seems to be "We won't hit you with this stick". > Sounds like the Piranha Brothers to me. There is no carrot for the resource holder. Society sets up rules that are good for all. We register cars, land, people, stocks, and all sorts of other stuff so society as a whole can take stock, determine rights, privileges and/or ownership. If you could avoid the cost, time, and hassle of doing any of the above you would. Don't have to renew your license plates every year, excellent! Don't have to send in any ARIN paperwork, bonus! However, you should be peeved when someone else gets to opt out of the system you use. When someone does a hit and run on your car, and you find they have no license plate to write down as they drive away you want them to be punished for not having properly registered their car. When someone sends you a 5G DOS attack you want network contacts so you can make it stop. This is far from a new problem. This is no different than a town suffering from the tragedy of the commons developing rules for who could graze and when, but then only applying them to half the towns people. It's no surprise the other half of the towns people like to be able to graze whenever they want, and even in some cases openly mock the townspeople who are trying to keep their animals off the commons. However, the end result is still a bare commons, and all of the animals die. That can happen here; when IPv4 runs out the motivation to hijack a legacy block will increase exponentially. Legacy holders may find themselves being hijacked at faster and faster rates. I have no doubt they will then come back to ARIN looking for a solution, and I fear the solution will be to abandon the IPv4 field as barren and destitute. I suspect the half of the towns people who set decent rules and tried to preserve the commons will be relatively unsympathetic at that point in time that those who have avoided participating in society and openly mocked them are now receiving their just rewards. There is no carrot for the individual. There is a need for the greater good. Unfortunately this is only enforced by sticks. Any carrot offered is only furthering a privileged class and codifying its nature. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From bicknell at ufp.org Wed Aug 20 18:24:38 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 20 Aug 2008 18:24:38 -0400 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: <1080820181257.27224A-201000@Ives.egh.com> References: <20080820220629.GA69278@ussenterprise.ufp.org> <1080820181257.27224A-201000@Ives.egh.com> Message-ID: <20080820222438.GA70867@ussenterprise.ufp.org> In a message written on Wed, Aug 20, 2008 at 06:16:09PM -0400, John Santos wrote: > So don't call it a carrot! > > (Not you Leo, you seem to be honestly refering to it as a stick, but > others have explicitly refered to it as a carrot, when in fact it is > just a offer to temporarily refrain from hitting us (legacy holders) > with a stick.) I believe the current LRSA might be more accurately fall under an "amnesty provision". Rather than go out with sticks swinging the community looked to see if there was some way they could reduce the fear of coming into compliance. Just like someone who found a gun in a house they bought the previous owner left, they might not know how to dispose of it, or if they can leagally turn it in at a police station without being arrested. Legacy holders didn't know if they came into the ARIN fold if they might immediately have their block taken away from them because they didn't meet current standards. Policy proposals like 2007-17, legacy outreach and partial reclamation have been further attempts to make the process easier and less frightening. So I don't view the LRSA as a carrot or a stick. I view it as a way to reassure people that coming into the fold is not something to fear. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From Lee.Howard at stanleyassociates.com Wed Aug 20 18:34:41 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 20 Aug 2008 18:34:41 -0400 Subject: [arin-ppml] Legacy RSA (was: Whois Integrity Policy Proposal) In-Reply-To: <3c3e3fca0808201241k77c1f45do506deb38e5f55719@mail.gmail.com> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40AFE734E@CL-S-EX-1.stanleyassociates.com> Bill Herrin said: > An "evil" ARIN eh? Hmm, let's see... I know, it's a contradiction in terms. But compare to what an evil legacy holder could do! > 4.d.ii. You host a whistleblower site on the IP addresses > through which classified information is leaked. Having broken > the law in a manner associated with the IP addresses, an evil > ARIN is permitted to cancel your registration, at which point > the IP addresses revert to ARIN's control. I see your point that that would be aggressive application of the clause, but really. . . you broke the law, you don't have my sympathy. > 6.b. An evil ARIN could reinterpret 6b. Means 1 or 2, not 1 and 2. > Since it's 2013 and all end-user maintenance fees have > increased to $50k/year (the money redistributed to help the > poor backbones cope with the IPv4 route explosion in the wake > of IPv6's failure) that includes the legacy maintenance fee. > Now the onus is on the registrant to successfully bring > action under 14.c, which requires him to attend 15.l. > arbitration in Washington DC. And then having gone to that > time and expense, he has to actually convince the arbitrator > that 6b really does require ARIN to meet BOTH criteria 1 and 2. It says "and." That's pretty clear: After 2013, ARIN, by vote of ARIN's Board, may annually increase the Legacy Fee by no more than (1) the amount charged non-Legacy holders for this maintenance service; and (2) no increase per year greater than $25. That would indeed be a pretty evil bunch of Trustees, elected by a pretty evil bunch of members, to try redefining "and" to mean "or", knowing that they would lose in arbitration. The intent of this clause is pretty clearly to limit the amount ARIN can hit you for. > 14.a. An evil ARIN could simply give 30 days' notice to the Huh. That's a scenario I hadn't considered. Thanks. > Want another? I can keep going for a while. I'll refer you to ARIN's counsel below, but so far I think it's a draw. > > My experience is such that > > I trust ARIN more than some people, so I have a paucity of > > imagination. > > The courts are full of good, trustworthy people suing each > other over broken promises. Stuff happens. Priorities change. > Even with the best intentions, perceptions of "fair" drift apart. > > A good system is resilient in the face of that drift. Absolutely. But people keep saying this contract offers no protection, so I hope to understand others' perceptions better. > > Extra points if you suggest terms of enforcement. > > Have termination for any cause other than non-communication, > non-payment or unlawful action specifically against ARIN to > cause control of the addresses to revert to the current > status quo, similar to the results of having successfully > completed 14.c. One of the benefits to the community is that legacy resource holders agree to follow the same policies as everyone else, except that ARIN will continue to provide service for numbers as described in 10(b). If legacy holders can terminate the contract because they don't agree with community consensus, but still keep the addresses, that benefit is lost. E.G., what if a transfer policy allowing deaggregation to /22 were passed, but you (a signatory to the LRSA) heard a rumor that somebody would pay good money for /32s? > Also, 14c and 14f are in conflict. The number resources can't > resume the status they had prior to the legacy agreement if > questionable sections (like 9) survive the contract's > termination. In an ordinary contract of adhesion like this, > the ambiguity would be resolved against the drafter (ARIN). > The LRSA specifically excludes that in 15i. You're right, parts of the agreement survive termination. I do think that if you have any question about section 9, your lawyer should discuss it with ARIN's lawyer before signing the LRSA, so that the terms are clear. The Legacy RSA FAQ has the contact information for ARIN's General Counsel: http://www.arin.net/registration/legacy/index.html Let me be clear that I am not speaking on behalf of ARIN; I do believe the LRSA is an olive branch extended for legacy resource holders, and I think its terms are reasonable. However, if I misunderstand a clause or misrepresent ARIN or the document, it's because I'm ignorant and didn't ask my lawyer. Lee From michael at rancid.berkeley.edu Wed Aug 20 19:19:32 2008 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Wed, 20 Aug 2008 16:19:32 -0700 Subject: [arin-ppml] LRSA concerns (Re: Policy Proposal: Whois Integrity Policy Proposal) In-Reply-To: <1698.1219180000@nsa.vix.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> Message-ID: <48ACA684.2090208@rancid.berkeley.edu> On 08/19/08 14:06, Paul Vixie wrote: >> ... I can't speak authoritatively, but I have heard that there are >> institutions who are being advised not to sign the legacy RSA because of >> various provisions in the contract. > > no doubt the people offering this hearsay advice are acting on hearsay advice. > >> ... I have also heard that said counsels are more concerned with some of >> the provisions in the LRSA than they are regarding the uncertainty of the >> status of their legacy resources. ... > > i'd like PPML to hear from those counsels directly, or to hear their words, > literally. This did jog my memory, and I was able to find the words of a GC that were posted to a public (and googlable) forum: http://listserv.educause.edu/cgi-bin/wa.exe?A2=ind0804&L=security&P=5103 Keep in mind that The Citadel is a state-supported college and that these words are not mine and they are not the words of the poster--they do appear to be direct from the GC. I hope this adds to the discussion. I am sure that I share a commonality with many on this list in saying IANAL. michael From vixie at isc.org Wed Aug 20 20:14:21 2008 From: vixie at isc.org (Paul Vixie) Date: Thu, 21 Aug 2008 00:14:21 +0000 Subject: [arin-ppml] Apple's secret "Back to My Mac" push behind IPv6 (appleinsider.com) Message-ID: <88347.1219277661@nsa.vix.com> http://www.appleinsider.com/articles/08/08/19/apples_secret_back_to_my_mac_push_behind_ipv6.html -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From bill at herrin.us Wed Aug 20 20:26:31 2008 From: bill at herrin.us (William Herrin) Date: Wed, 20 Aug 2008 20:26:31 -0400 Subject: [arin-ppml] LRSA concerns (Re: Policy Proposal: Whois Integrity Policy Proposal) In-Reply-To: <48ACA684.2090208@rancid.berkeley.edu> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> <48ACA684.2090208@rancid.berkeley.edu> Message-ID: <3c3e3fca0808201726l7e021ffakb53df5eedac8acbb@mail.gmail.com> On Wed, Aug 20, 2008 at 7:19 PM, Michael Sinatra wrote: > http://listserv.educause.edu/cgi-bin/wa.exe?A2=ind0804&L=security&P=5103 > " Their description of force majeure is a bit broad. I would > exclude "riots, failure of contractors or subcontractors to perform, > labor strike, lockout, boycott, or acts of governmental authorities." I > just don't see them as "acts of God." " Sweet. I completely missed that one. Under LRSA 15.k., an "evil" ARIN could contract the whois operation to someone incompetent, fail to perform it successfully for 30 days, and based on that failure opt to terminate all LRSA agreements immediately. Since the termination is outside the scope of 14.c., the addresses revert to ARIN per 14.e. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tedm at ipinc.net Wed Aug 20 20:48:19 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 20 Aug 2008 17:48:19 -0700 Subject: [arin-ppml] Apple's secret "Back to My Mac" push behind IPv6(appleinsider.com) In-Reply-To: <88347.1219277661@nsa.vix.com> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Paul Vixie > Sent: Wednesday, August 20, 2008 5:14 PM > To: ppml at arin.net > Subject: [arin-ppml] Apple's secret "Back to My Mac" push > behind IPv6(appleinsider.com) > > > http://www.appleinsider.com/articles/08/08/19/apples_secret_ba > ck_to_my_mac_push_behind_ipv6.html > Good. A much-needed intro to IPv6 for the Apple die-hards. At least, the first half of the article was. The last half was full of shameless plugging of Apple products, wrapped in the typical myopia of all-the-worlds-a-mac, though. Although I guess you have to have that, to force-feed the educational bit. Ted From vixie at isc.org Wed Aug 20 21:38:04 2008 From: vixie at isc.org (Paul Vixie) Date: Thu, 21 Aug 2008 01:38:04 +0000 Subject: [arin-ppml] LRSA concerns (Re: Policy Proposal: Whois Integrity Policy Proposal) In-Reply-To: Your message of "Wed, 20 Aug 2008 20:26:31 -0400." <3c3e3fca0808201726l7e021ffakb53df5eedac8acbb@mail.gmail.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> <48ACA684.2090208@rancid.berkeley.edu> <3c3e3fca0808201726l7e021ffakb53df5eedac8acbb@mail.gmail.com> Message-ID: <99772.1219282684@nsa.vix.com> > > http://listserv.educause.edu/cgi-bin/wa.exe?A2=ind0804&L=security&P=5103 > > Sweet. I completely missed that one. > > Under LRSA 15.k., an "evil" ARIN could contract the whois operation to > someone incompetent, fail to perform it successfully for 30 days, and > based on that failure opt to terminate all LRSA agreements > immediately. Since the termination is outside the scope of 14.c., the > addresses revert to ARIN per 14.e. what's your proposed fix? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owen at delong.com Wed Aug 20 20:21:23 2008 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Aug 2008 17:21:23 -0700 Subject: [arin-ppml] LRSA concerns (Re: Policy Proposal: Whois Integrity Policy Proposal) In-Reply-To: <48ACA684.2090208@rancid.berkeley.edu> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> <48ACA684.2090208@rancid.berkeley.edu> Message-ID: Some of this attorney's comments may be fair criticism. IANAL, so, I'm not sure about the issues in question. I do note, however, that some comments show some misunderstanding of the ARIN process and who/what ARIN is... To wit: > Section 7 Current and Future Policies > > This is another of the incredibly one-sided sections. ARIN has > "the sole and absolute discretion (to) amend the Poilicies," which > amendments become binding on us immediately upon publication on the > website. At the least, they could send us an e-mail of changes in > policies. I get notifications regularly from 401(k) and SEP account > companies. Why can't they do the same? If anyone affected by this chooses to subscribe to PPML, arin-discuss, or the ARIN notification email list, they will receive such notification. However, ARIN doesn't require the signatories to subscribe to such notifications if they do not want to. It is impossible for an ARIN policy to change without notice if the entity in question chooses to avail themselves of the information. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From geneb at deltasoft.com Wed Aug 20 22:13:42 2008 From: geneb at deltasoft.com (Gene Buckle) Date: Wed, 20 Aug 2008 19:13:42 -0700 (PDT) Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: <20080820222438.GA70867@ussenterprise.ufp.org> References: <20080820220629.GA69278@ussenterprise.ufp.org> <1080820181257.27224A-201000@Ives.egh.com> <20080820222438.GA70867@ussenterprise.ufp.org> Message-ID: > So I don't view the LRSA as a carrot or a stick. I view it as a > way to reassure people that coming into the fold is not something > to fear. > That may be the case, but it still scares the snot out of me. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. From bill at herrin.us Wed Aug 20 23:13:38 2008 From: bill at herrin.us (William Herrin) Date: Wed, 20 Aug 2008 23:13:38 -0400 Subject: [arin-ppml] LRSA concerns (Re: Policy Proposal: Whois Integrity Policy Proposal) In-Reply-To: <99772.1219282684@nsa.vix.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> <48ACA684.2090208@rancid.berkeley.edu> <3c3e3fca0808201726l7e021ffakb53df5eedac8acbb@mail.gmail.com> <99772.1219282684@nsa.vix.com> Message-ID: <3c3e3fca0808202013n65bf8bc8tae50417451e629f6@mail.gmail.com> On Wed, Aug 20, 2008 at 9:38 PM, Paul Vixie wrote: >> > http://listserv.educause.edu/cgi-bin/wa.exe?A2=ind0804&L=security&P=5103 >> >> Sweet. I completely missed that one. >> >> Under LRSA 15.k., an "evil" ARIN could contract the whois operation to >> someone incompetent, fail to perform it successfully for 30 days, and >> based on that failure opt to terminate all LRSA agreements >> immediately. Since the termination is outside the scope of 14.c., the >> addresses revert to ARIN per 14.e. > > what's your proposed fix? The contract termination process is the linchpin. Fix that part so that the registrant holds the power and all the other problems are academic. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From heather.skanks at gmail.com Thu Aug 21 00:36:52 2008 From: heather.skanks at gmail.com (heather skanks) Date: Thu, 21 Aug 2008 00:36:52 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <48A9897D.50209@arin.net> References: <48A9897D.50209@arin.net> Message-ID: <616812070808202136x4c90595cy773bc476374bdf0f@mail.gmail.com> My intention really is the integrity of whois data. As an Internet service provider that is part of the larger internet community, we want to know that the records are accurate. We depend on these records, and the actions we take based on them can affect the community. We'd like to avoid helping someone use something they aren't authorized to, but that is made difficult if we can not trust old records. I truly believe a policy like this, is one step toward making it more difficult to steal netblocks. One step.. I didn't say it was the absolute, or the end all way the prevent theft, just that it raises the bar. I considered proposing the same policy that was adopted in the APNIC region. The APNIC policy goes a step further and locked all "legacy" resource records at once. I intended the text I proposed as a compromise, to ease into the process by requiring L/RSA when you went to update a record. I am beginning to think that was a mistake, and in order for this to work that the policy should lock all legacy records or remove them altogether. I concede there are larger issues, ultimately ARIN is providing a service to entities with which it has no formal arangement or agreement. You can argue the merits or demerits of the RSA and LRSA, but they are not relevent to the text or intent of this policy. (If you would like to argue the points of the L/RSA, I encourage you to do so with ARIN staff and legal counsel, as the policy development process has no mechanism to change either!) The RSA and LRSA are the only mechanisms I know of for having a formal arrangement with ARIN. If there are other arrangements, or the possibility of others in the future, the text can be modified to take that into account: "To ensure the integrity of information in the ARIN WHOIS Database a resource must be under an RSA (either legacy or traditional) or other [formal/documented legal/contract/agreement] with ARIN, in order to update the WHOIS record." I went through all of the emails.. I pulled out a few points/questions to address: > Which is it, the resource must be under an RSA, or the holder must be > able to prove their right to the resource? These are not the same > thing The LRSA contains a procedure for evaluating a legacy applicant's request to sign the LRSA (See Section 3 of the LRSA). . > I do not think that this is an effort to make life difficult for legacy holders (including my employer), but to > prevent the theft of their address space. Heather, can you clarify? (Seems that Verizon Business was > involved in one to the cases I mentioned...not as a hijacker, of course.) It is not my intention to make anyone's life difficult - in fact quite the opposite. I would like to make everyone more at ease and comfortable with the records in the whois database. I cringe when I see route change requests for old netblocks that have not been updated. I would love to see a technical solution implemented- such a solution would still have this underlying problem. I don't know what incident the poster was referring to wrt VZB - but as I previously mentioned, we are concerned about this, we do not want to be an accessory to a hijacking. Two recent and public incidents, (that did not involve VZB in any way) were covered in this article: http://voices.washingtonpost.com/securityfix/2008/04/a_case_of_network_identity_the_1.html > If you really want to reduce spam, go after those people and leave the legacy holders alone who AREN'T > spamming but just happen to have not signed an RSA. Reduction of spam is not my primary goal, I'm not even sure I see the correlation. Most providers can tell which of their customers is routing a netblock and can work their customer support contacts for spam - besides most spam is sourced from legit but compromised hosts these days. --Heather On Mon, Aug 18, 2008 at 10:38 AM, Member Services wrote: > ARIN received the following policy proposal. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal at their next > regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as written. If the AC accepts the proposal, > it will be posted as a formal policy proposal to PPML and it will be > presented at a Public Policy Meeting. > > 2. Not accept the proposal. If the AC does not accept the proposal, > the AC will explain their decision via the PPML. If a proposal is not > accepted, 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 proposal will be closed. > > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > Policy Proposal Name: Whois Integrity Policy Proposal > > Author: Heather Schiller > > Proposal Version: 1 > > Submission Date: August 15, 2008 > > Policy statement: > > To ensure the integrity of information in the ARIN WHOIS Database a > resource must be under an RSA (either legacy or traditional) in order to > update the WHOIS record. ARIN will not update historical information in > the ARIN Whois Database until the resource holder can prove the > organization's right to the resource. > > > Rationale: > > ARIN currently maintains WHOIS and in-addr.arpa delegation records in a > best-effort fashion. In many cases ARIN does not have a formal > agreement with the legacy resource holders. Legacy records are > frequently out of date and have become an increasingly popular target > for hijackers. Having up to date contact information and a formal > relationship with legacy record holders would assist ARIN and ISP's in > ensuring these records are maintained accurately. A similar policy was > successfully adopted in the APNIC region. > (http://www.apnic.net/policy/proposals/prop-018-v001.html) > > Timetable for implementation: > > Within sixty (60) days of approval - with notification to current POC > email addresses listed on historical assignments, or as soon as > reasonable for ARIN staff. > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From heather.skanks at gmail.com Thu Aug 21 00:51:09 2008 From: heather.skanks at gmail.com (heather skanks) Date: Thu, 21 Aug 2008 00:51:09 -0400 Subject: [arin-ppml] Legacy RSA (was: Whois Integrity Policy Proposal) In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40AFE734E@CL-S-EX-1.stanleyassociates.com> References: <3c3e3fca0808201241k77c1f45do506deb38e5f55719@mail.gmail.com> <369EB04A0951824ABE7D8BAC67AF9BB40AFE734E@CL-S-EX-1.stanleyassociates.com> Message-ID: <616812070808202151p5605ef5dt193e3cca32075c13@mail.gmail.com> On Wed, Aug 20, 2008 at 6:34 PM, Howard, W. Lee < Lee.Howard at stanleyassociates.com> wrote: > Bill Herrin said: > > An "evil" ARIN eh? Hmm, let's see... > > I know, it's a contradiction in terms. > But compare to what an evil legacy holder could do! > > > 4.d.ii. You host a whistleblower site on the IP addresses > > through which classified information is leaked. Having broken > > the law in a manner associated with the IP addresses, an evil > > ARIN is permitted to cancel your registration, at which point > > the IP addresses revert to ARIN's control. > > I see your point that that would be aggressive application of the > clause, but really. . . you broke the law, you don't have my > sympathy. > > I believe Bill Herrin's example has to do with content - and it appears there is a seperate section in the LRSA about that. My guess is "Evil ARIN" couldn't have it both ways.. revoking you for content and disavowing control over content? 4.e: Content Control. Legacy Applicant acknowledges that content transmitted over the Internet occurs in real time. Accordingly, ARIN does not have the ability to control content accessible through or facilitated by those who receive number resources, directly or indirectly, from ARIN. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arin-ppml at westbrook.com Thu Aug 21 01:24:01 2008 From: arin-ppml at westbrook.com (Eric Westbrook) Date: Thu, 21 Aug 2008 13:24:01 +0800 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <616812070808202136x4c90595cy773bc476374bdf0f@mail.gmail.com> References: <48A9897D.50209@arin.net> <616812070808202136x4c90595cy773bc476374bdf0f@mail.gmail.com> Message-ID: <6905ba860808202224g3878609fie59949864d7f1436@mail.gmail.com> Heather, Thanks so much for your clarification of intent. I want to apologize to you publicly, because I do think I came off in this thread as a bit presumptious about your intent in this proposal without having spoken to you directly. I meant no such implication toward you; my intended point was that *if* the measure was really intended to achieve legacy assimilation as a deceptive side-effect, or if anyone supported it exclusively for that outcome, that such action would be disingenuous. I stand by my analysis and recommendation that the mechanism proposed does not achieve the stated goals. Clearly, improving whois integrity and authenticity of updates could hardly be called a bad thing. But I've seen no compelling argument that an RSA, in itself, does anything toward that particular goal; at least not anything that other mechanisms can't do more directly or simply. Reducing fraud and spam is a lofty and virtuous goal that I think most (if not all) of us would readily enjoin. Personally, however, I think getting legacy holders under contract is more of a business imperative than a technical problem-solver. Candidly, in my opinion, any legacy holder that isn't a little worried about what will happen at or near the inevitable exhaustion inflection point (the ipv6 singularity?) is probably either incompetent or ignorant. I also don't dispute that LRSA assimilation has potential value to the community as an objective (in fact, as a non-RSA legacy holder, I am currently wringing my own hands over it in a vigorous internal self-debate); in this thread I only intend to assert that it doesn't solve this specific problem and therefore doesn't warrant this specific action. Thanks, and again, my apologizes if I offended you with any unintended implication. Best regards, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From heather.skanks at gmail.com Thu Aug 21 01:30:31 2008 From: heather.skanks at gmail.com (heather skanks) Date: Thu, 21 Aug 2008 01:30:31 -0400 Subject: [arin-ppml] Whois Integrity Policy Proposal -- What is proof and how big is the problem? In-Reply-To: References: Message-ID: <616812070808202230u757e004dnb7f4d463c3c8b883@mail.gmail.com> On Mon, Aug 18, 2008 at 10:50 AM, Keith W. Hare wrote: > The Whois Integrity Policy Proposal says: > > ARIN will not update historical information in > the ARIN Whois Database until the resource holder > can prove the organization's right to the resource. > > What documentation will be required for an organization to prove their > right to a resource? > Section 3 of the LRSA provides a process for evaluating a request: 3. EVALUATION AND ACCEPTANCE Following Legacy Applicant's completion of the online application process, ARIN will promptly evaluate Legacy Applicant's request for the Services. Evaluation may require Legacy Applicant's submission of additional documentation to support its application such as, but not limited to, state registration, Dun & Bradstreet and/or taxpayer information, and/or registration under the province or country in which the entity is registered for verification purposes. If ARIN, in its sole and exclusive discretion, applying its published Policies and internal verification process, determines that it can provide the Services to Legacy Applicant, ARIN shall provide written notice to Legacy Applicant of its willingness to do so, and ARIN will promptly commence providing the Services to Legacy Applicant in accordance with the terms and conditions of this Legacy Agreement. If ARIN, in its sole and exclusive discretion, applying its published Policies and internal verification process, determines that it cannot provide the Services, it will provide written notice to Legacy Applicant of its decision. > > The APNIC proposal provided some statistics about how many organizations > might be affected by their proposal. Are there any counts available for > ARIN? > Roughly.. 1213 netblock records with "last modified" year of 1991 2654 netblock records with "last modified" year of 1992 6030 netblock records with "last modified" year of 1993 4641 netblock records with "last modified" year of 1994 7407 netblock records with "last modified" year of 1995 6038 netblock records with "last modified" year of 1996 162 ASN records with "last modified" year of 1991 72 ASN records with "last modified" year of 1992 122 ASN records with "last modified" year of 1993 321 ASN records with "last modified" year of 1994 411 ASN records with "last modified" year of 1995 624 ASN records with "last modified" year of 1996 912 ORG records with "last modified" year of 1991 1514 ORG records with "last modified" year of 1992 4452 ORG records with "last modified" year of 1993 3500 ORG records with "last modified" year of 1994 4917 ORG records with "last modified" year of 1995 3746 ORG records with "last modified" year of 1996 > > Keith > > ______________________________________________________________ > > Keith W. Hare JCC Consulting, Inc. > keith at jcc.com 600 Newark Road > Phone: 740-587-0157 P.O. Box 381 > Fax: 740-587-0163 Granville, Ohio 43023 > http://www.jcc.com USA > ______________________________________________________________ > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Thu Aug 21 02:01:07 2008 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 21 Aug 2008 02:01:07 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <34567.1219192974@nsa.vix.com> References: <20080819172716.2FFF74501A@ptavv.es.net><867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com><86skt0ltqu.fsf@seastrom.com> <48AB17DD.6020009@psg.com><86d4k4ltd9.fsf@seastrom.com><3c3e3fca0808191612x5d84942dyb935b30e1c673aaf@mail.gmail.com> <34567.1219192974@nsa.vix.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0E2B8@SUEXCL-02.ad.syr.edu> > i do personally hold either the "thing 1" or the "thing 2" view, and so to > me, uniqueness against competing allocations or merely against competing > utilization (perhaps by stronger or larger parties elsewhere in the world) > is a community-level right -- we all have it because the community agrees > that we all have it. i don't distinguish in my mind between the rights i > have to legacy space vs. non-legacy space, because all of those rights are > whatever the community agrees to protect, and while various individuals > have > begged differential relief in this area, i've seen no consensus for it. > Paul One can make a good case for a unified, consistent address governance regime that would involve eliminating legacy holder's special rights and bringing everyone in under the same kind of contract. But one cannot make the case you want to make based on appeals to "the community" and "consensus." Because the legacy holders are part of "the community." A big part of it, in North America. And I suspect that they will never agree to be part of a "consensus" that eliminates their special status. We have a lot of experience now with "legacy" holders of domain name resources, notably the ccTLDs. And it has been interesting to watch -- without expressing any positive or negative judgment -- how much the regime had to adapt to their special interests and demands. To put it another way, there is no "community," there are different groups of actors with different interests. A political ethic that attempts to resolve global, Internet-wide conflicts over rights by appealing to the norms of a small-scale, homogeneous community is unlikely to provide stable guidelines. I hope people are able to move beyond this communitarianism over the next few years; the "Internet as community" model may have existed 20 years ago but does not today. It would be better to base policies on the overall social effects of various policy decisions, using more scientific and well-understood standards such as economic efficiency, technical efficiency, and abstract concepts of justice and fairness. There are lots and lots of people around the world who will be affected by IP addressing policies who are not now, and probably never will be part of what you consider to be the "community." Yes, I know this is heresy. ;-) From gtb at slac.stanford.edu Thu Aug 21 01:57:36 2008 From: gtb at slac.stanford.edu (Buhrmaster, Gary) Date: Wed, 20 Aug 2008 22:57:36 -0700 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <616812070808202136x4c90595cy773bc476374bdf0f@mail.gmail.com> References: <48A9897D.50209@arin.net> <616812070808202136x4c90595cy773bc476374bdf0f@mail.gmail.com> Message-ID: > My intention really is the integrity of whois data. As an > Internet service provider that is part of the larger internet > community, we want to know that the records are accurate. We > depend on these records, and the actions we take based on > them can affect the community. We'd like to avoid helping > someone use something they aren't authorized to, but that is > made difficult if we can not trust old records. I truly > believe a policy like this, is one step toward making it more > difficult to steal netblocks. One step.. I didn't say it was > the absolute, or the end all way the prevent theft, just that > it raises the bar. If the goal is accurate whois (and not to force the (L)RSA contract on legacy holders, which is a separate discussion, and I have opinions on both sides of that debate), then I would propose a solution with a much more likely (quick) uptake would be a "LRSA-lite" contract, of which the legacy holders (on their part) agree only that they were previously allocated resources and are responsible for keeping the whois data correct/accurate. Arin would agree to provide the service for those requestors after some appropriate vetting process for holders (for some minor vetting fee), but such contract would not address the potentially contentious issues ("ownership", "stewardship", whatever), which are put off until another day (which will occur at some point). In that case, changes to the whois database would require one of the LRSA, RSA, or LRSA-lite, and accuracy and integrity would (possibly) be improved. From heather.skanks at gmail.com Thu Aug 21 02:18:27 2008 From: heather.skanks at gmail.com (heather skanks) Date: Thu, 21 Aug 2008 02:18:27 -0400 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: <1080820181257.27224A-201000@Ives.egh.com> References: <20080820220629.GA69278@ussenterprise.ufp.org> <1080820181257.27224A-201000@Ives.egh.com> Message-ID: <616812070808202318i4a597e92p39e7aeba120a14f9@mail.gmail.com> On Wed, Aug 20, 2008 at 6:16 PM, John Santos wrote: > > So don't call it a carrot! > (break out your philosophy textbooks, fire up wikipedia) So let's call it a "social contract" or "social compact" I believe that is basically what Leo is describing .. and he seems to have found a good analogy. > > (Not you Leo, you seem to be honestly refering to it as a stick, but > others have explicitly refered to it as a carrot, when in fact it is > just a offer to temporarily refrain from hitting us (legacy holders) > with a stick.) > > > -- > John Santos > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 > > In a message written on Wed, Aug 20, 2008 at 05:28:27PM -0400, John Santos > wrote: > > So the LRSA "carrot" seems to be "We won't hit you with this stick". > > Sounds like the Piranha Brothers to me. > > There is no carrot for the resource holder. > > Society sets up rules that are good for all. We register cars, > land, people, stocks, and all sorts of other stuff so society as a > whole can take stock, determine rights, privileges and/or ownership. > > If you could avoid the cost, time, and hassle of doing any of the > above you would. Don't have to renew your license plates every > year, excellent! Don't have to send in any ARIN paperwork, bonus! > > However, you should be peeved when someone else gets to opt out of > the system you use. When someone does a hit and run on your car, > and you find they have no license plate to write down as they drive > away you want them to be punished for not having properly registered > their car. When someone sends you a 5G DOS attack you want network > contacts so you can make it stop. > > This is far from a new problem. This is no different than a town > suffering from the tragedy of the commons developing rules for who > could graze and when, but then only applying them to half the towns > people. It's no surprise the other half of the towns people like > to be able to graze whenever they want, and even in some cases > openly mock the townspeople who are trying to keep their animals > off the commons. > > However, the end result is still a bare commons, and all of the > animals die. That can happen here; when IPv4 runs out the motivation > to hijack a legacy block will increase exponentially. Legacy holders > may find themselves being hijacked at faster and faster rates. I > have no doubt they will then come back to ARIN looking for a solution, > and I fear the solution will be to abandon the IPv4 field as barren > and destitute. > > I suspect the half of the towns people who set decent rules and > tried to preserve the commons will be relatively unsympathetic at > that point in time that those who have avoided participating in > society and openly mocked them are now receiving their just rewards. > > There is no carrot for the individual. There is a need for the > greater good. Unfortunately this is only enforced by sticks. Any > carrot offered is only furthering a privileged class and codifying > its nature. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Thu Aug 21 06:40:14 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 21 Aug 2008 11:40:14 +0100 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <20080820214944.GA68125@ussenterprise.ufp.org> Message-ID: > 70 POC records have UUCP e-mail addresses. > > 69 POC records have BITNET e-mail addresses. > > I looked at the time, all were on "legacy" records. The 5 I > spot checked were all still in use. In all probability, > that's 139 legacy networks that don't even have a valid > e-mail address. > > On page 16 we see that a full 10% of /all POC's in the > database/ were last updated /before ARIN existed/! That's > over 17,000 individual entries that really should be > verified. Somebody could set up a bogon-style feed listing all such blocks, and then individual networks could block traffic from these blocks if they wish to. The bogon-style feed would need to be updated fairly often, say daily. This may seem harsh, but essentially these networks have opted out of Internet society by not paying their taxes. There may not be an IRS to shut them down, but that doesn't mean that honest tax-paying members of the Internet need to do business with these network operators. Personally, I suspect that if someone sets up this type of feed, it will soon be picked up in the media and we will see a flurry of people updating their contact info. --Michael Dillon From Keith at jcc.com Thu Aug 21 09:10:48 2008 From: Keith at jcc.com (Keith W. Hare) Date: Thu, 21 Aug 2008 09:10:48 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal Message-ID: >This may seem harsh, but essentially these networks have opted >out of Internet society by not paying their taxes. There may >not be an IRS to shut them down, but that doesn't mean that >honest tax-paying members of the Internet need to do business >with these network operators. A year ago, there was not an easy way for an legacy resource holder to even find out how to opt in. The Legacy RSA has only been available since November, 2007. Its still a bit early to claim that the legacy resource holders have opted out by not paying their taxes. Keith ______________________________________________________________ Keith W. Hare JCC Consulting, Inc. keith at jcc.com 600 Newark Road Phone: 740-587-0157 P.O. Box 381 Fax: 740-587-0163 Granville, Ohio 43023 http://www.jcc.com USA ______________________________________________________________ From Keith at jcc.com Thu Aug 21 09:17:36 2008 From: Keith at jcc.com (Keith W. Hare) Date: Thu, 21 Aug 2008 09:17:36 -0400 Subject: [arin-ppml] Whois Integrity Policy Proposal -- What is proof and how big is the problem? Message-ID: <37c742b4f59832d9ff8b10637a25180548ad6adf@jcc.com> Heather, Thanks for the data. However, you left out 1997. Since ARIN didn't officially come into existence until December 22, 1997, most of 1997 is still legacy. Keith _____ From: heather skanks [mailto:heather.skanks at gmail.com] Sent: Thursday, August 21, 2008 1:31 AM To: Keith W. Hare Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Whois Integrity Policy Proposal -- What is proof and how big is the problem? On Mon, Aug 18, 2008 at 10:50 AM, Keith W. Hare wrote: The Whois Integrity Policy Proposal says: ARIN will not update historical information in the ARIN Whois Database until the resource holder can prove the organization's right to the resource. What documentation will be required for an organization to prove their right to a resource? Section 3 of the LRSA provides a process for evaluating a request: 3. EVALUATION AND ACCEPTANCE Following Legacy Applicant's completion of the online application process, ARIN will promptly evaluate Legacy Applicant's request for the Services. Evaluation may require Legacy Applicant's submission of additional documentation to support its application such as, but not limited to, state registration, Dun & Bradstreet and/or taxpayer information, and/or registration under the province or country in which the entity is registered for verification purposes. If ARIN, in its sole and exclusive discretion, applying its published Policies and internal verification process, determines that it can provide the Services to Legacy Applicant, ARIN shall provide written notice to Legacy Applicant of its willingness to do so, and ARIN will promptly commence providing the Services to Legacy Applicant in accordance with the terms and conditions of this Legacy Agreement. If ARIN, in its sole and exclusive discretion, applying its published Policies and internal verification process, determines that it cannot provide the Services, it will provide written notice to Legacy Applicant of its decision. The APNIC proposal provided some statistics about how many organizations might be affected by their proposal. Are there any counts available for ARIN? Roughly.. 1213 netblock records with "last modified" year of 1991 2654 netblock records with "last modified" year of 1992 6030 netblock records with "last modified" year of 1993 4641 netblock records with "last modified" year of 1994 7407 netblock records with "last modified" year of 1995 6038 netblock records with "last modified" year of 1996 162 ASN records with "last modified" year of 1991 72 ASN records with "last modified" year of 1992 122 ASN records with "last modified" year of 1993 321 ASN records with "last modified" year of 1994 411 ASN records with "last modified" year of 1995 624 ASN records with "last modified" year of 1996 912 ORG records with "last modified" year of 1991 1514 ORG records with "last modified" year of 1992 4452 ORG records with "last modified" year of 1993 3500 ORG records with "last modified" year of 1994 4917 ORG records with "last modified" year of 1995 3746 ORG records with "last modified" year of 1996 Keith ______________________________________________________________ Keith W. Hare JCC Consulting, Inc. keith at jcc.com 600 Newark Road Phone: 740-587-0157 P.O. Box 381 Fax: 740-587-0163 Granville, Ohio 43023 http://www.jcc.com USA ______________________________________________________________ _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Thu Aug 21 09:55:59 2008 From: info at arin.net (Member Services) Date: Thu, 21 Aug 2008 09:55:59 -0400 Subject: [arin-ppml] Policy Proposal: whois POC e-mail cleanup Message-ID: <48AD73EF.7010004@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At their following meeting the AC will accept or not accept the proposal. 3. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision via the PPML. If a proposal is not accepted, 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 proposal will be closed. The AC will assign shepherds in the near future. ARIN will provide the names of the shepherds to the community via the PPML. In the meantime, the AC invites everyone to comment on this proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: whois POC e-mail cleanup Author: Ted Mittelstaedt Proposal Version: 1 Submission Date: 8/20/2008 Proposal type: new Policy term: permanent Policy statement: Under Directory Services in the NRPM add section 3.6 titled "Reliability of Whois information" 3.6.1 ARIN will use an automated system that once a year will attempt to e-mail all separate e-mail addresses in the directory. (including abuse addresses) At it's discretion, ARIN will attempt to contact by regular mail or phone all POC entries that have invalid e-mail addresses (i.e. e-mail addresses that bounce mail sent to them) and give them a 3 month deadline for correction of their mail address. The automated system will not use a mail cluster or other mail transmission software that is incompatible with commonly available anti-spam technologies, such as greylisting. LIR POC's that fail to respond to paper mails or telephone calls will have Their e-mail address replaced with "REFUSED RESPONSE" in the directory. Non-legacy POCs will be requested to remedy the situation by their next billing date. At it's discretion and considering the size or number of complaints about an organization, ARIN may require the organization to supply accurate contact information in it's directory entry as a condition of accepting payment from the organization for registration renewals. POCs belonging to blocks reassigned by LIRs who fail to respond will be replaced by the POC of the reassigning LIR. The automated e-mails will have a text string titled "ARIN Automated POC e-mail test" identifying them so that automated trouble ticket systems can be programmed to automatically delete the mail messages instead of replying to them. Other standard mailing list practices will be followed by ARIN to insure the absence of e-mail loops, etc. 3.6.1 ARIN will supply a report to the community, updated monthly, that lists the percentage of "REFUSED RESPONSE" POCs, the percentage of POCs that accept e-mails, and the percentage of POC addresses that have not responded but have not yet been notified by paper mail or telephone. Rationale: As the entire Internet community gets closer to the date that IPv4 will be exhausted, more attention is being focused on the possibility that there is significant amounts of allocated IPv4 that is abandoned. There are also concerns that as the amount of usable IPv4 space gets more and more crowded, that Internet criminals are turning to abandoned IPv4 space that is still listed as allocated in the whois directories to use to make attacks on hosts on the Internet. Because of these reasons, it is becoming more important that users of ARIN's whois data have a reasonable expectation that it is accurate. The current NRPM has a mechanism for adding, modifying, and deleting POCs. However it also carries an assumption that POCs belonging to defunct companies will be removed when the bills for allocated IP addressing cease being paid, and the address resources are then returned to the ARIN pool as a result. The problem is that this assumption does not hold true for so-called "Legacy" IP address holders since they do not pay a yearly fee. Furthermore, billing for the IP addressing allocations is done through paper mail, thus it is possible for a POC to have a valid street address, but an invalid E-mail address, and not be caught because they are current on their account. This is becoming a serious issue because contacting a POC via a street address is too slow for victims of an attack from a hijacked IP block to be able to complain to the block owners and the block owners to be able to catch the perpetrators. Timetable for implementation: Immediate From kkargel at polartel.com Thu Aug 21 10:06:56 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 21 Aug 2008 09:06:56 -0500 Subject: [arin-ppml] Policy Proposal: whois POC e-mail cleanup In-Reply-To: <48AD73EF.7010004@arin.net> References: <48AD73EF.7010004@arin.net> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10A3A@mail> I cannot support a policy that holds members accountable while leaving Legacy holders immune. Apply the policy fairly or don't bother. There is no need for a monthly report for a system that is updated annually. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services Sent: Thursday, August 21, 2008 8:56 AM To: arin-ppml at arin.net Subject: [arin-ppml] Policy Proposal: whois POC e-mail cleanup ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At their following meeting the AC will accept or not accept the proposal. 3. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision via the PPML. If a proposal is not accepted, 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 proposal will be closed. The AC will assign shepherds in the near future. ARIN will provide the names of the shepherds to the community via the PPML. In the meantime, the AC invites everyone to comment on this proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: whois POC e-mail cleanup Author: Ted Mittelstaedt Proposal Version: 1 Submission Date: 8/20/2008 Proposal type: new Policy term: permanent Policy statement: Under Directory Services in the NRPM add section 3.6 titled "Reliability of Whois information" 3.6.1 ARIN will use an automated system that once a year will attempt to e-mail all separate e-mail addresses in the directory. (including abuse addresses) At it's discretion, ARIN will attempt to contact by regular mail or phone all POC entries that have invalid e-mail addresses (i.e. e-mail addresses that bounce mail sent to them) and give them a 3 month deadline for correction of their mail address. The automated system will not use a mail cluster or other mail transmission software that is incompatible with commonly available anti-spam technologies, such as greylisting. LIR POC's that fail to respond to paper mails or telephone calls will have Their e-mail address replaced with "REFUSED RESPONSE" in the directory. Non-legacy POCs will be requested to remedy the situation by their next billing date. At it's discretion and considering the size or number of complaints about an organization, ARIN may require the organization to supply accurate contact information in it's directory entry as a condition of accepting payment from the organization for registration renewals. POCs belonging to blocks reassigned by LIRs who fail to respond will be replaced by the POC of the reassigning LIR. The automated e-mails will have a text string titled "ARIN Automated POC e-mail test" identifying them so that automated trouble ticket systems can be programmed to automatically delete the mail messages instead of replying to them. Other standard mailing list practices will be followed by ARIN to insure the absence of e-mail loops, etc. 3.6.1 ARIN will supply a report to the community, updated monthly, that lists the percentage of "REFUSED RESPONSE" POCs, the percentage of POCs that accept e-mails, and the percentage of POC addresses that have not responded but have not yet been notified by paper mail or telephone. Rationale: As the entire Internet community gets closer to the date that IPv4 will be exhausted, more attention is being focused on the possibility that there is significant amounts of allocated IPv4 that is abandoned. There are also concerns that as the amount of usable IPv4 space gets more and more crowded, that Internet criminals are turning to abandoned IPv4 space that is still listed as allocated in the whois directories to use to make attacks on hosts on the Internet. Because of these reasons, it is becoming more important that users of ARIN's whois data have a reasonable expectation that it is accurate. The current NRPM has a mechanism for adding, modifying, and deleting POCs. However it also carries an assumption that POCs belonging to defunct companies will be removed when the bills for allocated IP addressing cease being paid, and the address resources are then returned to the ARIN pool as a result. The problem is that this assumption does not hold true for so-called "Legacy" IP address holders since they do not pay a yearly fee. Furthermore, billing for the IP addressing allocations is done through paper mail, thus it is possible for a POC to have a valid street address, but an invalid E-mail address, and not be caught because they are current on their account. This is becoming a serious issue because contacting a POC via a street address is too slow for victims of an attack from a hijacked IP block to be able to complain to the block owners and the block owners to be able to catch the perpetrators. Timetable for implementation: Immediate _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3107 bytes Desc: not available URL: From Lee.Howard at stanleyassociates.com Thu Aug 21 10:11:40 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 21 Aug 2008 10:11:40 -0400 Subject: [arin-ppml] Legacy RSA (was: Whois Integrity Policy Proposal) In-Reply-To: <616812070808202151p5605ef5dt193e3cca32075c13@mail.gmail.com> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B0612CE@CL-S-EX-1.stanleyassociates.com> Yuck, HTML email. Not an issue. ARIN can't prevent you from breaking the law with those addresses (i.e., we don't control your content), but it would be bad for ARIN to continue providing service to an entity knowing they had used that service to break the law. I have trouble imagining any organization with any integrity saying, "I won't sign this agreement because I'll get in trouble if I break the law." And again, my sympathy for that organization is low. Lee ________________________________ From: heather skanks [mailto:heather.skanks at gmail.com] Sent: Thursday, August 21, 2008 12:51 AM To: Howard, W. Lee Cc: William Herrin; arin-ppml at arin.net Subject: Re: [arin-ppml] Legacy RSA (was: Whois Integrity Policy Proposal) I believe Bill Herrin's example has to do with content - and it appears there is a seperate section in the LRSA about that. My guess is "Evil ARIN" couldn't have it both ways.. revoking you for content and disavowing control over content? 4.e: Content Control. Legacy Applicant acknowledges that content transmitted over the Internet occurs in real time. Accordingly, ARIN does not have the ability to control content accessible through or facilitated by those who receive number resources, directly or indirectly, from ARIN. -------------- next part -------------- An HTML attachment was scrubbed... URL: From heather.skanks at gmail.com Thu Aug 21 10:29:25 2008 From: heather.skanks at gmail.com (heather skanks) Date: Thu, 21 Aug 2008 10:29:25 -0400 Subject: [arin-ppml] Whois Integrity Policy Proposal -- What is proof and how big is the problem? In-Reply-To: <37c742b4f59832d9ff8b10637a25180548ad6ae6@jcc.com> References: <37c742b4f59832d9ff8b10637a25180548ad6ae6@jcc.com> Message-ID: <616812070808210729q50c560e8r70b00563a38c2efc@mail.gmail.com> For 1997 8055 netblock records with "last modified" year of 1997 645 ASN records with "last modified" year of 1997 3677 ORG records with "last modified" year of 1997 For the curious: 17 POC records with "last modified" year of 1987 23 POC records with "last modified" year of 1988 135 POC records with "last modified" year of 1989 234 POC records with "last modified" year of 1990 437 POC records with "last modified" year of 1991 896 POC records with "last modified" year of 1992 1733 POC records with "last modified" year of 1993 2256 POC records with "last modified" year of 1994 3396 POC records with "last modified" year of 1995 3945 POC records with "last modified" year of 1996 4009 POC records with "last modified" year of 1997 --Heather On Thu, Aug 21, 2008 at 9:17 AM, Keith W. Hare wrote: > Heather, > > Thanks for the data. > > However, you left out 1997. Since ARIN didn't officially come into > existence until December 22, 1997, most of 1997 is still legacy. > > Keith > > ------------------------------ > *From:* heather skanks [mailto:heather.skanks at gmail.com] > *Sent:* Thursday, August 21, 2008 1:31 AM > *To:* Keith W. Hare > *Cc:* arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Whois Integrity Policy Proposal -- What is > proof and how big is the problem? > > > On Mon, Aug 18, 2008 at 10:50 AM, Keith W. Hare wrote: > >> The Whois Integrity Policy Proposal says: >> >> ARIN will not update historical information in >> the ARIN Whois Database until the resource holder >> can prove the organization's right to the resource. >> >> What documentation will be required for an organization to prove their >> right to a resource? >> > > Section 3 of the LRSA provides a process for evaluating a request: > > 3. EVALUATION AND ACCEPTANCE > Following Legacy Applicant's completion of the online application process, > ARIN will promptly evaluate Legacy Applicant's request for the Services. > Evaluation may require Legacy Applicant's submission of additional > documentation to support its application such as, but not limited to, state > registration, Dun & Bradstreet and/or taxpayer information, and/or > registration under the province or country in which the entity is registered > for verification purposes. If ARIN, in its sole and exclusive discretion, > applying its published Policies and internal verification process, > determines that it can provide the Services to Legacy Applicant, ARIN shall > provide written notice to Legacy Applicant of its willingness to do so, and > ARIN will promptly commence providing the Services to Legacy Applicant in > accordance with the terms and conditions of this Legacy Agreement. If ARIN, > in its sole and exclusive discretion, applying > its published Policies and internal verification process, determines that > it cannot provide the Services, it will provide written notice to Legacy > Applicant of its decision. > > > >> >> The APNIC proposal provided some statistics about how many organizations >> might be affected by their proposal. Are there any counts available for >> ARIN? >> > > > Roughly.. > > 1213 netblock records with "last modified" year of 1991 > 2654 netblock records with "last modified" year of 1992 > 6030 netblock records with "last modified" year of 1993 > 4641 netblock records with "last modified" year of 1994 > 7407 netblock records with "last modified" year of 1995 > 6038 netblock records with "last modified" year of 1996 > > > 162 ASN records with "last modified" year of 1991 > 72 ASN records with "last modified" year of 1992 > 122 ASN records with "last modified" year of 1993 > 321 ASN records with "last modified" year of 1994 > 411 ASN records with "last modified" year of 1995 > 624 ASN records with "last modified" year of 1996 > > > 912 ORG records with "last modified" year of 1991 > 1514 ORG records with "last modified" year of 1992 > 4452 ORG records with "last modified" year of 1993 > 3500 ORG records with "last modified" year of 1994 > 4917 ORG records with "last modified" year of 1995 > 3746 ORG records with "last modified" year of 1996 > > > > > >> >> Keith >> >> ______________________________________________________________ >> >> Keith W. Hare JCC Consulting, Inc. >> keith at jcc.com 600 Newark Road >> Phone: 740-587-0157 P.O. Box 381 >> Fax: 740-587-0163 Granville, Ohio 43023 >> http://www.jcc.com USA >> ______________________________________________________________ >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Thu Aug 21 10:09:01 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 21 Aug 2008 15:09:01 +0100 Subject: [arin-ppml] Policy Proposal: whois POC e-mail cleanup In-Reply-To: <48AD73EF.7010004@arin.net> Message-ID: This seems to be more process than policy. Have you considered sending it to the ARIN suggestion box? Also, there should be a mechanism to get a complete list of address blocks with REFUSED RESPONSE status, even if it is via ftp and you need to apply for permission to download the list. ------------------------------------------------------- Michael Dillon MPLS Bid Support/IP Addressing Strategy - BT Design 66 Prescot St., London, E1 8HG, UK Mobile: +44 7900 823 672 Internet: michael.dillon at bt.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 http://www.btradianz.com Use the wiki: http://collaborate.intra.bt.com/ > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > Sent: 21 August 2008 14:56 > To: arin-ppml at arin.net > Subject: [arin-ppml] Policy Proposal: whois POC e-mail cleanup > > ARIN received the following policy proposal. In accordance > with the ARIN Internet Resource Policy Evaluation Process, > the proposal is being posted to the ARIN Public Policy > Mailing List (PPML) and being placed on ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal at > their next regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as written. If the AC accepts the > proposal, it will be posted as a formal policy proposal to > PPML and it will be presented at a Public Policy Meeting. > > 2. Postpone their decision regarding the proposal until > the next regularly scheduled AC meeting in order to work with > the author. The AC will work with the author to clarify, > combine or divide the proposal. At their following meeting > the AC will accept or not accept the proposal. > > 3. Not accept the proposal. If the AC does not accept > the proposal, the AC will explain their decision via the > PPML. If a proposal is not accepted, 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 proposal will be closed. > > The AC will assign shepherds in the near future. ARIN will > provide the names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this > proposal on the PPML, particularly their support or > non-support and the reasoning behind their opinion. Such > participation contributes to a thorough vetting and provides > important guidance to the AC in their deliberations. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: whois POC e-mail cleanup > > Author: Ted Mittelstaedt > > Proposal Version: 1 > > Submission Date: 8/20/2008 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Under Directory Services in the NRPM > > add section 3.6 titled "Reliability of Whois information" > > 3.6.1 ARIN will use an automated system that once a year > will attempt to e-mail all separate e-mail addresses in the > directory. (including abuse addresses) At it's discretion, > ARIN will attempt to contact by regular mail or phone all POC > entries that have invalid e-mail addresses (i.e. e-mail > addresses that bounce mail sent to them) and give them a 3 > month deadline for correction of their mail address. The > automated system will not use a mail cluster or other mail > transmission software that is incompatible with commonly > available anti-spam technologies, such as greylisting. > > LIR POC's that fail to respond to paper mails or telephone > calls will have Their e-mail address replaced with "REFUSED > RESPONSE" in the directory. Non-legacy POCs will be requested > to remedy the situation by their next billing date. At it's > discretion and considering the size or number of complaints > about an organization, ARIN may require the organization to > supply accurate contact information in it's directory entry > as a condition of accepting payment from the organization for > registration renewals. > > POCs belonging to blocks reassigned by LIRs who fail to > respond will be replaced by the POC of the reassigning LIR. > > The automated e-mails will have a text string titled "ARIN > Automated POC e-mail test" identifying them so that automated > trouble ticket systems can be programmed to automatically > delete the mail messages instead of replying to them. > > Other standard mailing list practices will be followed by > ARIN to insure the absence of e-mail loops, etc. > > 3.6.1 ARIN will supply a report to the community, updated > monthly, that lists the percentage of "REFUSED RESPONSE" > POCs, the percentage of POCs that accept e-mails, and the > percentage of POC addresses that have not responded but have > not yet been notified by paper mail or telephone. > > Rationale: > > As the entire Internet community gets closer to the date that > IPv4 will be exhausted, more attention is being focused on > the possibility that there is significant amounts of > allocated IPv4 that is abandoned. There are also concerns > that as the amount of usable IPv4 space gets more and more > crowded, that Internet criminals are turning to abandoned > IPv4 space that is still listed as allocated in the whois > directories to use to make attacks on hosts on the Internet. > Because of these reasons, it is becoming more important that > users of ARIN's whois data have a reasonable expectation that > it is accurate. > > The current NRPM has a mechanism for adding, modifying, and > deleting POCs. However it also carries an assumption that > POCs belonging to defunct companies will be removed when the > bills for allocated IP addressing cease being paid, and the > address resources are then returned to the ARIN pool as a > result. The problem is that this assumption does not hold > true for so-called "Legacy" IP address holders since they do > not pay a yearly fee. Furthermore, billing for the IP > addressing allocations is done through paper mail, thus it is > possible for a POC to have a valid street address, but an > invalid E-mail address, and not be caught because they are > current on their account. This is becoming a serious issue > because contacting a POC via a street address is too slow for > victims of an attack from a hijacked IP block to be able to > complain to the block owners and the block owners to be able > to catch the perpetrators. > > Timetable for implementation: Immediate > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From Keith at jcc.com Thu Aug 21 10:47:15 2008 From: Keith at jcc.com (Keith W. Hare) Date: Thu, 21 Aug 2008 10:47:15 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal Message-ID: <6a5ea173e242fea1b2ae77f8651e63d448ad7fe2@jcc.com> The numbers that Heather provided only partially describe the resources and organizations affected by this proposal. 36,038 netblock records with last modified year of 1997 or earlier 2,375 ASN records with last modified year of 1997 or earlier 22,718 ORG records with last modified year of 1997 or earlier How many legacy netblock and ASN records have been updated since the formation of ARIN on December 22, 1997? My biggest objection to the proposal is that it sounds like a stick to beat up the evil legacy resource holder because they haven't been paying their fair share. Until less than a year ago, ARIN did not have a process or documentation in place to allow a legacy resource holder to bring the resource under some kind of agreement. The Legacy RSA is currently scheduled to be available only through December 31, 2009. How about more complicated phased approach that: -- Extends the Legacy RSA availability until December 31, 2010 or December 31, 2011. -- Locks the records that have not been updated since December 22, 1997. -- Sets up a schedule something like: -- January 1, 2009 -- lock records not updated or under an (L)RSA since January 1, 2001 -- January 1, 2010 -- lock records not updated or under an (L)RSA since January 1, 2004 -- January 1, 2011 -- lock records not updated or under an (L)RSA since January 1, 2007 -- January 1, 2012 -- lock records not updated or under an (L)RSA since January 1, 2010 -- January 1, 2013 -- lock records not updated or under an (L)RSA Keith ______________________________________________________________ Keith W. Hare JCC Consulting, Inc. keith at jcc.com 600 Newark Road Phone: 740-587-0157 P.O. Box 381 Fax: 740-587-0163 Granville, Ohio 43023 http://www.jcc.com USA ______________________________________________________________ From bicknell at ufp.org Thu Aug 21 10:56:58 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 21 Aug 2008 10:56:58 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <6a5ea173e242fea1b2ae77f8651e63d448ad7fe2@jcc.com> References: <6a5ea173e242fea1b2ae77f8651e63d448ad7fe2@jcc.com> Message-ID: <20080821145657.GB49608@ussenterprise.ufp.org> In a message written on Thu, Aug 21, 2008 at 10:47:15AM -0400, Keith W. Hare wrote: > My biggest objection to the proposal is that it sounds like a stick to > beat up the evil legacy resource holder because they haven't been paying > their fair share. Until less than a year ago, ARIN did not have a > process or documentation in place to allow a legacy resource holder to > bring the resource under some kind of agreement. This is not an entirely true statement. I'll be the first to admit ARIN had insufficient publically available information on what legacy holders could do on their web site. That said, I believe more than a few legacy holders when they came in to ask for additional resources had their legacy resources listed as well, all covered by a single RSA. I have no idea the percentage who chose to do so, if ARIN pushed it at all, etc. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From kkargel at polartel.com Thu Aug 21 10:57:44 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 21 Aug 2008 09:57:44 -0500 Subject: [arin-ppml] Policy Proposal: whois POC e-mail cleanup In-Reply-To: References: <48AD73EF.7010004@arin.net> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10A3B@mail> I agree on the published list, and as it is information available in public records I see no problem with publishing the collated data freely, perhaps in a common format such as a dnsbl.. I am not suggesting any particualar use, but it may be good to make the information available in an easy to use format. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com Sent: Thursday, August 21, 2008 9:09 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal: whois POC e-mail cleanup This seems to be more process than policy. Have you considered sending it to the ARIN suggestion box? Also, there should be a mechanism to get a complete list of address blocks with REFUSED RESPONSE status, even if it is via ftp and you need to apply for permission to download the list. ------------------------------------------------------- Michael Dillon MPLS Bid Support/IP Addressing Strategy - BT Design 66 Prescot St., London, E1 8HG, UK Mobile: +44 7900 823 672 Internet: michael.dillon at bt.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 http://www.btradianz.com Use the wiki: http://collaborate.intra.bt.com/ > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > Sent: 21 August 2008 14:56 > To: arin-ppml at arin.net > Subject: [arin-ppml] Policy Proposal: whois POC e-mail cleanup > > ARIN received the following policy proposal. In accordance with the > ARIN Internet Resource Policy Evaluation Process, the proposal is > being posted to the ARIN Public Policy Mailing List (PPML) and being > placed on ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal at their next > regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as written. If the AC accepts the > proposal, it will be posted as a formal policy proposal to PPML and it > will be presented at a Public Policy Meeting. > > 2. Postpone their decision regarding the proposal until the next > regularly scheduled AC meeting in order to work with the author. The > AC will work with the author to clarify, combine or divide the > proposal. At their following meeting the AC will accept or not accept > the proposal. > > 3. Not accept the proposal. If the AC does not accept the > proposal, the AC will explain their decision via the PPML. If a > proposal is not accepted, 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 > proposal will be closed. > > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this proposal > on the PPML, particularly their support or non-support and the > reasoning behind their opinion. Such participation contributes to a > thorough vetting and provides important guidance to the AC in their > deliberations. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: whois POC e-mail cleanup > > Author: Ted Mittelstaedt > > Proposal Version: 1 > > Submission Date: 8/20/2008 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Under Directory Services in the NRPM > > add section 3.6 titled "Reliability of Whois information" > > 3.6.1 ARIN will use an automated system that once a year will attempt > to e-mail all separate e-mail addresses in the directory. (including > abuse addresses) At it's discretion, ARIN will attempt to contact by > regular mail or phone all POC entries that have invalid e-mail > addresses (i.e. e-mail addresses that bounce mail sent to them) and > give them a 3 month deadline for correction of their mail address. > The automated system will not use a mail cluster or other mail > transmission software that is incompatible with commonly available > anti-spam technologies, such as greylisting. > > LIR POC's that fail to respond to paper mails or telephone calls will > have Their e-mail address replaced with "REFUSED RESPONSE" in the > directory. Non-legacy POCs will be requested to remedy the situation > by their next billing date. At it's discretion and considering the > size or number of complaints about an organization, ARIN may require > the organization to supply accurate contact information in it's > directory entry as a condition of accepting payment from the > organization for registration renewals. > > POCs belonging to blocks reassigned by LIRs who fail to respond will > be replaced by the POC of the reassigning LIR. > > The automated e-mails will have a text string titled "ARIN Automated > POC e-mail test" identifying them so that automated trouble ticket > systems can be programmed to automatically delete the mail messages > instead of replying to them. > > Other standard mailing list practices will be followed by ARIN to > insure the absence of e-mail loops, etc. > > 3.6.1 ARIN will supply a report to the community, updated monthly, > that lists the percentage of "REFUSED RESPONSE" > POCs, the percentage of POCs that accept e-mails, and the percentage > of POC addresses that have not responded but have not yet been > notified by paper mail or telephone. > > Rationale: > > As the entire Internet community gets closer to the date that > IPv4 will be exhausted, more attention is being focused on the > possibility that there is significant amounts of allocated IPv4 that > is abandoned. There are also concerns that as the amount of usable > IPv4 space gets more and more crowded, that Internet criminals are > turning to abandoned > IPv4 space that is still listed as allocated in the whois directories > to use to make attacks on hosts on the Internet. > Because of these reasons, it is becoming more important that users of > ARIN's whois data have a reasonable expectation that it is accurate. > > The current NRPM has a mechanism for adding, modifying, and deleting > POCs. However it also carries an assumption that POCs belonging to > defunct companies will be removed when the bills for allocated IP > addressing cease being paid, and the address resources are then > returned to the ARIN pool as a result. The problem is that this > assumption does not hold true for so-called "Legacy" IP address > holders since they do not pay a yearly fee. Furthermore, billing for > the IP addressing allocations is done through paper mail, thus it is > possible for a POC to have a valid street address, but an invalid > E-mail address, and not be caught because they are current on their > account. This is becoming a serious issue because contacting a POC > via a street address is too slow for victims of an attack from a > hijacked IP block to be able to complain to the block owners and the > block owners to be able to catch the perpetrators. > > Timetable for implementation: Immediate > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3107 bytes Desc: not available URL: From owen at delong.com Thu Aug 21 11:30:53 2008 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Aug 2008 08:30:53 -0700 Subject: [arin-ppml] Policy Proposal: whois POC e-mail cleanup In-Reply-To: <48AD73EF.7010004@arin.net> References: <48AD73EF.7010004@arin.net> Message-ID: <1A98A9AD-80C3-4CD8-AAB4-601356194900@delong.com> > > add section 3.6 titled "Reliability of Whois information" > > 3.6.1 ARIN will use an automated system that once a year will attempt > to e-mail all separate e-mail addresses in the directory. (including > abuse addresses) At it's discretion, ARIN will attempt to contact by > regular mail or phone all POC entries that have invalid e-mail > addresses > (i.e. e-mail addresses that bounce mail sent to them) and give them > a 3 > month deadline for correction of their mail address. The automated > system will not use a mail cluster or other mail transmission software > that is incompatible with commonly available anti-spam technologies, > such as greylisting. > The first problem I see is a small wordsmithing nit.. The way this is worded, it gives ARIN discretion to regular mail or phone ALL POCs with invalid email adresses or none. I would suggest this be changed to ANY instead of ALL so that ARIN has case-by-case discretion rather than all-or-none. The second problem is this declares invalid only those addresses which result in a bounce back. What about addresses which are a black hole? Is a POC valid so long as some server accepts mail for it, regardless of whether anyone sees or acts on that email? This doesn't seem particularly meaningful. OTOH, black-hole detection is difficult unless you are going to require the POC to take some responsive action. > LIR POC's that fail to respond to paper mails or telephone calls will > have Their e-mail address replaced with "REFUSED RESPONSE" in the > directory. Non-legacy POCs will be requested to remedy the situation > by > their next billing date. At it's discretion and considering the > size or > number of complaints about an organization, ARIN may require the > organization to supply accurate contact information in it's directory > entry as a condition of accepting payment from the organization for > registration renewals. > As I understand it, the LIR term in the NRPM applies only to those holding IPv6 Delegations. Those with IPv4 resources and those with IPv6 end user assignments would not be covered by the above paragraph as I understand the terms. Further, I don't see selective enforcement codified in policy as a good thing. Either all organizations should be required to provide valid contact information or they should not. The organizations that ARIN staff chooses to pick on at any given time is a very poor way to construct policy IMHO. > POCs belonging to blocks reassigned by LIRs who fail to respond will > be > replaced by the POC of the reassigning LIR. > I think this should be carefully considered. How does this action distinguish itself from effectively deleting the whois record altogether? I would rather see the stale information with a flag on it than a new record that is indistinguishable from the LIR using this block for its own internal purposes. > The automated e-mails will have a text string titled "ARIN Automated > POC > e-mail test" identifying them so that automated trouble ticket systems > can be programmed to automatically delete the mail messages instead of > replying to them. > If the automated system deletes the message instead of replying, wouldn't this trigger ARIN treating the POC as invalid? Oh, wait, you treat black holes as valid, so, I guess not. However, if you fix the black hole loophole above, then, this paragraph needs fixing too. > Other standard mailing list practices will be followed by ARIN to > insure > the absence of e-mail loops, etc. > I think that ARIN staff is capable of using judgment here to act according to BCP rather than needing this in the NRPM. > 3.6.1 ARIN will supply a report to the community, updated monthly, > that > lists the percentage of "REFUSED RESPONSE" POCs, the percentage of > POCs > that accept e-mails, and the percentage of POC addresses that have not > responded but have not yet been notified by paper mail or telephone. > I have mixed emotions on this requirement. I'm not sure what the benefit of publishing these anonymized statistics is. Owen From vixie at isc.org Thu Aug 21 11:34:21 2008 From: vixie at isc.org (Paul Vixie) Date: Thu, 21 Aug 2008 15:34:21 +0000 Subject: [arin-ppml] LRSA concerns (Re: Policy Proposal: Whois Integrity Policy Proposal) In-Reply-To: Your message of "Wed, 20 Aug 2008 23:13:38 -0400." <3c3e3fca0808202013n65bf8bc8tae50417451e629f6@mail.gmail.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> <48ACA684.2090208@rancid.berkeley.edu> <3c3e3fca0808201726l7e021ffakb53df5eedac8acbb@mail.gmail.com> <99772.1219282684@nsa.vix.com> <3c3e3fca0808202013n65bf8bc8tae50417451e629f6@mail.gmail.com> Message-ID: <30601.1219332861@nsa.vix.com> > > what's your proposed fix? > > The contract termination process is the linchpin. Fix that part so > that the registrant holds the power and all the other problems are > academic. perhaps my own lack of perceived conflict between my role as LRSA signer and ARIN trustee makes me a bad dayjob CEO or a bad ARIN trustee, but when i signed ISC's LRSA, i knew it was inseverable in all practical senses, and i *liked* that. having a bunch of ungoverned and ungovernable legacy blocks and legacy holders running around makes it very hard for the community to act in a concerted fashion around things like WHOIS privacy, paid transfer market development, minimum allocation sizes, and lots of other things falling under the umbrella of "stewardship". arguments of the form "LRSA is bad because of its inseverability" boil down to "i as a legacy holder do not want my use of this resource to be governed unless i happen to like the direction that governance is taking me" and while i can see why some legacy holders might hold that position i don't see it as likely that the ARIN community will come to that as its consensus. but i'll watch for signs that the sense of the community is tipping in that direction. and i'll ask that KC address this in her next survey. note that ARIN exists to serve the whole community, not just its members, so you needn't fear a "tyranny of the majority" on LRSA policy. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From JOHN at egh.com Thu Aug 21 11:34:46 2008 From: JOHN at egh.com (John Santos) Date: Thu, 21 Aug 2008 11:34:46 -0400 Subject: [arin-ppml] Whois Integrity Policy Proposal -- What is proof and how big is the problem? In-Reply-To: <616812070808210729q50c560e8r70b00563a38c2efc@mail.gmail.com> Message-ID: <1080821103527.27224A-300000@Ives.egh.com> Just out of curiosity, if you go to the ARIN web site, check your POC info, determine that it is still accurate, and leave it unchanged, does your date get bumped, or does it still appear to be old? Does the database need a "date of last confirmation" to reflect this situation, or would touching the "date of last update" suffice, or is this a complete non-issue? (I just checked my POC and ORG records and they are still correct, and haven't been modified since 2000 and 2004 respectively.) -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 -------------- next part -------------- For 1997 8055 netblock records with "last modified" year of 1997 645 ASN records with "last modified" year of 1997 3677 ORG records with "last modified" year of 1997 For the curious: 17 POC records with "last modified" year of 1987 23 POC records with "last modified" year of 1988 135 POC records with "last modified" year of 1989 234 POC records with "last modified" year of 1990 437 POC records with "last modified" year of 1991 896 POC records with "last modified" year of 1992 1733 POC records with "last modified" year of 1993 2256 POC records with "last modified" year of 1994 3396 POC records with "last modified" year of 1995 3945 POC records with "last modified" year of 1996 4009 POC records with "last modified" year of 1997 --Heather On Thu, Aug 21, 2008 at 9:17 AM, Keith W. Hare wrote: > Heather, > > Thanks for the data. > > However, you left out 1997. Since ARIN didn't officially come into > existence until December 22, 1997, most of 1997 is still legacy. > > Keith > > ------------------------------ > *From:* heather skanks [mailto:heather.skanks at gmail.com] > *Sent:* Thursday, August 21, 2008 1:31 AM > *To:* Keith W. Hare > *Cc:* arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Whois Integrity Policy Proposal -- What is > proof and how big is the problem? > > > On Mon, Aug 18, 2008 at 10:50 AM, Keith W. Hare wrote: > >> The Whois Integrity Policy Proposal says: >> >> ARIN will not update historical information in >> the ARIN Whois Database until the resource holder >> can prove the organization's right to the resource. >> >> What documentation will be required for an organization to prove their >> right to a resource? >> > > Section 3 of the LRSA provides a process for evaluating a request: > > 3. EVALUATION AND ACCEPTANCE > Following Legacy Applicant's completion of the online application process, > ARIN will promptly evaluate Legacy Applicant's request for the Services. > Evaluation may require Legacy Applicant's submission of additional > documentation to support its application such as, but not limited to, state > registration, Dun & Bradstreet and/or taxpayer information, and/or > registration under the province or country in which the entity is registered > for verification purposes. If ARIN, in its sole and exclusive discretion, > applying its published Policies and internal verification process, > determines that it can provide the Services to Legacy Applicant, ARIN shall > provide written notice to Legacy Applicant of its willingness to do so, and > ARIN will promptly commence providing the Services to Legacy Applicant in > accordance with the terms and conditions of this Legacy Agreement. If ARIN, > in its sole and exclusive discretion, applying > its published Policies and internal verification process, determines that > it cannot provide the Services, it will provide written notice to Legacy > Applicant of its decision. > > > >> >> The APNIC proposal provided some statistics about how many organizations >> might be affected by their proposal. Are there any counts available for >> ARIN? >> > > > Roughly.. > > 1213 netblock records with "last modified" year of 1991 > 2654 netblock records with "last modified" year of 1992 > 6030 netblock records with "last modified" year of 1993 > 4641 netblock records with "last modified" year of 1994 > 7407 netblock records with "last modified" year of 1995 > 6038 netblock records with "last modified" year of 1996 > > > 162 ASN records with "last modified" year of 1991 > 72 ASN records with "last modified" year of 1992 > 122 ASN records with "last modified" year of 1993 > 321 ASN records with "last modified" year of 1994 > 411 ASN records with "last modified" year of 1995 > 624 ASN records with "last modified" year of 1996 > > > 912 ORG records with "last modified" year of 1991 > 1514 ORG records with "last modified" year of 1992 > 4452 ORG records with "last modified" year of 1993 > 3500 ORG records with "last modified" year of 1994 > 4917 ORG records with "last modified" year of 1995 > 3746 ORG records with "last modified" year of 1996 > > > > > >> >> Keith >> >> ______________________________________________________________ >> >> Keith W. Hare JCC Consulting, Inc. >> keith at jcc.com 600 Newark Road >> Phone: 740-587-0157 P.O. Box 381 >> Fax: 740-587-0163 Granville, Ohio 43023 >> http://www.jcc.com USA >> ______________________________________________________________ >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Aug 21 11:43:45 2008 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Aug 2008 08:43:45 -0700 Subject: [arin-ppml] Whois Integrity Policy Proposal -- What is proof and how big is the problem? In-Reply-To: <1080821103527.27224A-300000@Ives.egh.com> References: <1080821103527.27224A-300000@Ives.egh.com> Message-ID: As a point of information, the data on 192.159.10.0/24 is still correct and accurate and has not been updated since 1998. Owen On Aug 21, 2008, at 8:34 AM, John Santos wrote: > > Just out of curiosity, if you go to the ARIN web site, check your > POC info, determine that it is still accurate, and leave it unchanged, > does your date get bumped, or does it still appear to be old? > > Does the database need a "date of last confirmation" to reflect this > situation, or would touching the "date of last update" suffice, or > is this a complete non-issue? > > > (I just checked my POC and ORG records and they are still correct, > and haven't been modified since 2000 and 2004 respectively.) > > > > -- > John Santos > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 > > For 1997 > > 8055 netblock records with "last modified" year of 1997 > 645 ASN records with "last modified" year of 1997 > 3677 ORG records with "last modified" year of 1997 > > > For the curious: > 17 POC records with "last modified" year of 1987 > 23 POC records with "last modified" year of 1988 > 135 POC records with "last modified" year of 1989 > 234 POC records with "last modified" year of 1990 > 437 POC records with "last modified" year of 1991 > 896 POC records with "last modified" year of 1992 > 1733 POC records with "last modified" year of 1993 > 2256 POC records with "last modified" year of 1994 > 3396 POC records with "last modified" yea r of 1995 > 3945 POC records with "last modified" year of 1996 > 4009 POC records with "last modified" year of 1997 > > > --Heather > > > On Thu, Aug 21, 2008 at 9:17 AM, Keith W. Hare wrote: > Heather, > > Thanks for the data. > > However, you left out 1997. Since ARIN didn't officially come into > existence until December 22, 1997, most of 1997 is still legacy. > > Keith > > From: heather skanks [mailto:heather.skanks at gmail.com] > Sent: Thursday, August 21, 2008 1:31 AM > To: Keith W. Hare > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Whois Integrity Policy Proposal -- What is > proof and how big is the problem? > > > On Mon, Aug 18, 2008 at 10:50 AM, Keith W. Hare wrote: > The Whois Integrity Policy Proposal says: > > ARIN will not update historical information in > the ARIN Whois Database until the resource holder > can prove the organization's right to the resource. > > What documentation will be required for an organization to prove their > right to a resource? > > Section 3 of the LRSA provides a process for evaluating a request: > > 3. EVALUATION AND ACCEPTANCE > Following Legacy Applicant's completion of the online application > process, ARIN will promptly evaluate Legacy Applicant's request for > the Services. Evaluation may require Legacy Applicant's submission > of additional documentation to support its application such as, but > not limited to, state registration, Dun & Bradstreet and/or taxpayer > information, and/or registration under the province or country in > which the entity is registered for verification purposes. If ARIN, > in its sole and exclusive discretion, applying its published > Policies and internal verification process, determines that it can > provide the Services to Legacy Applicant, ARIN shall provide written > notice to Legacy Applicant of its willingness to do so, and ARIN > will promptly commence providing the Services to Legacy Applicant in > accordance with the terms and conditions of this Legacy Agreement. > If ARIN, in its sole and exclusive discretion, applying > its published Policies and internal verification process, determines > that it cannot provide the Services, it will provide written notice > to Legacy Applicant of its decision. > > > > The APNIC proposal provided some statistics about how many > organizations > might be affected by their proposal. Are there any counts available > for > ARIN? > > > Roughly.. > 1213 netblock records with "last modified" year of 1991 > 2654 netblock records with "last modified" year of 1992 > 6030 netblock records with "last modified" year of 1993 > 4641 netblock records with "last modified" year of 1994 > 7407 netblock records with "last modified" year of 1995 > 6038 netblock records with "last modified" year of 1996 > > > 162 ASN records with "last modified" year of 1991 > 72 ASN records with "last modified" year of 1992 > 122 ASN records with "last modified" year of 1993 > 321 ASN records with "last modified" year of 1994 > 411 ASN records with "last modified" year of 1995 > 624 ASN records with "last modified" year of 1996 > > > 912 ORG records with "last modified" year of 1991 > 1514 ORG records with "last modified" year of 1992 > 4452 ORG records with "last modified" year of 1993 > 3500 ORG records with "last modified" year of 1994 > 4917 ORG records with "last modified" year of 1995 > 3746 ORG records with "last modified" year of 1996 > > > > > > > Keith > > ______________________________________________________________ > > Keith W. Hare JCC Consulting, Inc. > keith at jcc.com 600 Newark Road > Phone: 740-587-0157 P.O. Box 381 > Fax: 740-587-0163 Granville, Ohio 43023 > http://www.jcc.com USA > ______________________________________________________________ > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From craig.finseth at state.mn.us Thu Aug 21 11:50:52 2008 From: craig.finseth at state.mn.us (Craig Finseth) Date: Thu, 21 Aug 2008 10:50:52 -0500 Subject: [arin-ppml] Legacy RSA (was: Whois Integrity Policy Proposal) In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40B0612CE@CL-S-EX-1.stanleyassociates.com> (Lee.Howard@stanleyassociates.com) References: <369EB04A0951824ABE7D8BAC67AF9BB40B0612CE@CL-S-EX-1.stanleyassociates.com> Message-ID: <200808211550.m7LFoqxC027637@inana.itg.state.mn.us> ... Not an issue. ARIN can't prevent you from breaking the law with those addresses (i.e., we don't control your content), but it would be bad for ARIN to continue providing service to an entity knowing they had used that service to break the law. ... Does ARIN really want to be in the business of investigating crimes? Of course, if a customer says "I am breaking the law," I have no problem with ARIN terminating service. But, I don't see that ARIN can or should be in the business of attempting to deterine guilt or innocence. Absent a court order, I don't think ARIN should be taking any positive action. Craig From Lee.Howard at stanleyassociates.com Thu Aug 21 12:47:57 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 21 Aug 2008 12:47:57 -0400 Subject: [arin-ppml] Legacy RSA (was: Whois Integrity Policy Proposal) In-Reply-To: <200808211550.m7LFoqxC027637@inana.itg.state.mn.us> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B0615CE@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: Craig Finseth [mailto:craig.finseth at state.mn.us] > Sent: Thursday, August 21, 2008 11:51 AM > To: Howard, W. Lee > Cc: heather.skanks at gmail.com; arin-ppml at arin.net > Subject: Re: [arin-ppml] Legacy RSA (was: Whois Integrity > Policy Proposal) > > ... > Not an issue. ARIN can't prevent you from breaking the > law with those > addresses (i.e., we don't control your content), but it > would be bad for > ARIN to continue providing service to an entity knowing > they had used > that service to break the law. > ... > > Does ARIN really want to be in the business of investigating crimes? Absolutely not, and I don't advocate that. The scenario provided was, 4.d.ii, "(ii) be found to have violated any applicable laws, statutes or regulations by a ruling of a court or government regulatory agency." This is further clarified in the same paragraph: "A definitive finding of a violation of law or regulation when established by a decision of a national, state, or other government authority regarding (i) through (iii) herein should similarly be sent to ARIN's General Counsel for ARIN's review and action." > Of course, if a customer says "I am breaking the law," I have > no problem with ARIN terminating service. But, I don't see > that ARIN can or should be in the business of attempting to > deterine guilt or innocence. Absent a court order, I don't > think ARIN should be taking any positive action. Does the text of the LRSA satisfy your concern? The question was, "What's the worst ARIN could do?" In the circumstance quoted above, the worst a hypothetical "evil ARIN" could do would be to terminate the contract for cause, which has the effects described in 14.e, "Effect of Termination," basically revocation. At least, I think that's the worst ARIN could do; there may be other things ARIN could do, and your definition of "worst" may vary. IANAL,YMMV,HAND. I think Bill Herrin was trying to come up with a White Hat lawbreaker scenario. I think that the stuff I quoted above ("ruling of a court or government regulatory agency") limits ARIN's potential vigilanteism. If you (anyone reading this) are a legacy resource holder, and have not signed the LRSA because of concerns that some action on your part might inadvertently trigger termination based on this section, please consult your attorney, and the Registration Services Help Desk or ARIN's General Counsel. Contact information is in: http://www.arin.net/registration/legacy/index.html#faq where it says: Anyone needing information about legacy space in general or the Legacy RSA can call the Registration Services Help Desk at +1.703.227. 0660 or send email to hostmaster at arin.net. If you have legal questions, please contact ARIN General Counsel, Steve Ryan, at sryan at mwe.com Lee > > Craig > > From Keith at jcc.com Thu Aug 21 14:28:19 2008 From: Keith at jcc.com (Keith W. Hare) Date: Thu, 21 Aug 2008 14:28:19 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal Message-ID: <09b25dba548903dea38cbf2bc153dba848adb3b2@jcc.com> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Leo Bicknell > Sent: Thursday, August 21, 2008 10:57 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Whois Integrity > Policy Proposal > > In a message written on Thu, Aug 21, 2008 at 10:47:15AM > -0400, Keith W. Hare wrote: > > My biggest objection to the proposal is that it sounds like > a stick to > > beat up the evil legacy resource holder because they > haven't been paying > > their fair share. Until less than a year ago, ARIN did not have a > > process or documentation in place to allow a legacy > resource holder to > > bring the resource under some kind of agreement. > > This is not an entirely true statement. I'll be the first to admit > ARIN had insufficient publically available information on what > legacy holders could do on their web site. That said, I believe > more than a few legacy holders when they came in to ask for additional > resources had their legacy resources listed as well, all covered > by a single RSA. For a legacy resource holder who did not need additional resources there was no visible process until last fall. A year ago, I looked for such a process on the ARIN web site and was unable to find one. I'd like to think that my rants last summer about that lack helped motivate the creation of the current process and LRSA. Keith From mueller at syr.edu Thu Aug 21 14:47:53 2008 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 21 Aug 2008 14:47:53 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <16328.1219256002@nsa.vix.com> References: <20080819172716.2FFF74501A@ptavv.es.net><867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com><86skt0ltqu.fsf@seastrom.com> <48AB17DD.6020009@psg.com><86d4k4ltd9.fsf@seastrom.com><3c3e3fca0808191612x5d84942dyb935b30e1c673aaf@mail.gmail.com><34567.1219192974@nsa.vix.com><3c3e3fca0808200934o4017bfb0s744e1e73d0d0d396@mail.gmail.com> <16328.1219256002@nsa.vix.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9011DCA61@SUEXCL-02.ad.syr.edu> > -----Original Message----- > From: arin-ppml-bounces at arin.net > > lawsuits, i expect. but can you explain ARIN's likely > motives for skirting? > "Trust me" arguments have no place in global governance processes. We've learned that with ICANN (at least, some of us have). It is horribly naive not to think carefully about appropriate institutionalized checks and balances on the RIRs, however good and dedicated the people in them may be (for the time being). The problem with private contractual governance of a global resource pool is that a private contract usually implies an alternative, a choice, somewhere else you can go. If you don't sign a contract with ARIN, what's your alternative? No amount of rhetorical identification of the RIRs with "the community" can obscure the fact that ARIN has exclusive control over the resource and thus unbalanced bargaining power in any negotiation. (Except, of course, with legacy holders. Which is what makes this discussion soooo interesting.) > is that the elephant in this room? are some legacy > holders objecting to having RSA-like restrictions on selling > their space, and are therefore rejecting the LRSA on that basis, but not > willing to say so here? if so, that's kinda rotten I think the situation is the opposite from what you project. Rather than legacy holders demanding special rights to sell, I suspect they are more concerned about the application of "justified need" standards that would take away addresses they currently have the option to use, or which would prevent them from selling them. Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org From cgrundemann at gmail.com Thu Aug 21 14:49:17 2008 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 21 Aug 2008 12:49:17 -0600 Subject: [arin-ppml] Policy Proposal: whois POC e-mail cleanup In-Reply-To: <48AD73EF.7010004@arin.net> References: <48AD73EF.7010004@arin.net> Message-ID: <443de7ad0808211149w7e3e2865tafc4e6baecc69262@mail.gmail.com> Imo; A response to the annual POC email should be required for verification that the email address is in fact valid. If there is no response to the email after X amount of time, the automated system should replace the POC address with "REFUSED RESPONSE" or some such. The list of POCs with this marking should be reviewed by ARIN staff and manual contact attempts could be made at their discretion. A provision for further action to be taken if manual contact methods fail should be considered (locking the POC from making other changes, deleting the POC, etc). A list of address blocks without valid POCs should be made easily available to the community. ~Chris On Thu, Aug 21, 2008 at 7:55 AM, Member Services wrote: > ARIN received the following policy proposal. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal at their next > regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as written. If the AC accepts the proposal, > it will be posted as a formal policy proposal to PPML and it will be > presented at a Public Policy Meeting. > > 2. Postpone their decision regarding the proposal until the next > regularly scheduled AC meeting in order to work with the author. The AC > will work with the author to clarify, combine or divide the proposal. At > their following meeting the AC will accept or not accept the proposal. > > 3. Not accept the proposal. If the AC does not accept the proposal, > the AC will explain their decision via the PPML. If a proposal is not > accepted, 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 proposal will be closed. > > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: whois POC e-mail cleanup > > Author: Ted Mittelstaedt > > Proposal Version: 1 > > Submission Date: 8/20/2008 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Under Directory Services in the NRPM > > add section 3.6 titled "Reliability of Whois information" > > 3.6.1 ARIN will use an automated system that once a year will attempt > to e-mail all separate e-mail addresses in the directory. (including > abuse addresses) At it's discretion, ARIN will attempt to contact by > regular mail or phone all POC entries that have invalid e-mail addresses > (i.e. e-mail addresses that bounce mail sent to them) and give them a 3 > month deadline for correction of their mail address. The automated > system will not use a mail cluster or other mail transmission software > that is incompatible with commonly available anti-spam technologies, > such as greylisting. > > LIR POC's that fail to respond to paper mails or telephone calls will > have Their e-mail address replaced with "REFUSED RESPONSE" in the > directory. Non-legacy POCs will be requested to remedy the situation by > their next billing date. At it's discretion and considering the size or > number of complaints about an organization, ARIN may require the > organization to supply accurate contact information in it's directory > entry as a condition of accepting payment from the organization for > registration renewals. > > POCs belonging to blocks reassigned by LIRs who fail to respond will be > replaced by the POC of the reassigning LIR. > > The automated e-mails will have a text string titled "ARIN Automated POC > e-mail test" identifying them so that automated trouble ticket systems > can be programmed to automatically delete the mail messages instead of > replying to them. > > Other standard mailing list practices will be followed by ARIN to insure > the absence of e-mail loops, etc. > > 3.6.1 ARIN will supply a report to the community, updated monthly, that > lists the percentage of "REFUSED RESPONSE" POCs, the percentage of POCs > that accept e-mails, and the percentage of POC addresses that have not > responded but have not yet been notified by paper mail or telephone. > > Rationale: > > As the entire Internet community gets closer to the date that IPv4 will > be exhausted, more attention is being focused on the possibility that > there is significant amounts of allocated IPv4 that is abandoned. There > are also concerns that as the amount of usable IPv4 space gets more and > more crowded, that Internet criminals are turning to abandoned IPv4 > space that is still listed as allocated in the whois directories to use > to make attacks on hosts on the Internet. Because of these reasons, it > is becoming more important that users of ARIN's whois data have a > reasonable expectation that it is accurate. > > The current NRPM has a mechanism for adding, modifying, and deleting > POCs. However it also carries an assumption that POCs belonging to > defunct companies will be removed when the bills for allocated IP > addressing cease being paid, and the address resources are then returned > to the ARIN pool as a result. The problem is that this assumption does > not hold true for so-called "Legacy" IP address holders since they do > not pay a yearly fee. Furthermore, billing for the IP addressing > allocations is done through paper mail, thus it is possible for a POC to > have a valid street address, but an invalid E-mail address, and not be > caught because they are current on their account. This is becoming a > serious issue because contacting a POC via a street address is too slow > for victims of an attack from a hijacked IP block to be able to complain > to the block owners and the block owners to be able to catch the > perpetrators. > > Timetable for implementation: Immediate > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- Chris Grundemann www.linkedin.com/in/cgrundemann -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Thu Aug 21 15:25:27 2008 From: bill at herrin.us (William Herrin) Date: Thu, 21 Aug 2008 15:25:27 -0400 Subject: [arin-ppml] LRSA concerns (Re: Policy Proposal: Whois Integrity Policy Proposal) In-Reply-To: <30601.1219332861@nsa.vix.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> <48ACA684.2090208@rancid.berkeley.edu> <3c3e3fca0808201726l7e021ffakb53df5eedac8acbb@mail.gmail.com> <99772.1219282684@nsa.vix.com> <3c3e3fca0808202013n65bf8bc8tae50417451e629f6@mail.gmail.com> <30601.1219332861@nsa.vix.com> Message-ID: <3c3e3fca0808211225j38f4a6f3u7aac16bfc4371ad5@mail.gmail.com> On Thu, Aug 21, 2008 at 11:34 AM, Paul Vixie wrote: > arguments of the form "LRSA is bad because of its inseverability" boil down > to "i as a legacy holder do not want my use of this resource to be governed > unless i happen to like the direction that governance is taking me" Paul, Governance? Is that what the LRSA is about? I thought LRSA was about normalizing the relationship between ARIN and the resource holders who predate it, authenticating the resources (to fight hijacking) and getting those holders to pay a fair share of the whois/rdns operations cost. Perhaps asking for the LRSA to also be about governance pushes the legacy registrants further than they're currently willing to go. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Lee.Howard at stanleyassociates.com Thu Aug 21 15:40:13 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 21 Aug 2008 15:40:13 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9011DCA61@SUEXCL-02.ad.syr.edu> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B06188E@CL-S-EX-1.stanleyassociates.com> > "Trust me" arguments have no place in global governance > processes. That's why we need contracts. > If you > don't sign a contract with ARIN, what's your alternative? You propose a competitive RIR structure? Wouldn't that inherently generate a "race to the bottom" of least responsible allocation policies? > I suspect they are more concerned about the application of > "justified need" standards that would take away addresses > they currently have the option to use, Does this cover that issue? 10.(b) ARIN will take no action to reduce the services provided for Included Number Resources that are not currently being utilized by the Legacy Applicant. > or which would prevent them from selling them. That's going into a completely different policy proposal. Is your concern that [if a legacy holder signs the LRSA, and if a liberalized transfer policy passes,] the legacy holder may not be able to get as high a price, because they could only transfer to an organization that can demonstrate need? If so--is that why your organization was allocated those addresses in the first place? > > Milton Mueller Lee From vixie at isc.org Thu Aug 21 16:22:07 2008 From: vixie at isc.org (Paul Vixie) Date: Thu, 21 Aug 2008 20:22:07 +0000 Subject: [arin-ppml] LRSA concerns (Re: Policy Proposal: Whois Integrity Policy Proposal) In-Reply-To: Your message of "Thu, 21 Aug 2008 15:25:27 -0400." <3c3e3fca0808211225j38f4a6f3u7aac16bfc4371ad5@mail.gmail.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> <48ACA684.2090208@rancid.berkeley.edu> <3c3e3fca0808201726l7e021ffakb53df5eedac8acbb@mail.gmail.com> <99772.1219282684@nsa.vix.com> <3c3e3fca0808202013n65bf8bc8tae50417451e629f6@mail.gmail.com> <30601.1219332861@nsa.vix.com> <3c3e3fca0808211225j38f4a6f3u7aac16bfc4371ad5@mail.gmail.com> Message-ID: <83829.1219350127@nsa.vix.com> > Governance? Is that what the LRSA is about? no. LRSA is about many things. but it's impossible to see ARIN's actions as not being related to its charter, in which the word "stewardship" figures prominently. > I thought LRSA was about normalizing the relationship between ARIN and > the resource holders who predate it, authenticating the resources (to > fight hijacking) and getting those holders to pay a fair share of the > whois/rdns operations cost. it is. (also.) > Perhaps asking for the LRSA to also be about governance pushes the > legacy registrants further than they're currently willing to go. not this legacy holder. perhaps you as a legacy holder have different goals than some others, and perhaps your goals are incompatible with governance, but i don't think that you should attempt to generalize that position. let's do an actual survey and find out what's generally believed about this topic. again, speaking for myself as CEO of $dayjob and a legacy holder, the reason that i signed the LRSA was that i know i only "have" these addresses because the community chooses to recognize and protect my unique allocation of same, and i wasn't willing to say "since there's a loophole that makes me untouchable by some current policies, i'll live like i am until the community either decides to come after me or stop protecting me." in other words, to want differential rights between legacy and RSA, i would have had to set my interests apart from the community's interests, while at the same time depending on the community to go on protecting my interests. bad juju. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From mueller at syr.edu Thu Aug 21 16:44:17 2008 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 21 Aug 2008 16:44:17 -0400 Subject: [arin-ppml] LRSA concerns (Re: Policy Proposal: Whois IntegrityPolicy Proposal) In-Reply-To: <3c3e3fca0808211225j38f4a6f3u7aac16bfc4371ad5@mail.gmail.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <48AB13CD.2030903@psg.com><84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu><1698.1219180000@nsa.vix.com> <48ACA684.2090208@rancid.berkeley.edu><3c3e3fca0808201726l7e021ffakb53df5eedac8acbb@mail.gmail.com><99772.1219282684@nsa.vix.com><3c3e3fca0808202013n65bf8bc8tae50417451e629f6@mail.gmail.com><30601.1219332861@nsa.vix.com> <3c3e3fca0808211225j38f4a6f3u7aac16bfc4371ad5@mail.gmail.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9011DCA69@SUEXCL-02.ad.syr.edu> Bill: I don't see a meaningful distinction between "normalizing the relationship" and "governance," if "normalization" includes signing a legally binding contract that gives the signatory both entitlements (an authenticated claim on resource use) and obligations (e.g., to pay a fair share of ARIN costs). Maybe you find the G-word scary, I can understand that, but people coming from political science, economics and organizational theory use the term to mean the same thing you seem to mean by "normalizing the relationship." But maybe the term means something different to you. Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org > -----Original Message----- > Governance? Is that what the LRSA is about? > > I thought LRSA was about normalizing the relationship between ARIN and > the resource holders who predate it, authenticating the resources (to > fight hijacking) and getting those holders to pay a fair share of the > whois/rdns operations cost. > > Perhaps asking for the LRSA to also be about governance pushes the > legacy registrants further than they're currently willing to go. > > Regards, > Bill Herrin > > From bill at herrin.us Thu Aug 21 18:19:25 2008 From: bill at herrin.us (William Herrin) Date: Thu, 21 Aug 2008 18:19:25 -0400 Subject: [arin-ppml] LRSA concerns (Re: Policy Proposal: Whois Integrity Policy Proposal) In-Reply-To: <83829.1219350127@nsa.vix.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> <48ACA684.2090208@rancid.berkeley.edu> <3c3e3fca0808201726l7e021ffakb53df5eedac8acbb@mail.gmail.com> <99772.1219282684@nsa.vix.com> <3c3e3fca0808202013n65bf8bc8tae50417451e629f6@mail.gmail.com> <30601.1219332861@nsa.vix.com> <3c3e3fca0808211225j38f4a6f3u7aac16bfc4371ad5@mail.gmail.com> <83829.1219350127@nsa.vix.com> Message-ID: <3c3e3fca0808211519u617ad455n878d9992660ed362@mail.gmail.com> On Thu, Aug 21, 2008 at 4:22 PM, Paul Vixie wrote: > community either decides to come after me or stop protecting me." in other > words, to want differential rights between legacy and RSA, i would have had > to set my interests apart from the community's interests, while at the same > time depending on the community to go on protecting my interests. bad juju. Paul, Legacy resource holders don't rely on anything so amorphous as "The Community" to protect their interests. They rely on finding one or two companies in a competitive market willing to announce their route, on the fact that they have a legal basis on which to use that route (the addresses were formally assigned to them) and on the lack of any legal basis for anyone other than them (especially ARIN) to challenge that announcement. At any rate, you asked what fix I would make to the LRSA to bring in more legacy registrants and I gave you my best answers. Like 'em or lump 'em. On Thu, Aug 21, 2008 at 4:44 PM, Milton L Mueller wrote: > I don't see a meaningful distinction between "normalizing the > relationship" and "governance," if "normalization" includes signing a > legally binding contract that gives the signatory both entitlements (an > authenticated claim on resource use) and obligations (e.g., to pay a > fair share of ARIN costs). Milton, I'll defer to your definition and restate my comment: Perhaps insisting that the LRSA include terms and conditions for which there is not a strong consensus pushes the legacy registrants further than they're willing to go. I believe there is a strong consensus that it's in everyone's interest for the legacy holders to normalize their relationship with ARIN at least as much as they're willing to. I believe there is a strong consensus that all active resources should be authenticated in order to fight hijacking. I believe there is a strong consensus that in order to receive whois and rdns service, the legacy registrants should pay a fair share of the whois and rdns operations cost. Perhaps an LRSA would be more effective if it focused on those consensus issues alone and left questions about ownership, utilization, revocation, force majeure, et cetera for some other day. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jis at mit.edu Thu Aug 21 18:32:53 2008 From: jis at mit.edu (Jeffrey I. Schiller) Date: Thu, 21 Aug 2008 18:32:53 -0400 Subject: [arin-ppml] LRSA concerns (Re: Policy Proposal: Whois Integrity Policy Proposal) In-Reply-To: <3c3e3fca0808211225j38f4a6f3u7aac16bfc4371ad5@mail.gmail.com> References: <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> <48ACA684.2090208@rancid.berkeley.edu> <3c3e3fca0808201726l7e021ffakb53df5eedac8acbb@mail.gmail.com> <99772.1219282684@nsa.vix.com> <3c3e3fca0808202013n65bf8bc8tae50417451e629f6@mail.gmail.com> <30601.1219332861@nsa.vix.com> <3c3e3fca0808211225j38f4a6f3u7aac16bfc4371ad5@mail.gmail.com> Message-ID: <20080821223253.GB14008@mit.edu> I've attached a message a sent to the ppml list back last October. From what I can tell, no one ever responded publicly to it (I did receive a private reply). I proposed then that a good first step to get legacy holders into the "tent" would be a milder contract that didn't put their "rights" (whatever they may be now or determined in the future) on the line. From what I have read and seen, one of the more egregious clauses in the LRSA is the one where you lose your address space when the contract terminates, for whatever reason. There are other problems as well, but I won't go into detail here (others have, I don't need to repeat them!). Perhaps a more middle ground between the current LRSA and my proposal of no discussion of address blocks would be something that would: o Bind the registrant to not sell or transfer their address blocks outside of an ARIN sanctioned process (this is one of the elephants in the room!). o Bind ARIN to not revoke legacy addresses (which the LRSA does today). o Arrange for the registrant to pay their fair share of ARIN costs (the LRSA does this). o Isn't terminated based on issues that have nothing to do with address assignment (like claimed violations of law, more on this later). o Is in some way non-revocable. What I mean here is that the registrant shouldn't be able to decide to void the agreement and walk away because they want to do something prohibited by the contract (like sell address space) *and* ARIN shouldn't be able to revoke a legacy address by wiggling out of the agreement. The registrant should feel secure in their continued use of address space and ARIN should feel secure in that the registrant will abide by the agreement. I'm not enough of a lawyer (heck, I am not even a lawyer at all) to come up with the language. I believe the key here is that the legacy registrant needs to be secure in their continued use of "their" address space. The current LRSA falls short on this score. So, how do we move forward on this score? Do I hire an attorney and develop a replacement LRSA. Is there a way to get the ARIN Board to consider changes to the LRSA without doing so (I would propose wording changes myself, but then I am not a competent attorney). I'm interested in guidance here. So about claimed violations of law... (feel free to stop reading now if you are not interested in this aspect of things). The problem with terminating the agreement on violations of law is that sometimes the law is wrong and the way to demonstrate it is to violate it and go to court. A number of years ago MIT was actually convicted of violating the Sherman Anti-Trust Act by participating in what was called the Overlap Group. The Overlap Group was a group of college financial aid administrators who arranged for students who applied to their colleges (thus they "overlapped") to receive a similar aid package from each school that they applied to (from the group). This was a benefit to society because it permitted students to select a school based on academics rather then the best aid package. It also permitted limited donations (where the financial aid sometimes comes from) to be stretched over a larger number of students. In some cases this was necessary for schools to offer "need blind admissions." The government viewed this as illegal price fixing and went to prosecute the member schools. All but one negotiated a consent decree. MIT was the one that wouldn't. We stood on principal and went to court. We were convicted. We appealed and the appellate court threw out the conviction and remanded the lower court to try again. At that point the government punted. My point: When we were convicted, it would have really been unpleasant to then loose our address block. Frankly what the heck does our address allocation have to do with this? Nothing, so it shouldn't be part of the equation. Sorry for the length. -Jeff On Thu, Aug 21, 2008 at 03:25:27PM -0400, William Herrin wrote: > Perhaps asking for the LRSA to also be about governance pushes the > legacy registrants further than they're currently willing to go. -- ======================================================================== Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis at mit.edu ======================================================================== -------------- next part -------------- An embedded message was scrubbed... From: Jeffrey Schiller Subject: Re: [ppml] Posting of Legacy RSA and FAQ Date: Sun, 14 Oct 2007 16:09:31 -0400 Size: 2494 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From Matthew.Wilder at telus.com Thu Aug 21 18:59:25 2008 From: Matthew.Wilder at telus.com (Matthew Wilder) Date: Thu, 21 Aug 2008 15:59:25 -0700 Subject: [arin-ppml] LRSA concerns (Re: Policy Proposal: Whois IntegrityPolicy Proposal) In-Reply-To: <3c3e3fca0808211519u617ad455n878d9992660ed362@mail.gmail.com> References: <20080819172716.2FFF74501A@ptavv.es.net><48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com><48ACA684.2090208@rancid.berkeley.edu><3c3e3fca0808201726l7e021ffakb53df5eedac8acbb@mail.gmail.com><99772.1219282684@nsa.vix.com><3c3e3fca0808202013n65bf8bc8tae50417451e629f6@mail.gmail.com><30601.1219332861@nsa.vix.com><3c3e3fca0808211225j38f4a6f3u7aac16bfc4371ad5@mail.gmail.com><83829.1219350127@nsa.vix.com> <3c3e3fca0808211519u617ad455n878d9992660ed362@mail.gmail.com> Message-ID: <4C80F17364FE2E4C93053BE9D01DB479094CE9A7@BCMSG111.corp.ads> On Thu, Aug 21, 2008 at 3:21 PM, William Herrin wrote: > Perhaps an LRSA would be more effective if it focused on those consensus > issues alone and left questions about ownership, utilization, revocation, > force majeure, et cetera for some other day. Bill, I am new to the PPML and so I have not experienced the historical progress of these policies as clearly many others here have. I also benefit in this regard by having the neutrality of a bystander. I believe your suggestions around acting on the consensus issues is wise, as it offers a compelling "risk-free" agreement to Legacy resource holders, which could be embodied in an LSRA-Lite agreement as previously suggested. Perhaps this is a good step forward. At the same time, I am at a loss as I try to understand the mentality of someone who believes that any kind of resource like IP Addresses could be under the ownership of anyone other than the governing bodies, in this case ARIN or at least AINA. If it is unclear that ARIN or AINA have "ownership" of IP Address resources, I am sure there is even less evidence that legacy holders have any legal ownership of the resource. In a legal grey area like that, who do you think an arbitrator would indicate as the owner of the resource? Would it be the person who had an IP Address "assigned" to them 15 years ago or the governing bodies which oversee and allocate those resources? I know where I would put my money, so even in the absence of good faith (which seems to be the case to a degree) I would be compelled (as a legacy holder) to view the resources as under the ownership of ARIN and AINA. Regards, Matthew Wilder -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Thursday, August 21, 2008 3:19 PM To: Paul Vixie Cc: Randy Bush; arin-ppml at arin.net Subject: Re: [arin-ppml] LRSA concerns (Re: Policy Proposal: Whois IntegrityPolicy Proposal) On Thu, Aug 21, 2008 at 4:22 PM, Paul Vixie wrote: > community either decides to come after me or stop protecting me." in > other words, to want differential rights between legacy and RSA, i > would have had to set my interests apart from the community's > interests, while at the same time depending on the community to go on protecting my interests. bad juju. Paul, Legacy resource holders don't rely on anything so amorphous as "The Community" to protect their interests. They rely on finding one or two companies in a competitive market willing to announce their route, on the fact that they have a legal basis on which to use that route (the addresses were formally assigned to them) and on the lack of any legal basis for anyone other than them (especially ARIN) to challenge that announcement. At any rate, you asked what fix I would make to the LRSA to bring in more legacy registrants and I gave you my best answers. Like 'em or lump 'em. On Thu, Aug 21, 2008 at 4:44 PM, Milton L Mueller wrote: > I don't see a meaningful distinction between "normalizing the > relationship" and "governance," if "normalization" includes signing a > legally binding contract that gives the signatory both entitlements > (an authenticated claim on resource use) and obligations (e.g., to pay > a fair share of ARIN costs). Milton, I'll defer to your definition and restate my comment: Perhaps insisting that the LRSA include terms and conditions for which there is not a strong consensus pushes the legacy registrants further than they're willing to go. I believe there is a strong consensus that it's in everyone's interest for the legacy holders to normalize their relationship with ARIN at least as much as they're willing to. I believe there is a strong consensus that all active resources should be authenticated in order to fight hijacking. I believe there is a strong consensus that in order to receive whois and rdns service, the legacy registrants should pay a fair share of the whois and rdns operations cost. Perhaps an LRSA would be more effective if it focused on those consensus issues alone and left questions about ownership, utilization, revocation, force majeure, et cetera for some other day. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From oberman at es.net Thu Aug 21 19:16:17 2008 From: oberman at es.net (Kevin Oberman) Date: Thu, 21 Aug 2008 16:16:17 -0700 Subject: [arin-ppml] Legacy RSA (was: Whois Integrity Policy Proposal) In-Reply-To: Your message of "Thu, 21 Aug 2008 12:47:57 EDT." <369EB04A0951824ABE7D8BAC67AF9BB40B0615CE@CL-S-EX-1.stanleyassociates.com> Message-ID: <20080821231617.1B6C84500F@ptavv.es.net> > Date: Thu, 21 Aug 2008 12:47:57 -0400 > From: "Howard, W. Lee" > Sender: arin-ppml-bounces at arin.net > > > > > -----Original Message----- > > From: Craig Finseth [mailto:craig.finseth at state.mn.us] > > Sent: Thursday, August 21, 2008 11:51 AM > > To: Howard, W. Lee > > Cc: heather.skanks at gmail.com; arin-ppml at arin.net > > Subject: Re: [arin-ppml] Legacy RSA (was: Whois Integrity > > Policy Proposal) > > > > ... > > Not an issue. ARIN can't prevent you from breaking the > > law with those > > addresses (i.e., we don't control your content), but it > > would be bad for > > ARIN to continue providing service to an entity knowing > > they had used > > that service to break the law. > > ... > > > > Does ARIN really want to be in the business of investigating crimes? > > Absolutely not, and I don't advocate that. > > The scenario provided was, 4.d.ii, "(ii) be found to have violated any > applicable laws, statutes or regulations by a ruling of a court or > government regulatory agency." > > This is further clarified in the same paragraph: "A definitive finding > of a violation of law or regulation when established by a decision of a > national, state, or other government authority regarding (i) through > (iii) herein should similarly be sent to ARIN's General Counsel for > ARIN's review and action." This begs the question of "Who's law?" There are businesses (on-line casinos) operating completely legally in some ARIN countries which are considered illegal by the US and, if the owners of those companies set foot in the US, they are subject to arrest and some have been arrested, convicted and imprisoned. Even within the US, there are businesses that are explicitly legal under state laws in many states and illegal under federal laws. (I'm talking about medicinal pot). Does ARIN really want to get into this tar pit? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From tvest at pch.net Thu Aug 21 19:38:23 2008 From: tvest at pch.net (Tom Vest) Date: Thu, 21 Aug 2008 19:38:23 -0400 Subject: [arin-ppml] Policy Proposal: Whois Integrity Policy Proposal In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40B06188E@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB40B06188E@CL-S-EX-1.stanleyassociates.com> Message-ID: On Aug 21, 2008, at 3:40 PM, Howard, W. Lee wrote: > >> "Trust me" arguments have no place in global governance >> processes. > > That's why we need contracts. > >> If you >> don't sign a contract with ARIN, what's your alternative? > > You propose a competitive RIR structure? Wouldn't that > inherently generate a "race to the bottom" of least responsible > allocation policies? It's good question I think -- in fact it was the main question I raised when I debated Milton about his first paper on mechanism competition for IP address distribution, back in early 2005: 7.2005 Competition in IPv6 Addressing: A Review of the Debate http://internetgovernance.org/pdf/igp-v6.pdf An IFG-sponsored online debate covering this issue took place on April 22, 2005: http://lists.cpsr.org/lists/arc/governance/2005-04/msg00110.html http://internetgovernance.org/events.html "Online Global Forum on ICANN Reform" http://cotelco-server.syr.edu:8080/recordings.html?start_date=20050422&end_date=20050422 However, if I recall correctly much of the live debate merely recapped several related exchanges on the CPSR's "Internet Governance" mailing list, e.g., http://lists.cpsr.org/lists/arc/governance/2005-04/msg00069.html http://lists.cpsr.org/lists/arc/governance/2005-04/msg00072.html http://lists.cpsr.org/lists/arc/governance/2005-04/msg00074.html http://lists.cpsr.org/lists/arc/governance/2005-04/msg00085.html http://lists.cpsr.org/lists/arc/governance/2005-04/msg00104.html TV >> I suspect they are more concerned about the application of >> "justified need" standards that would take away addresses >> they currently have the option to use, > > Does this cover that issue? > 10.(b) ARIN will take no action to reduce the services provided for > Included Number Resources that are not currently being utilized by the > Legacy Applicant. > > >> or which would prevent them from selling them. > > That's going into a completely different policy proposal. > Is your concern that [if a legacy holder signs the LRSA, and if a > liberalized transfer policy passes,] the legacy holder may not > be able to get as high a price, because they could only transfer to > an organization that can demonstrate need? If so--is that why > your organization was allocated those addresses in the first place? > > >> >> Milton Mueller > > > Lee > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From bill at herrin.us Thu Aug 21 19:54:09 2008 From: bill at herrin.us (William Herrin) Date: Thu, 21 Aug 2008 19:54:09 -0400 Subject: [arin-ppml] LRSA concerns (Re: Policy Proposal: Whois IntegrityPolicy Proposal) In-Reply-To: <4C80F17364FE2E4C93053BE9D01DB479094CE9A7@BCMSG111.corp.ads> References: <20080819172716.2FFF74501A@ptavv.es.net> <48ACA684.2090208@rancid.berkeley.edu> <3c3e3fca0808201726l7e021ffakb53df5eedac8acbb@mail.gmail.com> <99772.1219282684@nsa.vix.com> <3c3e3fca0808202013n65bf8bc8tae50417451e629f6@mail.gmail.com> <30601.1219332861@nsa.vix.com> <3c3e3fca0808211225j38f4a6f3u7aac16bfc4371ad5@mail.gmail.com> <83829.1219350127@nsa.vix.com> <3c3e3fca0808211519u617ad455n878d9992660ed362@mail.gmail.com> <4C80F17364FE2E4C93053BE9D01DB479094CE9A7@BCMSG111.corp.ads> Message-ID: <3c3e3fca0808211654s4cc73fb6ld821d753adf3280c@mail.gmail.com> On Thu, Aug 21, 2008 at 6:59 PM, Matthew Wilder wrote: > At the same time, I am at a loss as I try to understand > the mentality of someone who believes that any kind of > resource like IP Addresses could be under the ownership > of anyone other than the governing bodies, in this case > ARIN or at least [IANA]. Hi Matthew, The law recognizes physical items as property as well as a very narrow set of intangible items. IP addresses are not one of the intangibles recognized as property, hence they are not property. That's a double-edged sword because if they're not property then neither ARIN nor IANA nor any governing body can own them either. Thus it breaks into two main questions: 1. Rights to to use, such as by announcing addresses via BGP 2. Rights to receive related services, such as whois or rdns from ARIN #2 is more or less settled: your sole rights to receive services like rdns arise under your contract with ARIN. No contract, no rights. ARIN continues providing DNS to legacy registrants anyway because if they stopped before bringing the vast majority of legacy registrants under a contract, there'd be political hell to pay. #1 is problematic. Since the late '90s, everyone who has "received" IP addresses has received them under a legal contract, the Registration Services Agreement. The RSA spells out the registrants rights with respect to the resources (very few and very specific) and that's the start and end of the story. There is a gentlemen's agreement between ISPs (completely outside ARIN's scope) not to announce routes that folks pluck from the ether without a registration and it's likely that intentionally attempting to use someone else's IP addresses would run afoul of computer fraud statutes and as well as civil problems like tortious interference. ARIN got the authority to do this by virtue of the fact that network solutions decided to stop. Later they negotiated contracts with IANA/ICANN and normalized the arrangement into something pretty solid. Prior to ARIN's inception, IP addresses were assigned by various other entities, the last one being Network Solutions. These "legacy" assignments were no-promises-made and no-strings-attached. These are your numbers for use with the TCP/IP protocol. They are unique from any others. Have fun. The gentlemen's agreement between ISPs (over which ARIN has no control) extends to routing those addresses for the respective assignees as well. The key thing to understand here is this: ARIN probably has no legal standing in this part of the picture at all. The original assignees appear to have some legal standing with respect to control of the addresses but because of the shifting legal landscape behind the scenes and the internationalization of the Internet, it's not entirely clear who else does. It is entirely plausible that no one else does. Now, this issue -could- be resolved legislatively. The US Congress could pass a law stating that Department of Commerce is directed to contract someone to assign all number resources permitted to be used on Internet-connected networks in the United States. DOC would then assign that authority to ICANN who would assign it to IANA who would assign it to ARIN. The legacy registrant's standing with respect to the legacy address ranges would be moot and because addresses weren't property to begin with, their rights have not been violated. However, it is not in ARIN's best interest to take this course of action. You see, ARIN's authority doesn't currently derive from ICANN or the US Government. It's independent and it maintains it's prominence through contracts it has negotiated favorably with ICANN and through the ongoing ISP gentlemen's agreement. In essence, ARIN's relationship with ICANN and the USG is a whole lot like the legacy registrants' relationship with ARIN. They have authority over the number resources only because nobody else does. As a result, ARIN has near complete autonomy, which they've used to great effect. They never have to answer to Senator Ted "Tubes" Stevens. They're able to implement an operations process that's very close to the technical community they serve without having to worry about interference from the politically well-connected or financially powerful. Which IMHO is fantastic and ARIN has done a great job. But it does mean that the legacy registrants retain essentially indisputable control over their pre-ARIN address assignments, a reality that the rest of the community is stuck with if they want to retain the advantage of ARIN's autonomy. And IMO it would be better for all involved if we bowed to that reality and tried to focus our actions on the improvements where we actually do have consensus. It isn't about what's fair or unfair, it's about what achieves the best result both individually and for the community as a whole. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mueller at syr.edu Fri Aug 22 00:01:20 2008 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 22 Aug 2008 00:01:20 -0400 Subject: [arin-ppml] LRSA concerns (Re: Policy Proposal: WhoisIntegrityPolicy Proposal) References: <20080819172716.2FFF74501A@ptavv.es.net><48ACA684.2090208@rancid.berkeley.edu><3c3e3fca0808201726l7e021ffakb53df5eedac8acbb@mail.gmail.com><99772.1219282684@nsa.vix.com><3c3e3fca0808202013n65bf8bc8tae50417451e629f6@mail.gmail.com><30601.1219332861@nsa.vix.com><3c3e3fca0808211225j38f4a6f3u7aac16bfc4371ad5@mail.gmail.com><83829.1219350127@nsa.vix.com><3c3e3fca0808211519u617ad455n878d9992660ed362@mail.gmail.com><4C80F17364FE2E4C93053BE9D01DB479094CE9A7@BCMSG111.corp.ads> <3c3e3fca0808211654s4cc73fb6ld821d753adf3280c@mail.gmail.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9018841BF@SUEXCL-02.ad.syr.edu> -----Original Message----- >In essence, ARIN's relationship with ICANN and the USG is a whole lot >like the legacy registrants' relationship with ARIN. They have >authority over the number resources only because nobody else does. Astute observation! And as you noted, ARIN and the NRO (and later, the ccTLDs via the ccNSO) were able to negotiate favorable agreements with ICANN because they had legacy rights over resources that no one dared to usurp unilaterally. It was not about what you call "strong consensus," it would be more accurate to say that it was about more equal _bargaining power_ between the parties. So even though the rationalist and justice advocate in me tells me that the lack of uniformity of rights across legacy and RSA signatories is dodgy and inefficient and troublesome, it also acts as an important centrifugal force that prevents ARIN or other RIRs from becoming a much too integrated and centralized governance authority. Which is (probably) good. >As a result, ARIN has near complete autonomy, So how long do you think it will be before that ends? ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From vixie at isc.org Fri Aug 22 11:35:01 2008 From: vixie at isc.org (Paul Vixie) Date: Fri, 22 Aug 2008 15:35:01 +0000 Subject: [arin-ppml] LRSA concerns (Re: Policy Proposal: Whois Integrity Policy Proposal) In-Reply-To: Your message of "Thu, 21 Aug 2008 18:19:25 -0400." <3c3e3fca0808211519u617ad455n878d9992660ed362@mail.gmail.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> <48ACA684.2090208@rancid.berkeley.edu> <3c3e3fca0808201726l7e021ffakb53df5eedac8acbb@mail.gmail.com> <99772.1219282684@nsa.vix.com> <3c3e3fca0808202013n65bf8bc8tae50417451e629f6@mail.gmail.com> <30601.1219332861@nsa.vix.com> <3c3e3fca0808211225j38f4a6f3u7aac16bfc4371ad5@mail.gmail.com> <83829.1219350127@nsa.vix.com> <3c3e3fca0808211519u617ad455n878d9992660ed362@mail.gmail.com> Message-ID: <53531.1219419301@nsa.vix.com> > From: "William Herrin" > > On Thu, Aug 21, 2008 at 4:22 PM, Paul Vixie wrote: > > ... community either decides to come after me or stop protecting me." > > in other words, to want differential rights between legacy and RSA, i > > would have had to set my interests apart from the community's > > interests, while at the same time depending on the community to go on > > protecting my interests. bad juju. > > Legacy resource holders don't rely on anything so amorphous as "The > Community" to protect their interests. They rely on finding one or two > companies in a competitive market willing to announce their route, on the > fact that they have a legal basis on which to use that route (the > addresses were formally assigned to them) and on the lack of any legal > basis for anyone other than them (especially ARIN) to challenge that > announcement. i think you're wrong. you're relying on a lot of people to accept your route indirectly, which they do because it's in their best interests. the slot you need in every router on the planet costs a microinvestment from everybody. as RBN discovered, there is no guaranty of third party service. but more than the slot you want to occupy, consider the slots you want others to be able to occupy. policies designed to limit deaggregation are helping keep the internet stable enough so that other people actually have routers and those other router-owners aren't just gigantic telecoms with deep capital pockets and draconian peering policies. consider also the current lack of route origination security -- if you have a /18 and someone somewhere wants to steal it with a couple of /19's your present recourse is to ask the community to honour your assignment over the competing ones. which the community is likely to do because that's how things have always worked. in the future there may be digital certificates on route origination, which i expect to be funded and operated through the RIR system rather than through the kind of bilateral business arrangements you described. but, if you're willing to ask for that kind of support from nameless others while simultaneously withholding the legacy address space you use from the kind of stewardship the community practices through the RIR system, that's between you and your gods, and i can't think that this forum will benefit from us arguing it further. > At any rate, you asked what fix I would make to the LRSA to bring in > more legacy registrants and I gave you my best answers. Like 'em or > lump 'em. i wonder if you found jeff schiller's suggestions to be on-target? his were more specific than yours, and if they represent your position, it would be helpful to know this. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From dwcarder at wisc.edu Fri Aug 22 11:21:44 2008 From: dwcarder at wisc.edu (Dale W. Carder) Date: Fri, 22 Aug 2008 10:21:44 -0500 Subject: [arin-ppml] LRSA concerns (Re: Policy Proposal: Whois Integrity Policy Proposal) In-Reply-To: <20080821223253.GB14008@mit.edu> References: <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> <48ACA684.2090208@rancid.berkeley.edu> <3c3e3fca0808201726l7e021ffakb53df5eedac8acbb@mail.gmail.com> <99772.1219282684@nsa.vix.com> <3c3e3fca0808202013n65bf8bc8tae50417451e629f6@mail.gmail.com> <30601.1219332861@nsa.vix.com> <3c3e3fca0808211225j38f4a6f3u7aac16bfc4371ad5@mail.gmail.com> <20080821223253.GB14008@mit.edu> Message-ID: <17DE08BC-2D90-4146-A9A8-C1D284C4C896@wisc.edu> On Aug 21, 2008, at 5:32 PM, Jeffrey I. Schiller wrote: > > I proposed then that a good first step to get legacy holders into the > "tent" would be a milder contract that didn't put their "rights" > (whatever they may be now or determined in the future) on the line. I agree with this approach. If we all think that whois needs to be updated and this can't be done without a contract, could a contract specific to whois maintenance be written as Jeff outlined without the things that legacy holders are clearly concerned about in the current LRSA? LRSA-lite could be a lot easier for legacy holders to swallow. As v4 runout gets closer, I worry about increased hijacking. The value of database maintenance will then be clear to everyone. Dale From jmorrison at bogomips.com Fri Aug 22 13:27:09 2008 From: jmorrison at bogomips.com (John Paul Morrison) Date: Fri, 22 Aug 2008 10:27:09 -0700 Subject: [arin-ppml] LRSA concerns (Re: Policy Proposal: Whois Integrity Policy Proposal) In-Reply-To: <17DE08BC-2D90-4146-A9A8-C1D284C4C896@wisc.edu> References: <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> <48ACA684.2090208@rancid.berkeley.edu> <3c3e3fca0808201726l7e021ffakb53df5eedac8acbb@mail.gmail.com> <99772.1219282684@nsa.vix.com> <3c3e3fca0808202013n65bf8bc8tae50417451e629f6@mail.gmail.com> <30601.1219332861@nsa.vix.com> <3c3e3fca0808211225j38f4a6f3u7aac16bfc4371ad5@mail.gmail.com> <20080821223253.GB14008@mit.edu> <17DE08BC-2D90-4146-A9A8-C1D284C4C896@wisc.edu> Message-ID: <48AEF6ED.5000603@bogomips.com> On 8/22/2008 8:21 AM, Dale W. Carder wrote: > On Aug 21, 2008, at 5:32 PM, Jeffrey I. Schiller wrote: > >> I proposed then that a good first step to get legacy holders into the >> "tent" would be a milder contract that didn't put their "rights" >> (whatever they may be now or determined in the future) on the line. >> > > I agree with this approach. > I agree as well. It's also justifiable in terms of paying a registrar for domain and reverse DNS. I have no problem paying $10 a year or whatever to godaddy for a dot com registration, so I have no opposition to paying to an in-addr.arpa registrar, who could provide whois and registrar services at a competitive rate. Just as dot com registration was once free and was converted to pay as you go, so can in-addr.arpa for legacy registrants. Perhaps this can side-step some of the opposition to legacy changes. Most of this could leverage existing registrar, domain registration and whois infrastructure. So legacy holders can pay their way for the registration infrastructure, while any questions of "ownership" or legitimacy can be sorted out separately, or they can simply whither on the vine with IPv6 approaching. > If we all think that whois needs to be updated and this can't be > done without a contract, could a contract specific to whois > maintenance be written as Jeff outlined without the things that > legacy holders are clearly concerned about in the current LRSA? > > LRSA-lite could be a lot easier for legacy holders to swallow. > As v4 runout gets closer, I worry about increased hijacking. > The value of database maintenance will then be clear to everyone. > > Dale > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From george at dmu.edu Fri Aug 22 14:33:14 2008 From: george at dmu.edu (Davey, George) Date: Fri, 22 Aug 2008 13:33:14 -0500 Subject: [arin-ppml] Whois Integrity Policy Proposal In-Reply-To: <48AEF6ED.5000603@bogomips.com> References: <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> <48ACA684.2090208@rancid.berkeley.edu> <3c3e3fca0808201726l7e021ffakb53df5eedac8acbb@mail.gmail.com> <99772.1219282684@nsa.vix.com> <3c3e3fca0808202013n65bf8bc8tae50417451e629f6@mail.gmail.com> <30601.1219332861@nsa.vix.com> <3c3e3fca0808211225j38f4a6f3u7aac16bfc4371ad5@mail.gmail.com> <20080821223253.GB14008@mit.edu> <17DE08BC-2D90-4146-A9A8-C1D284C4C896@wisc.edu> <48AEF6ED.5000603@bogomips.com> Message-ID: Legacy agreements make no mention of DNS or email requirements. Legacy holders are under no obligation to please ARIN. This would be yet another attempt to force people in legacy agreements to sign an updated agreement and they should not be bullied into doing so. The Hobbs Act of 1951 addressed this type of unfair pressure to force people to change contractual rights out of fear of losing intangible properties acquired under an allocation contract. I feel firm that any attempt to bully legacy holders to sign anything is both unlawful and unnecessary. It is especially unnecessary harassment. What troubles me the most is the ease at which people will form a Lynch mob to strip others of rights they cannot share because they were not there at the time that particular right was established. Most of the victims are na?ve or have not had proper legal counsel advising them of their contractual rights. The legacy agreements did not have a clause giving ANY governing body the right to discuss or pressure them into changing their contract to please ARIN, ICANN, or IANA. In my opinion it is a democratic socialist movement to make everyone the same by force of fear of losing the space fairly allocated to them in the legacy time. There are many ways each of us can make the Internet a better place, forcing people to sign contracts by force of fear is not one of them. I do not support this policy at this time because I think it clearly has a hidden agenda and will not stop spammers or even slow them down. [cid:image001.gif at 01C90458.29CA5990] George Davey, B.S. MCSE Network Administrator 3200 Grand Avenue Des Moines, IA 50312 515.271.1544 FAX 515.271.4200 George.Davey at dmu.edu www.dmu.edu From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Paul Morrison Sent: Friday, August 22, 2008 12:27 PM To: Dale W. Carder Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] LRSA concerns (Re: Policy Proposal: Whois Integrity Policy Proposal) On 8/22/2008 8:21 AM, Dale W. Carder wrote: On Aug 21, 2008, at 5:32 PM, Jeffrey I. Schiller wrote: I proposed then that a good first step to get legacy holders into the "tent" would be a milder contract that didn't put their "rights" (whatever they may be now or determined in the future) on the line. I agree with this approach. I agree as well. It's also justifiable in terms of paying a registrar for domain and reverse DNS. I have no problem paying $10 a year or whatever to godaddy for a dot com registration, so I have no opposition to paying to an in-addr.arpa registrar, who could provide whois and registrar services at a competitive rate. Just as dot com registration was once free and was converted to pay as you go, so can in-addr.arpa for legacy registrants. Perhaps this can side-step some of the opposition to legacy changes. Most of this could leverage existing registrar, domain registration and whois infrastructure. So legacy holders can pay their way for the registration infrastructure, while any questions of "ownership" or legitimacy can be sorted out separately, or they can simply whither on the vine with IPv6 approaching. If we all think that whois needs to be updated and this can't be done without a contract, could a contract specific to whois maintenance be written as Jeff outlined without the things that legacy holders are clearly concerned about in the current LRSA? LRSA-lite could be a lot easier for legacy holders to swallow. As v4 runout gets closer, I worry about increased hijacking. The value of database maintenance will then be clear to everyone. Dale _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2167 bytes Desc: image001.gif URL: From aaron at wholesaleinternet.net Fri Aug 22 14:29:17 2008 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Fri, 22 Aug 2008 13:29:17 -0500 Subject: [arin-ppml] LRSA concerns (Re: Policy Proposal: Whois Integrity Policy Proposal) In-Reply-To: <48AEF6ED.5000603@bogomips.com> References: <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> <48ACA684.2090208@rancid.berkeley.edu> <3c3e3fca0808201726l7e021ffakb53df5eedac8acbb@mail.gmail.com> <99772.1219282684@nsa.vix.com> <3c3e3fca0808202013n65bf8bc8tae50417451e629f6@mail.gmail.com> <30601.1219332861@nsa.vix.com> <3c3e3fca0808211225j38f4a6f3u7aac16bfc4371ad5@mail.gmail.com> <20080821223253.GB14008@mit.edu> <17DE08BC-2D90-4146-A9A8-C1D284C4C896@wisc.edu> <48AEF6ED.5000603@bogomips.com> Message-ID: <119901c90484$fc573e60$f505bb20$@net> I had an enormous rant going on this but I'll pair it down to this: I oppose any action that increases the administrative duties of ARIN and therefore the expenses born by the paying IP holders to accommodate the non paying IP holders. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From ppml at rs.seastrom.com Fri Aug 22 16:38:00 2008 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Fri, 22 Aug 2008 16:38:00 -0400 Subject: [arin-ppml] Apple's secret "Back to My Mac" push behind IPv6(appleinsider.com) In-Reply-To: (Ted Mittelstaedt's message of "Wed, 20 Aug 2008 17:48:19 -0700") References: Message-ID: <868wuo7plj.fsf@seastrom.com> "Ted Mittelstaedt" writes: > Good. A much-needed intro to IPv6 for the Apple die-hards. > At least, the first half of the article was. Full of such unintended funniness as "class A subnet" and ten year out of date "IPv6 is more secure" drum banging. Wish they had a technical editor. > The last half was full of shameless plugging of Apple products, > wrapped in the typical myopia of all-the-worlds-a-mac, though. > Although I guess you have to have that, to force-feed the > educational bit. I don't see anything like that at all. What I see is "it can benefit Apple's applications in this way", while asserting that Microsoft and others are also supporting IPv6. Far cry from "all-the-world's-a-mac". -r From Lee.Howard at stanleyassociates.com Fri Aug 22 16:38:17 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 22 Aug 2008 16:38:17 -0400 Subject: [arin-ppml] Whois Integrity Policy Proposal In-Reply-To: Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B0CC51D@CL-S-EX-1.stanleyassociates.com> What "legacy agreements"? Are there contracts in place which bind ARIN to provide services? Lee ________________________________ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Davey, George Sent: Friday, August 22, 2008 2:33 PM To: arin-ppml at arin.net Subject: [arin-ppml] Whois Integrity Policy Proposal Legacy agreements make no mention of DNS or email requirements. Legacy holders are under no obligation to please ARIN. This would be yet another attempt to force people in legacy agreements to sign an updated agreement and they should not be bullied into doing so. The Hobbs Act of 1951 addressed this type of unfair pressure to force people to change contractual rights out of fear of losing intangible properties acquired under an allocation contract. I feel firm that any attempt to bully legacy holders to sign anything is both unlawful and unnecessary. It is especially unnecessary harassment. What troubles me the most is the ease at which people will form a Lynch mob to strip others of rights they cannot share because they were not there at the time that particular right was established. Most of the victims are na?ve or have not had proper legal counsel advising them of their contractual rights. The legacy agreements did not have a clause giving ANY governing body the right to discuss or pressure them into changing their contract to please ARIN, ICANN, or IANA. In my opinion it is a democratic socialist movement to make everyone the same by force of fear of losing the space fairly allocated to them in the legacy time. There are many ways each of us can make the Internet a better place, forcing people to sign contracts by force of fear is not one of them. I do not support this policy at this time because I think it clearly has a hidden agenda and will not stop spammers or even slow them down. George Davey, B.S. MCSE Network Administrator 3200 Grand Avenue Des Moines, IA 50312 515.271.1544 FAX 515.271.4200 George.Davey at dmu.edu www.dmu.edu From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Paul Morrison Sent: Friday, August 22, 2008 12:27 PM To: Dale W. Carder Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] LRSA concerns (Re: Policy Proposal: Whois Integrity Policy Proposal) On 8/22/2008 8:21 AM, Dale W. Carder wrote: On Aug 21, 2008, at 5:32 PM, Jeffrey I. Schiller wrote: I proposed then that a good first step to get legacy holders into the "tent" would be a milder contract that didn't put their "rights" (whatever they may be now or determined in the future) on the line. I agree with this approach. I agree as well. It's also justifiable in terms of paying a registrar for domain and reverse DNS. I have no problem paying $10 a year or whatever to godaddy for a dot com registration, so I have no opposition to paying to an in-addr.arpa registrar, who could provide whois and registrar services at a competitive rate. Just as dot com registration was once free and was converted to pay as you go, so can in-addr.arpa for legacy registrants. Perhaps this can side-step some of the opposition to legacy changes. Most of this could leverage existing registrar, domain registration and whois infrastructure. So legacy holders can pay their way for the registration infrastructure, while any questions of "ownership" or legitimacy can be sorted out separately, or they can simply whither on the vine with IPv6 approaching. If we all think that whois needs to be updated and this can't be done without a contract, could a contract specific to whois maintenance be written as Jeff outlined without the things that legacy holders are clearly concerned about in the current LRSA? LRSA-lite could be a lot easier for legacy holders to swallow. As v4 runout gets closer, I worry about increased hijacking. The value of database maintenance will then be clear to everyone. Dale _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2167 bytes Desc: image001.gif URL: From ralph at cancerboard.ab.ca Fri Aug 22 16:19:16 2008 From: ralph at cancerboard.ab.ca (Ralph Hand) Date: Fri, 22 Aug 2008 14:19:16 -0600 Subject: [arin-ppml] Whois Integrity Policy Proposal In-Reply-To: References: <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com><48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com><48ACA684.2090208@rancid.berkeley.edu><3c3e3fca0808201726l7e021ffakb53df5eedac8acbb@mail.gmail.com><99772.1219282684@nsa.vix.com><3c3e3fca0808202013n65bf8bc8tae50417451e629f6@mail.gmail.com><30601.1219332861@nsa.vix.com><3c3e3fca0808211225j38f4a6f3u7aac16bfc4371ad5@mail.gmail.com><20080821223253.GB14008@mit.edu><17DE08BC-2D90-4146-A9A8-C1D284C4C896@wisc.edu><48AEF6ED.5000603@bogomips.com> Message-ID: That's like saying that anyone born before the patriot act came into place is exempt. If the rules change they should change for everyone. I say that as a legacy holder. I don't have an issue with the policy per say but maybe the approach should be to push ipv6 harder. Implement any policies we need for ipv6 and everyone will have to be on board when it takes on a life of their own. That would of course imply that legacy holders do not have any special rights carried over to ipv6; I may have missed the discussions on that; but I hope they would not. Ralph From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Davey, George Sent: August 22, 2008 12:33 PM To: arin-ppml at arin.net Subject: [arin-ppml] Whois Integrity Policy Proposal Legacy agreements make no mention of DNS or email requirements. Legacy holders are under no obligation to please ARIN. This would be yet another attempt to force people in legacy agreements to sign an updated agreement and they should not be bullied into doing so. The Hobbs Act of 1951 addressed this type of unfair pressure to force people to change contractual rights out of fear of losing intangible properties acquired under an allocation contract. I feel firm that any attempt to bully legacy holders to sign anything is both unlawful and unnecessary. It is especially unnecessary harassment. What troubles me the most is the ease at which people will form a Lynch mob to strip others of rights they cannot share because they were not there at the time that particular right was established. Most of the victims are na?ve or have not had proper legal counsel advising them of their contractual rights. The legacy agreements did not have a clause giving ANY governing body the right to discuss or pressure them into changing their contract to please ARIN, ICANN, or IANA. In my opinion it is a democratic socialist movement to make everyone the same by force of fear of losing the space fairly allocated to them in the legacy time. There are many ways each of us can make the Internet a better place, forcing people to sign contracts by force of fear is not one of them. I do not support this policy at this time because I think it clearly has a hidden agenda and will not stop spammers or even slow them down. George Davey, B.S. MCSE Network Administrator 3200 Grand Avenue Des Moines, IA 50312 515.271.1544 FAX 515.271.4200 George.Davey at dmu.edu www.dmu.edu From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Paul Morrison Sent: Friday, August 22, 2008 12:27 PM To: Dale W. Carder Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] LRSA concerns (Re: Policy Proposal: Whois Integrity Policy Proposal) On 8/22/2008 8:21 AM, Dale W. Carder wrote: On Aug 21, 2008, at 5:32 PM, Jeffrey I. Schiller wrote: I proposed then that a good first step to get legacy holders into the "tent" would be a milder contract that didn't put their "rights" (whatever they may be now or determined in the future) on the line. I agree with this approach. I agree as well. It's also justifiable in terms of paying a registrar for domain and reverse DNS. I have no problem paying $10 a year or whatever to godaddy for a dot com registration, so I have no opposition to paying to an in-addr.arpa registrar, who could provide whois and registrar services at a competitive rate. Just as dot com registration was once free and was converted to pay as you go, so can in-addr.arpa for legacy registrants. Perhaps this can side-step some of the opposition to legacy changes. Most of this could leverage existing registrar, domain registration and whois infrastructure. So legacy holders can pay their way for the registration infrastructure, while any questions of "ownership" or legitimacy can be sorted out separately, or they can simply whither on the vine with IPv6 approaching. If we all think that whois needs to be updated and this can't be done without a contract, could a contract specific to whois maintenance be written as Jeff outlined without the things that legacy holders are clearly concerned about in the current LRSA? LRSA-lite could be a lot easier for legacy holders to swallow. As v4 runout gets closer, I worry about increased hijacking. The value of database maintenance will then be clear to everyone. Dale _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. This e-mail and any attachments may contain confidential and privileged information. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this e-mail and destroy any copies. Any dissemination or use of this information by a person other than the intended recipient is unauthorized and may be illegal. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2167 bytes Desc: image001.gif URL: From rhw2 at rhwsun.wooten.net Fri Aug 22 16:57:38 2008 From: rhw2 at rhwsun.wooten.net (Richard Wooten) Date: Fri, 22 Aug 2008 16:57:38 -0400 Subject: [arin-ppml] LRSA concerns (Re: Policy Proposal: Whois Integrity Policy Proposal) In-Reply-To: <20080821223253.GB14008@mit.edu> References: <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com> <48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com> <48ACA684.2090208@rancid.berkeley.edu> <3c3e3fca0808201726l7e021ffakb53df5eedac8acbb@mail.gmail.com> <99772.1219282684@nsa.vix.com> <3c3e3fca0808202013n65bf8bc8tae50417451e629f6@mail.gmail.com> <30601.1219332861@nsa.vix.com> <3c3e3fca0808211225j38f4a6f3u7aac16bfc4371ad5@mail.gmail.com> <20080821223253.GB14008@mit.edu> Message-ID: <48AF2842.9080804@rhwsun.wooten.net> Jeff, Thanks, you are the only one that has made any sense about the LRSA. I've always said, I would pay my fare share, just give me a way to do it. Richard Wooten Network Manager Richard & Associates Jeffrey I. Schiller wrote: >I've attached a message a sent to the ppml list back last >October. From what I can tell, no one ever responded publicly to it (I >did receive a private reply). > >I proposed then that a good first step to get legacy holders into the >"tent" would be a milder contract that didn't put their "rights" >(whatever they may be now or determined in the future) on the line. > >From what I have read and seen, one of the more egregious clauses in >the LRSA is the one where you lose your address space when the >contract terminates, for whatever reason. There are other problems as >well, but I won't go into detail here (others have, I don't need to >repeat them!). > >Perhaps a more middle ground between the current LRSA and my proposal >of no discussion of address blocks would be something that would: > >o Bind the registrant to not sell or transfer their address blocks > outside of an ARIN sanctioned process (this is one of the elephants > in the room!). > >o Bind ARIN to not revoke legacy addresses (which the LRSA does > today). > >o Arrange for the registrant to pay their fair share of ARIN costs > (the LRSA does this). > >o Isn't terminated based on issues that have nothing to do with > address assignment (like claimed violations of law, more on this > later). > >o Is in some way non-revocable. What I mean here is that the > registrant shouldn't be able to decide to void the agreement and > walk away because they want to do something prohibited by the > contract (like sell address space) *and* ARIN shouldn't be able to > revoke a legacy address by wiggling out of the agreement. The > registrant should feel secure in their continued use of address > space and ARIN should feel secure in that the registrant will abide > by the agreement. I'm not enough of a lawyer (heck, I am not even a > lawyer at all) to come up with the language. > >I believe the key here is that the legacy registrant needs to be >secure in their continued use of "their" address space. The current >LRSA falls short on this score. > >So, how do we move forward on this score? Do I hire an attorney and >develop a replacement LRSA. Is there a way to get the ARIN Board to >consider changes to the LRSA without doing so (I would propose wording >changes myself, but then I am not a competent attorney). I'm >interested in guidance here. > >So about claimed violations of law... (feel free to stop reading now >if you are not interested in this aspect of things). > >The problem with terminating the agreement on violations of law is >that sometimes the law is wrong and the way to demonstrate it is to >violate it and go to court. > >A number of years ago MIT was actually convicted of violating the >Sherman Anti-Trust Act by participating in what was called the Overlap >Group. The Overlap Group was a group of college financial aid >administrators who arranged for students who applied to their colleges >(thus they "overlapped") to receive a similar aid package from each >school that they applied to (from the group). This was a benefit to >society because it permitted students to select a school based on >academics rather then the best aid package. It also permitted limited >donations (where the financial aid sometimes comes from) to be >stretched over a larger number of students. In some cases this was >necessary for schools to offer "need blind admissions." > >The government viewed this as illegal price fixing and went to >prosecute the member schools. All but one negotiated a consent >decree. MIT was the one that wouldn't. We stood on principal and went >to court. We were convicted. We appealed and the appellate court threw >out the conviction and remanded the lower court to try again. At that >point the government punted. > >My point: When we were convicted, it would have really been unpleasant >to then loose our address block. Frankly what the heck does our >address allocation have to do with this? Nothing, so it shouldn't be >part of the equation. > >Sorry for the length. > > -Jeff > >On Thu, Aug 21, 2008 at 03:25:27PM -0400, William Herrin wrote: > > >>Perhaps asking for the LRSA to also be about governance pushes the >>legacy registrants further than they're currently willing to go. >> >> > >-- >======================================================================== >Jeffrey I. Schiller >MIT Network Manager >Information Services and Technology >Massachusetts Institute of Technology >77 Massachusetts Avenue Room W92-190 >Cambridge, MA 02139-4307 >617.253.0161 - Voice >jis at mit.edu > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gtb at slac.stanford.edu Fri Aug 22 16:57:39 2008 From: gtb at slac.stanford.edu (Buhrmaster, Gary) Date: Fri, 22 Aug 2008 13:57:39 -0700 Subject: [arin-ppml] Whois Integrity Policy Proposal In-Reply-To: References: <48AB13CD.2030903@psg.com> <84171.1219173955@nsa.vix.com><48AB328C.6010606@rancid.berkeley.edu> <1698.1219180000@nsa.vix.com><48ACA684.2090208@rancid.berkeley.edu><3c3e3fca0808201726l7e021ffakb53df5eedac8acbb@mail.gmail.com><99772.1219282684@nsa.vix.com><3c3e3fca0808202013n65bf8bc8tae50417451e629f6@mail.gmail.com><30601.1219332861@nsa.vix.com><3c3e3fca0808211225j38f4a6f3u7aac16bfc4371ad5@mail.gmail.com><20080821223253.GB14008@mit.edu><17DE08BC-2D90-4146-A9A8-C1D284C4C896@wisc.edu><48AEF6ED.5000603@bogomips.com> Message-ID: > That's like saying that anyone born before the patriot act > came into place is exempt. Criminal law is different than Civil law, and the agreement(s) (or lack thereof) between ARIN and the holders of space is a contract law issue (civil). But, to your point, even in criminal law, it does occur that changes in sentencing laws result in inconsistent terms of incarceration for the same crime. From mksmith at adhost.com Fri Aug 22 17:10:39 2008 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Fri, 22 Aug 2008 14:10:39 -0700 Subject: [arin-ppml] Whois Integrity Policy Proposal In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40B0CC51D@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB40B0CC51D@CL-S-EX-1.stanleyassociates.com> Message-ID: <17838240D9A5544AAA5FF95F8D520316049030CD@ad-exh01.adhost.lan> From http://www.arin.net/registration/legacy/ question 2's answer: "The first important benefit is the contractual promise to continue receiving WHOIS and IN-ADDR services. ARIN currently provides those services free to all legacy resource holders who maintain contact with ARIN. This could change if the community so desired. Correspondingly, we understand Legacy holders don?t want to receive free services from the community, but are willing to pay their fair share of the expenses." It seems to me that the bulk of responses from legacy holders to PPML are not favorable to ARIN having any rights to the resources they received pre-ARIN. So, perhaps it's time to revisit "This could change if the community so desired" in the paragraph above. If ARIN has no relationship at all with the legacy space, including providing whois and in-addr.arpa services, then a lot of these discussions are moot, no? Mike ---- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Howard, W. Lee Sent: Friday, August 22, 2008 1:38 PM To: Davey, George; arin-ppml at arin.net Subject: Re: [arin-ppml] Whois Integrity Policy Proposal What "legacy agreements"?? Are there contracts in place which bind ARIN to provide services?? ? Lee -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 475 bytes Desc: not available URL: From kkargel at polartel.com Fri Aug 22 17:18:10 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 22 Aug 2008 16:18:10 -0500 Subject: [arin-ppml] Whois Integrity Policy Proposal In-Reply-To: <17838240D9A5544AAA5FF95F8D520316049030CD@ad-exh01.adhost.lan> References: <369EB04A0951824ABE7D8BAC67AF9BB40B0CC51D@CL-S-EX-1.stanleyassociates.com> <17838240D9A5544AAA5FF95F8D520316049030CD@ad-exh01.adhost.lan> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10A56@mail> The key words here are " who maintain contact with ARIN " defunct contact info does not fulfill that clause. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael K. Smith - Adhost Sent: Friday, August 22, 2008 4:11 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Whois Integrity Policy Proposal >From http://www.arin.net/registration/legacy/ question 2's answer: "The first important benefit is the contractual promise to continue receiving WHOIS and IN-ADDR services. ARIN currently provides those services free to all legacy resource holders who maintain contact with ARIN. This could change if the community so desired. Correspondingly, we understand Legacy holders don?t want to receive free services from the community, but are willing to pay their fair share of the expenses." It seems to me that the bulk of responses from legacy holders to PPML are not favorable to ARIN having any rights to the resources they received pre-ARIN. So, perhaps it's time to revisit "This could change if the community so desired" in the paragraph above. If ARIN has no relationship at all with the legacy space, including providing whois and in-addr.arpa services, then a lot of these discussions are moot, no? Mike ---- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Howard, W. Lee Sent: Friday, August 22, 2008 1:38 PM To: Davey, George; arin-ppml at arin.net Subject: Re: [arin-ppml] Whois Integrity Policy Proposal What "legacy agreements"?? Are there contracts in place which bind ARIN to provide services?? ? Lee -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3107 bytes Desc: not available URL: From cliffb at cjbsys.bdb.com Fri Aug 22 17:16:02 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Fri, 22 Aug 2008 17:16:02 -0400 (EDT) Subject: [arin-ppml] Legacy RSA signers Message-ID: <200808222116.m7MLG2XM025250@cjbsys.bdb.com> I've been madly reading to catch up on the backlog of PPML messages in my inbox and don't have the email at hand that gave the answer about how many legacy number holders have signed the LRSA. A more interesting question might be "How many of the signers came in from the cold and did not have a separate RSA with ARIN?" I.e. Paul Vixie signed but it appears that he had a separate RSA with ARIN for non-legacy numbers. (If not true Paul please correct this.) I'm curious how many of the signers came from the outreach program started last year. Cliff -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From jay at handynetworks.com Fri Aug 22 17:19:48 2008 From: jay at handynetworks.com (Jay Sudowski - Handy Networks LLC) Date: Fri, 22 Aug 2008 15:19:48 -0600 Subject: [arin-ppml] Whois Integrity Policy Proposal In-Reply-To: <17838240D9A5544AAA5FF95F8D520316049030CD@ad-exh01.adhost.lan> References: <369EB04A0951824ABE7D8BAC67AF9BB40B0CC51D@CL-S-EX-1.stanleyassociates.com> <17838240D9A5544AAA5FF95F8D520316049030CD@ad-exh01.adhost.lan> Message-ID: <7EC421F755E45242A47938C3B6F634B10115173C@hnetavail1.exchange.handynetworks.com> I concur. I see no reason why we should subsidize the services that legacy allocations currently receive for free. Let them maintain their own WHOIS and in-addr.arpa servers. -Jay -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael K. Smith - Adhost Sent: Friday, August 22, 2008 3:11 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Whois Integrity Policy Proposal From http://www.arin.net/registration/legacy/ question 2's answer: "The first important benefit is the contractual promise to continue receiving WHOIS and IN-ADDR services. ARIN currently provides those services free to all legacy resource holders who maintain contact with ARIN. This could change if the community so desired. Correspondingly, we understand Legacy holders don?t want to receive free services from the community, but are willing to pay their fair share of the expenses." It seems to me that the bulk of responses from legacy holders to PPML are not favorable to ARIN having any rights to the resources they received pre-ARIN. So, perhaps it's time to revisit "This could change if the community so desired" in the paragraph above. If ARIN has no relationship at all with the legacy space, including providing whois and in-addr.arpa services, then a lot of these discussions are moot, no? Mike ---- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Howard, W. Lee Sent: Friday, August 22, 2008 1:38 PM To: Davey, George; arin-ppml at arin.net Subject: Re: [arin-ppml] Whois Integrity Policy Proposal What "legacy agreements"?? Are there contracts in place which bind ARIN to provide services?? ? Lee From jhframe at dcn.org Fri Aug 22 17:37:04 2008 From: jhframe at dcn.org (Jim Frame) Date: Fri, 22 Aug 2008 14:37:04 -0700 Subject: [arin-ppml] Legacy RSA signers In-Reply-To: <200808222116.m7MLG2XM025250@cjbsys.bdb.com> References: <200808222116.m7MLG2XM025250@cjbsys.bdb.com> Message-ID: <48AF3180.3000908@dcn.org> Cliff Bedore wrote: > I'm curious how many of the signers came from the outreach program started > last year. Count Davis Community Network as one. -- --------------------------------------------------------------------- Jim Frame jhframe at dcn.org (530) 756-8584 756-8201 (FAX) Frame Surveying & Mapping 609 A Street Davis, CA 95616 -----------------------< Davis Community Network >------------------- From cgrundemann at gmail.com Fri Aug 22 17:50:15 2008 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 22 Aug 2008 15:50:15 -0600 Subject: [arin-ppml] Policy Proposal: whois POC e-mail cleanup In-Reply-To: References: <443de7ad0808211149w7e3e2865tafc4e6baecc69262@mail.gmail.com> Message-ID: <443de7ad0808221450r705e76aau66916973cdf2c1ea@mail.gmail.com> I strongly support the general purpose of this proposal but just as strongly feel that the execution should be different on three points: 1) The verification email should require a response. 2) Non-RSA Legacy, LRSA and RSA space holders should be treated in an identical manner. 3) Once you start marking POCs as invalid or unresponsive, the list of netblocks without valid POCs should be pushed fully into the light in order to mitigate potential hijacking attempts. Beyond that, I think that a fully automated system will have the least impact on ARIN staff workload and that it makes sense to close the loop so to speak within one policy for final actions to be taken for completely non-responsive POCs. Based on the primary three differences I listed above, and some strong encouragement to do so, I went ahead and submitted a POC verification policy of my own. I want to thank you for the inspiration and I hope that you can support the new policy based on my rational for those changes. ~Chris On Thu, Aug 21, 2008 at 6:44 PM, Internet Partners Hostmaster wrote: > Chris, > > I deliberately left it vague as to the exact implementation. It would > certainly be > possible to have the automated system put the REFUSED RESPONSE in > then ARIN check this later, instead of the automated system producing a list > that > would have to be looked at before the address was changed to REFUSED > RESPONSE. > > I am concerned about writing that level of detail into the NRPM itself, > though. I > would rather just leave the vague statement that LIR POCs that fail to > respond > will have their address changed to REFUSED RESPONSE, and allow ARIN staff to > determine the exact method of implementation. > > As far as futher action to be taken, I had considered this, but I would > rather see > future policy proposals that addressed what kind of action. As it is now we > really > don't know if this is a big problem or not - thus the rationale for section > 3.6.1 for > a summary report. If after a year the summary reports indicate that invalid > POCs > are in reality a huge problem, then we can start talking penalties. > > I was a bit leery about offering a list of address blocks of uncontactable > POC's to > the general public (ie: NOT under the existing rationale for section 3.1 for > bulk > copies) It seems to me that doing so would be making it very simple for the > crackers to find blocks to attempt hijacking. > > In view of these explanations do you still have concerns about this > proposal? > > Ted > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Chris Grundemann > Sent: Thursday, August 21, 2008 11:49 AM > To: Member Services > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: whois POC e-mail cleanup > > Imo; > A response to the annual POC email should be required for verification that > the email address is in fact valid. If there is no response to the email > after X amount of time, the automated system should replace the POC address > with "REFUSED RESPONSE" or some such. The list of POCs with this marking > should be reviewed by ARIN staff and manual contact attempts could be made > at their discretion. A provision for further action to be taken if manual > contact methods fail should be considered (locking the POC from making other > changes, deleting the POC, etc). A list of address blocks without valid > POCs should be made easily available to the community. > ~Chris > > On Thu, Aug 21, 2008 at 7:55 AM, Member Services wrote: >> >> ARIN received the following policy proposal. In accordance with the ARIN >> Internet Resource Policy Evaluation Process, the proposal is being >> posted to the ARIN Public Policy Mailing List (PPML) and being placed on >> ARIN's website. >> >> The ARIN Advisory Council (AC) will review this proposal at their next >> regularly scheduled meeting. The AC may decide to: >> >> 1. Accept the proposal as written. If the AC accepts the proposal, >> it will be posted as a formal policy proposal to PPML and it will be >> presented at a Public Policy Meeting. >> >> 2. Postpone their decision regarding the proposal until the next >> regularly scheduled AC meeting in order to work with the author. The AC >> will work with the author to clarify, combine or divide the proposal. At >> their following meeting the AC will accept or not accept the proposal. >> >> 3. Not accept the proposal. If the AC does not accept the proposal, >> the AC will explain their decision via the PPML. If a proposal is not >> accepted, 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 proposal will be closed. >> >> The AC will assign shepherds in the near future. ARIN will provide the >> names of the shepherds to the community via the PPML. >> >> In the meantime, the AC invites everyone to comment on this proposal on >> the PPML, particularly their support or non-support and the reasoning >> behind their opinion. Such participation contributes to a thorough >> vetting and provides important guidance to the AC in their deliberations. >> >> The ARIN Internet Resource Policy Evaluation Process can be found at: >> http://www.arin.net/policy/irpep.html >> >> Mailing list subscription information can be found at: >> http://www.arin.net/mailing_lists/ >> >> Regards, >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Policy Proposal Name: whois POC e-mail cleanup >> >> Author: Ted Mittelstaedt >> >> Proposal Version: 1 >> >> Submission Date: 8/20/2008 >> >> Proposal type: new >> >> Policy term: permanent >> >> Policy statement: >> >> Under Directory Services in the NRPM >> >> add section 3.6 titled "Reliability of Whois information" >> >> 3.6.1 ARIN will use an automated system that once a year will attempt >> to e-mail all separate e-mail addresses in the directory. (including >> abuse addresses) At it's discretion, ARIN will attempt to contact by >> regular mail or phone all POC entries that have invalid e-mail addresses >> (i.e. e-mail addresses that bounce mail sent to them) and give them a 3 >> month deadline for correction of their mail address. The automated >> system will not use a mail cluster or other mail transmission software >> that is incompatible with commonly available anti-spam technologies, >> such as greylisting. >> >> LIR POC's that fail to respond to paper mails or telephone calls will >> have Their e-mail address replaced with "REFUSED RESPONSE" in the >> directory. Non-legacy POCs will be requested to remedy the situation by >> their next billing date. At it's discretion and considering the size or >> number of complaints about an organization, ARIN may require the >> organization to supply accurate contact information in it's directory >> entry as a condition of accepting payment from the organization for >> registration renewals. >> >> POCs belonging to blocks reassigned by LIRs who fail to respond will be >> replaced by the POC of the reassigning LIR. >> >> The automated e-mails will have a text string titled "ARIN Automated POC >> e-mail test" identifying them so that automated trouble ticket systems >> can be programmed to automatically delete the mail messages instead of >> replying to them. >> >> Other standard mailing list practices will be followed by ARIN to insure >> the absence of e-mail loops, etc. >> >> 3.6.1 ARIN will supply a report to the community, updated monthly, that >> lists the percentage of "REFUSED RESPONSE" POCs, the percentage of POCs >> that accept e-mails, and the percentage of POC addresses that have not >> responded but have not yet been notified by paper mail or telephone. >> >> Rationale: >> >> As the entire Internet community gets closer to the date that IPv4 will >> be exhausted, more attention is being focused on the possibility that >> there is significant amounts of allocated IPv4 that is abandoned. There >> are also concerns that as the amount of usable IPv4 space gets more and >> more crowded, that Internet criminals are turning to abandoned IPv4 >> space that is still listed as allocated in the whois directories to use >> to make attacks on hosts on the Internet. Because of these reasons, it >> is becoming more important that users of ARIN's whois data have a >> reasonable expectation that it is accurate. >> >> The current NRPM has a mechanism for adding, modifying, and deleting >> POCs. However it also carries an assumption that POCs belonging to >> defunct companies will be removed when the bills for allocated IP >> addressing cease being paid, and the address resources are then returned >> to the ARIN pool as a result. The problem is that this assumption does >> not hold true for so-called "Legacy" IP address holders since they do >> not pay a yearly fee. Furthermore, billing for the IP addressing >> allocations is done through paper mail, thus it is possible for a POC to >> have a valid street address, but an invalid E-mail address, and not be >> caught because they are current on their account. This is becoming a >> serious issue because contacting a POC via a street address is too slow >> for victims of an attack from a hijacked IP block to be able to complain >> to the block owners and the block owners to be able to catch the >> perpetrators. >> >> Timetable for implementation: Immediate >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > > > -- > Chris Grundemann > www.linkedin.com/in/cgrundemann > -- Chris Grundemann www.linkedin.com/in/cgrundemann From michael at rancid.berkeley.edu Fri Aug 22 18:00:25 2008 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Fri, 22 Aug 2008 15:00:25 -0700 Subject: [arin-ppml] Whois Integrity Policy Proposal In-Reply-To: <17838240D9A5544AAA5FF95F8D520316049030CD@ad-exh01.adhost.lan> References: <369EB04A0951824ABE7D8BAC67AF9BB40B0CC51D@CL-S-EX-1.stanleyassociates.com> <17838240D9A5544AAA5FF95F8D520316049030CD@ad-exh01.adhost.lan> Message-ID: <48AF36F9.4090109@rancid.berkeley.edu> On 08/22/08 14:10, Michael K. Smith - Adhost wrote: > From http://www.arin.net/registration/legacy/ question 2's answer: > > "The first important benefit is the contractual promise to continue > receiving WHOIS and IN-ADDR services. ARIN currently provides those > services free to all legacy resource holders who maintain contact > with ARIN. This could change if the community so desired. > Correspondingly, we understand Legacy holders don?t want to receive > free services from the community, but are willing to pay their fair > share of the expenses." > > It seems to me that the bulk of responses from legacy holders to PPML > are not favorable to ARIN having any rights to the resources they > received pre-ARIN. So, perhaps it's time to revisit "This could > change if the community so desired" in the paragraph above. If ARIN > has no relationship at all with the legacy space, including providing > whois and in-addr.arpa services, then a lot of these discussions are > moot, no? I have to admit that I am not totally following what you're saying, but my reading of the discussion is that issues of ARIN's jurisdiction over legacy IP address space can be separated from ARIN's providing WHOIS and in-addr.arpa services. It appears that many of the legacy holders are willing to pay for services received from ARIN, but aren't (yet?) ready to settle the issue of jurisdiction. It seems that we could advance the debate a bit by asking the questions: o Does it make sense to separate the issues and allow legacy holders to pay for services like whois and in-addr.arpa via some sort of LRSA-lite? o Will it help address the need for Whois integrity, since the LRSA-lite process could easily involve authentication and digital certs? o Does it create issues for ARIN and/or the (regular) RSA-signatory community if legacy holders pay for ARIN services without addressing the issue of jurisdiction over legacy number resources? thanks, michael From cgrundemann at gmail.com Fri Aug 22 18:43:31 2008 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 22 Aug 2008 16:43:31 -0600 Subject: [arin-ppml] Whois Integrity Policy Proposal In-Reply-To: <48AF36F9.4090109@rancid.berkeley.edu> References: <369EB04A0951824ABE7D8BAC67AF9BB40B0CC51D@CL-S-EX-1.stanleyassociates.com> <17838240D9A5544AAA5FF95F8D520316049030CD@ad-exh01.adhost.lan> <48AF36F9.4090109@rancid.berkeley.edu> Message-ID: <443de7ad0808221543n6ae97d9aoe6ec2901c5c865be@mail.gmail.com> On Fri, Aug 22, 2008 at 4:00 PM, Michael Sinatra wrote: >[...] > It seems that we could advance the debate a bit by asking the questions: > > o Does it make sense to separate the issues and allow legacy holders to > pay for services like whois and in-addr.arpa via some sort of LRSA-lite? > > o Will it help address the need for Whois integrity, since the LRSA-lite > process could easily involve authentication and digital certs? > > o Does it create issues for ARIN and/or the (regular) RSA-signatory > community if legacy holders pay for ARIN services without addressing the > issue of jurisdiction over legacy number resources? I agree that those questions get to the current heart of the issue and should help lead to a policy that can garner consensus. I would add a fourth question, much lower level but imo important as well: Should a whois integrity policy /require/ digital certs? I throw this in because I believe that a successful integrity policy would need to require a solid method for authenticating any and all change requests in a low-impact/automated manner but based on experience, I fear that some may be opposed to this idea. ~Chris > > thanks, > michael > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- Chris Grundemann www.linkedin.com/in/cgrundemann From mksmith at adhost.com Fri Aug 22 19:14:37 2008 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Fri, 22 Aug 2008 16:14:37 -0700 Subject: [arin-ppml] Whois Integrity Policy Proposal In-Reply-To: <48AF36F9.4090109@rancid.berkeley.edu> References: <369EB04A0951824ABE7D8BAC67AF9BB40B0CC51D@CL-S-EX-1.stanleyassociates.com> <17838240D9A5544AAA5FF95F8D520316049030CD@ad-exh01.adhost.lan> <48AF36F9.4090109@rancid.berkeley.edu> Message-ID: <17838240D9A5544AAA5FF95F8D52031604903101@ad-exh01.adhost.lan> Hello Michael (et. al.): > On 08/22/08 14:10, Michael K. Smith - Adhost wrote: > > From http://www.arin.net/registration/legacy/ question 2's answer: > > > > "The first important benefit is the contractual promise to continue > > receiving WHOIS and IN-ADDR services. ARIN currently provides those > > services free to all legacy resource holders who maintain contact > > with ARIN. This could change if the community so desired. > > Correspondingly, we understand Legacy holders don?t want to receive > > free services from the community, but are willing to pay their fair > > share of the expenses." > > > > It seems to me that the bulk of responses from legacy holders to PPML > > are not favorable to ARIN having any rights to the resources they > > received pre-ARIN. So, perhaps it's time to revisit "This could > > change if the community so desired" in the paragraph above. If ARIN > > has no relationship at all with the legacy space, including providing > > whois and in-addr.arpa services, then a lot of these discussions are > > moot, no? > > I have to admit that I am not totally following what you're saying, but > my reading of the discussion is that issues of ARIN's jurisdiction over > legacy IP address space can be separated from ARIN's providing WHOIS and > in-addr.arpa services. It appears that many of the legacy holders are > willing to pay for services received from ARIN, but aren't (yet?) ready > to settle the issue of jurisdiction. > > It seems that we could advance the debate a bit by asking the questions: > > o Does it make sense to separate the issues and allow legacy holders to > pay for services like whois and in-addr.arpa via some sort of LRSA-lite? > > o Will it help address the need for Whois integrity, since the LRSA-lite > process could easily involve authentication and digital certs? > > o Does it create issues for ARIN and/or the (regular) RSA-signatory > community if legacy holders pay for ARIN services without addressing the > issue of jurisdiction over legacy number resources? > > thanks, > michael You came to a much more level-headed solution than I was implying. :-) I was thinking that we just cut ties entirely with the legacy holders, including WHOIS and in-addr.arpa service since there seems to be nothing but friction from both sides of the isle. Regards, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 475 bytes Desc: not available URL: From jrhett at svcolo.com Fri Aug 22 20:16:24 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Fri, 22 Aug 2008 17:16:24 -0700 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: <20080820220629.GA69278@ussenterprise.ufp.org> References: <1080820172429.27224A-100000@Ives.egh.com> <20080820220629.GA69278@ussenterprise.ufp.org> Message-ID: On Aug 20, 2008, at 3:06 PM, Leo Bicknell wrote: > However, the end result is still a bare commons, and all of the > animals die. That can happen here; when IPv4 runs out the motivation > to hijack a legacy block will increase exponentially. Legacy holders > may find themselves being hijacked at faster and faster rates. I > have no doubt they will then come back to ARIN looking for a solution, TDB. They aren't members of ARIN, ARIN *should not* help them. > I suspect the half of the towns people who set decent rules and > tried to preserve the commons will be relatively unsympathetic at > that point in time that those who have avoided participating in > society and openly mocked them are now receiving their just rewards. I'll be dancing over here ;-) -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From randy at psg.com Fri Aug 22 20:44:41 2008 From: randy at psg.com (Randy Bush) Date: Fri, 22 Aug 2008 17:44:41 -0700 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: References: <1080820172429.27224A-100000@Ives.egh.com> <20080820220629.GA69278@ussenterprise.ufp.org> Message-ID: <48AF5D79.3010207@psg.com> >> I suspect the half of the towns people who set decent rules and >> tried to preserve the commons will be relatively unsympathetic at >> that point in time that those who have avoided participating in >> society and openly mocked them are now receiving their just rewards. kiddies, get a clue. many folk with legacy space were building the internet while you were still in nappies. we think it is you who are pissing on the commons. randy From jcurran at istaff.org Sat Aug 23 01:21:03 2008 From: jcurran at istaff.org (John Curran) Date: Sat, 23 Aug 2008 01:21:03 -0400 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: <3c3e3fca0808211654s4cc73fb6ld821d753adf3280c@mail.gmail.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <48ACA684.2090208@rancid.berkeley.edu> <3c3e3fca0808201726l7e021ffakb53df5eedac8acbb@mail.gmail.com> <99772.1219282684@nsa.vix.com> <3c3e3fca0808202013n65bf8bc8tae50417451e629f6@mail.gmail.com> <30601.1219332861@nsa.vix.com> <3c3e3fca0808211225j38f4a6f3u7aac16bfc4371ad5@mail.gmail.com> <83829.1219350127@nsa.vix.com> <3c3e3fca0808211519u617ad455n878d9992660ed362@mail.gmail.com> <4C80F17364FE2E4C93053BE9D01DB479094CE9A7@BCMSG111.corp.ads> <3c3e3fca0808211654s4cc73fb6ld821d753adf3280c@mail.gmail.com> Message-ID: <050C890C-EC53-462E-AB75-016BE2D58BBD@istaff.org> On Aug 21, 2008, at 7:54 PM, William Herrin wrote: > ... ARIN got the authority to do this by virtue of the fact > that network solutions decided to stop. Later they negotiated > contracts with IANA/ICANN and normalized the arrangement into > something pretty solid. Bill - This actually isn't correct. First, for background, it's important to note that while the IANA may have operated on behalf of the community under guidance of the Internet Activities Board (IAB), the authority for its operation was held by US FRICC / Federal Network Council (FNC) (which was the US Government's body for coordinating those agencies that supported the Internet [reference: RFC 1160, V. Cerf, May 1990]). If you'd like to verify this, refer to RFC 1174 which is a *request* from the IAB to the US FNC for approval to alter DNS & IP aspects of the Internet Registry (IR) system as a result of removal of "connected" status. It also recommends allowing CCIRN-designated regional Internet registries for international purposes, thus enabling delegation of IR functions to RIPE NCC & APNIC. The Internet Registry functions known as the DDN-NIC/INTERNIC/IR/IANA have been contracted over time by (D)ARPA, DCA/DISA, the National Science Foundation, and the US Department of Commerce; meanwhile, the oversight of these functions has been provided by then-current body coordinating US agency activities for the Internet (although happily it has been less and less direct oversight as the Internet has matured over time.) As a result, any early IP address allocations were made pursuant to a US Government contract, and this has some rather interesting implications to consider later. Now, with respect to ARIN, it was Jon Postel (who served as the IANA from the very beginning) and Don Telage of Network Solutions (who was leading the group in Network Solutions at the time) who recommended forming ARIN to provide Internet numbering resource administration for the "rest of world" region, i.e. those areas outside of the RIPE and APNIC regions. Many folks in the ISP community were heavily involved in its formation (some of whom remain actively involved in RIR and ISP operational communities even today), and I can say that the FNC, NSF, the Dept of Commerce, the FCC, and even the Executive branch were involved in the review and approval of ARIN's formation. The decision to proceed with ARIN's formation was communicated on June 23, 1997 with Amendment #6 of the National Science Foundation Cooperative Agreement NCR-9218742 with Network Solutions for Registration Services : "Approval of your Year 5 Program Plan constitutes full approval by the Foundation that the Awardee proceed with the formation of ARIN as outlined in the Program Plan." and it was finalized (after ARIN incorporation and transition) on December 3rd of 1997 with Amendment 7 of the same agreement which "relieves, releases, and discharges Network Solutions, Inc. from any responsibility for the IP Number assignment, Autonomous System Number assignment, and INADDR.ARPA tasks being performed under Cooperative Agreement No. NCR-9218742." So, it's not quite just that Network Solution decided to stop, it's that the community asked in many forums for ARIN to happen, and the entity that could authorize the change (i.e. US Government) agreed. > Prior to ARIN's inception, IP addresses were assigned by various other > entities, the last one being Network Solutions. These "legacy" > assignments were no-promises-made and no-strings-attached. These are > your numbers for use with the TCP/IP protocol. They are unique from > any others. Have fun. The gentlemen's agreement between ISPs (over > which ARIN has no control) extends to routing those addresses for the > respective assignees as well. The key thing to understand here is > this: ARIN probably has no legal standing in this part of the picture > at all. The original assignees appear to have some legal standing with > respect to control of the addresses but because of the shifting legal > landscape behind the scenes and the internationalization of the > Internet, it's not entirely clear who else does. It is entirely > plausible that no one else does. > > Now, this issue -could- be resolved legislatively. The US Congress > could pass a law stating that Department of Commerce is directed to > contract someone to assign all number resources permitted to be used > on Internet-connected networks in the United States. DOC would then > assign that authority to ICANN who would assign it to IANA who would > assign it to ARIN. The legacy registrant's standing with respect to > the legacy address ranges would be moot and because addresses weren't > property to begin with, their rights have not been violated. > > However, it is not in ARIN's best interest to take this course of > action. You see, ARIN's authority doesn't currently derive from ICANN > or the US Government. It is correct that the legacy IP assignments were made by various other entities, but it's also important to note that all of those allocations were performed as task or function under US Government contract or cooperative agreement, and that in its region ARIN is actually *already* performing these functions as the US Government directed successor. It's actually that simple. Frankly, I'd rather not think about this, and hope that this particular chain of succession remain nothing more than an interesting historical tidbit best ignored. It's theoretically possible to ask the "US Government" for support in performing our task, but we have to remember that the Internet has a much, much broader constituency than in the early days, and also that it has been generally accepted policy since ARIN's inception that the Internet is best served by industry self-determination... (one might even consider that one of the basic premises behind ARIN's formation.) In the end, we have to treat all parties with respect, whether they are holding a legacy allocation or one more recent. To the extent that the Internet community in the ARIN region wishes to be more flexible with the LRSA, it is relatively easy to change it accordingly. To the extent that the community wishes to see more reclamation efforts towards underutilized allocations, that too can be accomplished. While there are risks associated with any action, ARIN exists to perform this administration on behalf of the community and will do so diligently. However, it is very important for us to remember that: 1) The community must achieve rough consensus in these matters before ARIN can act, and 2) We're only provided the opportunity to address these questions because of the assumption that we're capable of doing it in a fair and open manner. We fail to do so at our own peril. /John Disclaimer: The views above are entirely my own, and written without consideration by ARIN Board, staff, or counsel. I am the Chairman of the ARIN Board of Trustees and have been so since ARIN's formation. From jcurran at istaff.org Sat Aug 23 02:25:29 2008 From: jcurran at istaff.org (John Curran) Date: Sat, 23 Aug 2008 02:25:29 -0400 Subject: [arin-ppml] Legacy space holders were a big part of the community... i.e. all of it. In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E2B8@SUEXCL-02.ad.syr.edu> References: <20080819172716.2FFF74501A@ptavv.es.net><867iacam3b.fsf@seastrom.com> <48AB13CD.2030903@psg.com><86skt0ltqu.fsf@seastrom.com> <48AB17DD.6020009@psg.com><86d4k4ltd9.fsf@seastrom.com><3c3e3fca0808191612x5d84942dyb935b30e1c673aaf@mail.gmail.com> <34567.1219192974@nsa.vix.com> <7663C7E01D8E094989CA62F0B0D21CD901E0E2B8@SUEXCL-02.ad.syr.edu> Message-ID: On Aug 21, 2008, at 2:01 AM, Milton L Mueller wrote: > Paul > One can make a good case for a unified, consistent address governance > regime that would involve eliminating legacy holder's special rights > and > bringing everyone in under the same kind of contract. Equating absence of an agreement with "special rights" is interesting, but that's probably best saved for another time. > But one cannot make the case you want to make based on appeals to "the > community" and "consensus." Because the legacy holders are part of > "the > community." A big part of it, in North America. And I suspect that > they > will never agree to be part of a "consensus" that eliminates their > special status. It is a very relevant point, since almost all of those same legacy holders were certainly part of the consensus decision in 1993 to change the basic IP address structure to allow variable sized blocks (aka "CIDR") and the matching matching address allocation policies (RFC1466/RFC1518/RFC1519). These documents state that an organization should receive sufficient address space to meet two years worth of organization need, so that we could "delay depletion of the IP address space". The community of the legacy space allocation era actually already reached consensus years ago that variable-sized blocks were needed and that organizational allocations based on two years of need were most appropriate. They just forgot to return their own extra space, for reasons unknown, and at this point are best off if they can simultaneously deny that they were part of the community that were involved in these decisions but somehow were still part of the team that earned their legacy allocation by helping build the Internet... good luck with that. /John (most certainly speaking individually) From bill at herrin.us Sat Aug 23 09:44:39 2008 From: bill at herrin.us (William Herrin) Date: Sat, 23 Aug 2008 09:44:39 -0400 Subject: [arin-ppml] LRSA concerns (Re: Policy Proposal: Whois Integrity Policy Proposal) In-Reply-To: <53531.1219419301@nsa.vix.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <48ACA684.2090208@rancid.berkeley.edu> <3c3e3fca0808201726l7e021ffakb53df5eedac8acbb@mail.gmail.com> <99772.1219282684@nsa.vix.com> <3c3e3fca0808202013n65bf8bc8tae50417451e629f6@mail.gmail.com> <30601.1219332861@nsa.vix.com> <3c3e3fca0808211225j38f4a6f3u7aac16bfc4371ad5@mail.gmail.com> <83829.1219350127@nsa.vix.com> <3c3e3fca0808211519u617ad455n878d9992660ed362@mail.gmail.com> <53531.1219419301@nsa.vix.com> Message-ID: <3c3e3fca0808230644i56c3e60cv3b5542285b6d24dd@mail.gmail.com> On Fri, Aug 22, 2008 at 11:35 AM, Paul Vixie wrote: > i think you're wrong. Paul, Could be. Time will tell. > in the future there may be digital certificates > on route origination, which i expect to be funded and operated through the > RIR system rather than through the kind of bilateral business arrangements > you described. Authentication is one of the bugaboos in the current routing system. ARIN certainly has an opportunity to be a part of the solution here, but to succeed it must first convince the vast majority of the legacy holders to join a contract that that makes ARIN the undisputed arbiter of authentication. Or convince the major carriers, most of them legacy holders themselves, to use ARIN as the authentication arbiter anyway. > i wonder if you found jeff schiller's suggestions to be on-target? his were > more specific than yours, and if they represent your position, it would be > helpful to know this. >> 1. Arrange for "Legacy" holders receiving services from ARIN (WHOIS, >> Reverse DNS) to enter into an agreement with ARIN and to pay their >> fair share for the services rendered. >> >> I would propose that ARIN consider yet another legacy RSA which only >> deals with [1] above. It doesn't go into address assignment issues at >> all (though it may require that the applicant assert that they are a >> legacy holder and demonstrate it in some way). I think Jeff's suggestions, this one particularly, move in a positive direction and would bring additional legacy registrants into the fold. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Sat Aug 23 10:40:20 2008 From: bill at herrin.us (William Herrin) Date: Sat, 23 Aug 2008 10:40:20 -0400 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: <050C890C-EC53-462E-AB75-016BE2D58BBD@istaff.org> References: <20080819172716.2FFF74501A@ptavv.es.net> <99772.1219282684@nsa.vix.com> <3c3e3fca0808202013n65bf8bc8tae50417451e629f6@mail.gmail.com> <30601.1219332861@nsa.vix.com> <3c3e3fca0808211225j38f4a6f3u7aac16bfc4371ad5@mail.gmail.com> <83829.1219350127@nsa.vix.com> <3c3e3fca0808211519u617ad455n878d9992660ed362@mail.gmail.com> <4C80F17364FE2E4C93053BE9D01DB479094CE9A7@BCMSG111.corp.ads> <3c3e3fca0808211654s4cc73fb6ld821d753adf3280c@mail.gmail.com> <050C890C-EC53-462E-AB75-016BE2D58BBD@istaff.org> Message-ID: <3c3e3fca0808230740q201bf1afg28de945e5b5b0581@mail.gmail.com> On Sat, Aug 23, 2008 at 1:21 AM, John Curran wrote: > On Aug 21, 2008, at 7:54 PM, William Herrin wrote: >> ... ARIN got the authority to do this by virtue of the fact >> that network solutions decided to stop. Later they negotiated >> contracts with IANA/ICANN and normalized the arrangement into >> something pretty solid. > > Bill - This actually isn't correct. John, I oversimplified. It was a very complex, largely extralegal community consensus process and I didn't want to go on for pages and pages. Perhaps it would be more accurate to say that the NSF agreed to step aside and relieve Network Solutions of its contractual duty to operate the number resource registry in favor of the community-organized and funded RIRs, including ARIN. > [clip list of documents] What you won't find, either in this list of documents or in the pre-ARIN address registration documents was any indication either that the then-extant registrations were revocable or that ARIN gained authority to revoke any registrations that predated it. Quite the contrary: the way the legacy registrations were described when made, they were intended to be unique and persist indefinitely, even if the network was never connected to the Internet at large. The sole described mechanism by which addresses could revert to the registry was voluntary return. What's more, the presentations made to gain the community consensus that led to NCR-9218742's amendment 6 repeatedly promised that what came to be known as the legacy registrations would remain untouched by ARIN except to provide whois and rdns services. http://rip.psg.com/~randy/970414.fncac.pdf is was such a presentation, made to the FNC in support of ARIN's formation. See page 9, specifically: "Current and old allocations and their DNS will be maintained with no policy changes" Inclusion of that statement was no mistake. "The Community" insisted on it. We're left with: no explicit grant of authority over the legacy registrations, and the historical documents that do talk about it suggest that the intention was to -not- grant such authority. It doesn't take a genius to figure out what that means in the scope of the US legal system, built on a foundation of common law that was eventually codified in the Tenth Amendment. It's also worth noting that today's "trust me" arguments for signing the LRSA are being made in the context of policy proposals which would, if ratified, explicitly break this 1997 "trust me" promise. > Frankly, I'd rather not think about this, and hope that this > particular chain of succession remain nothing more than an > interesting historical tidbit best ignored. You'll get no argument from me on this point. However, when v4 depletion is reached you'll find yourself under pressure to reclaim the fallow address space, however little it may be. To do so successfully you'll need to first normalize relations with the registrants whose legacy space is still in service. The only two ways you do that without creating a godawful mess for yourself are to either seek an explicit grant of authority from the USG that supersedes the old community agreements -OR- convince the vast majority of legacy registrants to voluntarily sign contracts with ARIN so that when you declare the rest of the space dead and expired there's no one left to raise a stink. Milton Mueller asked an interesting and relevant question: On Fri, Aug 22, 2008 at 12:01 AM, Milton L Mueller wrote: >>As a result, ARIN has near complete autonomy, > > So how long do you think it will be before that ends? ;-) ARIN's authority and autonomy derive from the *strong* consensus of the community it serves. That autonomy will end when ARIN places itself at the center of a dispute that results in a fall to weak consensus and the defection of any significant minority of that community. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jcurran at istaff.org Sat Aug 23 11:59:34 2008 From: jcurran at istaff.org (John Curran) Date: Sat, 23 Aug 2008 11:59:34 -0400 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: <3c3e3fca0808230740q201bf1afg28de945e5b5b0581@mail.gmail.com> References: <20080819172716.2FFF74501A@ptavv.es.net> <99772.1219282684@nsa.vix.com> <3c3e3fca0808202013n65bf8bc8tae50417451e629f6@mail.gmail.com> <30601.1219332861@nsa.vix.com> <3c3e3fca0808211225j38f4a6f3u7aac16bfc4371ad5@mail.gmail.com> <83829.1219350127@nsa.vix.com> <3c3e3fca0808211519u617ad455n878d9992660ed362@mail.gmail.com> <4C80F17364FE2E4C93053BE9D01DB479094CE9A7@BCMSG111.corp.ads> <3c3e3fca0808211654s4cc73fb6ld821d753adf3280c@mail.gmail.com> <050C890C-EC53-462E-AB75-016BE2D58BBD@istaff.org> <3c3e3fca0808230740q201bf1afg28de945e5b5b0581@mail.gmail.com> Message-ID: On Aug 23, 2008, at 10:40 AM, William Herrin wrote: > > What's more, the presentations made to gain the community consensus > that led to NCR-9218742's amendment 6 repeatedly promised that what > came to be known as the legacy registrations would remain untouched by > ARIN except to provide whois and rdns services. > http://rip.psg.com/~randy/970414.fncac.pdf is was such a presentation, > made to the FNC in support of ARIN's formation. See page 9, > specifically: "Current and old allocations and their DNS will be > maintained with no policy changes" You're right! That presentation was made after adoption of RFC 2050, which specifically calls for invalidation of existing assignments which are no longer needed. No change to address management policy was implied by creation of ARIN; the same address blocks that were obtained via US government auspices so that one could to participate in the Internet and Internet Protocol development were already covered by this policy in place at the time. > Inclusion of that statement was no mistake. "The Community" insisted > on it. Correct! > We're left with: no explicit grant of authority over the legacy > registrations, and the historical documents that do talk about it > suggest that the intention was to -not- grant such authority. I'm sorry, why did you expect such? Your allocations were always made under the authority of the IANA and based on your need for address space. The fact that we corrected the address subnet boundaries to allow for a better fit (CIDR) was the only major change, and if you happen to have been sitting on a "class A" or class B address block, it sure would have been nice if you returned the excess space which was provided to you due to this technical flaw in the original block allocation sizes. The reasons that some organizations did not are varied, and mostly related to pain of renumbering, sparse allocation, and similar technical issues [ref: ] >> Frankly, I'd rather not think about this, and hope that this >> particular chain of succession remain nothing more than an >> interesting historical tidbit best ignored. > > You'll get no argument from me on this point. > > However, when v4 depletion is reached you'll find yourself under > pressure to reclaim the fallow address space, however little it may > be. To do so successfully you'll need to first normalize relations > with the registrants whose legacy space is still in service. The only > two ways you do that without creating a godawful mess for yourself are > to either seek an explicit grant of authority from the USG that > supersedes the old community agreements The first direction above (reliance upon "authority") doesn't follow the principles of industry self-governance, and should be avoided at all costs. There's an fairly large "mess" whether one relies upon existing delegation of authority or whether one attempts to refresh it in some manner. > -OR- convince the vast majority of legacy registrants to voluntarily > sign contracts with ARIN so that when you declare the rest of the > space > dead and expired there's no one left to raise a stink. The second direction above is the correct one (IMHO), although I expect there'll always be someone left to "raise a stick" and ARIN must prepared accordingly if we're directed by the community to do anything with respect to legacy address reclamation. > .. > ARIN's authority and autonomy derive from the *strong* consensus of > the community it serves. That autonomy will end when ARIN places > itself at the center of a dispute that results in a fall to weak > consensus and the defection of any significant minority of that > community. We aim to please. If the consensus of the Internet community in the ARIN region is to undertake some action here, then we will very likely do so. It should be made very clear that ARIN serves the entire Internet community in the ARIN region, and not simply those who have taken the time and effort to participate as members. It is that reality which 1) causes ARIN to undertake more outreach than might otherwise be expected, and 2) makes the measurement of consensus for the "ARIN region Internet community" quite difficult. /John (my opinions only; 100% of the electrons used in this email are from recycled matter) From mksmith at adhost.com Sat Aug 23 12:55:40 2008 From: mksmith at adhost.com (Michael K. Smith) Date: Sat, 23 Aug 2008 09:55:40 -0700 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: Message-ID: John and Bill: Thank you for the historical look at the relationship between ARIN, the IANA and the Legacy address space. With that history, well defined and documented, why is ARIN now so interested in brining the legacy holders "into the fold?" What purpose does it serve? 1) Extend the life of IPv4 - opinions vary, but most data seems to suggest that even the best case scenario if all space was returned is that it won't extend it by much (6 months, 1 year?) 2) Normalize WHOIS and in-addr.arpa information - I question whether an LRSA or any other policy is really needed here. As many have pointed out, there is no commonality of the old records; some have invalid contact info but are still valid, some have totally invalid info, some are routed and some aren't, etc. With this many discrepancies, and with the historical reference presented by Bill and John, better policy would seem to be a broad statement of "we want WHOIS and in-addr.arpa to be accurate" and then build the tools to help with the process, and understand that there is still going to be a lot of bad information. Such is life. 3) Protect against future litigation - the line of thinking seems to be "if everyone is under a common structure then we can approach litigation in a common way." I disagree. If we have nothing but a services-based relationship with the legacy holders then we have nothing to defend against. The big question to my mind is whether or not we've already gone too far down the rabbit hole to go back to the original relationship with the legacy holders. I would like to see ARIN focus on the end-game of IPv4 and the adoption of IPv6, both through policy and press. I think all of the efforts to manipulate and control IPv4 space are, as Randy put it, just rearranging the deck chairs on the Titanic, and presents a picture to the public that there are ways to artificially extend the life of IPv4. It would be better if ARIN said "IPv4 is on its way out, we'll manage what we have left, but we're not going to work at extending its natural life." Regards, Mike On 8/23/08 8:59 AM, "John Curran" wrote: > On Aug 23, 2008, at 10:40 AM, William Herrin wrote: >> > >> What's more, the presentations made to gain the community consensus >> that led to NCR-9218742's amendment 6 repeatedly promised that what >> came to be known as the legacy registrations would remain untouched by >> ARIN except to provide whois and rdns services. >> http://rip.psg.com/~randy/970414.fncac.pdf is was such a presentation, >> made to the FNC in support of ARIN's formation. See page 9, >> specifically: "Current and old allocations and their DNS will be >> maintained with no policy changes" > > You're right! That presentation was made after adoption of RFC 2050, > which specifically calls for invalidation of existing assignments which > are no longer needed. > > No change to address management policy was implied by creation of ARIN; > the same address blocks that were obtained via US government auspices > so that one could to participate in the Internet and Internet Protocol > development were already covered by this policy in place at the time. > >> Inclusion of that statement was no mistake. "The Community" insisted >> on it. > > Correct! > >> We're left with: no explicit grant of authority over the legacy > >> registrations, and the historical documents that do talk about it >> suggest that the intention was to -not- grant such authority. > > I'm sorry, why did you expect such? Your allocations were always made > under the authority of the IANA and based on your need for address > space. > The fact that we corrected the address subnet boundaries to allow for > a better fit (CIDR) was the only major change, and if you happen to have > been sitting on a "class A" or class B address block, it sure would have > been nice if you returned the excess space which was provided to you > due to this technical flaw in the original block allocation sizes. The > reasons that some organizations did not are varied, and mostly related > to > pain of renumbering, sparse allocation, and similar technical issues > [ref: ] > >>> Frankly, I'd rather not think about this, and hope that this >>> particular chain of succession remain nothing more than an >>> interesting historical tidbit best ignored. >> >> You'll get no argument from me on this point. >> >> However, when v4 depletion is reached you'll find yourself under >> pressure to reclaim the fallow address space, however little it may >> be. To do so successfully you'll need to first normalize relations >> with the registrants whose legacy space is still in service. The only >> two ways you do that without creating a godawful mess for yourself are >> to either seek an explicit grant of authority from the USG that >> supersedes the old community agreements > > The first direction above (reliance upon "authority") doesn't follow the > principles of industry self-governance, and should be avoided at all > costs. > There's an fairly large "mess" whether one relies upon existing > delegation > of authority or whether one attempts to refresh it in some manner. > >> -OR- convince the vast majority of legacy registrants to voluntarily >> sign contracts with ARIN so that when you declare the rest of the >> space >> dead and expired there's no one left to raise a stink. > > The second direction above is the correct one (IMHO), although I expect > there'll always be someone left to "raise a stick" and ARIN must > prepared > accordingly if we're directed by the community to do anything with > respect > to legacy address reclamation. > >> .. >> ARIN's authority and autonomy derive from the *strong* consensus of >> the community it serves. That autonomy will end when ARIN places >> itself at the center of a dispute that results in a fall to weak >> consensus and the defection of any significant minority of that >> community. > > > We aim to please. If the consensus of the Internet community in the > ARIN > region is to undertake some action here, then we will very likely do so. > It should be made very clear that ARIN serves the entire Internet > community > in the ARIN region, and not simply those who have taken the time and > effort > to participate as members. It is that reality which 1) causes ARIN to > undertake more outreach than might otherwise be expected, and 2) makes > the > measurement of consensus for the "ARIN region Internet community" quite > difficult. > > /John > (my opinions only; 100% of the electrons used in this email are from > recycled matter) > > > > > > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From randy at psg.com Sat Aug 23 13:04:44 2008 From: randy at psg.com (Randy Bush) Date: Sat, 23 Aug 2008 10:04:44 -0700 Subject: [arin-ppml] ARIN's Authority - One view In-Reply-To: References: Message-ID: <48B0432C.3020206@psg.com> Michael K. Smith wrote: > I think all of the efforts to manipulate and control IPv4 space are, > as Randy put it, just rearranging the deck chairs on the Titanic as joanie used to say, think of all the foolish people who declined dessert on the titanic. :) > It would be better if ARIN said "IPv4 is on its way out, we'll manage > what we have left, but we're not going to work at extending its > natural life." how about "we are trying to achieve the serenity to accept the things we cannot change significantly, the courage to change the things we can, and the wisdom to know the difference." (stolen from the serenity prayer, provenance disputed) randy From Lee.Howard at stanleyassociates.com Sat Aug 23 13:29:32 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Sat, 23 Aug 2008 13:29:32 -0400 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B0CC5F3@CL-S-EX-1.stanleyassociates.com> Mike Smith wrote: > I would like to see ARIN focus on the end-game of IPv4 and > the adoption of IPv6, both through policy and press. I think > all of the efforts to manipulate and control IPv4 space are, > as Randy put it, just rearranging the deck chairs on the > Titanic, and presents a picture to the public that there are > ways to artificially extend the life of IPv4. It would be > better if ARIN said "IPv4 is on its way out, we'll manage > what we have left, but we're not going to work at extending > its natural life." What can we do to ease the transition to IPv6? Lee From randy at psg.com Sat Aug 23 13:33:32 2008 From: randy at psg.com (Randy Bush) Date: Sat, 23 Aug 2008 10:33:32 -0700 Subject: [arin-ppml] ARIN's Authority - One view In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40B0CC5F3@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB40B0CC5F3@CL-S-EX-1.stanleyassociates.com> Message-ID: <48B049EC.3000309@psg.com> > What can we do to ease the transition to IPv6? see slides 40 onward of note that no action beyond what is being done already is asked of the rirs. randy From JOHN at egh.com Sat Aug 23 13:34:17 2008 From: JOHN at egh.com (John Santos) Date: Sat, 23 Aug 2008 13:34:17 -0400 Subject: [arin-ppml] Legacy space holders were a big part of the community... i.e. all of it. In-Reply-To: Message-ID: <1080823130905.27224A-100000@Ives.egh.com> On Sat, 23 Aug 2008, John Curran wrote: > On Aug 21, 2008, at 2:01 AM, Milton L Mueller wrote: > > Paul > > One can make a good case for a unified, consistent address governance > > regime that would involve eliminating legacy holder's special rights > > and > > bringing everyone in under the same kind of contract. > > Equating absence of an agreement with "special rights" is interesting, > but that's probably best saved for another time. > > > But one cannot make the case you want to make based on appeals to "the > > community" and "consensus." Because the legacy holders are part of > > "the > > community." A big part of it, in North America. And I suspect that > > they > > will never agree to be part of a "consensus" that eliminates their > > special status. > > It is a very relevant point, since almost all of those same legacy > holders were certainly part of the consensus decision in 1993 to > change the basic IP address structure to allow variable sized > blocks (aka "CIDR") and the matching matching address allocation > policies (RFC1466/RFC1518/RFC1519). These documents state that > an organization should receive sufficient address space to meet > two years worth of organization need, so that we could "delay > depletion of the IP address space". > > The community of the legacy space allocation era actually already > reached consensus years ago that variable-sized blocks were needed > and that organizational allocations based on two years of need were > most appropriate. They just forgot to return their own extra space, > for reasons unknown, and at this point are best off if they can > simultaneously deny that they were part of the community that were > involved in these decisions but somehow were still part of the team > that earned their legacy allocation by helping build the Internet... > good luck with that. You are assuming that legacy holders are hanging on to "extra" space and refusing to return it. That is certainly not the case. As an existence proof, I am a legacy holder and am using most of my space. (As of today, 134 of 256 addresses staticly allocated, plus a bunch of DHCP space.) Under the rules in effect at the time I applied, my company was entitled to a class C (/24.) What scares me is the implication or possibility that, despite the fact that I am still entitled to a /24 under those rules, I am not entitled to a /22 under the current rules and if I sign on with ARIN, I risk losing my /24. A lot of people on this list seem perfectly happy with changing the rules in the middle of the game and applying them retroactively to others. In most or all cases, these people have nothing to lose under the new rules and a possibility of financial gain by them. I am refering specifically to ISPs that, despite their protestations that addresses are not property, will cheerfully lease them to me from their own allocations, forcing me to renumber and locking me into their service (unless I want to renumber again in order to move to a competing ISP.) If you can guarantee that I won't be forced to give up my /24 as long as I continue to use it, and "continue to use it" won't be redefined out from under me, then I would consider signing the LRSA. Otherwise, I feel I would be taking a huge risk for no perceivable benefit. The $100/year isn't an issue, and I have no intention of ever selling the addresses on Ebay or anywhere else. > > /John > (most certainly speaking individually) > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From jcurran at istaff.org Sat Aug 23 13:40:29 2008 From: jcurran at istaff.org (John Curran) Date: Sat, 23 Aug 2008 13:40:29 -0400 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: References: Message-ID: On Aug 23, 2008, at 12:55 PM, Michael K. Smith wrote: > > 1) Extend the life of IPv4 - opinions vary, but most data seems to > suggest > that even the best case scenario if all space was returned is that > it won't > extend it by much (6 months, 1 year?) The LRSA really doesn't do much for extension of the life of IPv4; there's a clause which allows for fee reduction on return of some percentage of resources, but I believe it's been infrequently taken up to date. > 2) Normalize WHOIS and in-addr.arpa information - I question whether > an LRSA > or any other policy is really needed here. As many have pointed > out, there > is no commonality of the old records; some have invalid contact info > but are > still valid, some have totally invalid info, some are routed and some > aren't, etc. With this many discrepancies, and with the historical > reference presented by Bill and John, better policy would seem to be > a broad > statement of "we want WHOIS and in-addr.arpa to be accurate" and > then build > the tools to help with the process, and understand that there is > still going > to be a lot of bad information. Such is life. There's little doubt that as part of signing the LRSA, the records are put in a state of much higher integrity. This benefit, plus avoiding having ARIN's resources (paid for by the membership) not used for those who don't participate in the organization, are what I have heard most often cited as benefits of this approach. > I would like to see ARIN focus on the end-game of IPv4 and the > adoption of > IPv6, both through policy and press. I think all of the efforts to > manipulate and control IPv4 space are, as Randy put it, just > rearranging the > deck chairs on the Titanic, and presents a picture to the public > that there > are ways to artificially extend the life of IPv4. The only direct implication of the LRSA with respect to IPv4 depletion is each legacy holder who signs the LRSA is one less block that is subject to being hijacked in the coming period of IPv4 free pool depletion. We can do a lot to refresh contact information, but a current contractual agreement is the best protection. /John From randy at psg.com Sat Aug 23 13:44:05 2008 From: randy at psg.com (Randy Bush) Date: Sat, 23 Aug 2008 10:44:05 -0700 Subject: [arin-ppml] ARIN's Authority - One view In-Reply-To: References: Message-ID: <48B04C65.5070503@psg.com> > The only direct implication of the LRSA with respect to IPv4 > depletion is each legacy holder who signs the LRSA is one less > block that is subject to being hijacked in the coming period > of IPv4 free pool depletion. We can do a lot to refresh > contact information, but a current contractual agreement is > the best protection. imiho, a private key matching the public key in an x.509/3779 cert that validates up to the iana is by far a better protection. my noc can not check your contract. it can validate a cert. rand From jcurran at istaff.org Sat Aug 23 13:45:40 2008 From: jcurran at istaff.org (John Curran) Date: Sat, 23 Aug 2008 13:45:40 -0400 Subject: [arin-ppml] ARIN's Authority - One view In-Reply-To: <48B04C65.5070503@psg.com> References: <48B04C65.5070503@psg.com> Message-ID: On Aug 23, 2008, at 1:44 PM, Randy Bush wrote: >> The only direct implication of the LRSA with respect to IPv4 >> depletion is each legacy holder who signs the LRSA is one less >> block that is subject to being hijacked in the coming period >> of IPv4 free pool depletion. We can do a lot to refresh >> contact information, but a current contractual agreement is >> the best protection. > > imiho, a private key matching the public key in an x.509/3779 cert > that > validates up to the iana is by far a better protection. my noc can > not > check your contract. it can validate a cert. Full agreement, /John From jcurran at istaff.org Sat Aug 23 13:51:51 2008 From: jcurran at istaff.org (John Curran) Date: Sat, 23 Aug 2008 13:51:51 -0400 Subject: [arin-ppml] What can we do to ease the transition? (was: ARIN's Authority - One view) In-Reply-To: <48B049EC.3000309@psg.com> References: <369EB04A0951824ABE7D8BAC67AF9BB40B0CC5F3@CL-S-EX-1.stanleyassociates.com> <48B049EC.3000309@psg.com> Message-ID: <898B6D51-5637-4660-A23C-2473965210E0@istaff.org> On Aug 23, 2008, at 1:33 PM, Randy Bush wrote: > see slides 40 onward of > > note that no action beyond what is being done already is asked of > the rirs. Randy's been around long enough to have seen the consequences of accidently spurring organizations to "get involved"... :-) I'd like to add that it would be nice if every organization worked on getting its public-facing servers (web, email, dns) reachable via IPv6 as soon as possible. Even ISP's who are presently working on very real issues with full IPv6 internal deployment might want to consider at least IPv6-enabling their public servers in the interim. The reason for this is simple: the workload on any transition mechanisms is going to be somewhat proportional to the number of public-facing resources which are still IPv4-only. There is also the benefit of obtaining some real-world experience with IPv6 outside of the lab but still short of swinging your backbone routing... /John p.s. My personal rant along these lines is contained in RFC5211. From mksmith at adhost.com Sat Aug 23 14:09:58 2008 From: mksmith at adhost.com (Michael K. Smith) Date: Sat, 23 Aug 2008 11:09:58 -0700 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40B0CC5F3@CL-S-EX-1.stanleyassociates.com> Message-ID: On 8/23/08 10:29 AM, "Howard, W. Lee" wrote: > Mike Smith wrote: >> I would like to see ARIN focus on the end-game of IPv4 and >> the adoption of IPv6, both through policy and press. I think >> all of the efforts to manipulate and control IPv4 space are, >> as Randy put it, just rearranging the deck chairs on the >> Titanic, and presents a picture to the public that there are >> ways to artificially extend the life of IPv4. It would be >> better if ARIN said "IPv4 is on its way out, we'll manage >> what we have left, but we're not going to work at extending >> its natural life." > > > What can we do to ease the transition to IPv6? > > Lee 1) Formally announce that ARIN supports the data that suggests IPv4 will run out in the near future. 2) Remove associations between IPv4 and IPv6 allocations in the NRPM 6.5.8 so that IPv6 allocations are based solely upon their own merit. 3) Provide a mechanism for legacy holders to obtain IPv6 space without having to make any modifications to their existing legacy allocation. 4) Maintain a promotional fee structure until the last IPv4 address is allocated. 5) Focus marketing and outreach resources on the IPv4 runout and IPv6. Regards, Mike From randy at psg.com Sat Aug 23 14:12:45 2008 From: randy at psg.com (Randy Bush) Date: Sat, 23 Aug 2008 11:12:45 -0700 Subject: [arin-ppml] What can we do to ease the transition? In-Reply-To: <898B6D51-5637-4660-A23C-2473965210E0@istaff.org> References: <369EB04A0951824ABE7D8BAC67AF9BB40B0CC5F3@CL-S-EX-1.stanleyassociates.com> <48B049EC.3000309@psg.com> <898B6D51-5637-4660-A23C-2473965210E0@istaff.org> Message-ID: <48B0531D.4060608@psg.com> John Curran wrote: > On Aug 23, 2008, at 1:33 PM, Randy Bush wrote: >> see slides 40 onward of >> >> note that no action beyond what is being done already is asked of >> the rirs. i lied, well have regretted the absoluteness of my statement. i think the five /8s proposal (already passed in arin, lacnic, and afrinic, apnic and ripe to go) is a wise one. i think the proposal in apnic for how to use that last /8 is a wise one which gives a path to ensure new entrants can get enough v4 space to run nat-pt or whatever so the transition can work without balkanization. > Randy's been around long enough to have seen the consequences > of accidently spurring organizations to "get involved"... :-) a few years back, i had a tee shirt made which says "running code and run away before someone comes to help" > I'd like to add that it would be nice if every organization > worked on getting its public-facing servers (web, email, dns) > reachable via IPv6 as soon as possible. yes! as a hint, here is what i had to do, ymwv randy From mksmith at adhost.com Sat Aug 23 14:21:41 2008 From: mksmith at adhost.com (Michael K. Smith) Date: Sat, 23 Aug 2008 11:21:41 -0700 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: Message-ID: On 8/23/08 10:40 AM, "John Curran" wrote: >> 2) Normalize WHOIS and in-addr.arpa information - I question whether >> an LRSA >> or any other policy is really needed here. As many have pointed >> out, there >> is no commonality of the old records; some have invalid contact info >> but are >> still valid, some have totally invalid info, some are routed and some >> aren't, etc. With this many discrepancies, and with the historical >> reference presented by Bill and John, better policy would seem to be >> a broad >> statement of "we want WHOIS and in-addr.arpa to be accurate" and >> then build >> the tools to help with the process, and understand that there is >> still going >> to be a lot of bad information. Such is life. > > There's little doubt that as part of signing the LRSA, the > records are put in a state of much higher integrity. This > benefit, plus avoiding having ARIN's resources (paid for by > the membership) not used for those who don't participate in > the organization, are what I have heard most often cited as > benefits of this approach. > >> I would like to see ARIN focus on the end-game of IPv4 and the >> adoption of >> IPv6, both through policy and press. I think all of the efforts to >> manipulate and control IPv4 space are, as Randy put it, just >> rearranging the >> deck chairs on the Titanic, and presents a picture to the public >> that there >> are ways to artificially extend the life of IPv4. > > The only direct implication of the LRSA with respect to IPv4 > depletion is each legacy holder who signs the LRSA is one less > block that is subject to being hijacked in the coming period > of IPv4 free pool depletion. We can do a lot to refresh > contact information, but a current contractual agreement is > the best protection. > > /John > I'm not sure I follow the logic. On the one hand, people don't want ARIN resources used for maintaining Legacy holders info but, on the other hand, we want to bring them under ARIN's legal umbrella and therefore incur legal liability by having the legacy resources under contract. I return to your email of the original relationship between ARIN and Legacy. ARIN agreed to provide services to Legacy space for WHOIS and in-addr.arpa. We should continue to do so. Anything that happens with Legacy space vis a vis hijacking, buying and selling, etc. is outside of ARIN's roles and responsibilities. We just assign and maintain records for the address space allocated to us by IANA. Easy. Mike From owen at delong.com Sat Aug 23 14:23:20 2008 From: owen at delong.com (Owen DeLong) Date: Sat, 23 Aug 2008 11:23:20 -0700 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: References: Message-ID: <902DFE43-805D-4EA3-9437-9C2CF35A5F49@delong.com> > 1) Formally announce that ARIN supports the data that suggests IPv4 > will run > out in the near future. This has been done in multiple ways in multiple fora. > > 2) Remove associations between IPv4 and IPv6 allocations in the NRPM > 6.5.8 > so that IPv6 allocations are based solely upon their own merit. There are policies which provide for IPv6 allocations solely on their own merit. The provisions in 6.5.8 are intended to make it EASIER for IPv4 holders to obtain IPv6 space with lower administrative overhead than if they had not already been through the ARIN process to get their IPv4 space. If we removed 6.5.8, it would only remove this simplification for existing IPv4 users to transition. It would not make anything easier in terms of getting IPv6 on its own merit. Is that what you intend? > > 3) Provide a mechanism for legacy holders to obtain IPv6 space without > having to make any modifications to their existing legacy allocation. Legacy holders can apply for IPv6 space under existing policy without regard to their IPv4 holdings if they so desire. In so doing, no modification to their IPv4 space occurs. This is usually not the most favorable set of terms under which to do so, but, it is available. > > 4) Maintain a promotional fee structure until the last IPv4 address is > allocated. So far, there has been no indication that promotional fee structures have accomplished much. However, I'm not opposed to this idea. > > 5) Focus marketing and outreach resources on the IPv4 runout and IPv6. > I think this is already happening Owen From cliffb at cjbsys.bdb.com Sat Aug 23 14:25:32 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Sat, 23 Aug 2008 14:25:32 -0400 Subject: [arin-ppml] Alternate LRSA Message-ID: <48B0561C.50405@cjbsys.bdb.com> After reading all the debate/discussion etc about what to do about getting legacy users into the fold, I'll offer the following idea. It is somewhat along the lines of the LRSA-lite that some have talked about. It will probably take some wordsmithing to make it a formal document but here are the general ideas. Definitions ARIN: American Registry for Internet Numbers Legacy address holder (LAH):. Any group, organization or individual who was legitimately issued address space prior to formation of ARIN This document spells out rights and responsibilities between the LAH and ARIN regarding services provided by ARIN to the LAH.and obligations of the LAH to ARIN. ARIN may require LAH to provide adequate proof of ownership/right to use the address space covered by this document. ARIN recognizes the unique status of the addresses assigned to the LAH and this document does not address ownership/rights of ARIN to control these addresses LAH recognizes the value of services provided by ARIN and without surrendering any rights regarding the addresses desires to contribute to the smooth operation of the ARIN community. ARIN agrees to provide whois, in-addr-arpa and other standard services to the LAH for $100.00/year, not to increase for 5 years and not more than $25.00/year thereafter (Feel free to offer suggestions on amounts/time frames here) Should LAH fail to pay these fees in a reasonable manner and time-frame, this document shall be rendered null and void and the ARIN and LAH status will revert to what it was prior to this agreement. Should this happen, LAH recognizes that actions outside the scope of this document may allow ARIN to discontinue those services it currently provides for LAH and/or gain control of LAH address space. LAH agrees to maintain up-to-date contact and other information as required by ARIN to provide it's standard services ARIN recognizes that due to the unique nature of the LAH addresses, LAH may be able to transfer it's addresses to a third party outside of ARIN rules and regulations. The resolution of this ability is outside the scope of this document. LAH recognizes that actions outside the scope of this document may result in ARIN or some other organization being given some level of control over LAH's rights regarding use of the LAH address space. Such action may render this document null and void.. ARIN and LAH recognize that either party may take action to resolve ownership/right to use LAH address space or other issues and that such resolution may result in the document becoming null and void. Should this document be rendered null and void, ARIN and LAH agree that with regards to this document, ARIN and LAH status will revert to what it was prior to this agreement. I realize that this will probably upset some and generate some debate but I think it allows ARIN and LAHs to reach an accommodation regarding LAHs contributing to the community and ARIN's need to have accurate and up-to-date information available on LAH address space and won't unduly abrogate LAH rights regarding their address space. Cliff . From Lee.Howard at stanleyassociates.com Sat Aug 23 14:43:53 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Sat, 23 Aug 2008 14:43:53 -0400 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B0CC5F9@CL-S-EX-1.stanleyassociates.com> > > What can we do to ease the transition to IPv6? > > > 1) Formally announce that ARIN supports the data that > suggests IPv4 will run out in the near future. We have said "We're running out, start using IPv6." http://www.arin.net/announcements/2007/20070801.html http://www.arin.net/announcements/2007/20070521.html I would not be surprised if we issue further statements. I personally am comfortable saying, "The best current data suggest IANA will run out of unallocated IPv4 addresses in early 2011." > 2) Remove associations between IPv4 and IPv6 allocations in > the NRPM 6.5.8 so that IPv6 allocations are based solely upon > their own merit. What criteria would be appropriate for evaluating end-user assignments? This would be perfect for a policy proposal. > 3) Provide a mechanism for legacy holders to obtain IPv6 > space without having to make any modifications to their > existing legacy allocation. That seems inconsistent with your #2. > 4) Maintain a promotional fee structure until the last IPv4 > address is allocated. We decided to stop waiving all IPv6 fees, but fees are partially waived for the next several years. http://www.arin.net/billing/fee_schedule.html#waivers 90% waived in 2008. 75% waived in 2009. And so on. Also, if you're already paying for allocation services for IPv4, your initial IPv6 allocation is free, and you only pay the larger of your IPv4 of IPv6 renewal. > 5) Focus marketing and outreach resources on the IPv4 runout and IPv6. Working on it. I'd like some more specific suggestions on this. Lee From jcurran at istaff.org Sat Aug 23 14:54:12 2008 From: jcurran at istaff.org (John Curran) Date: Sat, 23 Aug 2008 14:54:12 -0400 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: References: Message-ID: <123BC509-C608-4002-9263-B5270D56B7FB@istaff.org> On Aug 23, 2008, at 2:21 PM, Michael K. Smith wrote: > > I return to your email of the original relationship between ARIN and > Legacy. > ARIN agreed to provide services to Legacy space for WHOIS and in- > addr.arpa. > We should continue to do so. Anything that happens with Legacy > space vis a > vis hijacking, buying and selling, etc. is outside of ARIN's roles and > responsibilities. We just assign and maintain records for the > address space > allocated to us by IANA. Easy. A simple, well-phrased position that would certainly make chairing ARIN a lot easier :-) There's an explicit assumption that our current responsibility "to manage and help conserve scarce Internet protocol resources" would be addressed by whatever market appeared outside of ARIN... i.e. I'm not sure our mission exactly lines up with that position, unless one has a *lot* of faith. However, this is your (collective) organization, and things like articles of incorporation could be revised if that approach turns out to be the best way to achieve the overall goals. /John From vixie at isc.org Sat Aug 23 20:41:06 2008 From: vixie at isc.org (Paul Vixie) Date: Sun, 24 Aug 2008 00:41:06 +0000 Subject: [arin-ppml] Whois Integrity Policy Proposal In-Reply-To: <7EC421F755E45242A47938C3B6F634B10115173C@hnetavail1.exchange.handynetworks.com> (Jay Sudowski's message of "Fri\, 22 Aug 2008 15\:19\:48 -0600") References: <369EB04A0951824ABE7D8BAC67AF9BB40B0CC51D@CL-S-EX-1.stanleyassociates.com> <17838240D9A5544AAA5FF95F8D520316049030CD@ad-exh01.adhost.lan> <7EC421F755E45242A47938C3B6F634B10115173C@hnetavail1.exchange.handynetworks.com> Message-ID: jay at handynetworks.com ("Jay Sudowski - Handy Networks LLC") writes: > I concur. I see no reason why we should subsidize the services that > legacy allocations currently receive for free. Let them maintain their > own WHOIS and in-addr.arpa servers. i'd like WHOIS and in-addr.arpa to be universal, complete, and accurate, and i think that serves the community's interests moreso than even the registrant's interests. let's not cut off our nose to spite our face. -- Paul Vixie -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From mksmith at adhost.com Sat Aug 23 22:30:50 2008 From: mksmith at adhost.com (Michael K. Smith) Date: Sat, 23 Aug 2008 19:30:50 -0700 Subject: [arin-ppml] Whois Integrity Policy Proposal In-Reply-To: Message-ID: On 8/23/08 5:41 PM, "Paul Vixie" wrote: > jay at handynetworks.com ("Jay Sudowski - Handy Networks LLC") writes: > >> I concur. I see no reason why we should subsidize the services that >> legacy allocations currently receive for free. Let them maintain their >> own WHOIS and in-addr.arpa servers. > > i'd like WHOIS and in-addr.arpa to be universal, complete, and accurate, > and i think that serves the community's interests moreso than even the > registrant's interests. let's not cut off our nose to spite our face. Hopefully the dialog has progressed to the viability of maintaining the service of WHOIS and in-addr.arpa to the Legacy holders without requiring any sort of agreement with ARIN. This was the original design and I can't see any reason to change it. Mike From sleibrand at internap.com Sat Aug 23 23:26:30 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Sat, 23 Aug 2008 20:26:30 -0700 Subject: [arin-ppml] Legacy space holders were a big part of the community... i.e. all of it. In-Reply-To: <1080823130905.27224A-100000@Ives.egh.com> References: <1080823130905.27224A-100000@Ives.egh.com> Message-ID: <48B0D4E6.50400@internap.com> John Santos wrote: > Under the rules in effect at the time I applied, my company was > entitled to a class C (/24.) What scares me is the implication > or possibility that, despite the fact that I am still entitled to > a /24 under those rules, I am not entitled to a /22 under the > current rules and if I sign on with ARIN, I risk losing my /24. As far as I can tell, the carrot offered by the LRSA is precisely that: ARIN acknowledges your right, as long as the contract stands, to keep your legacy space. > If you can guarantee that I won't be forced to give up my > /24 as long as I continue to use it, and "continue to use it" > won't be redefined out from under me, then I would consider > signing the LRSA. Otherwise, I feel I would be taking a > huge risk for no perceivable benefit. Have you read the LRSA carefully with that in mind? After doing so, what concerns, if any, do you still have with the LRSA? -Scott From sleibrand at internap.com Sat Aug 23 23:50:21 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Sat, 23 Aug 2008 20:50:21 -0700 Subject: [arin-ppml] Policy to ease transition to IPv6 In-Reply-To: References: Message-ID: <48B0DA7D.7000503@internap.com> Michael K. Smith wrote: >> What can we do to ease the transition to IPv6? > > 2) Remove associations between IPv4 and IPv6 allocations in the NRPM 6.5.8 > so that IPv6 allocations are based solely upon their own merit. Currently, IPv6 policy for allocation of /48's to end-user orgs includes current IPv4 policy by reference, which avoids duplicating all the current text and requirements. In formulating the policy proposal that led to the addition of 6.5.8 to the NRPM, it's worth noting that there was *a lot* of discussion about host counts, subnet counts, and many other arcane details, so in the end we went with the consensus position of "if you qualify for IPv4, then you qualify for IPv6 too." Would you be interested in formulating a policy proposal that removes that reference and replaces it with similar requirements, as is done for LIRs in 6.5.1.1? > 3) Provide a mechanism for legacy holders to obtain IPv6 space without > having to make any modifications to their existing legacy allocation. Current policy allows legacy holders to obtain IPv6 space without reference or modification to their existing legacy address holdings. They simply apply as a new applicant, under the same set of rules as a new business who doesn't have or need any IPv4 space from ARIN. In addition, a clause was recently added to 6.5.8.1 that allows legacy holders who *don't* qualify as a new LIR or end-user applicant to get IPv6 space, by demonstrating efficient use of their current address holdings and bringing them under RSA or LRSA. Use of that route is entirely optional, however: any legacy holder with enough hosts to qualify for a singly-homed /20 or a multi-homed /22, or is an LIR with a plan for 200 customers, can simply get IPv6 space directly as a new applicant. Given the above, do you still see any need for policy work in this space? Thanks, Scott From tedm at ipinc.net Sun Aug 24 02:52:20 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Sat, 23 Aug 2008 23:52:20 -0700 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran > Sent: Saturday, August 23, 2008 10:40 AM > To: Michael K.Smith > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN's Authority - One view (was: > Re: LRSA concerns) > > > The only direct implication of the LRSA with respect to IPv4 > depletion is each legacy holder who signs the LRSA is one > less block that is subject to being hijacked in the coming > period of IPv4 free pool depletion. We can do a lot to > refresh contact information, but a current contractual > agreement is the best protection. > Frankly, the existence of a large number of legacy holders who refuse to sign the LRSA would be a Good Thing from one respect. Reason being is that it would increase the amount of trouble that IPv4 would be for the Internet community post-IPv4 runout, and would be a big incentive for people to start considering the IPv6 network on the Internet as the more trustworthy of the two. Think of the IP numbering pool as a city and IPv4 as the red-light district full of moldering brownstones and IPv6 as the nice new mall/retail/condo section. All of us are living in the brownstones right now but in 20 years most of us are going to be in the strip mall & condo section, shaking our heads over the morning paper at the latest hijacking in the IPv4 district and writing letters to our city to put more cops in there to run the bums out of town. The Legacy holders who cling to their large IPv4 holdings are going to end up with the pimps, whores and drug dealers of the IPv4 Internet. In healthy cities with good urban renewal programs that do not have a collapsed central core, every year the red light district gets smaller and smaller because the amount of trouble it causes is disproportionately higher than the benefit it brings to the city (especially since most of the porn has gone online these days the adult bookstores aren't even putting money into the city tax roles anymore) So, I encourage the Legacy holders that don't want to stop using their IPv4 holdings. The more of you that are out there doing it, the quicker the rest of us will get tired of dealing with all the trouble your causing and the faster we will switch to IPv6 and leave you to your crummy network. How's that for a visual? ;-) Ted From mueller at syr.edu Sun Aug 24 11:09:02 2008 From: mueller at syr.edu (Milton L Mueller) Date: Sun, 24 Aug 2008 11:09:02 -0400 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: References: Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0E385@SUEXCL-02.ad.syr.edu> Ted's comment raises an issue that I see coming to the fore more often here and elsewhere. Is it legitimate for an RIR to consider itself a promoter of IPv6 and to shape its policies to "nudge" or push people in that direction, or should it be a neutral administrator of address resources, try to manage both spaces as efficiently as possible and leave migration policies to organizations, governments, users, etc? I myself find repugnant the idea that you might deliberately try to turn an area of the address space into a sleazy area in order to "encourage" v6 migration. It seems better to have efficient and effective policies in place in both address spaces and let technical and economic issues sort out the migration. > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Ted Mittelstaedt > Frankly, the existence of a large number of legacy holders > who refuse to sign the LRSA would be a Good Thing from one > respect. Reason being is that it would increase the amount > of trouble that IPv4 would be for the Internet community > post-IPv4 runout, and would be a big incentive for people > to start considering the IPv6 network on the Internet as the > more trustworthy of the two. > > Think of the IP numbering pool as a city and IPv4 as the red-light > district full of moldering brownstones and IPv6 as the nice new > mall/retail/condo section. > > All of us are living in the brownstones right now but > in 20 years most of us are going to be in the strip mall & condo > section, shaking our heads over the morning paper at the > latest hijacking in the IPv4 district and writing letters > to our city to put more cops in there to run the bums out > of town. > > The Legacy holders who cling to their large IPv4 holdings are > going to end up with the pimps, whores and drug dealers of > the IPv4 Internet. > > In healthy cities with good urban renewal programs that do not > have a collapsed central core, every year the red light district > gets smaller and smaller because the amount of trouble it causes > is disproportionately higher than the benefit it brings to the > city (especially since most of the porn has gone online these days > the adult bookstores aren't even putting money into the city tax > roles anymore) > > So, I encourage the Legacy holders that don't want to stop > using their IPv4 holdings. The more of you that are out there > doing it, the quicker the rest of us will get tired of dealing > with all the trouble your causing and the faster we will switch > to IPv6 and leave you to your crummy network. > > How's that for a visual? ;-) > > Ted > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mueller at syr.edu Sun Aug 24 11:13:47 2008 From: mueller at syr.edu (Milton L Mueller) Date: Sun, 24 Aug 2008 11:13:47 -0400 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: References: Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0E386@SUEXCL-02.ad.syr.edu> I disagree. ARIN should focus on efficient and appropriate management of the scarcity of IPv4 resources. Neither you, nor I, nor ARIN knows when or even if a migration will occur. All policies should be based on acceptance of that fact, and seek to manage both v4 and v6 resources as effectively and efficiently as possible. > -----Original Message----- > > I would like to see ARIN focus on the end-game of IPv4 and the adoption of > IPv6, both through policy and press. I think all of the efforts to > manipulate and control IPv4 space are, as Randy put it, just rearranging > the > deck chairs on the Titanic, and presents a picture to the public that > there > are ways to artificially extend the life of IPv4. It would be better if > ARIN said "IPv4 is on its way out, we'll manage what we have left, but > we're > not going to work at extending its natural life." > > Regards, > > Mike > > > > On 8/23/08 8:59 AM, "John Curran" wrote: > > > On Aug 23, 2008, at 10:40 AM, William Herrin wrote: > >> > > > >> What's more, the presentations made to gain the community consensus > >> that led to NCR-9218742's amendment 6 repeatedly promised that what > >> came to be known as the legacy registrations would remain untouched by > >> ARIN except to provide whois and rdns services. > >> http://rip.psg.com/~randy/970414.fncac.pdf is was such a presentation, > >> made to the FNC in support of ARIN's formation. See page 9, > >> specifically: "Current and old allocations and their DNS will be > >> maintained with no policy changes" > > > > You're right! That presentation was made after adoption of RFC 2050, > > which specifically calls for invalidation of existing assignments which > > are no longer needed. > > > > No change to address management policy was implied by creation of ARIN; > > the same address blocks that were obtained via US government auspices > > so that one could to participate in the Internet and Internet Protocol > > development were already covered by this policy in place at the time. > > > >> Inclusion of that statement was no mistake. "The Community" insisted > >> on it. > > > > Correct! > > > >> We're left with: no explicit grant of authority over the legacy > > > >> registrations, and the historical documents that do talk about it > >> suggest that the intention was to -not- grant such authority. > > > > I'm sorry, why did you expect such? Your allocations were always made > > under the authority of the IANA and based on your need for address > > space. > > The fact that we corrected the address subnet boundaries to allow for > > a better fit (CIDR) was the only major change, and if you happen to have > > been sitting on a "class A" or class B address block, it sure would have > > been nice if you returned the excess space which was provided to you > > due to this technical flaw in the original block allocation sizes. The > > reasons that some organizations did not are varied, and mostly related > > to > > pain of renumbering, sparse allocation, and similar technical issues > > [ref: ] > > > >>> Frankly, I'd rather not think about this, and hope that this > >>> particular chain of succession remain nothing more than an > >>> interesting historical tidbit best ignored. > >> > >> You'll get no argument from me on this point. > >> > >> However, when v4 depletion is reached you'll find yourself under > >> pressure to reclaim the fallow address space, however little it may > >> be. To do so successfully you'll need to first normalize relations > >> with the registrants whose legacy space is still in service. The only > >> two ways you do that without creating a godawful mess for yourself are > >> to either seek an explicit grant of authority from the USG that > >> supersedes the old community agreements > > > > The first direction above (reliance upon "authority") doesn't follow the > > principles of industry self-governance, and should be avoided at all > > costs. > > There's an fairly large "mess" whether one relies upon existing > > delegation > > of authority or whether one attempts to refresh it in some manner. > > > >> -OR- convince the vast majority of legacy registrants to voluntarily > >> sign contracts with ARIN so that when you declare the rest of the > >> space > >> dead and expired there's no one left to raise a stink. > > > > The second direction above is the correct one (IMHO), although I expect > > there'll always be someone left to "raise a stick" and ARIN must > > prepared > > accordingly if we're directed by the community to do anything with > > respect > > to legacy address reclamation. > > > >> .. > >> ARIN's authority and autonomy derive from the *strong* consensus of > >> the community it serves. That autonomy will end when ARIN places > >> itself at the center of a dispute that results in a fall to weak > >> consensus and the defection of any significant minority of that > >> community. > > > > > > We aim to please. If the consensus of the Internet community in the > > ARIN > > region is to undertake some action here, then we will very likely do so. > > It should be made very clear that ARIN serves the entire Internet > > community > > in the ARIN region, and not simply those who have taken the time and > > effort > > to participate as members. It is that reality which 1) causes ARIN to > > undertake more outreach than might otherwise be expected, and 2) makes > > the > > measurement of consensus for the "ARIN region Internet community" quite > > difficult. > > > > /John > > (my opinions only; 100% of the electrons used in this email are from > > recycled matter) > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From jcurran at istaff.org Sun Aug 24 11:48:01 2008 From: jcurran at istaff.org (John Curran) Date: Sun, 24 Aug 2008 11:48:01 -0400 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E386@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD901E0E386@SUEXCL-02.ad.syr.edu> Message-ID: On Aug 24, 2008, at 11:13 AM, Milton L Mueller wrote: > > I disagree. ARIN should focus on efficient and appropriate > management of > the scarcity of IPv4 resources. Neither you, nor I, nor ARIN knows > when > or even if a migration will occur. All policies should be based on > acceptance of that fact, and seek to manage both v4 and v6 resources > as > effectively and efficiently as possible. Personal opinion follows. In a perfect world (with a perfectly informed global community), I guess I would agree. The decision to deploy or not deploy IPv6 would be based on the unanimous consensus of overall worldwide maximization of benefits to mankind, as well implications to our flora & fauna cohabiters of this fine planet. So, now back to reality... It is questionable whether we can keep the present Internet growing simply using IPv4. To attempt to do so represents (at best) a calculated gamble and (at worst) an irresponsible act with global economic consequences. Due to the inherent nature of IPv4/IPv6 interoperability, it's going to be necessary for many organizations to run both in parallel for some period of time in order to effect the transition. At a minimum, ARIN has an obligation to educate and inform the community in its region that we will be very unlikely to be able to provide access to IPv4 address space sometime in the foreseeable future, and that organizations that were planning on IPv4 address space availability need to take this reality into consideration. We did make such an announcement last May to this effect, and it made a real difference in the level of awareness of this issue. The question remains whether ARIN should take more aggressive measures to educate and inform user of IP numbering resources of this upcoming change, and/or whether ARIN should actively actively encourage migration to IPv6 via policy mechanisms... From the feedback at ARIN's most recent public policy meetings, there has been a clear mandate to increase the outreach on upcoming IPv4 depletion and the need to deploy IPv6. We have not had that level of agreement on using policy mechanisms to encourage IPv6 transition. /John From ray at snewisp.com Sun Aug 24 11:48:44 2008 From: ray at snewisp.com (r ay) Date: Sun, 24 Aug 2008 11:48:44 -0400 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) Message-ID: So that makes ARIN the loan shark, charging the street corner pimp for protection?? I was of the understanding as well, that the legacy's would be left alone. Im only talking about one class C however. There are plenty of them out there that are likely wasted. Make it easy to transition! Ray -----Original Message----- From: "Ted Mittelstaedt" To: "'John Curran'" , "'Michael K.Smith'" Cc: arin-ppml at arin.net Date: Sat, 23 Aug 2008 23:52:20 -0700 Subject: Re: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran > Sent: Saturday, August 23, 2008 10:40 AM > To: Michael K.Smith > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN's Authority - One view (was: > Re: LRSA concerns) > > > The only direct implication of the LRSA with respect to IPv4 > depletion is each legacy holder who signs the LRSA is one > less block that is subject to being hijacked in the coming > period of IPv4 free pool depletion. We can do a lot to > refresh contact information, but a current contractual > agreement is the best protection. > Frankly, the existence of a large number of legacy holders who refuse to sign the LRSA would be a Good Thing from one respect. Reason being is that it would increase the amount of trouble that IPv4 would be for the Internet community post-IPv4 runout, and would be a big incentive for people to start considering the IPv6 network on the Internet as the more trustworthy of the two. Think of the IP numbering pool as a city and IPv4 as the red-light district full of moldering brownstones and IPv6 as the nice new mall/retail/condo section. All of us are living in the brownstones right now but in 20 years most of us are going to be in the strip mall & condo section, shaking our heads over the morning paper at the latest hijacking in the IPv4 district and writing letters to our city to put more cops in there to run the bums out of town. The Legacy holders who cling to their large IPv4 holdings are going to end up with the pimps, whores and drug dealers of the IPv4 Internet. In healthy cities with good urban renewal programs that do not have a collapsed central core, every year the red light district gets smaller and smaller because the amount of trouble it causes is disproportionately higher than the benefit it brings to the city (especially since most of the porn has gone online these days the adult bookstores aren't even putting money into the city tax roles anymore) So, I encourage the Legacy holders that don't want to stop using their IPv4 holdings. The more of you that are out there doing it, the quicker the rest of us will get tired of dealing with all the trouble your causing and the faster we will switch to IPv6 and leave you to your crummy network. How's that for a visual? ;-) Ted -------------- next part -------------- An HTML attachment was scrubbed... URL: From bmanning at vacation.karoshi.com Sun Aug 24 12:01:48 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 24 Aug 2008 16:01:48 +0000 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E386@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD901E0E386@SUEXCL-02.ad.syr.edu> Message-ID: <20080824160148.GB28971@vacation.karoshi.com.> your wording is disingenous. ARIN has a stewardship role over Internet numbering resources. That stewardhip is not address family specific. We should not be swayed by the bias of the percevied value of any given resource. --bill > I disagree. ARIN should focus on efficient and appropriate management of > the scarcity of IPv4 resources. Neither you, nor I, nor ARIN knows when > or even if a migration will occur. All policies should be based on > acceptance of that fact, and seek to manage both v4 and v6 resources as > effectively and efficiently as possible. > > > -----Original Message----- > > > > I would like to see ARIN focus on the end-game of IPv4 and the > adoption of > > IPv6, both through policy and press. I think all of the efforts to > > manipulate and control IPv4 space are, as Randy put it, just > rearranging > > the > > deck chairs on the Titanic, and presents a picture to the public that > > there > > are ways to artificially extend the life of IPv4. It would be better > if > > ARIN said "IPv4 is on its way out, we'll manage what we have left, but > > we're > > not going to work at extending its natural life." > > > > Regards, > > > > Mike > > > > > > > > On 8/23/08 8:59 AM, "John Curran" wrote: > > > > > On Aug 23, 2008, at 10:40 AM, William Herrin wrote: > > >> > > > > > >> What's more, the presentations made to gain the community consensus > > >> that led to NCR-9218742's amendment 6 repeatedly promised that what > > >> came to be known as the legacy registrations would remain untouched > by > > >> ARIN except to provide whois and rdns services. > > >> http://rip.psg.com/~randy/970414.fncac.pdf is was such a > presentation, > > >> made to the FNC in support of ARIN's formation. See page 9, > > >> specifically: "Current and old allocations and their DNS will be > > >> maintained with no policy changes" > > > > > > You're right! That presentation was made after adoption of RFC > 2050, > > > which specifically calls for invalidation of existing assignments > which > > > are no longer needed. > > > > > > No change to address management policy was implied by creation of > ARIN; > > > the same address blocks that were obtained via US government > auspices > > > so that one could to participate in the Internet and Internet > Protocol > > > development were already covered by this policy in place at the > time. > > > > > >> Inclusion of that statement was no mistake. "The Community" > insisted > > >> on it. > > > > > > Correct! > > > > > >> We're left with: no explicit grant of authority over the legacy > > > > > >> registrations, and the historical documents that do talk about it > > >> suggest that the intention was to -not- grant such authority. > > > > > > I'm sorry, why did you expect such? Your allocations were always > made > > > under the authority of the IANA and based on your need for address > > > space. > > > The fact that we corrected the address subnet boundaries to allow > for > > > a better fit (CIDR) was the only major change, and if you happen to > have > > > been sitting on a "class A" or class B address block, it sure would > have > > > been nice if you returned the excess space which was provided to you > > > due to this technical flaw in the original block allocation sizes. > The > > > reasons that some organizations did not are varied, and mostly > related > > > to > > > pain of renumbering, sparse allocation, and similar technical issues > > > [ref: ] > > > > > >>> Frankly, I'd rather not think about this, and hope that this > > >>> particular chain of succession remain nothing more than an > > >>> interesting historical tidbit best ignored. > > >> > > >> You'll get no argument from me on this point. > > >> > > >> However, when v4 depletion is reached you'll find yourself under > > >> pressure to reclaim the fallow address space, however little it may > > >> be. To do so successfully you'll need to first normalize relations > > >> with the registrants whose legacy space is still in service. The > only > > >> two ways you do that without creating a godawful mess for yourself > are > > >> to either seek an explicit grant of authority from the USG that > > >> supersedes the old community agreements > > > > > > The first direction above (reliance upon "authority") doesn't follow > the > > > principles of industry self-governance, and should be avoided at all > > > costs. > > > There's an fairly large "mess" whether one relies upon existing > > > delegation > > > of authority or whether one attempts to refresh it in some manner. > > > > > >> -OR- convince the vast majority of legacy registrants to > voluntarily > > >> sign contracts with ARIN so that when you declare the rest of the > > >> space > > >> dead and expired there's no one left to raise a stink. > > > > > > The second direction above is the correct one (IMHO), although I > expect > > > there'll always be someone left to "raise a stick" and ARIN must > > > prepared > > > accordingly if we're directed by the community to do anything with > > > respect > > > to legacy address reclamation. > > > > > >> .. > > >> ARIN's authority and autonomy derive from the *strong* consensus of > > >> the community it serves. That autonomy will end when ARIN places > > >> itself at the center of a dispute that results in a fall to weak > > >> consensus and the defection of any significant minority of that > > >> community. > > > > > > > > > We aim to please. If the consensus of the Internet community in the > > > ARIN > > > region is to undertake some action here, then we will very likely do > so. > > > It should be made very clear that ARIN serves the entire Internet > > > community > > > in the ARIN region, and not simply those who have taken the time and > > > effort > > > to participate as members. It is that reality which 1) causes ARIN > to > > > undertake more outreach than might otherwise be expected, and 2) > makes > > > the > > > measurement of consensus for the "ARIN region Internet community" > quite > > > difficult. > > > > > > /John > > > (my opinions only; 100% of the electrons used in this email are from > > > recycled matter) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > PPML > > > You are receiving this message because you are subscribed to > > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > > Unsubscribe or manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > Please contact info at arin.net if you experience any issues. > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mksmith at adhost.com Sun Aug 24 15:20:46 2008 From: mksmith at adhost.com (Michael K. Smith) Date: Sun, 24 Aug 2008 12:20:46 -0700 Subject: [arin-ppml] Policy to ease transition to IPv6 In-Reply-To: <48B0DA7D.7000503@internap.com> Message-ID: Hello Scott: On 8/23/08 8:50 PM, "Scott Leibrand" wrote: > Michael K. Smith wrote: >>> What can we do to ease the transition to IPv6? >> >> 2) Remove associations between IPv4 and IPv6 allocations in the NRPM 6.5.8 >> so that IPv6 allocations are based solely upon their own merit. > > Currently, IPv6 policy for allocation of /48's to end-user orgs includes > current IPv4 policy by reference, which avoids duplicating all the current > text and requirements. In formulating the policy proposal that led to the > addition of 6.5.8 to the NRPM, it's worth noting that there was *a lot* of > discussion about host counts, subnet counts, and many other arcane > details, so in the end we went with the consensus position of "if you > qualify for IPv4, then you qualify for IPv6 too." > > Would you be interested in formulating a policy proposal that removes that > reference and replaces it with similar requirements, as is done for LIRs > in 6.5.1.1? > >> 3) Provide a mechanism for legacy holders to obtain IPv6 space without >> having to make any modifications to their existing legacy allocation. > > Current policy allows legacy holders to obtain IPv6 space without > reference or modification to their existing legacy address holdings. They > simply apply as a new applicant, under the same set of rules as a new > business who doesn't have or need any IPv4 space from ARIN. > > In addition, a clause was recently added to 6.5.8.1 that allows legacy > holders who *don't* qualify as a new LIR or end-user applicant to get IPv6 > space, by demonstrating efficient use of their current address holdings > and bringing them under RSA or LRSA. Use of that route is entirely > optional, however: any legacy holder with enough hosts to qualify for a > singly-homed /20 or a multi-homed /22, or is an LIR with a plan for 200 > customers, can simply get IPv6 space directly as a new applicant. > > Given the above, do you still see any need for policy work in this space? > I remember the threads! I still think there is policy work to be done and, with that said, I will get to it. Regards, Mike From cliffb at cjbsys.bdb.com Sun Aug 24 15:43:10 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Sun, 24 Aug 2008 15:43:10 -0400 (EDT) Subject: [arin-ppml] Comprehensive Study Shows IPv6 Shift Isn't Happening Message-ID: <200808241943.m7OJhAHB019085@cjbsys.bdb.com> The ACM Tecnews email referenced the lack of IPv6 adoption as discussed in http://www.extremetech.com/article2/0,2845,2328258,00.asp I found the last paragraph interesting "Craig Labovitz, chief scientist at Arbor, also said there are also discussions going on to make the remaining IPv4 address blocks available on the open market, where they could essentially be auctioned off." Cliff -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From iljitsch at muada.com Sun Aug 24 15:52:57 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 24 Aug 2008 21:52:57 +0200 Subject: [arin-ppml] Comprehensive Study Shows IPv6 Shift Isn't Happening In-Reply-To: <200808241943.m7OJhAHB019085@cjbsys.bdb.com> References: <200808241943.m7OJhAHB019085@cjbsys.bdb.com> Message-ID: <7E4C49BC-2257-4221-A042-1EBBDC95F758@muada.com> On 24 aug 2008, at 21:43, Cliff Bedore wrote: > http://www.extremetech.com/article2/0,2845,2328258,00.asp They talk about the IETF meeting creating a spike. We had 3 Mbps traffic when IPv4 was turned off. That's not even on Arbor's IPv6 radar. > I found the last paragraph interesting > "Craig Labovitz, chief scientist at Arbor, also said there are also > discussions going on to make the remaining IPv4 address blocks > available on > the open market, where they could essentially be auctioned off." I find it extremely uninteresting. An IPv4 market would be unfair (1) and unhelpful (2). We need IPv6 at some point anyway, delaying the inevitable won't do us any favors. However, the only thing that counts is how much IPv6 traffic there will be the day after the last IPv4 address is given out, IPv6 traffic before that is of no consequence. 1 It creates an undeserved windfall for companies and organizations that happen to be sitting on large amounts of v4 address space and it would mean a flow of money from poor regions of the world to rich ones. 2 All this talk about address trading means nobody will want to give them back for free, and market economics in a market with limited supply and high demand implies not only high prices but also unpredictability (the last thing that we need) and all kinds of unwanted behavior such as hoarding. From BillD at cait.wustl.edu Sun Aug 24 19:30:50 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Sun, 24 Aug 2008 18:30:50 -0500 Subject: [arin-ppml] Comprehensive Study Shows IPv6 Shift Isn't Happening References: <200808241943.m7OJhAHB019085@cjbsys.bdb.com> <7E4C49BC-2257-4221-A042-1EBBDC95F758@muada.com> Message-ID: -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of Iljitsch van Beijnum Sent: Sun 8/24/2008 2:52 PM To: Cliff Bedore Cc: arin ppml Subject: Re: [arin-ppml] Comprehensive Study Shows IPv6 Shift Isn't Happening On 24 aug 2008, at 21:43, Cliff Bedore wrote: > http://www.extremetech.com/article2/0,2845,2328258,00.asp They talk about the IETF meeting creating a spike. We had 3 Mbps traffic when IPv4 was turned off. That's not even on Arbor's IPv6 radar. > I found the last paragraph interesting > "Craig Labovitz, chief scientist at Arbor, also said there are also > discussions going on to make the remaining IPv4 address blocks > available on > the open market, where they could essentially be auctioned off." I find it extremely uninteresting. An IPv4 market would be unfair (1) and unhelpful (2). We need IPv6 at some point anyway, delaying the inevitable won't do us any favors. However, the only thing that counts is how much IPv6 traffic there will be the day after the last IPv4 address is given out, IPv6 traffic before that is of no consequence. 1 It creates an undeserved windfall for companies and organizations that happen to be sitting on large amounts of v4 address space and it would mean a flow of money from poor regions of the world to rich ones. 2 All this talk about address trading means nobody will want to give them back for free, and market economics in a market with limited supply and high demand implies not only high prices but also unpredictability (the last thing that we need) and all kinds of unwanted behavior such as hoarding. ------which is the only good thing that I see coming from all the talk of a market...make people nervous enough to move to v6, or at least get on towards it.... Bill Darte -------------- next part -------------- An HTML attachment was scrubbed... URL: From ppml at rs.seastrom.com Mon Aug 25 07:23:41 2008 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Mon, 25 Aug 2008 07:23:41 -0400 Subject: [arin-ppml] Legacy RSA (was: Whois Integrity Policy Proposal) In-Reply-To: <20080821231617.1B6C84500F@ptavv.es.net> (Kevin Oberman's message of "Thu, 21 Aug 2008 16:16:17 -0700") References: <20080821231617.1B6C84500F@ptavv.es.net> Message-ID: <86wsi5pcci.fsf@seastrom.com> "Kevin Oberman" writes: >> This is further clarified in the same paragraph: "A definitive finding >> of a violation of law or regulation when established by a decision of a >> national, state, or other government authority regarding (i) through >> (iii) herein should similarly be sent to ARIN's General Counsel for >> ARIN's review and action." > > This begs the question of "Who's law?" There are businesses (on-line > casinos) operating completely legally in some ARIN countries which are > considered illegal by the US and, if the owners of those companies set > foot in the US, they are subject to arrest and some have been arrested, > convicted and imprisoned. Case in point would be offshore online gambling (in the Caribbean) which is specifically aimed at US citizens. > Even within the US, there are businesses that are explicitly legal under > state laws in many states and illegal under federal laws. (I'm talking > about medicinal pot). One need not go any further than gunbroker.com to find articles advertised that are completely legal in most states but illegal in one or more. Need I even raise some of the misguided overstepping that's happened in some state legislatures regarding "adult content"? > Does ARIN really want to get into this tar pit? I could get behind a notion that fraud in dealing with ARIN should have severe repercussions. The current verbiage seems to suggest that I could get resources pulled if one of my users gets whacked for running a bittorrent tracker full of pirated software metadata, or maybe a tor exit point. Disclaimer: I'm on the AC, I have legacy resources, I have not (yet) signed the LRSA. -r From ppml at rs.seastrom.com Mon Aug 25 07:42:37 2008 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Mon, 25 Aug 2008 07:42:37 -0400 Subject: [arin-ppml] Whois Integrity Policy Proposal -- What is proof and how big is the problem? In-Reply-To: (Owen DeLong's message of "Thu, 21 Aug 2008 08:43:45 -0700") References: <1080821103527.27224A-300000@Ives.egh.com> Message-ID: <86skstpbgy.fsf@seastrom.com> Owen DeLong writes: > As a point of information, the data on 192.159.10.0/24 is still > > correct and accurate and has not been updated since 1998. As a further point of information, AS3066 appears on cursory inspection to not have been updated since 2000, but displays data that was updated in 2006 (see the encompassing orgid for a 'correct' modification date). Regardless of whether Heather's reports take this sort of thing into account, those of us who routinely muck around in the whois data after importing it into SQL are really at a disadvantage with our reverse-engineered schemas, queries, and loadup scripts until ARIN starts publishing actual SQL dumps rather than flat files full of whois output. -r From info at arin.net Mon Aug 25 08:27:20 2008 From: info at arin.net (Member Services) Date: Mon, 25 Aug 2008 08:27:20 -0400 Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation Message-ID: <48B2A528.9000703@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At their following meeting the AC will accept or not accept the proposal. 3. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision via the PPML. If a proposal is not accepted, 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 proposal will be closed. The AC will assign shepherds in the near future. ARIN will provide the names of the shepherds to the community via the PPML. In the meantime, the AC invites everyone to comment on this proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Annual WHOIS POC Validation Author: Chris Grundemann Proposal Version: 1 Submission Date: 21-Aug-2008 Proposal type: new Policy term: permanent Policy statement: ARIN will conduct POC validation annually. This validation will employ an automated system which will send a message to every separate email address in the whois directory. The message sent will request that the receiver verify that they are in fact the POC in question by replying to the email in a manner which will satisfy the automated systems requirements. The email message will also include information and instructions for reporting suspected fraud. If a valid response is not received within 14 days, every instance of the unresponsive email address will be replaced with "REFUSED RESPONSE" in the whois directory. The list of POCs with this marking will be reviewed by ARIN staff and manual contact attempts (telephone, postal mail) can be made at their discretion. After a minimum of three manual contact attempts have been made, with at least one to each physical address and telephone number provided and a minimum of three calendar months have passed from the third qualifying attempt; the POC record should be locked or deleted. The decision of whether to lock or delete the account should be made on a case by case basis. Following this validation each year, a list of address blocks with zero valid POCs should be made easily available to the community. Accurate annual records should be kept with regard to the total number of POCs, the number of POCs marked with "REFUSED RESPONSE," the number of locked POCs and the number of deleted POCs in addition to any other data that ARIN staff believes is appropriate to record with regard to this validation process. These records should be available to the public on request. Rationale: The intention of this proposal is to ensure valid whois POC information with an annual validation process. It further aims to mitigate any risk that it creates in so doing. One of the most important resources when dealing with abuse (including hijacking, spam, ddos, etc) is whois. ARIN's whois data is only useful if it is known to be valid. The current NRPM does not address this in a manner which ensures up to date POC contact information in all cases. The focus is on valid email addresses because this is the contact method of choice for most in the Internet community when dealing with abuse or hijacking issues. POC information that can not be confirmed can be judged as not valid. A netblock with no valid POC presents a target to hijackers. Once POC info is marked or tagged as invalid (like this policy proposes), it becomes possible for potential hijackers to locate such netblocks by searching the whois database. As a defense against such hijacking attempts, this policy proposes that the information be presented in full to the entire community. This should do at least one of two things; bring the netblock to the attention of whomever is responsible for it and/or allow other network operators to understand the potential risk and take appropriate action to mitigate. Timetable for implementation: The first validation should take place within one calendar year of the policy being accepted. From Keith at jcc.com Mon Aug 25 10:25:11 2008 From: Keith at jcc.com (Keith W. Hare) Date: Mon, 25 Aug 2008 10:25:11 -0400 Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation Message-ID: <69854b91ed6d31eaa9e64da655ffa9ed48b2c0c7@jcc.com> > If a valid response >is not received within 14 days, every instance of the unresponsive >email address will be replaced with "REFUSED RESPONSE" in the whois >directory. Since my background is database design and performance, I cringe at the idea of overloading the email address field with what should really be a separate field. However, aside from this implementation detail in a policy proposal, I support the proposal. This will achieve the goal of freezing orphaned resources while sidesteping the quagmire of (L)RSAs and legacy resource holders. Keith ______________________________________________________________ Keith W. Hare JCC Consulting, Inc. keith at jcc.com 600 Newark Road Phone: 740-587-0157 P.O. Box 381 Fax: 740-587-0163 Granville, Ohio 43023 http://www.jcc.com USA ______________________________________________________________ From ppml at rs.seastrom.com Mon Aug 25 11:46:50 2008 From: ppml at rs.seastrom.com (Robert E. Seastrom) Date: Mon, 25 Aug 2008 11:46:50 -0400 Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation In-Reply-To: <69854b91ed6d31eaa9e64da655ffa9ed48b2c0c7@jcc.com> (Keith W. Hare's message of "Mon, 25 Aug 2008 10:25:11 -0400") References: <69854b91ed6d31eaa9e64da655ffa9ed48b2c0c7@jcc.com> Message-ID: <86abf16qs5.fsf@seastrom.com> "Keith W. Hare" writes: >> If a valid response >>is not received within 14 days, every instance of the unresponsive >>email address will be replaced with "REFUSED RESPONSE" in the whois >>directory. > > Since my background is database design and performance, I cringe at the > idea of overloading the email address field with what should really be a > separate field. > > However, aside from this implementation detail in a policy proposal, I > support the proposal. This will achieve the goal of freezing orphaned > resources while sidesteping the quagmire of (L)RSAs and legacy resource > holders. I don't have a background in database design, but this sounds like a bad idea even to me - what's to stop us from adding a column to the schema with a "last handshake date"? -r From cgrundemann at gmail.com Mon Aug 25 12:12:30 2008 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 25 Aug 2008 10:12:30 -0600 Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation In-Reply-To: <69854b91ed6d31eaa9e64da655ffa9ed48b2c0c7@jcc.com> References: <69854b91ed6d31eaa9e64da655ffa9ed48b2c0c7@jcc.com> Message-ID: <443de7ad0808250912l424dba52u2e9e700a5990c51b@mail.gmail.com> On Mon, Aug 25, 2008 at 8:25 AM, Keith W. Hare wrote: >> If a valid response >>is not received within 14 days, every instance of the unresponsive >>email address will be replaced with "REFUSED RESPONSE" in the whois >>directory. > > Since my background is database design and performance, I cringe at the > idea of overloading the email address field with what should really be a > separate field. Maybe the wording should be changed to something along the lines of: ...is not received within 14 days, every instance of the unresponsive email address will be /marked/ with "REFUSED RESPONSE" in the whois directory. Would that leave it open enough for ARIN staff to implement the policy in a manner that works best for the database? > > However, aside from this implementation detail in a policy proposal, I > support the proposal. This will achieve the goal of freezing orphaned > resources while sidesteping the quagmire of (L)RSAs and legacy resource > holders. > > Keith > > > ______________________________________________________________ > > Keith W. Hare JCC Consulting, Inc. > keith at jcc.com 600 Newark Road > Phone: 740-587-0157 P.O. Box 381 > Fax: 740-587-0163 Granville, Ohio 43023 > http://www.jcc.com USA > ______________________________________________________________ > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- Chris Grundemann www.linkedin.com/in/cgrundemann From mueller at syr.edu Mon Aug 25 12:12:38 2008 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 25 Aug 2008 12:12:38 -0400 Subject: [arin-ppml] Comprehensive Study Shows IPv6 Shift Isn't Happening In-Reply-To: References: <200808241943.m7OJhAHB019085@cjbsys.bdb.com><7E4C49BC-2257-4221-A042-1EBBDC95F758@muada.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0E3B8@SUEXCL-02.ad.syr.edu> Under conditions of limited supply and high demand, the only thing more unpredictable, unstable and more likely to cause hoarding than a market is the absence of a market, (i.e., a decentralized transfer mechanism... But have fun, go ahead and experiment with the idea of using chaos and artificial scarcity to "force" people into IPv6. I suggest we keep careful track of who promotes that idea so that when it fails and causes serious problems we can fully credit them with the results. them back for free, and market economics in a market with limited supply and high demand implies not only high prices but also unpredictability (the last thing that we need) and all kinds of unwanted behavior such as hoarding. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tvest at pch.net Mon Aug 25 12:36:41 2008 From: tvest at pch.net (Tom Vest) Date: Mon, 25 Aug 2008 12:36:41 -0400 Subject: [arin-ppml] Comprehensive Study Shows IPv6 Shift Isn't Happening In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E3B8@SUEXCL-02.ad.syr.edu> References: <200808241943.m7OJhAHB019085@cjbsys.bdb.com><7E4C49BC-2257-4221-A042-1EBBDC95F758@muada.com> <7663C7E01D8E094989CA62F0B0D21CD901E0E3B8@SUEXCL-02.ad.syr.edu> Message-ID: <074C8E9A-FF6F-4D0B-A0E0-6F0EA864596F@pch.net> On Aug 25, 2008, at 12:12 PM, Milton L Mueller wrote: > Under conditions of limited supply and high demand, the only thing > more unpredictable, unstable and more likely to cause hoarding than > a market is the absence of a market, (i.e., a decentralized transfer > mechanism? What's the difference between a "market" and a "decentralized transfer mechanism"? I believe the qualifiers for "market" that you chose to leave unmentioned were "centralized", "stable", "predictable"... Which is certainly understandable, since under conditions of limited means (few compelling carrots, no sticks at all) to produce those qualifiers, there's no practical difference at all. > But have fun, go ahead and experiment with the idea of using chaos > and artificial scarcity to ?force? people into IPv6. I suggest we > keep careful track of who promotes that idea so that when it fails > and causes serious problems we can fully credit them with the results. I have no doubt that all predictions will remembered well by many parties. >> them back for free, and market economics in a market with limited >> supply and high demand implies not only high prices but also >> unpredictability (the last thing that we need) and all kinds of >> unwanted behavior such as hoarding. >> From mueller at syr.edu Mon Aug 25 12:38:55 2008 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 25 Aug 2008 12:38:55 -0400 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: References: <7663C7E01D8E094989CA62F0B0D21CD901E0E386@SUEXCL-02.ad.syr.edu> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0E3BA@SUEXCL-02.ad.syr.edu> > -----Original Message----- > From: John Curran [mailto:jcurran at istaff.org] > It is questionable whether we can > keep the present Internet growing simply using IPv4. Just to be clear, to advocate efficient management of scarcity in the IPv4 space does NOT entail a belief in indefinite extension of IPv4. It is simply asserts that the mechanisms used to manage IPv4 address resources should reflect the actual situation in that resource pool. > an irresponsible act with global economic consequences. Due to > the inherent nature of IPv4/IPv6 interoperability, it's going to > be necessary for many organizations to run both in parallel for > some period of time in order to effect the transition. Precisely, so IPv4 is going to be with us for a long time. Therefore its address space must be managed effectively and efficiently for some time. I have trouble understanding why this point is even controversial. There seems to be an attitude that as soon as the last free IPv4 block is allocated we can stop worrying about IPv4 resource management and (somehow) start pushing everyone into v6. This is a dangerous fantasy. Scarcity doesn't go away because you don't like it and wish it weren't there. Market forces don't disappear because you don't like markets and refuse to organize them properly. Conditions of scarcity in the ipv4 space will affect the conduct and behavior of organizations, ISPs and indirectly, internet users for at least a decade. So if you don't have a strategy for responding to v4 address scarcity you're not being responsible. If you don't like transfers in ipv4 tell me what that strategy is. From dsd at servervault.com Mon Aug 25 12:40:59 2008 From: dsd at servervault.com (Divins, David) Date: Mon, 25 Aug 2008 12:40:59 -0400 Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation References: <48B2A528.9000703@arin.net> Message-ID: <8A3DE12E408BBC499E40C0BE733C8603944471@mail1.dulles.sv.int> I am in support of this proposal. I feel the operational issues are best left to staff but I think the spirit of this is great! -dsd David Divins Principal Engineer ServerVault Corp. (703) 652-5955 -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services Sent: Monday, August 25, 2008 8:27 AM To: arin-ppml at arin.net Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At their following meeting the AC will accept or not accept the proposal. 3. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision via the PPML. If a proposal is not accepted, 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 proposal will be closed. The AC will assign shepherds in the near future. ARIN will provide the names of the shepherds to the community via the PPML. In the meantime, the AC invites everyone to comment on this proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Annual WHOIS POC Validation Author: Chris Grundemann Proposal Version: 1 Submission Date: 21-Aug-2008 Proposal type: new Policy term: permanent Policy statement: ARIN will conduct POC validation annually. This validation will employ an automated system which will send a message to every separate email address in the whois directory. The message sent will request that the receiver verify that they are in fact the POC in question by replying to the email in a manner which will satisfy the automated systems requirements. The email message will also include information and instructions for reporting suspected fraud. If a valid response is not received within 14 days, every instance of the unresponsive email address will be replaced with "REFUSED RESPONSE" in the whois directory. The list of POCs with this marking will be reviewed by ARIN staff and manual contact attempts (telephone, postal mail) can be made at their discretion. After a minimum of three manual contact attempts have been made, with at least one to each physical address and telephone number provided and a minimum of three calendar months have passed from the third qualifying attempt; the POC record should be locked or deleted. The decision of whether to lock or delete the account should be made on a case by case basis. Following this validation each year, a list of address blocks with zero valid POCs should be made easily available to the community. Accurate annual records should be kept with regard to the total number of POCs, the number of POCs marked with "REFUSED RESPONSE," the number of locked POCs and the number of deleted POCs in addition to any other data that ARIN staff believes is appropriate to record with regard to this validation process. These records should be available to the public on request. Rationale: The intention of this proposal is to ensure valid whois POC information with an annual validation process. It further aims to mitigate any risk that it creates in so doing. One of the most important resources when dealing with abuse (including hijacking, spam, ddos, etc) is whois. ARIN's whois data is only useful if it is known to be valid. The current NRPM does not address this in a manner which ensures up to date POC contact information in all cases. The focus is on valid email addresses because this is the contact method of choice for most in the Internet community when dealing with abuse or hijacking issues. POC information that can not be confirmed can be judged as not valid. A netblock with no valid POC presents a target to hijackers. Once POC info is marked or tagged as invalid (like this policy proposes), it becomes possible for potential hijackers to locate such netblocks by searching the whois database. As a defense against such hijacking attempts, this policy proposes that the information be presented in full to the entire community. This should do at least one of two things; bring the netblock to the attention of whomever is responsible for it and/or allow other network operators to understand the potential risk and take appropriate action to mitigate. Timetable for implementation: The first validation should take place within one calendar year of the policy being accepted. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From bmanning at vacation.karoshi.com Mon Aug 25 13:00:38 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 25 Aug 2008 17:00:38 +0000 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E3BA@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD901E0E386@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0E3BA@SUEXCL-02.ad.syr.edu> Message-ID: <20080825170038.GA8825@vacation.karoshi.com.> On Mon, Aug 25, 2008 at 12:38:55PM -0400, Milton L Mueller wrote: > > > -----Original Message----- > > From: John Curran [mailto:jcurran at istaff.org] > > It is questionable whether we can > > keep the present Internet growing simply using IPv4. > > Just to be clear, to advocate efficient management of scarcity in the > IPv4 space does NOT entail a belief in indefinite extension of IPv4. It > is simply asserts that the mechanisms used to manage IPv4 address > resources should reflect the actual situation in that resource pool. > > > an irresponsible act with global economic consequences. Due to > > the inherent nature of IPv4/IPv6 interoperability, it's going to > > be necessary for many organizations to run both in parallel for > > some period of time in order to effect the transition. > > Precisely, so IPv4 is going to be with us for a long time. Therefore its > address space must be managed effectively and efficiently for some time. > I have trouble understanding why this point is even controversial. There > seems to be an attitude that as soon as the last free IPv4 block is > allocated we can stop worrying about IPv4 resource management and > (somehow) start pushing everyone into v6. This is a dangerous fantasy. > Scarcity doesn't go away because you don't like it and wish it weren't > there. Market forces don't disappear because you don't like markets and > refuse to organize them properly. Conditions of scarcity in the ipv4 > space will affect the conduct and behavior of organizations, ISPs and > indirectly, internet users for at least a decade. > > So if you don't have a strategy for responding to v4 address scarcity > you're not being responsible. If you don't like transfers in ipv4 tell > me what that strategy is. > _______________________________________________ (speaking only for myself, donning the robes and polishing the crystal...) ok, so I'm going out on a limb and will posit that properly used in the new period of coexistance, that IPv4 addresses are -NOT- going to be the gating factor - claims of "address scarcity" will be used by those who wish to exploit fear, uncertainty and doubt into monetary gain, either as a direct party or as a broker. when all anyone will ever need is a few addresses to gateway into the increasingly smaller IPv4 world - there will be an abundance of IPv4 space ... (which will still need to be managed/accounted for) part of your premise seems to be that the purpose/use of IPv4 will not change. And if that premise is correct, then your fear-mongering language (dangerouse fantasy, scarcity) is warrented. And we are all in trouble because there are not enough v4 addresses to go around - GIVEN that the use/purpose does not change. But the use/purpose of IPv4 will change and while there may be some uncomfortable points in a transition/coexistance epoch, the end result will be an abudnance of IPv4 ... which no one will find interesting. in a nutshell - a possible strategy is to repurpose IPv4. want another one? --bill From tvest at pch.net Mon Aug 25 13:14:08 2008 From: tvest at pch.net (Tom Vest) Date: Mon, 25 Aug 2008 13:14:08 -0400 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E3BA@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD901E0E386@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0E3BA@SUEXCL-02.ad.syr.edu> Message-ID: <6858DAD5-903C-4B85-B98E-7DDEF11E46BD@pch.net> On Aug 25, 2008, at 12:38 PM, Milton L Mueller wrote: > >> -----Original Message----- >> From: John Curran [mailto:jcurran at istaff.org] >> It is questionable whether we can >> keep the present Internet growing simply using IPv4. > > Just to be clear, to advocate efficient management of scarcity in the > IPv4 space does NOT entail a belief in indefinite extension of IPv4. > It > is simply asserts that the mechanisms used to manage IPv4 address > resources should reflect the actual situation in that resource pool. > >> an irresponsible act with global economic consequences. Due to >> the inherent nature of IPv4/IPv6 interoperability, it's going to >> be necessary for many organizations to run both in parallel for >> some period of time in order to effect the transition. > > Precisely, so IPv4 is going to be with us for a long time. Therefore > its > address space must be managed effectively and efficiently for some > time. > I have trouble understanding why this point is even controversial. > There > seems to be an attitude that as soon as the last free IPv4 block is > allocated we can stop worrying about IPv4 resource management and > (somehow) start pushing everyone into v6. This is a dangerous fantasy. Hi Milton, There's a great, deflationary T-shirt circulating around the ops community with the caption: "IPv6: 96 more bits, no magic" It should probably be updated to the more accurate: "no more magic... but no less." Put another way, a world of uniform, homogenous IPv6 would be "as nice" as a world of uniform, homogenous IPv4, only potentially 2^96 times larger. Granted, we haven't had the former in a long time now, but the latter would assure that that address-related partitioning is largely voluntary -- and I think most people would agree that that would be a dramatic, positive improvement. > Scarcity doesn't go away because you don't like it and wish it weren't > there. Market forces don't disappear because you don't like markets > and > refuse to organize them properly. Conditions of scarcity in the ipv4 > space will affect the conduct and behavior of organizations, ISPs and > indirectly, internet users for at least a decade. If you face a choice between managing extreme scarcity, with ever- diminishing returns, forever, or managing a transition to a state where this particular scarcity is no longer very challenging at all (esp. when there are others to worry about in either case), what makes the former strategy inherently superior? Without a transition strategy, there's no reason to assume the term for such requirements should be measured in years, or even decades. Focusing on scarcity management in any context other than as part of a transition strategy is a self-fulfilling dead end. > So if you don't have a strategy for responding to v4 address scarcity > you're not being responsible. If you don't like transfers in ipv4 tell > me what that strategy is. From dsorenson at csdvrs.com Mon Aug 25 15:44:22 2008 From: dsorenson at csdvrs.com (Dan Sorenson) Date: Mon, 25 Aug 2008 14:44:22 -0500 Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation In-Reply-To: References: Message-ID: <6FF54E348BCC67458FF931A20DE963397FB56A@vrsex1.csdcomm.com> I'm curious as to why 14 days was chosen, and the mechanism used to update the field in the event that the POC did not respond within that time-frame. Thinking out loud, I suspect there are a fair number of entries that point to a single contact e-mail address (as opposed to a group address). With many employers offering up to six weeks of vacation time, where a person might reasonably be expected to remain out of contact, two weeks might prove to generate a fair number of false positives that would have to be later remedied manually. For a process that only runs once a year, surely six or eight weeks would not impose an excessive burden either on ARIN or the POC's. - Dan From kkargel at polartel.com Mon Aug 25 15:59:19 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 25 Aug 2008 14:59:19 -0500 Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation In-Reply-To: <6FF54E348BCC67458FF931A20DE963397FB56A@vrsex1.csdcomm.com> References: <6FF54E348BCC67458FF931A20DE963397FB56A@vrsex1.csdcomm.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10A6E@mail> Even 180 days would not be excessive considering we are dealing with a situation that has existed for decades already. Another six months is not going to tip the canoe. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Dan Sorenson Sent: Monday, August 25, 2008 2:44 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation I'm curious as to why 14 days was chosen, and the mechanism used to update the field in the event that the POC did not respond within that time-frame. Thinking out loud, I suspect there are a fair number of entries that point to a single contact e-mail address (as opposed to a group address). With many employers offering up to six weeks of vacation time, where a person might reasonably be expected to remain out of contact, two weeks might prove to generate a fair number of false positives that would have to be later remedied manually. For a process that only runs once a year, surely six or eight weeks would not impose an excessive burden either on ARIN or the POC's. - Dan _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3107 bytes Desc: not available URL: From tedm at ipinc.net Mon Aug 25 16:04:51 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 25 Aug 2008 13:04:51 -0700 Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10A6E@mail> Message-ID: <6470059FC9A5414E97ABDB2DE4D9D908@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel > Sent: Monday, August 25, 2008 12:59 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation > > > Even 180 days would not be excessive considering we are > dealing with a situation that has existed for decades > already. Another six months is not going to tip the canoe. > The whole point of having an e-mail address on the POC is in case there is a problem with the addressing, it allows other admins on the Internet who are suffering the ill effects of the troublesome IP range to e-mail the holder of the range and get them to fix the problem. 180 days turnaround time for me e-mailing an address holder because he has an attacker who has hijacked those ranges and is DDoSing me to death, it totally unacceptable and is making a mockery of the requirement for address holders to have current contact info. Ted From cgrundemann at gmail.com Mon Aug 25 16:05:02 2008 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 25 Aug 2008 14:05:02 -0600 Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10A6E@mail> References: <6FF54E348BCC67458FF931A20DE963397FB56A@vrsex1.csdcomm.com> <70DE64CEFD6E9A4EB7FAF3A063141066A10A6E@mail> Message-ID: <443de7ad0808251305m2fd0caffuac8cc4a524f72bd6@mail.gmail.com> On Mon, Aug 25, 2008 at 1:59 PM, Kevin Kargel wrote: > Even 180 days would not be excessive considering we are dealing with a > situation that has existed for decades already. Another six months is not > going to tip the canoe. I thought about this in two ways. First, I considered vacation or other time off. Then I shortened the time when I asked myself the question; what if I needed to contact this POC for a real issue? Would waiting 6 to 8 weeks be reasonable? I am not opposed to lengthening the response time at all, as long as both aspects are considered. I would like to do more than to just get whois better than it is now, although I agree that initially that is probably all that is needed. I did not want to get to complicated but maybe abuse contacts should have one response time set and others a longer allowance (I don't really like that idea though). Or perhaps the time should only be specified as being /equal for all/ and then let ARIN staff adjust it year to year, based on the number of false positives from the years before. ~Chris > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Dan Sorenson > Sent: Monday, August 25, 2008 2:44 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation > > I'm curious as to why 14 days was chosen, and the mechanism used to update > the field in the event that the POC did not respond within that time-frame. > > Thinking out loud, I suspect there are a fair number of entries that point > to a single contact e-mail address (as opposed to a group address). > With many employers offering up to six weeks of vacation time, where a > person might reasonably be expected to remain out of contact, two weeks > might prove to generate a fair number of false positives that would have to > be later remedied manually. > > For a process that only runs once a year, surely six or eight weeks would > not impose an excessive burden either on ARIN or the POC's. > > - Dan -- Chris Grundemann www.linkedin.com/in/cgrundemann From arin-ppml at westbrook.com Mon Aug 25 16:07:10 2008 From: arin-ppml at westbrook.com (Eric Westbrook) Date: Mon, 25 Aug 2008 14:07:10 -0600 Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10A6E@mail> References: <6FF54E348BCC67458FF931A20DE963397FB56A@vrsex1.csdcomm.com> <70DE64CEFD6E9A4EB7FAF3A063141066A10A6E@mail> Message-ID: <6905ba860808251307p654f9815k92ed0859c9b640b9@mail.gmail.com> 1. I suggest that the phrase "NO RESPONSE" should be used globally instead of "REFUSED RESPONSE" in this proposal, since a lack of response, which is not necessarily a refusal, is what triggers it. It probably warrants the same handling, but I think it's an important semantic distinction. 2. I agree with the contention that this marker shouldn't really "overwrite" the email address. The email addresses, even if they fail to respond, should not be discarded or lost. Also, in this rationale section: A netblock with no valid POC presents a target to hijackers. Once POC > info is marked or tagged as invalid (like this policy proposes), it > becomes possible for potential hijackers to locate such netblocks by > searching the whois database. As a defense against such hijacking > attempts, this policy proposes that the information be presented in > full to the entire community. This should do at least one of two > things; bring the netblock to the attention of whomever is responsible > for it and/or allow other network operators to understand the > potential risk and take appropriate action to mitigate. > I'm not fully convinced that the benefit of increased visibility to operators and white hats would universally trump the danger of increased visibility to black hats. But I suppose it could help mitigate it in some (and perhaps many) cases. Regardless, I do think the overall benefit gained by periodic verification (with perhaps a few adjustments as others are suggesting) probably outweighs that concern and any others of which I can currently think. $0.02, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From cliffb at cjbsys.bdb.com Mon Aug 25 16:18:07 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Mon, 25 Aug 2008 16:18:07 -0400 (EDT) Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation Message-ID: <200808252018.m7PKI7KL002202@cjbsys.bdb.com> I think the fundamentals of the proposal are fine but as someone else pointed out, 14 days can be a really short time when you come back from vacation and the SPAM filters let enough stuff through that you delete the message from ARIN by mistake thinking it was an offer for some ED drug. I think you should probably send a 2nd message 6 weeks later if you get no answer from the first one. Maybe the the details should be left to ARIN staff and just say that after no contact the first year by all reasonable methods, the record will be marked as unresponsive, locked and after three years, ARIN may reclaim the address space. Cliff -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From mueller at syr.edu Mon Aug 25 16:13:58 2008 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 25 Aug 2008 16:13:58 -0400 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: <6858DAD5-903C-4B85-B98E-7DDEF11E46BD@pch.net> References: <7663C7E01D8E094989CA62F0B0D21CD901E0E386@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0E3BA@SUEXCL-02.ad.syr.edu> <6858DAD5-903C-4B85-B98E-7DDEF11E46BD@pch.net> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9011DCA71@SUEXCL-02.ad.syr.edu> > If you face a choice between managing extreme scarcity, with ever- > diminishing returns, forever, or managing a transition to a state > where this particular scarcity is no longer very challenging at all > (esp. when there are others to worry about in either case), > what makes the former strategy inherently superior? > > Without a transition strategy, there's no reason to assume the term > for such requirements should be measured in years, or even decades. > Tom: As I understand it, and correct me if I'm wrong, the entities who manage the "transition" from IPv4 to IPv6 are network operators, not the RIRs. We are not debating _whether_ there should be a transition strategy, we are debating where it should be located. If RIRs handle the address resources they have according to the appropriate policies, operators can better decide for themselves when, where and how they "transition to a state where [IPv4] scarcity is no longer very challenging." Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org From mueller at syr.edu Mon Aug 25 16:25:36 2008 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 25 Aug 2008 16:25:36 -0400 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: <20080825170038.GA8825@vacation.karoshi.com.> References: <7663C7E01D8E094989CA62F0B0D21CD901E0E386@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0E3BA@SUEXCL-02.ad.syr.edu> <20080825170038.GA8825@vacation.karoshi.com.> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9011DCA72@SUEXCL-02.ad.syr.edu> > -----Original Message----- > From: bmanning at vacation.karoshi.com > > ok, so I'm going out on a limb and will posit that properly used > in the new period of coexistance, that IPv4 addresses are -NOT- > going to be the gating factor - claims of "address scarcity" will > be used by those who wish to exploit fear, uncertainty and doubt > into monetary gain, either as a direct party or as a broker. > > when all anyone will ever need is a few addresses to > gateway into the increasingly smaller IPv4 world - > there will be an abundance of IPv4 space ... >(which will still need to be managed/accounted for) This is one scenario, it may turn out to be true. Indeed, a transfer market could hasten that result by encouraging the reallocation of address space to such "gateway" situations. > part of your premise seems to be that the purpose/use of IPv4 > will not change. Untrue. I am sure that once IPv4 blocks command a price that accurately reflects their value, and once they can be shifted more easily from lower valued to higher valued uses, their use will change dramatically. That is one reason why I favor a more flexible transfers policy. If you want to understand what I am trying to tell you, stop thinking like a techie and start thinking like a policy person. I don't need or want to predict the precise uses and adaptations that operators will take. I do want to make sure that those decisions are based on an accurate assessment of the relative cost of the alternatives. > But the use/purpose of IPv4 will change and while there > may be some uncomfortable points in a transition/coexistance epoch, > the end result will be an abudnance of IPv4 ... which no one will find > interesting. > in a nutshell - a possible strategy is to repurpose IPv4. As a prognostication I find that plausible. But who makes the decision to repurpose? Operators or RIRs? Referring to my just-sent reply to Tom Vest, the issue is not whether a transition is needed, but where that decision is located and what role the RIRs play in facilitating it. I'm simply suggesting that given a scarce, legacy resource that everyone now needs, and an abundant, next-gen resource the utility of which depends on a massive migration across two incompatible standards, RIRs need to adopt policies that provide accurate price signals and which facilitate shifting the remaining ipv4 resources to their highest and best uses. I'm also suggesting that they refrain from exploiting their leverage over both resource pools to impose a top-down transition plan on operators. From celestea at usc.edu Mon Aug 25 16:30:00 2008 From: celestea at usc.edu (Celeste Anderson) Date: Mon, 25 Aug 2008 13:30:00 -0700 Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation References: <6FF54E348BCC67458FF931A20DE963397FB56A@vrsex1.csdcomm.com> <70DE64CEFD6E9A4EB7FAF3A063141066A10A6E@mail> <6905ba860808251307p654f9815k92ed0859c9b640b9@mail.gmail.com> Message-ID: <836B9591EC584EE583736C9217E3D2C5@yacht> I agree with Eric that the words "NO RESPONSE" should be used in place of "REFUSED RESPONSE". Celeste. ----- Original Message ----- From: Eric Westbrook To: arin-ppml at arin.net Sent: Monday, August 25, 2008 1:07 PM Subject: Re: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation 1. I suggest that the phrase "NO RESPONSE" should be used globally instead of "REFUSED RESPONSE" in this proposal, since a lack of response, which is not necessarily a refusal, is what triggers it. It probably warrants the same handling, but I think it's an important semantic distinction. 2. I agree with the contention that this marker shouldn't really "overwrite" the email address. The email addresses, even if they fail to respond, should not be discarded or lost. Also, in this rationale section: A netblock with no valid POC presents a target to hijackers. Once POC info is marked or tagged as invalid (like this policy proposes), it becomes possible for potential hijackers to locate such netblocks by searching the whois database. As a defense against such hijacking attempts, this policy proposes that the information be presented in full to the entire community. This should do at least one of two things; bring the netblock to the attention of whomever is responsible for it and/or allow other network operators to understand the potential risk and take appropriate action to mitigate. I'm not fully convinced that the benefit of increased visibility to operators and white hats would universally trump the danger of increased visibility to black hats. But I suppose it could help mitigate it in some (and perhaps many) cases. Regardless, I do think the overall benefit gained by periodic verification (with perhaps a few adjustments as others are suggesting) probably outweighs that concern and any others of which I can currently think. $0.02, Eric ------------------------------------------------------------------------------ _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tvest at pch.net Mon Aug 25 17:06:31 2008 From: tvest at pch.net (Tom Vest) Date: Mon, 25 Aug 2008 17:06:31 -0400 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9011DCA72@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD901E0E386@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0E3BA@SUEXCL-02.ad.syr.edu> <20080825170038.GA8825@vacation.karoshi.com.> <7663C7E01D8E094989CA62F0B0D21CD9011DCA72@SUEXCL-02.ad.syr.edu> Message-ID: <0FCC6A57-FC46-46B0-AF4E-B99A44ACFE02@pch.net> On Aug 25, 2008, at 4:25 PM, Milton L Mueller wrote: > >> -----Original Message----- >> From: bmanning at vacation.karoshi.com >> >> ok, so I'm going out on a limb and will posit that properly used >> in the new period of coexistance, that IPv4 addresses are -NOT- >> going to be the gating factor - claims of "address scarcity" > will >> be used by those who wish to exploit fear, uncertainty and doubt >> into monetary gain, either as a direct party or as a broker. >> >> when all anyone will ever need is a few addresses to >> gateway into the increasingly smaller IPv4 world - >> there will be an abundance of IPv4 space ... >> (which will still need to be managed/accounted for) > > This is one scenario, it may turn out to be true. Indeed, a transfer > market could hasten that result by encouraging the reallocation of > address space to such "gateway" situations. > >> part of your premise seems to be that the purpose/use of IPv4 >> will not change. > > Untrue. I am sure that once IPv4 blocks command a price that > accurately > reflects their value, and once they can be shifted more easily from > lower valued to higher valued uses, their use will change > dramatically. > That is one reason why I favor a more flexible transfers policy. > > If you want to understand what I am trying to tell you, stop thinking > like a techie and start thinking like a policy person. I don't need or > want to predict the precise uses and adaptations that operators will > take. I do want to make sure that those decisions are based on an > accurate assessment of the relative cost of the alternatives. > >> But the use/purpose of IPv4 will change and while there >> may be some uncomfortable points in a transition/coexistance epoch, >> the end result will be an abudnance of IPv4 ... which no one will >> find > >> interesting. >> in a nutshell - a possible strategy is to repurpose IPv4. > > As a prognostication I find that plausible. > > But who makes the decision to repurpose? Operators or RIRs? > Referring to > my just-sent reply to Tom Vest, the issue is not whether a > transition is > needed, but where that decision is located and what role the RIRs play > in facilitating it. I'm simply suggesting that given a scarce, legacy > resource that everyone now needs, and an abundant, next-gen resource > the > utility of which depends on a massive migration across two > incompatible > standards, RIRs need to adopt policies that provide accurate price > signals and which facilitate shifting the remaining ipv4 resources to > their highest and best uses. I'm also suggesting that they refrain > from > exploiting their leverage over both resource pools to impose a top- > down > transition plan on operators. Hi Milton, When I write something to the ppml list, or any other policy list, I am basically addressing the RIR stakeholder community -- which, now that you've chosen to jump in, includes you. When I lazily write that an RIR "should" or "must" do something, I am just using that phrasing as shorthand to refer to the members of that community, who call all of the shots. In that sense there is no external "RIRs" to impose anything -- there's just stakeholders who propose, consider, reject. modify, and occasionally achieve consensus and adopt policies. I am making an argument that other members of that community should consider some things favorably, and other proposals less favorably -- as presumably are you. But that basic fact of self-governance means that all of the policies in place now must also be "top-down" impositions, and the resource transfer proposal itself will necessarily be a "top-down" imposition, unless by some miracle one of more of the policies was approved by unanimous consent. A market transfer proposal won't just affect buyer and sellers; it'll affect all IP resources users, probably now and in the future indefinitely. So the immediate choice confronting community members is not between some ideal freedom and an imposed top-down solution, but rather between the accumulated policies accepted by consensus to date (i.e., the status quo), and one or more new consensus policies, e.g., for resource transfers, for a reservation for IPv6 transition, or others yet to be proposed... I'll try to be more precise in future messages, so as to avoid any misunderstandings along these lines. TV From tedm at ipinc.net Mon Aug 25 17:37:41 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 25 Aug 2008 14:37:41 -0700 Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation In-Reply-To: <69854b91ed6d31eaa9e64da655ffa9ed48b2c0c7@jcc.com> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Keith W. Hare > Sent: Monday, August 25, 2008 7:25 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation > > > > If a valid response > >is not received within 14 days, every instance of the unresponsive > >email address will be replaced with "REFUSED RESPONSE" in the whois > >directory. > > Since my background is database design and performance, I > cringe at the idea of overloading the email address field > with what should really be a separate field. > Keith, Adding a field could possibly break web-whois-lookup forms that are out there who don't have good parsers. Technically, there is no standard for an e-mail address. There's a standard for a DOMAIN-style e-mail address, but if your database parser that parses the e-mail address field of ARIN whois is dependent on seeing an '@' then you already are doing it wrong. Because the string "REFUSED RESPONSE" doesen't follow the standards for domain-style addressing, it isn't going to appear in a legitimate POC e-mail address. Because there's a space it isn't a legitimate UUCP address or BITNET address either. It is pretty simple for any COMPETENT programmer writing automated query tools to code for this. And we want to discourage people from bulk-queries of the whois database anyway - if you don't know how to code for this, we really don't want you harvesting e-mail addresses out of whois since your likely a spammer. If we simply remove the POC e-mail address then people don't know if it was removed because it's bogus or because someone made a mistake with a SWIP record. This is why I did not set it to "unavailable at example.com" or some such in my proposal from which this proposal is derived. There is no point in overloading someone's mailserver somewhere by some spammer trying to send 20,000 mails to a data item that looks like an e-mail address but isn't. Ted > However, aside from this implementation detail in a policy > proposal, I support the proposal. This will achieve the goal > of freezing orphaned resources while sidesteping the quagmire > of (L)RSAs and legacy resource holders. > > Keith > > > ______________________________________________________________ > > Keith W. Hare JCC Consulting, Inc. > keith at jcc.com 600 Newark Road > Phone: 740-587-0157 P.O. Box 381 > Fax: 740-587-0163 Granville, Ohio 43023 > http://www.jcc.com USA > ______________________________________________________________ > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From bill at herrin.us Mon Aug 25 18:27:18 2008 From: bill at herrin.us (William Herrin) Date: Mon, 25 Aug 2008 18:27:18 -0400 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40B0CC5F3@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB40B0CC5F3@CL-S-EX-1.stanleyassociates.com> Message-ID: <3c3e3fca0808251527u7204fb57t81061dba0df9a55b@mail.gmail.com> On Sat, Aug 23, 2008 at 1:29 PM, Howard, W. Lee wrote: > What can we do to ease the transition to IPv6? Lee, Not much. There are three key obstacles to IPv6 deployment: 1. In a down economy, deploying and maintaining both IPv6 and IPv4 costs noticeably more money than just IPv4 and it is not practical (at an individual or org-by-org level) to discontinue the IPv4 costs after deploying IPv6. Worse, it has the costliest of costs: manpower from your top technical people diverted from other tasks. Hence any organization which deploys IPv6 is economically disadvantaged versus those competitors who don't. 2. Some damn fools at the IETF recommended that applications which support IPv6 should use it in preference to IPv4 when available. Nearly all of the application developers have followed that bone-headed recommendation. So as soon as you turn IPv6 on in your network, -everything- in your network tries to use it first and only falls back to IPv4 if IPv6 doesn't work. Since that detection and fallback process is considerably less than perfect, the net result is an instant drop in overall system reliability when you deploy IPv6 (since the v6 parts of both your software and the network overall are less well tested), making IPv6 deployment undesirable. 3. Based in part on the recommendations from the same knuckleheads in #2, the registries (including ARIN) determined that a mid-90's style Internet land rush would undesirably generate the same legacy-registrant problems in IPv6 that they have with IPv4. So, policy was set such that we would not have a land rush. Hence no rush to deploy IPv6. Of these, only #3 is addressable within ARIN's bailiwick. Since last year, ARIN has at least removed the incentives for folks to work against IPv6 deployment (ALL present registrants now qualify for a direct IPv6 assignment or allocation). However, without a land rush folks will tend to deploy needs-justified resources only as they need them. For better or for worse, nobody needs IPv6; they need more IPv4. IPv6 functions as a substitute about as effectively as tap water at a bar. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Matthew.Wilder at telus.com Mon Aug 25 18:31:18 2008 From: Matthew.Wilder at telus.com (Matthew Wilder) Date: Mon, 25 Aug 2008 15:31:18 -0700 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9011DCA72@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD901E0E386@SUEXCL-02.ad.syr.edu><7663C7E01D8E094989CA62F0B0D21CD901E0E3BA@SUEXCL-02.ad.syr.edu><20080825170038.GA8825@vacation.karoshi.com.> <7663C7E01D8E094989CA62F0B0D21CD9011DCA72@SUEXCL-02.ad.syr.edu> Message-ID: <4C80F17364FE2E4C93053BE9D01DB479095205AC@BCMSG111.corp.ads> On Sat, Aug 25, 2008 at 1:29 PM, Milton Mueller wrote: > I'm simply suggesting that given a scarce, legacy resource that > everyone now needs, and an abundant, next-gen resource the utility > of which depends on a massive migration across two incompatible > standards, RIRs need to adopt policies that provide accurate price > signals and which facilitate shifting the remaining ipv4 resources > to their highest and best uses. And I suppose in the spirit of fairness that all proceeds will go to cancer research? MW From tvest at pch.net Mon Aug 25 20:14:03 2008 From: tvest at pch.net (Tom Vest) Date: Mon, 25 Aug 2008 20:14:03 -0400 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: <3c3e3fca0808251527u7204fb57t81061dba0df9a55b@mail.gmail.com> References: <369EB04A0951824ABE7D8BAC67AF9BB40B0CC5F3@CL-S-EX-1.stanleyassociates.com> <3c3e3fca0808251527u7204fb57t81061dba0df9a55b@mail.gmail.com> Message-ID: On Aug 25, 2008, at 6:27 PM, William Herrin wrote: > On Sat, Aug 23, 2008 at 1:29 PM, Howard, W. Lee > wrote: >> What can we do to ease the transition to IPv6? > > Lee, > > Not much. There are three key obstacles to IPv6 deployment: > > 1. In a down economy, deploying and maintaining both IPv6 and IPv4 > costs noticeably more money than just IPv4 and it is not practical (at > an individual or org-by-org level) to discontinue the IPv4 costs after > deploying IPv6. Worse, it has the costliest of costs: manpower from > your top technical people diverted from other tasks. Hence any > organization which deploys IPv6 is economically disadvantaged versus > those competitors who don't. Hi Bill, Wouldn't competitive pressures be just as relentless and unforgiving in an up economy? I'm trying to think back to what ambitious undertakings were achieved back in the go-go days (c. 1998-2000), but I can't remember any. If I'm not too off-base here, it's not an indictment of operators, or competition, or capitalism, or anything -- just an observation that some kinds of problems cannot be solved through purely uncoordinated/ competitive action alone. If deploying IPv6 is one of those problems, then it seems to me that we'll probably be facing this or an equivalent problem sooner or later -- at which point if we've lost the coordination mechanisms that we have today, they'll just have to be reinvented. > 2. Some damn fools at the IETF recommended that applications which > support IPv6 should use it in preference to IPv4 when available. > Nearly all of the application developers have followed that > bone-headed recommendation. So as soon as you turn IPv6 on in your > network, -everything- in your network tries to use it first and only > falls back to IPv4 if IPv6 doesn't work. Since that detection and > fallback process is considerably less than perfect, the net result is > an instant drop in overall system reliability when you deploy IPv6 > (since the v6 parts of both your software and the network overall are > less well tested), making IPv6 deployment undesirable. > > 3. Based in part on the recommendations from the same knuckleheads in > #2, the registries (including ARIN) determined that a mid-90's style > Internet land rush would undesirably generate the same > legacy-registrant problems in IPv6 that they have with IPv4. So, > policy was set such that we would not have a land rush. Hence no rush > to deploy IPv6. > > > Of these, only #3 is addressable within ARIN's bailiwick. Since last > year, ARIN has at least removed the incentives for folks to work > against IPv6 deployment (ALL present registrants now qualify for a > direct IPv6 assignment or allocation). However, without a land rush > folks will tend to deploy needs-justified resources only as they need > them. For better or for worse, nobody needs IPv6; they need more IPv4. > IPv6 functions as a substitute about as effectively as tap water at a > bar. Well, in that case everybody had better get ready for last call, if not next year then soon enough. We don't have to go home, but we can't stay here ;-) With promises of fewer postings tomorrow, TV From JOHN at egh.com Mon Aug 25 20:58:13 2008 From: JOHN at egh.com (John Santos) Date: Mon, 25 Aug 2008 20:58:13 -0400 Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation In-Reply-To: Message-ID: <1080825194128.2637D-100000@Ives.egh.com> On Mon, 25 Aug 2008, Ted Mittelstaedt wrote: > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Keith W. Hare > > Sent: Monday, August 25, 2008 7:25 AM > > To: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation > > > > > > > If a valid response > > >is not received within 14 days, every instance of the unresponsive > > >email address will be replaced with "REFUSED RESPONSE" in the whois > > >directory. > > > > Since my background is database design and performance, I > > cringe at the idea of overloading the email address field > > with what should really be a separate field. > > > > Keith, > > Adding a field could possibly break web-whois-lookup forms > that are out there who don't have good parsers. > > Technically, there is no standard for an e-mail address. There's a > standard for a DOMAIN-style e-mail address, but if your database parser > that parses the e-mail address field of ARIN whois is dependent on > seeing an '@' then you already are doing it wrong. > > Because the string "REFUSED RESPONSE" doesen't follow the > standards for domain-style addressing, it isn't going to appear > in a legitimate POC e-mail address. Because there's a space > it isn't a legitimate UUCP address or BITNET address either. It > is pretty simple for any COMPETENT programmer writing automated > query tools to code for this. And we want to discourage people > from bulk-queries of the whois database anyway - if you don't > know how to code for this, we really don't want you harvesting > e-mail addresses out of whois since your likely a spammer. > > If we simply remove the POC e-mail address then people don't > know if it was removed because it's bogus or because someone made > a mistake with a SWIP record. > > This is why I did not set it to "unavailable at example.com" or some > such in my proposal from which this proposal is derived. There is no > point in overloading someone's mailserver > somewhere by some spammer trying to send 20,000 mails to a data item that > looks like an e-mail address but isn't. How about: No response (was: ) This way no information is lost and it has a space in it so the resulting e-mail address is still invalid, and it makes no presumptions about the type of e-mail address was originally there. Also, it would be easy to restore the address if it turns out that it is valid but the mail was getting spam-trapped or the recipient was on vacation or otherwise didn't see it promptly. BTW, any kind of automatic second attempt at contacting the POC should use significantly different wording in case the original had fallen afoul of a Bayesian SPAM filter. I think the details should be left to the ARIN staff, though. Suggestions about specifics probably shouldn't be in the policy itself, but just in the rationale and the discussion. > > Ted > > > However, aside from this implementation detail in a policy > > proposal, I support the proposal. This will achieve the goal > > of freezing orphaned resources while sidesteping the quagmire > > of (L)RSAs and legacy resource holders. > > > > Keith > > > > > > ______________________________________________________________ > > > > Keith W. Hare JCC Consulting, Inc. > > keith at jcc.com 600 Newark Road > > Phone: 740-587-0157 P.O. Box 381 > > Fax: 740-587-0163 Granville, Ohio 43023 > > http://www.jcc.com USA > > ______________________________________________________________ > > > > > > > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From michael.dillon at bt.com Tue Aug 26 06:10:24 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 26 Aug 2008 11:10:24 +0100 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: <48AF5D79.3010207@psg.com> Message-ID: > kiddies, get a clue. many folk with legacy space were > building the internet while you were still in nappies. we > think it is you who are pissing on the commons. You are claiming special rights because you got here first, but at the same time referring to "the commons". I hate to burst your bubble, but it is either one or the other. If it really is "the commons", then the first people here don't have any special rights over the last people here. --Michael Dillon From michael.dillon at bt.com Tue Aug 26 07:03:00 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 26 Aug 2008 12:03:00 +0100 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: Message-ID: > The question remains whether ARIN should take more aggressive > measures to educate and inform user of IP numbering resources > of this upcoming change, and/or whether ARIN should actively > actively encourage migration to IPv6 via policy mechanisms... I'm not so sure about policy mechanisms, but I can see one possible action that ARIN could take which will seriously raise awareness of the IPv6 transition issues and timeline. Require all Address Block holders to file a monthly report of their address usage INCLUDING PROJECTED RUNOUT DATE. This would be very high level giving the begin and end address, current percentage used, and projected runout date. ARIN could have a simple website where people could upload CSV files, and the info would be confidential but would be used for statistical reporting purposes. Don't accept new applications unless the applicant is totally new, or has filed at least one of these reports. FYI, I borrowed this idea from NANPA, the North American Numbering Plan people who look after telephone numbers. They require all holders of 10,000 number blocks to report status and runout dates, although they want not only usage, but also how many numbers are in limbo between subscribers. My hope is that this would provide enough data so that we could provide some better projections of when ARIN's runout date would occur. --Michael Dillon From jcurran at istaff.org Tue Aug 26 07:25:06 2008 From: jcurran at istaff.org (John Curran) Date: Tue, 26 Aug 2008 07:25:06 -0400 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: References: Message-ID: On Aug 26, 2008, at 6:10 AM, wrote: >> (randy) >> kiddies, get a clue. many folk with legacy space were >> building the internet while you were still in nappies. we >> think it is you who are pissing on the commons. > > You are claiming special rights because you got here first, > but at the same time referring to "the commons". I hate to > burst your bubble, but it is either one or the other. If it > really is "the commons", then the first people here don't have > any special rights over the last people here. And if it's not "the commons", but instead some special right due to "Early Internet Protocol or Internet Services Pioneer" status, then one would expect the rights to be based on the circumstances under which such allocations were made (to facilitate development of the Internet) rather than rewriting the aberrations of our initial addressing model with fixed network/address boundaries into some form of twisted pioneer's reward... /John (solely my personal thoughts on the topic) From Lee at Dilkie.com Tue Aug 26 07:53:50 2008 From: Lee at Dilkie.com (Lee Dilkie) Date: Tue, 26 Aug 2008 07:53:50 -0400 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: References: Message-ID: <48B3EECE.6090405@Dilkie.com> John Curran wrote: > On Aug 26, 2008, at 6:10 AM, wrote: > >>> (randy) >>> kiddies, get a clue. many folk with legacy space were >>> building the internet while you were still in nappies. we >>> think it is you who are pissing on the commons. >>> >> You are claiming special rights because you got here first, >> ... >> any special rights over the last people here. >> > > And if it's not "the commons", but instead some special right due to > "Early Internet Protocol or Internet Services Pioneer" status, then > ... > /John > > I think he's asking for *respect* not *special status* or rights. Having read this list for over a year now, I can point to many postings that definitely have a lack of respect for those Legacy holders that pioneered the network you are using. And folks, we are in need of IPv6 pioneers, I cannot get native IPv6 from an ISP here in Canada's capital city. Relying on the "followers" isn't working out, we need pioneers. -lee From info at arin.net Tue Aug 26 08:50:04 2008 From: info at arin.net (Member Services) Date: Tue, 26 Aug 2008 08:50:04 -0400 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency Transfer Policy for IPv4 Addresses Message-ID: <48B3FBFC.7070307@arin.net> On 21 August 2008, the ARIN Advisory Council (AC) concluded its review of "Emergency Transfer Policy for IPv4 Addresses" and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2008-6: Emergency Transfer Policy for IPv4 Addresses. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2008_6.html All persons in the community are encouraged to discuss Policy Proposal 2008-6 prior to it being presented at the ARIN XXII Public Policy Meeting. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. AC shepherds for this proposal are Owen DeLong and Stacy Hughes. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2008-6 Emergency Transfer Policy for IPv4 Addresses Author: Bill Darte Proposal Version: 1.0 Submission Date: August 15, 2008 Proposal type: New Policy term: Temporary Policy statement: 8.2.1 Emergency Transfer Policy for IPv4 Addresses For a period of 3 years from policy implementation, transfer of ARIN IPv4 addresses between two entities in the ARIN region, without the active involvement of ARIN as an intermediary, will be considered legitimate and will be documented accordingly under the following conditions: 1. Transfer takes place from a holder of IPv4 addresses recognized by ARIN as the legitimate and exclusive holder of those resources. 2. Transfer takes place to a recipient that has documented operational need in accordance with current ARIN policy and that signs an RSA with ARIN covering those resources in advance of transfer. 3. Transfer of addresses takes place in such a way that the original contiguous block(s) are not disaggregated into more than 4 resultant network blocks each being greater than or equal to the current minimum sizes specified in applicable ARIN policy. 4. Transfer is complete and unrestricted and is supported by documentation that ARIN deems satisfactory. Rationale: In order for ARIN to fulfill its mission and to facilitate a continuing supply of IPv4 address resources to its service community when ARIN resources are no longer adequate, and to preserve the integrity of documentation and ARIN services for those resources, this policy may be implemented. Its intent is to preserve the current tradition of need-based allocation/assignments for those still needing IPv4 resources during a transition period as the industry adopts IPv6. This policy is not intended to create a 'market' for such transfers and does not introduce or condone the monetization of address resources or a view of addresses as property. It does recognize that organizations making available unused or no longer needed address resources may incur certain costs that might be compensated by those acquiring the resources. This policy is intended to be transient and light-weight and does not encourage a sustained or continuing role for IPv4, but rather helps to mitigate a transitional crisis that may emerge while the industry adopts IPv6 in accordance with the recommendation of ARIN's Board of Trustees. Timetable for implementation: This policy, once ratified by the ARIN Board of Trustees, would be implemented when either the free-pool of IANA addresses is exhausted or IPv4 address resources in the ARIN Region reaches a threshold of scarcity recognized by the ARIN Board of Trustees as requiring this policy implementation. From info at arin.net Tue Aug 26 08:52:32 2008 From: info at arin.net (Member Services) Date: Tue, 26 Aug 2008 08:52:32 -0400 Subject: [arin-ppml] Policy Proposal 2008-7: Whois Integrity Policy Proposal Message-ID: <48B3FC90.4010600@arin.net> On 21 August 2008, the ARIN Advisory Council (AC) concluded its review of "Whois Integrity Policy Proposal" and accepted it as a formal policy proposal for discussion by the community. The proposal is designated Policy Proposal 2008-7: Whois Integrity Policy Proposal. The proposal text is below and can be found at: http://www.arin.net/policy/proposals/2008_7.html All persons in the community are encouraged to discuss Policy Proposal 2008-7 prior to it being presented at the ARIN XXII Public Policy Meeting. Both the discussion on the Public Policy Mailing List and at the Public Policy Meeting will be used to determine the community consensus regarding this policy proposal. AC shepherds for this proposal are Paul Andersen and Bill Darte. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html ARIN's Policy Proposal Archive can be found at: http://www.arin.net/policy/proposals/proposal_archive.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2008-7: Whois Integrity Policy Proposal Author: Heather Schiller Proposal Version: 1 Submission Date: August 15, 2008 Policy statement: To ensure the integrity of information in the ARIN WHOIS Database a resource must be under an RSA (either legacy or traditional) in order to update the WHOIS record. ARIN will not update historical information in the ARIN Whois Database until the resource holder can prove the organization's right to the resource. Rationale: ARIN currently maintains WHOIS and in-addr.arpa delegation records in a best-effort fashion. In many cases ARIN does not have a formal agreement with the legacy resource holders. Legacy records are frequently out of date and have become an increasingly popular target for hijackers. Having up to date contact information and a formal relationship with legacy record holders would assist ARIN and ISP's in ensuring these records are maintained accurately. A similar policy was successfully adopted in the APNIC region. (http://www.apnic.net/policy/proposals/prop-018-v001.html) Timetable for implementation: Within sixty (60) days of approval - with notification to current POC email addresses listed on historical assignments, or as soon as reasonable for ARIN staff. From info at arin.net Tue Aug 26 08:54:29 2008 From: info at arin.net (Member Services) Date: Tue, 26 Aug 2008 08:54:29 -0400 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives Message-ID: <48B3FD05.2000009@arin.net> On 21 August 2008, the ARIN Advisory Council (AC) postponed making a decision regarding this proposal until their next meeting, "because the proposal will not make it into the process for the ARIN meeting in October as it came in after the deadline." Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At their following meeting the AC will accept or not accept the proposal. 3. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision via the PPML. If a proposal is not accepted, 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 proposal will be closed. The AC will assign shepherds in the near future. ARIN will provide the names of the shepherds to the community via the PPML. In the meantime, the AC invites everyone to comment on this proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Whois Authentication Alternatives Author: Michael Sinatra Proposal Version: 1 Submission Date: August 19, 2008 Proposal type: new Policy term: permanent Policy statement: In addition to current processes ARIN has to authenticate holders of historical resources, ARIN will also allow holders of resources to authenticate themselves for the purposes of updating WHOIS information for a given resource according to the following mechanism: A holder of resources not governed by any type of RSA (i.e. legacy or regular) may work with ARIN staff to establish an inventory of those resources legitimately maintained by the holder. ARIN staff will work to authenticate each resource claimed by the holder. Upon successful completion of the authentication process, the holder will be entitled to make updates to whois information for those resources for a period of one year, with an option for renewal. For ARIN non-members, ARIN will charge a maintenance fee to recover costs associated with the authentication process and whois maintenance. For ARIN members, the fee will be waived or discounted at ARIN's discretion. Renewal is automatic pending the payment of maintenance or membership fees. Failure to pay fees will result in the whois information being "locked," and updates to the information will not be possible. Successful authentication and the payment of membership and/or maintenance fees does not confer any rights upon the holder such as those that would be granted by an RSA (legacy or regular). Rationale: ARIN needs to protect whois data from hijacking, but the current mechanisms for authenticating holders (especially legacy holders) are limited. The current method, signing a Legacy RSA, may not be a viable option in the near term for such legacy holders for a variety of legal reasons. In the interest of: (a) protecting whois data; (b) keeping whois up-to-date for the Internet community; and (c) recovering costs associated with WHOIS and in-addr.arpa delegation, an alternative authentication mechanism needs to be established for holders of historical resources. This proposal does not intend to discount either type of RSA, and it attempts to specifically stay out of the way of the RSAs. NOTE: This proposal assumes the existence of some form of policy such as that proposed by the "Whois Integrity Policy Proposal." Timetable for implementation: Immediate From jcurran at istaff.org Tue Aug 26 08:55:30 2008 From: jcurran at istaff.org (John Curran) Date: Tue, 26 Aug 2008 08:55:30 -0400 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: <48B3EECE.6090405@Dilkie.com> References: <48B3EECE.6090405@Dilkie.com> Message-ID: <000248EC-E7B9-4534-9139-116A88EF11E8@istaff.org> On Aug 26, 2008, at 7:53 AM, Lee Dilkie wrote: > Having read this list for over a year now, I can point to many > postings that definitely have a lack of respect for those Legacy > holders that pioneered the network you are using. I'll count myself in that list of pioneers, and indeed have little respect for those who claim special address holding privileges as a result early involvement. The Internet "pioneer" community saw the address depletion problem, and specifically launched the IPng/IPv6 effort, introduced classless network numbering (CIDR), and identified the need for organizations to move to more appropriately sized blocks [per RFC1917/BCP 4] more than a decade ago. If you'd like to know some of the Internet pioneers worthy of respect in the area of their address management, check out these links: /John (solely my personal opinion) From kkargel at polartel.com Tue Aug 26 09:19:15 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 26 Aug 2008 08:19:15 -0500 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: <4C80F17364FE2E4C93053BE9D01DB479095205AC@BCMSG111.corp.ads> References: <7663C7E01D8E094989CA62F0B0D21CD901E0E386@SUEXCL-02.ad.syr.edu><7663C7E01D8E094989CA62F0B0D21CD901E0E3BA@SUEXCL-02.ad.syr.edu><20080825170038.GA8825@vacation.karoshi.com.><7663C7E01D8E094989CA62F0B0D21CD9011DCA72@SUEXCL-02.ad.syr.edu> <4C80F17364FE2E4C93053BE9D01DB479095205AC@BCMSG111.corp.ads> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10A74@mail> No, all the proceeds should fund a party for ARIN members in the Bahamas! ;) -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Matthew Wilder Sent: Monday, August 25, 2008 5:31 PM To: Milton L Mueller Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) On Sat, Aug 25, 2008 at 1:29 PM, Milton Mueller wrote: > I'm simply suggesting that given a scarce, legacy resource that > everyone now needs, and an abundant, next-gen resource the utility of > which depends on a massive migration across two incompatible > standards, RIRs need to adopt policies that provide accurate price > signals and which facilitate shifting the remaining ipv4 resources to > their highest and best uses. And I suppose in the spirit of fairness that all proceeds will go to cancer research? MW _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3107 bytes Desc: not available URL: From bicknell at ufp.org Tue Aug 26 09:37:38 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 26 Aug 2008 09:37:38 -0400 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: <48B3EECE.6090405@Dilkie.com> References: <48B3EECE.6090405@Dilkie.com> Message-ID: <20080826133738.GA69821@ussenterprise.ufp.org> In a message written on Tue, Aug 26, 2008 at 07:53:50AM -0400, Lee Dilkie wrote: > I think he's asking for *respect* not *special status* or rights. Having > read this list for over a year now, I can point to many postings that > definitely have a lack of respect for those Legacy holders that > pioneered the network you are using. I respect 99.99% of the legacy holders; but a few bad apples have generated much of the discussion. Like any large group, there are always a few who deserve no respect. We often talk about the large group of "Legacy Holders", but to me that does them all a disservice. There are really three subgroups of interest: * Small holders. This is anyone who doesn't meet ARIN's current criteria. The people with a single /24, for example. I personally have no interest in ever taking their space away. There are two reasons, I see it as a reasonable "reward" for being an early adopter; and second to recover it would do no good. Recovering a single /24 here or there because someone is using 16 of 256 IP's would leave ARIN with a pile of discontiguous /24's that it couldn't give out with the current policy. A lot of effort for little to no community benefit. I do think this group should have a contract with ARIN, and pay a small ($100 or under) fee per year to keep whois and in-addr.arpa working. * Assignments. This is anyone who would receive an Assignment under ARIN's current policies. An "end user" if you will. My feelings here are generally similar to the small holders. I have no interest in taking space away from this group or undergoing a major auditing campaign. If you managed to get a /20 for your business back in the day so be it. In particular, I don't want to audit them to current standards, it's not worth the time and effort. However, there are some large assignments I think should be audited, but audited to a different standard than we have today. Roughly I think anyone with a /16 or larger block in the assignment class who is using 25% or less should have to return 50% of the space. That to me would make them comply with the spirit of 2050. This group needs to have a contract with ARIN, and I see no reason the standard assignment fees shouldn't apply. * Allocations. This is anyone who would receive an allocation under ARIN's current policies, basically Internet service providers of one form or another. This would likely include many universities, ISP's, and a few big corporations. These groups should meet all current standards, but the requirements to do so should be phased in. For instance, they would be required to meet all current standards in 5 years, with ARIN coming up with an appropriate "sliding scale" of compliance over those 5 years. Why? Well, there are a number of entities sitting on huge swaths of address space they likely aren't using. We've seen with voluntary returns a /8 turned in for a /16. That's 255 /16's that can be given out to other people, and that is waste worth tracking down. A good number of these entities have come back to ARIN looking for more space and/or have acquired ARIN space via merger and to have one block be "special" or "exempt" makes no sense. Several of these companies have used these blocks to be actively anti-competitive in a way that flies in the face of RFC2050. I can think of at least one company that openly advertised a /24 with your T1, no justification required. To have thumbed their nose at the community in the past in such ways has earned them a lack of respect when it comes to the stewardship of Internet Resources. These legacy blocks should have SWIP or RWHOIS, should be included in the consideration of any new requested, and should fall under the standard fee structure. Heck, a good number of the larger blocks are now 2 or 3 merger or divesture steps from the original requestor. Treating them as special is not respecting an early adopter, it's rewarding a business man trying to use legacy status to flaunt 2050 in a way his competitors can't. Perhaps we would do better to divide these groups when we have the discussion. We seem to have a lot of the first group on the list speaking out, when most of my concern is with the third group. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From dudepron at gmail.com Tue Aug 26 11:22:20 2008 From: dudepron at gmail.com (Aaron) Date: Tue, 26 Aug 2008 11:22:20 -0400 Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation In-Reply-To: <6470059FC9A5414E97ABDB2DE4D9D908@tedsdesk> References: <70DE64CEFD6E9A4EB7FAF3A063141066A10A6E@mail> <6470059FC9A5414E97ABDB2DE4D9D908@tedsdesk> Message-ID: <480dad640808260822k7a0c8f82qe071752fd3407597@mail.gmail.com> And how is that any different then what you have had to deal with over the past 10 years? Email isn't the only option. There are other tools available to help in these situations. Your email might be getting filtered for one reason or another. I'm for changing it to 180 days. ARIN sends out bills to current members, mostly via email. Since those bills do get paid, then someone is getting those emails. Aaron Dudek On Mon, Aug 25, 2008 at 4:04 PM, Ted Mittelstaedt wrote: > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel > > Sent: Monday, August 25, 2008 12:59 PM > > To: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation > > > > > > Even 180 days would not be excessive considering we are > > dealing with a situation that has existed for decades > > already. Another six months is not going to tip the canoe. > > > > The whole point of having an e-mail address on the POC is in > case there is a problem with the addressing, it allows other > admins on the Internet who are suffering the ill effects of > the troublesome IP range to e-mail the holder of the range and > get them to fix the problem. > > 180 days turnaround time for me e-mailing an address holder > because he has an attacker who has hijacked those ranges and > is DDoSing me to death, it totally unacceptable and is making > a mockery of the requirement for address holders to have > current contact info. > > > Ted > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Tue Aug 26 11:36:55 2008 From: info at arin.net (Member Services) Date: Tue, 26 Aug 2008 11:36:55 -0400 Subject: [arin-ppml] Results of Transfer Proposal Survey Message-ID: <48B42317.5070108@arin.net> Subscribers to the ARIN Public Policy Mailing List were invited to participate last week in a policy proposal survey. The ARIN Advisory Council, working on an update to Policy Proposal 2008-2, IPv4 Transfer Policy Proposal, sponsored the survey in order to gain additional input. Two hundred plus subscribers to the mail list participated. The results of the survey are available on the ARIN website at: http://www.arin.net/policy/proposals/surveys/ and in pdf version at: http://www.arin.net/policy/proposals/surveys/pdfs/survey_summary_08242008.pdf This input will be added to that gained during the ARIN XXI meeting in Denver, the Caribbean sector meeting in Jamaica and the upcoming Caribbean sector meeting in the Bahamas. Additional discussion of the proposal will take place at the ARIN XXII Public Policy and Members Meeting being held 15-17 October in Los Angeles, California. Please note that the Advisory Council continues to seek input on this issue. Voice your thoughts and opinions on the open Public Policy Mailing List. If you are not subscribed to PPML and wish to participate in this and other policy proposal discussions, you will find subscription details here: http://lists.arin.net/mailman/listinfo/arin-ppml_ ._ Regards, Member Services American Registry for Internet Numbers (ARIN) From micah at riseup.net Tue Aug 26 12:16:36 2008 From: micah at riseup.net (Micah Anderson) Date: Tue, 26 Aug 2008 12:16:36 -0400 Subject: [arin-ppml] Legacy space holders were a big part of the community... i.e. all of it. In-Reply-To: <1080823130905.27224A-100000@Ives.egh.com> References: <1080823130905.27224A-100000@Ives.egh.com> Message-ID: <20080826161636.GB12410@pond.riseup.net> * John Santos [2008-08-23 10:34-0400]: > If you can guarantee that I won't be forced to give up my > /24 as long as I continue to use it, and "continue to use it" > won't be redefined out from under me, then I would consider > signing the LRSA. Otherwise, I feel I would be taking a > huge risk for no perceivable benefit. Full agreement here. > The $100/year isn't an issue, and I have no intention of ever > selling the addresses on Ebay or anywhere else. $100/year to force me to re-number yet again, doesn't seem like a good deal. I dont care how much people are offering on ebay, if they ever do, I have no intention of seeling either. micah -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From tedm at ipinc.net Tue Aug 26 13:39:59 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 26 Aug 2008 10:39:59 -0700 Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation In-Reply-To: <1080825194128.2637D-100000@Ives.egh.com> Message-ID: <03BCD078ADEC4E7EB0639302007832CB@tedsdesk> > -----Original Message----- > From: John Santos [mailto:JOHN at egh.com] > Sent: Monday, August 25, 2008 5:58 PM > To: arin-ppml at arin.net > Cc: Ted Mittelstaedt; 'Keith W. Hare' > Subject: Re: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation > > > On Mon, 25 Aug 2008, Ted Mittelstaedt wrote: > > > > > > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Keith W. Hare > > > Sent: Monday, August 25, 2008 7:25 AM > > > To: arin-ppml at arin.net > > > Subject: Re: [arin-ppml] Policy Proposal: Annual WHOIS > POC Validation > > > > > > > > > > If a valid response > > > >is not received within 14 days, every instance of the > unresponsive > > > >email address will be replaced with "REFUSED RESPONSE" > in the whois > > > >directory. > > > > > > Since my background is database design and performance, I > > > cringe at the idea of overloading the email address field > > > with what should really be a separate field. > > > > > > > Keith, > > > > Adding a field could possibly break web-whois-lookup > forms that are > > out there who don't have good parsers. > > > > Technically, there is no standard for an e-mail address. > There's a > > standard for a DOMAIN-style e-mail address, but if your database > > parser that parses the e-mail address field of ARIN whois > is dependent > > on seeing an '@' then you already are doing it wrong. > > > > Because the string "REFUSED RESPONSE" doesen't follow the > standards > > for domain-style addressing, it isn't going to appear in a > legitimate > > POC e-mail address. Because there's a space it isn't a legitimate > > UUCP address or BITNET address either. It is pretty simple for any > > COMPETENT programmer writing automated query tools to code > for this. > > And we want to discourage people from bulk-queries of the whois > > database anyway - if you don't know how to code for this, we really > > don't want you harvesting e-mail addresses out of whois since your > > likely a spammer. > > > > If we simply remove the POC e-mail address then people > don't know if > > it was removed because it's bogus or because someone made a mistake > > with a SWIP record. > > > > This is why I did not set it to "unavailable at example.com" or some > > such in my proposal from which this proposal is derived. > There is no > > point in overloading someone's mailserver somewhere by some spammer > > trying to send 20,000 mails to a data item that looks like > an e-mail > > address but isn't. > > How about: > > No response (was: ) > I agree, I was thinking of something along the same lines myself. However I will leave it to Chris Grundemann to decide. > This way no information is lost and it has a space in it so > the resulting e-mail address is still invalid, and it makes > no presumptions about the type of e-mail address was > originally there. Also, it would be easy to restore the > address if it turns out that it is valid but the mail was > getting spam-trapped or the recipient was on vacation or > otherwise didn't see it promptly. > The "whois POC e-mail cleanup" proposal I submitted does not have the same problem with people being on vacation - since it is not customary for people to make all e-mail to themselves to bounce, when they are on vacation. > BTW, any kind of automatic second attempt at contacting the > POC should use significantly different wording in case the > original had fallen afoul of a Bayesian SPAM filter. > > I think the details should be left to the ARIN staff, though. > Suggestions about specifics probably shouldn't be in the > policy itself, but just in the rationale and the discussion. > If you have serious enough concerns about looking for e-mail responses then I urge you to not support "Annual WHOIS POC Validation" and support "whois POC e-mail cleanup" instead. The proposals will be fundamentally identical with the exception that Chris's proposal requires a response from the POC e-mail address. My proposal only requires that the POC e-mail address be accepting mail, not that the POC actually responds. Ted From tedm at ipinc.net Tue Aug 26 13:42:52 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 26 Aug 2008 10:42:52 -0700 Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation In-Reply-To: <480dad640808260822k7a0c8f82qe071752fd3407597@mail.gmail.com> Message-ID: <569365D40C954C729E8847F7FC88A0A5@tedsdesk> If the POC e-mail address is heavily filtered then it defeats the purpose of having a POC e-mail address. If you are in favor of 180 days, then why not simply support the "whois POC e-mail cleanup" proposal since 180 day turnaround is pretty much equivalent to not having any turnaround at all, and don't support "Annual WHOIS POC Validation" Ted -----Original Message----- From: Aaron [mailto:dudepron at gmail.com] Sent: Tuesday, August 26, 2008 8:22 AM To: Ted Mittelstaedt Cc: Kevin Kargel; arin-ppml at arin.net Subject: Re: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation And how is that any different then what you have had to deal with over the past 10 years? Email isn't the only option. There are other tools available to help in these situations. Your email might be getting filtered for one reason or another. I'm for changing it to 180 days. ARIN sends out bills to current members, mostly via email. Since those bills do get paid, then someone is getting those emails. Aaron Dudek On Mon, Aug 25, 2008 at 4:04 PM, Ted Mittelstaedt wrote: > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel > Sent: Monday, August 25, 2008 12:59 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation > > > Even 180 days would not be excessive considering we are > dealing with a situation that has existed for decades > already. Another six months is not going to tip the canoe. > The whole point of having an e-mail address on the POC is in case there is a problem with the addressing, it allows other admins on the Internet who are suffering the ill effects of the troublesome IP range to e-mail the holder of the range and get them to fix the problem. 180 days turnaround time for me e-mailing an address holder because he has an attacker who has hijacked those ranges and is DDoSing me to death, it totally unacceptable and is making a mockery of the requirement for address holders to have current contact info. Ted _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arin-ppml at westbrook.com Tue Aug 26 14:32:26 2008 From: arin-ppml at westbrook.com (Eric Westbrook) Date: Wed, 27 Aug 2008 02:32:26 +0800 Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation In-Reply-To: <569365D40C954C729E8847F7FC88A0A5@tedsdesk> References: <480dad640808260822k7a0c8f82qe071752fd3407597@mail.gmail.com> <569365D40C954C729E8847F7FC88A0A5@tedsdesk> Message-ID: <6905ba860808261132i56cbcf63t93b447d8c369aee6@mail.gmail.com> It also occurs to me that under any automated email verification scheme, the sender address from which emails originate should be well published, to assist conscientious recipients in whitelisting the messages. I'd suggest explicitly mentioning doing so in any final language -- at least the practice of publishing the sender address, if not the actual address itself. $0.02, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrhett at svcolo.com Tue Aug 26 14:49:49 2008 From: jrhett at svcolo.com (Jo Rhett) Date: Tue, 26 Aug 2008 11:49:49 -0700 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: <48AF5D79.3010207@psg.com> References: <1080820172429.27224A-100000@Ives.egh.com> <20080820220629.GA69278@ussenterprise.ufp.org> <48AF5D79.3010207@psg.com> Message-ID: <8955155F-D3D1-4C36-A0BB-75DAEA49A08F@svcolo.com> On Aug 22, 2008, at 5:44 PM, Randy Bush wrote: >> I suspect the half of the towns people who set decent rules and >> tried to preserve the commons will be relatively unsympathetic at >> that point in time that those who have avoided participating in >> society and openly mocked them are now receiving their just rewards. > kiddies, get a clue. many folk with legacy space were building the > internet while you were still in nappies. we think it is you who are > pissing on the commons. I don't disagree. But I don't think that ARIN should spend time/ resources trying to help people who aren't paying members. Basic conservative approach. It's not like any of these individuals (who are still alive and frankly are mostly active in ARIN today) are unaware of ARIN or that the legacy RSA exists. -- Jo Rhett senior geek Silicon Valley Colocation Support Phone: 408-400-0550 From tedm at ipinc.net Tue Aug 26 14:54:32 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 26 Aug 2008 11:54:32 -0700 Subject: [arin-ppml] Results of Transfer Proposal Survey In-Reply-To: <48B42317.5070108@arin.net> Message-ID: <723083FF30894BF28532E39AC06E7859@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > Sent: Tuesday, August 26, 2008 8:37 AM > To: arin-ppml at arin.net; arin-announce at arin.net > Subject: [arin-ppml] Results of Transfer Proposal Survey > > > Subscribers to the ARIN Public Policy Mailing List were invited to > participate last week in a policy proposal survey. The ARIN Advisory > Council, working on an update to Policy Proposal 2008-2, IPv4 > Transfer > Policy Proposal, sponsored the survey in order to gain > additional input. > > Two hundred plus subscribers to the mail list participated. > The results > of the survey are available on the ARIN website at: > http://www.arin.net/policy/proposals/surveys/ > and in pdf version at: > http://www.arin.net/policy/proposals/surveys/pdfs/survey_summa ry_08242008.pdf >This input will be added to that gained during the ARIN XXI meeting in >Denver, the Caribbean sector meeting in Jamaica and the upcoming >Caribbean sector meeting in the Bahamas. Additional discussion of the >proposal will take place at the ARIN XXII Public Policy and Members >Meeting being held 15-17 October in Los Angeles, California. >Please note that the Advisory Council continues to seek input on this >issue. This survey was biased from the beginning - it omitted one key question at the beginning: Do you want a liberalized transfer policy at all? That is why the number of persons responding from the PPL was so small - 11% - because if you were opposed a liberalized policy, you could see where the survey was going and undoubtedly most people opposed to a liberalized policy abandoned the survey before completion. It's actually much more significant that question 11 had a 13% NO response! Since the survey was SO biased, it's amazing that that many people opposed to a liberalized policy actually made it through the survey at all! Where the usefulness of this survey is, though, is in telling us WHO is making up the pro-liberalization camp. The significant responses are as follows: Question 11: 86% in favor. OK well we already knew that because very few people opposing liberalized transfers would be completing the survey after getting to this question. Question 10: 80% in favor. What this tells us is that those in favor of liberalization want the "RIR stamp of approval" on their transaction. One more, this is a no-brainer; it should have been obvious prior to the survey that people calling for a "legacy number broker" separate from the RIR were the fringe element. Neither 11 or 10 tell us anything we don't already know and are more distractor questions than anything else. Question 9: 53% in favor of limiting multiple requests, 47% against. This is where it gets interesting - what this is telling us is that the pro-liberalized transfer camp is itself split over the idea of allowing freewheeling-and-dealing of IPv4 numbers. Question 8: 58% for current holders being allowed limited deaggregation, the rest want no limits. This is also indicative of that split in the pro-liberalized transfer camp. What it is telling us is HOW each camp wants things to proceed. The pro-wheeling-and-dealing camp are speculators - their aim is to make a lot of money brokering large blocks, splitting them up, and selling them. Any kind of restrictions would crimp their plans. But they are in the minority. The bulk of the pro-liberalized transfer folks are just wanting to make money off holdings that they have, but aren't using, or have but could easily give up by renumbering. They want limited deaggregation because that is all they need - and since they are planning on staying in the game long-haul, they don't want to screw themselves by allowing unlimited growth of routing entries in the BGP table. Question 7: 74% in favor of ARIN having control over limiting deaggregation. Once more, a no-brainer. These are the same folks who want ARIN's blessing in Question #10. Why would you be in favor of having ARIN operating a listing service but not giving them control over the stuff listed on it? That's why the % split on this question was within a few points of the split on #10 Question 6: 71% in favor of prequals on need. No brainer here. This is basically a restatement of the idea in #7 and #10 - give ARIN control. Question 5: Nearly even split on prequals of address holders wanting to sell space. This basically indicates the level of discomfort of the pro-liberalization camp who are NOT speculators. Obviously if you're a speculator then you don't care where the IPv4 is coming from, whether the holder meets prequal or not. The only people who would care are the ones who are pro-liberalization only for the reason that they want to see more space freed up, or perhaps sell off some of their own holdings. The majority of -those- people are not happy with the idea of allowing un-prequalified people out there selling off IPv4. Question 4: Uninteresting question - nobody cares what happens after the deal is done. Question 3: This is like Question 9 and 8 - it merely shows the split in the pro-liberalization camp, but it does indicate the bulk of the speculators are coming from the legacy arena because obviously if legacy holders didn't make up a large number of survey respondents, they wouldn't care if the legacy holders were shafted by an LRSA and the response would throw the legacy holders under the bus by a stronger majority voting yes. Question 2: No brainer, basically a restatement of question #11 Question 1: Expiration date. This is like 9, 8 and 3. It shows the split in the pro-liberalization camp. Obviously, speculators aren't going to want an expiration date of the liberalized policy. But the non-speculators in favor of a liberalized policy are more evenly split on the idea of an expiration date. In summary, while the survey illustrated the internal split within the pro-liberalization camp, it still doesen't tell us what is really important - how many people really are in favor of a liberalized policy. It in no way indicates that there is a majority of people in favor of a liberalized transfer policy. A more even-handed and unbiased survey would have been more useful. Ted From owen at delong.com Tue Aug 26 15:08:05 2008 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Aug 2008 12:08:05 -0700 Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation In-Reply-To: <03BCD078ADEC4E7EB0639302007832CB@tedsdesk> References: <03BCD078ADEC4E7EB0639302007832CB@tedsdesk> Message-ID: <04E0C3D0-E155-4407-A2B7-9F1031D145A9@delong.com> > > The proposals will be fundamentally identical with the exception > that Chris's proposal requires a response from the POC e-mail > address. My proposal only requires that the POC e-mail address > be accepting mail, not that the POC actually responds. For interesting values of accepting where domain-squatter simply black-holing the email qualifies as acceptance. Owen From Lee.Howard at stanleyassociates.com Tue Aug 26 14:52:59 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Tue, 26 Aug 2008 14:52:59 -0400 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9011DCA72@SUEXCL-02.ad.syr.edu> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B13A9C3@CL-S-EX-1.stanleyassociates.com> > Untrue. I am sure that once IPv4 blocks command a price that > accurately reflects their value, and once they can be shifted > more easily from lower valued to higher valued uses, their > use will change dramatically. I'm sure this only because of my ignorance of economics, but the only measure you have of "value" is "dollars." There are things of value (love, air, cooperation between providers) that are not measured in dollars. > the issue is not > whether a transition is needed, but where that decision is > located and what role the RIRs play in facilitating it. I disagree with this sequencing. The issue is not "where the transition plan occurs" but "what the transition plan is." If we can agree on how to do this, we can discuss the agents to execute the plan. > simply suggesting that given a scarce, legacy resource that > everyone now needs, and an abundant, next-gen resource the > utility of which depends on a massive migration across two > incompatible standards, RIRs need to adopt policies that > provide accurate price signals and which facilitate shifting Why "price" signals? Again, I Am Not An Economist. I do agree that we should send the signal that everyone should conserve IPv4 and implement IPv6. > the remaining ipv4 resources to their highest and best uses. > I'm also suggesting that they refrain from exploiting their > leverage over both resource pools to impose a top-down > transition plan on operators. We are incapable of doing so. *WE* can only create policies if *WE* create policies.[1] That is why I asked, "How can ARIN help minimize the pain of transition?" The pain of change isn't in the high cost of obtaining IPv6 address space, and the pain of change isn't in the scarcity of IPv4. To a large extent, it's in the inability of network operators to devote scarce resources (labor, dollars) to deployment. To a somewhat lesser extent, it's in some technical issues with IPv6, including vendor support, network tools, and some weakness with dual-stack and translation mechanisms. I see consensus that the best answer to IPv4 scarcity is IPv6. The policy issues with IPv6 are few. I don't know whether there is consensus that extending the life of IPv4 will help the transition, or by how much. So, if the best answer is for each of us to deploy IPv6, how can ARIN help? Lee Disclaimer: My logic and conclusions; I am not representing a Board position. [1] *WE* meaning those operators, and indeed the rest of the community. From owen at delong.com Tue Aug 26 15:21:16 2008 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Aug 2008 12:21:16 -0700 Subject: [arin-ppml] Results of Transfer Proposal Survey In-Reply-To: <723083FF30894BF28532E39AC06E7859@tedsdesk> References: <723083FF30894BF28532E39AC06E7859@tedsdesk> Message-ID: <2AC5EF1E-B452-4940-8E02-CD2FFE771B34@delong.com> > This survey was biased from the beginning - it omitted one > key question at the beginning: Do you want a liberalized > transfer policy at all? That is why the number of persons > responding from the PPL was so small - 11% - because if you > were opposed a liberalized policy, you could see where the > survey was going and undoubtedly most people opposed to > a liberalized policy abandoned the survey before completion. > Actually, no. We were trying to gauge what, if any, changes to a liberalized transfer policy would make it palatable, and, at the end, we specifically asked "If a proposal incorporated your above feedback, would you support such a proposal?" We put the question at the end of the survey, not at the beginning, but, the question was, indeed, in there. > > In summary, while the survey illustrated the internal split > within the pro-liberalization camp, it still doesen't tell us > what is really important - how many people really are in favor > of a liberalized policy. It in no way indicates that there is > a majority of people in favor of a liberalized transfer policy. > It at least tells us that a strong majority of respondents to the survey are in favor of a liberalized transfer policy. If you are opposed to such a policy in general, then, I encourage you to speak up on PPML and let us know. Personally, I do not think a liberalized transfer policy is a good idea. As an AC member, I perceive a roughly 50/50 split between those in favor and those opposed with a great deal of variation among those in favor as to what kind of policy they want to see. > A more even-handed and unbiased survey would have been more > useful. > I'm sorry the survey was not to your liking, but, we really did try to make it as even-handed as possible in the short time that was available to craft the questions. Remember, the survey was crafted by a group of volunteers trying to gather data from the community based on feedback already received and in order to gain some insight into how we might better craft the next revision of 2008-2. The question of whether a transfer policy should exist at all or not is one for this list and for the public policy meeting(s). At the Denver meeting, there was certainly strong support from the community to continue working on a transfer policy. Owen From mueller at syr.edu Tue Aug 26 15:25:38 2008 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 26 Aug 2008 15:25:38 -0400 Subject: [arin-ppml] Results of Transfer Proposal Survey In-Reply-To: <723083FF30894BF28532E39AC06E7859@tedsdesk> References: <48B42317.5070108@arin.net> <723083FF30894BF28532E39AC06E7859@tedsdesk> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9022150D9@SUEXCL-02.ad.syr.edu> An assessment of the ARIN survey is up at the IGP blog. http://blog.internetgovernance.org/blog/_archives/2008/8/26/3856632.html Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org From bicknell at ufp.org Tue Aug 26 15:31:52 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 26 Aug 2008 15:31:52 -0400 Subject: [arin-ppml] Results of Transfer Proposal Survey In-Reply-To: <723083FF30894BF28532E39AC06E7859@tedsdesk> References: <48B42317.5070108@arin.net> <723083FF30894BF28532E39AC06E7859@tedsdesk> Message-ID: <20080826193152.GA1321@ussenterprise.ufp.org> I think perhaps Ted misunderstood the purpose of the survey. The purpose of the survey was to help the AC modify 2008-2 in ways that would increase support for the policy proposal. In Denver the community strongly told the AC to revise the proposal, and the AC is trying to figure out how to do it. Since the proposal is to enable IPv4 transfers, it should be no suprise the questions are to which restrictions on transfers would be best. The survey does not represent consensus, or lack of, for the policy. That will be determined by PPML, and the community at the Carribean and Los Angeles meetings. In essence Ted, it's like jumping on the Democrats at the Democratic convention and complaining McCain isn't on the ballet. PPML is a little weird in that both sides of an issue get to discuss their strategys and ideas in front of the other side. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From mueller at syr.edu Tue Aug 26 15:33:21 2008 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 26 Aug 2008 15:33:21 -0400 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency Transfer Policy forIPv4 Addresses In-Reply-To: <48B3FBFC.7070307@arin.net> References: <48B3FBFC.7070307@arin.net> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9022150DA@SUEXCL-02.ad.syr.edu> I am having trouble understanding this proposal and seek clarification. 1. How does this "emergency" transfer proposal relate to Policy Proposal 2008-2, the other transfer policy proposal? Is it considered a supplement to that proposal or a substitute for it? 2. How does one engage in a transfer "without the active involvement of ARIN as an intermediary" when the recipient of the transfer must "document operational need in accordance with current ARIN policy" and sign an RSA "covering those resources in advance of transfer"? Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > Sent: Tuesday, August 26, 2008 8:50 AM > To: ppml at arin.net > Subject: [arin-ppml] Policy Proposal 2008-6: Emergency > Transfer Policy forIPv4 Addresses > > On 21 August 2008, the ARIN Advisory Council (AC) concluded its review > of "Emergency Transfer Policy for IPv4 Addresses" and accepted it as a > formal policy proposal for discussion by the community. > > The proposal is designated Policy Proposal 2008-6: Emergency Transfer > Policy for IPv4 Addresses. The proposal text is below and can > be found at: > http://www.arin.net/policy/proposals/2008_6.html > > All persons in the community are encouraged to discuss Policy Proposal > 2008-6 prior to it being presented at the ARIN XXII Public Policy > Meeting. Both the discussion on the Public Policy Mailing List > and at the Public Policy Meeting will be used to determine > the community > consensus regarding this policy proposal. > > AC shepherds for this proposal are Owen DeLong and Stacy Hughes. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > ARIN's Policy Proposal Archive can be found at: > http://www.arin.net/policy/proposals/proposal_archive.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal 2008-6 > Emergency Transfer Policy for IPv4 Addresses > > Author: Bill Darte > > Proposal Version: 1.0 > > Submission Date: August 15, 2008 > > Proposal type: New > > Policy term: Temporary > > Policy statement: > > 8.2.1 Emergency Transfer Policy for IPv4 Addresses > > For a period of 3 years from policy implementation, transfer of ARIN > IPv4 addresses between two entities in the ARIN region, without the > active involvement of ARIN as an intermediary, will be considered > legitimate and will be documented accordingly under the following > conditions: > > 1. Transfer takes place from a holder of IPv4 addresses recognized by > ARIN as the legitimate and exclusive holder of those resources. > > 2. Transfer takes place to a recipient that has documented > operational > need in accordance with current ARIN policy and that signs an RSA with > ARIN covering those resources in advance of transfer. > > 3. Transfer of addresses takes place in such a way that the original > contiguous block(s) are not disaggregated into more than 4 resultant > network blocks each being greater than or equal to the current minimum > sizes specified in applicable ARIN policy. > > 4. Transfer is complete and unrestricted and is supported by > documentation that ARIN deems satisfactory. > > > Rationale: > > In order for ARIN to fulfill its mission and to facilitate a > continuing > supply of IPv4 address resources to its service community when ARIN > resources are no longer adequate, and to preserve the integrity of > documentation and ARIN services for those resources, this > policy may be > implemented. Its intent is to preserve the current tradition of > need-based allocation/assignments for those still needing > IPv4 resources > during a transition period as the industry adopts IPv6. This policy is > not intended to create a 'market' for such transfers and does not > introduce or condone the monetization of address resources or > a view of > addresses as property. It does recognize that organizations making > available unused or no longer needed address resources may > incur certain > costs that might be compensated by those acquiring the > resources. This > policy is intended to be transient and light-weight and does not > encourage a sustained or continuing role for IPv4, but rather helps to > mitigate a transitional crisis that may emerge while the > industry adopts > IPv6 in accordance with the recommendation of ARIN's Board of > Trustees. > > Timetable for implementation: > > This policy, once ratified by the ARIN Board of Trustees, would be > implemented when either the free-pool of IANA addresses is > exhausted or > IPv4 address resources in the ARIN Region reaches a threshold of > scarcity recognized by the ARIN Board of Trustees as requiring this > policy implementation. > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From tedm at ipinc.net Tue Aug 26 15:37:33 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 26 Aug 2008 12:37:33 -0700 Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation In-Reply-To: <04E0C3D0-E155-4407-A2B7-9F1031D145A9@delong.com> Message-ID: <55411736BB584699BFF00E5EC4FCFB2F@tedsdesk> > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Tuesday, August 26, 2008 12:08 PM > To: Ted Mittelstaedt > Cc: 'John Santos'; arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation > > > > > > The proposals will be fundamentally identical with the > exception that > > Chris's proposal requires a response from the POC e-mail > address. My > > proposal only requires that the POC e-mail address be > accepting mail, > > not that the POC actually responds. > > For interesting values of accepting where domain-squatter > simply black-holing the email qualifies as acceptance. > Correct. I am not trying to fix the world, just one little piece of it. Does it really matter if someone is squatting on a domain name belonging to a former POC or not? Would you really advocate ARIN make a determination of whether the holder of an address - legacy or not - is the legitimate holder based purely on whether the e-mail address in the POC is accepting mail or not? (or responding to mail or not?) I am all in favor of having ARIN periodically validate POC's of allocated blocks, both legacy and non-legacy. But to do this requires a LOT of data checks in the block owner. Most importantly, is the block being routed? Who is routing it? Is there an operating website on it? For example suppose someone comes along and finds an old defunct legacy block and hijacks the domain name on it and starts routing the block and spamming from it. They blackhole e-mails to it. Would you have ARIN consider that block to be owned by a valid holder simply because they are accepting and black-holing mail on it? I would not. Clearly there is a debate over having ARIN validate block holders. For non-legacy blocks, we can assume for the purpose of argument that any block being paid up on it's annual fee is owned by the legitimate owner. Thus, for legacy blocks not under LRSA it is quite possible there are a lot of abandonded and invalid ones out there. My proposal isn't trying to become the vehicle to go out and identify all those abandoned and invalid legacy blocks that we assume exist. Perhaps I might even write a proposal that would attempt to define how to do this in the future. But, this proposal is not intended to be it. All that I am trying to do, and all that Chris is trying to do, with our proposals, is get the whois database POC's to have valid e-mail addresses. That is a very simple, basic goal - and yet, there's already 2 proposals that are fundamentally different on how to do that one little thing, because there's multiple definitions of what a valid e-mail address is. Ted From tedm at ipinc.net Tue Aug 26 15:54:20 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 26 Aug 2008 12:54:20 -0700 Subject: [arin-ppml] Results of Transfer Proposal Survey In-Reply-To: <2AC5EF1E-B452-4940-8E02-CD2FFE771B34@delong.com> Message-ID: <964B1F96D84F4CFF99E10160655B8804@tedsdesk> > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Tuesday, August 26, 2008 12:21 PM > To: Ted Mittelstaedt > Cc: 'Member Services'; arin-ppml at arin.net; arin-announce at arin.net > Subject: Re: [arin-ppml] Results of Transfer Proposal Survey > > > > This survey was biased from the beginning - it omitted one key > > question at the beginning: Do you want a liberalized > transfer policy > > at all? That is why the number of persons responding from > the PPL was > > so small - 11% - because if you were opposed a liberalized > policy, you > > could see where the survey was going and undoubtedly most people > > opposed to a liberalized policy abandoned the survey before > > completion. > > > Actually, no. We were trying to gauge what, if any, changes > to a liberalized transfer policy would make it palatable, > and, at the end, we specifically asked "If a proposal > incorporated your above feedback, would you support such a proposal?" > > We put the question at the end of the survey, not at the > beginning, but, the question was, indeed, in there. My main objection was putting that question at the end of the survey - and there was also that bit about answering question 11 consistent with your prior answers. Kind of in a way saying don't bother disagreeing unless you disagreement was consistent with your earlier "agreement" you might say. I did take and complete the survey, BTW. > > > > In summary, while the survey illustrated the internal split > within the > > pro-liberalization camp, it still doesen't tell us what is really > > important - how many people really are in favor of a liberalized > > policy. It in no way indicates that there is a majority of > people in > > favor of a liberalized transfer policy. > > > It at least tells us that a strong majority of respondents to > the survey are in favor of a liberalized transfer policy. If > you are opposed to such a policy in general, then, I > encourage you to speak up on PPML and let us know. > I and others have done this already and the AC is well aware I am sure that opponents of a liberalized transfer policy feel that we should be focusing on IPv6 and not doing things to try and extend IPv4. A liberalized transfer policy fundamentally extends the usability of IPv4 by providing IPv4 past the so-called date of "IPv4 runout" > Personally, I do not think a liberalized transfer policy is > a good idea. As an AC member, I perceive a roughly 50/50 > split between those in favor and those opposed with a > great deal of variation among those in favor as to what > kind of policy they want to see. > > > A more even-handed and unbiased survey would have been more useful. > > > I'm sorry the survey was not to your liking, but, we really > did try to make it as even-handed as possible in the short > time that was available to craft the questions. Remember, > the survey was crafted by a group of volunteers trying to > gather data from the community based on feedback already > received and in order to gain some insight into how we might > better craft the next revision of 2008-2. > How about the idea of NOT crafting another revision of 2008-2? > The question of whether a transfer policy should exist at all > or not is one for this list and for the public policy > meeting(s). At the Denver meeting, there was certainly strong > support from the community to continue working on a transfer policy. > Supporting the idea of "continuing to work on a policy" is entirely different than supporting the results of that labor. I for example strongly support the US continuing to work on a new energy policy. But, I oppose: )paying more money for energy )using less energy for myself )more nuke plants )more coal plants )importing more oil )offshore drilling )ANWR drilling )wind farms because they interfere with birds )tidal generation because the plants mess up the pristine beach views )geothermal generation because power plants shouldn't be in national forests and parks where most of the geothermal is )more transmission lines because they produce radiation )ethanol because it uses up our food supply )biodiesel because it uses up our food supply and encourages people to eat more fried foods that make them fat )more hydropower because of damaging fish runs )burning more natural gas because it adds to global warming )communities covering the roofs of their houses with solar cells because it violates the deed restrictions the neighborhood association setup that define what kind of roof is supposed to be on the home But, by golly, keep working on that new energy policy!!!! ;-) Ted From stephen at sprunk.org Tue Aug 26 15:56:27 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 26 Aug 2008 14:56:27 -0500 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: <8955155F-D3D1-4C36-A0BB-75DAEA49A08F@svcolo.com> References: <1080820172429.27224A-100000@Ives.egh.com> <20080820220629.GA69278@ussenterprise.ufp.org> <48AF5D79.3010207@psg.com> <8955155F-D3D1-4C36-A0BB-75DAEA49A08F@svcolo.com> Message-ID: <48B45FEB.2090406@sprunk.org> Jo Rhett wrote: > On Aug 22, 2008, at 5:44 PM, Randy Bush wrote: > >>> I suspect the half of the towns people who set decent rules and >>> tried to preserve the commons will be relatively unsympathetic at >>> that point in time that those who have avoided participating in >>> society and openly mocked them are now receiving their just rewards. >>> >> kiddies, get a clue. many folk with legacy space were building the >> internet while you were still in nappies. we think it is you who are >> pissing on the commons. >> > > I don't disagree. But I don't think that ARIN should spend time/ > resources trying to help people who aren't paying members. Basic > conservative approach. > That logic assumes it's the registrant who gets the benefit of the free service, while in fact the registrant gets little to no benefit. They already know who they are and what they have. The benefit of WHOIS is to let _others_ know who they are and what they have, and the majority of those "others" are the ones paying the bill and to whom the benefit actually accrues. If anything, we should be thanking the few legacy folks that do keep their information up to date, since they have no obligation nor much incentive to do so. Putting more obstacles in their path just means fewer will bother with the hassle, and the commons will suffer. > It's not like any of these individuals (who are still alive and > frankly are mostly active in ARIN today) are unaware of ARIN or that > the legacy RSA exists What the folks on this list, or the folks who built the Internet, think and what their employers' or ex-employers' managements and/or legal counsel are willing to do may be (and often are) wildly divergent. Discussion here of the LRSA is interesting but not productive; ARIN's counsel is the one that drafted it and is getting feedback from potential signers about possible problems. PPML is not, and IMHO should not be, involved in that cycle. S From cgrundemann at gmail.com Tue Aug 26 16:25:06 2008 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 26 Aug 2008 14:25:06 -0600 Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation In-Reply-To: <6905ba860808261132i56cbcf63t93b447d8c369aee6@mail.gmail.com> References: <480dad640808260822k7a0c8f82qe071752fd3407597@mail.gmail.com> <569365D40C954C729E8847F7FC88A0A5@tedsdesk> <6905ba860808261132i56cbcf63t93b447d8c369aee6@mail.gmail.com> Message-ID: <443de7ad0808261325t2e7cc206r1dbc1543e30f7aff@mail.gmail.com> On Tue, Aug 26, 2008 at 12:32 PM, Eric Westbrook wrote: > It also occurs to me that under any automated email verification scheme, the > sender address from which emails originate should be well published, to > assist conscientious recipients in whitelisting the messages. I'd suggest > explicitly mentioning doing so in any final language -- at least the > practice of publishing the sender address, if not the actual address itself. Agreed. Although I did not add it to the proposal, I believe that ARIN staff would want to do the verification on a set date every year and make some sort of announcement every year before the verification, to try and help POCs be prepared to receive and respond to the verification email. Also, the same sender address should always be used, to allow whitelisting. Do you believe that this should be specified in the proposal? ~Chris > > $0.02, > Eric > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- Chris Grundemann www.linkedin.com/in/cgrundemann From cgrundemann at gmail.com Tue Aug 26 16:33:59 2008 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 26 Aug 2008 14:33:59 -0600 Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation In-Reply-To: <1080825194128.2637D-100000@Ives.egh.com> References: <1080825194128.2637D-100000@Ives.egh.com> Message-ID: <443de7ad0808261333w6339e60v4b2fce64e3cdbfb3@mail.gmail.com> On Mon, Aug 25, 2008 at 6:58 PM, John Santos wrote: > On Mon, 25 Aug 2008, Ted Mittelstaedt wrote: > >> >> >> > -----Original Message----- >> > From: arin-ppml-bounces at arin.net >> > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Keith W. Hare >> > Sent: Monday, August 25, 2008 7:25 AM >> > To: arin-ppml at arin.net >> > Subject: Re: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation >> > >> > >> > > If a valid response >> > >is not received within 14 days, every instance of the unresponsive >> > >email address will be replaced with "REFUSED RESPONSE" in the whois >> > >directory. >> > >> > Since my background is database design and performance, I >> > cringe at the idea of overloading the email address field >> > with what should really be a separate field. >> > >> >> Keith, >> >> Adding a field could possibly break web-whois-lookup forms >> that are out there who don't have good parsers. >> >> Technically, there is no standard for an e-mail address. There's a >> standard for a DOMAIN-style e-mail address, but if your database parser >> that parses the e-mail address field of ARIN whois is dependent on >> seeing an '@' then you already are doing it wrong. >> >> Because the string "REFUSED RESPONSE" doesen't follow the >> standards for domain-style addressing, it isn't going to appear >> in a legitimate POC e-mail address. Because there's a space >> it isn't a legitimate UUCP address or BITNET address either. It >> is pretty simple for any COMPETENT programmer writing automated >> query tools to code for this. And we want to discourage people >> from bulk-queries of the whois database anyway - if you don't >> know how to code for this, we really don't want you harvesting >> e-mail addresses out of whois since your likely a spammer. >> >> If we simply remove the POC e-mail address then people don't >> know if it was removed because it's bogus or because someone made >> a mistake with a SWIP record. >> >> This is why I did not set it to "unavailable at example.com" or some >> such in my proposal from which this proposal is derived. There is no >> point in overloading someone's mailserver >> somewhere by some spammer trying to send 20,000 mails to a data item that >> looks like an e-mail address but isn't. > > How about: > > No response (was: ) I like this idea if it passes the db guys sniff test. > > This way no information is lost and it has a space in it so the resulting > e-mail address is still invalid, and it makes no presumptions about the > type of e-mail address was originally there. Also, it would be easy to > restore the address if it turns out that it is valid but the mail was > getting spam-trapped or the recipient was on vacation or otherwise didn't > see it promptly. > > BTW, any kind of automatic second attempt at contacting the POC should > use significantly different wording in case the original had fallen > afoul of a Bayesian SPAM filter. > > I think the details should be left to the ARIN staff, though. > Suggestions about specifics probably shouldn't be in the policy > itself, but just in the rationale and the discussion. I agree that more of the details should be left to ARIN staff. Would the change I proposed earlier be enough to leave this decision in their hands, in your (and everyone else's) opinion? "...is not received within 14 days, every instance of the unresponsive email address will be /marked/ with "/NO/ RESPONSE" in the whois directory." ~Chris > >> >> Ted >> >> > However, aside from this implementation detail in a policy >> > proposal, I support the proposal. This will achieve the goal >> > of freezing orphaned resources while sidesteping the quagmire >> > of (L)RSAs and legacy resource holders. >> > >> > Keith >> > >> > >> > ______________________________________________________________ >> > >> > Keith W. Hare JCC Consulting, Inc. >> > keith at jcc.com 600 Newark Road >> > Phone: 740-587-0157 P.O. Box 381 >> > Fax: 740-587-0163 Granville, Ohio 43023 >> > http://www.jcc.com USA >> > ______________________________________________________________ >> > >> > >> > >> > >> > _______________________________________________ >> > PPML >> > You are receiving this message because you are subscribed to >> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> > Unsubscribe or manage your mailing list subscription at: >> > http://lists.arin.net/mailman/listinfo/arin-ppml >> > Please contact info at arin.net if you experience any issues. >> > >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> >> > > -- > John Santos > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- Chris Grundemann www.linkedin.com/in/cgrundemann From BillD at cait.wustl.edu Tue Aug 26 16:59:36 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Tue, 26 Aug 2008 15:59:36 -0500 Subject: [arin-ppml] Results of Transfer Proposal Survey In-Reply-To: <723083FF30894BF28532E39AC06E7859@tedsdesk> References: <48B42317.5070108@arin.net> <723083FF30894BF28532E39AC06E7859@tedsdesk> Message-ID: No-one had to answer any question...therefore the could have skipped to the bottom and said NO.... but....to ask the question.... All those against a liberalized transfer policy of any kind...please reply saying so... Bill Darte ARIN AC > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > Sent: Tuesday, August 26, 2008 1:55 PM > To: 'Member Services'; arin-ppml at arin.net; arin-announce at arin.net > Subject: Re: [arin-ppml] Results of Transfer Proposal Survey > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > > Sent: Tuesday, August 26, 2008 8:37 AM > > To: arin-ppml at arin.net; arin-announce at arin.net > > Subject: [arin-ppml] Results of Transfer Proposal Survey > > > > > > Subscribers to the ARIN Public Policy Mailing List were invited to > > participate last week in a policy proposal survey. The ARIN > Advisory > > Council, working on an update to Policy Proposal 2008-2, > IPv4 Transfer > > Policy Proposal, sponsored the survey in order to gain additional > > input. > > > > Two hundred plus subscribers to the mail list participated. > > The results > > of the survey are available on the ARIN website at: > > http://www.arin.net/policy/proposals/surveys/ > > and in pdf version at: > > http://www.arin.net/policy/proposals/surveys/pdfs/survey_summa > ry_08242008.pdf > > > >This input will be added to that gained during the ARIN XXI > meeting in > >Denver, the Caribbean sector meeting in Jamaica and the upcoming > >Caribbean sector meeting in the Bahamas. Additional > discussion of the > >proposal will take place at the ARIN XXII Public Policy and Members > >Meeting being held 15-17 October in Los Angeles, California. > > >Please note that the Advisory Council continues to seek > input on this > >issue. > > This survey was biased from the beginning - it omitted one > key question at the beginning: Do you want a liberalized > transfer policy at all? That is why the number of persons > responding from the PPL was so small - 11% - because if you > were opposed a liberalized policy, you could see where the > survey was going and undoubtedly most people opposed to a > liberalized policy abandoned the survey before completion. > > It's actually much more significant that question 11 had a > 13% NO response! Since the survey was SO biased, it's > amazing that that many people opposed to a liberalized policy > actually made it through the survey at all! > > Where the usefulness of this survey is, though, is in telling > us WHO is making up the pro-liberalization camp. > > The significant responses are as follows: > > Question 11: 86% in favor. OK well we already knew that > because very few people opposing liberalized transfers would > be completing the survey after getting to this question. > > Question 10: 80% in favor. What this tells us is that those > in favor of liberalization want the "RIR stamp of approval" > on their transaction. One more, this is a no-brainer; it > should have been obvious prior to the survey that people > calling for a "legacy number broker" separate from the RIR > were the fringe element. > > Neither 11 or 10 tell us anything we don't already know and > are more distractor questions than anything else. > > Question 9: 53% in favor of limiting multiple requests, 47% > against. This is where it gets interesting - what this is > telling us is that the pro-liberalized transfer camp is > itself split over the idea of allowing freewheeling-and-dealing of > IPv4 numbers. > > Question 8: 58% for current holders being allowed limited > deaggregation, the rest want no limits. This is also > indicative of that split in the pro-liberalized transfer camp. > What it is telling us is HOW each camp wants things to proceed. > > The pro-wheeling-and-dealing camp are speculators - their aim > is to make a lot of money brokering large blocks, splitting > them up, and selling them. Any kind of restrictions would > crimp their plans. But they are in the minority. The bulk > of the pro-liberalized transfer folks are just wanting to > make money off holdings that they have, but aren't using, or > have but could easily give up by renumbering. They want > limited deaggregation because that is all they need - and > since they are planning on staying in the game long-haul, > they don't want to screw themselves by allowing unlimited > growth of routing entries in the BGP table. > > Question 7: 74% in favor of ARIN having control over limiting > deaggregation. Once more, a no-brainer. These are the same > folks who want ARIN's blessing in Question #10. Why would > you be in favor of having ARIN operating a listing service > but not giving them control over the stuff listed on it? > That's why the % split on this question was within a few > points of the split on #10 > > Question 6: 71% in favor of prequals on need. No brainer here. > This is basically a restatement of the idea in #7 and #10 - > give ARIN control. > > Question 5: Nearly even split on prequals of address holders > wanting to sell space. This basically indicates the level of > discomfort of the pro-liberalization camp who are NOT > speculators. Obviously if you're a speculator then you don't > care where the IPv4 is coming from, whether the holder meets > prequal or not. The only people who would care are the ones > who are pro-liberalization only for the reason that they want > to see more space freed up, or perhaps sell off some of their > own holdings. The majority of -those- people are not happy > with the idea of allowing un-prequalified people out there > selling off IPv4. > > Question 4: Uninteresting question - nobody cares what > happens after the deal is done. > > Question 3: This is like Question 9 and 8 - it merely shows > the split in the pro-liberalization camp, but it does > indicate the bulk of the speculators are coming from the > legacy arena because obviously if legacy holders didn't make > up a large number of survey respondents, they wouldn't care > if the legacy holders were shafted by an LRSA and the > response would throw the legacy holders under the bus by a > stronger majority voting yes. > > Question 2: No brainer, basically a restatement of question #11 > > Question 1: Expiration date. This is like 9, 8 and 3. It > shows the split in the pro-liberalization camp. Obviously, > speculators aren't going to want an expiration date of the > liberalized policy. But the non-speculators in favor of a > liberalized policy are more evenly split on the idea of an > expiration date. > > In summary, while the survey illustrated the internal split > within the pro-liberalization camp, it still doesen't tell us > what is really important - how many people really are in > favor of a liberalized policy. It in no way indicates that > there is a majority of people in favor of a liberalized > transfer policy. > > A more even-handed and unbiased survey would have been more useful. > > Ted > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From cliffb at cjbsys.bdb.com Tue Aug 26 17:33:32 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Tue, 26 Aug 2008 17:33:32 -0400 (EDT) Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: <48B45FEB.2090406@sprunk.org> from "Stephen Sprunk" at Aug 26, 2008 02:56:27 PM Message-ID: <200808262133.m7QLXWlA019138@cjbsys.bdb.com> Stephen Sprunk wrote ........ deleted.... > What the folks on this list, or the folks who built the Internet, think > and what their employers' or ex-employers' managements and/or legal > counsel are willing to do may be (and often are) wildly divergent. > Discussion here of the LRSA is interesting but not productive; ARIN's > counsel is the one that drafted it and is getting feedback from > potential signers about possible problems. PPML is not, and IMHO should > not be, involved in that cycle. For some of us legacy address holders who are the entire company (i.e. no corporate or any other lawyer) and given that people keep proposing policies that require us to sign the LRSA, I think it is most appropriate to discuss what we see as problems with the LRSA and even propose alternatives. (Although I haven't seen much in the way of comments on my Alternative LRSA) And by the way, I don't lay any claim to being one of the people who built the Internet, I just had some good advice about getting addresses early. Cliff > > S > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From sleibrand at internap.com Tue Aug 26 17:29:13 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 26 Aug 2008 14:29:13 -0700 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency Transfer Policy forIPv4 Addresses In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9022150DA@SUEXCL-02.ad.syr.edu> References: <48B3FBFC.7070307@arin.net> <7663C7E01D8E094989CA62F0B0D21CD9022150DA@SUEXCL-02.ad.syr.edu> Message-ID: <48B475A9.70107@internap.com> I think I can answer #1: Bill proposed 2008-6 as an alternative to 2008-2, so that in case 2008-2 fails to reach consensus, we have a bare-bones alternative on the docket at L.A. that could be advanced if there's consensus for something simpler. My own hope is that we'll discuss both a revised 2008-2 (based on survey results and further discussion here) and 2008-6 at L.A., make any remaining minor edits to 2008-2 to bring it in line with consensus (perhaps revising it to be more like 2008-6 on some points), and hopefully have the consensus to adopt 2008-2 at that point. I guess we'll see if we can develop that level of consensus around the issue or not. I'll let Bill respond regarding the specifics of his proposal. -Scott Milton L Mueller wrote: > I am having trouble understanding this proposal and seek clarification. > > 1. How does this "emergency" transfer proposal relate to Policy Proposal > 2008-2, the other transfer policy proposal? Is it considered a > supplement to that proposal or a substitute for it? > > 2. How does one engage in a transfer "without the active involvement of > ARIN as an intermediary" when the recipient of the transfer must > "document operational need in accordance with current ARIN policy" and > sign an RSA "covering those resources in advance of transfer"? > > Milton Mueller > Professor, Syracuse University School of Information Studies > XS4All Professor, Delft University of Technology > ------------------------------ > Internet Governance Project: > http://internetgovernance.org > > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net >> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services >> Sent: Tuesday, August 26, 2008 8:50 AM >> To: ppml at arin.net >> Subject: [arin-ppml] Policy Proposal 2008-6: Emergency >> Transfer Policy forIPv4 Addresses >> >> On 21 August 2008, the ARIN Advisory Council (AC) concluded its review >> of "Emergency Transfer Policy for IPv4 Addresses" and accepted it as a >> formal policy proposal for discussion by the community. >> >> The proposal is designated Policy Proposal 2008-6: Emergency Transfer >> Policy for IPv4 Addresses. The proposal text is below and can >> be found at: >> http://www.arin.net/policy/proposals/2008_6.html >> >> All persons in the community are encouraged to discuss Policy Proposal >> 2008-6 prior to it being presented at the ARIN XXII Public Policy >> Meeting. Both the discussion on the Public Policy Mailing List >> and at the Public Policy Meeting will be used to determine >> the community >> consensus regarding this policy proposal. >> >> AC shepherds for this proposal are Owen DeLong and Stacy Hughes. >> >> The ARIN Internet Resource Policy Evaluation Process can be found at: >> http://www.arin.net/policy/irpep.html >> >> ARIN's Policy Proposal Archive can be found at: >> http://www.arin.net/policy/proposals/proposal_archive.html >> >> Regards, >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Policy Proposal 2008-6 >> Emergency Transfer Policy for IPv4 Addresses >> >> Author: Bill Darte >> >> Proposal Version: 1.0 >> >> Submission Date: August 15, 2008 >> >> Proposal type: New >> >> Policy term: Temporary >> >> Policy statement: >> >> 8.2.1 Emergency Transfer Policy for IPv4 Addresses >> >> For a period of 3 years from policy implementation, transfer of ARIN >> IPv4 addresses between two entities in the ARIN region, without the >> active involvement of ARIN as an intermediary, will be considered >> legitimate and will be documented accordingly under the following >> conditions: >> >> 1. Transfer takes place from a holder of IPv4 addresses recognized by >> ARIN as the legitimate and exclusive holder of those resources. >> >> 2. Transfer takes place to a recipient that has documented >> operational >> need in accordance with current ARIN policy and that signs an RSA with >> ARIN covering those resources in advance of transfer. >> >> 3. Transfer of addresses takes place in such a way that the original >> contiguous block(s) are not disaggregated into more than 4 resultant >> network blocks each being greater than or equal to the current minimum >> sizes specified in applicable ARIN policy. >> >> 4. Transfer is complete and unrestricted and is supported by >> documentation that ARIN deems satisfactory. >> >> >> Rationale: >> >> In order for ARIN to fulfill its mission and to facilitate a >> continuing >> supply of IPv4 address resources to its service community when ARIN >> resources are no longer adequate, and to preserve the integrity of >> documentation and ARIN services for those resources, this >> policy may be >> implemented. Its intent is to preserve the current tradition of >> need-based allocation/assignments for those still needing >> IPv4 resources >> during a transition period as the industry adopts IPv6. This policy is >> not intended to create a 'market' for such transfers and does not >> introduce or condone the monetization of address resources or >> a view of >> addresses as property. It does recognize that organizations making >> available unused or no longer needed address resources may >> incur certain >> costs that might be compensated by those acquiring the >> resources. This >> policy is intended to be transient and light-weight and does not >> encourage a sustained or continuing role for IPv4, but rather helps to >> mitigate a transitional crisis that may emerge while the >> industry adopts >> IPv6 in accordance with the recommendation of ARIN's Board of >> Trustees. >> >> Timetable for implementation: >> >> This policy, once ratified by the ARIN Board of Trustees, would be >> implemented when either the free-pool of IANA addresses is >> exhausted or >> IPv4 address resources in the ARIN Region reaches a threshold of >> scarcity recognized by the ARIN Board of Trustees as requiring this >> policy implementation. >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From alain_durand at cable.comcast.com Tue Aug 26 17:41:50 2008 From: alain_durand at cable.comcast.com (Alain Durand) Date: Tue, 26 Aug 2008 17:41:50 -0400 Subject: [arin-ppml] Results of Transfer Proposal Survey In-Reply-To: Message-ID: I'm still not convinced we need a liberalized transfer policy at all... And I'm also not convinced that such a policy would be sufficient to address the problem at hand, ie scaling the Internet after IANA completion. - Alain. On 8/26/08 4:59 PM, "Bill Darte" wrote: > No-one had to answer any question...therefore the could have skipped to > the bottom and said NO.... > > but....to ask the question.... > > All those against a liberalized transfer policy of any kind...please > reply saying so... > > Bill Darte > ARIN AC > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net >> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt >> Sent: Tuesday, August 26, 2008 1:55 PM >> To: 'Member Services'; arin-ppml at arin.net; arin-announce at arin.net >> Subject: Re: [arin-ppml] Results of Transfer Proposal Survey >> >> >> >>> -----Original Message----- >>> From: arin-ppml-bounces at arin.net >>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services >>> Sent: Tuesday, August 26, 2008 8:37 AM >>> To: arin-ppml at arin.net; arin-announce at arin.net >>> Subject: [arin-ppml] Results of Transfer Proposal Survey >>> >>> >>> Subscribers to the ARIN Public Policy Mailing List were invited to >>> participate last week in a policy proposal survey. The ARIN >> Advisory >>> Council, working on an update to Policy Proposal 2008-2, >> IPv4 Transfer >>> Policy Proposal, sponsored the survey in order to gain additional >>> input. >>> >>> Two hundred plus subscribers to the mail list participated. >>> The results >>> of the survey are available on the ARIN website at: >>> http://www.arin.net/policy/proposals/surveys/ >>> and in pdf version at: >>> http://www.arin.net/policy/proposals/surveys/pdfs/survey_summa >> ry_08242008.pdf >> >> >>> This input will be added to that gained during the ARIN XXI >> meeting in >>> Denver, the Caribbean sector meeting in Jamaica and the upcoming >>> Caribbean sector meeting in the Bahamas. Additional >> discussion of the >>> proposal will take place at the ARIN XXII Public Policy and Members >>> Meeting being held 15-17 October in Los Angeles, California. >> >>> Please note that the Advisory Council continues to seek >> input on this >>> issue. >> >> This survey was biased from the beginning - it omitted one >> key question at the beginning: Do you want a liberalized >> transfer policy at all? That is why the number of persons >> responding from the PPL was so small - 11% - because if you >> were opposed a liberalized policy, you could see where the >> survey was going and undoubtedly most people opposed to a >> liberalized policy abandoned the survey before completion. >> >> It's actually much more significant that question 11 had a >> 13% NO response! Since the survey was SO biased, it's >> amazing that that many people opposed to a liberalized policy >> actually made it through the survey at all! >> >> Where the usefulness of this survey is, though, is in telling >> us WHO is making up the pro-liberalization camp. >> >> The significant responses are as follows: >> >> Question 11: 86% in favor. OK well we already knew that >> because very few people opposing liberalized transfers would >> be completing the survey after getting to this question. >> >> Question 10: 80% in favor. What this tells us is that those >> in favor of liberalization want the "RIR stamp of approval" >> on their transaction. One more, this is a no-brainer; it >> should have been obvious prior to the survey that people >> calling for a "legacy number broker" separate from the RIR >> were the fringe element. >> >> Neither 11 or 10 tell us anything we don't already know and >> are more distractor questions than anything else. >> >> Question 9: 53% in favor of limiting multiple requests, 47% >> against. This is where it gets interesting - what this is >> telling us is that the pro-liberalized transfer camp is >> itself split over the idea of allowing freewheeling-and-dealing of >> IPv4 numbers. >> >> Question 8: 58% for current holders being allowed limited >> deaggregation, the rest want no limits. This is also >> indicative of that split in the pro-liberalized transfer camp. >> What it is telling us is HOW each camp wants things to proceed. >> >> The pro-wheeling-and-dealing camp are speculators - their aim >> is to make a lot of money brokering large blocks, splitting >> them up, and selling them. Any kind of restrictions would >> crimp their plans. But they are in the minority. The bulk >> of the pro-liberalized transfer folks are just wanting to >> make money off holdings that they have, but aren't using, or >> have but could easily give up by renumbering. They want >> limited deaggregation because that is all they need - and >> since they are planning on staying in the game long-haul, >> they don't want to screw themselves by allowing unlimited >> growth of routing entries in the BGP table. >> >> Question 7: 74% in favor of ARIN having control over limiting >> deaggregation. Once more, a no-brainer. These are the same >> folks who want ARIN's blessing in Question #10. Why would >> you be in favor of having ARIN operating a listing service >> but not giving them control over the stuff listed on it? >> That's why the % split on this question was within a few >> points of the split on #10 >> >> Question 6: 71% in favor of prequals on need. No brainer here. >> This is basically a restatement of the idea in #7 and #10 - >> give ARIN control. >> >> Question 5: Nearly even split on prequals of address holders >> wanting to sell space. This basically indicates the level of >> discomfort of the pro-liberalization camp who are NOT >> speculators. Obviously if you're a speculator then you don't >> care where the IPv4 is coming from, whether the holder meets >> prequal or not. The only people who would care are the ones >> who are pro-liberalization only for the reason that they want >> to see more space freed up, or perhaps sell off some of their >> own holdings. The majority of -those- people are not happy >> with the idea of allowing un-prequalified people out there >> selling off IPv4. >> >> Question 4: Uninteresting question - nobody cares what >> happens after the deal is done. >> >> Question 3: This is like Question 9 and 8 - it merely shows >> the split in the pro-liberalization camp, but it does >> indicate the bulk of the speculators are coming from the >> legacy arena because obviously if legacy holders didn't make >> up a large number of survey respondents, they wouldn't care >> if the legacy holders were shafted by an LRSA and the >> response would throw the legacy holders under the bus by a >> stronger majority voting yes. >> >> Question 2: No brainer, basically a restatement of question #11 >> >> Question 1: Expiration date. This is like 9, 8 and 3. It >> shows the split in the pro-liberalization camp. Obviously, >> speculators aren't going to want an expiration date of the >> liberalized policy. But the non-speculators in favor of a >> liberalized policy are more evenly split on the idea of an >> expiration date. >> >> In summary, while the survey illustrated the internal split >> within the pro-liberalization camp, it still doesen't tell us >> what is really important - how many people really are in >> favor of a liberalized policy. It in no way indicates that >> there is a majority of people in favor of a liberalized >> transfer policy. >> >> A more even-handed and unbiased survey would have been more useful. >> >> Ted >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From BillD at cait.wustl.edu Tue Aug 26 17:49:17 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Tue, 26 Aug 2008 16:49:17 -0500 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency Transfer PolicyforIPv4 Addresses In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9022150DA@SUEXCL-02.ad.syr.edu> References: <48B3FBFC.7070307@arin.net> <7663C7E01D8E094989CA62F0B0D21CD9022150DA@SUEXCL-02.ad.syr.edu> Message-ID: #1....substitute for 2008-2....as Scott Leibrand said elsewhere... if a liberalized transfer policy is the will of the community, but consensus cannot be reached over details encompassed by 2008-2 then this "bare-bones" policy might suffice to get started down that path. #2....the intent is that the transfer takes place between the holder and the entity acquiring and the details of the transfer do not involve ARIN as an intermediary there. But, in order for ARIN to document the transfer within Whois, etc. and to establish that the entity receiving the transfer has need, the RSA must be established in advance. bd > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller > Sent: Tuesday, August 26, 2008 2:33 PM > To: Member Services; ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal 2008-6: Emergency > Transfer PolicyforIPv4 Addresses > > > I am having trouble understanding this proposal and seek > clarification. > > 1. How does this "emergency" transfer proposal relate to > Policy Proposal 2008-2, the other transfer policy proposal? > Is it considered a supplement to that proposal or a substitute for it? > > 2. How does one engage in a transfer "without the active > involvement of ARIN as an intermediary" when the recipient of > the transfer must "document operational need in accordance > with current ARIN policy" and sign an RSA "covering those > resources in advance of transfer"? > > Milton Mueller > Professor, Syracuse University School of Information Studies > XS4All Professor, Delft University of Technology > ------------------------------ > Internet Governance Project: > http://internetgovernance.org > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > > Sent: Tuesday, August 26, 2008 8:50 AM > > To: ppml at arin.net > > Subject: [arin-ppml] Policy Proposal 2008-6: Emergency > Transfer Policy > > forIPv4 Addresses > > > > On 21 August 2008, the ARIN Advisory Council (AC) concluded > its review > > of "Emergency Transfer Policy for IPv4 Addresses" and > accepted it as a > > formal policy proposal for discussion by the community. > > > > The proposal is designated Policy Proposal 2008-6: > Emergency Transfer > > Policy for IPv4 Addresses. The proposal text is below and > can be found > > at: > > http://www.arin.net/policy/proposals/2008_6.html > > > > All persons in the community are encouraged to discuss > Policy Proposal > > 2008-6 prior to it being presented at the ARIN XXII Public Policy > > Meeting. Both the discussion on the Public Policy Mailing > List and at > > the Public Policy Meeting will be used to determine the community > > consensus regarding this policy proposal. > > > > AC shepherds for this proposal are Owen DeLong and Stacy Hughes. > > > > The ARIN Internet Resource Policy Evaluation Process can be > found at: > > http://www.arin.net/policy/irpep.html > > > > ARIN's Policy Proposal Archive can be found at: > > http://www.arin.net/policy/proposals/proposal_archive.html > > > > Regards, > > > > Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > ## * ## > > > > > > Policy Proposal 2008-6 > > Emergency Transfer Policy for IPv4 Addresses > > > > Author: Bill Darte > > > > Proposal Version: 1.0 > > > > Submission Date: August 15, 2008 > > > > Proposal type: New > > > > Policy term: Temporary > > > > Policy statement: > > > > 8.2.1 Emergency Transfer Policy for IPv4 Addresses > > > > For a period of 3 years from policy implementation, transfer of ARIN > > IPv4 addresses between two entities in the ARIN region, without the > > active involvement of ARIN as an intermediary, will be considered > > legitimate and will be documented accordingly under the following > > conditions: > > > > 1. Transfer takes place from a holder of IPv4 addresses > recognized by > > ARIN as the legitimate and exclusive holder of those resources. > > > > 2. Transfer takes place to a recipient that has documented > > operational need in accordance with current ARIN policy and > that signs > > an RSA with ARIN covering those resources in advance of transfer. > > > > 3. Transfer of addresses takes place in such a way that > the original > > contiguous block(s) are not disaggregated into more than 4 > resultant > > network blocks each being greater than or equal to the > current minimum > > sizes specified in applicable ARIN policy. > > > > 4. Transfer is complete and unrestricted and is supported by > > documentation that ARIN deems satisfactory. > > > > > > Rationale: > > > > In order for ARIN to fulfill its mission and to facilitate a > > continuing supply of IPv4 address resources to its service > community > > when ARIN resources are no longer adequate, and to preserve the > > integrity of documentation and ARIN services for those > resources, this > > policy may be implemented. Its intent is to preserve the current > > tradition of need-based allocation/assignments for those > still needing > > IPv4 resources > > during a transition period as the industry adopts IPv6. > This policy is > > not intended to create a 'market' for such transfers and does not > > introduce or condone the monetization of address resources > or a view > > of addresses as property. It does recognize that > organizations making > > available unused or no longer needed address resources may incur > > certain costs that might be compensated by those acquiring the > > resources. This policy is intended to be transient and > light-weight > > and does not encourage a sustained or continuing role for IPv4, but > > rather helps to mitigate a transitional crisis that may > emerge while > > the industry adopts > > IPv6 in accordance with the recommendation of ARIN's Board of > > Trustees. > > > > Timetable for implementation: > > > > This policy, once ratified by the ARIN Board of Trustees, would be > > implemented when either the free-pool of IANA addresses is > exhausted > > or > > IPv4 address resources in the ARIN Region reaches a threshold of > > scarcity recognized by the ARIN Board of Trustees as > requiring this > > policy implementation. > > > > > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed > to the ARIN > > Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From oberman at es.net Tue Aug 26 19:50:15 2008 From: oberman at es.net (Kevin Oberman) Date: Tue, 26 Aug 2008 16:50:15 -0700 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: Your message of "Tue, 26 Aug 2008 14:56:27 CDT." <48B45FEB.2090406@sprunk.org> Message-ID: <20080826235015.02CED4500F@ptavv.es.net> > Date: Tue, 26 Aug 2008 14:56:27 -0500 > From: Stephen Sprunk > Sender: arin-ppml-bounces at arin.net > > Jo Rhett wrote: > > On Aug 22, 2008, at 5:44 PM, Randy Bush wrote: > > > >>> I suspect the half of the towns people who set decent rules and > >>> tried to preserve the commons will be relatively unsympathetic at > >>> that point in time that those who have avoided participating in > >>> society and openly mocked them are now receiving their just rewards. > >>> > >> kiddies, get a clue. many folk with legacy space were building the > >> internet while you were still in nappies. we think it is you who are > >> pissing on the commons. > >> > > > > I don't disagree. But I don't think that ARIN should spend time/ > > resources trying to help people who aren't paying members. Basic > > conservative approach. > > > > That logic assumes it's the registrant who gets the benefit of the free > service, while in fact the registrant gets little to no benefit. They > already know who they are and what they have. The benefit of WHOIS is > to let _others_ know who they are and what they have, and the majority > of those "others" are the ones paying the bill and to whom the benefit > actually accrues. If anything, we should be thanking the few legacy > folks that do keep their information up to date, since they have no > obligation nor much incentive to do so. Putting more obstacles in their > path just means fewer will bother with the hassle, and the commons will > suffer. Thanks you, Stephen! Someone finally stated the obvious. A complete registry is of benefit to everyone. (I think that this is probably "the commons" to which Randy was referring.) Rest assured that the $100 is not an issue keeping most legacy holders from signing the LRSA. > > > It's not like any of these individuals (who are still alive and > > frankly are mostly active in ARIN today) are unaware of ARIN or that > > the legacy RSA exists > > What the folks on this list, or the folks who built the Internet, think > and what their employers' or ex-employers' managements and/or legal > counsel are willing to do may be (and often are) wildly divergent. > Discussion here of the LRSA is interesting but not productive; ARIN's > counsel is the one that drafted it and is getting feedback from > potential signers about possible problems. PPML is not, and IMHO should > not be, involved in that cycle. A very valid point. Our customers almost all hold legacy space, some using it well and others not so well. If they get their space from us, we mandate that they comply with ARIN rules for utilization even though our assignments are from legacy space. I know that several have been told that under applicable laws in their states, they simply cannot sign the LRSA. I mean as in "It would be a criminal offense to do so". I am not a lawyer, so I won't comment as the the validity of the lawyer's issues, but, working for an organization that must meet both Federal Government and State of California purchasing requirements, I suspect that the opinions are correct. We have had long battle with very standard contract clauses that we can't sign. There is a reason Switch and Data refuses to deal with anyone contracting under GSA procurement rules. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available URL: From randy at psg.com Tue Aug 26 20:22:32 2008 From: randy at psg.com (Randy Bush) Date: Wed, 27 Aug 2008 12:22:32 +1200 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: <20080826235015.02CED4500F@ptavv.es.net> References: <20080826235015.02CED4500F@ptavv.es.net> Message-ID: <48B49E48.4040905@psg.com> > Thanks you, Stephen! Someone finally stated the obvious. A complete > registry is of benefit to everyone. (I think that this is probably > "the commons" to which Randy was referring.) there is a saying "s/he works for the internet." > Rest assured that the $100 is not an issue keeping most legacy > holders from signing the LRSA. socio-political clue plus you are a good unix hacker. wowza! :) randy From jcurran at istaff.org Tue Aug 26 22:19:22 2008 From: jcurran at istaff.org (John Curran) Date: Tue, 26 Aug 2008 22:19:22 -0400 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: <20080826235015.02CED4500F@ptavv.es.net> References: <20080826235015.02CED4500F@ptavv.es.net> Message-ID: <84CB3115-5C87-46FC-8303-17CA29AA343B@istaff.org> On Aug 26, 2008, at 7:50 PM, Kevin Oberman wrote: > >> Date: Tue, 26 Aug 2008 14:56:27 -0500 >> From: Stephen Sprunk >> . If anything, we should be thanking the few legacy >> folks that do keep their information up to date, since they have no >> obligation nor much incentive to do so. Putting more obstacles in >> their >> path just means fewer will bother with the hassle, and the commons >> will >> suffer. > > Thanks you, Stephen! Someone finally stated the obvious. A complete > registry is of benefit to everyone. (I think that this is probably > "the > commons" to which Randy was referring.) Yes, it appears that Randy wasn't seeking special rights for legacy holders per se, only trying to protect the usefulness of a complete registry by arguing against new (and what might seem to be arbitrary) requirements on legacy holder record updates. /John From randy at psg.com Tue Aug 26 22:29:03 2008 From: randy at psg.com (Randy Bush) Date: Wed, 27 Aug 2008 14:29:03 +1200 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: <84CB3115-5C87-46FC-8303-17CA29AA343B@istaff.org> References: <20080826235015.02CED4500F@ptavv.es.net> <84CB3115-5C87-46FC-8303-17CA29AA343B@istaff.org> Message-ID: <48B4BBEF.5070609@psg.com> > Yes, it appears that Randy wasn't seeking special rights for legacy > holders per se, only trying to protect the usefulness of a complete > registry by arguing against new (and what might seem to be arbitrary) > requirements on legacy holder record updates. while i do not disagree with that argument, all i was actually taking issue with was the assertion that legacy holders were damaging the commons. it was just another sad case of "legacy holders are evil. have you now or have you ever been, ..." an echo of arin's lawyer at nanog, techo- macarthyism . i am a holder of legacy address space. i am neither proud nor ashamed of it; it's just an artifact of history. those who know me know that i would be extremely glad to be 20-30 years younger. randy From bmanning at vacation.karoshi.com Wed Aug 27 00:02:11 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 27 Aug 2008 04:02:11 +0000 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9011DCA72@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD901E0E386@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0E3BA@SUEXCL-02.ad.syr.edu> <20080825170038.GA8825@vacation.karoshi.com.> <7663C7E01D8E094989CA62F0B0D21CD9011DCA72@SUEXCL-02.ad.syr.edu> Message-ID: <20080827040211.GA29120@vacation.karoshi.com.> On Mon, Aug 25, 2008 at 04:25:36PM -0400, Milton L Mueller wrote: > > > -----Original Message----- > > From: bmanning at vacation.karoshi.com > > > > If you want to understand what I am trying to tell you, stop thinking > like a techie and start thinking like a policy person. I don't need or > want to predict the precise uses and adaptations that operators will > take. I do want to make sure that those decisions are based on an > accurate assessment of the relative cost of the alternatives. well Milton, reciprocity is a good thing. I'll start thinking like a policy person if you start thinking like a techie. if you can't gauge the costs properly (by using your techie googles), then your assessments's can't be accurate. > > > in a nutshell - a possible strategy is to repurpose IPv4. > > As a prognostication I find that plausible. > > But who makes the decision to repurpose? Operators or RIRs? Referring to > my just-sent reply to Tom Vest, the issue is not whether a transition is > needed, but where that decision is located and what role the RIRs play > in facilitating it. I'm simply suggesting that given a scarce, legacy > resource that everyone now needs, and an abundant, next-gen resource the > utility of which depends on a massive migration across two incompatible > standards, RIRs need to adopt policies that provide accurate price > signals and which facilitate shifting the remaining ipv4 resources to > their highest and best uses. I'm also suggesting that they refrain from > exploiting their leverage over both resource pools to impose a top-down > transition plan on operators. > the RIR's are the operators (and others) who participate.... even techies and policy wonks. --bill From arin-ppml at westbrook.com Wed Aug 27 01:38:23 2008 From: arin-ppml at westbrook.com (Eric Westbrook) Date: Wed, 27 Aug 2008 13:38:23 +0800 Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation In-Reply-To: <443de7ad0808261325t2e7cc206r1dbc1543e30f7aff@mail.gmail.com> References: <480dad640808260822k7a0c8f82qe071752fd3407597@mail.gmail.com> <569365D40C954C729E8847F7FC88A0A5@tedsdesk> <6905ba860808261132i56cbcf63t93b447d8c369aee6@mail.gmail.com> <443de7ad0808261325t2e7cc206r1dbc1543e30f7aff@mail.gmail.com> Message-ID: <6905ba860808262238w392b2866m7f8af6f35231a85f@mail.gmail.com> On Wed, Aug 27, 2008 at 4:25 AM, Chris Grundemann wrote: > Agreed. Although I did not add it to the proposal, I believe that > ARIN staff would want to do the verification on a set date every year > and make some sort of announcement every year before the verification, > to try and help POCs be prepared to receive and respond to the > verification email. Also, the same sender address should always be > used, to allow whitelisting. Do you believe that this should be > specified in the proposal? > ~Chris Sure. Expected transmission dates as well as sender addresses would be good things to make known to potential recipients. Publishing them by email would probably be a dubious mechanism, since we're trying to mitigate the non-receipt of email in the first place. But the more paths for broadcast, the better, I suppose. Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From arin-ppml at westbrook.com Wed Aug 27 01:44:57 2008 From: arin-ppml at westbrook.com (Eric Westbrook) Date: Wed, 27 Aug 2008 13:44:57 +0800 Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation In-Reply-To: <6905ba860808262238w392b2866m7f8af6f35231a85f@mail.gmail.com> References: <480dad640808260822k7a0c8f82qe071752fd3407597@mail.gmail.com> <569365D40C954C729E8847F7FC88A0A5@tedsdesk> <6905ba860808261132i56cbcf63t93b447d8c369aee6@mail.gmail.com> <443de7ad0808261325t2e7cc206r1dbc1543e30f7aff@mail.gmail.com> <6905ba860808262238w392b2866m7f8af6f35231a85f@mail.gmail.com> Message-ID: <6905ba860808262244u6f2d6465l1a4619c868b3f969@mail.gmail.com> Following on a bit more on this little detail: Perhaps the proposal should just state something to the effect of "expected transmission dates and sender email addresses will be published as widely and be as readily available as is reasonable and practical." That would make the point that it needs to be done, and leave the implementation details to whomever actually assumes responsibility for it. Is that workable? Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleibrand at internap.com Wed Aug 27 02:08:40 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 26 Aug 2008 23:08:40 -0700 Subject: [arin-ppml] Results of Transfer Proposal Survey In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9022150D9@SUEXCL-02.ad.syr.edu> References: <48B42317.5070108@arin.net> <723083FF30894BF28532E39AC06E7859@tedsdesk> <7663C7E01D8E094989CA62F0B0D21CD9022150D9@SUEXCL-02.ad.syr.edu> Message-ID: <48B4EF68.8000602@internap.com> Milton, You write: > We confess that we are unsure what it means to ?pre-qualify? a seller. > It seems self-evident that in an environment of increasing IPv4 address > scarcity, any organization wants to give up their addresses to a willing > buyer should be encouraged to do so. If ?pre-qualification? simply means > that sellers must show that they are actually the legitimate holder of > address resources they are selling, then it is a good idea, but it would > be better to call it ?authentication.? The intent behind the question was that pre-qualification on the transferor side would consist of authentication, plus (assuming there is a consensus for it as hinted in the responses to #3) some sort of contractual agreement, such as an RSA or LRSA, concerning the addresses. Having such a contract in place backs the authentication process up with some legal teeth, and increases everyone's confidence in the authenticity of the relationship between the addresses and the organization offering them for transfer. Similarly, pre-qualification requires that the organization goes through that process before they list the space for transfer on a listing service (or eBay), so that potential recipients know that the person offering to transfer the space has a legitimate right to do so. -Scott Milton L Mueller wrote: > An assessment of the ARIN survey is up at the IGP blog. > http://blog.internetgovernance.org/blog/_archives/2008/8/26/3856632.html > > Milton Mueller > Professor, Syracuse University School of Information Studies > XS4All Professor, Delft University of Technology > ------------------------------ > Internet Governance Project: > http://internetgovernance.org > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From michael.dillon at bt.com Wed Aug 27 03:49:07 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 27 Aug 2008 08:49:07 +0100 Subject: [arin-ppml] Results of Transfer Proposal Survey In-Reply-To: Message-ID: > No-one had to answer any question...therefore the could have > skipped to the bottom and said NO.... It is quite common in surveys to ask more or less the same question two times using different wording. It would not have been amiss to start the survey with: Do you support any kind of transfer policy? > All those against a liberalized transfer policy of any > kind...please reply saying so... I am against any kind of liberalized transfer policy. --Michael Dillon From pauldotwall at gmail.com Wed Aug 27 03:54:59 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Wed, 27 Aug 2008 03:54:59 -0400 Subject: [arin-ppml] Results of Transfer Proposal Survey In-Reply-To: References: Message-ID: <620fd17c0808270054t173a6287l4d42f381f9741d1b@mail.gmail.com> Liberalized transfer is going to happen whether we like it or not. One need not look futher than ebay sales, webhostingtalk all-stars "buying" up swamp space under shady pretense, etc. I'd rather ARIN institute policy for it, so we can at least try and keep things on the up and up, than not. Drive Slow, Paul Wall On Wed, Aug 27, 2008 at 3:49 AM, wrote: >> No-one had to answer any question...therefore the could have >> skipped to the bottom and said NO.... > > It is quite common in surveys to ask more or less the same question two > times using different wording. It would not have been amiss to start the > survey with: > > Do you support any kind of transfer policy? > >> All those against a liberalized transfer policy of any >> kind...please reply saying so... > > I am against any kind of liberalized transfer policy. > > --Michael Dillon > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From michael.dillon at bt.com Wed Aug 27 03:55:27 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 27 Aug 2008 08:55:27 +0100 Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation In-Reply-To: <6905ba860808262238w392b2866m7f8af6f35231a85f@mail.gmail.com> Message-ID: > Agreed. Although I did not add it to the proposal, I > believe that > ARIN staff would want to do the verification on a set > date every year > and make some sort of announcement every year before > the verification, > to try and help POCs be prepared to receive and respond to the > verification email. Also, the same sender address > should always be > used, to allow whitelisting. Do you believe that this should be > specified in the proposal? > ~Chris > > > Sure. Expected transmission dates as well as sender > addresses would be good things to make known to potential > recipients. Publishing them by email would probably be a > dubious mechanism, since we're trying to mitigate the > non-receipt of email in the first place. But the more paths > for broadcast, the better, I suppose. > > Eric This discussion has now descended into the absurd. We are supposed to be discussing policy, not setting out ARIN's processes and working practices. This whole issue should be dealt with by one or more suggestions to the ARIN suggestion box. If ARIN would add a "last contacted date" to the whois database, and begin a process of contacting all orgs that have not been contacted in over a year, this whole issue would go away. --Michael Dillon From heldal at eml.cc Wed Aug 27 06:09:35 2008 From: heldal at eml.cc (Per Heldal) Date: Wed, 27 Aug 2008 12:09:35 +0200 Subject: [arin-ppml] Results of Transfer Proposal Survey In-Reply-To: <620fd17c0808270054t173a6287l4d42f381f9741d1b@mail.gmail.com> References: <620fd17c0808270054t173a6287l4d42f381f9741d1b@mail.gmail.com> Message-ID: <1219831775.9775.36.camel@obelix.sandbu> On Wed, 2008-08-27 at 03:54 -0400, Paul Wall wrote: > Liberalized transfer is going to happen whether we like it or not. That depends on the definition of "we". _If_ transit operators don't approve they only need participation from a handful of big networks to render black/grey-market address-blocks useless. "We", as in everybody else, can do little but watch should that happen. > > One need not look futher than ebay sales, webhostingtalk all-stars > "buying" up swamp space under shady pretense, etc. Some people are willing to trade just about anything for a profit. That doesn't mean that every form of profitable transaction must be permitted. //per From BillD at cait.wustl.edu Wed Aug 27 06:18:05 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Wed, 27 Aug 2008 05:18:05 -0500 Subject: [arin-ppml] Results of Transfer Proposal Survey References: <620fd17c0808270054t173a6287l4d42f381f9741d1b@mail.gmail.com> <1219831775.9775.36.camel@obelix.sandbu> Message-ID: Like the NFO...national farmer's union...you have tremendous power. Governance, address policy, etc...all these things are within your sphere of influence... and yet, you are a group of individual entities that are driven to maximize your individual profit. So, no cartel are ISPs, to decide which numbers are routed and which are not...I think. bd -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of Per Heldal On Wed, 2008-08-27 at 03:54 -0400, Paul Wall wrote: > Liberalized transfer is going to happen whether we like it or not. That depends on the definition of "we". _If_ transit operators don't approve they only need participation from a handful of big networks to render black/grey-market address-blocks useless. "We", as in everybody else, can do little but watch should that happen. > > One need not look futher than ebay sales, webhostingtalk all-stars > "buying" up swamp space under shady pretense, etc. Some people are willing to trade just about anything for a profit. That doesn't mean that every form of profitable transaction must be permitted. //per _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Wed Aug 27 07:43:06 2008 From: info at arin.net (Member Services) Date: Wed, 27 Aug 2008 07:43:06 -0400 Subject: [arin-ppml] Legacy RSA signers In-Reply-To: <200808222116.m7MLG2XM025250@cjbsys.bdb.com> References: <200808222116.m7MLG2XM025250@cjbsys.bdb.com> Message-ID: <48B53DCA.2060108@arin.net> Hi Cliff- Answers are provided below to the questions you posted to ppml. You asked: "How many of the signers came in from the cold and did not have a separate RSA with ARIN?" Of the 129 Organization IDs that have signed the Legacy RSA to date, 66 of them have a separate standard RSA signed with ARIN. You asked: I'm curious how many of the signers came from the outreach program started last year. Although we can't say for certain that a Legacy RSA was signed as a direct result of the outreach program ARIN began in December 2007, we can provide the following statistics: Prior to the beginning of ARIN's outreach efforts in December 2007, 25 Legacy RSA applications had been received in total, and three of them had been completed and signed. ARIN began its outreach efforts by sending letters to legacy Class A registrants in December 2007. Since that date, two Class A registrants have signed the Legacy RSA. ARIN began sending letters to the legacy Class B registrants in early March 2008. Since that date, 72 Class B registrants have signed the Legacy RSA. ARIN will begin its outreach efforts to legacy Class C registrants within the next week. As a side note, there are currently 166 pending Legacy RSA applications in progress. Fifty-three of these have been approved and are awaiting final paperwork. Regards, Leslie Nobile Director, Registration Services American Registry for Internet Numbers Cliff Bedore wrote: > I've been madly reading to catch up on the backlog of PPML messages in my > inbox and don't have the email at hand that gave the answer about how many > legacy number holders have signed the LRSA. A more interesting question might > be "How many of the signers came in from the cold and did not have a separate > RSA with ARIN?" I.e. Paul Vixie signed but it appears that he had a separate > RSA with ARIN for non-legacy numbers. (If not true Paul please correct this.) > I'm curious how many of the signers came from the outreach program started > last year. > > Cliff > > From mueller at syr.edu Wed Aug 27 09:59:15 2008 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 27 Aug 2008 09:59:15 -0400 Subject: [arin-ppml] Results of Transfer Proposal Survey In-Reply-To: <48B4EF68.8000602@internap.com> References: <48B42317.5070108@arin.net> <723083FF30894BF28532E39AC06E7859@tedsdesk> <7663C7E01D8E094989CA62F0B0D21CD9022150D9@SUEXCL-02.ad.syr.edu> <48B4EF68.8000602@internap.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9022150E5@SUEXCL-02.ad.syr.edu> Scott, thanks for clearing that up. I wonder whether the 50-50 response to that question reflected in part the ambiguity of the meaning. Anyway, as you probably know I think the full-fledged pre-qualification you suggest is a bit too much bureaucracy -- but a liberalized address transfer policy with such a requirement is better than none at all. My only quibble with an otherwise very useful and important survey is that it was probably a mistake to bundle a question about seller authentication with a question about sellers signing a LRSA. If legacy holders want to get rid of addresses they are not using, short of good authentication ARIN shouldn't put any barriers at all in their way. A stubborn insistence on pushing legacy holders into contracts seems utterly pointless to me when the _recipient_ of the transferred addresses will of necessity be incorporated into the contractual regime, and so over time nearly all v4 address holders will come in. And I can't resist adding that I did not take the survey, got too busy during the period it was circulated, and am now quite amused by the people who did take the survey reasserting their opposition, as if this somehow increases their numbers. ;-) > -----Original Message----- > From: Scott Leibrand [mailto:sleibrand at internap.com] > > The intent behind the question was that pre-qualification on the > transferor side would consist of authentication, plus > (assuming there is a consensus for it as hinted in the responses > to #3) some sort of contractual agreement, such as an RSA or LRSA, concerning the > addresses. > Having such a contract in place backs the authentication > process up with > some legal teeth, and increases everyone's confidence in the > authenticity > of the relationship between the addresses and the > organization offering > them for transfer. Similarly, pre-qualification requires that the > organization goes through that process before they list the space for > transfer on a listing service (or eBay), so that potential > recipients know > that the person offering to transfer the space has a > legitimate right to > do so. > > -Scott > > Milton L Mueller wrote: > > An assessment of the ARIN survey is up at the IGP blog. > > > http://blog.internetgovernance.org/blog/_archives/2008/8/26/38 56632.html > > > > Milton Mueller > > Professor, Syracuse University School of Information Studies > > XS4All Professor, Delft University of Technology > > ------------------------------ > > Internet Governance Project: > > http://internetgovernance.org > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > From kkargel at polartel.com Wed Aug 27 10:01:25 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 27 Aug 2008 09:01:25 -0500 Subject: [arin-ppml] Results of Transfer Proposal Survey In-Reply-To: References: <48B42317.5070108@arin.net><723083FF30894BF28532E39AC06E7859@tedsdesk> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10A80@mail> I am strongly opposed to any form of free market trading of IP addresses. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Bill Darte Sent: Tuesday, August 26, 2008 4:00 PM To: Ted Mittelstaedt; Member Services; arin-ppml at arin.net; arin-announce at arin.net Subject: Re: [arin-ppml] Results of Transfer Proposal Survey No-one had to answer any question...therefore the could have skipped to the bottom and said NO.... but....to ask the question.... All those against a liberalized transfer policy of any kind...please reply saying so... Bill Darte ARIN AC > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt > Sent: Tuesday, August 26, 2008 1:55 PM > To: 'Member Services'; arin-ppml at arin.net; arin-announce at arin.net > Subject: Re: [arin-ppml] Results of Transfer Proposal Survey > > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > > Sent: Tuesday, August 26, 2008 8:37 AM > > To: arin-ppml at arin.net; arin-announce at arin.net > > Subject: [arin-ppml] Results of Transfer Proposal Survey > > > > > > Subscribers to the ARIN Public Policy Mailing List were invited to > > participate last week in a policy proposal survey. The ARIN > Advisory > > Council, working on an update to Policy Proposal 2008-2, > IPv4 Transfer > > Policy Proposal, sponsored the survey in order to gain additional > > input. > > > > Two hundred plus subscribers to the mail list participated. > > The results > > of the survey are available on the ARIN website at: > > http://www.arin.net/policy/proposals/surveys/ > > and in pdf version at: > > http://www.arin.net/policy/proposals/surveys/pdfs/survey_summa > ry_08242008.pdf > > > >This input will be added to that gained during the ARIN XXI > meeting in > >Denver, the Caribbean sector meeting in Jamaica and the upcoming > >Caribbean sector meeting in the Bahamas. Additional > discussion of the > >proposal will take place at the ARIN XXII Public Policy and Members > >Meeting being held 15-17 October in Los Angeles, California. > > >Please note that the Advisory Council continues to seek > input on this > >issue. > > This survey was biased from the beginning - it omitted one key > question at the beginning: Do you want a liberalized transfer policy > at all? That is why the number of persons responding from the PPL was > so small - 11% - because if you were opposed a liberalized policy, you > could see where the survey was going and undoubtedly most people > opposed to a liberalized policy abandoned the survey before > completion. > > It's actually much more significant that question 11 had a 13% NO > response! Since the survey was SO biased, it's amazing that that many > people opposed to a liberalized policy actually made it through the > survey at all! > > Where the usefulness of this survey is, though, is in telling us WHO > is making up the pro-liberalization camp. > > The significant responses are as follows: > > Question 11: 86% in favor. OK well we already knew that because very > few people opposing liberalized transfers would be completing the > survey after getting to this question. > > Question 10: 80% in favor. What this tells us is that those in favor > of liberalization want the "RIR stamp of approval" > on their transaction. One more, this is a no-brainer; it should have > been obvious prior to the survey that people calling for a "legacy > number broker" separate from the RIR were the fringe element. > > Neither 11 or 10 tell us anything we don't already know and are more > distractor questions than anything else. > > Question 9: 53% in favor of limiting multiple requests, 47% against. > This is where it gets interesting - what this is telling us is that > the pro-liberalized transfer camp is itself split over the idea of > allowing freewheeling-and-dealing of > IPv4 numbers. > > Question 8: 58% for current holders being allowed limited > deaggregation, the rest want no limits. This is also indicative of > that split in the pro-liberalized transfer camp. > What it is telling us is HOW each camp wants things to proceed. > > The pro-wheeling-and-dealing camp are speculators - their aim is to > make a lot of money brokering large blocks, splitting them up, and > selling them. Any kind of restrictions would crimp their plans. But > they are in the minority. The bulk of the pro-liberalized transfer > folks are just wanting to make money off holdings that they have, but > aren't using, or have but could easily give up by renumbering. They > want limited deaggregation because that is all they need - and since > they are planning on staying in the game long-haul, they don't want to > screw themselves by allowing unlimited growth of routing entries in > the BGP table. > > Question 7: 74% in favor of ARIN having control over limiting > deaggregation. Once more, a no-brainer. These are the same folks who > want ARIN's blessing in Question #10. Why would you be in favor of > having ARIN operating a listing service but not giving them control > over the stuff listed on it? > That's why the % split on this question was within a few points of the > split on #10 > > Question 6: 71% in favor of prequals on need. No brainer here. > This is basically a restatement of the idea in #7 and #10 - give ARIN > control. > > Question 5: Nearly even split on prequals of address holders wanting > to sell space. This basically indicates the level of discomfort of > the pro-liberalization camp who are NOT speculators. Obviously if > you're a speculator then you don't care where the IPv4 is coming from, > whether the holder meets prequal or not. The only people who would > care are the ones who are pro-liberalization only for the reason that > they want to see more space freed up, or perhaps sell off some of > their own holdings. The majority of -those- people are not happy with > the idea of allowing un-prequalified people out there selling off > IPv4. > > Question 4: Uninteresting question - nobody cares what happens after > the deal is done. > > Question 3: This is like Question 9 and 8 - it merely shows the split > in the pro-liberalization camp, but it does indicate the bulk of the > speculators are coming from the legacy arena because obviously if > legacy holders didn't make up a large number of survey respondents, > they wouldn't care if the legacy holders were shafted by an LRSA and > the response would throw the legacy holders under the bus by a > stronger majority voting yes. > > Question 2: No brainer, basically a restatement of question #11 > > Question 1: Expiration date. This is like 9, 8 and 3. It shows the > split in the pro-liberalization camp. Obviously, speculators aren't > going to want an expiration date of the liberalized policy. But the > non-speculators in favor of a liberalized policy are more evenly split > on the idea of an expiration date. > > In summary, while the survey illustrated the internal split within the > pro-liberalization camp, it still doesen't tell us what is really > important - how many people really are in favor of a liberalized > policy. It in no way indicates that there is a majority of people in > favor of a liberalized transfer policy. > > A more even-handed and unbiased survey would have been more useful. > > Ted > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3107 bytes Desc: not available URL: From bicknell at ufp.org Wed Aug 27 10:20:46 2008 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 27 Aug 2008 10:20:46 -0400 Subject: [arin-ppml] Results of Transfer Proposal Survey In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9022150E5@SUEXCL-02.ad.syr.edu> References: <48B42317.5070108@arin.net> <723083FF30894BF28532E39AC06E7859@tedsdesk> <7663C7E01D8E094989CA62F0B0D21CD9022150D9@SUEXCL-02.ad.syr.edu> <48B4EF68.8000602@internap.com> <7663C7E01D8E094989CA62F0B0D21CD9022150E5@SUEXCL-02.ad.syr.edu> Message-ID: <20080827142045.GA78975@ussenterprise.ufp.org> In a message written on Wed, Aug 27, 2008 at 09:59:15AM -0400, Milton L Mueller wrote: > authentication ARIN shouldn't put any barriers at all in their way. A > stubborn insistence on pushing legacy holders into contracts seems > utterly pointless to me when the _recipient_ of the transferred > addresses will of necessity be incorporated into the contractual regime, > and so over time nearly all v4 address holders will come in. The thought exercise here is what happens when things go bad. If ARIN has a contract with both parites that bind them to the ARIN policies then any dispute is relatively simple, both parties agreed to the same terms, conditions, and policies. If no contract between ARIN and the seller is required then any dispute will involve two contracts between three parties: Transferor---Contract A----Transferee----Contract B----ARIN (Where Contract B is probably always a standard RSA.) It's hard, but not impossible to imagine a situation where the two contracts place conflicting requirements on the transferee, something I hope the transferee's laywer would not let happen, but could. Please note I used contract, and not LRSA. The LRSA would fill the need here of binding people to the same policies, and so it's not inapprpriate to use it as the straw man, but other contracts (including the regular RSA) could do it as well. The counter argument is, if you're going to transfer away the block why would anyone care that they are signing the LRSA? They are going to be bound to it for a matter of minutes or hours until the transfer takes place. Indeed for small parties this may preclude them writing their own contract, thus saving time and money. They can simply say "we're both doing this per the terms of ARIN's transfer policy, for $x." -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- 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 Aug 27 10:29:34 2008 From: owen at delong.com (Owen DeLong) Date: Wed, 27 Aug 2008 07:29:34 -0700 Subject: [arin-ppml] Results of Transfer Proposal Survey In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9022150E5@SUEXCL-02.ad.syr.edu> References: <48B42317.5070108@arin.net> <723083FF30894BF28532E39AC06E7859@tedsdesk> <7663C7E01D8E094989CA62F0B0D21CD9022150D9@SUEXCL-02.ad.syr.edu> <48B4EF68.8000602@internap.com> <7663C7E01D8E094989CA62F0B0D21CD9022150E5@SUEXCL-02.ad.syr.edu> Message-ID: > My only quibble with an otherwise very useful and important survey is > that it was probably a mistake to bundle a question about seller > authentication with a question about sellers signing a LRSA. If legacy > holders want to get rid of addresses they are not using, short of good > authentication ARIN shouldn't put any barriers at all in their way. A > stubborn insistence on pushing legacy holders into contracts seems > utterly pointless to me when the _recipient_ of the transferred > addresses will of necessity be incorporated into the contractual > regime, > and so over time nearly all v4 address holders will come in. > Absent a contract with ARIN, what recourse would ARIN have if a legacy holder engaged such a transfer, then, subsequently reneged on their agreement? No contract in place pretty much means no agreement from a legal perspective. In my opinion, if we're going to do this, it is vital that ARIN have a contract with both the transferor and the transferee. Owen From sleibrand at internap.com Wed Aug 27 10:31:34 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 27 Aug 2008 07:31:34 -0700 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives Message-ID: <48B56546.8090501@internap.com> Kevin Oberman wrote: > I know that several have been told that under applicable laws in their > states, they simply cannot sign the LRSA. I mean as in "It would be a > criminal offense to do so". I am not a lawyer, so I won't comment as the > the validity of the lawyer's issues, but, working for an organization > that must meet both Federal Government and State of California > purchasing requirements, I suspect that the opinions are correct. We > have had long battle with very standard contract clauses that we can't > sign. There is a reason Switch and Data refuses to deal with anyone > contracting under GSA procurement rules. If they haven't already, I would encourage anyone finding themselves in this situation, but who would otherwise like to sign the LRSA, contact ARIN. I don't know which clauses they're talking about here, but: "Government agencies and institutions often have special contractual needs. These include: (1) no evergreen clauses in contracts for anti-deficiency laws; (2) no indemnity clauses; (3) choice of law may be restricted; (4) use of binding arbitration may be prohibited and etc. ARIN has always routinely and cooperatively amended both the RSA and now LRSA for these issues." -Scott From sdean at bard.edu Wed Aug 27 10:36:54 2008 From: sdean at bard.edu (Stewart Dean) Date: Wed, 27 Aug 2008 10:36:54 -0400 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about Message-ID: <48B56686.4080601@bard.edu> how clueless I am. At some point, I joined this list because something I was doing related to it. In the course of time, either from membership here or because I'm the Tech POC for 12 Class Cs, I got the transfer policy questionnaire, and I rarely felt my ignorance so keenly. I had only the vaguest idea of what the questions meant, much less having an informed opinion of them. I spent some time over the next 3 days flogging Google and www.arin.net to try to educate myself. At the end of that exercise, I understood something about questions and was able to respond to them....but I really never did find much that spoke clearly and unequivocally on what they were about. Why wasn't there a linked resource explaining the background of each question, the pros and cons or each side? All the documentation I could find was scattered here and there and was colorless and passive-voiced...like reading a telephone book....yes, there was data but what did it mean? What is a liberalized transfer policy? Whose ox is getting gored? I guess this is a minefield and perhaps saying anything would precipitate a flame-war, but what doc there was related poorly or in such an inobvious way that it didn't make much clear. Like presenting a Noh play in Wichita...*whatever* are those people doing and talking about???? BTW, one of the problems about being sysadmin in a small shop is that you have to be a Shiva Nataraja generalist in a world of rapidly expanding requirements and areas of expertise...and unless you're a glow-in-the-dark genius with an eidetic memory, your ignorance grows exponentially. :( -- ==== Stewart Dean, Unix System Admin, Henderson Computer Resources Center of Bard College, Annandale-on-Hudson, New York 12504 sdean at bard.edu voice: 845-758-7475, fax: 845-758-7035 From BillD at cait.wustl.edu Wed Aug 27 11:25:06 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Wed, 27 Aug 2008 10:25:06 -0500 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <48B56686.4080601@bard.edu> References: <48B56686.4080601@bard.edu> Message-ID: Hi Stewart, You are right. Those of us that have been engaged 'know' what's going on because we have been engaged for an extended period of time. Our policy proposals and the 'liberalized transfer policy proposal' particularly are intended supplement, replace, augment, etc. existing ARIN policy. Each proposal should include numbering that suggests where it would reside within our Number Resource Policy Manual. That provides context, but requires that you either know already or are willing to read the larger document to understand where a given proposal fits in. Also, each proposal presents a short rationale which should provide addition context, motivation for it. Whose ox? Well, that depends upon where they fit into the industry and will be affected by the policy or their professional or personal values and perspective. Your tack is correct. Ask on the ppml and get engaged. If you can wade through the often less than direct and organized input, you get lots of education on the subject. Most often inquiry doesn't reward you with flames. Hope to see you in LA at the next meeting..... Bill Darte ARIN AC > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Stewart Dean > Sent: Wednesday, August 27, 2008 9:37 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Stepping forward,opening my mouth and > removing all doubt about > > how clueless I am. > > At some point, I joined this list because something I was > doing related to it. > In the course of time, either from membership here or because > I'm the Tech POC for 12 Class Cs, I got the transfer policy > questionnaire, and I rarely felt my ignorance so keenly. I > had only the vaguest idea of what the questions meant, much > less having an informed opinion of them. I spent some time > over the next 3 days flogging Google and www.arin.net to try > to educate myself. At the end of that exercise, I understood > something about questions and was able to respond to > them....but I really never did find much that spoke clearly > and unequivocally on what they were about. Why wasn't there > a linked resource explaining the background of each question, > the pros and cons or each side? All the documentation I > could find was scattered here and there and was colorless and > passive-voiced...like reading a telephone book....yes, there > was data but what did it mean? > What is a liberalized transfer policy? Whose ox is getting > gored? I guess this is a minefield and perhaps saying > anything would precipitate a flame-war, but what doc there > was related poorly or in such an inobvious way that it didn't > make much clear. Like presenting a Noh play in > Wichita...*whatever* are those people doing and talking about???? > > BTW, one of the problems about being sysadmin in a small shop > is that you have to be a Shiva Nataraja generalist in a world > of rapidly expanding requirements and areas of > expertise...and unless you're a glow-in-the-dark genius with > an eidetic memory, your ignorance grows exponentially. > > :( > > -- > ==== > Stewart Dean, Unix System Admin, Henderson Computer Resources > Center of Bard College, Annandale-on-Hudson, New York 12504 > sdean at bard.edu voice: 845-758-7475, fax: 845-758-7035 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From bill at herrin.us Wed Aug 27 11:24:42 2008 From: bill at herrin.us (William Herrin) Date: Wed, 27 Aug 2008 11:24:42 -0400 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <48B56686.4080601@bard.edu> References: <48B56686.4080601@bard.edu> Message-ID: <3c3e3fca0808270824o7c0e6867h7668e8cd4cfdaed4@mail.gmail.com> On Wed, Aug 27, 2008 at 10:36 AM, Stewart Dean wrote: > What is a liberalized transfer policy? Stewart, Here's the short version: >From it's inception through today, ARIN has received allocations of IP addresses from IANA in large (/8) quantities. ARIN then carves them up and allocates or assigns them to ISPs and end users respectively. If the current rate of consumption holds, some time in 2011, IANA will run out of IP addresses. It will have allocated all possible IPv4 addresses to ARIN and the other registries. Shortly after that, ARIN will allocate its last IP address to some ISP. Then what? A liberalized transfer policy is one possible answer. It would allow entities which hold allocations or assignments of IP addresses to "sell" them, that is transfer them to some other entity in exchange for money or some other consideration. This is largely prohibited by current policy: You can return addresses to ARIN or you can sell your entire company (including its address assignments) to someone else but there's not much in between. The proponents of a liberalized transfer policy say that the inability to get new address from ARIN will bring a market into being regardless of what ARIN does. It falls to ARIN to determine what the constraints on the market process will be. Should it fail to act, ARIN will lose its relevance as a resource steward and registry. Address assignment will devolve into a poorly documented black or gray market process in which everybody gets hurt. The opponents of a liberalized transfer policy say that everybody should just switch to IPv6 which won't have this problem for many decades. Liberalizing the transfer policy would dilute the urgency behind deploying IPv6 and bring about all the problems the existing transfer policy is designed to prevent, like route disaggregation and hording. Everyone would be hurt by that in the end. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From farmer at umn.edu Tue Aug 26 20:14:30 2008 From: farmer at umn.edu (David Farmer) Date: Tue, 26 Aug 2008 19:14:30 -0500 Subject: [arin-ppml] Legacy space holders were a big part of the community... i.e. all of it. In-Reply-To: References: <20080819172716.2FFF74501A@ptavv.es.net>, <7663C7E01D8E094989CA62F0B0D21CD901E0E2B8@SUEXCL-02.ad.syr.edu>, Message-ID: <48B45616.30549.5A340F6@farmer.umn.edu> Sorry this is so long but, I've been thinking on this for a while. On 23 Aug 2008 John Curran wrote: > On Aug 21, 2008, at 2:01 AM, Milton L Mueller wrote: > > Paul > > One can make a good case for a unified, consistent address > governance > > regime that would involve eliminating legacy holder's special > rights > > and > > bringing everyone in under the same kind of contract. > > Equating absence of an agreement with "special rights" is > interesting, > but that's probably best saved for another time. I don't think Legacy holders really have any special rights, but the fact that legacy holder didn't originally have their rights clearly enumerated through a contract or agreement means that there is room to debate what rights they have or the terms that their resources were provided under. What were the terms that resources were provided under? This is a serious question, I wasn't personally there. It is also not as simple as what were the original terms, I believe for the earliest assignments there was an expectation of non-commercial use, I don't think anyone really thinks that is still valid. > > But one cannot make the case you want to make based on appeals to > "the > > community" and "consensus." Because the legacy holders are part of > > "the > > community." A big part of it, in North America. And I suspect that > > they > > will never agree to be part of a "consensus" that eliminates > their > > special status. > > It is a very relevant point, since almost all of those same legacy > holders were certainly part of the consensus decision in 1993 to > change the basic IP address structure to allow variable sized > blocks (aka "CIDR") and the matching matching address allocation > policies (RFC1466/RFC1518/RFC1519). These documents state that > an organization should receive sufficient address space to meet > two years worth of organization need, so that we could "delay > depletion of the IP address space". > > The community of the legacy space allocation era actually already > reached consensus years ago that variable-sized blocks were needed > and that organizational allocations based on two years of need > were > most appropriate. They just forgot to return their own extra > space, > for reasons unknown, With twenty-twenty hind sight, I think maybe this should have happened. But I can't find anything explicitly calling for this at the time. Most of the stuff I have found was really focused forward, but that is probably natural, that is where the cliff was. Do you know of anything calling for what are now classful legacy resources to be repartitioned with CIDR and excess resources to be returned? Especially from the mid-to late 90's time frame, but even from their early 2000's. > and at this point are best off if they can > simultaneously deny that they were part of the community that were > involved in these decisions but somehow were still part of the > team > that earned their legacy allocation by helping build the > Internet... > good luck with that. I propose another spin in the situation, I think the community decided to ignore many issues of the Legacy holders because they were hard problems and the community had more important things to do like moving forward to create the commercialized Internet and avoid driving over the cliff. If the community had stopped to deal with the issues of Legacy resources at that time, it is possible that could have jeopardized the success of the Internet as a whole. Also note many of the earliest Legacy Resources are assigned to non- commercial entities. I think it is natural and possible a good thing that during the early days of ARIN that many of these Legacy Resource holders didn't pay close attention to ARIN and let it work on the issues of bringing the Internet to the commercial world and the rest of society. I personally believe that the community did the prudent thing by leaving the Legacy Resource holders alone in the early days of ARIN and focused on moving forward. But now I think the prudent thing for both ARIN and the Legacy holders is to normalize the status of Legacy Resources. I think part of dealing with the Legacy Resources is to have an open and honest debate about what the terms of those original resources were assigned under. Throwing around terms like "special rights" just makes that debate harder. I don't think Legacy Resource holders have special rights, but I do think it is possible and even likely that the original terms that the resources were allocated under were different that what we have documented in the current RSA and maybe even the LRSA. Some of those differences my still be valid, some my not. I also think if we can have a healthy debate about what the terms Legacy Resource holders received their resource under that could inform policy for Legacy and non-Legacy resources alike. That said I don't think that debate should be accomplished through proposing contract language on PPML. I think we should discuss and the idea and policies that need to be incorporated in the contracts. So I'll start with a concept that I think is not covered in current contract or policies; I don't believe that Legacy or non-Legacy resource holders have property rights to their assigned numbers. I don't believe numbers should be or can be property. However, that said I do believe that certain implied covenants exist between resource holders and ARIN, both Legacy and non-Legacy. Some of these covenants are similar to property right covenants, I propose this is why some people are so dead set against agreeing the "not property" clause. Just because these covenants are similar doesn't mean the resources are property. But maybe these covenants need to become explicit in the RSA or LRSA contract, the Policies, or Both. I feel these covenants start with; 1. the Assigned or Allocated Resources are unique 2. the Assigned or Allocated Resources are not subject to change for arbitrary or capricious reasons 3. the Assigned Resources are in the context of the Internet are for the undistrubed use or benefit of the Assigned Entity I'm not sure how to word #3 for Allocations. Also, maybe #3 needs a limitation of legal use, too. I really can't find #1 or #2 anywhere in the NPRM, RSA or LRSA, and #3 is kind of in NPRM 2.6, but I think it is really intended as a restriction and not a a grant of a right to use. In my view, these kind of form a right of "Quiet Enjoyment" for Number Resources, "Quiet Enjoyment" is from common law for property. I don't think we should call it that but that is the concept I'm after. I don't think #1 or #2 are that much of an issue, if they were not true, then the Internet really wouldn't function. But, #3 is probably much more controversial. People will argue that it makes the resources look like property and therefore it is property, I don't think that is necessarily true, but it could be That is for the lawyers and probably only case law will decided it some day. But I believe you can have the above covenants between ARIN and Resource Holders without making the Resources property. Furthermore, I believe that this provides much of what those that claim that resources are property really think they have. ======================================================= David Farmer Email: farmer at umn.edu Office of Information Technology Networking & Telecomunication Services University of Minnesota Phone: 612-626-0815 2218 University Ave SE Cell: 612-812-9952 Minneapolis, MN 55414-3029 FAX: 612-626-1818 ======================================================= From alain_durand at cable.comcast.com Wed Aug 27 11:55:17 2008 From: alain_durand at cable.comcast.com (Alain Durand) Date: Wed, 27 Aug 2008 11:55:17 -0400 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <3c3e3fca0808270824o7c0e6867h7668e8cd4cfdaed4@mail.gmail.com> Message-ID: On 8/27/08 11:24 AM, "William Herrin" wrote: > The proponents of a liberalized transfer policy say that the inability > to get new address from ARIN will bring a market into being regardless > of what ARIN does. It falls to ARIN to determine what the constraints > on the market process will be. Should it fail to act, ARIN will lose > its relevance as a resource steward and registry. Address assignment > will devolve into a poorly documented black or gray market process in > which everybody gets hurt. > > The opponents of a liberalized transfer policy say that everybody > should just switch to IPv6 which won't have this problem for many > decades. Liberalizing the transfer policy would dilute the urgency > behind deploying IPv6 and bring about all the problems the existing > transfer policy is designed to prevent, like route disaggregation and > hording. Everyone would be hurt by that in the end. Then there is also those who say, me included, that a liberalized transfer policy will not solve the problem at all. Recent ARIN stats showed that most addresses have been allocated in large or very large blocks. This is a direct consequence of the market concentration. Other recent data showed that what would be potentially available via a liberalized transfer policy would mostly be legacy Bs & Cs. Those blocks are simply too small to meet the global demand. - Alain. From mueller at syr.edu Wed Aug 27 12:06:44 2008 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 27 Aug 2008 12:06:44 -0400 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: References: <3c3e3fca0808270824o7c0e6867h7668e8cd4cfdaed4@mail.gmail.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9022150E6@SUEXCL-02.ad.syr.edu> > Then there is also those who say, me included, that a > liberalized transfer > policy will not solve the problem at all. No one in their right mind believes that a liberalized transfer policy will "solve the problem" if "the problem" is IPv4 address scarcity. What it does is handle that scarcity in the most efficient manner over a temporary (hopefully) period. I hope we can lay that straw man to rest. People who believe in an IPv6 transition have to ask themselves what happens 3 - 5 years from now when the migration is not complete and the free pool is exhausted. Apparently their "policy" is panic-based crash IPv6 adoption by people who may or may not be ready. To have no policy regarding the reclamation and transfer of available IPv4 resources during that period is irresponsible. The idea that transfer policies somehow delay the migration to IPv6 has been refuted in our paper. Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org From kkargel at polartel.com Wed Aug 27 12:13:14 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 27 Aug 2008 11:13:14 -0500 Subject: [arin-ppml] FW: Stepping forward, opening my mouth and removing all doubt about Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10A84@mail> I do not believe that a liberalized transfer policy handles the problem in any manner. All it will do is ensure that those with the most money will get access to the addresses, and that some speculators will get rich. If you are not one of those with too much money, or a speculator, I caution you to carefully consider the ramifications of such a policy. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller Sent: Wednesday, August 27, 2008 11:07 AM To: Alain Durand; William Herrin; Stewart Dean Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Stepping forward,opening my mouth and removing all doubt about > Then there is also those who say, me included, that a liberalized > transfer policy will not solve the problem at all. No one in their right mind believes that a liberalized transfer policy will "solve the problem" if "the problem" is IPv4 address scarcity. What it does is handle that scarcity in the most efficient manner over a temporary (hopefully) period. I hope we can lay that straw man to rest. People who believe in an IPv6 transition have to ask themselves what happens 3 - 5 years from now when the migration is not complete and the free pool is exhausted. Apparently their "policy" is panic-based crash IPv6 adoption by people who may or may not be ready. To have no policy regarding the reclamation and transfer of available IPv4 resources during that period is irresponsible. The idea that transfer policies somehow delay the migration to IPv6 has been refuted in our paper. Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3107 bytes Desc: not available URL: From mueller at syr.edu Wed Aug 27 12:19:15 2008 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 27 Aug 2008 12:19:15 -0400 Subject: [arin-ppml] Results of Transfer Proposal Survey Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9022150E8@SUEXCL-02.ad.syr.edu> > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Absent a contract with ARIN, what recourse would ARIN have if a > legacy holder engaged such a transfer, then, subsequently > reneged on their agreement? Is this a serious question? > No contract in place pretty much > means no agreement from a legal perspective. No. When party A sells something to party B for consideration and doesn't deliver it there is all kinds of legal recourse outside of the ARIN regime. If ARIN wants to help it can prepare a simple template transfer contract, but the enforcement of it would depend on the buyer, not ARIN. The LRSA is irrelevant for those purposes. From farmer at umn.edu Wed Aug 27 11:34:03 2008 From: farmer at umn.edu (David Farmer) Date: Wed, 27 Aug 2008 10:34:03 -0500 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <48B56686.4080601@bard.edu> References: <48B56686.4080601@bard.edu> Message-ID: <48B52D9B.23502.313A6DA@farmer.umn.edu> For those who complain about the lack of participation PLEASE TAKE NOTE of this. It is an excellent critique of how we do things on PPML. As the ARIN Board works on revising the Internet Resource Policy Evaluation Process (IRPEP) maybe another role for the Advisory Council (AC) is to provide a summary of both sides of the argument and pointers to more information. In Denver there was talk of web forums and other tools for input that might make this a little easier. On 27 Aug 2008 Stewart Dean wrote: > how clueless I am. > > At some point, I joined this list because something I was doing > related to it. In the course of time, either from membership here or > because I'm the Tech POC for 12 Class Cs, I got the transfer policy > questionnaire, and I rarely felt my ignorance so keenly. I had only > the vaguest idea of what the questions meant, much less having an > informed opinion of them. I spent some time over the next 3 days > flogging Google and www.arin.net to try to educate myself. At the end > of that exercise, I understood something about questions and was able > to respond to them....but I really never did find much that spoke > clearly and unequivocally on what they were about. Why wasn't there a > linked resource explaining the background of each question, the pros > and cons or each side? All the documentation I could find was > scattered here and there and was colorless and passive-voiced...like > reading a telephone book....yes, there was data but what did it mean? > What is a liberalized transfer policy? Whose ox is getting gored? I > guess this is a minefield and perhaps saying anything would > precipitate a flame-war, but what doc there was related poorly or in > such an inobvious way that it didn't make much clear. Like presenting > a Noh play in Wichita...*whatever* are those people doing and talking > about???? > > BTW, one of the problems about being sysadmin in a small shop is that > you have to be a Shiva Nataraja generalist in a world of rapidly > expanding requirements and areas of expertise...and unless you're a > glow-in-the-dark genius with an eidetic memory, your ignorance grows > exponentially. > > :( > > -- > ==== > Stewart Dean, Unix System Admin, Henderson Computer Resources > Center of Bard College, Annandale-on-Hudson, New York 12504 > sdean at bard.edu voice: 845-758-7475, fax: 845-758-7035 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. ======================================================= David Farmer Email: farmer at umn.edu Office of Information Technology Networking & Telecomunication Services University of Minnesota Phone: 612-626-0815 2218 University Ave SE Cell: 612-812-9952 Minneapolis, MN 55414-3029 FAX: 612-626-1818 ======================================================= From stephen at sprunk.org Wed Aug 27 12:21:19 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 27 Aug 2008 11:21:19 -0500 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: References: Message-ID: <48B57EFF.9040901@sprunk.org> Alain Durand wrote: > On 8/27/08 11:24 AM, "William Herrin" wrote: >> The proponents of a liberalized transfer policy say that the inability >> to get new address from ARIN will bring a market into being regardless >> of what ARIN does. It falls to ARIN to determine what the constraints >> on the market process will be. Should it fail to act, ARIN will lose >> its relevance as a resource steward and registry. Address assignment >> will devolve into a poorly documented black or gray market process in >> which everybody gets hurt. >> >> The opponents of a liberalized transfer policy say that everybody >> should just switch to IPv6 which won't have this problem for many >> decades. Liberalizing the transfer policy would dilute the urgency >> behind deploying IPv6 and bring about all the problems the existing >> transfer policy is designed to prevent, like route disaggregation and >> hording. Everyone would be hurt by that in the end. >> > > Then there is also those who say, me included, that a liberalized transfer > policy will not solve the problem at all. Recent ARIN stats showed that most > addresses have been allocated in large or very large blocks. This is a > direct consequence of the market concentration. Other recent data showed > that what would be potentially available via a liberalized transfer policy > would mostly be legacy Bs & Cs. Those blocks are simply too small to meet > the global demand. > OTOH, there are several large companies that have legacy As, which currently have no incentive to return them to ARIN. Many could renumber into a /16 or less, using NAT, if only they had the financial motivation to incur that cost; ditto for the hundreds of companies sitting on multiple Bs that could renumber into a /24 if motivated. However, that still only buys us another year or two at current growth rates... Plus, I don't hear many folks here being sympathetic to the big ISPs in the first place, since they're the ones consuming most of the address space and causing problems for the rest of us. These ISPs have the market power to force their vendors to support IPv6, which would trickle down to the smaller players, but so far there's been little visible motion on that front. They're the ones that are going to be hit the hardest in the coming crunch, given their rates of consumption, so they _have_ to go to IPv6 with NAT-PT (or multi-layered IPv4 NAT) in the near future. Once they do, though, they could return most of their IPv4 space, which would eliminate the address space depletion problem for the rest of the community... There are lots of paths out of this problem, and I'm sure that the Internet will keep on working no matter which one we choose. Transfers seem to minimize short-term pain, but forcing a transition to IPv6 would minimize long-term pain. Do we have the guts, as Lincoln did, to destroy the Internet in order to save it? If not, the only option left is a liberal transfer policy. S From BillD at cait.wustl.edu Wed Aug 27 12:46:04 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Wed, 27 Aug 2008 11:46:04 -0500 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <48B52D9B.23502.313A6DA@farmer.umn.edu> References: <48B56686.4080601@bard.edu> <48B52D9B.23502.313A6DA@farmer.umn.edu> Message-ID: Great point Dan, and I for one, on the Advisory Council will take this idea and bring it back for discussion! Bill Darte ARIN AC > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer > Sent: Wednesday, August 27, 2008 10:34 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Stepping forward,opening my mouth > and removing all doubt about > > For those who complain about the lack of participation PLEASE > TAKE NOTE of this. It is an excellent critique of how we do > things on PPML. As the ARIN Board works on revising the > Internet Resource Policy Evaluation Process (IRPEP) maybe > another role for the Advisory Council (AC) is to provide a > summary of both sides of the argument and pointers to more > information. In Denver there was talk of web forums and > other tools for input that might make this a little easier. > > On 27 Aug 2008 Stewart Dean wrote: > > > how clueless I am. > > > > At some point, I joined this list because something I was doing > > related to it. In the course of time, either from > membership here or > > because I'm the Tech POC for 12 Class Cs, I got the transfer policy > > questionnaire, and I rarely felt my ignorance so keenly. I > had only > > the vaguest idea of what the questions meant, much less having an > > informed opinion of them. I spent some time over the next 3 days > > flogging Google and www.arin.net to try to educate myself. > At the end > > of that exercise, I understood something about questions > and was able > > to respond to them....but I really never did find much that spoke > > clearly and unequivocally on what they were about. Why > wasn't there a > > linked resource explaining the background of each question, > the pros > > and cons or each side? All the documentation I could find was > > scattered here and there and was colorless and > passive-voiced...like > > reading a telephone book....yes, there was data but what > did it mean? > > What is a liberalized transfer policy? Whose ox is getting > gored? I > > guess this is a minefield and perhaps saying anything would > > precipitate a flame-war, but what doc there was related > poorly or in > > such an inobvious way that it didn't make much clear. Like > presenting > > a Noh play in Wichita...*whatever* are those people doing > and talking > > about???? > > > > BTW, one of the problems about being sysadmin in a small > shop is that > > you have to be a Shiva Nataraja generalist in a world of rapidly > > expanding requirements and areas of expertise...and unless you're a > > glow-in-the-dark genius with an eidetic memory, your > ignorance grows > > exponentially. > > > > :( > > > > -- > > ==== > > Stewart Dean, Unix System Admin, Henderson Computer > Resources Center > > of Bard College, Annandale-on-Hudson, New York 12504 > sdean at bard.edu > > voice: 845-758-7475, fax: 845-758-7035 > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed > to the ARIN > > Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > ======================================================= > David Farmer Email: farmer at umn.edu > Office of Information Technology > Networking & Telecomunication Services > University of Minnesota Phone: > 612-626-0815 > 2218 University Ave SE Cell: > 612-812-9952 > Minneapolis, MN 55414-3029 FAX: 612-626-1818 > ======================================================= > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From BillD at cait.wustl.edu Wed Aug 27 12:46:48 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Wed, 27 Aug 2008 11:46:48 -0500 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <48B52D9B.23502.313A6DA@farmer.umn.edu> References: <48B56686.4080601@bard.edu> <48B52D9B.23502.313A6DA@farmer.umn.edu> Message-ID: Of course I mean...David.... Great point Dan, and I for one, on the Advisory Council will take this idea and bring it back for discussion! Bill Darte ARIN AC > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer > Sent: Wednesday, August 27, 2008 10:34 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Stepping forward,opening my mouth > and removing all doubt about > > For those who complain about the lack of participation PLEASE > TAKE NOTE of this. It is an excellent critique of how we do > things on PPML. As the ARIN Board works on revising the > Internet Resource Policy Evaluation Process (IRPEP) maybe > another role for the Advisory Council (AC) is to provide a > summary of both sides of the argument and pointers to more > information. In Denver there was talk of web forums and > other tools for input that might make this a little easier. > > On 27 Aug 2008 Stewart Dean wrote: > > > how clueless I am. > > > > At some point, I joined this list because something I was doing > > related to it. In the course of time, either from > membership here or > > because I'm the Tech POC for 12 Class Cs, I got the transfer policy > > questionnaire, and I rarely felt my ignorance so keenly. I > had only > > the vaguest idea of what the questions meant, much less having an > > informed opinion of them. I spent some time over the next 3 days > > flogging Google and www.arin.net to try to educate myself. > At the end > > of that exercise, I understood something about questions > and was able > > to respond to them....but I really never did find much that spoke > > clearly and unequivocally on what they were about. Why > wasn't there a > > linked resource explaining the background of each question, > the pros > > and cons or each side? All the documentation I could find was > > scattered here and there and was colorless and > passive-voiced...like > > reading a telephone book....yes, there was data but what > did it mean? > > What is a liberalized transfer policy? Whose ox is getting > gored? I > > guess this is a minefield and perhaps saying anything would > > precipitate a flame-war, but what doc there was related > poorly or in > > such an inobvious way that it didn't make much clear. Like > presenting > > a Noh play in Wichita...*whatever* are those people doing > and talking > > about???? > > > > BTW, one of the problems about being sysadmin in a small > shop is that > > you have to be a Shiva Nataraja generalist in a world of rapidly > > expanding requirements and areas of expertise...and unless you're a > > glow-in-the-dark genius with an eidetic memory, your > ignorance grows > > exponentially. > > > > :( > > > > -- > > ==== > > Stewart Dean, Unix System Admin, Henderson Computer > Resources Center > > of Bard College, Annandale-on-Hudson, New York 12504 > sdean at bard.edu > > voice: 845-758-7475, fax: 845-758-7035 > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed > to the ARIN > > Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > ======================================================= > David Farmer Email: farmer at umn.edu > Office of Information Technology > Networking & Telecomunication Services > University of Minnesota Phone: > 612-626-0815 > 2218 University Ave SE Cell: > 612-812-9952 > Minneapolis, MN 55414-3029 FAX: 612-626-1818 > ======================================================= > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From michael.dillon at bt.com Wed Aug 27 12:45:48 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 27 Aug 2008 17:45:48 +0100 Subject: [arin-ppml] Legacy space holders were a big part of thecommunity... i.e. all of it. In-Reply-To: <48B45616.30549.5A340F6@farmer.umn.edu> Message-ID: > 1. the Assigned or Allocated Resources are unique They are NOT unique. All they are is numbers and ARIN can do nothing directly to prevent others from using the same numbers. Anyone whose job lets them see inside other organizations networks knows that there is a lot of usage of non-registered IP addresses out there, mostly hidden behind NATs but not always. > 3. the Assigned Resources are > in the context of the Internet are for the undistrubed use or > benefit of the Assigned Entity Not sure how that would fly since the regular RSA address allocations have no Internet restriction, and RFC 2050 which predated ARIN, also notes that it is not necessary to use the addresses on the Internet in order to justify an allocation. --Michael Dillon From sdean at bard.edu Wed Aug 27 12:48:01 2008 From: sdean at bard.edu (Stewart Dean) Date: Wed, 27 Aug 2008 12:48:01 -0400 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <48B56686.4080601@bard.edu> References: <48B56686.4080601@bard.edu> Message-ID: <48B58541.6050409@bard.edu> Thank you one and all. This is a GREAT list for burning off fog (to say nothing of FUD). Got much more from this in a few hours than I did in my flogging of the Web resources. Also got a few note from others, less brave or fool hardy, thanking me for speaking up and asking about the Emperor's New Transfer Policy. The only thing stupider than being dazed and clueless is not asking questions to get sensible information.... > Like presenting a Noh play in Wichita... http://en.wikipedia.org/wiki/Noh -- ==== Stewart Dean, Unix System Admin, Henderson Computer Resources Center of Bard College, Annandale-on-Hudson, New York 12504 sdean at bard.edu voice: 845-758-7475, fax: 845-758-7035 From mueller at syr.edu Wed Aug 27 12:49:23 2008 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 27 Aug 2008 12:49:23 -0400 Subject: [arin-ppml] Policy Proposal 2008-6: Emergency Transfer PolicyforIPv4 Addresses In-Reply-To: References: <48B3FBFC.7070307@arin.net> <7663C7E01D8E094989CA62F0B0D21CD9022150DA@SUEXCL-02.ad.syr.edu> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9022150E9@SUEXCL-02.ad.syr.edu> Based on the discussion of 2008-6 I would have to express my opposition to it. 2008-2 is preferable. I would oppose Darte's substitute because it is evident that consensus can be reached on the more detailed provisions of 2008-2, and that the AC has been working effectively to improve that proposal based on suggestions. I would also oppose 2008-6 because it is vaguely worded in key spots. To say that ARIN is not an intermediary while requiring both buyers and sellers to be prequalified by ARIN is just incomprehensible. > -----Original Message----- > From: Bill Darte [mailto:BillD at cait.wustl.edu] > > #1....substitute for 2008-2....as Scott Leibrand said > elsewhere... if a > liberalized transfer policy is the will of the community, but > consensus > cannot be reached over details encompassed by 2008-2 then this > "bare-bones" policy might suffice to get started down that path. > > #2....the intent is that the transfer takes place between the > holder and > the entity acquiring and the details of the transfer do not > involve ARIN > as an intermediary there. But, in order for ARIN to document the > transfer within Whois, etc. and to establish that the entity receiving > the transfer has need, the RSA must be established in advance. > > bd > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller > > Sent: Tuesday, August 26, 2008 2:33 PM > > To: Member Services; ppml at arin.net > > Subject: Re: [arin-ppml] Policy Proposal 2008-6: Emergency > > Transfer PolicyforIPv4 Addresses > > > > > > I am having trouble understanding this proposal and seek > > clarification. > > > > 1. How does this "emergency" transfer proposal relate to > > Policy Proposal 2008-2, the other transfer policy proposal? > > Is it considered a supplement to that proposal or a > substitute for it? > > > > 2. How does one engage in a transfer "without the active > > involvement of ARIN as an intermediary" when the recipient of > > the transfer must "document operational need in accordance > > with current ARIN policy" and sign an RSA "covering those > > resources in advance of transfer"? > > > > Milton Mueller > > Professor, Syracuse University School of Information Studies > > XS4All Professor, Delft University of Technology > > ------------------------------ > > Internet Governance Project: > > http://internetgovernance.org > > > > > > > -----Original Message----- > > > From: arin-ppml-bounces at arin.net > > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Member Services > > > Sent: Tuesday, August 26, 2008 8:50 AM > > > To: ppml at arin.net > > > Subject: [arin-ppml] Policy Proposal 2008-6: Emergency > > Transfer Policy > > > forIPv4 Addresses > > > > > > On 21 August 2008, the ARIN Advisory Council (AC) concluded > > its review > > > of "Emergency Transfer Policy for IPv4 Addresses" and > > accepted it as a > > > formal policy proposal for discussion by the community. > > > > > > The proposal is designated Policy Proposal 2008-6: > > Emergency Transfer > > > Policy for IPv4 Addresses. The proposal text is below and > > can be found > > > at: > > > http://www.arin.net/policy/proposals/2008_6.html > > > > > > All persons in the community are encouraged to discuss > > Policy Proposal > > > 2008-6 prior to it being presented at the ARIN XXII Public Policy > > > Meeting. Both the discussion on the Public Policy Mailing > > List and at > > > the Public Policy Meeting will be used to determine the community > > > consensus regarding this policy proposal. > > > > > > AC shepherds for this proposal are Owen DeLong and Stacy Hughes. > > > > > > The ARIN Internet Resource Policy Evaluation Process can be > > found at: > > > http://www.arin.net/policy/irpep.html > > > > > > ARIN's Policy Proposal Archive can be found at: > > > http://www.arin.net/policy/proposals/proposal_archive.html > > > > > > Regards, > > > > > > Member Services > > > American Registry for Internet Numbers (ARIN) > > > > > > > > > ## * ## > > > > > > > > > Policy Proposal 2008-6 > > > Emergency Transfer Policy for IPv4 Addresses > > > > > > Author: Bill Darte > > > > > > Proposal Version: 1.0 > > > > > > Submission Date: August 15, 2008 > > > > > > Proposal type: New > > > > > > Policy term: Temporary > > > > > > Policy statement: > > > > > > 8.2.1 Emergency Transfer Policy for IPv4 Addresses > > > > > > For a period of 3 years from policy implementation, > transfer of ARIN > > > IPv4 addresses between two entities in the ARIN region, > without the > > > active involvement of ARIN as an intermediary, will be considered > > > legitimate and will be documented accordingly under the following > > > conditions: > > > > > > 1. Transfer takes place from a holder of IPv4 addresses > > recognized by > > > ARIN as the legitimate and exclusive holder of those resources. > > > > > > 2. Transfer takes place to a recipient that has documented > > > operational need in accordance with current ARIN policy and > > that signs > > > an RSA with ARIN covering those resources in advance of transfer. > > > > > > 3. Transfer of addresses takes place in such a way that > > the original > > > contiguous block(s) are not disaggregated into more than 4 > > resultant > > > network blocks each being greater than or equal to the > > current minimum > > > sizes specified in applicable ARIN policy. > > > > > > 4. Transfer is complete and unrestricted and is supported by > > > documentation that ARIN deems satisfactory. > > > > > > > > > Rationale: > > > > > > In order for ARIN to fulfill its mission and to facilitate a > > > continuing supply of IPv4 address resources to its service > > community > > > when ARIN resources are no longer adequate, and to preserve the > > > integrity of documentation and ARIN services for those > > resources, this > > > policy may be implemented. Its intent is to preserve the current > > > tradition of need-based allocation/assignments for those > > still needing > > > IPv4 resources > > > during a transition period as the industry adopts IPv6. > > This policy is > > > not intended to create a 'market' for such transfers and does not > > > introduce or condone the monetization of address resources > > or a view > > > of addresses as property. It does recognize that > > organizations making > > > available unused or no longer needed address resources may incur > > > certain costs that might be compensated by those acquiring the > > > resources. This policy is intended to be transient and > > light-weight > > > and does not encourage a sustained or continuing role for > IPv4, but > > > rather helps to mitigate a transitional crisis that may > > emerge while > > > the industry adopts > > > IPv6 in accordance with the recommendation of ARIN's Board of > > > Trustees. > > > > > > Timetable for implementation: > > > > > > This policy, once ratified by the ARIN Board of Trustees, > would be > > > implemented when either the free-pool of IANA addresses is > > exhausted > > > or > > > IPv4 address resources in the ARIN Region reaches a threshold of > > > scarcity recognized by the ARIN Board of Trustees as > > requiring this > > > policy implementation. > > > > > > > > > > > > _______________________________________________ > > > PPML > > > You are receiving this message because you are subscribed > > to the ARIN > > > Public Policy Mailing List (ARIN-PPML at arin.net). > > > Unsubscribe or manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > Please contact info at arin.net if you experience any issues. > > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > From mueller at syr.edu Wed Aug 27 13:01:18 2008 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 27 Aug 2008 13:01:18 -0400 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: References: <3c3e3fca0808270824o7c0e6867h7668e8cd4cfdaed4@mail.gmail.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9022150EC@SUEXCL-02.ad.syr.edu> Alain, as a person from an ISP wouldn't the ability to sell IPv4 resources freed up by a conversion to IPv6 add anything to the incentives of ISPs to make the migration? Of course that is more a matter for your business officers but I suspect that it could make a difference. > -----Original Message----- > From: arin-ppml-bounces at arin.net > Recent ARIN stats showed that most addresses have been > allocated in large or very large blocks. This is a > direct consequence of the market concentration. Other recent > data showed that what would be potentially available via a liberalized > transfer policy would mostly be legacy Bs & Cs. > Those blocks are simply too small to meet > the global demand. > > - Alain. > From farmer at umn.edu Wed Aug 27 13:08:25 2008 From: farmer at umn.edu (David Farmer) Date: Wed, 27 Aug 2008 12:08:25 -0500 Subject: [arin-ppml] Legacy space holders were a big part of thecommunity... i.e. all of it. In-Reply-To: References: <48B45616.30549.5A340F6@farmer.umn.edu>, Message-ID: <48B543B9.23978.36A0E3D@farmer.umn.edu> On 27 Aug 2008 michael.dillon at bt.com wrote: > > 1. the Assigned or Allocated Resources are unique > > They are NOT unique. All they are is numbers and ARIN > can do nothing directly to prevent others from using > the same numbers. Anyone whose job lets them see inside > other organizations networks knows that there is a lot > of usage of non-registered IP addresses out there, mostly > hidden behind NATs but not always. This is to be a convent between ARIN and the Assignee that is it, no one else. Are you telling me ARIN is suppose to assign the same number to more than one entity. I'm not asking ARIN to say anything about what others do only about what they do. No where in policy or the contracts does it say ARIN can't assign the same resources to two different groups. That is all I'm asking for here. It may seem obvious, but I can't find it said anywhere, it is that simple. So if ARIN is suppose to be able to assign the same resources to two different groups then what is all this about IPv4 exhaustion. Just start the counter over, problem solved, some how I don't think it is that easy. :) > > 3. the Assigned Resources are > > in the context of the Internet are for the undistrubed use or > > benefit of the Assigned Entity > > Not sure how that would fly since the regular RSA address allocations > have no Internet restriction, and RFC 2050 which predated ARIN, also > notes that it is not necessary to use the addresses on the Internet in > order to justify an allocation. I have worded this badly, I'm try to say that it is limited to the domain of Internet Protocol Addressing and has no bearing on some other domain of 32 bit numbers. I'm open to better wording. > --Michael Dillon > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. ======================================================= David Farmer Email: farmer at umn.edu Office of Information Technology Networking & Telecomunication Services University of Minnesota Phone: 612-626-0815 2218 University Ave SE Cell: 612-812-9952 Minneapolis, MN 55414-3029 FAX: 612-626-1818 ======================================================= From tvest at pch.net Wed Aug 27 13:24:03 2008 From: tvest at pch.net (Tom Vest) Date: Wed, 27 Aug 2008 13:24:03 -0400 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9022150EC@SUEXCL-02.ad.syr.edu> References: <3c3e3fca0808270824o7c0e6867h7668e8cd4cfdaed4@mail.gmail.com> <7663C7E01D8E094989CA62F0B0D21CD9022150EC@SUEXCL-02.ad.syr.edu> Message-ID: From a forthcoming paper: "One author believes that there is a significant risk that introduction of a transfer market may substantially increase incentives to delay conversion to IPv6, and quite possibly derail it altogether. This prediction is based on the hypothesis that the establishment of a market for IPv4 transfers will present every individual IPv4-based network operator capable of providing Internet services with a mix of incentives that is broadly weighted toward, and cumulatively strengthened over time, by the perpetuation of IPv4?s status as critical, non-substitutable (i.e., ?bottleneck?) input for Internet service delivery. On this argument, individual IPv4-based incumbents facing the certainty of one-time returns resulting from an immediate simple sale and transfer of surplus IPv4, might opt instead to postpone any sale as long as transfer prices appear to be stable or appreciating, with any resulting opportunity costs being offset by the steady stream of recurring revenues that could be realized by making the surplus IPv4 addresses accessible only as an indivisible part of a ?bundled? Internet service (e.g., IPv6-IPv4 translation or IPv4 transit). As long as the market for simple transfers and critical IPv4-related services continues to appreciate ? or at minimum, simple transfer prices do not clearly depreciate below the medium-term gains achievable in the bundled IPv4 services market ? simple sale would be irrational. As long as simple IPv4 transfers remain a sub-optimal strategy for potential sellers, and IPv4 continues to be sought by at least some growing ISPs -- and remains an absolutely non-substitutable requirement for aspiring new Internet service providers -- prices are likely to continue appreciating, in perpetuity. In turn, this appreciation would encourage surplus IPv4 to become increasingly concentrated amongst providers of bundled IPv4 services, both through successful bargaining and competition for the remaining liquid IPv4 addresses, and by the gradual adoption of increasingly attractive IPv4 service-centered business models by large, independent IPv4 reserve holders that previously provided networking services only to themselves. The key ingredient in this perverse mix is not the scarcity of IPv4 itself, but rather the continued scarcity of substitutable Internet content and services that require no IPv4 at all ? i.e., that are transparently accessible by IPv6-only networks. Knowing this, every prospective IPv4 seller-cum-service provider could face strong individual disincentives to migrate their own online content and services to IPv6, or otherwise make such resources transparently accessible to pure IPv6-based operators. The cumulative result of such individual-level dynamics would be an indefinite postponement of, and active resistance to any IPv6 transition by the same institutions whose strategies, decisions, and investments will ultimately determine when, how, or whether such a transition will actually happen." TV On Aug 27, 2008, at 1:01 PM, Milton L Mueller wrote: > > Alain, as a person from an ISP wouldn't the ability to sell IPv4 > resources freed up by a conversion to IPv6 add anything to the > incentives of ISPs to make the migration? Of course that is more a > matter for your business officers but I suspect that it could make a > difference. > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net >> Recent ARIN stats showed that most addresses have been >> allocated in large or very large blocks. This is a >> direct consequence of the market concentration. Other recent >> data showed that what would be potentially available via a >> liberalized > >> transfer policy would mostly be legacy Bs & Cs. >> Those blocks are simply too small to meet >> the global demand. >> >> - Alain. >> > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From micah at riseup.net Wed Aug 27 13:42:32 2008 From: micah at riseup.net (Micah Anderson) Date: Wed, 27 Aug 2008 13:42:32 -0400 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: <20080826235015.02CED4500F@ptavv.es.net> References: <48B45FEB.2090406@sprunk.org> <20080826235015.02CED4500F@ptavv.es.net> Message-ID: <20080827174232.GA3875@pond.riseup.net> * Kevin Oberman [2008-08-26 16:50-0400]: > Thanks you, Stephen! Someone finally stated the obvious. A complete > registry is of benefit to everyone. (I think that this is probably "the > commons" to which Randy was referring.) Rest assured that the $100 is not > an issue keeping most legacy holders from signing the LRSA. People keep saying this about the $100, as if this was well established fact, based on some data. Why do people keep asserting this, I'd like to know what I missed. Personally, I'd like a clear idea of the costs involved to run whatever service I am getting before I would say if $100 was a good number or not. It may seem small to people with large corporate budgets, but small non-profit organizations tend to be misers with good reason. Until I've seen good reason, I am not interested in spending $100/year. micah From bill at herrin.us Wed Aug 27 13:54:20 2008 From: bill at herrin.us (William Herrin) Date: Wed, 27 Aug 2008 13:54:20 -0400 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: References: <3c3e3fca0808270824o7c0e6867h7668e8cd4cfdaed4@mail.gmail.com> Message-ID: <3c3e3fca0808271054j3d45c03ar6e0bc38245905bc7@mail.gmail.com> On Wed, Aug 27, 2008 at 11:55 AM, Alain Durand wrote: > On 8/27/08 11:24 AM, "William Herrin" wrote: > >> The proponents of a liberalized transfer policy say that the inability >> to get new address from ARIN will bring a market into being regardless >> of what ARIN does. >> >> The opponents of a liberalized transfer policy say that everybody >> should just switch to IPv6 which won't have this problem for many >> decades. > > Then there is also those who say, me included, that a liberalized transfer > policy will not solve the problem at all. Yeah, yeah. Obviously some on each side of the question also disbelieve the basis for the other side's claim. For example, I think the idea that IPv6 will be capable of playing a role in the solution is a crock and that the feared hording has already happened by a few large ISPs who opted to use globally routeable IP addresses instead of NATed systems everywhere they could primarily because it leaves them in control of huge swaths of address space. If it makes you feel better, add "And by the way, the other side's claims are in error," to both the proponent and opponent sides. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From kkargel at polartel.com Wed Aug 27 14:07:42 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 27 Aug 2008 13:07:42 -0500 Subject: [arin-ppml] FW: Stepping forward, opening my mouth and removing all doubt about Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10A89@mail> It depends on whether you are more concerned with a short term monetary gain or the continued well being of the internet as a whole. If the only thing you are concerned with is a short term profit taking then being able to sell your IP addresses would be a windfall. If you want to be able to continue to use the internet, or you would like perhaps to be able to get what IPv4 addresses are left in the future without paying exorbitant fees then it is not so good. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Milton L Mueller Sent: Wednesday, August 27, 2008 12:01 PM To: Alain Durand Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Stepping forward,opening my mouth and removing all doubt about Alain, as a person from an ISP wouldn't the ability to sell IPv4 resources freed up by a conversion to IPv6 add anything to the incentives of ISPs to make the migration? Of course that is more a matter for your business officers but I suspect that it could make a difference. > -----Original Message----- > From: arin-ppml-bounces at arin.net > Recent ARIN stats showed that most addresses have been allocated in > large or very large blocks. This is a direct consequence of the market > concentration. Other recent data showed that what would be potentially > available via a liberalized > transfer policy would mostly be legacy Bs & Cs. > Those blocks are simply too small to meet the global demand. > > - Alain. > _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3107 bytes Desc: not available URL: From JOHN at egh.com Wed Aug 27 14:30:19 2008 From: JOHN at egh.com (John Santos) Date: Wed, 27 Aug 2008 14:30:19 -0400 Subject: [arin-ppml] Legacy space holders were a big part of the community... i.e. all of it. In-Reply-To: <1080823130905.27224A-100000@Ives.egh.com> Message-ID: <1080827141047.423B-100000@Ives.egh.com> On Sat, 23 Aug 2008, John Santos wrote: > On Sat, 23 Aug 2008, John Curran wrote: [snip] > > > > It is a very relevant point, since almost all of those same legacy > > holders were certainly part of the consensus decision in 1993 to > > change the basic IP address structure to allow variable sized > > blocks (aka "CIDR") and the matching matching address allocation > > policies (RFC1466/RFC1518/RFC1519). These documents state that > > an organization should receive sufficient address space to meet > > two years worth of organization need, so that we could "delay > > depletion of the IP address space". > > > > The community of the legacy space allocation era actually already > > reached consensus years ago that variable-sized blocks were needed > > and that organizational allocations based on two years of need were > > most appropriate. They just forgot to return their own extra space, > > for reasons unknown, and at this point are best off if they can > > simultaneously deny that they were part of the community that were > > involved in these decisions but somehow were still part of the team > > that earned their legacy allocation by helping build the Internet... > > good luck with that. > > You are assuming that legacy holders are hanging on to "extra" Left out an "all" here... Oops. Should be "that all legacy holders..." > space and refusing to return it. That is certainly not the case. > I suspect that some legacy holders might be doing that, but object to *all* of us being tarred with the same brush, and object to any policies being adopted that assume ill-intent or hoarding on the part of *all* legacy holders. > As an existence proof, I am a legacy holder and am using most of > my space. (As of today, 134 of 256 addresses staticly allocated, > plus a bunch of DHCP space.) [snip] -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From mueller at syr.edu Wed Aug 27 14:46:19 2008 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 27 Aug 2008 14:46:19 -0400 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: References: <3c3e3fca0808270824o7c0e6867h7668e8cd4cfdaed4@mail.gmail.com> <7663C7E01D8E094989CA62F0B0D21CD9022150EC@SUEXCL-02.ad.syr.edu> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD9022150F2@SUEXCL-02.ad.syr.edu> It's great when Tom forwards these lengthy (sorta)economic analyses and one can refute them in one sentence. And here it is: if ISPs can game the migration process in the way he predicts, then they don't need transfer markets to do it. > The key ingredient in this perverse mix is not the scarcity of IPv4 > itself, but rather the continued scarcity of substitutable Internet > content and services that require no IPv4 at all - i.e., that are > transparently accessible by IPv6-only networks. Knowing this, every > prospective IPv4 seller-cum-service provider could face strong > individual disincentives to migrate their own online content and > services to IPv6, or otherwise make such resources transparently > accessible to pure IPv6-based operators. Note that this supposed "disincentive" exists whether or not there are ipv4 transfer markets. Note that the concentration of ipv4 resources he fears could be achieved via acquistions under the current regime. Note also that the analysis _assumes_ that the price of IPv4 addresses "increases in perpetuity." A strong, what we call "heroic" assumption. "Heroic" being a polite word for pulled out of one's a** and patently unrealistic. Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org > -----Original Message----- > From: Tom Vest [mailto:tvest at pch.net] > Sent: Wednesday, August 27, 2008 1:24 PM > To: Milton L Mueller > Cc: Alain Durand; arin-ppml at arin.net > Subject: Re: [arin-ppml] Stepping forward, opening my mouth > and removing all doubt about > > From a forthcoming paper: > > "One author believes that there is a > significant risk that introduction of a transfer market may > substantially increase incentives to delay conversion to IPv6, and > quite possibly derail it altogether. This prediction is based on the > hypothesis that the establishment of a market for IPv4 > transfers will > present every individual IPv4-based network operator capable of > providing Internet services with a mix of incentives that is broadly > weighted toward, and cumulatively strengthened over time, by the > perpetuation of IPv4's status as critical, non-substitutable (i.e., > "bottleneck") input for Internet service delivery. > > On this argument, individual IPv4-based incumbents facing the > certainty of one-time returns resulting from an immediate > simple sale > and transfer of surplus IPv4, might opt instead to postpone any sale > as long as transfer prices appear to be stable or appreciating, with > any resulting opportunity costs being offset by the steady stream of > recurring revenues that could be realized by making the surplus IPv4 > addresses accessible only as an indivisible part of a "bundled" > Internet service (e.g., IPv6-IPv4 translation or IPv4 transit). As > long as the market for simple transfers and critical IPv4-related > services continues to appreciate - or at minimum, simple transfer > prices do not clearly depreciate below the medium-term gains > achievable in the bundled IPv4 services market - simple sale > would be > irrational. As long as simple IPv4 transfers remain a sub-optimal > strategy for potential sellers, and IPv4 continues to be > sought by at > least some growing ISPs -- and remains an absolutely > non-substitutable > requirement for aspiring new Internet service providers -- > prices are > likely to continue appreciating, in perpetuity. > > In turn, this appreciation would encourage surplus IPv4 to become > increasingly concentrated amongst providers of bundled IPv4 > services, > both through successful bargaining and competition for the remaining > liquid IPv4 addresses, and by the gradual adoption of increasingly > attractive IPv4 service-centered business models by large, > independent > IPv4 reserve holders that previously provided networking > services only > to themselves. > The cumulative > result of such > individual-level dynamics would be an indefinite postponement > of, and > active resistance to any IPv6 transition by the same institutions > whose strategies, decisions, and investments will ultimately > determine > when, how, or whether such a transition will actually happen." > > TV > > On Aug 27, 2008, at 1:01 PM, Milton L Mueller wrote: > > > > > Alain, as a person from an ISP wouldn't the ability to sell IPv4 > > resources freed up by a conversion to IPv6 add anything to the > > incentives of ISPs to make the migration? Of course that is more a > > matter for your business officers but I suspect that it could make a > > difference. > > > >> -----Original Message----- > >> From: arin-ppml-bounces at arin.net > >> Recent ARIN stats showed that most addresses have been > >> allocated in large or very large blocks. This is a > >> direct consequence of the market concentration. Other recent > >> data showed that what would be potentially available via a > >> liberalized > > > >> transfer policy would mostly be legacy Bs & Cs. > >> Those blocks are simply too small to meet > >> the global demand. > >> > >> - Alain. > >> > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > From Lee.Howard at stanleyassociates.com Wed Aug 27 14:52:49 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 27 Aug 2008 14:52:49 -0400 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: <20080827174232.GA3875@pond.riseup.net> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B13B409@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Micah Anderson > Sent: Wednesday, August 27, 2008 1:43 PM > To: Kevin Oberman > Cc: Randy Bush; arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Whois > Authentication Alternatives > > * Kevin Oberman [2008-08-26 16:50-0400]: > > Thanks you, Stephen! Someone finally stated the obvious. A complete > > registry is of benefit to everyone. (I think that this is probably > > "the commons" to which Randy was referring.) Rest assured that the > > $100 is not an issue keeping most legacy holders from > signing the LRSA. > > People keep saying this about the $100, as if this was well > established fact, based on some data. Why do people keep > asserting this, I'd like to know what I missed. Several folks with legacy space have conceded that they wouldn't object to $100 per year. I don't recall anyone else saying that this level of expense was a barrier. Like the scientific method, the assumption that $100/year is not an obstacle is based on available evidence, but if additional evidence is provided, the theory can be revised. > Personally, I'd like a clear idea of the costs involved to > run whatever service I am getting before I would say if $100 > was a good number or not. It may seem small to people with > large corporate budgets, but small non-profit organizations > tend to be misers with good reason. Until I've seen good > reason, I am not interested in spending $100/year. ARIN publishes its annual budget. http://www.arin.net/about_us/corp_docs/budget.html I believe the fee to be nominal, just enough to encourage organizations to check their records before sending in a check. I think that if you consider the costs of running IN-ADDR and WHOIS servers, with high availability and bandwidth, plus the support of the public policy development process, coordination with other organizations, and outreach (for instance, to legacy resource holders to let them know what's going on, or to everyone about the need for IPv6), $100 is pretty reasonable. An argument has been made that if one can't afford $100/year, one is unlikely to be able to afford the equipment requiring those addresses. An argument could also be made that an alternative exists: get address space (free) from an upstream. I don't usually make those arguments. Disclosure: I'm ARIN's Treasurer, and chair the Finance Committee. But I didn't ask them their opinion of this message. Lee From Lee.Howard at stanleyassociates.com Wed Aug 27 14:54:25 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 27 Aug 2008 14:54:25 -0400 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9022150F2@SUEXCL-02.ad.syr.edu> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B13B40D@CL-S-EX-1.stanleyassociates.com> > "Heroic" being a polite word for pulled out of one's a** and > patently unrealistic. > > Milton Mueller Please observe decorum. Lee From michael.dillon at bt.com Wed Aug 27 14:58:27 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 27 Aug 2008 19:58:27 +0100 Subject: [arin-ppml] FW: Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10A89@mail> Message-ID: > Alain, as a person from an ISP wouldn't the ability to sell > IPv4 resources freed up by a conversion to IPv6 add anything > to the incentives of ISPs to make the migration? Of course > that is more a matter for your business officers but I > suspect that it could make a difference. There is such a thing as "core business" and selling or buying of addresses is so far from the core of an ISP's business that I cannot imagine any ISP decision-makers even considering this as an incentive for more than a minute. The numbers just aren't big enough. Let's not forget that the ISP business is a subscription business where the customers keep on paying month after month for the term of the contract which is often greater than one year. And contracts tend to be renewed unless the ISP has done something bad. ISP business decision-makers are looking for recurring revenue opportunities, not the one time boost from selling of an IP address block. I'm quite sure that product managers will try to build IP address revenue into their business cases, but I would hope that the finance people catch this trick to disguise the true cost of their product plan. In most cases, the IP addresses don't belong to the product, i.e. it is the underlying network operations group that owns the addresses, and if there is some money to be made, those are the guys who will want to own the revenue in the same way that they sell off any other obsolete stuff. But if they do sell off some addresses, this is not going to be any incentive to new product deployment or at the board level, because it will be lost several levels deep in the financials. --Michael Dillon From plzak at arin.net Wed Aug 27 15:10:15 2008 From: plzak at arin.net (Ray Plzak) Date: Wed, 27 Aug 2008 15:10:15 -0400 Subject: [arin-ppml] Results of Transfer Proposal Survey In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9022150E8@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD9022150E8@SUEXCL-02.ad.syr.edu> Message-ID: > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Milton L Mueller > Sent: Wednesday, August 27, 2008 12:19 > To: ppml at arin.net > Subject: [arin-ppml] Results of Transfer Proposal Survey > No. When party A sells something to party B for consideration and > doesn't deliver it there is all kinds of legal recourse outside of the > ARIN regime. Speaking from experience as the CEO of ARIN, such legal activity can very quickly draw ARIN in the process by either one party or the other. Ray From tedm at ipinc.net Wed Aug 27 15:21:25 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 27 Aug 2008 12:21:25 -0700 Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation In-Reply-To: Message-ID: <84ED083B4FF7496EAC1B4F513BAFEE2B@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of michael.dillon at bt.com > Sent: Wednesday, August 27, 2008 12:55 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation > > > > Agreed. Although I did not add it to the proposal, I > > believe that > > ARIN staff would want to do the verification on a set > > date every year > > and make some sort of announcement every year before > > the verification, > > to try and help POCs be prepared to receive and respond to the > > verification email. Also, the same sender address > > should always be > > used, to allow whitelisting. Do you believe that this should be > > specified in the proposal? > > ~Chris > > > > > > Sure. Expected transmission dates as well as sender > > addresses would be good things to make known to potential > > recipients. Publishing them by email would probably be a > > dubious mechanism, since we're trying to mitigate the > > non-receipt of email in the first place. But the more paths > > for broadcast, the better, I suppose. > > > > Eric > > This discussion has now descended into the absurd. > > We are supposed to be discussing policy, not setting out > ARIN's processes and working practices. This whole issue > should be dealt with by one or more suggestions to the ARIN > suggestion box. > > If ARIN would add a "last contacted date" to the whois > database, and begin a process of contacting all orgs that > have not been contacted in over a year, this whole issue > would go away. > Well, Michael, you have a great point. In fact, I have copied and pasted your suggestion here into the ARIN suggestion webform and submitted it. Here is what I submitted: "If ARIN would add a "last contacted date" to the whois database, and begin a process of contacting all orgs that have not been contacted in over a year, it would help the rest of us who use the whois database." Per the suggestion response rules I will get a response within 10 days. I will post the response here. We will know within a month if ARIN wants this submitted via policy or your way - via suggestion. If ARIN takes me up on it, and implements the additional field before the meeting next year that would consider both Chris and my proposals, and starts filling it in, then I think that both Chris and I would withdraw both our proposals. But if they don't, then I think you better make up your mind which proposal to support. Or, tell the list the REAL reason you don't want the POC's e-mail addresses verified. Ted From owen at delong.com Wed Aug 27 15:26:55 2008 From: owen at delong.com (Owen DeLong) Date: Wed, 27 Aug 2008 12:26:55 -0700 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9022150E6@SUEXCL-02.ad.syr.edu> References: <3c3e3fca0808270824o7c0e6867h7668e8cd4cfdaed4@mail.gmail.com> <7663C7E01D8E094989CA62F0B0D21CD9022150E6@SUEXCL-02.ad.syr.edu> Message-ID: <8649E007-1BE9-48CB-9946-39CD9B22D2A0@delong.com> On Aug 27, 2008, at 9:06 AM, Milton L Mueller wrote: >> Then there is also those who say, me included, that a >> liberalized transfer >> policy will not solve the problem at all. > > No one in their right mind believes that a liberalized transfer policy > will "solve the problem" if "the problem" is IPv4 address scarcity. > What > it does is handle that scarcity in the most efficient manner over a > temporary (hopefully) period. I hope we can lay that straw man to > rest. The most efficient in this case being defined in terms of "Those addresses being reassigned to the highest bidder". It is not clear to me that the highest and best use of IP addresses can be measured by the dollars people are willing to commit to their possession. I realize that this flies in the face of many pro- capitalism pro-market, etc. types which abound here. I am not anti-capitalism or anti-market, but, I am not 100% convinced in either direction. > > People who believe in an IPv6 transition have to ask themselves what > happens 3 - 5 years from now when the migration is not complete and > the > free pool is exhausted. Apparently their "policy" is panic-based crash > IPv6 adoption by people who may or may not be ready. To have no policy > regarding the reclamation and transfer of available IPv4 resources > during that period is irresponsible. The idea that transfer policies > somehow delay the migration to IPv6 has been refuted in our paper. > There is an existing policy for the reclamation and transfer of IPv4 resources. Anyone who has IPv4 resources they do not need can turn them back in to ARIN or their local RIR for recycling at no cost. The RIRs will happily recycle any and all IP resources received. The fact that this policy does not provide adequate incentives to those holding the resources is, perhaps, a better description of the issue at hand? Owen From tedm at ipinc.net Wed Aug 27 15:31:07 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 27 Aug 2008 12:31:07 -0700 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <8649E007-1BE9-48CB-9946-39CD9B22D2A0@delong.com> Message-ID: <39C2B159EACD4998A2DA4109DE318B3A@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong > Sent: Wednesday, August 27, 2008 12:27 PM > To: Milton L Mueller > Cc: Stewart Dean; arin-ppml at arin.net > Subject: Re: [arin-ppml] Stepping forward,opening my mouth > and removing all doubt about > > > The most efficient in this case being defined in terms of "Those > addresses > being reassigned to the highest bidder". > > It is not clear to me that the highest and best use of IP > addresses can be measured by the dollars people are willing > to commit to their possession. Hear, hear!!! If you want to join an elitist network that costs a lot of money, signup with Compu$erve. I'll stay with the Internet, thank you. Ted From tedm at ipinc.net Wed Aug 27 15:33:21 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 27 Aug 2008 12:33:21 -0700 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <3c3e3fca0808271054j3d45c03ar6e0bc38245905bc7@mail.gmail.com> Message-ID: <2EDE637B040E45DEA32F3E2DBA990BAA@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin > Sent: Wednesday, August 27, 2008 10:54 AM > To: Alain Durand > Cc: Stewart Dean; arin-ppml at arin.net > Subject: Re: [arin-ppml] Stepping forward,opening my mouth > and removing all doubt about > > I think the idea that IPv6 will be capable of playing a role > in the solution is a crock and that the feared hording has > already happened by a few large ISPs who opted to use > globally routeable IP addresses instead of NATed systems > everywhere they could primarily because it leaves them in > control of huge swaths of address space. > I'm sure that has happened. But, once those hoarded addresses are sold on the open market, then shortly afterwards those hoarders will be using NATed systems everywhere, and the folks they sold the addresses to will be using NATed systems, and we will have succeeded only in delaying the inevitable for a short time. IPv6 is the only way. TEd From tedm at ipinc.net Wed Aug 27 15:55:20 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 27 Aug 2008 12:55:20 -0700 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <48B57EFF.9040901@sprunk.org> Message-ID: <2BFF70FB5D6F43C3B8CDA99E23369140@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Stephen Sprunk > Sent: Wednesday, August 27, 2008 9:21 AM > To: Alain Durand; ARIN PPML > Subject: Re: [arin-ppml] Stepping forward, opening my mouth > and removing all doubt about > > > Alain Durand wrote: > > On 8/27/08 11:24 AM, "William Herrin" wrote: > >> The proponents of a liberalized transfer policy say that the > >> inability to get new address from ARIN will bring a market > into being > >> regardless of what ARIN does. It falls to ARIN to > determine what the > >> constraints on the market process will be. Should it fail to act, > >> ARIN will lose its relevance as a resource steward and registry. > >> Address assignment will devolve into a poorly documented black or > >> gray market process in which everybody gets hurt. > >> > >> The opponents of a liberalized transfer policy say that everybody > >> should just switch to IPv6 which won't have this problem for many > >> decades. Liberalizing the transfer policy would dilute the urgency > >> behind deploying IPv6 and bring about all the problems the > existing > >> transfer policy is designed to prevent, like route > disaggregation and > >> hording. Everyone would be hurt by that in the end. > >> > > > > Then there is also those who say, me included, that a liberalized > > transfer policy will not solve the problem at all. Recent > ARIN stats > > showed that most addresses have been allocated in large or > very large > > blocks. This is a direct consequence of the market concentration. > > Other recent data showed that what would be potentially > available via > > a liberalized transfer policy would mostly be legacy Bs & Cs. Those > > blocks are simply too small to meet the global demand. > > > > OTOH, there are several large companies that have legacy As, which > currently have no incentive to return them to ARIN. Many > could renumber > into a /16 or less, using NAT, if only they had the financial > motivation > to incur that cost; ditto for the hundreds of companies sitting on > multiple Bs that could renumber into a /24 if motivated. Please don't use straw men. If you know of any, cite who they are. > However, that > still only buys us another year or two at current growth rates... > > Plus, I don't hear many folks here being sympathetic to the > big ISPs in > the first place, since they're the ones consuming most of the address > space and causing problems for the rest of us. This is not correct - those big ISP's are big because they have a lot of customers - those customers are the ones using the IP numbers. If you passed a law tomorrow that said all ISP's must shrink their customer base to 1000 customers or less, you would create huge amounts of free IPv4 numbers at the large ISPs - which would then have to be moved to the small ISP's that all the customers would have to move to - and thus you end up with no net gain in free IPv4. > These ISPs have the > market power to force their vendors to support IPv6, They do and they are. All major router vendors today support IPv6. And we are even starting to see IPv6-compliant code in SOHO routers now. All current Windows, Mac and UNIX os support IPv6. Where is this equipment that vendors aren't supporting IPv6 on that these big ISP's can apply pressure? That may have been true a few years ago but that ship has sailed. > which > would trickle > down to the smaller players, but so far there's been little visible > motion on that front. Please give examples, this is rediculous. Even the Ebay discards now from the bigger ISP's are supporting Ipv6. > They're the ones that are going to be hit the > hardest in the coming crunch, given their rates of > consumption, so they > _have_ to go to IPv6 with NAT-PT (or multi-layered IPv4 NAT) > in the near > future. Once they do, though, they could return most of their IPv4 > space, which would eliminate the address space depletion > problem for the > rest of the community... > If they go to NAT-PT or multilayer NAT it will be for their NEW customers, they won't be changing their legacy customers out. Doing this will not free up IPv4. > There are lots of paths out of this problem, and I'm sure that the > Internet will keep on working no matter which one we choose. > Transfers > seem to minimize short-term pain, but forcing a transition to > IPv6 would > minimize long-term pain. Do we have the guts, as Lincoln did, to > destroy the Internet in order to save it? WE can't force anything. When IPv4 runout happens, the most logical thing will be for the ISP's to tell BRAND NEW customers that they must use IPv6. This requirement will be SO NOT A PROBLEM for your typical Windows Vista user on a cable modem or DSL modem, the ISP will simply supply a bridged modem, and the user will plug their OS in and be able to surf the web and read e-mail as before. Who will get SCREWED are the customers who have OLD technology networks - like a shop full of Windows 98 systems and a NT4 server - and who are using IPv4 with an ISP, then for whatever reason get their panties in a twist at that ISP and decide they are going to sneak off in the middle of the night to one of that ISP's competitors. THOSE will be the folks screeching at their new ISP who is telling them they have to use IPv6 that to heck with you, we aren't going to forklift upgrade our network and pay all that money. Then they go down the street to yet another ISP who tells them the same thing. Well tough cookies, they shouldn't have left their first ISP in the beginning. The only really serious barrier I see to IPv6 on the Internet at this time is a handful of 2nd tier national networks who are still running IPv4 backbones and haven't yet picked up the cluephone. And that should be solved by their ISP customers insisting at contract renewal time that native IPv6 support be provided or they will not renew. And the more of the small ISPs we can educate about this, the faster that will happen. Ted From micah at riseup.net Wed Aug 27 16:28:14 2008 From: micah at riseup.net (Micah Anderson) Date: Wed, 27 Aug 2008 16:28:14 -0400 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9022150E6@SUEXCL-02.ad.syr.edu> References: <3c3e3fca0808270824o7c0e6867h7668e8cd4cfdaed4@mail.gmail.com> <7663C7E01D8E094989CA62F0B0D21CD9022150E6@SUEXCL-02.ad.syr.edu> Message-ID: <20080827202814.GG3875@pond.riseup.net> * Milton L Mueller [2008-08-27 09:06-0400]: > No one in their right mind believes that a liberalized transfer policy > will "solve the problem" if "the problem" is IPv4 address scarcity. What > it does is handle that scarcity in the most efficient manner over a > temporary (hopefully) period. I hope we can lay that straw man to rest. One could argue that handling the transition to IPv6 in the 'most efficient manner' possible might be the solution to "the problem" of IPv4 address scarcity and that the liberalized transfer policy seems to do nothing but delay and discourage that. > People who believe in an IPv6 transition have to ask themselves what > happens 3 - 5 years from now when the migration is not complete and the > free pool is exhausted. Apparently their "policy" is panic-based crash > IPv6 adoption by people who may or may not be ready. To have no policy > regarding the reclamation and transfer of available IPv4 resources > during that period is irresponsible. There has to be a deadline at some point, and those who are not ready will have to deal with that. Is almost 20 years (RFC 2460 was in 1996, if 5 years from now is 17 years) long enough or people to get ready? At what point do we decide its time to have a flag-day? Is it after the small folks have been squeezed out of the 'market-based economy' due to disparity? What possible motivation are the big corporations going to want to give up their market dominance? > The idea that transfer policies somehow delay the migration to IPv6 > has been refuted in our paper. With apologies to Milton L Mueller who in a previous message said something sort of like: It's great when Milton asserts something is true because he wrote it as true in his (sorta)analysis paper, and then fails to provide a reference to this paper. Its true because you said so? If you say so... but please at least reference your paper if you are goning to use it so authoritatively. micah From stephen at sprunk.org Wed Aug 27 16:39:10 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 27 Aug 2008 15:39:10 -0500 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <2BFF70FB5D6F43C3B8CDA99E23369140@tedsdesk> References: <2BFF70FB5D6F43C3B8CDA99E23369140@tedsdesk> Message-ID: <48B5BB6E.1000802@sprunk.org> Ted Mittelstaedt wrote: >> OTOH, there are several large companies that have legacy As, which >> currently have no incentive to return them to ARIN. Many >> could renumber into a /16 or less, using NAT, if only they had the financial motivation to incur that cost; ditto for the hundreds of companies sitting on multiple Bs that could renumber into a /24 if motivated. >> > > Please don't use straw men. If you know of any, cite who they are. > I can't cite specific examples because the details are covered by various NDAs that I'm subject to. I have no desire to be sued into bankruptcy by several dozen of the Fortune 100. If I were putting up a strawman, or proposing a hypothetical scenario, I would make that clear. In this case, I am giving aggregated facts as to what I have seen in practice. You could come to the same conclusion as to what is _likely_ by analyzing publicly-available data, but you couldn't be sure you were correct without seeing the other side of their firewall, as I have. >> These ISPs have the market power to force their vendors to support IPv6, >> > > They do and they are. All major router vendors today support IPv6. And we are even starting to see IPv6-compliant code in SOHO routers now. All current Windows, Mac and UNIX os support IPv6. > > Where is this equipment that vendors aren't supporting IPv6 on > that these big ISP's can apply pressure? > The desktop OS vendors are mostly there. The big router vendors are getting close. However, the little cable and DSL modem vendors, home firewall vendors, etc. are still absent from the game with the exception of Apple (kudos!). As a consumer, I have one DSL option and one cable option, and neither will even admit to having plans to roll out IPv6 -- ever. My 3G GSM provider doesn't do IPv6, though at least they'll say it's coming at some indeterminate point in the future. _Any_ of those companies could force their vendors to implement IPv6 if they chose to. How many millions more modems are they going to buy before they get around to marking IPv6 support "mandatory" on the RFP instead of "optional"? Business-class providers are doing better, but every week on NANOG I read responses about how various major ISPs don't do v6, only have it as an experimental service, require a second pipe, require special contract addenda, don't offer SLAs, etc. At least in that market, customers can choose to change providers; consumers can't, in general. >> They're the ones that are going to be hit the hardest in the coming crunch, given their rates of consumption, so they _have_ to go to IPv6 with NAT-PT (or multi-layered IPv4 NAT) in the near future. Once they do, though, they could return most of their IPv4 space, which would eliminate the address space depletion problem for the rest of the community... >> > > If they go to NAT-PT or multilayer NAT it will be for their NEW > customers, they won't be changing their legacy customers out. > Doing this will not free up IPv4. > Consumer service is all about cookie cutter designs. If they do all the testing necessary for NAT-PT or multi-layered NAT in one market, they're going to roll it out to every customer as their standard solution. At most, they might make non-NAT service a "business class" product and charge you five times as much for it, like most already do for static addresses. And why wouldn't they give back all the IPv4 space they don't need once they've completed the rollout? That'd cut down on their ARIN fees... >> There are lots of paths out of this problem, and I'm sure that the >> Internet will keep on working no matter which one we choose. Transfers >> seem to minimize short-term pain, but forcing a transition to IPv6 would >> minimize long-term pain. Do we have the guts, as Lincoln did, to destroy the Internet in order to save it? >> > > WE can't force anything. When IPv4 runout happens, the most logical > thing will be for the ISP's to tell BRAND NEW customers that they > must use IPv6. This requirement will be SO NOT A PROBLEM for your > typical Windows Vista user on a cable modem or DSL modem, the > ISP will simply supply a bridged modem, and the user will plug > their OS in and be able to surf the web and read e-mail as before. > None of the four major ISPs (any given area has a duopoly, but which two varies) where I live will give a "bridged" modem to customers. They're all routers, with no way to turn NAT off. A firmware update is needed to add v6 support, but that same firmware update would get rolled out to _every_ customer for support reasons. You'd need to add v6 in every CO/headend for "new" customers to be able to work, so why not enable it for "old" ones too? And, after that, why keep giving the "old" customers v4 addresses? S From bmanning at vacation.karoshi.com Wed Aug 27 17:00:05 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 27 Aug 2008 21:00:05 +0000 Subject: [arin-ppml] flogging IPv6 Message-ID: <20080827210005.GA23940@vacation.karoshi.com.> others are doing a fine job of promoting IPv6 (see below). ARIN (imho) should not promote IPv6 as much as create reasonable policies on IPv6 management. --bill (speaking for myslef) ----- from the IAB ---- One common theme was that, as with many technological advances, success stories in IPv6 adoption are frequently the result of one or two motivated individuals who take the initiative to make things happen in their organization. If you yourself have worked on "throwing the IPv6 switch" within your organization, or you know of someone with an interesting IPv6 adoption story, the IAB invites you to let us know about it, including issues overcome, or hurdles still before you. Send your story to: ipv6-adoption at iab.org The IAB will deliver a summary report on these stories at a future IETF meeting. On the universal deployment of IPv6[*], -- For the IAB Olaf Kolkman PS: Want to make a difference? A brainstorm of ideas follow: * Share the slides and a report of the plenary session with the networking lead in your organization's IT department. * Personally request IPv6 service from your ISP and enable IPv6 for your home network. * Prepare your laptop for IPv6 and primarily use the IPv6 network at IETF 73. * If you work on application code, make sure your application works with IPv6, and if not, fix it. (Even if you don't test wide-area IPv6, at the very least make sure your application works with IPv6 link-local addresses, which are configured automatically these days on Mac OS X and Windows.) * Start using IPv6 operationally within your organization. [*] There is an old tradition to toast on "the Universal Deployment of IPv6" during the the IETF Scotch BOFs. With that in mind we plan to provide the best story with a bottle of single malt. ------------ From bill at herrin.us Wed Aug 27 17:32:20 2008 From: bill at herrin.us (William Herrin) Date: Wed, 27 Aug 2008 17:32:20 -0400 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <2BFF70FB5D6F43C3B8CDA99E23369140@tedsdesk> References: <48B57EFF.9040901@sprunk.org> <2BFF70FB5D6F43C3B8CDA99E23369140@tedsdesk> Message-ID: <3c3e3fca0808271432o297630efod4efcc35a1e92a3a@mail.gmail.com> On Wed, Aug 27, 2008 at 3:55 PM, Ted Mittelstaedt wrote: > This is not correct - those big ISP's are big because they have a > lot of customers - those customers are the ones using the IP numbers. Ted, I have yet to connect to a residential Internet service (be it 56k modem, DSL or cable) that has assigned me an RFC1918 address. The blackberry on my belt even appears to be using its own globally routeable IP address. How many hundreds of millions of addresses are consumed by similar uses? Is it your position that more than 10% of those users would be inconvenienced by having an RFC 1918 address behind a NAT box instead? I recently had the opportunity to do some passive traffic analysis on one of the California POPs for a major DSL provider. Just under a /14 of addresses was routed to this POP. That's around a quarter million addresses. The grand total number of unique addresses observed sending traffic this March? Less than 6000. That's the -reality- of address assignment at the mega-ISPs, and if it's even within an order of magnitude of typical then we have decades of addresses available for IPv4 just by recovering the waste. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Lee at dilkie.com Wed Aug 27 17:56:53 2008 From: Lee at dilkie.com (Lee Dilkie) Date: Wed, 27 Aug 2008 17:56:53 -0400 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: <20080827174232.GA3875@pond.riseup.net> References: <48B45FEB.2090406@sprunk.org> <20080826235015.02CED4500F@ptavv.es.net> <20080827174232.GA3875@pond.riseup.net> Message-ID: <48B5CDA5.2070703@dilkie.com> Micah Anderson wrote: > People keep saying this about the $100, as if this was well > established fact, based on some data. Why do people keep asserting > this, I'd like to know what I missed. > Many months ago I asserted that I *do* have a problem with $100/yr for simply maintaining a whois and reverse lookup database. The cost is excessive for such an obviously trival task (considering the infrequency of changes). Other will, and have, pointed out that ARIN spends lots of $ vetting new assignments and that's where the money goes. To which I answered, what does that have to do with me? If new assignments cost more to approve than they used to, then those costs should be born by the new assignees, much like land development charges that cities apply to new development projects. > Personally, I'd like a clear idea of the costs involved to run > whatever service I am getting before I would say if $100 was a good > number or not. It may seem small to people with large corporate > budgets, but small non-profit organizations tend to be misers with > good reason. Until I've seen good reason, I am not interested in > spending $100/year. > agreed. -lee From bmanning at vacation.karoshi.com Wed Aug 27 18:00:20 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 27 Aug 2008 22:00:20 +0000 Subject: [arin-ppml] Legacy space holders were a big part of the community... i.e. all of it. In-Reply-To: <48B45616.30549.5A340F6@farmer.umn.edu> References: <48B45616.30549.5A340F6@farmer.umn.edu> Message-ID: <20080827220020.GE23940@vacation.karoshi.com.> On Tue, Aug 26, 2008 at 07:14:30PM -0500, David Farmer wrote: > > > > It is a very relevant point, since almost all of those same legacy > > holders were certainly part of the consensus decision in 1993 to > > change the basic IP address structure to allow variable sized > > blocks (aka "CIDR") and the matching matching address allocation > > policies (RFC1466/RFC1518/RFC1519). These documents state that > > an organization should receive sufficient address space to meet > > two years worth of organization need, so that we could "delay > > depletion of the IP address space". > > > > The community of the legacy space allocation era actually already > > reached consensus years ago that variable-sized blocks were needed > > and that organizational allocations based on two years of need > > were > > most appropriate. They just forgot to return their own extra > > space, > > for reasons unknown, > > With twenty-twenty hind sight, I think maybe this should have happened. > But I can't find anything explicitly calling for this at the time. Most of the stuff > I have found was really focused forward, but that is probably natural, that is > where the cliff was. Do you know of anything calling for what are now > classful legacy resources to be repartitioned with CIDR and excess > resources to be returned? Especially from the mid-to late 90's time frame, > but even from their early 2000's. RFC 1797 and the IETF PIER WG archives > ======================================================= > David Farmer Email: farmer at umn.edu > Office of Information Technology > Networking & Telecomunication Services > University of Minnesota Phone: 612-626-0815 > 2218 University Ave SE Cell: 612-812-9952 > Minneapolis, MN 55414-3029 FAX: 612-626-1818 > ======================================================= > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From alain_durand at cable.comcast.com Wed Aug 27 18:34:47 2008 From: alain_durand at cable.comcast.com (Alain Durand) Date: Wed, 27 Aug 2008 18:34:47 -0400 Subject: [arin-ppml] IANA IPv4 /8 burn rate.... (was Re: Stepping forward, opening my mouth and removing all doubt about) In-Reply-To: <48B57EFF.9040901@sprunk.org> Message-ID: On 8/27/08 12:21 PM, "Stephen Sprunk" wrote: >> Then there is also those who say, me included, that a liberalized transfer >> policy will not solve the problem at all. Recent ARIN stats showed that most >> addresses have been allocated in large or very large blocks. This is a >> direct consequence of the market concentration. Other recent data showed >> that what would be potentially available via a liberalized transfer policy >> would mostly be legacy Bs & Cs. Those blocks are simply too small to meet >> the global demand. >> > > OTOH, there are several large companies that have legacy As, which > currently have no incentive to return them to ARIN. Many could renumber > into a /16 or less, using NAT, if only they had the financial motivation > to incur that cost; ditto for the hundreds of companies sitting on > multiple Bs that could renumber into a /24 if motivated. However, that > still only buys us another year or two at current growth rates... In 2007, IANA has delegated 13 /8 to the 5 combined RIR. This burn rate has been increasing year over year. Now, can someone tell me with a straight face that there will be the equivalent of at least 13 /8 every year made available from "liberalized transfer"? - Alain. From sleibrand at internap.com Wed Aug 27 19:02:12 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 27 Aug 2008 16:02:12 -0700 Subject: [arin-ppml] IANA IPv4 /8 burn rate.... (was Re: Stepping forward, opening my mouth and removing all doubt about) In-Reply-To: References: Message-ID: <48B5DCF4.3070009@internap.com> Alain, You're missing the point. If IPv4 addresses are free (as they are now), of course everyone will use a lot of them. When they become scarce and expensive, people will start conserving IPv4. Some will be able to conserve more than others, and a liberalized transfer policy will encourage them to free those addresses up and transfer them to someone who needs them more. (And yes, at least in the commercial world, "need" roughly equates to "willingness to pay" for them.) In basic microeconomics, quantity supplied equals quantity demanded at the price and quantity where the supply and demand curves intersect. Expecting that quantity to be the same in a market under conditions of scarcity (where the price is non-zero) as in a non-market distribution system based on abundance (where the price is zero) makes no sense unless the demand is completely inelastic (which it's clearly not). -Scott Alain Durand wrote: > On 8/27/08 12:21 PM, "Stephen Sprunk" wrote: > >>> Then there is also those who say, me included, that a liberalized transfer >>> policy will not solve the problem at all. Recent ARIN stats showed that most >>> addresses have been allocated in large or very large blocks. This is a >>> direct consequence of the market concentration. Other recent data showed >>> that what would be potentially available via a liberalized transfer policy >>> would mostly be legacy Bs & Cs. Those blocks are simply too small to meet >>> the global demand. >>> >> OTOH, there are several large companies that have legacy As, which >> currently have no incentive to return them to ARIN. Many could renumber >> into a /16 or less, using NAT, if only they had the financial motivation >> to incur that cost; ditto for the hundreds of companies sitting on >> multiple Bs that could renumber into a /24 if motivated. However, that >> still only buys us another year or two at current growth rates... > > In 2007, IANA has delegated 13 /8 to the 5 combined RIR. This burn rate has > been increasing year over year. > > Now, can someone tell me with a straight face that there will be the > equivalent of at least 13 /8 every year made available from "liberalized > transfer"? > > - Alain. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From tedm at ipinc.net Wed Aug 27 19:05:46 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 27 Aug 2008 16:05:46 -0700 Subject: [arin-ppml] IANA IPv4 /8 burn rate.... (was Re: Stepping forward, opening my mouth and removing all doubt about) In-Reply-To: Message-ID: <0872EEBE15934C60977381DB1F29F771@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Alain Durand > Sent: Wednesday, August 27, 2008 3:35 PM > To: Stephen Sprunk; ARIN PPML > Subject: [arin-ppml] IANA IPv4 /8 burn rate.... (was Re: > Stepping forward, opening my mouth and removing all doubt about) > > > In 2007, IANA has delegated 13 /8 to the 5 combined RIR. This > burn rate has been increasing year over year. > > Now, can someone tell me with a straight face that there will > be the equivalent of at least 13 /8 every year made available > from "liberalized transfer"? Oh didn't you know? It's when they open up those class E addresses, there's 13 /8's up there... HAW! ;-) (I almost made it with a straight face) Ted From tedm at ipinc.net Wed Aug 27 19:14:55 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 27 Aug 2008 16:14:55 -0700 Subject: [arin-ppml] IANA IPv4 /8 burn rate.... (was Re: Stepping forward, opening my mouth and removing all doubt about) In-Reply-To: <48B5DCF4.3070009@internap.com> Message-ID: <0E9AFED7A08B4566A79CDE80F22686B2@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand > Sent: Wednesday, August 27, 2008 4:02 PM > To: Alain Durand > Cc: ARIN PPML > Subject: Re: [arin-ppml] IANA IPv4 /8 burn rate.... (was Re: > Stepping forward, opening my mouth and removing all doubt about) > > > Alain, > > You're missing the point. If IPv4 addresses are free (as > they are now), > of course everyone will use a lot of them. When they become > scarce and > expensive, people will start conserving IPv4. Some will be able to > conserve more than others, and a liberalized transfer policy will > encourage them to free those addresses up and transfer them > to someone who > needs them more. (And yes, at least in the commercial world, "need" > roughly equates to "willingness to pay" for them.) > However what you succeed in doing is then creating hundreds of dis-contiguous little subnets which will all create the need for their own separate little BGP advertisements, when you gather together all these unused little bits and odds and ends of subnets. Kind of like gathering up all the bits of soap in the house and mashing them into one "bar" If there were a horde of small little ISPs out there all needing IPv4, who right now we were slicing little subnets off of the big block of soap, this might make sense. But post IPv4 runout we won't have that, we will just have large porky ISP's still needing huge hunks of soap at roughly the same rate they were using them before. And how many mashed-together soap bars will we have to give them before all the little pieces of soap in the house are gone, I wonder? And how clean will the result be? Ted From farmer at umn.edu Wed Aug 27 19:17:35 2008 From: farmer at umn.edu (David Farmer) Date: Wed, 27 Aug 2008 18:17:35 -0500 Subject: [arin-ppml] Legacy space holders were a big part of the community... i.e. all of it. In-Reply-To: <20080827220020.GE23940@vacation.karoshi.com.> References: , <48B45616.30549.5A340F6@farmer.umn.edu>, <20080827220020.GE23940@vacation.karoshi.com.> Message-ID: <48B59A3F.287.4BC0911@farmer.umn.edu> On 27 Aug 2008 bmanning at vacation.karoshi.com wrote: > On Tue, Aug 26, 2008 at 07:14:30PM -0500, David Farmer wrote: > > On 23 Aug 2008 John Curran wrote: > > > It is a very relevant point, since almost all of those same legacy > > > holders were certainly part of the consensus decision in 1993 to > > > change the basic IP address structure to allow variable sized > > > blocks (aka "CIDR") and the matching matching address allocation > > > policies (RFC1466/RFC1518/RFC1519). These documents state that an > > > organization should receive sufficient address space to meet two > > > years worth of organization need, so that we could "delay > > > depletion of the IP address space". > > > > > > The community of the legacy space allocation era actually already > > > reached consensus years ago that variable-sized blocks were needed > > > and that organizational allocations based on two years of need > > > were most appropriate. They just forgot to return their own extra > > > space, for reasons unknown, > > > > With twenty-twenty hind sight, I think maybe this should have > > happened. But I can't find anything explicitly calling for this at > > the time. Most of the stuff I have found was really focused > > forward, but that is probably natural, that is where the cliff was. > > Do you know of anything calling for what are now classful legacy > > resources to be repartitioned with CIDR and excess resources to be > > returned? Especially from the mid-to late 90's time frame, but even > > from their early 2000's. > > > RFC 1797 and the IETF PIER WG archives RFC 1797 - Class A Subnet Experiment We this is an experiment, it is related, but it doesn't have a call to do anything. However, with the pointer to IETF PIER WG, I found RFC 1879, and RFC 1917. Thanks Bill, it wasn't a direct reference but it got me there. RFC1879 - Class A Subnet Experiment Results and Recommendations It says we can do it but still doesn't call to action. "Recommendations: The RFC 1797 experiment appears to have been a success. We believe it safe to start carving up "Class A" space, if the spaces are delegated according to normal IR conventions [7] and recommend the IANA consider this for future address delegations." RFC1917 - An Appeal to the Internet Community to Return Unused Here we go this is it I know it had to be there some place. FYI, it is BCP 4 by the way "4. Appeal To the members of the Internet community who have IP network assignments which may be currently unused, the Internet community would like to encourage you to return those addresses to the IANA or your provider for reapportionment. Specifically those sites who have networks which are unused are encouraged to return those addresses. Similarly to those sites who are using a small percentage of their address space and who could relatively easily remove network assignments from active use, the Internet community encourages such efforts. To those sites who have networks which will never need to connect to the global Internet, or for security reasons will always be isolated, consider returning the address assignments to the IANA or your provider and utilizing prefixes recommended in RFC 1597. In those cases where renumbering is required, sites are encouraged to put into place a plan to renumber machines, as is reasonably convenient, and work towards minimizing the number of routes advertised to their providers." So for the record, Randy, myself (my employer actaully), and many other Legacy holders are evil incarnate because we have ignored RFC 1917 and BCP 4 and not returned our unused address space. :) But even more interesting is what follows: "4.1 Suggestions to Providers Many providers are currently advertising non-CIDR routes which encompass a large block of addresses, ie any Class A (0/1) or Class B (128/2) space. Some customers who are only using a percentage of their address space (assuming they are subnetting using contiguous bits) may be willing to allow usage of the upper portion of their assigned address space by their providers other customers. This scheme requires certain elements be installed or already in place to get the routing correct, but has the potential to gain the use of a large number of small networks without growth of the global routing tables. This would require additional measures of cooperation between providers and their customers but could prove to have both economic advantages, as well as good Internet citizen standing." So why aren't the "Black Market IP Traders" just not following BCP 4, and according to this quote "good Internet citizen(s)"? And why wouldn't a Liberalized Transfer Policy be better that this? Why isn't having this recoded in the registry is a much better idea? In my gut I still don't like the idea of a Liberalized Transfer Policy, but there are lots of things I don't like in my gut that work perfectly fine. For me personally the above are interesing questions, can you help answer them? ======================================================= David Farmer Email: farmer at umn.edu Office of Information Technology Networking & Telecomunication Services University of Minnesota Phone: 612-626-0815 2218 University Ave SE Cell: 612-812-9952 Minneapolis, MN 55414-3029 FAX: 612-626-1818 ======================================================= From tvest at pch.net Wed Aug 27 20:26:22 2008 From: tvest at pch.net (Tom Vest) Date: Wed, 27 Aug 2008 20:26:22 -0400 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9022150F2@SUEXCL-02.ad.syr.edu> References: <3c3e3fca0808270824o7c0e6867h7668e8cd4cfdaed4@mail.gmail.com> <7663C7E01D8E094989CA62F0B0D21CD9022150EC@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD9022150F2@SUEXCL-02.ad.syr.edu> Message-ID: On Aug 27, 2008, at 2:46 PM, Milton L Mueller wrote: > It's great when Tom forwards these lengthy (sorta)economic analyses > and > one can refute them in one sentence. > > And here it is: > if ISPs can game the migration process in the way he predicts, then > they > don't need transfer markets to do it. Hi Milton, Sorry if that excerpt taxed your attention span. Seriously though, you might want to try reading a little more carefully before responding. Nobody said that anybody was out to intentionally "game" the migration process. Remember, this is a forum composed almost exclusively of presumptive "gamers", as you might call them. Accusing your audience of willful malfeasance wouldn't exactly be the smartest way to make your case. But I encourage you to give it a try.* You might also try to learn a little more about the incentive structure in this industry before making such broad and absolute pronouncements. >> The key ingredient in this perverse mix is not the scarcity of IPv4 >> itself, but rather the continued scarcity of substitutable Internet >> content and services that require no IPv4 at all - i.e., that are >> transparently accessible by IPv6-only networks. Knowing this, every >> prospective IPv4 seller-cum-service provider could face strong >> individual disincentives to migrate their own online content and >> services to IPv6, or otherwise make such resources transparently >> accessible to pure IPv6-based operators. > > Note that this supposed "disincentive" exists whether or not there are > ipv4 transfer markets. Apparently, some operators don't think so, right now. But you do know better, don't you? Here's a hint: http://en.wikipedia.org/wiki/Unintended_consequence > Note that the concentration of ipv4 resources he fears could be > achieved > via acquistions under the current regime. Really? I suppose those thousands of M&A transactions wouldn't raise an eyebrow. In fact, your refutation makes me wonder why there are any economic regulations at all in any sector -- you can outlaw something or you can incentivize it, the results will be the same. Somebody call Washington! > Note also that the analysis _assumes_ that the price of IPv4 addresses > "increases in perpetuity." A strong, what we call "heroic" assumption. I guess you're hoping here that others are as "casual" in their reading and interpretation as you apparently are. I'm happy to let those who actually read to decide for themselves. > "Heroic" being a polite word for pulled out of one's a** and patently > unrealistic. Now that's an interesting accusation coming from you. I pull things like this out of memory, and basic common sense, tempered by actual industry experience doing strategic things, in this very industry, and working with/observing others doing the same kind of job(s) for peer institutions. Remind me again, what's your basis for judging what's realistic and unrealistic in this specific context? > Milton Mueller > Professor, Syracuse University School of Information Studies > XS4All Professor, Delft University of Technology > ------------------------------ > Internet Governance Project: > http://internetgovernance.org > > >> -----Original Message----- >> From: Tom Vest [mailto:tvest at pch.net] >> Sent: Wednesday, August 27, 2008 1:24 PM >> To: Milton L Mueller >> Cc: Alain Durand; arin-ppml at arin.net >> Subject: Re: [arin-ppml] Stepping forward, opening my mouth >> and removing all doubt about >> >> From a forthcoming paper: >> >> "One author believes that there is a >> significant risk that introduction of a transfer market may >> substantially increase incentives to delay conversion to IPv6, and >> quite possibly derail it altogether. This prediction is based on the >> hypothesis that the establishment of a market for IPv4 >> transfers will >> present every individual IPv4-based network operator capable of >> providing Internet services with a mix of incentives that is broadly >> weighted toward, and cumulatively strengthened over time, by the >> perpetuation of IPv4's status as critical, non-substitutable (i.e., >> "bottleneck") input for Internet service delivery. >> >> On this argument, individual IPv4-based incumbents facing the >> certainty of one-time returns resulting from an immediate >> simple sale >> and transfer of surplus IPv4, might opt instead to postpone any sale >> as long as transfer prices appear to be stable or appreciating, with >> any resulting opportunity costs being offset by the steady stream of >> recurring revenues that could be realized by making the surplus IPv4 >> addresses accessible only as an indivisible part of a "bundled" >> Internet service (e.g., IPv6-IPv4 translation or IPv4 transit). As >> long as the market for simple transfers and critical IPv4-related >> services continues to appreciate - or at minimum, simple transfer >> prices do not clearly depreciate below the medium-term gains >> achievable in the bundled IPv4 services market - simple sale >> would be >> irrational. As long as simple IPv4 transfers remain a sub-optimal >> strategy for potential sellers, and IPv4 continues to be >> sought by at >> least some growing ISPs -- and remains an absolutely >> non-substitutable >> requirement for aspiring new Internet service providers -- >> prices are >> likely to continue appreciating, in perpetuity. >> >> In turn, this appreciation would encourage surplus IPv4 to become >> increasingly concentrated amongst providers of bundled IPv4 >> services, >> both through successful bargaining and competition for the remaining >> liquid IPv4 addresses, and by the gradual adoption of increasingly >> attractive IPv4 service-centered business models by large, >> independent >> IPv4 reserve holders that previously provided networking >> services only >> to themselves. >> > The cumulative >> result of such >> individual-level dynamics would be an indefinite postponement >> of, and >> active resistance to any IPv6 transition by the same institutions >> whose strategies, decisions, and investments will ultimately >> determine >> when, how, or whether such a transition will actually happen." >> >> TV >> >> On Aug 27, 2008, at 1:01 PM, Milton L Mueller wrote: >> >>> >>> Alain, as a person from an ISP wouldn't the ability to sell IPv4 >>> resources freed up by a conversion to IPv6 add anything to the >>> incentives of ISPs to make the migration? Of course that is more a >>> matter for your business officers but I suspect that it could make a >>> difference. >>> >>>> -----Original Message----- >>>> From: arin-ppml-bounces at arin.net >>>> Recent ARIN stats showed that most addresses have been >>>> allocated in large or very large blocks. This is a >>>> direct consequence of the market concentration. Other recent >>>> data showed that what would be potentially available via a >>>> liberalized >>> >>>> transfer policy would mostly be legacy Bs & Cs. >>>> Those blocks are simply too small to meet >>>> the global demand. >>>> >>>> - Alain. >>>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. * "RB Benediction," (TM) Randy Bush From cliffb at cjbsys.bdb.com Wed Aug 27 20:41:08 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Wed, 27 Aug 2008 20:41:08 -0400 (EDT) Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives Message-ID: <200808280041.m7S0f8QX002816@cjbsys.bdb.com> With regards to the $100.00 per year number, I like what I'm paying now which is $0.00. But while it seems like the status quo is good for me for some time in the future, it's probably not the "right thing". I look at our cell phone (tracfone pay as you go) and it costs us just over $100.00 per year ($105.00 with tax) for the annual card. It's 4 meals at TGIF/RubyTuesday/Applebees for my wife and I. It's realistically peanuts if it helps keep ARIN running better. Is it the right number? Who knows but it's in the right order of magnitude so I can live with it. My problem is with the existing LRSA which is why I sent in the Alternative LRSA/LRSA-lite. Cliff -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From sleibrand at internap.com Wed Aug 27 20:46:45 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 27 Aug 2008 17:46:45 -0700 Subject: [arin-ppml] Further revisions to 2008-2? In-Reply-To: <0E9AFED7A08B4566A79CDE80F22686B2@tedsdesk> References: <0E9AFED7A08B4566A79CDE80F22686B2@tedsdesk> Message-ID: <48B5F575.2000001@internap.com> Yes, there are definitely some valid concerns I share regarding deaggregation, and the possibility that action taken to reduce the impact of IPv4 exhaustion may slow down IPv6 adoption. However, on balance I think we can address most of the deaggregation concerns with the restrictions in 2008-2, and I think it will do more good (in reducing transition costs) than harm (in extending the transition over a longer timeframe). But in addition to (re)debating those points, I'd love to hear any further feedback on how folks think we should revise 2008-2. There will be a consensus call on it at L.A., and I'd like to have the best possible proposal on the table when we get to that point. -Scott Ted Mittelstaedt wrote: > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net >> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand >> Sent: Wednesday, August 27, 2008 4:02 PM >> To: Alain Durand >> Cc: ARIN PPML >> Subject: Re: [arin-ppml] IANA IPv4 /8 burn rate.... (was Re: >> Stepping forward, opening my mouth and removing all doubt about) >> >> >> Alain, >> >> You're missing the point. If IPv4 addresses are free (as >> they are now), >> of course everyone will use a lot of them. When they become >> scarce and >> expensive, people will start conserving IPv4. Some will be able to >> conserve more than others, and a liberalized transfer policy will >> encourage them to free those addresses up and transfer them >> to someone who >> needs them more. (And yes, at least in the commercial world, "need" >> roughly equates to "willingness to pay" for them.) >> > > However what you succeed in doing is then creating hundreds of > dis-contiguous little subnets which will all create the need > for their own separate little BGP advertisements, when you > gather together all these unused little bits and odds and > ends of subnets. Kind of like gathering up all the bits of > soap in the house and mashing them into one "bar" > > If there were a horde of small little ISPs out there all needing > IPv4, who right now we were slicing little subnets off of the > big block of soap, this might make sense. > > But post IPv4 runout we won't have that, we will just have large > porky ISP's still needing huge hunks of soap at roughly the > same rate they were using them before. And how many mashed-together > soap bars will we have to give them before all the little pieces > of soap in the house are gone, I wonder? And how clean will > the result be? > > Ted > From tedm at ipinc.net Thu Aug 28 01:07:31 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 27 Aug 2008 22:07:31 -0700 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <3c3e3fca0808271432o297630efod4efcc35a1e92a3a@mail.gmail.com> Message-ID: > -----Original Message----- > From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf > Of William Herrin > Sent: Wednesday, August 27, 2008 2:32 PM > To: Ted Mittelstaedt > Cc: ARIN PPML > Subject: Re: [arin-ppml] Stepping forward, opening my mouth > and removing all doubt about > > > On Wed, Aug 27, 2008 at 3:55 PM, Ted Mittelstaedt > wrote: > > This is not correct - those big ISP's are big because they > have a lot > > of customers - those customers are the ones using the IP numbers. > > Ted, > > I have yet to connect to a residential Internet service (be > it 56k modem, DSL or cable) that has assigned me an RFC1918 > address. The blackberry on my belt even appears to be using > its own globally routeable IP address. > > How many hundreds of millions of addresses are consumed by > similar uses? > > Is it your position that more than 10% of those users would > be inconvenienced by having an RFC 1918 address behind a NAT > box instead? > No, however the issue is that with those large ISP's almost certainly a percentage of their customers are running some app that is dependent on a public IP. The large ISPs do not want to have to deal with the thousands of irate phone calls that would result out of their million+ customer base if they just arbitrairly switched people over to private IP numbers. Now, this does not mean that they couldn't do a gradual switchover, I agree. But I don't agree that it is for us to force them to do it. > I recently had the opportunity to do some passive traffic > analysis on one of the California POPs for a major DSL > provider. Just under a /14 of addresses was routed to this > POP. That's around a quarter million addresses. The grand > total number of unique addresses observed sending traffic > this March? Less than 6000. > > That's the -reality- of address assignment at the mega-ISPs, > and if it's even within an order of magnitude of typical then > we have decades of addresses available for IPv4 just by > recovering the waste. > Hey, I was running NAT even before Cisco had it in their code, I was running the set of patches for divert sockets on the FreeBSD 2.1 kernel back when most people thought a NAT was a little bug that flew around annoying people - and I had a 50 person/100+ host business behind it which I was admining years before I ever worked for an ISP. And it worked great. So your not going to find anyone who is more familiar with the great things IPv4 NAT can do. BUT - the fact of the matter is that stateful inspection of packets through a firewall shouldn't require this icky disgusting rewriting of source IP addresses. NAT is a transition technology and it has a lot more years left in it, but we cannot lose sight of the fact that it is a hack, despite our amazement that the elephant can actually dance. And you do not lay the foundations of a stable Internet on a hack. Yes, IPv6 conversion is not simple. Hell, our largest upstream feed promised me last year they would have native IPv6 running by now. I contacted them a few months ago and I got a song and dance about how they would have to charge us more money - turns out that rather than do what they said they would do, they lined up some IPv6 tunnel brokers with the intent to have their customers pay extra money for tunnelling. Screw that. Fortunately, all our contracts with them are coming due this fall. We need to continue the slow slogging towards IPv6 - everyone does, really. Consider that we are at a nexus point in the growth of the Internet. One path leads down the NAT trail and the other leads down the IPv6 trail. It is just like the automotive industry, which is facing a similar nexus. One path leads down squeezing even more mpg out of our gasburners, and drilling anywhere we can find a scrap of oil, and putting coal-to-oil schemes online asap. The other path leads to hybrids, then plug-in-hybrids, then finally electric passenger cars, with wind generation by the utilities supplying the grid power. If we keep doing what we are doing with IPv4 it will be easier for a while - just as if we just keep squeezing the gasoline infrastructure in passenger car vehicles it will be easier for a while. If we go full-bore damn-the-torpedos into IPv6 it will be much more difficult right away but better in the long run. Just like converting the passenger car fleet to electric will leave plenty of diesel for the long haul trucks and give us enough time to get freight infrastructure back on to rail. But, you cannot make the IPv4 infrastructure last another 20 years, just as we can't make gasoline powered passenger cars last another 20 years. Bill, I don't know how old you are but I am too young to be from the original generation that got the Internet going, I'm not from the Jon Postel generation. But I am too old to be from the YouTube generation. I have a foot both in the old guard, as I can remember what the green-screen days were like, I've actually seen a VAX boot up - yet I'm also helping people today to run Flash and their digital cameras and all of that. My generation knows both the Internet Generation That Was, and the Internet Generation That Is To Come. It is my generation's responsibility to take the same care of the Internet that the Generation That Was took care of when they handed it over to us, and took their millions and retired early. When we got it, sure it was warty - SMTP with big holes that spammers exploited, and legacy IP number holders who are ghosts in the machine - but by and large it was OK. Your asking my generation to committ a terribly immoral act by making the very fabric of the Internet dependent on a cheap hack. Are we to then hand a huge messy hairball over to The Internet Generation That Is To Come for them to untangle? It really saddens me that so many people see only the short term IPv4 solutions of a few dozen years at most and run pell-mell towards them. Although with the shoddy leadership of the last 8 years in the US government setting a spectacular example of short-term-solutions, I guess I shouldn't be too surprised. Ted From tedm at ipinc.net Thu Aug 28 01:12:22 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 27 Aug 2008 22:12:22 -0700 Subject: [arin-ppml] Further revisions to 2008-2? In-Reply-To: <48B5F575.2000001@internap.com> Message-ID: <06883533F2614F508C56A91CCA7301FD@tedsdesk> Then I would encourage you to get your rewrite done asap, so the rewrite can be further debated and examined. Every day that you do not post a rewrite merely makes people think that your uninterested in suggestions. Ted > -----Original Message----- > From: Scott Leibrand [mailto:sleibrand at internap.com] > Sent: Wednesday, August 27, 2008 5:47 PM > To: Ted Mittelstaedt > Cc: 'ARIN PPML' > Subject: Further revisions to 2008-2? > > > Yes, there are definitely some valid concerns I share regarding > deaggregation, and the possibility that action taken to > reduce the impact > of IPv4 exhaustion may slow down IPv6 adoption. However, on > balance I > think we can address most of the deaggregation concerns with the > restrictions in 2008-2, and I think it will do more good (in reducing > transition costs) than harm (in extending the transition over > a longer > timeframe). > > But in addition to (re)debating those points, I'd love to > hear any further > feedback on how folks think we should revise 2008-2. There will be a > consensus call on it at L.A., and I'd like to have the best possible > proposal on the table when we get to that point. > > -Scott > > Ted Mittelstaedt wrote: > > > >> -----Original Message----- > >> From: arin-ppml-bounces at arin.net > >> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand > >> Sent: Wednesday, August 27, 2008 4:02 PM > >> To: Alain Durand > >> Cc: ARIN PPML > >> Subject: Re: [arin-ppml] IANA IPv4 /8 burn rate.... (was Re: > >> Stepping forward, opening my mouth and removing all doubt about) > >> > >> > >> Alain, > >> > >> You're missing the point. If IPv4 addresses are free (as > >> they are now), > >> of course everyone will use a lot of them. When they become > >> scarce and > >> expensive, people will start conserving IPv4. Some will > be able to > >> conserve more than others, and a liberalized transfer policy will > >> encourage them to free those addresses up and transfer them > >> to someone who > >> needs them more. (And yes, at least in the commercial > world, "need" > >> roughly equates to "willingness to pay" for them.) > >> > > > > However what you succeed in doing is then creating hundreds of > > dis-contiguous little subnets which will all create the > need for their > > own separate little BGP advertisements, when you gather > together all > > these unused little bits and odds and ends of subnets. > Kind of like > > gathering up all the bits of soap in the house and mashing > them into > > one "bar" > > > > If there were a horde of small little ISPs out there all > needing IPv4, > > who right now we were slicing little subnets off of the big > block of > > soap, this might make sense. > > > > But post IPv4 runout we won't have that, we will just have > large porky > > ISP's still needing huge hunks of soap at roughly the same > rate they > > were using them before. And how many mashed-together soap > bars will > > we have to give them before all the little pieces of soap > in the house > > are gone, I wonder? And how clean will the result be? > > > > Ted > > > From sleibrand at internap.com Thu Aug 28 01:15:18 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 27 Aug 2008 22:15:18 -0700 Subject: [arin-ppml] Further revisions to 2008-2? In-Reply-To: <06883533F2614F508C56A91CCA7301FD@tedsdesk> References: <06883533F2614F508C56A91CCA7301FD@tedsdesk> Message-ID: <48B63466.3010705@internap.com> When we (the AC) discussed it, we had hoped to get feedback from the community on what people thought the results of the survey meant, and how we should modify 2008-2 to reflect it. We've gotten some of that already, which is good. If anyone else has any other constructive input, I'd love to hear it. We'll definitely be posting a revised 2008-2 soon, giving plenty of time to debate further. -Scott Ted Mittelstaedt wrote: > Then I would encourage you to get your rewrite done asap, so > the rewrite can be further debated and examined. Every day > that you do not post a rewrite merely makes people think > that your uninterested in suggestions. > > Ted > >> -----Original Message----- >> From: Scott Leibrand [mailto:sleibrand at internap.com] >> Sent: Wednesday, August 27, 2008 5:47 PM >> To: Ted Mittelstaedt >> Cc: 'ARIN PPML' >> Subject: Further revisions to 2008-2? >> >> >> Yes, there are definitely some valid concerns I share regarding >> deaggregation, and the possibility that action taken to >> reduce the impact >> of IPv4 exhaustion may slow down IPv6 adoption. However, on >> balance I >> think we can address most of the deaggregation concerns with the >> restrictions in 2008-2, and I think it will do more good (in reducing >> transition costs) than harm (in extending the transition over >> a longer >> timeframe). >> >> But in addition to (re)debating those points, I'd love to >> hear any further >> feedback on how folks think we should revise 2008-2. There will be a >> consensus call on it at L.A., and I'd like to have the best possible >> proposal on the table when we get to that point. >> >> -Scott >> >> Ted Mittelstaedt wrote: >>>> -----Original Message----- >>>> From: arin-ppml-bounces at arin.net >>>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand >>>> Sent: Wednesday, August 27, 2008 4:02 PM >>>> To: Alain Durand >>>> Cc: ARIN PPML >>>> Subject: Re: [arin-ppml] IANA IPv4 /8 burn rate.... (was Re: >>>> Stepping forward, opening my mouth and removing all doubt about) >>>> >>>> >>>> Alain, >>>> >>>> You're missing the point. If IPv4 addresses are free (as >>>> they are now), >>>> of course everyone will use a lot of them. When they become >>>> scarce and >>>> expensive, people will start conserving IPv4. Some will >> be able to >>>> conserve more than others, and a liberalized transfer policy will >>>> encourage them to free those addresses up and transfer them >>>> to someone who >>>> needs them more. (And yes, at least in the commercial >> world, "need" >>>> roughly equates to "willingness to pay" for them.) >>>> >>> However what you succeed in doing is then creating hundreds of >>> dis-contiguous little subnets which will all create the >> need for their >>> own separate little BGP advertisements, when you gather >> together all >>> these unused little bits and odds and ends of subnets. >> Kind of like >>> gathering up all the bits of soap in the house and mashing >> them into >>> one "bar" >>> >>> If there were a horde of small little ISPs out there all >> needing IPv4, >>> who right now we were slicing little subnets off of the big >> block of >>> soap, this might make sense. >>> >>> But post IPv4 runout we won't have that, we will just have >> large porky >>> ISP's still needing huge hunks of soap at roughly the same >> rate they >>> were using them before. And how many mashed-together soap >> bars will >>> we have to give them before all the little pieces of soap >> in the house >>> are gone, I wonder? And how clean will the result be? >>> >>> Ted >>> > From michael.dillon at bt.com Thu Aug 28 06:03:24 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 28 Aug 2008 11:03:24 +0100 Subject: [arin-ppml] Policy Proposal: Annual WHOIS POC Validation In-Reply-To: <84ED083B4FF7496EAC1B4F513BAFEE2B@tedsdesk> Message-ID: > Or, tell the list the REAL reason > you don't want the POC's e-mail addresses verified. The real reason is that email sucks as a universal contact method. It may have been a good idea, and one that actually worked, back in the early 1990's when everyone on the Internet had an email address and used it. But today, lots of people don't even use email. They use IM, they use Twitter, they post comments on each others' blogs. The bottom line here is that there is a benefit to us if every org with IP address blocks is *CONTACTABLE*. There is no real benefit to specifying the method of contact. Even many of the blocks with a valid working email address, actually go to some email robot which perhaps opens a low priority ticket which some low-level front-line support person *MAY* pass on to a relevant party if it suits them, or they may just close that ticket to keep their stats looking good. It would be reasonable for ARIN to begin by populating that "last contacted date" with the most recent of (last bill payment date, last conference registration date, last application for resources date). It would be an awfully good idea for ARIN to keep track of all contact info in their internal db, things like IM addresses, phone numbers, personal email addresses, and anything else that organizations may give to them. It would be very nice if members in good standing could send a message (via email or a web form) to ARIN for relaying to whatever contact means is available. A service like that might encourage more orgs to give ARIN their secret 3rd level support numbers, or personal email addresses of clued individuals. --Michael Dillon From michael.dillon at bt.com Thu Aug 28 06:09:32 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 28 Aug 2008 11:09:32 +0100 Subject: [arin-ppml] Fantasyland In-Reply-To: <48B57EFF.9040901@sprunk.org> Message-ID: > OTOH, there are several large companies that have legacy As, > which currently have no incentive to return them to ARIN. > Many could renumber into a /16 or less, using NAT, if only > they had the financial motivation to incur that cost; ditto > for the hundreds of companies sitting on multiple Bs that > could renumber into a /24 if motivated. How many dollars would it take to convince a single company to renumber from a /16 into a /24? Actual dollars please. > However, that still > only buys us another year or two at current growth rates... Too true. Now consider the cost that this same company will incur to renumber into IPv6 two years after renumbering into a /24 using NAT. Can you justify this extra cost? Why shouldn't the company in question just deploy IPv6 and install NAT-PT gateways to cover the next 2-3 years before IPv6 transit is widely available? --Michael Dillon From bmanning at vacation.karoshi.com Thu Aug 28 06:17:11 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 28 Aug 2008 10:17:11 +0000 Subject: [arin-ppml] Fantasyland In-Reply-To: References: <48B57EFF.9040901@sprunk.org> Message-ID: <20080828101711.GA30839@vacation.karoshi.com.> On Thu, Aug 28, 2008 at 11:09:32AM +0100, michael.dillon at bt.com wrote: > > Why shouldn't the company in question just deploy IPv6 and > install NAT-PT gateways to cover the next 2-3 years before > IPv6 transit is widely available? > > --Michael Dillon > _______________________________________________ Yo! Mr. Dillon! Please provide a vendor list for NAT-PT gateways that provide production level service/availability - today. --bill From cliffb at cjbsys.bdb.com Thu Aug 28 07:09:33 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Thu, 28 Aug 2008 07:09:33 -0400 (EDT) Subject: [arin-ppml] Further revisions to 2008-2? Message-ID: <200808281109.m7SB9YtF008664@cjbsys.bdb.com> After reading all the debate about 2008-2, I'll offer the following thoughts. I think overall the policy will help more than it hurts. Think of it as needing a gallon of gas to get to the dealer to trade in your old clunker (v4) for the hot new car on the lot (v6). I think ARIN should not refer in any way to auctioning/selling/etc of IP addresses. It should simply be a modification of the rules to allow a direct transfer of addresses between two elegible parties. That way all the debate about "selling" and "property" etc can be avoided. All current restrictiona about numbers not being property will be maintained. I believe any entity receiving addresses under this policy must qualify for them in the same way they do under existing policy. I believe the only qualification for a transferor should be a reasonably good provenence showing the address space is theirs to transfer. I have mixed feelings about ARIN getting involved with the listing of addresses offered for transfer. I was originally against it but if ARIN only lists addresses that meet the provenence clause, that would ease many people's minds about the legitimacy of the addresses offered. I worry about ARIN getting caught up in lawsuits when things get tight and people get desparate. I don't think the policy should become effective until some reasonably low level of available "free" addresses has been reached. Doing it sooner could put conflicting policies in place. Although if the quilifications section remain the same for transferees, the market may take care of itself. If I have to qualify for/justify addresses under either method of getting addresses, who's going to pay for addresses when they can get them for free. Alternatively, if we have reached the arbitrary low level of available address space, maybe the transferee wouldn't need to justify the space and only the transferor's provenence would need to be checked. It should be one or the other else "spammers/other bad guys" could buy space now with no justification and make life more miserable. I am not really knowledgeable enough to know where the deagregation point is but I think there should be a point below which now transfer should not be allowed if it will cause major changes to the routing tables. Worst case scenario is all the holders of /24s that are not now routed being offered and trying to fit them in the tables. However, an existing routed /24 would probably be ok. My $.03 worth (inflation) Cliff -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From michael.dillon at bt.com Thu Aug 28 07:03:29 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 28 Aug 2008 12:03:29 +0100 Subject: [arin-ppml] Fantasyland In-Reply-To: <20080828101711.GA30839@vacation.karoshi.com.> Message-ID: > > Why shouldn't the company in question just deploy IPv6 and install > > NAT-PT gateways to cover the next 2-3 years before > > IPv6 transit is widely available? > Please provide a vendor list for NAT-PT gateways that > provide production level service/availability - today. I would hope that the company in question would plan their deployment exercise and not just rush out buying equipment and blasting out their old network. As part of the planning exercise, they might go to the ARIN IPv6 wiki at where they will note vendor names. If they contact said vendors, then there is motivation for said vendors to provide production level service and availabilty within the timeframe for implementation. Note that there is also the possibility of consulting firms using open-source NAT-PT who would then provide the SLA and support component. Obviously, today, there is only one vendor on that page and no mention of where open-source NAT-PT can be found. I would hope that anyone with more information would log on to the wiki and update this page and others. I recently discovered that there were a couple of people in my company who test and qualify DSL equipment for use on our IPv4 Broadband Internet service. I asked them whether they were asking the vendors for their IPv6 roadmaps considering that IPv4 exhaustion is only 2 to 3 years away. They were surprised but thanked me for the info on exhaustion and told me that they plan to ask all the DSL vendors which they deal with, about their IPv6 roadmap. More people need to do stuff like this, instead of just passively noting that vendor X does not support feature Y which you need to deploy IPv6. We can't just keep on sitting on our hands. We need to pester the vendors to supply the features that we need. We have to deploy IPv6 in our labs and find out what works and what doesn't. We need to ask our product managers why they haven't incorporated IPv4 exhaustion and IPv6 deployment into their product roadmaps. In fact, a lot of companies are already doing all of these things, which is good but since it is simmering under the surface, many observers still think that the world is behind on IPv6. I don't think that it is as bad as that. What has really happened is that telco work practices now rule the Internet, and just as the telco Internet deployment plans simmered under the surface throughout the mid 90's before bursting out and consuming the Internet industry, now the same is happening with v6. The difference is that there is no thriving independent IPv6 ISP industry today, so when we compare the external appearance of things with 1995, it looks worse than it really is. --Michael Dillon From alain_durand at cable.comcast.com Thu Aug 28 08:29:33 2008 From: alain_durand at cable.comcast.com (Alain Durand) Date: Thu, 28 Aug 2008 08:29:33 -0400 Subject: [arin-ppml] IANA IPv4 /8 burn rate.... (was Re: Stepping forward, opening my mouth and removing all doubt about) In-Reply-To: <48B5DCF4.3070009@internap.com> Message-ID: On 8/27/08 7:02 PM, "Scott Leibrand" wrote: > In basic microeconomics, quantity supplied equals quantity demanded at the > price and quantity where the supply and demand curves intersect. > Expecting that quantity to be the same in a market under conditions of > scarcity (where the price is non-zero) as in a non-market distribution > system based on abundance (where the price is zero) makes no sense unless > the demand is completely inelastic (which it's clearly not). I disagree with your last point, the demand seems to be pretty much inelastic. It is fuelled by the growth of the Internet. The fact that some historical allocations were not as efficiently made as they are today should not fool you into thinking that recent allocations are not efficient either. - Alain. From iljitsch at muada.com Thu Aug 28 08:41:35 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 28 Aug 2008 14:41:35 +0200 Subject: [arin-ppml] IANA IPv4 /8 burn rate.... (was Re: Stepping forward, opening my mouth and removing all doubt about) In-Reply-To: <48B5DCF4.3070009@internap.com> References: <48B5DCF4.3070009@internap.com> Message-ID: <35071283-7887-496F-ADAA-FF7EEB5487BD@muada.com> On 28 aug 2008, at 1:02, Scott Leibrand wrote: > You're missing the point. If IPv4 addresses are free (as they are > now), > of course everyone will use a lot of them. When they become scarce > and > expensive, people will start conserving IPv4. How is that a good thing? IPv6 addresses are free, because whatever the cost is, after dividing by the number of addresses you get for that cost you're left with pretty much only zeros. So if we start using IPv6, we can use as many addresses as we feel is useful, while if we stay with IPv4 we should be happy to pay a lot because then we get to say with IPv4... Trying to stretch IPv4 is both a bad idea and pointless. It's a bad idea because then we have to suffer address scarcity for even longer. It's pointless because it won't work. Even with all this NAT and the restrictive RIR rules and procedures, we ended up using up a hair shy of 200 million fresh addresses last year, and more than 130 million so far this year. There is no way you can turn this rate into something that can be sustained from the deflation of IPv4 by letting out the air that's in there. What we should do is try to make the switch to IPv6 as painless as we can. The most important part of that is to make it predictable: we need to know what's going to happen in the next 5 years or so. Any policy change means that there will be a bigger difference between what's being predicted and what will happen, so all policy changes are at least somewhat harmful, and potentially very harmful. So we should only make the ones that are extremely obvious wins. From pauldotwall at gmail.com Thu Aug 28 09:01:20 2008 From: pauldotwall at gmail.com (Paul Wall) Date: Thu, 28 Aug 2008 09:01:20 -0400 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) Message-ID: <620fd17c0808280601o1b0b2182n81bb0f530a5898ce@mail.gmail.com> "Milton L Mueller" writes: > If you want to understand what I am trying to tell you, stop thinking > like a techie and start thinking like a policy person. Milton, At the risk of starting a flame war, I'd sure appreciate it if you didn't address your colleagues here in the same dismissive condescending tone that I understand you use with your students. It tends to overshadow the important points you make when you're less than cordial and respectful. Drive Slow, Paul Wall From iljitsch at muada.com Thu Aug 28 08:50:52 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 28 Aug 2008 14:50:52 +0200 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9022150E6@SUEXCL-02.ad.syr.edu> References: <3c3e3fca0808270824o7c0e6867h7668e8cd4cfdaed4@mail.gmail.com> <7663C7E01D8E094989CA62F0B0D21CD9022150E6@SUEXCL-02.ad.syr.edu> Message-ID: On 27 aug 2008, at 18:06, Milton L Mueller wrote: > People who believe in an IPv6 transition have to ask themselves what > happens 3 - 5 years from now when the migration is not complete and > the > free pool is exhausted. Apparently their "policy" is panic-based crash > IPv6 adoption by people who may or may not be ready. To have no policy > regarding the reclamation and transfer of available IPv4 resources > during that period is irresponsible. Not at all. We are currently approaching a brick wall at a relatively modest pace. We all know what needs to be done, and there is still time to get 90% of what needs to be done in place before we hit that wall. Making IPv4 tradable means that our trajectory towards the wall will change in ways that we can't predict. The wall is still going to be there so we still need to plan for that collision, the only difference is that now we don't know when that will happen. Some think it will be later than it would be without the policy change and that that's enough of an advantage to take the risk, but I disagree: it buys us little and we risk a lot. From bill at herrin.us Thu Aug 28 10:12:24 2008 From: bill at herrin.us (William Herrin) Date: Thu, 28 Aug 2008 10:12:24 -0400 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: References: <3c3e3fca0808271432o297630efod4efcc35a1e92a3a@mail.gmail.com> Message-ID: <3c3e3fca0808280712v23df6875k978151b86744f91a@mail.gmail.com> On Thu, Aug 28, 2008 at 1:07 AM, Ted Mittelstaedt wrote: >> Is it your position that more than 10% of those users would >> be inconvenienced by having an RFC 1918 address behind a NAT >> box instead? > > No, however the issue is that with those large ISP's almost > certainly a percentage of their customers are running some app > that is dependent on a public IP. My guess puts it at 3% to 5% but let's use 10% for our calculations just to be on the safe side. That's the maximum number of folks choose to use applications which either fail or function suboptimally when behind a typical NAT firewall. > The large ISPs do not want > to have to deal with the thousands of irate phone calls that > would result out of their million+ customer base if they > just arbitrairly switched people over to private IP numbers. > > Now, this does not mean that they couldn't do a gradual > switchover, I agree. But I don't agree that it is for > us to force them to do it. A liberalized transfer policy doesn't force anyone to do anything. What it does do is enable an ISP to reap a benefit from making the effort to use RFC 1918 addresses. > BUT - the fact of the matter is that stateful inspection > of packets through a firewall shouldn't require this icky > disgusting rewriting of source IP addresses. NAT is a > transition technology and it has a lot more years left in > it, but we cannot lose sight of the fact that it is a hack, > despite our amazement that the elephant can actually dance. > And you do not lay the foundations of a stable Internet > on a hack. Actually, that icky rewriting is a benefit from a network security perspective. NAT has a tendency to fail closed while non-translating firewalls have a tendency to fail open. But that's beside the point. No one is extolling the merits of ditching IPv6 in favor of a NAT-based Internet. What we are saying is that it is essentially impossible to achieve sufficiently ubiquitous IPv6 deployment in the next 3 years as to allow IPv6-only deployments to customers. Ain't gonna happen. Get past it and realize that however fast or slow IPv6 is deployed, we're going to need an interim solution so that until the long term solution is ubiquitously usable the folks who -can't- engineer their systems to use NAT still have a viable way to get IPv4 addresses. > Your asking my generation to committ a terribly immoral act > by making the very fabric of the Internet dependent on a cheap > hack. Providing a working interim solution between depletion of the IPv4 free pool and whatever long term solution comes next is an -immoral- act? That is an astonishing claim. On Thu, Aug 28, 2008 at 8:50 AM, Iljitsch van Beijnum wrote: > Making IPv4 tradable means that our trajectory towards the wall will change > in ways that we can't predict. We went through this pretty extensively last year. Control of IPv4 addresses can be legitimately traded now using The Ruse and The Container Sale. No one is proposing that we suddenly make IPv4 tradable; for all practical purposes it already is. One point of a liberalized transfer policy is to give ARIN better control over the trading process so that the community can avoid the more egregious abuses (like heavy disaggregation). Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From kkargel at polartel.com Thu Aug 28 10:25:57 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 28 Aug 2008 09:25:57 -0500 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <3c3e3fca0808280712v23df6875k978151b86744f91a@mail.gmail.com> References: <3c3e3fca0808271432o297630efod4efcc35a1e92a3a@mail.gmail.com> <3c3e3fca0808280712v23df6875k978151b86744f91a@mail.gmail.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10A91@mail> >>My guess puts it at 3% to 5% but let's use 10% for our calculations just to be on the safe side. That's the maximum number of folks choose >>to use applications which either fail or function suboptimally when behind a typical NAT firewall. Speaking as a system administrator for an ISP.. The number of customers who during the course of a year use applications that would be negatively affected by nat is more in the range of 80 to 100 %.. Flame this if you want.. I am speaking from experience having tried it.. Instant messaging with file sharing, online gaming (like yahoo and msn games), game consoles, p2p applications, web cam videoconference, VOIP, VPN, followed by a host of other applications.. Almost all of my residential customers use one or more applications in this ilk at least occasionally.. Business customers would actually have an easier time with NAT than residential customers. Business customers prefer to avoid the p2p apps anyway, and would be more willing to invest in the one time network configurations to get their VPN's to work behind a NAT.. Though they are still stuck if they want to use VOIP to connect offices.. Many VOIP and some VPN implementations cannot even survive the overhead required for PPPoE, much less the complexities of NAT. I am not saying this is how it should or has to be, just how it is.. Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3107 bytes Desc: not available URL: From iljitsch at muada.com Thu Aug 28 10:47:10 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 28 Aug 2008 16:47:10 +0200 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <3c3e3fca0808280712v23df6875k978151b86744f91a@mail.gmail.com> References: <3c3e3fca0808271432o297630efod4efcc35a1e92a3a@mail.gmail.com> <3c3e3fca0808280712v23df6875k978151b86744f91a@mail.gmail.com> Message-ID: <8F8BCCAE-B795-4483-A5DD-F1A43F80B520@muada.com> On 28 aug 2008, at 16:12, William Herrin wrote: > My guess puts it at 3% to 5% but let's use 10% for our calculations > just to be on the safe side. That's the maximum number of folks choose > to use applications which either fail or function suboptimally when > behind a typical NAT firewall. Give them all NAT and magically the number of people running NAT- incompatible applications shrinks to 0%. We'd be doing those misguided individuals who try to use these apps today a favor, really. > A liberalized transfer policy doesn't force anyone to do anything. > What it does do is enable an ISP to reap a benefit from making the > effort to use RFC 1918 addresses. You mean: give them an incentive to break connectivity for their existing customers. ISP-provided NAT is a lot worse than the NAT people run themselves because opening up ports is much harder or may even be impossible. > What we are saying is > that it is essentially impossible to achieve sufficiently ubiquitous > IPv6 deployment in the next 3 years as to allow IPv6-only deployments > to customers. Ain't gonna happen. Spoken like a true poster from the top level domain of one of only three places in the world that haven't embraced the metric system yet. No matter how much time you allot, IPv6 deployment will never be "sufficiently ubiquitous" because there are always holdouts. With NAT-PT-like mechanisms there is no need for all current IPv4 users to switch to IPv6, but new users can be given IPv6 and be translated by their ISPs with only a very small number of IPv4 addresses. I see no reason why this couldn't be put in place within 3 years. > we're going to need an interim solution You mean on top of current address conserving technologies such as: - ethernet switching - VLSM - CIDR - NAT At some point you'll have to make peace with the fact that IPv4 can't power the internet anymore. > We went through this pretty extensively last year. Control of IPv4 > addresses can be legitimately traded now using The Ruse and The > Container Sale. No one is proposing that we suddenly make IPv4 > tradable; for all practical purposes it already is. One point of a > liberalized transfer policy is to give ARIN better control over the > trading process so that the community can avoid the more egregious > abuses (like heavy disaggregation). Oh right, because ARIN is in charge of aggregation. I forgot that. Actually the RIR policies that try to promote aggregation are harmful. See this presentation that I did at the LACNIC meeting (the prefix growing stuff): http://www.bgpexpert.com/presentations/lacnic-ivb-ipv6-routingtable.pdf What needs to happen is that people return address space when they are no longer using it in accordance with the relevant policies so it can be given to others. About 10 million addresses per year are returned, which is enough to keep giving out > /16 prefixes for years to come. The big ISPs that need /12s etc won't be able to get those for prices that they can't afford if there is trading anyway, because freeing up these amounts of legacy space requires expensive audits to make sure that it's really no longer in use so the minimum price will be sufficiently high that ISPs can't afford millions of those kinds of addresses. Address trading would do nothing for us except waste a lot of time and resources and make a few people rich who don't deserve it. And it could lock up otherwise useful address space. From tvest at pch.net Thu Aug 28 11:03:21 2008 From: tvest at pch.net (Tom Vest) Date: Thu, 28 Aug 2008 11:03:21 -0400 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <3c3e3fca0808280712v23df6875k978151b86744f91a@mail.gmail.com> References: <3c3e3fca0808271432o297630efod4efcc35a1e92a3a@mail.gmail.com> <3c3e3fca0808280712v23df6875k978151b86744f91a@mail.gmail.com> Message-ID: <64B35A94-F830-4BAA-8E68-1F91EDB69905@pch.net> On Aug 28, 2008, at 10:12 AM, William Herrin wrote: > On Thu, Aug 28, 2008 at 1:07 AM, Ted Mittelstaedt > wrote: >>> Is it your position that more than 10% of those users would >>> be inconvenienced by having an RFC 1918 address behind a NAT >>> box instead? >> >> No, however the issue is that with those large ISP's almost >> certainly a percentage of their customers are running some app >> that is dependent on a public IP. > > My guess puts it at 3% to 5% but let's use 10% for our calculations > just to be on the safe side. That's the maximum number of folks choose > to use applications which either fail or function suboptimally when > behind a typical NAT firewall. > > >> The large ISPs do not want >> to have to deal with the thousands of irate phone calls that >> would result out of their million+ customer base if they >> just arbitrairly switched people over to private IP numbers. >> >> Now, this does not mean that they couldn't do a gradual >> switchover, I agree. But I don't agree that it is for >> us to force them to do it. > > A liberalized transfer policy doesn't force anyone to do anything. > What it does do is enable an ISP to reap a benefit from making the > effort to use RFC 1918 addresses. > > >> BUT - the fact of the matter is that stateful inspection >> of packets through a firewall shouldn't require this icky >> disgusting rewriting of source IP addresses. NAT is a >> transition technology and it has a lot more years left in >> it, but we cannot lose sight of the fact that it is a hack, >> despite our amazement that the elephant can actually dance. >> And you do not lay the foundations of a stable Internet >> on a hack. > > Actually, that icky rewriting is a benefit from a network security > perspective. NAT has a tendency to fail closed while non-translating > firewalls have a tendency to fail open. > > But that's beside the point. No one is extolling the merits of > ditching IPv6 in favor of a NAT-based Internet. What we are saying is > that it is essentially impossible to achieve sufficiently ubiquitous > IPv6 deployment in the next 3 years as to allow IPv6-only deployments > to customers. Ain't gonna happen. Get past it and realize that however > fast or slow IPv6 is deployed, we're going to need an interim solution > so that until the long term solution is ubiquitously usable the folks > who -can't- engineer their systems to use NAT still have a viable way > to get IPv4 addresses. > > > >> Your asking my generation to committ a terribly immoral act >> by making the very fabric of the Internet dependent on a cheap >> hack. > > Providing a working interim solution between depletion of the IPv4 > free pool and whatever long term solution comes next is an -immoral- > act? That is an astonishing claim. > > > On Thu, Aug 28, 2008 at 8:50 AM, Iljitsch van Beijnum > wrote: >> Making IPv4 tradable means that our trajectory towards the wall >> will change >> in ways that we can't predict. > > We went through this pretty extensively last year. Control of IPv4 > addresses can be legitimately traded now using The Ruse and The > Container Sale. No one is proposing that we suddenly make IPv4 > tradable; for all practical purposes it already is. One point of a > liberalized transfer policy is to give ARIN better control over the > trading process so that the community can avoid the more egregious > abuses (like heavy disaggregation). Hi Bill, Could you provide pointers to where this was discussed extensively last year? I've tried to point out some potential issues at the mike or on this list since 2008-2 was introduced, but I don't recall much related discussion going back that far. I also don't think that many of the concerns that I have raised have been addressed fully, much less discredited. I still don't understand how one reconciles the two conflicting beliefs (a) that a transfer policy is essential because people will violate any transfer restrictions if that serves their private interests, and (b) transfer participants will comply with all transfer- related policy restrictions even if they if they conflict with their private interests. Why does that make sense? My impression is that the proposal counts on the benefits of ongoing RIR registration and whois to haul most of the freight -- i.e., to keep transactions within the regulated channel, to assure ongoing compliance after transfers have occurred, etc. That faith seems a little incongruous today, given the fact that whois is widely assumed to be full of cruft, and to have been even worse before RIR mechanisms like subsequent allocation reviews and annual renewal fees helped to establish some basis for evaluating even minimum accuracy -- conditions that will be roughly similar to the post-runout world. The mixed views that some express about resource certification leave the impression that some people still view whois and identifiability in general (or beyond bilateral relationships with direct peers, customers, and providers) as more of a liability than an advantage. Matters would probably be dramatically different if res cert was already widely accepted, adopted, and clearly/solidly anchored at some level where ongoing uniqueness and public identifiability was assured, but since it's not I don't think it can be or should be assumed as a feature of the transfer market at this point. Thanks, Tom > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From bill at herrin.us Thu Aug 28 11:22:02 2008 From: bill at herrin.us (William Herrin) Date: Thu, 28 Aug 2008 11:22:02 -0400 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <64B35A94-F830-4BAA-8E68-1F91EDB69905@pch.net> References: <3c3e3fca0808271432o297630efod4efcc35a1e92a3a@mail.gmail.com> <3c3e3fca0808280712v23df6875k978151b86744f91a@mail.gmail.com> <64B35A94-F830-4BAA-8E68-1F91EDB69905@pch.net> Message-ID: <3c3e3fca0808280822v26e76997o535a9a1378b19328@mail.gmail.com> On Thu, Aug 28, 2008 at 11:03 AM, Tom Vest wrote: > Could you provide pointers to where this was discussed extensively last > year? > I've tried to point out some potential issues at the mike or on this list > since 2008-2 was introduced, but I don't recall much related discussion > going back that far. Tom, Refer to: http://lists.arin.net/pipermail/ppml/2007-July/008275.html http://lists.arin.net/pipermail/ppml/2007-August/008310.html > I still don't understand how one reconciles the two conflicting beliefs (a) > that a transfer policy is essential because people will violate any transfer > restrictions if that serves their private interests, and (b) transfer > participants will comply with all transfer-related policy restrictions even > if they if they conflict with their private interests. Why does that make > sense? Folks will comply with whatever set of constraints is the least onerous. The Container Sale takes a lot of effort to set up and the Ruse has some stability problems over time. A liberalized transfer policy need only be "better" than one of those two to draw in the folks who seek IP addresses. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Thu Aug 28 11:25:22 2008 From: bill at herrin.us (William Herrin) Date: Thu, 28 Aug 2008 11:25:22 -0400 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A063141066A10A91@mail> References: <3c3e3fca0808271432o297630efod4efcc35a1e92a3a@mail.gmail.com> <3c3e3fca0808280712v23df6875k978151b86744f91a@mail.gmail.com> <70DE64CEFD6E9A4EB7FAF3A063141066A10A91@mail> Message-ID: <3c3e3fca0808280825j255bec99oa77ae8abe2295a9e@mail.gmail.com> On Thu, Aug 28, 2008 at 10:25 AM, Kevin Kargel wrote: > Speaking as a system administrator for an ISP.. The number of customers who > during the course of a year use applications that would be negatively > affected by nat is more in the range of 80 to 100 %.. > > Flame this if you want.. I am speaking from experience having tried it.. Kevin, Would you settle for questions which challenge you to document your claims instead? > Instant messaging Which widely used IM systems do you find have trouble when the clients are behind a NAT firewall? Certainly not AIM, Yahoo messenger, Google chat or IRC. DCC has some issues, but now you've crossed into P2P file transfer rather than IM. > online gaming (like yahoo and msn games), Which Yahoo or MSN games malfunction when access is attempted from behind a NAT firewall? >game consoles, Which game consoles malfunction when access is attempted from behind a NAT firewall? The standard deployment for DSL and cable modems is to send out a "DSL router" which implements a local NAT firewall and all three manufacturers knew that when they designed the current generation of consoles. Would you have us believe that Microsoft, Sony and Nintendo built and deployed game consoles which require extraordinary action to get on the Internet? > VOIP, Other than Skype (see P2P apps), what widely used VOIP services malfunction when the client is behind a NAT firewall? Definately not Vonage. I used it for years behind NAT+PPPoE. > VPN, Which widely used VPN client products malfunction when the client is behind a NAT firewall? Certainly not Microsoft's PPtP client nor Cisco's VPN client nor open source solutions like OpenVPN. I've used all of these without difficulty from behind NAT firewalls. > p2p applications, > web cam videoconference, And you believe that more than 80% of your users use applications in these two categories? What's your basis for this claim? Have your surveyed your users? Performed traffic analysis to match well known applications to user accounts? > followed by a host of other applications.. Almost all of my residential > customers use one or more applications in this ilk at least occasionally. Not unless your user base is comprised of a disproportionate number of techies. I'll concede that possibility, but if true it negates the utility of your observations for establishing a baseline for the percentage of users who directly need globally routable IP addresses. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Thu Aug 28 11:26:46 2008 From: owen at delong.com (Owen DeLong) Date: Thu, 28 Aug 2008 08:26:46 -0700 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <3c3e3fca0808280712v23df6875k978151b86744f91a@mail.gmail.com> References: <3c3e3fca0808271432o297630efod4efcc35a1e92a3a@mail.gmail.com> <3c3e3fca0808280712v23df6875k978151b86744f91a@mail.gmail.com> Message-ID: <369DB83A-DFDE-4F97-9EF7-498E50FDE492@delong.com> On Aug 28, 2008, at 7:12 AM, William Herrin wrote: > On Thu, Aug 28, 2008 at 1:07 AM, Ted Mittelstaedt > wrote: >>> Is it your position that more than 10% of those users would >>> be inconvenienced by having an RFC 1918 address behind a NAT >>> box instead? >> >> No, however the issue is that with those large ISP's almost >> certainly a percentage of their customers are running some app >> that is dependent on a public IP. > > My guess puts it at 3% to 5% but let's use 10% for our calculations > just to be on the safe side. That's the maximum number of folks choose > to use applications which either fail or function suboptimally when > behind a typical NAT firewall. > Let's put it closer to 75%. Here's a list of popular things that function sub-optimally behind NAT: 1. Pick your favorite IM 2. VOIP (when it doesn't break outright) 3. P2P applications of various types -- Regardless of what you think of P2P filesharing, there are a number of additional P2P applications that have legitimate purposes and there are, frankly, many more legitimate P2P file shares than illegal ones. For example, virtually every linux distro has a bit torrent available. 4. Voice and Video chats. 5. SSH I'm willing to bet at least 75% of users use one or more of these on almost daily basis. Things which break behind NAT: 1. Inbound access to your machine from somewhere else. (Remote desktop, SSH, Web Server, etc.) Lots of people would _LIKE_ to do these things if they could, and, even more would be upset if it was suddenly taken away from them. Hence, I argue that your 10% figure is... optimistic. > >> BUT - the fact of the matter is that stateful inspection >> of packets through a firewall shouldn't require this icky >> disgusting rewriting of source IP addresses. NAT is a >> transition technology and it has a lot more years left in >> it, but we cannot lose sight of the fact that it is a hack, >> despite our amazement that the elephant can actually dance. >> And you do not lay the foundations of a stable Internet >> on a hack. > > Actually, that icky rewriting is a benefit from a network security > perspective. NAT has a tendency to fail closed while non-translating > firewalls have a tendency to fail open. > This simply isn't true. Non-translating firewalls fail just as closed if the firewall supports stateful inspection. As an example, a Netscreen without NAT fails just as closed as a Netscreen with NAT configured. > But that's beside the point. No one is extolling the merits of > ditching IPv6 in favor of a NAT-based Internet. What we are saying is > that it is essentially impossible to achieve sufficiently ubiquitous > IPv6 deployment in the next 3 years as to allow IPv6-only deployments > to customers. Ain't gonna happen. Get past it and realize that however > fast or slow IPv6 is deployed, we're going to need an interim solution > so that until the long term solution is ubiquitously usable the folks > who -can't- engineer their systems to use NAT still have a viable way > to get IPv4 addresses. > I don't see how that is going to happen, either. What I'm hearing from most of those that have addresses which might be put into such a pool is that there is no price at which they are likely to do so. > > >> Your asking my generation to committ a terribly immoral act >> by making the very fabric of the Internet dependent on a cheap >> hack. > > Providing a working interim solution between depletion of the IPv4 > free pool and whatever long term solution comes next is an -immoral- > act? That is an astonishing claim. > 1. Calling it a working solution assumes facts not in evidence. 2. Increasing the spread of the NAT disease is an immoral act unless it can be shown to have a very high likelihood of strong meaningful beneficial effect to outweigh it's extreme disadvantages. You have failed to show any such likelihood. > > On Thu, Aug 28, 2008 at 8:50 AM, Iljitsch van Beijnum > wrote: >> Making IPv4 tradable means that our trajectory towards the wall >> will change >> in ways that we can't predict. > > We went through this pretty extensively last year. Control of IPv4 > addresses can be legitimately traded now using The Ruse and The > Container Sale. No one is proposing that we suddenly make IPv4 > tradable; for all practical purposes it already is. One point of a > liberalized transfer policy is to give ARIN better control over the > trading process so that the community can avoid the more egregious > abuses (like heavy disaggregation). > The current policy limits you to: 1. Transferring entire blocks. 2. Tremendous scrutiny and a larger paper trail than what is proposed. 3. You at least have to claim that you transferred the underlying physical assets/infrastructure, not just the addresses. 4. Deaggregation is NOT allowed under the current policy. Owen From stephen at sprunk.org Thu Aug 28 11:36:27 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 28 Aug 2008 10:36:27 -0500 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: References: Message-ID: <48B6C5FB.9090209@sprunk.org> Ted Mittelstaedt wrote: >> On Wed, Aug 27, 2008 at 3:55 PM, Ted Mittelstaedt >> wrote: >> >>> This is not correct - those big ISP's are big because they have a lot of customers - those customers are the ones using the IP numbers. >>> >> I have yet to connect to a residential Internet service (be it 56k modem, DSL or cable) that has assigned me an RFC1918 address. The blackberry on my belt even appears to be using its own globally routeable IP address. >> >> How many hundreds of millions of addresses are consumed by similar uses? >> >> Is it your position that more than 10% of those users would be inconvenienced by having an RFC 1918 address behind a NAT box instead? >> > > No, however the issue is that with those large ISP's almost certainly a percentage of their customers are running some app that is dependent on a public IP. A percentage that are making use of their public IP for inbound traffic? Yes. However, what percentage is that, and what fraction of them are actually "dependent" on it? I'd venture to say that the vast majority of consumers that have a port mapping through their home NAT/FW device are using it for gaming and/or P2P, both of which violate most ISPs' AUPs anyways. Still, those are a tiny fraction of the overall population, most of whom are still trying to figure out how to use IE5 and don't have a clue what a "public address" or "port mapping" is. > The large ISPs do not want to have to deal with the thousands of irate phone calls that would result out of their million+ customer base if they just arbitrairly switched people over to private IP numbers. > And, from the perspective of most monopoly or duopoly providers, that is an opportunity to "upsell" them to public IP service, just like the thousands of irate phone calls they get today about being given a dynamic IP address are an opportunity to upsell them to static IP service. Also, at the same time those customers would be moved to NAT or NAT-PT for IPv4, they could be given public, static IPv6 addresses for free, to use instead of public, static IPv4 addresses. > Now, this does not mean that they couldn't do a gradual switchover, I agree. But I don't agree that it is for us to force them to do it. > On that, we agree. However, it is not "us" that will be doing the forcing but rather IPv4 exhaustion, caused by the victims' own consumption. S From bill at herrin.us Thu Aug 28 11:49:20 2008 From: bill at herrin.us (William Herrin) Date: Thu, 28 Aug 2008 11:49:20 -0400 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD9011DCA72@SUEXCL-02.ad.syr.edu> References: <7663C7E01D8E094989CA62F0B0D21CD901E0E386@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0E3BA@SUEXCL-02.ad.syr.edu> <20080825170038.GA8825@vacation.karoshi.com.> <7663C7E01D8E094989CA62F0B0D21CD9011DCA72@SUEXCL-02.ad.syr.edu> Message-ID: <3c3e3fca0808280849y18faa74dg37a2d47608c2d47a@mail.gmail.com> On Mon, Aug 25, 2008 at 4:25 PM, Milton L Mueller wrote: > If you want to understand what I am trying to tell you, stop thinking > like a techie and start thinking like a policy person. Milton, I'd encourage the opposite. DO think like a techie down in the trenches faced with the immediate problem that you've run out of IPv4 addresses and it's no longer possible to get more from ARIN. What do you do? The answer is not hard to find. You'll do more NAT. You'll identify client machines that don't absolutely need a globally routeable address (like your cell phone or grandma's dialup) and you'll move them behind NAT firewalls. Then you'll retask the recovered addresses for the purpose you need. And if you don't have enough addresses to retask, you'll contract with someone who does. You'll do more NAT because there's really nothing else you'll be able to do. What you won't do, and again I'm thinking from a techie's perspective on depletion day, is seriously consider solving the problem with IPv6. At a policy level, IPv6 is a systemic replacement for IPv4 but at a technical level IPv6 addresses are not functional as a substitute for IPv4 addresses on the IPv4 Internet. As a techie, your sole concern is: what works? What solves my immediate problem? IPv6 does not. The techie in the data center on depletion day has the power to institute more NAT. He does not have the power to move everyone else to IPv6 so that he can proceed without IPv4. However that techie solves his problem, you can be sure the solution will be within his individual power to implement. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Lee.Howard at stanleyassociates.com Thu Aug 28 11:51:43 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 28 Aug 2008 11:51:43 -0400 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <48B57EFF.9040901@sprunk.org> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B197E9A@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Stephen Sprunk > OTOH, there are several large companies that have legacy As, > which currently have no incentive to return them to ARIN. > Many could renumber into a /16 or less, using NAT, if only > they had the financial motivation to incur that cost; ditto How many? Is it fair to assume governments don't have financial motivation (specifically US, UK or German governments)? Is it fair to assume that large ISPs could not be sufficiently motivated to renumber their customers from Class A to /16s (specifically Level 3, AT&T, Cogent, Japan Inet)? If I make those assumptions, how much do you think it would take to get these remaining organizations to renumber into a block justifiable under current rules: IBM Xerox HP DEC Apple MIT Ford CSC Halliburton MERIT Eli Lily Amateur Radio operators Interop Prudential duPont Cap Debis Merck SITA I haven't looked up the number of employees at each one, and MIT and MERIT are arguably unmotivated by financial incentives. That's 18 Class A's that could be renumbered, which assuming current demand trends means ARIN would run out of IPv4 space in mid-2012. > for the hundreds of companies sitting on multiple Bs that > could renumber into a /24 if motivated. However, that still > only buys us another year or two at current growth rates... Exactly. Though I can't say what level of efficiency is even theoretically possible with Class B space. > Plus, I don't hear many folks here being sympathetic to the > big ISPs in the first place, since they're the ones consuming > most of the address space and causing problems for the rest > of us. Most of "the rest of us" (on the Internet, not on PPML) get our address space from those ISPs. > These ISPs have the market power to force their > vendors to support IPv6, which would trickle down to the > smaller players, but so far there's been little visible > motion on that front. It wouldn't be visible, would it? It would be Jason Schiller beating up on Cisco and Juniper in private meetings, saying, "You have to support IPv6 in hardware." Actually, that was in public. It would be TWC and Comcast updating DOCSIS and giving orders to settopbox vendors supporting IPv6. Huh. Which vendors need to be pushed by ISPs to support IPv6? Name names and let's coordinate a campaign on their product marketing departments. > They're the ones that are going to be > hit the hardest in the coming crunch, given their rates of > consumption, so they _have_ to go to IPv6 with NAT-PT (or > multi-layered IPv4 NAT) in the near future. Once they do, > though, they could return most of their IPv4 space, which > would eliminate the address space depletion problem for the > rest of the community... I don't believe that. A) Some stuff works poorly through address translation. One support call blows the profit margin on that customer. B) I find it unlikely that existing customers would be renumbered into IPv6. I would expect new customers only. C) I doubt address space would be returned. I would expect it to be used for translations and for those users who needed IPv4 for some reason. Don't know what that reason would be. This is clearly my own personal opinion and shouldn't even need disclamation. Lee From stephen at sprunk.org Thu Aug 28 12:00:55 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 28 Aug 2008 11:00:55 -0500 Subject: [arin-ppml] Fantasyland In-Reply-To: References: Message-ID: <48B6CBB7.8060009@sprunk.org> michael.dillon at bt.com wrote: >> OTOH, there are several large companies that have legacy As, >> which currently have no incentive to return them to ARIN. >> Many could renumber into a /16 or less, using NAT, if only >> they had the financial motivation to incur that cost; ditto >> for the hundreds of companies sitting on multiple Bs that >> could renumber into a /24 if motivated. >> > > How many dollars would it take to convince a single company > to renumber from a /16 into a /24? Actual dollars please. > I'm not a business guy, so I have no idea how many dollars they'd find to be sufficient motivation. However, I do know that the cost of renumbering is non-zero and the current incentive is zero; it doesn't require an MBA to know that no manager in their right mind is going to feel motivated under those conditions. Heck, my own employer isn't even _using_ our B (we're RFC1918 internally, NATed to PA /24s), but I know that management isn't interested in giving up that valuable "asset" for the $0 that we're currently offered. I don't know how much they'd want, but it's certainly more than $0. >> However, that still only buys us another year or two at current growth rates... >> > > Too true. Now consider the cost that this same company will incur to renumber into IPv6 two years after renumbering into a /24 using NAT. Can you justify this extra cost? > I don't predict that's how it will go, particularly since any large company is going to have loads of internal software that isn't, and probably will never be, IPv6-capable. If/when they find that their external IPv4-only connectivity isn't sufficient, they will first enable NAT-PT on their existing NAT box. After a few years, some bored geek will get around to deploying IPv6 internally, in parallel to the RFC1918 IPv4 addresses, because he's sick of NAT-PT breaking some not-work-related app he's using. Eventually, the IPv4 addresses will be taken out, perhaps with another NAT-PT box so IPv6-only users can access IPv4-only servers -- but that won't happen for at least a decade, maybe two. > Why shouldn't the company in question just deploy IPv6 and > install NAT-PT gateways to cover the next 2-3 years before > IPv6 transit is widely available? > See above about internal apps not supporting IPv6. Also, many companies still do not have network equipment that supports IPv6, and the management tools, reporting, internal training, etc. aren't there yet either even if all the equipment does nominally support IPv6. If a handful of ISPs, whose core business is networking, can't get this right, how do you expect millions of businesses, who have a core business of making toothpaste or whatever, to do so? S From stephen at sprunk.org Thu Aug 28 12:14:44 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 28 Aug 2008 11:14:44 -0500 Subject: [arin-ppml] Policy Proposal: Whois Authentication Alternatives In-Reply-To: <48B5CDA5.2070703@dilkie.com> References: <48B45FEB.2090406@sprunk.org> <20080826235015.02CED4500F@ptavv.es.net> <20080827174232.GA3875@pond.riseup.net> <48B5CDA5.2070703@dilkie.com> Message-ID: <48B6CEF4.5030507@sprunk.org> Lee Dilkie wrote: > Micah Anderson wrote: > >> People keep saying this about the $100, as if this was well >> established fact, based on some data. Why do people keep asserting >> this, I'd like to know what I missed. >> > Many months ago I asserted that I *do* have a problem with $100/yr for > simply maintaining a whois and reverse lookup database. The cost is > excessive for such an obviously trival task (considering the infrequency > of changes). > I'll point out that the $100/yr maintenance fee is the same charged to _any_ org that has _any_ number of assignments under RSA or LRSA. Now, if you'd prefer to pay $10/yr per object, like you do with domain names, that's a valid suggestion to put to the BoT, who are the folks that set the fee schedule (not PPML). If you think that a flat fee is good, but that it's too high, consider the number of orgs that have dozens to hundreds of objects, and that has to be averaged out. (One could make an argument that a per-object fee would incent returns or aggregation requests, but IMHO that's a different matter.) > Other will, and have, pointed out that ARIN spends lots of $ vetting new > assignments and that's where the money goes. To which I answered, what > does that have to do with me? If new assignments cost more to approve > than they used to, then those costs should be born by the new assignees, > much like land development charges that cities apply to new development > projects. > That _should_ be covered by the initial assignment/allocation fees, not maintenance fees. Maintenance fees should only be paying for the cost of keeping WHOIS and rDNS running after the assignments are made. Note that maintenance fees for allocations _are_ higher, due to the cost of all those SWIP transactions, which assignments shouldn't incur. Also, please keep in mind that all fees contain a contribution to support the public policy process, outreach activities, and other resources and services for the community at large that inherently must be "free" to the beneficiaries. S From kkargel at polartel.com Thu Aug 28 13:10:49 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 28 Aug 2008 12:10:49 -0500 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <8F8BCCAE-B795-4483-A5DD-F1A43F80B520@muada.com> References: <3c3e3fca0808271432o297630efod4efcc35a1e92a3a@mail.gmail.com><3c3e3fca0808280712v23df6875k978151b86744f91a@mail.gmail.com> <8F8BCCAE-B795-4483-A5DD-F1A43F80B520@muada.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10A92@mail> >>Give them all NAT and magically the number of people running NAT- incompatible applications shrinks to 0%. We'd be doing those misguided individuals who try to use these apps today a favor, really. Give then all NAT and magically all your customers move to your competitor -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3107 bytes Desc: not available URL: From Lee.Howard at stanleyassociates.com Thu Aug 28 13:14:54 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 28 Aug 2008 13:14:54 -0400 Subject: [arin-ppml] How much time would we have? Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B197FE9@CL-S-EX-1.stanleyassociates.com> QUESTION At various levels of assignment efficiency (i.e., doing nothing, reclaiming or marketizing addresses) and at various levels of demand (extrapolation of current level, increase due to panic, decrease due to IPv6 uptake or increased IPv4 efficiency), what is the effective runout date? i.e., can we figure various runout dates based on various assumptions? For each set of assumptions, what is RIR runout date? Demand assumptions: What multiple of current rate (13.7 per year, plus 1.5 per year) Supply assumptions: What percentage of legacy space could be recovered and reallocated (whether by reclamation or by market incentives)? Demand Assumption (what multiple of current rate) 1/3 Current 3X %Legacy Realloc 0% 2011 2011 2011 30% 2011 2012 2011 50% 2014 2013 2012 70% 2015 2014 2012 90% 2017 2015 2013 (formatting note: I used tabs for whitespace) In English: for each level of demand (1/3 of current rate, current rate, or 3X current rate) and each level of legacy space reassigned, when do we run out of space? SUMMARY Changing IPv4 policies (harder or easier to get more) doesn't have much effect on the runout date by itself. Becoming more efficient in legacy space buys a year or two (or more, depending on how inefficient you think legacy assignments are). If you want to delay the time-to-runout by two or more years, you need extreme measures: significantly reduce the amount of IPv4 address space assigned by RIRs, and reassign at least half of legacy address space. CONCLUSIONS You have until 2011 to get onto IPv6, or otherwise make it so you never need more IPv4. Aggressive outreach to encourage organizations to transition to IPv6 and/or make broad use of address translation. Barriers to IPv6 need to be eliminated. DATA USED FOR ASSUMPTIONS http://www.nro.net/documents/presentations/jointstats.v1.0608.pdf http://www.iana.org/assignments/ipv4-address-space/ There are 35 /8 unavailable, 91 legacy, 39 to be assigned. Global demand is increasing since 2002, by very roughly 1.5 /8 per year. It doesn't matter whether you measure IANA assigning the last /8 (or the last 5 /8s) or RIR runout date. By 2011, RIRs will be assigning/allocating 1.5 /8 per month, so the last ARIN assignment will be only 3-6 months following IANA runout. CAVEATS I'm a liberal arts guy, not a math guy. This is all my own work, for my own use. I didn't check with anybody while doing it. I ignored data from 2008 (although run rate is about right). I assumed that improved efficiency in legacy space would be the same for Classes A, B, and C, though I believe this assumption to be flawed. Of only 18 Class As are privately held, I believe 4 Class A holders could be convinced to renumber, given enough money. Assuming a significant number of Class B and C holders (let's say 30/44 Class B holders and 6/7 Class C holders) can renumber, that's still only 40 out of 91 legacy /8s reclaimed. Assuming they have only 25% efficiency, they use 10 /8s to renumber into, giving us a net of 30 /8s Not all RIRs assign address space at the same rate. If you want to reduce the burn rate on IPv4, APNIC and RIPE NCC are the areas of highest consumption, followed by ARIN. I've attached the spreadsheet I used, so you can check my work. I'll be surprised if it survives scrutiny. -------------- next part -------------- A non-text attachment was scrubbed... Name: IPv4 run rates.xls Type: application/vnd.ms-excel Size: 39424 bytes Desc: IPv4 run rates.xls URL: From bjohnson at drtel.com Thu Aug 28 13:27:26 2008 From: bjohnson at drtel.com (Brian Johnson) Date: Thu, 28 Aug 2008 12:27:26 -0500 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <369DB83A-DFDE-4F97-9EF7-498E50FDE492@delong.com> References: <3c3e3fca0808271432o297630efod4efcc35a1e92a3a@mail.gmail.com><3c3e3fca0808280712v23df6875k978151b86744f91a@mail.gmail.com> <369DB83A-DFDE-4F97-9EF7-498E50FDE492@delong.com> Message-ID: <29A54911243620478FF59F00EBB12F47012AFDDE@ex01.drtel.lan> Owen DeLong carved in a stone tablet: > Let's put it closer to 75%. Here's a list of popular things that > function > sub-optimally behind NAT: Please define sub-optimal and whether this is due to the NAT or the coding of the program. > > 1. Pick your favorite IM I have yet to come across a modern IM client that doesn't work fine behind NAT. > 2. VOIP (when it doesn't break outright) I know several people who use Vonage behind cheap NAT routers. > 3. P2P applications of various types -- Regardless of what > you think of P2P filesharing, there are a number of > additional > P2P applications that have legitimate purposes and there > are, frankly, many more legitimate P2P file shares than > illegal ones. For example, virtually every linux distro has > a bit torrent available. I use bit torrent to download distros all the time from behind a NAT system. > 4. Voice and Video chats. I have used voice and video chat applications from behind a NAT system. This does require a broker to make connections or at least one side having a directly addressable end-point though. > 5. SSH Have no idea what to say on this one unless you are securing your SSH sessions by a remote IP address list. > > I'm willing to bet at least 75% of users use one or more of these > on almost daily basis. I will proceed under the assumption this is true :) > > Things which break behind NAT: > > 1. Inbound access to your machine from somewhere > else. (Remote desktop, SSH, Web Server, etc.) This I see as a viable gripe. But there are several vendors out there offering free solutions for this using an external broker. > > Lots of people would _LIKE_ to do these things if they could, > and, even more would be upset if it was suddenly taken away > from them. I can't agree with you more. > > Hence, I argue that your 10% figure is... optimistic. > > > >> BUT - the fact of the matter is that stateful inspection > >> of packets through a firewall shouldn't require this icky > >> disgusting rewriting of source IP addresses. NAT is a > >> transition technology and it has a lot more years left in > >> it, but we cannot lose sight of the fact that it is a hack, > >> despite our amazement that the elephant can actually dance. > >> And you do not lay the foundations of a stable Internet > >> on a hack. > > > > Actually, that icky rewriting is a benefit from a network security > > perspective. NAT has a tendency to fail closed while non-translating > > firewalls have a tendency to fail open. > > > This simply isn't true. Non-translating firewalls fail just as closed > if the firewall supports stateful inspection. As an example, a > Netscreen without NAT fails just as closed as a Netscreen > with NAT configured. This is a configuration and management issue. I can make my firewall act either way depending on my configuration. I have always leaned toward the no NAT option due to poorly designed programs in the past, many of which broke severely under NAT. But as time has evolved, I see no real reason to believe that for a large volume of people, NAT is perfectly acceptable. It also provides a minor amount of security through obscurity. I have no plans to suggest anyone make such a change, but if v6 adoption falls behind and I need more space after v4 exhaustion, I'll probably propose a NAT firewall service trial on our network. Keep the carrot in front of me... and I see the stick coming. :) - Brian From kkargel at polartel.com Thu Aug 28 13:48:11 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 28 Aug 2008 12:48:11 -0500 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <3c3e3fca0808280825j255bec99oa77ae8abe2295a9e@mail.gmail.com> References: <3c3e3fca0808271432o297630efod4efcc35a1e92a3a@mail.gmail.com> <3c3e3fca0808280712v23df6875k978151b86744f91a@mail.gmail.com> <70DE64CEFD6E9A4EB7FAF3A063141066A10A91@mail> <3c3e3fca0808280825j255bec99oa77ae8abe2295a9e@mail.gmail.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10A93@mail> On Thu, Aug 28, 2008 at 10:25 AM, Kevin Kargel wrote: > Speaking as a system administrator for an ISP.. The number of > customers who during the course of a year use applications that would > be negatively affected by nat is more in the range of 80 to 100 %.. > > Flame this if you want.. I am speaking from experience having tried it.. >Kevin, >Would you settle for questions which challenge you to document your claims instead? I will be happy to answer your questions. I am sure there are technical solutions to each of these problems, the issue is that my customers have neither the inclination nor the skills to tackle the issue, they would rather pay me and expect everything to run smoothly. I'll throw in some easily grabbed surface links.. My and your customers are not extraordinarily loyal. With prices being competative they will take their business to whichever ISP works best for them with the least amount of trouble. I want that to be me. > Instant messaging >Which widely used IM systems do you find have trouble when the clients are behind a NAT firewall? Certainly not AIM, Yahoo messenger, Google >chat or IRC. DCC has some issues, but now you've crossed into P2P file transfer rather than IM. To the contrary, Any of the yahoo IM features using p2p break when behind NAT.. It doesn't matter that it's a p2p, my customers just know there is a button for that in there Yahoo console and they expect it to work. The apps will survive local NAT to some degree, but look in the FAQ's and you will find instructions for overcoming NAT.. It takes special software to be able to utilize some IM features like file transfer behind NAT.. http://www.brothersoft.com/enat-for-msn-messenger-17678.html http://www.unixwiz.net/techtips/yahoo-sonicwall.html > online gaming (like yahoo and msn games), >Which Yahoo or MSN games malfunction when access is attempted from behind a NAT firewall? Try to host any YAHOO or MSN card game from behind a NATed console.. I am not talking about local NAT on your personal router, but on an ISP supplied NAT address.. Unless you are talking about 1 to 1 NAT.. But that rather defeats the purpose.. http://answers.yahoo.com/question/index?qid=20080826124256AAb1nB7 http://www.homenethelp.com/web/howto/game-behind-router.asp >game consoles, >Which game consoles malfunction when access is attempted from behind a NAT firewall? The standard deployment for DSL and cable modems is to >send out a "DSL router" which implements a local NAT firewall and all three manufacturers knew that when they designed the current >>>>generation of consoles. Would you have us believe that Microsoft, Sony and Nintendo built and deployed game consoles which require extraordinary action to get on the Internet? No, I would have you believe that Microsoft, Sony and Nintendo built and deployed game consoles which require ordinary action to get on the internet. Not extraordinary action like NAT http://boardsus.playstation.com/playstation/board/message?board.id=psnetwork &thread.id=116102 Again, there is a huge difference between using NAT for your one game console, and putting your game console behind an ISP NAT alongside dozens or hundreds of other game consoles. Try running three Xboxes behind your SOHO router without doing fancy router tricks and see what happens.. http://support.microsoft.com/kb/908880 > VOIP, >Other than Skype (see P2P apps), what widely used VOIP services malfunction when the client is behind a NAT firewall? Definately not Vonage. >I used it for years behind NAT+PPPoE. Are you talking about your personal NAT in your PPPoE router or a private address supplied by your ISP? There is a difference.. Try running two simultaneous sessions of VOIP behind your NATed router even. http://blogs.zdnet.com/ip-telephony/?p=1095 >>Which widely used VPN client products malfunction when the client is behind a NAT firewall? Certainly not Microsoft's PPtP client nor Cisco's VPN client nor open source solutions like OpenVPN. I've used all of these without difficulty from behind NAT firewalls. CITRIX for one.. Also Cisco VPN and Microsoft PPtP.. Again.. We are talking about a 1 to hundreds NAT.. Not your SOHO router http://www.cisco.com/en/US/products/sw/secursw/ps2308/products_qanda_item091 86a00801c2dbe.shtml http://osdir.com/ml/security.vpn/2003-08/msg00017.html http://www.cisco.com/en/US/tech/tk827/tk369/technologies_configuration_examp le09186a00800949c0.shtml > p2p applications, > web cam videoconference, >>And you believe that more than 80% of your users use applications in these two categories? What's your basis for this claim? Have your surveyed your users? Performed traffic analysis to match well known applications to user accounts? I base it on the thousands of phone calls I got the first day we implemented NAT.. I also base it on my network traffic analysis (Xangati if you are interested, very cool) that enumerates endpoints associated with a protocol.. As I type this I have over 150 customers using BitTorrent, a couple dozen actively using VOIP, dozens on yahoo and msn games, ad nauseum.. And this is in the middle of the day during school.. > followed by a host of other applications.. Almost all of my > residential customers use one or more applications in this ilk at least occasionally. >>Not unless your user base is comprised of a disproportionate number of techies. I'll concede that possibility, but if true it negates the utility of your observations for establishing a baseline for the percentage of users who directly need globally routable IP addresses. You don't need techies to want to do p2p or play games.. Any schoolkid will meet that criteria, and most of those are techies these days.. One instance of any of these applications behind a NAT is configurable without undue strain, but when you try configuring NAT to work with hundreds or thousands of instances of a single application without special client-side configuration you are going to have to think harder. Remember that your customers expect their software to work out-of-the-box.. And when it doesn't they are going to call you and that costs you money. Also, if your ISP does not by default give you a block of NAT'ed addresses in the same subnet as your WAN for your LAN, then you are forced to double-nat which greatly increases the likelyhood of breaking apps. >>Regards, >>Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3107 bytes Desc: not available URL: From kkargel at polartel.com Thu Aug 28 14:04:50 2008 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 28 Aug 2008 13:04:50 -0500 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <29A54911243620478FF59F00EBB12F47012AFDDE@ex01.drtel.lan> References: <3c3e3fca0808271432o297630efod4efcc35a1e92a3a@mail.gmail.com><3c3e3fca0808280712v23df6875k978151b86744f91a@mail.gmail.com><369DB83A-DFDE-4F97-9EF7-498E50FDE492@delong.com> <29A54911243620478FF59F00EBB12F47012AFDDE@ex01.drtel.lan> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066A10A94@mail> On the subject of NAT.. We are not talking about an individual customer premise using single instances of applications behind his own NAT firewall that he has control of. We are talking about putting hundreds, thousands or more customers behind a single NAT that the end user cannot configure. Many of the applications we are discussing require PAT translation to operate. There is NO way to set up PAT to know which of a dozen internal hosts to direct an externally initiated application to without requiring some fancy port mapping at both ends. When you are on your own home router you can configure your PAT to send incoming traffic for your IM to workstation A, and to send incoming traffic for your Xbox gaming server to your one Xbox.. If you put a hundred clients behind an ISP provided NAT you need some mechanism for the many external Xbox users to initiate connections to the proper internal Xboxes hosting the game they want to join. Simple NAT or PAT cannot accomplish that. If you want a simple test of how this will work, try to set up Remote Desktop to two or more workstations in your home network using the same external ip address and port to connect to each of them from outside your NAT. Tell me how that works for you. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3107 bytes Desc: not available URL: From mueller at syr.edu Thu Aug 28 14:22:28 2008 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 28 Aug 2008 14:22:28 -0400 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: References: <3c3e3fca0808270824o7c0e6867h7668e8cd4cfdaed4@mail.gmail.com> <7663C7E01D8E094989CA62F0B0D21CD9022150EC@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD9022150F2@SUEXCL-02.ad.syr.edu> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0E4FF@SUEXCL-02.ad.syr.edu> > -----Original Message----- > From: Tom Vest [mailto:tvest at pch.net] > > Sorry if that excerpt taxed your attention span. :-) > Remember, this is a forum composed almost exclusively of presumptive > "gamers", as you might call them. > Accusing your audience of willful malfeasance wouldn't exactly be the > smartest way to make your case. I agree with that, but it's _your_ case that points the finger at the threat of gaming, not mine. > You might also try to learn a little more about the incentive > structure in this industry before making such broad and absolute > pronouncements. Hmm, that advice would seem to be reciprocally applicable... Yeah, I'm being flip -- issues are too complex to bang out on a list like this, let's talk about it at TPRC, ok? From mueller at syr.edu Thu Aug 28 14:22:29 2008 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 28 Aug 2008 14:22:29 -0400 Subject: [arin-ppml] Further revisions to 2008-2? In-Reply-To: <48B5F575.2000001@internap.com> References: <0E9AFED7A08B4566A79CDE80F22686B2@tedsdesk> <48B5F575.2000001@internap.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0E501@SUEXCL-02.ad.syr.edu> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Scott Leibrand > > But in addition to (re)debating those points, I'd love to hear any further > feedback on how folks think we should revise 2008-2. There will be a > consensus call on it at L.A., and I'd like to have the best possible > proposal on the table when we get to that point. > I may have made my view on this known, but in case not: * Authenticate sellers only, do not bring the RSA or LRSA into it. * Reduce the "freeze" for buyers from 2 years to 1 year in line with the survey results. * Implement immediately, don't wait for "free pool depletion" * put a 3-4 year sunset on the geographic restrictions, re-evaluate that issue after a while From mueller at syr.edu Thu Aug 28 14:22:35 2008 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 28 Aug 2008 14:22:35 -0400 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: <620fd17c0808280601o1b0b2182n81bb0f530a5898ce@mail.gmail.com> References: <620fd17c0808280601o1b0b2182n81bb0f530a5898ce@mail.gmail.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0E503@SUEXCL-02.ad.syr.edu> Paul I'm quite popular with my students, and I don't recall you being in any of my classes. So that kind of insulting insinuation is way out of bounds. It's purely ad hominem in the sense that it has nothing to do with the issues being discussed on the list, or even with my comment, but is an attempt to smear the person. And if our list monitors are consistent in their application of their civility policy you'll be reprimanded. Nevertheless, if that message was viewed as disrespectful I certainly apologize, both to you and to anyone else who took it that way. I didn't see it as condescending. I guess it's the context-less nature of asynchronous text communication. In my circles it's not disrespectful at all to refer to someone as a techie, and at interdisciplinary programs at Syracuse and Delft we are constantly engaged in discussions about the different but sometimes intersecting and complementary relationships between policy and technology knowledge. That message simply responded to the fact that the party I was talking to kept responding to a discussion of policy options by talking about what he considered to be the optimal technical solution. Accomplished technical people can appear to others to be extremely dismissive of other forms of knowledge. Sometimes they have to be forcefully reminded that a technical perspective is not the only one. The point about policy frameworks is that they are often designed not to select a particular technical option but to provide an incentive framework within which individuals can make their own optimization choices. --MM > -----Original Message----- > From: Paul Wall [mailto:pauldotwall at gmail.com] > Sent: Thursday, August 28, 2008 9:01 AM > To: Milton L Mueller > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA > concerns) > > "Milton L Mueller" writes: > > > If you want to understand what I am trying to tell you, stop thinking > > like a techie and start thinking like a policy person. > > Milton, > > At the risk of starting a flame war, I'd sure appreciate it if you > didn't address your colleagues here in the same dismissive > condescending tone that I understand you use with your students. It > tends to overshadow the important points you make when you're less > than cordial and respectful. > > Drive Slow, > Paul Wall From mueller at syr.edu Thu Aug 28 14:22:45 2008 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 28 Aug 2008 14:22:45 -0400 Subject: [arin-ppml] IANA IPv4 /8 burn rate.... (was Re: Steppingforward, opening my mouth and removing all doubt about) In-Reply-To: <35071283-7887-496F-ADAA-FF7EEB5487BD@muada.com> References: <48B5DCF4.3070009@internap.com> <35071283-7887-496F-ADAA-FF7EEB5487BD@muada.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0E508@SUEXCL-02.ad.syr.edu> > -----Original Message----- > Behalf Of Iljitsch van Beijnum > > of course everyone will use a lot of them. When they become scarce > > and expensive, people will start conserving IPv4. > > How is that a good thing? When you don't know how long it will take to convert, and are uncertain about the cost of migration, stricter conservation allowing for a longer transition, if needed, is prudent policy. If a longer transition period is not needed, a transfer policy does no harm, as the resources become devalued more rapidly. > IPv6 addresses are free, because whatever the cost is, after dividing Business/economic reality check: nothing is free. Certainly not a protocol that requires heavy investments in new equipment and human resources/skills. So you don't compare the cost of addresses, you compare the cost of delivering internet service using the two protocols. Insofar as you are making a serious argument, it is contained here: > What we should do is try to make the switch to IPv6 as painless as we > can. The most important part of that is to make it predictable: we > need to know what's going to happen in the next 5 years or so. Interesting. You think we can make the migration "predictable" by erecting a brick wall. One logical consequence of this argument: no need to wait, we can do it tomorrow, or as soon as ARIN agrees to adopt a flag date where IPv4 just ends. Agree? You should. Because if you want to keep handing out IPv4 for the next 3 years or however long the free pool lasts, that is actually inconsistent with your position, it adds to uncertainty because we don't know exactly when it will deplete. Could be sooner, could be later. Uncertainty. Bad. So your position is that starting, say, Jan 1 2009 we just stop handing out IPv4 blocks. Very clear. You have eliminated all uncertainty about the v4 address pool. Do you _really_ think the results of that will be "predictable?" Can you _really_ predict, with reasonable levels of probability, that you will even prevent private unauthorized transfers from taking place under those circumstances? Much less what migration strategies will be adopted? I don't see arbitrary limits on the use of IPv4 as decreasing the uncertainty of the migration in any appreciable way. But why not go whole hog with the uncertainty argument: let's just get a decree to stop operating the IPv4 internet tomorrow. That would really clear things up, eh? Certainly everyone would know exactly where they stood with respect to v4 and v6. But the adjustments would be anything but "painless" as you put it. > Any policy change means that there will be a bigger difference between > what's being predicted and what will happen, I'm afraid that that's not true. You are assuming that the migration is 1) a linear, progressive and predictable process and 2) will occupy a known time period. Both assumptions are shaky. A transfer policy is a hedge. It maximizes efficient utilization of remaining v4 resources while in no way precluding IPv6 migration. > so all policy changes are > at least somewhat harmful, and potentially very harmful. So we should > only make the ones that are extremely obvious wins. In an environment of IPv4 scarcity, with large swaths of v4 address blocks known to be underutilized, and with occupiers of address resources needing an incentive to migrate, allowing holders of those address blocks to financially benefit from releasing them is an obvious win. That's the only reason I support it. From mueller at syr.edu Thu Aug 28 14:44:56 2008 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 28 Aug 2008 14:44:56 -0400 Subject: [arin-ppml] ARIN's Authority - One view (was: Re: LRSA concerns) In-Reply-To: <3c3e3fca0808280849y18faa74dg37a2d47608c2d47a@mail.gmail.com> References: <7663C7E01D8E094989CA62F0B0D21CD901E0E386@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0E3BA@SUEXCL-02.ad.syr.edu> <20080825170038.GA8825@vacation.karoshi.com.> <7663C7E01D8E094989CA62F0B0D21CD9011DCA72@SUEXCL-02.ad.syr.edu> <3c3e3fca0808280849y18faa74dg37a2d47608c2d47a@mail.gmail.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0E50B@SUEXCL-02.ad.syr.edu> True, if you frame it that way: NEVER stop thinking like a techie if you are one, but strive to consider also the economic factors driving your technical options and how policies might alter them. If you think like a policy person, however, you look not only at your own choice constellation but at the aggregate of other people's choices and how your choices might affect theirs and vice versa. That can be difficult. And apologies again if anyone was offended by my original construction. This debate (while vital) is getting tedious and we're all getting a bit cranky. > -----Original Message----- > From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William > Herrin > > I'd encourage the opposite. DO think like a techie down in the > trenches faced with the immediate problem that you've run out of IPv4 > addresses and it's no longer possible to get more from ARIN. What do > you do? The answer is not hard to find. > From tvest at pch.net Thu Aug 28 15:12:55 2008 From: tvest at pch.net (Tom Vest) Date: Thu, 28 Aug 2008 15:12:55 -0400 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E4FF@SUEXCL-02.ad.syr.edu> References: <3c3e3fca0808270824o7c0e6867h7668e8cd4cfdaed4@mail.gmail.com> <7663C7E01D8E094989CA62F0B0D21CD9022150EC@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD9022150F2@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0E4FF@SUEXCL-02.ad.syr.edu> Message-ID: <3E393D72-5C10-442B-AD30-07F58C896E37@pch.net> On Aug 28, 2008, at 2:22 PM, Milton L Mueller wrote: >> -----Original Message----- >> From: Tom Vest [mailto:tvest at pch.net] >> >> Sorry if that excerpt taxed your attention span. > > :-) > >> Remember, this is a forum composed almost exclusively of presumptive >> "gamers", as you might call them. >> Accusing your audience of willful malfeasance wouldn't exactly be the >> smartest way to make your case. > > I agree with that, but it's _your_ case that points the finger at the > threat of gaming, not mine. No gaming, no bad faith, no "evil" intentions required or assumed. Being responsive to shifting incentives that are in motion initially because of the proposed policy, and then subsequently because of competitive pressures and uncertainty about the future -- absolutely; that happens all the time in this industry. >> You might also try to learn a little more about the incentive >> structure in this industry before making such broad and absolute >> pronouncements. > > Hmm, that advice would seem to be reciprocally applicable... > > Yeah, I'm being flip -- issues are too complex to bang out on a list > like this, let's talk about it at TPRC, ok? Fair enough. Peace, TV From bmanning at vacation.karoshi.com Thu Aug 28 17:45:39 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 28 Aug 2008 21:45:39 +0000 Subject: [arin-ppml] Fantasyland In-Reply-To: References: <20080828101711.GA30839@vacation.karoshi.com.> Message-ID: <20080828214539.GA6973@vacation.karoshi.com.> On Thu, Aug 28, 2008 at 12:03:29PM +0100, michael.dillon at bt.com wrote: > > > Why shouldn't the company in question just deploy IPv6 and install > > > NAT-PT gateways to cover the next 2-3 years before > > > IPv6 transit is widely available? > > > Please provide a vendor list for NAT-PT gateways that > > provide production level service/availability - today. > > I would hope that the company in question would plan their deployment > exercise and not just rush out buying equipment and blasting out their > old network. As part of the planning exercise, they might go to the ARIN > IPv6 wiki at > where they will note vendor names. If they contact said vendors, then > there is motivation for said vendors to provide production level service > and availabilty within the timeframe for implementation. Note that there > is also the possibility of consulting firms using open-source NAT-PT who > would then provide the SLA and support component. > > Obviously, today, there is only one vendor on that page and no mention > of > where open-source NAT-PT can be found. I would hope that anyone with > more > information would log on to the wiki and update this page and others. which raises the question of "eating our own dogfood"... there have been a number of calls for folks to take first steps to get their "externally" facing DNS, SMTP, HTTP services visable on IPv6. One might find this survey of interest. http://www.mrp.net/IPv6_Survey.html clearly we have a ways to go to meet the first hurdle. As for NAT-PT, the IETF is still trying to settle on a standard. --bill From alain_durand at cable.comcast.com Thu Aug 28 18:07:36 2008 From: alain_durand at cable.comcast.com (Alain Durand) Date: Thu, 28 Aug 2008 18:07:36 -0400 Subject: [arin-ppml] About NAT-PT.... (Re: Fantasyland) In-Reply-To: <20080828214539.GA6973@vacation.karoshi.com.> Message-ID: On 8/28/08 5:45 PM, "bmanning at vacation.karoshi.com" wrote: > > clearly we have a ways to go to meet the first hurdle. As for NAT-PT, > the IETF is still trying to settle on a standard. I read a lot of fantasy about NAT-PT those days, like it is going to be the silver bullet that will make this all problems go away... NAT-PT is a v6 to v4 translator. Which mean, it only helps if your internal network is... v6. If you have any device in there that cannot do IPv6 and need to talk to the rest of the universe (think IP-webcam, gaming device, windows box prior to vista, load balancer, IDS, firewall, IMS, xyz server,.... NAT-PT is *not* a solution for you. Nor would be any of its replacement candidates. Dual-stack lite (see http://tools.ietf.org/html/draft-durand-dual-stack-lite-00) might be a better approach in that space. It is being standardized by IETF in the softwire working group. - Alain. From plzak at arin.net Thu Aug 28 18:25:18 2008 From: plzak at arin.net (Ray Plzak) Date: Thu, 28 Aug 2008 18:25:18 -0400 Subject: [arin-ppml] Stepping forward, opening my mouth and removing all doubt about In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E4FF@SUEXCL-02.ad.syr.edu> References: <3c3e3fca0808270824o7c0e6867h7668e8cd4cfdaed4@mail.gmail.com> <7663C7E01D8E094989CA62F0B0D21CD9022150EC@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD9022150F2@SUEXCL-02.ad.syr.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0E4FF@SUEXCL-02.ad.syr.edu> Message-ID: Milton, Issues like these need to be discussed in the ARIN policy fora, such as the upcoming ARIN meetings. Will you be in Los Angeles? Ray > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Milton L Mueller > Sent: Thursday, August 28, 2008 14:22 > To: Tom Vest > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Stepping forward, opening my mouth and > removing all doubt about > > > > > -----Original Message----- > > From: Tom Vest [mailto:tvest at pch.net] > > > > Sorry if that excerpt taxed your attention span. > > :-) > > > Remember, this is a forum composed almost exclusively of presumptive > > "gamers", as you might call them. > > Accusing your audience of willful malfeasance wouldn't exactly be the > > smartest way to make your case. > > I agree with that, but it's _your_ case that points the finger at the > threat of gaming, not mine. > > > You might also try to learn a little more about the incentive > > structure in this industry before making such broad and absolute > > pronouncements. > > Hmm, that advice would seem to be reciprocally applicable... > > Yeah, I'm being flip -- issues are too complex to bang out on a list > like this, let's talk about it at TPRC, ok? > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From sleibrand at internap.com Thu Aug 28 19:23:48 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 28 Aug 2008 16:23:48 -0700 Subject: [arin-ppml] IANA IPv4 /8 burn rate.... In-Reply-To: References: Message-ID: <48B73384.4010802@internap.com> Alain Durand wrote: > On 8/27/08 7:02 PM, "Scott Leibrand" wrote: > >> In basic microeconomics, quantity supplied equals quantity demanded at the >> price and quantity where the supply and demand curves intersect. >> Expecting that quantity to be the same in a market under conditions of >> scarcity (where the price is non-zero) as in a non-market distribution >> system based on abundance (where the price is zero) makes no sense unless >> the demand is completely inelastic (which it's clearly not). > > I disagree with your last point, the demand seems to be pretty much > inelastic. It is fuelled by the growth of the Internet. The fact that some > historical allocations were not as efficiently made as they are today should > not fool you into thinking that recent allocations are not efficient either. Ok, that's a valid assertion. I would counter that there is not a one-to-one relationship between devices and IPv4 addresses, and therefore the current level of observed efficiency is a function of the current price of IP addresses. Given the technical means to serve multiple devices using a single IPv4 address (such as with NAT or IPv6+NAT-PT), I am confident that enterprising folks will find a way to increase the devices-per-IPv4-address ratio as IPv4 addresses become more costly to obtain. -Scott From tedm at ipinc.net Thu Aug 28 19:42:01 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 28 Aug 2008 16:42:01 -0700 Subject: [arin-ppml] IANA IPv4 /8 burn rate.... In-Reply-To: <48B73384.4010802@internap.com> Message-ID: <603B658D97F841CABD555DFA83D9310C@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand > Sent: Thursday, August 28, 2008 4:24 PM > To: Alain Durand > Cc: ARIN PPML > Subject: Re: [arin-ppml] IANA IPv4 /8 burn rate.... > > > I > am confident that enterprising folks will find a way to increase the > devices-per-IPv4-address ratio as IPv4 addresses become more > costly to obtain. > But those devices still themselves require IP addresss. Thus the statement your really trying to say is: "...enterprising folks will find a way to increase the devices-per-GLOBALLY-UNIQUE-IPv4-address ratio as IPv4..." In actual fact, the enterprising folks sidestepped this by increasing the number of globally unique addresses so that IP addresses would not become more costly to obtain. Since either way fixes the problem why is yours more desirable? Everyone who assumes that moving to IPv6 would be better has I think already provided a boatload of arguments as to why their way would be better. But I have not really heard any arguments from the people who want to stay with IPv4 as to why their way would be better. Ted From stephen at sprunk.org Thu Aug 28 23:41:37 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 28 Aug 2008 22:41:37 -0500 Subject: [arin-ppml] IANA IPv4 /8 burn rate.... In-Reply-To: <603B658D97F841CABD555DFA83D9310C@tedsdesk> References: <603B658D97F841CABD555DFA83D9310C@tedsdesk> Message-ID: <48B76FF1.7080606@sprunk.org> Ted Mittelstaedt wrote: > Everyone who assumes that moving to IPv6 would be better > has I think already provided a boatload of arguments as to why > their way would be better. > > But I have not really heard any arguments from the people who > want to stay with IPv4 as to why their way would be better. > I think that answer is simple: the short-term cost of adding more NAT is lower than the short-term cost of moving everything to IPv6. There's a lot of stuff that _still_ doesn't work (well or at all) with IPv6, despite over a decade of work and sweeping claims by IPv6 supporters, so the cost of the latter option isn't even calculable because it's not possible -- but even the parts that are possible will undoubtedly cost more, in the short term, than just tossing a few more NAT boxes into the network. I think everyone is in agreement that the long-term costs of IPv6 are cheaper than IPv4+NAT; what we're really debating is if and when that transition will happen and what to do in the meantime. S From sleibrand at internap.com Fri Aug 29 03:05:40 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 29 Aug 2008 00:05:40 -0700 Subject: [arin-ppml] IANA IPv4 /8 burn rate.... In-Reply-To: <603B658D97F841CABD555DFA83D9310C@tedsdesk> References: <603B658D97F841CABD555DFA83D9310C@tedsdesk> Message-ID: <48B79FC4.608@internap.com> Ted Mittelstaedt wrote: > >> I am confident that enterprising folks will find a way to increase the >> devices-per-IPv4-address ratio as IPv4 addresses become more >> costly to obtain. >> > > But those devices still themselves require IP addresss. Thus the > statement your really trying to say is: > > "...enterprising folks will find a way to increase the > devices-per-GLOBALLY-UNIQUE-IPv4-address ratio as IPv4..." That is a correct reading of my statement... > In actual fact, the enterprising folks sidestepped this by > increasing the number of globally unique addresses so that > IP addresses would not become more costly to obtain. > > Since either way fixes the problem why is yours more desirable? You snipped out what I said about "the technical means to serve multiple devices using a single IPv4 address (such as with NAT or IPv6+NAT-PT)". So the only way in which "my way" is more desirable is that it is a superset of "your way". I believe that the best long-term way to increase the devices-per-globally-unique-IPv4-address ratio is to put as many hosts as possible on IPv6, and provide various translation mechanisms to allow them to interoperate with legacy IPv4-only hosts. I further believe that organizations doing so should be able to recoup some of their investment costs by recycling the IPv4 addresses freed up in the process, and transferring them to another organization for whom a more short-term approach is warranted. > Everyone who assumes that moving to IPv6 would be better > has I think already provided a boatload of arguments as to why > their way would be better. > > But I have not really heard any arguments from the people who > want to stay with IPv4 as to why their way would be better. Maybe because there's almost no one in this debate who is expressing that opinion. Most everyone arguing for a transfer policy (including myself) is doing so because they think it is a reasonable short-term accommodation to get us through a period of transition, and to provide incentives for those best able to transition to do so first. -Scott From iljitsch at muada.com Fri Aug 29 05:05:51 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 29 Aug 2008 11:05:51 +0200 Subject: [arin-ppml] IANA IPv4 /8 burn rate.... (was Re: Steppingforward, opening my mouth and removing all doubt about) In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E508@SUEXCL-02.ad.syr.edu> References: <48B5DCF4.3070009@internap.com> <35071283-7887-496F-ADAA-FF7EEB5487BD@muada.com> <7663C7E01D8E094989CA62F0B0D21CD901E0E508@SUEXCL-02.ad.syr.edu> Message-ID: <247AC75C-B61D-402C-B226-D99C4299E159@muada.com> On 28 aug 2008, at 20:22, Milton L Mueller wrote: >>> of course everyone will use a lot of them. When they become scarce >>> and expensive, people will start conserving IPv4. >> How is that a good thing? > When you don't know how long it will take to convert, and are > uncertain > about the cost of migration, stricter conservation allowing for a > longer > transition, if needed, is prudent policy. If a longer transition > period > is not needed, a transfer policy does no harm, as the resources become > devalued more rapidly. You assume that having IPv4 space available is a good thing, which I can agree with, but also that stricter conservation isn't harmful, or the harmful effects are less than the good that comes from having IPv4 addresses available. I disagree with that. The current rules are already so strict that they're harmful. The inability to get addresses is a huge problem. See the NAT issue. I agree that NAT works for most people most of the time, and we can argue about how often it doesn't work for how many people, but it's obvious that it breaks stuff for some people. So these people would be better off not using NAT, which means they need more IPv4 addresses. They usually can't get them at a price that they find affordable. Today, that's mostly due to ISP policies. Giving out more than a single IPv4 address is significant extra work and you can probably make more money by keeping the prices for this extra service high than by making it cheap. Also, an address is only of use (and value) when someone uses it. >> IPv6 addresses are free, because whatever the cost is, after dividing > Business/economic reality check: nothing is free. Certainly not a > protocol that requires heavy investments in new equipment and human > resources/skills. Sure, the switch to IPv6 isn't free. (The addresses are.) But you need to train people and upgrade equipment periodically anyway. So if you take long enough, the switch to IPv6 doesn't cost all that much money. However, if people prefer to stick their heads in the sand and then make the switch over night, that's going to be very expensive. >> What we should do is try to make the switch to IPv6 as painless as we >> can. The most important part of that is to make it predictable: we >> need to know what's going to happen in the next 5 years or so. > Interesting. You think we can make the migration "predictable" by > erecting a brick wall. The brick wall is already there: 3706.65 million usable addresses, 992.46 are still available. We get closer to the brick wall at a rate of about half a million addresses a day. > One logical consequence of this argument: no need > to wait, we can do it tomorrow, or as soon as ARIN agrees to adopt a > flag date where IPv4 just ends. Agree? 1. No: people wouldn't do it just because ARIN (or anyone else) mandates it 2. Obviously there are other costs than just unpredictability > Can you _really_ predict, with reasonable levels of probability, that > you will even prevent private unauthorized transfers from taking place > under those circumstances? Of course not. IP transit service usually comes with IP addresses. Unless the customer has a portable address range of their own, this is a necessary part of the service. Now this wouldn't be "buying" but more like "leasing" but that doesn't really matter in the grand scheme of things. The point is that IP addresses are a limited resource and everybody should have the same access to that resource. Some people getting it for (almost) free from ARIN and others paying a lot, but without conforming to the ARIN rules would be a bad outcome, because the ARIN rules are such that the level of address constraining pain is kept equal across the industry. Some rules only work if they are applied 100% all the time, but in most cases they are still beneficial if a few people break them, as long as this doesn't get out of hand. So the fact that a few people manage to get addresses in ways that they shouldn't doesn't automatically mean that we should remove the rules. Of course we have a small number of organizations that manage to hold a lot of space without conforming to the rules (the legacy holders, with the most prominent among them the US government with some 10 /8s) and ARIN and/or its counsel have conceded defeat there, which was a very bad thing. Fixing that by bribing these people to give up their address space won't make it right. > But why not go whole hog with the uncertainty argument: let's just > get a > decree to stop operating the IPv4 internet tomorrow. That would really > clear things up, eh? There is an important difference between not being able to deploy new address space and breaking the already deployed IPv4 installations. >> Any policy change means that there will be a bigger difference >> between >> what's being predicted and what will happen, > I'm afraid that that's not true. You are assuming that the migration > is > 1) a linear, progressive and predictable process and 2) will occupy a > known time period. Both assumptions are shaky. Nobody knows what will happen as we run out of IPv4 space. But as long as we can predict that this will happen with enough certainty that people can't ignore it (which is a point we're finally reaching right about now) everyone will be forced to start planning for a future where no new IPv4 space can be obtained. Presumably, some people will botch this and have a problem, but most people will come up with a strategy that works for them so the internet will continue to work after we run out of IPv4 space. > A transfer policy is a hedge. It maximizes efficient utilization of > remaining v4 resources while in no way precluding IPv6 migration. There was nothing precluding IPv6 migration five years ago. But nobody migrated. As long as people keep squeezing the IPv4 toothpaste tube they won't get around to buying a new tube and their teeth will rot in the meantime. So: let's use IPv4 the way we've been doing while it lasts and plan for a no-new-v4 future in the mean time. > In an environment of IPv4 scarcity, with large swaths of v4 address > blocks known to be underutilized, and with occupiers of address > resources needing an incentive to migrate, allowing holders of those > address blocks to financially benefit from releasing them is an > obvious > win. That's the only reason I support it. No. I'm 95% sure a functioning address market for IPv4 addresses won't form for the 1M+/yr address users (= all the broadband ISPs) because for them even a few dollars per address is more expensive than the alternatives while freeing up large address blocks is expensive. (You'd probably have to audit all of HP's IT infrastructure to see if there is old DEC gear that still has a 16.x.x.x address before you can sell off 16/8, for instance.) So we'll have a lot of confusion, experiments and waiting going on and two years from now we're still pretty much in the same boat except that then we have to make the transition in half the time that we have today. From iljitsch at muada.com Fri Aug 29 05:13:58 2008 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Fri, 29 Aug 2008 11:13:58 +0200 Subject: [arin-ppml] About NAT-PT.... (Re: Fantasyland) In-Reply-To: References: Message-ID: <95626FE1-05F4-47A4-A016-EEE33FEB8ACC@muada.com> On 29 aug 2008, at 0:07, Alain Durand wrote: > I read a lot of fantasy about NAT-PT those days, like it is going to > be the > silver bullet that will make this all problems go away... > NAT-PT is a v6 to v4 translator. Which mean, it only helps if your > internal > network is... v6. If you have any device in there that cannot do > IPv6 and > need to talk to the rest of the universe (think IP-webcam, gaming > device, > windows box prior to vista, load balancer, IDS, firewall, IMS, xyz > server,.... NAT-PT is *not* a solution for you. Nor would be any of > its > replacement candidates. > Dual-stack lite (see > http://tools.ietf.org/html/draft-durand-dual-stack-lite-00) might be a > better approach in that space. It is being standardized by IETF in the > softwire working group. Sorry for overquoting. Note that dual stack light (plz run a spell check on your title, Alain!) is just a clever way to do two things: - make life for ISPs easier so they don't have to route RFC 1918 space internally - make life for end-users easier so they can keep their IPv4-only stuff and don't have to go through multiple NATs Apart from that it's still basically ISP-operated NAT with all the downsides that that entails. Which includes no easy and reliable way to make incoming connections work: on a good day VoIP that conforms to the latest IETF standards may work, but no webcams and probably very little BitTorrent until they start using completely new NAT traversal techniques. So you still want IPv6 for that webcam and most of your peer-to-peer stuff. From BillD at cait.wustl.edu Fri Aug 29 07:32:00 2008 From: BillD at cait.wustl.edu (Bill Darte) Date: Fri, 29 Aug 2008 06:32:00 -0500 Subject: [arin-ppml] Fantasyland References: <20080828101711.GA30839@vacation.karoshi.com.> <20080828214539.GA6973@vacation.karoshi.com.> Message-ID: Now THAT is interesting....and disappointing... I believe it makes a fantastic scorecard and target for 'anyone' who wishes to influence practical participation in the IPv6 Internet. I know that I will be sharing this with my colleagues at Washington University in St. Louis. I hope we all learn to appreciate the taste of dogfood. Bill Darte ARIN AC Washington University in St. Louis -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of bmanning at vacation.karoshi.com Sent: Thu 8/28/2008 4:45 PM To: michael.dillon at bt.com Cc: ppml at arin.net Subject: Re: [arin-ppml] Fantasyland On Thu, Aug 28, 2008 at 12:03:29PM +0100, michael.dillon at bt.com wrote: > > > Why shouldn't the company in question just deploy IPv6 and install > > > NAT-PT gateways to cover the next 2-3 years before > > > IPv6 transit is widely available? > > > Please provide a vendor list for NAT-PT gateways that > > provide production level service/availability - today. > > I would hope that the company in question would plan their deployment > exercise and not just rush out buying equipment and blasting out their > old network. As part of the planning exercise, they might go to the ARIN > IPv6 wiki at > where they will note vendor names. If they contact said vendors, then > there is motivation for said vendors to provide production level service > and availabilty within the timeframe for implementation. Note that there > is also the possibility of consulting firms using open-source NAT-PT who > would then provide the SLA and support component. > > Obviously, today, there is only one vendor on that page and no mention > of > where open-source NAT-PT can be found. I would hope that anyone with > more > information would log on to the wiki and update this page and others. which raises the question of "eating our own dogfood"... there have been a number of calls for folks to take first steps to get their "externally" facing DNS, SMTP, HTTP services visable on IPv6. One might find this survey of interest. http://www.mrp.net/IPv6_Survey.html clearly we have a ways to go to meet the first hurdle. As for NAT-PT, the IETF is still trying to settle on a standard. --bill _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cliffb at cjbsys.bdb.com Fri Aug 29 08:40:21 2008 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Fri, 29 Aug 2008 08:40:21 -0400 (EDT) Subject: [arin-ppml] IANA IPv4 /8 burn rate.... Message-ID: <200808291240.m7TCeL6K024278@cjbsys.bdb.com> Iljitsch van Beijnum wrote ... There was nothing precluding IPv6 migration five years ago. But nobody migrated. As long as people keep squeezing the IPv4 toothpaste tube they won't get around to buying a new tube and their teeth will rot in the meantime. ... When the new toothpaste costs a lot more and it doesn't really protect your teeth in its current form, you can bet that people will squeeze that tube for all it's worth. Cliff -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From info at arin.net Fri Aug 29 08:57:57 2008 From: info at arin.net (Member Services) Date: Fri, 29 Aug 2008 08:57:57 -0400 Subject: [arin-ppml] ARIN XXII Remote Participation and Webcast Message-ID: <48B7F255.6050707@arin.net> Even if you can?t join us in LA for ARIN XXII, you can still play a vital role. To facilitate community participation, ARIN offers free remote participation to any individual. Registered remote participants may post questions or comments, via e-mail, which will be moderated and presented during normal question and answer periods throughout the agenda. All ARIN XXII activities involving public participation and comment, including the Open Policy Hour and the ARIN Public Policy and Members Meetings will be webcast. Only remote registrants will be able to submit questions and comments, and all remote participants are subject to the Remote Participation Acceptable Use Policy (AUP). Registration for remote participation is available through our online meeting registration system. To register, please visit the ARIN XXII home page: http://www.arin.net/ARIN-XXII/, click the "Register for the Meeting" button at the top of the page, choose "ARIN XXII Remote Participant" from the drop-down box, and complete the subsequent form. The live meeting webcast is available without registering as a remote participant. Additional information about remote participation and the webcast, including the Remote Participation AUP, is available at: http://www.arin.net/ARIN-XXII/webcast.html Webcast access details will be posted through the link above before the meeting. The webcast will begin Tuesday, 14 October 2008 at 6:00 PM PDT (UTC/GMT -7 hours). Regards, Member Services American Registry for Internet Numbers (ARIN) From jhg at omsys.com Fri Aug 29 10:58:33 2008 From: jhg at omsys.com (Jeremy H. Griffith) Date: Fri, 29 Aug 2008 07:58:33 -0700 Subject: [arin-ppml] Results of Transfer Proposal Survey In-Reply-To: References: <48B42317.5070108@arin.net> <723083FF30894BF28532E39AC06E7859@tedsdesk> Message-ID: <8e3gb412d8mja53osg8ec2rdrbdadbfah4@4ax.com> On Tue, 26 Aug 2008 15:59:36 -0500, "Bill Darte" wrote: >No-one had to answer any question...therefore the could have skipped to >the bottom and said NO.... > >but....to ask the question.... > >All those against a liberalized transfer policy of any kind...please >reply saying so... Me. I'm one of those legacy Class C swamp dwellere. I have absolutely no intention of selling "my" addresses, and see no reason anyone else should either. I can see justification for ARIN to offer incentives to those who don't need all they have, perhaps in the form of reduced fees. But I do not think we as a community will benefit from making money replace need as a criterion for address assignment. That's privatization, not stewardship. Personally, I don't meet the current ARIN criteria for need because I cannot justify half of a /22. I'm not an LIR. But I certainly can justify need for *some* PI space. When this debate began, I seriously considered whether I could return part of my /24 to help; I could live with a /28. But my main upstream dissuaded me on the grounds that nothing below a /24 was routable, and therefore I would accomplish nothing. I suspect that anyone with a legacy Class C is in the same boat. As to supporting whois service, I've kept my contact info current since 1992. The beneficiary of this service is *not* me; in fact, I tend to suffer for it, since I'm sure it's a source of spam. But the *rest* of the community benefits from knowing who to call in case of trouble. Charging me for this "service" seems like a more cynical manipulation than I believe ARIN capable of. I hope. ;-) That means that for me, the LRSA has no benefit at all. While $100/year isn't that much, it's about what I pay for ten domains at the moment. And ARIN is hardly hurting for income; in an earlier thread, the problem was that ARIN wasn't spending fast enough and was accumulating more surplus than the IRS allows for nonprofits! So my $100 would make that problem worse... or, it could go to an orphanage in Afghanistan I'm helping: https://www.charityhelp.org/rawa --JHG From pete.templin at texlink.com Fri Aug 29 11:16:03 2008 From: pete.templin at texlink.com (Pete Templin) Date: Fri, 29 Aug 2008 10:16:03 -0500 Subject: [arin-ppml] Results of Transfer Proposal Survey In-Reply-To: <8e3gb412d8mja53osg8ec2rdrbdadbfah4@4ax.com> References: <48B42317.5070108@arin.net><723083FF30894BF28532E39AC06E7859@tedsdesk> <8e3gb412d8mja53osg8ec2rdrbdadbfah4@4ax.com> Message-ID: <8A4B226B2C92FC4F81C386F8F2F7D5297F0901@hqserv03.texlinkcom.com> -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jeremy H. Griffith Sent: Friday, August 29, 2008 9:59 AM To: ppml at arin.net Subject: Re: [arin-ppml] Results of Transfer Proposal Survey > Personally, I don't meet the current ARIN criteria for need > because I cannot justify half of a /22. I'm not an LIR. But > I certainly can justify need for *some* PI space. I'm curious...what's the justification for _needing_ PI space? Pt From jcurran at istaff.org Fri Aug 29 11:52:48 2008 From: jcurran at istaff.org (John Curran) Date: Fri, 29 Aug 2008 11:52:48 -0400 Subject: [arin-ppml] Merits of "returning" part of a class C In-Reply-To: <8e3gb412d8mja53osg8ec2rdrbdadbfah4@4ax.com> References: <48B42317.5070108@arin.net> <723083FF30894BF28532E39AC06E7859@tedsdesk> <8e3gb412d8mja53osg8ec2rdrbdadbfah4@4ax.com> Message-ID: <87A4EF0D-4D20-46E2-A307-84891A17FBAD@istaff.org> On Aug 29, 2008, at 10:58 AM, Jeremy H. Griffith wrote: > > Personally, I don't meet the current ARIN criteria for need > because I cannot justify half of a /22. I'm not an LIR. But > I certainly can justify need for *some* PI space. When this > debate began, I seriously considered whether I could return > part of my /24 to help; I could live with a /28. But my main > upstream dissuaded me on the grounds that nothing below a /24 > was routable, and therefore I would accomplish nothing. I > suspect that anyone with a legacy Class C is in the same boat. Quite likely, unless our expectations of what is routable changes significantly in the near future. I'll note that at some point your ISP may change its tune on the merits of having you squeeze down into a /26, particularly since the remainder would be already routed by the ISP, and useful for connecting additional IPv4 customers in about 3 years... This wouldn't be "returning" per se, but a transfer per relaxed policy in a post-depletion world, if such is available. /John p.s. The decision to take an ISP up on such an offer is rather interesting; you might want service level assurances in addition any transfer incentive (since one's ability to leave without renumbering could be quite limited given your resulting block size and prevailing routing policy) From jcurran at istaff.org Fri Aug 29 12:22:21 2008 From: jcurran at istaff.org (John Curran) Date: Fri, 29 Aug 2008 12:22:21 -0400 Subject: [arin-ppml] The LRSA $100 fee... In-Reply-To: <8e3gb412d8mja53osg8ec2rdrbdadbfah4@4ax.com> References: <48B42317.5070108@arin.net> <723083FF30894BF28532E39AC06E7859@tedsdesk> <8e3gb412d8mja53osg8ec2rdrbdadbfah4@4ax.com> Message-ID: <5C39F7C4-5F32-469F-AC1A-E9DF7BCBD21E@istaff.org> On Aug 29, 2008, at 10:58 AM, Jeremy H. Griffith wrote: > ... > As to supporting whois service, I've kept my contact info > current since 1992. The beneficiary of this service is *not* > me; in fact, I tend to suffer for it, since I'm sure it's a > source of spam. But the *rest* of the community benefits > from knowing who to call in case of trouble. Charging me for > this "service" seems like a more cynical manipulation than > I believe ARIN capable of. I hope. ;-) Your service to the community in keeping your contact information up to date is so noted, and thanks! With respect to charging you under the LRSA for this "service", see below. > That means that for me, the LRSA has no benefit at all. While > $100/year isn't that much, it's about what I pay for ten domains > at the moment. And ARIN is hardly hurting for income; in an > earlier thread, the problem was that ARIN wasn't spending fast > enough and was accumulating more surplus than the IRS allows > for nonprofits! So my $100 would make that problem worse... Okay, to be clear, ARIN's got a surplus today but that's a good thing. We've lowered fees 5 times, added new services, and I know that I'll at least advocate that continue to reduce fees and increase services to the extent that seems financially prudent. If one takes a very long term view, it's clear that there will not be a lot of allocation activity with IPv6 (i.e. folks coming back for additional blocks ;-) and it's uncertain whether there will be much IPv6 policy activity. It's a valid question as to what level of subscription to registration services is needed when someone doesn't anticipating putting in their next Internet resource request within the same decade, and hence what fees should apply. For reference (from the online Annual Report), subscription services fees made up just over 85% of ARIN's total receipts, so any significant change in the nature of subscription services or fees could have a significant impact on ARIN's overall finances. As a result, it seems a good idea of address block holders to pay a nominal amount to insure that the common registry was maintained regardless of registration services activity going on an RIR. I do not know whether $100 is the right number or not, but setting it to any lower number today runs the risk that that processing costs with receiving purchase orders, invoicing, collection begin to offset receipts significantly. It's relatively to easy to lower if we get to that world, and put the same level of automation in place that the domain folks have, and see that we're over-recovering compared to operating costs. /John (speaking personal views and without consultation w/fellow Board members) From farmer at umn.edu Fri Aug 29 12:33:51 2008 From: farmer at umn.edu (David Farmer) Date: Fri, 29 Aug 2008 11:33:51 -0500 Subject: [arin-ppml] IPv4 is depleted today Message-ID: <48B7DE9F.7707.3AEC08B@farmer.umn.edu> When will IPv4 be depleted? Well I realized yesterday that for me and many other Legacy holders it already is. Let's step back a minute, from discussion on the list its become obvious to me that IPv4 depletion isn't a singe event like when the IANA or ARIN Free Pools are depleted, it is not a magic date. It is a series of events or dates that occurs when each organization can't easily get any more addresses. For some networks, that date will come before others, and for some that date could be a long ways away. Then, I realized for some of us that day already came a long time ago, especially for many Legacy holders. Actually, for UMN that day was 8 or 10 years ago, when I realized we will never ever justify another IPv4 address assignment, nor should we for that matter. I'm not complaining or bragging, but stating a fact. You could argue that we don't deserve the resources we have and should return some. I'll grant you the right to your opinion. I have arguments why I believe your wrong. However, both are irrelevant to this line of thought. The discussion about what IP addresses cost got me thinking about this. Because, IP address have been quite expensive for us for sometime, not in hard currency, but in remembering and reorganizing within the IPv4 address space we have. This is no where as easy as some on the list try to make it sound, NATs don't scale for us in bandwidth, number of flows, or cost. There are a few places we use RFC1918 addresses, mostly for things that don't ever need to talk to the Public Internet, but DNS issues both for reverse and the leaking of forward DNS out to the Internet make this very ugly and just as much of a Hack as NAT. We are considering very limited uses of NAT, like for visitor wireless access. Personally, I can't compare these costs to the costs associated with justifying more address space through ARIN. Realistically we can't do that, at least not until very long after IANA free pool exhaustion. It is possible that they are comparable, I don't know. You might say we (UMN) really have not and probably will not completely exhaust our IPv4 address, that is use it to 100%, well that is probably true. But, this is probably going to be true for all networks. There are very few if any networks that use each and every address they have. There will always be little unused bits within subnets and small subnets sitting around in all networks. The difference is only a matter of degree and the rate of growth for each network. Eventually, each network will get into a dead-lock state where they don't have enough resources to maneuver to free up old resource, or a pseudo-dead-lock where it is more costly than it is worth to free up old resources. So what will we (UMN) do when the IANA and ARIN IPv4 free pools are gone? Well, much the same as we are doing now, try to make use of our current resources more efficiently. We probably will never sell or return our current IPv4 address space it is to valuable internally. We might share it with other less directly associated customers or projects, but always public entities. What about IPv6 you ask, well we have been working on it for sometime, the GigaPOP (think of it as an Internet2 regional ISP) we operate has been doing IPv6 for over 5 years. I my opinion, IPv6 transport is very easy, and been that way for a while. Where things get much harder is the local subnet and with the host. We have had IPv6 operating in our lab off and on over the last 5 years, for about the past year we have had it in Beta on the network engineers and security folks subnets. I hope to enable it on our whole backbone and make it available anywhere anyone wants it yet this year or early next, then in 2010 or 2011 turn it on by default everywhere on campus. Personally I think, increased use IPv4 NAT, some kind of transfer policy, or forced return of unused resources, will be necessary to extend the life of IPv4 long enough for us to get IPv6 ramped up. I think a transfer policy will be cleaner than trying to force people to return resources. But please don't take that as saying I like those options or that it is an alternative to deploying IPv6, it is just necessary. We have to do BOTH, we have to keep the IPv4 elephants dancing until we get all the IPv6 elephants dancing. I loved that pice of metaphoric imagery.:) So, if you haven't started tuning up the IPv6 band for the IPv6 elephants get started now, the IPv4 elephants are starting to get tired. ======================================================= David Farmer Email: farmer at umn.edu Office of Information Technology Networking & Telecomunication Services University of Minnesota Phone: 612-626-0815 2218 University Ave SE Cell: 612-812-9952 Minneapolis, MN 55414-3029 FAX: 612-626-1818 ======================================================= From jmorrison at bogomips.com Fri Aug 29 13:02:54 2008 From: jmorrison at bogomips.com (John Paul Morrison) Date: Fri, 29 Aug 2008 10:02:54 -0700 Subject: [arin-ppml] The LRSA $100 fee... In-Reply-To: <5C39F7C4-5F32-469F-AC1A-E9DF7BCBD21E@istaff.org> References: <48B42317.5070108@arin.net> <723083FF30894BF28532E39AC06E7859@tedsdesk> <8e3gb412d8mja53osg8ec2rdrbdadbfah4@4ax.com> <5C39F7C4-5F32-469F-AC1A-E9DF7BCBD21E@istaff.org> Message-ID: <48B82BBE.80907@bogomips.com> Existing domain registrars can process orders, invoicing, payment etc. for $10/year. To reduce overhead, a single $100 fee could be charged up front and cover a 10 year period. It doesn't take any more work for ARIN to enter "today's date + 10 years" instead of "today's date + 1 year" in a database. If ARIN really can't deliver service at that level, then those functions should be contracted out to a private operator or operators in the same way that .com registrations are handled. As far as Legacy Agreements go, I see no reason so sign anything now that might waive any rights I may (or may not) have, in advance of some other ruling compelling me. But I am not opposed to simply signing up and paying a fair rate for a service that is limited to the whois and reverse DNS functions, as long as it's clear that is all I am signing up and paying for. If a policy tries to link reverse DNS/whois service with signing some other agreement, then I'm not in favor. I think it is reasonable to pay for the basic services that are provided, and reasonable for ARIN to suspend whois and reverse DNS to those who don't pay. Failure to keep up to date on paying for one's whois and reverse DNS service might eventually become part of the criteria in a legal ruling or policy that one has abandoned their IP address space and it can be returned to the community. Failure to have DNS and whois records could also impact your ability to route or transfer those addresses. The situation is a lot like property taxes (without getting into whether IP addresses are free-hold property or a long term lease). You may not like the fact that the frontier has grown up into a city around what used to be wilderness, but now you have to pay your property taxes. If you don't pay, problems will stack up for you. You may not get thrown out, but you'll have a hard time doing things, and eventually the tax man will get paid. On 8/29/2008 9:22 AM, John Curran wrote: > As a result, it seems a good idea of address block holders to pay > a nominal amount to insure that the common registry was maintained > regardless of registration services activity going on an RIR. I do > not know whether $100 is the right number or not, but setting it to > any lower number today runs the risk that that processing costs with > receiving purchase orders, invoicing, collection begin to offset > receipts significantly. It's relatively to easy to lower if we get > to that world, and put the same level of automation in place that > the domain folks have, and see that we're over-recovering compared > to operating costs. > > /John > > (speaking personal views and without > consultation w/fellow Board members) > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From bill at herrin.us Fri Aug 29 13:33:54 2008 From: bill at herrin.us (William Herrin) Date: Fri, 29 Aug 2008 13:33:54 -0400 Subject: [arin-ppml] The LRSA $100 fee... In-Reply-To: <48B82BBE.80907@bogomips.com> References: <48B42317.5070108@arin.net> <723083FF30894BF28532E39AC06E7859@tedsdesk> <8e3gb412d8mja53osg8ec2rdrbdadbfah4@4ax.com> <5C39F7C4-5F32-469F-AC1A-E9DF7BCBD21E@istaff.org> <48B82BBE.80907@bogomips.com> Message-ID: <3c3e3fca0808291033v74b58d99x648b0fcb0c83c482@mail.gmail.com> On Fri, Aug 29, 2008 at 1:02 PM, John Paul Morrison wrote: > Existing domain registrars can process orders, invoicing, payment etc. > for $10/year. Perhaps ARIN could charge you $1/year to process orders, invoicing, payment, etc. for each address and offer a "bulk discount" of $100/year to cover all of your addresses. Why, then they'd be giving you a 90% discount off the normal registrar's $10 price! What a deal! What a deal. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From alain_durand at cable.comcast.com Fri Aug 29 13:48:48 2008 From: alain_durand at cable.comcast.com (Alain Durand) Date: Fri, 29 Aug 2008 13:48:48 -0400 Subject: [arin-ppml] About NAT-PT.... (Re: Fantasyland) In-Reply-To: <95626FE1-05F4-47A4-A016-EEE33FEB8ACC@muada.com> Message-ID: On 8/29/08 5:13 AM, "Iljitsch van Beijnum" wrote: > So you still want IPv6 for that webcam and most of your peer-to-peer > stuff. Oh, yes... 100% agreed. The point is that DS-lite offers a way to get there. Alain. From Lee.Howard at stanleyassociates.com Fri Aug 29 14:09:01 2008 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 29 Aug 2008 14:09:01 -0400 Subject: [arin-ppml] The LRSA $100 fee... In-Reply-To: <48B82BBE.80907@bogomips.com> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40B2033D4@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Paul Morrison > Sent: Friday, August 29, 2008 1:03 PM > To: John Curran > Cc: ppml at arin.net > Subject: Re: [arin-ppml] The LRSA $100 fee... > > Existing domain registrars can process orders, invoicing, > payment etc. for $10/year. > To reduce overhead, a single $100 fee could be charged up > front and cover a 10 year period. > It doesn't take any more work for ARIN to enter "today's date > + 10 years" instead of "today's date + 1 year" > in a database. It is my humble opinion that domain name registrars suck. The best of them provides lousy service and near-useless WHOIS. Competition has ruined registry services by starting a race to the bottom in price and service. It may be the case in an all-IPv6 world that very little processing is required for initial allocations/assignments. Until we have better-automated authentication, changes to records will still be expensive in labor. We could go to a transactional model, but then every update (for community benefit) has a disincentive fee. > As far as Legacy Agreements go, I see no reason so sign > anything now that might waive any rights I may (or may not) > have, in advance of some other ruling compelling me. What rights do you have that would be waived under the Legacy RSA? > But I am not opposed to simply signing up and paying a fair > rate for a service that is limited to the whois and reverse What's fair? Lee From JOHN at egh.com Fri Aug 29 14:19:50 2008 From: JOHN at egh.com (John Santos) Date: Fri, 29 Aug 2008 14:19:50 -0400 Subject: [arin-ppml] Results of Transfer Proposal Survey In-Reply-To: <8e3gb412d8mja53osg8ec2rdrbdadbfah4@4ax.com> Message-ID: <1080829134107.13222F-100000@Ives.egh.com> On Fri, 29 Aug 2008, Jeremy H. Griffith wrote: > On Tue, 26 Aug 2008 15:59:36 -0500, "Bill Darte" wrote: > > >No-one had to answer any question...therefore the could have skipped to > >the bottom and said NO.... > > > >but....to ask the question.... > > > >All those against a liberalized transfer policy of any kind...please > >reply saying so... > > Me. I'm one of those legacy Class C swamp dwellere. > I have absolutely no intention of selling "my" addresses, and see > no reason anyone else should either. I can see justification for > ARIN to offer incentives to those who don't need all they have, > perhaps in the form of reduced fees. But I do not think we as a > community will benefit from making money replace need as a criterion > for address assignment. That's privatization, not stewardship. > > Personally, I don't meet the current ARIN criteria for need > because I cannot justify half of a /22. I'm not an LIR. But > I certainly can justify need for *some* PI space. When this > debate began, I seriously considered whether I could return > part of my /24 to help; I could live with a /28. But my main > upstream dissuaded me on the grounds that nothing below a /24 > was routable, and therefore I would accomplish nothing. I > suspect that anyone with a legacy Class C is in the same boat. > > As to supporting whois service, I've kept my contact info > current since 1992. The beneficiary of this service is *not* > me; in fact, I tend to suffer for it, since I'm sure it's a > source of spam. But the *rest* of the community benefits > from knowing who to call in case of trouble. Charging me for > this "service" seems like a more cynical manipulation than > I believe ARIN capable of. I hope. ;-) > > That means that for me, the LRSA has no benefit at all. While > $100/year isn't that much, it's about what I pay for ten domains > at the moment. And ARIN is hardly hurting for income; in an > earlier thread, the problem was that ARIN wasn't spending fast > enough and was accumulating more surplus than the IRS allows > for nonprofits! So my $100 would make that problem worse... > or, it could go to an orphanage in Afghanistan I'm helping: > https://www.charityhelp.org/rawa > > > --JHG Well said, Jeremy. I wholeheartedly agree with 99% of this. The only bit I'm not sure of is whether a liberalized transfer market, would actually help the transition or not. I have no interest in selling my legacy Class C, and it seems pretty clear that /24's would have little or no market value anyway, but some sort of award for recycling /16's or larger might delay hitting the *wall* for a while. On the other hand, it might produce a California electricity situation, where the rich get richer and everyone else pays through the nose. My instincts say a market would result in rampant speculation, bubbles and busts, and the ultimate concentration of wealth (i.e. addresses and money paid for the use of them) and power in the hands of the few, but I don't always trust my instincts in economic matters. I currently use slight more than half of a /24, but if I were to move local-only hosts to a private address range, I could probably shrink to a /25 or /26, a few more than Jeremy needs, but equally pointless. In my situation, I need several dozen globally unique, static addresses for connections with various customers. All of them use RFC 1918 addressing internally and independently of each other, and my addresses can't collide with *any* of them. Like Jeremy, I couldn't justify half of a /22, but I can justify a /24 (with current usage) and even if I took heroic measures, would still need at least a /26. I've also kept my whois up to date, which may be one source of the several hundred SPAMs I get every day. There may be economies of scale, due the relatively small numbers of RDNS domains, but commercial .com providers seem to be able to maintain DNS profitably for about $10/year. (Seems to me that originally our domain from NETSOL was about $50/year, but has come down a lot since then, but consumer-level domain providers seem to charge even less.) If ARIN feels it needs to charge $100 per year to keep things serious, maybe a portion (50%?) should be donated to some worthwhile cause, maybe computer science scholarships at some third-world university or providing Internet service to elementary schools or hospitals in poor countries, if we wan't to keep it somehow network or computer related. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From jhg at omsys.com Fri Aug 29 14:26:02 2008 From: jhg at omsys.com (Jeremy H. Griffith) Date: Fri, 29 Aug 2008 11:26:02 -0700 Subject: [arin-ppml] The LRSA $100 fee... In-Reply-To: <3c3e3fca0808291033v74b58d99x648b0fcb0c83c482@mail.gmail.com> References: <48B42317.5070108@arin.net> <723083FF30894BF28532E39AC06E7859@tedsdesk> <8e3gb412d8mja53osg8ec2rdrbdadbfah4@4ax.com> <5C39F7C4-5F32-469F-AC1A-E9DF7BCBD21E@istaff.org> <48B82BBE.80907@bogomips.com> <3c3e3fca0808291033v74b58d99x648b0fcb0c83c482@mail.gmail.com> Message-ID: <47fgb410p1k4cmsvs8hn4ek5jo7tmviu69@4ax.com> On Fri, 29 Aug 2008 13:33:54 -0400, "William Herrin" wrote: >Perhaps ARIN could charge you $1/year to process orders, invoicing, >payment, etc. for each address and offer a "bulk discount" of >$100/year to cover all of your addresses. Why, then they'd be giving >you a 90% discount off the normal registrar's $10 price! What a deal! >What a deal. LOL! The last time the notion of per-address pricing came up here, the figure that would give ARIN the same income as under the current scheme was about $.06, IIRC... I'd happily do that, at $15.36/year for a /24, and would pay five years at a time to reduce overheads (which I do for the domains already, BTW). But somehow, I doubt if the folks with /8s would be nearly as pleased, since they pay far, far less per address now... and as that group is well represented on the ARIN board... However, wouldn't that be a great incentive to return what you don't really need? Want to write up the proposal, Bill? ;-) --JHG From tedm at ipinc.net Fri Aug 29 15:13:33 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 29 Aug 2008 12:13:33 -0700 Subject: [arin-ppml] IPv4 is depleted today In-Reply-To: <48B7DE9F.7707.3AEC08B@farmer.umn.edu> Message-ID: There are a couple of phrases in this post I found most humorous: "...return our current IPv4 address space it is to valuable internally...." "...will be necessary to extend the life of IPv4 long enough for us to get IPv6 ramped up..." What our esteemed colleague David is saying is in essence he wants a transfer policy because he has a lot of IPv4 and he (understandably) wants to continue to use it. He labels IPv6 not ready, why not? He already has plenty of IPv4, he doesn't need IPv6. He has no incentive to deploy IPv6, really. He also won't give his network's IPv4 up to "sell" through a transfer policy, or course not. He is just expecting every other legacy holder out there to sell off their IPv4. The situation reminds me when my city, Portland OR, put in Light Rail. Everyone driving cars in the city strongly supported light rail. They all wanted it because the figured that "the OTHER guy" would stop driving his car, and take light rail, and get the heck off the freeway so that THEY could drive an uncongested freeway. Needless to say, the freeway congestion did NOT go away. I would ask our colleague that if he feels that it would be too much trouble for him to split his legacy block to be able to sell off part of it under a liberalized transfer policy, doesn't he think that everyone else with a legacy block is going to feel the same way? Why is he special? And if every other legacy holder feels this way, then where exactly are these IPv4 blocks going to come from that will be sold through a liberalized transfer policy, that will "extend the life of IPv4" as he puts it. In short, he meticulously explains why a liberalized transfer policy would do absolutely nothing to help him return his unused IPv4 space to the free pool, then proceeds to claim that we need a liberalized transfer policy to enable more IPv4 to be returned to the free pool!!! I can't think of a more damming example of why a liberalized transfer policy would be about as useful as teats on a boar. Ted > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer > Sent: Friday, August 29, 2008 9:34 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] IPv4 is depleted today > > > When will IPv4 be depleted? Well I realized yesterday that > for me and many > other Legacy holders it already is. > > Let's step back a minute, from discussion on the list its > become obvious to > me that IPv4 depletion isn't a singe event like when the IANA > or ARIN Free > Pools are depleted, it is not a magic date. It is a series > of events or dates > that occurs when each organization can't easily get any more > addresses. > For some networks, that date will come before others, and for > some that > date could be a long ways away. Then, I realized for some of > us that day > already came a long time ago, especially for many Legacy holders. > > Actually, for UMN that day was 8 or 10 years ago, when I > realized we will > never ever justify another IPv4 address assignment, nor > should we for that > matter. I'm not complaining or bragging, but stating a fact. > You could argue > that we don't deserve the resources we have and should return > some. I'll > grant you the right to your opinion. I have arguments why I > believe your > wrong. However, both are irrelevant to this line of thought. > > The discussion about what IP addresses cost got me thinking > about this. > Because, IP address have been quite expensive for us for > sometime, not in > hard currency, but in remembering and reorganizing within the > IPv4 address > space we have. This is no where as easy as some on the list > try to make it > sound, NATs don't scale for us in bandwidth, number of flows, > or cost. > > There are a few places we use RFC1918 addresses, mostly for > things that > don't ever need to talk to the Public Internet, but DNS > issues both for > reverse and the leaking of forward DNS out to the Internet > make this very > ugly and just as much of a Hack as NAT. We are considering > very limited > uses of NAT, like for visitor wireless access. > > Personally, I can't compare these costs to the costs associated with > justifying more address space through ARIN. Realistically we > can't do that, > at least not until very long after IANA free pool exhaustion. > It is possible that > they are comparable, I don't know. > > You might say we (UMN) really have not and probably will not > completely > exhaust our IPv4 address, that is use it to 100%, well that > is probably true. > But, this is probably going to be true for all networks. > There are very few if > any networks that use each and every address they have. > There will always > be little unused bits within subnets and small subnets > sitting around in all > networks. The difference is only a matter of degree and the > rate of growth > for each network. Eventually, each network will get into a > dead-lock state > where they don't have enough resources to maneuver to free up old > resource, or a pseudo-dead-lock where it is more costly than > it is worth to > free up old resources. > > So what will we (UMN) do when the IANA and ARIN IPv4 free pools are > gone? Well, much the same as we are doing now, try to make > use of our > current resources more efficiently. We probably will never > sell or return our > current IPv4 address space it is to valuable internally. We > might share it > with other less directly associated customers or projects, > but always public > entities. > > What about IPv6 you ask, well we have been working on it for > sometime, the > GigaPOP (think of it as an Internet2 regional ISP) we operate > has been > doing IPv6 for over 5 years. I my opinion, IPv6 transport is > very easy, and > been that way for a while. Where things get much harder is > the local subnet > and with the host. We have had IPv6 operating in our lab off > and on over > the last 5 years, for about the past year we have had it in > Beta on the > network engineers and security folks subnets. I hope to > enable it on our > whole backbone and make it available anywhere anyone wants it > yet this > year or early next, then in 2010 or 2011 turn it on by > default everywhere on > campus. > > Personally I think, increased use IPv4 NAT, some kind of > transfer policy, or > forced return of unused resources, will be necessary to > extend the life of > IPv4 long enough for us to get IPv6 ramped up. I think a > transfer policy will > be cleaner than trying to force people to return resources. > > But please don't take that as saying I like those options or > that it is an > alternative to deploying IPv6, it is just necessary. We have > to do BOTH, we > have to keep the IPv4 elephants dancing until we get all the > IPv6 elephants > dancing. I loved that pice of metaphoric imagery.:) So, if > you haven't > started tuning up the IPv6 band for the IPv6 elephants get > started now, the > IPv4 elephants are starting to get tired. > > > > ======================================================= > David Farmer Email: farmer at umn.edu > Office of Information Technology > Networking & Telecomunication Services > University of Minnesota Phone: > 612-626-0815 > 2218 University Ave SE Cell: > 612-812-9952 > Minneapolis, MN 55414-3029 FAX: 612-626-1818 > ======================================================= > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From stephen at sprunk.org Fri Aug 29 15:13:43 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 29 Aug 2008 14:13:43 -0500 Subject: [arin-ppml] The LRSA $100 fee... In-Reply-To: <48B82BBE.80907@bogomips.com> References: <48B42317.5070108@arin.net> <723083FF30894BF28532E39AC06E7859@tedsdesk> <8e3gb412d8mja53osg8ec2rdrbdadbfah4@4ax.com> <5C39F7C4-5F32-469F-AC1A-E9DF7BCBD21E@istaff.org> <48B82BBE.80907@bogomips.com> Message-ID: <48B84A67.50608@sprunk.org> John Paul Morrison wrote: > Existing domain registrars can process orders, invoicing, payment etc. > for $10/year. To reduce overhead, a single $100 fee could be charged up front and cover a 10 year period. It doesn't take any more work for ARIN to enter "today's date + 10 years" instead of "today's date + 1 year" in a database. > > If ARIN really can't deliver service at that level, then those functions should be contracted out to a private operator or operators in the same way that .com registrations are handled. > ... > But I am not opposed to simply signing up and paying a fair rate for a service that is limited to the whois and reverse DNS functions, as long as it's clear that is all I am signing up and paying for. If a policy tries to link reverse DNS/whois service with signing some other agreement, then I'm not in favor. > I hate to quote myself, particularly after only a day has passed, but I think my prior response to another commenter addresses your points as well, and you appear to have missed it in the flood of comments: > I'll point out that the $100/yr maintenance fee is the same charged to > _any_ org that has _any_ number of assignments under RSA or LRSA. Now, > if you'd prefer to pay $10/yr per object, like you do with domain names, > that's a valid suggestion to put to the BoT, who are the folks that set > the fee schedule (not PPML). If you think that a flat fee is good, but > that [$100 is] too high, consider the number of orgs that have dozens to > hundreds of objects, and that has to be averaged out. > ... > Also, please keep in mind that all fees contain a contribution to > support the public policy process, outreach activities, and other > resources and services for the community at large that inherently must > be "free" to the beneficiaries. S From stephen at sprunk.org Fri Aug 29 15:23:54 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 29 Aug 2008 14:23:54 -0500 Subject: [arin-ppml] Further revisions to 2008-2? In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E501@SUEXCL-02.ad.syr.edu> References: <0E9AFED7A08B4566A79CDE80F22686B2@tedsdesk> <48B5F575.2000001@internap.com> <7663C7E01D8E094989CA62F0B0D21CD901E0E501@SUEXCL-02.ad.syr.edu> Message-ID: <48B84CCA.7050707@sprunk.org> Milton L Mueller wrote: >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand >> >> But in addition to (re)debating those points, I'd love to hear any further feedback on how folks think we should revise 2008-2. There will be a consensus call on it at L.A., and I'd like to have the best possible >> proposal on the table when we get to that point > > I may have made my view on this known, but in case not: > * Authenticate sellers only, do not bring the RSA or LRSA into it. > * Reduce the "freeze" for buyers from 2 years to 1 year in line with the > survey results. > * Implement immediately, don't wait for "free pool depletion" > I'm still on the fence about supporting the proposal due to concerns about paid transfers in general, but I think these changes make sense, do not hurt the proposal in any meaningful way, and are more consistent with the other RIRs if we do end up deciding to go down that path. > * put a 3-4 year sunset on the geographic restrictions, re-evaluate that > issue after a while I'm opposed to this, however. If the proposal is implemented, we can still modify it at any time in the future if consensus is gained. I am opposed to any "sunset" provision that would kick in at an arbitrary point in the future without another trip through the policy cycle to build consensus in light of the actual circumstances of that time. Also, we would need a global policy, passed by all five RIRs, to properly implement inter-region transfers. We still don't know if intra-region transfer proposals will pass in _any_ region, nor what their differences may be if/when they do (and so far, there are many). Let's not borrow that trouble today. S From tedm at ipinc.net Fri Aug 29 16:27:23 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 29 Aug 2008 13:27:23 -0700 Subject: [arin-ppml] The LRSA $100 fee... In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40B2033D4@CL-S-EX-1.stanleyassociates.com> Message-ID: <6B79B308F41D4C46A6F534727F703034@tedsdesk> > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Howard, W. Lee > Sent: Friday, August 29, 2008 11:09 AM > To: John Paul Morrison; John Curran > Cc: ppml at arin.net > Subject: Re: [arin-ppml] The LRSA $100 fee... > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net > > [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Paul Morrison > > Sent: Friday, August 29, 2008 1:03 PM > > To: John Curran > > Cc: ppml at arin.net > > Subject: Re: [arin-ppml] The LRSA $100 fee... > > > > Existing domain registrars can process orders, invoicing, > > payment etc. for $10/year. > > To reduce overhead, a single $100 fee could be charged up > > front and cover a 10 year period. > > It doesn't take any more work for ARIN to enter "today's date > > + 10 years" instead of "today's date + 1 year" > > in a database. > > It is my humble opinion that domain name registrars suck. > The best of them provides lousy service and near-useless WHOIS. > Competition has ruined registry services by starting a race > to the bottom in price and service. > Actually, it's worse than that What happens now is that since registrars give so little help other than the FAQ's and such on their websites, that now when Joe Sixpack wants a domain name, he has to pay a consultant to actually register it for him In the old days Joe Sixpack could call up Network Solutions on their 800 number, pay his $40 and get a 1 year registration on the domain. In the process he would get someone on the phone who would take the time to tell him exactly what he was getting and how to use it. Today, Joe Sixpack has to pay an Internet consultant $50 to use a webinterface on someplace like towcows to register the name, and then Joe Sixpack has to pay towcows $20 for the domain name. And the Internet Consultant is half the time going to barely know a bit more than Joe Sixpack does. So the net result is for the end-user, prices have actually RISEN and service has DROPPED. The ONLY beneficiaries of the domain name competition that I can see are spammers who go though domain names like candy, and the sex industry who now finds it immensely cheap to setup innumerable variations of seeherpantiescomeoff.com. Ted From tedm at ipinc.net Fri Aug 29 16:48:17 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 29 Aug 2008 13:48:17 -0700 Subject: [arin-ppml] IANA IPv4 /8 burn rate.... In-Reply-To: <48B76FF1.7080606@sprunk.org> Message-ID: <24E5B4C3EDC14831A8AD22BD13D1FD1E@tedsdesk> > -----Original Message----- > From: Stephen Sprunk [mailto:stephen at sprunk.org] > Sent: Thursday, August 28, 2008 8:42 PM > To: Ted Mittelstaedt > Cc: 'Scott Leibrand'; 'Alain Durand'; 'ARIN PPML' > Subject: Re: [arin-ppml] IANA IPv4 /8 burn rate.... > > > Ted Mittelstaedt wrote: > > Everyone who assumes that moving to IPv6 would be better > has I think > > already provided a boatload of arguments as to why their > way would be > > better. > > > > But I have not really heard any arguments from the people > who want > > to stay with IPv4 as to why their way would be better. > > > > I think that answer is simple: the short-term cost of adding > more NAT is > lower than the short-term cost of moving everything to IPv6. > There's a > lot of stuff that _still_ doesn't work (well or at all) with IPv6, > despite over a decade of work and sweeping claims by IPv6 > supporters, so > the cost of the latter option isn't even calculable because it's not > possible -- but even the parts that are possible will > undoubtedly cost > more, in the short term, than just tossing a few more NAT > boxes into the > network. > > I think everyone is in agreement that the long-term costs of IPv6 are > cheaper than IPv4+NAT; what we're really debating is if and when that > transition will happen and what to do in the meantime. > If the long term costs of IPv6 are cheaper that is a huge argument against tossing a few more NAT boxes into the network. In short you have just successfully argued one of the many points AGAINST a liberalized transfer policy, and FOR moving to IPv6 asap, that is, why IPv6 is better. I had asked for arguments from the people who want to stay with IPv4 as to why their way would be better, and the best you can come up with so far is to take an argument saying the IPv4 way would be worse, and turn it upside down and paint it a different color and hope I wouldn't notice this? Surely you do better than that! The transition would happen tomorrow if people just went and did the work. Unfortunately the IPv6 transition is something that everyone doing it is dependent on everyone else doing their bit. The end users can't switch unless they get native IPv6 from their ISPs, and they can't use a proxy because an IPv4->IPv6 proxy standard is still under debate. The ISP's can't switch until their feeds switch, and those can't switch until their peers switch, and their peers are probably the worst of all. You get 3 backbones like Sprint, ATT & MCI in the room and MCI will say they can't go to IPv6 until Sprint does, and Sprint will say they can't go to IPv6 until ATT does, and ATT says they can't go to IPv6 until MCI does. If you're a father of children surely you will have recognized this as classic textbook BSing by now. Claims that IPv6 is not ready yet are EXACTLY LIKE claims that Microsoft Windows Vista isn't ready yet. They are simply bogus nonsense excuses that people make because IPv4 is a comfortable pair of old broken-in shoes, and IPv6 is the brand new pair of shiny, creaky, squeaky shoes. Yes the new shoes will take some breaking in and you will get some sores for a bit until you adjust. But how long are you going to keep putting tape or whatever on the old shoes? Until they fall apart and the Internet stops working? Ted From sleibrand at internap.com Fri Aug 29 16:59:23 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 29 Aug 2008 13:59:23 -0700 Subject: [arin-ppml] IANA IPv4 /8 burn rate.... In-Reply-To: <24E5B4C3EDC14831A8AD22BD13D1FD1E@tedsdesk> References: <24E5B4C3EDC14831A8AD22BD13D1FD1E@tedsdesk> Message-ID: <48B8632B.5030100@internap.com> Electric cars are better than gasoline ones. Electric cars are available today, and fully compatible with the existing road system. Therefore, we should stop selling gasoline cars and go all electric. Oh, electric cars are too expensive, you say? And there's no charging stations where you live? Well that's OK, because you'll be better off in the long run. -Scott Ted Mittelstaedt wrote: > >> -----Original Message----- >> From: Stephen Sprunk [mailto:stephen at sprunk.org] >> Sent: Thursday, August 28, 2008 8:42 PM >> To: Ted Mittelstaedt >> Cc: 'Scott Leibrand'; 'Alain Durand'; 'ARIN PPML' >> Subject: Re: [arin-ppml] IANA IPv4 /8 burn rate.... >> >> >> Ted Mittelstaedt wrote: >>> Everyone who assumes that moving to IPv6 would be better >> has I think >>> already provided a boatload of arguments as to why their >> way would be >>> better. >>> >>> But I have not really heard any arguments from the people >> who want >>> to stay with IPv4 as to why their way would be better. >>> >> I think that answer is simple: the short-term cost of adding >> more NAT is >> lower than the short-term cost of moving everything to IPv6. >> There's a >> lot of stuff that _still_ doesn't work (well or at all) with IPv6, >> despite over a decade of work and sweeping claims by IPv6 >> supporters, so >> the cost of the latter option isn't even calculable because it's not >> possible -- but even the parts that are possible will >> undoubtedly cost >> more, in the short term, than just tossing a few more NAT >> boxes into the >> network. >> >> I think everyone is in agreement that the long-term costs of IPv6 are >> cheaper than IPv4+NAT; what we're really debating is if and when that >> transition will happen and what to do in the meantime. >> > > If the long term costs of IPv6 are cheaper that is a huge argument > against tossing a few more NAT boxes into the network. In short > you have just successfully argued one of the many points AGAINST > a liberalized transfer policy, and FOR moving to IPv6 asap, that > is, why IPv6 is better. > > I had asked for arguments from the people who want to stay with IPv4 > as to why their way would be better, and the best you can come > up with so far is to take an argument saying the IPv4 way would > be worse, and turn it upside down and paint it a different color > and hope I wouldn't notice this? > > Surely you do better than that! > > The transition would happen tomorrow if people just went and did the work. > Unfortunately the IPv6 transition is something that everyone doing it > is dependent on everyone else doing their bit. The end users can't > switch unless they get native IPv6 from their ISPs, and they can't > use a proxy because an IPv4->IPv6 proxy standard is still under debate. > The ISP's can't switch until their feeds switch, and those can't switch > until their peers switch, and their peers are probably the worst of all. > > You get 3 backbones like Sprint, ATT & MCI in the room and MCI will > say they can't go to IPv6 until Sprint does, and Sprint will say > they can't go to IPv6 until ATT does, and ATT says they can't go to > IPv6 until MCI does. > > If you're a father of children surely you will have recognized this > as classic textbook BSing by now. > > Claims that IPv6 is not ready yet are EXACTLY LIKE claims that > Microsoft Windows Vista isn't ready yet. They are simply bogus > nonsense excuses that people make because IPv4 is a comfortable > pair of old broken-in shoes, and IPv6 is the brand new pair of > shiny, creaky, squeaky shoes. Yes the new shoes will take some > breaking in and you will get some sores for a bit until you > adjust. But how long are you going to keep putting tape or whatever > on the old shoes? Until they fall apart and the Internet stops working? > > Ted > From ptimmins at clearrate.com Fri Aug 29 17:05:35 2008 From: ptimmins at clearrate.com (Paul G. Timmins) Date: Fri, 29 Aug 2008 17:05:35 -0400 Subject: [arin-ppml] IANA IPv4 /8 burn rate.... In-Reply-To: <48B8632B.5030100@internap.com> Message-ID: Biodiesel is available, and works in almost any vehicle that takes normal diesel. It doesn't use fossil fuels, and in some cases, burns cleaner. But it doesn't work in cars that take Unleaded Gas. So we shouldn't use Biodiesel until all cars can use it. That way we don't have to worry about compatibility issues. -Paul > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand > Sent: Friday, August 29, 2008 4:59 PM > To: Ted Mittelstaedt > Cc: 'ARIN PPML' > Subject: Re: [arin-ppml] IANA IPv4 /8 burn rate.... > > Electric cars are better than gasoline ones. Electric cars > are available > today, and fully compatible with the existing road system. > Therefore, we > should stop selling gasoline cars and go all electric. > > Oh, electric cars are too expensive, you say? And there's no > charging > stations where you live? Well that's OK, because you'll be > better off in > the long run. > > -Scott > > Ted Mittelstaedt wrote: > > > >> -----Original Message----- > >> From: Stephen Sprunk [mailto:stephen at sprunk.org] > >> Sent: Thursday, August 28, 2008 8:42 PM > >> To: Ted Mittelstaedt > >> Cc: 'Scott Leibrand'; 'Alain Durand'; 'ARIN PPML' > >> Subject: Re: [arin-ppml] IANA IPv4 /8 burn rate.... > >> > >> > >> Ted Mittelstaedt wrote: > >>> Everyone who assumes that moving to IPv6 would be better > >> has I think > >>> already provided a boatload of arguments as to why their > >> way would be > >>> better. > >>> > >>> But I have not really heard any arguments from the people > >> who want > >>> to stay with IPv4 as to why their way would be better. > >>> > >> I think that answer is simple: the short-term cost of adding > >> more NAT is > >> lower than the short-term cost of moving everything to IPv6. > >> There's a > >> lot of stuff that _still_ doesn't work (well or at all) with IPv6, > >> despite over a decade of work and sweeping claims by IPv6 > >> supporters, so > >> the cost of the latter option isn't even calculable > because it's not > >> possible -- but even the parts that are possible will > >> undoubtedly cost > >> more, in the short term, than just tossing a few more NAT > >> boxes into the > >> network. > >> > >> I think everyone is in agreement that the long-term costs > of IPv6 are > >> cheaper than IPv4+NAT; what we're really debating is if > and when that > >> transition will happen and what to do in the meantime. > >> > > > > If the long term costs of IPv6 are cheaper that is a huge argument > > against tossing a few more NAT boxes into the network. In short > > you have just successfully argued one of the many points AGAINST > > a liberalized transfer policy, and FOR moving to IPv6 asap, that > > is, why IPv6 is better. > > > > I had asked for arguments from the people who want to stay with IPv4 > > as to why their way would be better, and the best you can come > > up with so far is to take an argument saying the IPv4 way would > > be worse, and turn it upside down and paint it a different color > > and hope I wouldn't notice this? > > > > Surely you do better than that! > > > > The transition would happen tomorrow if people just went > and did the work. > > Unfortunately the IPv6 transition is something that > everyone doing it > > is dependent on everyone else doing their bit. The end users can't > > switch unless they get native IPv6 from their ISPs, and they can't > > use a proxy because an IPv4->IPv6 proxy standard is still > under debate. > > The ISP's can't switch until their feeds switch, and those > can't switch > > until their peers switch, and their peers are probably the > worst of all. > > > > You get 3 backbones like Sprint, ATT & MCI in the room and MCI will > > say they can't go to IPv6 until Sprint does, and Sprint will say > > they can't go to IPv6 until ATT does, and ATT says they can't go to > > IPv6 until MCI does. > > > > If you're a father of children surely you will have recognized this > > as classic textbook BSing by now. > > > > Claims that IPv6 is not ready yet are EXACTLY LIKE claims that > > Microsoft Windows Vista isn't ready yet. They are simply bogus > > nonsense excuses that people make because IPv4 is a comfortable > > pair of old broken-in shoes, and IPv6 is the brand new pair of > > shiny, creaky, squeaky shoes. Yes the new shoes will take some > > breaking in and you will get some sores for a bit until you > > adjust. But how long are you going to keep putting tape or whatever > > on the old shoes? Until they fall apart and the Internet > stops working? > > > > Ted > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From ptimmins at clearrate.com Fri Aug 29 16:42:42 2008 From: ptimmins at clearrate.com (Paul G. Timmins) Date: Fri, 29 Aug 2008 16:42:42 -0400 Subject: [arin-ppml] OT: The LRSA $100 fee... In-Reply-To: <6B79B308F41D4C46A6F534727F703034@tedsdesk> Message-ID: (heavily snipped message from Ted) > > It is my humble opinion that domain name registrars suck. > > The best of them provides lousy service and near-useless WHOIS. > > Competition has ruined registry services by starting a race > > to the bottom in price and service. > > > > Actually, it's worse than that > > What happens now is that since registrars give so little help > other than the FAQ's and such on their websites, that now > when Joe Sixpack wants a domain name, he has to pay a > consultant to actually register it for him > In the old days Joe Sixpack could call up Network Solutions on > their 800 number, pay his $40 and get a 1 year registration on > the domain. In the process he would get someone on the phone who > would take the time to tell him exactly what he was getting and > how to use it. Really? In the old days, Joe Sixpack knew what a DNS server was, and how to set up his server himself? In the old days, Joe Sixpack didn't care about domain names, and in the current time, Joe Sixpack probably still doesn't care. But if he did, he would probably have been one of those people who paid NetSol their **$75** (or like the first one I got, $100) for the 1 year registration ($40 was well after the introduction of competitive registrars, if I remember right), and then not realized what they were talking about when they asked for "nameservers". They didn't park domains back then so you really needed those in advance. > Today, Joe Sixpack has to pay an Internet consultant $50 to > use a webinterface on someplace like towcows to register the > name, and then Joe Sixpack has to pay towcows $20 for the domain > name. And the Internet Consultant is half the time going to > barely know a bit more than Joe Sixpack does. Or he can go to Godaddy and not uncheck all those boxes I typically used to that said things like "free webhosting" etc, and pay less than $50 total. (To say nothing of their loathsome web interface) > So the net result is for the end-user, prices have actually > RISEN and service has DROPPED. Many hosting providers will do it for a minimal cost on top of hosting. What situations are you finding where an internet consultant actually does this? > The ONLY beneficiaries of the domain name competition that I > can see are spammers who go though domain names like candy, and > the sex industry who now finds it immensely cheap to setup > innumerable variations of seeherpantiescomeoff.com. While the benefit to these companies is immense, I highly disagree with your assertion that they were the ONLY beneficiaries. I'm neither, and own a lot more domain names now, than I could afford to own before. Same with most of my friends. -Paul (slightly on topic: while I disagree with your rant regarding DNS competition, I don't support competition in the in-addr zone.) From bmanning at vacation.karoshi.com Fri Aug 29 17:14:05 2008 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 29 Aug 2008 21:14:05 +0000 Subject: [arin-ppml] About NAT-PT.... (Re: Fantasyland) In-Reply-To: References: <95626FE1-05F4-47A4-A016-EEE33FEB8ACC@muada.com> Message-ID: <20080829211405.GA19647@vacation.karoshi.com.> On Fri, Aug 29, 2008 at 01:48:48PM -0400, Alain Durand wrote: > On 8/29/08 5:13 AM, "Iljitsch van Beijnum" wrote: > > > So you still want IPv6 for that webcam and most of your peer-to-peer > > stuff. > > Oh, yes... 100% agreed. The point is that DS-lite offers a way to get there. > > Alain. as does IVI... and there is at least one more candidate in this field. --bill From alain_durand at cable.comcast.com Fri Aug 29 17:17:20 2008 From: alain_durand at cable.comcast.com (Alain Durand) Date: Fri, 29 Aug 2008 17:17:20 -0400 Subject: [arin-ppml] About NAT-PT.... (Re: Fantasyland) In-Reply-To: <20080829211405.GA19647@vacation.karoshi.com.> Message-ID: On 8/29/08 5:14 PM, "bmanning at vacation.karoshi.com" wrote: > On Fri, Aug 29, 2008 at 01:48:48PM -0400, Alain Durand wrote: >> On 8/29/08 5:13 AM, "Iljitsch van Beijnum" wrote: >> >>> So you still want IPv6 for that webcam and most of your peer-to-peer >>> stuff. >> >> Oh, yes... 100% agreed. The point is that DS-lite offers a way to get there. >> >> Alain. > > as does IVI... and there is at least one more candidate in this field. Unfortunately, IVI does not help you if you have legacy IPv4 nodes and don't have any IPv4 addresses for them. - Alain. From sleibrand at internap.com Fri Aug 29 17:17:49 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 29 Aug 2008 14:17:49 -0700 Subject: [arin-ppml] IANA IPv4 /8 burn rate.... In-Reply-To: References: Message-ID: <48B8677D.3010909@internap.com> Yeah, that's why the idea of "everyone must convert to IPv6 at the same time" makes no sense to me. IPv4 and IPv6 will have to interoperate for some time, so we need to have policies that continue to make IPv4 available to support such transition mechanisms. -Scott Paul G. Timmins wrote: > Biodiesel is available, and works in almost any vehicle that takes > normal diesel. > It doesn't use fossil fuels, and in some cases, burns cleaner. > > But it doesn't work in cars that take Unleaded Gas. > > So we shouldn't use Biodiesel until all cars can use it. That way we > don't have to worry about compatibility issues. > > -Paul > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net >> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand >> Sent: Friday, August 29, 2008 4:59 PM >> To: Ted Mittelstaedt >> Cc: 'ARIN PPML' >> Subject: Re: [arin-ppml] IANA IPv4 /8 burn rate.... >> >> Electric cars are better than gasoline ones. Electric cars >> are available >> today, and fully compatible with the existing road system. >> Therefore, we >> should stop selling gasoline cars and go all electric. >> >> Oh, electric cars are too expensive, you say? And there's no >> charging >> stations where you live? Well that's OK, because you'll be >> better off in >> the long run. >> >> -Scott >> >> Ted Mittelstaedt wrote: >>>> -----Original Message----- >>>> From: Stephen Sprunk [mailto:stephen at sprunk.org] >>>> Sent: Thursday, August 28, 2008 8:42 PM >>>> To: Ted Mittelstaedt >>>> Cc: 'Scott Leibrand'; 'Alain Durand'; 'ARIN PPML' >>>> Subject: Re: [arin-ppml] IANA IPv4 /8 burn rate.... >>>> >>>> >>>> Ted Mittelstaedt wrote: >>>>> Everyone who assumes that moving to IPv6 would be better >>>> has I think >>>>> already provided a boatload of arguments as to why their >>>> way would be >>>>> better. >>>>> >>>>> But I have not really heard any arguments from the people >>>> who want >>>>> to stay with IPv4 as to why their way would be better. >>>>> >>>> I think that answer is simple: the short-term cost of adding >>>> more NAT is >>>> lower than the short-term cost of moving everything to IPv6. >>>> There's a >>>> lot of stuff that _still_ doesn't work (well or at all) with IPv6, >>>> despite over a decade of work and sweeping claims by IPv6 >>>> supporters, so >>>> the cost of the latter option isn't even calculable >> because it's not >>>> possible -- but even the parts that are possible will >>>> undoubtedly cost >>>> more, in the short term, than just tossing a few more NAT >>>> boxes into the >>>> network. >>>> >>>> I think everyone is in agreement that the long-term costs >> of IPv6 are >>>> cheaper than IPv4+NAT; what we're really debating is if >> and when that >>>> transition will happen and what to do in the meantime. >>>> >>> If the long term costs of IPv6 are cheaper that is a huge argument >>> against tossing a few more NAT boxes into the network. In short >>> you have just successfully argued one of the many points AGAINST >>> a liberalized transfer policy, and FOR moving to IPv6 asap, that >>> is, why IPv6 is better. >>> >>> I had asked for arguments from the people who want to stay with IPv4 >>> as to why their way would be better, and the best you can come >>> up with so far is to take an argument saying the IPv4 way would >>> be worse, and turn it upside down and paint it a different color >>> and hope I wouldn't notice this? >>> >>> Surely you do better than that! >>> >>> The transition would happen tomorrow if people just went >> and did the work. >>> Unfortunately the IPv6 transition is something that >> everyone doing it >>> is dependent on everyone else doing their bit. The end users can't >>> switch unless they get native IPv6 from their ISPs, and they can't >>> use a proxy because an IPv4->IPv6 proxy standard is still >> under debate. >>> The ISP's can't switch until their feeds switch, and those >> can't switch >>> until their peers switch, and their peers are probably the >> worst of all. >>> You get 3 backbones like Sprint, ATT & MCI in the room and MCI will >>> say they can't go to IPv6 until Sprint does, and Sprint will say >>> they can't go to IPv6 until ATT does, and ATT says they can't go to >>> IPv6 until MCI does. >>> >>> If you're a father of children surely you will have recognized this >>> as classic textbook BSing by now. >>> >>> Claims that IPv6 is not ready yet are EXACTLY LIKE claims that >>> Microsoft Windows Vista isn't ready yet. They are simply bogus >>> nonsense excuses that people make because IPv4 is a comfortable >>> pair of old broken-in shoes, and IPv6 is the brand new pair of >>> shiny, creaky, squeaky shoes. Yes the new shoes will take some >>> breaking in and you will get some sores for a bit until you >>> adjust. But how long are you going to keep putting tape or whatever >>> on the old shoes? Until they fall apart and the Internet >> stops working? >>> Ted >>> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> From stephen at sprunk.org Fri Aug 29 17:22:51 2008 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 29 Aug 2008 16:22:51 -0500 Subject: [arin-ppml] IANA IPv4 /8 burn rate.... In-Reply-To: <24E5B4C3EDC14831A8AD22BD13D1FD1E@tedsdesk> References: <24E5B4C3EDC14831A8AD22BD13D1FD1E@tedsdesk> Message-ID: <48B868AB.4000400@sprunk.org> Ted Mittelstaedt wrote: >> -----Original Message----- >> From: Stephen Sprunk [mailto:stephen at sprunk.org] >> Sent: Thursday, August 28, 2008 8:42 PM >> To: Ted Mittelstaedt >> Cc: 'Scott Leibrand'; 'Alain Durand'; 'ARIN PPML' >> Subject: Re: [arin-ppml] IANA IPv4 /8 burn rate.... >> >> >> Ted Mittelstaedt wrote: >> >>> Everyone who assumes that moving to IPv6 would be better has I think already provided a boatload of arguments as to why their way would be better. But I have not really heard any arguments from the people who want to stay with IPv4 as to why their way would be better. >>> >> I think that answer is simple: the short-term cost of adding more NAT is >> lower than the short-term cost of moving everything to IPv6. There's a >> lot of stuff that _still_ doesn't work (well or at all) with IPv6, despite over a decade of work and sweeping claims by IPv6 supporters, so the cost of the latter option isn't even calculable because it's not possible -- but even the parts that are possible will undoubtedly cost >> more, in the short term, than just tossing a few more NAT boxes into the >> network. >> >> I think everyone is in agreement that the long-term costs of IPv6 are cheaper than IPv4+NAT; what we're really debating is if and when that transition will happen and what to do in the meantime. >> > > If the long term costs of IPv6 are cheaper that is a huge argument > against tossing a few more NAT boxes into the network. In short > you have just successfully argued one of the many points AGAINST > a liberalized transfer policy, and FOR moving to IPv6 asap, that > is, why IPv6 is better. > No, I have pointed out the frame of debate; I am not saying either side is correct, because the economic and technical factors will vary for each organization as well as over time. That is why I'm leaning _towards_ the transfer policy, because it gives each org the flexibility of deciding for itself when to make the transition and how, depending on how it assesses the factors in its particular situation. > I had asked for arguments from the people who want to stay with IPv4 as to why their way would be better, and the best you can come up with so far is to take an argument saying the IPv4 way would be worse, and turn it upside down and paint it a different color and hope I wouldn't notice this? > Your question presupposes that there exist people who think it is best to stay on IPv4+NAT forever. I have seen no evidence that such exist, therefore I assumed your question was about people who are trying to stretch out or delay the transition. > Surely you do better than that! > > The transition would happen tomorrow if people just went and did the work. > What people? Which work? > Unfortunately the IPv6 transition is something that everyone doing it is dependent on everyone else doing their bit. The end users can't switch unless they get native IPv6 from their ISPs, and they can't use a proxy because an IPv4->IPv6 proxy standard is still under debate. The ISP's can't switch until their feeds switch, and those can't switch until their peers switch, and their peers are probably the worst of all. > > You get 3 backbones like Sprint, ATT & MCI in the room and MCI will say they can't go to IPv6 until Sprint does, and Sprint will say they can't go to IPv6 until ATT does, and ATT says they can't go to IPv6 until MCI does. > > If you're a father of children surely you will have recognized this as classic textbook BSing by now. > That's not what I see. The vendors aren't making the products necessary because customers aren't asking for them and there is financial incentive to _not_ do work that people won't pay extra for. The customers aren't asking yet because they don't want to pay extra for features they don't yet need. There is no need yet because the Internet hasn't collapsed yet. Believe me, I've tried to get my employer to implement IPv6, and the reality is that, so far, we have lost zero sales because we didn't have it, while other features competing for the same developers _would_ have lost us sales if we didn't deliver them. Until a non-trivial number of our customers start refusing to buy products without IPv6 support, it's financially irresponsible for us to do the work. The engineer in me doesn't like that answer, but the stockholder in me takes the results to the bank... Calling reality "BS" does not change the fact it's still reality. > Claims that IPv6 is not ready yet are EXACTLY LIKE claims that Microsoft Windows Vista isn't ready yet. They are simply bogus nonsense excuses that people make because IPv4 is a comfortable pair of old broken-in shoes, and IPv6 is the brand new pair of shiny, creaky, squeaky shoes. Yes the new shoes will take some breaking in and you will get some sores for a bit until you adjust. But how long are you going to keep putting tape or whatever on the old shoes? Until they fall apart and the Internet stops working? > The economics strongly favor that scenario, and that scenario has been played out several times in the past: nobody is willing to step up and spend the money to fix things, which gives their non-acting competitors an financial advantage, so any major change to the Internet must result from actual failure because that forces _all_ players to act at the same time. The financial markets also encourages executives to cut costs today despite disastrous long-term consequences, because the executives will rake in tens of millions of dollars in the meantime and then pull the ripcord on their golden parachute when their choices catch up to them, leaving the mess to the next round of execs -- or a bankruptcy court -- to sort things out and start the cycle over again. S From tvest at pch.net Fri Aug 29 17:32:21 2008 From: tvest at pch.net (Tom Vest) Date: Fri, 29 Aug 2008 17:32:21 -0400 Subject: [arin-ppml] IANA IPv4 /8 burn rate.... In-Reply-To: <48B8677D.3010909@internap.com> References: <48B8677D.3010909@internap.com> Message-ID: So the question then becomes: which transition order(s)/sequence(s) are possible vs. impossible given the compatibility gap and assuming the same basic mix of industry players -- and which ones are more vs. less likely given the various customer/provider relationships, incentives, and opportunities? TV On Aug 29, 2008, at 5:17 PM, Scott Leibrand wrote: > Yeah, that's why the idea of "everyone must convert to IPv6 at the > same > time" makes no sense to me. IPv4 and IPv6 will have to interoperate > for > some time, so we need to have policies that continue to make IPv4 > available to support such transition mechanisms. > > -Scott > > Paul G. Timmins wrote: >> Biodiesel is available, and works in almost any vehicle that takes >> normal diesel. >> It doesn't use fossil fuels, and in some cases, burns cleaner. >> >> But it doesn't work in cars that take Unleaded Gas. >> >> So we shouldn't use Biodiesel until all cars can use it. That way we >> don't have to worry about compatibility issues. >> >> -Paul >> >>> -----Original Message----- >>> From: arin-ppml-bounces at arin.net >>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand >>> Sent: Friday, August 29, 2008 4:59 PM >>> To: Ted Mittelstaedt >>> Cc: 'ARIN PPML' >>> Subject: Re: [arin-ppml] IANA IPv4 /8 burn rate.... >>> >>> Electric cars are better than gasoline ones. Electric cars >>> are available >>> today, and fully compatible with the existing road system. >>> Therefore, we >>> should stop selling gasoline cars and go all electric. >>> >>> Oh, electric cars are too expensive, you say? And there's no >>> charging >>> stations where you live? Well that's OK, because you'll be >>> better off in >>> the long run. >>> >>> -Scott >>> >>> Ted Mittelstaedt wrote: >>>>> -----Original Message----- >>>>> From: Stephen Sprunk [mailto:stephen at sprunk.org] >>>>> Sent: Thursday, August 28, 2008 8:42 PM >>>>> To: Ted Mittelstaedt >>>>> Cc: 'Scott Leibrand'; 'Alain Durand'; 'ARIN PPML' >>>>> Subject: Re: [arin-ppml] IANA IPv4 /8 burn rate.... >>>>> >>>>> >>>>> Ted Mittelstaedt wrote: >>>>>> Everyone who assumes that moving to IPv6 would be better >>>>> has I think >>>>>> already provided a boatload of arguments as to why their >>>>> way would be >>>>>> better. >>>>>> >>>>>> But I have not really heard any arguments from the people >>>>> who want >>>>>> to stay with IPv4 as to why their way would be better. >>>>>> >>>>> I think that answer is simple: the short-term cost of adding >>>>> more NAT is >>>>> lower than the short-term cost of moving everything to IPv6. >>>>> There's a >>>>> lot of stuff that _still_ doesn't work (well or at all) with IPv6, >>>>> despite over a decade of work and sweeping claims by IPv6 >>>>> supporters, so >>>>> the cost of the latter option isn't even calculable >>> because it's not >>>>> possible -- but even the parts that are possible will >>>>> undoubtedly cost >>>>> more, in the short term, than just tossing a few more NAT >>>>> boxes into the >>>>> network. >>>>> >>>>> I think everyone is in agreement that the long-term costs >>> of IPv6 are >>>>> cheaper than IPv4+NAT; what we're really debating is if >>> and when that >>>>> transition will happen and what to do in the meantime. >>>>> >>>> If the long term costs of IPv6 are cheaper that is a huge argument >>>> against tossing a few more NAT boxes into the network. In short >>>> you have just successfully argued one of the many points AGAINST >>>> a liberalized transfer policy, and FOR moving to IPv6 asap, that >>>> is, why IPv6 is better. >>>> >>>> I had asked for arguments from the people who want to stay with >>>> IPv4 >>>> as to why their way would be better, and the best you can come >>>> up with so far is to take an argument saying the IPv4 way would >>>> be worse, and turn it upside down and paint it a different color >>>> and hope I wouldn't notice this? >>>> >>>> Surely you do better than that! >>>> >>>> The transition would happen tomorrow if people just went >>> and did the work. >>>> Unfortunately the IPv6 transition is something that >>> everyone doing it >>>> is dependent on everyone else doing their bit. The end users can't >>>> switch unless they get native IPv6 from their ISPs, and they can't >>>> use a proxy because an IPv4->IPv6 proxy standard is still >>> under debate. >>>> The ISP's can't switch until their feeds switch, and those >>> can't switch >>>> until their peers switch, and their peers are probably the >>> worst of all. >>>> You get 3 backbones like Sprint, ATT & MCI in the room and MCI will >>>> say they can't go to IPv6 until Sprint does, and Sprint will say >>>> they can't go to IPv6 until ATT does, and ATT says they can't go to >>>> IPv6 until MCI does. >>>> >>>> If you're a father of children surely you will have recognized this >>>> as classic textbook BSing by now. >>>> >>>> Claims that IPv6 is not ready yet are EXACTLY LIKE claims that >>>> Microsoft Windows Vista isn't ready yet. They are simply bogus >>>> nonsense excuses that people make because IPv4 is a comfortable >>>> pair of old broken-in shoes, and IPv6 is the brand new pair of >>>> shiny, creaky, squeaky shoes. Yes the new shoes will take some >>>> breaking in and you will get some sores for a bit until you >>>> adjust. But how long are you going to keep putting tape or >>>> whatever >>>> on the old shoes? Until they fall apart and the Internet >>> stops working? >>>> Ted >>>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >>> > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Fri Aug 29 18:17:39 2008 From: owen at delong.com (Owen DeLong) Date: Fri, 29 Aug 2008 15:17:39 -0700 Subject: [arin-ppml] IANA IPv4 /8 burn rate.... In-Reply-To: <48B8677D.3010909@internap.com> References: <48B8677D.3010909@internap.com> Message-ID: I believe the proposal that reserves the last N (for some value of N) addresses for transitional technologies comes much closer to achieving that stated purpose than any transfer policy will. Owen On Aug 29, 2008, at 2:17 PM, Scott Leibrand wrote: > Yeah, that's why the idea of "everyone must convert to IPv6 at the > same > time" makes no sense to me. IPv4 and IPv6 will have to interoperate > for > some time, so we need to have policies that continue to make IPv4 > available to support such transition mechanisms. > > -Scott > > Paul G. Timmins wrote: >> Biodiesel is available, and works in almost any vehicle that takes >> normal diesel. >> It doesn't use fossil fuels, and in some cases, burns cleaner. >> >> But it doesn't work in cars that take Unleaded Gas. >> >> So we shouldn't use Biodiesel until all cars can use it. That way we >> don't have to worry about compatibility issues. >> >> -Paul >> >>> -----Original Message----- >>> From: arin-ppml-bounces at arin.net >>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand >>> Sent: Friday, August 29, 2008 4:59 PM >>> To: Ted Mittelstaedt >>> Cc: 'ARIN PPML' >>> Subject: Re: [arin-ppml] IANA IPv4 /8 burn rate.... >>> >>> Electric cars are better than gasoline ones. Electric cars >>> are available >>> today, and fully compatible with the existing road system. >>> Therefore, we >>> should stop selling gasoline cars and go all electric. >>> >>> Oh, electric cars are too expensive, you say? And there's no >>> charging >>> stations where you live? Well that's OK, because you'll be >>> better off in >>> the long run. >>> >>> -Scott >>> >>> Ted Mittelstaedt wrote: >>>>> -----Original Message----- >>>>> From: Stephen Sprunk [mailto:stephen at sprunk.org] >>>>> Sent: Thursday, August 28, 2008 8:42 PM >>>>> To: Ted Mittelstaedt >>>>> Cc: 'Scott Leibrand'; 'Alain Durand'; 'ARIN PPML' >>>>> Subject: Re: [arin-ppml] IANA IPv4 /8 burn rate.... >>>>> >>>>> >>>>> Ted Mittelstaedt wrote: >>>>>> Everyone who assumes that moving to IPv6 would be better >>>>> has I think >>>>>> already provided a boatload of arguments as to why their >>>>> way would be >>>>>> better. >>>>>> >>>>>> But I have not really heard any arguments from the people >>>>> who want >>>>>> to stay with IPv4 as to why their way would be better. >>>>>> >>>>> I think that answer is simple: the short-term cost of adding >>>>> more NAT is >>>>> lower than the short-term cost of moving everything to IPv6. >>>>> There's a >>>>> lot of stuff that _still_ doesn't work (well or at all) with IPv6, >>>>> despite over a decade of work and sweeping claims by IPv6 >>>>> supporters, so >>>>> the cost of the latter option isn't even calculable >>> because it's not >>>>> possible -- but even the parts that are possible will >>>>> undoubtedly cost >>>>> more, in the short term, than just tossing a few more NAT >>>>> boxes into the >>>>> network. >>>>> >>>>> I think everyone is in agreement that the long-term costs >>> of IPv6 are >>>>> cheaper than IPv4+NAT; what we're really debating is if >>> and when that >>>>> transition will happen and what to do in the meantime. >>>>> >>>> If the long term costs of IPv6 are cheaper that is a huge argument >>>> against tossing a few more NAT boxes into the network. In short >>>> you have just successfully argued one of the many points AGAINST >>>> a liberalized transfer policy, and FOR moving to IPv6 asap, that >>>> is, why IPv6 is better. >>>> >>>> I had asked for arguments from the people who want to stay with >>>> IPv4 >>>> as to why their way would be better, and the best you can come >>>> up with so far is to take an argument saying the IPv4 way would >>>> be worse, and turn it upside down and paint it a different color >>>> and hope I wouldn't notice this? >>>> >>>> Surely you do better than that! >>>> >>>> The transition would happen tomorrow if people just went >>> and did the work. >>>> Unfortunately the IPv6 transition is something that >>> everyone doing it >>>> is dependent on everyone else doing their bit. The end users can't >>>> switch unless they get native IPv6 from their ISPs, and they can't >>>> use a proxy because an IPv4->IPv6 proxy standard is still >>> under debate. >>>> The ISP's can't switch until their feeds switch, and those >>> can't switch >>>> until their peers switch, and their peers are probably the >>> worst of all. >>>> You get 3 backbones like Sprint, ATT & MCI in the room and MCI will >>>> say they can't go to IPv6 until Sprint does, and Sprint will say >>>> they can't go to IPv6 until ATT does, and ATT says they can't go to >>>> IPv6 until MCI does. >>>> >>>> If you're a father of children surely you will have recognized this >>>> as classic textbook BSing by now. >>>> >>>> Claims that IPv6 is not ready yet are EXACTLY LIKE claims that >>>> Microsoft Windows Vista isn't ready yet. They are simply bogus >>>> nonsense excuses that people make because IPv4 is a comfortable >>>> pair of old broken-in shoes, and IPv6 is the brand new pair of >>>> shiny, creaky, squeaky shoes. Yes the new shoes will take some >>>> breaking in and you will get some sores for a bit until you >>>> adjust. But how long are you going to keep putting tape or >>>> whatever >>>> on the old shoes? Until they fall apart and the Internet >>> stops working? >>>> Ted >>>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >>> > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From farmer at umn.edu Fri Aug 29 18:22:23 2008 From: farmer at umn.edu (David Farmer) Date: Fri, 29 Aug 2008 17:22:23 -0500 Subject: [arin-ppml] IPv4 is depleted today In-Reply-To: References: <48B7DE9F.7707.3AEC08B@farmer.umn.edu>, Message-ID: <48B8304F.8816.4EDD8D6@farmer.umn.edu> On 29 Aug 2008 Ted Mittelstaedt wrote: > There are a couple of phrases in this post I found most > humorous: > > "...return our current IPv4 address space it is to valuable > internally...." > > "...will be necessary to extend the life of > IPv4 long enough for us to get IPv6 ramped up..." Glad to be comic relief for you, but; > What our esteemed colleague David is saying is in essence > he wants a transfer policy because he has a lot of IPv4 > and he (understandably) wants to continue to use it. > He labels IPv6 not ready, why not? He already has > plenty of IPv4, he doesn't need IPv6. He has no incentive > to deploy IPv6, really. Wrong, we have plenty of incentive to deploy IPv6, we been working on it, have you? We just have bigger incentives not to break IPv4, yet, and there are other projects, with higher priorities too. But, we are making deliberate, all be it slow progress, are you? Four years ago we had IPv6 as an equipment requirement for our new campus network RFP, we have been putting our money where our mouth is for IPv6 for a while. But, IPv6 ain't ready for grandma today, with a lot of work it will be by IPv4 exhaustion. > He also won't give his network's IPv4 up to "sell" through a > transfer policy, or course not. He is just expecting every > other legacy holder out there to sell off their IPv4. Wrong, if the University of Minnesota were to stop using it's IPv4 address space we will return it to ARIN, and not sell it. We have in the past, we returned a C to IANA when we got our original B, and we may return a couple other swamp C's in the future as a matter of principle, but that really won't make any difference to anything. Nor, would returning all of our address space, it might delay IANA exhaustion by a whole day or two. I'm just trying to recognize that it will be easier and more effective to give people an incentive to return address space, then to only ask them return it, or to try to force them to return it. > The situation reminds me when my city, Portland OR, put > in Light Rail. Everyone driving cars in the city strongly > supported light rail. They all wanted it because the > figured that "the OTHER guy" would stop driving his > car, and take light rail, and get the heck off the freeway > so that THEY could drive an uncongested freeway. > > Needless to say, the freeway congestion did NOT go away. > > I would ask our colleague that if he feels that it would > be too much trouble for him to split his legacy block > to be able to sell off part of it under a liberalized > transfer policy, doesn't he think that everyone else with > a legacy block is going to feel the same way? Why is > he special? And if every other legacy holder feels this > way, then where exactly are these IPv4 blocks going to > come from that will be sold through a liberalized transfer > policy, that will "extend the life of IPv4" as he puts it. > > In short, he meticulously explains why a liberalized transfer > policy would do absolutely nothing to help him return his > unused IPv4 space to the free pool, then proceeds to > claim that we need a liberalized transfer policy to enable > more IPv4 to be returned to the free pool!!! > > I can't think of a more damming example of why a liberalized > transfer policy would be about as useful as teats on a boar. You are right, we're not special, a liberalized transfer policy will probably not free up much space. That was one of my points, that I obviously didn't hammer hard enough. But, it might free up a little, and we're going to need every hair-brained Wile E. Coyote idea we can come up with to get to keep IPv4 going long enough to get everyone on to IPv6. Because unlike Wile E. Coyote, if the Internet falls off the cliff we not going to get up and walk away. I'll put it back on you, are you sure we can get IPv6 fully deployed before IPv4 crashes into the wall, I'm not. We (UMN) will be there but we've been working on it for a long time. I don't think everyone will be. If we have a transfer policy that might free up a little space, it is not going to save us in the long term, nor will NAT, only IPv6 can do that. But it could help build a bridge, and if IPv4 addresses went for $1000 an address it sure would make a bigger incentive to move to IPv6 and hopefully push IPv6 up the priority list for IT departments everywhere. So if only for that reason, it might help to have a transfer policy, to give that extra little push. I also think the longer we debate a transfer policy, the more the message that IPv6 is the only true hope get diluted. ======================================================= David Farmer Email: farmer at umn.edu Office of Information Technology Networking & Telecomunication Services University of Minnesota Phone: 612-626-0815 2218 University Ave SE Cell: 612-812-9952 Minneapolis, MN 55414-3029 FAX: 612-626-1818 ======================================================= From sleibrand at internap.com Fri Aug 29 18:24:13 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 29 Aug 2008 15:24:13 -0700 Subject: [arin-ppml] IANA IPv4 /8 burn rate.... In-Reply-To: References: <48B8677D.3010909@internap.com> Message-ID: <48B8770D.70702@internap.com> FWIW, I just pinged the authors of the APNIC proposal that just got consensus yesterday about proposing it in the ARIN region. Looks like they're interested if we are, so we should have something on the table for April. -Scott Owen DeLong wrote: > I believe the proposal that reserves the last N (for some value of N) > addresses for transitional technologies comes much closer to > achieving that stated purpose than any transfer policy will. > > Owen > > On Aug 29, 2008, at 2:17 PM, Scott Leibrand wrote: > >> Yeah, that's why the idea of "everyone must convert to IPv6 at the same >> time" makes no sense to me. IPv4 and IPv6 will have to interoperate for >> some time, so we need to have policies that continue to make IPv4 >> available to support such transition mechanisms. >> >> -Scott >> >> Paul G. Timmins wrote: >>> Biodiesel is available, and works in almost any vehicle that takes >>> normal diesel. >>> It doesn't use fossil fuels, and in some cases, burns cleaner. >>> >>> But it doesn't work in cars that take Unleaded Gas. >>> >>> So we shouldn't use Biodiesel until all cars can use it. That way we >>> don't have to worry about compatibility issues. >>> >>> -Paul >>> >>>> -----Original Message----- >>>> From: arin-ppml-bounces at arin.net >>>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand >>>> Sent: Friday, August 29, 2008 4:59 PM >>>> To: Ted Mittelstaedt >>>> Cc: 'ARIN PPML' >>>> Subject: Re: [arin-ppml] IANA IPv4 /8 burn rate.... >>>> >>>> Electric cars are better than gasoline ones. Electric cars >>>> are available >>>> today, and fully compatible with the existing road system. >>>> Therefore, we >>>> should stop selling gasoline cars and go all electric. >>>> >>>> Oh, electric cars are too expensive, you say? And there's no >>>> charging >>>> stations where you live? Well that's OK, because you'll be >>>> better off in >>>> the long run. >>>> >>>> -Scott >>>> >>>> Ted Mittelstaedt wrote: >>>>>> -----Original Message----- >>>>>> From: Stephen Sprunk [mailto:stephen at sprunk.org] >>>>>> Sent: Thursday, August 28, 2008 8:42 PM >>>>>> To: Ted Mittelstaedt >>>>>> Cc: 'Scott Leibrand'; 'Alain Durand'; 'ARIN PPML' >>>>>> Subject: Re: [arin-ppml] IANA IPv4 /8 burn rate.... >>>>>> >>>>>> >>>>>> Ted Mittelstaedt wrote: >>>>>>> Everyone who assumes that moving to IPv6 would be better >>>>>> has I think >>>>>>> already provided a boatload of arguments as to why their >>>>>> way would be >>>>>>> better. >>>>>>> >>>>>>> But I have not really heard any arguments from the people >>>>>> who want >>>>>>> to stay with IPv4 as to why their way would be better. >>>>>>> >>>>>> I think that answer is simple: the short-term cost of adding >>>>>> more NAT is >>>>>> lower than the short-term cost of moving everything to IPv6. >>>>>> There's a >>>>>> lot of stuff that _still_ doesn't work (well or at all) with IPv6, >>>>>> despite over a decade of work and sweeping claims by IPv6 >>>>>> supporters, so >>>>>> the cost of the latter option isn't even calculable >>>> because it's not >>>>>> possible -- but even the parts that are possible will >>>>>> undoubtedly cost >>>>>> more, in the short term, than just tossing a few more NAT >>>>>> boxes into the >>>>>> network. >>>>>> >>>>>> I think everyone is in agreement that the long-term costs >>>> of IPv6 are >>>>>> cheaper than IPv4+NAT; what we're really debating is if >>>> and when that >>>>>> transition will happen and what to do in the meantime. >>>>>> >>>>> If the long term costs of IPv6 are cheaper that is a huge argument >>>>> against tossing a few more NAT boxes into the network. In short >>>>> you have just successfully argued one of the many points AGAINST >>>>> a liberalized transfer policy, and FOR moving to IPv6 asap, that >>>>> is, why IPv6 is better. >>>>> >>>>> I had asked for arguments from the people who want to stay with IPv4 >>>>> as to why their way would be better, and the best you can come >>>>> up with so far is to take an argument saying the IPv4 way would >>>>> be worse, and turn it upside down and paint it a different color >>>>> and hope I wouldn't notice this? >>>>> >>>>> Surely you do better than that! >>>>> >>>>> The transition would happen tomorrow if people just went >>>> and did the work. >>>>> Unfortunately the IPv6 transition is something that >>>> everyone doing it >>>>> is dependent on everyone else doing their bit. The end users can't >>>>> switch unless they get native IPv6 from their ISPs, and they can't >>>>> use a proxy because an IPv4->IPv6 proxy standard is still >>>> under debate. >>>>> The ISP's can't switch until their feeds switch, and those >>>> can't switch >>>>> until their peers switch, and their peers are probably the >>>> worst of all. >>>>> You get 3 backbones like Sprint, ATT & MCI in the room and MCI will >>>>> say they can't go to IPv6 until Sprint does, and Sprint will say >>>>> they can't go to IPv6 until ATT does, and ATT says they can't go to >>>>> IPv6 until MCI does. >>>>> >>>>> If you're a father of children surely you will have recognized this >>>>> as classic textbook BSing by now. >>>>> >>>>> Claims that IPv6 is not ready yet are EXACTLY LIKE claims that >>>>> Microsoft Windows Vista isn't ready yet. They are simply bogus >>>>> nonsense excuses that people make because IPv4 is a comfortable >>>>> pair of old broken-in shoes, and IPv6 is the brand new pair of >>>>> shiny, creaky, squeaky shoes. Yes the new shoes will take some >>>>> breaking in and you will get some sores for a bit until you >>>>> adjust. But how long are you going to keep putting tape or whatever >>>>> on the old shoes? Until they fall apart and the Internet >>>> stops working? >>>>> Ted >>>>> >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>>> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > From sleibrand at internap.com Fri Aug 29 18:47:04 2008 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 29 Aug 2008 15:47:04 -0700 Subject: [arin-ppml] IANA IPv4 /8 burn rate.... In-Reply-To: <48B8770D.70702@internap.com> References: <48B8677D.3010909@internap.com> <48B8770D.70702@internap.com> Message-ID: <48B87C68.50804@internap.com> Sorry, that last statement made very little sense in the context of http://www.arin.net/policy/proposals/2008_5.html I think it's time for a long weekend. -Scott Scott Leibrand wrote: > FWIW, I just pinged the authors of the APNIC proposal that just got > consensus yesterday about proposing it in the ARIN region. Looks like > they're interested if we are, so we should have something on the table for > April. > > -Scott > > Owen DeLong wrote: >> I believe the proposal that reserves the last N (for some value of N) >> addresses for transitional technologies comes much closer to >> achieving that stated purpose than any transfer policy will. >> >> Owen >> >> On Aug 29, 2008, at 2:17 PM, Scott Leibrand wrote: >> >>> Yeah, that's why the idea of "everyone must convert to IPv6 at the same >>> time" makes no sense to me. IPv4 and IPv6 will have to interoperate for >>> some time, so we need to have policies that continue to make IPv4 >>> available to support such transition mechanisms. >>> >>> -Scott >>> >>> Paul G. Timmins wrote: >>>> Biodiesel is available, and works in almost any vehicle that takes >>>> normal diesel. >>>> It doesn't use fossil fuels, and in some cases, burns cleaner. >>>> >>>> But it doesn't work in cars that take Unleaded Gas. >>>> >>>> So we shouldn't use Biodiesel until all cars can use it. That way we >>>> don't have to worry about compatibility issues. >>>> >>>> -Paul >>>> >>>>> -----Original Message----- >>>>> From: arin-ppml-bounces at arin.net >>>>> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand >>>>> Sent: Friday, August 29, 2008 4:59 PM >>>>> To: Ted Mittelstaedt >>>>> Cc: 'ARIN PPML' >>>>> Subject: Re: [arin-ppml] IANA IPv4 /8 burn rate.... >>>>> >>>>> Electric cars are better than gasoline ones. Electric cars >>>>> are available >>>>> today, and fully compatible with the existing road system. >>>>> Therefore, we >>>>> should stop selling gasoline cars and go all electric. >>>>> >>>>> Oh, electric cars are too expensive, you say? And there's no >>>>> charging >>>>> stations where you live? Well that's OK, because you'll be >>>>> better off in >>>>> the long run. >>>>> >>>>> -Scott >>>>> >>>>> Ted Mittelstaedt wrote: >>>>>>> -----Original Message----- >>>>>>> From: Stephen Sprunk [mailto:stephen at sprunk.org] >>>>>>> Sent: Thursday, August 28, 2008 8:42 PM >>>>>>> To: Ted Mittelstaedt >>>>>>> Cc: 'Scott Leibrand'; 'Alain Durand'; 'ARIN PPML' >>>>>>> Subject: Re: [arin-ppml] IANA IPv4 /8 burn rate.... >>>>>>> >>>>>>> >>>>>>> Ted Mittelstaedt wrote: >>>>>>>> Everyone who assumes that moving to IPv6 would be better >>>>>>> has I think >>>>>>>> already provided a boatload of arguments as to why their >>>>>>> way would be >>>>>>>> better. >>>>>>>> >>>>>>>> But I have not really heard any arguments from the people >>>>>>> who want >>>>>>>> to stay with IPv4 as to why their way would be better. >>>>>>>> >>>>>>> I think that answer is simple: the short-term cost of adding >>>>>>> more NAT is >>>>>>> lower than the short-term cost of moving everything to IPv6. >>>>>>> There's a >>>>>>> lot of stuff that _still_ doesn't work (well or at all) with IPv6, >>>>>>> despite over a decade of work and sweeping claims by IPv6 >>>>>>> supporters, so >>>>>>> the cost of the latter option isn't even calculable >>>>> because it's not >>>>>>> possible -- but even the parts that are possible will >>>>>>> undoubtedly cost >>>>>>> more, in the short term, than just tossing a few more NAT >>>>>>> boxes into the >>>>>>> network. >>>>>>> >>>>>>> I think everyone is in agreement that the long-term costs >>>>> of IPv6 are >>>>>>> cheaper than IPv4+NAT; what we're really debating is if >>>>> and when that >>>>>>> transition will happen and what to do in the meantime. >>>>>>> >>>>>> If the long term costs of IPv6 are cheaper that is a huge argument >>>>>> against tossing a few more NAT boxes into the network. In short >>>>>> you have just successfully argued one of the many points AGAINST >>>>>> a liberalized transfer policy, and FOR moving to IPv6 asap, that >>>>>> is, why IPv6 is better. >>>>>> >>>>>> I had asked for arguments from the people who want to stay with IPv4 >>>>>> as to why their way would be better, and the best you can come >>>>>> up with so far is to take an argument saying the IPv4 way would >>>>>> be worse, and turn it upside down and paint it a different color >>>>>> and hope I wouldn't notice this? >>>>>> >>>>>> Surely you do better than that! >>>>>> >>>>>> The transition would happen tomorrow if people just went >>>>> and did the work. >>>>>> Unfortunately the IPv6 transition is something that >>>>> everyone doing it >>>>>> is dependent on everyone else doing their bit. The end users can't >>>>>> switch unless they get native IPv6 from their ISPs, and they can't >>>>>> use a proxy because an IPv4->IPv6 proxy standard is still >>>>> under debate. >>>>>> The ISP's can't switch until their feeds switch, and those >>>>> can't switch >>>>>> until their peers switch, and their peers are probably the >>>>> worst of all. >>>>>> You get 3 backbones like Sprint, ATT & MCI in the room and MCI will >>>>>> say they can't go to IPv6 until Sprint does, and Sprint will say >>>>>> they can't go to IPv6 until ATT does, and ATT says they can't go to >>>>>> IPv6 until MCI does. >>>>>> >>>>>> If you're a father of children surely you will have recognized this >>>>>> as classic textbook BSing by now. >>>>>> >>>>>> Claims that IPv6 is not ready yet are EXACTLY LIKE claims that >>>>>> Microsoft Windows Vista isn't ready yet. They are simply bogus >>>>>> nonsense excuses that people make because IPv4 is a comfortable >>>>>> pair of old broken-in shoes, and IPv6 is the brand new pair of >>>>>> shiny, creaky, squeaky shoes. Yes the new shoes will take some >>>>>> breaking in and you will get some sores for a bit until you >>>>>> adjust. But how long are you going to keep putting tape or whatever >>>>>> on the old shoes? Until they fall apart and the Internet >>>>> stops working? >>>>>> Ted >>>>>> >>>>> _______________________________________________ >>>>> PPML >>>>> You are receiving this message because you are subscribed to >>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>>> Unsubscribe or manage your mailing list subscription at: >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>> Please contact info at arin.net if you experience any issues. >>>>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From tedm at ipinc.net Fri Aug 29 20:12:57 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 29 Aug 2008 17:12:57 -0700 Subject: [arin-ppml] IPv4 is depleted today In-Reply-To: <48B8304F.8816.4EDD8D6@farmer.umn.edu> Message-ID: <063C51B9C31343FDA0EBB4F986E01C33@tedsdesk> > -----Original Message----- > From: David Farmer [mailto:farmer at umn.edu] > Sent: Friday, August 29, 2008 3:22 PM > To: arin-ppml at arin.net; Ted Mittelstaedt > Cc: 'David Farmer' > Subject: RE: [arin-ppml] IPv4 is depleted today > > > On 29 Aug 2008 Ted Mittelstaedt wrote: > > > There are a couple of phrases in this post I found most > > humorous: > > > > "...return our current IPv4 address space it is to valuable > > internally...." > > > > "...will be necessary to extend the life of > > IPv4 long enough for us to get IPv6 ramped up..." > > Glad to be comic relief for you, but; > > > What our esteemed colleague David is saying is in essence > > he wants a transfer policy because he has a lot of IPv4 > > and he (understandably) wants to continue to use it. > > He labels IPv6 not ready, why not? He already has > > plenty of IPv4, he doesn't need IPv6. He has no incentive > > to deploy IPv6, really. > > Wrong, we have plenty of incentive to deploy IPv6, we been > working on it, Can you walk into your University Presidents office and tell him with a straight face that unless they pony up a quarter million bucks over the next 3 years for IPv6 deployment, that the college will lose connectivity to the Internet? That is my point. Of course you could not. If you did there would be an investigation by the beancounters who would find out that the real answer is "well, maybe we need to do this but not right at this moment" and the President would say "I understand where your coming from but there's more important things to spend money on right now" and that would, as they say, be that. THAT is what I am talking about when I say you have no real incentive. Not you personally, your organization. It does not. Have any real incentive. And it will not until the rest of the Internet does, in fact, switch to IPv6 You must have heard of the phrase "Mexican Standoff" I am sure. Same issue. > have you? We just have bigger incentives not to break IPv4, > yet, and there > are other projects, with higher priorities too. So you will do very little until the loss of access to IPv6 makes conversion to IPv6 into the top-dog incentive, more of an incentive than breaking IPv4, or other projects with "higher priorities" This is visionary management? Aren't you setting the priorities on your own projects? > But, we are > making deliberate, > all be it slow progress, are you? Four years ago we had IPv6 as an > equipment requirement for our new campus network RFP, we have been > putting our money where our mouth is for IPv6 for a while. > > But, IPv6 ain't ready for grandma today, with a lot of work > it will be by IPv4 > exhaustion. > And when will this work be done? It seems the incentive is into putting work into finding out how to avoid doing the work to switch to IPv6, rather than actually switching. Name 5 reasons that have nothing to do with money that you could not switch to IPv6 right this moment. I am sure there must be some. THOSE are the REAL reasons that are blocking IPv6 deployment. All other reasons, including the monetary "other projects are higher priority" are bogus nonsense. When people talk about IPv6 not being ready, THOSE are the issues that they should be talking about. But they don't - mostly, they talk about how expensive it's going to be to switch everything. That's making excuses. In our case the reason is simple - our major upstream promised native IPv6 this fall, last year. A few months ago they reniged. There will be consequences when their contract comes up at the end of the year. And incidentally they are a GSA contractor and so they obviously are reniging on the US government requirement for IPv6 too. I cannot understand how this is allowed to be so without consequences - but thankfully our owner has avoided government jobs when possible so we do not have, as they might say, an intimate knowledge of how government suppliers are allowed to get away with breaking their promises. Our suppliers aren't. > > He also won't give his network's IPv4 up to "sell" through > a transfer > > policy, or course not. He is just expecting every other > legacy holder > > out there to sell off their IPv4. > > Wrong, if the University of Minnesota were to stop using it's > IPv4 address > space we will return it to ARIN, and not sell it. We have in > the past, we > returned a C to IANA when we got our original B, and we may return a > couple other swamp C's in the future as a matter of > principle, but that really > won't make any difference to anything. Nor, would returning > all of our > address space, it might delay IANA exhaustion by a whole day or two. > > I'm just trying to recognize that it will be easier and more > effective to give > people an incentive to return address space, then to only ask > them return it, > or to try to force them to return it. > Timing is everything. Giving back a large swath of IPv6 pre-IPv6 runout matters. Giving it back soon after runout matters. Giving it back years later, when IPv6 is well on it's way, it nothing more than a photo-op. > > The situation reminds me when my city, Portland OR, put > > in Light Rail. Everyone driving cars in the city strongly > supported > > light rail. They all wanted it because the figured that "the OTHER > > guy" would stop driving his car, and take light rail, and > get the heck > > off the freeway so that THEY could drive an uncongested freeway. > > > > Needless to say, the freeway congestion did NOT go away. > > > > I would ask our colleague that if he feels that it would > > be too much trouble for him to split his legacy block > > to be able to sell off part of it under a liberalized > transfer policy, > > doesn't he think that everyone else with a legacy block is going to > > feel the same way? Why is he special? And if every other legacy > > holder feels this way, then where exactly are these IPv4 > blocks going > > to come from that will be sold through a liberalized transfer > > policy, that will "extend the life of IPv4" as he puts it. > > > > In short, he meticulously explains why a liberalized > transfer policy > > would do absolutely nothing to help him return his unused > IPv4 space > > to the free pool, then proceeds to claim that we need a liberalized > > transfer policy to enable more IPv4 to be returned to the > free pool!!! > > > > I can't think of a more damming example of why a > liberalized transfer > > policy would be about as useful as teats on a boar. > > You are right, we're not special, a liberalized transfer > policy will probably not > free up much space. That was one of my points, that I > obviously didn't > hammer hard enough. > > But, it might free up a little, and we're going to need every > hair-brained Wile > E. Coyote idea we can come up with to get to keep IPv4 going > long enough > to get everyone on to IPv6. Correction WE are going to need it, YOU are not. Because as you say, you already have enough IPv4 to last you. > Because unlike Wile E. Coyote, > if the Internet > falls off the cliff we not going to get up and walk away. > No, what will happen is the moneymen in the various companies that have billions invested in the Internet will apply wads of cash to the problem and voila, all IPv6 deployment problems will vanish. Right now all they are doing is throwing engineers at the problem and letting them argue amongst themselves as to the best solutions. Because, they really don't care right now because there's still IPv4 available. They figure once runout actually happens, the engineers will have finished arguing and then they will start paying for the deployment. > I'll put it back on you, are you sure we can get IPv6 fully > deployed before > IPv4 crashes into the wall, I'm not. We (UMN) will be there > but we've been > working on it for a long time. I don't think everyone will be. > Then, those who truly are unable to deploy it will say goodby to the Internet and go back to growing vegetables, or mailing letters via US mail or whatever they were doing before the Internet came along. While the rest of the world leaves them behind. When the horse-drawn carriage came out, a lot of people who were farmers ended up being blacksmiths, and carriage makers, and such. Then when the automobile came out, not every buggy whip maker made the transition to making cars. Some kept making buggy whips until they died - and likely, they were happy doing it. They had just opted out of the rat race. We cannot fundamentally change the Internet to accommodate the buggy whip makers. Right now we all are making buggy whips. But, before most of us retire, we likely will be making cars. > If we have a transfer policy that might free up a little > space, it is not going to > save us in the long term, nor will NAT, only IPv6 can do > that. But it could > help build a bridge, No, all it will do is provide incentive to the beancounters who don't know squat about anything, to NOT spend money for a while longer. It's a false hope, a mirage. > and if IPv4 addresses went for $1000 an > address it sure > would make a bigger incentive to move to IPv6 and hopefully > push IPv6 up > the priority list for IT departments everywhere. So if only > for that reason, it > might help to have a transfer policy, to give that extra little push. > IT departments who would only take action if this happened are what we call reactionary. In the US, unless a business is in a monopoly, (like Microsoft) being reactionary just pushes you down the whirlpool of inaction until you go out of business. > I also think the longer we debate a transfer policy, the more > the message > that IPv6 is the only true hope get diluted. > You are right. We should just kill the transfer policy idea and be done with it. Ted From tedm at ipinc.net Fri Aug 29 20:22:08 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 29 Aug 2008 17:22:08 -0700 Subject: [arin-ppml] IANA IPv4 /8 burn rate.... In-Reply-To: <48B868AB.4000400@sprunk.org> Message-ID: > -----Original Message----- > From: Stephen Sprunk [mailto:stephen at sprunk.org] > Sent: Friday, August 29, 2008 2:23 PM > To: Ted Mittelstaedt > Cc: 'Scott Leibrand'; 'Alain Durand'; 'ARIN PPML' > Subject: Re: [arin-ppml] IANA IPv4 /8 burn rate.... > > > The economics strongly favor that scenario, and that scenario > has been > played out several times in the past: nobody is willing to > step up and > spend the money to fix things, which gives their non-acting > competitors > an financial advantage, so any major change to the Internet > must result > from actual failure because that forces _all_ players to act > at the same > time. > > The financial markets also encourages executives to cut costs today > despite disastrous long-term consequences, because the > executives will > rake in tens of millions of dollars in the meantime and then pull the > ripcord on their golden parachute when their choices catch up > to them, > leaving the mess to the next round of execs -- or a > bankruptcy court -- > to sort things out and start the cycle over again. > Then I ask you, how long until the Halkan's prediction of galactic revolt is realized? IPv4 is illogical, it cannot endure, and therefore you are illogical to willingly be a part of it. Do nothing - let the failure happen. Ted From farmer at umn.edu Fri Aug 29 22:46:37 2008 From: farmer at umn.edu (David Farmer) Date: Fri, 29 Aug 2008 21:46:37 -0500 Subject: [arin-ppml] IPv4 is depleted today In-Reply-To: <063C51B9C31343FDA0EBB4F986E01C33@tedsdesk> References: <48B8304F.8816.4EDD8D6@farmer.umn.edu>, <063C51B9C31343FDA0EBB4F986E01C33@tedsdesk> Message-ID: <48B86E3D.25955.5DFC370@farmer.umn.edu> On 29 Aug 2008 Ted Mittelstaedt wrote: > On 29 Aug 2008 David Farmer wrote: > > > On 29 Aug 2008 Ted Mittelstaedt wrote: > > > > > There are a couple of phrases in this post I found most > > > humorous: > > > > > > "...return our current IPv4 address space it is to valuable > > > internally...." > > > > > > "...will be necessary to extend the life of > > > IPv4 long enough for us to get IPv6 ramped up..." > > > > Glad to be comic relief for you, but; > > > > > What our esteemed colleague David is saying is in essence > > > he wants a transfer policy because he has a lot of IPv4 > > > and he (understandably) wants to continue to use it. > > > He labels IPv6 not ready, why not? He already has > > > plenty of IPv4, he doesn't need IPv6. He has no incentive > > > to deploy IPv6, really. > > > > Wrong, we have plenty of incentive to deploy IPv6, we been > > working on it, > > Can you walk into your University Presidents office and > tell him with a straight face that unless they pony up a > quarter million bucks over the next 3 years for IPv6 deployment, > that the college will lose connectivity to the Internet? I don't have to; IPv6 was built into our requirements for our last tech refresh, 4 years ago, and that wasn't a quarter million it was 16 million, and included 10G backbone and 10/100/1000 for now 70,000 ports. > That is my point. Of course you could not. Probably not as a separate project, but if your not doing a tech refresh in the next 2 years or so why didn't you include IPv6 in your last tech refresh? The writing was on the wall. > If you did there > would be an investigation by the beancounters who would find > out that the real answer is "well, maybe we need to do this > but not right at this moment" and the President would say "I > understand where your coming from but there's more important > things to spend money on right now" and that would, as they > say, be that. No, that wouldn't be the President of the University that would be the CIO, and I have a plak on my wall thanking me for a three year effort, of which making sure all the new equipment has basic IPv6 capabilities was one little part. > THAT is what I am talking about when I say you have no real > incentive. Not you personally, your organization. It does not. > Have any real incentive. And it will not until the rest of > the Internet does, in fact, switch to IPv6 That is where you are wrong, you might be right for other organizations but we were doing IPv4 in 1985 or so. What was our incentive to do IPv4 then? We have the same incentives to do IPv6 now. > You must have heard of the phrase "Mexican Standoff" I am sure. > Same issue. > > > have you? We just have bigger incentives not to break IPv4, > > yet, and there > > are other projects, with higher priorities too. > > So you will do very little until the loss of access to IPv6 > makes conversion to IPv6 into the top-dog incentive, more > of an incentive than breaking IPv4, or other projects with > "higher priorities" It will be done long before it needs to be a top priority, if I wanted to just throw the switch I could do it right now. But, we aren't just going to throw the switch. Did you miss the part in my original email "I hope to enable it (IPv6) on our whole backbone and make it available anywhere anyone wants it yet this year or early next, then in 2010 or 2011 turn it on by default everywhere on campus." > This is visionary management? Well, I think we do pretty good, if your not ready for IPv6 then it is you who lacks visionary management. > Aren't you setting the priorities on your own projects? No, that is what CIOs, Directors, and Managers are for. We are deploying about 3000 new 802.11n APs as we speak, students don't care about IPv6 yet, they sure do about wireless though. We just completed upgrades for 10G WAN connectivity, including lighting 1500 miles of dark fiber, we share a 100G to Chicago and are already upgrading to 200G. IPv6 is not a top priority, but it high enough on the list that work does get done on it. > > But, we are > > making deliberate, > > all be it slow progress, are you? Four years ago we had IPv6 as an > > equipment requirement for our new campus network RFP, we have been > > putting our money where our mouth is for IPv6 for a while. > > > > But, IPv6 ain't ready for grandma today, with a lot of work > > it will be by IPv4 > > exhaustion. > > > > And when will this work be done? It seems the incentive is into > putting work into finding out how to avoid doing the work to switch to > IPv6, rather than actually switching. Not for us. We've been working on it for several years now. > Name 5 reasons that have nothing to do with money that you > could not switch to IPv6 right this moment. I am sure there must be > some. THOSE are the REAL reasons that are blocking IPv6 deployment. > All other reasons, including the monetary "other projects are higher > priority" are bogus nonsense. 1. The risk of getting IPv6 labelled as that stuff that breaks the network 2. Testing, Testing, more Testing, and Change Control 3. Lack of feature parity between IPv4 and IPv6 on the same platform 4. Stupid vendor games, making IPv6 a special feature train 5. Having to argue with people like you that IPv6 is what needs to happen See this for the detail of a particular instance of #2 and #3; http://events.internet2.edu/2008/jt- hawaii/sessionDetails.cfm?session=3638&event=278 Also, #2, #3, and #4 have money components, but thats not the driver for them. #5 alternates between a big a head ache and a lot of fun depending on how I feel on a particular day. :) > When people talk about IPv6 not being ready, THOSE are the issues that > they should be talking about. But they don't - mostly, they talk > about how expensive it's going to be to switch everything. That's > making excuses. Not us, look at the link above. > In our case the reason is simple - our major upstream promised native > IPv6 this fall, last year. A few months ago they reniged. There will > be consequences when their contract comes up at the end of the year. Good, you have to put your money where your mouth is. > And incidentally they are a GSA contractor and so they obviously are > reniging on the US government requirement for IPv6 too. I cannot > understand how this is allowed to be so without consequences - but > thankfully our owner has avoided government jobs when possible so we > do not have, as they might say, an intimate knowledge of how > government suppliers are allowed to get away with breaking their > promises. Our suppliers aren't. I won't go there except to say, the Government "requirement" was mostly smoke. I have a commercial IP provider (GX) that does IPv6 and IPv6 was part of the reason we selected them. I also have Internet2 connectivity. You could do tunnels to get started, I wouldn't use tunnel for production, but you can get your feet wet. > > > He also won't give his network's IPv4 up to "sell" through > > a transfer > > > policy, or course not. He is just expecting every other > > legacy holder > > > out there to sell off their IPv4. > > > > Wrong, if the University of Minnesota were to stop using it's > > IPv4 address > > space we will return it to ARIN, and not sell it. We have in > > the past, we > > returned a C to IANA when we got our original B, and we may return a > > couple other swamp C's in the future as a matter of principle, but > > that really won't make any difference to anything. Nor, would > > returning all of our address space, it might delay IANA exhaustion > > by a whole day or two. > > > > I'm just trying to recognize that it will be easier and more > > effective to give > > people an incentive to return address space, then to only ask > > them return it, > > or to try to force them to return it. > > > > Timing is everything. Giving back a large swath of IPv6 pre-IPv6 > runout matters. Giving it back soon after runout matters. Giving it > back years later, when IPv6 is well on it's way, it nothing more than > a photo-op. I think you mean "Giving back a large swath of IPv4 pre-IPv4 run-out matters." At the current burn-rate giving back anything less than a major portion of a /8 is really only a photo-op. That might means a month or two longer at current burn-rates. After IPv4 run-out giving back any addresses probably wouldn't even make a historical footnote, let alone a photo-op. > > > The situation reminds me when my city, Portland OR, put > > > in Light Rail. Everyone driving cars in the city strongly > > supported > > > light rail. They all wanted it because the figured that "the > > > OTHER guy" would stop driving his car, and take light rail, and > > get the heck > > > off the freeway so that THEY could drive an uncongested freeway. > > > > > > Needless to say, the freeway congestion did NOT go away. > > > > > > I would ask our colleague that if he feels that it would > > > be too much trouble for him to split his legacy block > > > to be able to sell off part of it under a liberalized > > transfer policy, > > > doesn't he think that everyone else with a legacy block is going > > > to feel the same way? Why is he special? And if every other > > > legacy holder feels this way, then where exactly are these IPv4 > > blocks going > > > to come from that will be sold through a liberalized transfer > > > policy, that will "extend the life of IPv4" as he puts it. > > > > > > In short, he meticulously explains why a liberalized > > transfer policy > > > would do absolutely nothing to help him return his unused > > IPv4 space > > > to the free pool, then proceeds to claim that we need a > > > liberalized transfer policy to enable more IPv4 to be returned to > > > the > > free pool!!! > > > > > > I can't think of a more damming example of why a > > liberalized transfer > > > policy would be about as useful as teats on a boar. > > > > You are right, we're not special, a liberalized transfer > > policy will probably not > > free up much space. That was one of my points, that I > > obviously didn't > > hammer hard enough. > > > > But, it might free up a little, and we're going to need every > > hair-brained Wile > > E. Coyote idea we can come up with to get to keep IPv4 going > > long enough > > to get everyone on to IPv6. > > Correction WE are going to need it, YOU are not. Because as you > say, you already have enough IPv4 to last you. Because of Metcalfe's Law, I = YOU = WE = THEM, I lose value if your not connected. > > Because unlike Wile E. Coyote, > > if the Internet > > falls off the cliff we not going to get up and walk away. > > > > No, what will happen is the moneymen in the various companies > that have billions invested in the Internet will apply wads of > cash to the problem and voila, all IPv6 deployment problems > will vanish. Right, you obviously don't understand the combination of Internet Scale and Logistics, there are problems that money can't solve, and that only time can. Wile E. Coyote seems to have an infinite credit line with ACME and he still can't catch the Road Runner. :) > Right now all they are doing is throwing engineers at the problem and > letting them argue amongst themselves as to the best solutions. > Because, they really don't care right now because there's still IPv4 > available. They figure once runout actually happens, the engineers > will have finished arguing and then they will start paying for the > deployment. That's to late, the Internet goes splat, and unlike Wile E. Coyote we don't get up a walk away. > > I'll put it back on you, are you sure we can get IPv6 fully > > deployed before > > IPv4 crashes into the wall, I'm not. We (UMN) will be there > > but we've been > > working on it for a long time. I don't think everyone will be. > > > > Then, those who truly are unable to deploy it will say goodby > to the Internet and go back to growing vegetables, or mailing > letters via US mail or whatever they were doing before the > Internet came along. While the rest of the world leaves them > behind. Again Metcalfe's Law, if they go away we lose a lot too. > When the horse-drawn carriage came out, a lot of people who were > farmers ended up being blacksmiths, and carriage makers, and > such. Then when the automobile came out, not every buggy whip > maker made the transition to making cars. Some kept making > buggy whips until they died - and likely, they were happy > doing it. They had just opted out of the rat race. > > We cannot fundamentally change the Internet to accommodate the > buggy whip makers. Right now we all are making buggy whips. > But, before most of us retire, we likely will be making cars. Then why do you seem to be telling people to keep making buggy whips? > > If we have a transfer policy that might free up a little > > space, it is not going to > > save us in the long term, nor will NAT, only IPv6 can do > > that. But it could > > help build a bridge, > > No, all it will do is provide incentive to the beancounters > who don't know squat about anything, to NOT spend money for > a while longer. It's a false hope, a mirage. > > > and if IPv4 addresses went for $1000 an > > address it sure > > would make a bigger incentive to move to IPv6 and hopefully > > push IPv6 up > > the priority list for IT departments everywhere. So if only > > for that reason, it > > might help to have a transfer policy, to give that extra little > > push. > > > > IT departments who would only take action if this happened are what we > call reactionary. In the US, unless a business is in a monopoly, > (like Microsoft) being reactionary just pushes you down the whirlpool > of inaction until you go out of business. > > > I also think the longer we debate a transfer policy, the more > > the message > > that IPv6 is the only true hope get diluted. > > > > You are right. We should just kill the transfer policy idea and > be done with it. I could live with that if it could only just happen. You might subscribe to my alternate proposal then, lets relax the usage requirement for IPv4 and kick up the burn-rate, make it run out faster. Then your moneymen come to the rescue. The only problem with this, that's a big gamble. If we get it wrong, Wile E. Coyote goes splat and maybe even hard enough that he doesn't get up. What do you think? > Ted ======================================================= David Farmer Email: farmer at umn.edu Office of Information Technology Networking & Telecomunication Services University of Minnesota Phone: 612-626-0815 2218 University Ave SE Cell: 612-812-9952 Minneapolis, MN 55414-3029 FAX: 612-626-1818 ======================================================= From michael.dillon at bt.com Sat Aug 30 10:04:39 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sat, 30 Aug 2008 15:04:39 +0100 Subject: [arin-ppml] IPv4 is depleted today In-Reply-To: <48B86E3D.25955.5DFC370@farmer.umn.edu> Message-ID: > I don't have to; IPv6 was built into our requirements for our > last tech refresh, > Probably not as a separate project, but if your not doing a > tech refresh in the next 2 years or so why didn't you include > IPv6 in your last tech refresh? The writing was on the wall. That is a darn good question and one which I expect stock market analysts to be asking before the year is out. Apparently in some large publicly traded companies, management screwed up and did not include IPv6 in their technology refresh other than as an afterthought. Those companies are going to have very tough times in two to three years, their share values will plummet, and their customers will suffer as well. If this is the case, then it is better for all of us if market analysts ask the tough questions now and spur senior management into incorporating IPv6 into the company's survival plan. There is still enough time for these companies to avoid financial disaster and shareholder lawsuits if they act soon. --Michael Dillon From rw at firstpr.com.au Sat Aug 30 11:02:36 2008 From: rw at firstpr.com.au (Robin Whittle) Date: Sun, 31 Aug 2008 01:02:36 +1000 Subject: [arin-ppml] IPv4 is depleted today - unrealistic statements about IPv6 inevitability In-Reply-To: References: Message-ID: <48B9610C.5010404@firstpr.com.au> I think this is completely unrealistic: Michael Dillon wrote: >> I don't have to; IPv6 was built into our requirements for our >> last tech refresh, > >> Probably not as a separate project, but if your not doing a >> tech refresh in the next 2 years or so why didn't you include >> IPv6 in your last tech refresh? The writing was on the wall. > > That is a darn good question and one which I expect stock market > analysts to be asking before the year is out. Apparently in some > large publicly traded companies, management screwed up and did > not include IPv6 in their technology refresh other than as an > afterthought. Those companies are going to have very tough times > in two to three years, their share values will plummet, and their > customers will suffer as well. > > If this is the case, then it is better for all of us if market analysts > ask the tough questions now and spur senior management into > incorporating IPv6 into the company's survival plan. There is still > enough time for these companies to avoid financial disaster > and shareholder lawsuits if they act soon. IPv6 isn't much use to anyone right now, because almost no-one else is using it http://www.potaroo.net/presentations/2008-08-21-ipv6-failure.pdf http://www.extremetech.com/article2/0,2845,2328258,00.asp http://asert.arbornetworks.com/2008/8/the-end-is-near-but-is-ipv6/ and since there is still so much software and hardware which doesn't work with it. IPv6 doesn't enable ordinary end-users to do anything of value they can't already do with IPv4. The shortage of previously unallocated address space in IPv4 will just mean that people get smarter about using the available space. The IPv4 Internet works. It is what everyone uses. Virtually no-one uses the IPv6 Internet. (Traffic is ~0.00002 of IPv4's traffic.) It is a separate Internet and is not compatible with the IPv4 Internet in terms of being able to do what people want to do while only having an IPv6 address. The IPv4 Internet works OK right now and this won't change as it gets a bit trickier to find address space over the next five or ten years. What I wrote about IPv6 will take an awfully long time to change: It is a separate, incompatible, Internet from IPv4. No-one uses it much. There is way too much hardware and software which doesn't work with it to consider abandoning IPv4. I think it is wildly unrealistic to talk about companies failing due to not having IPv6. This imminent doomsday stuff about IPv4 address depletion is even less credible than Y2K scaremongering. For more on why it is hard or impossible to get ordinary domestic and office DSL/DOCSIS end-users away from having their own IPv4 address, please search for "Dual Stack Lite" (Comcast's proposal for having a bunch of DSL/DOCSIS customers on a single IPv4 NAT public address) in the IRTF Routing Research Group list: http://psg.com/lists/rrg/2008/maillist.html To see my approach to making IPv4 and IPv6 more scalable, whilst also enabling much finer slicing and dicing of IPv4 space, so space can be better utilized . . . and a new approach to global mobility for IPv4 and IPv6: http://www.firstpr.com.au/ip/ivip/ - Robin From vixie at isc.org Sat Aug 30 12:46:15 2008 From: vixie at isc.org (Paul Vixie) Date: Sat, 30 Aug 2008 16:46:15 +0000 Subject: [arin-ppml] IPv4 is depleted today - unrealistic statements about IPv6 inevitability In-Reply-To: <48B9610C.5010404@firstpr.com.au> (Robin Whittle's message of "Sun\, 31 Aug 2008 01\:02\:36 +1000") References: <48B9610C.5010404@firstpr.com.au> Message-ID: rw at firstpr.com.au (Robin Whittle) writes: > I think this is completely unrealistic: i think it's only mostly unrealistic :-). > IPv6 isn't much use to anyone right now, because almost no-one else > is using it there's a significant last-mover advantage, and so the people who want to finish the transition with the most money, are hanging back and letting everybody else go first. this is "the network effect" in action. at PAIX when we opened a new site nobody wanted to be the first one to connect to the peering switch, but folks were anxiously desirous to get the tenth port. that doesn't mean IPv6 is a bad idea any more than new peering points are a bad idea. it just means uptake is slow at first on stuff like this, and that early adopters have to be insensitive to their in-year revenue and expense prospects. IPv6 works fine for the early adopters who use it to talk to each other and who are getting their equipment and training done NOW so that if it actually takes off in a big way they won't be in a hurry later. it's well understood that investment in IPv6 will probably not yield much same-year revenue, and that the largest part of the "endpoint base" will not move until that changes. when other networks can't get new IPv4 or can't deaggregate the IPv4 they bought off of e-bay fast enough because the other, other networks can't grow their routing tables fast enough, then those other networks are going to start doing their growth some other way. they won't stop growing. GIH seems to think that the "other way" this growth will happen is going to be NAT and while i agree that there will be an uptick i cannot think that this will be all that happens. many of you here won't need IPv6 because you've run out of space. you will need IPv6 because other networks have run out of space, and because new deployments will have no choice. but you don't have to take my word for it; you can wait for hard evidence and then do a bunch of in-year hurry-up unbudgeted upgrades. i think that approach is a little bit silly, since the actual costs of running dual-stack, at least near your edge or in your labs, is not high enough to be worth avoiding. even if you have to tunnel at first because your upstreams and/or peers aren't as visionary as yourself. speaking of vision, here are the competing ones as i see them. on one hand we've got a massively deaggregated IPv4-only core with the density of pure neutronium and only the largest carriers able to handle the route churn and FIB storage, and where the market value of one more /24 is set by the cost of trying to find someone who will route it for you, and there are harsh pressures on old PI, and there's more or less no new PI, and there will be no new entrants into the IPv4 core routing market. the rest of us will be paying high dollars for edge PA and using NAT universally. all new apps will either not depend on end-to-end or they will fail, so things like VoIP will have to be carrier-side and most new apps will ride on TCP/80. on the other hand we've got a brief unpleasant period like described above before enough other networks add native IPv6 to make it worthwhile for late adopters to finally add native IPv6, at which point new apps have a choice of "IPv6 native, or IPv4 NAT" and new entrants to the core routing arena have that choice and while it's risky some folks will make it work somehow. pressure against PI will remain about the same as it is now. NAT will gradually shrink down to places where its security features are worthwhile, or where there's just no good enough reason to tear it out and go native. i don't merely like the second vision better. i am the parent of teenagers i have studied history and am sure that if new generations of humans and their corporations are told that they will have to live out their lives according to the values and compromises of their forebears and that their opporunities must all be shackled by tithes to existing landowners, then they WILL find another way. -- Paul Vixie From mueller at syr.edu Sat Aug 30 12:54:46 2008 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 30 Aug 2008 12:54:46 -0400 Subject: [arin-ppml] IPv4 is depleted today In-Reply-To: <48B7DE9F.7707.3AEC08B@farmer.umn.edu> References: <48B7DE9F.7707.3AEC08B@farmer.umn.edu> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0E56C@SUEXCL-02.ad.syr.edu> David Your long post was a really excellent encapsulation of the kind of economic trade-offs that many organizations must face. From an economic point of view, it is absolutely correct that depletion is not a single event but a process, and that for many organizations the economic-technical calculus has already crossed the threshold of what one might call "depletion." Your post has two clear implications. One is that any policy regarding IPv4 depletion should not be contingent on free pool exhaustion but should go into effect as soon as feasible. The second is that you have conclusively demonstrated how inapplicable and outdated the whole business of assigning IPv4 according to "need" has become in these circumstances. One could argue that you have more addresses than you need, one could also argue that you need them. What really matters is how much it costs to reclaim them, how many opportunity costs you incur by giving them up, how much it costs to implement technical measures to reduce consumption, etc. It's not about "need" it's relative need in the context of cost-benefit tradeoffs. And as you suggest, liberalized transfers may or may not make a big difference in this calculus. But it is clearly an option we should have, and it clearly could have some benefit. For me, liberalization of transfers is no longer a debate about the merits of that policy itself. It has become a debate about whether the ARIN community has become so ideologically rigid in its commitment to "address Marxism" that it cannot adapt to new economic realities. I will watch the progress of these policies with interest as a kind of diagnosis of the health of the RIR governance regime. If ARIN and the others cannot face reality and execute on this matter, it will not bode well for the future. --MM > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of David Farmer [long snip] > Personally I think, increased use IPv4 NAT, some kind of transfer policy, > or forced return of unused resources, will be necessary to extend the life > of IPv4 long enough for us to get IPv6 ramped up. I think a transfer > policy will be cleaner than trying to force people to return resources. > > But please don't take that as saying I like those options or that it is an > alternative to deploying IPv6, it is just necessary. From mueller at syr.edu Sat Aug 30 13:09:19 2008 From: mueller at syr.edu (Milton L Mueller) Date: Sat, 30 Aug 2008 13:09:19 -0400 Subject: [arin-ppml] The LRSA $100 fee... In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40B2033D4@CL-S-EX-1.stanleyassociates.com> References: <48B82BBE.80907@bogomips.com> <369EB04A0951824ABE7D8BAC67AF9BB40B2033D4@CL-S-EX-1.stanleyassociates.com> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0E56E@SUEXCL-02.ad.syr.edu> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Howard, W. Lee > It is my humble opinion that domain name registrars suck. The > best of them provides lousy service and near-useless WHOIS. > Competition has ruined registry services by starting a race to > the bottom in price and service. > Competition in the domain name registrar space has probably returned about US$ 5 billion in consumer surplus to domain name registrants over the past 7 years. It's led to some problems but also a massive improvement in service levels and growth in the industry. If you wish to hold up Network Solutions Inc's pre-competition service levels as an improvement over what exists now I suspect that you keep that quiet. People who had to deal with them will either harm themselves via an apoplectic reaction or lose control and assault you. ;-) Are we going to start pining for the good old AT&T monopoly next? From tvest at pch.net Sat Aug 30 13:28:58 2008 From: tvest at pch.net (Tom Vest) Date: Sat, 30 Aug 2008 13:28:58 -0400 Subject: [arin-ppml] The LRSA $100 fee... In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E56E@SUEXCL-02.ad.syr.edu> References: <48B82BBE.80907@bogomips.com> <369EB04A0951824ABE7D8BAC67AF9BB40B2033D4@CL-S-EX-1.stanleyassociates.com> <7663C7E01D8E094989CA62F0B0D21CD901E0E56E@SUEXCL-02.ad.syr.edu> Message-ID: <03B49827-8327-430E-A6B9-7F45EA1D0EEE@pch.net> On Aug 30, 2008, at 1:09 PM, Milton L Mueller wrote: >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On >> Behalf Of Howard, W. Lee >> It is my humble opinion that domain name registrars suck. The >> best of them provides lousy service and near-useless WHOIS. >> Competition has ruined registry services by starting a race to >> the bottom in price and service. >> > > Competition in the domain name registrar space has probably returned > about US$ 5 billion in consumer surplus to domain name registrants > over > the past 7 years. It's led to some problems but also a massive > improvement in service levels and growth in the industry. If you > wish to > hold up Network Solutions Inc's pre-competition service levels as an > improvement over what exists now I suspect that you keep that quiet. > People who had to deal with them will either harm themselves via an > apoplectic reaction or lose control and assault you. ;-) > > Are we going to start pining for the good old AT&T monopoly next? With *competing* switched services, a race to the bottom only affects the parties that opt for the the lower/lowest cost provider. Given the nature of switched services, the existence of competition itself would mean that the system is not highly vulnerable to reckless economizing by the most aggressive price slashers. Notice how Lee specifically mentioned whois -- that's one feature that obviously can be (has been?) eroded by race-to-the-bottom competition. Broadly decentralized, unswitched service platforms like the Internet don't enjoy the same kind of immunity/invulnerability to such perverse commercial strategies as do switched platforms... (note: we covered this once before on June 26, 2008 11:55:09 AM EDT / Re: [arin-ppml] Q1 - ARIN address transfer policy: why thetriggerdate?) So, will the real good old monopoly advocate please stand up! TV From ray at snewisp.com Sat Aug 30 13:34:46 2008 From: ray at snewisp.com (r ay) Date: Sat, 30 Aug 2008 13:34:46 -0400 Subject: [arin-ppml] domain registrars etc Message-ID: Well this hits it on the head. Network Solutions, prior to competition, WAS the bottom of the barrel as far as service goes. At the least, they were forced to improve to compete. So the competition was indeed healthy. Yes, some are bad, but overall its FAR better than pre competition. Ray Weber SNEWISP llc On Aug 30, 2008, at 1:09 PM, Milton L Mueller wrote: >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On >> Behalf Of Howard, W. Lee >> It is my humble opinion that domain name registrars suck. The >> best of them provides lousy service and near-useless WHOIS. >> Competition has ruined registry services by starting a race to >> the bottom in price and service. >> > > Competition in the domain name registrar space has probably returned > about US$ 5 billion in consumer surplus to domain name registrants > over > the past 7 years. It's led to some problems but also a massive > improvement in service levels and growth in the industry. If you > wish to > hold up Network Solutions Inc's pre-competition service levels as an > improvement over what exists now I suspect that you keep that quiet. > People who had to deal with them will either harm themselves via an > apoplectic reaction or lose control and assault you. ;-) > > Are we going to start pining for the good old AT&T monopoly next? -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.kessens at nsn.com Sun Aug 31 02:18:30 2008 From: david.kessens at nsn.com (David Kessens) Date: Sat, 30 Aug 2008 23:18:30 -0700 Subject: [arin-ppml] IPv4 is depleted today In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E56C@SUEXCL-02.ad.syr.edu> References: <48B7DE9F.7707.3AEC08B@farmer.umn.edu> <7663C7E01D8E094989CA62F0B0D21CD901E0E56C@SUEXCL-02.ad.syr.edu> Message-ID: <20080831061830.GK5025@nsn.com> Milton, On Sat, Aug 30, 2008 at 12:54:46PM -0400, Milton L Mueller wrote: > > For me, liberalization of transfers is no longer a debate about the > merits of that policy itself. It has become a debate about whether the > ARIN community has become so ideologically rigid in its commitment to > "address Marxism" that it cannot adapt to new economic realities. While I am personally not opposed to allowing a more liberalized market of transfers, you just exposed yourself as way more rigid in your own pro open market thinking as most people on this list who are in support of a non open market approach. Can we please keep this kind of ideologism off this list and discuss the actual merits of a transfer policy instead of accusing other thinking people of being a communists ? David Kessens --- From mueller at syr.edu Sun Aug 31 12:34:26 2008 From: mueller at syr.edu (Milton L Mueller) Date: Sun, 31 Aug 2008 12:34:26 -0400 Subject: [arin-ppml] The LRSA $100 fee... In-Reply-To: <03B49827-8327-430E-A6B9-7F45EA1D0EEE@pch.net> References: <48B82BBE.80907@bogomips.com> <369EB04A0951824ABE7D8BAC67AF9BB40B2033D4@CL-S-EX-1.stanleyassociates.com> <7663C7E01D8E094989CA62F0B0D21CD901E0E56E@SUEXCL-02.ad.syr.edu> <03B49827-8327-430E-A6B9-7F45EA1D0EEE@pch.net> Message-ID: <7663C7E01D8E094989CA62F0B0D21CD901E0E574@SUEXCL-02.ad.syr.edu> > -----Original Message----- > Notice how Lee specifically mentioned whois -- that's one feature that > obviously can be (has been?) eroded by race-to-the-bottom competition. DNS Whois? If you are referring to the efforts of individuals to retrieve their privacy rights via proxy registration services, I don't see that as a race to the bottom but as a significant response to human rights concerns and legitimate demand. If you are referring to the quality of data in your run-of-the-mill Whois registration, there has been significant improvement since 1999. Whois is a uniform contractual requirement and new enforcement mechanisms for reporting and correcting data accuracy have been instituted. Sorry to spoil your points with facts. But its difficult not to be struck with the tendency to blame problems that have nothing to do with competition on "competition." From tvest at pch.net Sun Aug 31 13:31:07 2008 From: tvest at pch.net (Tom Vest) Date: Sun, 31 Aug 2008 13:31:07 -0400 Subject: [arin-ppml] The LRSA $100 fee... In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E574@SUEXCL-02.ad.syr.edu> References: <48B82BBE.80907@bogomips.com> <369EB04A0951824ABE7D8BAC67AF9BB40B2033D4@CL-S-EX-1.stanleyassociates.com> <7663C7E01D8E094989CA62F0B0D21CD901E0E56E@SUEXCL-02.ad.syr.edu> <03B49827-8327-430E-A6B9-7F45EA1D0EEE@pch.net> <7663C7E01D8E094989CA62F0B0D21CD901E0E574@SUEXCL-02.ad.syr.edu> Message-ID: <99DAA789-91C2-43F7-9BB9-99FD7169E0F7@pch.net> On Aug 31, 2008, at 12:34 PM, Milton L Mueller wrote: >> -----Original Message----- >> Notice how Lee specifically mentioned whois -- that's one feature >> that >> obviously can be (has been?) eroded by race-to-the-bottom >> competition. > > DNS Whois? If you are referring to the efforts of individuals to > retrieve their privacy rights via proxy registration services, I don't > see that as a race to the bottom but as a significant response to > human > rights concerns and legitimate demand. > > If you are referring to the quality of data in your run-of-the-mill > Whois registration, there has been significant improvement since 1999. > Whois is a uniform contractual requirement and new enforcement > mechanisms for reporting and correcting data accuracy have been > instituted. > > Sorry to spoil your points with facts. Facts?! If you are referring to your latest ad hoc substitution of what we were previously talking about by something you'd be more comfortable talking about, I don't see that as meriting the indulgence of a serious response here. But I'll grant a partial indulgence anyway. "Improvement since 1999" is a clever way of phrasing the answer, since that could be said of any change that improves matters the tiniest bit, e.g., from 91% to 92% accuracy, or from 1% to 2% accuracy. Which one is closer to true? GAO 06-165, November 2005: Prevalence of False Contact Information for Registered Domain Names http://www.gao.gov/new.items/d06165.pdf But you don't really care about competition or accuracy in this case, do you? You tipped your hand a little too much with the attempted redirection to "retrieval of privacy rights," whatever that means. Be honest Milton, if you value personal privacy above all other values, isn't falsification of whois just one acceptable means to a greater end? > But its difficult not to be struck with the tendency to blame problems > that have nothing to do with competition on "competition." It's also not difficult to be struck by the behavior of someone who only has one tool -- ala a child with a hammer. They're the ones wandering around bashing everything the exact same way, as if every other object in the world is a nail. TV P.S. we can talk about this at TPRC too, or at ARIN XXII if you're also planning to be there. From tvest at pch.net Sun Aug 31 16:24:28 2008 From: tvest at pch.net (Tom Vest) Date: Sun, 31 Aug 2008 16:24:28 -0400 Subject: [arin-ppml] Privacy rights & IP number whois ( was Re: The LRSA $100 fee...) In-Reply-To: <99DAA789-91C2-43F7-9BB9-99FD7169E0F7@pch.net> References: <48B82BBE.80907@bogomips.com> <369EB04A0951824ABE7D8BAC67AF9BB40B2033D4@CL-S-EX-1.stanleyassociates.com> <7663C7E01D8E094989CA62F0B0D21CD901E0E56E@SUEXCL-02.ad.syr.edu> <03B49827-8327-430E-A6B9-7F45EA1D0EEE@pch.net> <7663C7E01D8E094989CA62F0B0D21CD901E0E574@SUEXCL-02.ad.syr.edu> <99DAA789-91C2-43F7-9BB9-99FD7169E0F7@pch.net> Message-ID: Hi Milton, A couple of quick questions: 1. Do you think that the completeness and accuracy of current DNS whois is the right standard for IP number whois? 2. Does your vision for individual privacy rights extend to "corporate persons," or only to natural persons? -- It would appear that you reject the distinction in DNS whois: http://forum.icann.org/lists/gnso-reg-sgc/msg00072.html Thanks, TV On Aug 31, 2008, at 1:31 PM, Tom Vest wrote: > On Aug 31, 2008, at 12:34 PM, Milton L Mueller wrote: > >>> -----Original Message----- >>> Notice how Lee specifically mentioned whois -- that's one feature >>> that >>> obviously can be (has been?) eroded by race-to-the-bottom >>> competition. >> >> DNS Whois? If you are referring to the efforts of individuals to >> retrieve their privacy rights via proxy registration services, I >> don't >> see that as a race to the bottom but as a significant response to >> human >> rights concerns and legitimate demand. >> >> If you are referring to the quality of data in your run-of-the-mill >> Whois registration, there has been significant improvement since >> 1999. >> Whois is a uniform contractual requirement and new enforcement >> mechanisms for reporting and correcting data accuracy have been >> instituted. >> >> Sorry to spoil your points with facts. > > Facts?! If you are referring to your latest ad hoc substitution of > what we were previously talking about by something you'd be more > comfortable talking about, I don't see that as meriting the > indulgence of a serious response here. > > But I'll grant a partial indulgence anyway. "Improvement since 1999" > is a clever way of phrasing the answer, since that could be said of > any change that improves matters the tiniest bit, e.g., from 91% to > 92% accuracy, or from 1% to 2% accuracy. > > Which one is closer to true? > > GAO 06-165, November 2005: > Prevalence of False Contact Information for Registered Domain Names > http://www.gao.gov/new.items/d06165.pdf > > But you don't really care about competition or accuracy in this > case, do you? You tipped your hand a little too much with the > attempted redirection to "retrieval of privacy rights," whatever > that means. Be honest Milton, if you value personal privacy above > all other values, isn't falsification of whois just one acceptable > means to a greater end? > > >> But its difficult not to be struck with the tendency to blame >> problems >> that have nothing to do with competition on "competition." > > It's also not difficult to be struck by the behavior of someone who > only has one tool -- ala a child with a hammer. > They're the ones wandering around bashing everything the exact same > way, as if every other object in the world is a nail. > > TV > > P.S. we can talk about this at TPRC too, or at ARIN XXII if you're > also planning to be there. > > From bill at herrin.us Sun Aug 31 19:30:33 2008 From: bill at herrin.us (William Herrin) Date: Sun, 31 Aug 2008 19:30:33 -0400 Subject: [arin-ppml] The LRSA $100 fee... In-Reply-To: <7663C7E01D8E094989CA62F0B0D21CD901E0E574@SUEXCL-02.ad.syr.edu> References: <48B82BBE.80907@bogomips.com> <369EB04A0951824ABE7D8BAC67AF9BB40B2033D4@CL-S-EX-1.stanleyassociates.com> <7663C7E01D8E094989CA62F0B0D21CD901E0E56E@SUEXCL-02.ad.syr.edu> <03B49827-8327-430E-A6B9-7F45EA1D0EEE@pch.net> <7663C7E01D8E094989CA62F0B0D21CD901E0E574@SUEXCL-02.ad.syr.edu> Message-ID: <3c3e3fca0808311630s833e70fwf6f0c6ee00e3259e@mail.gmail.com> On Sun, Aug 31, 2008 at 12:34 PM, Milton L Mueller wrote: > DNS Whois? If you are referring to the efforts of individuals to > retrieve their privacy rights via proxy registration services, I don't > see that as a race to the bottom but as a significant response to human > rights concerns and legitimate demand. Milton, I have to strongly disagree with you here. Transparency is absolutely critical to the address management process, especially with the status of addresses as a diminishing resource. Without transparency, nothing even vaguely similar to ARIN's current management process can exist. Privacy and anonymity are forms of secrecy. They have an important role in our society, but secrecy is fundamentally incompatible with transparency. You can't have both. If folks need anonymous addresses they can get them from the ISPs' PA allocations. There's no call for secrecy at the international registry level. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mysidia at gmail.com Sun Aug 31 19:41:04 2008 From: mysidia at gmail.com (James Hess) Date: Sun, 31 Aug 2008 18:41:04 -0500 Subject: [arin-ppml] Privacy rights & IP number whois ( was Re: The LRSA $100 fee...) In-Reply-To: References: <48B82BBE.80907@bogomips.com> <369EB04A0951824ABE7D8BAC67AF9BB40B2033D4@CL-S-EX-1.stanleyassociates.com> <7663C7E01D8E094989CA62F0B0D21CD901E0E56E@SUEXCL-02.ad.syr.edu> <03B49827-8327-430E-A6B9-7F45EA1D0EEE@pch.net> <7663C7E01D8E094989CA62F0B0D21CD901E0E574@SUEXCL-02.ad.syr.edu> <99DAA789-91C2-43F7-9BB9-99FD7169E0F7@pch.net> Message-ID: <6eb799ab0808311641nc3a569eqbc20352cf9de47e9@mail.gmail.com> On Sun, Aug 31, 2008 at 3:24 PM, Tom Vest wrote: > 1. Do you think that the completeness and accuracy of current DNS > whois is the right standard for IP number whois? In my view there is no legitimate privacy right protected by allowing contact information to be witheld in _EITHER_ the case of DNS or IP whois. WHOIS proxy services should simply not be allowed by any registry. Privacy deals with private, personal information. The right to privacy is not a right to anonymity. There is no human right to anonymity. Once a member of the public knows your identity, they will in general share it with other people. If you are the CEO of a public corporation with 50% ownership; you cannot hide your identity as CEO, you will be identified in publicly available records created when the corporation is registered. What individuals do with domains and with IPs is no less a public manner than owning something like a public corporation. Once you connect your equipment to other people's equipment, or want to take possession of public resources like IP addresses and domain names, you are performing actions that are of concern to the public. There is no expectation of privacy. Just as if you claim ownership to a piece of land, you cannot expect that your identity as owner will be kept secret (in fact, it is a matter of public record) The public has an interest in being able to contact you directly with regard to your use of public resources, using all means that are ordinarily available, especially when those actions are detrimental (for example, you use a domain or IP for sending spam). More importantly, the public has the right to take action against you regarding serious abuses; including legal action, and informing others of your identity and the problem. The right of the public to do these things without hinderance is much more important than any semblence of anonymity that could be offered. If the information is kept hidden by proxy -- the information provided to the proxy is much more likely to be illegitimate falsified information; since the public does not see it, no one will be looking and reporting obvious falsities to the registrar. The increased likelihood of illegitimate information being filed practically eliminates usefulness of WHOIS, and the ability for operators to contact each other about connectivity and other problems that may arise between their networks. -- -J