From narten at us.ibm.com Fri Mar 4 00:53:03 2011 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 04 Mar 2011 00:53:03 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201103040553.p245r3rk005686@rotala.raleigh.ibm.com> Total of 104 messages in the last 7 days. script run at: Fri Mar 4 00:53:03 EST 2011 Messages | Bytes | Who --------+------+--------+----------+------------------------ 20.19% | 21 | 19.38% | 145268 | jcurran at arin.net 17.31% | 18 | 17.31% | 129732 | bensons at queuefull.net 11.54% | 12 | 11.58% | 86755 | owen at delong.com 7.69% | 8 | 7.31% | 54807 | tedm at ipinc.net 7.69% | 8 | 6.98% | 52316 | matthew at matthew.at 7.69% | 8 | 6.04% | 45253 | gbonser at seven.com 1.92% | 2 | 5.77% | 43271 | wesley.e.george at sprint.com 2.88% | 3 | 2.69% | 20124 | mysidia at gmail.com 2.88% | 3 | 2.18% | 16304 | jmaimon at chl.com 2.88% | 3 | 2.05% | 15391 | woody at pch.net 1.92% | 2 | 2.53% | 18980 | daniel_alexander at cable.comcast.com 1.92% | 2 | 2.47% | 18510 | frnkblk at iname.com 1.92% | 2 | 1.83% | 13740 | cgrundemann at gmail.com 1.92% | 2 | 1.72% | 12863 | bill at herrin.us 0.96% | 1 | 2.01% | 15034 | warren at wholesaleinternet.com 0.96% | 1 | 1.18% | 8857 | farmer at umn.edu 0.96% | 1 | 1.11% | 8340 | tvest at eyeconomics.com 0.96% | 1 | 1.07% | 8022 | narten at us.ibm.com 0.96% | 1 | 0.95% | 7135 | john at egh.com 0.96% | 1 | 0.89% | 6684 | keith at jcc.com 0.96% | 1 | 0.81% | 6099 | andrew.koch at gawul.net 0.96% | 1 | 0.77% | 5739 | kkargel at polartel.com 0.96% | 1 | 0.75% | 5600 | mueller at syr.edu 0.96% | 1 | 0.62% | 4660 | khelms at zcorum.com --------+------+--------+----------+------------------------ 100.00% | 104 |100.00% | 749484 | Total From joelja at bogus.com Mon Mar 7 23:41:23 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 07 Mar 2011 20:41:23 -0800 Subject: [arin-ppml] why hp bladeserver chassis have a sudden interest in thailand. Message-ID: <4D75B373.2040506@bogus.com> http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1299558177753+28353475&threadId=1471451 As a potentially cautionary tale for the squatting on unused pieces of address space either in your network or applications. drive slow (and filter 22 outgoing to 49.48.46.49 until you get new firmware) joel From Donald.Smith at qwest.com Tue Mar 8 07:46:09 2011 From: Donald.Smith at qwest.com (Smith, Donald) Date: Tue, 8 Mar 2011 05:46:09 -0700 Subject: [arin-ppml] why hp bladeserver chassis have a sudden interest in thailand. In-Reply-To: <4D75B373.2040506@bogus.com> References: <4D75B373.2040506@bogus.com> Message-ID: http://isc.sans.edu/diary/Outbound+SSH+Traffic+from+HP+Virtual+Connect+Blades/10498 It is going for a range of ips. We only see syn's never a response from the ips. Netflow sampling at 1/1k results from yesterday's SSH fun:) Countx1k ip 244 49.48.46.49 125 49.48.46.51 74 49.48.46.50 69 49.48.46.54 25 49.48.46.55 18 49.48.46.53 11 49.48.46.48 2 49.48.46.57 (coffee != sleep) & (!coffee == sleep) Donald.Smith at qwest.com ________________________________________ From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of Joel Jaeggli [joelja at bogus.com] Sent: Monday, March 07, 2011 9:41 PM To: NANOG; arin-ppml at arin.net Subject: [arin-ppml] why hp bladeserver chassis have a sudden interest in thailand. http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1299558177753+28353475&threadId=1471451 As a potentially cautionary tale for the squatting on unused pieces of address space either in your network or applications. drive slow (and filter 22 outgoing to 49.48.46.49 until you get new firmware) joel _______________________________________________ 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 communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From mcr at sandelman.ca Tue Mar 8 09:28:25 2011 From: mcr at sandelman.ca (Michael Richardson) Date: Tue, 08 Mar 2011 09:28:25 -0500 Subject: [arin-ppml] why hp bladeserver chassis have a sudden interest in thailand. In-Reply-To: <4D75B373.2040506@bogus.com> References: <4D75B373.2040506@bogus.com> Message-ID: <8674.1299594505@marajade.sandelman.ca> >>>>> "Joel" == Joel Jaeggli writes: Joel> http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1299558177753+28353475&threadId=1471451 Joel> As a potentially cautionary tale for the squatting on unused Joel> pieces of address space either in your network or Joel> applications. Thanks. This is a perfect example of why *VENDORS* need to be able to EASILY get pieces of identifiable NCN IPv6 space, and it needs to be simple enough for even a lowest level manager or intermediate programmer to get a piece. IP is used for more than the Internet, and this is a really good example of what happens when a programmer doesn't know what address space to use for their internal use. I call again upon ARIN to find a way to hand out /56s or /64s to anyone from a block which is identifiable (whois) and make this so simple that it will simpler than trying to make up a number like 49.48.46.49. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From info at arin.net Tue Mar 8 14:46:37 2011 From: info at arin.net (ARIN) Date: Tue, 08 Mar 2011 14:46:37 -0500 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA Message-ID: <4D76879D.4000508@arin.net> ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with the Policy Development Process. The ARIN Advisory Council (AC) will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. The AC invites everyone to comment on the 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. Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA Proposal Originator: Philip Smith co-authors: Alejandro Acosta, Nicolas Antoniello, S. Moonesamy, Douglas Onyango, Medel Ramirez, Masato Yamanishi Proposal Version: 1 Date: 8 March 2011 Proposal type: new Policy term: permanent Policy statement: The IANA shall establish a Recovered IPv4 Pool to be utilized post RIR IPv4 exhaustion. The Recovered IPv4 Pool will initially contain any fragments that may be left over in the IANA. It will also hold any space returned to the IANA by any other means. The Recovered IPv4 Pool will be administered by the IANA. It will contain: a. Any fragments left over in the IANA inventory after the last /8s of IPv4 space are delegated to the RIRs - The IANA inventory excludes "Special use IPv4 addresses" as defined in BCP 153 and any addresses allocated by the IANA for experimental use. b. Any IPv4 space returned to the IANA by any means. The Recovered IPv4 Pool will stay inactive until the first RIR has less than a total of a /9 in its inventory of IPv4 address space. When one of the RIRs declares it has less than a total of a /9 in its inventory, the Recovered IPv4 pool will be declared active, and IP addresses from the Recovered IPv4 Pool will be allocated as follows: a. Allocations from the IANA may begin once the pool is declared active. b. In each "IPv4 allocation period", each RIR will receive a single "IPv4 allocation unit" from the IANA. c. An "IPv4 allocation period" is defined as a 6-month period following 1 March or 1 September in each year. d. The IANA will calculate the size of the "IPv4 allocation unit" at the following times: - When the Recovered IPv4 Pool is first activated - At the beginning of each IPv4 allocation period To calculate the "IPv4 allocation unit" at these times, the IANA will use the following formula: IPv4 allocation unit = 1/5 of Recovered IPv4 pool, rounded down to the next CIDR (power-of-2) boundary. No RIR may get more than this calculation used to determine the IPv4 allocation unit even when they can justify a need for it. The minimum "IPv4 allocation unit" size will be a /24. If the calculation used to determine the IPv4 allocation unit results in a block smaller than a /24, the IANA will not distribute any addresses in that IPv4 allocation period. The IANA may make public announcements of IPv4 address transactions that occur under this policy. The IANA will make appropriate modifications to the "Internet Protocol V4 Address Space" page of the IANA website and may make announcements to its own appropriate announcement lists. The IANA announcements will be limited to which address ranges, the time of allocation, and to which Registry they have been allocated. Rationale: The policy provides a mechanism for the ongoing distribution of IPv4 address space, while removing the areas that have been problematic in previous attemts at this proposal. The proposal: - Permits regional variation in runout policy amongst RIRs to be accounted for in the distribution of the Recovered IPv4 Pool - Prevents the possibility of a single RIR being eligible to be allocated the entire Recovered IPv4 Pool in the first (and perhaps only) allocation period - Removes two areas of policy that have failed to reach agreement in previous attempts at this proposal: - How addresses should be placed in the Recovered IPv4 Pool - References to how transfers should or should not take place Timetable for implementation: Once consensus has been reached in each of the 5 RIR regions, the policy will be forwarded to ICANN for approval and then implemented by the IANA. From jeffrey.lyon at blacklotus.net Tue Mar 8 17:02:31 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 8 Mar 2011 17:02:31 -0500 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: <4D76879D.4000508@arin.net> References: <4D76879D.4000508@arin.net> Message-ID: I presume this was proposed by IANA? It looks like something that would result in IPv4 being shuffled out of the ARIN region and into developing regions and those who will be slow to adopt IPv6. For reasons that I cannot qualify at this moment, I feel that developing regions will also be much slower than the ARIN region to adopt IPv6. Jeff On Tue, Mar 8, 2011 at 2:46 PM, ARIN wrote: > ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation > mechanisms by the IANA > > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with the Policy > Development Process. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the 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. > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation > mechanisms by the IANA > > Proposal Originator: Philip Smith > ? co-authors: Alejandro Acosta, Nicolas Antoniello, S. Moonesamy, > ? ? ? ?Douglas Onyango, Medel Ramirez, Masato Yamanishi > > Proposal Version: 1 > > Date: 8 March 2011 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > ?The IANA shall establish a Recovered IPv4 Pool to be utilized post > ?RIR IPv4 exhaustion. ?The Recovered IPv4 Pool will initially contain > ?any fragments that may be left over in the IANA. ?It will also hold > ?any space returned to the IANA by any other means. > > ?The Recovered IPv4 Pool will be administered by the IANA. ?It will > ?contain: > > ? ?a. ?Any fragments left over in the IANA inventory after the last > ? ? ? ?/8s of IPv4 space are delegated to the RIRs > > ? ? ? - The IANA inventory excludes "Special use IPv4 addresses" as > ? ? ? ? defined in BCP 153 and any addresses allocated by the IANA > ? ? ? ? for experimental use. > > ? ?b. ?Any IPv4 space returned to the IANA by any means. > > ?The Recovered IPv4 Pool will stay inactive until the first RIR has > ?less than a total of a /9 in its inventory of IPv4 address space. > > ?When one of the RIRs declares it has less than a total of a /9 in > ?its inventory, the Recovered IPv4 pool will be declared active, and > ?IP addresses from the Recovered IPv4 Pool will be allocated as > ?follows: > > ? ?a. ?Allocations from the IANA may begin once the pool is declared > ? ? ? ?active. > > ? ?b. ?In each "IPv4 allocation period", each RIR will receive a > ? ? ? ?single "IPv4 allocation unit" from the IANA. > > ? ?c. ?An "IPv4 allocation period" is defined as a 6-month period > ? ? ? ?following 1 March or 1 September in each year. > > ? ?d. ?The IANA will calculate the size of the "IPv4 allocation unit" > ? ? ? ?at the following times: > > ? ? ? ?- When the Recovered IPv4 Pool is first activated > ? ? ? ?- At the beginning of each IPv4 allocation period > > ? ? ? ?To calculate the "IPv4 allocation unit" at these times, the > ? ? ? ?IANA will use the following formula: > > ? ? ? ? ? ?IPv4 allocation unit = 1/5 of Recovered IPv4 pool, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? rounded down to the next CIDR > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (power-of-2) boundary. > > ? ? ? ?No RIR may get more than this calculation used to determine > ? ? ? ?the IPv4 allocation unit even when they can justify a need for > ? ? ? ?it. > > ? ? ? ?The minimum "IPv4 allocation unit" size will be a /24. ?If the > ? ? ? ?calculation used to determine the IPv4 allocation unit results > ? ? ? ?in a block smaller than a /24, the IANA will not distribute > ? ? ? ?any addresses in that IPv4 allocation period. > > ? ?The IANA may make public announcements of IPv4 address > ? ?transactions that occur under this policy. ?The IANA will make > ? ?appropriate modifications to the "Internet Protocol V4 Address > ? ?Space" page of the IANA website and may make announcements to its > ? ?own appropriate announcement lists. ?The IANA announcements will > ? ?be limited to which address ranges, the time of allocation, and to > ? ?which Registry they have been allocated. > > Rationale: > > ? The policy provides a mechanism for the ongoing distribution of > ? IPv4 address space, while removing the areas that have been > ? problematic in previous attemts at this proposal. The proposal: > > ? ?- Permits regional variation in runout policy amongst RIRs to > ? ? ?be accounted for in the distribution of the Recovered IPv4 Pool > > ? ?- Prevents the possibility of a single RIR being eligible to > ? ? ?be allocated the entire Recovered IPv4 Pool in the first > ? ? ?(and perhaps only) allocation period > > ? ?- Removes two areas of policy that have failed to reach > ? ? ?agreement in previous attempts at this proposal: > > ? ? ? - How addresses should be placed in the Recovered IPv4 Pool > ? ? ? - References to how transfers should or should not take > ? ? ? ? place > > Timetable for implementation: > > ? Once consensus has been reached in each of the 5 RIR regions, the > ? policy will be forwarded to ICANN for approval and then implemented > ? by the IANA. > > > > _______________________________________________ > 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. > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From hannigan at gmail.com Tue Mar 8 17:09:32 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 8 Mar 2011 17:09:32 -0500 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: References: <4D76879D.4000508@arin.net> Message-ID: On Tue, Mar 8, 2011 at 5:02 PM, Jeffrey Lyon wrote: > I presume this was proposed by IANA? It looks like something that The IANA does not make policy proposals. They execute them. > would result in IPv4 being shuffled out of the ARIN region and into > developing regions and those who will be slow to adopt IPv6. For > reasons that I cannot qualify at this moment, I feel that developing > regions will also be much slower than the ARIN region to adopt IPv6. > There are a lot of things very wrong with this proposal not to mention the redistribution of "assets" in a manner that is not needs based. Best, -M< From gbonser at seven.com Tue Mar 8 17:44:58 2011 From: gbonser at seven.com (George Bonser) Date: Tue, 8 Mar 2011 14:44:58 -0800 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: References: <4D76879D.4000508@arin.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13FBE@RWC-EX1.corp.seven.com> > Behalf Of Jeffrey Lyon > Sent: Tuesday, March 08, 2011 2:03 PM > To: ARIN > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-137 Global Policy for post > exhaustion IPv4 allocation mechanisms by the IANA > > I presume this was proposed by IANA? It looks like something that > would result in IPv4 being shuffled out of the ARIN region and into > developing regions and those who will be slow to adopt IPv6. For > reasons that I cannot qualify at this moment, I feel that developing > regions will also be much slower than the ARIN region to adopt IPv6. > > Jeff As "developing regions" have a much smaller installed base of v4, I would think it might be just the opposite. From jeffrey.lyon at blacklotus.net Tue Mar 8 17:47:59 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 8 Mar 2011 17:47:59 -0500 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13FBE@RWC-EX1.corp.seven.com> References: <4D76879D.4000508@arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13FBE@RWC-EX1.corp.seven.com> Message-ID: George, I'm thinking in terms of future growth. Some small region might have little need for IP space of any type and then have out of control demand a few months down the line. Where ARIN region users might address this problem with IPv6, folks in developing regions might choose to use older or discarded gear and rely on IPv4. Best regards, Jeff On Tue, Mar 8, 2011 at 5:44 PM, George Bonser wrote: > >> Behalf Of Jeffrey Lyon >> Sent: Tuesday, March 08, 2011 2:03 PM >> To: ARIN >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] ARIN-prop-137 Global Policy for post >> exhaustion IPv4 allocation mechanisms by the IANA >> >> I presume this was proposed by IANA? It looks like something that >> would result in IPv4 being shuffled out of the ARIN region and into >> developing regions and those who will be slow to adopt IPv6. For >> reasons that I cannot qualify at this moment, I feel that developing >> regions will also be much slower than the ARIN region to adopt IPv6. >> >> Jeff > > As "developing regions" have a much smaller installed base of v4, I > would think it might be just the opposite. > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From hannigan at gmail.com Tue Mar 8 17:53:16 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 8 Mar 2011 17:53:16 -0500 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13FBE@RWC-EX1.corp.seven.com> References: <4D76879D.4000508@arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13FBE@RWC-EX1.corp.seven.com> Message-ID: Developing regions also have a much longer availability horizon than ARIN RIPE and APNIC. Its highly likely that those that have continued need during transition would be buying these addresses back from developing regions at magnitudes of order more cost. Best, -M< On 3/8/11, George Bonser wrote: > >> Behalf Of Jeffrey Lyon >> Sent: Tuesday, March 08, 2011 2:03 PM >> To: ARIN >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] ARIN-prop-137 Global Policy for post >> exhaustion IPv4 allocation mechanisms by the IANA >> >> I presume this was proposed by IANA? It looks like something that >> would result in IPv4 being shuffled out of the ARIN region and into >> developing regions and those who will be slow to adopt IPv6. For >> reasons that I cannot qualify at this moment, I feel that developing >> regions will also be much slower than the ARIN region to adopt IPv6. >> >> Jeff > > As "developing regions" have a much smaller installed base of v4, I > would think it might be just the opposite. > > _______________________________________________ > 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 george.herbert at gmail.com Wed Mar 9 00:21:37 2011 From: george.herbert at gmail.com (George Herbert) Date: Tue, 8 Mar 2011 21:21:37 -0800 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: <4D76879D.4000508@arin.net> References: <4D76879D.4000508@arin.net> Message-ID: On Tue, Mar 8, 2011 at 11:46 AM, ARIN wrote: >[...] > ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation > mechanisms by the IANA > > Proposal Originator: Philip Smith > ? co-authors: Alejandro Acosta, Nicolas Antoniello, S. Moonesamy, > ? ? ? ?Douglas Onyango, Medel Ramirez, Masato Yamanishi Philip and others - Can you explain your rationale and reasoning behind this proposal? Also, please address how a valid IANA policy would be appropriately created by an ARIN policy process... ? -- -george william herbert george.herbert at gmail.com From owen at delong.com Wed Mar 9 01:36:09 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 8 Mar 2011 22:36:09 -0800 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: References: <4D76879D.4000508@arin.net> Message-ID: Global policy (IANA policies) require the same policy proposal to be passed by all 5 RIR policy processes. This is the appropriate mechanism for doing so. Owen On Mar 8, 2011, at 9:21 PM, George Herbert wrote: > On Tue, Mar 8, 2011 at 11:46 AM, ARIN wrote: >> [...] >> ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation >> mechanisms by the IANA >> >> Proposal Originator: Philip Smith >> co-authors: Alejandro Acosta, Nicolas Antoniello, S. Moonesamy, >> Douglas Onyango, Medel Ramirez, Masato Yamanishi > > > Philip and others - > > Can you explain your rationale and reasoning behind this proposal? > > Also, please address how a valid IANA policy would be appropriately > created by an ARIN policy process... ? > > > -- > -george william herbert > george.herbert at gmail.com > _______________________________________________ > 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 Thu Mar 10 10:26:23 2011 From: farmer at umn.edu (David Farmer) Date: Thu, 10 Mar 2011 09:26:23 -0600 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: References: <4D76879D.4000508@arin.net> Message-ID: <4D78ED9F.3040701@umn.edu> On 3/8/11 23:21 CST, George Herbert wrote: > On Tue, Mar 8, 2011 at 11:46 AM, ARIN wrote: >> [...] >> ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation >> mechanisms by the IANA >> >> Proposal Originator: Philip Smith >> co-authors: Alejandro Acosta, Nicolas Antoniello, S. Moonesamy, >> Douglas Onyango, Medel Ramirez, Masato Yamanishi > > > Philip and others - > > Can you explain your rationale and reasoning behind this proposal? I won't speak for the authors, but this proposed global policy is known as APNIC-Prop-097 in the APNIC region and was discussed at the APNIC meeting two weeks ago in Hong Kong, and on the APNIC sig-policy mailing list. APNIC-Prop-097 was the second policy presented in the 4th session of APNIC's Policy SIG, on Thursday, Feb 24. It was proceeded by the presentation of APNIC-Prop-086 which is equilivant to ARIN-2010-10, which is an alternate proposal for dealing with many of the same issues. Once both proposals were presented, then a joint discussion of the two proposals followed. A link to the transcript from the 4th Policy SIG session; http://meetings.apnic.net/31/policy/transcript#session4 A link to the Audio from the 4th Policy SIG session; http://podcast.apnic.net/meetings/31/policy-sig-sess4.mp3 A link to the Video from the 4th Policy SIG session; http://streaming.apnic.net/meetings/31/policy-sig-sess4-hinted.mov Further, the APNIC sig-policy mailing list archives can be found at; http://mailman.apnic.net/mailing-lists/sig-policy/index.shtml > Also, please address how a valid IANA policy would be appropriately > created by an ARIN policy process... ? As has been stated, Global Policies are how IANA policies are created and all Global Policies must go through each of the five RIR policy processes. See the following for details; http://www.nro.net/documents/global-policy-development-process I hope that helps; -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From info at arin.net Thu Mar 10 10:28:44 2011 From: info at arin.net (ARIN) Date: Thu, 10 Mar 2011 10:28:44 -0500 Subject: [arin-ppml] Draft Policy ARIN-2011-6: Returned IPv4 Addresses - revised Message-ID: <4D78EE2C.3050501@arin.net> Draft Policy ARIN-2011-6 Returned IPv4 Addresses ARIN-2011-6 has been revised. This draft policy is open for discussion on this mailing list and will be on the agenda at the upcoming ARIN Public Policy Meeting in San Juan. ARIN-2011-6 is below and can be found at: https://www.arin.net/policy/proposals/2011_6.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2011-6 Returned IPv4 Addresses Date: 10 March 2011 Policy statement: 4.1.9 Returned IPv4 Addresses Except where otherwise directed by policy; all IPv4 addresses returned to, recovered, or revoked by ARIN will be made available for allocation or assignment in the ARIN region as quickly as practicable. Rationale: Adopting this proposal will result in the clarification of the status of returned IPv4 addresses. IPv4 address resources should not sit idle due to lack of policy clarity. Timetable for implementation: Immediately From rudi.daniel at gmail.com Thu Mar 10 12:13:19 2011 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Thu, 10 Mar 2011 13:13:19 -0400 Subject: [arin-ppml] OAM v MPLS Message-ID: > > I am trying to understand the significance of the ITU's decision to promote > OAM as opposed to the IETF's MPLS as a networking standard. > Any comments RD ------------------------------------------------------------------ > > Message: 1 > Date: Thu, 10 Mar 2011 09:26:23 -0600 > From: David Farmer > To: George Herbert > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-137 Global Policy for post > exhaustion IPv4 allocation mechanisms by the IANA > Message-ID: <4D78ED9F.3040701 at umn.edu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 3/8/11 23:21 CST, George Herbert wrote: > > On Tue, Mar 8, 2011 at 11:46 AM, ARIN wrote: > >> [...] > >> ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation > >> mechanisms by the IANA > >> > >> Proposal Originator: Philip Smith > >> co-authors: Alejandro Acosta, Nicolas Antoniello, S. Moonesamy, > >> Douglas Onyango, Medel Ramirez, Masato Yamanishi > > > > > > Philip and others - > > > > Can you explain your rationale and reasoning behind this proposal? > > I won't speak for the authors, but this proposed global policy is known > as APNIC-Prop-097 in the APNIC region and was discussed at the APNIC > meeting two weeks ago in Hong Kong, and on the APNIC sig-policy mailing > list. APNIC-Prop-097 was the second policy presented in the 4th session > of APNIC's Policy SIG, on Thursday, Feb 24. It was proceeded by the > presentation of APNIC-Prop-086 which is equilivant to ARIN-2010-10, > which is an alternate proposal for dealing with many of the same issues. > Once both proposals were presented, then a joint discussion of the two > proposals followed. > > A link to the transcript from the 4th Policy SIG session; > http://meetings.apnic.net/31/policy/transcript#session4 > > A link to the Audio from the 4th Policy SIG session; > http://podcast.apnic.net/meetings/31/policy-sig-sess4.mp3 > > A link to the Video from the 4th Policy SIG session; > http://streaming.apnic.net/meetings/31/policy-sig-sess4-hinted.mov > > Further, the APNIC sig-policy mailing list archives can be found at; > http://mailman.apnic.net/mailing-lists/sig-policy/index.shtml > > > Also, please address how a valid IANA policy would be appropriately > > created by an ARIN policy process... ? > > As has been stated, Global Policies are how IANA policies are created > and all Global Policies must go through each of the five RIR policy > processes. > > See the following for details; > http://www.nro.net/documents/global-policy-development-process > > I hope that helps; > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > > > ------------------------------ > > Message: 2 > Date: Thu, 10 Mar 2011 10:28:44 -0500 > From: ARIN > To: arin-ppml at arin.net > Subject: [arin-ppml] Draft Policy ARIN-2011-6: Returned IPv4 Addresses > - revised > Message-ID: <4D78EE2C.3050501 at arin.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Draft Policy ARIN-2011-6 > Returned IPv4 Addresses > > ARIN-2011-6 has been revised. This draft policy is open for discussion > on this mailing list and will be on the agenda at the upcoming ARIN > Public Policy Meeting in San Juan. > > ARIN-2011-6 is below and can be found at: > https://www.arin.net/policy/proposals/2011_6.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy ARIN-2011-6 > Returned IPv4 Addresses > > Date: 10 March 2011 > > Policy statement: > > 4.1.9 Returned IPv4 Addresses > > Except where otherwise directed by policy; all IPv4 addresses returned > to, recovered, or revoked by ARIN will be made available for allocation > or assignment in the ARIN region as quickly as practicable. > > Rationale: > > Adopting this proposal will result in the clarification of the status of > returned IPv4 addresses. IPv4 address resources should not sit idle due > to lack of policy clarity. > > Timetable for implementation: Immediately > > > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 69, Issue 5 > **************************************** > -- Rudi Daniel *danielcharles consulting **1-784 498 8277 * * * -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Thu Mar 10 13:08:50 2011 From: jcurran at arin.net (John Curran) Date: Thu, 10 Mar 2011 18:08:50 +0000 Subject: [arin-ppml] OAM v MPLS In-Reply-To: References: Message-ID: <97B4F73D-72B8-46D2-B94B-D65BAB41A3C7@corp.arin.net> > On Mar 10, 2011, at 12:13 PM, Rudolph Daniel wrote: > > I am trying to understand the significance of the ITU's decision to promote OAM as opposed to the IETF's MPLS as a networking standard. > Any comments Rudi - That's probably a little too far from PPML's charter to be a good topic for this mailing list... There's quite a bit of existing discussion of the MPLS OAM difference of opinion over on LightReading in this article: and the associated links that follow the article. The main IETF mailing list also has some discussion of the topic. Short version is that the IETF and ITU agreed on an approach to a single OAM standard for MPLS, and the IETF has been working on it (albeit slower than expected) and it appears that some of the vendors in the ITU community continued to ship product based on the ITU version in the meantime. This ultimately came to a head last month, when the ITU Study Group 15 decided to adopt the ITU original proposal despite its earlier agreement with the IETF to work on a single joint standard. Implications could include interoperability issues for large-multivendor MPLS networks, and general concern about the strength of commitment behind any other agreements that the ITU might enter in the future. This is the aspect of the dispute that is disturbing for ARIN, and requires careful thought when considering offers from the ITU to "work together" on any Internet number resource activities. FYI, /John John Curran President and CEO ARIN From rudi.daniel at gmail.com Thu Mar 10 13:14:27 2011 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Thu, 10 Mar 2011 14:14:27 -0400 Subject: [arin-ppml] OAM v MPLS In-Reply-To: <97B4F73D-72B8-46D2-B94B-D65BAB41A3C7@corp.arin.net> References: <97B4F73D-72B8-46D2-B94B-D65BAB41A3C7@corp.arin.net> Message-ID: With thanks.... RD On Thu, Mar 10, 2011 at 2:08 PM, John Curran wrote: > > On Mar 10, 2011, at 12:13 PM, Rudolph Daniel wrote: > > > > I am trying to understand the significance of the ITU's decision to > promote OAM as opposed to the IETF's MPLS as a networking standard. > > Any comments > > Rudi - > > That's probably a little too far from PPML's charter to be a good topic > for > this mailing list... There's quite a bit of existing discussion of the > MPLS > OAM difference of opinion over on LightReading in this article: > and > the associated links that follow the article. The main IETF mailing list > also has some discussion of the topic. > > Short version is that the IETF and ITU agreed on an approach to a single > OAM standard for MPLS, and the IETF has been working on it (albeit slower > than expected) and it appears that some of the vendors in the ITU > community > continued to ship product based on the ITU version in the meantime. This > ultimately came to a head last month, when the ITU Study Group 15 decided > to adopt the ITU original proposal despite its earlier agreement with the > IETF > to work on a single joint standard. Implications could include > interoperability > issues for large-multivendor MPLS networks, and general concern about the > strength of commitment behind any other agreements that the ITU might > enter > in the future. This is the aspect of the dispute that is disturbing for > ARIN, and > requires careful thought when considering offers from the ITU to "work > together" > on any Internet number resource activities. > > FYI, > /John > > John Curran > President and CEO > ARIN > > > -- Rudi Daniel *danielcharles consulting **1-784 498 8277 * * * -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffrey.lyon at blacklotus.net Thu Mar 10 13:49:28 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 10 Mar 2011 13:49:28 -0500 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: <4D78ED9F.3040701@umn.edu> References: <4D76879D.4000508@arin.net> <4D78ED9F.3040701@umn.edu> Message-ID: On Thu, Mar 10, 2011 at 10:26 AM, David Farmer wrote: > On 3/8/11 23:21 CST, George Herbert wrote: >> >> On Tue, Mar 8, 2011 at 11:46 AM, ARIN ?wrote: >>> >>> [...] >>> ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation >>> mechanisms by the IANA >>> >>> Proposal Originator: Philip Smith >>> ? co-authors: Alejandro Acosta, Nicolas Antoniello, S. Moonesamy, >>> ? ? ? ?Douglas Onyango, Medel Ramirez, Masato Yamanishi >> >> >> Philip and others - >> >> Can you explain your rationale and reasoning behind this proposal? > > I won't speak for the authors, but this proposed global policy is known as > APNIC-Prop-097 in the APNIC region and was discussed at the APNIC meeting > two weeks ago in Hong Kong, and on the APNIC sig-policy mailing list. > ?APNIC-Prop-097 was the second policy presented in the 4th session of > APNIC's Policy SIG, on Thursday, Feb 24. ?It was proceeded by the > presentation of APNIC-Prop-086 which is equilivant to ARIN-2010-10, which is > an alternate proposal for dealing with many of the same issues. ?Once both > proposals were presented, then a joint discussion of the two proposals > followed. > > A link to the transcript from the 4th Policy SIG session; > http://meetings.apnic.net/31/policy/transcript#session4 > > A link to the Audio from the 4th Policy SIG session; > http://podcast.apnic.net/meetings/31/policy-sig-sess4.mp3 > > A link to the Video from the 4th Policy SIG session; > http://streaming.apnic.net/meetings/31/policy-sig-sess4-hinted.mov > > Further, the APNIC sig-policy mailing list archives can be found at; > http://mailman.apnic.net/mailing-lists/sig-policy/index.shtml > >> Also, please address how a valid IANA policy would be appropriately >> created by an ARIN policy process... ? > > As has been stated, Global Policies are how IANA policies are created and > all Global Policies must go through each of the five RIR policy processes. > > See the following for details; > http://www.nro.net/documents/global-policy-development-process > > I hope that helps; > > -- > =============================================== > David Farmer ? ? ? ? ? ? ? Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE ? ? ?Phone: 612-626-0815 > Minneapolis, MN 55414-3029 ? Cell: 612-812-9952 > =============================================== > _______________________________________________ > 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 the APNIC transcript: -- Why did we do this? Without this policy, any space returned to the IANA would be stranded, because we have triggered the allocation of the last /8s from IANA, it's questionable as to what would happen to returned space, because there's no current mechanism for IANA to distribute space to the RIRs, especially space that's smaller than a /8. -- Is this factual, or does APNIC have a policy requiring the return of unused space to IANA? Would IANA even accept returns at this point? Additionally: -- As evidence to that, Interop returned almost a full /8 and their press release is quite clear, I'll read it from it here: "After the hold period, ARIN will follow global policy at that time and return it to the global free pool or distribute the space to those organizations in the ARIN region with documented need." So, I think it's very clear that if there is a global policy in place that allows ARIN to return this space to IANA, they will do that, if they think that's the right thing to do. -- I for one, do not. -- Basically, it's been adopted in the ARIN region and is under discussion here and in the others three regions. -- It has? -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From bill at herrin.us Thu Mar 10 14:20:43 2011 From: bill at herrin.us (William Herrin) Date: Thu, 10 Mar 2011 14:20:43 -0500 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: References: <4D76879D.4000508@arin.net> <4D78ED9F.3040701@umn.edu> Message-ID: On Thu, Mar 10, 2011 at 1:49 PM, Jeffrey Lyon wrote: > >From the APNIC transcript: > -- > As evidence to that, Interop returned almost a full /8 and their press > release is quite clear, I'll read it from it here: "After the hold > period, ARIN will follow global policy at that time and return it to > the global free pool or distribute the space to those organizations in > the ARIN region with documented need." So, I think it's very clear > that if there is a global policy in place that allows ARIN to return > this space to IANA, they will do that, if they think that's the right > thing to do. > -- > > I for one, do not. That's why we need 2011-6 to spell it out: addresses recovered by ARIN are not returned to IANA. Which is in turn why the the current text of 2011-6 is unacceptable. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From hannigan at gmail.com Thu Mar 10 14:25:23 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 10 Mar 2011 14:25:23 -0500 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: References: <4D76879D.4000508@arin.net> <4D78ED9F.3040701@umn.edu> Message-ID: On Thu, Mar 10, 2011 at 1:49 PM, Jeffrey Lyon wrote: [ clip ] > >From the APNIC transcript: > > -- > Why did we do this? Without this policy, any space returned to the > IANA would be stranded, because we have triggered the allocation of > the last /8s from IANA, it's questionable as to what would happen to > returned space, because there's no current mechanism for IANA to > distribute space to the RIRs, especially space that's smaller than a > /8. > -- > > Is this factual, or does APNIC have a policy requiring the return of > unused space to IANA? Would IANA even accept returns at this point? > Additionally: APNIC has no requirement to return address to IANA. Future actions directing the IANA specifically related to this issue are non existent. That means that between the IANA and the NRO, we could end up with completely unpredictable and undesirable results. > As evidence to that, Interop returned almost a full /8 and their press > release is quite clear, I'll read it from it here: "After the hold > period, ARIN will follow global policy at that time and return it to > the global free pool or distribute the space to those organizations in > the ARIN region with documented need." So, I think it's very clear > that if there is a global policy in place that allows ARIN to return > this space to IANA, they will do that, if they think that's the right > thing to do. > -- > > I for one, do not. > I highly doubt that any address space will ever be returned to the IANA. Aside from that, the proposal is weak in many areas and is unlikely to reach consensus in the ARIN region anyhow and IMHO. We also already have adopted a proposal to address this issue. It's unfortunate that at least one region opted for politics over cooperation hence here we are again. What I find most interesting with this latest proposal is that need seems to be rapidly collapsing as a concrete basis for continued allocations. YMMV. Best, -M< From george.herbert at gmail.com Thu Mar 10 16:42:39 2011 From: george.herbert at gmail.com (George Herbert) Date: Thu, 10 Mar 2011 13:42:39 -0800 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: References: <4D76879D.4000508@arin.net> Message-ID: Thanks for everyone who informed me on this point. I'm new to arin-ppml and this particular detail wasn't something I picked up over the decades on nanog and other lists. On Tue, Mar 8, 2011 at 10:36 PM, Owen DeLong wrote: > Global policy (IANA policies) require the same policy proposal > to be passed by all 5 RIR policy processes. This is the appropriate > mechanism for doing so. > > Owen > > On Mar 8, 2011, at 9:21 PM, George Herbert wrote: > >> On Tue, Mar 8, 2011 at 11:46 AM, ARIN wrote: >>> [...] >>> ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation >>> mechanisms by the IANA >>> >>> Proposal Originator: Philip Smith >>> ? co-authors: Alejandro Acosta, Nicolas Antoniello, S. Moonesamy, >>> ? ? ? ?Douglas Onyango, Medel Ramirez, Masato Yamanishi >> >> >> Philip and others - >> >> Can you explain your rationale and reasoning behind this proposal? >> >> Also, please address how a valid IANA policy would be appropriately >> created by an ARIN policy process... ? >> >> >> -- >> -george william herbert >> george.herbert at gmail.com >> _______________________________________________ >> 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. > > -- -george william herbert george.herbert at gmail.com From maxlarson.henry at transversal.ht Thu Mar 10 18:07:50 2011 From: maxlarson.henry at transversal.ht (maxlarson.henry at transversal.ht) Date: Thu, 10 Mar 2011 23:07:50 +0000 Subject: [arin-ppml] ARIN-prop-137 Global Policy for poste exhaustionIPv4 allocation mechanisms by the IANA In-Reply-To: References: <4D76879D.4000508@arin.net> Message-ID: <1464153966-1299798303-cardhu_decombobulator_blackberry.rim.net-254929392-@bda2190.bisx.prod.on.blackberry> Envoy? par mon BlackBerry de Digicel -----Original Message----- From: George Herbert Sender: arin-ppml-bounces at arin.net Date: Thu, 10 Mar 2011 13:42:39 To: Owen DeLong Cc: Subject: Re: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA Thanks for everyone who informed me on this point. I'm new to arin-ppml and this particular detail wasn't something I picked up over the decades on nanog and other lists. On Tue, Mar 8, 2011 at 10:36 PM, Owen DeLong wrote: > Global policy (IANA policies) require the same policy proposal > to be passed by all 5 RIR policy processes. This is the appropriate > mechanism for doing so. > > Owen > > On Mar 8, 2011, at 9:21 PM, George Herbert wrote: > >> On Tue, Mar 8, 2011 at 11:46 AM, ARIN wrote: >>> [...] >>> ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation >>> mechanisms by the IANA >>> >>> Proposal Originator: Philip Smith >>> ? co-authors: Alejandro Acosta, Nicolas Antoniello, S. Moonesamy, >>> ? ? ? ?Douglas Onyango, Medel Ramirez, Masato Yamanishi >> >> >> Philip and others - >> >> Can you explain your rationale and reasoning behind this proposal? >> >> Also, please address how a valid IANA policy would be appropriately >> created by an ARIN policy process... ? >> >> >> -- >> -george william herbert >> george.herbert at gmail.com >>_______________________________________________ >> 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. > > -- -george william herbert george.herbert at gmail.com _______________________________________________ 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 narten at us.ibm.com Fri Mar 11 00:53:02 2011 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 11 Mar 2011 00:53:02 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201103110553.p2B5r20O022372@rotala.raleigh.ibm.com> Total of 22 messages in the last 7 days. script run at: Fri Mar 11 00:53:02 EST 2011 Messages | Bytes | Who --------+------+--------+----------+------------------------ 13.64% | 3 | 16.90% | 26845 | jeffrey.lyon at blacklotus.net 9.09% | 2 | 17.77% | 28227 | rudi.daniel at gmail.com 13.64% | 3 | 11.71% | 18595 | hannigan at gmail.com 9.09% | 2 | 8.55% | 13575 | info at arin.net 9.09% | 2 | 7.49% | 11902 | george.herbert at gmail.com 4.55% | 1 | 4.37% | 6945 | farmer at umn.edu 4.55% | 1 | 4.30% | 6836 | maxlarson.henry at transversal.ht 4.55% | 1 | 4.20% | 6672 | donald.smith at qwest.com 4.55% | 1 | 4.06% | 6443 | narten at us.ibm.com 4.55% | 1 | 3.89% | 6172 | bill at herrin.us 4.55% | 1 | 3.72% | 5916 | owen at delong.com 4.55% | 1 | 3.72% | 5903 | jcurran at arin.net 4.55% | 1 | 3.40% | 5409 | mcr at sandelman.ca 4.55% | 1 | 3.10% | 4931 | gbonser at seven.com 4.55% | 1 | 2.82% | 4485 | joelja at bogus.com --------+------+--------+----------+------------------------ 100.00% | 22 |100.00% | 158856 | Total From mpetach at netflight.com Sun Mar 13 15:37:37 2011 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 13 Mar 2011 12:37:37 -0700 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: <4D76879D.4000508@arin.net> References: <4D76879D.4000508@arin.net> Message-ID: On Tue, Mar 8, 2011 at 11:46 AM, ARIN wrote: > ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation > mechanisms by the IANA As this policy does not in any way state what addresses must or must not be returned to IANA, it focuses only on ensuring that any addresses that are returned to IANA are given out in a fair and equitable manner, I find myself to be in SUPPORT of this proposal. Matt From jeffrey.lyon at blacklotus.net Sun Mar 13 15:45:44 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sun, 13 Mar 2011 15:45:44 -0400 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: References: <4D76879D.4000508@arin.net> Message-ID: .. but they shouldn't be returned to IANA so we don't need a mechanism for ensuring that anything happens when, in theory, the undesirable occurs. I'm still opposed. Best regards, Jeff On Sun, Mar 13, 2011 at 3:37 PM, Matthew Petach wrote: > On Tue, Mar 8, 2011 at 11:46 AM, ARIN wrote: >> ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation >> mechanisms by the IANA > > As this policy does not in any way state what addresses must > or must not be returned to IANA, it focuses only on ensuring > that any addresses that are returned to IANA are given out in > a fair and equitable manner, I find myself to be in SUPPORT > of this proposal. > > Matt > _______________________________________________ > 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. > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From mpetach at netflight.com Sun Mar 13 15:55:14 2011 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 13 Mar 2011 12:55:14 -0700 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: References: <4D76879D.4000508@arin.net> Message-ID: On Sun, Mar 13, 2011 at 12:45 PM, Jeffrey Lyon wrote: > .. but they shouldn't be returned to IANA so we don't need a mechanism > for ensuring that anything happens when, in theory, the undesirable > occurs. > > I'm still opposed. > > Best regards, Jeff *heh* So, you'd rather any addresses that happen to end up back with IANA get stranded there in perpetuity? *shrug* I guess that's one more push for people to move to v6 instead. ;-P Matt From joelja at bogus.com Sun Mar 13 16:06:08 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 13 Mar 2011 13:06:08 -0700 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: References: <4D76879D.4000508@arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13FBE@RWC-EX1.corp.seven.com> Message-ID: <4D7D23B0.2030205@bogus.com> On 3/8/11 2:47 PM, Jeffrey Lyon wrote: > George, > > I'm thinking in terms of future growth. Some small region might have > little need for IP space of any type and then have out of control > demand a few months down the line. Where ARIN region users might > address this problem with IPv6, folks in developing regions might > choose to use older or discarded gear and rely on IPv4. we've got 2 billion more end-users to number before we have pairty with the pstn... They aren't in the US and Western Europe. > Best regards, Jeff > From jeffrey.lyon at blacklotus.net Sun Mar 13 16:08:12 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sun, 13 Mar 2011 16:08:12 -0400 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: References: <4D76879D.4000508@arin.net> Message-ID: No, I would like to take whatever measures necessary to make sure that IANA never touches IPv4 space, ever again. Jeff On Sun, Mar 13, 2011 at 3:55 PM, Matthew Petach wrote: > On Sun, Mar 13, 2011 at 12:45 PM, Jeffrey Lyon > wrote: >> .. but they shouldn't be returned to IANA so we don't need a mechanism >> for ensuring that anything happens when, in theory, the undesirable >> occurs. >> >> I'm still opposed. >> >> Best regards, Jeff > > *heh* > So, you'd rather any addresses that happen to end up back with > IANA get stranded there in perpetuity? > > *shrug* ?I guess that's one more push for people to move to v6 instead. ?;-P > > Matt > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From info at arin.net Mon Mar 14 17:18:25 2011 From: info at arin.net (ARIN) Date: Mon, 14 Mar 2011 17:18:25 -0400 Subject: [arin-ppml] ARIN-prop-138 IPv6 Size Category Alignment Message-ID: <4D7E8621.1030807@arin.net> ARIN-prop-138 IPv6 Size Category Alignment ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with the Policy Development Process. The ARIN Advisory Council (AC) will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. The AC invites everyone to comment on the 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. Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-138 IPv6 Size Category Alignment Proposal Originator: Charles Gucker Proposal Version: 1.0 Date: 14 March 2011 Proposal type: modify Policy term: permanent Policy statement: For IPv6 ISP Classification, the "Size Category" shall be determined based on the following schedule: X-small /32 or smaller Small /31 to /30 Medium /29 to /27 Large /26 to /24 X-large /23 to /20 XX-large /20 and larger Rationale: Since the adoption of ARIN Policy 2001-4 and the introduction of the IPv6 fee schedule there has existed a discontinuity between the fee schedule and the policy language. As the policy is written, "6.5.1.1. Initial allocation size Organizations that meet at least one of the following criteria are eligible to receive a minimum allocation of /32. ?", However, the fee schedule currently states that an ISP within the X-Small category be allocated "smaller than /40" and the Small category of "/40 to /32". As a result, with current policy an existing ISP within the X-Small category, when requesting the minimum IPv6 allocation, would have to jump Size categories to receive their IPv6 Allocation. With the IANA IPv4 runout behind us, it is important to eliminate all hurdles for existing Organizations to receive IPv6 allocations, even the X-Small. This proposal is intended to do just that by aligning the Size Category with current policy. Timetable for implementation: immediate From rcarpen at network1.net Mon Mar 14 17:43:13 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Mon, 14 Mar 2011 17:43:13 -0400 (EDT) Subject: [arin-ppml] ARIN-prop-138 IPv6 Size Category Alignment In-Reply-To: <4D7E8621.1030807@arin.net> Message-ID: <37884c97-7cb4-4892-b2c9-3323b3502654@zimbra.network1.net> I think I'd rather see it line up better with ARIN-2011-3: X-small /35 or smaller Small /34 to /31 Medium /30 to /27 Large /26 to /23 X-large /22 to /19 XX-large /18 and larger This places the proposed nibble-boundary cutoffs (36,32,28,24,20) in the middle of each range (off by 1, but that can't be helped). Or maybe even shift them all 1 bit, so that people are encouraged to bump up to a nibble boundary if they already have an odd allocation: X-small /36 or smaller Small /35 to /32 Medium /31 to /28 Large /27 to /24 X-large /23 to /20 XX-large /19 and larger -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 ---- ----- Original Message ----- > ARIN-prop-138 IPv6 Size Category Alignment > > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with the Policy > Development Process. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be > extended > to the subsequent regularly scheduled meeting). The AC will decide > how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the 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. > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-138 IPv6 Size Category Alignment > > Proposal Originator: Charles Gucker > > Proposal Version: 1.0 > > Date: 14 March 2011 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > For IPv6 ISP Classification, the "Size Category" shall be determined > based on the following schedule: > > X-small /32 or smaller > Small /31 to /30 > Medium /29 to /27 > Large /26 to /24 > X-large /23 to /20 > XX-large /20 and larger > > Rationale: > > Since the adoption of ARIN Policy 2001-4 and the introduction of the > IPv6 fee schedule there has existed a discontinuity between the fee > schedule and the policy language. As the policy is written, > "6.5.1.1. Initial allocation size Organizations that meet at least > one > of the following criteria are eligible to receive a minimum > allocation > of /32. ?", However, the fee schedule currently states that an ISP > within the X-Small category be allocated "smaller than /40" and the > Small category of "/40 to /32". As a result, with current policy an > existing ISP within the X-Small category, when requesting the minimum > IPv6 allocation, would have to jump Size categories to receive their > IPv6 Allocation. With the IANA IPv4 runout behind us, it is > important > to eliminate all hurdles for existing Organizations to receive IPv6 > allocations, even the X-Small. This proposal is intended to do just > that by aligning the Size Category with current policy. > > 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 mksmith at adhost.com Mon Mar 14 17:59:16 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Mon, 14 Mar 2011 21:59:16 +0000 Subject: [arin-ppml] ARIN-prop-138 IPv6 Size Category Alignment In-Reply-To: <4D7E8621.1030807@arin.net> References: <4D7E8621.1030807@arin.net> Message-ID: I don't support this proposal as written. I could see putting the /48 and greater in the X-SMALL to give some balance between smallest allocations in v4 and v6, but I think the /32 belongs in the SMALL size as it is presently. So that would leave something like: X-small /48 or smaller Small /31 to /47 Medium /29 to /27 Large /26 to /24 X-large /23 to /20 XX-large /20 and larger I'm not sure that the boundaries have to be exact - it's really an O&M function to specify the "size" of a netblock, specifically for billing purposes. Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of ARIN > Sent: Monday, March 14, 2011 2:18 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] ARIN-prop-138 IPv6 Size Category Alignment > > ARIN-prop-138 IPv6 Size Category Alignment > > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with the Policy > Development Process. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the 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. > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-138 IPv6 Size Category Alignment > > Proposal Originator: Charles Gucker > > Proposal Version: 1.0 > > Date: 14 March 2011 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > For IPv6 ISP Classification, the "Size Category" shall be determined > based on the following schedule: > > X-small /32 or smaller > Small /31 to /30 > Medium /29 to /27 > Large /26 to /24 > X-large /23 to /20 > XX-large /20 and larger > > Rationale: > > Since the adoption of ARIN Policy 2001-4 and the introduction of the > IPv6 fee schedule there has existed a discontinuity between the fee > schedule and the policy language. As the policy is written, > "6.5.1.1. Initial allocation size Organizations that meet at least one > of the following criteria are eligible to receive a minimum allocation > of /32. ...", However, the fee schedule currently states that an ISP > within the X-Small category be allocated "smaller than /40" and the > Small category of "/40 to /32". As a result, with current policy an > existing ISP within the X-Small category, when requesting the minimum > IPv6 allocation, would have to jump Size categories to receive their > IPv6 Allocation. With the IANA IPv4 runout behind us, it is important > to eliminate all hurdles for existing Organizations to receive IPv6 > allocations, even the X-Small. This proposal is intended to do just > that by aligning the Size Category with current policy. > > 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 farmer at umn.edu Mon Mar 14 18:05:13 2011 From: farmer at umn.edu (David Farmer) Date: Mon, 14 Mar 2011 17:05:13 -0500 Subject: [arin-ppml] ARIN-prop-138 IPv6 Size Category Alignment In-Reply-To: <4D7E8621.1030807@arin.net> References: <4D7E8621.1030807@arin.net> Message-ID: <4D7E9119.1010908@umn.edu> Charles, There is already an attempt to deal with this issue in Draft Policy ARIN-2011-3: Better IPv6 Allocations for ISPs, in section 6.5.2.1(b), by optionally allowing an ISP to request a /36 if they wish to retain the X-small status in the IPv6 world. This Draft Policy will be up for discussion at the San Jaun meeting. Do you object to that way of dealing with this issue? If so, why? The problem I with this proposal is that sets the default billing size for all ISPs to the X-small size, which has the probable side effect of a significant impact on ARIN's revenue from fees in the long term. Where as the approach taken in 2011-3 allows X-small ISPs a choice between a smaller allocation (/36) at the lower rate or the normal /32 at the normal rate. In theory this should be more or less revenue neutral for ARIN. While not accidentally imposing a rate hike on X-small ISPs. While the fee structure itself is not really a policy issue. There is an undeniable interaction between the minimum allocation size, which is a policy issue, and the fee structure, which is not, therefore the two issues can not be completely and cleanly separated. However, if we don't to come to consensus on 2011-3 then we should probably deal with this as a separate issue and take up this proposal and limit it to this issue only. On 3/14/11 16:18 CDT, ARIN wrote: > ARIN-prop-138 IPv6 Size Category Alignment > > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with the Policy > Development Process. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the 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. > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-138 IPv6 Size Category Alignment > > Proposal Originator: Charles Gucker > > Proposal Version: 1.0 > > Date: 14 March 2011 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > For IPv6 ISP Classification, the "Size Category" shall be determined > based on the following schedule: > > X-small /32 or smaller > Small /31 to /30 > Medium /29 to /27 > Large /26 to /24 > X-large /23 to /20 > XX-large /20 and larger > > Rationale: > > Since the adoption of ARIN Policy 2001-4 and the introduction of the > IPv6 fee schedule there has existed a discontinuity between the fee > schedule and the policy language. As the policy is written, > "6.5.1.1. Initial allocation size Organizations that meet at least one > of the following criteria are eligible to receive a minimum allocation > of /32. ?", However, the fee schedule currently states that an ISP > within the X-Small category be allocated "smaller than /40" and the > Small category of "/40 to /32". As a result, with current policy an > existing ISP within the X-Small category, when requesting the minimum > IPv6 allocation, would have to jump Size categories to receive their > IPv6 Allocation. With the IANA IPv4 runout behind us, it is important > to eliminate all hurdles for existing Organizations to receive IPv6 > allocations, even the X-Small. This proposal is intended to do just > that by aligning the Size Category with current policy. > > Timetable for implementation: immediate -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From cgucker at onesc.net Mon Mar 14 18:12:23 2011 From: cgucker at onesc.net (Charles Gucker) Date: Mon, 14 Mar 2011 18:12:23 -0400 Subject: [arin-ppml] ARIN-prop-138 IPv6 Size Category Alignment In-Reply-To: References: <4D7E8621.1030807@arin.net> Message-ID: On Mon, Mar 14, 2011 at 5:59 PM, Michael K. Smith - Adhost wrote: > I don't support this proposal as written. ?I could see putting the /48 and greater in the X-SMALL to give some balance between smallest allocations in v4 and v6, but I think the /32 belongs in the SMALL size as it is presently. ?So that would leave something like: Keep in mind, this is for ISPs, not end-users. The global consensus has been /32's for ISPs, which is where this originated from. > > X-small ? ?/48 or smaller > Small ? ? ?/31 to /47 > Medium ? ? /29 to /27 > Large ? ? ?/26 to /24 > X-large ? ?/23 to /20 > XX-large ? ? ? ? ?/20 and larger > > I'm not sure that the boundaries have to be exact - it's really an O&M function to specify the "size" of a netblock, specifically for billing purposes. I really took a swag at this and tried to keep it as clean as possible. It's an existing model using IPv4 that was being followed. charles From matthew at matthew.at Mon Mar 14 18:15:18 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 14 Mar 2011 15:15:18 -0700 Subject: [arin-ppml] ARIN-prop-138 IPv6 Size Category Alignment In-Reply-To: <4D7E9119.1010908@umn.edu> References: <4D7E8621.1030807@arin.net> <4D7E9119.1010908@umn.edu> Message-ID: <4D7E9376.90801@matthew.at> On 3/14/2011 3:05 PM, David Farmer wrote: > > The problem I with this proposal is that sets the default billing size > for all ISPs to the X-small size, which has the probable side effect > of a significant impact on ARIN's revenue from fees in the long term. 1) IPv6 itself already has this impact, as far fewer upgrade requests will be coming in, and with luck fewer people will need their own space. 2) How is ARIN's revenue a policy development issue? Matthew Kaufman From cgucker at onesc.net Mon Mar 14 18:22:49 2011 From: cgucker at onesc.net (Charles Gucker) Date: Mon, 14 Mar 2011 18:22:49 -0400 Subject: [arin-ppml] ARIN-prop-138 IPv6 Size Category Alignment In-Reply-To: <4D7E9119.1010908@umn.edu> References: <4D7E8621.1030807@arin.net> <4D7E9119.1010908@umn.edu> Message-ID: On Mon, Mar 14, 2011 at 6:05 PM, David Farmer wrote: > Charles, > > There is already an attempt to deal with this issue in Draft Policy > ARIN-2011-3: Better IPv6 Allocations for ISPs, in section 6.5.2.1(b), by > optionally allowing an ISP to request a /36 if they wish to retain the > X-small status in the IPv6 world. ?This Draft Policy will be up for > discussion at the San Jaun meeting. Understood. I certainly agree that if 2011-3 is adopted, this would be amended to follow suit. But unfortunately it does very little to address the direct problem today. 2011-3 is attempting to rewrite a substantial portion of IPv6 policy. I am simply attempting to align the current policy with practice. If the policy is changed, I would be all for modifying the practice. IMO, there is little reason to intentionally leave Organizations with whom are requesting IPv6 space in limbo. If current policy states that a /32 is the minimum ISP allocation, the fee structure should follow. Again, if policy changes, then the structure would change to match. > Do you object to that way of dealing with this issue? ?If so, why? As I stated above, I want to be consistence with existing policy, nothing more. If policy changes, as proposed in 2011-3, then this should be modified to match, nothing more, nothing less. > The problem I with this proposal is that sets the default billing size for > all ISPs to the X-small size, which has the probable side effect of a > significant impact on ARIN's revenue from fees in the long term. Where as > the approach taken in 2011-3 allows X-small ISPs a choice between a smaller > allocation (/36) at the lower rate or the normal /32 at the normal rate. ?In > theory this should be more or less revenue neutral for ARIN. ?While not > accidentally imposing a rate hike on X-small ISPs. Correct. Just keep in mind, with the critical mass, that is IPv4, the fees borne for such services will not disappear quickly. With IPv6, we are suppose to be encouraging the masses who run service providers to be independent and run their own networks. I wonder how many additional networks will surface if given the chance to get a direct allocation from ARIN. I specifically left the fee structure in place, just matched policy with practice. > While the fee structure itself is not really a policy issue. ?There is an > undeniable interaction between the minimum allocation size, which is a > policy issue, and the fee structure, which is not, therefore the two issues > can not be completely and cleanly separated. I would leave this up to the staff review, in so much as to determine the current customer demographic and determine the "average" member size. > However, if we don't to come to consensus on 2011-3 then we should probably > deal with this as a separate issue and take up this proposal and limit it to > this issue only. That was my goal. Keep it stupid simple. charles From cgucker at onesc.net Mon Mar 14 20:00:29 2011 From: cgucker at onesc.net (Charles Gucker) Date: Mon, 14 Mar 2011 20:00:29 -0400 Subject: [arin-ppml] ARIN-prop-138 IPv6 Size Category Alignment In-Reply-To: <37884c97-7cb4-4892-b2c9-3323b3502654@zimbra.network1.net> References: <4D7E8621.1030807@arin.net> <37884c97-7cb4-4892-b2c9-3323b3502654@zimbra.network1.net> Message-ID: On Mon, Mar 14, 2011 at 5:43 PM, Randy Carpenter wrote: > > I think I'd rather see it line up better with ARIN-2011-3: I would implore you to add the appropriate language to ARIN-2011-3 then. As I have stated in other threads. This proposal is to simply align the current policy with current practice. If policy changes and the policy does not take this type of activity into account, then I would modify the language to reflect such change. But in absence of that, lets just sync up the policy and practice. charles From farmer at umn.edu Mon Mar 14 20:32:05 2011 From: farmer at umn.edu (David Farmer) Date: Mon, 14 Mar 2011 19:32:05 -0500 Subject: [arin-ppml] ARIN-prop-138 IPv6 Size Category Alignment In-Reply-To: <4D7E9376.90801@matthew.at> References: <4D7E8621.1030807@arin.net> <4D7E9119.1010908@umn.edu> <4D7E9376.90801@matthew.at> Message-ID: <4D7EB385.1030004@umn.edu> On 3/14/11 17:15 CDT, Matthew Kaufman wrote: > On 3/14/2011 3:05 PM, David Farmer wrote: >> >> The problem I with this proposal is that sets the default billing size >> for all ISPs to the X-small size, which has the probable side effect >> of a significant impact on ARIN's revenue from fees in the long term. > > 1) IPv6 itself already has this impact, as far fewer upgrade requests > will be coming in, and with luck fewer people will need their own space. Yes, but this would create a much steeper slope for that change. > 2) How is ARIN's revenue a policy development issue? It is not directly one, however the cost of implementation is considered as part of a policies evaluation, and a reduction of revenue is a potential cost of the implementation of this policy that would have to be understood. And as I said Fees are not policy matters, but this issue entangles policy and fees in a way that I'm not sure you can completely and cleanly separate the two. > Matthew Kaufman -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From matthew at matthew.at Mon Mar 14 20:37:08 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 14 Mar 2011 17:37:08 -0700 Subject: [arin-ppml] ARIN-prop-138 IPv6 Size Category Alignment In-Reply-To: <4D7EB385.1030004@umn.edu> References: <4D7E8621.1030807@arin.net> <4D7E9119.1010908@umn.edu> <4D7E9376.90801@matthew.at> <4D7EB385.1030004@umn.edu> Message-ID: <4D7EB4B4.3030202@matthew.at> On 3/14/2011 5:32 PM, David Farmer wrote: > > And as I said Fees are not policy matters, but this issue entangles > policy and fees in a way that I'm not sure you can completely and > cleanly separate the two. Perhaps that means that this entire proposal is inappropriate for the policy development process. Matthew Kaufman From hannigan at gmail.com Mon Mar 14 22:20:32 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 14 Mar 2011 19:20:32 -0700 Subject: [arin-ppml] ARIN-prop-138 IPv6 Size Category Alignment In-Reply-To: <4D7EB4B4.3030202@matthew.at> References: <4D7E8621.1030807@arin.net> <4D7E9119.1010908@umn.edu> <4D7E9376.90801@matthew.at> <4D7EB385.1030004@umn.edu> <4D7EB4B4.3030202@matthew.at> Message-ID: I was thinking that this may be more administrative vs policy bound myself. Since we're on the subject of fees, a wider discussion would be interesting. A fee reduction across the board would worthy of discussion IMHO. Best, Marty On 3/14/11, Matthew Kaufman wrote: > On 3/14/2011 5:32 PM, David Farmer wrote: >> >> And as I said Fees are not policy matters, but this issue entangles >> policy and fees in a way that I'm not sure you can completely and >> cleanly separate the two. > > Perhaps that means that this entire proposal is inappropriate for the > policy development process. > > Matthew Kaufman > > _______________________________________________ > 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 arin.net Mon Mar 14 22:57:05 2011 From: jcurran at arin.net (John Curran) Date: Tue, 15 Mar 2011 02:57:05 +0000 Subject: [arin-ppml] ARIN-prop-138 IPv6 Size Category Alignment In-Reply-To: <4D7EB385.1030004@umn.edu> References: <4D7E8621.1030807@arin.net> <4D7E9119.1010908@umn.edu> <4D7E9376.90801@matthew.at> <4D7EB385.1030004@umn.edu> Message-ID: <28ECA12E-53AA-4707-853D-9458B246E007@corp.arin.net> On Mar 14, 2011, at 5:32 PM, David Farmer wrote: >> On 3/14/11 17:15 CDT, Matthew Kaufman wrote: >> 2) How is ARIN's revenue a policy development issue? > > It is not directly one, however the cost of implementation is considered as part of a policies evaluation, and a reduction of revenue is a potential cost of the implementation of this policy that would have to be understood. > > And as I said Fees are not policy matters, but this issue entangles policy and fees in a way that I'm not sure you can completely and cleanly separate the two. The structure of the fee schedule is a policy matter and discussion on PPML is perfectly reasonable. The specific fees charged for each tier or category is an ARIN membership matter outside of the policy process and best handled over on the arin-discuss mailing list. Same for a general fee increase or decrease discussion. Hope this helps, /John John Curran President and CEO ARIN From cgucker at onesc.net Mon Mar 14 23:02:46 2011 From: cgucker at onesc.net (Charles Gucker) Date: Mon, 14 Mar 2011 23:02:46 -0400 Subject: [arin-ppml] ARIN-prop-138 IPv6 Size Category Alignment In-Reply-To: <28ECA12E-53AA-4707-853D-9458B246E007@corp.arin.net> References: <4D7E8621.1030807@arin.net> <4D7E9119.1010908@umn.edu> <4D7E9376.90801@matthew.at> <4D7EB385.1030004@umn.edu> <28ECA12E-53AA-4707-853D-9458B246E007@corp.arin.net> Message-ID: On Mon, Mar 14, 2011 at 10:57 PM, John Curran wrote: > On Mar 14, 2011, at 5:32 PM, David Farmer wrote: >>> On 3/14/11 17:15 CDT, Matthew Kaufman wrote: >>> 2) How is ARIN's revenue a policy development issue? >> >> It is not directly one, however the cost of implementation is considered as part of a policies evaluation, and a reduction of revenue is a potential cost of the implementation of this policy that would have to be understood. >> >> And as I said Fees are not policy matters, but this issue entangles policy and fees in a way that I'm not sure you can completely and cleanly separate the two. > > The structure of the fee schedule is a policy matter and discussion > on PPML is perfectly reasonable. John, Thank you for the clarification. Question is, the condition that exists today (as was outlined as the rational in the policy proposal) an administrative oversight (since the policy clearly stated the ISP minimum Block Size), or a disconnection in policy management ? If it's the first, it should be able to be resolved outside of the PDP process, if the later, then this proposal serves to resolve it. > The specific fees charged for each tier or category is an ARIN > membership matter outside of the policy process and best handled > over on the arin-discuss mailing list. ?Same for a general fee > increase or decrease discussion. I'm personally going to wait on this part of the discussion until we sort out the disconnect. thanks, charles From jcurran at arin.net Mon Mar 14 23:22:39 2011 From: jcurran at arin.net (John Curran) Date: Tue, 15 Mar 2011 03:22:39 +0000 Subject: [arin-ppml] ARIN-prop-138 IPv6 Size Category Alignment In-Reply-To: References: <4D7E8621.1030807@arin.net> <4D7E9119.1010908@umn.edu> <4D7E9376.90801@matthew.at> <4D7EB385.1030004@umn.edu> <28ECA12E-53AA-4707-853D-9458B246E007@corp.arin.net> Message-ID: On Mar 14, 2011, at 8:02 PM, Charles Gucker wrote: > > Thank you for the clarification. Question is, the condition > that exists today (as was outlined as the rational in the policy > proposal) an administrative oversight (since the policy clearly stated > the ISP minimum Block Size), or a disconnection in policy management ? It's normal consequence of the policy adoption. > If it's the first, it should be able to be resolved outside of the > PDP process, if the later, then this proposal serves to resolve it. Because of arin-discuss mailing list is only for members, we tend to error of the side of caution and hold discussions on ppml if there may be policy implications to fee schedule changes. (For example, this was the case with the ARIN IPv6 fee waiver discussion, as it had potential to materially impact IPv6 adoption) I'd recommend discussing this policy proposal on PPML for now, as the input is crucial regardless of whether the AC takes it as a policy item or the Board considers as fee schedule revision. If I receive guidance that this should be taken strictly to the members, I will advise the PPML community promptly. Thanks! /John John Curran President and CEO ARIN From owen at delong.com Tue Mar 15 00:25:06 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 14 Mar 2011 21:25:06 -0700 Subject: [arin-ppml] ARIN-prop-138 IPv6 Size Category Alignment In-Reply-To: <4D7E8621.1030807@arin.net> References: <4D7E8621.1030807@arin.net> Message-ID: This is not a policy topic, IMHO, and is already the subject of a request to the BoT in the ACSP which should receive attention well before the October PPM. Owen On Mar 14, 2011, at 2:18 PM, ARIN wrote: > ARIN-prop-138 IPv6 Size Category Alignment > > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with the Policy > Development Process. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the 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. > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-138 IPv6 Size Category Alignment > > Proposal Originator: Charles Gucker > > Proposal Version: 1.0 > > Date: 14 March 2011 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > For IPv6 ISP Classification, the "Size Category" shall be determined > based on the following schedule: > > X-small /32 or smaller > Small /31 to /30 > Medium /29 to /27 > Large /26 to /24 > X-large /23 to /20 > XX-large /20 and larger > > Rationale: > > Since the adoption of ARIN Policy 2001-4 and the introduction of the > IPv6 fee schedule there has existed a discontinuity between the fee > schedule and the policy language. As the policy is written, > "6.5.1.1. Initial allocation size Organizations that meet at least one > of the following criteria are eligible to receive a minimum allocation > of /32. ?", However, the fee schedule currently states that an ISP > within the X-Small category be allocated "smaller than /40" and the > Small category of "/40 to /32". As a result, with current policy an > existing ISP within the X-Small category, when requesting the minimum > IPv6 allocation, would have to jump Size categories to receive their > IPv6 Allocation. With the IANA IPv4 runout behind us, it is important > to eliminate all hurdles for existing Organizations to receive IPv6 > allocations, even the X-Small. This proposal is intended to do just > that by aligning the Size Category with current policy. > > 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 jcurran at istaff.org Tue Mar 15 00:47:20 2011 From: jcurran at istaff.org (John Curran) Date: Mon, 14 Mar 2011 21:47:20 -0700 Subject: [arin-ppml] ARIN-prop-138 IPv6 Size Category Alignment In-Reply-To: References: <4D7E8621.1030807@arin.net> Message-ID: <3127C3A6-55A8-40B9-A1BF-7842FF275EF6@istaff.org> On Mar 14, 2011, at 9:25 PM, Owen DeLong wrote: > This is not a policy topic, IMHO, and is already the subject of a > request to the BoT in the ACSP which should receive attention > well before the October PPM. Owen - The Board will still appreciate hearing the views of the community on whether this is an actual problem to be fixed or not, so discussion on PPML is encouraged at this time. /John John Curran President and CEO ARIN From info at arin.net Tue Mar 15 08:19:12 2011 From: info at arin.net (ARIN) Date: Tue, 15 Mar 2011 08:19:12 -0400 Subject: [arin-ppml] Open Policy Hour and First Timers Orientation Message-ID: <4D7F5940.4010406@arin.net> ARIN XXVII has a couple changes to the normal premeeting/Open Policy Hour agenda. The timing and content of both the Open Policy Hour and First Timer sessions have changed. The Open Policy Hour (OPH) will now take place Tuesday afternoon within the Public Policy Meeting. The OPH is not for discussion of draft policies that are already on the ARIN XXVII agenda. It is for new ideas and suggestions. If you have a policy idea that you would like to receive feedback on prior to submitting a proposal, this is your opportunity. Sign up by Friday, 1 April to ensure your chance to take the microphone. Send an email to policy at arin.net with your name, organization, and a general description of the policy subject you wish to present. You do not need to have a formal presentation in order to participate. Signing up in advance allows us to confirm your turn to present, but is not required. The First Timers Orientation will be at 2:00 PM on Sunday. This session will be an ?ARIN 101?, an overview of the Policy Development Process, and a preview of the Draft Policies which will be presented and discussed later at the Public Policy Meeting. You don?t have to be a first timer to attend, all are welcome. For more information about ARIN XXVII, visit https://www.arin.net/ARIN-XXVII/. Hope to see you there! Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From bensons at queuefull.net Tue Mar 15 20:57:49 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 15 Mar 2011 19:57:49 -0500 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: References: <4D76879D.4000508@arin.net> Message-ID: <162CB1B9-C689-4E13-A846-D968EBD0C09A@queuefull.net> On Mar 13, 2011, at 2:37 PM, Matthew Petach wrote: > On Tue, Mar 8, 2011 at 11:46 AM, ARIN wrote: >> ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation >> mechanisms by the IANA > > As this policy does not in any way state what addresses must > or must not be returned to IANA, it focuses only on ensuring > that any addresses that are returned to IANA are given out in > a fair and equitable manner, I find myself to be in SUPPORT > of this proposal. For the reason described above, I support this policy proposal. However, something isn't clear (to me) from the policy text: Does each RIR automatically receive an "IPv4 allocation unit" per allocation period, or must they first submit an outstanding request to IANA? I imagine that the latter approach would be similar to historical policy, perhaps with a justification-of-needs requirement associated with it. The former, automatic allocation approach would possibly result in allocation to RIRs without need. But it may also have the most fairness, given different regional policies on such topics as address transfers / markets, return of addresses to IANA, etc. Cheers, -Benson From hannigan at gmail.com Tue Mar 15 21:09:01 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 15 Mar 2011 18:09:01 -0700 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: <162CB1B9-C689-4E13-A846-D968EBD0C09A@queuefull.net> References: <4D76879D.4000508@arin.net> <162CB1B9-C689-4E13-A846-D968EBD0C09A@queuefull.net> Message-ID: On Tue, Mar 15, 2011 at 5:57 PM, Benson Schliesser wrote: > > On Mar 13, 2011, at 2:37 PM, Matthew Petach wrote: >> On Tue, Mar 8, 2011 at 11:46 AM, ARIN wrote: >>> ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation >>> mechanisms by the IANA >> >> As this policy does not in any way state what addresses must >> or must not be returned to IANA, it focuses only on ensuring >> that any addresses that are returned to IANA are given out in >> a fair and equitable manner, I find myself to be in SUPPORT >> of this proposal. > > For the reason described above, I support this policy proposal. > > However, something isn't clear (to me) from the policy text: ?Does each RIR automatically receive an "IPv4 allocation unit" per allocation period, or must they first submit an outstanding request to IANA? > > I imagine that the latter approach would be similar to historical policy, perhaps with a justification-of-needs requirement associated with it. > > The former, automatic allocation approach would possibly result in allocation to RIRs without need. ?But it may also have the most fairness, given different regional policies on such topics as address transfers / markets, return of addresses to IANA, etc. > There is no needs based requirement contained in this proposal. It also fails to address the transfer problem; giving more addresses to regions with weaker policy regimes will result in the liklihood of the addresses finding their way back to this region to fulfill need --- via an expensive market. This proposal is patently unfair and disenfranchising to the ARIN community. Best, -M< From info at arin.net Wed Mar 16 12:23:16 2011 From: info at arin.net (ARIN) Date: Wed, 16 Mar 2011 12:23:16 -0400 Subject: [arin-ppml] =?windows-1252?q?NRPM_2011=2E2_=96_New_Policy_Impleme?= =?windows-1252?q?nted?= Message-ID: <4D80E3F4.2010301@arin.net> A new version of the ARIN Number Resource Policy Manual (NRPM) has been published to the ARIN website. NRPM version 2011.2 is effective 16 March 2011 and supersedes the previous version. NRPM version 2011.2 contains the implementation of the following policy: ARIN-2010-8: Rework of IPv6 assignment criteria https://www.arin.net/policy/proposals/2010_8.html ARIN-2010-8 replaced section "6.5.8. Direct assignments from ARIN to end-user organizations" in the policy manual. 2010-8 was adopted by the ARIN Board on 11 January 2011. Board minutes are available at: https://www.arin.net/about_us/bot/index.html The NRPM is available at: https://www.arin.net/policy/nrpm.html Draft policies and proposals are available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From farmer at umn.edu Thu Mar 17 01:47:15 2011 From: farmer at umn.edu (David Farmer) Date: Thu, 17 Mar 2011 00:47:15 -0500 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: References: <4D76879D.4000508@arin.net> Message-ID: <4D81A063.7090906@umn.edu> On 3/13/11 15:08 CDT, Jeffrey Lyon wrote: > No, I would like to take whatever measures necessary to make sure that > IANA never touches IPv4 space, ever again. > > Jeff Too late, IANA still has some bits of IPv4. From the transcript of the APNIC meeting three weeks ago; > Leo Vegoda: We actually appear to have about a /20 in bits and pieces of /24, which I think would be the seed for any reclamation pool were such a policy to be passed. > > Of course, if people don't want us to allocate those eight, I think it is, /24s, then we can probably just pass them out to staff and, you know, sort it out that way. In any case, we do have very small bits currently waiting for a policy. It's not really very much, so you probably don't want to go through a lot of effort just to get that /20. In any case, there is some space in /24s and no one is using it at the moment. Should we leave them in jail at IANA? Or, put together a simple policy that allows them out of jail to be put to use? > On Sun, Mar 13, 2011 at 3:55 PM, Matthew Petach wrote: >> On Sun, Mar 13, 2011 at 12:45 PM, Jeffrey Lyon >> wrote: >>> .. but they shouldn't be returned to IANA so we don't need a mechanism >>> for ensuring that anything happens when, in theory, the undesirable >>> occurs. >>> >>> I'm still opposed. >>> >>> Best regards, Jeff >> >> *heh* >> So, you'd rather any addresses that happen to end up back with >> IANA get stranded there in perpetuity? >> >> *shrug* I guess that's one more push for people to move to v6 instead. ;-P >> >> Matt >> > > > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From springer at inlandnet.com Thu Mar 17 14:06:53 2011 From: springer at inlandnet.com (John Springer) Date: Thu, 17 Mar 2011 11:06:53 -0700 (PDT) Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: <4D81A063.7090906@umn.edu> References: <4D76879D.4000508@arin.net> <4D81A063.7090906@umn.edu> Message-ID: <20110317090043.A97412@mail.inlandnet.com> Hi David, Just to you, not the list: On Thu, 17 Mar 2011, David Farmer wrote: > On 3/13/11 15:08 CDT, Jeffrey Lyon wrote: >> No, I would like to take whatever measures necessary to make sure that >> IANA never touches IPv4 space, ever again. >> >> Jeff > > Too late, IANA still has some bits of IPv4. > > From the transcript of the APNIC meeting three weeks ago; > >> Leo Vegoda: We actually appear to have about a /20 in bits and pieces of >> /24, which I think would be the seed for any reclamation pool were such a >> policy to be passed. >> >> Of course, if people don't want us to allocate those eight, I think it is, >> /24s, then we can probably just pass them out to staff and, you know, sort >> it out that way. In any case, we do have very small bits currently waiting >> for a policy. It's not really very much, so you probably don't want to go >> through a lot of effort just to get that /20. In any case, there is some >> space in /24s and no one is using it at the moment. > > Should we leave them in jail at IANA? Or, put together a simple policy that > allows them out of jail to be put to use? I hope you won't be offended, but in the race to find the smallest possible item of V4 concern, this seems pretty close to the theoretical minimum. I don't have a strong opinion about this proposal, but citing the existance of these addresses as rationale one way or the other seems immaterial. I'd rather have IANA hang on to them. John Springer >> On Sun, Mar 13, 2011 at 3:55 PM, Matthew Petach >> wrote: >>> On Sun, Mar 13, 2011 at 12:45 PM, Jeffrey Lyon >>> wrote: >>>> .. but they shouldn't be returned to IANA so we don't need a mechanism >>>> for ensuring that anything happens when, in theory, the undesirable >>>> occurs. >>>> >>>> I'm still opposed. >>>> >>>> Best regards, Jeff >>> >>> *heh* >>> So, you'd rather any addresses that happen to end up back with >>> IANA get stranded there in perpetuity? >>> >>> *shrug* I guess that's one more push for people to move to v6 instead. >>> ;-P >>> >>> Matt >>> >> >> >> > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > _______________________________________________ > 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 Thu Mar 17 15:14:58 2011 From: farmer at umn.edu (David Farmer) Date: Thu, 17 Mar 2011 14:14:58 -0500 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: <20110317090043.A97412@mail.inlandnet.com> References: <4D76879D.4000508@arin.net> <4D81A063.7090906@umn.edu> <20110317090043.A97412@mail.inlandnet.com> Message-ID: <4D825DB2.3060908@umn.edu> On 3/17/11 13:06 CDT, John Springer wrote: > Hi David, > > Just to you, not the list: No, you sent it to the list; > On Thu, 17 Mar 2011, David Farmer wrote: > >> On 3/13/11 15:08 CDT, Jeffrey Lyon wrote: >>> No, I would like to take whatever measures necessary to make sure that >>> IANA never touches IPv4 space, ever again. >>> >>> Jeff >> >> Too late, IANA still has some bits of IPv4. >> >> From the transcript of the APNIC meeting three weeks ago; >> >>> Leo Vegoda: We actually appear to have about a /20 in bits and pieces >>> of /24, which I think would be the seed for any reclamation pool were >>> such a policy to be passed. >>> >>> Of course, if people don't want us to allocate those eight, I think >>> it is, /24s, then we can probably just pass them out to staff and, >>> you know, sort it out that way. In any case, we do have very small >>> bits currently waiting for a policy. It's not really very much, so >>> you probably don't want to go through a lot of effort just to get >>> that /20. In any case, there is some space in /24s and no one is >>> using it at the moment. >> >> Should we leave them in jail at IANA? Or, put together a simple policy >> that allows them out of jail to be put to use? > > I hope you won't be offended, but in the race to find the smallest > possible item of V4 concern, this seems pretty close to the theoretical > minimum. > > I don't have a strong opinion about this proposal, but citing the > existance of these addresses as rationale one way or the other seems > immaterial. > > I'd rather have IANA hang on to them. > > John Springer I don't disagree at all, but this needs to be a conscious choice and not one made by default. I don't want anyone thinking we accidentally left addresses at IANA. If we want to leave addresses at IANA I'm fine with that, as long as we consciously chose to do so. However, the tone of the previous post was that, we don't need this policy because we can just make sure that IANA doesn't have any IPv4 address space, which is not and will not be the case. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From hannigan at gmail.com Thu Mar 17 16:37:55 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 17 Mar 2011 13:37:55 -0700 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: <4D825DB2.3060908@umn.edu> References: <4D76879D.4000508@arin.net> <4D81A063.7090906@umn.edu> <20110317090043.A97412@mail.inlandnet.com> <4D825DB2.3060908@umn.edu> Message-ID: This is the one case, due to global RIR community failure to reach consensus on related issues and the likelihood that we never will, that ICANN should do what needs to be done. This should not be considered support to do it consecutively ie if addresses some how found their way back to the IANA. Just this time and this issue. Best, -M< On 3/17/11, David Farmer wrote: > On 3/17/11 13:06 CDT, John Springer wrote: >> Hi David, >> >> Just to you, not the list: > > No, you sent it to the list; > >> On Thu, 17 Mar 2011, David Farmer wrote: >> >>> On 3/13/11 15:08 CDT, Jeffrey Lyon wrote: >>>> No, I would like to take whatever measures necessary to make sure that >>>> IANA never touches IPv4 space, ever again. >>>> >>>> Jeff >>> >>> Too late, IANA still has some bits of IPv4. >>> >>> From the transcript of the APNIC meeting three weeks ago; >>> >>>> Leo Vegoda: We actually appear to have about a /20 in bits and pieces >>>> of /24, which I think would be the seed for any reclamation pool were >>>> such a policy to be passed. >>>> >>>> Of course, if people don't want us to allocate those eight, I think >>>> it is, /24s, then we can probably just pass them out to staff and, >>>> you know, sort it out that way. In any case, we do have very small >>>> bits currently waiting for a policy. It's not really very much, so >>>> you probably don't want to go through a lot of effort just to get >>>> that /20. In any case, there is some space in /24s and no one is >>>> using it at the moment. >>> >>> Should we leave them in jail at IANA? Or, put together a simple policy >>> that allows them out of jail to be put to use? >> >> I hope you won't be offended, but in the race to find the smallest >> possible item of V4 concern, this seems pretty close to the theoretical >> minimum. >> >> I don't have a strong opinion about this proposal, but citing the >> existance of these addresses as rationale one way or the other seems >> immaterial. >> >> I'd rather have IANA hang on to them. >> >> John Springer > > I don't disagree at all, but this needs to be a conscious choice and not > one made by default. I don't want anyone thinking we accidentally left > addresses at IANA. If we want to leave addresses at IANA I'm fine with > that, as long as we consciously chose to do so. > > However, the tone of the previous post was that, we don't need this > policy because we can just make sure that IANA doesn't have any IPv4 > address space, which is not and will not be the case. > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > _______________________________________________ > 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 narten at us.ibm.com Fri Mar 18 00:53:02 2011 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 18 Mar 2011 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201103180453.p2I4r2Fj014718@rotala.raleigh.ibm.com> Total of 30 messages in the last 7 days. script run at: Fri Mar 18 00:53:02 EDT 2011 Messages | Bytes | Who --------+------+--------+----------+------------------------ 13.33% | 4 | 15.85% | 29106 | farmer at umn.edu 13.33% | 4 | 12.13% | 22267 | cgucker at onesc.net 10.00% | 3 | 11.27% | 20689 | hannigan at gmail.com 10.00% | 3 | 8.80% | 16153 | info at arin.net 6.67% | 2 | 6.64% | 12189 | jeffrey.lyon at blacklotus.net 6.67% | 2 | 6.00% | 11024 | jcurran at arin.net 6.67% | 2 | 5.79% | 10624 | mpetach at netflight.com 6.67% | 2 | 4.71% | 8651 | matthew at matthew.at 3.33% | 1 | 4.63% | 8510 | mksmith at adhost.com 3.33% | 1 | 4.35% | 7996 | owen at delong.com 3.33% | 1 | 4.30% | 7890 | rcarpen at network1.net 3.33% | 1 | 3.95% | 7258 | springer at inlandnet.com 3.33% | 1 | 3.35% | 6159 | narten at us.ibm.com 3.33% | 1 | 2.96% | 5430 | bensons at queuefull.net 3.33% | 1 | 2.73% | 5015 | joelja at bogus.com 3.33% | 1 | 2.53% | 4654 | jcurran at istaff.org --------+------+--------+----------+------------------------ 100.00% | 30 |100.00% | 183615 | Total From charles at office.tcsn.net Tue Mar 22 15:56:58 2011 From: charles at office.tcsn.net (Charles O'Hern) Date: Tue, 22 Mar 2011 12:56:58 -0700 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D65B8B2.9070702@arin.net> References: <4D65B8B2.9070702@arin.net> Message-ID: <4D88FF0A.7000805@office.tcsn.net> We do not support this proposal. On 2/23/11 5:47 PM, ARIN wrote: > ARIN-prop-136: Services Opt-out Allowed for Unaffiliated Address Blocks > > ARIN acknowledges receipt of the policy proposal that can be found below. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the 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. > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-136: Services Opt-out Allowed for Unaffiliated Address Blocks > > Proposal Originator: Benson Schliesser > > Proposal Version: 1 > > Date: 23 Feb 2011 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > Add the following to the NRPM: > > 13. Unaffiliated Address Blocks > > 13.x. Opt-out Allowed > > ARIN provides IP address registry services to all IP address holders in > the ARIN region, for all IP address resources that are not registered by > another RIR, regardless of whether any given address holder has entered > into a services agreement. However, ARIN will cease providing any > registry services for specific IP address resources in the event that > the legitimate address holder of an unaffiliated address block, that is > an address block that is not covered by an ongoing services agreement, > chooses to opt-out of receiving any or all registry services from ARIN. > > 13.x.1. Requirements for Whois Opt-out > > In order for an opt-out request for Whois directory services to be > valid, the legitimate address holder must agree to provide a replacement > directory service reflecting operationally accurate allocation and > assignment information for the specified IP number resources. ARIN will > create generic placeholder entries in the ARIN Whois directory for all > IP number resources that are removed due to opt-out, and each > placeholder entry will include a reference and/or RWhois referral to the > replacement directory service. > > > Rationale: > > This proposal does not seek to replace ARIN-prop-133 but is offered as > an exclusive alternative for consideration by the ARIN community, in > order to address concerns that it would unfairly harm legacy address > holders and/or cause unnecessary damage to the Whois database. > > Policy Background: > > This policy attempts to clarify the relationship that ARIN has with > legacy address holders. > > Specifically, this policy recognizes that absent an agreement such as > the RSA or LRSA there is no formal relationship with legacy address > holders. At present, however, ARIN continues to provide services to > these organizations. This is done without compensation and potentially > in opposition to the legacy address holders' wishes. As a result of > this behavior ARIN has created an illusion of implied authority that > exposes ARIN to unacceptable levels of liability, is hindering the > development of an open address market (driving it "underground"), and is > putting the operational stability of the Internet at risk. As new > services such as RPKI are contemplated this situation becomes even more > critical. > > This policy assumes the tacit consent of all address holders in the ARIN > region, to receive ARIN registry services and to be governed by ARIN > policy, but allows for legitimate address holders of unaffiliated > address blocks to explicitly opt-out of any and/or all services. This > approach would allow ARIN to continue providing volunteer services to > any member of the legacy community as long as this service was not > contrary to their wishes. Further, it would allow legacy address > holders to opt-out of some services such as Whois while continuing to > receive other services such as in-addr DNS reverse mapping. > > In the event that a legacy address holder does opt-out of Whois > directory services under this policy, ARIN would require the address > holder to provide a replacement directory service and would continue to > provide a Whois pointer (such as a RWhois referral) to that service. As > a result, the integrity of the distributed Whois database would remain > intact and be improved. > > Timetable for implementation: Immediately > > > > _______________________________________________ > 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. -- Charles O'Hern Network Operations TCSN - The Computer Shop Netlink 1306 Pine St. Paso Robles CA 93446 1-(805) 227-7000 1-(800) 974-DISK http://www.tcsn.net abuse at tcsn.net From owen at delong.com Wed Mar 23 02:18:50 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Mar 2011 23:18:50 -0700 Subject: [arin-ppml] [arin-council] FW: lunch table topics In-Reply-To: <-3857647331525754290@unknownmsgid> References: <1046004119469854908@unknownmsgid> <410886717751839205@unknownmsgid> <9707D54B-2D59-4640-B615-FC4828855469@delong.com> <4429174256206207402@unknownmsgid> <7646141884847324772@unknownmsgid> <317D2CAA-2AA8-45D7-AFE7-EF244653FB93@delong.com> <-3857647331525754290@unknownmsgid> Message-ID: <2D9A191B-2CAB-4BA0-9FDB-7F5B0FA2ECE3@delong.com> On Mar 22, 2011, at 9:18 PM, Scott Leibrand wrote: > On Mar 22, 2011, at 8:52 PM, Owen DeLong wrote: > >> >> On Mar 22, 2011, at 8:22 PM, Scott Leibrand wrote: >> >>> Agreed. I think that part is actually handled quite well by the >>> current LRSA process. I think the gap that has been identified is >>> allowing a legacy holder to demonstrate that they're the legitimate >>> holder of the space while they're doing negotiations with potential >>> buyers. If there was some sort of pre-qualification they could do >>> that accomplishes the same verification required for an LRSA, but >>> doesn't commit the legacy holder to signing the LRSA if the transfer >>> doesn't go through, I think we'll be able to reduce the perceived risk >>> among a certain percentage of the legacy holders, and thereby increase >>> the available supply of legacy space on the legitimate transfer >>> market. >> >> I think that is best handled by having the transfer in escrow pending >> LRSA completion which doesn't affect ARIN. >> >> The escrow is a process between the legacy holder and the recipient. >> >> I see no reason to have ARIN expend resources to the benefit of legacy >> holders in this process without LRSA signature. If they want to avoid >> the need for escrow, they can sign the LRSA. > > If I'm looking for someone to acquire space from, and find a legacy > holder, I'd rather tell them "please show me your LRSA or ARIN > pre-qualification as the legitimate holder, and I'll show you my > pre-qualification to receive space" before we get to the point of > having our lawyers go over our agreement. Waiting until closing time > to discover that they really aren't authorized to transfer the space > (or I'm not authorized to receive it) is a big waste of effort. It > reduces everyone's risk to get the verification done up front, if > you're gonna have to do it anyway (for this transaction or another > one). > I completely agree. As such, legacy holders who have signed the LRSA will be at an advantage in the market and probably be able to get higher prices. I don't see a problem with that. OTOH, if someone wants to sell their space, but, doesn't want to sign the LRSA, then, they need to find a buyer that will work with them through the process. Sure, this is slightly less convenient for the buyer if they can't find an LRSA signatory. I don't see a problem with having this as a carrot for legacy holders to sign the LRSA. I also don't see any reason to eliminate that carrot from ARIN's toolbox. > IMO if the upfront verification work justifies a $100 fee for the > LRSA, then the prequalification should cost the same $100 to do the > exact same verification work, and should be convertible into an LRSA > with no additional fee. > I don't disagree, but, I don't see any advantage to ARIN in doing the pre-qualification without it resulting in an LRSA. I see advantage to the legacy holder (who if they are unwilling to sign an LRSA, frankly, I'm not particularly interested in providing an advantage to). I see a small potential advantage to the transferee (though I think they can mitigate this in other ways). > Now I wish we'd moved this discussion to PPML... > As you wish... Owen > -Scott > >> >> Owen >> >>> >>> Scott >>> >>> On Mar 22, 2011, at 8:12 PM, Owen DeLong wrote: >>> >>>> Depending on the definition of successful, I would accept that. >>>> >>>> However, I'll point out that since they're signing the LRSA as one of the >>>> last steps in getting their transfer processed, it shouldn't be possible >>>> for their transfer to subsequently fail. >>>> >>>> Owen >>>> >>>> On Mar 22, 2011, at 7:50 PM, Scott Leibrand wrote: >>>> >>>>> Scott >>>>> >>>>> On Mar 22, 2011, at 7:42 PM, Owen DeLong wrote: >>>>> >>>>>> >>>>>> On Mar 22, 2011, at 7:28 PM, Scott Leibrand wrote: >>>>>> >>>>>>> What do you feel that contact should require of the legacy holder? If >>>>>>> it's just a "pay ARIN $X, provide documentation, and attest to its >>>>>>> validity, in exchange for the ability to provide address space via >>>>>>> transfer", then I completely agree that a contract is warranted. >>>>>>> >>>>>> If they are transferring their complete legacy holdings, then, i would accept >>>>>> that as the minimum. >>>>>> >>>>>> If they are conducting a partial transfer, then, I think that the LRSA is about >>>>>> as minimal as I am willing to go. >>>>>> >>>>>>> IMO the LRSA is an entirely appropriate contract for a legacy holder >>>>>>> who wants to keep their space, but it's overkill for a holder who just >>>>>>> wants to put some of that space up for transfer with as little fuss >>>>>>> and risk as possible. >>>>>>> >>>>>> If they want to put SOME of that space up, then, they are also wanting >>>>>> to keep their space, so, I think we just agreed, but, it's not clear that >>>>>> is the case from the way you worded the last paragraph. >>>>> >>>>> I think it would be reasonable to have an LRSA that goes into effect >>>>> for the remaining space upon successful completion of a transfer of >>>>> some of their space... >>>>> >>>>> -Scott >>>>> >>>>>> >>>>>> Owen >>>>>> >>>>>>> Scott >>>>>>> >>>>>>> On Mar 22, 2011, at 7:07 PM, Owen DeLong wrote: >>>>>>> >>>>>>>> I don't actually favor making it easier for legacy holders to make space available >>>>>>>> without a contractual relationship with ARIN about the space first. I'm not opposed >>>>>>>> to a lighter weight contract for complete transfers, but, I think it is reasonable to >>>>>>>> insist that anyone wanting to monetize a portion of their legacy space be required >>>>>>>> to develop a contractual relationship with the RIR for all of their space in order to >>>>>>>> do so. >>>>>>>> >>>>>>>> I see no reason to open up the benefits of new ARIN policy to legacy holders without >>>>>>>> also requiring that they at least accept the encumbrance of a contractual relationship >>>>>>>> with ARIN to go with it. >>>>>>>> >>>>>>>> I think the potential risk to the organization from a legacy holder that does not have >>>>>>>> a contractual relationship with ARIN engaging in transfers is unacceptable. >>>>>>>> >>>>>>>> Owen >>>>>>>> >>>>>>>> On Mar 22, 2011, at 5:47 PM, Scott Leibrand wrote: >>>>>>>> >>>>>>>>> Something along the lines of "Avoiding unnecessary friction in the >>>>>>>>> transfer market" maybe? I think some discussion around ways to make >>>>>>>>> it easier for legacy holders to make space available for transfer, and >>>>>>>>> demonstrate that they're the legitimate address holder, without first >>>>>>>>> agreeing to the conditions of an LRSA, would be helpful. >>>>>>>>> >>>>>>>>> Scott >>>>>>>>> >>>>>>>>> On Mar 22, 2011, at 1:52 PM, "Sweeting, John" wrote: >>>>>>>>> >>>>>>>>>> Hello everyone, >>>>>>>>>> >>>>>>>>>> Please review the list of table topics below and submit any other topics that you wish to monitor or have discussed. >>>>>>>>>> >>>>>>>>>> Heather, did you want to add a topic that captures PP 132 for discussion? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> John >>>>>>>>>> >>>>>>>>>> ++ >>>>>>>>>> ------ Forwarded Message >>>>>>>>>> From: Einar Bohlin >>>>>>>>>> Date: Tue, 22 Mar 2011 15:37:11 -0400 >>>>>>>>>> To: John Sweeting >>>>>>>>>> Subject: lunch table topics >>>>>>>>>> >>>>>>>>>> John, >>>>>>>>>> >>>>>>>>>> These will be active proposals: >>>>>>>>>> >>>>>>>>>> ARIN-prop-126 Compliance Requirement >>>>>>>>>> >>>>>>>>>> ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA >>>>>>>>>> >>>>>>>>>> ARIN-prop-138 IPv6 Size Category Alignment >>>>>>>>>> >>>>>>>>>> Any other topics for lunch tables? >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Einar Bohlin >>>>>>>>>> Policy Analyst >>>>>>>>>> Communications and Member Services, ARIN >>>>>>>>>> einarb at arin.net +1 703 227-9867 >>>>>>>>>> >>>>>>>>>> - >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ------ End of Forwarded Message >>>>>>>>>> >>>>>>>>>> ________________________________ >>>>>>>>>> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. >>>>>>>>>> _______________________________________________ >>>>>>>>>> ARIN-COUNCIL mailing list >>>>>>>>>> ARIN-COUNCIL at arin.net >>>>>>>>>> http://lists.arin.net/mailman/listinfo/arin-council >>>>>>>>> _______________________________________________ >>>>>>>>> ARIN-COUNCIL mailing list >>>>>>>>> ARIN-COUNCIL at arin.net >>>>>>>>> http://lists.arin.net/mailman/listinfo/arin-council >>>>>>>> >>>>>> >>>> >> From info at arin.net Wed Mar 23 10:47:03 2011 From: info at arin.net (ARIN) Date: Wed, 23 Mar 2011 10:47:03 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 Message-ID: <4D8A07E7.6020906@arin.net> In accordance with the ARIN Policy Development Process (PDP), the ARIN Advisory Council (AC) held a meeting on 17 March 2011 and made decisions about several policy proposals. The AC abandoned the following proposals: ARIN-prop-132 ISP Sub-assignments Do Not Require Specific Customer Relationships ARIN-prop-133 No Volunteer Services on Behalf of Unaffiliated Address Blocks ARIN-prop-134 Identification of Legitimate Address Holders ARIN-prop-135 Clarification of draft policy 2009-3 ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks The AC voted to abandon ARIN-prop-132 for the following reasons: - Aggregation is one of the goals of addressing stewardship, this policy encourages deaggregation, and accelerates routing table growth. - Creates a situation where the ISP providing the address space is not in a position to remediate security and abuse issues which may have significant impact on the larger internet community. - The AC believes that a discussion about how staff currently handles this situation is worth having, and suggests the author or a member of the community submit it as an Open Policy hour topic at the upcoming ARIN meeting. ARIN-prop-133 was abandoned by the AC because there was not significant support for it on PPML and because the proposal as written is not something that could be implemented under the existing circumstances (ICANN MOU, ARIN structure, and the fact that there is no provision for "alternate" registries in any existing documents, RFCs, or other approved structures). The AC has chosen to abandon ARIN-prop-134. Aside from the author, there were no statements of support on the mailing list, and the majority of opinion questioned the problem to be solved. While wording can often be refined during the policy development process, the problem statement itself needs further clarification. The abandonment of this proposal is not to dismiss the discussion. It would just be clearer to refine the problem statement first and submit a proposal if more clarity and support can be reached on the mailing list. The AC abandoned ARIN-prop-135 because: a. The original author wished to withdraw it, and b. The proposal was an attempt to clarify policy. If policy is to be changed, the policy itself needs to be rewritten, not clarified. The AC voted to abandon ARIN-prop-136 for the following reasons: - Overwhelming lack of support within the ARIN community, as evidenced by discussion on the PPML. - ARIN staff has indicated that they do not believe that it is possible to implement this policy due to existing agreements, namely they can not not-serve our community. - Today folks have the option of opting out of swip by using RWHOIS and providing ARIN information about the location of the RHWOIS service to publish in the SWIP record. This hasn't always gone so well, not all RWHOIS services are kept up to date and publicly available. Providing another mechanism for folks to opt out of having records published publicly in a centralized location, is not in the best interest of the community, as it would complicate abuse, security and law enforcement investigations. The AC encourages further discussion of this topic and would be happy to work with anyone who believes policy changes in this area are needed. The Advisory Council appreciates the involvement of all community members who provide input toward a complete discussion of policy proposals. The AC especially wishes to thank those authors of policy proposals for their efforts in helping the community address possible improvements. The PDP states, ?Any member of the community, including a proposal originator, may initiate a Discussion Petition if they are dissatisfied with the action taken by the Advisory Council regarding any specific policy proposal.? Proposals 132, 133, 134, 135, and 136 were abandoned and as such may be petitioned (Discussion Petition) to try to change them into draft policies for adoption discussion on the Public Policy Mailing List and at the ARIN XXVIII (October 2011) Public Policy Meeting (March 7 was the deadline for petitions for the upcoming meeting in San Juan). The deadline to begin a petition will be five business days after the AC's draft meeting minutes are published. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html Draft Policy and Policy Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From charles at office.tcsn.net Wed Mar 23 15:47:11 2011 From: charles at office.tcsn.net (Charles O'Hern) Date: Wed, 23 Mar 2011 12:47:11 -0700 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: <4D76879D.4000508@arin.net> References: <4D76879D.4000508@arin.net> Message-ID: <4D8A4E3F.7010007@office.tcsn.net> While it seemed a good idea for the last 5 /8's to be handed out equally to the 5 RIR's, for perpetual policy I'm not sure if I like equal distribution over needs-based distribution. I support policy to address assets returned to IANA set aside for re-allocation, just not the method of equal distribution. But if the only way to get this passed by all the RIRs is with the equal distribution clause, I would drop my objection. I think its more important to allow IANA policy regarding returned assets than nitpick about the re-allocation method (as long as the assets are re-allocated). -head fuzzy from the flu, I hope I made some semblance of sense. -- Charles O'Hern Network Operations TCSN - The Computer Shop Netlink 1306 Pine St. Paso Robles CA 93446 1-(805) 227-7000 1-(800) 974-DISK http://www.tcsn.net abuse at tcsn.net On 3/8/11 11:46 AM, ARIN wrote: > ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation > mechanisms by the IANA > > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with the Policy > Development Process. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the 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. > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation > mechanisms by the IANA > > Proposal Originator: Philip Smith > co-authors: Alejandro Acosta, Nicolas Antoniello, S. Moonesamy, > Douglas Onyango, Medel Ramirez, Masato Yamanishi > > Proposal Version: 1 > > Date: 8 March 2011 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > The IANA shall establish a Recovered IPv4 Pool to be utilized post > RIR IPv4 exhaustion. The Recovered IPv4 Pool will initially contain > any fragments that may be left over in the IANA. It will also hold > any space returned to the IANA by any other means. > > The Recovered IPv4 Pool will be administered by the IANA. It will > contain: > > a. Any fragments left over in the IANA inventory after the last > /8s of IPv4 space are delegated to the RIRs > > - The IANA inventory excludes "Special use IPv4 addresses" as > defined in BCP 153 and any addresses allocated by the IANA > for experimental use. > > b. Any IPv4 space returned to the IANA by any means. > > The Recovered IPv4 Pool will stay inactive until the first RIR has > less than a total of a /9 in its inventory of IPv4 address space. > > When one of the RIRs declares it has less than a total of a /9 in > its inventory, the Recovered IPv4 pool will be declared active, and > IP addresses from the Recovered IPv4 Pool will be allocated as > follows: > > a. Allocations from the IANA may begin once the pool is declared > active. > > b. In each "IPv4 allocation period", each RIR will receive a > single "IPv4 allocation unit" from the IANA. > > c. An "IPv4 allocation period" is defined as a 6-month period > following 1 March or 1 September in each year. > > d. The IANA will calculate the size of the "IPv4 allocation unit" > at the following times: > > - When the Recovered IPv4 Pool is first activated > - At the beginning of each IPv4 allocation period > > To calculate the "IPv4 allocation unit" at these times, the > IANA will use the following formula: > > IPv4 allocation unit = 1/5 of Recovered IPv4 pool, > rounded down to the next CIDR > (power-of-2) boundary. > > No RIR may get more than this calculation used to determine > the IPv4 allocation unit even when they can justify a need for > it. > > The minimum "IPv4 allocation unit" size will be a /24. If the > calculation used to determine the IPv4 allocation unit results > in a block smaller than a /24, the IANA will not distribute > any addresses in that IPv4 allocation period. > > The IANA may make public announcements of IPv4 address > transactions that occur under this policy. The IANA will make > appropriate modifications to the "Internet Protocol V4 Address > Space" page of the IANA website and may make announcements to its > own appropriate announcement lists. The IANA announcements will > be limited to which address ranges, the time of allocation, and to > which Registry they have been allocated. > > Rationale: > > The policy provides a mechanism for the ongoing distribution of > IPv4 address space, while removing the areas that have been > problematic in previous attemts at this proposal. The proposal: > > - Permits regional variation in runout policy amongst RIRs to > be accounted for in the distribution of the Recovered IPv4 Pool > > - Prevents the possibility of a single RIR being eligible to > be allocated the entire Recovered IPv4 Pool in the first > (and perhaps only) allocation period > > - Removes two areas of policy that have failed to reach > agreement in previous attempts at this proposal: > > - How addresses should be placed in the Recovered IPv4 Pool > - References to how transfers should or should not take > place > > Timetable for implementation: > > Once consensus has been reached in each of the 5 RIR regions, the > policy will be forwarded to ICANN for approval and then implemented > by the IANA. > > > > _______________________________________________ > 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 charles at office.tcsn.net Wed Mar 23 15:53:49 2011 From: charles at office.tcsn.net (Charles O'Hern) Date: Wed, 23 Mar 2011 12:53:49 -0700 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: References: <4D76879D.4000508@arin.net> Message-ID: <4D8A4FCD.4030007@office.tcsn.net> On 3/13/11 12:45 PM, Jeffrey Lyon wrote: > .. but they shouldn't be returned to IANA so we don't need a mechanism > for ensuring that anything happens when, in theory, the undesirable > occurs. > > I'm still opposed. > > Best regards, Jeff Why is the possibility (if high improbability) of returning assets to IANA undesirable? It is possible at some future time that ARIN has assets that no one in ARIN's region needs. Why shouldn't they be returned to IANA? -- Charles O'Hern Network Operations TCSN - The Computer Shop Netlink 1306 Pine St. Paso Robles CA 93446 1-(805) 227-7000 1-(800) 974-DISK http://www.tcsn.net abuse at tcsn.net From scottleibrand at gmail.com Wed Mar 23 15:54:31 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 23 Mar 2011 12:54:31 -0700 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: <4D8A4E3F.7010007@office.tcsn.net> References: <4D76879D.4000508@arin.net> <4D8A4E3F.7010007@office.tcsn.net> Message-ID: <-2280570596895311140@unknownmsgid> Well put. I suspect that the number of addresses being returned to IANA (as opposed to being transferred directly) will be small, and that most RIRs will very soon be in a situation of needing more addresses (and not being able to get them). The only two that may be exceptions would be AfriNIC and maybe LACNIC, and I certainly wouldn't object to providing a few extra resources to those regions (as we did with the last /8s). Scott On Mar 23, 2011, at 12:47 PM, Charles O'Hern wrote: > While it seemed a good idea for the last 5 /8's to be handed out equally to the 5 RIR's, for perpetual policy I'm not sure if I like equal distribution over needs-based distribution. > > I support policy to address assets returned to IANA set aside for re-allocation, just not the method of equal distribution. > > But if the only way to get this passed by all the RIRs is with the equal distribution clause, I would drop my objection. I think its more important to allow IANA policy regarding > returned assets than nitpick about the re-allocation method (as long as the assets are re-allocated). > > -head fuzzy from the flu, I hope I made some semblance of sense. > -- > Charles O'Hern > Network Operations > > TCSN - The Computer Shop Netlink > 1306 Pine St. Paso Robles CA 93446 > 1-(805) 227-7000 1-(800) 974-DISK > http://www.tcsn.net abuse at tcsn.net > > On 3/8/11 11:46 AM, ARIN wrote: >> ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation >> mechanisms by the IANA >> >> ARIN received the following policy proposal and is posting it to the >> Public Policy Mailing List (PPML) in accordance with the Policy >> Development Process. >> >> The ARIN Advisory Council (AC) will review the proposal at their next >> regularly scheduled meeting (if the period before the next regularly >> scheduled meeting is less than 10 days, then the period may be extended >> to the subsequent regularly scheduled meeting). The AC will decide how >> to utilize the proposal and announce the decision to the PPML. >> >> The AC invites everyone to comment on the 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. >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> The ARIN Policy Development Process can be found at: >> https://www.arin.net/policy/pdp.html >> >> Mailing list subscription information can be found >> at: https://www.arin.net/mailing_lists/ >> >> Regards, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation >> mechanisms by the IANA >> >> Proposal Originator: Philip Smith >> co-authors: Alejandro Acosta, Nicolas Antoniello, S. Moonesamy, >> Douglas Onyango, Medel Ramirez, Masato Yamanishi >> >> Proposal Version: 1 >> >> Date: 8 March 2011 >> >> Proposal type: new >> >> Policy term: permanent >> >> Policy statement: >> >> The IANA shall establish a Recovered IPv4 Pool to be utilized post >> RIR IPv4 exhaustion. The Recovered IPv4 Pool will initially contain >> any fragments that may be left over in the IANA. It will also hold >> any space returned to the IANA by any other means. >> >> The Recovered IPv4 Pool will be administered by the IANA. It will >> contain: >> >> a. Any fragments left over in the IANA inventory after the last >> /8s of IPv4 space are delegated to the RIRs >> >> - The IANA inventory excludes "Special use IPv4 addresses" as >> defined in BCP 153 and any addresses allocated by the IANA >> for experimental use. >> >> b. Any IPv4 space returned to the IANA by any means. >> >> The Recovered IPv4 Pool will stay inactive until the first RIR has >> less than a total of a /9 in its inventory of IPv4 address space. >> >> When one of the RIRs declares it has less than a total of a /9 in >> its inventory, the Recovered IPv4 pool will be declared active, and >> IP addresses from the Recovered IPv4 Pool will be allocated as >> follows: >> >> a. Allocations from the IANA may begin once the pool is declared >> active. >> >> b. In each "IPv4 allocation period", each RIR will receive a >> single "IPv4 allocation unit" from the IANA. >> >> c. An "IPv4 allocation period" is defined as a 6-month period >> following 1 March or 1 September in each year. >> >> d. The IANA will calculate the size of the "IPv4 allocation unit" >> at the following times: >> >> - When the Recovered IPv4 Pool is first activated >> - At the beginning of each IPv4 allocation period >> >> To calculate the "IPv4 allocation unit" at these times, the >> IANA will use the following formula: >> >> IPv4 allocation unit = 1/5 of Recovered IPv4 pool, >> rounded down to the next CIDR >> (power-of-2) boundary. >> >> No RIR may get more than this calculation used to determine >> the IPv4 allocation unit even when they can justify a need for >> it. >> >> The minimum "IPv4 allocation unit" size will be a /24. If the >> calculation used to determine the IPv4 allocation unit results >> in a block smaller than a /24, the IANA will not distribute >> any addresses in that IPv4 allocation period. >> >> The IANA may make public announcements of IPv4 address >> transactions that occur under this policy. The IANA will make >> appropriate modifications to the "Internet Protocol V4 Address >> Space" page of the IANA website and may make announcements to its >> own appropriate announcement lists. The IANA announcements will >> be limited to which address ranges, the time of allocation, and to >> which Registry they have been allocated. >> >> Rationale: >> >> The policy provides a mechanism for the ongoing distribution of >> IPv4 address space, while removing the areas that have been >> problematic in previous attemts at this proposal. The proposal: >> >> - Permits regional variation in runout policy amongst RIRs to >> be accounted for in the distribution of the Recovered IPv4 Pool >> >> - Prevents the possibility of a single RIR being eligible to >> be allocated the entire Recovered IPv4 Pool in the first >> (and perhaps only) allocation period >> >> - Removes two areas of policy that have failed to reach >> agreement in previous attempts at this proposal: >> >> - How addresses should be placed in the Recovered IPv4 Pool >> - References to how transfers should or should not take >> place >> >> Timetable for implementation: >> >> Once consensus has been reached in each of the 5 RIR regions, the >> policy will be forwarded to ICANN for approval and then implemented >> by the IANA. >> >> >> >> _______________________________________________ >> 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 Wed Mar 23 16:16:07 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 23 Mar 2011 13:16:07 -0700 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: <4D8A4E3F.7010007@office.tcsn.net> References: <4D76879D.4000508@arin.net> <4D8A4E3F.7010007@office.tcsn.net> Message-ID: <15DCD985-B989-415A-B4AC-79B6FEF0F69D@delong.com> On Mar 23, 2011, at 12:47 PM, Charles O'Hern wrote: > While it seemed a good idea for the last 5 /8's to be handed out equally to the 5 RIR's, for perpetual policy I'm not sure if I like equal distribution over needs-based distribution. > I think that this is intended as policy based on the assumption that need exceeds supply and that all 5 RIRs will have need in excess of 20% of the supply available at IANA at any given time. I agree that policy should incorporate a needs basis absent that condition. > I support policy to address assets returned to IANA set aside for re-allocation, just not the method of equal distribution. > Would you support equal distribution in an environment where need exceeds availability? If not, what mechanism would you support for distributing space in such conditions? > But if the only way to get this passed by all the RIRs is with the equal distribution clause, I would drop my objection. I think its more important to allow IANA policy regarding > returned assets than nitpick about the re-allocation method (as long as the assets are re-allocated). > Assuming, of course, that the idea of IANA having returned resources is not academic in nature. Owen From matthew at matthew.at Wed Mar 23 16:24:42 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 23 Mar 2011 13:24:42 -0700 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: <15DCD985-B989-415A-B4AC-79B6FEF0F69D@delong.com> References: <4D76879D.4000508@arin.net> <4D8A4E3F.7010007@office.tcsn.net> <15DCD985-B989-415A-B4AC-79B6FEF0F69D@delong.com> Message-ID: <4D8A570A.9090304@matthew.at> On 3/23/2011 1:16 PM, Owen DeLong wrote: > > Would you support equal distribution in an environment where need exceeds availability? If not, what > mechanism would you support for distributing space in such conditions? Highest bidder. Matthew Kaufman From gary.buhrmaster at gmail.com Wed Mar 23 17:19:41 2011 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Wed, 23 Mar 2011 21:19:41 +0000 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: <4D8A570A.9090304@matthew.at> References: <4D76879D.4000508@arin.net> <4D8A4E3F.7010007@office.tcsn.net> <15DCD985-B989-415A-B4AC-79B6FEF0F69D@delong.com> <4D8A570A.9090304@matthew.at> Message-ID: On Wed, Mar 23, 2011 at 20:24, Matthew Kaufman wrote: > On 3/23/2011 1:16 PM, Owen DeLong wrote: >> >> Would you support equal distribution in an environment where need exceeds >> availability? If not, what >> mechanism would you support for distributing space in such conditions? > > > Highest bidder. How would the RIRs be expected to valud/bid for the numbers? I suspect that by the time any global policy can be enacted to allow distribution from IANA all regions will have need. Trying to determine which need is greater is likely more complex and politically charged than a simple equal distribution. From charles at office.tcsn.net Wed Mar 23 17:34:57 2011 From: charles at office.tcsn.net (Charles O'Hern) Date: Wed, 23 Mar 2011 14:34:57 -0700 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: <15DCD985-B989-415A-B4AC-79B6FEF0F69D@delong.com> References: <4D76879D.4000508@arin.net> <4D8A4E3F.7010007@office.tcsn.net> <15DCD985-B989-415A-B4AC-79B6FEF0F69D@delong.com> Message-ID: <4D8A6781.7050805@office.tcsn.net> On 3/23/11 1:16 PM, Owen DeLong wrote: > > On Mar 23, 2011, at 12:47 PM, Charles O'Hern wrote: > >> While it seemed a good idea for the last 5 /8's to be handed out equally to the 5 RIR's, for perpetual policy I'm not sure if I like equal distribution over needs-based distribution. >> > I think that this is intended as policy based on the assumption that need exceeds supply and that > all 5 RIRs will have need in excess of 20% of the supply available at IANA at any given time. > > I agree that policy should incorporate a needs basis absent that condition. > >> I support policy to address assets returned to IANA set aside for re-allocation, just not the method of equal distribution. >> > Would you support equal distribution in an environment where need exceeds availability? If not, what > mechanism would you support for distributing space in such conditions? Oh yes, I would support that. > >> But if the only way to get this passed by all the RIRs is with the equal distribution clause, I would drop my objection. I think its more important to allow IANA policy regarding >> returned assets than nitpick about the re-allocation method (as long as the assets are re-allocated). >> > Assuming, of course, that the idea of IANA having returned resources is not academic in nature. I suspect that it will be academic for quite some time, but I like the idea of policy being in place for such a time when it is not. > > Owen > -- Charles O'Hern Network Operations TCSN - The Computer Shop Netlink 1306 Pine St. Paso Robles CA 93446 1-(805) 227-7000 1-(800) 974-DISK http://www.tcsn.net abuse at tcsn.net From owen at delong.com Wed Mar 23 17:33:38 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 23 Mar 2011 14:33:38 -0700 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: <4D8A570A.9090304@matthew.at> References: <4D76879D.4000508@arin.net> <4D8A4E3F.7010007@office.tcsn.net> <15DCD985-B989-415A-B4AC-79B6FEF0F69D@delong.com> <4D8A570A.9090304@matthew.at> Message-ID: On Mar 23, 2011, at 1:24 PM, Matthew Kaufman wrote: > On 3/23/2011 1:16 PM, Owen DeLong wrote: >> >> Would you support equal distribution in an environment where need exceeds availability? If not, what >> mechanism would you support for distributing space in such conditions? > > > Highest bidder. > > Matthew Kaufman I don't think putting the RIRs into a bidding war at IANA makes any sense at all. Owen From hannigan at gmail.com Wed Mar 23 17:54:14 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 23 Mar 2011 17:54:14 -0400 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: References: <4D76879D.4000508@arin.net> <4D8A4E3F.7010007@office.tcsn.net> <15DCD985-B989-415A-B4AC-79B6FEF0F69D@delong.com> <4D8A570A.9090304@matthew.at> Message-ID: On Wed, Mar 23, 2011 at 5:19 PM, Gary Buhrmaster wrote: > On Wed, Mar 23, 2011 at 20:24, Matthew Kaufman wrote: >> On 3/23/2011 1:16 PM, Owen DeLong wrote: >>> >>> Would you support equal distribution in an environment where need exceeds >>> availability? If not, what >>> mechanism would you support for distributing space in such conditions? >> >> >> Highest bidder. > > How would the RIRs be expected to valud/bid for the numbers? The idea is for resource users, that's us, to have cheap and easy access to legacy addresses. Not to pay premiums on space that is already in the inventory. Asking the RIR's to bid on available address space only increases all of our costs and would actually be unfair since the balance sheets of each region are dramatically different. You might be surprised that even one or more of the larger RIR's might be hobbled in such an arrangement. A problem with sending addresses to the IANA and then letting them send them to anyone else is that they are likely to almost immediately end up on the secondary market in another region with weaker controls. What you pay now for addresses will not be the same that you will pay later especially if you are buying addresses that we already had in our inventory back from someone in another region who didn't even have to qualify for them. Without something codified, we're subject to the weakest link and there are some seriously weak links out there in RIR land. > I suspect that by the time any global policy can be enacted to > allow distribution from IANA all regions will have need. ?Trying > to determine which need is greater is likely more complex > and politically charged than a simple equal distribution. That's possible, but I suspect unlikely. LACNIC and AFRINIC have resources for "years" to come depending upon the policies that they implement in the future. APNIC claims that they'll have address for years under their austerity measure. Based on discussions that I've been observing, I'd say "years" is a safe bet in the "developing" regions. They're talking about exclusions of applicants and other mechanisms to insure that noone except someone definitively in their region gets resources. That's quite different that the way that things operate today and will result in higher costs for some of us. In contrast, ARIN has resources for months. Perhaps if all RIR's had to give back anything more than the equivalent of a /9 and we revamped the distribution policy for the IANA that would be more fair? It would insure that all RIR's would run out as close as possible. But even if we like that, a few of the other RIR's will most definitely not like it so we're back to tossing political footballs back and forth like we are now. Best, -M< From matthew at matthew.at Wed Mar 23 20:14:49 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 23 Mar 2011 17:14:49 -0700 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: References: <4D76879D.4000508@arin.net> <4D8A4E3F.7010007@office.tcsn.net> <15DCD985-B989-415A-B4AC-79B6FEF0F69D@delong.com> <4D8A570A.9090304@matthew.at> Message-ID: <4D8A8CF9.5070106@matthew.at> On 3/23/2011 2:19 PM, Gary Buhrmaster wrote: > On Wed, Mar 23, 2011 at 20:24, Matthew Kaufman wrote: >> On 3/23/2011 1:16 PM, Owen DeLong wrote: >>> Would you support equal distribution in an environment where need exceeds >>> availability? If not, what >>> mechanism would you support for distributing space in such conditions? >> >> Highest bidder. > How would the RIRs be expected to valud/bid for the numbers? Last I checked, the RIRs have enough money to do all sorts of other things... why not also bid against each other for address space? (Even easier if they're just proxying bids from people who need the space badly enough) > I suspect that by the time any global policy can be enacted to > allow distribution from IANA all regions will have need. Trying > to determine which need is greater is likely more complex > and politically charged than a simple equal distribution. Highest bidder conveniently solves this problem without all the ethical complications. Matthew Kaufman From matthew at matthew.at Wed Mar 23 20:15:42 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 23 Mar 2011 17:15:42 -0700 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: References: <4D76879D.4000508@arin.net> <4D8A4E3F.7010007@office.tcsn.net> <15DCD985-B989-415A-B4AC-79B6FEF0F69D@delong.com> <4D8A570A.9090304@matthew.at> Message-ID: <4D8A8D2E.104@matthew.at> On 3/23/2011 2:33 PM, Owen DeLong wrote: > On Mar 23, 2011, at 1:24 PM, Matthew Kaufman wrote: > >> On 3/23/2011 1:16 PM, Owen DeLong wrote: >>> Would you support equal distribution in an environment where need exceeds availability? If not, what >>> mechanism would you support for distributing space in such conditions? >> >> Highest bidder. >> >> Matthew Kaufman > I don't think putting the RIRs into a bidding war at IANA makes any sense at all. > Well perhaps not... maybe that argues for not giving the space back to somewhere from which it must then be again redistributed? Matthew Kaufman From scottleibrand at gmail.com Wed Mar 23 20:40:55 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 23 Mar 2011 17:40:55 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: <4D8A07E7.6020906@arin.net> References: <4D8A07E7.6020906@arin.net> Message-ID: <2736336328847355897@unknownmsgid> As I've done a couple times now, I'd like to expand on my own personal opinions on some of the proposals inline below. I'm not speaking for the AC or anyone else: the AC's actions are captured well below, and further detail on the discussion leading up to them will be available in the minutes. On Mar 23, 2011, at 7:47 AM, ARIN wrote: > In accordance with the ARIN Policy Development Process (PDP), the ARIN > Advisory Council (AC) held a meeting on 17 March 2011 and made decisions > about several policy proposals. > > The AC abandoned the following proposals: > > ARIN-prop-132 ISP Sub-assignments Do Not Require Specific Customer > Relationships > > ARIN-prop-133 No Volunteer Services on Behalf of Unaffiliated Address > Blocks > > ARIN-prop-134 Identification of Legitimate Address Holders > > ARIN-prop-135 Clarification of draft policy 2009-3 > > ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks > > The AC voted to abandon ARIN-prop-132 for the following reasons: > - Aggregation is one of the goals of addressing stewardship, this > policy encourages deaggregation, and accelerates routing table growth. > - Creates a situation where the ISP providing the address space is > not in a position to remediate security and abuse issues which may have > significant impact on the larger internet community. > - The AC believes that a discussion about how staff currently handles > this situation is worth having, and suggests the author or a member of > the community submit it as an Open Policy hour topic at the upcoming > ARIN meeting. I was initially sympathetic to this proposal and wanted to make sure the community had a chance to discuss the pros and cons of LIRs that are not ISPs. However, it seems that we have an example of non-ISP LIRs in the RIPE region, and what I've heard from several folks is that such arrangements cause a lot of problems, and probably would not be worth doing here. If anyone takes a different lesson from that, I'd love to hear your experiences as well. > ARIN-prop-133 was abandoned by the AC because there was not significant > support for it on PPML and because the proposal as written is not > something that could be implemented under the existing circumstances > (ICANN MOU, ARIN structure, and the fact that there is no provision for > "alternate" registries in any existing documents, RFCs, or other > approved structures). > > The AC has chosen to abandon ARIN-prop-134. Aside from the author, there > were no statements of support on the mailing list, and the majority of > opinion questioned the problem to be solved. While wording can often be > refined during the policy development process, the problem statement > itself needs further clarification. The abandonment of this proposal is > not to dismiss the discussion. It would just be clearer to refine the > problem statement first and submit a proposal if more clarity and > support can be reached on the mailing list. I believe there is actually a substantive problem here that is worth discussing. At this point I'm not sure if it should be addressed through a new policy proposal, or if it would end up being an ACSP suggestion, though... I have heard from a number of people the concern that some legacy holders are reluctant to sign an LRSA because they perceive it to require giving up rights to use the address space as they see fit. While I largely thing such concerns are exaggerated, they nonetheless could represent a barrier if a legacy holder is attempting to make space available for 8.3 transfer. The current method for ARIN to validate that a legacy holder is indeed the legitimate party responsible for a block is for them to apply for an LRSA, for ARIN to validate all their documentation, and then to sign the LRSA. For parties reluctant to do so, they have the option of waiting to sign the LRSA until the transfer transaction closes. But if an organization looking to receive addresses under 8.3 wants to validate (before they engage their lawyers in contract negotiations) that they are dealing with the legitimate holder of the address block, there is currently no way to do that short of that holder signing an LRSA. So I think the question is whether the community thinks it would be worthwhile for ARIN to develop a process to validate an address holder's legitimacy, the same way they do for the LRSA today, but then simply provide some sort of pre-qualification document to the holder while he goes out looking for a party to transfer the block to. Ideally, IMO, this pre-qualification could be upgraded to a full LRSA with just a couple signatures (i.e. when the 8.3 transfer transaction is otherwise approved). Thoughts? -Scott > The AC abandoned ARIN-prop-135 because: a. The original author wished to > withdraw it, and b. The proposal was an attempt to clarify policy. If > policy is to be changed, the policy itself needs to be rewritten, not > clarified. > > The AC voted to abandon ARIN-prop-136 for the following reasons: > - Overwhelming lack of support within the ARIN community, as evidenced > by discussion on the PPML. > - ARIN staff has indicated that they do not believe that it is > possible to implement this policy due to existing agreements, namely > they can not not-serve our community. > - Today folks have the option of opting out of swip by using RWHOIS > and providing ARIN information about the location of the RHWOIS service > to publish in the SWIP record. This hasn't always gone so well, not all > RWHOIS services are kept up to date and publicly available. Providing > another mechanism for folks to opt out of having records published > publicly in a centralized location, is not in the best interest of the > community, as it would complicate abuse, security and law enforcement > investigations. > The AC encourages further discussion of this topic and would be happy > to work with anyone who believes policy changes in this area are > needed. > > The Advisory Council appreciates the involvement of all community > members who provide input toward a complete discussion of policy > proposals. The AC especially wishes to thank those authors of policy > proposals for their efforts in helping the community address possible > improvements. > > The PDP states, ?Any member of the community, including a proposal > originator, may initiate a Discussion Petition if they are dissatisfied > with the action taken by the Advisory Council regarding any specific > policy proposal.? Proposals 132, 133, 134, 135, and 136 were abandoned > and as such may be petitioned (Discussion Petition) to try to change > them into draft policies for adoption discussion on the Public Policy > Mailing List and at the ARIN XXVIII (October 2011) Public Policy Meeting > (March 7 was the deadline for petitions for the upcoming meeting in San > Juan). The deadline to begin a petition will be five business days after > the AC's draft meeting minutes are published. > > For more information on starting and participating in petitions, see PDP > Petitions at: https://www.arin.net/policy/pdp_petitions.html > > Draft Policy and Policy Proposal texts are available at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Regards, > > Communications and 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. From owen at delong.com Wed Mar 23 22:28:24 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 23 Mar 2011 19:28:24 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: <2736336328847355897@unknownmsgid> References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> Message-ID: > So I think the question is whether the community thinks it would be > worthwhile for ARIN to develop a process to validate an address > holder's legitimacy, the same way they do for the LRSA today, but then > simply provide some sort of pre-qualification document to the holder > while he goes out looking for a party to transfer the block to. > Ideally, IMO, this pre-qualification could be upgraded to a full LRSA > with just a couple signatures (i.e. when the 8.3 transfer transaction > is otherwise approved). > As I have said elsewhere before, I do not believe that ARIN should bend over backwards to aid legacy holders who choose not to participate in the ARIN process by making new policies available to them without an LRSA. If legacy holders want to opt out of new policies by not signing the LRSA (and I'm not saying failing to sign an LRSA actually accomplishes that, just that that seems to be what they think they are gaining), then, they should not be entitled to new policies on a piecemeal basis. Either accept new ARIN policies and sign a contract recognizing ARIN as the authoritative registry, or, don't. As it stands, the LRSA provides substantial advantages over the RSA. I see no advantage to ARIN or to the ARIN community from further extending the ability to monetize address space under ARIN policy in the absence of a signed LRSA, but, I do see significant risk to ARIN in doing so. Owen From gary.buhrmaster at gmail.com Wed Mar 23 22:57:21 2011 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Thu, 24 Mar 2011 02:57:21 +0000 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: <2736336328847355897@unknownmsgid> References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> Message-ID: On Thu, Mar 24, 2011 at 00:40, Scott Leibrand wrote: .... > I have heard from a number of people the concern that some legacy > holders are reluctant to sign an LRSA because they perceive it to > require giving up rights to use the address space as they see fit. ... > So I think the question is whether the community thinks it would be > worthwhile for ARIN to develop a process to validate an address > holder's legitimacy, the same way they do for the LRSA today, but then > simply provide some sort of pre-qualification document to the holder > while he goes out looking for a party to transfer the block to. > Ideally, IMO, this pre-qualification could be upgraded to a full LRSA > with just a couple signatures (i.e. when the 8.3 transfer transaction > is otherwise approved). > > Thoughts? Would an organization that wants to preserve some (potential perceived) rights by not signing an LRSA intend to use the ARIN transfer process? It is probably true that everyone has a price, and at a high enough offer an organizations point of view can be altered, but if the offers of compensation that use the ARIN transfer process get high enough, those that were previously reluctant will swam to ARIN to sign the LRSA to "cash in" quickly while they still can (if they ever intended to so). Gary From scottleibrand at gmail.com Wed Mar 23 23:40:09 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 23 Mar 2011 20:40:09 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> Message-ID: On Wed, Mar 23, 2011 at 7:57 PM, Gary Buhrmaster wrote: > On Thu, Mar 24, 2011 at 00:40, Scott Leibrand wrote: > .... >> I have heard from a number of people the concern that some legacy >> holders are reluctant to sign an LRSA because they perceive it to >> require giving up rights to use the address space as they see fit. > ... >> So I think the question is whether the community thinks it would be >> worthwhile for ARIN to develop a process to validate an address >> holder's legitimacy, the same way they do for the LRSA today, but then >> simply provide some sort of pre-qualification document to the holder >> while he goes out looking for a party to transfer the block to. >> Ideally, IMO, this pre-qualification could be upgraded to a full LRSA >> with just a couple signatures (i.e. when the 8.3 transfer transaction >> is otherwise approved). >> >> Thoughts? > > Would an organization that wants to preserve some (potential > perceived) rights by not signing an LRSA intend to use the ARIN > transfer process? > > It is probably true that everyone has a price, and at a high > enough offer an organizations point of view can be altered, > but if the offers of compensation that use the ARIN transfer > process get high enough, those that were previously reluctant > will swam to ARIN to sign the LRSA to "cash in" quickly while > they still can (if they ever intended to so). I suspect there are some who think they can get higher prices transferring outside the ARIN process. Time (and likely lawsuits) will tell if they're right. But I'm more interested in those who aren't sure if they want to be in the ARIN system, but are more than willing to find a willing buyer and sign an LRSA to cover their space (for 5 minutes while they finalize an 8.3 transfer that's already approved). But to get to that point, they need to prove to potential transfer recipients that they're the legitimate holder of the address space they say they have. I'd rather make it as easy as possible for such folks to transfer their space to someone who needs it, is willing to pay for it, and is willing to work within the system (under RSA). -Scott From owen at delong.com Thu Mar 24 01:39:46 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 23 Mar 2011 22:39:46 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> Message-ID: <15AE4A1C-BB72-4C9D-B75A-64FA5D1B965D@delong.com> On Mar 23, 2011, at 8:40 PM, Scott Leibrand wrote: > On Wed, Mar 23, 2011 at 7:57 PM, Gary Buhrmaster > wrote: >> On Thu, Mar 24, 2011 at 00:40, Scott Leibrand wrote: >> .... >>> I have heard from a number of people the concern that some legacy >>> holders are reluctant to sign an LRSA because they perceive it to >>> require giving up rights to use the address space as they see fit. >> ... >>> So I think the question is whether the community thinks it would be >>> worthwhile for ARIN to develop a process to validate an address >>> holder's legitimacy, the same way they do for the LRSA today, but then >>> simply provide some sort of pre-qualification document to the holder >>> while he goes out looking for a party to transfer the block to. >>> Ideally, IMO, this pre-qualification could be upgraded to a full LRSA >>> with just a couple signatures (i.e. when the 8.3 transfer transaction >>> is otherwise approved). >>> >>> Thoughts? >> >> Would an organization that wants to preserve some (potential >> perceived) rights by not signing an LRSA intend to use the ARIN >> transfer process? >> >> It is probably true that everyone has a price, and at a high >> enough offer an organizations point of view can be altered, >> but if the offers of compensation that use the ARIN transfer >> process get high enough, those that were previously reluctant >> will swam to ARIN to sign the LRSA to "cash in" quickly while >> they still can (if they ever intended to so). > > I suspect there are some who think they can get higher prices > transferring outside the ARIN process. Time (and likely lawsuits) > will tell if they're right. > > But I'm more interested in those who aren't sure if they want to be in > the ARIN system, but are more than willing to find a willing buyer and > sign an LRSA to cover their space (for 5 minutes while they finalize > an 8.3 transfer that's already approved). But to get to that point, > they need to prove to potential transfer recipients that they're the > legitimate holder of the address space they say they have. > If they are intent on transferring their space, there's nothing lost in signing the LRSA. If they don't want to sign the LRSA, I see no reason ARIN should be seeking additional ways to help them take advantage of new policies to monetize their space. If buyers want to have that assurance up front or demand a lower price, I think that is a matter for the market to negotiate. > I'd rather make it as easy as possible for such folks to transfer > their space to someone who needs it, is willing to pay for it, and is > willing to work within the system (under RSA). > I'm all for making it as easy as possible within limits. Providing an assurance service without a contract goes beyond those limits. You're basically talking about operating a title insurance agency where you have no contract with the holder of the title you are insuring. Owen From hannigan at gmail.com Thu Mar 24 01:47:14 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 24 Mar 2011 01:47:14 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> Message-ID: On Wed, Mar 23, 2011 at 11:40 PM, Scott Leibrand wrote: > I suspect there are some who think they can get higher prices > transferring outside the ARIN process. ?Time (and likely lawsuits) > will tell if they're right. The new benchmark is $20 per address. http://www.totaltele.com/view.aspx?ID=463504&G=5&C=5&page=2 Best, -M< From hannigan at gmail.com Thu Mar 24 01:48:07 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 24 Mar 2011 01:48:07 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> Message-ID: On Thu, Mar 24, 2011 at 1:47 AM, Martin Hannigan wrote: > On Wed, Mar 23, 2011 at 11:40 PM, Scott Leibrand > wrote: > >> I suspect there are some who think they can get higher prices >> transferring outside the ARIN process. ?Time (and likely lawsuits) >> will tell if they're right. > > The new benchmark is $20 per address. Argh. Correction. It's $11, at least publicly. > > http://www.totaltele.com/view.aspx?ID=463504&G=5&C=5&page=2 > > > Best, > > -M< > From scottleibrand at gmail.com Thu Mar 24 01:57:29 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 23 Mar 2011 22:57:29 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> Message-ID: <4309103786012542480@unknownmsgid> Thanks. That's the first large confirmed IPv4 address sale I've seen reported between two such companies. But I wonder how they can transfer 666,624 addresses under 8.3, which requires that the recipient "demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies." That would seem to allow 512k or 1M addresses to be transferred, but nothing in between... Scott On Mar 23, 2011, at 10:48 PM, Martin Hannigan wrote: On Thu, Mar 24, 2011 at 1:47 AM, Martin Hannigan wrote: On Wed, Mar 23, 2011 at 11:40 PM, Scott Leibrand wrote: I suspect there are some who think they can get higher prices transferring outside the ARIN process. Time (and likely lawsuits) will tell if they're right. The new benchmark is $20 per address. Argh. Correction. It's $11, at least publicly. http://www.totaltele.com/view.aspx?ID=463504&G=5&C=5&page=2 Best, -M< -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.buhrmaster at gmail.com Thu Mar 24 01:58:43 2011 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Wed, 23 Mar 2011 22:58:43 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> Message-ID: On Wed, Mar 23, 2011 at 20:40, Scott Leibrand wrote: .. > But I'm more interested in those who aren't sure if they want to > be in the ARIN system ... > I'd rather make it as easy as possible for such folks to transfer > their space to someone who needs it, is willing to pay for it, and is > willing to work within the system (under RSA). I agree with Owen, and if those organizations want to and intend to work with(in) the ARIN processes they should expect to have to sign the agreements that state so accordingly (the (L)RSA). While honest people may disagree, it is my opinion that the LRSA is not onerous (if one's goal is the be part of the community). The time for dithering is approaching an end. Gary From bill at herrin.us Thu Mar 24 05:07:31 2011 From: bill at herrin.us (William Herrin) Date: Thu, 24 Mar 2011 05:07:31 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: <2736336328847355897@unknownmsgid> References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> Message-ID: On Wed, Mar 23, 2011 at 8:40 PM, Scott Leibrand wrote: > As I've done a couple times now, I'd like to expand on my own personal > opinions on some of the proposals inline below. As always, thanks. And my thanks to Owen and Marty as well, for choosing to help those of us in the general community understand your and their personal thought processes during votes on the proposals. You exhibit a commitment to an open process above and beyond what some of your colleagues have been willing to do. > I have heard from a number of people the concern that some legacy > holders are reluctant to sign an LRSA because they perceive it to > require giving up rights to use the address space as they see fit. > While I largely thing such concerns are exaggerated, they nonetheless > could represent a barrier if a legacy holder is attempting to make > space available for 8.3 transfer. > So I think the question is whether the community thinks it would be > worthwhile for ARIN to develop a process to validate an address > holder's legitimacy, the same way they do for the LRSA today, but then > simply provide some sort of pre-qualification document to the holder > while he goes out looking for a party to transfer the block to. Speaking as a legacy holder reluctant to sign an LRSA, I personally don't have a problem with signing an LRSA when/if I decide I want to transfer addresses. WRT reluctance on the part of the buyer... beggars can't be choosers. There are only so many addresses which will be on the market at any given time. Addresses that aren't under contract may end up selling for less than addresses under contract but they'll still sell. The recipient can use the addresses as soon as I sign a letter of authorization. It's not a big deal if the completed transfer paperwork takes a little while as ARIN validates my claim. I tend to agree with the others who've said that ARIN really shouldn't be doing a lot of work on behalf of registrants who aren't under contract. In my mind, ARIN made a basic commitment to maintain the registrations it inherited without new conditions. However, I think this sort of transfer qualification activity goes beyond that maintenance. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From john.sweeting at twcable.com Thu Mar 24 08:45:38 2011 From: john.sweeting at twcable.com (Sweeting, John) Date: Thu, 24 Mar 2011 08:45:38 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: Message-ID: Bill, I just want to point out that every single AC member is equally committed to the priniciples of openness and transparency. There are AC members with over a decade of duty to the community and for them to be slighted is just not right. The AC is made up of 15 very diverse and talented professionals who have cared enough over the years to volunteer many hours of their life to support those priniciples. I would like to publicly state that I am proud to serve with each of the members, it is indeed a great privilege. Thanks, John ++ On 3/24/11 5:07 AM, "William Herrin" wrote: On Wed, Mar 23, 2011 at 8:40 PM, Scott Leibrand wrote: > As I've done a couple times now, I'd like to expand on my own personal > opinions on some of the proposals inline below. As always, thanks. And my thanks to Owen and Marty as well, for choosing to help those of us in the general community understand your and their personal thought processes during votes on the proposals. You exhibit a commitment to an open process above and beyond what some of your colleagues have been willing to do. > I have heard from a number of people the concern that some legacy > holders are reluctant to sign an LRSA because they perceive it to > require giving up rights to use the address space as they see fit. > While I largely thing such concerns are exaggerated, they nonetheless > could represent a barrier if a legacy holder is attempting to make > space available for 8.3 transfer. > So I think the question is whether the community thinks it would be > worthwhile for ARIN to develop a process to validate an address > holder's legitimacy, the same way they do for the LRSA today, but then > simply provide some sort of pre-qualification document to the holder > while he goes out looking for a party to transfer the block to. Speaking as a legacy holder reluctant to sign an LRSA, I personally don't have a problem with signing an LRSA when/if I decide I want to transfer addresses. WRT reluctance on the part of the buyer... beggars can't be choosers. There are only so many addresses which will be on the market at any given time. Addresses that aren't under contract may end up selling for less than addresses under contract but they'll still sell. The recipient can use the addresses as soon as I sign a letter of authorization. It's not a big deal if the completed transfer paperwork takes a little while as ARIN validates my claim. I tend to agree with the others who've said that ARIN really shouldn't be doing a lot of work on behalf of registrants who aren't under contract. In my mind, ARIN made a basic commitment to maintain the registrations it inherited without new conditions. However, I think this sort of transfer qualification activity goes beyond that maintenance. 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. ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. From cgrundemann at gmail.com Thu Mar 24 11:26:30 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 24 Mar 2011 09:26:30 -0600 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> Message-ID: On Thu, Mar 24, 2011 at 03:07, William Herrin wrote: > WRT reluctance on the part of the buyer... beggars can't be choosers. > There are only so many addresses which will be on the market at any > given time. Addresses that aren't under contract may end up selling > for less than addresses under contract but they'll still sell. The > recipient can use the addresses as soon as I sign a letter of > authorization. It's not a big deal if the completed transfer paperwork > takes a little while as ARIN validates my claim. The primary concern that I have heard raised (and did not catch myself on initial thoughts) is not the time that ARIN paperwork might take but rather that the outcome may not be what the recipient was promised. A scenario for illustration: Org B needs addresses. Org A tells Org B that they have addresses. Orgs A and B come to an agreement on price, etc. Org A writes an LoA for Org B to begin using the addresses. Org A files an LRSA with ARIN. ARIN finds that Org A is not authorized to hold nor transfer the addresses in question. Org B now has a number of problems... - wasted time - wasted money - using addresses that they must return - etc... I am not trying to argue one way or the other, just pointing out the piece of this that eluded me at first in case others missed it as well. ~Chris From hannigan at gmail.com Thu Mar 24 11:37:44 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 24 Mar 2011 11:37:44 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> Message-ID: On Thu, Mar 24, 2011 at 11:26 AM, Chris Grundemann wrote: > On Thu, Mar 24, 2011 at 03:07, William Herrin wrote: >> WRT reluctance on the part of the buyer... beggars can't be choosers. >> There are only so many addresses which will be on the market at any >> given time. Addresses that aren't under contract may end up selling >> for less than addresses under contract but they'll still sell. The >> recipient can use the addresses as soon as I sign a letter of >> authorization. It's not a big deal if the completed transfer paperwork >> takes a little while as ARIN validates my claim. > > The primary concern that I have heard raised (and did not catch myself > on initial thoughts) is not the time that ARIN paperwork might take > but rather that the outcome may not be what the recipient was > promised. > > A scenario for illustration: > Org B needs addresses. > Org A tells Org B that they have addresses. > Orgs A and B come to an agreement on price, etc. > Org A writes an LoA for Org B to begin using the addresses. > Org A files an LRSA with ARIN. > ARIN finds that Org A is not authorized to hold nor transfer the > addresses in question. > Org B now has a number of problems... > ?- wasted time > ?- wasted money > ?- using addresses that they must return > ?- etc... > > I am not trying to argue one way or the other, just pointing out the > piece of this that eluded me at first in case others missed it as > well. This is a fairly complex issue, but making it easy for people to do business and be compliant at the same time should be a priority. Best, -M< From bill at herrin.us Thu Mar 24 12:36:26 2011 From: bill at herrin.us (William Herrin) Date: Thu, 24 Mar 2011 12:36:26 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> Message-ID: On Thu, Mar 24, 2011 at 11:26 AM, Chris Grundemann wrote: > On Thu, Mar 24, 2011 at 03:07, William Herrin wrote: >> WRT reluctance on the part of the buyer... beggars can't be choosers. >> There are only so many addresses which will be on the market at any >> given time. Addresses that aren't under contract may end up selling >> for less than addresses under contract but they'll still sell. The >> recipient can use the addresses as soon as I sign a letter of >> authorization. It's not a big deal if the completed transfer paperwork >> takes a little while as ARIN validates my claim. > > The primary concern that I have heard raised (and did not catch myself > on initial thoughts) is not the time that ARIN paperwork might take > but rather that the outcome may not be what the recipient was > promised. > > A scenario for illustration: > Org B needs addresses. > Org A tells Org B that they have addresses. > Orgs A and B come to an agreement on price, etc. > Org A writes an LoA for Org B to begin using the addresses. > Org A files an LRSA with ARIN. > ARIN finds that Org A is not authorized to hold nor transfer the > addresses in question. > Org B now has a number of problems... > ?- wasted time > ?- wasted money > ?- using addresses that they must return > ?- etc... Hi Chris, So you offer an ARIN validation service for a fee. But I don't want to pay a fee. I might not find a buyer at the price I want. When I find a buyer at the price I want, I want him to pay the fee. No hassle for me. Shall ARIN validate for free so we can avoid this problem as well? Perhaps they should guarantee that they won't revoke addresses if the validation shows fraud so that folks can feel safe about asking ARIN to validate the registration? How far does the slippery slope slide? Look at it in real estate terms: You don't produce a deed in order to list a house for sale. You check the tax registration and unless it's funny you proceed. The deed only shows up at closing after everything else is done. And everybody understands that the deed must show up at closing. If it doesn't, the seller is in breach with the normal remedies at law. On Thu, Mar 24, 2011 at 8:45 AM, Sweeting, John wrote: > I just want to point out that every single AC member is >equally committed to the priniciples of openness and >transparency. There are AC members with over a decade Hi John, Elected office is indeed meritorious civic service. However, Scott has gone beyond the minimum. By publicly sharing his thoughts on the proposals and encouraging discussion and debate surrounding those views, he has demonstrated an extraordinary commitment to openness that I think deserves praise. He sets a standard than any present or future AC member could aspire to. > of duty to the community and for them to be > slighted is just not right. Praising someone for going above and beyond slights the folks who are meeting the minimum requirement? Yes, I suppose it does. Tough. Regards. Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From john.sweeting at gmail.com Thu Mar 24 14:51:05 2011 From: john.sweeting at gmail.com (John Sweeting) Date: Thu, 24 Mar 2011 14:51:05 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> Message-ID: On Thu, Mar 24, 2011 at 12:36 PM, William Herrin wrote: > On Thu, Mar 24, 2011 at 11:26 AM, Chris Grundemann > wrote: > > On Thu, Mar 24, 2011 at 03:07, William Herrin wrote: > >> WRT reluctance on the part of the buyer... beggars can't be choosers. > >> There are only so many addresses which will be on the market at any > >> given time. Addresses that aren't under contract may end up selling > >> for less than addresses under contract but they'll still sell. The > >> recipient can use the addresses as soon as I sign a letter of > >> authorization. It's not a big deal if the completed transfer paperwork > >> takes a little while as ARIN validates my claim. > > > > The primary concern that I have heard raised (and did not catch myself > > on initial thoughts) is not the time that ARIN paperwork might take > > but rather that the outcome may not be what the recipient was > > promised. > > > > A scenario for illustration: > > Org B needs addresses. > > Org A tells Org B that they have addresses. > > Orgs A and B come to an agreement on price, etc. > > Org A writes an LoA for Org B to begin using the addresses. > > Org A files an LRSA with ARIN. > > ARIN finds that Org A is not authorized to hold nor transfer the > > addresses in question. > > Org B now has a number of problems... > > - wasted time > > - wasted money > > - using addresses that they must return > > - etc... > > Hi Chris, > > So you offer an ARIN validation service for a fee. But I don't want to > pay a fee. I might not find a buyer at the price I want. When I find a > buyer at the price I want, I want him to pay the fee. No hassle for > me. Shall ARIN validate for free so we can avoid this problem as well? > Perhaps they should guarantee that they won't revoke addresses if the > validation shows fraud so that folks can feel safe about asking ARIN > to validate the registration? > > How far does the slippery slope slide? > > Look at it in real estate terms: You don't produce a deed in order to > list a house for sale. You check the tax registration and unless it's > funny you proceed. The deed only shows up at closing after everything > else is done. And everybody understands that the deed must show up at > closing. If it doesn't, the seller is in breach with the normal > remedies at law. > > > > On Thu, Mar 24, 2011 at 8:45 AM, Sweeting, John > wrote: > > I just want to point out that every single AC member is > >equally committed to the priniciples of openness and > >transparency. There are AC members with over a decade > > Hi John, > > Elected office is indeed meritorious civic service. However, Scott has > gone beyond the minimum. By publicly sharing his thoughts on the > proposals and encouraging discussion and debate surrounding those > views, he has demonstrated an extraordinary commitment to openness > that I think deserves praise. He sets a standard than any present or > future AC member could aspire to. > ***JCS***Thank you for complimenting Scott on his availability to post on PPML and his willingness to share his thoughts and ideas. He is indeed a very valuable member of the AC. > > > > of duty to the community and for them to be > > slighted is just not right. > > Praising someone for going above and beyond slights the folks who are > meeting the minimum requirement? Yes, I suppose it does. Tough. > ***JCS***There is no need to slight someone in order to praise another. As I said earlier, every member of the AC is very valuable and brings their own special qualities to the AC. Thanks again for taking the time to compliment members of the AC. > > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Mar 24 15:45:29 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 24 Mar 2011 13:45:29 -0600 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> Message-ID: Sent from my iPad On Mar 24, 2011, at 9:26 AM, Chris Grundemann wrote: > On Thu, Mar 24, 2011 at 03:07, William Herrin wrote: >> WRT reluctance on the part of the buyer... beggars can't be choosers. >> There are only so many addresses which will be on the market at any >> given time. Addresses that aren't under contract may end up selling >> for less than addresses under contract but they'll still sell. The >> recipient can use the addresses as soon as I sign a letter of >> authorization. It's not a big deal if the completed transfer paperwork >> takes a little while as ARIN validates my claim. > > The primary concern that I have heard raised (and did not catch myself > on initial thoughts) is not the time that ARIN paperwork might take > but rather that the outcome may not be what the recipient was > promised. > > A scenario for illustration: > Org B needs addresses. > Org A tells Org B that they have addresses. > Orgs A and B come to an agreement on price, etc. > Org A writes an LoA for Org B to begin using the addresses. > Org A files an LRSA with ARIN. > ARIN finds that Org A is not authorized to hold nor transfer the > addresses in question. > Org B now has a number of problems... > - wasted time > - wasted money > - using addresses that they must return > - etc... > > I am not trying to argue one way or the other, just pointing out the > piece of this that eluded me at first in case others missed it as > well. > ~Chris > _______________________________________________ > 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. I can't speak for others, but, I clearly understood this from Scott's original statements. My opinion remains unchanged: Org B if they ask ARIN will receive an indication that the addresses need to be vetted before they can be transferred. I am not interested in putting ARIN at risk to prevent Org B suffering the expected consequences of failing to do due diligence. Org A, if they want their addresses vetted so that Org B doesn't look askance at the deal when they do their due diligence should sign the LRSA for the addresses they plan to transfer, or, should expect Org B to want some assurances and indemnification on the deal and likely a lower price than what they could find for LRSA/RSA-covered addresses. I regard this as a prime carrot to use for encouraging organizations who want to monetize their address space to sign the (L)RSA. Owen From tedm at ipinc.net Thu Mar 24 16:33:06 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 24 Mar 2011 13:33:06 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> Message-ID: <4D8BAA82.8070101@ipinc.net> Org B can do due diligence with ARIN before the purchase and if they don't and org a turns out to be a pig in a poke then org B deserves what they get, in my book. Ted On 3/24/2011 8:26 AM, Chris Grundemann wrote: > On Thu, Mar 24, 2011 at 03:07, William Herrin wrote: >> WRT reluctance on the part of the buyer... beggars can't be choosers. >> There are only so many addresses which will be on the market at any >> given time. Addresses that aren't under contract may end up selling >> for less than addresses under contract but they'll still sell. The >> recipient can use the addresses as soon as I sign a letter of >> authorization. It's not a big deal if the completed transfer paperwork >> takes a little while as ARIN validates my claim. > > The primary concern that I have heard raised (and did not catch myself > on initial thoughts) is not the time that ARIN paperwork might take > but rather that the outcome may not be what the recipient was > promised. > > A scenario for illustration: > Org B needs addresses. > Org A tells Org B that they have addresses. > Orgs A and B come to an agreement on price, etc. > Org A writes an LoA for Org B to begin using the addresses. > Org A files an LRSA with ARIN. > ARIN finds that Org A is not authorized to hold nor transfer the > addresses in question. > Org B now has a number of problems... > - wasted time > - wasted money > - using addresses that they must return > - etc... > > I am not trying to argue one way or the other, just pointing out the > piece of this that eluded me at first in case others missed it as > well. > ~Chris > _______________________________________________ > 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 gary.buhrmaster at gmail.com Thu Mar 24 16:58:05 2011 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Thu, 24 Mar 2011 20:58:05 +0000 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> Message-ID: On Thu, Mar 24, 2011 at 15:26, Chris Grundemann wrote: .... > Org B now has a number of problems... > ?- wasted time > ?- wasted money > ?- using addresses that they must return > ?- etc... And Org A has a number of problems, which may include various claims by Org B for expenses. I think we have to presume that Org A and Org B will both have lawyers, and due diligence will occur somewhere. Contract negotiations are well known ground. Fraudulent sellers and buyers are a fact of life in the process, and again, well understood. The Org that chooses to go into a contract without a lawyer chooses a different risk. Their org, their choice. Gary From tedm at ipinc.net Thu Mar 24 17:07:48 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 24 Mar 2011 14:07:48 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> Message-ID: <4D8BB2A4.4080401@ipinc.net> On 3/23/2011 10:48 PM, Martin Hannigan wrote: > On Thu, Mar 24, 2011 at 1:47 AM, Martin Hannigan wrote: >> On Wed, Mar 23, 2011 at 11:40 PM, Scott Leibrand >> wrote: >> >>> I suspect there are some who think they can get higher prices >>> transferring outside the ARIN process. Time (and likely lawsuits) >>> will tell if they're right. >> >> The new benchmark is $20 per address. > > > Argh. Correction. It's $11, at least publicly. > > > >> >> http://www.totaltele.com/view.aspx?ID=463504&G=5&C=5&page=2 >> >> Can I be correct in assuming a few things: The story said most of these numbers are ready to use. That would indicate Nortel had been violating the ARIN minimum utilization requirements for years. Since ARIN had not done an audit that pulled these addresses from Nortel am I correct in assuming that they had no legal ability to do so - ergo, this is a Legacy block? If it is a legacy block am I also correct in assuming that once this "sale" completes that ARIN is going to realize a spike in it's income, as this block is now going to be subject to yearly registration renewal fees? If all of that is true then as these sales happen and more of these legacy blocks come online, ARIN's income from fees will rise. Since ARIN is obligated to not generate a profit can I assume that the excess income will result in fee reductions for the rest of us? After all when your friendly local government gets increased tax revenue it reduces taxes, correct? Or have I just been out in the sun too long ;-) Ted From farmer at umn.edu Thu Mar 24 19:28:21 2011 From: farmer at umn.edu (David Farmer) Date: Thu, 24 Mar 2011 18:28:21 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: <4D8BAA82.8070101@ipinc.net> References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> <4D8BAA82.8070101@ipinc.net> Message-ID: <4D8BD395.9080509@umn.edu> On 3/24/11 15:33 CDT, Ted Mittelstaedt wrote: > > Org B can do due diligence with ARIN before the purchase and > if they don't and org a turns out to be a pig in a poke then > org B deserves what they get, in my book. If Org B ask ARIN about Org A, I'm not sure ARIN would tell them anything, at least nothing more than is already published in Whois. So what kind of due diligence is it that you think Org B would or should do with ARIN? > Ted > > On 3/24/2011 8:26 AM, Chris Grundemann wrote: ... >> A scenario for illustration: >> Org B needs addresses. >> Org A tells Org B that they have addresses. >> Orgs A and B come to an agreement on price, etc. >> Org A writes an LoA for Org B to begin using the addresses. >> Org A files an LRSA with ARIN. >> ARIN finds that Org A is not authorized to hold nor transfer the >> addresses in question. >> Org B now has a number of problems... >> - wasted time >> - wasted money >> - using addresses that they must return >> - etc... >> >> I am not trying to argue one way or the other, just pointing out the >> piece of this that eluded me at first in case others missed it as >> well. >> ~Chris -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From bensons at queuefull.net Thu Mar 24 20:16:14 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 24 Mar 2011 19:16:14 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: <2736336328847355897@unknownmsgid> References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> Message-ID: <9C29520B-E77C-4954-B67C-AF1E3EB0D121@queuefull.net> Hi, Scott. On Mar 23, 2011, at 7:40 PM, Scott Leibrand wrote: > As I've done a couple times now, I'd like to expand on my own personal > opinions on some of the proposals inline below. Thank you for your feedback, Scott. I appreciate your contribution to the conversation. > I'm not speaking for > the AC or anyone else: the AC's actions are captured well below, and > further detail on the discussion leading up to them will be available > in the minutes. Do you know when the AC meeting minutes will be posted? The only 2011 meeting minutes currently posted at https://www.arin.net/about_us/ac/index.html are from the January meeting (under the outdated heading "2010"). Does it typically take a month(+) to publish these? >> The AC voted to abandon ARIN-prop-132 for the following reasons: >> - Aggregation is one of the goals of addressing stewardship, this >> policy encourages deaggregation, and accelerates routing table growth. >> - Creates a situation where the ISP providing the address space is >> not in a position to remediate security and abuse issues which may have >> significant impact on the larger internet community. >> - The AC believes that a discussion about how staff currently handles >> this situation is worth having, and suggests the author or a member of >> the community submit it as an Open Policy hour topic at the upcoming >> ARIN meeting. > > I was initially sympathetic to this proposal and wanted to make sure > the community had a chance to discuss the pros and cons of LIRs that > are not ISPs. However, it seems that we have an example of non-ISP > LIRs in the RIPE region, and what I've heard from several folks is > that such arrangements cause a lot of problems, and probably would not > be worth doing here. If anyone takes a different lesson from that, > I'd love to hear your experiences as well. I'm confused by your choice of words, and I think it would be useful to clarify. The current NRPM language allows ISPs to assign addresses to their customers, but doesn't define what "customer" means. The text of proposal 132 does not explicitly create "non-ISP LIRs", but explicitly allows an ISP to act as a LIR for customers that might not be receiving "traditional connectivity" services from that ISP. Granted, this is a nuance - but it's worth noting, for operational purposes, that the proposal wouldn't necessarily allow non-ISPs to become LIRs. Having said that, I'm frankly not sure this matters. As I mentioned above, the current policy doesn't define "customer" and I posit that an ISP is already free to engage in this behavior. Proposal 132 was intended to clarify existing policy. The AC "reasons" given for abandoning this proposal seem to suggest a preference for the opposite of 132; should we expect such a proposal in the near future? >> The AC has chosen to abandon ARIN-prop-134. Aside from the author, there >> were no statements of support on the mailing list, and the majority of >> opinion questioned the problem to be solved. While wording can often be >> refined during the policy development process, the problem statement >> itself needs further clarification. The abandonment of this proposal is >> not to dismiss the discussion. It would just be clearer to refine the >> problem statement first and submit a proposal if more clarity and >> support can be reached on the mailing list. > > I believe there is actually a substantive problem here that is worth > discussing. At this point I'm not sure if it should be addressed > through a new policy proposal, or if it would end up being an ACSP > suggestion, though... I don't have much to say about this, except that I think the standard should be documented in an open and transparent way. If you think there is an alteration that would make prop 134 more interesting to the "ARIN community", please feel free to submit a new version. I have no objections to my proposal text being used and/or adapted by anybody here. Cheers, -Benson From bensons at queuefull.net Thu Mar 24 20:26:37 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 24 Mar 2011 19:26:37 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> Message-ID: On Mar 24, 2011, at 12:58 AM, Gary Buhrmaster wrote: > While honest people > may disagree, it is my opinion that the LRSA is not > onerous (if one's goal is the be part of the community). > The time for dithering is approaching an end. I'm interested in this term "community" which seems to be so highly valued on PPML. Does "community" refer to participants in PPML? Attendees at ARIN meetings? Address holders? The larger community of address stakeholders (vendors, operators, users) in the ARIN region? Or the entire population of the region? My perspective is that a small community at ARIN makes policy that affects the larger population of stakeholders, and frequently conflates the two. Cheers, -Benson From tedm at ipinc.net Thu Mar 24 20:29:24 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 24 Mar 2011 17:29:24 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: <4D8BD395.9080509@umn.edu> References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> <4D8BAA82.8070101@ipinc.net> <4D8BD395.9080509@umn.edu> Message-ID: <4D8BE1E4.3030902@ipinc.net> On 3/24/2011 4:28 PM, David Farmer wrote: > On 3/24/11 15:33 CDT, Ted Mittelstaedt wrote: >> >> Org B can do due diligence with ARIN before the purchase and >> if they don't and org a turns out to be a pig in a poke then >> org B deserves what they get, in my book. > > If Org B ask ARIN about Org A, I'm not sure ARIN would tell them > anything, at least nothing more than is already published in Whois. So > what kind of due diligence is it that you think Org B would or should do > with ARIN? > This is what LOAs are for. Most likely this kind of transaction would work as follows: Org A advertises out it's IPv4 Org B sees it and contacts Org A. They feel each other out until they arrive at a price that is contingent on validity. Org A then gives a LOI (letter of intent) listing pricing and a deadline, and also gives Org B a LOA allowing Org B to act as Org A's agent in dealing with ARIN. Org B gives Org A an NDA that promises not to reveal Org A's dirty underwear to the world. Org B submits the LOA to ARIN and ARIN reports back that everything is OK. Org B then pays Org A and gets handed a second LOA that allows them to execute all the paperwork with ARIN. Org B does all that and signs the transfer docs for Org A and then gets the IP addressing from ARIN. A LOA can easily be written to legally designate Org B to act as a proxy for Org A in dealing with ARIN. If ARIN refused to divulge Org A's dirty underwear to Org B then it would be the same as ARIN refusing to divulge Org A's dirty underwear to Org A. Anyway, this is how you would do it directly. Another way would be to find an impartial 3rd party attorney that both Org A and Org B would sign over power of attorney to and the 3rd party would escrow the money and handle the transaction. But of course this just fattens up the wallets of some lawyer who probably already has swimming pools full of money anyway. Both of these scenarios are legally equivalent from ARIN's POV of having Org A ask about itself, or Org B ask about itself. Org B can say to ARIN "I'm the legal equivalent of Org A, are these numbers I think I have, valid" Then Org B can say to ARIN "I'm going to execute a transfer for XXX numbers and here is my utilization justification will you allow it?" If the answer to both questions is yes, then your good to go. Obviously ARIN could require Org A to sign an LSRA as a condition of transfer, but this is a pointless exercise, since if an LOA was in place Org B could do that for Org A anyway, 2 minutes before signing the transfer paperwork and the actual RSA. And in any case the RIR's incentive is to get the numbers out of Org A's control since Org A is just sitting on them doing nothing with them. Although several posters said that if they were Org B they could insist Org A sign a LSRA before selling, this is actually not a likely scenario. The reason is that Org A is in the power position. They have something that Org B cannot get from anyone else. They have absolutely no incentive to deal with the RIR. If Org B doesn't like this then they can stuff it and go elsewhere for their IPv4 addresses. Org A's can simply sit back and do nothing at all and let Org B do all the gruntwork and deal with the RIR and the paperwork. I've been in these scenarios with other stuff that Org A is so lazy that they don't even bother writing the LOA and the LOI and the NDA they make Org B do that, then if they like it they sign it. It's like buying a used car without a title. I've bought a number of them like this over the years. You save a lot of money because most buyers are scared to death if the stuff isn't handed to them on a silver platter. The DMV will tell you if the VIN is stolen and if it is not, then you buy the car and file for lost title. But the chances of getting the seller to actually bother to file for lost title themselves is almost nil. Ted >> Ted >> >> On 3/24/2011 8:26 AM, Chris Grundemann wrote: > ... >>> A scenario for illustration: >>> Org B needs addresses. >>> Org A tells Org B that they have addresses. >>> Orgs A and B come to an agreement on price, etc. >>> Org A writes an LoA for Org B to begin using the addresses. >>> Org A files an LRSA with ARIN. >>> ARIN finds that Org A is not authorized to hold nor transfer the >>> addresses in question. >>> Org B now has a number of problems... >>> - wasted time >>> - wasted money >>> - using addresses that they must return >>> - etc... >>> >>> I am not trying to argue one way or the other, just pointing out the >>> piece of this that eluded me at first in case others missed it as >>> well. >>> ~Chris > From rudi.daniel at gmail.com Thu Mar 24 20:51:56 2011 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Thu, 24 Mar 2011 21:51:56 -0300 Subject: [arin-ppml] ARIN-PPML Digest, Vol 69, Issue 21 In-Reply-To: References: Message-ID: > > Was this the first widely reported public transaction? > RD > > Can I be correct in assuming a few things: > > The story said most of these numbers are ready to use. That would > indicate Nortel had been violating the ARIN minimum utilization > requirements for years. Since ARIN had not done an audit that > pulled these addresses from Nortel am I correct in assuming that > they had no legal ability to do so - ergo, this is a Legacy block? > > If it is a legacy block am I also correct in assuming that once this > "sale" completes that ARIN is going to realize a spike in it's > income, as this block is now going to be subject to yearly registration > renewal fees? > > If all of that is true then as these sales happen and more of these > legacy blocks come online, ARIN's income from fees will rise. > > Since ARIN is obligated to not generate a profit can I assume that > the excess income will result in fee reductions for the rest of us? > > After all when your friendly local government gets increased tax revenue > it reduces taxes, correct? > > Or have I just been out in the sun too long ;-) > > Ted > > > > ------------------------------ > > Message: 4 > Date: Thu, 24 Mar 2011 18:28:21 -0500 > From: David Farmer > To: Ted Mittelstaedt > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Advisory Council Meeting Results - March 2011 > Message-ID: <4D8BD395.9080509 at umn.edu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 3/24/11 15:33 CDT, Ted Mittelstaedt wrote: > > > > Org B can do due diligence with ARIN before the purchase and > > if they don't and org a turns out to be a pig in a poke then > > org B deserves what they get, in my book. > > If Org B ask ARIN about Org A, I'm not sure ARIN would tell them > anything, at least nothing more than is already published in Whois. So > what kind of due diligence is it that you think Org B would or should do > with ARIN? > > > Ted > > > > On 3/24/2011 8:26 AM, Chris Grundemann wrote: > ... > >> A scenario for illustration: > >> Org B needs addresses. > >> Org A tells Org B that they have addresses. > >> Orgs A and B come to an agreement on price, etc. > >> Org A writes an LoA for Org B to begin using the addresses. > >> Org A files an LRSA with ARIN. > >> ARIN finds that Org A is not authorized to hold nor transfer the > >> addresses in question. > >> Org B now has a number of problems... > >> - wasted time > >> - wasted money > >> - using addresses that they must return > >> - etc... > >> > >> I am not trying to argue one way or the other, just pointing out the > >> piece of this that eluded me at first in case others missed it as > >> well. > >> ~Chris > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > > > ------------------------------ > > Message: 5 > Date: Thu, 24 Mar 2011 19:16:14 -0500 > From: Benson Schliesser > To: Scott Leibrand > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Advisory Council Meeting Results - March 2011 > Message-ID: <9C29520B-E77C-4954-B67C-AF1E3EB0D121 at queuefull.net> > Content-Type: text/plain; charset=us-ascii > > Hi, Scott. > > On Mar 23, 2011, at 7:40 PM, Scott Leibrand wrote: > > > As I've done a couple times now, I'd like to expand on my own personal > > opinions on some of the proposals inline below. > > Thank you for your feedback, Scott. I appreciate your contribution to the > conversation. > > > I'm not speaking for > > the AC or anyone else: the AC's actions are captured well below, and > > further detail on the discussion leading up to them will be available > > in the minutes. > > Do you know when the AC meeting minutes will be posted? The only 2011 > meeting minutes currently posted at > https://www.arin.net/about_us/ac/index.html are from the January meeting > (under the outdated heading "2010"). Does it typically take a month(+) to > publish these? > > >> The AC voted to abandon ARIN-prop-132 for the following reasons: > >> - Aggregation is one of the goals of addressing stewardship, this > >> policy encourages deaggregation, and accelerates routing table growth. > >> - Creates a situation where the ISP providing the address space is > >> not in a position to remediate security and abuse issues which may have > >> significant impact on the larger internet community. > >> - The AC believes that a discussion about how staff currently handles > >> this situation is worth having, and suggests the author or a member of > >> the community submit it as an Open Policy hour topic at the upcoming > >> ARIN meeting. > > > > I was initially sympathetic to this proposal and wanted to make sure > > the community had a chance to discuss the pros and cons of LIRs that > > are not ISPs. However, it seems that we have an example of non-ISP > > LIRs in the RIPE region, and what I've heard from several folks is > > that such arrangements cause a lot of problems, and probably would not > > be worth doing here. If anyone takes a different lesson from that, > > I'd love to hear your experiences as well. > > I'm confused by your choice of words, and I think it would be useful to > clarify. The current NRPM language allows ISPs to assign addresses to their > customers, but doesn't define what "customer" means. The text of proposal > 132 does not explicitly create "non-ISP LIRs", but explicitly allows an ISP > to act as a LIR for customers that might not be receiving "traditional > connectivity" services from that ISP. Granted, this is a nuance - but it's > worth noting, for operational purposes, that the proposal wouldn't > necessarily allow non-ISPs to become LIRs. > > Having said that, I'm frankly not sure this matters. As I mentioned above, > the current policy doesn't define "customer" and I posit that an ISP is > already free to engage in this behavior. Proposal 132 was intended to > clarify existing policy. The AC "reasons" given for abandoning this > proposal seem to suggest a preference for the opposite of 132; should we > expect such a proposal in the near future? > > >> The AC has chosen to abandon ARIN-prop-134. Aside from the author, there > >> were no statements of support on the mailing list, and the majority of > >> opinion questioned the problem to be solved. While wording can often be > >> refined during the policy development process, the problem statement > >> itself needs further clarification. The abandonment of this proposal is > >> not to dismiss the discussion. It would just be clearer to refine the > >> problem statement first and submit a proposal if more clarity and > >> support can be reached on the mailing list. > > > > I believe there is actually a substantive problem here that is worth > > discussing. At this point I'm not sure if it should be addressed > > through a new policy proposal, or if it would end up being an ACSP > > suggestion, though... > > I don't have much to say about this, except that I think the standard > should be documented in an open and transparent way. > > If you think there is an alteration that would make prop 134 more > interesting to the "ARIN community", please feel free to submit a new > version. I have no objections to my proposal text being used and/or adapted > by anybody here. > > Cheers, > -Benson > > > > ------------------------------ > > Message: 6 > Date: Thu, 24 Mar 2011 19:26:37 -0500 > From: Benson Schliesser > To: Gary Buhrmaster > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Advisory Council Meeting Results - March 2011 > Message-ID: > Content-Type: text/plain; charset=us-ascii > > > On Mar 24, 2011, at 12:58 AM, Gary Buhrmaster wrote: > > > While honest people > > may disagree, it is my opinion that the LRSA is not > > onerous (if one's goal is the be part of the community). > > The time for dithering is approaching an end. > > I'm interested in this term "community" which seems to be so highly valued > on PPML. Does "community" refer to participants in PPML? Attendees at ARIN > meetings? Address holders? The larger community of address stakeholders > (vendors, operators, users) in the ARIN region? Or the entire population of > the region? > > My perspective is that a small community at ARIN makes policy that affects > the larger population of stakeholders, and frequently conflates the two. > > Cheers, > -Benson > > > > > ------------------------------ > > Message: 7 > Date: Thu, 24 Mar 2011 17:29:24 -0700 > From: Ted Mittelstaedt > To: David Farmer > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Advisory Council Meeting Results - March 2011 > Message-ID: <4D8BE1E4.3030902 at ipinc.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 3/24/2011 4:28 PM, David Farmer wrote: > > On 3/24/11 15:33 CDT, Ted Mittelstaedt wrote: > >> > >> Org B can do due diligence with ARIN before the purchase and > >> if they don't and org a turns out to be a pig in a poke then > >> org B deserves what they get, in my book. > > > > If Org B ask ARIN about Org A, I'm not sure ARIN would tell them > > anything, at least nothing more than is already published in Whois. So > > what kind of due diligence is it that you think Org B would or should do > > with ARIN? > > > > This is what LOAs are for. > > Most likely this kind of transaction would work as follows: > > Org A advertises out it's IPv4 > > Org B sees it and contacts Org A. They feel each other out > until they arrive at a price that is contingent on validity. Org > A then gives a LOI (letter of intent) listing pricing and a deadline, > and also gives Org B a LOA allowing Org B to act as Org A's agent > in dealing with ARIN. Org B gives Org A an NDA that promises not to > reveal Org A's dirty underwear to the world. > > Org B submits the LOA to ARIN and ARIN reports back that everything > is OK. Org B then pays Org A and gets handed a second LOA that allows > them to execute all the paperwork with ARIN. Org B does all that and > signs the transfer docs for Org A and then gets the IP addressing from > ARIN. > > A LOA can easily be written to legally designate Org B to act as > a proxy for Org A in dealing with ARIN. If ARIN refused to divulge Org > A's dirty underwear to Org B then it would be the same as ARIN refusing > to divulge Org A's dirty underwear to Org A. > > Anyway, this is how you would do it directly. Another way would be > to find an impartial 3rd party attorney that both Org A and Org B would > sign over power of attorney to and the 3rd party would escrow the > money and handle the transaction. But of course this just fattens up > the wallets of some lawyer who probably already has swimming pools full > of money anyway. > > Both of these scenarios are legally equivalent from ARIN's POV of > having Org A ask about itself, or Org B ask about itself. Org B can > say to ARIN "I'm the legal equivalent of Org A, are these numbers > I think I have, valid" Then Org B can say to ARIN "I'm going to > execute a transfer for XXX numbers and here is my utilization > justification will you allow it?" If the answer to both questions > is yes, then your good to go. > > Obviously ARIN could require Org A to sign an LSRA as a condition of > transfer, but this is a pointless exercise, since if an LOA was in place > Org B could do that for Org A anyway, 2 minutes before signing > the transfer paperwork and the actual RSA. And in any case the RIR's > incentive is to get the numbers out of Org A's control since Org > A is just sitting on them doing nothing with them. > > Although several posters said that if they were Org B they could > insist Org A sign a LSRA before selling, this is actually not a likely > scenario. The reason is that Org A is in the power > position. They have something that Org B cannot get from anyone else. > They have absolutely no incentive to deal with the RIR. If Org B doesn't > like this then they can stuff it and go elsewhere for their IPv4 > addresses. Org A's can simply sit back and do nothing at all and let > Org B do all the gruntwork and deal with the RIR and the paperwork. > > I've been in these scenarios with other stuff that Org A is so lazy > that they don't even bother writing the LOA and the LOI and the NDA they > make Org B do that, then if they like it they sign it. > > It's like buying a used car without a title. I've bought a number of > them like this over the years. You save a lot of money because most > buyers are scared to death if the stuff isn't handed to them on a silver > platter. The DMV will tell you if the VIN is stolen and if it is not, > then you buy the car and file for lost title. But the chances of > getting the seller to actually bother to file for lost title themselves > is almost nil. > > Ted > > > > >> Ted > >> > >> On 3/24/2011 8:26 AM, Chris Grundemann wrote: > > ... > >>> A scenario for illustration: > >>> Org B needs addresses. > >>> Org A tells Org B that they have addresses. > >>> Orgs A and B come to an agreement on price, etc. > >>> Org A writes an LoA for Org B to begin using the addresses. > >>> Org A files an LRSA with ARIN. > >>> ARIN finds that Org A is not authorized to hold nor transfer the > >>> addresses in question. > >>> Org B now has a number of problems... > >>> - wasted time > >>> - wasted money > >>> - using addresses that they must return > >>> - etc... > >>> > >>> I am not trying to argue one way or the other, just pointing out the > >>> piece of this that eluded me at first in case others missed it as > >>> well. > >>> ~Chris > > > > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 69, Issue 21 > ***************************************** > -- Rudi Daniel *danielcharles consulting **1-784 498 8277 * * * -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Thu Mar 24 21:00:03 2011 From: jcurran at arin.net (John Curran) Date: Fri, 25 Mar 2011 01:00:03 +0000 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: <4D8BB2A4.4080401@ipinc.net> References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> <4D8BB2A4.4080401@ipinc.net> Message-ID: <8AA945D1-0E3D-4B20-8965-87854B7E1619@arin.net> On Mar 24, 2011, at 5:07 PM, Ted Mittelstaedt wrote: > Since ARIN is obligated to not generate a profit can I assume that > the excess income will result in fee reductions for the rest of us? Several times in the past, ARIN has reduced fees when the income exceeded operating expenses and reserve funding on a sustained basis. If this were to recur, I'd recommend to that the ARIN Board Finance Committee look into a similar reduction. /John John Curran President and CEO ARIN From scottleibrand at gmail.com Thu Mar 24 21:04:35 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 24 Mar 2011 18:04:35 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: <9C29520B-E77C-4954-B67C-AF1E3EB0D121@queuefull.net> References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> <9C29520B-E77C-4954-B67C-AF1E3EB0D121@queuefull.net> Message-ID: On Thu, Mar 24, 2011 at 5:16 PM, Benson Schliesser wrote: > Hi, Scott. > > On Mar 23, 2011, at 7:40 PM, Scott Leibrand wrote: > >> As I've done a couple times now, I'd like to expand on my own personal >> opinions on some of the proposals inline below. > > Thank you for your feedback, Scott. ?I appreciate your contribution to the conversation. > >> ?I'm not speaking for >> the AC or anyone else: the AC's actions are captured well below, and >> further detail on the discussion leading up to them will be available >> in the minutes. > > Do you know when the AC meeting minutes will be posted? ?The only 2011 meeting minutes currently posted at https://www.arin.net/about_us/ac/index.html are from the January meeting (under the outdated heading "2010"). ?Does it typically take a month(+) to publish these? Per https://www.arin.net/about_us/acguidelines.html#approval the process is that the minutes are first reviewed by the AC chair, and then sent out to the full AC for review. After that 10 business day review, they are posted as "draft" to the website until they are formally approved by the AC at their next meeting. In this case, the February minutes were posted to the AC for review on March 8, and formally approved on the 17th, so I believe they should be posted already. I'll check with ARIN staff on the status of that. In the case of the March 17 meeting, the minutes were sent to the AC for review on March 21, so they should be considered approved on the 4th of April (or possibly the 11th, if a second round of review is needed), and can be posted shortly after that. >>> The AC voted to abandon ARIN-prop-132 for the following reasons: >>> - Aggregation is one of the goals of addressing stewardship, this >>> policy ?encourages deaggregation, and accelerates routing table growth. >>> - Creates a situation where the ISP providing the address space is >>> not in a position to remediate security and abuse issues which may have >>> significant impact on the larger internet community. >>> - The AC believes that a discussion about how staff currently handles >>> this situation is worth having, and suggests the author or a member of >>> the community submit it as an Open Policy hour topic at the upcoming >>> ARIN meeting. >> >> I was initially sympathetic to this proposal and wanted to make sure >> the community had a chance to discuss the pros and cons of LIRs that >> are not ISPs. ?However, it seems that we have an example of non-ISP >> LIRs in the RIPE region, and what I've heard from several folks is >> that such arrangements cause a lot of problems, and probably would not >> be worth doing here. ?If anyone takes a different lesson from that, >> I'd love to hear your experiences as well. > > I'm confused by your choice of words, and I think it would be useful to clarify. ?The current NRPM language allows ISPs to assign addresses to their customers, but doesn't define what "customer" means. ?The text of proposal 132 does not explicitly create "non-ISP LIRs", but explicitly allows an ISP to act as a LIR for customers that might not be receiving "traditional connectivity" services from that ISP. ?Granted, this is a nuance - but it's worth noting, for operational purposes, that the proposal wouldn't necessarily allow non-ISPs to become LIRs. > > Having said that, I'm frankly not sure this matters. ?As I mentioned above, the current policy doesn't define "customer" and I posit that an ISP is already free to engage in this behavior. ?Proposal 132 was intended to clarify existing policy. ?The AC "reasons" given for abandoning this proposal seem to suggest a preference for the opposite of 132; should we expect such a proposal in the near future? I agree with you that the NRPM is ambiguous on the question of whether ISPs can act as LIRs for organizations that don't buy IP connectivity services from them. The relevant NRPM section is: 2.4. Local Internet Registry (LIR) A Local Internet Registry (LIR) is an IR that primarily assigns address space to the users of the network services that it provides. LIRs are generally Internet Service Providers (ISPs), whose customers are primarily end users and possibly other ISPs. However, during the evaluation of ARIN-prop-132, ARIN staff stated that "If a network assigns address space without a corresponding network service (i.e. connectivity), it's no longer an LIR, thus no longer an ISP, thus ineligible for consideration under ISP policy." In order to change that, we'd need a policy proposal to modify NRPM 2.4. Given what I've learned about the impacts of a more liberal definition of LIR in the RIPE region, I don't think I'd support relaxing the "network services" requirement in 2.4. >>> The AC has chosen to abandon ARIN-prop-134. Aside from the author, there >>> were no statements of support on the mailing list, and the majority of >>> opinion questioned the problem to be solved. While wording can often be >>> refined during the policy development process, the problem statement >>> itself needs further clarification. The abandonment of this proposal is >>> not to dismiss the discussion. It would just be clearer to refine the >>> problem statement first and submit a proposal if more clarity and >>> support can be reached on the mailing list. >> >> I believe there is actually a substantive problem here that is worth >> discussing. ?At this point I'm not sure if it should be addressed >> through a new policy proposal, or if it would end up being an ACSP >> suggestion, though... > > I don't have much to say about this, except that I think the standard should be documented in an open and transparent way. At the moment, the standards are documented at https://www.arin.net/resources/transfer_listing/index.html and https://www.arin.net/resources/request/transfers.html If you think any particular aspect of those documents should be clarified, or would like to suggest a change to any of the procedures, the ARIN Consultation and Suggestion Process (ACSP) is the way to do it: https://www.arin.net/participate/acsp/index.html or https://www.arin.net/app/suggestion/ > If you think there is an alteration that would make prop 134 more interesting to the "ARIN community", please feel free to submit a new version. ?I have no objections to my proposal text being used and/or adapted by anybody here. Thanks. I intend to continue discussing the general topic of whether the transfer market is working effectively, so any input there is welcome. And if you're going to be at the San Juan meeting, we should definitely discuss it there. At the moment I don't see any clear need for policy changes, but when we do identify something, I'll be happy to work with anyone who's interested to submit a proposal to make them. -Scott From kevinb at thewire.ca Thu Mar 24 21:49:46 2011 From: kevinb at thewire.ca (Kevin Blumberg) Date: Thu, 24 Mar 2011 21:49:46 -0400 (EDT) Subject: [arin-ppml] STLS 8.3 Message-ID: <097401cbea8e$f0822df0$d18689d0$@thewire.ca> I have two questions in regards to 8.3. 1) Is the STLS require a 12 month justification or 3 month or ???. 2) If Company A has a /18 netblock and wishes to use the STLS to transfer a /19 to Company B and a /19 to Company C is that prohibited in the STLS? Thanks, Kevin Blumberg T 416.214.9473 x31 F 416.862.9473 kevinb at thewire.ca From bensons at queuefull.net Thu Mar 24 21:52:16 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 24 Mar 2011 20:52:16 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> <9C29520B-E77C-4954-B67C-AF1E3EB0D121@queuefull.net> Message-ID: <3615DB63-FB05-4377-AC1A-D0A2ECB98242@queuefull.net> Hi, Scott. On Mar 24, 2011, at 8:04 PM, Scott Leibrand wrote: > Per https://www.arin.net/about_us/acguidelines.html#approval > ... > In the case of the March 17 meeting, the minutes were sent to the AC > for review on March 21, so they should be considered approved on the > 4th of April (or possibly the 11th, if a second round of review is > needed), and can be posted shortly after that. Thank you for explaining this. Just a comment / feedback for the AC: I feel it is important to review the minutes before I decide how to proceed, and I understand that I must initiate an appeal (via the petition process) within 5 days after the minutes are posted. Thus I'd like to see these posted in a predictable and efficient way. > I agree with you that the NRPM is ambiguous on the question of whether > ISPs can act as LIRs for organizations that don't buy IP connectivity > services from them. The relevant NRPM section is: > > 2.4. Local Internet Registry (LIR) > > A Local Internet Registry (LIR) is an IR that primarily assigns > address space to the users of the network services that it provides. > LIRs are generally Internet Service Providers (ISPs), whose customers > are primarily end users and possibly other ISPs. > > However, during the evaluation of ARIN-prop-132, ARIN staff stated > that "If a network assigns address space without a corresponding > network service (i.e. connectivity), it's no longer an LIR, thus no > longer an ISP, thus ineligible for consideration under ISP policy." > > In order to change that, we'd need a policy proposal to modify NRPM > 2.4. Given what I've learned about the impacts of a more liberal > definition of LIR in the RIPE region, I don't think I'd support > relaxing the "network services" requirement in 2.4. With respect to the ARIN staff, I believe their assessment is unfounded. Current policy text uses "primarily" and "generally" to define the LIR - ISP - Customer relationships. Thus, this is not an exclusive definition. There is nothing that says the end users must be customers of the LIR, and nothing that requires a customer to receive connectivity services. Having said that, I agree that it is ambiguous. The ARIN staff review errs on the side of a loose interpretation of policy, resulting in more conservative expectations, and I think this is misleading. Cheers, -Benson From scottleibrand at gmail.com Thu Mar 24 21:55:26 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 24 Mar 2011 18:55:26 -0700 Subject: [arin-ppml] STLS 8.3 In-Reply-To: <097401cbea8e$f0822df0$d18689d0$@thewire.ca> References: <097401cbea8e$f0822df0$d18689d0$@thewire.ca> Message-ID: <7112046463422531493@unknownmsgid> On Mar 24, 2011, at 6:50 PM, "Kevin Blumberg" wrote: > I have two questions in regards to 8.3. > > 1) Is the STLS require a 12 month justification or 3 month or ???. First, it's important to be clear that the STLS is just a service for helping find other parties who wish to do a transfer. NRPM 8.3 is what sets the rules for transfers, whether they go through the STLS or not. NRPM 4.2.4.4 states that An organization receiving a transfer under section 8.3 may continue to request up to a 12-month supply of IP addresses. > 2) If Company A has a /18 netblock and wishes to use the STLS to transfer > a /19 to Company B and a /19 to Company C is that prohibited in the STLS? That is allowed by 8.3. But company B can't get a 19 from company A, and another /19 from company D. -Scott From cgrundemann at gmail.com Thu Mar 24 22:53:55 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 24 Mar 2011 20:53:55 -0600 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> Message-ID: On Thu, Mar 24, 2011 at 18:26, Benson Schliesser wrote: > I'm interested in this term "community" which seems to be so highly valued on PPML. ?Does "community" refer to participants in PPML? ?Attendees at ARIN meetings? ?Address holders? ?The larger community of address stakeholders (vendors, operators, users) in the ARIN region? ?Or the entire population of the region? All of the above plus some. Participation in ARIN is not limited to members, ISPs, vendors, or even to folks who reside within the region. > My perspective is that a small community at ARIN makes policy that affects the larger population of stakeholders, and frequently conflates the two. All stakeholders are welcome to join these discussions and make policy. Non-participation does not remove you from the community. Cheers, ~Chris > Cheers, > -Benson > > > _______________________________________________ > 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. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From bensons at queuefull.net Thu Mar 24 23:54:52 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 24 Mar 2011 22:54:52 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> Message-ID: On Mar 24, 2011, at 9:53 PM, Chris Grundemann wrote: > On Thu, Mar 24, 2011 at 18:26, Benson Schliesser wrote: > >> I'm interested in this term "community" which seems to be so highly valued on PPML. Does "community" refer to participants in PPML? Attendees at ARIN meetings? Address holders? The larger community of address stakeholders (vendors, operators, users) in the ARIN region? Or the entire population of the region? > > All of the above plus some. Participation in ARIN is not limited to > members, ISPs, vendors, or even to folks who reside within the region. > >> My perspective is that a small community at ARIN makes policy that affects the larger population of stakeholders, and frequently conflates the two. > > All stakeholders are welcome to join these discussions and make > policy. Non-participation does not remove you from the community. http://en.wikipedia.org/wiki/Consent_of_the_governed Cheers, -Benson From narten at us.ibm.com Fri Mar 25 00:53:02 2011 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 25 Mar 2011 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201103250453.p2P4r25h009007@rotala.raleigh.ibm.com> Total of 46 messages in the last 7 days. script run at: Fri Mar 25 00:53:02 EDT 2011 Messages | Bytes | Who --------+------+--------+----------+------------------------ 13.04% | 6 | 16.02% | 58626 | scottleibrand at gmail.com 13.04% | 6 | 12.73% | 46573 | owen at delong.com 8.70% | 4 | 8.32% | 30438 | charles at office.tcsn.net 8.70% | 4 | 6.98% | 25533 | hannigan at gmail.com 8.70% | 4 | 6.96% | 25452 | bensons at queuefull.net 8.70% | 4 | 6.25% | 22886 | gary.buhrmaster at gmail.com 2.17% | 1 | 10.50% | 38421 | rudi.daniel at gmail.com 6.52% | 3 | 5.75% | 21026 | tedm at ipinc.net 6.52% | 3 | 3.86% | 14124 | matthew at matthew.at 4.35% | 2 | 4.30% | 15719 | bill at herrin.us 4.35% | 2 | 3.44% | 12583 | cgrundemann at gmail.com 2.17% | 1 | 4.26% | 15573 | john.sweeting at gmail.com 2.17% | 1 | 2.30% | 8434 | info at arin.net 2.17% | 1 | 2.29% | 8395 | john.sweeting at twcable.com 2.17% | 1 | 1.70% | 6229 | farmer at umn.edu 2.17% | 1 | 1.70% | 6206 | narten at us.ibm.com 2.17% | 1 | 1.39% | 5104 | jcurran at arin.net 2.17% | 1 | 1.26% | 4608 | kevinb at thewire.ca --------+------+--------+----------+------------------------ 100.00% | 46 |100.00% | 365930 | Total From tedm at ipinc.net Fri Mar 25 02:55:00 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 24 Mar 2011 23:55:00 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> Message-ID: <4D8C3C44.4050607@ipinc.net> On 3/24/2011 8:54 PM, Benson Schliesser wrote: > > On Mar 24, 2011, at 9:53 PM, Chris Grundemann wrote: > >> On Thu, Mar 24, 2011 at 18:26, Benson Schliesser wrote: >> >>> I'm interested in this term "community" which seems to be so highly valued on PPML. Does "community" refer to participants in PPML? Attendees at ARIN meetings? Address holders? The larger community of address stakeholders (vendors, operators, users) in the ARIN region? Or the entire population of the region? >> >> All of the above plus some. Participation in ARIN is not limited to >> members, ISPs, vendors, or even to folks who reside within the region. >> >>> My perspective is that a small community at ARIN makes policy that affects the larger population of stakeholders, and frequently conflates the two. >> >> All stakeholders are welcome to join these discussions and make >> policy. Non-participation does not remove you from the community. > > http://en.wikipedia.org/wiki/Consent_of_the_governed > Reread the section of that article on tacit consent, you are missing something. Your assertion that the community members who form the "silent majority" are opposed to the decisions of the participatory minority is nothing more than a warmed-over version of Tricky Dicky's 1969 speech implications. But even he knew he was on thin ice as in that speech he did NOT assert, as you did with your "conflate" comment, that the silent majority was opposed to the vocal minority. Instead he begged for the silent majority to come forward and support him in opposition to the vocal minority. And as I recall, very few did. Unless we see evidence otherwise, in my opinion it is a much more supportable assertion to claim that the non-participants are in general perfectly contented with what the small community making policy at ARIN is doing. Ted > Cheers, > -Benson > > _______________________________________________ > 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 mje at posix.co.za Fri Mar 25 03:50:23 2011 From: mje at posix.co.za (Mark Elkins) Date: Fri, 25 Mar 2011 09:50:23 +0200 Subject: [arin-ppml] ARIN-prop-137 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: <4D8A8CF9.5070106@matthew.at> References: <4D76879D.4000508@arin.net> <4D8A4E3F.7010007@office.tcsn.net> <15DCD985-B989-415A-B4AC-79B6FEF0F69D@delong.com> <4D8A570A.9090304@matthew.at> <4D8A8CF9.5070106@matthew.at> Message-ID: <1301039423.7177.416.camel@mje99.posix.co.za> On Wed, 2011-03-23 at 17:14 -0700, Matthew Kaufman wrote: > On 3/23/2011 2:19 PM, Gary Buhrmaster wrote: > > On Wed, Mar 23, 2011 at 20:24, Matthew Kaufman wrote: > >> On 3/23/2011 1:16 PM, Owen DeLong wrote: > >>> Would you support equal distribution in an environment where need exceeds > >>> availability? If not, what > >>> mechanism would you support for distributing space in such conditions? > >> > >> Highest bidder. > > How would the RIRs be expected to valud/bid for the numbers? > > Last I checked, the RIRs have enough money to do all sorts of other > things... why not also bid against each other for address space? (Even > easier if they're just proxying bids from people who need the space > badly enough) Ouch! - Maybe RIPE, ARIN and APNIC - but probably not LACNIC and certainly not AfriNIC. I'd suspect a reasonable generalisation would be that the same goes for the businesses in these respective areas.. > > > I suspect that by the time any global policy can be enacted to > > allow distribution from IANA all regions will have need. Trying > > to determine which need is greater is likely more complex > > and politically charged than a simple equal distribution. > > Highest bidder conveniently solves this problem without all the ethical > complications. > > Matthew Kaufman > > _______________________________________________ > 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. -- . . ___. .__ Posix Systems - (South) Africa /| /| / /__ mje at posix.co.za - Mark J Elkins, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6696 bytes Desc: not available URL: From jcurran at arin.net Fri Mar 25 12:45:17 2011 From: jcurran at arin.net (John Curran) Date: Fri, 25 Mar 2011 16:45:17 +0000 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: <3615DB63-FB05-4377-AC1A-D0A2ECB98242@queuefull.net> References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> <9C29520B-E77C-4954-B67C-AF1E3EB0D121@queuefull.net> <3615DB63-FB05-4377-AC1A-D0A2ECB98242@queuefull.net> Message-ID: On Mar 24, 2011, at 9:52 PM, Benson Schliesser wrote: > Just a comment / feedback for the AC: I feel it is important to review the minutes before I decide how to proceed, and I understand that I must initiate an appeal (via the petition process) within 5 days after the minutes are posted. Thus I'd like to see these posted in a predictable and efficient way. Benson - The timing issue in petition process in the current PDP is acknowledged, and I will see if we can the minutes out asap. /John John Curran President and CEO ARIN From cgrundemann at gmail.com Fri Mar 25 14:29:43 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 25 Mar 2011 12:29:43 -0600 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> Message-ID: On Thu, Mar 24, 2011 at 21:54, Benson Schliesser wrote: > > On Mar 24, 2011, at 9:53 PM, Chris Grundemann wrote: >> >> All stakeholders are welcome to join these discussions and make >> policy. Non-participation does not remove you from the community. > > http://en.wikipedia.org/wiki/Consent_of_the_governed I'm familiar, but your point might be better made by being more specific; the linked article allows a lot of room for speculation. I could extrapolate from it that you are referring to tacit consent which would mean that since the ARIN community is not currently in revolt, we have collectively provided consent to ARIN. I could also assume that you were referring to overt consent, by which I would conclude that choosing to operate within the ARIN region using resources managed by ARIN indicates consent of the community for the current model. Or perhaps you were referring to hypothetical consent, in that case we could look at the history of ARIN and see that in general terms, this organization and structure was built from a state of non-governance over time and thus it can be easily concluded that we ought to consent, since it is the model we would (read: have) choose in a vacuum. It is also possible that you are more interested in the idea of unanimous consent, and in that scenario that you may be calling for the right of succession... On the other hand, it may not matter which specific idea you are referring us to, since my response is the same in all cases: If folks out there want to see change in ARIN policy, all they have to do is come speak up - as you and I and every other member of the "active" community has done and is now doing. Cheers, ~Chris From info at arin.net Fri Mar 25 14:57:34 2011 From: info at arin.net (ARIN) Date: Fri, 25 Mar 2011 14:57:34 -0400 Subject: [arin-ppml] [Fwd: Advisory Council Meeting Results - February 2011] Message-ID: <4D8CE59E.5040501@arin.net> The minutes from the ARIN Advisory Council's February 17 meeting have been published: https://www.arin.net/about_us/ac/ac2011_0217.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) -------- Original Message -------- Subject: Advisory Council Meeting Results - February 2011 Date: Mon, 21 Feb 2011 21:26:28 -0500 From: ARIN To: arin-ppml at arin.net In accordance with the ARIN Policy Development Process (PDP), the ARIN Advisory Council (AC) held a meeting on 17 February 2011 in order to make decisions about draft policies and proposals. The AC added the following proposal to their docket: ARIN-prop-131. Section 5.0 Legacy Addresses The AC also developed ARIN-prop-131 into a draft policy for adoption discussion online and at the ARIN XXVII Public Policy Meeting in San Juan, Puerto Rico. The draft policy "ARIN-2011-6: Returned IPv4 Addresses" will be posted shortly to the PPML. The PDP states, ?Any member of the community, including a proposal originator, may initiate a Discussion Petition if they are dissatisfied with the action taken by the Advisory Council regarding any specific policy proposal.? The AC used proposal 131 to generate a draft policy, the text of which is different from the original proposal. Proposal 131 may be petitioned (Discussion Petition) to try to advance the original version as a draft policy for adoption discussion on the Public Policy Mailing List and at a Public Policy Meeting. The deadline to begin a petition will be five business days after the AC's draft meeting minutes are published. However, in order for a petition of proposal 131 to be considered successful for the ARIN XXVII meeting, the entire petition must be concluded by 7 March 2011 in order to meet the requirement of posting as draft policy at least 35 days prior to the meeting. The Advisory Council appreciates the involvement of all community members who provide input toward a complete discussion of policy proposals. The AC especially wishes to thank those authors of policy proposals for their efforts in helping the community address possible improvements. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html Draft Policy and Policy Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From owen at delong.com Fri Mar 25 15:52:37 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Mar 2011 12:52:37 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: <4D8BD395.9080509@umn.edu> References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> <4D8BAA82.8070101@ipinc.net> <4D8BD395.9080509@umn.edu> Message-ID: <3B3B4570-AF02-445A-AEC6-9D01D7F27EB6@delong.com> I would support a policy/ACSP suggestion that allowed ARIN to disclose the RSA or not status of blocks in whois. Owen On Mar 24, 2011, at 4:28 PM, David Farmer wrote: > On 3/24/11 15:33 CDT, Ted Mittelstaedt wrote: >> >> Org B can do due diligence with ARIN before the purchase and >> if they don't and org a turns out to be a pig in a poke then >> org B deserves what they get, in my book. > > If Org B ask ARIN about Org A, I'm not sure ARIN would tell them anything, at least nothing more than is already published in Whois. So what kind of due diligence is it that you think Org B would or should do with ARIN? > >> Ted >> >> On 3/24/2011 8:26 AM, Chris Grundemann wrote: > ... >>> A scenario for illustration: >>> Org B needs addresses. >>> Org A tells Org B that they have addresses. >>> Orgs A and B come to an agreement on price, etc. >>> Org A writes an LoA for Org B to begin using the addresses. >>> Org A files an LRSA with ARIN. >>> ARIN finds that Org A is not authorized to hold nor transfer the >>> addresses in question. >>> Org B now has a number of problems... >>> - wasted time >>> - wasted money >>> - using addresses that they must return >>> - etc... >>> >>> I am not trying to argue one way or the other, just pointing out the >>> piece of this that eluded me at first in case others missed it as >>> well. >>> ~Chris > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > _______________________________________________ > 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 Mar 25 15:55:22 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Mar 2011 12:55:22 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: <4D8BD395.9080509@umn.edu> References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> <4D8BAA82.8070101@ipinc.net> <4D8BD395.9080509@umn.edu> Message-ID: In fact, I just submitted the following suggestion to the ACSP I think it fits better there than in policy and has a better chance of being implemented more quickly: ARIN should add to the WHOIS and any other published address directory services the RSA or not status of each delegation. Ideally, this should be a single "Contract:" field which would contain one of "None", "LRSA", or "RSA". Owen On Mar 24, 2011, at 4:28 PM, David Farmer wrote: > On 3/24/11 15:33 CDT, Ted Mittelstaedt wrote: >> >> Org B can do due diligence with ARIN before the purchase and >> if they don't and org a turns out to be a pig in a poke then >> org B deserves what they get, in my book. > > If Org B ask ARIN about Org A, I'm not sure ARIN would tell them anything, at least nothing more than is already published in Whois. So what kind of due diligence is it that you think Org B would or should do with ARIN? > >> Ted >> >> On 3/24/2011 8:26 AM, Chris Grundemann wrote: > ... >>> A scenario for illustration: >>> Org B needs addresses. >>> Org A tells Org B that they have addresses. >>> Orgs A and B come to an agreement on price, etc. >>> Org A writes an LoA for Org B to begin using the addresses. >>> Org A files an LRSA with ARIN. >>> ARIN finds that Org A is not authorized to hold nor transfer the >>> addresses in question. >>> Org B now has a number of problems... >>> - wasted time >>> - wasted money >>> - using addresses that they must return >>> - etc... >>> >>> I am not trying to argue one way or the other, just pointing out the >>> piece of this that eluded me at first in case others missed it as >>> well. >>> ~Chris > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > _______________________________________________ > 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 Mar 25 16:01:55 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Mar 2011 13:01:55 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: <9C29520B-E77C-4954-B67C-AF1E3EB0D121@queuefull.net> References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> <9C29520B-E77C-4954-B67C-AF1E3EB0D121@queuefull.net> Message-ID: <6902B85A-C3D5-42E7-B82C-6AC9B1A7A720@delong.com> On Mar 24, 2011, at 5:16 PM, Benson Schliesser wrote: > Hi, Scott. > > On Mar 23, 2011, at 7:40 PM, Scott Leibrand wrote: > >> As I've done a couple times now, I'd like to expand on my own personal >> opinions on some of the proposals inline below. > > Thank you for your feedback, Scott. I appreciate your contribution to the conversation. > >> I'm not speaking for >> the AC or anyone else: the AC's actions are captured well below, and >> further detail on the discussion leading up to them will be available >> in the minutes. > > Do you know when the AC meeting minutes will be posted? The only 2011 meeting minutes currently posted at https://www.arin.net/about_us/ac/index.html are from the January meeting (under the outdated heading "2010"). Does it typically take a month(+) to publish these? > The meeting minutes are approved by motion at the next meeting which is pretty typical of such bodies in general. As such, they cannot be published until that time. The AC meets monthly, so, by definition, that would mean a one-month cycle. >>> The AC voted to abandon ARIN-prop-132 for the following reasons: >>> - Aggregation is one of the goals of addressing stewardship, this >>> policy encourages deaggregation, and accelerates routing table growth. >>> - Creates a situation where the ISP providing the address space is >>> not in a position to remediate security and abuse issues which may have >>> significant impact on the larger internet community. >>> - The AC believes that a discussion about how staff currently handles >>> this situation is worth having, and suggests the author or a member of >>> the community submit it as an Open Policy hour topic at the upcoming >>> ARIN meeting. >> >> I was initially sympathetic to this proposal and wanted to make sure >> the community had a chance to discuss the pros and cons of LIRs that >> are not ISPs. However, it seems that we have an example of non-ISP >> LIRs in the RIPE region, and what I've heard from several folks is >> that such arrangements cause a lot of problems, and probably would not >> be worth doing here. If anyone takes a different lesson from that, >> I'd love to hear your experiences as well. > > I'm confused by your choice of words, and I think it would be useful to clarify. The current NRPM language allows ISPs to assign addresses to their customers, but doesn't define what "customer" means. The text of proposal 132 does not explicitly create "non-ISP LIRs", but explicitly allows an ISP to act as a LIR for customers that might not be receiving "traditional connectivity" services from that ISP. Granted, this is a nuance - but it's worth noting, for operational purposes, that the proposal wouldn't necessarily allow non-ISPs to become LIRs. > It really doesn't matter whether you have to be an ISP or not. You can fabricate an ISP out of thin air by claiming you are a schedule C business selling service to your individual self. So, your nuance is really irrelevant. > Having said that, I'm frankly not sure this matters. As I mentioned above, the current policy doesn't define "customer" and I posit that an ISP is already free to engage in this behavior. Proposal 132 was intended to clarify existing policy. The AC "reasons" given for abandoning this proposal seem to suggest a preference for the opposite of 132; should we expect such a proposal in the near future? > I agree that the current policy has unfortunate ambiguity, but, ARIN has, to date, interpreted the policy to imply connectivity services. However, I would support a policy proposal to amend the policy and codify this interpretation (that connectivity services are required for the address utilization to be considered legitimate). >>> The AC has chosen to abandon ARIN-prop-134. Aside from the author, there >>> were no statements of support on the mailing list, and the majority of >>> opinion questioned the problem to be solved. While wording can often be >>> refined during the policy development process, the problem statement >>> itself needs further clarification. The abandonment of this proposal is >>> not to dismiss the discussion. It would just be clearer to refine the >>> problem statement first and submit a proposal if more clarity and >>> support can be reached on the mailing list. >> >> I believe there is actually a substantive problem here that is worth >> discussing. At this point I'm not sure if it should be addressed >> through a new policy proposal, or if it would end up being an ACSP >> suggestion, though... > > I don't have much to say about this, except that I think the standard should be documented in an open and transparent way. > > If you think there is an alteration that would make prop 134 more interesting to the "ARIN community", please feel free to submit a new version. I have no objections to my proposal text being used and/or adapted by anybody here. > I'm probably short on time to develop one at the moment, but, I will support a proposal to codify a requirement for connectivity services into the existing policy if someone wants to draft such a proposal. Owen From owen at delong.com Fri Mar 25 16:03:18 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Mar 2011 13:03:18 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> Message-ID: On Mar 24, 2011, at 5:26 PM, Benson Schliesser wrote: > > On Mar 24, 2011, at 12:58 AM, Gary Buhrmaster wrote: > >> While honest people >> may disagree, it is my opinion that the LRSA is not >> onerous (if one's goal is the be part of the community). >> The time for dithering is approaching an end. > > I'm interested in this term "community" which seems to be so highly valued on PPML. Does "community" refer to participants in PPML? Attendees at ARIN meetings? Address holders? The larger community of address stakeholders (vendors, operators, users) in the ARIN region? Or the entire population of the region? > Community refers to anyone who wishes to take an active role in the ARIN policy development process. > My perspective is that a small community at ARIN makes policy that affects the larger population of stakeholders, and frequently conflates the two. > Decisions are made by those who participate. There is no feasible way to account for the desires of people who choose not to participate. Owen From owen at delong.com Fri Mar 25 16:22:41 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Mar 2011 13:22:41 -0700 Subject: [arin-ppml] STLS 8.3 In-Reply-To: <097401cbea8e$f0822df0$d18689d0$@thewire.ca> References: <097401cbea8e$f0822df0$d18689d0$@thewire.ca> Message-ID: <6403FADF-27FF-4336-A2BE-0EBB6CF3E21C@delong.com> 8.3 is not STLS and STLS is not 8.3 STLS is a listing service being provided by ARIN to help recipients and donors find each other. 8.3 is the policy under which transfers would occur between entities that found each other through STLS or other mechanisms. 8.3 allows a 12 month window. Item 2 is permitted under 8.3. STLS is irrelevant to the question. Owen On Mar 24, 2011, at 6:49 PM, Kevin Blumberg wrote: > I have two questions in regards to 8.3. > > 1) Is the STLS require a 12 month justification or 3 month or ???. > > 2) If Company A has a /18 netblock and wishes to use the STLS to transfer > a /19 to Company B and a /19 to Company C is that prohibited in the STLS? > > Thanks, > > > Kevin Blumberg > T 416.214.9473 x31 > F 416.862.9473 > kevinb at thewire.ca > > > > > > > _______________________________________________ > 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 heather.skanks at gmail.com Fri Mar 25 17:16:58 2011 From: heather.skanks at gmail.com (Heather Schiller) Date: Fri, 25 Mar 2011 17:16:58 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: <9C29520B-E77C-4954-B67C-AF1E3EB0D121@queuefull.net> References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> <9C29520B-E77C-4954-B67C-AF1E3EB0D121@queuefull.net> Message-ID: On Thu, Mar 24, 2011 at 8:16 PM, Benson Schliesser wrote: >> I was initially sympathetic to this proposal and wanted to make sure >> the community had a chance to discuss the pros and cons of LIRs that >> are not ISPs. ?However, it seems that we have an example of non-ISP >> LIRs in the RIPE region, and what I've heard from several folks is >> that such arrangements cause a lot of problems, and probably would not >> be worth doing here. ?If anyone takes a different lesson from that, >> I'd love to hear your experiences as well. > > I'm confused by your choice of words, and I think it would be useful to clarify. ?The current NRPM language allows ISPs to assign addresses to their customers, but doesn't define what "customer" means. ?The text of proposal 132 does not explicitly create "non-ISP LIRs", but explicitly allows an ISP to act as a LIR for customers that might not be receiving "traditional connectivity" services from that ISP. ?Granted, this is a nuance - but it's worth noting, for operational purposes, that the proposal wouldn't necessarily allow non-ISPs to become LIRs. > >From the NRPM: 2.4. Local Internet Registry (LIR) A Local Internet Registry (LIR) is an IR that primarily assigns address space to the users of the network services that it provides. LIRs are generally Internet Service Providers (ISPs), whose customers are primarily end users and possibly other ISPs. ** users of network service it provides** and yes, I understand it says 'primarily' and not 'exclusively' I believe this section of NRPM is one of the older bits - and the rest of NRPM largely refers to ISP's and not LIR's. > Having said that, I'm frankly not sure this matters. ?As I mentioned above, the current policy doesn't define "customer" and I posit that an ISP is already free to engage in this behavior. ?Proposal 132 was intended to clarify existing policy. ?The AC "reasons" given for abandoning this proposal seem to suggest a preference for the opposite of 132; should we expect such a proposal in the near future? From cgrundemann at gmail.com Fri Mar 25 18:11:23 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 25 Mar 2011 16:11:23 -0600 Subject: [arin-ppml] Better Defining of LIR (was: Re: Advisory Council Meeting Results - March 2011) Message-ID: On Fri, Mar 25, 2011 at 14:01, Owen DeLong wrote: > > On Mar 24, 2011, at 5:16 PM, Benson Schliesser wrote: >> >> I don't have much to say about this, except that I think the standard should be documented in an open and transparent way. >> >> If you think there is an alteration that would make prop 134 more interesting to the "ARIN community", please feel free to submit a new version. ?I have no objections to my proposal text being used and/or adapted by anybody here. >> > I'm probably short on time to develop one at the moment, but, I will > support a proposal to codify a requirement for connectivity services into the > existing policy if someone wants to draft such a proposal. Without delving into the arguments one way or the other (yet) but with the expectation that the community may in fact want to make the definition of LIR more clear; I have taken the liberty of drafting two distinct policy proposals that could be submitted by folks who agree with one or the other view: *Proposal to make current operational practice explicit in policy: Strike the word 'primarily' and add the word 'exclusively' after 'address space' in the first sentence of NRPM section 2.4, with the following result: 2.4. Local Internet Registry (LIR) A Local Internet Registry (LIR) is an IR that assigns address space exclusively to the users of the network services that it provides. LIRs are generally Internet Service Providers (ISPs), whose customers are primarily end users and possibly other ISPs. *Propsal to change the current intent and to explicitly allow the allocation and assignment of space from an LIR to any customer, regardless of connectivity: Strike the word 'primary' and replace 'the users of the network services that it provides' with 'it's customers' in the first sentence of NRPM section 2.4, with the following result: 2.4. Local Internet Registry (LIR) A Local Internet Registry (LIR) is an IR that assigns address space to it's customers. LIRs are generally Internet Service Providers (ISPs), whose customers are primarily end users and possibly other ISPs. Current NRPM text for easy reference: 2.4. Local Internet Registry (LIR) A Local Internet Registry (LIR) is an IR that primarily assigns address space to the users of the network services that it provides. LIRs are generally Internet Service Providers (ISPs), whose customers are primarily end users and possibly other ISPs. Enjoy, ~Chris > > 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. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From lea.roberts at stanford.edu Sun Mar 27 11:00:31 2011 From: lea.roberts at stanford.edu (Lea Roberts) Date: Sun, 27 Mar 2011 08:00:31 -0700 (PDT) Subject: [arin-ppml] BCP 157, RFC 6177 on IPv6 Address Assignment to End Sites (fwd) Message-ID: I'm happy to report that this has made it to being an RFC! /Lea ---------- Forwarded message ---------- Date: Sun, 27 Mar 2011 02:47:08 -0700 (PDT) From: rfc-editor at rfc-editor.org To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org Cc: v6ops at ietf.org, rfc-editor at rfc-editor.org Subject: BCP 157, RFC 6177 on IPv6 Address Assignment to End Sites A new Request for Comments is now available in online RFC libraries. BCP 157 RFC 6177 Title: IPv6 Address Assignment to End Sites Author: T. Narten, G. Huston, L. Roberts Status: Best Current Practice Stream: IETF Date: March 2011 Mailbox: narten at us.ibm.com, gih at apnic.net, lea.roberts at stanford.edu Pages: 9 Characters: 21231 Obsoletes: RFC3177 See Also: BCP0157 I-D Tag: draft-ietf-v6ops-3177bis-end-sites-01.txt URL: http://www.rfc-editor.org/rfc/rfc6177.txt RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005. This document obsoletes the RFC 3177 recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is an issue for the operational community. The IETF's role in this case is limited to providing guidance on IPv6 architectural and operational considerations. This document reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original recommendations in RFC 3177. Moreover, this document clarifies that a one-size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default. This document obsoletes RFC 3177. [STANDARDS-TRACK] This document is a product of the IPv6 Operations Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor at rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ IETF-Announce mailing list IETF-Announce at ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From Vaughn at SwiftSystems.com Tue Mar 29 16:15:42 2011 From: Vaughn at SwiftSystems.com (Vaughn Thurman - Swift Systems Inc) Date: Tue, 29 Mar 2011 16:15:42 -0400 Subject: [arin-ppml] BCP 157, RFC 6177 on IPv6 Address Assignment to End Sites (fwd) In-Reply-To: References: Message-ID: <03fc01cbee4e$1435a1b0$3ca0e510$@SwiftSystems.com> Excellent! Thanks for passing this along. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Lea Roberts Sent: Sunday, March 27, 2011 11:01 AM To: ppml at arin.net Subject: [arin-ppml] BCP 157, RFC 6177 on IPv6 Address Assignment to End Sites (fwd) I'm happy to report that this has made it to being an RFC! /Lea ---------- Forwarded message ---------- Date: Sun, 27 Mar 2011 02:47:08 -0700 (PDT) From: rfc-editor at rfc-editor.org To: ietf-announce at ietf.org, rfc-dist at rfc-editor.org Cc: v6ops at ietf.org, rfc-editor at rfc-editor.org Subject: BCP 157, RFC 6177 on IPv6 Address Assignment to End Sites A new Request for Comments is now available in online RFC libraries. BCP 157 RFC 6177 Title: IPv6 Address Assignment to End Sites Author: T. Narten, G. Huston, L. Roberts Status: Best Current Practice Stream: IETF Date: March 2011 Mailbox: narten at us.ibm.com, gih at apnic.net, lea.roberts at stanford.edu Pages: 9 Characters: 21231 Obsoletes: RFC3177 See Also: BCP0157 I-D Tag: draft-ietf-v6ops-3177bis-end-sites-01.txt URL: http://www.rfc-editor.org/rfc/rfc6177.txt RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks in most cases. The Regional Internet Registries (RIRs) adopted that recommendation in 2002, but began reconsidering the policy in 2005. This document obsoletes the RFC 3177 recommendations on the assignment of IPv6 address space to end sites. The exact choice of how much address space to assign end sites is an issue for the operational community. The IETF's role in this case is limited to providing guidance on IPv6 architectural and operational considerations. This document reviews the architectural and operational considerations of end site assignments as well as the motivations behind the original recommendations in RFC 3177. Moreover, this document clarifies that a one-size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default. This document obsoletes RFC 3177. [STANDARDS-TRACK] This document is a product of the IPv6 Operations Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor at rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ IETF-Announce mailing list IETF-Announce at ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ 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 frnkblk at iname.com Tue Mar 29 22:44:57 2011 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 29 Mar 2011 21:44:57 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - March 2011 In-Reply-To: References: <4D8A07E7.6020906@arin.net> <2736336328847355897@unknownmsgid> Message-ID: <001901cbee84$75423c80$5fc6b580$@iname.com> Escrow companies could play a role in the process. Nortel and Microsoft are using one, and I can see them performing some non-authoritative validation, all for a small fee. Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Thursday, March 24, 2011 4:08 AM To: Scott Leibrand Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Advisory Council Meeting Results - March 2011 On Wed, Mar 23, 2011 at 8:40 PM, Scott Leibrand wrote: > As I've done a couple times now, I'd like to expand on my own personal > opinions on some of the proposals inline below. As always, thanks. And my thanks to Owen and Marty as well, for choosing to help those of us in the general community understand your and their personal thought processes during votes on the proposals. You exhibit a commitment to an open process above and beyond what some of your colleagues have been willing to do. > I have heard from a number of people the concern that some legacy > holders are reluctant to sign an LRSA because they perceive it to > require giving up rights to use the address space as they see fit. > While I largely thing such concerns are exaggerated, they nonetheless > could represent a barrier if a legacy holder is attempting to make > space available for 8.3 transfer. > So I think the question is whether the community thinks it would be > worthwhile for ARIN to develop a process to validate an address > holder's legitimacy, the same way they do for the LRSA today, but then > simply provide some sort of pre-qualification document to the holder > while he goes out looking for a party to transfer the block to. Speaking as a legacy holder reluctant to sign an LRSA, I personally don't have a problem with signing an LRSA when/if I decide I want to transfer addresses. WRT reluctance on the part of the buyer... beggars can't be choosers. There are only so many addresses which will be on the market at any given time. Addresses that aren't under contract may end up selling for less than addresses under contract but they'll still sell. The recipient can use the addresses as soon as I sign a letter of authorization. It's not a big deal if the completed transfer paperwork takes a little while as ARIN validates my claim. I tend to agree with the others who've said that ARIN really shouldn't be doing a lot of work on behalf of registrants who aren't under contract. In my mind, ARIN made a basic commitment to maintain the registrations it inherited without new conditions. However, I think this sort of transfer qualification activity goes beyond that maintenance. 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 info at arin.net Wed Mar 30 13:48:42 2011 From: info at arin.net (ARIN) Date: Wed, 30 Mar 2011 13:48:42 -0400 Subject: [arin-ppml] Draft Policy ARIN-2011-6: Returned IPv4 Addresses - revised In-Reply-To: <4D78EE2C.3050501@arin.net> References: <4D78EE2C.3050501@arin.net> Message-ID: <4D936CFA.7040003@arin.net> Draft Policy ARIN-2011-6 Returned IPv4 Addresses Below is an updated staff assessment of the revised text. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2011-6 Returned IPv4 Addresses Version (Date): 10 Mar 2011 Date of Assessment: 25 Mar 2011 1. Proposal Summary (Staff Understanding): This policy proposal would require ARIN to retain any address space that is or has been returned, revoked or recovered for redistribution to customers within the ARIN region, except where otherwise directed by policy. 2. Comments A. Staff Comments: - The wording of the proposal seems to indicate that any address space, including a /8, that gets returned to ARIN gets added into ARIN's inventory and made available for redistribution. In all other instances where a legacy /8 has been returned to ARIN, ARIN has returned that space to IANA. This proposal would change that standard practice. - Staff will continue to implement its own operating procedures for recycling any returned address space. - The community should consider amending the Rationale to state ?? status of existing and future returned IPv4 addresses? if that matches the policy intent. The clarification would avoid any misinterpretation in implementation when handling space returned, recovered, or revoked before policy adoption. B. Legal Comments None 3. Resource Impact This policy would have minimal resource impact from an implementation aspect. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: ? Updated guidelines ? Staff training ARIN wrote: > Draft Policy ARIN-2011-6 > Returned IPv4 Addresses > > ARIN-2011-6 has been revised. This draft policy is open for discussion > on this mailing list and will be on the agenda at the upcoming ARIN > Public Policy Meeting in San Juan. > > ARIN-2011-6 is below and can be found at: > https://www.arin.net/policy/proposals/2011_6.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy ARIN-2011-6 > Returned IPv4 Addresses > > Date: 10 March 2011 > > Policy statement: > > 4.1.9 Returned IPv4 Addresses > > Except where otherwise directed by policy; all IPv4 addresses returned > to, recovered, or revoked by ARIN will be made available for allocation > or assignment in the ARIN region as quickly as practicable. > > Rationale: > > Adopting this proposal will result in the clarification of the status of > returned IPv4 addresses. IPv4 address resources should not sit idle due > to lack of policy clarity. > > Timetable for implementation: Immediately > > > From Wesley.E.George at sprint.com Thu Mar 31 07:34:20 2011 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Thu, 31 Mar 2011 11:34:20 +0000 Subject: [arin-ppml] ARIN validation of authorized contacts Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6949C@PLSWM12A.ad.sprint.com> Apologies in advance if folks don't view this as policy-related enough. Happy to move the discussion to arin-discuss if it's more appropriate for that list instead. There's a thread on NANOG right now about some address hijacking/squatting, and it brings up an interesting question about how ARIN determines whether a person purporting to represent a company is actually authorized to make changes. That is, how do you prove to ARIN that: a) you are who you say you are b) that you are actually an agent for the company you are purportedly representing c) that you are authorized to request changes on behalf of said company. The situation where someone poses as an agent of a company (especially one that has let their records/domains lapse) in an effort to acquire their address space in a way that looks semi-legitimate (by updating the ARIN records) is mainly an annoyance right now, because ARIN usually works rapidly with the proper owners (if exist) to restore the correct contact info. However, my sense is that as long as the bills get paid and nothing triggers the "spidey sense" of ARIN staff, *accuracy* of records is less important than simply having *valid* (reachable) POC records. As we look at the SIDR origin validation implementation, where ARIN would be providing Resource Certificates for the rightful owner to originate an announcement of a given block of addresses, I think this becomes more than just an annoyance. The expectation is that other announcements that do not have that authority will be either rejected or treated with lower priority than the validated announcement in the routing table. But this system is only as good as the underlying verification to provide the delegation in the first place. If it's easily gamed, then the veracity of the information is suspect and the entire implementation is of limited value as an input to a routing policy decision, not to mention the fact that it opens legitimate resource holders up to exactly the type of attack this is trying to prevent. So my question is regarding the identification and validation of authorized agents. Is ARIN staff already thinking about ways to manage this? Can we potentially kill two birds with one stone and improve the accuracy of ARIN whois records and support RPKI? Most security authorization systems have a rigidly defined validation procedure, or a web of trust (think PGP key signing parties), or both. I'm not by any means a security expert, but I'm wondering if there is a hole in our policy that needs to cover how ARIN manages POC verification/authorization? Our policy around DMR POCs does require that the person have an email address that matches the company of record, but to my knowledge, even this limited requirement is not enforced for other POCs. Even if it simply documents an existing BCP that staff should follow, I would think that this should be part of our policy. Since this isn't strictly an implementation detail of the system itself, but rather the process surrounding the system, I think that ARIN is probably the proper place for this, rather than as an extension to the SIDR RPKI drafts. I will also note that there is no existing policy covering ARIN's participation in the RPKI/Origin Validation at all. I'm not sure if it's something that should be documented in policy, or whether it's something like the other services that ARIN offers that is largely left to staff to determine implementation details. ARIN info on RPKI: https://www.arin.net/resources/rpki.html Email on NANOG, for reference: http://mailman.nanog.org/pipermail/nanog/2011-March/034845.html http://mailman.nanog.org/pipermail/nanog/2011-March/034849.html Thanks, Wes George -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6781 bytes Desc: not available URL: From jcurran at arin.net Thu Mar 31 08:15:50 2011 From: jcurran at arin.net (John Curran) Date: Thu, 31 Mar 2011 12:15:50 +0000 Subject: [arin-ppml] ARIN validation of authorized contacts In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6949C@PLSWM12A.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6949C@PLSWM12A.ad.sprint.com> Message-ID: On Mar 31, 2011, at 7:34 AM, George, Wes E [NTK] wrote: > That is, how do you prove to ARIN that: > a) you are who you say you are George - We seek government-issued identification for this purpose. > b) that you are actually an agent for the company you are purportedly representing > c) that you are authorized to request changes on behalf of said company. These are addressed by requiring officer attestation for requests: > The situation where someone poses as an agent of a company (especially one that has let their records/domains lapse) in an effort to > acquire their address space in a way that looks semi-legitimate (by updating the ARIN records) is mainly an annoyance right now, > because ARIN usually works rapidly with the proper owners (if exist) to restore the correct contact info. > > However, my sense is that as long as the bills get paid and nothing triggers the "spidey sense" of ARIN staff, *accuracy* of records > is less important than simply having *valid* (reachable) POC records. As we look at the SIDR origin validation implementation, where > ARIN would be providing Resource Certificates for the rightful owner to originate an announcement of a given block of addresses, I > think this becomes more than just an annoyance. We will only provide certificates to the address holder per the ARIN Whois database. > The expectation is that other announcements that do not have that authority will be > either rejected or treated with lower priority than the validated announcement in the routing table. But this system is only as good > as the underlying verification to provide the delegation in the first place. If it's easily gamed, then the veracity of the > information is suspect and the entire implementation is of limited value as an input to a routing policy decision, not to mention the > fact that it opens legitimate resource holders up to exactly the type of attack this is trying to prevent. Agreed. We'd welcome any suggestions on improvements to these processes; as they are operational in nature, I'd recommend making them via the ARIN Consultation and Suggestion Process or at the open mike session at the ARIN Public meeting. Thanks! /John John Curran President and CEO ARIN From bensons at queuefull.net Thu Mar 31 08:51:11 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 31 Mar 2011 07:51:11 -0500 Subject: [arin-ppml] ARIN validation of authorized contacts In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6949C@PLSWM12A.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6949C@PLSWM12A.ad.sprint.com> Message-ID: <71C6F3A4-49E9-4BF0-860F-4D24D792B63D@queuefull.net> On Mar 31, 2011, at 6:34 AM, George, Wes E [NTK] wrote: > There's a thread on NANOG right now about some address hijacking/squatting, and it brings up an interesting question about how ARIN > determines whether a person purporting to represent a company is actually authorized to make changes. > ... > So my question is regarding the identification and validation of authorized agents. Is ARIN staff already thinking about ways to > manage this? Can we potentially kill two birds with one stone and improve the accuracy of ARIN whois records and support RPKI? Important questions, Wes - thanks for asking them. In addition, I would also like to understand the following: How does the ARIN process compare with existing models (e.g. SSL certificates)? Given the recent headlines about weakness in the certificate industry, is the ARIN process considered adequately robust? And given the single-root nature of RPKI as implemented by the RIRs (which differs from the SSL multi-CA model) are operators confident they can deal with potential systemic trust issues, i.e. around security threats, governance policy, etc? Cheers, -Benson From Wesley.E.George at sprint.com Thu Mar 31 08:53:51 2011 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Thu, 31 Mar 2011 12:53:51 +0000 Subject: [arin-ppml] ARIN validation of authorized contacts In-Reply-To: References: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6949C@PLSWM12A.ad.sprint.com> Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6954F@PLSWM12A.ad.sprint.com> John - thanks for your response. A couple of comments below inline Wes -----Original Message----- From: John Curran [mailto:jcurran at arin.net] Sent: Thursday, March 31, 2011 8:16 AM Subject: Re: [arin-ppml] ARIN validation of authorized contacts On Mar 31, 2011, at 7:34 AM, George, Wes E [NTK] wrote: > That is, how do you prove to ARIN that: > a) you are who you say you are We seek government-issued identification for this purpose. [WEG] How does that work if you're working entirely via email? Most of your customers don't exactly walk into your office. I don't remember being asked to provide any ID prior to being made the primary POC for an X-Large resource holder... I mean, in my case, one of the existing POCs added me, so in that sense, they vouched for my identity, but that could have just as easily been a compromised password that someone uses to update this information. > b) that you are actually an agent for the company you are purportedly > representing > c) that you are authorized to request changes on behalf of said company. These are addressed by requiring officer attestation for requests [WEG] Sure, for new resource requests. What about changes being requested to whois data, POC records, reverse DNS delegation, etc? > As we look at the SIDR origin validation implementation, where ARIN would be providing Resource Certificates for the rightful owner > to originate an announcement of a given block of addresses, I think this becomes more than just an annoyance. We will only provide certificates to the address holder per the ARIN Whois database. [WEG] Exactly my point. Unless you have a way of securing and vouching for the validity of those whois POC records, this is an attack vector. We had a subsidiary that we bought, and the address POC records had not been updated to point to our common address management team yet. In the meantime, a former employee of the subsidiary updated the records so that they now pointed to his new company, and so it looked like *we* were actually the ones using the addresses without authorization. They threatened us that they would start announcing the blocks within a few weeks until ARIN restored the correct address records. What happens if someone uses this to pull down a certification and doesn't warn the original owner first? I will try to bring this up at open mic, but I wanted to start some discussion here among some who may have ideas on the security BCP that would be appropriate here. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6781 bytes Desc: not available URL: From jcurran at arin.net Thu Mar 31 09:06:14 2011 From: jcurran at arin.net (John Curran) Date: Thu, 31 Mar 2011 13:06:14 +0000 Subject: [arin-ppml] ARIN validation of authorized contacts In-Reply-To: <71C6F3A4-49E9-4BF0-860F-4D24D792B63D@queuefull.net> References: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6949C@PLSWM12A.ad.sprint.com> <71C6F3A4-49E9-4BF0-860F-4D24D792B63D@queuefull.net> Message-ID: <567DF854-7DCB-4A30-9606-0DEAE0E00B08@arin.net> On Mar 31, 2011, at 8:51 AM, Benson Schliesser wrote: > And given the single-root nature of RPKI as implemented by the RIRs (which differs from the SSL multi-CA model) are operators confident they can deal with potential systemic trust issues, i.e. around security threats, governance policy, etc? Benson - At present, there is no single trust anchor for RPKI. It's been discussed by the RPKI community at length, as well as the RIR community, but it's still quite conceptual at this point. I know that the NRO recently asked ICANN about holding discussions (including folks such as the IAB) regarding ICANN potentially implementing a global trust anchor for RPKI; that letter is on the NRO web site: http://www.nro.net/news/letter-to-icann-single-trust-anchor FYI, /John From jcurran at arin.net Thu Mar 31 09:14:44 2011 From: jcurran at arin.net (John Curran) Date: Thu, 31 Mar 2011 13:14:44 +0000 Subject: [arin-ppml] ARIN validation of authorized contacts In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6954F@PLSWM12A.ad.sprint.com> References: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6949C@PLSWM12A.ad.sprint.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C6954F@PLSWM12A.ad.sprint.com> Message-ID: <29D92533-8CD4-4A2D-8BC5-E67BED328669@arin.net> On Mar 31, 2011, at 8:53 AM, George, Wes E [NTK] wrote: > John - thanks for your response. A couple of comments below inline > Wes > > -----Original Message----- > From: John Curran [mailto:jcurran at arin.net] > Sent: Thursday, March 31, 2011 8:16 AM > Subject: Re: [arin-ppml] ARIN validation of authorized contacts > > On Mar 31, 2011, at 7:34 AM, George, Wes E [NTK] wrote: > >> That is, how do you prove to ARIN that: >> a) you are who you say you are > We seek government-issued identification for this purpose. > > [WEG] How does that work if you're working entirely via email? Most of your customers don't exactly walk into your office. I don't > remember being asked to provide any ID prior to being made the primary POC for an X-Large resource holder... I mean, in my case, one > of the existing POCs added me, so in that sense, they vouched for my identity, but that could have just as easily been a compromised > password that someone uses to update this information. Absolutely. If you believe ARIN should add extra protections against such an attack (comprised account password), either optionally for an account or for everyone, that is definitely something that should be discussed. > These are addressed by requiring officer attestation for requests > > [WEG] Sure, for new resource requests. What about changes being requested to whois data, POC records, reverse DNS delegation, etc? For new resource requests, and sometimes related to reestablishment of authority over an address block when all contacts have become invalid. > We will only provide certificates to the address holder per the ARIN Whois database. > [WEG] Exactly my point. Unless you have a way of securing and vouching for the validity of those whois POC records, this is an > attack vector. We had a subsidiary that we bought, and the address POC records had not been updated to point to our common address > management team yet. In the meantime, a former employee of the subsidiary updated the records so that they now pointed to his new > company, and so it looked like *we* were actually the ones using the addresses without authorization. They threatened us that they > would start announcing the blocks within a few weeks until ARIN restored the correct address records. What happens if someone uses > this to pull down a certification and doesn't warn the original owner first? This would be considered an "internal controls" issue for most companies, and not much different than buying a subsidiary but having them change the building alarm codes to prevent access. Cases like these are going to almost always require legal documentation to straighten out, as ARIN can't know that an employee is no longer authorized to make changes unless the organization updates records promptly at ARIN. If you've got a suggestion for how to better deal with this, definitely make it known. > I will try to bring this up at open mic, but I wanted to start some discussion here among some who may have ideas on the security > BCP that would be appropriate here. Understood. /John John Curran President and CEO ARIN From jis at mit.edu Thu Mar 31 11:00:44 2011 From: jis at mit.edu (Jeffrey I. Schiller) Date: Thu, 31 Mar 2011 11:00:44 -0400 Subject: [arin-ppml] ARIN validation of authorized contacts In-Reply-To: <29D92533-8CD4-4A2D-8BC5-E67BED328669@arin.net> References: <54E900DC635DAB4DB7A6D799B3C4CD8E10C6949C@PLSWM12A.ad.sprint.com> <54E900DC635DAB4DB7A6D799B3C4CD8E10C6954F@PLSWM12A.ad.sprint.com> <29D92533-8CD4-4A2D-8BC5-E67BED328669@arin.net> Message-ID: <20110331150044.GE5505@mit.edu> On Thu, Mar 31, 2011 at 09:14:44AM -0400, John Curran wrote: > Absolutely. If you believe ARIN should add extra protections against > such an attack (comprised account password), either optionally for > an account or for everyone, that is definitely something that should > be discussed. I know that there are discussions in the SSL community about providing two-factor authentication. Some DNS registrars (name.com for example) offer two-factor authentication to customers (I am one of them who uses two-factor authentication with them). I am not sure the time is right for requiring POCs to use two-factor to authentication to ARIN, but it is probably a good time for ARIN to offer it as an option. I am particularly in favor of Google's approach. They make use of an open standard (OATH, RFC4226) and the customer gets to download their token seed (yes, this is a risk) which you can load into a smart phone based authenticator (or write your own code, as I have done). Google also creates a set of "scratch" codes which you are told to print and keep in a safe place. They can be used in lieu of an OATH code, in the case where you lose your phone. Of course part of Google's model is to avoid people having to contact Google's customer service to reset their account if they lose their tokens. It is also a low cost solution compared to other token vendors which charge $$ for the tokens (even a "soft" token loaded into a smart phone) or require you to validate customers via a web server they operate and charge $$ for. -Jeff -- _______________________________________________________________________ Jeffrey I. Schiller Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room N42-283 Cambridge, MA 02139-4307 617.253.0161 - Voice jis at mit.edu http://jis.qyv.name _______________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3502 bytes Desc: not available URL: