Thanks, Rudi. That is very valuable feedback regarding the current situation in some parts of the ARIN region.
-Scott On Friday, January 31, 2014, Rudolph Daniel <[email protected]> wrote: > Two networks connecting are not necessarily private peers. > In the small Caribbean states, although there seems to be policy to > implement IXP s, many are still not getting the buy in from existing ISP s > ...so it is possible that an IXP could get off the ground with 2 and once > up and running, others will join in. > That could be a strategy. > > So raising the bar to three minimum may well make it more difficult for > them to get past the starting line. In my locale, we have 2 ISP s. And a > planned IXP. > My argument is that once we have an IXP, there is more of a likely hood > that it will attract new providers, be it specialists like health or > education for example. > And since the number of networks connecting is not the only criteria for > designating an IXP, my opinion is to leave it at two. > > Rudi Daniel > (information technologist) > 784 430 9235 > On Jan 30, 2014 1:19 PM, <[email protected]> wrote: > > [image: Boxbe] <https://www.boxbe.com/overview> This message is eligible > for Automatic Cleanup! ([email protected]) Add cleanup > rule<https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Ftoken%3D%252B2Hpz4gnu%252FejMZuSFdv87bmQBOtxEDS3b9X7gpLdwNWGg8XULREXlQT0aw%252Bg4wvXefzxDae7hDB3aavY%252Fl%252BPimWlX2yI0NQXtOB1j063pJn2Hz8TkS%252BrWybaclKxn%252FQH2U8LmZNyew4wxDdpjPd28A%253D%253D%26key%3DpptuT0%252Fde44tGc8pS94PFdMgJuo2iA0z7G0HcQ%252BSG2c%253D&tc_serial=16233316801&tc_rand=178071754&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_ADD&utm_content=001>| > More > info<http://blog.boxbe.com/general/boxbe-automatic-cleanup?tc_serial=16233316801&tc_rand=178071754&utm_source=stf&utm_medium=email&utm_campaign=ANNO_CLEANUP_ADD&utm_content=001> > > Send ARIN-PPML mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Draft Policy ARIN-2014-7: Section 4.4 Micro Allocation > Conservation Update (ARIN) > 2. Re: NRPM Policies 4.6 and 4.7 Suspended by ARIN Board (ARIN) > 3. Re: Draft Policy ARIN-2014-5: Remove 7.2 Lame Delegations > (William Herrin) > 4. Re: Draft Policy ARIN-2014-2: Improving 8.4 Anti-Flip > Language (William Herrin) > 5. Re: Draft Policy ARIN-2014-2: Improving 8.4 Anti-Flip > Language (Bill Darte) > 6. Re: Draft Policy ARIN-2014-2: Improving 8.4 Anti-Flip > Language (William Herrin) > 7. Re: Draft Policy ARIN-2014-2: Improving 8.4 Anti-Flip > Language (David Huberman) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 29 Jan 2014 10:27:44 -0500 > From: ARIN <[email protected]> > To: [email protected] > Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro > Allocation Conservation Update > Message-ID: <[email protected]> > Content-Type: text/plain; charset=windows-1252; format=flowed > > On 24 January 2014 the ARIN Advisory Council (AC) accepted > "ARIN-prop-200 Section 4.4 Micro Allocation Conservation Update" as a > Draft Policy. > > Draft Policy ARIN-2014-7 is below and can be found at: > https://www.arin.net/policy/proposals/2014_7.html > > You are encouraged to discuss the merits and your concerns of Draft > Policy 2014-7 on the Public Policy Mailing List. > > The AC will evaluate the discussion in order to assess the conformance > of this draft policy with ARIN's Principles of Internet Number Resource > Policy as stated in the PDP. Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The ARIN Policy Development Process (PDP) 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, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy ARIN-2014-7 > Section 4.4 Micro Allocation Conservation Update > > Date: 29 January 2014 > > Problem Statement: > > Two networks interconnecting are private peers. Three could be > considered an IXP. In light of exhaustion and the low reserve available > to CI _and_ the significant growth of IXP's in North America, it is > prudent to insure that there are minimum criteria that are sensible in > order to not waste address space on an activity that is delineated by a > minimum allocation vs. a /30. The barrier to entry remains low regardless. > > Policy statement: > > Change the following paragraph in Section 4.4 from: > > Exchange point operators must provide justification for the allocation, > including: connection policy, location, other participants (minimum of > two total), ASN, and contact information. ISPs and other organizations > receiving these micro-allocations will be charged under the ISP fee > schedule, while end-users will be charged under the fee schedule for > end-users. This policy does not preclude exchange point operators from > requesting address space under other policies. > > To: > > Exchange point operators must provide justification for the allocation, > including: connection policy, location, other participants (minimum of > three total), ASN, and contact information. IXP's formed as non profits > will be considered end user organizations. All others will be considered > ISPs. > > Comments: > a.Timetable for implementation: > b.Anything else: > > > ------------------------------ > > Message: 2 > Date: Wed, 29 Jan 2014 11:04:38 -0500 > From: ARIN <[email protected]> > To: [email protected] > Subject: Re: [arin-ppml] NRPM Policies 4.6 and 4.7 Suspended by ARIN > Board > Message-ID: <[email protected]> > Content-Type: text/plain; charset=windows-1252; format=flowed > > > Per the PDP, the ARIN Advisory Council will review this matter and make a > > recommendation to the Board. The AC's recommendation will be posted > to the > > Public Policy Mailing List for discussion. > > The ARIN Advisory Council recommended the following: > > "The Advisory Council supports the action of the Board to suspend > sections 4.6 and 4.7 of the NRPM. The AC recommends the suspension > remain in place while we work with the community on an appropriate > policy response. To initiate community discussion, the AC submitted a > proposal to remove Sections 4.6 and 4.7. The AC encourages input from > the community on this matter. If anyone believes that aspects of the > amnesty or aggregation policy should be retained, they are encouraged to > post their comments and recommendations to the PPML.? > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > On 1/21/14 3:08 PM, ARIN wrote: > > On 6 January 2014 the ARIN Board of Trustees, in accordance with the > > ARIN Policy > > Development Process (Part Two, Section 10.2 - Policy Suspension) > suspended > > Number Resource Policy Manual sections (NRPM) "4.6 Amnesty and > Aggregation > > Requests" and "4.7 Aggregation Requests". > > > > From the Board's minutes: "The ARIN Board of Trustees suspends Sections > > 4.6 and > > 4.7 of the Number Resource Policy Manual, and refers the matter to the > ARIN > > Advisory Council per the Policy Development Process." > > > > Per the PDP, the ARIN Advisory Council will review this matter and make a > > recommendation to the Board. The AC's recommendation will be posted to > the > > Public Policy Mailing List for discussion. > > > > The suspensions have been marked with notes from the editor in a new > > version of > > the policy manual- NRPM version 2014.2, dated 21 January 2014, > > supersedes the > > previous version. > > > > Board minutes are available at: https://www.arin.net/about_us/bot/ > > > > The ARIN Number Resource Policy Manual is available at: > > https://www.arin.net/policy/nrpm.html > > > > The ARIN Policy Development Process is available at: > > https://www.arin.net/policy/pdp.html > > > > Regards, > > > > Communications and Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > > > > > > > > > ------------------------------ > > Message: 3 > Date: Wed, 29 Jan 2014 19:18:33 -0500 > From: William Herrin <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [arin-ppml] Draft Policy ARIN-2014-5: Remove 7.2 Lame > Delegations > Message-ID: > <CAP-guGXtXJ=wCi1PO2gxDapeCX1srLEm-L6=UYpk= > [email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > On Wed, Jan 29, 2014 at 10:27 AM, ARIN <[email protected]> wrote: > > On 24 January 2014 the ARIN Advisory Council (AC) accepted "ARIN-prop-197 > > Remove 7.2 Lame Delegations" as a Draft Policy. > > > > ARIN will actively identify lame DNS name server(s) for reverse address > > delegations associated with address blocks allocated, assigned or > > administered by ARIN. Upon identification of a lame delegation, ARIN > shall > > attempt to contact the POC for that resource and resolve the issue. If, > > following due diligence, ARIN is unable to resolve the lame delegation, > ARIN > > will update the Whois database records resulting in the removal of lame > > servers. > > Howdy, > > Two decades of software improvements later, is there a *technical* > need for ARIN to take any action at all with respect to lame > delegations? Any stable DNS resolver has to deal with routine lame > delegations in the forward DNS anyway. > > On a related note, does anyone actually make use of section 7.1, > allowing an organization with less than a /16 to have ARIN handle all > its RDNS rather than delegating it? How does that work? What are the > mechanics involved in a registrant having ARIN set and change RDNS PTR > records for him? > > I'm wondering if there's a good reason to keep any part of section 7 at > all. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ [email protected] [email protected] > 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> > Falls Church, VA 22042-3004 > > > ------------------------------ > > Message: 4 > Date: Wed, 29 Jan 2014 19:06:33 -0500 > From: William Herrin <[email protected]> > To: ARIN <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [arin-ppml] Draft Policy ARIN-2014-2: Improving 8.4 > Anti-Flip Language > Message-ID: > < > cap-gugxmmkeheorso7hndn9oo+rggtfsb7qo5kujvjd0wom...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Wed, Jan 29, 2014 at 10:26 AM, ARIN <[email protected]> wrote: > > On 24 January 2014 the ARIN Advisory Council (AC) accepted "ARIN-prop-194 > > Improving 8.4 Anti-Flip Language" as a Draft Policy. > > > > Modify 8.4: > > Source entities within the ARIN region must not have received a transfer, > > allocation, or assignment of IPv4 number resources from ARIN for the 12 > > months prior to the approval of a transfer request. This restriction does > > not include M&A transfers. Restrictions related to recent receipt of > blocks > > shall not apply to inter-RIR transfers within the same organization and > its > > subsidiaries. > > Howdy. > > "and its subsidiaries" defeats the anti-flipping provision. Creating > and then selling a "subsidiary" has a trivial cost. Restrict it to > "same organization" and you won't have harmed things any more than > having inter-rir transfers at all harms things. > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ [email protected] [email protected] > 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> > Falls Church, VA 22042-3004 > > > ------------------------------ > > Message: 5 > Date: Thu, 30 Jan 2014 06:11:27 -0600 > From: Bill Darte <[email protected]> > To: William Herrin <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [arin-ppml] Draft Policy ARIN-2014-2: Improving 8.4 > Anti-Flip Language > Message-ID: > <CAMApp35z+Cc+w+Kxt0P7XDDhb0qavy4nO= > [email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Bill, > > Thanks for your input on this issue. We saw the same issue when adding the > clause, but did so anyway to get insight from the community. Our reasoning > was to get feedback on (at least) two issues.... > ...first, the issue of organizational structure. What if an organization > wishes to transfer to an 'existing' subsidiary....is that the same > organization? Is it possible to allow subsidiary transfer, but bound it > with a time constraint....'existing for the past XX months or years? > ...and, is this issue 'really' of concern given the late date relative to > ARIN free-pool run out? > > Thanks again, > bd > > > > > On Wed, Jan 29, 2014 at 6:06 PM, William Herrin <[email protected]> wrote: > > > On Wed, Jan 29, 2014 at 10:26 AM, ARIN <[email protected]> wrote: > > > On 24 January 2014 the ARIN Advisory Council (AC) accepted > "ARIN-prop-194 > > > Improving 8.4 Anti-Flip Language" as a Draft Policy. > > > > > > Modify 8.4: > > > Source entities within the ARIN region must not have received a > transfer, > > > allocation, or assignment of IPv4 number resources from ARIN for the 12 > > > months prior to the approval of a transfer request. This restriction > does > > > not include M&A transfers. Restrictions related to recent receipt of > > blocks > > > shall not apply to inter-RIR transfers within the same organization and > > its > > -- Scott
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
