From eosterweil at verisign.com  Thu Feb  1 13:03:40 2018
From: eosterweil at verisign.com (Osterweil, Eric)
Date: Thu, 1 Feb 2018 18:03:40 +0000
Subject: [ARIN-consult] Comment on IRR Consultation
Message-ID: <D6E57C75-048C-4BA8-825C-B1BA6918D222@verisign.com>

To whom it may concern,

ARIN?s newly opened Community Consultation that solicits feedback on ARIN?s IRR Roadmap (posted on 09, January 2018) is an encouraging development.  We, at Verisign, are supportive of this initiative.  We believe it aligns well with our long-standing interests in Internet Security, Stability, and Resiliency and the community?s existing security-related needs to ensure the veracity of IRR objects (described in [RFC-7682).

Eric Osterweil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20180201/b6c29e2c/attachment.html>

From jcurran at arin.net  Thu Feb  1 13:27:23 2018
From: jcurran at arin.net (John Curran)
Date: Thu, 1 Feb 2018 18:27:23 +0000
Subject: [ARIN-consult] Comment on IRR Consultation
In-Reply-To: <D6E57C75-048C-4BA8-825C-B1BA6918D222@verisign.com>
References: <D6E57C75-048C-4BA8-825C-B1BA6918D222@verisign.com>
Message-ID: <CA55680A-FD5F-4CFF-BAB5-D109BA8592A8@arin.net>

On Feb 1, 2018, at 12:04 PM, Osterweil, Eric <eosterweil at verisign.com<mailto:eosterweil at verisign.com>> wrote:
...
ARIN's newly opened Community Consultation that solicits feedback on ARIN's IRR Roadmap (posted on 09, January 2018) is an encouraging development.  We, at Verisign, are supportive of this initiative.  We believe it aligns well with our long-standing interests in Internet Security, Stability, and Resiliency and the community's existing security-related needs to ensure the veracity of IRR objects (described in [RFC-7682).

Eric -

That's very clear and helpful feedback on this consultation.

Thanks!
/John

John Curran
President and CEO
ARIN

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20180201/4253edae/attachment.html>

From info at arin.net  Fri Feb  2 08:59:35 2018
From: info at arin.net (ARIN)
Date: Fri, 2 Feb 2018 08:59:35 -0500
Subject: [ARIN-consult] ASO Review Consultation 2018
Message-ID: <add605bc-1f11-b364-d954-9184f03bb0fb@arin.net>

As a part of the Number Resource Organization (NRO), ARIN is seeking
community input on the NRO community consultation on the ASO review.

"The most recent ASO Review concluded with 18 recommendations, which the
NRO has resolved to accept. The first 17 recommendations are well
defined and practical, and can be implemented by actions of the NRO
Secretariat, or of the ASO Address Council, with respect to
administrative procedures, documentation, or in some cases adjustments
to agreements which are expected to be non-controversial.

The 18th recommendation of the Report is that "The NRO should initiate a
public consultation, involving the five RIR communities, to determine
the future structure of the ASO". The NRO EC has concluded to accept
that recommendation and is hereby launching a consultation on the issues
identified in the ASO Review Report."

The full Consultation is available for review at:

https://www.nro.net/aso-review-consultation-2018/

Issues to Address:

The scope of this consultation includes the structural implications of
issues identified by the ASO Review, including but not limited to:

      * Any updates and adjustments identified as required for
ASO-related documents
      * Any procedural clarifications and adjustments identified
      * Reported confusion of roles between ASO and NRO, and their 
components
      * Perceived complexity of relationships among NRO, ASO and ICANN
      * Relevance and cost to the RIRs of various ICANN engagement 
activities

Out of the Scope of this consultation are the following aspects:

      * Global Policy Development Process (GPDP)
      * ASO AC role with GPDP

Specific Questions:

The NRO EC is looking to specific answer to the following questions:

      * What adjustments, if any, should be made in order to address the
issues described above?
      * Should adjustments be limited to NRO MoU, ASO MoU, and/or ICANN
Bylaws
      * Over what timeframes should these adjustments be developed and
implemented
      * What strategic aspects should we pay attention to when
considering these adjustments?

Please provide comments to arin-consult at arin.net. All ARIN community
feedback will be forwarded on to the NRO. You can subscribe to this
mailing list at: http://lists.arin.net/mailman/listinfo/arin-consult.

This consultation will remain open through 5:00 PM EST on Wednesday, 28
February 2018.

Regards,

John Curran
President and CEO
American Registry for Internet Numbers (ARIN)





From info at arin.net  Fri Feb  9 10:29:42 2018
From: info at arin.net (ARIN)
Date: Fri, 9 Feb 2018 10:29:42 -0500
Subject: [ARIN-consult] ASO Review Consultation 2018
In-Reply-To: <add605bc-1f11-b364-d954-9184f03bb0fb@arin.net>
References: <add605bc-1f11-b364-d954-9184f03bb0fb@arin.net>
Message-ID: <50943a0a-8707-5544-282c-5d5a1b668972@arin.net>

The NRO EC and ASO AC Joint Response to the 2017 Independent ASO Review 
Recommendations has been published on the NRO website for community 
consideration.

https://www.nro.net/nro-ec-and-aso-ac-joint-response-to-the-2017-independent-aso-review-recommendations/

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


On 2/2/18 8:59 AM, ARIN wrote:
> As a part of the Number Resource Organization (NRO), ARIN is seeking
> community input on the NRO community consultation on the ASO review.
>
> "The most recent ASO Review concluded with 18 recommendations, which the
> NRO has resolved to accept. The first 17 recommendations are well
> defined and practical, and can be implemented by actions of the NRO
> Secretariat, or of the ASO Address Council, with respect to
> administrative procedures, documentation, or in some cases adjustments
> to agreements which are expected to be non-controversial.
>
> The 18th recommendation of the Report is that "The NRO should initiate a
> public consultation, involving the five RIR communities, to determine
> the future structure of the ASO". The NRO EC has concluded to accept
> that recommendation and is hereby launching a consultation on the issues
> identified in the ASO Review Report."
>
> The full Consultation is available for review at:
>
> https://www.nro.net/aso-review-consultation-2018/
>
> Issues to Address:
>
> The scope of this consultation includes the structural implications of
> issues identified by the ASO Review, including but not limited to:
>
>      * Any updates and adjustments identified as required for
> ASO-related documents
>      * Any procedural clarifications and adjustments identified
>      * Reported confusion of roles between ASO and NRO, and their 
> components
>      * Perceived complexity of relationships among NRO, ASO and ICANN
>      * Relevance and cost to the RIRs of various ICANN engagement 
> activities
>
> Out of the Scope of this consultation are the following aspects:
>
>      * Global Policy Development Process (GPDP)
>      * ASO AC role with GPDP
>
> Specific Questions:
>
> The NRO EC is looking to specific answer to the following questions:
>
>      * What adjustments, if any, should be made in order to address the
> issues described above?
>      * Should adjustments be limited to NRO MoU, ASO MoU, and/or ICANN
> Bylaws
>      * Over what timeframes should these adjustments be developed and
> implemented
>      * What strategic aspects should we pay attention to when
> considering these adjustments?
>
> Please provide comments to arin-consult at arin.net. All ARIN community
> feedback will be forwarded on to the NRO. You can subscribe to this
> mailing list at: http://lists.arin.net/mailman/listinfo/arin-consult.
>
> This consultation will remain open through 5:00 PM EST on Wednesday, 28
> February 2018.
>
> Regards,
>
> John Curran
> President and CEO
> American Registry for Internet Numbers (ARIN)
>
>
>



From bjones at vt.edu  Tue Feb 13 14:05:36 2018
From: bjones at vt.edu (Brian Jones)
Date: Tue, 13 Feb 2018 19:05:36 +0000
Subject: [ARIN-consult] Consultation on ARIN IRR Roadmap Extended
 through 25 April 2018
In-Reply-To: <d8a5106b-00c9-0dd2-36f3-c69d5a4a0ffa@arin.net>
References: <d8a5106b-00c9-0dd2-36f3-c69d5a4a0ffa@arin.net>
Message-ID: <CANyqO+F0LJi+8N5kt8eKhcndo-OZv5hq9ZAykuodzDxm6=Hujw@mail.gmail.com>

I agree that this is an effort worth pursuing. I do have security concerns
about how authentication and authorization occurs.

I would recommend focusing efforts around a set of agreed upon standards
and remove any mention of ? best practices? from the language. That is an
overloaded term that can mean anything to anyone, whereas a set of agreed
upon standards should allow for clearer and more efficient operation.  (See
last bullet that includes ?best practices?.)

fwiw
?
Brian

On Wed, Jan 31, 2018 at 11:22 AM ARIN <info at arin.net> wrote:

> Based on the level of community interest and the significance of the
> work involved in improving the ARIN Internet Routing Registry (IRR), we
> are extending the discussion period on the current consultation through
> 25 April 2018. The consultation text is available at:
> https://www.arin.net/participate/acsp/community_consult/01-09-2018_irr.html
>
> This extension will allow time for ARIN staff to present on this topic
> at both the North American Network Operators Group (NANOG) meeting,
> 19-21 February in Atlanta, GA and at the upcoming ARIN 41 Public Policy
> and Members Meeting, 15-18 April in Miami, Fl.
>
> For details on both events, including remote participation options, visit:
>
> NANOG 72:
> https://www.nanog.org/
> Presentation on 20 February at 10:00 AM EDT
>
> ARIN 41:
> https://www.arin.net/ARIN41
>
> We encourage all interested individuals to provide comments to
> arin-consult at arin.net. You can subscribe to this mailing list at:
> http://lists.arin.net/mailman/listinfo/arin-consult.
>
> Regards,
>
> John Curran
> President and CEO
> American Registry for Internet Numbers (ARIN)
>
>
>
> _______________________________________________
> ARIN-Consult
> You are receiving this message because you are subscribed to the ARIN
> Consult Mailing
> List (ARIN-consult at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-consult Please contact the
> ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20180213/a92ce22a/attachment.html>

From job at ntt.net  Tue Feb 13 14:11:34 2018
From: job at ntt.net (Job Snijders)
Date: Tue, 13 Feb 2018 19:11:34 +0000
Subject: [ARIN-consult] Consultation on ARIN IRR Roadmap Extended
 through 25 April 2018
In-Reply-To: <CANyqO+F0LJi+8N5kt8eKhcndo-OZv5hq9ZAykuodzDxm6=Hujw@mail.gmail.com>
References: <d8a5106b-00c9-0dd2-36f3-c69d5a4a0ffa@arin.net>
 <CANyqO+F0LJi+8N5kt8eKhcndo-OZv5hq9ZAykuodzDxm6=Hujw@mail.gmail.com>
Message-ID: <20180213191134.GB26009@vurt.meerval.net>

Dear Brian,

On Tue, Feb 13, 2018 at 07:05:36PM +0000, Brian Jones wrote:
> I agree that this is an effort worth pursuing. I do have security concerns
> about how authentication and authorization occurs.
> 
> I would recommend focusing efforts around a set of agreed upon standards
> and remove any mention of ? best practices? from the language. That is an
> overloaded term that can mean anything to anyone, whereas a set of agreed
> upon standards should allow for clearer and more efficient operation.  (See
> last bullet that includes ?best practices?.)

At this point there aren't really any proper standards to adhere to: the
"standards" that exist (as IETF documents) are grossly outdated and have
issues. We mostly have common sense and learning from other registries'
mistakes.

Kind regards,

Job


From bjones at vt.edu  Tue Feb 13 14:17:28 2018
From: bjones at vt.edu (Brian Jones)
Date: Tue, 13 Feb 2018 19:17:28 +0000
Subject: [ARIN-consult] Consultation on ARIN IRR Roadmap Extended
 through 25 April 2018
In-Reply-To: <20180213191134.GB26009@vurt.meerval.net>
References: <d8a5106b-00c9-0dd2-36f3-c69d5a4a0ffa@arin.net>
 <CANyqO+F0LJi+8N5kt8eKhcndo-OZv5hq9ZAykuodzDxm6=Hujw@mail.gmail.com>
 <20180213191134.GB26009@vurt.meerval.net>
Message-ID: <CANyqO+FbHOKkc4WGtr7KHsCVFJC=f-n7t2gCvdzzou9jwqaDKA@mail.gmail.com>

So in my view it is evident we need to work toward a set of standards. Its
okay to use best practices to get there, but the goal should be a set of
standards that all the participants can agree to and rely on imho.

Thanks,
Brian

On Tue, Feb 13, 2018 at 2:11 PM Job Snijders <job at ntt.net> wrote:

> Dear Brian,
>
> On Tue, Feb 13, 2018 at 07:05:36PM +0000, Brian Jones wrote:
> > I agree that this is an effort worth pursuing. I do have security
> concerns
> > about how authentication and authorization occurs.
> >
> > I would recommend focusing efforts around a set of agreed upon standards
> > and remove any mention of ? best practices? from the language. That is an
> > overloaded term that can mean anything to anyone, whereas a set of agreed
> > upon standards should allow for clearer and more efficient operation.
> (See
> > last bullet that includes ?best practices?.)
>
> At this point there aren't really any proper standards to adhere to: the
> "standards" that exist (as IETF documents) are grossly outdated and have
> issues. We mostly have common sense and learning from other registries'
> mistakes.
>
> Kind regards,
>
> Job
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20180213/ba42516b/attachment.html>

From farmer at umn.edu  Thu Feb 22 15:13:16 2018
From: farmer at umn.edu (David Farmer)
Date: Thu, 22 Feb 2018 14:13:16 -0600
Subject: [ARIN-consult] Consultation on ARIN IRR Roadmap
Message-ID: <CAN-Dau3EKZ9Ts124KkJCeh35NS2-6WT23uDinTuDf5tEQ_CbHQ@mail.gmail.com>

On Tuesday at NANOG there was a presentation on ARIN's IRR Roadmap.

https://youtu.be/tsWq_LgNS5s

To me, one of the more interesting questions was should the old data be
carried over into the new system.  My answer is both YES and NO.
More precisely, NO unverified IRR data should not be imported into the new
ARIN IRR. However YES, I want the opportunity to import and validate my
current data from the old ARIN IRR, or other IRRs for that matter, and have
it published into the new system.

To facilitate this transition I would suggest renaming the old ARIN IRR, to
something like "ARINOLD", allowing the new ARIN IRR to use the name
"ARIN".  This would allow both the old and new ARIN IRRs to be available
for some period of time, I'd suggest a year or more.

Also, I would like to have the ability to import routing information from
the live BGP routing system and be able to validate it for publication into
the new ARIN IRR as well. Think of it as an IRR wizard, the wizard would
look at the BGP routing system and recommends the creation or removal of
IRR entries based on my live BGP announcements.  It would also be great if
there was such a wizard for RPKI ROAs in ARIN's RPKI system too.

Thanks

-- 
===============================================
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 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20180222/9a785b67/attachment.html>

From jschiller at google.com  Thu Feb 22 16:06:28 2018
From: jschiller at google.com (Jason Schiller)
Date: Thu, 22 Feb 2018 16:06:28 -0500
Subject: [ARIN-consult] Consultation on ARIN IRR Roadmap
In-Reply-To: <CAN-Dau3EKZ9Ts124KkJCeh35NS2-6WT23uDinTuDf5tEQ_CbHQ@mail.gmail.com>
References: <CAN-Dau3EKZ9Ts124KkJCeh35NS2-6WT23uDinTuDf5tEQ_CbHQ@mail.gmail.com>
Message-ID: <CAC4yj2UwFcQzebb-=a-K6g5+VmEyCjbV1pCoYKv1wAG49zSUkQ@mail.gmail.com>

I am confused...

the current ARIN IRR is rr.arin.net

as in:

whois -h rr.arin.net 199.43.0.0/24

% This is the ARIN Routing Registry.

% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '199.43.0.0/24AS10745'

route:          199.43.0.0/24
descr:          American Registry for Internet Numbers
                PO Box 232290
                Centreville, VA 20120
                US
origin:         AS10745
mnt-by:         MNT-ARIN
source:         ARIN # Filtered
remarks:        ****************************
remarks:        * THIS OBJECT CONTAINS PLACEHOLDER DATA
remarks:        * Please note that all data that is generally regarded as
personal
remarks:        * data has been removed from this object.
remarks:        * To view the original object, please query the ARIN
Database at:
remarks:        * http://www.arin.net/whois
remarks:        ****************************


Are you just talking about handy language to use in discussions to make
things more clear?

__Jason

On Thu, Feb 22, 2018 at 3:13 PM, David Farmer <farmer at umn.edu> wrote:

> On Tuesday at NANOG there was a presentation on ARIN's IRR Roadmap.
>
> https://youtu.be/tsWq_LgNS5s
>
> To me, one of the more interesting questions was should the old data be
> carried over into the new system.  My answer is both YES and NO.
> More precisely, NO unverified IRR data should not be imported into the new
> ARIN IRR. However YES, I want the opportunity to import and validate my
> current data from the old ARIN IRR, or other IRRs for that matter, and have
> it published into the new system.
>
> To facilitate this transition I would suggest renaming the old ARIN IRR,
> to something like "ARINOLD", allowing the new ARIN IRR to use the name
> "ARIN".  This would allow both the old and new ARIN IRRs to be available
> for some period of time, I'd suggest a year or more.
>
> Also, I would like to have the ability to import routing information from
> the live BGP routing system and be able to validate it for publication into
> the new ARIN IRR as well. Think of it as an IRR wizard, the wizard would
> look at the BGP routing system and recommends the creation or removal of
> IRR entries based on my live BGP announcements.  It would also be great if
> there was such a wizard for RPKI ROAs in ARIN's RPKI system too.
>
> Thanks
>
> --
> ===============================================
> 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 <(612)%20626-0815>
> Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
> ===============================================
>
> _______________________________________________
> ARIN-Consult
> You are receiving this message because you are subscribed to the ARIN
> Consult Mailing
> List (ARIN-consult at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-consult Please contact the
> ARIN Member Services
> Help Desk at info at arin.net if you experience any issues.
>



-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20180222/acf72403/attachment.html>

From job at ntt.net  Thu Feb 22 16:19:59 2018
From: job at ntt.net (Job Snijders)
Date: Thu, 22 Feb 2018 21:19:59 +0000
Subject: [ARIN-consult] Consultation on ARIN IRR Roadmap
In-Reply-To: <20180222211618.GI43843@vurt.meerval.net>
References: <CAN-Dau3EKZ9Ts124KkJCeh35NS2-6WT23uDinTuDf5tEQ_CbHQ@mail.gmail.com>
 <CAC4yj2UwFcQzebb-=a-K6g5+VmEyCjbV1pCoYKv1wAG49zSUkQ@mail.gmail.com>
 <20180222211618.GI43843@vurt.meerval.net>
Message-ID: <20180222211959.GJ43843@vurt.meerval.net>

On Thu, Feb 22, 2018 at 04:06:28PM -0500, Jason Schiller wrote:
> I am confused...
> 
> the current ARIN IRR is rr.arin.net

ARIN manages an IRR database called "ARIN" in a daemon running on host
rr.arin.net. You can publish data from multiple databases via a single
fqdn like 'rr.arin.net'. I think what David Farmer is talking about is
the "source: ARIN" aspect of the data you show:

    $ whois -h rr.arin.net 199.43.0.0/24 | grep source
    source:         ARIN # Filtered

RIPE is developing something similar, where non-authoritative data will
be marked with "source: RIPE-NONAUTH" rather than "source: RIPE" to show
which objects came into existance because of the chain of trust from the
RIR data to the IRR data, and some didn't.

With an example from the ARIN IRR:

    job at vurt ~$ whois -h rr.arin.net -- "-B 192.0.2.0/24" | egrep "route:|source:"
    route:          192.0.2.0/24
    source:         ARIN
    route:          192.0.2.0/24
    source:         ARIN

192.0.2.0/24 is a Special Use IPv4 prefix (RFC 3330 / RFC 5735) and not
owned by either of the organisations that created a route object for it
in the ARIN IRR. It is crazy that there even are route objects for this
prefix.

In my opinion, IRR 'route:' objects covering prefixes like 192.0.2.0/24
should either be purged from the ARIN IRR - or should be clearly marked
by changing the "source: ARIN" to "source: ARIN-OLD" (or perhaps "source:
ARIN-NONAUTHORITATIVE-LEGACY-GARBAGE" ;-))

Kind regards,

Job


From farmer at umn.edu  Thu Feb 22 17:42:02 2018
From: farmer at umn.edu (David Farmer)
Date: Thu, 22 Feb 2018 16:42:02 -0600
Subject: [ARIN-consult] Consultation on ARIN IRR Roadmap
In-Reply-To: <20180222211959.GJ43843@vurt.meerval.net>
References: <CAN-Dau3EKZ9Ts124KkJCeh35NS2-6WT23uDinTuDf5tEQ_CbHQ@mail.gmail.com>
 <CAC4yj2UwFcQzebb-=a-K6g5+VmEyCjbV1pCoYKv1wAG49zSUkQ@mail.gmail.com>
 <20180222211618.GI43843@vurt.meerval.net>
 <20180222211959.GJ43843@vurt.meerval.net>
Message-ID: <CAN-Dau3pkYeH+T55inssj8OjjPcfQZOhYwCk=iC6YdxhKmtdAg@mail.gmail.com>

On Thu, Feb 22, 2018 at 3:19 PM, Job Snijders <job at ntt.net> wrote:

> On Thu, Feb 22, 2018 at 04:06:28PM -0500, Jason Schiller wrote:
> > I am confused...
> >
> > the current ARIN IRR is rr.arin.net
>
> ARIN manages an IRR database called "ARIN" in a daemon running on host
> rr.arin.net. You can publish data from multiple databases via a single
> fqdn like 'rr.arin.net'. I think what David Farmer is talking about is
> the "source: ARIN" aspect of the data you show:
>
>     $ whois -h rr.arin.net 199.43.0.0/24 | grep source
>     source:         ARIN # Filtered
>
> RIPE is developing something similar, where non-authoritative data will
> be marked with "source: RIPE-NONAUTH" rather than "source: RIPE" to show
> which objects came into existance because of the chain of trust from the
> RIR data to the IRR data, and some didn't.
>
> With an example from the ARIN IRR:
>
>     job at vurt ~$ whois -h rr.arin.net -- "-B 192.0.2.0/24" | egrep
> "route:|source:"
>     route:          192.0.2.0/24
>     source:         ARIN
>     route:          192.0.2.0/24
>     source:         ARIN
>
> 192.0.2.0/24 is a Special Use IPv4 prefix (RFC 3330 / RFC 5735) and not
> owned by either of the organisations that created a route object for it
> in the ARIN IRR. It is crazy that there even are route objects for this
> prefix.
>
> In my opinion, IRR 'route:' objects covering prefixes like 192.0.2.0/24
> should either be purged from the ARIN IRR - or should be clearly marked
> by changing the "source: ARIN" to "source: ARIN-OLD" (or perhaps "source:
> ARIN-NONAUTHORITATIVE-LEGACY-GARBAGE" ;-))
>
> Kind regards,
>
> Job
>

Yep, that is what I was trying to get at. I didn't know if "-" was a valid
character, since none of the current IRRs have a "-" in their source
field.  Therefore it was just easier to assume "-" wasn't valid.

But if "-" is valid then "ARIN-OLD" is what I really thought of first, but
better yet is "ARIN-LEGACY" (and "ARIN-NONAUTHORITATIVE-LEGACY-GARBAGE" is
fine with me too;-)).

And, then after a year or so all the "ARIN-NONAUTHORITATIVE-LEGACY-GARBAGE"
 magically just disappears.

Thanks.

-- 
===============================================
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/20180222/beb8fdb9/attachment.html>

From job at ntt.net  Fri Feb 23 11:18:09 2018
From: job at ntt.net (Job Snijders)
Date: Fri, 23 Feb 2018 16:18:09 +0000
Subject: [ARIN-consult] Consultation on ARIN IRR Roadmap
In-Reply-To: <CAN-Dau3pkYeH+T55inssj8OjjPcfQZOhYwCk=iC6YdxhKmtdAg@mail.gmail.com>
References: <CAN-Dau3EKZ9Ts124KkJCeh35NS2-6WT23uDinTuDf5tEQ_CbHQ@mail.gmail.com>
 <CAC4yj2UwFcQzebb-=a-K6g5+VmEyCjbV1pCoYKv1wAG49zSUkQ@mail.gmail.com>
 <20180222211618.GI43843@vurt.meerval.net>
 <20180222211959.GJ43843@vurt.meerval.net>
 <CAN-Dau3pkYeH+T55inssj8OjjPcfQZOhYwCk=iC6YdxhKmtdAg@mail.gmail.com>
Message-ID: <20180223161809.GV43843@vurt.meerval.net>

On Thu, Feb 22, 2018 at 04:42:02PM -0600, David Farmer wrote:
> On Thu, Feb 22, 2018 at 3:19 PM, Job Snijders <job at ntt.net> wrote:
> 
> > On Thu, Feb 22, 2018 at 04:06:28PM -0500, Jason Schiller wrote:
> > > I am confused...
> > >
> > > the current ARIN IRR is rr.arin.net
> >
> > ARIN manages an IRR database called "ARIN" in a daemon running on host
> > rr.arin.net. You can publish data from multiple databases via a single
> > fqdn like 'rr.arin.net'. I think what David Farmer is talking about is
> > the "source: ARIN" aspect of the data you show:
> >
> >     $ whois -h rr.arin.net 199.43.0.0/24 | grep source
> >     source:         ARIN # Filtered
> >
> > RIPE is developing something similar, where non-authoritative data will
> > be marked with "source: RIPE-NONAUTH" rather than "source: RIPE" to show
> > which objects came into existance because of the chain of trust from the
> > RIR data to the IRR data, and some didn't.
> >
> > With an example from the ARIN IRR:
> >
> >     job at vurt ~$ whois -h rr.arin.net -- "-B 192.0.2.0/24" | egrep
> > "route:|source:"
> >     route:          192.0.2.0/24
> >     source:         ARIN
> >     route:          192.0.2.0/24
> >     source:         ARIN
> >
> > 192.0.2.0/24 is a Special Use IPv4 prefix (RFC 3330 / RFC 5735) and not
> > owned by either of the organisations that created a route object for it
> > in the ARIN IRR. It is crazy that there even are route objects for this
> > prefix.
> >
> > In my opinion, IRR 'route:' objects covering prefixes like 192.0.2.0/24
> > should either be purged from the ARIN IRR - or should be clearly marked
> > by changing the "source: ARIN" to "source: ARIN-OLD" (or perhaps "source:
> > ARIN-NONAUTHORITATIVE-LEGACY-GARBAGE" ;-))
> 
> Yep, that is what I was trying to get at. I didn't know if "-" was a valid
> character, since none of the current IRRs have a "-" in their source
> field.  Therefore it was just easier to assume "-" wasn't valid.
> 
> But if "-" is valid then "ARIN-OLD" is what I really thought of first, but
> better yet is "ARIN-LEGACY" (and "ARIN-NONAUTHORITATIVE-LEGACY-GARBAGE" is
> fine with me too;-)).
> 
> And, then after a year or so all the "ARIN-NONAUTHORITATIVE-LEGACY-GARBAGE"
>  magically just disappears.

I'd avoid the term "LEGACY" as that may confuse some because we also
have the concept of "Legacy IP space".

Perhaps "ARIN-NONAUTH" to align somewhat with the work being done in
RIPE?

If a subset of the data in ARIN's IRR can be validated, and the set of
objects that are not validated are tagged with "ARIN-NONAUTH" (since
those objects are not authoritative due to lack of validation) - we'll
be in much better shape.

I maintain that no new "ARIN-NONAUTH" objects should be allowed to come
into existence.

Kind regards,

Job


From jcurran at arin.net  Fri Feb 23 13:07:20 2018
From: jcurran at arin.net (John Curran)
Date: Fri, 23 Feb 2018 18:07:20 +0000
Subject: [ARIN-consult] Consultation on ARIN IRR Roadmap
In-Reply-To: <20180223161809.GV43843@vurt.meerval.net>
References: <CAN-Dau3EKZ9Ts124KkJCeh35NS2-6WT23uDinTuDf5tEQ_CbHQ@mail.gmail.com>
 <CAC4yj2UwFcQzebb-=a-K6g5+VmEyCjbV1pCoYKv1wAG49zSUkQ@mail.gmail.com>
 <20180222211618.GI43843@vurt.meerval.net>
 <20180222211959.GJ43843@vurt.meerval.net>
 <CAN-Dau3pkYeH+T55inssj8OjjPcfQZOhYwCk=iC6YdxhKmtdAg@mail.gmail.com>
 <20180223161809.GV43843@vurt.meerval.net>
Message-ID: <1C835BBA-AB70-4E47-9DC5-422130E7CD6B@arin.net>

On 23 Feb 2018, at 11:18 AM, Job Snijders <job at ntt.net<mailto:job at ntt.net>> wrote:

I'd avoid the term "LEGACY" as that may confuse some because we also
have the concept of "Legacy IP space".

Indeed.

Perhaps "ARIN-NONAUTH" to align somewhat with the work being done in
RIPE?

I believe that?s being used with slightly different semantics, but it is certainly a possible tag.

If a subset of the data in ARIN's IRR can be validated, and the set of
objects that are not validated are tagged with "ARIN-NONAUTH" (since
those objects are not authoritative due to lack of validation) - we'll
be in much better shape.

I maintain that no new "ARIN-NONAUTH" objects should be allowed to come
into existence.

Perhaps all prior data should be left "as-is" for period of a year once ARIN?s new IRR is in place,
and be tagged as ?source: ARIN-FROZEN? ?

/John

John Curran
President and CEO
ARIN


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20180223/47d64a05/attachment.html>

From jayb at braeburn.org  Fri Feb 23 13:09:21 2018
From: jayb at braeburn.org (Jay Borkenhagen)
Date: Fri, 23 Feb 2018 13:09:21 -0500
Subject: [ARIN-consult] Consultation on ARIN IRR Roadmap
In-Reply-To: <CAN-Dau3EKZ9Ts124KkJCeh35NS2-6WT23uDinTuDf5tEQ_CbHQ@mail.gmail.com>
References: <CAN-Dau3EKZ9Ts124KkJCeh35NS2-6WT23uDinTuDf5tEQ_CbHQ@mail.gmail.com>
Message-ID: <23184.22737.368242.869776@oz.mt.att.com>

David Farmer writes:
 > On Tuesday at NANOG there was a presentation on ARIN's IRR Roadmap.
 > 
 > https://youtu.be/tsWq_LgNS5s
 > 

Thanks for posting that link, David.


I have a couple questions for John and/or others from ARIN:

At around 16:30 in the youtube video, John made a statement along the
lines that information published in the rpki would "pre-empt
everything".  Those words could be interpreted in some very different
ways, so I'd like John/ARIN to clarify what he meant.

For example, John may have meant that the ARIN Online registry + RPKI
+ IRR system of the future system would enforce a rule whereby the
presence of ROAs placing the origin of a block of IPs in one or more
ASNs would make it impossible to register any route objects that
contradict the ROAs.  If so, I think that would be great.

On the other hand, some might interpret John to mean that by
publishing ROAs a resource holder could magically inform the world
that the IRR route objects for that space are no longer authoritative
causing them to no longer be used.  That's clearly not the case.


Also, at about 19:25, John mentioned that ARIN is enhancing its rpki
tools.  Where can a description of those enhancements be found?


Thank you.

						Jay B.





From jcurran at arin.net  Fri Feb 23 13:27:24 2018
From: jcurran at arin.net (John Curran)
Date: Fri, 23 Feb 2018 18:27:24 +0000
Subject: [ARIN-consult] Consultation on ARIN IRR Roadmap
In-Reply-To: <23184.22737.368242.869776@oz.mt.att.com>
References: <CAN-Dau3EKZ9Ts124KkJCeh35NS2-6WT23uDinTuDf5tEQ_CbHQ@mail.gmail.com>
 <23184.22737.368242.869776@oz.mt.att.com>
Message-ID: <7FBD50BB-96B9-4EA1-AB64-9CD2452177F1@arin.net>

On 23 Feb 2018, at 1:09 PM, Jay Borkenhagen <jayb at braeburn.org> wrote:
> 
> David Farmer writes:
>> On Tuesday at NANOG there was a presentation on ARIN's IRR Roadmap.
>> 
>> https://youtu.be/tsWq_LgNS5s
>> 
> 
> Thanks for posting that link, David.
> 
> I have a couple questions for John and/or others from ARIN:
> 
> At around 16:30 in the youtube video, John made a statement along the
> lines that information published in the rpki would "pre-empt
> everything".  Those words could be interpreted in some very different
> ways, so I'd like John/ARIN to clarify what he meant.
> 
> For example, John may have meant that the ARIN Online registry + RPKI
> + IRR system of the future system would enforce a rule whereby the
> presence of ROAs placing the origin of a block of IPs in one or more
> ASNs would make it impossible to register any route objects that
> contradict the ROAs.  If so, I think that would be great.

That was not the intent of my statement, but that can certainly be done if the community wishes that level of integration. 

> On the other hand, some might interpret John to mean that by
> publishing ROAs a resource holder could magically inform the world
> that the IRR route objects for that space are no longer authoritative
> causing them to no longer be used.  That's clearly not the case.

What I intended by the remark is simply that parties which rely upon RPKI will often more heavily weight local-preference based on the RPKI validation result.  This is not assured but is indeed probable. 

> Also, at about 19:25, John mentioned that ARIN is enhancing its rpki
> tools.  Where can a description of those enhancements be found?

We are continuing to enhance our RPKI tools, but no new functionality is being announced at this time.   If there is specific functionality that you seek, please submit a suggestion so that it can be prioritized.

Thanks!
/John

John Curran
President and CEO
ARIN




From jayb at braeburn.org  Fri Feb 23 15:36:46 2018
From: jayb at braeburn.org (Jay Borkenhagen)
Date: Fri, 23 Feb 2018 15:36:46 -0500
Subject: [ARIN-consult] Consultation on ARIN IRR Roadmap
In-Reply-To: <7FBD50BB-96B9-4EA1-AB64-9CD2452177F1@arin.net>
References: <CAN-Dau3EKZ9Ts124KkJCeh35NS2-6WT23uDinTuDf5tEQ_CbHQ@mail.gmail.com>
 <23184.22737.368242.869776@oz.mt.att.com>
 <7FBD50BB-96B9-4EA1-AB64-9CD2452177F1@arin.net>
Message-ID: <23184.31582.759219.618036@oz.mt.att.com>

John Curran writes:
 > > For example, John may have meant that the ARIN Online registry + RPKI
 > > + IRR system of the future system would enforce a rule whereby the
 > > presence of ROAs placing the origin of a block of IPs in one or more
 > > ASNs would make it impossible to register any route objects that
 > > contradict the ROAs.  If so, I think that would be great.
 > 
 > That was not the intent of my statement, but that can certainly be done if the community wishes that level of integration. 

Thank you.  Please consider the suggestion recorded.  Other folk are
invited to comment.

 > What I intended by the remark is simply that parties which rely upon RPKI will often more heavily weight local-preference based on the RPKI validation result.  This is not assured but is indeed probable. 
 > 

It's about weighting only in a limited and temporary sense.  Breaking
it down:

Once a CIDR block is covered by a valid ROA (a "VRP" per
https://tools.ietf.org/html/rfc6811), that CIDR route and all its
more-specific routes can be either valid or invalid only -- no longer
can they be 'not found'.  Thus it does nothing to change local-pref of
'not found' routes relative to valid and invalid ones.

When a service provider first begins using validation state in their
routing policies, yes, they probably will give valid routes a higher
local-pref than the invalid ones.  But until they begin outright
blocking invalid routes, they will not be addressing the YouTube /
Pakistan Telecom case of more-specific hijacks.  So this phase should
be only temporary.

Networks that use validation state in their policies obviously need
valid ROAs to exist.  Networks that do not use validation state in
their routers directly can potentially still augment their current
IRR-based tools so they utilize RPKI information when generating
prefix list route filters, but I bet most will not do so.  For those
networks that do not, there is no pre-empting of IRR by RPKI.  (Other
than through the integration suggestion above.)


 > We are continuing to enhance our RPKI tools, but no new functionality is being announced at this time.   If there is specific functionality that you seek, please submit a suggestion so that it can be prioritized.
 > 

Thank you, I will.  Please announce ARIN's rpki enhancement plans
prior to beginning development.

						Jay B.




From jschiller at google.com  Fri Feb 23 15:46:46 2018
From: jschiller at google.com (Jason Schiller)
Date: Fri, 23 Feb 2018 15:46:46 -0500
Subject: [ARIN-consult] Consultation on ARIN IRR Roadmap
In-Reply-To: <20180223161809.GV43843@vurt.meerval.net>
References: <CAN-Dau3EKZ9Ts124KkJCeh35NS2-6WT23uDinTuDf5tEQ_CbHQ@mail.gmail.com>
 <CAC4yj2UwFcQzebb-=a-K6g5+VmEyCjbV1pCoYKv1wAG49zSUkQ@mail.gmail.com>
 <20180222211618.GI43843@vurt.meerval.net>
 <20180222211959.GJ43843@vurt.meerval.net>
 <CAN-Dau3pkYeH+T55inssj8OjjPcfQZOhYwCk=iC6YdxhKmtdAg@mail.gmail.com>
 <20180223161809.GV43843@vurt.meerval.net>
Message-ID: <CAC4yj2WQEv251wfdkgxwEvgKV7OawWGvJgKH21Mk3WT+1vVksQ@mail.gmail.com>

Job,

thank you for the clarification on source=ARIN, vs ARIN-OLD.

makes sense now.

I also agree we should stay away from unsing "Legacy"
unless we are trying to specificly note the resource is
"ARIN Legacy space" (meaning it is not currently under
any ARIN RSA, and therefor the provenance is not clear
to ARIN).

I like alignment.. so ARIN-NONAUTH seems like a good choice.



___Jason


On Fri, Feb 23, 2018 at 11:18 AM, Job Snijders <job at ntt.net> wrote:

> On Thu, Feb 22, 2018 at 04:42:02PM -0600, David Farmer wrote:
> > On Thu, Feb 22, 2018 at 3:19 PM, Job Snijders <job at ntt.net> wrote:
> >
> > > On Thu, Feb 22, 2018 at 04:06:28PM -0500, Jason Schiller wrote:
> > > > I am confused...
> > > >
> > > > the current ARIN IRR is rr.arin.net
> > >
> > > ARIN manages an IRR database called "ARIN" in a daemon running on host
> > > rr.arin.net. You can publish data from multiple databases via a single
> > > fqdn like 'rr.arin.net'. I think what David Farmer is talking about is
> > > the "source: ARIN" aspect of the data you show:
> > >
> > >     $ whois -h rr.arin.net 199.43.0.0/24 | grep source
> > >     source:         ARIN # Filtered
> > >
> > > RIPE is developing something similar, where non-authoritative data will
> > > be marked with "source: RIPE-NONAUTH" rather than "source: RIPE" to
> show
> > > which objects came into existance because of the chain of trust from
> the
> > > RIR data to the IRR data, and some didn't.
> > >
> > > With an example from the ARIN IRR:
> > >
> > >     job at vurt ~$ whois -h rr.arin.net -- "-B 192.0.2.0/24" | egrep
> > > "route:|source:"
> > >     route:          192.0.2.0/24
> > >     source:         ARIN
> > >     route:          192.0.2.0/24
> > >     source:         ARIN
> > >
> > > 192.0.2.0/24 is a Special Use IPv4 prefix (RFC 3330 / RFC 5735) and
> not
> > > owned by either of the organisations that created a route object for it
> > > in the ARIN IRR. It is crazy that there even are route objects for this
> > > prefix.
> > >
> > > In my opinion, IRR 'route:' objects covering prefixes like
> 192.0.2.0/24
> > > should either be purged from the ARIN IRR - or should be clearly marked
> > > by changing the "source: ARIN" to "source: ARIN-OLD" (or perhaps
> "source:
> > > ARIN-NONAUTHORITATIVE-LEGACY-GARBAGE" ;-))
> >
> > Yep, that is what I was trying to get at. I didn't know if "-" was a
> valid
> > character, since none of the current IRRs have a "-" in their source
> > field.  Therefore it was just easier to assume "-" wasn't valid.
> >
> > But if "-" is valid then "ARIN-OLD" is what I really thought of first,
> but
> > better yet is "ARIN-LEGACY" (and "ARIN-NONAUTHORITATIVE-LEGACY-GARBAGE"
> is
> > fine with me too;-)).
> >
> > And, then after a year or so all the "ARIN-NONAUTHORITATIVE-LEGACY-
> GARBAGE"
> >  magically just disappears.
>
> I'd avoid the term "LEGACY" as that may confuse some because we also
> have the concept of "Legacy IP space".
>
> Perhaps "ARIN-NONAUTH" to align somewhat with the work being done in
> RIPE?
>
> If a subset of the data in ARIN's IRR can be validated, and the set of
> objects that are not validated are tagged with "ARIN-NONAUTH" (since
> those objects are not authoritative due to lack of validation) - we'll
> be in much better shape.
>
> I maintain that no new "ARIN-NONAUTH" objects should be allowed to come
> into existence.
>
> Kind regards,
>
> Job
>



-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-consult/attachments/20180223/466a82bf/attachment.html>

From info at arin.net  Tue Feb 27 12:06:41 2018
From: info at arin.net (ARIN)
Date: Tue, 27 Feb 2018 12:06:41 -0500
Subject: [ARIN-consult] Extension of ACSP Consultation: ASO Review
 Consultation 2018
Message-ID: <c996913f-5979-c671-313c-6f034fe9aad1@arin.net>

On 1 February 2018, ARIN opened an ACSP Consultation on the results of
the Address Supporting Organization (ASO) Review.

https://www.arin.net/participate/acsp/community_consult/02-01-2018_aso.html

We are extending the review period in order to allow for a presentation
and discussion at ARIN 41 in Miami, FL, 15-18 April.

Please provide comments to arin-consult at arin.net. All ARIN community
feedback will be forwarded on to the NRO. You can subscribe to this
mailing list at: http://lists.arin.net/mailman/listinfo/arin-consult.

This consultation will remain open through 5:00 PM EDT on Monday, 30
April 2018.

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)