[arin-ppml] draft policy 2019-19 ARIN-PPML
Rudolph Daniel
rudi.daniel at gmail.com
Tue Nov 12 00:09:28 EST 2019
I've struggled so far with much of the comments on this draft.
Until that is, Fernando mentioned "documented justification".
...in the interest of ipv6 adoption and not restrict but include internal
networks. But where do you draw the line?
RD
On Mon, Nov 11, 2019, 22:38 <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
> https://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: Draft Policy ARIN-2019-19: Require IPv6 Before Receiving
> Section 8 IPv4 Transfers (Fernando Frediani)
> 2. Re: Draft Policy ARIN-2019-19: Require IPv6 Before Receiving
> Section 8 IPv4 Transfers (Owen DeLong)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 12 Nov 2019 00:26:37 -0300
> From: Fernando Frediani <fhfrediani at gmail.com>
> To: arin-ppml <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2019-19: Require IPv6
> Before Receiving Section 8 IPv4 Transfers
> Message-ID: <eee67d32-0eda-68a2-4ae8-eb2b1c06df20 at gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 12/11/2019 00:06, Owen DeLong wrote:
> >> This is not something new to be done as it is similar that the
> justification process which has always been done for IPv4, with the
> specific differences. It's important to highlight that this doesn't mean
> one must prove it has 100% IPv6 deployment, but rather that it is
> operational and in fact in used by internal devices, staff, customers, etc
> rather than just announced to the internet and used in a single tiny
> network just for Internet browsing.
> > Actually, it?s completely different from any justification process for
> IPv4 in any of ARIN?s history. ARIN has never required routing or proof of
> routing or any such thing in any IP number resource policy other than
> public ASNs requiring either peering with other AS(s) or a unique routing
> policy. Internet connectivity has _NEVER_ been an ARIN policy requirement
> for number resources.
> I said similar in the sense things should be proved through
> documentation, if it was the same I was going say that specifically.
> There is no how to put a list of specific requirements for one to prove
> IPv6 is operational, but similar to when someone used to justify for
> newer IPv4 allocation, it can be done as well to show IPv6 is
> operational, with all differences that apply to each case. Parts of this
> are contained in NRPM sections 4.2.1.4, mainly in 4.2.3.1 (where
> mentions "documented justification" - but doesn't specify which ones,
> which is up to staff's discretion). That has always worked well as far
> as I know.
> >> I think is reasonable to trust ARIN staff to evaluate at their
> discretion as three is precedent in the NRPM and it is not very difficult
> to differentiate both scenarios. In short words, a commitment to IPv6 and
> having it operational doesn't mean 100% deployment.
> > Please point to this precedent? I can?t find it.
> The mentioned above. Also section 4.1.0 mentions "ARIN staff will use
> their discretion when evaluating justifications.".
>
> Therefore I believe it's reasonable to let them process these
> justification and it's not very difficult to differentiate one that
> turns on IPv6 just to fulfill this policy requirements and one that
> really has it operational and is committed to it.
>
> Fernando
>
> >
> > Owen
> >
> >> Best regards
> >> Fernando
> >>
> >> On 11/11/2019 17:34, hostmaster at uneedus.com wrote:
> >>> I have a request for any numbers on IPv6 adoption of those who have
> received directed transfers in the last year, or any other available period.
> >>>
> >>> I have looked at some of the blocks that have been transferred, and
> most of them seem to be obtained by larger ISP or Mobile Wireless providers
> that are already well known adopters of IPv6. Such providers would of
> course have no issues meeting the standards of the Draft Policy.
> >>>
> >>> What I would like to find out is what percentage are in the position
> of not having any IPv6 in place, and therefore might be adversely affected.
> >>>
> >>> Thanks,
> >>>
> >>> Albert Erdmann
> >>> Network Administrator
> >>> Paradise On Line Inc.
> >>>
> >>> On Thu, 7 Nov 2019, Owen DeLong wrote:
> >>>
> >>>>
> >>>> On Nov 6, 2019, at 13:40 , Fernando Frediani <
> fhfrediani at gmail.com> wrote:
> >>>>
> >>>> I wanted to kindly request AC members attention to all objections
> based on the argument that "ARIN is forcing someone to do something on
> their own
> >>>> network?.
> >>>>
> >>>>
> >>>> This is NOT true at all and not the propose of this proposal
> therefore I believe these kind of objections have been refuted multiple
> times already.
> >>>>
> >>>>
> >>>> I cannot speak for the entire AC, but this AC member (at least until
> the end of the year) is well aware of your position on the matter. I do
> not, however,
> >>>> share this opinion.
> >>>>
> >>>> Insisting that people make an IPv6 address pingable in order to
> receive IPv4 resources via transfer strikes me as an effort to push those
> who do not wish to
> >>>> do IPv6 into doing so.
> >>>> As such, it is about forcing someone to do something on their own
> network.
> >>>>
> >>>> This is a valid objection to the policy. It may be an objection the
> community decides to overrule or dismiss, but it is an objection,
> nonetheless.
> >>>>
> >>>> You may not like that objection, and that?s fine. You?ve said so, and
> we?ve heard you.
> >>>>
> >>>> With regards the proposal this community has the right to
> estabilish whatever conditions for the RIR registration related stuff it
> finds better
> >>>> for the RIR and the Internet to continue working healthy in
> the region.
> >>>>
> >>>>
> >>>> This is also true, but the people you are dismissing because you
> don?t like their objections are just as much members of the community as
> you are. They have
> >>>> every right to object to the policy on whatever basis they feel is in
> their best interests or that of the community.
> >>>>
> >>>> For example the increasing cost imposed to all others by those
> who wishes to remain in the past and the growing conflicts due to the
> current
> >>>> scenario are good point for this community to evaluate.
> >>>>
> >>>>
> >>>> Here, I agree with you. I don?t agree that what is proposed will help
> resolve that issue. I do think we will have many discussions about how to
> resolve this
> >>>> particular problem in the coming years.
> >>>>
> >>>> Also I am finding some people having trouble with the
> mechanism to validate IPv6 is operational and would really like to hear
> other points of
> >>>> view about more effective way that process can be validaded
> and be more effective in their point of view.
> >>>>
> >>>>
> >>>> This is a very tough question. I think that all of the corner cases
> that would exist in response to this question are a perfectly valid reason
> not to
> >>>> inflict this proposed policy on the community.
> >>>>
> >>>> Owen
> >>>>
> >>>>
> >>>> Regards
> >>>> Fernando
> >>>>
> >>>> On Thu, 7 Nov 2019 16:06 Brett Frankenberger, <
> rbf+arin-ppml at panix.com> wrote:
> >>>> On Wed, Nov 06, 2019 at 12:55:50PM -0500, ARIN wrote:
> >>>> > On 1 November 2019, the ARIN Advisory Council (AC) accepted
> "ARIN-prop-278:
> >>>> > Require IPv6 Before Receiving Section 8 IPv4 Transfers" as a
> Draft Policy.
> >>>> >
> >>>> > Draft Policy ARIN-2019-19 is below and can be found at:
> >>>> >
> >>>> > Policy statement:
> >>>> >
> >>>> > In section 8.5.2, add the following language to the end of
> the paragraph
> >>>> > entitled ?Operational Use?:
> >>>> >
> >>>> > Such operational network must at minimum include an
> allocation or assignment
> >>>> > by ARIN of IPv6 address space under the same Org ID
> receiving the
> >>>> > transferred IPv4 space. Such Org must be able to prove this
> IPv6 space is
> >>>> > being routed by using it to communicate with ARIN.
> >>>> >
> >>>> > In the event the receiver provides a written statement from
> its upstream
> >>>> > that IPv6 connectivity is unavailable, the IPv6 requirement
> may be waived.
> >>>>
> >>>> Opposed for multiple reasons.
> >>>>
> >>>> First, it should not be ARINs role to dictate the manner in
> which
> >>>> networks are operated. We have routinely resisted the notion
> that, for
> >>>> example, spammers should have resources revoked. Now we're
> proposing
> >>>> to deny resources to networks that decide not to operate IPv6.
> >>>>
> >>>> Second, the proposal is premised on the idea that IP addresses
> are
> >>>> solely allocated for the purpose of operation on the public
> network,
> >>>> despite policy being clear that that's not the case. While
> that's
> >>>> certainly the predominate use case, there is nothing that
> prevents a
> >>>> private interconnected network from operating on
> >>>> ARIN-assigned/allocated public space without connecting to the
> >>>> Internet. Are we proposing to deny any future transfers for
> such
> >>>> networks? They would by their nature be unable to prove IPv6
> >>>> connectivity to ARIN (except as a stunt -- see below) and
> would be
> >>>> unable to get a statement from their upstream (since they
> would have
> >>>> none) as to the availability of IPv6 connectivity.
> >>>>
> >>>> Third, this encourages meaningless stunts. A network that
> does not
> >>>> desire to opreate V6 is not going to reconsider that decision
> as a
> >>>> result of this policy. At best, they will get an IPv6
> allocation or
> >>>> assignment from ARIN, route it to one subnet, put a device on
> it long
> >>>> enough to perform whatever ceremony ARIN requires to prove IPV6
> >>>> connectivity, get their transfer, and then shut it down (or
> maybe leave
> >>>> it there in case they have to reperform the ceremony should
> they
> >>>> transfer additional addresses in the future). More likely,
> this will
> >>>> cause the creation of a new industry: organizations needing to
> complete
> >>>> an IPv6 connectivity validation to get a IPv4 transfer
> processed will
> >>>> sign a LOA granting their Ceremony Consultant the right to
> announce
> >>>> their IPv6 allocation/assignment long enough to complete the
> ceremony,
> >>>> and their consultant will do all the work necessary to get the
> required
> >>>> box checked in ARIN's systesm.
> >>>>
> >>>> This will not drive IPv6 adoption. I oppose the use of ARIN or
> >>>> community resources on stunts, and I oppose the creation of a
> "IPv6
> >>>> Ceremony Consultant" industry.
> >>>>
> >>>> -- Brett
> >>>> _______________________________________________
> >>>> 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:
> >>>> https://lists.arin.net/mailman/listinfo/arin-ppml
> >>>> Please contact info at arin.net if you experience any issues.
> >>>>
> >>>> _______________________________________________
> >>>> 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:
> >>>> https://lists.arin.net/mailman/listinfo/arin-ppml
> >>>> Please contact info at arin.net if you experience any issues.
> >>>>
> >>>>
> >>>>
> >>>>
> >> _______________________________________________
> >> 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:
> >> https://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 11 Nov 2019 19:36:19 -0800
> From: Owen DeLong <owen at delong.com>
> To: Fernando Frediani <fhfrediani at gmail.com>
> Cc: arin-ppml <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Draft Policy ARIN-2019-19: Require IPv6
> Before Receiving Section 8 IPv4 Transfers
> Message-ID: <DC4791DB-282B-40FC-96CF-5007A6C18D9D at delong.com>
> Content-Type: text/plain; charset=utf-8
>
>
>
> > On Nov 11, 2019, at 19:26 , Fernando Frediani <fhfrediani at gmail.com>
> wrote:
> >
> > On 12/11/2019 00:06, Owen DeLong wrote:
> >>> This is not something new to be done as it is similar that the
> justification process which has always been done for IPv4, with the
> specific differences. It's important to highlight that this doesn't mean
> one must prove it has 100% IPv6 deployment, but rather that it is
> operational and in fact in used by internal devices, staff, customers, etc
> rather than just announced to the internet and used in a single tiny
> network just for Internet browsing.
> >> Actually, it?s completely different from any justification process for
> IPv4 in any of ARIN?s history. ARIN has never required routing or proof of
> routing or any such thing in any IP number resource policy other than
> public ASNs requiring either peering with other AS(s) or a unique routing
> policy. Internet connectivity has _NEVER_ been an ARIN policy requirement
> for number resources.
> > I said similar in the sense things should be proved through
> documentation, if it was the same I was going say that specifically. There
> is no how to put a list of specific requirements for one to prove IPv6 is
> operational, but similar to when someone used to justify for newer IPv4
> allocation, it can be done as well to show IPv6 is operational, with all
> differences that apply to each case. Parts of this are contained in NRPM
> sections 4.2.1.4, mainly in 4.2.3.1 (where mentions "documented
> justification" - but doesn't specify which ones, which is up to staff's
> discretion). That has always worked well as far as I know.
>
> If you want to apply the utilization tests embodied in sections 4, 6, or
> 8, then I?d be fine with that. None of them require being able to
> communicate with ARIN on the space in question. None of them require
> attachment to the internet. None of them require any of the tests that have
> been proposed earlier in this discussion or in the current proposed policy
> text.
>
> So, if an updated policy text appears that refers to those tests, then I
> will withdraw my objection to the proposal on that ground.
>
> My objection on the grounds that it will be ineffectual at best and on the
> basis that I do not believe tying acquisition of one set of number
> resources to another is reasonable will still stand, however.
>
> >>> I think is reasonable to trust ARIN staff to evaluate at their
> discretion as three is precedent in the NRPM and it is not very difficult
> to differentiate both scenarios. In short words, a commitment to IPv6 and
> having it operational doesn't mean 100% deployment.
> >> Please point to this precedent? I can?t find it.
> > The mentioned above. Also section 4.1.0 mentions "ARIN staff will use
> their discretion when evaluating justifications.?.
>
> Those don?t support any of the tests previously described in this
> discussion, nor do they support the tests described in the policy proposal.
>
> So far, the discussion in this context has been about tests which require
> some form of IPv6 internet connectivity using the addresses in question. To
> date, that?s never been part of ARIN policy, nor do I believe it should be.
>
> > Therefore I believe it's reasonable to let them process these
> justification and it's not very difficult to differentiate one that turns
> on IPv6 just to fulfill this policy requirements and one that really has it
> operational and is committed to it.
>
> Again, if the proposal is amended to reflect use of any of the current
> utilization tests I?m fine with that aspect of the proposal. That?s not
> where we are today. The tests currently proposed represent a major change
> the requirements in question for demonstrating utilization which I do not
> support.
>
> Owen
>
> >
> > Fernando
> >
> >>
> >> Owen
> >>
> >>> Best regards
> >>> Fernando
> >>>
> >>> On 11/11/2019 17:34, hostmaster at uneedus.com wrote:
> >>>> I have a request for any numbers on IPv6 adoption of those who have
> received directed transfers in the last year, or any other available period.
> >>>>
> >>>> I have looked at some of the blocks that have been transferred, and
> most of them seem to be obtained by larger ISP or Mobile Wireless providers
> that are already well known adopters of IPv6. Such providers would of
> course have no issues meeting the standards of the Draft Policy.
> >>>>
> >>>> What I would like to find out is what percentage are in the position
> of not having any IPv6 in place, and therefore might be adversely affected.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Albert Erdmann
> >>>> Network Administrator
> >>>> Paradise On Line Inc.
> >>>>
> >>>> On Thu, 7 Nov 2019, Owen DeLong wrote:
> >>>>
> >>>>>
> >>>>> On Nov 6, 2019, at 13:40 , Fernando Frediani <
> fhfrediani at gmail.com> wrote:
> >>>>>
> >>>>> I wanted to kindly request AC members attention to all objections
> based on the argument that "ARIN is forcing someone to do something on
> their own
> >>>>> network?.
> >>>>>
> >>>>>
> >>>>> This is NOT true at all and not the propose of this proposal
> therefore I believe these kind of objections have been refuted multiple
> times already.
> >>>>>
> >>>>>
> >>>>> I cannot speak for the entire AC, but this AC member (at least until
> the end of the year) is well aware of your position on the matter. I do
> not, however,
> >>>>> share this opinion.
> >>>>>
> >>>>> Insisting that people make an IPv6 address pingable in order to
> receive IPv4 resources via transfer strikes me as an effort to push those
> who do not wish to
> >>>>> do IPv6 into doing so.
> >>>>> As such, it is about forcing someone to do something on their own
> network.
> >>>>>
> >>>>> This is a valid objection to the policy. It may be an objection the
> community decides to overrule or dismiss, but it is an objection,
> nonetheless.
> >>>>>
> >>>>> You may not like that objection, and that?s fine. You?ve said so,
> and we?ve heard you.
> >>>>>
> >>>>> With regards the proposal this community has the right to
> estabilish whatever conditions for the RIR registration related stuff it
> finds better
> >>>>> for the RIR and the Internet to continue working healthy in
> the region.
> >>>>>
> >>>>>
> >>>>> This is also true, but the people you are dismissing because you
> don?t like their objections are just as much members of the community as
> you are. They have
> >>>>> every right to object to the policy on whatever basis they feel is
> in their best interests or that of the community.
> >>>>>
> >>>>> For example the increasing cost imposed to all others by those
> who wishes to remain in the past and the growing conflicts due to the
> current
> >>>>> scenario are good point for this community to evaluate.
> >>>>>
> >>>>>
> >>>>> Here, I agree with you. I don?t agree that what is proposed will
> help resolve that issue. I do think we will have many discussions about how
> to resolve this
> >>>>> particular problem in the coming years.
> >>>>>
> >>>>> Also I am finding some people having trouble with the
> mechanism to validate IPv6 is operational and would really like to hear
> other points of
> >>>>> view about more effective way that process can be validaded
> and be more effective in their point of view.
> >>>>>
> >>>>>
> >>>>> This is a very tough question. I think that all of the corner cases
> that would exist in response to this question are a perfectly valid reason
> not to
> >>>>> inflict this proposed policy on the community.
> >>>>>
> >>>>> Owen
> >>>>>
> >>>>>
> >>>>> Regards
> >>>>> Fernando
> >>>>>
> >>>>> On Thu, 7 Nov 2019 16:06 Brett Frankenberger, <
> rbf+arin-ppml at panix.com> wrote:
> >>>>> On Wed, Nov 06, 2019 at 12:55:50PM -0500, ARIN wrote:
> >>>>> > On 1 November 2019, the ARIN Advisory Council (AC) accepted
> "ARIN-prop-278:
> >>>>> > Require IPv6 Before Receiving Section 8 IPv4 Transfers" as a
> Draft Policy.
> >>>>> >
> >>>>> > Draft Policy ARIN-2019-19 is below and can be found at:
> >>>>> >
> >>>>> > Policy statement:
> >>>>> >
> >>>>> > In section 8.5.2, add the following language to the end of
> the paragraph
> >>>>> > entitled ?Operational Use?:
> >>>>> >
> >>>>> > Such operational network must at minimum include an
> allocation or assignment
> >>>>> > by ARIN of IPv6 address space under the same Org ID
> receiving the
> >>>>> > transferred IPv4 space. Such Org must be able to prove this
> IPv6 space is
> >>>>> > being routed by using it to communicate with ARIN.
> >>>>> >
> >>>>> > In the event the receiver provides a written statement from
> its upstream
> >>>>> > that IPv6 connectivity is unavailable, the IPv6 requirement
> may be waived.
> >>>>>
> >>>>> Opposed for multiple reasons.
> >>>>>
> >>>>> First, it should not be ARINs role to dictate the manner in
> which
> >>>>> networks are operated. We have routinely resisted the notion
> that, for
> >>>>> example, spammers should have resources revoked. Now we're
> proposing
> >>>>> to deny resources to networks that decide not to operate IPv6.
> >>>>>
> >>>>> Second, the proposal is premised on the idea that IP addresses
> are
> >>>>> solely allocated for the purpose of operation on the public
> network,
> >>>>> despite policy being clear that that's not the case. While
> that's
> >>>>> certainly the predominate use case, there is nothing that
> prevents a
> >>>>> private interconnected network from operating on
> >>>>> ARIN-assigned/allocated public space without connecting to the
> >>>>> Internet. Are we proposing to deny any future transfers for
> such
> >>>>> networks? They would by their nature be unable to prove IPv6
> >>>>> connectivity to ARIN (except as a stunt -- see below) and
> would be
> >>>>> unable to get a statement from their upstream (since they
> would have
> >>>>> none) as to the availability of IPv6 connectivity.
> >>>>>
> >>>>> Third, this encourages meaningless stunts. A network that
> does not
> >>>>> desire to opreate V6 is not going to reconsider that decision
> as a
> >>>>> result of this policy. At best, they will get an IPv6
> allocation or
> >>>>> assignment from ARIN, route it to one subnet, put a device on
> it long
> >>>>> enough to perform whatever ceremony ARIN requires to prove IPV6
> >>>>> connectivity, get their transfer, and then shut it down (or
> maybe leave
> >>>>> it there in case they have to reperform the ceremony should
> they
> >>>>> transfer additional addresses in the future). More likely,
> this will
> >>>>> cause the creation of a new industry: organizations needing to
> complete
> >>>>> an IPv6 connectivity validation to get a IPv4 transfer
> processed will
> >>>>> sign a LOA granting their Ceremony Consultant the right to
> announce
> >>>>> their IPv6 allocation/assignment long enough to complete the
> ceremony,
> >>>>> and their consultant will do all the work necessary to get the
> required
> >>>>> box checked in ARIN's systesm.
> >>>>>
> >>>>> This will not drive IPv6 adoption. I oppose the use of ARIN or
> >>>>> community resources on stunts, and I oppose the creation of a
> "IPv6
> >>>>> Ceremony Consultant" industry.
> >>>>>
> >>>>> -- Brett
> >>>>> _______________________________________________
> >>>>> 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:
> >>>>> https://lists.arin.net/mailman/listinfo/arin-ppml
> >>>>> Please contact info at arin.net if you experience any issues.
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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:
> >>>>> https://lists.arin.net/mailman/listinfo/arin-ppml
> >>>>> Please contact info at arin.net if you experience any issues.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>> _______________________________________________
> >>> 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:
> >>> https://lists.arin.net/mailman/listinfo/arin-ppml
> >>> Please contact info at arin.net if you experience any issues.
> > _______________________________________________
> > 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:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> https://lists.arin.net/mailman/listinfo/arin-ppml
>
>
> ------------------------------
>
> End of ARIN-PPML Digest, Vol 173, Issue 35
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20191112/650a45a3/attachment.htm>
More information about the ARIN-PPML
mailing list