It is achievable because ARIN will evaluate the policy of each RIR in this regard prior to approving the transfer.
Owen > On Aug 18, 2017, at 12:36 , Rudolph Daniel <[email protected]> wrote: > > " Recipient RIR policy must not permit transfers to other RIRs or NIRs whose > policies do not support bi-directional transfers." > > Whereas I am in support of closing this loophole, I cannot be sure that this > is actually achievable... > rd > > > On Aug 17, 2017 6:01 PM, <[email protected] > <mailto:[email protected]>> wrote: > Send ARIN-PPML mailing list submissions to > [email protected] <mailto:[email protected]> > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > <http://lists.arin.net/mailman/listinfo/arin-ppml> > or, via email, send a message with subject or body 'help' to > [email protected] <mailto:[email protected]> > > You can reach the person managing the list at > [email protected] <mailto:[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. Re: Revised: Draft Policy ARIN-2017-5: Equalization of > Assignment Registration requirements between IPv4 and IPv6 > (Paul McNary) > 2. Draft Policy 2017-6: Improve Reciprocity Requirements for > Inter RIR Transfers (WOOD Alison * DAS) > 3. Re: Revised: Draft Policy ARIN-2017-5: Equalization of > Assignment Registration requirements between IPv4 and IPv6 > ([email protected] <mailto:[email protected]>) > 4. Re: Revised: Draft Policy ARIN-2017-5: Equalization of > Assignment Registration requirements between IPv4 and IPv6 > (David Farmer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 17 Aug 2017 15:49:47 -0500 > From: Paul McNary <[email protected] <mailto:[email protected]>> > To: "[email protected] <mailto:[email protected]>" <[email protected] > <mailto:[email protected]>> > Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: > Equalization of Assignment Registration requirements between IPv4 and > IPv6 > Message-ID: <[email protected] > <mailto:[email protected]>> > Content-Type: text/plain; charset=utf-8; format=flowed > > Sorry I typed the numbers backwards, yes, that is what I meant. :-) > > A /48 is smaller than a /47 and would not be required to be registered? > A /47 would need to be > > > On 8/17/2017 1:30 PM, Chris Woodfield wrote: > > The opposite - a /47 is 2 /48s aggregated. > > > > -C > > > >> On Aug 17, 2017, at 11:26 AM, Paul McNary <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> A /47 is smaller than a /48 and would not be required to be registered? > >> > >> > >> On 8/17/2017 12:50 PM, [email protected] > >> <mailto:[email protected]> wrote: > >>> I note that any ISP size reassignment, with the recommended /48 for each > >>> end user site, will be /47 or larger, which must always be registered. > >>> > >>> Thus, I think 6.5.5.5 language is unneeded, since any LIR/ISP > >>> reassignment will be large enough to already trigger registration. > >>> > >>> Under the current policy, LIR's and ISP's are equal, so usually both > >>> terms are stated in any policy that mentions them. > >>> > >>> May I also suggest that if we are going to require registration upon > >>> downstream request for IPv6, that we consider placing the same language > >>> and requirements for IPv4 customers as well? And if we do, where do we > >>> draw the minimum line? Maybe a /32.... > >>> > >>> Also, good catch on the cut and paste error..... > >>> > >>> Albert Erdmann > >>> Network Administrator > >>> Paradise On Line Inc. > >>> > >>> > >>> On Thu, 17 Aug 2017, Leif Sawyer wrote: > >>> > >>>> Thanks for the feedback, David. > >>>> > >>>> I've added the fix for 6.5.5.2, since we're already in the section. > >>>> > >>>> I've also modified the text for 6.5.5.4 as well, because I think your > >>>> suggesting is a little cleaner. > >>>> > >>>> I'm not sure what the point of 6.5.5.5 is - you're just reiterating > >>>> 6.5.5.1. > >>>> That said, we could potentially clean up 6.5.5.1 by extending "static > >>>> IPv6 assignment" > >>>> to "static IPv6 assignment, or allocation," - or something similar. > >>>> > >>>> > >>>> Which also brings to mind the question: LIR or ISP? Both are in use > >>>> in 6.5.... > >>>> > >>>> ________________________________ > >>>> From: ARIN-PPML [[email protected] > >>>> <mailto:[email protected]>] on behalf of David Farmer > >>>> [[email protected] <mailto:[email protected]>] > >>>> Sent: Thursday, August 17, 2017 8:53 AM > >>>> To: [email protected] <mailto:[email protected]> > >>>> Cc: [email protected] <mailto:[email protected]> > >>>> Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization > >>>> of Assignment Registration requirements between IPv4 and IPv6 > >>>> > >>>> [External Email] > >>>> > >>>> Here is a slightly different formulation to consider. I refactored the > >>>> title a little, and based the phrasing on other parts of section 6.5.5 > >>>> > >>>> 6.5.5.4 Registration Requested by Recipient > >>>> > >>>> If requested by the downstream recipient of a block, each static IPv6 > >>>> assignment containing a /64 or more addresses, shall be registered, as > >>>> described in section 6.5.5.1. > >>>> > >>>> I'd like us to think about adding an additional section, based on > >>>> previous discussions. > >>>> > >>>> 6.5.5.5 Re-allocation to ISPs > >>>> > >>>> Each IPv6 re-allocation to a downstream ISP, regardless of size, > >>>> intended for further assignment by the downstream ISP's to it's > >>>> customers, shall be registered, as described in section 6.5.5.1 > >>>> > >>>> Also, in Section 6.5.5.2 there is a reference to section 4.2.3.7.1. I > >>>> think this is a cut and past error, I think the reference should be to > >>>> 6.5.5.1. Please, compare sections 4.2.3.7.1 and 4.2.3.7.2 with sections > >>>> 6.5.5.1 and 6.5.5.2 and I think it is obvious what happened. > >>>> > >>>> Thanks. > >>>> > >>>> On Wed, Aug 16, 2017 at 6:10 AM, <[email protected] > >>>> <mailto:[email protected]><mailto:[email protected] > >>>> <mailto:[email protected]>>> wrote: > >>>> I am in favor of the draft, with or without the changes to make it > >>>> clearer. > >>>> > >>>> I suggest the following language for clarity: > >>>> > >>>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to the > >>>> NRPM that reads "If the downstream recipient of a static assignment of > >>>> /64 or more addresses requests publishing of that static assignment in > >>>> ARIN's registration database, the ISP must register that static > >>>> assignment." > >>>> > >>>> Since "static assignment" is the term in this section, not netblock, I > >>>> suggest using this term instead of "netblock". "Of any size" is not > >>>> needed, as the language would require the ISP to register in total > >>>> whatever size the ISP has assigned to the downstream in the ARIN > >>>> database if requested by the downstream recipient, as long as it was /64 > >>>> or more. > >>>> > >>>> This language would also prevent requests to register only part of an > >>>> assignment. I think this language works in making the intent of the new > >>>> section more clear. > >>>> > >>>> Albert Erdmann > >>>> Network Administrator > >>>> Paradise On Line Inc. > >>>> > >>>> > >>>> > >>>> On Tue, 15 Aug 2017, John Santos wrote: > >>>> > >>>> I think that the "/64 or more addresses" and the "regardless of size" > >>>> are meant to convey that any netblock between a /64 and a /48 can and > >>>> should be registered if the recipient requests it, even if the block is > >>>> smaller than the /47 which would make it mandatory. Perhaps there is > >>>> better wording that would make this clearer. > >>>> > >>>> Three ranges: > >>>> > >>>> 1. smaller than /64: shouldn't be issued, can't be registered. > >>>> 2. /64 through /48: register at recipient's request > >>>> 3. /47 or larger: must be registered > >>>> > >>>> I agree on dynamic assignments > >>>> > >>>> Otherwise, I think this is a much clearer and better update to the > >>>> proposed policy, and can't find any other reason not to support it. > >>>> (I.E. this is a tentative vote FOR, if there is such a thing.) > >>>> > >>>> > >>>> > >>>> On 8/15/2017 3:59 PM, David Farmer wrote: > >>>> I support what I think is the intent, but I have language/editorial nits; > >>>> > >>>> 1. In 3) below; Which is it "a /64 or more addresses" or "regardless of > >>>> size" that requires registration? I think logically we need one or the > >>>> other, or some qualification on "regardless of size" statement. I think > >>>> it is a good idea to not require registration of less than a /64. But > >>>> the current language seems contradictory, and therefore confusing, my > >>>> recommendation is delete "regardless of size", from the sentence and > >>>> leaving "a /64 or more addresses". I pretty sure we don't want people > >>>> having an expectation that they can request the registration of "their" > >>>> /128 address. > >>>> > >>>> 2. Also in 3) below; It would seem to require even dynamic assignments > >>>> be registered if requested, I don't think that is our intent either, > >>>> section 6.5.5.1 starts with "Each static IPv6 assignment containing", > >>>> this needs a similar qualification. > >>>> > >>>> Also, I'm fine with the deltas in the policy statement but it would be > >>>> helpful to see the final resulting policy block, maybe in a separate > >>>> email so we can all see how the result reads. > >>>> > >>>> Thanks, I think we are getting close, maybe one or two more turns of the > >>>> crank. > >>>> > >>>> On Tue, Aug 15, 2017 at 12:06 PM, ARIN <[email protected] > >>>> <mailto:[email protected]><mailto:[email protected] <mailto:[email protected]>> > >>>> <mailto:[email protected] <mailto:[email protected]><mailto:[email protected] > >>>> <mailto:[email protected]>>>> wrote: > >>>> > >>>> The following has been revised: > >>>> > >>>> * Draft Policy ARIN-2017-5: Equalization of Assignment > >>>> Registration requirements between IPv4 and IPv6 > >>>> > >>>> Revised text is below and can be found at: > >>>> https://www.arin.net/policy/proposals/2017_5.html > >>>> <https://www.arin.net/policy/proposals/2017_5.html><https://www.arin.net/policy/proposals/2017_5.html > >>>> <https://www.arin.net/policy/proposals/2017_5.html>> > >>>> <https://www.arin.net/policy/proposals/2017_5.html > >>>> <https://www.arin.net/policy/proposals/2017_5.html><https://www.arin.net/policy/proposals/2017_5.html > >>>> <https://www.arin.net/policy/proposals/2017_5.html>>> > >>>> > >>>> You are encouraged to discuss all Draft Policies on PPML. 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 Policy Development Process (PDP). > >>>> Specifically, these principles are: > >>>> > >>>> * Enabling Fair and Impartial Number Resource Administration > >>>> * Technically Sound > >>>> * Supported by the Community > >>>> > >>>> The PDP can be found at: > >>>> https://www.arin.net/policy/pdp.html > >>>> <https://www.arin.net/policy/pdp.html><https://www.arin.net/policy/pdp.html > >>>> <https://www.arin.net/policy/pdp.html>> > >>>> <https://www.arin.net/policy/pdp.html > >>>> <https://www.arin.net/policy/pdp.html><https://www.arin.net/policy/pdp.html > >>>> <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 > >>>> <https://www.arin.net/policy/proposals/index.html><https://www.arin.net/policy/proposals/index.html > >>>> <https://www.arin.net/policy/proposals/index.html>> > >>>> <https://www.arin.net/policy/proposals/index.html > >>>> <https://www.arin.net/policy/proposals/index.html><https://www.arin.net/policy/proposals/index.html > >>>> <https://www.arin.net/policy/proposals/index.html>>> > >>>> > >>>> Regards, > >>>> > >>>> Sean Hopkins > >>>> Policy Analyst > >>>> American Registry for Internet Numbers (ARIN) > >>>> > >>>> > >>>> > >>>> > >>>> Problem Statement: > >>>> > >>>> Current ARIN policy has different WHOIS directory registration > >>>> requirements for IPv4 vs IPv6 address assignments. IPv4 > >>>> registration is triggered for an assignment of any address block > >>>> equal to or greater than a /29 (i.e., eight IPv4 addresses). In > >>>> the case of IPv6, registration occurs for an assignment of any > >>>> block equal to or greater than a /64, which constitutes one entire > >>>> IPv6 subnet and is the minimum block size for an allocation. > >>>> Accordingly, there is a significant disparity between IPv4 and > >>>> IPv6 WHOIS registration thresholds in the case of assignments, > >>>> resulting in more work in the case of IPv6 than is the case for > >>>> IPv4. There is no technical or policy rationale for the disparity, > >>>> which could serve as a deterrent to more rapid IPv6 adoption. The > >>>> purpose of this proposal is to eliminate the disparity and > >>>> corresponding adverse consequences. > >>>> > >>>> Policy statement: > >>>> > >>>> 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to > >>>> strike "/64 or more addresses" and change to "/47 or more > >>>> addresses, or subdelegation of any size that will be individually > >>>> announced," > >>>> > >>>> and > >>>> > >>>> 2) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the > >>>> NRPM by deleting the phrase "holding /64 and larger blocks" > >>>> > >>>> and > >>>> > >>>> 3) Add new section 6.5.5.4 "Downstream Registration Requests" to > >>>> the NRPM that reads "If the downstream recipient of a netblock ( a > >>>> /64 or more addresses) requests publishing in ARIN's registration > >>>> database, the ISP must register the netblock, regardless of size." > >>>> > >>>> Comments: > >>>> > >>>> a. Timetable for implementation: Policy should be adopted as > >>>> soon as possible. > >>>> > >>>> b. Anything else: > >>>> > >>>> Author Comments: > >>>> > >>>> IPv6 should not be more burdensome than the equivalent IPv4 > >>>> network size. Currently, assignments of /29 or more of IPv4 space > >>>> (8 addresses) require registration. The greatest majority of ISP > >>>> customers who have assignments of IPv4 space are of a single IPv4 > >>>> address which do not trigger any ARIN registration requirement > >>>> when using IPv4. This is NOT true when these same exact customers > >>>> use IPv6, as assignments of /64 or more of IPv6 space require > >>>> registration. Beginning with RFC 3177, it has been standard > >>>> practice to assign a minimum assignment of /64 to every customer > >>>> end user site, and less is never used. This means that ALL IPv6 > >>>> assignments, including those customers that only use a single IPv4 > >>>> address must be registered with ARIN if they are given the minimum > >>>> assignment of /64 of IPv6 space. This additional effort may > >>>> prevent ISP's from giving IPv6 addresses because of the additional > >>>> expense of registering those addresses with ARIN, which is not > >>>> required for IPv4. The administrative burden of 100% customer > >>>> registration of IPv6 customers is unreasonable, when such is not > >>>> required for those customers receiving only IPv4 connections. > >>>> > >>>> -- > >>>> John Santos > >>>> Evans Griffiths & Hart, Inc. > >>>> 781-861-0670 ext 539<tel:781-861-0670%20ext%20539> > >>>> > >>>> > >>>> _______________________________________________ > >>>> PPML > >>>> You are receiving this message because you are subscribed to > >>>> the ARIN Public Policy Mailing List ([email protected] > >>>> <mailto:[email protected]><mailto:[email protected] > >>>> <mailto:[email protected]>>). > >>>> Unsubscribe or manage your mailing list subscription at: > >>>> http://lists.arin.net/mailman/listinfo/arin-ppml > >>>> <http://lists.arin.net/mailman/listinfo/arin-ppml><http://lists.arin.net/mailman/listinfo/arin-ppml > >>>> <http://lists.arin.net/mailman/listinfo/arin-ppml>> > >>>> Please contact [email protected] <mailto:[email protected]><mailto:[email protected] > >>>> <mailto:[email protected]>> if you experience any issues. > >>>> > >>>> > >>>> > >>>> -- > >>>> =============================================== > >>>> David Farmer Email:[email protected] > >>>> <mailto:email%[email protected]><mailto:email%[email protected] > >>>> <mailto:email%[email protected]>> > >>>> Networking & Telecommunication Services > >>>> Office of Information Technology > >>>> University of Minnesota > >>>> 2218 University Ave SE Phone: 612-626-0815 <tel:612-626-0815> > >>>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <tel:612-812-9952> > >>>> =============================================== > >>>> > >>> _______________________________________________ > >>> PPML > >>> You are receiving this message because you are subscribed to > >>> the ARIN Public Policy Mailing List ([email protected] > >>> <mailto:[email protected]>). > >>> Unsubscribe or manage your mailing list subscription at: > >>> http://lists.arin.net/mailman/listinfo/arin-ppml > >>> <http://lists.arin.net/mailman/listinfo/arin-ppml> > >>> Please contact [email protected] <mailto:[email protected]> if you experience any > >>> issues. > >>> > >>> > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed to > >> the ARIN Public Policy Mailing List ([email protected] > >> <mailto:[email protected]>). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> <http://lists.arin.net/mailman/listinfo/arin-ppml> > >> Please contact [email protected] <mailto:[email protected]> if you experience any > >> issues. > >> > > > > > > > > ------------------------------ > > Message: 2 > Date: Thu, 17 Aug 2017 20:54:23 +0000 > From: WOOD Alison * DAS <[email protected] > <mailto:[email protected]>> > To: "[email protected] <mailto:[email protected]>" <[email protected] > <mailto:[email protected]>> > Subject: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity > Requirements for Inter RIR Transfers > Message-ID: > <b0ca7478a1f03f4ca96a93288751a91a01a47cf...@wporgexcl10.entss.or.gov > <mailto:b0ca7478a1f03f4ca96a93288751a91a01a47cf...@wporgexcl10.entss.or.gov>> > Content-Type: text/plain; charset="us-ascii" > > Thank you for the feedback on this draft policy to date. I would appreciate > any other thoughts or comments on this draft policy. > > For review, Draft Policy 2017-6 is intended to add the following conditions > on Inter RIR transfers to section 8.4: > > Recipient RIR policy must not permit transfers to other RIRs or NIRs whose > policies do not support bi-directional transfers. > > And the problem statement on this draft policy is: > > Currently ARIN's requirement that inter-RIR transfer policies be reciprocal > has a glaring hole in it in that RIRs which have NIRs and/or a two-hop RIR > transfer process can be used to circumvent the intent of the requirement. > Rather than eliminate the requirement, a better approach would be to close > the loophole. > > All feedback is appreciated. > > Thank you > > -Alison Wood > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://lists.arin.net/pipermail/arin-ppml/attachments/20170817/22d7858b/attachment-0001.html > > <http://lists.arin.net/pipermail/arin-ppml/attachments/20170817/22d7858b/attachment-0001.html>> > > ------------------------------ > > Message: 3 > Date: Thu, 17 Aug 2017 18:00:05 -0400 (EDT) > From: [email protected] <mailto:[email protected]> > To: "[email protected] <mailto:[email protected]>" <[email protected] > <mailto:[email protected]>> > Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: > Equalization of Assignment Registration requirements between IPv4 and > IPv6 > Message-ID: <[email protected]> > Content-Type: text/plain; charset="x-unknown"; Format="flowed" > > While the most recent drafts have not dealt with IPv4, in the last round > there was a proposal to require registration upon request of the > downstream customer of their IPv6 assignment. > > If we intend to provide that power to require registration for IPv6 > customer assignments upon request, in fairness we should also use the same > language in a new 4.2.3.7.4 to allow static IPv4 customers that same > power. I suggest /32 as the limit, as /29 or more already has required > registration. The same problems identfied in not being able to register > assignments with ARIN for v6 are also true for v4 assignments between > those limits. > > Since both protocols are still being addressed and attempts are being > made by the draft to make v6 equal or better than v4, the title should > remain. The only thing we have done is not shift the v4 limit of /29. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > > While we???re turning the crank, can we please fix the title since IPv4 > > is no longer relevant to the proposal and there???s really no > > equalization happening? > > > > Perhaps ???Improved Registration Requirements for IPv6??? > > > > Owen > > ------------------------------ > > Message: 4 > Date: Thu, 17 Aug 2017 17:01:09 -0500 > From: David Farmer <[email protected] <mailto:[email protected]>> > To: Leif Sawyer <[email protected] <mailto:[email protected]>> > Cc: "[email protected] <mailto:[email protected]>" > <[email protected] <mailto:[email protected]>>, > "[email protected] <mailto:[email protected]>" <[email protected] > <mailto:[email protected]>> > Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: > Equalization of Assignment Registration requirements between IPv4 and > IPv6 > Message-ID: > <CAN-Dau0+4ms_7V-=y89zavkp+duwvhk932fbkfburtb_ryy...@mail.gmail.com > <mailto:y89zavkp%[email protected]>> > Content-Type: text/plain; charset="utf-8" > > On Thu, Aug 17, 2017 at 1:43 PM, David Farmer <[email protected] > <mailto:[email protected]>> wrote: > > > Inline. > > > > On Thu, Aug 17, 2017 at 12:29 PM, Leif Sawyer <[email protected] > > <mailto:[email protected]>> wrote: > > > >> Thanks for the feedback, David. > >> > > ... > > > I'm not sure what the point of 6.5.5.5 is - you're just reiterating > >> 6.5.5.1. > >> That said, we could potentially clean up 6.5.5.1 by extending "static > >> IPv6 assignment" > >> to "static IPv6 assignment, or allocation," - or something similar. > >> > > > > ISP re-allocations need to be registered regardless of size or if it is > > being advertised or not. For example, if for some stupid reason a /56 was > > re-allocated to downsterm ISP so they could assign /64s to customers that > > has to be registered, by 6.5.5.1 that wouldn't have to be registered. > > Should you re-allocate a /56, @!@#$ NO!!! But if you did, it has to be > > registered. This is so LEA and other legal requests get directly to the > > correct ISP the first time. I think this is important enough issue that it > > should have it's own section, and not get blended in to 6.5.5.1. > > > > Now should that be part of this policy maybe not, maybe this belongs in > > ARIN-2017-3 or whole new separate policy proposal instead. > > > > Thinking about this for the last couple hours I'm thinking 6.5.5.5 this > should not be part of this policy. As similar text should be added in the > IPv4 section, and this should have a somewhat different problem statement > as well. > > -- > =============================================== > David Farmer Email:[email protected] > <mailto:email%[email protected]> > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <tel:612-626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <tel:612-812-9952> > =============================================== > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://lists.arin.net/pipermail/arin-ppml/attachments/20170817/7e7a2fcd/attachment.html > > <http://lists.arin.net/pipermail/arin-ppml/attachments/20170817/7e7a2fcd/attachment.html>> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > ARIN-PPML mailing list > [email protected] <mailto:[email protected]> > http://lists.arin.net/mailman/listinfo/arin-ppml > <http://lists.arin.net/mailman/listinfo/arin-ppml> > > ------------------------------ > > End of ARIN-PPML Digest, Vol 146, Issue 10 > ****************************************** > _______________________________________________ > 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.
_______________________________________________ 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.
