From farmer at umn.edu  Mon Aug  5 13:42:13 2019
From: farmer at umn.edu (David Farmer)
Date: Mon, 5 Aug 2019 12:42:13 -0500
Subject: [ARIN-consult] [ARIN-Suggestions] NEW ACSP 2019.17: RSA Change
In-Reply-To: <2dd02fb0-6b50-eab0-9834-faedef83cc3d@arin.net>
References: <2dd02fb0-6b50-eab0-9834-faedef83cc3d@arin.net>
Message-ID: <CAN-Dau2j76hdK5yUYW-xhVEfhUuO97BQOTQLZE2Rb87=Wjkj8w@mail.gmail.com>

While I generally support the idea behind this change, the specifics of the
language added to the RSA matters significantly. Furthermore, I do not
believe that the language added to the RSA should be specific to routing.
The language added to the RSA should be more generic, such as a commitment
to not deliberately interfere with another registrant's use of the
resources that are registered to them within the context of their use on
Internet and not limited to any specific form of interference. Where making
route announcements for blocks without permission of the registrant should
be a specific example of such prohibited interference.

Also, ARIN will need to create formal procedures, in addition to the
informal procedures discussed in the following;

https://teamarin.net/2019/05/06/how-does-arin-handle-reports-of-route-hijacking/


I think only the registrant affected should be able to formally make a
complaint and such a complaint is only actionable by ARIN after the accused
is given a formal opportunity to cure the complaint.

I think this type of change to the RSA is important and within the scope of
the industry self-regulatory framework that the RIR system is intended to
provide. Further, such a change promotes an equitable registry system,
entities that are unwilling to respect other's registrations do not deserve
the protections afforded to them by the registry system. For the RIR system
to be taken seriously and provide effective industry self-regulation it
needs a mechanism to sanction those that systematically and egregiously
thwart the fundamental intent of the registry system, especially when such
activities constitute deliberate interference with the proper operation of
the Internet.

That said, while in my opinion, this change is necessary, it is only a very
small part of the overall fix for the problem, as most incidents are
neither systematic or egregious, and are usually not deliberate, most
incidences are merely accidental. In addition this change to the RSA, the
industry needs to adopt best practices for routing security, including
route filtering and RPKI, to prevent and mitigate these accidental
incidents, such as promoted by the MANRS program;

https://www.manrs.org/

Thanks.

On Wed, Jul 31, 2019 at 2:24 PM ARIN <info at arin.net> wrote:

> On 31 July, we received a new suggestion, numbered 2019.17 upon confirmed
> receipt, that ARIN update its Registration Services Agreement. Staff is
> reviewing this suggestion and will issue a formal response once analysis
> is complete.
>
> The full text of the suggestion may be found below or at:
>
> https://www.arin.net/participate/community/acsp/suggestions/2019-17/
>
> ***
>
> Description: ARIN should modify its Registration Services Agreement so
> that address holders agree to only announce routing for its own address
> blocks, or those address blocks for which it has obtained permission of
> the registrant as listed in the Internet Number Registry System.
>
> Value to Community: The additional value to the community would be that
> ARIN address holders would be far less likely to hijack routes as it
> would represent a breach of their agreement with ARIN.
>
> Timeframe: Not specified
>
> ***
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
>
> _______________________________________________
> arin-suggestions mailing list
> arin-suggestions at arin.net
> https://lists.arin.net/mailman/listinfo/arin-suggestions
>


-- 
===============================================
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: <https://lists.arin.net/pipermail/arin-consult/attachments/20190805/25865919/attachment.htm>

From athompso at athompso.net  Mon Aug  5 15:57:32 2019
From: athompso at athompso.net (Adam Thompson)
Date: Mon, 05 Aug 2019 14:57:32 -0500
Subject: [ARIN-consult] [ARIN-Suggestions] NEW ACSP 2019.17: RSA Change
In-Reply-To: <CAN-Dau2j76hdK5yUYW-xhVEfhUuO97BQOTQLZE2Rb87=Wjkj8w@mail.gmail.com>
References: <2dd02fb0-6b50-eab0-9834-faedef83cc3d@arin.net>
 <CAN-Dau2j76hdK5yUYW-xhVEfhUuO97BQOTQLZE2Rb87=Wjkj8w@mail.gmail.com>
Message-ID: <E07FB348-D7DB-4E06-B0CD-46AA5ECC6224@athompso.net>

I would suggest that ARIN needs to grow a bigger stick before there is any _point_ in changing the RSA to include specific language like that, anyway.

So ARIN terminates my contract and nullifies my number assignments - if I'm a malicious or even just egregiously negligent user, my reaction is "so what?"  Even here in Winnipeg, there's at least one ISP I'm pretty sure will peer with me and/or advertise for me, even if I'm using bogus IP and AS numbers (for a suitable price, of course).

If MANRS/RPKI/IRR/etc. had decent adoption here, I think the situation would be different.

I just don't understand why we're talking about adding T&C's when there's so little consequence to willfully breaching them anyway.

-Adam


On August 5, 2019 12:42:13 p.m. CDT, David Farmer <farmer at umn.edu> wrote:
>While I generally support the idea behind this change, the specifics of
>the
>language added to the RSA matters significantly. Furthermore, I do not
>believe that the language added to the RSA should be specific to
>routing.
>The language added to the RSA should be more generic, such as a
>commitment
>to not deliberately interfere with another registrant's use of the
>resources that are registered to them within the context of their use
>on
>Internet and not limited to any specific form of interference. Where
>making
>route announcements for blocks without permission of the registrant
>should
>be a specific example of such prohibited interference.
>
>Also, ARIN will need to create formal procedures, in addition to the
>informal procedures discussed in the following;
>
>https://teamarin.net/2019/05/06/how-does-arin-handle-reports-of-route-hijacking/
>
>
>I think only the registrant affected should be able to formally make a
>complaint and such a complaint is only actionable by ARIN after the
>accused
>is given a formal opportunity to cure the complaint.
>
>I think this type of change to the RSA is important and within the
>scope of
>the industry self-regulatory framework that the RIR system is intended
>to
>provide. Further, such a change promotes an equitable registry system,
>entities that are unwilling to respect other's registrations do not
>deserve
>the protections afforded to them by the registry system. For the RIR
>system
>to be taken seriously and provide effective industry self-regulation it
>needs a mechanism to sanction those that systematically and egregiously
>thwart the fundamental intent of the registry system, especially when
>such
>activities constitute deliberate interference with the proper operation
>of
>the Internet.
>
>That said, while in my opinion, this change is necessary, it is only a
>very
>small part of the overall fix for the problem, as most incidents are
>neither systematic or egregious, and are usually not deliberate, most
>incidences are merely accidental. In addition this change to the RSA,
>the
>industry needs to adopt best practices for routing security, including
>route filtering and RPKI, to prevent and mitigate these accidental
>incidents, such as promoted by the MANRS program;
>
>https://www.manrs.org/
>
>Thanks.
>
>On Wed, Jul 31, 2019 at 2:24 PM ARIN <info at arin.net> wrote:
>
>> On 31 July, we received a new suggestion, numbered 2019.17 upon
>confirmed
>> receipt, that ARIN update its Registration Services Agreement. Staff
>is
>> reviewing this suggestion and will issue a formal response once
>analysis
>> is complete.
>>
>> The full text of the suggestion may be found below or at:
>>
>> https://www.arin.net/participate/community/acsp/suggestions/2019-17/
>>
>> ***
>>
>> Description: ARIN should modify its Registration Services Agreement
>so
>> that address holders agree to only announce routing for its own
>address
>> blocks, or those address blocks for which it has obtained permission
>of
>> the registrant as listed in the Internet Number Registry System.
>>
>> Value to Community: The additional value to the community would be
>that
>> ARIN address holders would be far less likely to hijack routes as it
>> would represent a breach of their agreement with ARIN.
>>
>> Timeframe: Not specified
>>
>> ***
>>
>> Regards,
>>
>> Communications and Member Services
>> American Registry for Internet Numbers (ARIN)
>>
>>
>>
>> _______________________________________________
>> arin-suggestions mailing list
>> arin-suggestions at arin.net
>> https://lists.arin.net/mailman/listinfo/arin-suggestions
>>
>
>
>-- 
>===============================================
>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
>===============================================

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20190805/caeb733c/attachment.htm>

From farmer at umn.edu  Mon Aug  5 16:54:53 2019
From: farmer at umn.edu (David Farmer)
Date: Mon, 5 Aug 2019 15:54:53 -0500
Subject: [ARIN-consult] [ARIN-Suggestions] NEW ACSP 2019.17: RSA Change
In-Reply-To: <E07FB348-D7DB-4E06-B0CD-46AA5ECC6224@athompso.net>
References: <2dd02fb0-6b50-eab0-9834-faedef83cc3d@arin.net>
 <CAN-Dau2j76hdK5yUYW-xhVEfhUuO97BQOTQLZE2Rb87=Wjkj8w@mail.gmail.com>
 <E07FB348-D7DB-4E06-B0CD-46AA5ECC6224@athompso.net>
Message-ID: <CAN-Dau2DQcLLj2eiu+x-2-BtkpjmpHztWD68WKkvML84+UVHbg@mail.gmail.com>

I think you are making my point for me, currently, there aren't even
theoretical consequences for ignoring the RIR system, even deliberately
using someone else's allocations on the Internet, let alone using bogons.
If you deliberately use someone else's allocations the RIR system currently
continues to protect your allocations, even though you are thwarting the
system. This is a form of "free-riding", you are enjoying the protection
provided by the RIR system that is honored by many if not most operators,
without honoring the protection it should be providing to others. I think
those that deliberately thwart the system should lose the protection of the
system.

In my opinion, this is how ARIN grows the bigger stick you seem to be
saying it needs. ARIN and the other RIRs only have the sticks that we give
them. If you think they need sticks, we need to give them the sticks. If we
don't give them any sticks, we can't complain that that don't have them and
that they don't use them.

As I said this by itself doesn't solve the problem, MANRS and other efforts
are equally if not more important for the practical solution of this
problem. But, If you think the RIRs should have any sticks at all to bring
to bear even in the most systematic and egregious instances then we have to
give them the sticks and that is done through T&Cs in the RSA contract.

If you don't think ARIN or the other RIRs should have any sticks, I can
respect that, but then don't say "ARIN needs to grow a bigger stick."

Thanks.

On Mon, Aug 5, 2019 at 3:06 PM Adam Thompson <athompso at athompso.net> wrote:

> I would suggest that ARIN needs to grow a bigger stick before there is any
> _point_ in changing the RSA to include specific language like that, anyway.
>
> So ARIN terminates my contract and nullifies my number assignments - if
> I'm a malicious or even just egregiously negligent user, my reaction is "so
> what?" Even here in Winnipeg, there's at least one ISP I'm pretty sure will
> peer with me and/or advertise for me, even if I'm using bogus IP and AS
> numbers (for a suitable price, of course).
>
> If MANRS/RPKI/IRR/etc. had decent adoption here, I think the situation
> would be different.
>
> I just don't understand why we're talking about adding T&C's when there's
> so little consequence to willfully breaching them anyway.
>
> -Adam
>
>
> On August 5, 2019 12:42:13 p.m. CDT, David Farmer <farmer at umn.edu> wrote:
>>
>> While I generally support the idea behind this change, the specifics of
>> the language added to the RSA matters significantly. Furthermore, I do not
>> believe that the language added to the RSA should be specific to routing.
>> The language added to the RSA should be more generic, such as a commitment
>> to not deliberately interfere with another registrant's use of the
>> resources that are registered to them within the context of their use on
>> Internet and not limited to any specific form of interference. Where making
>> route announcements for blocks without permission of the registrant should
>> be a specific example of such prohibited interference.
>>
>> Also, ARIN will need to create formal procedures, in addition to the
>> informal procedures discussed in the following;
>>
>>
>> https://teamarin.net/2019/05/06/how-does-arin-handle-reports-of-route-hijacking/
>>
>>
>> I think only the registrant affected should be able to formally make a
>> complaint and such a complaint is only actionable by ARIN after the accused
>> is given a formal opportunity to cure the complaint.
>>
>> I think this type of change to the RSA is important and within the scope
>> of the industry self-regulatory framework that the RIR system is intended
>> to provide. Further, such a change promotes an equitable registry system,
>> entities that are unwilling to respect other's registrations do not deserve
>> the protections afforded to them by the registry system. For the RIR system
>> to be taken seriously and provide effective industry self-regulation it
>> needs a mechanism to sanction those that systematically and egregiously
>> thwart the fundamental intent of the registry system, especially when such
>> activities constitute deliberate interference with the proper operation of
>> the Internet.
>>
>> That said, while in my opinion, this change is necessary, it is only a
>> very small part of the overall fix for the problem, as most incidents are
>> neither systematic or egregious, and are usually not deliberate, most
>> incidences are merely accidental. In addition this change to the RSA, the
>> industry needs to adopt best practices for routing security, including
>> route filtering and RPKI, to prevent and mitigate these accidental
>> incidents, such as promoted by the MANRS program;
>>
>> https://www.manrs.org/
>>
>> Thanks.
>>
>> On Wed, Jul 31, 2019 at 2:24 PM ARIN <info at arin.net> wrote:
>>
>>> On 31 July, we received a new suggestion, numbered 2019.17 upon confirmed
>>> receipt, that ARIN update its Registration Services Agreement. Staff is
>>> reviewing this suggestion and will issue a formal response once analysis
>>> is complete.
>>>
>>> The full text of the suggestion may be found below or at:
>>>
>>> https://www.arin.net/participate/community/acsp/suggestions/2019-17/
>>>
>>> ***
>>>
>>> Description: ARIN should modify its Registration Services Agreement so
>>> that address holders agree to only announce routing for its own address
>>> blocks, or those address blocks for which it has obtained permission of
>>> the registrant as listed in the Internet Number Registry System.
>>>
>>> Value to Community: The additional value to the community would be that
>>> ARIN address holders would be far less likely to hijack routes as it
>>> would represent a breach of their agreement with ARIN.
>>>
>>> Timeframe: Not specified
>>>
>>> ***
>>>
>>> Regards,
>>>
>>> Communications and Member Services
>>> American Registry for Internet Numbers (ARIN)
>>>
>>>
>>>
>>> _______________________________________________
>>> arin-suggestions mailing list
>>> arin-suggestions at arin.net
>>> https://lists.arin.net/mailman/listinfo/arin-suggestions
>>>
>>
>>
>> --
>> ===============================================
>> 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
>> ===============================================
>>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>


-- 
===============================================
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: <https://lists.arin.net/pipermail/arin-consult/attachments/20190805/eb132be5/attachment.htm>

From athompso at athompso.net  Mon Aug  5 18:44:49 2019
From: athompso at athompso.net (Adam Thompson)
Date: Mon, 05 Aug 2019 17:44:49 -0500
Subject: [ARIN-consult] [ARIN-Suggestions] NEW ACSP 2019.17: RSA Change
In-Reply-To: <CAN-Dau2DQcLLj2eiu+x-2-BtkpjmpHztWD68WKkvML84+UVHbg@mail.gmail.com>
References: <2dd02fb0-6b50-eab0-9834-faedef83cc3d@arin.net>
 <CAN-Dau2j76hdK5yUYW-xhVEfhUuO97BQOTQLZE2Rb87=Wjkj8w@mail.gmail.com>
 <E07FB348-D7DB-4E06-B0CD-46AA5ECC6224@athompso.net>
 <CAN-Dau2DQcLLj2eiu+x-2-BtkpjmpHztWD68WKkvML84+UVHbg@mail.gmail.com>
Message-ID: <62DA4F4A-62BB-4AFA-B126-34944846C2EA@athompso.net>

I see it as orthogonal, but YMMV.

I'd very much like the RIRs to have bigger sticks.

However, I don't know of any proposal or idea, current or historical, for said stick(s) that is or has been acceptable to a sufficiently broad cross-section of the membership to get any traction. :-(

(Nor am I about to suggest anything new, even if I had a new idea, as I don't need to get flamed that much this month.)

-Adam

On August 5, 2019 3:54:53 p.m. CDT, David Farmer <farmer at umn.edu> wrote:
>I think you are making my point for me, currently, there aren't even
>theoretical consequences for ignoring the RIR system, even deliberately
>using someone else's allocations on the Internet, let alone using
>bogons.
>If you deliberately use someone else's allocations the RIR system
>currently
>continues to protect your allocations, even though you are thwarting
>the
>system. This is a form of "free-riding", you are enjoying the
>protection
>provided by the RIR system that is honored by many if not most
>operators,
>without honoring the protection it should be providing to others. I
>think
>those that deliberately thwart the system should lose the protection of
>the
>system.
>
>In my opinion, this is how ARIN grows the bigger stick you seem to be
>saying it needs. ARIN and the other RIRs only have the sticks that we
>give
>them. If you think they need sticks, we need to give them the sticks.
>If we
>don't give them any sticks, we can't complain that that don't have them
>and
>that they don't use them.
>
>As I said this by itself doesn't solve the problem, MANRS and other
>efforts
>are equally if not more important for the practical solution of this
>problem. But, If you think the RIRs should have any sticks at all to
>bring
>to bear even in the most systematic and egregious instances then we
>have to
>give them the sticks and that is done through T&Cs in the RSA contract.
>
>If you don't think ARIN or the other RIRs should have any sticks, I can
>respect that, but then don't say "ARIN needs to grow a bigger stick."
>
>Thanks.
>
>On Mon, Aug 5, 2019 at 3:06 PM Adam Thompson <athompso at athompso.net>
>wrote:
>
>> I would suggest that ARIN needs to grow a bigger stick before there
>is any
>> _point_ in changing the RSA to include specific language like that,
>anyway.
>>
>> So ARIN terminates my contract and nullifies my number assignments -
>if
>> I'm a malicious or even just egregiously negligent user, my reaction
>is "so
>> what?" Even here in Winnipeg, there's at least one ISP I'm pretty
>sure will
>> peer with me and/or advertise for me, even if I'm using bogus IP and
>AS
>> numbers (for a suitable price, of course).
>>
>> If MANRS/RPKI/IRR/etc. had decent adoption here, I think the
>situation
>> would be different.
>>
>> I just don't understand why we're talking about adding T&C's when
>there's
>> so little consequence to willfully breaching them anyway.
>>
>> -Adam
>>
>>
>> On August 5, 2019 12:42:13 p.m. CDT, David Farmer <farmer at umn.edu>
>wrote:
>>>
>>> While I generally support the idea behind this change, the specifics
>of
>>> the language added to the RSA matters significantly. Furthermore, I
>do not
>>> believe that the language added to the RSA should be specific to
>routing.
>>> The language added to the RSA should be more generic, such as a
>commitment
>>> to not deliberately interfere with another registrant's use of the
>>> resources that are registered to them within the context of their
>use on
>>> Internet and not limited to any specific form of interference. Where
>making
>>> route announcements for blocks without permission of the registrant
>should
>>> be a specific example of such prohibited interference.
>>>
>>> Also, ARIN will need to create formal procedures, in addition to the
>>> informal procedures discussed in the following;
>>>
>>>
>>>
>https://teamarin.net/2019/05/06/how-does-arin-handle-reports-of-route-hijacking/
>>>
>>>
>>> I think only the registrant affected should be able to formally make
>a
>>> complaint and such a complaint is only actionable by ARIN after the
>accused
>>> is given a formal opportunity to cure the complaint.
>>>
>>> I think this type of change to the RSA is important and within the
>scope
>>> of the industry self-regulatory framework that the RIR system is
>intended
>>> to provide. Further, such a change promotes an equitable registry
>system,
>>> entities that are unwilling to respect other's registrations do not
>deserve
>>> the protections afforded to them by the registry system. For the RIR
>system
>>> to be taken seriously and provide effective industry self-regulation
>it
>>> needs a mechanism to sanction those that systematically and
>egregiously
>>> thwart the fundamental intent of the registry system, especially
>when such
>>> activities constitute deliberate interference with the proper
>operation of
>>> the Internet.
>>>
>>> That said, while in my opinion, this change is necessary, it is only
>a
>>> very small part of the overall fix for the problem, as most
>incidents are
>>> neither systematic or egregious, and are usually not deliberate,
>most
>>> incidences are merely accidental. In addition this change to the
>RSA, the
>>> industry needs to adopt best practices for routing security,
>including
>>> route filtering and RPKI, to prevent and mitigate these accidental
>>> incidents, such as promoted by the MANRS program;
>>>
>>> https://www.manrs.org/
>>>
>>> Thanks.
>>>
>>> On Wed, Jul 31, 2019 at 2:24 PM ARIN <info at arin.net> wrote:
>>>
>>>> On 31 July, we received a new suggestion, numbered 2019.17 upon
>confirmed
>>>> receipt, that ARIN update its Registration Services Agreement.
>Staff is
>>>> reviewing this suggestion and will issue a formal response once
>analysis
>>>> is complete.
>>>>
>>>> The full text of the suggestion may be found below or at:
>>>>
>>>>
>https://www.arin.net/participate/community/acsp/suggestions/2019-17/
>>>>
>>>> ***
>>>>
>>>> Description: ARIN should modify its Registration Services Agreement
>so
>>>> that address holders agree to only announce routing for its own
>address
>>>> blocks, or those address blocks for which it has obtained
>permission of
>>>> the registrant as listed in the Internet Number Registry System.
>>>>
>>>> Value to Community: The additional value to the community would be
>that
>>>> ARIN address holders would be far less likely to hijack routes as
>it
>>>> would represent a breach of their agreement with ARIN.
>>>>
>>>> Timeframe: Not specified
>>>>
>>>> ***
>>>>
>>>> Regards,
>>>>
>>>> Communications and Member Services
>>>> American Registry for Internet Numbers (ARIN)
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> arin-suggestions mailing list
>>>> arin-suggestions at arin.net
>>>> https://lists.arin.net/mailman/listinfo/arin-suggestions
>>>>
>>>
>>>
>>> --
>>> ===============================================
>>> 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
>>> ===============================================
>>>
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
>
>
>-- 
>===============================================
>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
>===============================================

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20190805/383b892c/attachment.htm>

From info at arin.net  Mon Aug 12 10:57:50 2019
From: info at arin.net (ARIN)
Date: Mon, 12 Aug 2019 10:57:50 -0400
Subject: [ARIN-consult] Consultation on Deleting Aged Report Request Tickets
 is Now Closed
Message-ID: <598afae2-e2f5-5cdc-46b0-0ca56f14fd85@arin.net>

ARIN thanks those who provided valuable feedback during this
consultation on options for deleting aged report request tickets from
ARIN Online. This important feedback will help inform ARIN?s path
forward in this area.

Based on feedback, we have changed our implementation plan to include an
?archive? option that users may select on a ticket to exclude it from
the 90-day expiration policy. At implementation, we will notify users of
the archive option so they can update any report tickets they wish to
retain before we begin deleting aged report request tickets. ARIN users
may also contact the registration services help desk to have ARIN mark
all of their existing report request tickets for archive.

The ONLY tickets that will be affected are requests for the following
reports that are over 90-days old:

 ??? * Associations reports
 ??? * WhoWas reports
 ??? * Reassignment reports
 ??? * User Reassignment reports

This consultation is available at:
https://www.arin.net/vault/participate/acsp/community_consult/06-26-2019_aged_reports.html

Regards,



John Curran

President and CEO
American Registry for Internet Numbers (ARIN)