Speaking as regular ol' member

On Wednesday, November 07, 2012 10:48 PM, Shane Amante [sh...@castlepoint.net] 
said:

>Commercial operators, in particular, should carefully evaluate the risks posed 
>to
> their core business (selling Internet transit) by now being reliant on 
> certificate 
>information that directly affects _reachability_information_ carried within 
>their 
>network.  That certificate information is maintained by an outside party 
>that's 
>outside the operator organization's _direct_ (immediate) control and for
> which they, seemingly, have no recourse if (when?) something goes wrong.

I think the Internet is already there.

There are ISPs that spend considerable energy creating prefix filters from IRR 
data and strongly encourage their customers to register in IRRs.  Those 
registers are maintained by an outside party that's outside the operator 
organization's direct control.  Those registered objects directly affect 
reachability information carried within their network.

Commercial operators have been comfortable with this mode of operation for many 
years.  I doubt whether any of them have felt the need to carefully evaluate 
the risks or consult their legal departments.  It has been best current 
practice and urged on operators at *OG meetings.

I don't think we want people asking ISPs that use IRRs why they run such a 
risky operation.

--Sandy, speaking as regular ol' member


________________________________________
From: sidr-boun...@ietf.org [sidr-boun...@ietf.org] on behalf of Shane Amante 
[sh...@castlepoint.net]
Sent: Wednesday, November 07, 2012 10:48 PM
To: Michael Sinatra
Cc: sidr@ietf.org; Murphy, Sandra
Subject: Re: [sidr] additions and changes to agenda on Friday

Michael,

On Nov 7, 2012, at 7:48 PM, Michael Sinatra <mich...@burnttofu.net> wrote:
> On 11/07/2012 10:29, Danny McPherson wrote:
>
>> Sandy, Can you elaborate what your "concerns about this agreement's
>> impact on the envisioned RPKI architecture and dominant use" are?  Do
>> you have a reference or outline we can review prior to the discussion
>> in order to keep this from being a
>> bash-the-RIR-and-force-them-into-submission-for-trying-to-deploy-this-stuff
>> fest?
>
> In addition to Sandy's concerns, the agreement contains a third-party 
> indemnification clause (as do other ARIN RPKI-related agreements) that makes 
> it difficult for many state and federal government (and large EDUs) to simply 
> click through and sign.  In most of these environments, the network engineers 
> who would be wanting to try out RPKI would not be permitted to agree to such 
> indemnification.  This may also be true at large corporations.
>
> This, I think, has very little architectural impact, but it does mean 
> additional hoops for operators (like myself) to experiment with RPKI and/or 
> put it in production.  As such, further discussion is probably out of scope 
> for SIDR, and I will take this to arin-discuss@ accordingly.  But I did want 
> to give this group an FYI that this may be at least a speed-bump on the 
> deployment front.


I (also) commend ARIN for their due diligence on this matter.  Commercial 
operators, in particular, should carefully evaluate the risks posed to their 
core business (selling Internet transit) by now being reliant on certificate 
information that directly affects _reachability_information_ carried within 
their network.  That certificate information is maintained by an outside party 
that's outside the operator organization's _direct_ (immediate) control and for 
which they, seemingly, have no recourse if (when?) something goes wrong.  That 
risk without remedies/recourse is not something commercial entities are prone 
to voluntarily accept.

Obviously, each operator should seek advice from their own legal counsel as to 
the risks and make their own decisions.

-shane
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to