[arin-ppml] ARIN-PPML 2014-7
Scott Leibrand
scottleibrand at gmail.com
Fri Jan 31 12:15:48 EST 2014
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 <rudi.daniel at gmail.com> 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, <arin-ppml-request at arin.net> wrote:
>
> [image: Boxbe] <https://www.boxbe.com/overview> This message is eligible
> for Automatic Cleanup! (arin-ppml-request at arin.net) 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
> arin-ppml at arin.net
>
> 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
> arin-ppml-request at arin.net
>
> You can reach the person managing the list at
> arin-ppml-owner at arin.net
>
> 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 <info at arin.net>
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Draft Policy ARIN-2014-7: Section 4.4 Micro
> Allocation Conservation Update
> Message-ID: <52E91DF0.9040909 at arin.net>
> 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 <info at arin.net>
> To: arin-ppml at arin.net
> Subject: Re: [arin-ppml] NRPM Policies 4.6 and 4.7 Suspended by ARIN
> Board
> Message-ID: <52E92696.4000709 at arin.net>
> 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 <bill at herrin.us>
> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-5: Remove 7.2 Lame
> Delegations
> Message-ID:
> <CAP-guGXtXJ=wCi1PO2gxDapeCX1srLEm-L6=UYpk=
> fb_5S_SmQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Wed, Jan 29, 2014 at 10:27 AM, ARIN <info at arin.net> 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 ................ herrin at dirtside.com bill at herrin.us
> 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 <bill at herrin.us>
> To: ARIN <info at arin.net>
> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-2: Improving 8.4
> Anti-Flip Language
> Message-ID:
> <
> CAP-guGXmmkEHeorSO7hnDN9oO+RggTFsB7qO5KUjVjD0wOMDqQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Wed, Jan 29, 2014 at 10:26 AM, ARIN <info at arin.net> 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 ................ herrin at dirtside.com bill at herrin.us
> 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 <billdarte at gmail.com>
> To: William Herrin <bill at herrin.us>
> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-2: Improving 8.4
> Anti-Flip Language
> Message-ID:
> <CAMApp35z+Cc+w+Kxt0P7XDDhb0qavy4nO=
> jVCWh-1ue4P0rFZw at mail.gmail.com>
> 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 <bill at herrin.us> wrote:
>
> > On Wed, Jan 29, 2014 at 10:26 AM, ARIN <info at arin.net> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140131/8729b5eb/attachment.htm>
More information about the ARIN-PPML
mailing list