On 2013-04-01 20:31, John Curran wrote:
Indeed, there will be some that see RPKI as a possible new approach
for such matters. The registry needs to be consistent (i.e. across
registration data, Whois publication, and RPKI publication) and we'll
certainly seek to prevent RPKI-specific actions
On Apr 2, 2013, at 9:53 AM, Danny McPherson da...@tcb.net wrote:
Speaking of inconsistencies in the RPKI, what's ARIN and the NRO's status on
getting to a single trust anchor?
I believe that ICANN and the RIR technical staffs are busy trying to
document a proposed structure and operation to
John,
See below.
On Apr 2, 2013, at 8:26 AM, John Curran jcur...@arin.net wrote:
On Apr 2, 2013, at 9:53 AM, Danny McPherson da...@tcb.net wrote:
[--snip--]
Yeah, they were nonsensical in the past and present role of ARIN, not in an
RPKI-enabled world where revocation or transfer or
On Apr 2, 2013, at 10:53 AM, Shane Amante sh...@castlepoint.net
wrote:
You keep repeating that assertion, but note that even in today's world
we could be ordered to reclaim and reassign a block with similar effect.
It may not be real time but there are plenty of folks who follow both
the
On 2013-04-02 09:30, John Curran wrote:
Indeed. Of course, that same outcome can effectively be had today
(for any
given IP address block) via one handful of court orders directed to
the larger
ISP backbones.
Assuming those backbones operate within jurisdictional or MLAT reach,
as
On 2013-04-02 08:26, John Curran wrote:
On Apr 2, 2013, at 9:53 AM, Danny McPherson da...@tcb.net wrote:
Speaking of inconsistencies in the RPKI, what's ARIN and the NRO's
status on getting to a single trust anchor?
I believe that ICANN and the RIR technical staffs are busy trying to
On Apr 2, 2013, at 9:58 AM, Danny McPherson da...@tcb.net wrote:
On 2013-04-02 09:30, John Curran wrote:
Indeed. Of course, that same outcome can effectively be had today (for any
given IP address block) via one handful of court orders directed to the
larger
ISP backbones.
Assuming
On Apr 2, 2013, at 12:27 PM, Shane Amante sh...@castlepoint.net wrote:
IMO, there is still one key difference. ISP's are _directly_ involved in
receiving such orders, evaluating them for validity, applicability and then
carrying them out. This can also include providing a heads-up to
Danny,
The architecture permits overlapping allocations to accommodate
transfers that involve address space that
is in use. I've been told by several operators that, for this sort of
transfer, such overlap
is required.
Steve
On 4/2/13 12:02 PM, Danny McPherson wrote:
...
As for today, the
Shane,
As one operator whose worldwide routing/operations could be negatively
impacted by the above, it would be nice to have a concise statement
about what is/was the original intent of the design of the RPKI with
respect to the above. In addition, it would be useful to see if any
potential
On Tue, Apr 2, 2013 at 1:59 PM, Stephen Kent k...@bbn.com wrote:
Danny,
The architecture permits overlapping allocations to accommodate transfers
that involve address space that
is in use. I've been told by several operators that, for this sort of
transfer, such overlap
is required.
Shane,
IMO, there is still one key difference. ISP's are _directly_ involved in receiving such orders,
evaluating them for validity, applicability and then carrying them out. This can also include
providing a heads-up to operations teams, in that SP, that a change in configuration to effect
Sharon,
...
Nonetheless, all of the methods for whacking a ROA described in the
paper
are detectable by anyone who monitors the RPKI. One might argue that
each
resource holder should monitor his/her RPKI pub point to detect any
action
that causes one's ROA to become unverifiable.
We
Chris,
Yes, the example you provided matches what I had in mind.
Steve
-
On Tue, Apr 2, 2013 at 1:59 PM, Stephen Kent k...@bbn.com
mailto:k...@bbn.com wrote:
Danny,
The architecture permits overlapping allocations to accommodate
transfers that involve address space that
is
John,
On Apr 2, 2013, at 11:22 AM, John Curran jcur...@arin.net wrote:
On Apr 2, 2013, at 12:27 PM, Shane Amante sh...@castlepoint.net wrote:
IMO, there is still one key difference. ISP's are _directly_ involved in
receiving such orders, evaluating them for validity, applicability and then
Danny,
No, I didn't realize you were referring to the current multi-TA environment.
I thought that John Curran was alluding to plans to create an ICANN-managed
global TA, which is why I didn't realize the context you had in mind.
Steve
--
On 4/2/13 3:20 PM, Danny McPherson wrote:
On
On Apr 2, 2013, at 2:59 PM, Shane Amante sh...@castlepoint.net wrote:
So, in the future of the RPKI, as a resource holder, how am I able to shop
around as per the above, to mitigate one or more of the concerns that I've
illustrated above? Hint: given the, at present, limited number of RIR's
17 matches
Mail list logo