[arin-ppml] ARIN-PPML 2017-6 draft policy
Rudolph Daniel
rudi.daniel at gmail.com
Wed Aug 23 09:15:26 EDT 2017
Thank you Owen, and I remember those exact words when the policy was
formulated and I accept that too. Of course, the community did not, at that
time see the loop hole we are currently trying to close. So I was being
cautious in that whilst we can modify the wording, to achieve a close, is
arin staff also confident that it can be implemented. Of course I also
appreciate that what ever we as a community do, there is always some out
there looking or searching for yet another loop hole.
rd
Rudi Daniel
*danielcharles consulting
<http://www.facebook.com/pages/Kingstown-Saint-Vincent-and-the-Grenadines/DanielCharles/153611257984774>*
On Tue, Aug 22, 2017 at 6:15 PM, Owen DeLong <owen at delong.com> wrote:
> 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 <rudi.daniel at gmail.com> 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, <arin-ppml-request at arin.net> wrote:
>
>> 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. 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
>> (hostmaster at uneedus.com)
>> 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 <pmcnary at cameron.net>
>> To: "arin-ppml at arin.net" <arin-ppml at arin.net>
>> Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5:
>> Equalization of Assignment Registration requirements between IPv4
>> and
>> IPv6
>> Message-ID: <7460ee99-c116-7c0a-b726-2267de135596 at cameron.net>
>> 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 <pmcnary at cameron.net> wrote:
>> >>
>> >> A /47 is smaller than a /48 and would not be required to be registered?
>> >>
>> >>
>> >> On 8/17/2017 12:50 PM, hostmaster at uneedus.com 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 [arin-ppml-bounces at arin.net] on behalf of David
>> Farmer [farmer at umn.edu]
>> >>>> Sent: Thursday, August 17, 2017 8:53 AM
>> >>>> To: hostmaster at uneedus.com
>> >>>> Cc: arin-ppml at arin.net
>> >>>> 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, <hostmaster at uneedus.com<mailto:
>> hostmaster at uneedus.com>> 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 <info at arin.net<mailto:
>> info at arin.net> <mailto:info at arin.net<mailto:info at arin.net>>> 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://ww
>> w.arin.net/policy/proposals/2017_5.html>
>> >>>> <https://www.arin.net/policy/proposals/2017_5.html<https://w
>> ww.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/po
>> licy/pdp.html>
>> >>>> <https://www.arin.net/policy/pdp.html<https://www.arin.net/p
>> olicy/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://ww
>> w.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 <(781)%20861-0670><tel:781-861-0670%20ext%205
>> 39>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> PPML
>> >>>> You are receiving this message because you are subscribed to
>> >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto:ARI
>> N-PPML at arin.net>).
>> >>>> Unsubscribe or manage your mailing list subscription at:
>> >>>> http://lists.arin.net/mailman/listinfo/arin-ppml<http://list
>> s.arin.net/mailman/listinfo/arin-ppml>
>> >>>> Please contact info at arin.net<mailto:info at arin.net> if you
>> experience any issues.
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> ===============================================
>> >>>> David Farmer Email:farmer at umn.edu<mailto:Email%3Afarmer 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.
>> >>>
>> >>>
>> >> _______________________________________________
>> >> 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.
>> >>
>> >
>> >
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 17 Aug 2017 20:54:23 +0000
>> From: WOOD Alison * DAS <Alison.WOOD at oregon.gov>
>> To: "arin-ppml at arin.net" <arin-ppml at arin.net>
>> Subject: [arin-ppml] Draft Policy 2017-6: Improve Reciprocity
>> Requirements for Inter RIR Transfers
>> Message-ID:
>> <B0CA7478A1F03F4CA96A93288751A91A01A47CF968 at WPORGEXCL10.ENTS
>> S.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>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Thu, 17 Aug 2017 18:00:05 -0400 (EDT)
>> From: hostmaster at uneedus.com
>> To: "arin-ppml at arin.net" <arin-ppml at arin.net>
>> Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5:
>> Equalization of Assignment Registration requirements between IPv4
>> and
>> IPv6
>> Message-ID: <Pine.LNX.4.64.1708171744310.28692 at localhost.localdomain>
>> 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 <farmer at umn.edu>
>> To: Leif Sawyer <lsawyer at gci.com>
>> Cc: "hostmaster at uneedus.com" <hostmaster at uneedus.com>,
>> "arin-ppml at arin.net" <arin-ppml at arin.net>
>> 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_rYybGQ at mail.
>> gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> On Thu, Aug 17, 2017 at 1:43 PM, David Farmer <farmer at umn.edu> wrote:
>>
>> > Inline.
>> >
>> > On Thu, Aug 17, 2017 at 12:29 PM, Leif Sawyer <lsawyer at gci.com> 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: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
>> ===============================================
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://lists.arin.net/pipermail/arin-ppml/attachments/
>> 20170817/7e7a2fcd/attachment.html>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> ARIN-PPML mailing list
>> ARIN-PPML at arin.net
>> 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 (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170823/c9e3acfb/attachment.htm>
More information about the ARIN-PPML
mailing list