From narten at us.ibm.com Fri Mar 2 00:53:02 2012 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 02 Mar 2012 00:53:02 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201203020553.q225r2pr027869@rotala.raleigh.ibm.com> Total of 80 messages in the last 7 days. script run at: Fri Mar 2 00:53:02 EST 2012 Messages | Bytes | Who --------+------+--------+----------+------------------------ 10.00% | 8 | 14.66% | 128487 | tvest at eyeconomics.com 8.75% | 7 | 10.22% | 89606 | mpetach at netflight.com 7.50% | 6 | 7.10% | 62275 | owen at delong.com 7.50% | 6 | 6.63% | 58154 | astrodog at gmail.com 6.25% | 5 | 7.65% | 67075 | jrhett at netconsonance.com 3.75% | 3 | 6.94% | 60821 | kkargel at polartel.com 5.00% | 4 | 4.14% | 36260 | info at arin.net 3.75% | 3 | 4.88% | 42821 | arinfactcheck at gmail.com 5.00% | 4 | 3.36% | 29434 | hannigan at gmail.com 5.00% | 4 | 3.09% | 27107 | bill at herrin.us 3.75% | 3 | 3.64% | 31901 | jeffrey.lyon at blacklotus.net 3.75% | 3 | 3.00% | 26259 | admin at bango.org.bb 1.25% | 1 | 5.38% | 47164 | sean.copeland at ibips.com 3.75% | 3 | 2.54% | 22280 | cgrundemann at gmail.com 3.75% | 3 | 2.18% | 19104 | ppml at rs.seastrom.com 3.75% | 3 | 2.14% | 18791 | gbonser at seven.com 3.75% | 3 | 2.12% | 18606 | jcurran at arin.net 2.50% | 2 | 2.28% | 20009 | scottleibrand at gmail.com 1.25% | 1 | 1.68% | 14761 | alan at batie.org 1.25% | 1 | 0.96% | 8377 | narten at us.ibm.com 1.25% | 1 | 0.94% | 8271 | celestea at usc.edu 1.25% | 1 | 0.89% | 7772 | cengel at conxeo.com 1.25% | 1 | 0.85% | 7457 | farmer at umn.edu 1.25% | 1 | 0.76% | 6622 | keith at jcc.com 1.25% | 1 | 0.71% | 6225 | lar at mwtcorp.net 1.25% | 1 | 0.69% | 6016 | jsw at inconcepts.biz 1.25% | 1 | 0.58% | 5051 | jmaimon at chl.com --------+------+--------+----------+------------------------ 100.00% | 80 |100.00% | 876706 | Total From lear at cisco.com Fri Mar 2 02:51:55 2012 From: lear at cisco.com (Eliot Lear) Date: Fri, 02 Mar 2012 08:51:55 +0100 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net In-Reply-To: <201203020553.q225r2pr027869@rotala.raleigh.ibm.com> References: <201203020553.q225r2pr027869@rotala.raleigh.ibm.com> Message-ID: <4F507C1B.7020504@cisco.com> Thomas, I'm just curious: do these reports make you the overall top poster on across all these different mailing lists? ;-) Eliot On 3/2/12 6:53 AM, Thomas Narten wrote: > Total of 80 messages in the last 7 days. > > script run at: Fri Mar 2 00:53:02 EST 2012 > > Messages | Bytes | Who > --------+------+--------+----------+------------------------ > 10.00% | 8 | 14.66% | 128487 | tvest at eyeconomics.com > 8.75% | 7 | 10.22% | 89606 | mpetach at netflight.com > 7.50% | 6 | 7.10% | 62275 | owen at delong.com > 7.50% | 6 | 6.63% | 58154 | astrodog at gmail.com > 6.25% | 5 | 7.65% | 67075 | jrhett at netconsonance.com > 3.75% | 3 | 6.94% | 60821 | kkargel at polartel.com > 5.00% | 4 | 4.14% | 36260 | info at arin.net > 3.75% | 3 | 4.88% | 42821 | arinfactcheck at gmail.com > 5.00% | 4 | 3.36% | 29434 | hannigan at gmail.com > 5.00% | 4 | 3.09% | 27107 | bill at herrin.us > 3.75% | 3 | 3.64% | 31901 | jeffrey.lyon at blacklotus.net > 3.75% | 3 | 3.00% | 26259 | admin at bango.org.bb > 1.25% | 1 | 5.38% | 47164 | sean.copeland at ibips.com > 3.75% | 3 | 2.54% | 22280 | cgrundemann at gmail.com > 3.75% | 3 | 2.18% | 19104 | ppml at rs.seastrom.com > 3.75% | 3 | 2.14% | 18791 | gbonser at seven.com > 3.75% | 3 | 2.12% | 18606 | jcurran at arin.net > 2.50% | 2 | 2.28% | 20009 | scottleibrand at gmail.com > 1.25% | 1 | 1.68% | 14761 | alan at batie.org > 1.25% | 1 | 0.96% | 8377 | narten at us.ibm.com > 1.25% | 1 | 0.94% | 8271 | celestea at usc.edu > 1.25% | 1 | 0.89% | 7772 | cengel at conxeo.com > 1.25% | 1 | 0.85% | 7457 | farmer at umn.edu > 1.25% | 1 | 0.76% | 6622 | keith at jcc.com > 1.25% | 1 | 0.71% | 6225 | lar at mwtcorp.net > 1.25% | 1 | 0.69% | 6016 | jsw at inconcepts.biz > 1.25% | 1 | 0.58% | 5051 | jmaimon at chl.com > --------+------+--------+----------+------------------------ > 100.00% | 80 |100.00% | 876706 | Total > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From Daniel_Alexander at Cable.Comcast.com Thu Mar 8 14:28:58 2012 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Thu, 8 Mar 2012 19:28:58 +0000 Subject: [arin-ppml] ARIN-2012-1: Clarifying requirements for IPv4 transfers In-Reply-To: Message-ID: Owen and Chris G, In previous threads you have suggested the inclusion of transfers in the 12 month restriction on the source organization of a transfer. This would be in addition to any allocation or assignment from ARIN's free pool. I have asked ARIN staff for feedback and they raised a point. Section 8.2 transfers are often used to bring records up to date prior to any 8.3 transfer. If we only say "transfers" without clarifying, it could create an issue. Is your thought to include any and all transfers as triggering a 12 month black out from further sourcing transfers, or would you suggest only 8.3 (and 8.4 as this proposal is written) transfers be included in the restriction? Everyone else on the mailing list is encouraged to respond as well. I would really like to continue the conversation regarding this point and the proposal as a whole. I've included the current text as a reference. Thank you, Dan Alexander AC Shepherd Current text: 2012-1: Clarifying requirements for IPv4 transfers Replace Section 8.3 with 8.3 Transfers between Specified Recipients within the ARIN Region. In addition to transfers under section 8.2, IPv4 numbers resources may be transferred according to the following conditions. Conditions on source of the transfer: * The source entity must be the current registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources. * The source entity will be ineligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs first. * The source entity must not have received an allocation or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. * The minimum transfer size is a /24 Conditions on recipient of the transfer: * The recipient must demonstrate the need for up to a 24 month supply of IP address resources under current ARIN policies and sign an RSA. * The resources transferred will be subject to current ARIN policies. Add Section 8.4 Inter-RIR Transfers to Specified Recipients Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies. Conditions on source of the transfer: * The source entity must be the current rights holder of the IPv4 address resources recognized by the RIR responsible for the resources, and not be involved in any dispute as to the status of those resources. * Source entities outside of the ARIN region must meet any requirements defined by the RIR where the source entity holds the registration. * Source entities within the ARIN region will not be eligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever occurs first. * Source entities within the ARIN region must not have received an allocation or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. * The minimum transfer size is a /24. Conditions on recipient of the transfer: * The conditions on a recipient outside of the ARIN region will be defined by the policies of the receiving RIR. * Recipients within the ARIN region will be subject to current ARIN policies and sign an RSA for the resources being received. * Recipients within the ARIN region must demonstrate the need for up to a 24 month supply of IPv4 address space. * The minimum transfer size is a /24 From cgrundemann at gmail.com Thu Mar 8 14:56:15 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 8 Mar 2012 12:56:15 -0700 Subject: [arin-ppml] ARIN-2012-1: Clarifying requirements for IPv4 transfers In-Reply-To: References: Message-ID: On Thu, Mar 8, 2012 at 12:28, Alexander, Daniel wrote: > Owen and Chris G, > > In previous threads you have suggested the inclusion of transfers in the > 12 month restriction on the source organization of a transfer. This would > be in addition to any allocation or assignment from ARIN's free pool. > > I have asked ARIN staff for feedback and they raised a point. Section 8.2 > transfers are often used to bring records up to date prior to any 8.3 > transfer. If we only say "transfers" without clarifying, it could create > an issue. Is your thought to include any and all transfers as triggering a > 12 month black out from further sourcing transfers, or would you suggest > only 8.3 (and 8.4 as this proposal is written) transfers be included in > the restriction? That's a good point (not uncommon for ARIN staff). M&A transfers come with infrastructure (they are not *just* the transfer of IP addresses) and thus should not count against an organization wrt future allocations, assignments, or transfers as long as they remain efficiently utilized, properly registered in whois, etc. Cheers, ~Chris > Everyone else on the mailing list is encouraged to respond as well. I > would really like to continue the conversation regarding this point and > the proposal as a whole. I've included the current text as a reference. > > Thank you, > Dan Alexander > AC Shepherd > > > Current text: 2012-1: Clarifying requirements for IPv4 transfers > > Replace Section 8.3 with > > 8.3 Transfers between Specified Recipients within the ARIN Region. > > In addition to transfers under section 8.2, IPv4 numbers resources may be > transferred according to the following conditions. > > Conditions on source of the transfer: > > * The source entity must be the current registered holder of the IPv4 > address resources, and not be involved in any dispute as to the status of > those resources. > * The source entity will be ineligible to receive any further IPv4 address > allocations or assignments from ARIN for a period of 12 months after a > transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever > occurs first. > * The source entity must not have received an allocation or assignment of > IPv4 number resources from ARIN for the 12 months prior to the approval of > a transfer request. > * The minimum transfer size is a /24 > > Conditions on recipient of the transfer: > > * The recipient must demonstrate the need for up to a 24 month supply of > IP address resources under current ARIN policies and sign an RSA. > * The resources transferred will be subject to current ARIN policies. > > > Add Section 8.4 Inter-RIR Transfers to Specified Recipients > > Inter-regional transfers may take place only via RIRs who agree to the > transfer and share reciprocal, compatible, needs-based policies. > > Conditions on source of the transfer: > > * The source entity must be the current rights holder of the IPv4 address > resources recognized by the RIR responsible for the resources, and not be > involved in any dispute as to the status of those resources. > * Source entities outside of the ARIN region must meet any requirements > defined by the RIR where the source entity holds the registration. > * Source entities within the ARIN region will not be eligible to receive > any further IPv4 address allocations or assignments from ARIN for a period > of 12 months after a transfer approval, or until the exhaustion of ARIN's > IPv4 space, whichever occurs first. > * Source entities within the ARIN region must not have received an > allocation or assignment of IPv4 number resources from ARIN for the 12 > months prior to the approval of a transfer request. > * The minimum transfer size is a /24. > > > Conditions on recipient of the transfer: > > * The conditions on a recipient outside of the ARIN region will be defined > by the policies of the receiving RIR. > * Recipients within the ARIN region will be subject to current ARIN > policies and sign an RSA for the resources being received. > * Recipients within the ARIN region must demonstrate the need for up to a > 24 month supply of IPv4 address space. > * The minimum transfer size is a /24 > > -- @ChrisGrundemann http://chrisgrundemann.com From info at arin.net Thu Mar 8 14:58:45 2012 From: info at arin.net (ARIN) Date: Thu, 08 Mar 2012 14:58:45 -0500 Subject: [arin-ppml] Petition for Discussion of ARIN-prop-163 In-Reply-To: <4F4EEF65.9070902@arin.net> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4F46AC77.8060206@arin.net> <4F4EEF65.9070902@arin.net> Message-ID: <4F590F75.605@arin.net> This petition did not receive the required 10 statements of support and was therefore not successful. ARIN-prop-163 is closed. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) On 2/29/12 10:39 PM, ARIN wrote: >> The duration of the petition is until five business days after the AC's >> draft meeting minutes are published. ARIN staff will post the result of >> the petition to PPML. > > The minutes of the AC's 16 February 2012 meeting have been published > and are available at: > https://www.arin.net/about_us/ac/index.html > > This petition will end on 7 March 2012. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > On 2/23/12 4:15 PM, ARIN wrote: >> The message below started a petition regarding the ARIN Advisory >> Council's decision to abandon ARIN-prop-163. The AC's decision was >> posted by ARIN staff to PPML on 22 February 2012. >> >> If successful, this petition will change ARIN-prop-163 into a Draft >> Policy which will be published for adoption discussion on the PPML and >> at the Public Policy Meeting in April 2012. If the petition fails, the >> proposal will be closed. >> >> For this petition to be successful, the petition needs statements of >> support from at least 10 different people from 10 different >> organizations. If you wish to support this petition, post a statement of >> support to PPML on this thread. >> >> The duration of the petition is until five business days after the AC's >> draft meeting minutes are published. ARIN staff will post the result of >> the petition to PPML. >> >> For more information on starting and participating in petitions, see PDP >> Petitions at: >> https://www.arin.net/policy/pdp_petitions.html >> >> The proposal text is below and 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) >> >> >> ##### >> >> >>> -----Original Message----- >>> From: Joe Maimon >>> Date: Wed, 22 Feb 2012 23:47:10 -0500 >>> To: "ppml >> \"ppml at arin.net\"" >>> Subject: [arin-ppml] Petition for advancement of Policy Proposal #163 >>> Dedicated resources for initial ISP allocations, to Draft Policy status >>> >>> All, >>> >>> I am unsatisfied with the AC's abandonment of Policy Proposal #163 >>> Dedicated resources for initial ISP allocations. >>> >>> I formally petition you, the members of this regional community, for >>> your support in advancing to draft policy status the proposal and >>> for it >>> to be discussed at an upcoming ARIN Public Policy meeting. >>> >>> I ask you for statements in support of this petition. >>> >>> The full policy proposal text is available at >>> >>> http://lists.arin.net/pipermail/arin-ppml/2012-February/024054.html >>> >>> Best and my thanks, >>> >>> Joe >>> >>> >>> _______________________________________________ >>> 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. >> >> >> ARIN-prop-163 Dedicated resources for initial ISP allocations >> >> Proposal Originator: Joe Maimon >> >> Proposal Version: 1.0 >> >> Date: 1 February 2012 >> >> Proposal type: New >> >> Policy term: Temporary >> >> Policy statement: >> >> Add >> >> 4.2.2.4. Resources dedicated for initial ISP allocations. >> >> Prior to any allocation or assignment that will cause ARIN's total >> available, unreserved and non-dedicated resources to fall under a total >> of a /8, ARIN will first ensure that dedicated resources equivalent to a >> /10 are available from the remainder of the available resources. These >> resources are to be used solely for initial ISP allocations that cannot >> be fulfilled from any other available ARIN resources. >> >> 4.2.2.4.1 Restrictions >> >> ARIN may require qualifying organizations to demonstrate that they were >> not created solely to receive resources from these dedicated resources. >> >> 4.2.2.4.2 Replenishment >> >> ARIN will replenish the available dedicated resources, up to the total >> of a /10 of available resources, whenever there are sufficient available >> resources, with no more than 25% of the available resources going for >> this purpose. >> >> 4.2.2.4.3 Reporting >> >> ARIN will keep numbers and statistics available as to the total size of >> the dedicated resources, allocated and unallocated and to how many >> members allocations were made, available annually. >> >> 4.2.2.4.4 Retirement >> >> ARIN will retire this section whenever two full calendar years go by >> that no allocations are made from these resources, following their >> creation. >> >> Rationale: >> >> I believe it is important to ensure access to new entities to the IPv4 >> resources ARIN maintains stewardship over. Without a policy like this >> one, they are unlikely to have any alternative other then to use PA >> space or utilize transfers that may be prohibitively burdensome. >> >> I also believe it is important to ARIN to be an essential and relevant >> entity to the process of getting these new ISP's to their footing with >> IPv4 resources. >> >> ARIN informal numbers: >> >> Total first time IPv4 allocations to ISPs approved in 2011: 318 >> Total IPv4 space approved for: 2,812 /24s >> >> Total additional IPv4 allocations to ISPs in 2011: 497 ISP accounts >> received at least one additional IPv4 allocation. >> Total IPv4 space approved for: 70,569 /24s >> >> This suggests that maintaining resources for these new ISPs can ensure a >> steady influx of new members who would otherwise have much more limited >> options, and that a /10 can provide an estimated 4 years of access to >> these resources. >> >> This same /10 would last for additional allocations less than a year. >> >> Timetable for implementation: Before ARIN has less than a /8 in >> its free pool. >> >> > From info at arin.net Thu Mar 8 14:59:02 2012 From: info at arin.net (ARIN) Date: Thu, 08 Mar 2012 14:59:02 -0500 Subject: [arin-ppml] Petition for Discussion of ARIN-prop-164 In-Reply-To: <4F4EEF41.5000908@arin.net> References: <8A5E1973-DD08-436E-8D5F-F79F28197DFA@delong.com> <4F46ABF8.80206@arin.net> <4F4EEF41.5000908@arin.net> Message-ID: <4F590F86.3070909@arin.net> This petition did not receive the required 10 statements of support and was therefore not successful. ARIN-prop-164 is closed. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) On 2/29/12 10:38 PM, ARIN wrote: >> The duration of the petition is until five business days after the AC's >> draft meeting minutes are published. ARIN staff will post the result of >> the petition to PPML. > > The minutes of the AC's 16 February 2012 meeting have been published > and are available at: > https://www.arin.net/about_us/ac/index.html > > This petition will end on 7 March 2012. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > > On 2/23/12 4:13 PM, ARIN wrote: >> The message below started a petition regarding the ARIN Advisory >> Council's decision to abandon ARIN-prop-164. The AC's decision was >> posted by ARIN staff to PPML on 22 February 2012. >> >> If successful, this petition will change ARIN-prop-164 into a Draft >> Policy which will be published for adoption discussion on the PPML and >> at the Public Policy Meeting in April 2012. If the petition fails, the >> proposal will be closed. >> >> For this petition to be successful, the petition needs statements of >> support from at least 10 different people from 10 different >> organizations. If you wish to support this petition, post a statement of >> support to PPML on this thread. >> >> The duration of the petition is until five business days after the AC's >> draft meeting minutes are published. ARIN staff will post the result of >> the petition to PPML. >> >> For more information on starting and participating in petitions, see PDP >> Petitions at: >> https://www.arin.net/policy/pdp_petitions.html >> >> The proposal text is below and 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) >> >> >> ##### >> >> >>> -----Original Message----- >>> From: Joe Maimon >>> Date: Wed, 22 Feb 2012 23:47:12 -0500 >>> To: "ppml >> \"ppml at arin.net\"" >>> Subject: [arin-ppml] Petition for advancement of Policy Proposal #164 >>> Predictable ARIN IPv4 Resource exhaustion, to Draft Policy status >>> >>> All, >>> >>> I am unsatisfied with the AC's abandonment of Policy Proposal #164 >>> Predictable ARIN IPv4 Resource exhaustion. >>> >>> I formally petition you, the members of this regional community, for >>> your support in advancing to draft policy status the proposal and >>> for it >>> to be discussed at an upcoming ARIN Public Policy meeting. >>> >>> I ask you for statements in support of this petition. >>> >>> The full policy proposal text is available at >>> >>> http://lists.arin.net/pipermail/arin-ppml/2012-February/024055.html >>> >>> Best and my thanks, >>> >>> Joe >>> >>> >>> _______________________________________________ >>> 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. >> >> ARIN-prop-164 Predictable ARIN IPv4 Resource exhaustion >> >> Proposal Originator: Joe Maimon >> >> Proposal Version: 1.0 >> >> Date: 1 February 2012 >> >> Proposal type: New >> >> Policy term: Temporary >> >> Policy statement: >> >> Add a section to 4 >> >> Upon the last calendar date of the year that this proposal is adopted, >> ARIN will disburse all of its available IPv4 resources to its existing >> members, in proportion to their fee schedule, with the smallest >> allocation of size /24, to be effective immediately. >> >> Rationale: >> >> Many people feel that ARIN has too much available resources. Many people >> also believe that the uncertainty as to when ARIN will run out of these >> resources is not good. This proposal seeks to resolve both of these >> concerns. >> >> Timetable for implementation: Immediate >> >> >> > From owen at delong.com Thu Mar 8 15:14:14 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 8 Mar 2012 12:14:14 -0800 Subject: [arin-ppml] ARIN-2012-1: Clarifying requirements for IPv4 transfers In-Reply-To: References: Message-ID: <755CF36A-9B69-414E-8092-05AF505A8DAC@delong.com> On Mar 8, 2012, at 11:28 AM, Alexander, Daniel wrote: > Owen and Chris G, > > In previous threads you have suggested the inclusion of transfers in the > 12 month restriction on the source organization of a transfer. This would > be in addition to any allocation or assignment from ARIN's free pool. > > I have asked ARIN staff for feedback and they raised a point. Section 8.2 > transfers are often used to bring records up to date prior to any 8.3 > transfer. If we only say "transfers" without clarifying, it could create > an issue. Is your thought to include any and all transfers as triggering a > 12 month black out from further sourcing transfers, or would you suggest > only 8.3 (and 8.4 as this proposal is written) transfers be included in > the restriction? > I would have no problem with providing an exception for 8.2 transfers. I would want to see it written as an exemption for M&A and not a limitation that this applies only to particular sections of the transfer policy. The difference is the default state for future policy changes. I think it is important for the default to be that this limitation apples. Owen > Everyone else on the mailing list is encouraged to respond as well. I > would really like to continue the conversation regarding this point and > the proposal as a whole. I've included the current text as a reference. > > Thank you, > Dan Alexander > AC Shepherd > > > Current text: 2012-1: Clarifying requirements for IPv4 transfers > > Replace Section 8.3 with > > 8.3 Transfers between Specified Recipients within the ARIN Region. > > In addition to transfers under section 8.2, IPv4 numbers resources may be > transferred according to the following conditions. > > Conditions on source of the transfer: > > * The source entity must be the current registered holder of the IPv4 > address resources, and not be involved in any dispute as to the status of > those resources. > * The source entity will be ineligible to receive any further IPv4 address > allocations or assignments from ARIN for a period of 12 months after a > transfer approval, or until the exhaustion of ARIN's IPv4 space, whichever > occurs first. > * The source entity must not have received an allocation or assignment of > IPv4 number resources from ARIN for the 12 months prior to the approval of > a transfer request. > * The minimum transfer size is a /24 > > Conditions on recipient of the transfer: > > * The recipient must demonstrate the need for up to a 24 month supply of > IP address resources under current ARIN policies and sign an RSA. > * The resources transferred will be subject to current ARIN policies. > > > Add Section 8.4 Inter-RIR Transfers to Specified Recipients > > Inter-regional transfers may take place only via RIRs who agree to the > transfer and share reciprocal, compatible, needs-based policies. > > Conditions on source of the transfer: > > * The source entity must be the current rights holder of the IPv4 address > resources recognized by the RIR responsible for the resources, and not be > involved in any dispute as to the status of those resources. > * Source entities outside of the ARIN region must meet any requirements > defined by the RIR where the source entity holds the registration. > * Source entities within the ARIN region will not be eligible to receive > any further IPv4 address allocations or assignments from ARIN for a period > of 12 months after a transfer approval, or until the exhaustion of ARIN's > IPv4 space, whichever occurs first. > * Source entities within the ARIN region must not have received an > allocation or assignment of IPv4 number resources from ARIN for the 12 > months prior to the approval of a transfer request. > * The minimum transfer size is a /24. > > > Conditions on recipient of the transfer: > > * The conditions on a recipient outside of the ARIN region will be defined > by the policies of the receiving RIR. > * Recipients within the ARIN region will be subject to current ARIN > policies and sign an RSA for the resources being received. > * Recipients within the ARIN region must demonstrate the need for up to a > 24 month supply of IPv4 address space. > * The minimum transfer size is a /24 > From narten at us.ibm.com Fri Mar 9 00:53:03 2012 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 09 Mar 2012 00:53:03 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201203090553.q295r3T4006718@rotala.raleigh.ibm.com> Total of 7 messages in the last 7 days. script run at: Fri Mar 9 00:53:03 EST 2012 Messages | Bytes | Who --------+------+--------+----------+------------------------ 28.57% | 2 | 30.78% | 19106 | info at arin.net 14.29% | 1 | 15.30% | 9498 | cgrundemann at gmail.com 14.29% | 1 | 15.22% | 9448 | owen at delong.com 14.29% | 1 | 13.73% | 8525 | daniel_alexander at cable.comcast.com 14.29% | 1 | 12.67% | 7865 | lear at cisco.com 14.29% | 1 | 12.29% | 7628 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 7 |100.00% | 62070 | Total From info at arin.net Tue Mar 13 15:37:49 2012 From: info at arin.net (ARIN) Date: Tue, 13 Mar 2012 15:37:49 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - March 2012 Message-ID: <4F5FA20D.8070201@arin.net> In accordance with the ARIN Policy Development Process, the ARIN Advisory Council (AC) held a meeting on 8 March 2012 and made decisions about several proposals. The AC selected the following proposals as draft policies for adoption discussion online and at the ARIN XXIX Public Policy Meeting in Vancouver in April. The draft policies will be posted shortly to the PPML. ARIN-prop-157 Section 8.3 Simplification ARIN-prop-162 Redefining request window in 4.2.4.4 The AC abandoned the following proposal: ARIN-prop-165 Eliminate Needs-Based Justification on 8.3 Specified Transfers The AC provided the following statement about prop-165: "Based on significant community opposition to the removal of the needs requirement in 8.3 transfers, the AC chose to abandon proposal 165. While the author has brought to light privately additional issues, most of them are procedural in nature and would require a complete rewrite of both the policy and rationale text well beyond the original proposal's intent. The AC feels that there is merit in the discussion of these issues, and suggests that the author look at more specific issues outside of removal of needs, that could be applied to new proposal submissions." The AC thanks the authors and the community for their continuing effort and contributions to these and all other policy considerations. The AC abandoned proposal 165. The AC is advancing draft policy text for proposals 157 and 162 that differs from the original proposal texts. Anyone dissatisfied with these decisions may initiate a petition. The petition to advance these proposals is the "Discussion Petition." The deadline to begin a petition will be five business days after the AC's draft meeting minutes are published. Note that in order for a petition of any of the proposals to be considered successful for the upcoming ARIN XXIX meeting, the petition must be concluded by 18 March 2012 in order to meet the requirement of posting as draft policy at least 35 days prior to the meeting. If you are considering petitioning, starting one early is better than later. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html Draft Policy and 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 scottleibrand at gmail.com Tue Mar 13 16:09:28 2012 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 13 Mar 2012 13:09:28 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - March 2012 In-Reply-To: <4F5FA20D.8070201@arin.net> References: <4F5FA20D.8070201@arin.net> Message-ID: On Tue, Mar 13, 2012 at 12:37 PM, ARIN wrote: > In accordance with the ARIN Policy Development Process, the ARIN Advisory > Council (AC) held a meeting on 8 March 2012 and made decisions about > several proposals. > > The AC selected the following proposals as draft policies for adoption > discussion online and at the ARIN XXIX Public Policy Meeting in > Vancouver in April. The draft policies will be posted shortly to the PPML. > > ARIN-prop-157 Section 8.3 Simplification > This is a revised version that the AC also retitled to "ASN transfers". The revised draft policy text is short enough to post here: In NRPM 8.3, replace "IPv4 number resources" with "IPv4 number resources and ASNs". I personally feel that while there is not a compelling need to be able to transfer ASNs as there was/is with IPv4 addresses, that there are legitimate use cases, and very few downsides that I can see to allowing it. > ARIN-prop-162 Redefining request window in 4.2.4.4 > This was also re-titled to "Return to 12 Month Supply and Reset Trigger to /8 in Free Pool". In my opinion we have (perhaps unintentionally) achieved somewhat of a "soft landing" with the current policy that allows for 3 month allocations from the free pool and 24 months worth of space via transfer. I don't think moving back to a 12 month free pool supply will be helpful, but I voted to put this on the agenda for Vancouver because I think we need to have a full discussion on it. > The AC abandoned the following proposal: > > ARIN-prop-165 Eliminate Needs-Based Justification on 8.3 Specified > Transfers > The AC provided the following statement about prop-165: > "Based on significant community opposition to the removal of the needs > requirement in 8.3 transfers, the AC chose to abandon proposal 165. While > the author has brought to light privately additional issues, most of them > are procedural in nature and would require a complete rewrite of both the > policy and rationale text well beyond the original proposal's intent. The > AC feels that there is merit in the discussion of these issues, and > suggests that the author look at more specific issues outside of removal of > needs, that could be applied to new proposal submissions." > I was in the minority here, largely because I think this is an important issue that should be discussed at the public policy meeting. (I was not in favor of putting this particular text up for adoption discussion, and in any event, it was received too late to make the timeline for Vancouver). Given that the majority of the AC (and the community) opposed this particular text, I would agree with the statement above that "The AC feels that there is merit in the discussion of these issues, and suggests that the author look at more specific issues outside of removal of needs, that could be applied to new proposal submissions." I look forward to having such discussion at upcoming meeting(s) and working towards a consensus proposal for how to assess needs basis on transfers, particularly after the free pool is empty. > > The AC thanks the authors and the community for their continuing effort > and contributions to these and all other policy considerations. > Agreed! I'd particularly like to thank those new contributors (and long-term silent list readers) who've gotten involved and spoken up recently. -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Mar 13 17:33:46 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 13 Mar 2012 14:33:46 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - March 2012 In-Reply-To: References: <4F5FA20D.8070201@arin.net> Message-ID: <7CF6B21C-4CA7-4DFB-A442-07616BD40A52@delong.com> On Mar 13, 2012, at 1:09 PM, Scott Leibrand wrote: > On Tue, Mar 13, 2012 at 12:37 PM, ARIN wrote: > In accordance with the ARIN Policy Development Process, the ARIN Advisory Council (AC) held a meeting on 8 March 2012 and made decisions about several proposals. > > The AC selected the following proposals as draft policies for adoption > discussion online and at the ARIN XXIX Public Policy Meeting in > Vancouver in April. The draft policies will be posted shortly to the PPML. > > ARIN-prop-157 Section 8.3 Simplification > > This is a revised version that the AC also retitled to "ASN transfers". The revised draft policy text is short enough to post here: > > In NRPM 8.3, replace "IPv4 number resources" with "IPv4 number resources and ASNs". > > I personally feel that while there is not a compelling need to be able to transfer ASNs as there was/is with IPv4 addresses, that there are legitimate use cases, and very few downsides that I can see to allowing it. > Scott has not yet been able to articulate to me use cases that I consider particularly legitimate, so, community input in that regard would be helpful. Personally, I don't feel that there is a compelling need for this. Further, given the number of problems we have already created by opening up a market in IPv4 number resources, I really feel that it is imprudent to expand this strategy before we've had time to better understand the ramifications of such a transfer policy and work out some of the policy kinks. There was urgency and a necessity for implementing an IPv4 resource transfer policy and process. I see no such urgency for ASN transfers and I don't think we need to be creating more headaches for staff and more policy problems for ourselves at this time. I supported the motion to discuss this with the community, but, as it currently stands, I do not support the draft policy. > ARIN-prop-162 Redefining request window in 4.2.4.4 > > This was also re-titled to "Return to 12 Month Supply and Reset Trigger to /8 in Free Pool". > > In my opinion we have (perhaps unintentionally) achieved somewhat of a "soft landing" with the current policy that allows for 3 month allocations from the free pool and 24 months worth of space via transfer. I don't think moving back to a 12 month free pool supply will be helpful, but I voted to put this on the agenda for Vancouver because I think we need to have a full discussion on it. It is my opinion that we missed the target on the soft landing we were trying to achieve and we have actually caused quite a bit of harm in the process. When we passed the soft landing proposal, we did not realize that there would be a significant difference between the time that ARIN received its last /8 from IANA and the time that ARIN would be starting to consume that last /8 for address allocations. It was much easier to codify the IANA date than the ARIN free pool based date which resulted in policy that was easier to read and understand. Unfortunately, since the dates ended up being far apart, it is having significant impact to a number of organizations in the ARIN constituency and I believe we should correct this mistake post haste. On the other hand, if we debate the issue long enough, it will become moot in 1-2 policy cycles. > > The AC abandoned the following proposal: > > ARIN-prop-165 Eliminate Needs-Based Justification on 8.3 Specified Transfers > > The AC provided the following statement about prop-165: > "Based on significant community opposition to the removal of the needs > requirement in 8.3 transfers, the AC chose to abandon proposal 165. While the author has brought to light privately additional issues, most of them are procedural in nature and would require a complete rewrite of both the policy and rationale text well beyond the original proposal's intent. The AC feels that there is merit in the discussion of these issues, and suggests that the author look at more specific issues outside of removal of needs, that could be applied to new proposal submissions." > > I was in the minority here, largely because I think this is an important issue that should be discussed at the public policy meeting. (I was not in favor of putting this particular text up for adoption discussion, and in any event, it was received too late to make the timeline for Vancouver). > > Given that the majority of the AC (and the community) opposed this particular text, I would agree with the statement above that "The AC feels that there is merit in the discussion of these issues, and suggests that the author look at more specific issues outside of removal of needs, that could be applied to new proposal submissions." I look forward to having such discussion at upcoming meeting(s) and working towards a consensus proposal for how to assess needs basis on transfers, particularly after the free pool is empty. It might be an important issue. However, it is an issue that has been discussed, re-discussed, and discussed again. The community each and every time this has come up has resoundingly responded with opposition to eliminating needs basis. Further, we structured our response to inter-RIR transfers to say "agree to needs basis or go play in your own sandbox without access to resources from the ARIN community". That was almost the only aspect of inter-RIR transfers that had really wide community consensus from the start. I'm not saying we shouldn't discuss it further, but, this proposal in anything remotely resembling its current form had such overwhelming community opposition that I felt any action other than abandonment would have been disingenuous to the community and to the author. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Wed Mar 14 11:07:26 2012 From: info at arin.net (ARIN) Date: Wed, 14 Mar 2012 11:07:26 -0400 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers Message-ID: <4F60B42E.9040101@arin.net> Draft Policy ARIN-2012-3 ASN Transfers On 8 March 2012 the ARIN Advisory Council (AC) selected "ASN Transfers" as a draft policy for adoption discussion on the PPML and at the Public Policy Meeting in Vancouver in April. The draft was developed by the AC from policy proposal "ARIN-prop-157 Section 8.3 Simplification." Per the Policy Development Process the AC submitted text to ARIN for a staff and legal assessment prior to its selection as a draft policy. Below the draft policy is the ARIN staff and legal assessment, followed by the text that was submitted by the AC. Draft Policy ARIN-2012-3 is below and can be found at: https://www.arin.net/policy/proposals/2012_3.html You are encouraged to discuss Draft Policy 2012-3 on the PPML prior to the April Public Policy Meeting. Both the discussion on the list and at the meeting will be used by the ARIN Advisory Council to determine the community consensus for adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2012-3 ASN Transfers Date: 14 March 2012 Policy statement: In NRPM 8.3, replace "IPv4 number resources" with "IPv4 number resources and ASNs". Rationale: There are legitimate use cases for transferring ASNs, and no significant downsides (identified to date) of allowing it. Timetable for implementation: Immediate ########## ARIN STAFF ASSESSMENT Draft Policy: Proposal 157 ?ASN Transfers? Date of Assessment: 23 Feb 2012 1. Proposal Summary (Staff Understanding) This proposal would allow organizations to transfer ASNs in addition to IPv4 address space in an 8.3 transfer to specified recipients. 2. Comments A. ARIN Staff Comments ? If implemented as written, the 24-month utilization requirement in 8.3 would not apply to ASN requests since 8.3 clearly says ?how the addresses will be utilized in 24 months?. Staff would apply the current ASN policy, which requires an organization to be multi-homed or to immediately become multi-homed. B. ARIN General Counsel This creates no legal concerns and may actually facilitate any bankruptcy proceedings where ASNs are involved. 3. Resource Impact This policy would have minimum 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 4. Proposal Text Policy statement: In NRPM 8.3, replace "IPv4 number resources" with "IPv4 number resources and ASNs". Rationale: There are legitimate use cases for transferring ASNs, and no significant downsides (identified to date) of allowing it. Timetable for implementation: Immediate From info at arin.net Wed Mar 14 11:07:46 2012 From: info at arin.net (ARIN) Date: Wed, 14 Mar 2012 11:07:46 -0400 Subject: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool Message-ID: <4F60B442.1030706@arin.net> Draft Policy ARIN-2012-4 Return to 12 Month Supply and Reset Trigger to /8 in Free Pool On 8 March 2012 the ARIN Advisory Council (AC) selected "Return to 12 Month Supply and Reset Trigger to /8 in Free Pool" as a draft policy for adoption discussion on the PPML and at the Public Policy Meeting in Vancouver in April. The draft was developed by the AC from policy proposal "ARIN-prop-162 Redefining request window in 4.2.4.4." Per the Policy Development Process the AC submitted text to ARIN for a staff and legal assessment prior to its selection as a draft policy. Below the draft policy is the ARIN staff and legal assessment, followed by the text that was submitted by the AC. Draft Policy ARIN-2012-4 is below and can be found at: https://www.arin.net/policy/proposals/2012_4.html You are encouraged to discuss Draft Policy 2012-4 on the PPML prior to the April Public Policy Meeting. Both the discussion on the list and at the meeting will be used by the ARIN Advisory Council to determine the community consensus for adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2012-4 Return to 12 Month Supply and Reset Trigger to /8 in Free Pool Date: 14 March 2012 Policy statement: 4.2.4.4. Subscriber Members After One Year After an organization has been a subscriber member of ARIN for one year, they may choose to request up to a twelve (12) month supply of IP addresses. When the ARIN Free Pool is down to the equivalent of one /8, excluding all special reservations, the length of supply that an organization may request will be reduced. An organization may choose to request up to a three (3) month supply of IP addresses. Any request that reduces the ARIN free pool below the /8 threshold above will trigger the reduction for that and all subsequent requests by all organizations. Rationale: There has been discussion in the community that ARIN's inventory of IPv4 addresses may be excessive given the reduction in the rate of consumption which is concurrent with the reduction to a 3 month supply when ARIN received its last /8 at IANA run-out. And that such an excess inventory in the ARIN region may be damaging the transition to IPv6 by elongating the amount of time between ARIN's exhaustion and exhaustion by other RIR's, thus creating a dangerous skew across parts of Internet in the need to transition to IPv6. One solution for this issue is to increase ARIN's rate of consumption by restoring the a 12 month supply of addresses. ARIN's stewardship responsibilities are of primary concern in this region. However, restoring the a 12 month supply of addresses is consistent with these stewardship responsibilities. Asking businesses to request addresses on a three month basis with such large inventory available at ARIN unnecessarily increases the cost and complexity of operating networks; repeated and slow interactions with ARIN, duplicate paperwork requirements and an inefficient use of resources by all compound the pain. The original intent of ARIN-2009-8 "Equitable IPv4 Run-Out" wasn't necessarily to slow the consumption of IPv4 but to limit the competitive disadvantage created by unequal run-out. However, when the trigger of IANA run-out was selected it wasn't anticipated that ARIN would have more that 5 /8s in inventory when the IANA run-out occurred. Therefore, restoring the 12-month supply and resetting the trigger for a reduction to a 3-month supply to a locally controlled event seems consistent with the original intent of ARIN-2009-8 as well. Considering that the ARIN region has consumed significantly less than a /8 since the 3-month supply was triggered at IANA run-out approximately a year ago; Resetting the trigger for the 3-month supply to /8 in the free pool, excluding all special reservations, seems reasonable. The special reservations to be excluded, should include all reservations made in policy, including those in sections 4.4, 4.10, any new reservations made by subsequent policies, and may also include reservations for draft policies in process at the board's discretion, such as Draft Policy ARIN-2011-5: Shared Transition Space for IPv4 Address Extension. Please Note: By triggering on any request that would drop the free pool below /8 it is possible that there will be slightly more or slightly less than /8 available after the triggering request is fulfilled. The size of the triggering request and the exact amount above /8 available in the free pool will determine how much more or less than /8 will be available after the triggering request is fulfilled. This could be as much as 3/4 of the triggering request above /8 or as much as 1/4 of the triggering request below /8 available after fulfilling the triggering request. To help clarify how this policy proposal changes Section 4.2.4.4, the current policy text as of Feb 10, 2012 is included below; 4.2.4.4. Subscriber Members After One Year After an organization has been a subscriber member of ARIN for one year, they may choose to request up to a 12-month supply of IP addresses. When ARIN receives its last /8, by IANA implementing section 10.4.2.2, the length of supply that an organization may request will be reduced. An organization may choose to request up to a 3-month supply of IP addresses. Timetable for implementation: Immediate ########## ARIN STAFF ASSESSMENT Draft Policy: Proposal 162 ?Return to 12 month Supply and Reset Trigger to /8 in Free Pool? Date of Assessment: 23 Feb 2012 1. Proposal Summary (Staff Understanding) This proposal would revert NRPM section 4.2.4.4 ?Subscriber Members After One Year? back to an earlier version in which an organization may request up to a 12 month supply of IPv4 addresses. At the time that the ARIN free pool is the equivalent of a /8, an organization would only be able to request a 3 month supply. 2. Comments A. ARIN Staff Comments ? Background Information for consideration: Currently, ARIN has ~1,900 /24s free, ~800 /23s free, ~400 /22s free, etc. These smaller blocks are very useful to a large segment of ARIN's customers as we typically issue mostly small blocks to customers on a daily basis. The total number of these small, discontiguous IPv4 blocks fluctuates often due to returns and revocations, which are quite common with these smaller blocks. In contrast, ARIN has a very limited supply of large aggregates ? currently there is a single contiguous /8 free (104.0.0.0/8), two /9s, three /10s, five /11s, etc. Because we have a limited number of these larger aggregates, we will exhaust the supply of large aggregates long before we exhaust the supply of smaller aggregates. We see very little churn with these larger blocks as ARIN rarely receives back large aggregates for re-distribution. It is important to note that NRPM 4.1.6 prevents ARIN from issuing multiple prefixes to satisfy a single request ? e.g. a large operator cannot receive a /12 allocation compromised of multiple prefixes. ? Taking the above information into consideration, staff believes it may be operationally prudent and practicable to reserve a single contiguous /8 to serve as the trigger for this policy. o Doing it this way offers a fixed, easily understood target for the community to track. o It's a very clear window into our inventory status, and is therefore more transparent to the community. o It would allow operators to better plan for the future as ARIN policy switches from a 12-month allocation window back to a 3-month allocation window. ? Issuing a 12-month supply of IPv4 addresses will likely significantly accelerate the depletion of ARIN?s existing IPv4 free pool. Historically, ARIN?s IPv4 consumption rate was roughly doubled when issuing a 12-month supply vs a 3-month supply. o From 2008 through 2010, ARIN issued 3.36, 2.46, and 2.69 /8s respectively when issuing a 12-month supply, vs 1.32 /8s in 2011 when the 3-month supply policy went into effect. ? With the reintroduction of a 12-month supply window, there is the possibility that several very large requests could quickly deplete ARIN?s free pool. In light of this fact, the community may want to consider bringing back a maximum allocation/assignment size. B. ARIN General Counsel The policy proposal is a major event, since it will dramatically change the date of IPV4 run out at ARIN. This is a profound policy, but not legal change. 3. Resource Impact This policy would have major 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: ? Software needed to track the /8 equivalent trigger ? Updated guidelines ? Staff training 4. Proposal Text Policy statement: New Title: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool Date: 22 FEB 2012 Policy statement: 4.2.4.4. Subscriber Members After One Year After an organization has been a subscriber member of ARIN for one year, they may choose to request up to a twelve (12) month supply of IP addresses. When the ARIN Free Pool is down to the equivalent of one /8, excluding all special reservations, the length of supply that an organization may request will be reduced. An organization may choose to request up to a three (3) month supply of IP addresses. Any request that reduces the ARIN free pool below the /8 threshold above will trigger the reduction for that and all subsequent requests by all organizations. Rationale: There has been discussion in the community that ARIN's inventory of IPv4 addresses may be excessive given the reduction in the rate of consumption which is concurrent with the reduction to a 3 month supply when ARIN received its last /8 at IANA run-out. And that such an excess inventory in the ARIN region may be damaging the transition to IPv6 by elongating the amount of time between ARIN's exhaustion and exhaustion by other RIR's, thus creating a dangerous skew across parts of Internet in the need to transition to IPv6. One solution for this issue is to increase ARIN's rate of consumption by restoring the a 12 month supply of addresses. ARIN's stewardship responsibilities are of primary concern in this region. However, restoring the a 12 month supply of addresses is consistent with these stewardship responsibilities. Asking businesses to request addresses on a three month basis with such large inventory available at ARIN unnecessarily increases the cost and complexity of operating networks; repeated and slow interactions with ARIN, duplicate paperwork requirements and an inefficient use of resources by all compound the pain. The original intent of ARIN-2009-8 "Equitable IPv4 Run-Out" wasn't necessarily to slow the consumption of IPv4 but to limit the competitive disadvantage created by unequal run-out. However, when the trigger of IANA run-out was selected it wasn't anticipated that ARIN would have more that 5 /8s in inventory when the IANA run-out occurred. Therefore, restoring the 12-month supply and resetting the trigger for a reduction to a 3-month supply to a locally controlled event seems consistent with the original intent of ARIN-2009-8 as well. Considering that the ARIN region has consumed significantly less than a /8 since the 3-month supply was triggered at IANA run-out approximately a year ago; Resetting the trigger for the 3-month supply to /8 in the free pool, excluding all special reservations, seems reasonable. The special reservations to be excluded, should include all reservations made in policy, including those in sections 4.4, 4.10, any new reservations made by subsequent policies, and may also include reservations for draft policies in process at the board's discretion, such as Draft Policy ARIN-2011-5: Shared Transition Space for IPv4 Address Extension. Please Note: By triggering on any request that would drop the free pool below /8 it is possible that there will be slightly more or slightly less than /8 available after the triggering request is fulfilled. The size of the triggering request and the exact amount above /8 available in the free pool will determine how much more or less than /8 will be available after the triggering request is fulfilled. This could be as much as 3/4 of the triggering request above /8 or as much as 1/4 of the triggering request below /8 available after fulfilling the triggering request. To help clarify how this policy proposal changes Section 4.2.4.4, the current policy text as of Feb 10, 2012 is included below; 4.2.4.4. Subscriber Members After One Year After an organization has been a subscriber member of ARIN for one year, they may choose to request up to a 12-month supply of IP addresses. When ARIN receives its last /8, by IANA implementing section 10.4.2.2, the length of supply that an organization may request will be reduced. An organization may choose to request up to a 3-month supply of IP addresses. From jcurran at arin.net Wed Mar 14 12:09:56 2012 From: jcurran at arin.net (John Curran) Date: Wed, 14 Mar 2012 16:09:56 +0000 Subject: [arin-ppml] 4-Byte ASN's in the ARIN region... Message-ID: <17F1F66E-1792-4ED4-AEF6-AC94B593DEBA@corp.arin.net> ARIN Community - Please reference the attached graph charting issued 4-Byte ASN's by region (part of the ASO Update presentation at the ICANN Costa Rica meeting) I've been asked why 4-Byte ASN's don't seem work in the ARIN region, but do seem to work all of the other regions. I'm sure there's an easy, straightforward answer to this question, and would welcome any/all thoughts. Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 4-Byte ASNS-ASO.pdf Type: application/pdf Size: 467323 bytes Desc: 4-Byte ASNS-ASO.pdf URL: From jrhett at netconsonance.com Wed Mar 14 12:38:44 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Wed, 14 Mar 2012 09:38:44 -0700 Subject: [arin-ppml] 4-Byte ASN's in the ARIN region... In-Reply-To: <17F1F66E-1792-4ED4-AEF6-AC94B593DEBA@corp.arin.net> References: <17F1F66E-1792-4ED4-AEF6-AC94B593DEBA@corp.arin.net> Message-ID: <65B64DCB-9C48-4A89-81C0-2131B1E0443B@netconsonance.com> On Mar 14, 2012, at 9:09 AM, John Curran wrote: > I've been asked why 4-Byte ASN's don't seem work in the ARIN region, but > do seem to work all of the other regions. FUD I've implemented them with perfect success, only to have them removed because someone was told a scary story. I have likewise met vendors who have gear which supports 4-byte ASNs who are unwilling to implement them in our peering session due to unreasoned, no-facts-need-apply fear. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmaimon at chl.com Wed Mar 14 19:32:39 2012 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 14 Mar 2012 19:32:39 -0400 Subject: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool In-Reply-To: <4F60B442.1030706@arin.net> References: <4F60B442.1030706@arin.net> Message-ID: <4F612A97.1030404@chl.com> ARIN wrote: > Draft Policy ARIN-2012-4 > Return to 12 Month Supply and Reset Trigger to /8 in Free Pool Very opposed. > Staff Assessment. > > ? Issuing a 12-month supply of IPv4 addresses will likely significantly > accelerate the depletion of ARIN?s existing IPv4 free pool. > Historically, ARIN?s IPv4 consumption rate was roughly doubled when > issuing a 12-month supply vs a 3-month supply. > o From 2008 through 2010, ARIN issued 3.36, 2.46, and 2.69 /8s > respectively when issuing a 12-month supply, vs 1.32 /8s in 2011 when > the 3-month supply policy went into effect. > > ? With the reintroduction of a 12-month supply window, there is the > possibility that several very large requests could quickly deplete > ARIN?s free pool. In light of this fact, the community may want to > consider bringing back a maximum allocation/assignment size. How long do you want ARIN resources to be generally available for? 1-2 years? 3-5 years? > > Rationale: > > There has been discussion in the community that ARIN's inventory of IPv4 > addresses may be excessive given the reduction in the rate of > consumption which is concurrent with the reduction to a 3 month supply > when ARIN received its last /8 at IANA run-out. In other words, soft landing is working surprisingly well, cutting the burn rate and extending ARIN's IPv4 availability, which every sane person should consider a good thing, considering the dismal state of IPv6 adoption. > And that such an excess > inventory in the ARIN region may be damaging the transition to IPv6 by IPv6 does not deserve a chance if it must come from hastening the demise of IPv4. Doing so is wrong and irresponsible. Is is also not within your power. You cant kill IPv4. All you can do is try to ensure that the registries are not in the business of providing it. That leaves everybody else, especially those who have gobs of it. Fine stewardship, that, leaving the community solely to the mercy of the commercial interests. Thus taking an irresponsible idea and turning it into downright immoral. Besides, you all had your chance to deplete ARIN, and nobody was brave enough to step up to that plate. > elongating the amount of time between ARIN's exhaustion and exhaustion > by other RIR's, thus creating a dangerous skew across parts of Internet > in the need to transition to IPv6. They are welcome to try and be more responsible if they want to extend their availability. I welcome them doing so. Did not APNIC do something like that already? > ARIN's stewardship responsibilities are of primary concern in this > region. However, restoring the a 12 month supply of addresses is > consistent with these stewardship responsibilities. No it isnt. Its contradictory. Its reversing an effective mechanism that preserves IPv4 availability to everybody within the ARIN region. > Asking businesses to > request addresses on a three month basis with such large inventory > available at ARIN unnecessarily increases the cost and complexity of > operating networks; repeated and slow interactions with ARIN, duplicate > paperwork requirements and an inefficient use of resources by all > compound the pain. This is the soft landing at work. More inconvenience, less pain. Greater general availability, greater efficiency of resource utilization, more time to get further with IPv6 transition then we are now, gradual increase of scarcity pressures instead of sudden shocks. All good things. Unlike this draft policy. Best, Joe From hannigan at gmail.com Wed Mar 14 19:59:52 2012 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 14 Mar 2012 19:59:52 -0400 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: <4F60B42E.9040101@arin.net> References: <4F60B42E.9040101@arin.net> Message-ID: On Wed, Mar 14, 2012 at 11:07 AM, ARIN wrote: > Draft Policy ARIN-2012-3 [ clip ] > Policy statement: > > In NRPM 8.3, replace "IPv4 number resources" with "IPv4 number resources and > ASNs". > In support of 2013-3. Best, -M< From owen at delong.com Wed Mar 14 20:10:47 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 14 Mar 2012 17:10:47 -0700 Subject: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool In-Reply-To: <4F612A97.1030404@chl.com> References: <4F60B442.1030706@arin.net> <4F612A97.1030404@chl.com> Message-ID: I want ARIN to be able to continue to hand out resources indefinitely. I don't see that changing based on this policy. The policy scope applies only to IPv4 resources. For those, it is not a question of how long we want resources to be available, but, how we distribute the pain of runout. Owen On Mar 14, 2012, at 4:32 PM, Joe Maimon wrote: > > > ARIN wrote: >> Draft Policy ARIN-2012-4 >> Return to 12 Month Supply and Reset Trigger to /8 in Free Pool > > > Very opposed. > > > > Staff Assessment. > > > > ? Issuing a 12-month supply of IPv4 addresses will likely significantly > > accelerate the depletion of ARIN?s existing IPv4 free pool. > > Historically, ARIN?s IPv4 consumption rate was roughly doubled when > > issuing a 12-month supply vs a 3-month supply. > > o From 2008 through 2010, ARIN issued 3.36, 2.46, and 2.69 /8s > > respectively when issuing a 12-month supply, vs 1.32 /8s in 2011 when > > the 3-month supply policy went into effect. > > > > ? With the reintroduction of a 12-month supply window, there is the > > possibility that several very large requests could quickly deplete > > ARIN?s free pool. In light of this fact, the community may want to > > consider bringing back a maximum allocation/assignment size. > > How long do you want ARIN resources to be generally available for? > > 1-2 years? > > 3-5 years? > > >> >> Rationale: >> >> There has been discussion in the community that ARIN's inventory of IPv4 >> addresses may be excessive given the reduction in the rate of >> consumption which is concurrent with the reduction to a 3 month supply >> when ARIN received its last /8 at IANA run-out. > > In other words, soft landing is working surprisingly well, cutting the burn rate and extending ARIN's IPv4 availability, which every sane person should consider a good thing, considering the dismal state of IPv6 adoption. > >> And that such an excess >> inventory in the ARIN region may be damaging the transition to IPv6 by > > IPv6 does not deserve a chance if it must come from hastening the demise of IPv4. > > Doing so is wrong and irresponsible. Is is also not within your power. > > You cant kill IPv4. All you can do is try to ensure that the registries are not in the business of providing it. > > That leaves everybody else, especially those who have gobs of it. Fine stewardship, that, leaving the community solely to the mercy of the commercial interests. > > Thus taking an irresponsible idea and turning it into downright immoral. > > Besides, you all had your chance to deplete ARIN, and nobody was brave enough to step up to that plate. > > > >> elongating the amount of time between ARIN's exhaustion and exhaustion >> by other RIR's, thus creating a dangerous skew across parts of Internet >> in the need to transition to IPv6. > > They are welcome to try and be more responsible if they want to extend their availability. I welcome them doing so. > > Did not APNIC do something like that already? > > >> ARIN's stewardship responsibilities are of primary concern in this >> region. However, restoring the a 12 month supply of addresses is >> consistent with these stewardship responsibilities. > > No it isnt. Its contradictory. Its reversing an effective mechanism that preserves IPv4 availability to everybody within the ARIN region. > >> Asking businesses to >> request addresses on a three month basis with such large inventory >> available at ARIN unnecessarily increases the cost and complexity of >> operating networks; repeated and slow interactions with ARIN, duplicate >> paperwork requirements and an inefficient use of resources by all >> compound the pain. > > > This is the soft landing at work. > > More inconvenience, less pain. > > Greater general availability, greater efficiency of resource utilization, more time to get further with IPv6 transition then we are now, gradual increase of scarcity pressures instead of sudden shocks. > > All good things. Unlike this draft policy. > > Best, > > Joe > _______________________________________________ > 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 petertbui0 at gmail.com Wed Mar 14 20:51:35 2012 From: petertbui0 at gmail.com (Peter Bui) Date: Wed, 14 Mar 2012 17:51:35 -0700 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: <4F60B42E.9040101@arin.net> References: <4F60B42E.9040101@arin.net> Message-ID: <101E49E2-A2B5-409A-9087-859EC24A84D8@gmail.com> I am in support of this. On Mar 14, 2012, at 8:07 AM, ARIN wrote: > Draft Policy ARIN-2012-3 > ASN Transfers > > On 8 March 2012 the ARIN Advisory Council (AC) selected "ASN Transfers" as a draft policy for adoption discussion on the PPML and at the Public Policy Meeting in Vancouver in April. > > The draft was developed by the AC from policy proposal "ARIN-prop-157 Section 8.3 Simplification." Per the Policy Development Process the AC submitted text to ARIN for a staff and legal assessment prior to its selection as a draft policy. Below the draft policy is the ARIN staff and legal assessment, followed by the text that was submitted by the AC. > > Draft Policy ARIN-2012-3 is below and can be found at: > https://www.arin.net/policy/proposals/2012_3.html > > You are encouraged to discuss Draft Policy 2012-3 on the PPML prior to > the April Public Policy Meeting. Both the discussion on the list and > at the meeting will be used by the ARIN Advisory Council to determine > the community consensus for adopting this as policy. > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy ARIN-2012-3 > ASN Transfers > > Date: 14 March 2012 > > Policy statement: > > In NRPM 8.3, replace "IPv4 number resources" with "IPv4 number resources and ASNs". > > Rationale: > > There are legitimate use cases for transferring ASNs, and no significant downsides (identified to date) of allowing it. > > Timetable for implementation: Immediate > > > ########## > > > ARIN STAFF ASSESSMENT > > Draft Policy: Proposal 157 ?ASN Transfers? > Date of Assessment: 23 Feb 2012 > > 1. Proposal Summary (Staff Understanding) > > This proposal would allow organizations to transfer ASNs in addition to IPv4 address space in an 8.3 transfer to specified recipients. > > 2. Comments > > A. ARIN Staff Comments > > ? If implemented as written, the 24-month utilization requirement in 8.3 would not apply to ASN requests since 8.3 clearly says ?how the addresses will be utilized in 24 months?. Staff would apply the current ASN policy, which requires an organization to be multi-homed or to immediately become multi-homed. > > B. ARIN General Counsel > > This creates no legal concerns and may actually facilitate any bankruptcy proceedings where ASNs are involved. > > 3. Resource Impact > > This policy would have minimum 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 > > 4. Proposal Text > > Policy statement: > > In NRPM 8.3, replace "IPv4 number resources" with "IPv4 number resources and ASNs". > > Rationale: > There are legitimate use cases for transferring ASNs, and no significant downsides (identified to date) of allowing it. > 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 jmaimon at chl.com Wed Mar 14 22:54:32 2012 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 14 Mar 2012 22:54:32 -0400 Subject: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool In-Reply-To: References: <4F60B442.1030706@arin.net> <4F612A97.1030404@chl.com> Message-ID: <4F6159E8.2040703@chl.com> Owen DeLong wrote: > I want ARIN to be able to continue to hand out resources indefinitely. > > I don't see that changing based on this policy. > > The policy scope applies only to IPv4 resources. For those, it is not a question of how long we want resources to be available, but, how we distribute the pain of runout. > > Owen How long we want ipv4 resources available from ARIN is very much the exact question. I know you read the staff assessment, where that is stated explicitly. >>> Staff Assessment. >>> >>> ? Issuing a 12-month supply of IPv4 addresses will likely significantly >>> accelerate the depletion of ARIN?s existing IPv4 free pool. >>> Historically, ARIN?s IPv4 consumption rate was roughly doubled when >>> issuing a 12-month supply vs a 3-month supply. >>> o From 2008 through 2010, ARIN issued 3.36, 2.46, and 2.69 /8s >>> respectively when issuing a 12-month supply, vs 1.32 /8s in 2011 when >>> the 3-month supply policy went into effect. >>> >>> ? With the reintroduction of a 12-month supply window, there is the >>> possibility that several very large requests could quickly deplete >>> ARIN?s free pool. In light of this fact, the community may want to >>> consider bringing back a maximum allocation/assignment size. >> How long do you want ARIN resources to be generally available for? >> >> 1-2 years? >> >> 3-5 years? >> >> From mysidia at gmail.com Wed Mar 14 23:50:33 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 14 Mar 2012 22:50:33 -0500 Subject: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool In-Reply-To: References: <4F60B442.1030706@arin.net> <4F612A97.1030404@chl.com> Message-ID: On Wed, Mar 14, 2012 at 7:10 PM, Owen DeLong wrote: I am opposed to this proposed policy. > The policy scope applies only to IPv4 resources. For those, it is not a question of how long we want resources to be available, but, how we distribute the pain of runout. > Owen There you go. I'll take the pin prick every week for the next 5 years over decapitation in 12 months any day. Both questions amount to the same; "how long we want there to be resources available for assignment" is equivalent to "how long until runout". The idea that the amount of pain will necessarily be the same no matter how it is distributed, is just wrong. The duration of exhaustion cannot be considered independent of other factors related to the amount of "pain", such as more time and opportunity to conserve and promote more efficient use of IPv4 addressing, and more time available for IPv6 technologies to mature and be implemented. Increasing the time until runout by avoiding allocating resources too far in advance reduces the net amount of pain. -- -JH From jeffrey.lyon at blacklotus.net Wed Mar 14 23:55:19 2012 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Wed, 14 Mar 2012 23:55:19 -0400 Subject: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool In-Reply-To: References: <4F60B442.1030706@arin.net> <4F612A97.1030404@chl.com> Message-ID: On Wed, Mar 14, 2012 at 11:50 PM, Jimmy Hess wrote: > On Wed, Mar 14, 2012 at 7:10 PM, Owen DeLong wrote: > > I am opposed to this proposed policy. > >> The policy scope applies only to IPv4 resources. For those, it is not a question of how long we want resources to be available, but, how we distribute the pain of runout. >> Owen > > There you go. ? ?I'll take the pin prick every week for the next 5 > years ?over ?decapitation in 12 months any day. ? Both questions > amount to the same; ?"how long we want there to be resources available > for assignment" is equivalent to ?"how long until runout". > > The idea that the amount of pain will necessarily be the same no > matter how it is distributed, is just wrong. ?The duration of > exhaustion cannot be considered independent of other factors related > to the amount of "pain", ?such as more time and opportunity to > conserve and promote more efficient use of IPv4 addressing, ?and more > time available for IPv6 technologies to mature and be implemented. > > Increasing the time until runout ?by avoiding allocating resources too > far in advance > reduces the net amount of pain. > > -- > -JH > _______________________________________________ > 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. Opposed. Here is my logic: - At face value, being able to request 12 months is a plus, however.. - .. it's at the risk of killing off the surplus we've built up too quickly - The STLS is now at 24 months, so keeping the free pool at 3 months encourages recycling - I like recycling. -- 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 Timothy.S.Morizot at irs.gov Thu Mar 15 00:05:26 2012 From: Timothy.S.Morizot at irs.gov (Morizot Timothy S) Date: Thu, 15 Mar 2012 04:05:26 +0000 Subject: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool In-Reply-To: <4F60B442.1030706@arin.net> References: <4F60B442.1030706@arin.net> Message-ID: <968C470DAC25FB419E0159952F28F0C039D7D48D@MEM0200CP3XF04.ds.irsnet.gov> > -----Original Message----- > Subject: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool > Draft Policy ARIN-2012-4 > Return to 12 Month Supply and Reset Trigger to /8 in Free Pool I'm very much in favor of a policy change that will speed ARIN runout to bring it more in line with APNIC and RIPE, but with the IPv4 resources going to those who are actively using them. I remember the world of scarcity and silos Geoff Huston recalls and am concerned that an extended period of time with ARIN significantly out of step with the other two large RIRs could easily lead to some of the scenarios he describes. We must make the transition to IPv6 or end up with a very different Internet than the one to which we've become accustomed. And the longer ARIN draws out its runout, the greater the risk to that goal. As we've been seeing on arin-discuss today, an attitude that IPv6 can be put off and a lack of urgency about transition seems to continue to pervade our region. If I saw a long-term view driving IPv6 adoption in our region, I would think it would be a good thing to slow our rate of IPv4 consumption to make our transition less painful. But I don't see that. Instead, I just see organizations continuing to put it off until they are forced to act. Scott From owen at delong.com Thu Mar 15 02:09:33 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 14 Mar 2012 23:09:33 -0700 Subject: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool In-Reply-To: <4F6159E8.2040703@chl.com> References: <4F60B442.1030706@arin.net> <4F612A97.1030404@chl.com> <4F6159E8.2040703@chl.com> Message-ID: <3E026457-5AAB-42B9-A07F-AE4AD97E532C@delong.com> On Mar 14, 2012, at 7:54 PM, Joe Maimon wrote: > > > Owen DeLong wrote: >> I want ARIN to be able to continue to hand out resources indefinitely. >> >> I don't see that changing based on this policy. >> >> The policy scope applies only to IPv4 resources. For those, it is not a question of how long we want resources to be available, but, how we distribute the pain of runout. >> >> Owen > > How long we want ipv4 resources available from ARIN is very much the exact question. > > I know you read the staff assessment, where that is stated explicitly. My point is that convincing ourselves that we can extend that date is an act of fiction. In reality, we're already past runout and we have been for years if you define runout as the point at which genuine needs cannot be fully and rationally satisfied. We passed runout as far as I'm concerned at the point where we were no longer able to take every host that is currently behind NAT and put a public address on it instead. We've been out of IPv4 resources for years, but that's an inconvenient truth. So, instead we find new and different ways to lie to ourselves and pretend that the free pool today is not measured in the pain of others and that we can magically extend the life of that free pool, conveniently ignoring the pain such actions inflict. There is already pain from IPv4 runout reflected in current policy. Anything we do to extend the imaginary life of the free pool comes at the price of increasing that pain for all who are currently bearing it and for others who will bear it in the future as well. Hence, I stand by my statement that it is not about extending the life of the free pool, but, rather about how we distribute the pain of runout and how long we keep that pain going. If the window stays at 3 months, it's not like those large requests don't still represent real need. The large requests are either spread out over 4 requests or we have managed to make the pain/cost of address acquisition exceed the value for those requestors (possibly to the expense and detriment of their customers). Essentially, we have robbed $LARGE_REQUESTOR to provide resources to n * $SMALL_REQUESTORS where the value of n is unknown and n may actually be entirely made up of smaller requests from the same organization resulting in greater fragmentation of the routing table while not changing actual address consumption. Owen > >>>> Staff Assessment. >>>> >>>> ? Issuing a 12-month supply of IPv4 addresses will likely significantly >>>> accelerate the depletion of ARIN?s existing IPv4 free pool. >>>> Historically, ARIN?s IPv4 consumption rate was roughly doubled when >>>> issuing a 12-month supply vs a 3-month supply. >>>> o From 2008 through 2010, ARIN issued 3.36, 2.46, and 2.69 /8s >>>> respectively when issuing a 12-month supply, vs 1.32 /8s in 2011 when >>>> the 3-month supply policy went into effect. >>>> >>>> ? With the reintroduction of a 12-month supply window, there is the >>>> possibility that several very large requests could quickly deplete >>>> ARIN?s free pool. In light of this fact, the community may want to >>>> consider bringing back a maximum allocation/assignment size. >>> How long do you want ARIN resources to be generally available for? >>> >>> 1-2 years? >>> >>> 3-5 years? >>> >>> From owen at delong.com Thu Mar 15 02:12:21 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 14 Mar 2012 23:12:21 -0700 Subject: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool In-Reply-To: References: <4F60B442.1030706@arin.net> <4F612A97.1030404@chl.com> Message-ID: <136B4C7B-C0CE-4514-83FE-4395E6F0F39A@delong.com> On Mar 14, 2012, at 8:50 PM, Jimmy Hess wrote: > On Wed, Mar 14, 2012 at 7:10 PM, Owen DeLong wrote: > > I am opposed to this proposed policy. > >> The policy scope applies only to IPv4 resources. For those, it is not a question of how long we want resources to be available, but, how we distribute the pain of runout. >> Owen > > There you go. I'll take the pin prick every week for the next 5 > years over decapitation in 12 months any day. Both questions > amount to the same; "how long we want there to be resources available > for assignment" is equivalent to "how long until runout". > I think it's more like the severed limb every 3 months vs. the decapitation in 12 months if you want to draw that kind of an analogy. > The idea that the amount of pain will necessarily be the same no > matter how it is distributed, is just wrong. The duration of > exhaustion cannot be considered independent of other factors related > to the amount of "pain", such as more time and opportunity to > conserve and promote more efficient use of IPv4 addressing, and more > time available for IPv6 technologies to mature and be implemented. > > Increasing the time until runout by avoiding allocating resources too > far in advance > reduces the net amount of pain. > You mistake what I am saying as "longer free pool duration means less pain over a longer time". That is not what I am saying at all. I am saying that the only way to make the free pool last longer is to inflict a higher level of pain on some organizations for a longer period of time in order to (possibly) provide a lower level of pain to other organizations for part of that same time. Owen From jmaimon at chl.com Thu Mar 15 02:35:01 2012 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 15 Mar 2012 02:35:01 -0400 Subject: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool In-Reply-To: <968C470DAC25FB419E0159952F28F0C039D7D48D@MEM0200CP3XF04.ds.irsnet.gov> References: <4F60B442.1030706@arin.net> <968C470DAC25FB419E0159952F28F0C039D7D48D@MEM0200CP3XF04.ds.irsnet.gov> Message-ID: <4F618D95.50407@chl.com> Morizot Timothy S wrote: >> -----Original Message----- >> Subject: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool > >> Draft Policy ARIN-2012-4 >> Return to 12 Month Supply and Reset Trigger to /8 in Free Pool > > I'm very much in favor of a policy change that will speed ARIN runout to bring it more in line with APNIC and RIPE, but with the IPv4 resources going to those who are actively using them. > > I remember the world of scarcity and silos Geoff Huston recalls and am concerned that an extended period of time with ARIN significantly out of step with the other two large RIRs could easily lead to some of the scenarios he describes. We must make the transition to IPv6 or end up with a very different Internet than the one to which we've become accustomed. And the longer ARIN draws out its runout, the greater the risk to that goal. > > As we've been seeing on arin-discuss today, an attitude that IPv6 can be put off and a lack of urgency about transition seems to continue to pervade our region. If I saw a long-term view driving IPv6 adoption in our region, I would think it would be a good thing to slow our rate of IPv4 consumption to make our transition less painful. But I don't see that. Instead, I just see organizations continuing to put it off until they are forced to act. > > Scott > How about someone be specific, and point out what kind of specific issues that the ARIN region may experience due to its expanded ipv4 availability, thanks in no small part to a decreased burn rate and greater efficiency, brought to you by three month soft landing? Misery loves company? If all you have to whine about is that people deserve to suffer for not racing to adopt IPv6 and by golly we are going to make sure they do, I am really tired of hearing that. And you are not thinking things through to their rational end. Do you really think that IPv4 address availability and consumption will dry up and vanish right along with RIR pool depletion? Consider where the vast majority of IPv4 addresses will be post ARIN runout. Hint: It is where they already are. What do you think it will do to IPv6 adoption, when a couple dozen organizations control the vast majority of IPv4 - and get to monetize those holdings in ways we are only seeing the beginning of? Do you really think the suits at these organizations would be so eager to work against their own immediate interests? Or do you eagerly anticipate that all these pain factors combined will generate enough network effect to bootstrap IPv6? How are things working out in the depleted regions? Or is that ARIN's responsibility as well? It is completely irresponsible to gamble in this fashion - even were the ends to justify the means. They do not. Joe From jmaimon at chl.com Thu Mar 15 02:39:24 2012 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 15 Mar 2012 02:39:24 -0400 Subject: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool In-Reply-To: <136B4C7B-C0CE-4514-83FE-4395E6F0F39A@delong.com> References: <4F60B442.1030706@arin.net> <4F612A97.1030404@chl.com> <136B4C7B-C0CE-4514-83FE-4395E6F0F39A@delong.com> Message-ID: <4F618E9C.5000203@chl.com> Owen DeLong wrote: > I think it's more like the severed limb every 3 months vs. the decapitation in 12 months if you want to draw that kind of an analogy. > > > > I am saying that the only way to make the free pool last longer is to inflict a higher level of pain on some organizations for a longer period of time in order to (possibly) provide a lower level of pain to other organizations for part of that same time. > > Owen > We already know how to make the free pool last longer. We are doing it and it is working, now. You want to break that, because it seems like it will last longer then you want it to. Could you show me the pile of severed limbs please? Joe From jmaimon at chl.com Thu Mar 15 02:57:20 2012 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 15 Mar 2012 02:57:20 -0400 Subject: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool In-Reply-To: <3E026457-5AAB-42B9-A07F-AE4AD97E532C@delong.com> References: <4F60B442.1030706@arin.net> <4F612A97.1030404@chl.com> <4F6159E8.2040703@chl.com> <3E026457-5AAB-42B9-A07F-AE4AD97E532C@delong.com> Message-ID: <4F6192D0.3040501@chl.com> Owen DeLong wrote: > > My point is that convincing ourselves that we can extend that date is an act of fiction. In reality, we're already past runout and we have been for years if you define runout as the point at which genuine needs cannot be fully and rationally satisfied. We passed runout as far as I'm concerned at the point where we were no longer able to take every host that is currently behind NAT and put a public address on it instead. > > We've been out of IPv4 resources for years, but that's an inconvenient truth. So, instead we find new and different ways to lie to ourselves and pretend that the free pool today is not measured in the pain of others and that we can magically extend the life of that free pool, conveniently ignoring the pain such actions inflict. In theory, there is no difference between theory and practice and we have run out. In practice, there is, and the evident fact is that there is still plenty to go around. Hence, this discussion. There could be quite more kept available, if the theorist did not keep stonewalling practical attempts at doing so. > > > If the window stays at 3 months, it's not like those large requests don't still represent real need. What theory glosses over is that need is relative, and elastic. Actual practical use of IPv4 has demonstrated that over and again. > The large requests are either spread out over 4 requests Fine. > or we have managed to make the pain/cost of address acquisition exceed the value for those requestors (possibly to the expense and detriment of their customers). Better. > Essentially, we have robbed $LARGE_REQUESTOR to provide resources to n * $SMALL_REQUESTORS where the value of n is unknown and n may actually be entirely made up of smaller requests from the same organization resulting in greater fragmentation of the routing table while not changing actual address consumption > > Owen Your theory actually cites two conclusions that are actually measurable. Bad Theory! Did you miss the part that actual address consumption has changed? Has anybody noticed increased route table growth driven by increased rate of ARIN smaller sized allocations? Which would not happen all by itself, or spurred by market activity growth? Or are those the inconvenient facts that does not line up with your theories? I feel really bad for these organizations who have more addresses then everybody else combined and yet manage to charge 15USD for a block of 5 addresses. Where are they getting those addresses to do that with? They must need more. Give them a 12 month supply.. Joe From louie at louie.net Thu Mar 15 04:08:52 2012 From: louie at louie.net (Louie Lee) Date: Thu, 15 Mar 2012 02:08:52 -0600 Subject: [arin-ppml] ARIN-2011-9 / GPP-IPv4-2011 sent to ICANN Board for ratification In-Reply-To: <4ECBE656.5060300@arin.net> References: <4ECBE656.5060300@arin.net> Message-ID: <06F1746C-7C68-46CF-81E4-A2F673FF3C8C@louie.net> Dear ARIN Community, On behalf of the ICANN ASO Address Council and the global IP addressing community, I have forwarded the global policy proposal GPP-IPv4-2011 (also known as ARIN-2011-9 in the ARIN region) onto the ICANN Board of Directors for review and ratification. The ICANN Board's Review Procedures for such global policy proposals require a 21-day comment period. ICANN has acknowledged receipt of this global policy proposal from the ASO AC and began a public comment period which will end on April 4, 2012. The ASO Address Council expects ratification by the ICANN Board within 60 days. Please stay tuned for further updates. Relevant links: ARIN-2011-9 status: https://www.arin.net/policy/proposals/2011_9.html GPP-IPv4-2011 status: http://aso.icann.org/global-policy-proposals/#GPP-IPv4-2011 background report: http://www.icann.org/en/news/announcements/announcement-26apr11-en.htm ASO AC communiqu?: https://aso.icann.org/pipermail/aso-council/2012-March/000026.html policy proposal text: http://www.icann.org/en/news/in-focus/global-addressing/proposal-allocation-ipv4-post-exhaust-14mar12-en.txt ICANN public comment: http://www.icann.org/en/news/public-comment/gpp-recovered-ipv4-14mar12-en.htm Best Regards, Louie ASO AC Chair -- Louis Lee louie at louie.net NRO Number Council http://www.nro.net/about/number-council.html ASO Address Council http://aso.icann.org/ac/ On Nov 22, 2011, at 12:13 PM, ARIN wrote: > Subject: [arin-ppml] Advisory Council Meeting Results - November 2011 > > In accordance with the ARIN Policy Development Process, the ARIN > Advisory Council (AC) held a meeting on 16 November 2011 and made > decisions about several draft policies and proposals. > > The AC recommended the following draft policies to the ARIN Board for > adoption: > > ARIN-2011-1: ARIN Inter-RIR Transfers > ARIN-2011-8: Combined M&A and Specified Transfers > ARIN-2011-9 (Global Proposal): Global Policy for post exhaustion IPv4 > allocation mechanisms by the IANA > ARIN-2011-10: Remove Single Aggregate requirement from Specified Transfer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsw at inconcepts.biz Thu Mar 15 15:11:08 2012 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Thu, 15 Mar 2012 15:11:08 -0400 Subject: [arin-ppml] 4-Byte ASN's in the ARIN region... In-Reply-To: <17F1F66E-1792-4ED4-AEF6-AC94B593DEBA@corp.arin.net> References: <17F1F66E-1792-4ED4-AEF6-AC94B593DEBA@corp.arin.net> Message-ID: On Wed, Mar 14, 2012 at 12:09 PM, John Curran wrote: > ?I've been asked why 4-Byte ASN's don't seem work in the ARIN region, but > ?do seem to work all of the other regions. I still find it common for transit providers to react with a "we don't support..." and similar. I suppose they will stop doing this when their customers are no longer able to get a 2 byte ASN because they have been exhausted, or when two or three more years go by and substantially all non-supporting routers/software has finally reached the end of its useful life. On the other side of the coin, I found my clients unwilling to upgrade router software (a simple matter of an outage window for reboot) simply to gain 4 byte ASN support given that customers had an easy time changing to a 2 byte ASN by going back to the RIR. I really don't have a strong opinion on if this is good or bad behavior. Why? The BGP community issues related to 4 byte ASN are still not resolved and likely won't be very soon. The IETF community, and more so, vendors, really screwed the pooch on ASN exhaustion. We still don't have the community tools we need and it's pretty unfortunate that a problem which was easily predicted in the 90s is still an issue for new network operators in 2012. If there was a way to modify current ARIN policy or practice so that networks could not exchange a 4 byte ASN for a 2 byte ASN unless they were connecting to an IXP, I think that would encourage the remaining networks who have not supported 4 byte ASN to do so, while also not penalizing folks who participate in peering at public exchanges where there remain some legitimate technical problems. $0.02. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From owen at delong.com Thu Mar 15 16:31:56 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 15 Mar 2012 13:31:56 -0700 Subject: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool In-Reply-To: <4F618D95.50407@chl.com> References: <4F60B442.1030706@arin.net> <968C470DAC25FB419E0159952F28F0C039D7D48D@MEM0200CP3XF04.ds.irsnet.gov> <4F618D95.50407@chl.com> Message-ID: <5A43A629-4145-428C-9F52-8590D720857C@delong.com> On Mar 14, 2012, at 11:35 PM, Joe Maimon wrote: > > > Morizot Timothy S wrote: >>> -----Original Message----- >>> Subject: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool >> >>> Draft Policy ARIN-2012-4 >>> Return to 12 Month Supply and Reset Trigger to /8 in Free Pool >> >> I'm very much in favor of a policy change that will speed ARIN runout to bring it more in line with APNIC and RIPE, but with the IPv4 resources going to those who are actively using them. >> >> I remember the world of scarcity and silos Geoff Huston recalls and am concerned that an extended period of time with ARIN significantly out of step with the other two large RIRs could easily lead to some of the scenarios he describes. We must make the transition to IPv6 or end up with a very different Internet than the one to which we've become accustomed. And the longer ARIN draws out its runout, the greater the risk to that goal. >> >> As we've been seeing on arin-discuss today, an attitude that IPv6 can be put off and a lack of urgency about transition seems to continue to pervade our region. If I saw a long-term view driving IPv6 adoption in our region, I would think it would be a good thing to slow our rate of IPv4 consumption to make our transition less painful. But I don't see that. Instead, I just see organizations continuing to put it off until they are forced to act. >> >> Scott >> > > > How about someone be specific, and point out what kind of specific issues that the ARIN region may experience due to its expanded ipv4 availability, thanks in no small part to a decreased burn rate and greater efficiency, brought to you by three month soft landing? > I will start by specifically pointing out the flaws in the above assumptions... First, the assumption that the three month soft landing has caused greater efficiency and that the decreased burn rate has resulted from that greater efficiency and not from other factors. In reality, that decreased burn rate represents not greater efficiency, but, greater pain inflicted upon organizations struggling to get by with what they have because the effort involved in obtaining 3 months worth of address space and the costs associated with doing so exceeds the revenue those addresses are likely to produce. It represents real customers suffering under degraded services and increased pricing as a result. That's not greater efficiency, it's just greater pain. > Misery loves company? > > If all you have to whine about is that people deserve to suffer for not racing to adopt IPv6 and by golly we are going to make sure they do, I am really tired of hearing that. > This is a very interesting way to characterize my argument. What I'm arguing against is the fact that people are actually suffering now. Even people who have adopted IPv6. Not because they failed to adopt IPv6, but, in part because others have failed to do so, but in larger part because our current flawed policy is inflicting additional unnecessary pain in the name of making the free pool last mythically longer. > And you are not thinking things through to their rational end. > > Do you really think that IPv4 address availability and consumption will dry up and vanish right along with RIR pool depletion? > Quite the contrary... However, when the RIR pools are depleted, the cost of failing to deploy IPv6 will start to be expressed in terms that seem to be better understood by managers, whereas today they are expressed in technical esoterica that does not seem to get through as well. Further, the post RIR depletion fragmentation of the address pool and subsequent consequences to the routing table will serve as a further driver. I have very much thought this through to its logical conclusion. Have you thought through to the logical conclusion of the damage today's policy is causing today in the real world? Have you thought through the silo effect and the damage that is already causing? Have you thought through the extent of the damage to the concept of ubiquitous network communications world wide that will evolve from north america being so completely disjoint from the rest of the world? > Consider where the vast majority of IPv4 addresses will be post ARIN runout. Hint: It is where they already are. > > What do you think it will do to IPv6 adoption, when a couple dozen organizations control the vast majority of IPv4 - and get to monetize those holdings in ways we are only seeing the beginning of? I think that depends on the price at which they seek to monetize. If the price is too high, it will spur IPv6 adoption pretty well. If the price is low enough, it will create some minor additional costs associated with the migration and delay it by a few months or maybe even a year or two. > Do you really think the suits at these organizations would be so eager to work against their own immediate interests? > This conclusion is opaque to me. I absolutely expect them to work in their own interests. However, I see their interests falling into one of three behaviors: 1. Hoard what they have and try to be the rare provider of IPv4 that still has addresses to give in order to gain competitive advantage. 2. Attempt to monetize IPv4 addresses at such a high asking price as to strongly motivate potential customers to use IPv6 as an alternative wherever possible. 3. Attempt to monetize IPv4 addresses at low enough prices that a one-time redistribution of addresses replaces the RIR system as the new free pool until the readily available monetizable addresses are redistributed and we are faced with runout once again. If you see some other behavior as being in their interests, please do tell. If they behave in some combination of those three ways, then, the end result is still the same... 1. IPv4 runs out. 2. People faced with the rising cost of IPv4 and supply problems obtaining IPv4 addresses will turn to IPv6. 3. IPv4 deaggregation will make IPv4 routing more and more expensive to maintain. If you have other logical conclusions from these actions (or different behaviors), please do tell. > Or do you eagerly anticipate that all these pain factors combined will generate enough network effect to bootstrap IPv6? > I don't know that I would say "eagerly", but, I do anticipate that these pain factors (which, by the way cannot really be mitigated, only moved around from place to place a little bit) which can only continue to increase will increase until such time as we generally deploy IPv6. Faced with an ever-increasing level of pain becoming ever more widespread and continuing to spread and to increase until such time as IPv6 is widely deployed, it is utterly absurd to believe that making that process last longer will somehow reduce the level of pain. All it can do is transfer more of the pain to some organizations in order to reduce or postpone that pain for other organizations. > How are things working out in the depleted regions? Or is that ARIN's responsibility as well? > The depleted region is still in the transfers are available stage, but, even so, there is a significant increase in IPv6 deployment efforts in that region. There is also a significant increase in IPv6 deployment efforts in the RIPE region which, while it hasn't run out yet is close enough that it is pretty clear they will be the second region to run out. > It is completely irresponsible to gamble in this fashion - even were the ends to justify the means. > I guess that depends on how you perceive gambling. I think it is completely irresponsible maintain a padlock on the granary in front of all the hungry villagers and post armed guards to watch them starve slowly gambling on the likelihood that more villagers arrive next month. You seem to think it is irresponsible to feed the people who are hungry today gambling on the possibility that the number of people starving next month will be about the same. I prefer to feed the people in front of me at the risk that more people MIGHT be hungry tomorrow vs. keep people hungry today based on such an uncertainty. Owen From gbonser at seven.com Thu Mar 15 18:23:57 2012 From: gbonser at seven.com (George Bonser) Date: Thu, 15 Mar 2012 22:23:57 +0000 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: <4F60B42E.9040101@arin.net> References: <4F60B42E.9040101@arin.net> Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09D1569B@RWC-MBX1.corp.seven.com> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of ARIN > Sent: Wednesday, March 14, 2012 8:07 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers > > Draft Policy ARIN-2012-3 > ASN Transfersence any issues. Support. From gbonser at seven.com Thu Mar 15 18:31:42 2012 From: gbonser at seven.com (George Bonser) Date: Thu, 15 Mar 2012 22:31:42 +0000 Subject: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool In-Reply-To: <4F60B442.1030706@arin.net> References: <4F60B442.1030706@arin.net> Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09D156D4@RWC-MBX1.corp.seven.com> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of ARIN > Sent: Wednesday, March 14, 2012 8:08 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and > Reset Trigger to /8 in Free Pool > > Draft Policy ARIN-2012-4 > Return to 12 Month Supply and Reset Trigger to /8 in Free Pool > Oppose From kkargel at polartel.com Thu Mar 15 18:36:07 2012 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 15 Mar 2012 17:36:07 -0500 Subject: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool In-Reply-To: <4F60B442.1030706@arin.net> References: <4F60B442.1030706@arin.net> Message-ID: <8695009A81378E48879980039EEDAD28011E05E4A6@MAIL1.polartel.local> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of ARIN > Sent: Wednesday, March 14, 2012 10:08 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and > Reset Trigger to /8 in Free Pool > > Draft Policy ARIN-2012-4 > Return to 12 Month Supply and Reset Trigger to /8 in Free Pool > Oppose -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4935 bytes Desc: not available URL: From cgrundemann at gmail.com Thu Mar 15 18:40:46 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 15 Mar 2012 16:40:46 -0600 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: <4F60B42E.9040101@arin.net> References: <4F60B42E.9040101@arin.net> Message-ID: On Wed, Mar 14, 2012 at 09:07, ARIN wrote: > Policy statement: > > In NRPM 8.3, replace "IPv4 number resources" with "IPv4 number resources and > ASNs". > > Rationale: > > There are legitimate use cases for transferring ASNs, and no significant > downsides (identified to date) of allowing it. This is not an effective rationale. Rather than stating that "There are legitimate use cases for transfering ASNs" (which is unhelpful at best), it would be much more useful to have these supposed use-cases identified. Can anyone identify any use-cases where transferring ASNs is actually *necessary* for the operation of the Internet in the ARIN region? I have read (all of) the previous discussion threads on this topic and have yet to see a single compelling use-case. I think it would be very helpful to the discussion for folks to understand why this request is being made. Thanks, ~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. -- @ChrisGrundemann http://chrisgrundemann.com From gbonser at seven.com Thu Mar 15 18:47:30 2012 From: gbonser at seven.com (George Bonser) Date: Thu, 15 Mar 2012 22:47:30 +0000 Subject: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool In-Reply-To: <968C470DAC25FB419E0159952F28F0C039D7D48D@MEM0200CP3XF04.ds.irsnet.gov> References: <4F60B442.1030706@arin.net> <968C470DAC25FB419E0159952F28F0C039D7D48D@MEM0200CP3XF04.ds.irsnet.gov> Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09D15736@RWC-MBX1.corp.seven.com> > I'm very much in favor of a policy change that will speed ARIN runout > to bring it more in line with APNIC and RIPE, but with the IPv4 > resources going to those who are actively using them. I am not in favor of keeping v4 alive any longer than necessary. I would favor possibly taking it from 3 months to 6 months but probably not much longer than that. Many networks often have optimistic projections a year out. Their latest thing is *always* going to be wildly successful and address requirement projections generally err on the high side because nobody wants to get caught short. As we get closer to runout, people are going to want even more with the notion that they may not be able to get any more later. There will be some amount of hoarding going on as is natural for people to do. But relatively few networks when looked at over the entire region have a reliably predictable IP address burn rate. What going to one year does is results on over allocation of resources. The rationale seems to be "everyone else is doing it this way and we don't want to be the odd man out" or "we want to go ahead and burn up v4 as quickly as possible to encourage people to migrate to v6" and that doesn't make sense to me either. From gbonser at seven.com Thu Mar 15 19:06:30 2012 From: gbonser at seven.com (George Bonser) Date: Thu, 15 Mar 2012 23:06:30 +0000 Subject: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09D15736@RWC-MBX1.corp.seven.com> References: <4F60B442.1030706@arin.net> <968C470DAC25FB419E0159952F28F0C039D7D48D@MEM0200CP3XF04.ds.irsnet.gov> <596B74B410EE6B4CA8A30C3AF1A155EA09D15736@RWC-MBX1.corp.seven.com> Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09D1578A@RWC-MBX1.corp.seven.com> Another reason for the reduction in burn rate may have nothing to do with going from 12 month to 3 month allocations. Think about it ... there SHOULD be NO change in burn rate over a 12 month period. If I need a /19 every three months then I am going to need them every three months whether I get them once a year in a larger block or not. The frequency of having to go to ARIN does not change the growth rate of a service requiring IP addresses. So the notion that going from 12 month supply to 3 month supply having greatly reduced the consumption of address resources seems odd to me. What is more likely are things like the largest consumers of public IP space (mobile networks, for example) going to IPv6 internally in their networks and using NAT64/DNS64 CGN to interface devices to the v4 Internet. There are an increasing number of native v6 devices out there on an increasing number of networks in the mobile space. This is reducing the amount of v4 addresses burned up in these mobile networks. VZW, for example, has a large number of native v6 devices these days and as old devices are retired and people upgrade to new ones, the number is increasing with every passing day. That space is just one example where consumption of v6 addresses are in decline. My v6 traffic is increasing with each passing month. I would currently estimate that of all clients able to connect to my network for service, about 1% are currently native v6 (I'll know with more precision at the end of this month). Of the newer clients, 100% are v6 capable and nearly 100% are on a v6 native network with some carriers. The reason for reduction in burn rate isn't because of the interval in requesting resources. Growth is not modulated by frequency of contacting ARIN. I would posit that the reason for burn rate reduction in IPv4 is that we are seeing more widespread adoption of v6 in internal networks by large consumers of address space than people realize. We don't see the corresponding increase in v6 traffic on the internet because we don't see service providers moving their primary landing pages to v6 yet. For many you still need to provide a "special" hostname to get their v6 service and most people aren't going to bother with that. So much of the traffic is being NATed to v4 at the network provider's internet edge. From gbonser at seven.com Thu Mar 15 19:07:58 2012 From: gbonser at seven.com (George Bonser) Date: Thu, 15 Mar 2012 23:07:58 +0000 Subject: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09D1578A@RWC-MBX1.corp.seven.com> References: <4F60B442.1030706@arin.net> <968C470DAC25FB419E0159952F28F0C039D7D48D@MEM0200CP3XF04.ds.irsnet.gov> <596B74B410EE6B4CA8A30C3AF1A155EA09D15736@RWC-MBX1.corp.seven.com> <596B74B410EE6B4CA8A30C3AF1A155EA09D1578A@RWC-MBX1.corp.seven.com> Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09D1579C@RWC-MBX1.corp.seven.com> " That space is just one example where consumption of v6 addresses are in decline." Meant "v4 addresses are in decline" > -----Original Message----- > From: George Bonser > Sent: Thursday, March 15, 2012 4:07 PM > To: George Bonser; Morizot Timothy S; arin-ppml at arin.net > Subject: RE: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply > and Reset Trigger to /8 in Free Pool > > Another reason for the reduction in burn rate may have nothing to do > with going from 12 month to 3 month allocations. Think about it ... > there SHOULD be NO change in burn rate over a 12 month period. If I > need a /19 every three months then I am going to need them every three > months whether I get them once a year in a larger block or not. The > frequency of having to go to ARIN does not change the growth rate of a > service requiring IP addresses. So the notion that going from 12 month > supply to 3 month supply having greatly reduced the consumption of > address resources seems odd to me. > > What is more likely are things like the largest consumers of public IP > space (mobile networks, for example) going to IPv6 internally in their > networks and using NAT64/DNS64 CGN to interface devices to the v4 > Internet. > > There are an increasing number of native v6 devices out there on an > increasing number of networks in the mobile space. This is reducing > the amount of v4 addresses burned up in these mobile networks. VZW, > for example, has a large number of native v6 devices these days and as > old devices are retired and people upgrade to new ones, the number is > increasing with every passing day. > > That space is just one example where consumption of v6 addresses are in > decline. My v6 traffic is increasing with each passing month. I would > currently estimate that of all clients able to connect to my network > for service, about 1% are currently native v6 (I'll know with more > precision at the end of this month). Of the newer clients, 100% are v6 > capable and nearly 100% are on a v6 native network with some carriers. > > The reason for reduction in burn rate isn't because of the interval in > requesting resources. Growth is not modulated by frequency of > contacting ARIN. I would posit that the reason for burn rate reduction > in IPv4 is that we are seeing more widespread adoption of v6 in > internal networks by large consumers of address space than people > realize. We don't see the corresponding increase in v6 traffic on the > internet because we don't see service providers moving their primary > landing pages to v6 yet. For many you still need to provide a > "special" hostname to get their v6 service and most people aren't going > to bother with that. So much of the traffic is being NATed to v4 at > the network provider's internet edge. > > From jeffrey.lyon at blacklotus.net Thu Mar 15 19:21:29 2012 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 15 Mar 2012 19:21:29 -0400 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: References: <4F60B42E.9040101@arin.net> Message-ID: On Thu, Mar 15, 2012 at 6:40 PM, Chris Grundemann wrote: > On Wed, Mar 14, 2012 at 09:07, ARIN wrote: >> Policy statement: >> >> In NRPM 8.3, replace "IPv4 number resources" with "IPv4 number resources and >> ASNs". >> >> Rationale: >> >> There are legitimate use cases for transferring ASNs, and no significant >> downsides (identified to date) of allowing it. > > This is not an effective rationale. Rather than stating that "There > are legitimate use cases for transfering ASNs" (which is unhelpful at > best), it would be much more useful to have these supposed use-cases > identified. > > Can anyone identify any use-cases where transferring ASNs is actually > *necessary* for the operation of the Internet in the ARIN region? I > have read (all of) the previous discussion threads on this topic and > have yet to see a single compelling use-case. I think it would be very > helpful to the discussion for folks to understand why this request is > being made. > > Thanks, > ~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. > > > > -- > @ChrisGrundemann > http://chrisgrundemann.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 a marketing standpoint, there seems to be an understanding that lower numbered AS means better established carrier. Those looking to offer network services may wish to acquire older networks and merge into the lower numbered AS. We are AS32421, and a customer of ours was just issued a 4 digit ASN. I'd be willing to trade for aesthetic reasons ;) This is the only reason I can think of. Thanks, -- 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 cgrundemann at gmail.com Thu Mar 15 19:33:52 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 15 Mar 2012 17:33:52 -0600 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: References: <4F60B42E.9040101@arin.net> Message-ID: On Thu, Mar 15, 2012 at 17:21, Jeffrey Lyon wrote: > From a marketing standpoint, there seems to be an understanding that > lower numbered AS means better established carrier. Those looking to > offer network services may wish to acquire older networks and merge > into the lower numbered AS. We are AS32421, and a customer of ours was > just issued a 4 digit ASN. I'd be willing to trade for aesthetic > reasons ;) Thanks Jeffery, this is one I've seen stated before. The other one I've read is "peering relationships" - the idea being that you could assume peering relationships by assuming the AS of a previously established network. So we have: 1) Aesthetics 2) Deception I have to say I remain unconvinced that this policy does anything to better our community in any real way. In fact, the "deceiving folks by assuming another identity" use-case is probably a net-evil. > This is the only reason I can think of. If anyone else can think of something more necessary, I'd love to hear it. Cheers, ~Chris > Thanks, > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications - AS32421 > First and Leading in DDoS Protection Solutions -- @ChrisGrundemann http://chrisgrundemann.com From jmaimon at chl.com Thu Mar 15 19:34:09 2012 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 15 Mar 2012 19:34:09 -0400 Subject: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool In-Reply-To: <5A43A629-4145-428C-9F52-8590D720857C@delong.com> References: <4F60B442.1030706@arin.net> <968C470DAC25FB419E0159952F28F0C039D7D48D@MEM0200CP3XF04.ds.irsnet.gov> <4F618D95.50407@chl.com> <5A43A629-4145-428C-9F52-8590D720857C@delong.com> Message-ID: <4F627C71.9040404@chl.com> Owen DeLong wrote: > On Mar 14, 2012, at 11:35 PM, Joe Maimon wrote: > >> >> How about someone be specific, and point out what kind of specific issues that the ARIN region may experience due to its expanded ipv4 availability, thanks in no small part to a decreased burn rate and greater efficiency, brought to you by three month soft landing? >> > I will start by specifically pointing out the flaws in the above assumptions... > > First, the assumption that the three month soft landing has caused greater efficiency and that the decreased burn rate has resulted from that greater efficiency and not from other factors. If not that, then from what? Because we all can see that the burn rate has decreased. > > In reality, that decreased burn rate represents not greater efficiency, but, greater pain inflicted upon organizations struggling to get by with what they have because the effort involved in obtaining 3 months worth of address space and the costs associated with doing so exceeds the revenue those addresses are likely to produce. It represents real customers suffering under degraded services and increased pricing as a result. That's not greater efficiency, it's just greater pain. You keep describing greater efficiency. And if the greater efficiency comes at the cost of extra inconvenience and effort, obtaining efficiency usually entails some effort. It wont get better by getting rid of ipv4 availability faster. >> Misery loves company? >> >> If all you have to whine about is that people deserve to suffer for not racing to adopt IPv6 and by golly we are going to make sure they do, I am really tired of hearing that. >> > This is a very interesting way to characterize my argument. I just called your spade a spade. Hardly interesting. > What I'm arguing against is the fact that people are actually suffering now. And how does your proposal help? > Even people who have adopted IPv6. Not because they failed to adopt IPv6, but, in part because others have failed to do so, but in larger part because our current flawed policy is inflicting additional unnecessary pain in the name of making the free pool last mythically longer. Back to the spade. IPv4 is lasting too long. > > Quite the contrary... However, when the RIR pools are depleted, the cost of failing to deploy IPv6 will start to be expressed in terms that seem to be better understood by managers, whereas today they are expressed in technical esoterica that does not seem to get through as well. These same managers would quite prefer a dollar tag, because the technical esoterica is actually much scarier to them. Most of them would rather ask one question and be told one answer when trying to obtain addresses. How much will it cost? > Further, the post RIR depletion fragmentation of the address pool and subsequent consequences to the routing table will serve as a further driver. I have very much thought this through to its logical conclusion. So why are you trying to hurry up RIR depletion? Are you looking forward to these consequences? Because they are not happening now. > > Have you thought through to the logical conclusion of the damage today's policy is causing today in the real world? Why cant you simply state what the damage is? > Have you thought through the silo effect Whats that? Be specific. > and the damage that is already causing? What damage? Be specific. > Have you thought through the extent of the damage to the concept of ubiquitous network communications world wide that will evolve from north america being so completely disjoint from the rest of the world? You have got to be kidding me. Are you talking about the NAT boogeyman again? And somehow depleting ARIN free pool makes that better? > I think that depends on the price at which they seek to monetize. Which in many markets, is $15 for 5. > If the price is too high, it will spur IPv6 adoption pretty well. Your gambling without even understanding your odds. >> Do you really think the suits at these organizations would be so eager to work against their own immediate interests? >> > This conclusion is opaque to me. I absolutely expect them to work in their own interests. However, I see their interests falling into one of three behaviors: > > 1. Hoard what they have and try to be the rare provider of IPv4 that still has addresses to give in order to gain > competitive advantage. They wont be rare, they will be a member of the Xlarge club, and they will have a competitive advantage. > > 2. Attempt to monetize IPv4 addresses at such a high asking price as to strongly motivate potential customers > to use IPv6 as an alternative wherever possible. Since that would not be in their best interest, one can assume they will make every effort not to do so intentionally. > > 3. Attempt to monetize IPv4 addresses at low enough prices that a one-time redistribution of addresses replaces > the RIR system as the new free pool until the readily available monetizable addresses are redistributed and > we are faced with runout once again. FTFY Attempt to monetize IPv4 addresses at market bearing prices so that continuing efficiency of addressing adequately replaces the RIR system as the new NON-free pool for as long as they can benefit from the extra costs that they can impose. > > > If they behave in some combination of those three ways, then, the end result is still the same... > > 1. IPv4 runs out. No it doesnt. There is the same amount of finite IPv4 as there always was. And the holders of the vast majority of it will be sitting pretty. > 2. People faced with the rising cost of IPv4 and supply problems obtaining IPv4 addresses will turn to IPv6. You hope. Where is the evidence of that occurring, say, in the regions that have already run out? > 3. IPv4 deaggregation will make IPv4 routing more and more expensive to maintain. This is very possibly inevitable and this draft policy has nothing relevant to bear on this issue. > > I don't know that I would say "eagerly", but, I do anticipate that these pain factors (which, by the way cannot really be mitigated, only moved around from place to place a little bit) which can only continue to increase will increase until such time as we generally deploy IPv6. This is the crux of your rational, out in the open. Kill off IPv4 to drive IPv6 adoption. Except it is immoral, improper, and inaccurate. > > >> How are things working out in the depleted regions? Or is that ARIN's responsibility as well? >> > The depleted region is still in the transfers are available stage, but, even so, there is a significant increase in IPv6 deployment efforts in that region. There is also a significant increase in IPv6 deployment efforts in the RIPE region which, while it hasn't run out yet is close enough that it is pretty clear they will be the second region to run out. That is great. So how is ARIN free pool availability negatively affecting them? And we both know that they are nowhere close to where they need to be and I dont believe we want to be in their position any sooner that we have to. > I think it is completely irresponsible maintain a padlock on the granary in front of all the hungry villagers and post armed guards to watch them starve slowly gambling on the likelihood that more villagers arrive next month. > > You seem to think it is irresponsible to feed the people who are hungry today gambling on the possibility that the number of people starving next month will be about the same. > > I prefer to feed the people in front of me at the risk that more people MIGHT be hungry tomorrow vs. keep people hungry today based on such an uncertainty. > > Owen Your analogy is flawed, even more so than most. 1) IPv4 is not consumable. It is recyclable. 2) When the doors were wide open, even when we well understood the coming scarcity, the hoarders grabbed their fill, repeatedly. 3) Nobody is padlocking anything. Gluttony is simply being discouraged. 4) We absolutely know that under the previous burn rate people will not be able to get IPv4 from ARIN when they need it, prior to IPv6 being a real option for them. Under the current burn rate, there is a much better chance, a reason to hope again that this time we will make it in time. Where it really falls down. The rational course to coming scarcity is not to consume as much as possible prior to its arrival, it is to preserve and restrict your consumption to the most efficient level possible that extends your longevity, even at a cost of a hungrier belly. When a community of individuals enters the dynamic, things change. The communities rational course is still efficiency. However, It is different for the individual, where the rational course is to consume as much as possible from the communal resources, and to preserve them in reusable and recyclable form for when there are no more to be had. And if such behavior generates a marketable surplus, so much the better. The community is best served by limiting the individual tendency for this kind of behavior. I got a better analogy, a car one! (The consumption aspect is still problematic, but gasoline as a resource is more renewable [at least for now]) The needle has just started hovering above the E, past the 1/8th mark but still on the gauge line. The low fuel warning has not come on yet, but you dont recall if it comes on at 1 gallon or 2. You are on the highway in a mountaneous region. Its late at night and you last passed an open station hours ago. Some exits have signs posted for Service stations, but the last few you tried were all closed, a false hope. You know that in about 100 miles there is an open 24hrs station, right on the interstate, in the next state, where the prices are significantly cheaper. Your car is rated at 35mpg highway, but your driving experience is more usually at 22-25. I suspect most of us have been in situations very much like this one. Do you: A) press the pedal to the metal hoping to get as far as you possibly can, so that your nerves have to deal with this painful suspense for the shortest time possible. I cant drive 55. B) Drive as judiciously and as efficiently to get as far as you possibly can, using the terrain and keeping within your rpm/torque efficiency sweet spot, hoping you have closer to 3gals in the tank and that you will make at least 33mpg. [B1) Unload the wife and kids and all the luggage and hope you can come back for them with your increased fuel range] C) Drive as you normally do and hope for the best. Maybe you will make it, maybe you wont, maybe the next exit's service station will be open, maybe a passerby will see you stranded and give you a lift, maybe you have AAA. D) Detour through the empty streets looking for somebody awake who can point you to an open station and hope you dont get lost and stranded. Best, Joe From jmaimon at chl.com Thu Mar 15 19:40:38 2012 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 15 Mar 2012 19:40:38 -0400 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: References: <4F60B42E.9040101@arin.net> Message-ID: <4F627DF6.5090107@chl.com> Jeffrey Lyon wrote: >> From a marketing standpoint, there seems to be an understanding that > lower numbered AS means better established carrier. Those looking to > offer network services may wish to acquire older networks and merge > into the lower numbered AS. We are AS32421, and a customer of ours was > just issued a 4 digit ASN. I'd be willing to trade for aesthetic > reasons ;) > > This is the only reason I can think of. > > Thanks, Given the coming exhaustion of 2byte ASN, and the difficulties with 4bytes, given my druthers I would much rather get one on the transfer market for a reasonable price so that I can use the nice community attribute layout and keep all my old gear, have zero inter-operation concerns, and appear to be an older established network. Yes, I am one of those guys who try to ensure those whom I consult for and advise get a 2byte while they still can. Nobody has complained that they wanted the 4byte instead. Or suppose I am transferring addresses and I want the routing gear along with it, but this is not quite an M&A or structuring it as one has its own disadvantages. Or I was your customer and you has an extra one and I used it for all this time and I would like it to outlive our relationship and I dont want to redo all my stuff. I support directed transfers of all resources. Picking and choosing is not quite right, even if it might be more prudent, where there to be no identified benefits. Support. Joe From kevinb at thewire.ca Thu Mar 15 19:56:38 2012 From: kevinb at thewire.ca (Kevin Blumberg) Date: Thu, 15 Mar 2012 23:56:38 +0000 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: References: <4F60B42E.9040101@arin.net> Message-ID: <7E7773B523E82C478734E793E58F69E7694C36F7@SBS2011.thewireinc.local> Chris, Operators with 4 Byte ASN's are being turned away from peering in the ARIN region. The fact that there is almost zero take up of 4 Byte in the region shows there is an issue that shouldn't be ignored. I support this proposal and would suggest that just as it specifies IPv4 in the 8.3 text it should specify 2 Byte ASN's. Thanks, Kevin Blumberg > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Chris Grundemann > Sent: Thursday, March 15, 2012 7:34 PM > To: Jeffrey Lyon > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy 2012-3: ASN Transfers > > On Thu, Mar 15, 2012 at 17:21, Jeffrey Lyon > wrote: > > > From a marketing standpoint, there seems to be an understanding that > > lower numbered AS means better established carrier. Those looking to > > offer network services may wish to acquire older networks and merge > > into the lower numbered AS. We are AS32421, and a customer of ours was > > just issued a 4 digit ASN. I'd be willing to trade for aesthetic > > reasons ;) > > Thanks Jeffery, this is one I've seen stated before. The other one I've read is > "peering relationships" - the idea being that you could assume peering > relationships by assuming the AS of a previously established network. > > So we have: > 1) Aesthetics > 2) Deception > > I have to say I remain unconvinced that this policy does anything to better > our community in any real way. In fact, the "deceiving folks by assuming > another identity" use-case is probably a net-evil. > > > This is the only reason I can think of. > > If anyone else can think of something more necessary, I'd love to hear it. > > Cheers, > ~Chris > > > > Thanks, > > -- > > Jeffrey Lyon, Leadership Team > > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus > > Communications - AS32421 First and Leading in DDoS Protection > > Solutions > > > > -- > @ChrisGrundemann > http://chrisgrundemann.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 jmaimon at chl.com Thu Mar 15 20:00:32 2012 From: jmaimon at chl.com (Joe Maimon) Date: Thu, 15 Mar 2012 20:00:32 -0400 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: References: <4F60B42E.9040101@arin.net> Message-ID: <4F6282A0.5070404@chl.com> Chris Grundemann wrote: > So we have: > 1) Aesthetics > 2) Deception > As I personally believe that is all shared transition space really has going for it, I dont underestimate the appeal of either. Joe From farmer at umn.edu Thu Mar 15 20:52:04 2012 From: farmer at umn.edu (David Farmer) Date: Thu, 15 Mar 2012 19:52:04 -0500 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: <4F627DF6.5090107@chl.com> References: <4F60B42E.9040101@arin.net> <4F627DF6.5090107@chl.com> Message-ID: <4F628EB4.6040409@umn.edu> On 3/15/12 18:40 CDT, Joe Maimon wrote: > > > Jeffrey Lyon wrote: > >>> From a marketing standpoint, there seems to be an understanding that >> lower numbered AS means better established carrier. Those looking to >> offer network services may wish to acquire older networks and merge >> into the lower numbered AS. We are AS32421, and a customer of ours was >> just issued a 4 digit ASN. I'd be willing to trade for aesthetic >> reasons ;) >> >> This is the only reason I can think of. >> >> Thanks, > > Given the coming exhaustion of 2byte ASN, and the difficulties with > 4bytes, given my druthers I would much rather get one on the transfer > market for a reasonable price so that I can use the nice community > attribute layout and keep all my old gear, have zero inter-operation > concerns, and appear to be an older established network. > > Yes, I am one of those guys who try to ensure those whom I consult for > and advise get a 2byte while they still can. Nobody has complained that > they wanted the 4byte instead. Also, there seems to be a lot of 2 byte ASNs assigned but not visible in the routing system, over 16,000. Yes, at least some of those are actually in use, but not visible to the majority of the routing system. But, I suspect the vast majority of those 16,000 are just not in use any longer. See; http://www.potaroo.net/tools/asns/index.html > Or suppose I am transferring addresses and I want the routing gear along > with it, but this is not quite an M&A or structuring it as one has its > own disadvantages. > > Or I was your customer and you has an extra one and I used it for all > this time and I would like it to outlive our relationship and I dont > want to redo all my stuff. These seem a little hypothetical to me, but still possible. > I support directed transfers of all resources. Picking and choosing is > not quite right, even if it might be more prudent, where there to be no > identified benefits. I'm NOT ready to go all the way and include IPv6, at least not yet. Before allowing IPv6 specified transfers, I think we need a lot more discussion and thought about technical issues like sparse aggregation, etc... Bedsides there is no good reason to institute a recycling program for IPv6, not yet, maybe some day. Although, I'm ready to take the next step and include ASNs, in particular 2-byte ASN. I think I like Kevin's suggestion to restrict ASN transfers to 2-byte ASNs only, at least for now. We are running low and there can be valid reasons to recycle 2-byte ASNs, no where near as strong of reasons as the reasons to recycle IPv4 addresses, but still valid. > Support. I think I support it too, but think I would like the 2-byte ASN restriction added. If we decide to not allow ASN transfers then we should probably work on an awareness campaign and get people to return unused 2-byte ASN, maybe get the Board to approve some kind of discount for the return of 2-byte ASNs. ARIN could even, put something on the annual invoice, let people know they have an ASN that doesn't seem to be in the routing system, and allow then to return it and save a $100 or $250 on the invoice. This is NOT a critical issue like IPv4 exhaustion, but we probably shouldn't completely ignore the issue either. Fundamentally, I prefer a voluntary transfer system to most any kind of reclamation system, both for IPv4 addresses and 2-byte ASNs. -- =============================================== 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 farmer at umn.edu Thu Mar 15 20:56:53 2012 From: farmer at umn.edu (David Farmer) Date: Thu, 15 Mar 2012 19:56:53 -0500 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: <4F628EB4.6040409@umn.edu> References: <4F60B42E.9040101@arin.net> <4F627DF6.5090107@chl.com> <4F628EB4.6040409@umn.edu> Message-ID: <4F628FD5.3080102@umn.edu> On 3/15/12 19:52 CDT, David Farmer wrote: > > On 3/15/12 18:40 CDT, Joe Maimon wrote: >> >> >> Jeffrey Lyon wrote: >> >>>> From a marketing standpoint, there seems to be an understanding that >>> lower numbered AS means better established carrier. Those looking to >>> offer network services may wish to acquire older networks and merge >>> into the lower numbered AS. We are AS32421, and a customer of ours was >>> just issued a 4 digit ASN. I'd be willing to trade for aesthetic >>> reasons ;) >>> >>> This is the only reason I can think of. >>> >>> Thanks, >> >> Given the coming exhaustion of 2byte ASN, and the difficulties with >> 4bytes, given my druthers I would much rather get one on the transfer >> market for a reasonable price so that I can use the nice community >> attribute layout and keep all my old gear, have zero inter-operation >> concerns, and appear to be an older established network. >> >> Yes, I am one of those guys who try to ensure those whom I consult for >> and advise get a 2byte while they still can. Nobody has complained that >> they wanted the 4byte instead. > > Also, there seems to be a lot of 2 byte ASNs assigned but not visible in > the routing system, over 16,000. Yes, at least some of those are > actually in use, but not visible to the majority of the routing system. > But, I suspect the vast majority of those 16,000 are just not in use any > longer. See; > > http://www.potaroo.net/tools/asns/index.html > >> Or suppose I am transferring addresses and I want the routing gear along >> with it, but this is not quite an M&A or structuring it as one has its >> own disadvantages. >> >> Or I was your customer and you has an extra one and I used it for all >> this time and I would like it to outlive our relationship and I dont >> want to redo all my stuff. > > These seem a little hypothetical to me, but still possible. > >> I support directed transfers of all resources. Picking and choosing is >> not quite right, even if it might be more prudent, where there to be no >> identified benefits. > > I'm NOT ready to go all the way and include IPv6, at least not yet. > Before allowing IPv6 specified transfers, I think we need a lot more > discussion and thought about technical issues like sparse aggregation, I meant "sparse allocation", but I'm sure a discussion of "sparse aggregation" would be really interesting. :( > etc... Bedsides there is no good reason to institute a recycling program > for IPv6, not yet, maybe some day. > > Although, I'm ready to take the next step and include ASNs, in > particular 2-byte ASN. I think I like Kevin's suggestion to restrict ASN > transfers to 2-byte ASNs only, at least for now. We are running low and > there can be valid reasons to recycle 2-byte ASNs, no where near as > strong of reasons as the reasons to recycle IPv4 addresses, but still > valid. > >> Support. > > I think I support it too, but think I would like the 2-byte ASN > restriction added. > > If we decide to not allow ASN transfers then we should probably work on > an awareness campaign and get people to return unused 2-byte ASN, maybe > get the Board to approve some kind of discount for the return of 2-byte > ASNs. ARIN could even, put something on the annual invoice, let people > know they have an ASN that doesn't seem to be in the routing system, and > allow then to return it and save a $100 or $250 on the invoice. > > This is NOT a critical issue like IPv4 exhaustion, but we probably > shouldn't completely ignore the issue either. Fundamentally, I prefer a > voluntary transfer system to most any kind of reclamation system, both > for IPv4 addresses and 2-byte ASNs. > -- =============================================== 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 owen at delong.com Thu Mar 15 21:20:13 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 15 Mar 2012 18:20:13 -0700 Subject: [arin-ppml] Draft Policy 2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool In-Reply-To: <4F627C71.9040404@chl.com> References: <4F60B442.1030706@arin.net> <968C470DAC25FB419E0159952F28F0C039D7D48D@MEM0200CP3XF04.ds.irsnet.gov> <4F618D95.50407@chl.com> <5A43A629-4145-428C-9F52-8590D720857C@delong.com> <4F627C71.9040404@chl.com> Message-ID: >> >> In reality, that decreased burn rate represents not greater efficiency, but, greater pain inflicted upon organizations struggling to get by with what they have because the effort involved in obtaining 3 months worth of address space and the costs associated with doing so exceeds the revenue those addresses are likely to produce. It represents real customers suffering under degraded services and increased pricing as a result. That's not greater efficiency, it's just greater pain. > You keep describing greater efficiency. And if the greater efficiency comes at the cost of extra inconvenience and effort, obtaining efficiency usually entails some effort. > You define efficiency by radically different criteria than I do. To me, greater efficiency would mean providing the same capabilities with reduced consumption. That isn't what is happening. What is happening is providing less and less capabilities to more and more users at greater and greater cost. That's pretty much my definition of the opposite of efficiency. The word I use for that is pain. Ever increasing pain. > It wont get better by getting rid of ipv4 availability faster. > It will get better in the short term and it will not get any worse than it is going to be anyway in the long run. In fact, it will actually get worse by stretching it out because instead of providing good services and capabilities to as many as we can and then providing no services and capabilities to new users short of migration, your strategy leaves us continuing to provide less and less to more and more for longer and longer. >> What I'm arguing against is the fact that people are actually suffering now. > > And how does your proposal help? > It reduces short term suffering. >> Even people who have adopted IPv6. Not because they failed to adopt IPv6, but, in part because others have failed to do so, but in larger part because our current flawed policy is inflicting additional unnecessary pain in the name of making the free pool last mythically longer. > > Back to the spade. IPv4 is lasting too long. No. IPv4 is not lasting too long. The perception that there is IPv4 available is lasting too long. In reality, we've been operating under an IPv4 shortage for a long time already and continuing to draw that out longer and longer is causing additional harm. >> >> Quite the contrary... However, when the RIR pools are depleted, the cost of failing to deploy IPv6 will start to be expressed in terms that seem to be better understood by managers, whereas today they are expressed in technical esoterica that does not seem to get through as well. > > These same managers would quite prefer a dollar tag, because the technical esoterica is actually much scarier to them. > > Most of them would rather ask one question and be told one answer when trying to obtain addresses. > > How much will it cost? > Well, the sooner there is no perceived free pool, the sooner they can have their wish. However, that's really not my goal here. My goal is to stop punishing those who are running networks today (and by extension their customers) for the sake of preserving an IPv4 free pool to dole out little bits of rationed IPv4 to organizations that are currently vaporware or less and may never materialize. >> Further, the post RIR depletion fragmentation of the address pool and subsequent consequences to the routing table will serve as a further driver. I have very much thought this through to its logical conclusion. > > So why are you trying to hurry up RIR depletion? Are you looking forward to these consequences? > As I said, I'm not trying to hurry RIR depletion, I'm trying to reduce the extent to which we artificially slow it down slightly. > Because they are not happening now. Actually, they are. Just not on as noticeable a scale as they will later. >> Have you thought through to the logical conclusion of the damage today's policy is causing today in the real world? > > Why cant you simply state what the damage is? > I have stated it several times. To make it very very clear: The state of end-user connectivity today is a chronic provision of less and less useful service to more and more people with worse and worse constraints which further hobbles application development, innovation, and product generation. We have entire industry segments built around nothing but make-shift ways of overcoming these unnecessary artificial limitations. Continuing to make the constraints and limitations worse in order to allow organizations to avoid making necessary changes is causing harm not only to the organizations that are avoiding the necessary changes, but, to everyone else as well. We're heading for a world where end users will be connected through CGN gateways to gain what you would call "further efficiency". That's akin to calling the sharing of needles among junkies "greater efficiency" in their use of needles. I suppose, technically the term could apply, but, I would argue that the reduced public health cost of providing clean needles is far more efficient than needle-sharing. Rationing IPv4 out to extend the free pool really is having a similar systemic effect at this point. >> Have you thought through the silo effect > Whats that? > > Be specific. > The APNIC region is moving forward with IPv6. RIPE is moving forward with IPv6. North America preserving a prolonged period of IPv4 dependency with more and more degraded IPv4 service instead of moving forward to IPv6 will isolate us into our own little broken internet silo. Unfortunately, because the internet is global, this will not only cause the local self-inflicted damage for which we can blame no one but ourselves, but, will also increase costs and degrade the user experience world wide as folks in those regions that have already migrated to IPv6 are forced to continue to cobble together ways to communicate with our dysfunctional region. >> and the damage that is already causing? > What damage? > > Be specific. > I have been very specific above and earlier in the thread. >> I think that depends on the price at which they seek to monetize. > Which in many markets, is $15 for 5. $3/IPv4 address is actually cheap given that Micr0$0ft was paying $11/IPv4 address and I hear that whoever bought the registrations from Borders paid even more. > If the price is too high, it will spur IPv6 adoption pretty well. > > Your gambling without even understanding your odds. Huh? Be specific. > Do you really think the suits at these organizations would be so eager to work against their own immediate interests? >>> >> This conclusion is opaque to me. I absolutely expect them to work in their own interests. However, I see their interests falling into one of three behaviors: >> >> 1. Hoard what they have and try to be the rare provider of IPv4 that still has addresses to give in order to gain >> competitive advantage. > > They wont be rare, they will be a member of the Xlarge club, and they will have a competitive advantage. > If the providers that have available IPv4 addresses for new and growing customers are not rare, then, they have no competitive advantage from this fact. The competitive advantage of which I speak specifically comes from the fact that having available IPv4 addresses is rare. As long as a bunch of providers have available IPv4 addresses to provide services, there is still a competitive landscape for those services. >> >> 2. Attempt to monetize IPv4 addresses at such a high asking price as to strongly motivate potential customers >> to use IPv6 as an alternative wherever possible. > > Since that would not be in their best interest, one can assume they will make every effort not to do so intentionally. > >> >> 3. Attempt to monetize IPv4 addresses at low enough prices that a one-time redistribution of addresses replaces >> the RIR system as the new free pool until the readily available monetizable addresses are redistributed and >> we are faced with runout once again. > > FTFY > > Attempt to monetize IPv4 addresses at market bearing prices so that continuing efficiency of addressing adequately replaces > the RIR system as the new NON-free pool for as long as they can benefit from the extra costs that they can impose. > I'm not sure how you see that working. I'm also not sure what FTFY is supposed to be an abbreviation for. > > >> >> >> If they behave in some combination of those three ways, then, the end result is still the same... >> >> 1. IPv4 runs out. > > No it doesnt. There is the same amount of finite IPv4 as there always was. And the holders of the vast majority of it will be sitting pretty. The ratio of IPv4 addresses to demand continues to shrink, if you prefer. Since that ratio is already well below 0.25 (yes, I believe there are at least 4 addresses needed for every one available today) and demand is continuing to grow, it boggles my mind how you can deceive yourself into perceiving this as realistic. >> 2. People faced with the rising cost of IPv4 and supply problems obtaining IPv4 addresses will turn to IPv6. > > You hope. Where is the evidence of that occurring, say, in the regions that have already run out? http://www.cidr-report.org/cgi-bin/plota?file=%2Fvar%2Fdata%2Fbgp%2Fv6%2Fas2.0%2Fbgp-active.txt&descr=Active+BGP+entries+%28FIB%29&ylabel=Active+BGP+entries+%28FIB%29&range=--OR--&StartDate=1-jan-2010&EndDate=15-mar-2012&yrange=Auto&ymin=&ymax=&Width=1&Height=1&with=Step&color=auto&logscale=linear There are a couple of steps in there, but, a market upswing after April, 2011 and another upswing appears to be starting. (Upswing being used to describe the curve turning towards vertical from the linear average). Note, the overall linear trend is markedly upwards and other than some very short-lived anomalies, tends to be increasing towards vertical overall as well. In fact, a parabola could be a relatively close curve fit with a slight curve inwards from about April/11 to December/11. I'd say that's pretty strong evidence, actually. > >> 3. IPv4 deaggregation will make IPv4 routing more and more expensive to maintain. > > This is very possibly inevitable and this draft policy has nothing relevant to bear on this issue. > Not at all true. Forcing providers to get 4x as many prefixes per year has a lot to do with IPv4 deaggregation. >> >> I don't know that I would say "eagerly", but, I do anticipate that these pain factors (which, by the way cannot really be mitigated, only moved around from place to place a little bit) which can only continue to increase will increase until such time as we generally deploy IPv6. > > This is the crux of your rational, out in the open. > I think you mean rationale. > Kill off IPv4 to drive IPv6 adoption. > That isn't all what I said. What I said was that pain is inevitable. We can move the pain around. We can increase the pain in intensity and in duration. The only permanent relief available is IPv6 adoption. However, in terms of what we can do with IPv4, we can only provide small amounts of relief to some entities. However, to do so, we must inflict proportionately (or possibly disproportionately larger) amounts of pain on other entities. > Except it is immoral, improper, and inaccurate. Funny, that's pretty close to my view of continuing the 3-month policy. > >> >> >>> How are things working out in the depleted regions? Or is that ARIN's responsibility as well? >>> >> The depleted region is still in the transfers are available stage, but, even so, there is a significant increase in IPv6 deployment efforts in that region. There is also a significant increase in IPv6 deployment efforts in the RIPE region which, while it hasn't run out yet is close enough that it is pretty clear they will be the second region to run out. > > That is great. So how is ARIN free pool availability negatively affecting them? And we both know that they are nowhere close to where they need to be and I dont believe we want to be in their position any sooner that we have to. This is described in detail above. > >> I think it is completely irresponsible maintain a padlock on the granary in front of all the hungry villagers and post armed guards to watch them starve slowly gambling on the likelihood that more villagers arrive next month. >> >> You seem to think it is irresponsible to feed the people who are hungry today gambling on the possibility that the number of people starving next month will be about the same. >> >> I prefer to feed the people in front of me at the risk that more people MIGHT be hungry tomorrow vs. keep people hungry today based on such an uncertainty. >> >> Owen > > Your analogy is flawed, even more so than most. > > 1) IPv4 is not consumable. It is recyclable. > It is only recyclable if you tear down the service that is depending on it. > 2) When the doors were wide open, even when we well understood the coming scarcity, the hoarders grabbed their fill, repeatedly. > I don't share your belief here. > 3) Nobody is padlocking anything. Gluttony is simply being discouraged. > I don't share your belief here, either. There is a very real cost to an organization to go through the ARIN process for getting more addresses. That cost is increasing as a result of this and other policies. One of the things I do is provide consulting services helping organizations to get their IP addresses from ARIN. The number of hours I spend on each of these has gone up as a result of other policies. Quadrupling the number of times an organization needs to pay someone to do this further increases those costs. That is the economic equivalent of a padlock. > 4) We absolutely know that under the previous burn rate people will not be able to get IPv4 from ARIN when they need it, prior to IPv6 being a real option for them. Under the current burn rate, there is a much better chance, a reason to hope again that this time we will make it in time. > We absolutely know that under the current policy, people who need IPv4 today are not able to get it from ARIN in a cost-effective manner. You have to factor the costs of processing an application into the thinking on this. > Where it really falls down. > > The rational course to coming scarcity is not to consume as much as possible prior to its arrival, it is to preserve and restrict your consumption to the most efficient level possible that extends your longevity, even at a cost of a hungrier belly. > Agreed. We were at hungry bellies at 12 months with current policies. Now, we've moved past that towards starvation. > When a community of individuals enters the dynamic, things change. The communities rational course is still efficiency. However, It is different for the individual, where the rational course is to consume as much as possible from the communal resources, and to preserve them in reusable and recyclable form for when there are no more to be had. And if such behavior generates a marketable surplus, so much the better. > Which is one of the many reasons I'm not thrilled about having an IPv4 market. However, it seemed less damaging than the available alternatives. > The community is best served by limiting the individual tendency for this kind of behavior. > Which we were already doing before we set the allocation window to 3 months and which doesn't go away with putting it back to 12 months until we get closer to runout as intended. > I got a better analogy, a car one! (The consumption aspect is still problematic, but gasoline as a resource is more renewable [at least for now]) > > The needle has just started hovering above the E, past the 1/8th mark but still on the gauge line. The low fuel warning has not come on yet, but you dont recall if it comes on at 1 gallon or 2. You are on the highway in a mountaneous region. Its late at night and you last passed an open station hours ago. Some exits have signs posted for Service stations, but the last few you tried were all closed, a false hope. You know that in about 100 miles there is an open 24hrs station, right on the interstate, in the next state, where the prices are significantly cheaper. Your car is rated at 35mpg highway, but your driving experience is more usually at 22-25. > > I suspect most of us have been in situations very much like this one. > > Do you: > > A) press the pedal to the metal hoping to get as far as you possibly can, so that your nerves have to deal with this painful suspense for the shortest time possible. I cant drive 55. > > B) Drive as judiciously and as efficiently to get as far as you possibly can, using the terrain and keeping within your rpm/torque efficiency sweet spot, hoping you have closer to 3gals in the tank and that you will make at least 33mpg. > > [B1) Unload the wife and kids and all the luggage and hope you can come back for them with your increased fuel range] > > C) Drive as you normally do and hope for the best. Maybe you will make it, maybe you wont, maybe the next exit's service station will be open, maybe a passerby will see you stranded and give you a lift, maybe you have AAA. > > D) Detour through the empty streets looking for somebody awake who can point you to an open station and hope you dont get lost and stranded. Your analogy is, IMHO even more deeply flawed than mine. First, it generates the illusion that there are no other consequences to selecting option B (which makes it ideal for pushing your viewpoint, I realize). To match the situation with IPv4, selecting option B would have to include getting a ticket for driving too slow from every state trooper you passed along the way and include the additional gasoline consumed in the process of each start and stop process because of it. When you consider those additional aspects on option B, using option C until the indicator light comes on (which may actually be a decent analogy for this proposal) and then switching to option B may well be an attractive alternative. Especially when you consider that under this proposal, the light comes on at 1 /8 remaining in the tank and we are currently at more than 7 /8s in the tank. Owen From owen at delong.com Thu Mar 15 21:38:18 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 15 Mar 2012 18:38:18 -0700 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: References: <4F60B42E.9040101@arin.net> Message-ID: As soon as ASN transfers became possible based on this policy, it would eliminate that perception and thus remove the marketing value. I see no reason to pass policy based on the idea that someone's marketing department thinks it might look cool. That does not seem technically sound or particularly useful from an internet resource stewardship perspective. Owen > >> From a marketing standpoint, there seems to be an understanding that > lower numbered AS means better established carrier. Those looking to > offer network services may wish to acquire older networks and merge > into the lower numbered AS. We are AS32421, and a customer of ours was > just issued a 4 digit ASN. I'd be willing to trade for aesthetic > reasons ;) > > This is the only reason I can think of. > > Thanks, > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications - AS32421 > First and Leading in DDoS Protection Solutions > _______________________________________________ > 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 Thu Mar 15 21:42:20 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 15 Mar 2012 18:42:20 -0700 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: <7E7773B523E82C478734E793E58F69E7694C36F7@SBS2011.thewireinc.local> References: <4F60B42E.9040101@arin.net> <7E7773B523E82C478734E793E58F69E7694C36F7@SBS2011.thewireinc.local> Message-ID: <3F5C7A15-C07E-4FC4-BBF4-4E0983DB4472@delong.com> Turned away by whom and for what reasons? At this point, there aren't really any compatibility problems even if the peer's router can't handle 4-byte ASNs locally, they just have to configure the peering session with AS23456 and move on. I really don't think continuing to cater to irrational misperceptions is the right solution to this problem. Rather, I think we should investigate what is actually causing these issues and find a better solution. The fact that people aren't getting turned away in other regions is proof that the technology is feasible. Owen On Mar 15, 2012, at 4:56 PM, Kevin Blumberg wrote: > Chris, > > Operators with 4 Byte ASN's are being turned away from peering in the ARIN region. The fact that there is > almost zero take up of 4 Byte in the region shows there is an issue that shouldn't be ignored. > > I support this proposal and would suggest that just as it specifies IPv4 in the 8.3 text it should specify > 2 Byte ASN's. > > Thanks, > > Kevin Blumberg > > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Chris Grundemann >> Sent: Thursday, March 15, 2012 7:34 PM >> To: Jeffrey Lyon >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] Draft Policy 2012-3: ASN Transfers >> >> On Thu, Mar 15, 2012 at 17:21, Jeffrey Lyon >> wrote: >> >>> From a marketing standpoint, there seems to be an understanding that >>> lower numbered AS means better established carrier. Those looking to >>> offer network services may wish to acquire older networks and merge >>> into the lower numbered AS. We are AS32421, and a customer of ours was >>> just issued a 4 digit ASN. I'd be willing to trade for aesthetic >>> reasons ;) >> >> Thanks Jeffery, this is one I've seen stated before. The other one I've read is >> "peering relationships" - the idea being that you could assume peering >> relationships by assuming the AS of a previously established network. >> >> So we have: >> 1) Aesthetics >> 2) Deception >> >> I have to say I remain unconvinced that this policy does anything to better >> our community in any real way. In fact, the "deceiving folks by assuming >> another identity" use-case is probably a net-evil. >> >>> This is the only reason I can think of. >> >> If anyone else can think of something more necessary, I'd love to hear it. >> >> Cheers, >> ~Chris >> >> >>> Thanks, >>> -- >>> Jeffrey Lyon, Leadership Team >>> jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus >>> Communications - AS32421 First and Leading in DDoS Protection >>> Solutions >> >> >> >> -- >> @ChrisGrundemann >> http://chrisgrundemann.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. > _______________________________________________ > 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 leslien at arin.net Thu Mar 15 21:50:10 2012 From: leslien at arin.net (Leslie Nobile) Date: Fri, 16 Mar 2012 01:50:10 +0000 Subject: [arin-ppml] AC requested Stats Message-ID: These stats are being provided at the request of the ARIN AC regarding some information they felt would help in the consideration of address policy. I have attached a spreadsheet that shows the monthly breakdown of IPv4 space issued in 2011. The spreadsheet shows the clear decline in IPv4 space issued after Feb 2011 when ARIN received its last /8 from the IANA, and the new 3 month allocation supply policy went into effect. Regarding how much space in Feb 2011 was issued under the 3 month window vs the 12 month window, we show that the majority of IPv4 space issued during that month was issued in the first 4 days (under the 12 month window). Between Feb 1 and Feb 4 2011, ARIN issued 20,753 /24s. For the remainder of that month, ARIN issued only 1,435 /24s. Regards, Leslie Nobile -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2011 IPv4 stats.xlsx Type: application/x-msexcel Size: 33039 bytes Desc: 2011 IPv4 stats.xlsx URL: From jeffrey.lyon at blacklotus.net Thu Mar 15 22:17:33 2012 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 15 Mar 2012 22:17:33 -0400 Subject: [arin-ppml] AC requested Stats In-Reply-To: References: Message-ID: On Thu, Mar 15, 2012 at 9:50 PM, Leslie Nobile wrote: > These stats are being provided at the request of the ?ARIN AC regarding some > information they felt would help ?in the consideration of address policy. > > I have attached a spreadsheet that shows the monthly breakdown of IPv4?space > issued in 2011. ?The spreadsheet shows the clear decline in IPv4 > space issued after Feb 2011 when ARIN received its last /8 from the IANA, > and the new 3 month allocation supply policy went into effect. > > Regarding how much space in Feb 2011 was issued under the 3 month window?vs > the 12 month window, we show that the majority of IPv4 space issued > during that month was issued in the first 4 days (under the 12 > month?window). ?Between Feb 1 and Feb 4 2011, ARIN issued 20,753 /24s. For > the > remainder of that month, ARIN issued only 1,435 /24s. > > Regards, > Leslie Nobile > > _______________________________________________ > 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. Those of us who saw the end of 12 month supply requested new space at the 11th hour, which would at least partially explain the sudden drop. -- 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 gbonser at seven.com Thu Mar 15 23:36:15 2012 From: gbonser at seven.com (George Bonser) Date: Fri, 16 Mar 2012 03:36:15 +0000 Subject: [arin-ppml] AC requested Stats In-Reply-To: References: Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09D23D25@RWC-MBX1.corp.seven.com> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Jeffrey Lyon > Those of us who saw the end of 12 month supply requested new space at > the 11th hour, which would at least partially explain the sudden drop. If that's the case, then there would have been a corresponding ramp up toward the end of 2010. I just don't see the frequency of having to go to ARIN as having any real impact on the number of IP addresses an organization actually requires to do business. What this would seem to tell me is that people tend to make very optimistic projections of address requirements a year out and then fail to meet those targets and end up with a bunch of IP addresses they didn't really need. Doing forecasting on a quarterly basis probably tends to be a little more realistic. That said, going to 6 months would probably be ok, but a year is likely too much. If that assumption is NOT true and if the change is simply due to people "stocking up" then we should see address consumption start to return to earlier rates after some period of time from the change once that supply has been put into service and more are required. Probably better to leave things as they are and see how it goes for the next six months, in my opinion. From narten at us.ibm.com Fri Mar 16 00:53:02 2012 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 16 Mar 2012 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201203160453.q2G4r2Bo005835@rotala.raleigh.ibm.com> Total of 45 messages in the last 7 days. script run at: Fri Mar 16 00:53:02 EDT 2012 Messages | Bytes | Who --------+------+--------+----------+------------------------ 2.22% | 1 | 59.63% | 638240 | jcurran at arin.net 17.78% | 8 | 9.12% | 97614 | owen at delong.com 17.78% | 8 | 5.68% | 60849 | jmaimon at chl.com 13.33% | 6 | 3.48% | 37212 | gbonser at seven.com 6.67% | 3 | 2.96% | 31694 | info at arin.net 6.67% | 3 | 2.06% | 22088 | jeffrey.lyon at blacklotus.net 2.22% | 1 | 4.91% | 52539 | leslien at arin.net 4.44% | 2 | 1.85% | 19817 | farmer at umn.edu 4.44% | 2 | 1.20% | 12853 | cgrundemann at gmail.com 2.22% | 1 | 1.44% | 15360 | louie at louie.net 2.22% | 1 | 1.30% | 13925 | scottleibrand at gmail.com 2.22% | 1 | 1.16% | 12382 | kkargel at polartel.com 2.22% | 1 | 0.83% | 8933 | petertbui0 at gmail.com 2.22% | 1 | 0.75% | 8071 | jrhett at netconsonance.com 2.22% | 1 | 0.68% | 7247 | kevinb at thewire.ca 2.22% | 1 | 0.66% | 7104 | jsw at inconcepts.biz 2.22% | 1 | 0.61% | 6501 | timothy.s.morizot at irs.gov 2.22% | 1 | 0.60% | 6424 | narten at us.ibm.com 2.22% | 1 | 0.59% | 6275 | mysidia at gmail.com 2.22% | 1 | 0.49% | 5220 | hannigan at gmail.com --------+------+--------+----------+------------------------ 100.00% | 45 |100.00% | 1070348 | Total From tvest at eyeconomics.com Fri Mar 16 11:11:02 2012 From: tvest at eyeconomics.com (Tom Vest) Date: Fri, 16 Mar 2012 11:11:02 -0400 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: <4F60B42E.9040101@arin.net> References: <4F60B42E.9040101@arin.net> Message-ID: <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> There are lots of compelling reasons to support ASN transfers, depending on what one hopes to accomplish: 1. Entities that already expect to enjoy a long profitable run as IPv4 brokers will be able to command even higher prices for the bundled lease/sales of "lightly used" IPv4 prefixes along with their associated origin-ASes. 2. Entities that aspire to further extend their profitable run as IPv4 brokers will have an easier time power-washing their more roughly used Pv4 by repackaging soiled prefixes with a different origin-AS between each new lease transaction. 3. Entities that would not be unhappy to see SIDR/RPKI fail absolutely and/or to succeed primarily in turning the current industry pecking order into a perpetual, insurmountable reputation hierarchy -- where no amount of good of behavior can ever be truly reassuring (if you're a new entrant), and no instance of bad behavior need ever tarnish one's own reputation (if you're an incumbent operator) -- would have everything they require to achieve those goals. 4. Ditto (3), but for ASN32. 5. Peering game players and associated suppliers/enablers/profiteers would be able to extend the current round of AS-centered games indefinitely into the future -- or at least until someone determines the next new realm into which the game will be extended. Oh, and the vanity number-thing. Given the adverse impact that this proposed change is very very likely to have just *within* this industry, there shouldn't be any need to speculate about the numerous layer 8+ implications of each of the above -- but I encourage anyone who has any lingering doubts to think each threat vector through on their own. Opposed (!), TV On Mar 14, 2012, at 11:07 AM, ARIN wrote: > Draft Policy ARIN-2012-3 > ASN Transfers > > On 8 March 2012 the ARIN Advisory Council (AC) selected "ASN Transfers" as a draft policy for adoption discussion on the PPML and at the Public Policy Meeting in Vancouver in April. > > The draft was developed by the AC from policy proposal "ARIN-prop-157 Section 8.3 Simplification." Per the Policy Development Process the AC submitted text to ARIN for a staff and legal assessment prior to its selection as a draft policy. Below the draft policy is the ARIN staff and legal assessment, followed by the text that was submitted by the AC. > > Draft Policy ARIN-2012-3 is below and can be found at: > https://www.arin.net/policy/proposals/2012_3.html > > You are encouraged to discuss Draft Policy 2012-3 on the PPML prior to > the April Public Policy Meeting. Both the discussion on the list and > at the meeting will be used by the ARIN Advisory Council to determine > the community consensus for adopting this as policy. > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy ARIN-2012-3 > ASN Transfers > > Date: 14 March 2012 > > Policy statement: > > In NRPM 8.3, replace "IPv4 number resources" with "IPv4 number resources and ASNs". > > Rationale: > > There are legitimate use cases for transferring ASNs, and no significant downsides (identified to date) of allowing it. > > Timetable for implementation: Immediate > > > ########## > > > ARIN STAFF ASSESSMENT > > Draft Policy: Proposal 157 ?ASN Transfers? > Date of Assessment: 23 Feb 2012 > > 1. Proposal Summary (Staff Understanding) > > This proposal would allow organizations to transfer ASNs in addition to IPv4 address space in an 8.3 transfer to specified recipients. > > 2. Comments > > A. ARIN Staff Comments > > ? If implemented as written, the 24-month utilization requirement in 8.3 would not apply to ASN requests since 8.3 clearly says ?how the addresses will be utilized in 24 months?. Staff would apply the current ASN policy, which requires an organization to be multi-homed or to immediately become multi-homed. > > B. ARIN General Counsel > > This creates no legal concerns and may actually facilitate any bankruptcy proceedings where ASNs are involved. > > 3. Resource Impact > > This policy would have minimum 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 > > 4. Proposal Text > > Policy statement: > > In NRPM 8.3, replace "IPv4 number resources" with "IPv4 number resources and ASNs". > > Rationale: > There are legitimate use cases for transferring ASNs, and no significant downsides (identified to date) of allowing it. > 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 Fri Mar 16 14:40:31 2012 From: farmer at umn.edu (David Farmer) Date: Fri, 16 Mar 2012 13:40:31 -0500 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> References: <4F60B42E.9040101@arin.net> <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> Message-ID: <4F63891F.7010005@umn.edu> On 3/16/12 10:11 CDT, Tom Vest wrote: > 3. Entities that would not be unhappy to see SIDR/RPKI fail > absolutely and/or to succeed primarily in turning the current > industry pecking order into a perpetual, insurmountable reputation > hierarchy -- where no amount of good of behavior can ever be truly > reassuring (if you're a new entrant), and no instance of bad behavior > need ever tarnish one's own reputation (if you're an incumbent > operator) -- would have everything they require to achieve those > goals. I'd be interested in more details on the risks you see ASN transfers creating for RPKI. Would such risks to RPKI associated with ASN transfers be any different than ARIN reassigning an ASN that was returned to it or that ARIN reclaimed? Are you saying that ASNs are suppose to be both globally and eternally unique? I'm not saying I'd be opposed to ASNs being eternally unique, but I didn't know it was a requirement, especially of RPKI. Thanks -- =============================================== 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 owen at delong.com Fri Mar 16 15:13:58 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 16 Mar 2012 12:13:58 -0700 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: <4F63891F.7010005@umn.edu> References: <4F60B42E.9040101@arin.net> <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> <4F63891F.7010005@umn.edu> Message-ID: <199FAA5B-A4C0-46FD-819E-DC7D969B4D93@delong.com> Given the lack of good revocation procedures for certificates and the fact that even when good revocation procedures have been available, they tend not to get used, having ASNs milling about with multiple possibly legitimate-looking signers would, in fact, reduce the usefulness of RPKI. Owen On Mar 16, 2012, at 11:40 AM, David Farmer wrote: > > On 3/16/12 10:11 CDT, Tom Vest wrote: > >> 3. Entities that would not be unhappy to see SIDR/RPKI fail >> absolutely and/or to succeed primarily in turning the current >> industry pecking order into a perpetual, insurmountable reputation >> hierarchy -- where no amount of good of behavior can ever be truly >> reassuring (if you're a new entrant), and no instance of bad behavior >> need ever tarnish one's own reputation (if you're an incumbent >> operator) -- would have everything they require to achieve those >> goals. > > I'd be interested in more details on the risks you see ASN transfers creating for RPKI. > > Would such risks to RPKI associated with ASN transfers be any different than ARIN reassigning an ASN that was returned to it or that ARIN reclaimed? > > Are you saying that ASNs are suppose to be both globally and eternally unique? > > I'm not saying I'd be opposed to ASNs being eternally unique, but I didn't know it was a requirement, especially of RPKI. > > Thanks > -- > =============================================== > 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 cgrundemann at gmail.com Fri Mar 16 15:32:38 2012 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 16 Mar 2012 13:32:38 -0600 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: <4F6282A0.5070404@chl.com> References: <4F60B42E.9040101@arin.net> <4F6282A0.5070404@chl.com> Message-ID: On Thu, Mar 15, 2012 at 18:00, Joe Maimon wrote: > > > Chris Grundemann wrote: > > >> So we have: >> 1) Aesthetics >> 2) Deception >> > > As I personally believe that is all shared transition space really has going > for it, I dont underestimate the appeal of either. ZING! Thanks for pointing out the 4-byte ASN issue earlier Joe, I forgot to include that myself. To the rest: I won't pollute this list with discussion of an already adopted policy except to point you to where I, along with several others, previously documented the rationale for shared transition space: https://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space. Hopefully you never need to deploy CGN, if you do - no thank you is necessary. ;) Cheers, ~Chris > Joe -- @ChrisGrundemann http://chrisgrundemann.com From tvest at eyeconomics.com Fri Mar 16 17:23:00 2012 From: tvest at eyeconomics.com (Tom Vest) Date: Fri, 16 Mar 2012 17:23:00 -0400 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: <4F63891F.7010005@umn.edu> References: <4F60B42E.9040101@arin.net> <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> <4F63891F.7010005@umn.edu> Message-ID: <4AB26D9E-56D2-47EC-8CE2-1352F0D7580C@eyeconomics.com> On Mar 16, 2012, at 2:40 PM, David Farmer wrote: > On 3/16/12 10:11 CDT, Tom Vest wrote: > >> 3. Entities that would not be unhappy to see SIDR/RPKI fail >> absolutely and/or to succeed primarily in turning the current >> industry pecking order into a perpetual, insurmountable reputation >> hierarchy -- where no amount of good of behavior can ever be truly >> reassuring (if you're a new entrant), and no instance of bad behavior >> need ever tarnish one's own reputation (if you're an incumbent >> operator) -- would have everything they require to achieve those >> goals. > > I'd be interested in more details on the risks you see ASN transfers creating for RPKI. > > Would such risks to RPKI associated with ASN transfers be any different than ARIN reassigning an ASN that was returned to it or that ARIN reclaimed? > > Are you saying that ASNs are suppose to be both globally and eternally unique? > > I'm not saying I'd be opposed to ASNs being eternally unique, but I didn't know it was a requirement, especially of RPKI. > > Thanks > -- Hi David, The risk would be to the value of the information that RPKI provides to (any/all) non-peers, and at least potentially to direct peers as well (as I believe Chris alluded to earlier this week). The knowledge that route (a) was originated by AS (x) is only meaningful insofar as one has some set of high-confidence beliefs/expectations about AS (x). However, if AS (x) can change hands at will, henceforth no such confidence will be possible for the overwhelming majority if not all ASes. It seems to me that the community has embraced an adaptation strategy involving IPv4 transfers in part because of "extremely optimistic" assumptions about the power of (some combination of) self-interest, passive administrative mechanisms, and esp. operational discovery capabilities to mitigate the inevitable consequences of market speculation -- including the escalating likelihood that some resources will change hands operationally without much (or any) public disclosure -- with RPKI playing a big role in boosting confidence about the latter. However, whatever confidence that RPKI may provide is & has always been founded on the (mostly unacknowledged) assumptions that (a) one would actually know who/what a particular AS represents (or how it is likely to behave, which has the same implications) -- and that (b) that knowledge would not/could not be invalidated without producing some operationally detectable "telltale sign." A bilaterally negotiated transfer of a routed IPv4 prefix along with its current origin-AS might not leave any such operational trace, and could go undetected for a long time. TV From jrhett at netconsonance.com Tue Mar 20 16:48:21 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Tue, 20 Mar 2012 13:48:21 -0700 Subject: [arin-ppml] 4-Byte ASN's in the ARIN region... In-Reply-To: References: <17F1F66E-1792-4ED4-AEF6-AC94B593DEBA@corp.arin.net> Message-ID: <7D8EB831-D807-402F-8E89-C4D7B8CACD9E@netconsonance.com> On Mar 15, 2012, at 12:11 PM, Jeff Wheeler wrote: > I still find it common for transit providers to react with a "we don't > support..." and similar. I suppose they will stop doing this when > their customers are no longer able to get a 2 byte ASN because they > have been exhausted, or when two or three more years go by and > substantially all non-supporting routers/software has finally reached > the end of its useful life. ?. > If there was a way to modify current ARIN policy or practice so that > networks could not exchange a 4 byte ASN for a 2 byte ASN unless they > were connecting to an IXP, I think that would encourage the remaining > networks who have not supported 4 byte ASN to do so, while also not > penalizing folks who participate in peering at public exchanges where > there remain some legitimate technical problems. Jeff, I would like to point out that due to operator stupidity, this would have a direct cost to customers. If only two providers can provide transit for a location, and neither one is willing to accept 4-byte ASNs then my only way to control my announcements would be to purchase another company that owns a two-byte ASN. Stupid, absolutely. Unfortunately true, and I have recently been in this exact scenario which forced us to return a 4-byte ASN. In short, I don't think you can put pressure on the end customer. You have to put pressure on the providers, and I'm not sure what mechanism ARIN has to do that. The only place it can be applied would be to require anyone getting new IP allocations for reassignment to assert that they support 4-byte ASN customers, which I would absolutely support. I'm just not certain that it would affect enough of the market to make a difference. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsw at inconcepts.biz Tue Mar 20 18:48:07 2012 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Tue, 20 Mar 2012 18:48:07 -0400 Subject: [arin-ppml] 4-Byte ASN's in the ARIN region... In-Reply-To: <7D8EB831-D807-402F-8E89-C4D7B8CACD9E@netconsonance.com> References: <17F1F66E-1792-4ED4-AEF6-AC94B593DEBA@corp.arin.net> <7D8EB831-D807-402F-8E89-C4D7B8CACD9E@netconsonance.com> Message-ID: On Tue, Mar 20, 2012 at 4:48 PM, Jo Rhett wrote: > Jeff, I would like to point out that due to operator stupidity, this would > have a direct cost to customers. ?If only two providers can provide transit > for a location, and neither one is willing to accept 4-byte ASNs then my You can be AS23456. Also, it really is not an "operator stupidity" problem. Anyone who didn't think we needed to expand the ASN space in the 90s must not have been in this field in the 90s. Yet it took vendors 10+ years, depending on how you look at it, to get this done. This is par for the course in our industry. > In short, I don't think you can put pressure on the end customer. You have > to put pressure on the providers, and I'm not sure what mechanism ARIN has > to do that. ?The only place it can be applied would be to require anyone If new networks are no longer able to get 2-byte ASNs, two things will happen pretty quickly. Most remaining SPs will support 4-byte ASNs very rapidly, because they will lose out on new customers if they don't. Second, folks in your position will be more willing to do ugly work-arounds (because they won't have another choice.) None of this is good. I'm just answering John's question that the reason adoption is so poor in the ARIN region is because there is still no urgency. As long as customers can go back to ARIN and swap a 4-byte ASN for a 2-byte ASN they will continue to do so, thus ISPs will not accelerate their adoption efforts. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From kevinb at thewire.ca Wed Mar 21 20:11:47 2012 From: kevinb at thewire.ca (Kevin Blumberg) Date: Thu, 22 Mar 2012 00:11:47 +0000 Subject: [arin-ppml] Inital ISP IPv6 Allocation Policy Question Message-ID: <7E7773B523E82C478734E793E58F69E7694CCB8F@SBS2011.thewireinc.local> I wanted to get some feedback from the community on the following section of the NRPM. 6.5.2.2. Qualifications An organization qualifies for an allocation under this policy if they meet any of the following criteria: 1. Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria. In my mind this text would allow for ARIN, to setup a fast track button on ARIN online, to give an existing IPv4 member a new allocation without any further justification. Is that how other's read this text, is there any other text that you believe would contradict my statement? Thanks, Kevin Blumberg From scottleibrand at gmail.com Wed Mar 21 20:18:31 2012 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 21 Mar 2012 17:18:31 -0700 Subject: [arin-ppml] Inital ISP IPv6 Allocation Policy Question In-Reply-To: <7E7773B523E82C478734E793E58F69E7694CCB8F@SBS2011.thewireinc.local> References: <7E7773B523E82C478734E793E58F69E7694CCB8F@SBS2011.thewireinc.local> Message-ID: Yes, that was the intent when we adopted this text: to make it way easier for existing IPv4 holders to get IPv6 allocations. Similarly, for end user assignments: 6.5.8.1. Initial Assignment Criteria Organizations may justify an initial assignment for addressing devices directly attached to their own network infrastructure, with an intent for the addresses to begin operational use within 12 months, by meeting one of the following criteria: Having a previously justified IPv4 end-user assignment from ARIN or one of its predecessor registries, or; ... Do I hear an ACSP suggestion behind your question? :-) -Scott On Wed, Mar 21, 2012 at 5:11 PM, Kevin Blumberg wrote: > I wanted to get some feedback from the community on the following section of the NRPM. > > 6.5.2.2. Qualifications > > An organization qualifies for an allocation under this policy if they meet any of the following criteria: > 1. Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria. > > In my mind this text would allow for ARIN, to setup a fast track button on ARIN online, to give an existing IPv4 member a new allocation without any > further justification. Is that how other's read this text, is there any other text that you believe would contradict my statement? > > Thanks, > > Kevin Blumberg > > > > > > > _______________________________________________ > 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 21 21:50:20 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 21 Mar 2012 18:50:20 -0700 Subject: [arin-ppml] Inital ISP IPv6 Allocation Policy Question In-Reply-To: <7E7773B523E82C478734E793E58F69E7694CCB8F@SBS2011.thewireinc.local> References: <7E7773B523E82C478734E793E58F69E7694CCB8F@SBS2011.thewireinc.local> Message-ID: On Mar 21, 2012, at 5:11 PM, Kevin Blumberg wrote: > I wanted to get some feedback from the community on the following section of the NRPM. > > 6.5.2.2. Qualifications > > An organization qualifies for an allocation under this policy if they meet any of the following criteria: > 1. Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria. > > In my mind this text would allow for ARIN, to setup a fast track button on ARIN online, to give an existing IPv4 member a new allocation without any > further justification. Is that how other's read this text, is there any other text that you believe would contradict my statement? > Sort of yes and sort of no. They would still need to evaluate their IPv6 need in terms of determining a prefix size if the provider wanted something other than a /32. Since most providers will likely need something larger than a /32, I'm not a big fan of the idea of setting up an APNIC-Like Easy IPv6 "Push here for a /32" button. Owen From heather.skanks at gmail.com Thu Mar 22 00:38:51 2012 From: heather.skanks at gmail.com (Heather Schiller) Date: Thu, 22 Mar 2012 00:38:51 -0400 Subject: [arin-ppml] Inital ISP IPv6 Allocation Policy Question In-Reply-To: References: <7E7773B523E82C478734E793E58F69E7694CCB8F@SBS2011.thewireinc.local> Message-ID: On Wed, Mar 21, 2012 at 9:50 PM, Owen DeLong wrote: > > On Mar 21, 2012, at 5:11 PM, Kevin Blumberg wrote: > >> I wanted to get some feedback from the community on the following section of the NRPM. >> >> 6.5.2.2. Qualifications >> >> An organization qualifies for an allocation under this policy if they meet any of the following criteria: >> 1. Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria. >> >> In my mind this text would allow for ARIN, to setup a fast track button on ARIN online, to give an existing IPv4 member a new allocation without any >> further justification. Is that how other's read this text, is there any other text that you believe would contradict my statement? >> > > Sort of yes and sort of no. They would still need to evaluate their IPv6 need in terms of determining a prefix size if the provider wanted something other than a /32. Since most providers will likely need something larger than a ?/32, I'm not a big fan of the idea of setting up an APNIC-Like Easy IPv6 "Push here for a /32" button. > With a big fat warning button? Maybe if they have v4 prefix > x they get a warning to strongly consider requesting a larger v6 block and not using the easy button. The potential downside is that a lot of folks have multiple org id's/accounts - and may end up getting multiple v6 blocks when it might not be necessary. No need to replicate the shortcomings of v4 subnetting/design into v6. > Owen > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From farmer at umn.edu Thu Mar 22 00:41:21 2012 From: farmer at umn.edu (David Farmer) Date: Wed, 21 Mar 2012 23:41:21 -0500 Subject: [arin-ppml] Inital ISP IPv6 Allocation Policy Question In-Reply-To: References: <7E7773B523E82C478734E793E58F69E7694CCB8F@SBS2011.thewireinc.local> Message-ID: <4F6AAD71.9080902@umn.edu> On 3/21/12 20:50 CDT, Owen DeLong wrote: > On Mar 21, 2012, at 5:11 PM, Kevin Blumberg wrote: > >> I wanted to get some feedback from the community on the following section of the NRPM. >> >> 6.5.2.2. Qualifications >> >> An organization qualifies for an allocation under this policy if they meet any of the following criteria: >> 1. Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria. >> >> In my mind this text would allow for ARIN, to setup a fast track button on ARIN online, to give an existing IPv4 member a new allocation without any >> further justification. Is that how other's read this text, is there any other text that you believe would contradict my statement? >> > > Sort of yes and sort of no. They would still need to evaluate their IPv6 need in terms of determining a prefix size if the provider wanted something other than a /32. Since most providers will likely need something larger than a /32, I'm not a big fan of the idea of setting up an APNIC-Like Easy IPv6 "Push here for a /32" button. Heather beat me to the punch, but I fleshed it out a bit more. And, I agree with the warning button. I tend to agree with the objection to just proving a one click for a /32, as it will not serve many providers very well. However, what if we created a policy allowing for an even more simplified justification for larger IPv6 allocations based on a providers total IPv4 allocations. Something like; if a ISP has an equilivant of a total /15 or more of IPv4, they need no additional justification to receive /28, and if they have a /9 or more they need on additional justification to receive /24, more than a /24 requires a complete justification. Similarly, we could provider end-users a simplified justification for IPv6 assignments as well. End-users with than a /18 or more of IPv4 automatically qualify for a /44 of IPv6, or more than a /15 they automatically qualify for a /44, more than a /44 requires a complete justification. Because there will probably be a financial impact, it should be implemented with maybe two clicks, for a provider select from /36, /32, /28, and /24, allowing the appropriate options base on a providers total IPv4 allocation. This would probably allow an 80/20 rule to come in to play and provide for web page for IPv6 allocations appropriate for more than 80% of ARIN members. The /18, /15, and /9 are just examples, you would want to look at a histogram of total IPv4 allocations by organization, before actually picking the cut-offs, but I think those may be at least in the ballpark. -- =============================================== 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 owen at delong.com Thu Mar 22 01:19:18 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 21 Mar 2012 22:19:18 -0700 Subject: [arin-ppml] Inital ISP IPv6 Allocation Policy Question In-Reply-To: <4F6AAD71.9080902@umn.edu> References: <7E7773B523E82C478734E793E58F69E7694CCB8F@SBS2011.thewireinc.local> <4F6AAD71.9080902@umn.edu> Message-ID: On Mar 21, 2012, at 9:41 PM, David Farmer wrote: > > > On 3/21/12 20:50 CDT, Owen DeLong wrote: >> On Mar 21, 2012, at 5:11 PM, Kevin Blumberg wrote: >> >>> I wanted to get some feedback from the community on the following section of the NRPM. >>> >>> 6.5.2.2. Qualifications >>> >>> An organization qualifies for an allocation under this policy if they meet any of the following criteria: >>> 1. Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria. >>> >>> In my mind this text would allow for ARIN, to setup a fast track button on ARIN online, to give an existing IPv4 member a new allocation without any >>> further justification. Is that how other's read this text, is there any other text that you believe would contradict my statement? >>> >> >> Sort of yes and sort of no. They would still need to evaluate their IPv6 need in terms of determining a prefix size if the provider wanted something other than a /32. Since most providers will likely need something larger than a /32, I'm not a big fan of the idea of setting up an APNIC-Like Easy IPv6 "Push here for a /32" button. > > Heather beat me to the punch, but I fleshed it out a bit more. And, I agree with the warning button. > > I tend to agree with the objection to just proving a one click for a /32, as it will not serve many providers very well. However, what if we created a policy allowing for an even more simplified justification for larger IPv6 allocations based on a providers total IPv4 allocations. > > Something like; if a ISP has an equilivant of a total /15 or more of IPv4, they need no additional justification to receive /28, and if they have a /9 or more they need on additional justification to receive /24, more than a /24 requires a complete justification. > > Similarly, we could provider end-users a simplified justification for IPv6 assignments as well. End-users with than a /18 or more of IPv4 automatically qualify for a /44 of IPv6, or more than a /15 they automatically qualify for a /44, more than a /44 requires a complete justification. > > Because there will probably be a financial impact, it should be implemented with maybe two clicks, for a provider select from /36, /32, /28, and /24, allowing the appropriate options base on a providers total IPv4 allocation. This would probably allow an 80/20 rule to come in to play and provide for web page for IPv6 allocations appropriate for more than 80% of ARIN members. > > The /18, /15, and /9 are just examples, you would want to look at a histogram of total IPv4 allocations by organization, before actually picking the cut-offs, but I think those may be at least in the ballpark. > It just doesn't map that well. I've been through just about every exercise possible in terms of how much IPv6 space should equal how much IPv4 space and the answer always works out to "it depends". Sure, you can come up with rules of thumb that fit a limited constrained set of possible environments, but, that's not what ARIN deals with. When you look for something that has to fit residential, business, backbone, colo, etc. providers and then multiply it by the number of variations in each space, there's really no formulaic mapping function that actually works. At least none that I've been able to find. The current IPv6 justification process really is pretty simple. It took me less than 30 minutes to put all the data together and submit the form through ARIN online (25 of the 30 minutes... Gawd I miss simple easy to use templates). It took ARIN less than 24 hours to approve the request. There was a brief delay for the officer attestation and I wouldn't mind providing an attestation waiver for IPv4 subscribers getting their first IPv6 allocation. This was fora subsequent IPv6 allocation for a /24 based on our actual need and utilization of our existing /32 rather than an initial allocation, but, frankly, an initial allocation would have been even easier as it would not have required existing IPv6 utilization data. Here's a simple flow for preparing a request under the current rules: 1. How many end sites are served by your largest aggregation point? (Let this answer be A) 2. How many aggregation points do you expect to have in the next 5 years? (Let this answer be P) Find a number n such that (n%4==0) && (2^n > 4P/3). Find a number o such that (o%4==0) && (2^n > 4A/3). X = 48 - (n+o) [see note 1] 3. Request a /X Someone even posted a .XLS template for doing this to PPML as part of the discussion of the current policy. Owen [note 1] 48 applies only if your PAU is /48 or shorter. If you assign something longer than a /48 (e.g. /56, /60, /64) to any of your customers, then your PAU is the smallest block you assign to a customer end site. Use that number in place of /48. For example, if you are a residential provider and provide /64s to your residential customers, then your PAU is /64 and you should use 64 in place of 48 in the above formula. From owen at delong.com Thu Mar 22 01:41:21 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 21 Mar 2012 22:41:21 -0700 Subject: [arin-ppml] Inital ISP IPv6 Allocation Policy Question In-Reply-To: References: <7E7773B523E82C478734E793E58F69E7694CCB8F@SBS2011.thewireinc.local> Message-ID: <52A4F883-5BDD-464F-8752-0B538F04936A@delong.com> On Mar 21, 2012, at 9:38 PM, Heather Schiller wrote: > On Wed, Mar 21, 2012 at 9:50 PM, Owen DeLong wrote: >> >> On Mar 21, 2012, at 5:11 PM, Kevin Blumberg wrote: >> >>> I wanted to get some feedback from the community on the following section of the NRPM. >>> >>> 6.5.2.2. Qualifications >>> >>> An organization qualifies for an allocation under this policy if they meet any of the following criteria: >>> 1. Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria. >>> >>> In my mind this text would allow for ARIN, to setup a fast track button on ARIN online, to give an existing IPv4 member a new allocation without any >>> further justification. Is that how other's read this text, is there any other text that you believe would contradict my statement? >>> >> >> Sort of yes and sort of no. They would still need to evaluate their IPv6 need in terms of determining a prefix size if the provider wanted something other than a /32. Since most providers will likely need something larger than a /32, I'm not a big fan of the idea of setting up an APNIC-Like Easy IPv6 "Push here for a /32" button. >> > > With a big fat warning button? Maybe if they have v4 prefix > x they > get a warning to strongly consider requesting a larger v6 block and > not using the easy button. > > The potential downside is that a lot of folks have multiple org > id's/accounts - and may end up getting multiple v6 blocks when it > might not be necessary. No need to replicate the shortcomings of v4 > subnetting/design into v6. > Which is why I believe that the process is as easy as it needs to be. I really don't think that the process is keeping anyone from deploying IPv6 at this point. If anyone thinks otherwise, I would very much like to hear a more detailed explanation of how that is. Owen From info at arin.net Thu Mar 22 14:48:55 2012 From: info at arin.net (ARIN) Date: Thu, 22 Mar 2012 14:48:55 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - March 2012 In-Reply-To: <4F5FA20D.8070201@arin.net> References: <4F5FA20D.8070201@arin.net> Message-ID: <4F6B7417.8060503@arin.net> > The deadline to begin a petition will be five business days after the > AC's draft meeting minutes are published. Note that in order for a > petition of any of the proposals to be considered successful for the > upcoming ARIN XXIX meeting, the petition must be concluded by 18 March > 2012 in order to meet the requirement of posting as draft policy at > least 35 days prior to the meeting. The minutes from the ARIN Advisory Council's meeting of 8 March 2012 have been published to the ARIN website and are available at: https://www.arin.net/about_us/ac/index.html The petition deadline is 29 March 2012. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) On 3/13/12 3:37 PM, ARIN wrote: > In accordance with the ARIN Policy Development Process, the ARIN > Advisory Council (AC) held a meeting on 8 March 2012 and made > decisions about several proposals. > > The AC selected the following proposals as draft policies for adoption > discussion online and at the ARIN XXIX Public Policy Meeting in > Vancouver in April. The draft policies will be posted shortly to the > PPML. > > ARIN-prop-157 Section 8.3 Simplification > ARIN-prop-162 Redefining request window in 4.2.4.4 > > The AC abandoned the following proposal: > > ARIN-prop-165 Eliminate Needs-Based Justification on 8.3 Specified > Transfers > > The AC provided the following statement about prop-165: > "Based on significant community opposition to the removal of the needs > requirement in 8.3 transfers, the AC chose to abandon proposal 165. > While the author has brought to light privately additional issues, > most of them are procedural in nature and would require a complete > rewrite of both the policy and rationale text well beyond the original > proposal's intent. The AC feels that there is merit in the discussion > of these issues, and suggests that the author look at more specific > issues outside of removal of needs, that could be applied to new > proposal submissions." > > The AC thanks the authors and the community for their continuing effort > and contributions to these and all other policy considerations. > > The AC abandoned proposal 165. The AC is advancing draft policy text > for proposals 157 and 162 that differs from the original proposal > texts. Anyone dissatisfied with these decisions may initiate a > petition. The petition to advance these proposals is the "Discussion > Petition." The deadline to begin a petition will be five business days > after the AC's draft meeting minutes are published. Note that in order > for a petition of any of the proposals to be considered successful for > the upcoming ARIN XXIX meeting, the petition must be concluded by 18 > March 2012 in order to meet the requirement of posting as draft policy > at least 35 days prior to the meeting. If you are considering > petitioning, starting one early is better than later. > > For more information on starting and participating in petitions, see > PDP Petitions at: > https://www.arin.net/policy/pdp_petitions.html > > Draft Policy and 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 narten at us.ibm.com Fri Mar 23 00:53:02 2012 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 23 Mar 2012 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201203230453.q2N4r2QB029562@rotala.raleigh.ibm.com> Total of 16 messages in the last 7 days. script run at: Fri Mar 23 00:53:02 EDT 2012 Messages | Bytes | Who --------+------+--------+----------+------------------------ 25.00% | 4 | 25.43% | 31399 | owen at delong.com 12.50% | 2 | 14.26% | 17606 | tvest at eyeconomics.com 12.50% | 2 | 13.15% | 16237 | farmer at umn.edu 6.25% | 1 | 8.69% | 10731 | jrhett at netconsonance.com 6.25% | 1 | 6.19% | 7646 | info at arin.net 6.25% | 1 | 5.88% | 7255 | heather.skanks at gmail.com 6.25% | 1 | 5.81% | 7178 | narten at us.ibm.com 6.25% | 1 | 5.76% | 7107 | jsw at inconcepts.biz 6.25% | 1 | 5.65% | 6980 | scottleibrand at gmail.com 6.25% | 1 | 4.95% | 6108 | cgrundemann at gmail.com 6.25% | 1 | 4.23% | 5222 | kevinb at thewire.ca --------+------+--------+----------+------------------------ 100.00% | 16 |100.00% | 123469 | Total From hannigan at gmail.com Fri Mar 23 12:15:44 2012 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 23 Mar 2012 12:15:44 -0400 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: <4AB26D9E-56D2-47EC-8CE2-1352F0D7580C@eyeconomics.com> References: <4F60B42E.9040101@arin.net> <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> <4F63891F.7010005@umn.edu> <4AB26D9E-56D2-47EC-8CE2-1352F0D7580C@eyeconomics.com> Message-ID: On Fri, Mar 16, 2012 at 5:23 PM, Tom Vest wrote: > > On Mar 16, 2012, at 2:40 PM, David Farmer wrote: > >> On 3/16/12 10:11 CDT, Tom Vest wrote: >> >>> 3. Entities that would not be unhappy to see SIDR/RPKI fail >>> absolutely and/or to succeed primarily in turning the current >>> industry pecking order into a perpetual, insurmountable reputation >>> hierarchy -- where no amount of good of behavior can ever be truly >>> reassuring (if you're a new entrant), and no instance of bad behavior >>> need ever tarnish one's own reputation (if you're an incumbent >>> operator) -- would have everything they require to achieve those >>> goals. >> >> I'd be interested in more details on the risks you see ASN transfers creating for RPKI. >> >> Would such risks to RPKI associated with ASN transfers be any different than ARIN reassigning an ASN that was returned to it or that ARIN reclaimed? >> >> Are you saying that ASNs are suppose to be both globally and eternally unique? >> >> I'm not saying I'd be opposed to ASNs being eternally unique, but I didn't know it was a requirement, especially of RPKI. >> >> Thanks >> -- > > Hi David, > > The risk would be to the value of the information that RPKI provides to (any/all) non-peers, and at least potentially to direct peers as well (as I believe Chris alluded to earlier this week). The knowledge that route (a) was originated by AS (x) is only meaningful insofar as one has some set of high-confidence beliefs/expectations about AS (x). However, if AS (x) can change hands at will, henceforth no such confidence will be possible for the overwhelming majority if not all ASes. > If the ASN was transferred and trust mechanisms were implemented, wouldn't the trust chain break? I don't quite understand what the problem you are describing actually is. If someone transfers an ASN to "steal" peering, it would take a lot more work than just that. At a very high level, the entire relationship would change and probably dramatically from what it was before the transfer. How about a real world example of how transferring an ASN has hurt someone? Best, -M< From gary.buhrmaster at gmail.com Fri Mar 23 14:16:26 2012 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Fri, 23 Mar 2012 18:16:26 +0000 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: <4AB26D9E-56D2-47EC-8CE2-1352F0D7580C@eyeconomics.com> References: <4F60B42E.9040101@arin.net> <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> <4F63891F.7010005@umn.edu> <4AB26D9E-56D2-47EC-8CE2-1352F0D7580C@eyeconomics.com> Message-ID: On Fri, Mar 16, 2012 at 21:23, Tom Vest wrote: .... > The risk would be to the value of the information that RPKI provides to (any/all) non-peers, and at least potentially to direct peers as well (as I believe Chris alluded to earlier this week). The knowledge that route (a) was originated by AS (x) is only meaningful insofar as one has some set of high-confidence beliefs/expectations about AS (x). However, if AS (x) can change hands at will, henceforth no such confidence will be possible for the overwhelming majority if not all ASes. So, what I am hearing the RPKI experts say, is that ASNs (at least from some point moving forward) might need to be eternally unique, and that in (all?) cases of mergers, acquisitions, and/or bankrupcy transfers of numbers, ARIN should issue a new ASN in exchange (with some period of overlap, presumably) in order that reputation is not migrated. Also, presumably, the (new) ASN should be issued by ARIN without an additional needs review (it is an exchange in the best interests of the (RPKI) community, not a new request). Is this a correct characterization of the RPKI experts opinions? Gary From hannigan at gmail.com Fri Mar 23 14:22:42 2012 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 23 Mar 2012 14:22:42 -0400 Subject: [arin-ppml] Fwd: ARIN-prop-165 Eliminate Needs-Based Justification In-Reply-To: References: <90100EA6-CA1C-4F38-9D4A-AF6CC1C661C1@corp.arin.net> <85F403CE-6828-4D10-BB4B-3345929DAD80@eyeconomics.com> <2A1E9EA1-7D44-4A3E-87AB-A86EAB2FFAA6@eyeconomics.com> <6FBFA779-0ACA-48C9-82A7-4F1BFAA9A7C0@delong.com> <6A72B49C-4E38-497D-9CE5-0EEA63478289@netconsonance.com> Message-ID: On Tue, Feb 28, 2012 at 7:03 PM, Matthew Petach wrote: > On Tue, Feb 28, 2012 at 11:48 AM, Jo Rhett wrote: >> On Feb 28, 2012, at 10:53 AM, Matthew Petach wrote: >> [ clip ] >> >> Um, no. The current policy is to focus on the need for space, which is in >> fact what ARIN is directed to deal with. > > I guess I should simply be happy that the term "need" is > sufficiently vague to allow anyone to apply for IP space > based on their stated "need" for it, whether or not that > "need" translates into real-world usage, as it seems > it can be sufficient to "need" it for an internal network > not visible to the rest of the internet. Agreed. It's also sufficiently vague enough to add instability and undermine trust in some of the IPv4 marketplaces. I support the elimination of needs based justification. From farmer at umn.edu Fri Mar 23 14:41:33 2012 From: farmer at umn.edu (David Farmer) Date: Fri, 23 Mar 2012 13:41:33 -0500 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: References: <4F60B42E.9040101@arin.net> <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> <4F63891F.7010005@umn.edu> <4AB26D9E-56D2-47EC-8CE2-1352F0D7580C@eyeconomics.com> Message-ID: <4F6CC3DD.6060308@umn.edu> On 3/23/12 13:16 CDT, Gary Buhrmaster wrote: > On Fri, Mar 16, 2012 at 21:23, Tom Vest wrote: > .... >> The risk would be to the value of the information that RPKI provides to (any/all) non-peers, and at least potentially to direct peers as well (as I believe Chris alluded to earlier this week). The knowledge that route (a) was originated by AS (x) is only meaningful insofar as one has some set of high-confidence beliefs/expectations about AS (x). However, if AS (x) can change hands at will, henceforth no such confidence will be possible for the overwhelming majority if not all ASes. > > So, what I am hearing the RPKI experts say, is that ASNs (at least > from some point moving forward) might need to be eternally unique, > and that in (all?) cases of mergers, acquisitions, and/or bankrupcy transfers > of numbers, ARIN should issue a new ASN in exchange (with some > period of overlap, presumably) in order that reputation is not migrated. > Also, presumably, the (new) ASN should be issued by ARIN without > an additional needs review (it is an exchange in the best interests > of the (RPKI) community, not a new request). I think that is what was said. However, I'm not sure Owen or Tom classify themselves as RPKI experts, please correct me if I'm wrong. And, if I'm wrong, I apologize. Further, this is the first I heard of this being an issue, it's never been brought up in any of the several RKPI talks I've been to. > Is this a correct characterization of the RPKI experts opinions? I would appreciate comments from RPKI experts on this issue. If ASN transfers actually create additional risk within RPKI, then that is something we need to consider. But I for one would like to have a much more detail description of the problem and/or a pointer to previous discussion of the issue. > Gary -- =============================================== 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 owen at delong.com Fri Mar 23 17:28:50 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 23 Mar 2012 14:28:50 -0700 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: <4F6CC3DD.6060308@umn.edu> References: <4F60B42E.9040101@arin.net> <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> <4F63891F.7010005@umn.edu> <4AB26D9E-56D2-47EC-8CE2-1352F0D7580C@eyeconomics.com> <4F6CC3DD.6060308@umn.edu> Message-ID: <079491F6-E442-4988-A068-AA27C13D36FF@delong.com> On Mar 23, 2012, at 11:41 AM, David Farmer wrote: > > On 3/23/12 13:16 CDT, Gary Buhrmaster wrote: >> On Fri, Mar 16, 2012 at 21:23, Tom Vest wrote: >> .... >>> The risk would be to the value of the information that RPKI provides to (any/all) non-peers, and at least potentially to direct peers as well (as I believe Chris alluded to earlier this week). The knowledge that route (a) was originated by AS (x) is only meaningful insofar as one has some set of high-confidence beliefs/expectations about AS (x). However, if AS (x) can change hands at will, henceforth no such confidence will be possible for the overwhelming majority if not all ASes. >> >> So, what I am hearing the RPKI experts say, is that ASNs (at least >> from some point moving forward) might need to be eternally unique, >> and that in (all?) cases of mergers, acquisitions, and/or bankrupcy transfers >> of numbers, ARIN should issue a new ASN in exchange (with some >> period of overlap, presumably) in order that reputation is not migrated. >> Also, presumably, the (new) ASN should be issued by ARIN without >> an additional needs review (it is an exchange in the best interests >> of the (RPKI) community, not a new request). > > > I think that is what was said. However, I'm not sure Owen or Tom classify themselves as RPKI experts, please correct me if I'm wrong. And, if I'm wrong, I apologize. Further, this is the first I heard of this being an issue, it's never been brought up in any of the several RKPI talks I've been to. > I don't classify myself as an RPKI expert, and I would say that Gary's concerns are additive to what Tom and I have expressed. I don't think that requiring ARIN to issue new ASNs will necessarily prevent ASN reputation hijacking, however, since you have the same revocation problem as the RPKI certificates... ASN validation would suffer from the same issues. Owen From tvest at eyeconomics.com Fri Mar 23 18:24:02 2012 From: tvest at eyeconomics.com (Tom Vest) Date: Fri, 23 Mar 2012 18:24:02 -0400 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: References: <4F60B42E.9040101@arin.net> <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> <4F63891F.7010005@umn.edu> <4AB26D9E-56D2-47EC-8CE2-1352F0D7580C@eyeconomics.com> Message-ID: <12AEFCDC-FE19-4483-9E0D-26B1D6D3BD16@eyeconomics.com> On Mar 23, 2012, at 12:15 PM, Martin Hannigan wrote: > On Fri, Mar 16, 2012 at 5:23 PM, Tom Vest wrote: >> >> On Mar 16, 2012, at 2:40 PM, David Farmer wrote: >> >>> On 3/16/12 10:11 CDT, Tom Vest wrote: >>> >>>> 3. Entities that would not be unhappy to see SIDR/RPKI fail >>>> absolutely and/or to succeed primarily in turning the current >>>> industry pecking order into a perpetual, insurmountable reputation >>>> hierarchy -- where no amount of good of behavior can ever be truly >>>> reassuring (if you're a new entrant), and no instance of bad behavior >>>> need ever tarnish one's own reputation (if you're an incumbent >>>> operator) -- would have everything they require to achieve those >>>> goals. >>> >>> I'd be interested in more details on the risks you see ASN transfers creating for RPKI. >>> >>> Would such risks to RPKI associated with ASN transfers be any different than ARIN reassigning an ASN that was returned to it or that ARIN reclaimed? >>> >>> Are you saying that ASNs are suppose to be both globally and eternally unique? >>> >>> I'm not saying I'd be opposed to ASNs being eternally unique, but I didn't know it was a requirement, especially of RPKI. >>> >>> Thanks >>> -- >> >> Hi David, >> >> The risk would be to the value of the information that RPKI provides to (any/all) non-peers, and at least potentially to direct peers as well (as I believe Chris alluded to earlier this week). The knowledge that route (a) was originated by AS (x) is only meaningful insofar as one has some set of high-confidence beliefs/expectations about AS (x). However, if AS (x) can change hands at will, henceforth no such confidence will be possible for the overwhelming majority if not all ASes. >> > > If the ASN was transferred and trust mechanisms were implemented, > wouldn't the trust chain break? Hi Marty, I'd like to respond to your question directly, but for that to be possible you'll first have to explain what you mean by "trust mechanisms." Without specifics it sort of sounds like the proverbial "dormitive principle." > I don't quite understand what the problem you are describing actually is. Proponents of market-based resource transfers frequently argue that "command and control mechanisms" (in this case meaning a majority of the RIR policy-engaged community themselves c. a couple of policy cycles in the past) are inferior to markets because they cannot anticipate all of the reasons why resource seekers might want/need to acquire resources. It's basically an argument for individual humility before a market that somehow "knows more" than individuals acting alone or groups of individuals voluntarily coordinating their actions -- allegedly even in cases where "the market" and "the voluntarily self-coordinating group" are identical in size and composition. The thing is, this argument for humility works both ways. So even if you don't know what sort of problems/exploits/vulnerabilities that AS transfers will create, you can rest assured that the market knows. > If someone transfers an ASN to "steal" peering, it would take a > lot more work than just that. Maybe it would take more work, eventually. Maybe not. Depends on what you mean by "steal" I guess. In general you might assume that landlords would have all sorts of reasons and opportunities to inform their tenants when they decide to sell their rental properties. Despite that, a quick Google search suggests that there are probably "millions" of cases involving property owners who are not entirely clear about their incentives/obligations in this area, and/or tenants who "didn't get the memo" until it was too late to avoid some nontrivial personal inconvenience, etc., as a result of some unforeseen equity event. There may be no physical "stealing" in most such cases, but there certainly seems to be quite a lot of allegedly tortious activity -- which invariably means that somebody's claiming to have suffered losses due to someone else's actions. Now, if we can come up with a "trust mechanism" for AS transfers that is as effective as black letter law + judicial system + continuous, consistent universal public visibility + armed LEA, we might very optimistically aspire to limit the frequency and impact of (invisible, ephemeral) AS-transfer related disputes to equivalent problem rates encountered in the market for (tangible, immovable, unmistakable) real property. Without (at least) an equivalent mechanism, the cumulative results are likely to start out ugly and only get uglier over time. > At a very high level, the entire > relationship would change and probably dramatically from what it was > before the transfer. So do you require your NOC staff to monitor dedicated video feeds for each and every one of your BGP links on a 24x7 basis (and also make the 24x7 visibility of some previously identified customer/peer/provider rep in each of those feeds as a mandatory condition of every peering agreement and interconnection deal you enter into)? Do your routers automatically detect and log changes in ownership status of the devices on the other side? Here's a riddle that (IMO) perfectly encapsulates the problem: Q: Practically speaking, what are the three most significant operational differences between an AS changing hands between two private parties and a BGP MITM attack? A: 1. A legally executed purchase agreement that you'll never see. 2. A buyer or seller-initiated registry update that may or may not have happened yet (or ever). 3. An aggrieved third party who might discover or be tipped off about the unauthorized spoofing of his/her AS -- which would only exist in a real MITM attack. > How about a real world example of how transferring an ASN has hurt someone? As you know, If I had any to share, I couldn't share 'em ;-) I've already shared several scenarios here and at various meetings a few years back, although none that is likely to cross the threshold separating "hypothetical" from "predictable" unless/until private AS transfers are actually sanctioned by the community. I just don't see how private, market-based AS transfers can be made to be feasible/sustainable as a general practice under current circumstances :-\ Regards, TV > Best, > > -M< From tvest at eyeconomics.com Fri Mar 23 20:04:18 2012 From: tvest at eyeconomics.com (Tom Vest) Date: Fri, 23 Mar 2012 20:04:18 -0400 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: <4F6CC3DD.6060308@umn.edu> References: <4F60B42E.9040101@arin.net> <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> <4F63891F.7010005@umn.edu> <4AB26D9E-56D2-47EC-8CE2-1352F0D7580C@eyeconomics.com> <4F6CC3DD.6060308@umn.edu> Message-ID: <003D1A60-9771-431F-B5E7-F73B0D8BFCB1@eyeconomics.com> On Mar 23, 2012, at 2:41 PM, David Farmer wrote: > > On 3/23/12 13:16 CDT, Gary Buhrmaster wrote: >> On Fri, Mar 16, 2012 at 21:23, Tom Vest wrote: >> .... >>> The risk would be to the value of the information that RPKI provides to (any/all) non-peers, and at least potentially to direct peers as well (as I believe Chris alluded to earlier this week). The knowledge that route (a) was originated by AS (x) is only meaningful insofar as one has some set of high-confidence beliefs/expectations about AS (x). However, if AS (x) can change hands at will, henceforth no such confidence will be possible for the overwhelming majority if not all ASes. >> >> So, what I am hearing the RPKI experts say, is that ASNs (at least >> from some point moving forward) might need to be eternally unique, >> and that in (all?) cases of mergers, acquisitions, and/or bankrupcy transfers >> of numbers, ARIN should issue a new ASN in exchange (with some >> period of overlap, presumably) in order that reputation is not migrated. >> Also, presumably, the (new) ASN should be issued by ARIN without >> an additional needs review (it is an exchange in the best interests >> of the (RPKI) community, not a new request). > > > I think that is what was said. However, I'm not sure Owen or Tom classify themselves as RPKI experts, please correct me if I'm wrong. And, if I'm wrong, I apologize. Further, this is the first I heard of this being an issue, it's never been brought up in any of the several RKPI talks I've been to. Hi David, I can positively and emphatically identify myself as an RPKI non-expert. That said, I've been to trying to keep an inexpert (+casual, +passive, etc.) eye on its evolution from afar ever since it first appeared (?) on the back of a napkin in March 2006. Rather than opining inexpertly, I'll just provide a couple of likely non-representative primary source references that arguably speak to your question: 1. M. Lepinski & S. Kent, "RFC6480: An Infrastructure to Support Secure Internet Routing" http://tools.ietf.org/rfc/rfc6480.txt Introduction: "In order to facilitate deployment, the architecture takes advantage of existing technologies and practices. The structure of the PKI element of the architecture corresponds to the existing resource allocation structure. Thus management of this PKI is a natural extension of the resource-management functions of the organizations that are already responsible for IP address and AS number resource allocation. Likewise, existing resource allocation and revocation practices have well-defined correspondents in this architecture. Note that while the initial focus of this architecture is routing security applications, the PKI described in this document could be used to support other applications that make use of attestations of IP address or AS number resource holdings." Section 2.1: "An important property of this PKI is that certificates do not attest to the identity of the subject. Therefore, the subject names used in certificates are not intended to be "descriptive". That is, the resource PKI is intended to provide authorization, but not authentication. This is in contrast to most PKIs where the issuer ensures that the descriptive subject name in a certificate is properly associated with the entity that holds the private key corresponding to the public key in the certificate." The relevant question here to my mind is whether or not the adoption of a completely new "resource allocation and revocation practices" associated with AS transfers are likely to be compatible with the continued competent functioning of the "organizations that are already responsible for IP address and AS number resource allocation" and/or with the associated "existing resource allocation and revocation practices" upon which the RPKI was modeled. To be fair, a real RPKI expert would probably emphasize the fact that the "existing resource distribution mechanisms and practices" are actually treated as completely optional by many aspects of RPKI., c.f.: Section 2.4: "In any PKI, each relying party (RP) chooses its own set of trust anchors (TAs). This general property of PKIs applies here as well. There is an extant IP address space and AS number allocation hierarchy, and thus IANA and/or the five RIRs are obvious candidates to be default TAs here. Nonetheless, each RP ultimately chooses the set of trust anchors it will use for certificate validation." However, in the end you have to "trust" somebody or something to perform the "authentication" function to which the RPKI attests but does not itself provide: 2. J. Snyder, K. O'Donoghue, M. Shore, "draft-snyder-trust-relationships-00: A Survey of Trust Models and Relationships in Internet Protocols" http://tools.ietf.org/html/draft-snyder-trust-relationships-00 Section 6.2.1: "Perhaps the key assumption around which PKIX is built is that it is not necessary for two entities to have an existing relationship in order to make a decision whether or not to accept the otherE1/4s assertions as 1) correct, and 2) trustworthy. Rather than negotiating in advance of any communication, those decisions are mediated through the use of third party agents, and consequently whether or not a given entity is trustworthy comes down to the question of whether or not the agent (and its agent, and on up the chain) can be seen as trustworthy and authoritative, and can make reliable assertions about the credentials it has issued." Thus ISTM that while the RPKI may make it technically possible for a thousand new trust anchors to bloom, if they do not all agree to be mutually accountable to each other, at least for some minimal set of shared conditions, the results would likely look something like the domain of customary (non-treaty based) international commercial law, c. back when when inter-national trade was relative new and risky. Hint: That wouldn't be "anarchy" exactly, but neither would it likely be the kind of environment that provides a great deal of reassurance to prospective inter-domain commercial actors. Hopefully a real RPKI expert will chime in and provide a more thorough/representative/accurate account... TV >> Is this a correct characterization of the RPKI experts opinions? > > I would appreciate comments from RPKI experts on this issue. If ASN transfers actually create additional risk within RPKI, then that is something we need to consider. But I for one would like to have a much more detail description of the problem and/or a pointer to previous discussion of the issue. > >> Gary > > -- > =============================================== > 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 Fri Mar 23 20:26:01 2012 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 23 Mar 2012 17:26:01 -0700 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: <4AB26D9E-56D2-47EC-8CE2-1352F0D7580C@eyeconomics.com> References: <4F60B42E.9040101@arin.net> <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> <4F63891F.7010005@umn.edu> <4AB26D9E-56D2-47EC-8CE2-1352F0D7580C@eyeconomics.com> Message-ID: <4F6D1499.9010909@matthew.at> On 3/16/2012 2:23 PM, Tom Vest wrote: > The knowledge that route (a) was originated by AS (x) is only > meaningful insofar as one has some set of high-confidence > beliefs/expectations about AS (x). However, if AS (x) can change hands > at will, henceforth no such confidence will be possible for the > overwhelming majority if not all ASes. I would point out that this fact is *already* true, as ASNs are transferred through merger and acquisition all the time, and have been for over a decade. I don't see anyone proposing a policy where an entity is required to return (and have permanently marked as unavailable) their ASN when ownership changes... I see, for instance, that AS 1 and AS 701 are still out there, despite the above happening several times, and yet nothing terrible has happened as a result. Matthew Kaufman From tvest at eyeconomics.com Fri Mar 23 21:30:17 2012 From: tvest at eyeconomics.com (Tom Vest) Date: Fri, 23 Mar 2012 21:30:17 -0400 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: <4F6D1499.9010909@matthew.at> References: <4F60B42E.9040101@arin.net> <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> <4F63891F.7010005@umn.edu> <4AB26D9E-56D2-47EC-8CE2-1352F0D7580C@eyeconomics.com> <4F6D1499.9010909@matthew.at> Message-ID: <51857197-13B9-465E-A812-75883EB6C537@eyeconomics.com> On Mar 23, 2012, at 8:26 PM, Matthew Kaufman wrote: > On 3/16/2012 2:23 PM, Tom Vest wrote: >> The knowledge that route (a) was originated by AS (x) is only meaningful insofar as one has some set of high-confidence beliefs/expectations about AS (x). However, if AS (x) can change hands at will, henceforth no such confidence will be possible for the overwhelming majority if not all ASes. > > I would point out that this fact is *already* true, as ASNs are transferred through merger and acquisition all the time, and have been for over a decade. > > I don't see anyone proposing a policy where an entity is required to return (and have permanently marked as unavailable) their ASN when ownership changes... I see, for instance, that AS 1 and AS 701 are still out there, despite the above happening several times, and yet nothing terrible has happened as a result. > > Matthew Kaufman For the record, neither have I -- nor would I advocate such a wasteful arrangement. But your comment seems to be completely orthogonal to the statement quoted above. Unless you're saying that at some point in time you were unsure who the owner/operators of AS1 and/or AS701 were...? TV From owen at delong.com Fri Mar 23 23:18:07 2012 From: owen at delong.com (Owen DeLong) Date: Fri, 23 Mar 2012 20:18:07 -0700 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: <4F6D1499.9010909@matthew.at> References: <4F60B42E.9040101@arin.net> <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> <4F63891F.7010005@umn.edu> <4AB26D9E-56D2-47EC-8CE2-1352F0D7580C@eyeconomics.com> <4F6D1499.9010909@matthew.at> Message-ID: On Mar 23, 2012, at 5:26 PM, Matthew Kaufman wrote: > On 3/16/2012 2:23 PM, Tom Vest wrote: >> The knowledge that route (a) was originated by AS (x) is only meaningful insofar as one has some set of high-confidence beliefs/expectations about AS (x). However, if AS (x) can change hands at will, henceforth no such confidence will be possible for the overwhelming majority if not all ASes. > > I would point out that this fact is *already* true, as ASNs are transferred through merger and acquisition all the time, and have been for over a decade. > > I don't see anyone proposing a policy where an entity is required to return (and have permanently marked as unavailable) their ASN when ownership changes... I see, for instance, that AS 1 and AS 701 are still out there, despite the above happening several times, and yet nothing terrible has happened as a result. > I don't see acquiring the reputation of a network when acquiring the entire network as being all that likely to be harmful. At the time of acquisition, the network is still behaving according to its reputation and what is done will cause necessary modifications to that reputation as time goes by. On the other hand, I can see tremendous potential for mischief when acquiring an AS Number on the open market without having to take on the operation of said network as part of the package. I think these are very different scenarios. Again, I think we're seeing enough problems created by allowing transfers with IPv4 addresses that unless there is truly a compelling argument to be made for doing this with ASNs (and so far none has been presented), we should at the very least hold off on expanding to ASNs until such time as we sort out the issues with IPv4 transfers. Owen From matthew at matthew.at Sat Mar 24 00:03:20 2012 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 23 Mar 2012 21:03:20 -0700 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: References: <4F60B42E.9040101@arin.net> <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> <4F63891F.7010005@umn.edu> <4AB26D9E-56D2-47EC-8CE2-1352F0D7580C@eyeconomics.com> <4F6D1499.9010909@matthew.at> Message-ID: <4F6D4788.3000907@matthew.at> On 3/23/2012 8:18 PM, Owen DeLong wrote: > On Mar 23, 2012, at 5:26 PM, Matthew Kaufman wrote: > >> On 3/16/2012 2:23 PM, Tom Vest wrote: >>> The knowledge that route (a) was originated by AS (x) is only meaningful insofar as one has some set of high-confidence beliefs/expectations about AS (x). However, if AS (x) can change hands at will, henceforth no such confidence will be possible for the overwhelming majority if not all ASes. >> I would point out that this fact is *already* true, as ASNs are transferred through merger and acquisition all the time, and have been for over a decade. >> >> I don't see anyone proposing a policy where an entity is required to return (and have permanently marked as unavailable) their ASN when ownership changes... I see, for instance, that AS 1 and AS 701 are still out there, despite the above happening several times, and yet nothing terrible has happened as a result. >> > I don't see acquiring the reputation of a network when acquiring the entire network as being all that likely to be harmful. What makes you think that ASNs acquired through M&A transfer always come with "the entire network"? > At the time of acquisition, the network is still behaving according to its reputation and what is done will cause necessary modifications to that reputation as time goes by. Yes. Perhaps immediately, as the new owners are of course entirely different people with likely different motivations. The network might immediately have vastly different traffic patterns. Etc. > > On the other hand, I can see tremendous potential for mischief when acquiring an AS Number on the open market without having to take on the operation of said network as part of the package. No different than the current situation. You simply make more money for the lawyers when you require that it use the M&A transfer process. > > I think these are very different scenarios. > > Again, I think we're seeing enough problems created by allowing transfers with IPv4 addresses Really? What problems are those? From where I sit, I've seen none. And are those any different than the problems that already existed with transfers of IPv4 addresses via M&A transfer? Matthew Kaufman From owen at delong.com Sat Mar 24 04:02:35 2012 From: owen at delong.com (Owen DeLong) Date: Sat, 24 Mar 2012 01:02:35 -0700 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: <4F6D4788.3000907@matthew.at> References: <4F60B42E.9040101@arin.net> <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> <4F63891F.7010005@umn.edu> <4AB26D9E-56D2-47EC-8CE2-1352F0D7580C@eyeconomics.com> <4F6D1499.9010909@matthew.at> <4F6D4788.3000907@matthew.at> Message-ID: <0241FA8D-83CA-48E4-B1A1-373C0A815E23@delong.com> On Mar 23, 2012, at 9:03 PM, Matthew Kaufman wrote: > On 3/23/2012 8:18 PM, Owen DeLong wrote: >> On Mar 23, 2012, at 5:26 PM, Matthew Kaufman wrote: >> >>> On 3/16/2012 2:23 PM, Tom Vest wrote: >>>> The knowledge that route (a) was originated by AS (x) is only meaningful insofar as one has some set of high-confidence beliefs/expectations about AS (x). However, if AS (x) can change hands at will, henceforth no such confidence will be possible for the overwhelming majority if not all ASes. >>> I would point out that this fact is *already* true, as ASNs are transferred through merger and acquisition all the time, and have been for over a decade. >>> >>> I don't see anyone proposing a policy where an entity is required to return (and have permanently marked as unavailable) their ASN when ownership changes... I see, for instance, that AS 1 and AS 701 are still out there, despite the above happening several times, and yet nothing terrible has happened as a result. >>> >> I don't see acquiring the reputation of a network when acquiring the entire network as being all that likely to be harmful. > > What makes you think that ASNs acquired through M&A transfer always come with "the entire network"? > The ARIN policies that say they are supposed to (or at least a significant portion of it). > >> At the time of acquisition, the network is still behaving according to its reputation and what is done will cause necessary modifications to that reputation as time goes by. > > Yes. Perhaps immediately, as the new owners are of course entirely different people with likely different motivations. The network might immediately have vastly different traffic patterns. Etc. > Pretty rare so far. >> >> On the other hand, I can see tremendous potential for mischief when acquiring an AS Number on the open market without having to take on the operation of said network as part of the package. > > No different than the current situation. You simply make more money for the lawyers when you require that it use the M&A transfer process. > >> We have long since agreed to disagree on this topic. Current practice to date would seem to support my position. >> I think these are very different scenarios. >> >> Again, I think we're seeing enough problems created by allowing transfers with IPv4 addresses > > Really? What problems are those? From where I sit, I've seen none. > That doesn't surprise me. > And are those any different than the problems that already existed with transfers of IPv4 addresses via M&A transfer? > Very much so. Owen From mueller at syr.edu Sun Mar 25 02:51:49 2012 From: mueller at syr.edu (Milton L Mueller) Date: Sun, 25 Mar 2012 06:51:49 +0000 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: References: <4F60B42E.9040101@arin.net> <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> <4F63891F.7010005@umn.edu> <4AB26D9E-56D2-47EC-8CE2-1352F0D7580C@eyeconomics.com> <4F6D1499.9010909@matthew.at> Message-ID: <855077AC3D7A7147A7570370CA01ECD20D4708@SUEX10-mbx-10.ad.syr.edu> > -----Original Message----- > > Again, I think we're seeing enough problems created by allowing > transfers with IPv4 addresses that unless there is truly a compelling [Milton L Mueller] Care to enumerate what these "problems" are? From mysidia at gmail.com Sun Mar 25 03:55:45 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 25 Mar 2012 02:55:45 -0500 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: <4F60B42E.9040101@arin.net> References: <4F60B42E.9040101@arin.net> Message-ID: On Wed, Mar 14, 2012 at 10:07 AM, ARIN wrote: > There are legitimate use cases for transferring ASNs, and no significant > downsides (identified to date) of allowing it. Opposed to this proposal; it appears to be unnecessary scope creep for the 8.3 IPv4 transfer policy. unless that network is transferred together with its network equipment/IP resources and ASN under 8.2, AND a separate routing policy will be maintained for IP addresses after the transfer; a new ASN should be allocated, (or the existing AS should be required to be used when 8.3 transferred IP addresses will not have a distinct routing policy and the transfer recipient already has an AS). An ASN should not be transferrable to an unrelated entity without the IP resources associated with that ASN, because an ASN is an identification of the administrative division, and not an addressing resource. By definition, you have a new AS, therefore a new AS ID number should be assigned to this new AS, and the old one should be retired and not be reallocated for some amount of time. The significant downside is that allowing the free transfer of ASNs breaks the stability of the administrative ID. Because the ID number relates to routing policy, the unexpected transferrance of such ID may cause confusion or have unwanted effects on other networks' treatment of the AS in regards to routing policy. For example, the previous holder of the AS might have had a bad reputation, a position of trust, or relationships with other networks that caused their AS number to appear in various kinds of policy lists. There is also no danger of AS exhaustion, since the field was extended to 32 bits many years ago, therefore, no significant need for the transfer of AS. -- -JH From hannigan at gmail.com Mon Mar 26 15:51:39 2012 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 26 Mar 2012 15:51:39 -0400 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: <4F6D4788.3000907@matthew.at> References: <4F60B42E.9040101@arin.net> <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> <4F63891F.7010005@umn.edu> <4AB26D9E-56D2-47EC-8CE2-1352F0D7580C@eyeconomics.com> <4F6D1499.9010909@matthew.at> <4F6D4788.3000907@matthew.at> Message-ID: On Sat, Mar 24, 2012 at 12:03 AM, Matthew Kaufman wrote: > On 3/23/2012 8:18 PM, Owen DeLong wrote: >> >> On Mar 23, 2012, at 5:26 PM, Matthew Kaufman wrote: >> >>> On 3/16/2012 2:23 PM, Tom Vest wrote: >>>> >>>> The knowledge that route (a) was originated by AS (x) is only meaningful >>>> insofar as one has some set of high-confidence beliefs/expectations about AS >>>> (x). However, if AS (x) can change hands at will, henceforth no such >>>> confidence will be possible for the overwhelming majority if not all ASes. >>> >>> I would point out that this fact is *already* true, as ASNs are >>> transferred through merger and acquisition all the time, and have been for >>> over a decade. >>> >>> I don't see anyone proposing a policy where an entity is required to >>> return (and have permanently marked as unavailable) their ASN when ownership >>> changes... I see, for instance, that AS 1 and AS 701 are still out there, >>> despite the above happening several times, and yet nothing terrible has >>> happened as a result. >>> >> I don't see acquiring the reputation of a network when acquiring the >> entire network as being all that likely to be harmful. > > > What makes you think that ASNs acquired through M&A transfer always come > with "the entire network"? > > > >> ?At the time of acquisition, the network is still behaving according to >> its reputation and what is done will cause necessary modifications to that >> reputation as time goes by. > > > Yes. Perhaps immediately, as the new owners are of course entirely different > people with likely different motivations. The network might immediately have > vastly different traffic patterns. Etc. > > >> >> On the other hand, I can see tremendous potential for mischief when >> acquiring an AS Number on the open market without having to take on the >> operation of said network as part of the package. > > > No different than the current situation. You simply make more money for the > lawyers when you require that it use the M&A transfer process. > > >> >> I think these are very different scenarios. >> >> Again, I think we're seeing enough problems created by allowing transfers >> with IPv4 addresses > > > Really? What problems are those? From where I sit, I've seen none. > > And are those any different than the problems that already existed with > transfers of IPv4 addresses via M&A transfer? > I've said similar things in this thread and I'll simply add +1. What we seem to be talking about here, at least from the counter argument perspective, is a desire to regulate business process instead of providing a technically sound and useful mechanism to enable ASN transfers. As someone involved in peering with literally hundreds of networks, I'm not convinced that there is a risk that I need to be so concerned about that I would want to disallow ASN transfers, especially without a single real life incident that is compelling enough to warrant a change in thought. Adopting this policy will allow ARIN to "get out of the way" and legitimize what's already transpiring on a regular basis. This is a good thing. Best, -M< From michael+ppml at burnttofu.net Mon Mar 26 16:17:08 2012 From: michael+ppml at burnttofu.net (Michael Sinatra) Date: Mon, 26 Mar 2012 13:17:08 -0700 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: References: <4F60B42E.9040101@arin.net> <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> <4F63891F.7010005@umn.edu> <4AB26D9E-56D2-47EC-8CE2-1352F0D7580C@eyeconomics.com> <4F6D1499.9010909@matthew.at> <4F6D4788.3000907@matthew.at> Message-ID: <4F70CEC4.1010902@burnttofu.net> On 3/26/12 12:51 PM, Martin Hannigan wrote: > I've said similar things in this thread and I'll simply add +1. > > What we seem to be talking about here, at least from the counter > argument perspective, is a desire to regulate business process instead > of providing a technically sound and useful mechanism to enable ASN > transfers. As someone involved in peering with literally hundreds of > networks, I'm not convinced that there is a risk that I need to be so > concerned about that I would want to disallow ASN transfers, > especially without a single real life incident that is compelling > enough to warrant a change in thought. > > Adopting this policy will allow ARIN to "get out of the way" and > legitimize what's already transpiring on a regular basis. This is a > good thing. Hi Marty: Can you (or perhaps ARIN staff) shed some light on what is already transpiring with respect to ASN transfers other than via M&A? I have to admit that I am pretty out of the loop when it comes to actual demand for ASN transfers other than the use cases identified by Chris G. a while back. The only other thing I see is a quick note by the staff analysis to the effect that it would expedite bankruptcy proceedings. Is that the main focus here or are there other use cases (other than the ones Chris identified)? thanks, michael From jrhett at netconsonance.com Mon Mar 26 17:30:50 2012 From: jrhett at netconsonance.com (Jo Rhett) Date: Mon, 26 Mar 2012 14:30:50 -0700 Subject: [arin-ppml] 4-Byte ASN's in the ARIN region... In-Reply-To: References: <17F1F66E-1792-4ED4-AEF6-AC94B593DEBA@corp.arin.net> <7D8EB831-D807-402F-8E89-C4D7B8CACD9E@netconsonance.com> Message-ID: On Mar 20, 2012, at 3:48 PM, Jeff Wheeler wrote: > If new networks are no longer able to get 2-byte ASNs, two things will > happen pretty quickly. Most remaining SPs will support 4-byte ASNs > very rapidly, because they will lose out on new customers if they > don't. You are suggesting something you believe to be true. I am stating what I have observed time and time again. Operators see no value in supporting 4-byte ASNs, regardless of what you want to believe. Therefore your proposal to penalize the customer is aimed at the wrong place. It would hurt the customer, not the operator. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannigan at gmail.com Mon Mar 26 18:29:53 2012 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 26 Mar 2012 18:29:53 -0400 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: <4F70CEC4.1010902@burnttofu.net> References: <4F60B42E.9040101@arin.net> <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> <4F63891F.7010005@umn.edu> <4AB26D9E-56D2-47EC-8CE2-1352F0D7580C@eyeconomics.com> <4F6D1499.9010909@matthew.at> <4F6D4788.3000907@matthew.at> <4F70CEC4.1010902@burnttofu.net> Message-ID: On Mon, Mar 26, 2012 at 4:17 PM, Michael Sinatra wrote: > On 3/26/12 12:51 PM, Martin Hannigan wrote: > >> I've said similar things in this thread and I'll simply add +1. >> >> What we seem to be talking about here, at least from the counter >> argument perspective, is a desire to regulate business process instead >> of providing a technically sound and useful mechanism to enable ASN >> transfers. ?As someone involved in peering with literally hundreds of >> networks, I'm not convinced that there is a risk that I need to be so >> concerned about that I would want to disallow ASN transfers, >> especially without a single real life incident that is compelling >> enough to warrant a change in thought. >> >> Adopting this policy will allow ARIN to "get out of the way" and >> legitimize what's already transpiring on a regular basis. ?This is a >> good thing. > > Hi Marty: > > Can you (or perhaps ARIN staff) shed some light on what is already > transpiring with respect to ASN transfers other than via M&A? ?I have to > admit that I am pretty out of the loop when it comes to actual demand > for ASN transfers other than the use cases identified by Chris G. a > while back. ?The only other thing I see is a quick note by the staff > analysis to the effect that it would expedite bankruptcy proceedings. > Is that the main focus here or are there other use cases (other than the > ones Chris identified)? > Michael, That would be the at least part of the idea. The other would be to insure that transfers that occur for reasons not related to bankruptcy are fully documented and as transparent as they need to be. The legal comments in the ARIN staff clarity and understanding would have most infer that legacy ASN's and IP addresses are in a similar legal state. This proposal would remove what is currently an ambiguity, provide a useful policy to those who do want to transfer an ASN for a multitude of legitimate reasons and to help improve the accuracy of our documentation. I don't know what the staff experience is, it wasn't contained in the C/U. I would be interested to hear it. Best, -M< From jcurran at arin.net Mon Mar 26 18:45:44 2012 From: jcurran at arin.net (John Curran) Date: Mon, 26 Mar 2012 22:45:44 +0000 Subject: [arin-ppml] 4-Byte ASN's in the ARIN region... In-Reply-To: References: <17F1F66E-1792-4ED4-AEF6-AC94B593DEBA@corp.arin.net> <7D8EB831-D807-402F-8E89-C4D7B8CACD9E@netconsonance.com> Message-ID: On Mar 26, 2012, at 5:30 PM, Jo Rhett wrote: > You are suggesting something you believe to be true. I am stating what I have observed time and time again. Operators see no value in supporting 4-byte ASNs, regardless of what you want to believe. Therefore your proposal to penalize the customer is aimed at the wrong place. It would hurt the customer, not the operator. Is there a public list somewhere of operators who do not presently support 4-byte ASN's? That might be helpful to customers looking for service and/or those in community researching the problem with 4-byte ASN deployment in this region. /John John Curran President and CEO ARIN From jcurran at arin.net Mon Mar 26 18:50:17 2012 From: jcurran at arin.net (John Curran) Date: Mon, 26 Mar 2012 22:50:17 +0000 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: References: <4F60B42E.9040101@arin.net> <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> <4F63891F.7010005@umn.edu> <4AB26D9E-56D2-47EC-8CE2-1352F0D7580C@eyeconomics.com> <4F6D1499.9010909@matthew.at> <4F6D4788.3000907@matthew.at> <4F70CEC4.1010902@burnttofu.net> Message-ID: On Mar 26, 2012, at 6:29 PM, Martin Hannigan wrote: > On Mon, Mar 26, 2012 at 4:17 PM, Michael Sinatra > wrote: >> >> Can you (or perhaps ARIN staff) shed some light on what is already >> transpiring with respect to ASN transfers other than via M&A? I have to >> admit that I am pretty out of the loop when it comes to actual demand >> for ASN transfers other than the use cases identified by Chris G. a >> while back. The only other thing I see is a quick note by the staff >> analysis to the effect that it would expedite bankruptcy proceedings. >> Is that the main focus here or are there other use cases (other than >> the ones Chris identified)? > > Michael, > > That would be the at least part of the idea. The other would be to > insure that transfers that occur for reasons not related to bankruptcy > are fully documented and as transparent as they need to be. The legal > comments in the ARIN staff clarity and understanding would have most > infer that legacy ASN's and IP addresses are in a similar legal state. > > This proposal would remove what is currently an ambiguity, provide a > useful policy to those who do want to transfer an ASN for a multitude > of legitimate reasons and to help improve the accuracy of our > documentation. > > I don't know what the staff experience is, it wasn't contained in the > C/U. I would be interested to hear it. Marty, Michael - Request received. We will research past staff experience regarding ASN transfers and report back to the list. Thanks, /John John Curran President and CEO ARIN From mysidia at gmail.com Mon Mar 26 19:56:31 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 26 Mar 2012 18:56:31 -0500 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: References: <4F60B42E.9040101@arin.net> <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> <4F63891F.7010005@umn.edu> <4AB26D9E-56D2-47EC-8CE2-1352F0D7580C@eyeconomics.com> <4F6D1499.9010909@matthew.at> <4F6D4788.3000907@matthew.at> <4F70CEC4.1010902@burnttofu.net> Message-ID: On Mon, Mar 26, 2012 at 5:29 PM, Martin Hannigan wrote: > This proposal would remove what is currently an ambiguity, provide a > useful policy to those who do want to transfer an ASN for a multitude > of legitimate reasons and to help improve the accuracy of our > documentation. What are these multitude of legitimate reasons that an ASN transfer would be required outside of M&A instead of applying for and receiving a new ASN? Even in the case of M&A the need for AS transfer in the absence of a continued unique routing policy is unclear. Renumbering into a different AS is a highly inexpensive operation (compared to renumbering into a new IP address space). With AS transfers between different organizations allowed, there is an increased risk of an accidental situation where two different organizations are simultaneously using the same AS to announce prefixes, even though they are not supposed to, because the losing organization made an oversight in the "AS deconfiguration process"; and such simultaneous use of the same AS is very bad, and much less likely to be properly detected than accidental simultaneous use of an IP prefix. To be clear, some example of things I would define as not legitimate: * An organization disposing of AS numbers through specified transfer to hide or "change" their apparent identity, for example, their previous AS may have been depeered, and become known as a spammer AS; it could be convenient for them to dispose of that AS, and apply for a new one later. * Deriving unfair value out of "special" ASN numbers, for example selling "AS number 1", "AS number 123", "456", or "AS number 666" for a large sum of money via specified transfer, because ARIN happened to allocate a number that some buyer considers to have some vanity significance. Any value of this significance really belongs to the community, who did not issue these numbers with the expectation they could be transferred or sold. * Trading 16-bit numbers as a means of discouraging use of "less valuable" 32-bit AS numbers. * An organization that does not actually need multiple AS numbers acquiring multiple AS numbers. * An organization acquiring large numbers of AS numbers for the purpose of reselling and transferring them later, an "AS broker". --- -JH From mysidia at gmail.com Mon Mar 26 20:43:53 2012 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 26 Mar 2012 19:43:53 -0500 Subject: [arin-ppml] 4-Byte ASN's in the ARIN region... In-Reply-To: References: <17F1F66E-1792-4ED4-AEF6-AC94B593DEBA@corp.arin.net> <7D8EB831-D807-402F-8E89-C4D7B8CACD9E@netconsonance.com> Message-ID: On Mon, Mar 26, 2012 at 4:30 PM, Jo Rhett wrote: > On Mar 20, 2012, at 3:48 PM, Jeff Wheeler wrote: [snip] > You are suggesting something you believe to be true. I am stating what I > have observed time and time again. Operators see no value in supporting > 4-byte ASNs, regardless of what you want to believe. Therefore your proposal > to penalize the customer is aimed at the wrong place. ?It would hurt the > customer, not the operator. At this point all ASNs are 4-byte ASNs. I see no value in allowing any operator to refuse to peer with an ASN that has non-zero bits in multiple octets. The few who don't must see value immediately, when their business demands they support 4-byte ASNs due to having customer(s) with a 4-byte ASN, a signed contract, and no 2-byte ASN available. -- -JH From nicky.smith at guilfordcommunications.com Tue Mar 27 20:59:35 2012 From: nicky.smith at guilfordcommunications.com (nicky.smith at guilfordcommunications.com) Date: Tue, 27 Mar 2012 20:59:35 -0400 Subject: [arin-ppml] WhoWas Service Now in ARIN Online Announcement Message-ID: > As send from arin-announce at arin.net on Mon, 26 Mar 2012 10:18:02 -0400 > > Subject: WhoWas Service Now in ARIN Online (ARIN) > From: Mark Kosters, Chief Technical Officer (ARIN) > > > ARIN is pleased to announce the integration of its WhoWas service in > ARIN Online. ARIN?s WhoWas service provides historical registration > reports for a given IP address or ASN. WhoWas functionality is > available to ARIN Online users through the DOWNLOADS option in the > left navigation. To access this service, users must first submit a > one-time request to become authorized to access the WhoWas service. > Once approved, users will need to agree to the WhoWas Terms of Use > before requesting a report. > > Please view https://www.arin.net/resources/whowas/index.html for > complete details on ARIN?s WhoWas service. -- snip -- It appears that after years of being harangued by 'anti-spam' cultists for access to historic WHOIS data in order to burnish their credentials as Official Spam Detectives and support their efforts to criminalize marketing and drag email back to the DARPA era, ARIN has finally thrown in the towel. I am frankly disappointed. Has this topic every been discussed? This needs not to be part of the Disciples of ARIN. I am optimistic this can be reversed pending discussion. Nicky Smith CAROLINANET.COM 336.346.6000 x105 From jlewis at lewis.org Tue Mar 27 21:28:13 2012 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 27 Mar 2012 21:28:13 -0400 (EDT) Subject: [arin-ppml] WhoWas Service Now in ARIN Online Announcement In-Reply-To: References: Message-ID: On Tue, 27 Mar 2012 nicky.smith at guilfordcommunications.com wrote: > It appears that after years of being harangued by 'anti-spam' cultists > for access to historic WHOIS data in order to burnish their credentials > as Official Spam Detectives and support their efforts to criminalize > marketing and drag email back to the DARPA era, ARIN has finally thrown > in the towel. I am frankly disappointed. > > Has this topic every been discussed? This needs not to be part of the > Disciples of ARIN. I am optimistic this can be reversed pending > discussion. What (or who) do you have to hide? Disciples of ARIN? What the heck is that? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From cja at daydream.com Wed Mar 28 01:59:54 2012 From: cja at daydream.com (CJ Aronson) Date: Wed, 28 Mar 2012 07:59:54 +0200 Subject: [arin-ppml] WhoWas Service Now in ARIN Online Announcement In-Reply-To: References: Message-ID: Nicky WHOWAS has been discussed at length at many ARIN meetings and on the mailing list. There is a large demand for this service and thanks to ARIN for bringing it to reality. ----CJ On Wed, Mar 28, 2012 at 2:59 AM, wrote: >> As send from arin-announce at arin.net on Mon, 26 Mar 2012 10:18:02 -0400 >> >> Subject: WhoWas Service Now in ARIN Online (ARIN) >> From: Mark Kosters, Chief Technical Officer (ARIN) >> >> >> ARIN is pleased to announce the integration of its WhoWas service in >> ARIN Online. ARIN?s WhoWas service provides historical registration >> reports for a given IP address or ASN. WhoWas functionality is >> available to ARIN Online users through the DOWNLOADS option in the >> left navigation. To access this service, users must first submit a >> one-time request to become authorized to access the WhoWas service. >> Once approved, users will need to agree to the WhoWas Terms of Use >> before requesting a report. >> >> Please view https://www.arin.net/resources/whowas/index.html for >> complete details on ARIN?s WhoWas service. > > -- snip -- > > > It appears that after years of being harangued by 'anti-spam' cultists for access to historic WHOIS data in order to burnish their credentials as Official Spam Detectives and support their efforts to criminalize marketing and drag email back to the DARPA era, ARIN has finally thrown in the towel. I am frankly disappointed. > > Has this topic every been discussed? This needs not to be part of the Disciples of ARIN. I am optimistic this can be reversed pending discussion. > > Nicky Smith > CAROLINANET.COM > 336.346.6000 x105 > > > > _______________________________________________ > 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 Wed Mar 28 14:16:26 2012 From: jcurran at arin.net (John Curran) Date: Wed, 28 Mar 2012 18:16:26 +0000 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: <4F70CEC4.1010902@burnttofu.net> References: <4F60B42E.9040101@arin.net> <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> <4F63891F.7010005@umn.edu> <4AB26D9E-56D2-47EC-8CE2-1352F0D7580C@eyeconomics.com> <4F6D1499.9010909@matthew.at> <4F6D4788.3000907@matthew.at> <4F70CEC4.1010902@burnttofu.net> Message-ID: <9CEC6522-1C0B-411A-87A8-D1531C2FE8FD@corp.arin.net> On Mar 26, 2012, at 4:17 PM, Michael Sinatra wrote: > Can you (or perhaps ARIN staff) shed some light on what is already > transpiring with respect to ASN transfers other than via M&A? In general, it is difficult to assess whether parties would like to transfer ASNs (outside of normal M&A) as they are likely not request such from ARIN if they are familiar with the existing NRPM 8.3 policy. In an effort to shed some light on potential demand, we went back through the 2011 and 2012 transfer tickets (which is when the majority of the 8.3 transfers have taken place) to try to discern if there were ASN resources included originally as part of any 8.3 specified transfers requests. In doing so, we found that there were 3 requests that originally included ASN resources in the original transfer request (and which were then removed due to the existing policy language.) This is out of a total of 31 specified transfer requests (26 in 2011 and 5 requests so far in 2012.) I hope this information is helpful in your policy considerations, /John John Curran President and CEO ARIN From kkargel at polartel.com Wed Mar 28 14:31:04 2012 From: kkargel at polartel.com (Kevin Kargel) Date: Wed, 28 Mar 2012 13:31:04 -0500 Subject: [arin-ppml] WhoWas Service Now in ARIN Online Announcement In-Reply-To: References: Message-ID: <8695009A81378E48879980039EEDAD28011E05E506@MAIL1.polartel.local> > > > It appears that after years of being harangued by 'anti-spam' cultists for > access to historic WHOIS data in order to burnish their credentials as > Official Spam Detectives and support their efforts to criminalize > marketing and drag email back to the DARPA era, ARIN has finally thrown in > the towel. I am frankly disappointed. > > Has this topic every been discussed? This needs not to be part of the > Disciples of ARIN. I am optimistic this can be reversed pending > discussion. > > Nicky Smith > CAROLINANET.COM > 336.346.6000 x105 I, for one, do not understand what you perceive the evil of a WhoWas service to be? Aside from the worst case of wasting admin time and budget I do not see a real down side to it's existence. Please elucidate. I do remember the topic being discussed on more than one occasion. Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4935 bytes Desc: not available URL: From admin at directcolocation.com Wed Mar 28 15:04:45 2012 From: admin at directcolocation.com (admin at directcolocation.com) Date: Wed, 28 Mar 2012 15:04:45 -0400 (EDT) Subject: [arin-ppml] WhoWas Service Now in ARIN Online Announcement Message-ID: <52621.admin@directcolocation.com.1332961485.squirrel@www.directcolocation.com> I guess it comes down to the fact of how they the ARIN intends to create the starting point on this service since it is a new service, does it go back in the historical past from the inception of the blocks that are assigned to such or does it go forward from this point of the service being created. The key for his concern would be if they had problems in the past with the anti spammers and continued having the same kind of problem customers, then I could see the use of this service potential effecting the long term reputation, since the problem would be that some of the anti spammer groups that might use the service could refuse to work with this kind of operator so they could at least clean up there act. Does anyone know if ARIN intends to start the service from this point forward and or go back into current historical data from the issuance of the blocks in the whois. If they start it from this point on then I would look at it as an opportunity to get my house in order if you know that this is the kind of customers you have been targeting. Donald Mahoney Network Engineer Direct Colocation On 3/28/12 2:31 PM, "Kevin Kargel" wrote: It appears that after years of being harangued by 'anti-spam' cultists for access to historic WHOIS data in order to burnish their credentials as Official Spam Detectives and support their efforts to criminalize marketing and drag email back to the DARPA era, ARIN has finally thrown in the towel. I am frankly disappointed. Has this topic every been discussed? This needs not to be part of the Disciples of ARIN. I am optimistic this can be reversed pending discussion. Nicky Smith CAROLINANET.COM 336.346.6000 x105 I, for one, do not understand what you perceive the evil of a WhoWas service to be? Aside from the worst case of wasting admin time and budget I do not see a real down side to it's existence. Please elucidate. I do remember the topic being discussed on more than one occasion. Kevin _______________________________________________ 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 28 15:42:52 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 28 Mar 2012 13:42:52 -0600 Subject: [arin-ppml] WhoWas Service Now in ARIN Online Announcement In-Reply-To: <52621.admin@directcolocation.com.1332961485.squirrel@www.directcolocation.com> References: <52621.admin@directcolocation.com.1332961485.squirrel@www.directcolocation.com> Message-ID: <346D7BB0-7305-4AB9-BD13-574184DC508E@delong.com> It goes back in time and should include all historical whois information available. The only drawback is it prevents someone from denying their history. Personally, I don't see that as a bad thing. Owen Sent from my iPad On Mar 28, 2012, at 1:04 PM, admin at directcolocation.com wrote: > I guess it comes down to the fact of how they the ARIN intends to create > the starting point on this service since it is a new service, does it go > back in the historical past from the inception of the blocks that are > assigned to such or does it go forward from this point of the service > being created. > > The key for his concern would be if they had problems in the past with the > anti spammers and continued having the same kind of problem customers, > then I could see the use of this service potential effecting the long term > reputation, since the problem would be that some of the anti spammer > groups that might use the service could refuse to work with this kind of > operator so they could at least clean up there act. > > Does anyone know if ARIN intends to start the service from this point > forward and or go back into current historical data from the issuance of > the blocks in the whois. > > If they start it from this point on then I would look at it as an > opportunity to get my house in order if you know that this is the kind of > customers you have been targeting. > > Donald Mahoney > Network Engineer > Direct Colocation > > > On 3/28/12 2:31 PM, "Kevin Kargel" wrote: > > It appears that after years of being harangued by 'anti-spam' cultists for > access to historic WHOIS data in order to burnish their credentials as > Official Spam Detectives and support their efforts to criminalize > marketing and drag email back to the DARPA era, ARIN has finally thrown in > the towel. I am frankly disappointed. > Has this topic every been discussed? This needs not to be part of the > Disciples of ARIN. I am optimistic this can be reversed pending > discussion. > Nicky Smith > CAROLINANET.COM > 336.346.6000 x105 > > I, for one, do not understand what you perceive the evil of a WhoWas service > to be? Aside from the worst case of wasting admin time and budget I do not > see a real down side to it's existence. Please elucidate. > > I do remember the topic being discussed on more than one occasion. > Kevin > _______________________________________________ > 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 ppml at rsuc.gweep.net Wed Mar 28 15:44:28 2012 From: ppml at rsuc.gweep.net (Joe Provo) Date: Wed, 28 Mar 2012 15:44:28 -0400 Subject: [arin-ppml] WhoWas Service Now in ARIN Online Announcement Message-ID: <20120328194427.GA63291@gweep.net> On Wed, Mar 28, 2012 at 03:04:45PM -0400, admin at directcolocation.com wrote: > I guess it comes down to the fact of how they the ARIN intends to create > the starting point on this service since it is a new service, does it go > back in the historical past from the inception of the blocks that are > assigned to such or does it go forward from this point of the service > being created. [snip] >From the posted links, "Each .tsv file will contain a complete history of publicly viewable information for the given handle." So we can only hope it goes back at least to the beginning of ARIN's time. Sadly, I wouldn't expect the [non normalized format] pre-RIR data to be included. Thanks ARIN - many of us have been asking for this since we started to have whois fragmentation (I never convinced rodney to fold it into geektools). -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG From admin at directcolocation.com Wed Mar 28 16:27:20 2012 From: admin at directcolocation.com (admin at directcolocation.com) Date: Wed, 28 Mar 2012 16:27:20 -0400 (EDT) Subject: [arin-ppml] WhoWas Service Now in ARIN Online Announcement Message-ID: <53734.admin@directcolocation.com.1332966440.squirrel@www.directcolocation.com> I do agree that it is not a bad thing but I do not see how it is a fair approach for a new service being applied to the whois at this date forward, if you were in the business of LAW then it would appear that it was a law that was being implemented and now would effect you on anything you have done in the past vrs now that you know making sure that you govern yourself accordingly. I am not a lawyer but I think they call this ex post facto in the fact you cannot punished for something you did in the past. But in this case you may have well done something in the past and now have to live with it for the rest of your IP life. I do not see how this could be a fair way to handle the implementation of the information available in this service, now that you know it exist and or you had some issues in the past, even if you have cleaned up your act. The problem I see is in this case is that as we all know the anti spammers are not held accountable by any law or in some cases we do not know who they are and or where they are, so if the have this information at there disposal. Could it put ARIN a position of some kind of liability from a potential law suite for providing this information based on private business models and who one chooses to do business with based on the legal side of the quote can spam act as all spammers will calm they follow. The problem could be perceived is that the network operator is being punished here by unregulated anti spammer groups and thus harming the business income of that operator by the act of ARIN providing access to this information to unregulated anti spammer groups, vrs the operators business income being harmed because of the actions of ARIN providing the unregulated groups access to the info. Again I am not a lawyer, but this should be considered, because anti spammers, like spammers hide themselves. With out the ability to regulate the anti spammers and hold them accountable for there actions of the use or mis use of this service, while there is some legislation in the can spam act that has holds the spammers to some accountability. I would venture to say in our law suite happy world that some sharp lawyer might just challenge the use of this service harming an operators business income and go after the provider of information that caused the harm in this case ARIN. I guess we should consider if any of the other RIR's are doing the same service because that would negate this concern. I am sure they would try to site that as a difference in single out of ARIN if it came down to that extreme situation. Also do you know if the service will be used on IPV6 whois so as this goes forward we will be able to have that information there also or is just on the IPV4 whois Donald Mahoney Network Engineer Direct Colocation On 3/28/12 3:42 PM, "Owen DeLong" wrote: It goes back in time and should include all historical whois information available. The only drawback is it prevents someone from denying their history. Personally, I don't see that as a bad thing. Owen Sent from my iPad On Mar 28, 2012, at 1:04 PM, admin at directcolocation.com wrote: I guess it comes down to the fact of how they the ARIN intends to create the starting point on this service since it is a new service, does it go back in the historical past from the inception of the blocks that are assigned to such or does it go forward from this point of the service being created. The key for his concern would be if they had problems in the past with the anti spammers and continued having the same kind of problem customers, then I could see the use of this service potential effecting the long term reputation, since the problem would be that some of the anti spammer groups that might use the service could refuse to work with this kind of operator so they could at least clean up there act. Does anyone know if ARIN intends to start the service from this point forward and or go back into current historical data from the issuance of the blocks in the whois. If they start it from this point on then I would look at it as an opportunity to get my house in order if you know that this is the kind of customers you have been targeting. Donald Mahoney Network Engineer Direct Colocation On 3/28/12 2:31 PM, "Kevin Kargel" wrote: It appears that after years of being harangued by 'anti-spam' cultists for access to historic WHOIS data in order to burnish their credentials as Official Spam Detectives and support their efforts to criminalize marketing and drag email back to the DARPA era, ARIN has finally thrown in the towel. I am frankly disappointed. Has this topic every been discussed? This needs not to be part of the Disciples of ARIN. I am optimistic this can be reversed pending discussion. Nicky Smith CAROLINANET.COM 336.346.6000 x105 I, for one, do not understand what you perceive the evil of a WhoWas service to be? Aside from the worst case of wasting admin time and budget I do not see a real down side to it's existence. Please elucidate. I do remember the topic being discussed on more than one occasion. Kevin _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From jcurran at arin.net Wed Mar 28 17:16:43 2012 From: jcurran at arin.net (John Curran) Date: Wed, 28 Mar 2012 21:16:43 +0000 Subject: [arin-ppml] WhoWas Service Now in ARIN Online Announcement In-Reply-To: <53734.admin%directcolocation.com.1332966440.squirrel@www.directcolocation.com> References: <53734.admin%directcolocation.com.1332966440.squirrel@www.directcolocation.com> Message-ID: Donald - The information being provided is the same information that has already been provided publicly over the years. ARIN is providing it via a WhoWas service as a convenience due to the repeated requests of the members that this information be made readily available. It is possible that parties will indeed take various actions based on the information therein; please rest assured that ARIN has taken appropriate legal precautions in offering the service. For specific details, you should refer to the WhoWas Terms of Use available here: Thanks for asking about this! Sincerely, /John John Curran President and CEO ARIN On Mar 28, 2012, at 4:27 PM, admin at directcolocation.com wrote: > I do agree that it is not a bad thing but I do not see how it is a fair > approach for a new service being applied to the whois at this date > forward, if you were in the business of LAW then it would appear that it > was a law that was being implemented and now would effect you on anything > you have done in the past vrs now that you know making sure that you > govern yourself accordingly. > > I am not a lawyer but I think they call this ex post facto in the fact you > cannot punished for something you did in the past. > > But in this case you may have well done something in the past and now have > to live with it for the rest of your IP life. I do not see how this could > be a fair way to handle the implementation of the information available in > this service, now that you know it exist and or you had some issues in the > past, even if you have cleaned up your act. > > The problem I see is in this case is that as we all know the anti spammers > are not held accountable by any law or in some cases we do not know who > they are and or where they are, so if the have this information at there > disposal. > > Could it put ARIN a position of some kind of liability from a potential > law suite for providing this information based on private business models > and who one chooses to do business with based on the legal side of the > quote can spam act as all spammers will calm they follow. > > The problem could be perceived is that the network operator is being > punished here by unregulated anti spammer groups and thus harming the > business income of that operator by the act of ARIN providing access to > this information to unregulated anti spammer groups, vrs the operators > business income being harmed because of the actions of ARIN providing the > unregulated groups access to the info. > > > Again I am not a lawyer, but this should be considered, because anti > spammers, like spammers hide themselves. With out the ability to regulate > the anti spammers and hold them accountable for there actions of the use > or mis use of this service, while there is some legislation in the can > spam act that has holds the spammers to some accountability. > > I would venture to say in our law suite happy world that some sharp lawyer > might just challenge the use of this service harming an operators business > income and go after the provider of information that caused the harm in > this case ARIN. > > I guess we should consider if any of the other RIR's are doing the same > service because that would negate this concern. > > I am sure they would try to site that as a difference in single out of > ARIN if it came down to that extreme situation. > > > Also do you know if the service will be used on IPV6 whois so as this goes > forward we will be able to have that information there also or is just on > the IPV4 whois > > Donald Mahoney > Network Engineer > Direct Colocation > > On 3/28/12 3:42 PM, "Owen DeLong" wrote: > > It goes back in time and should include all historical whois information > available. > > The only drawback is it prevents someone from denying their history. > Personally, I don't see that as a bad thing. > > Owen > > > Sent from my iPad > > On Mar 28, 2012, at 1:04 PM, admin at directcolocation.com wrote: > > I guess it comes down to the fact of how they the ARIN intends to create > the starting point on this service since it is a new service, does it go > back in the historical past from the inception of the blocks that are > assigned to such or does it go forward from this point of the service > being created. > The key for his concern would be if they had problems in the past with the > anti spammers and continued having the same kind of problem customers, > then I could see the use of this service potential effecting the long term > reputation, since the problem would be that some of the anti spammer > groups that might use the service could refuse to work with this kind of > operator so they could at least clean up there act. > Does anyone know if ARIN intends to start the service from this point > forward and or go back into current historical data from the issuance of > the blocks in the whois. > If they start it from this point on then I would look at it as an > opportunity to get my house in order if you know that this is the kind of > customers you have been targeting. > Donald Mahoney > Network Engineer > Direct Colocation > On 3/28/12 2:31 PM, "Kevin Kargel" wrote: > It appears that after years of being harangued by 'anti-spam' cultists for > access to historic WHOIS data in order to burnish their credentials as > Official Spam Detectives and support their efforts to criminalize > marketing and drag email back to the DARPA era, ARIN has finally thrown in > the towel. I am frankly disappointed. > Has this topic every been discussed? This needs not to be part of the > Disciples of ARIN. I am optimistic this can be reversed pending > discussion. > Nicky Smith > CAROLINANET.COM > 336.346.6000 x105 > I, for one, do not understand what you perceive the evil of a WhoWas service > to be? Aside from the worst case of wasting admin time and budget I do not > see a real down side to it's existence. Please elucidate. > I do remember the topic being discussed on more than one occasion. > Kevin > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > 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 kevinb at thewire.ca Wed Mar 28 17:19:35 2012 From: kevinb at thewire.ca (Kevin Blumberg) Date: Wed, 28 Mar 2012 21:19:35 +0000 Subject: [arin-ppml] WhoWas Service Now in ARIN Online Announcement In-Reply-To: <53734.admin@directcolocation.com.1332966440.squirrel@www.directcolocation.com> References: <53734.admin@directcolocation.com.1332966440.squirrel@www.directcolocation.com> Message-ID: <7E7773B523E82C478734E793E58F69E7694D5121@SBS2011.thewireinc.local> The information in the Who was service is only what was available ***publically***. It is the same as going to the library and getting the 2001-2012 phone books to see what number you had. The point of Who Was (in my mind) is to be able to see the history of an allocation. It is crucial moving forward for 8.3 transfers to be able to see the "pedigree" of a netblock before purchase and this makes it much easier to do. It allows for Peering Co-Coordinators to look at the history of a net block to help in preventing hijacked space from being used. It allows me to see if a company coming to me for transit is using another name of convenience and has changed there whois record 10 time in the past 18 months. The service has no rating engine in it and makes no assumptions on how the space was used, just who used it. If you have an example of how the WhoWas service could be a problem can you please articulate a specific example. I'd like to understand how having access to what was public information could be considered harmful. Thanks, Kevin Blumberg > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of admin at directcolocation.com > Sent: Wednesday, March 28, 2012 4:27 PM > To: owen at delong.com; arin-ppml at arin.net > Subject: Re: [arin-ppml] WhoWas Service Now in ARIN Online > Announcement > > I do agree that it is not a bad thing but I do not see how it is a fair approach > for a new service being applied to the whois at this date forward, if you were > in the business of LAW then it would appear that it was a law that was being > implemented and now would effect you on anything you have done in the > past vrs now that you know making sure that you govern yourself > accordingly. > > I am not a lawyer but I think they call this ex post facto in the fact you cannot > punished for something you did in the past. > > But in this case you may have well done something in the past and now have > to live with it for the rest of your IP life. I do not see how this could be a fair > way to handle the implementation of the information available in this > service, now that you know it exist and or you had some issues in the past, > even if you have cleaned up your act. > > The problem I see is in this case is that as we all know the anti spammers are > not held accountable by any law or in some cases we do not know who they > are and or where they are, so if the have this information at there disposal. > > Could it put ARIN a position of some kind of liability from a potential law suite > for providing this information based on private business models and who one > chooses to do business with based on the legal side of the quote can spam > act as all spammers will calm they follow. > > The problem could be perceived is that the network operator is being > punished here by unregulated anti spammer groups and thus harming the > business income of that operator by the act of ARIN providing access to this > information to unregulated anti spammer groups, vrs the operators business > income being harmed because of the actions of ARIN providing the > unregulated groups access to the info. > > > Again I am not a lawyer, but this should be considered, because anti > spammers, like spammers hide themselves. With out the ability to regulate > the anti spammers and hold them accountable for there actions of the use or > mis use of this service, while there is some legislation in the can spam act that > has holds the spammers to some accountability. > > I would venture to say in our law suite happy world that some sharp lawyer > might just challenge the use of this service harming an operators business > income and go after the provider of information that caused the harm in this > case ARIN. > > I guess we should consider if any of the other RIR's are doing the same > service because that would negate this concern. > > I am sure they would try to site that as a difference in single out of ARIN if it > came down to that extreme situation. > > > Also do you know if the service will be used on IPV6 whois so as this goes > forward we will be able to have that information there also or is just on the > IPV4 whois > > Donald Mahoney > Network Engineer > Direct Colocation > > On 3/28/12 3:42 PM, "Owen DeLong" wrote: > > It goes back in time and should include all historical whois information > available. > > The only drawback is it prevents someone from denying their history. > Personally, I don't see that as a bad thing. > > Owen > > > Sent from my iPad > > On Mar 28, 2012, at 1:04 PM, admin at directcolocation.com wrote: > > I guess it comes down to the fact of how they the ARIN intends to create the > starting point on this service since it is a new service, does it go back in the > historical past from the inception of the blocks that are assigned to such or > does it go forward from this point of the service being created. > The key for his concern would be if they had problems in the past with the > anti spammers and continued having the same kind of problem customers, > then I could see the use of this service potential effecting the long term > reputation, since the problem would be that some of the anti spammer > groups that might use the service could refuse to work with this kind of > operator so they could at least clean up there act. > Does anyone know if ARIN intends to start the service from this point > forward and or go back into current historical data from the issuance of the > blocks in the whois. > If they start it from this point on then I would look at it as an opportunity to > get my house in order if you know that this is the kind of customers you have > been targeting. > Donald Mahoney > Network Engineer > Direct Colocation > On 3/28/12 2:31 PM, "Kevin Kargel" wrote: > It appears that after years of being harangued by 'anti-spam' cultists for > access to historic WHOIS data in order to burnish their credentials as Official > Spam Detectives and support their efforts to criminalize marketing and drag > email back to the DARPA era, ARIN has finally thrown in the towel. I am > frankly disappointed. > Has this topic every been discussed? This needs not to be part of the > Disciples of ARIN. I am optimistic this can be reversed pending discussion. > Nicky Smith > CAROLINANET.COM > 336.346.6000 x105 > I, for one, do not understand what you perceive the evil of a WhoWas > service to be? Aside from the worst case of wasting admin time and budget I > do not see a real down side to it's existence. Please elucidate. > I do remember the topic being discussed on more than one occasion. > Kevin > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > 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 dmiller at tiggee.com Wed Mar 28 18:26:19 2012 From: dmiller at tiggee.com (David Miller) Date: Wed, 28 Mar 2012 18:26:19 -0400 Subject: [arin-ppml] WhoWas Service Now in ARIN Online Announcement In-Reply-To: <53734.admin@directcolocation.com.1332966440.squirrel@www.directcolocation.com> References: <53734.admin@directcolocation.com.1332966440.squirrel@www.directcolocation.com> Message-ID: <4F73900B.5090804@tiggee.com> On 3/28/2012 4:27 PM, admin at directcolocation.com wrote: > I do agree that it is not a bad thing but I do not see how it is a fair > approach for a new service being applied to the whois at this date > forward, if you were in the business of LAW then it would appear that it > was a law that was being implemented and now would effect you on anything > you have done in the past vrs now that you know making sure that you > govern yourself accordingly. > > I am not a lawyer but I think they call this ex post facto in the fact you > cannot punished for something you did in the past. > > But in this case you may have well done something in the past and now have > to live with it for the rest of your IP life. I do not see how this could > be a fair way to handle the implementation of the information available in > this service, now that you know it exist and or you had some issues in the > past, even if you have cleaned up your act. > > The problem I see is in this case is that as we all know the anti spammers > are not held accountable by any law or in some cases we do not know who > they are and or where they are, so if the have this information at there > disposal. > > Could it put ARIN a position of some kind of liability from a potential > law suite for providing this information based on private business models > and who one chooses to do business with based on the legal side of the > quote can spam act as all spammers will calm they follow. > > The problem could be perceived is that the network operator is being > punished here by unregulated anti spammer groups and thus harming the > business income of that operator by the act of ARIN providing access to > this information to unregulated anti spammer groups, vrs the operators > business income being harmed because of the actions of ARIN providing the > unregulated groups access to the info. > > > Again I am not a lawyer, but this should be considered, because anti > spammers, like spammers hide themselves. With out the ability to regulate > the anti spammers and hold them accountable for there actions of the use > or mis use of this service, while there is some legislation in the can > spam act that has holds the spammers to some accountability. > > I would venture to say in our law suite happy world that some sharp lawyer > might just challenge the use of this service harming an operators business > income and go after the provider of information that caused the harm in > this case ARIN. > > I guess we should consider if any of the other RIR's are doing the same > service because that would negate this concern. > > I am sure they would try to site that as a difference in single out of > ARIN if it came down to that extreme situation. > > > Also do you know if the service will be used on IPV6 whois so as this goes > forward we will be able to have that information there also or is just on > the IPV4 whois > > Donald Mahoney > Network Engineer > Direct Colocation Most of these strike me as "I wouldn't have been speeding if I had known there was a speed trap on this road." arguments. IANAL, but you can most certainly be punished under the law for things that you did in the past. There are limits for many crimes and civil cases - called statutes of limitations / periods of prescription. In the US there is no statute of limitations for many offenses including murder and kidnapping. Ex post facto laws are those that retroactively criminalize actions from the past. We don't allow these in the US, but this is not applicable to this situation. There is no new law here. What you are referring to would probably be better compared to the development of the use of DNA evidence. I am not aware of rules limiting the use of new forms of evidence in investigating events that happened before the form of evidence existed. It isn't a useful defense to say that a person would have been more careful at the crime scene if they had known that DNA collection and matching would be developed and eventually used as evidence against them. -DMM > > On 3/28/12 3:42 PM, "Owen DeLong" wrote: > > It goes back in time and should include all historical whois information > available. > > The only drawback is it prevents someone from denying their history. > Personally, I don't see that as a bad thing. > > Owen > > > Sent from my iPad > > On Mar 28, 2012, at 1:04 PM, admin at directcolocation.com wrote: > > I guess it comes down to the fact of how they the ARIN intends to create > the starting point on this service since it is a new service, does it go > back in the historical past from the inception of the blocks that are > assigned to such or does it go forward from this point of the service > being created. > The key for his concern would be if they had problems in the past with the > anti spammers and continued having the same kind of problem customers, > then I could see the use of this service potential effecting the long term > reputation, since the problem would be that some of the anti spammer > groups that might use the service could refuse to work with this kind of > operator so they could at least clean up there act. > Does anyone know if ARIN intends to start the service from this point > forward and or go back into current historical data from the issuance of > the blocks in the whois. > If they start it from this point on then I would look at it as an > opportunity to get my house in order if you know that this is the kind of > customers you have been targeting. > Donald Mahoney > Network Engineer > Direct Colocation > On 3/28/12 2:31 PM, "Kevin Kargel" wrote: > It appears that after years of being harangued by 'anti-spam' cultists for > access to historic WHOIS data in order to burnish their credentials as > Official Spam Detectives and support their efforts to criminalize > marketing and drag email back to the DARPA era, ARIN has finally thrown in > the towel. I am frankly disappointed. > Has this topic every been discussed? This needs not to be part of the > Disciples of ARIN. I am optimistic this can be reversed pending > discussion. > Nicky Smith > CAROLINANET.COM > 336.346.6000 x105 > I, for one, do not understand what you perceive the evil of a WhoWas service > to be? Aside from the worst case of wasting admin time and budget I do not > see a real down side to it's existence. Please elucidate. > I do remember the topic being discussed on more than one occasion. > Kevin > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > 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 28 23:53:57 2012 From: owen at delong.com (Owen DeLong) Date: Wed, 28 Mar 2012 20:53:57 -0700 Subject: [arin-ppml] WhoWas Service Now in ARIN Online Announcement In-Reply-To: <53734.admin@directcolocation.com.1332966440.squirrel@www.directcolocation.com> References: <53734.admin@directcolocation.com.1332966440.squirrel@www.directcolocation.com> Message-ID: On Mar 28, 2012, at 1:27 PM, admin at directcolocation.com wrote: > I do agree that it is not a bad thing but I do not see how it is a fair > approach for a new service being applied to the whois at this date > forward, if you were in the business of LAW then it would appear that it > was a law that was being implemented and now would effect you on anything > you have done in the past vrs now that you know making sure that you > govern yourself accordingly. > I completely disagree. Nothing being published by ARIN today is anything that ARIN did not publish in the past. In the past anyone could have archived what was published and so there is no new exposure from ARIN making it available today. It is a convenient and useful tool and I really don't believe it is a case of ex post facto as you describe it. > I am not a lawyer but I think they call this ex post facto in the fact you > cannot punished for something you did in the past. ARIN isn't punishing anyone. They are simply re-publishing data that they once published some time ago. Once you give someone your data and permission to make that data public, the data is public. It seems beyond illogical to me for you to think that ARIN should somehow be enjoined from publishing it again at a later date as a historical reference. > The problem I see is in this case is that as we all know the anti spammers > are not held accountable by any law or in some cases we do not know who > they are and or where they are, so if the have this information at there > disposal. > I think it is absurd to make ARIN responsible for all possible uses by any third party of any data that ARIN publishes. ARIN has placed a reasonable AUP around the data and requires authenticated access and active agreement to said AUP prior to access. > Could it put ARIN a position of some kind of liability from a potential > law suite for providing this information based on private business models > and who one chooses to do business with based on the legal side of the > quote can spam act as all spammers will calm they follow. Huh? ARIN is publishing again data ARIN previously published with full permission of the provider of the data. There has never been an expectation of or procedure for one to revoke their permission to publish said data. I just can't figure out how to apply what you are saying to the current context. > The problem could be perceived is that the network operator is being > punished here by unregulated anti spammer groups and thus harming the > business income of that operator by the act of ARIN providing access to > this information to unregulated anti spammer groups, vrs the operators > business income being harmed because of the actions of ARIN providing the > unregulated groups access to the info. If the information was published previously, how is publishing it again an issue here? The alleged unregulated anti-spammer groups of which you appear to be so afraid had access to the data already in the past. > Again I am not a lawyer, but this should be considered, because anti > spammers, like spammers hide themselves. With out the ability to regulate > the anti spammers and hold them accountable for there actions of the use > or mis use of this service, while there is some legislation in the can > spam act that has holds the spammers to some accountability. Given that it requires an ARIN-online account and agreement to an AUP to access the data, I'm not sure how you can claim that a user of this data could hide, but, even if they can, since it's public data, I'm just not sure what the issue could be. > I would venture to say in our law suite happy world that some sharp lawyer > might just challenge the use of this service harming an operators business > income and go after the provider of information that caused the harm in > this case ARIN. You can sue anyone for anything at any time regardless of whether there is any legal basis to do so or not. Such is the nature of our system. However, to me, this is the moral equivalent of the following scenario: 1. Library makes book Q available for lending. 2. Library takes book Q off the shelves for several weeks/months/years. 3. Library again makes book Q available for lending. 4. Some data in book Q is somehow used by party Z to harm the income of business XX. 5. Business XX sues the library for placing book Q back on the shelf. Unless I'm missing something, this is just plain absurd. > I guess we should consider if any of the other RIR's are doing the same > service because that would negate this concern. If they aren't yet, they should definitely be encouraged to do so. However, they operate in entirely different regulatory frameworks with which I am completely unfamiliar. Given some of the stranger things about German privacy laws and pseudo-laws, RIPE might have some issues, for example. > I am sure they would try to site that as a difference in single out of > ARIN if it came down to that extreme situation. I think you mean cite, but, ARIN has often been an innovator among the RIRs, so the fact that we're doing something the other RIRs may not be doing yet really doesn't strike me as all that material to the discussion. > Also do you know if the service will be used on IPV6 whois so as this goes > forward we will be able to have that information there also or is just on > the IPV4 whois I believe it covers all ARIN whois data current and historic. Again, entirely public data that has been published in the past and is being published again. Nothing proprietary, nothing about business relationships that hasn't been disclosed publicly in the past, no new information, and nothing that the provider of the data did not consent to disclosing. Owen From ppml at rsuc.gweep.net Thu Mar 29 07:55:12 2012 From: ppml at rsuc.gweep.net (Joe Provo) Date: Thu, 29 Mar 2012 07:55:12 -0400 Subject: [arin-ppml] WhoWas Service Now in ARIN Online Announcement Message-ID: <20120329115512.GA8287@gweep.net> On Wed, Mar 28, 2012 at 04:27:20PM -0400, admin at directcolocation.com wrote: > I do agree that it is not a bad thing but I do not see how it is a fair > approach for a new service being applied to the whois at this date > forward, if you were in the business of LAW then it would appear that it > was a law that was being implemented and now would effect you on anything > you have done in the past vrs now that you know making sure that you > govern yourself accordingly. > > I am not a lawyer but I think they call this ex post facto in the fact you > cannot punished for something you did in the past. Publishing != punishing. The ARIN community wants the history of published records to be available. Given that the historical data was once 'public', there is nothing new being revealed. If there's shady dealings, frankly that is precisely what the ARIN community wishes to be plainly seen by this historical record. > The problem I see is in this case is that as we all know the anti spammers > are not held accountable by any law or in some cases we do not know who > they are and or where they are, so if the have this information at there > disposal. Seems like you were trying to construct a sentence here but it failed you. You might start by dropping the supposition that anyone in the anti abuse realm is operating outside the law. > Could it put ARIN a position of some kind of liability from a potential > law suite for providing this information based on private business models > and who one chooses to do business with based on the legal side of the > quote can spam act as all spammers will calm they follow. All the whois data was once public. There is nothing in whowas that would be "private business models" or any such claptrap. Your later attempts at sentences make it seem like you wish to defend shady dealings and abuse facilited by obfuscated addressing. If that is the case, then I'm not sorry that this services will inconvenience you. Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG From admin at directcolocation.com Thu Mar 29 09:11:44 2012 From: admin at directcolocation.com (admin at directcolocation.com) Date: Thu, 29 Mar 2012 09:11:44 -0400 (EDT) Subject: [arin-ppml] WhoWas Service Now in ARIN Online Announcement Message-ID: <49520.admin@directcolocation.com.1333026704.squirrel@www.directcolocation.com> It was not my intention to provoke such intense response as I do understand everyone's responses and appreciate them, as they are all valid as I am trying to better understand both sides of the situation. I was only trying to have so theoretical possibilities as to what the original email that started this topic was about. With this in mind I do not support anything that may negatively impact the community and or operators in general, as I am sure we all want, I was merely trying to understand the side of what Nicky stared here with this topic and have feedback from all of you on the different possibilities. Obviously I have that now and understand better the reasons the rational of the responses all of you have offered. I am a first time responder on here and did not intend to provoke such passionate responses, as I was just trying to get involved, and should have chosen a different topic or tried to better understand the service before just jumping in. Donald Mahoney Network Engineer Direct Colocation On 3/29/12 7:55 AM, "Joe Provo" wrote: On Wed, Mar 28, 2012 at 04:27:20PM -0400, admin at directcolocation.com wrote: I do agree that it is not a bad thing but I do not see how it is a fair approach for a new service being applied to the whois at this date forward, if you were in the business of LAW then it would appear that it was a law that was being implemented and now would effect you on anything you have done in the past vrs now that you know making sure that you govern yourself accordingly. I am not a lawyer but I think they call this ex post facto in the fact you cannot punished for something you did in the past. Publishing != punishing. The ARIN community wants the history of published records to be available. Given that the historical data was once 'public', there is nothing new being revealed. If there's shady dealings, frankly that is precisely what the ARIN community wishes to be plainly seen by this historical record. The problem I see is in this case is that as we all know the anti spammers are not held accountable by any law or in some cases we do not know who they are and or where they are, so if the have this information at there disposal. Seems like you were trying to construct a sentence here but it failed you. You might start by dropping the supposition that anyone in the anti abuse realm is operating outside the law. Could it put ARIN a position of some kind of liability from a potential law suite for providing this information based on private business models and who one chooses to do business with based on the legal side of the quote can spam act as all spammers will calm they follow. All the whois data was once public. There is nothing in whowas that would be "private business models" or any such claptrap. Your later attempts at sentences make it seem like you wish to defend shady dealings and abuse facilited by obfuscated addressing. If that is the case, then I'm not sorry that this services will inconvenience you. Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG _______________________________________________ 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 Thu Mar 29 09:26:51 2012 From: jcurran at arin.net (John Curran) Date: Thu, 29 Mar 2012 13:26:51 +0000 Subject: [arin-ppml] Welcome to the ARIN PPML List (was: WhoWas Service Now in ARIN Online Announcement) In-Reply-To: <49520.admin%directcolocation.com.1333026704.squirrel@www.directcolocation.com> References: <49520.admin%directcolocation.com.1333026704.squirrel@www.directcolocation.com> Message-ID: <538F35E5-DC00-47DB-9FFD-D32D0A1CE648@corp.arin.net> On Mar 29, 2012, at 9:11 AM, admin at directcolocation.com wrote: > It was not my intention to provoke such intense response as I do > understand everyone's responses and appreciate them, as they are all valid > as I am trying to better understand both sides of the situation. > > I was only trying to have so theoretical possibilities as to what the > original email that started this topic was about. > > With this in mind I do not support anything that may negatively impact the > community and or operators in general, as I am sure we all want, I was > merely trying to understand the side of what Nicky stared here with this > topic and have feedback from all of you on the different possibilities. > > Obviously I have that now and understand better the reasons the rational > of the responses all of you have offered. > > I am a first time responder on here and did not intend to provoke such > passionate responses, as I was just trying to get involved, and should > have chosen a different topic or tried to better understand the service > before just jumping in. Donald - Welcome to the rather spirited Public Policy Mailing List... :-) Please do not take the responses personally, and I encourage you to continue participating as much as desired (with the recognition that a thick skin may be helpful on occasion when reading the replies...) While the frankness of the replies can make for a raucous discussion, they are generally heartfelt by the senders who mean no harm and are simply trying to make ARIN and its services as useful as possible to the community. Best wishes and thanks for posting your thoughts on this topic! /John John Curran President and CEO ARIN From paul at redbarn.org Thu Mar 29 10:29:47 2012 From: paul at redbarn.org (paul vixie) Date: Thu, 29 Mar 2012 14:29:47 +0000 Subject: [arin-ppml] WhoWas Service Now in ARIN Online Announcement In-Reply-To: References: <53734.admin@directcolocation.com.1332966440.squirrel@www.directcolocation.com> Message-ID: <4F7471DB.8090703@redbarn.org> On 3/29/2012 3:53 AM, Owen DeLong wrote: > On Mar 28, 2012, at 1:27 PM, admin at directcolocation.com wrote: >> I do agree that it is not a bad thing but I do not see how it is a fair >> approach for a new service being applied to the whois at this date >> forward, if you were in the business of LAW then it would appear that it >> was a law that was being implemented and now would effect you on anything >> you have done in the past vrs now that you know making sure that you >> govern yourself accordingly. > I completely disagree. i almost completely disagree but i do see some small merit in the concerns that have been expressed. > Nothing being published by ARIN today is anything that ARIN did not > publish in the past. In the past anyone could have archived what was > published and so there is no new exposure from ARIN making it > available today. when data is available in the aggregate it has different privacy considerations than when it's available only in focus. to see this work in the real world, witness the difference in how people feel about having their picture taken if they know it's going up on the web with full tagging and facial recognition. or how people feel about a picture of their front yard appearing somewhere on the web, vs. having it on google street view. public but unindexed and unaggregated information just does not have the same relationship to "reasonable expectation of privacy" that indexed and tagged and aggregated information does. that having been said... whowas has in my view societal benefits that outweigh its societal costs. noone who has an exclusive right to any internet resource has any reasonable expectation of privacy as to their relationship to that resource, nor the history of that resource's prior exclusive rights holders. paul From owen at delong.com Thu Mar 29 11:13:51 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 29 Mar 2012 08:13:51 -0700 Subject: [arin-ppml] Welcome to the ARIN PPML List (was: WhoWas Service Now in ARIN Online Announcement) In-Reply-To: <538F35E5-DC00-47DB-9FFD-D32D0A1CE648@corp.arin.net> References: <49520.admin%directcolocation.com.1333026704.squirrel@www.directcolocation.com> <538F35E5-DC00-47DB-9FFD-D32D0A1CE648@corp.arin.net> Message-ID: <61D856A7-9A72-4174-AE25-D6DE5E65B166@delong.com> On Mar 29, 2012, at 6:26 AM, John Curran wrote: > On Mar 29, 2012, at 9:11 AM, admin at directcolocation.com wrote: > >> It was not my intention to provoke such intense response as I do >> understand everyone's responses and appreciate them, as they are all valid >> as I am trying to better understand both sides of the situation. >> >> I was only trying to have so theoretical possibilities as to what the >> original email that started this topic was about. >> >> With this in mind I do not support anything that may negatively impact the >> community and or operators in general, as I am sure we all want, I was >> merely trying to understand the side of what Nicky stared here with this >> topic and have feedback from all of you on the different possibilities. >> >> Obviously I have that now and understand better the reasons the rational >> of the responses all of you have offered. >> >> I am a first time responder on here and did not intend to provoke such >> passionate responses, as I was just trying to get involved, and should >> have chosen a different topic or tried to better understand the service >> before just jumping in. > > Donald - > > Welcome to the rather spirited Public Policy Mailing List... :-) > > Please do not take the responses personally, and I encourage you to > continue participating as much as desired (with the recognition that > a thick skin may be helpful on occasion when reading the replies...) > While the frankness of the replies can make for a raucous discussion, > they are generally heartfelt by the senders who mean no harm and are > simply trying to make ARIN and its services as useful as possible to > the community. > > Best wishes and thanks for posting your thoughts on this topic! > /John +1 -- Nothing I said was intended personally. It's all about trying to make things better. Owen From owen at delong.com Thu Mar 29 11:19:27 2012 From: owen at delong.com (Owen DeLong) Date: Thu, 29 Mar 2012 08:19:27 -0700 Subject: [arin-ppml] WhoWas Service Now in ARIN Online Announcement In-Reply-To: <4F7471DB.8090703@redbarn.org> References: <53734.admin@directcolocation.com.1332966440.squirrel@www.directcolocation.com> <4F7471DB.8090703@redbarn.org> Message-ID: <56D12794-911F-4FAF-A7FF-E642AC5BCC08@delong.com> On Mar 29, 2012, at 7:29 AM, paul vixie wrote: > On 3/29/2012 3:53 AM, Owen DeLong wrote: >> On Mar 28, 2012, at 1:27 PM, admin at directcolocation.com wrote: >>> I do agree that it is not a bad thing but I do not see how it is a fair >>> approach for a new service being applied to the whois at this date >>> forward, if you were in the business of LAW then it would appear that it >>> was a law that was being implemented and now would effect you on anything >>> you have done in the past vrs now that you know making sure that you >>> govern yourself accordingly. >> I completely disagree. > > i almost completely disagree but i do see some small merit in the > concerns that have been expressed. > >> Nothing being published by ARIN today is anything that ARIN did not >> publish in the past. In the past anyone could have archived what was >> published and so there is no new exposure from ARIN making it >> available today. > > when data is available in the aggregate it has different privacy > considerations than when it's available only in focus. to see this work > in the real world, witness the difference in how people feel about > having their picture taken if they know it's going up on the web with > full tagging and facial recognition. or how people feel about a picture > of their front yard appearing somewhere on the web, vs. having it on > google street view. > I don't see the privacy concerns of individual whowas queries as being any different from the privacy concerns of individual whois queries. In either case, it is specific, indexed, tied to a particular entity. In one case, it is current information only. In the other, it is current + historical information. In this day and age, if you expect people not to put your public historical information together with your public current information, you are likely to be disappointed on many more fronts than just ARIN. Owen From owen at delong.com Tue Mar 27 21:35:13 2012 From: owen at delong.com (Owen DeLong) Date: Tue, 27 Mar 2012 18:35:13 -0700 Subject: [arin-ppml] WhoWas Service Now in ARIN Online Announcement In-Reply-To: References: Message-ID: On Mar 27, 2012, at 5:59 PM, wrote: >> As send from arin-announce at arin.net on Mon, 26 Mar 2012 10:18:02 -0400 >> >> Subject: WhoWas Service Now in ARIN Online (ARIN) >> From: Mark Kosters, Chief Technical Officer (ARIN) >> >> >> ARIN is pleased to announce the integration of its WhoWas service in >> ARIN Online. ARIN?s WhoWas service provides historical registration >> reports for a given IP address or ASN. WhoWas functionality is >> available to ARIN Online users through the DOWNLOADS option in the >> left navigation. To access this service, users must first submit a >> one-time request to become authorized to access the WhoWas service. >> Once approved, users will need to agree to the WhoWas Terms of Use >> before requesting a report. >> >> Please view https://www.arin.net/resources/whowas/index.html for >> complete details on ARIN?s WhoWas service. > > -- snip -- > > > It appears that after years of being harangued by 'anti-spam' cultists for access to historic WHOIS data in order to burnish their credentials as Official Spam Detectives and support their efforts to criminalize marketing and drag email back to the DARPA era, ARIN has finally thrown in the towel. I am frankly disappointed. > > Has this topic every been discussed? This needs not to be part of the Disciples of ARIN. I am optimistic this can be reversed pending discussion. > It was discussed at numerous ARIN meetings and there was broad support from the community and the membership. Arguably, this was implemented (finally) in spite of ARIN staff doing their best to drag their feet on the implementation because of overwhelming support from the community. Owen From narten at us.ibm.com Fri Mar 30 00:53:02 2012 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 30 Mar 2012 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201203300453.q2U4r2WO013261@rotala.raleigh.ibm.com> Total of 43 messages in the last 7 days. script run at: Fri Mar 30 00:53:02 EDT 2012 Messages | Bytes | Who --------+------+--------+----------+------------------------ 18.60% | 8 | 18.48% | 62772 | owen at delong.com 11.63% | 5 | 11.22% | 38100 | jcurran at arin.net 9.30% | 4 | 9.01% | 30611 | hannigan at gmail.com 6.98% | 3 | 8.60% | 29219 | tvest at eyeconomics.com 6.98% | 3 | 7.84% | 26623 | admin at directcolocation.com 6.98% | 3 | 6.17% | 20962 | mysidia at gmail.com 4.65% | 2 | 3.66% | 12445 | matthew at matthew.at 4.65% | 2 | 3.49% | 11849 | ppml at rsuc.gweep.net 2.33% | 1 | 3.85% | 13089 | dmiller at tiggee.com 2.33% | 1 | 3.82% | 12965 | kkargel at polartel.com 2.33% | 1 | 3.80% | 12891 | kevinb at thewire.ca 2.33% | 1 | 2.46% | 8358 | jrhett at netconsonance.com 2.33% | 1 | 2.44% | 8293 | farmer at umn.edu 2.33% | 1 | 2.19% | 7429 | cja at daydream.com 2.33% | 1 | 1.97% | 6689 | narten at us.ibm.com 2.33% | 1 | 1.97% | 6675 | nicky.smith at guilfordcommunications.com 2.33% | 1 | 1.91% | 6491 | michael+ppml at burnttofu.net 2.33% | 1 | 1.89% | 6431 | gary.buhrmaster at gmail.com 2.33% | 1 | 1.87% | 6349 | paul at redbarn.org 2.33% | 1 | 1.74% | 5925 | jlewis at lewis.org 2.33% | 1 | 1.62% | 5515 | mueller at syr.edu --------+------+--------+----------+------------------------ 100.00% | 43 |100.00% | 339681 | Total From jcurran at arin.net Fri Mar 30 05:32:04 2012 From: jcurran at arin.net (John Curran) Date: Fri, 30 Mar 2012 09:32:04 +0000 Subject: [arin-ppml] WhoWas Service Now in ARIN Online Announcement In-Reply-To: References: Message-ID: <02E5BE87-7E1E-491C-8F36-516B763A97E0@corp.arin.net> On Mar 27, 2012, at 9:35 PM, Owen DeLong wrote: > It was discussed at numerous ARIN meetings and there was broad support from the community and the membership. Arguably, this was implemented (finally) in spite of ARIN staff doing their best to drag their feet on the implementation because of overwhelming support from the community. Owen - I agree that WhoWas implementation moved forward after overwhelming support was demonstrated by the community, but the ARIN staff did not hold up implementation before that time; any delay was simply the result of normal prioritization given our fixed budget each year for development work. A list of the work that was accomplished over that time period may be found here: Thanks! /John John Curran President and CEO ARIN From snowhorn at gmail.com Fri Mar 30 08:04:02 2012 From: snowhorn at gmail.com (JOSHUA SNOWHORN) Date: Fri, 30 Mar 2012 07:04:02 -0500 Subject: [arin-ppml] DRAFT POLICY 2012-3: ASN TRANSFERS Message-ID: in support of 2012-3. The current process via only M&A or Bankruptcy, forces entities to troll for cheap assets or failed companies to acquire an AS that is viewed as favorable. Simply stating a policy to facilitate simple transfers removes the hassle for the few who would do such a transaction and frankly clarifies a market for unused assets. Spend some time digging AS by AS and you will find by far and away too many unused ASN's that in some cases have sat there for decades. I cannot imagine any of us would condone leaving such a limited 2bit asset class as dead in the water because we did not support a written transfer process. Removal of ambiguity is the goal here, from everything I read on the proposed policy change, and that is a good thing. Cheers, Josh Snowhorn From snowhorn at gmail.com Fri Mar 30 11:41:19 2012 From: snowhorn at gmail.com (JOSHUA SNOWHORN) Date: Fri, 30 Mar 2012 10:41:19 -0500 Subject: [arin-ppml] DRAFT POLICY 2012-3: ASN TRANSFERS In-Reply-To: <1120330112006.56017D-100000@Ives.egh.com> References: <1120330112006.56017D-100000@Ives.egh.com> Message-ID: <0AE39222-F337-45DE-B3E3-91A7B9F23E05@gmail.com> On Mar 30, 2012, at 10:31 AM, John Santos wrote: > On Fri, 30 Mar 2012, JOSHUA SNOWHORN wrote: > >> in support of 2012-3. >> > >> The current process via only M&A or Bankruptcy, forces entities to >> troll for cheap assets or failed companies to acquire an AS that is >> viewed as favorable. Simply stating a policy to facilitate simple >> transfers removes the hassle for the few who would do >> such a transaction and frankly clarifies a market for unused assets. >> > > False dichotomy. They have a 3rd option, applying for and receiving a > new AS directly from ARIN. Yes?always available to anyone who qualifies?and a high number AS is just as good as a low number AS. > > Why should any number be viewed as favorably or unfavorably? Unless it > is a very rare special number attached to superstition (7, 13 and 666 > are the only 3 examples I can think of), you must be refering to the > reputation attached to an AS by the business reputation of its former > holder. Rather than inducing clarity, attempting to confuse people by > trading on the reputation of the current or former holder without > acquiring the network, assets, customers or anything else that reputation > was built on, smacks of deception. Regardless of any one individuals superstition or ideas, the fact remains that people like to have lower AS numbers and do feel it somehow represents credibility. Your assumption of the reputation of the previous holder however I do not think brings any bearing to this argument. I think it is just the "old school" credibility of that low AS that matters?.not the previous owners good or bad reputation which is evidenced by the renaming in whole, generally, of the handles associated with that AS. > > >> Spend some time digging AS by AS and you will find by far and away too >> many unused ASN's that in some cases have sat there for decades. I cannot >> imagine any of us would condone leaving such a limited 2bit > > 32bit? There is no current or impending shortage of 32bit ASNs. mea culpa?yes meant 32bit. And yes no shortage?but certainly dead wasted AS's abound?why waste when others want. > >> ... asset class as >> dead in the water because we did not support a written transfer process. >> >> Removal of ambiguity is the goal here, from everything I read on the >> proposed policy change, and that is a good thing. > > This proposal will increase ambiguity, not remove it. How is that? It is defining a process which does not exist today giving ARIN the ability to manage something properly without throwing up their hands and saying sorry but we can't... > >> >> Cheers, >> >> Josh Snowhorn > > -- > John Santos > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 > Josh From jeffrey.lyon at blacklotus.net Fri Mar 30 11:43:37 2012 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 30 Mar 2012 11:43:37 -0400 Subject: [arin-ppml] DRAFT POLICY 2012-3: ASN TRANSFERS In-Reply-To: <0AE39222-F337-45DE-B3E3-91A7B9F23E05@gmail.com> References: <1120330112006.56017D-100000@Ives.egh.com> <0AE39222-F337-45DE-B3E3-91A7B9F23E05@gmail.com> Message-ID: On Fri, Mar 30, 2012 at 11:41 AM, JOSHUA SNOWHORN wrote: > > On Mar 30, 2012, at 10:31 AM, John Santos wrote: > >> On Fri, 30 Mar 2012, JOSHUA SNOWHORN wrote: >> >>> in support of 2012-3. >>> >> >>> The current process via only M&A or Bankruptcy, forces entities to >>> troll for cheap assets or failed companies to acquire an AS that is >>> viewed as favorable. Simply stating a policy to facilitate simple >>> transfers removes the hassle for the few who would do >>> such a transaction and frankly clarifies a market for unused assets. >>> >> >> False dichotomy. ?They have a 3rd option, applying for and receiving a >> new AS directly from ARIN. > > Yes?always available to anyone who qualifies?and a high number AS is just as good as a low number AS. > >> >> Why should any number be viewed as favorably or unfavorably? ?Unless it >> is a very rare special number attached to superstition (7, 13 and 666 >> are the only 3 examples I can think of), you must be refering to the >> reputation attached to an AS by the business reputation of its former >> holder. ?Rather than inducing clarity, attempting to confuse people by >> trading on the reputation of the current or former holder without >> acquiring the network, assets, customers or anything else that reputation >> was built on, smacks of deception. > > Regardless of any one individuals superstition or ideas, the fact remains that people like to have lower AS numbers and do feel it somehow represents credibility. Your assumption of the reputation of the previous holder however I do not think brings any bearing to this argument. I think it is just the "old school" credibility of that low AS that matters?.not the previous owners good or bad reputation which is evidenced by the renaming in whole, generally, of the handles associated with that AS. > >> >> >>> Spend some time digging AS by AS and you will find by far and away too >>> many unused ASN's that in some cases have sat there for decades. I cannot >>> imagine any of us would condone leaving such a limited 2bit >> >> 32bit? ?There is no current or impending shortage of 32bit ASNs. > > mea culpa?yes meant 32bit. And yes no shortage?but certainly dead wasted AS's abound?why waste when others want. > >> >>> ?... ?asset class as >>> dead in the water because we did not support a written transfer process. >>> >>> Removal of ambiguity is the goal here, from everything I read on the >>> proposed policy change, and that is a good thing. >> >> This proposal will increase ambiguity, not remove it. > > How is that? It is defining a process which does not exist today giving ARIN the ability to manage something properly without throwing up their hands and saying sorry but we can't... > >> >>> >>> Cheers, >>> >>> Josh Snowhorn >> >> -- >> John Santos >> Evans Griffiths & Hart, Inc. >> 781-861-0670 ext 539 >> > > Josh > _______________________________________________ > 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 disagree that continually adding more bits as decades pass is the solution to all resource shortages. Regardless of whether we have 2, 4, 8, etc bits we should have policies in effect which allow for more efficient use (eg. transfers). My two cents. -- 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 JOHN at egh.com Fri Mar 30 11:31:35 2012 From: JOHN at egh.com (John Santos) Date: Fri, 30 Mar 2012 11:31:35 -0400 Subject: [arin-ppml] DRAFT POLICY 2012-3: ASN TRANSFERS In-Reply-To: Message-ID: <1120330112006.56017D-100000@Ives.egh.com> On Fri, 30 Mar 2012, JOSHUA SNOWHORN wrote: > in support of 2012-3. > > The current process via only M&A or Bankruptcy, forces entities to > troll for cheap assets or failed companies to acquire an AS that is > viewed as favorable. Simply stating a policy to facilitate simple > transfers removes the hassle for the few who would do > such a transaction and frankly clarifies a market for unused assets. > False dichotomy. They have a 3rd option, applying for and receiving a new AS directly from ARIN. Why should any number be viewed as favorably or unfavorably? Unless it is a very rare special number attached to superstition (7, 13 and 666 are the only 3 examples I can think of), you must be refering to the reputation attached to an AS by the business reputation of its former holder. Rather than inducing clarity, attempting to confuse people by trading on the reputation of the current or former holder without acquiring the network, assets, customers or anything else that reputation was built on, smacks of deception. > Spend some time digging AS by AS and you will find by far and away too > many unused ASN's that in some cases have sat there for decades. I cannot > imagine any of us would condone leaving such a limited 2bit 32bit? There is no current or impending shortage of 32bit ASNs. > ... asset class as > dead in the water because we did not support a written transfer process. > > Removal of ambiguity is the goal here, from everything I read on the > proposed policy change, and that is a good thing. This proposal will increase ambiguity, not remove it. > > Cheers, > > Josh Snowhorn -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From michael+ppml at burnttofu.net Fri Mar 30 12:12:16 2012 From: michael+ppml at burnttofu.net (Michael Sinatra) Date: Fri, 30 Mar 2012 09:12:16 -0700 Subject: [arin-ppml] DRAFT POLICY 2012-3: ASN TRANSFERS In-Reply-To: References: <1120330112006.56017D-100000@Ives.egh.com> <0AE39222-F337-45DE-B3E3-91A7B9F23E05@gmail.com> Message-ID: <4F75DB60.50702@burnttofu.net> On 3/30/12 8:43 AM, Jeffrey Lyon wrote: > I disagree that continually adding more bits as decades pass is the > solution to all resource shortages. Regardless of whether we have 2, > 4, 8, etc bits we should have policies in effect which allow for more > efficient use (eg. transfers). > > My two cents. With respect to ASNs, that horse has already left the barn. 32-bit ASNs are commonly being assigned in other regions, and the standard is already supported in vendor equipment. There may still be issues with actual carrier support of 32-bit ASNs, but if you really think we shouldn't be adding bits to ASNs, you have long ago lost that argument. michael From adudek16 at gmail.com Fri Mar 30 12:13:29 2012 From: adudek16 at gmail.com (Aaron Dudek) Date: Fri, 30 Mar 2012 12:13:29 -0400 Subject: [arin-ppml] DRAFT POLICY 2012-3: ASN TRANSFERS In-Reply-To: <0AE39222-F337-45DE-B3E3-91A7B9F23E05@gmail.com> References: <1120330112006.56017D-100000@Ives.egh.com> <0AE39222-F337-45DE-B3E3-91A7B9F23E05@gmail.com> Message-ID: On Fri, Mar 30, 2012 at 11:41, JOSHUA SNOWHORN wrote: > > On Mar 30, 2012, at 10:31 AM, John Santos wrote: > >> On Fri, 30 Mar 2012, JOSHUA SNOWHORN wrote: >> >>> in support of 2012-3. >>> >> >>> The current process via only M&A or Bankruptcy, forces entities to >>> troll for cheap assets or failed companies to acquire an AS that is >>> viewed as favorable. Simply stating a policy to facilitate simple >>> transfers removes the hassle for the few who would do >>> such a transaction and frankly clarifies a market for unused assets. >>> >> >> False dichotomy. ?They have a 3rd option, applying for and receiving a >> new AS directly from ARIN. > > Yes?always available to anyone who qualifies?and a high number AS is just as good as a low number AS. > >> >> Why should any number be viewed as favorably or unfavorably? ?Unless it >> is a very rare special number attached to superstition (7, 13 and 666 >> are the only 3 examples I can think of), you must be refering to the >> reputation attached to an AS by the business reputation of its former >> holder. ?Rather than inducing clarity, attempting to confuse people by >> trading on the reputation of the current or former holder without >> acquiring the network, assets, customers or anything else that reputation >> was built on, smacks of deception. > > Regardless of any one individuals superstition or ideas, the fact remains that people like to have lower AS numbers and do feel it somehow represents credibility. Your assumption of the reputation of the previous holder however I do not think brings any bearing to this argument. I think it is just the "old school" credibility of that low AS that matters?.not the previous owners good or bad reputation which is evidenced by the renaming in whole, generally, of the handles associated with that AS. > >> >> >>> Spend some time digging AS by AS and you will find by far and away too >>> many unused ASN's that in some cases have sat there for decades. I cannot >>> imagine any of us would condone leaving such a limited 2bit >> >> 32bit? ?There is no current or impending shortage of 32bit ASNs. > > mea culpa?yes meant 32bit. And yes no shortage?but certainly dead wasted AS's abound?why waste when others want. > How are determining that these are wasted? Just because they are not seen doesn't imply not used. Yes there are other ways of using ASN if not going to connect to the internet. >> >>> ?... ?asset class as >>> dead in the water because we did not support a written transfer process. >>> >>> Removal of ambiguity is the goal here, from everything I read on the >>> proposed policy change, and that is a good thing. >> >> This proposal will increase ambiguity, not remove it. > > How is that? It is defining a process which does not exist today giving ARIN the ability to manage something properly without throwing up their hands and saying sorry but we can't... > >> >>> >>> Cheers, >>> >>> Josh Snowhorn >> >> -- >> John Santos >> Evans Griffiths & Hart, Inc. >> 781-861-0670 ext 539 >> > > Josh > _______________________________________________ > 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. Aaron Dudek From michael+ppml at burnttofu.net Fri Mar 30 12:28:05 2012 From: michael+ppml at burnttofu.net (Michael Sinatra) Date: Fri, 30 Mar 2012 09:28:05 -0700 Subject: [arin-ppml] DRAFT POLICY 2012-3: ASN TRANSFERS In-Reply-To: <0AE39222-F337-45DE-B3E3-91A7B9F23E05@gmail.com> References: <1120330112006.56017D-100000@Ives.egh.com> <0AE39222-F337-45DE-B3E3-91A7B9F23E05@gmail.com> Message-ID: <4F75DF15.7060509@burnttofu.net> On 3/30/12 8:41 AM, JOSHUA SNOWHORN wrote: >>> Why should any number be viewed as favorably or unfavorably? >>> Unless it is a very rare special number attached to superstition >>> (7, 13 and 666 are the only 3 examples I can think of), you must >>> be refering to the reputation attached to an AS by the business >>> reputation of its former holder. Rather than inducing clarity, >>> attempting to confuse people by trading on the reputation of the >>> current or former holder without acquiring the network, assets, >>> customers or anything else that reputation was built on, smacks >>> of deception. > Regardless of any one individuals superstition or ideas, the fact > remains that people like to have lower AS numbers and do feel it > somehow represents credibility. Your assumption of the reputation of > the previous holder however I do not think brings any bearing to this > argument. I think it is just the "old school" credibility of that low > AS that matters?.not the previous owners good or bad reputation which > is evidenced by the renaming in whole, generally, of the handles > associated with that AS. You seem to be saying that it's not actual reputation that is being traded, but some sort of misperception that ASNs in a certain number range bring credibility. So rather than trade on actual reputation (which I would question in itself), you are advocating creating a market where a fake perception of reputation is what's traded. That doesn't sound to me like a market that will efficiently allocate resources, although it may efficiently allocate misperception. IPv4 number transfers make sense. IPv6 number transfers do not. I am on the fence about ASN transfers, but it's arguments like these in favor that are making me increasingly wary. michael From snowhorn at gmail.com Fri Mar 30 12:28:33 2012 From: snowhorn at gmail.com (Joshua Snowhorn) Date: Fri, 30 Mar 2012 13:28:33 -0300 Subject: [arin-ppml] DRAFT POLICY 2012-3: ASN TRANSFERS In-Reply-To: References: <1120330112006.56017D-100000@Ives.egh.com> <0AE39222-F337-45DE-B3E3-91A7B9F23E05@gmail.com> Message-ID: <99CEAEC0-2578-4D6C-8EFF-53DA691F129D@gmail.com> On Mar 30, 2012, at 1:13 PM, Aaron Dudek wrote: >> >>> >>> >>>> Spend some time digging AS by AS and you will find by far and away too >>>> many unused ASN's that in some cases have sat there for decades. I cannot >>>> imagine any of us would condone leaving such a limited 2bit >>> >>> 32bit? There is no current or impending shortage of 32bit ASNs. >> >> mea culpa?yes meant 32bit. And yes no shortage?but certainly dead wasted AS's abound?why waste when others want. >> > > How are determining that these are wasted? Just because they are not > seen doesn't imply not used. Yes there are other ways of using ASN if > not going to connect to the internet. > No doubt there are many AS assets being used for different purposes, but to think there are not unused AS assets out there is silly. The process for getting an AS is not prohibitive today and was certainly not in the past, which has invariably led to a tiny bit of hoarding. But let's be clear here...I think we are talking about a companies or institutions ability to transfer an asset they are not using. Not the semantics of it being wasted or not, which is up to all of our lofty interpretations. >> >>> >>>> >>>> Cheers, >>>> >>>> Josh Snowhorn >>> >>> -- >>> John Santos >>> Evans Griffiths & Hart, Inc. >>> 781-861-0670 ext 539 >>> >> >> Josh >> _______________________________________________ >> 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. > > Aaron Dudek Josh From snowhorn at gmail.com Fri Mar 30 12:41:01 2012 From: snowhorn at gmail.com (Joshua Snowhorn) Date: Fri, 30 Mar 2012 13:41:01 -0300 Subject: [arin-ppml] DRAFT POLICY 2012-3: ASN TRANSFERS In-Reply-To: <4F75DF15.7060509@burnttofu.net> References: <1120330112006.56017D-100000@Ives.egh.com> <0AE39222-F337-45DE-B3E3-91A7B9F23E05@gmail.com> <4F75DF15.7060509@burnttofu.net> Message-ID: <44870666-F333-47E0-81F2-C7C26187B04F@gmail.com> On Mar 30, 2012, at 1:28 PM, Michael Sinatra wrote: > On 3/30/12 8:41 AM, JOSHUA SNOWHORN wrote: > >>>> Why should any number be viewed as favorably or unfavorably? >>>> Unless it is a very rare special number attached to superstition >>>> (7, 13 and 666 are the only 3 examples I can think of), you must >>>> be refering to the reputation attached to an AS by the business >>>> reputation of its former holder. Rather than inducing clarity, >>>> attempting to confuse people by trading on the reputation of the >>>> current or former holder without acquiring the network, assets, >>>> customers or anything else that reputation was built on, smacks >>>> of deception. > >> Regardless of any one individuals superstition or ideas, the fact >> remains that people like to have lower AS numbers and do feel it >> somehow represents credibility. Your assumption of the reputation of >> the previous holder however I do not think brings any bearing to this >> argument. I think it is just the "old school" credibility of that low >> AS that matters?.not the previous owners good or bad reputation which >> is evidenced by the renaming in whole, generally, of the handles >> associated with that AS. > > You seem to be saying that it's not actual reputation that is being > traded, but some sort of misperception that ASNs in a certain number > range bring credibility. So rather than trade on actual reputation > (which I would question in itself), you are advocating creating a market > where a fake perception of reputation is what's traded. That doesn't > sound to me like a market that will efficiently allocate resources, > although it may efficiently allocate misperception. I said "somehow represents credibility". Not saying it gives it...but if it is just cool or does infer credibility (I agree that is lame), a person or company should have the benefit, perceived or factual, of acquiring said asset if another party has no need for it. No harm done to anyone and instead a benefit for the new user...in their own minds :) > > IPv4 number transfers make sense. IPv6 number transfers do not. I am > on the fence about ASN transfers, but it's arguments like these in favor > that are making me increasingly wary. Can't fault you here...but I would argue that should let market forces dictate this and have a process for it to occur should it ever end up existing. Frankly the volume and value of that market will likey be tiny. > > michael Josh From ppml at rsuc.gweep.net Fri Mar 30 12:42:15 2012 From: ppml at rsuc.gweep.net (Joe Provo) Date: Fri, 30 Mar 2012 12:42:15 -0400 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> References: <4F60B42E.9040101@arin.net> <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> Message-ID: <20120330164215.GA69699@gweep.net> On Fri, Mar 16, 2012 at 11:11:02AM -0400, Tom Vest wrote: > There are lots of compelling reasons to support ASN transfers, > depending on what one hopes to accomplish: [snip] TV put it better than I could. I'm amused that "legitimate use cases for transferring ASNs" in the proposal was asserted without example nor further justification. Nothing compelling has emerged here IMO; making a market for the sake of making a market smacks of making 'enhanced financial products' out of derivatives. Opposed. If there is a fear of hoarded 16bit ASNs, incent return. The question of 'why ARIN region lags behind in 32bit uptake' deserves separate detailed attention beyond supposition and anecdotes. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG From scottleibrand at gmail.com Fri Mar 30 12:54:00 2012 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 30 Mar 2012 09:54:00 -0700 Subject: [arin-ppml] DRAFT POLICY 2012-3: ASN TRANSFERS In-Reply-To: <4F75DF15.7060509@burnttofu.net> References: <1120330112006.56017D-100000@Ives.egh.com> <0AE39222-F337-45DE-B3E3-91A7B9F23E05@gmail.com> <4F75DF15.7060509@burnttofu.net> Message-ID: <21CD3214-FEA6-44A5-AFE5-47CBF579F962@gmail.com> On Mar 30, 2012, at 9:28 AM, Michael Sinatra wrote: > > You seem to be saying that it's not actual reputation that is being > traded, but some sort of misperception that ASNs in a certain number > range bring credibility. So rather than trade on actual reputation > (which I would question in itself), you are advocating creating a market > where a fake perception of reputation is what's traded. That doesn't > sound to me like a market that will efficiently allocate resources, > although it may efficiently allocate misperception. > > IPv4 number transfers make sense. IPv6 number transfers do not. I am > on the fence about ASN transfers, but it's arguments like these in favor > that are making me increasingly wary. IMO it's not about reputation, it's about ease of use. A shorter ASN is easier to remember, say, and recognize. When I was setting up peering at a former job, we needed a new ASN for the peering network, and had a few unused ASNs to choose from. We chose the one that was easiest for humans (22212). If we could've easily acquired a 3-digit ASN instead, that would've been even better. There are fewer than 9999 companies doing peering at IXs, and likely fewer than 999 that have more than a few dozen peers. IMO there's no good reason any of them should have to use a hard-to-remember random 5-digit ASN for peering if they don't want to. -Scott From farmer at umn.edu Fri Mar 30 17:39:16 2012 From: farmer at umn.edu (David Farmer) Date: Fri, 30 Mar 2012 16:39:16 -0500 Subject: [arin-ppml] DRAFT POLICY 2012-3: ASN TRANSFERS In-Reply-To: <21CD3214-FEA6-44A5-AFE5-47CBF579F962@gmail.com> References: <1120330112006.56017D-100000@Ives.egh.com> <0AE39222-F337-45DE-B3E3-91A7B9F23E05@gmail.com> <4F75DF15.7060509@burnttofu.net> <21CD3214-FEA6-44A5-AFE5-47CBF579F962@gmail.com> Message-ID: <4F762804.6070100@umn.edu> On 3/30/12 11:54 CDT, Scott Leibrand wrote: > On Mar 30, 2012, at 9:28 AM, Michael Sinatra wrote: >> You seem to be saying that it's not actual reputation that is being >> traded, but some sort of misperception that ASNs in a certain number >> range bring credibility. So rather than trade on actual reputation >> (which I would question in itself), you are advocating creating a market >> where a fake perception of reputation is what's traded. That doesn't >> sound to me like a market that will efficiently allocate resources, >> although it may efficiently allocate misperception. >> >> IPv4 number transfers make sense. IPv6 number transfers do not. I am >> on the fence about ASN transfers, but it's arguments like these in favor >> that are making me increasingly wary. > > IMO it's not about reputation, it's about ease of use. A shorter ASN is easier to remember, say, and recognize. When I was setting up peering at a former job, we needed a new ASN for the peering network, and had a few unused ASNs to choose from. We chose the one that was easiest for humans (22212). If we could've easily acquired a 3-digit ASN instead, that would've been even better. > > There are fewer than 9999 companies doing peering at IXs, and likely fewer than 999 that have more than a few dozen peers. IMO there's no good reason any of them should have to use a hard-to-remember random 5-digit ASN for peering if they don't want to. > > -Scott This Human Factors based argument makes sense to me. It is on par with making IPv6 allocations on nibble boundaries and the fact that IPv6 has zero suppression, because they also makes things easier for Humans. Until the Internet starts building itself, Human Factors are always going to be an issue to some degree or another. Number are just numbers to computers. However, when Humans interact with the numbers as part of the system, smaller or easy to remember longer sequences will be better and less likely to cause transcription or other Human based errors. -- =============================================== 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 kkargel at polartel.com Fri Mar 30 18:17:30 2012 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 30 Mar 2012 17:17:30 -0500 Subject: [arin-ppml] WhoWas Service Now in ARIN Online Announcement In-Reply-To: <02E5BE87-7E1E-491C-8F36-516B763A97E0@corp.arin.net> References: <02E5BE87-7E1E-491C-8F36-516B763A97E0@corp.arin.net> Message-ID: <8695009A81378E48879980039EEDAD28011E05E51A@MAIL1.polartel.local> I just wanted to chime in and share that whowas was useful for me today. I was able to verify that an address that was in my RBL had recently changed hands (to a different country even) so I was able to delist it for the new operators of a polluted IP address. This was a very legitimate use that imho was actually to the benefit of a new ethical mailing list operator. It may prove in the future to need to be re-listed, but today it gave me justification to give them the benefit of a doubt. Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4935 bytes Desc: not available URL: From heather.skanks at gmail.com Fri Mar 30 21:11:40 2012 From: heather.skanks at gmail.com (Heather Schiller) Date: Fri, 30 Mar 2012 21:11:40 -0400 Subject: [arin-ppml] WhoWas Service Now in ARIN Online Announcement In-Reply-To: <02E5BE87-7E1E-491C-8F36-516B763A97E0@corp.arin.net> References: <02E5BE87-7E1E-491C-8F36-516B763A97E0@corp.arin.net> Message-ID: Almost 4 years is a huge delay! After the big stink in October, it got done in 5 months. I'm thrilled it's done, ecstatic even. I'm really grateful to ARIN staff. You saved us from having to make t-shirts for the meeting next month. I get that ARIN has a limited budget, but it makes me concerned about other, bigger projects.. like RPKI. I don't want to wait a decade for that :) https://www.arin.net/participate/acsp/suggestions/2008-15.html --Heather On Fri, Mar 30, 2012 at 5:32 AM, John Curran wrote: > On Mar 27, 2012, at 9:35 PM, Owen DeLong wrote: > >> It was discussed at numerous ARIN meetings and there was broad support from the community and the membership. Arguably, this was implemented (finally) in spite of ARIN staff doing their best to drag their feet on the implementation because of overwhelming support from the community. > > Owen - > > ?I agree that WhoWas implementation moved forward after overwhelming > ?support was demonstrated by the community, but the ARIN staff did > ?not hold up implementation before that time; any delay was simply > ?the result of normal prioritization given our fixed budget each year > ?for development work. ?A list of the work that was accomplished over > ?that time period may be found here: > > Thanks! > /John > > John Curran > President and CEO > 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 tvest at eyeconomics.com Sat Mar 31 14:45:19 2012 From: tvest at eyeconomics.com (Tom Vest) Date: Sat, 31 Mar 2012 14:45:19 -0400 Subject: [arin-ppml] DRAFT POLICY 2012-3: ASN TRANSFERS In-Reply-To: <4F762804.6070100@umn.edu> References: <1120330112006.56017D-100000@Ives.egh.com> <0AE39222-F337-45DE-B3E3-91A7B9F23E05@gmail.com> <4F75DF15.7060509@burnttofu.net> <21CD3214-FEA6-44A5-AFE5-47CBF579F962@gmail.com> <4F762804.6070100@umn.edu> Message-ID: <841AF67E-5A7D-41DE-8A43-6877303FBE85@eyeconomics.com> On Mar 30, 2012, at 5:39 PM, David Farmer wrote: > > > On 3/30/12 11:54 CDT, Scott Leibrand wrote: >> On Mar 30, 2012, at 9:28 AM, Michael Sinatra wrote: >>> You seem to be saying that it's not actual reputation that is being >>> traded, but some sort of misperception that ASNs in a certain number >>> range bring credibility. So rather than trade on actual reputation >>> (which I would question in itself), you are advocating creating a market >>> where a fake perception of reputation is what's traded. That doesn't >>> sound to me like a market that will efficiently allocate resources, >>> although it may efficiently allocate misperception. >>> >>> IPv4 number transfers make sense. IPv6 number transfers do not. I am >>> on the fence about ASN transfers, but it's arguments like these in favor >>> that are making me increasingly wary. >> >> IMO it's not about reputation, it's about ease of use. A shorter ASN is easier to remember, say, and recognize. When I was setting up peering at a former job, we needed a new ASN for the peering network, and had a few unused ASNs to choose from. We chose the one that was easiest for humans (22212). If we could've easily acquired a 3-digit ASN instead, that would've been even better. >> >> There are fewer than 9999 companies doing peering at IXs, and likely fewer than 999 that have more than a few dozen peers. IMO there's no good reason any of them should have to use a hard-to-remember random 5-digit ASN for peering if they don't want to. >> >> -Scott > > This Human Factors based argument makes sense to me. It is on par with making IPv6 allocations on nibble boundaries and the fact that IPv6 has zero suppression, because they also makes things easier for Humans. Until the Internet starts building itself, Human Factors are always going to be an issue to some degree or another. > > Number are just numbers to computers. However, when Humans interact with the numbers as part of the system, smaller or easy to remember longer sequences will be better and less likely to cause transcription or other Human based errors. Hi David, Please consider the following two counterarguments. First, while the "human factors" interest does indeed merit consideration, the relative ease of remembering a five-digit vs. ten-digit number is hardly the only or even the most important interest at stake in how ASes are distributed. ISTM that a routed prefix' is ultimately operationally "authenticated" by means of/reference to its origin-AS (though this may have been easy for many to forget during the last decade of non-transferable IPv4 and rapidly proliferating single prefix-originating singlehomed ASes) -- and the ASes themselves are currently "authenticated" through the RIR needs-based allocation procedure. Sure, today some ASNs are short and easier both to remember and configure, while others are long and give some people discomfort -- but changing the mechanisms through which they're distributed would affect much more than just the quantity of "easy numbers" available to the AS-seeking population. As an analogy, one might consider the relationship between automobiles and license plates in the United States. The contents of the "authentication" embodied in different license tokens (plates, stickers, etc.) may vary from state to state, but they all play some kind of role in attesting not just to the "uniqueness" of a car, but also to the unique relationship between each vehicle and the party that bears ultimate responsibility for how it is used. Basically that's what "authentication" means. A trip down any US street clearly reveals both that "human factors" influence people's tastes in this numbering domain as well, and also that the some kind of mechanism exists to accommodate those differences in tastes. Everywhere, demand seems to be especially high for certain kinds of license strings (esp. anything related to the home-team), and no doubt there are many people who might be willing to pay a large premium to obtain an especially pithy license string from whomever currently possesses it. But the question is: even assuming that you are one of those persons who would be willing to pay a lot to acquire someone else's vanity license plate without actually acquiring the attached car, would you be better off *as a driver* if the law allowed you to buy and sell license plates at will with anyone at any time for any reason, so long as the other party is willing to strike a deal? Apart from simplifying your quest for a license string that that uniquely satisfies your own personal preferences, can you imagine how else might that change affect your life as a driver -- e.g., incidence of auto-related theft and other crimes, cost and availability of insurance, etc. etc.? (Note: bonus points if you can further imagine how this situation might differ if the cars in question were just as capable of causing damage as conventional autos are today, but in additional were invisible, ephemeral, and could appear and/or disappear at will anywhere in the world, like ASNs...) Second, while again the "human factors" interest does indeed deserve serious consideration -- esp. during a technology's design phase -- when the context is market rather than technology design, it's important to distinguish between factors that might make certain market alternative(s) more or less useful/valuable to some market participants but not others -- i.e., about which opinions can vary both across individuals and even within individual market participants over time (as people change their minds) -- vs. factors that would have the same kind of effect but universally, i.e., which would cause *all* market participants to agree that one kind of factor is absolutely more valuable/useful or "superior" to any alternative. I'd argue that this distinction is especially important to recognize and understand when considering network-related markets, and double-plus important to take into account during times of "market transition" (such as the one we'll undergo as the ASN16 pool is exhausted), because at such moments a flawed market might cause the former kind of variable/transient preferences (i.e., "personal tastes") to harden into the latter sort of uniform judgment, causing the absolute rejection/market failure/technical non-viability of the less favored alternative. If that seems too abstract, try out this example. How do you feel about CIDR today? As a veteran of the classful networking days, do you feel that it took more effort to learn CIDR and more time/effort/$$$ to actually transition to CIDR (and IDR in general) than it would have to just continue on as before with classful networking forever -- *if* that option had been available to you? Do you think that, instead of migrating directly to CIDR, things would have turned out better if the Class A and B holders of the early 1990s had held off on CIDR adoption for a while in order to try out IPv4 privatization and see how high aspiring customers would bid up the price of ever-scarcer classful prefixes? Since the value of anyone else adopting CIDR *before* the largest providers of the time had signaled their absolute commitment to go that way would have been marginal if not negative, how do you think that minor accommodation of "human factors" would have affected the timing of CIDR adoption? Would the net effect of that minor change have been positive or negative, and for who? In the end you may still feel that the benefits of embracing ASN transfers outweigh the dangers; I just ask that you recognize and consider both. Thanks, TV From tvest at eyeconomics.com Sat Mar 31 14:48:21 2012 From: tvest at eyeconomics.com (Tom Vest) Date: Sat, 31 Mar 2012 14:48:21 -0400 Subject: [arin-ppml] Draft Policy 2012-3: ASN Transfers In-Reply-To: References: <4F60B42E.9040101@arin.net> <7210C63D-FEFA-4530-944F-7338BE5A7D5A@eyeconomics.com> <4F63891F.7010005@umn.edu> <4AB26D9E-56D2-47EC-8CE2-1352F0D7580C@eyeconomics.com> <4F6D1499.9010909@matthew.at> <4F6D4788.3000907@matthew.at> Message-ID: On Mar 26, 2012, at 3:51 PM, Martin Hannigan wrote: > On Sat, Mar 24, 2012 at 12:03 AM, Matthew Kaufman wrote: >> On 3/23/2012 8:18 PM, Owen DeLong wrote: >>> >>> On Mar 23, 2012, at 5:26 PM, Matthew Kaufman wrote: >>> >>>> On 3/16/2012 2:23 PM, Tom Vest wrote: >>>>> >>>>> The knowledge that route (a) was originated by AS (x) is only meaningful >>>>> insofar as one has some set of high-confidence beliefs/expectations about AS >>>>> (x). However, if AS (x) can change hands at will, henceforth no such >>>>> confidence will be possible for the overwhelming majority if not all ASes. >>>> >>>> I would point out that this fact is *already* true, as ASNs are >>>> transferred through merger and acquisition all the time, and have been for >>>> over a decade. >>>> >>>> I don't see anyone proposing a policy where an entity is required to >>>> return (and have permanently marked as unavailable) their ASN when ownership >>>> changes... I see, for instance, that AS 1 and AS 701 are still out there, >>>> despite the above happening several times, and yet nothing terrible has >>>> happened as a result. >>>> >>> I don't see acquiring the reputation of a network when acquiring the >>> entire network as being all that likely to be harmful. >> >> >> What makes you think that ASNs acquired through M&A transfer always come >> with "the entire network"? >> >> >> >>> At the time of acquisition, the network is still behaving according to >>> its reputation and what is done will cause necessary modifications to that >>> reputation as time goes by. >> >> >> Yes. Perhaps immediately, as the new owners are of course entirely different >> people with likely different motivations. The network might immediately have >> vastly different traffic patterns. Etc. >> >> >>> >>> On the other hand, I can see tremendous potential for mischief when >>> acquiring an AS Number on the open market without having to take on the >>> operation of said network as part of the package. >> >> >> No different than the current situation. You simply make more money for the >> lawyers when you require that it use the M&A transfer process. >> >> >>> I think these are very different scenarios. >>> >>> Again, I think we're seeing enough problems created by allowing transfers >>> with IPv4 addresses >> >> >> Really? What problems are those? From where I sit, I've seen none. >> >> And are those any different than the problems that already existed with >> transfers of IPv4 addresses via M&A transfer? > > > I've said similar things in this thread and I'll simply add +1. > > What we seem to be talking about here, at least from the counter > argument perspective, is a desire to regulate business process instead > of providing a technically sound and useful mechanism to enable ASN > transfers. As someone involved in peering with literally hundreds of > networks, I'm not convinced that there is a risk that I need to be so > concerned about that I would want to disallow ASN transfers, > especially without a single real life incident that is compelling > enough to warrant a change in thought. > > Adopting this policy will allow ARIN to "get out of the way" and > legitimize what's already transpiring on a regular basis. This is a > good thing. > > > Best, > > -M< Hi Marty, As someone who has had similar peering responsibilities in the past, I was initially surprised by your statement. But then I remembered all of the other unique advantages that you enjoy that would tend to reduce your own risks of operating in an environment of "unsecured" ASes (or ASes with private, commercial-only authentication), but which would do nothing to reduce those risks for anyone else. If every network operator had both bilateral contractual relations with thousands of other network operators spread across every continent, and also operated the equivalent of their own private looking glasses and 24x7x365 active/passive network monitoring infrastructure within each of those thousands of locations, there probably wouldn't be a strong argument for any kind of standardized, "official" third-party mechanism for authenticating number resource recipients (like the RIRs) to exist at all. However, very few operators will ever possess such capabilities. And because of that, the official/standardized/public AS authentication function that is currently performed by the RIRs is going to continue to be critical to the general security of the operating environment for the foreseeable future -- unless perhaps you're willing to provide the global operator community with unrestricted access to all of your global monitoring infrastructure in perpetuity ;-) If adopted, an ASN transfer proposal like the one under discussion would inevitably contribute to the accelerated erosion of that third-party authentication mechanism that (almost) everyone has to rely on. As a thought experiment, I urge you to consider how you might feel if you *were not* actively "involved in peering with literally hundreds of networks," and *could not* rely on Akamai's unique private capabilities as a complete substitute for the identification/authentication mechanisms that are embodied in current AS distribution policies. Thanks, TV