I think you are twisting the facts on your own convenience.
No, I am merely pointing out that adding a hosted service to an already
complex system increases it's complexity. I don't see how that's
twisting facts. Would you care to explain which fact I've twisted, and
how?
RPKI != RPKI-hosted
I just want to point out that I was on a different train. Discussing the
supposition that querycahce arch's behave differently that batch pull
archs in either startup or steady state performance. I was not commenting
on the whole trust/business model discussion.
I was replying to Eric's
Hello R.
On 12/07/2012 10:25 AM, Russ White wrote:
I think you are twisting the facts on your own convenience.
So you're saying that the hosted RPKI system is not reliant on routing?
That it can be reached no matter whether or not routing is available?
If by 'hosted RPKI' you are
Hey Chris et al,
On 12/07/2012 03:34 AM, Christopher Morrow wrote:
... snip ...
I think somewhere 5-8 messages back Arturo's note that:
1) hosted model is just a crutch
2) hosted model isn't intended for everyone to use
3) most large ISP or large operations groups are expected to run
IMHO they address the architectural issue, by pointing out that while the
there are architecturally different in the abstract, for the purpose they
are being designed/discussed, this architectural difference makes very
little difference in performance.
Seriously Doug, this totally misses the
On Dec 7, 2012, at 12:34 AM, Christopher Morrow wrote:
On Thu, Dec 6, 2012 at 11:20 PM, Montgomery, Douglas do...@nist.gov wrote:
I was talking about when the systems designed to support the distribution
of authorization information (e.g., RP/RPKI or some DNS based system?)
were in steady
Hey all,
On Dec 7, 2012, at 2:31 PM, Carlos M. martinez carlosm3...@gmail.com wrote:
Hey Chris et al,
On 12/07/2012 03:34 AM, Christopher Morrow wrote:
... snip ...
I think somewhere 5-8 messages back Arturo's note that:
1) hosted model is just a crutch
2) hosted model isn't intended
On Dec 7, 2012, at 7:56 AM, Montgomery, Douglas wrote:
I just want to point out that I was on a different train. Discussing the
supposition that querycahce arch's behave differently that batch pull
archs in either startup or steady state performance. I was not commenting
on the whole
On 12/6/12 5:57 PM, Eric Osterweil eosterw...@verisign.com wrote:
Nope, it doesn't. It actually points out that hosting's myopic benefits
are fools-gold, and they come with a
much more dangerous price tag. Your choice of dreamhost is a _choice_,
not a mandate from a set of 5
options.
Hi,
Sorry for procrastinating on this for so long.
Here are questions I would like to ask WG participants. At this point I
would like to ask people to review the questions and let me know if you
think they are contradictory. If they are clear, I will poll the WG
early next week. Comments on
Just because the RIRs are the only organization offering hosting services,
doesn't mean that they are the only ones that can offer hosting services.
Certainly an enterprising Internet company with DDOS mitigation services
could offer RPKI CA hosting or simply hosting of RPKI repositories for
On Dec 7, 2012, at 12:01 PM, Eric Osterweil wrote:
Yeah, while I'm not proposing that, my whole point was triggered off the
assertion that there will be 5 repos, and that the hosted model fits the
eventual needs. That thinking ignored too much grey area for me.
Sorry, meant to say fits
Top-reply for convenience:
(This is strictly my opinion/observation and does not represent the
viewpoint of any organization per se)
1. Yes, there is a problem alluded to that might need to be solved.
2. C - no, this draft is not the place to solve the problem.
The root of the problem, is
On 12/7/12 10:28 AM, Eric Osterweil eosterw...@verisign.com wrote:
IMHO they address the architectural issue, by pointing out that while
the
there are architecturally different in the abstract, for the purpose
they
are being designed/discussed, this architectural difference makes very
From comments made at the mike in the last IETG sidr session after the
discussion of key rollover techniques, I think there might be a bit of
confusion about beaconing.
An Expire Time was a feature of the bgpsec protocol in versions 00-01. The
purpose of the Expire Time was to prevent replay
On Fri, Dec 7, 2012 at 12:35 PM, Montgomery, Douglas do...@nist.gov wrote:
suggesting/discussing loading a RIB from DNS queries. I was thought we
were discussing information systems that might allow me to validate the
origin of an router's RIB. That problem is O(500K) at time zero.
On Fri, Dec 7, 2012 at 1:24 PM, Russ White ru...@riw.us wrote:
You are twisting the fact when you are mixing hosted-rpiki and
rpki-repositories as the same thing.
(*note quoting russ's message, but not actually aiming at russ in particular)
could we focus a bit of the conversation on
clarifying question in your example...
On Fri, Dec 7, 2012 at 12:32 PM, Brian Dickson
brian.peter.dick...@gmail.com wrote:
P.S. Here is a worked example to illustrate this concept:
Suppose the initial state of affairs is as follows:
10.0.0.0/8 is delegated by IANA to RIR A. RIR A does not
On Dec 7, 2012, at 2:38 PM, Murphy, Sandra wrote:
From comments made at the mike in the last IETG sidr session after the
discussion of key rollover techniques, I think there might be a bit of
confusion about beaconing.
An Expire Time was a feature of the bgpsec protocol in versions
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Inter-Domain Routing Working Group of
the IETF.
Title : BGP Prefix Origin Validation State Extended Community
Author(s) : Pradosh Mohapatra
20 matches
Mail list logo
