On Fri, Nov 9, 2012 at 9:35 AM, Tim Bruijnzeels wrote:
> Good. On that note I think it's worthwhile thinking about different
> complementary ways to deal with this. I.e. make the server side more
> scalable as well as considering flooding protocols and other ways to share
> data between RPs.
can
Hi,
On Nov 9, 2012, at 4:07 AM, Randy Bush wrote:
>>> no need. this is object based security. rama and hanuman have tals and
>>> validate. having every cache in the world hit the CAs is not gonna
>>> scale.
>> Yes, perhaps we need a different architecture and transport protocol.
>
> measurem
>> no need. this is object based security. rama and hanuman have tals and
>> validate. having every cache in the world hit the CAs is not gonna
>> scale.
> Yes, perhaps we need a different architecture and transport protocol.
measurement has shown that rsync is about as good as you're gonna do
Thu, Nov 08, 2012 at 11:25:44AM +, Murphy, Sandra:
> 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
> organizat
On 11/8/12 6:01 AM, Shane Amante wrote:
> Sandy,
>
> On Nov 8, 2012, at 6:25 AM, "Murphy, Sandra"
> wrote:
>> 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
On Nov 8, 2012, at 11:14 AM, Murphy, Sandra wrote:
> Sorry, I thought your complaint that I was misquoting was that I had said
> "all" when you said "most".
>
> So your complaint that I am misquoting is... what did I get wrong?
This:
=
On Nov 8, 2012, at 9:37 AM, Mur
McPherson [da...@tcb.net]
Sent: Thursday, November 08, 2012 11:03 AM
To: Murphy, Sandra
Cc: sidr wg list
Subject: Re: [sidr] additions and changes to agenda on Friday
On Nov 8, 2012, at 10:55 AM, Murphy, Sandra wrote:
> Sorry, you did not say "all" you said "most"
Sandy, c
On Nov 8, 2012, at 10:55 AM, Murphy, Sandra wrote:
> Sorry, you did not say "all" you said "most"
Sandy, could you please not take this out of context? I quoted it below, but
one more time:
I said "_many [most] operators DO carefully evaluate the risks and consult
their legal departments."
Sorry, you did not say "all" you said "most"
--Sandy
From: Danny McPherson [da...@tcb.net]
Sent: Thursday, November 08, 2012 10:54 AM
To: Murphy, Sandra
Cc: sidr wg list
Subject: Re: [sidr] additions and changes to agenda on Friday
On
#x27;t assume operators are naive.
-danny
[1] inline below:
Begin forwarded message:
> From: Danny McPherson
> Subject: Re: [sidr] additions and changes to agenda on Friday
> Date: November 8, 2012 7:40:11 AM EST
> To: sidr wg list , Sandra Murphy
>
>
> On Nov 8, 2012, a
On 07/11/2012 21:09, Randy Bush wrote:
>> In your example, is sita taking on this responsibility on behalf of rama
>> and hanuman?
>
> no need. this is object based security. rama and hanuman have tals and
> validate. having every cache in the world hit the CAs is not gonna
> scale.
On Thursday, November 08, 2012 8:44 AM, Danny McPherson [da...@tcb.net] said:
>> If operators always consult their legal departments on deploying new
>> features,
>>then there is no need to advise them to consult their legal departments.
>
>This is incorrect.
>
>It's "Risks to our business" --
erations.
-shane
P.S. -- I apologize for having veered off of technical topics for an IETF
mailing list. I will refrain from responding to this thread further.
> ____
> From: sidr-boun...@ietf.org [sidr-boun...@ietf.org] on behalf of Shane Amante
>
On Nov 8, 2012, at 8:17 AM, Murphy, Sandra wrote:
> Shane's message said that reliance on outside parties was a risk. I was
> pointing out that operators already are relying on outside parties. Whatever
> means they employ now to evaluate risk or legal impact, they are comfortable
> with out
Re: [sidr] additions and changes to agenda on Friday
On Nov 8, 2012, at 6:25 AM, Murphy, Sandra wrote:
> I doubt whether any of them have felt the need to carefully evaluate the
> risks or consult their legal departments.
And therein lies the disconnect!
I think it'd be extremel
On Nov 8, 2012, at 6:25 AM, Murphy, Sandra wrote:
> I doubt whether any of them have felt the need to carefully evaluate the
> risks or consult their legal departments.
And therein lies the disconnect!
I think it'd be extremely naive to think that operators don't know, or care
about, or ev
_
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 Fri
Thu, Nov 08, 2012 at 03:27:02AM +, John Curran:
> > no need. this is object based security. rama and hanuman have tals and
> > validate.
>
> This would leave Rama and hanuman dependent on the CA services but
> not aware of the CPS term and conditions despite the explicit
> requirement sp
On Wed, Nov 7, 2012 at 10:55 PM, John Curran wrote:
> a lot of fun, but the semantics behind the PKIX certificates are actually
> there for good reason. While I'm sure you can make the bits syntactically
> fit, it is equally important that there is an actual meeting of the minds
> regarding the n
On Nov 7, 2012, at 10:39 PM, Randy Bush wrote:
>> This would leave Rama and hanuman dependent on the CA services but not
>> aware of the CPS term and conditions despite the explicit requirement
>> specified in the PKIX profile?
>
> OMG!!! my router forgot to call her lawyer! call the network p
Michael,
On Nov 7, 2012, at 7:48 PM, Michael Sinatra 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 re
> This would leave Rama and hanuman dependent on the CA services but not
> aware of the CPS term and conditions despite the explicit requirement
> specified in the PKIX profile?
OMG!!! my router forgot to call her lawyer! call the network police?
john, you have been out of ops for way too l
On Nov 7, 2012, at 9:09 PM, Randy Bush
wrote:
>> In your example, is sita taking on this responsibility on behalf of rama
>> and hanuman?
>
> no need. this is object based security. rama and hanuman have tals and
> validate.
This would leave Rama and hanuman dependent on the CA services b
> In your example, is sita taking on this responsibility on behalf of rama
> and hanuman?
no need. this is object based security. rama and hanuman have tals and
validate. having every cache in the world hit the CAs is not gonna
scale.
you may want to look at my ripe and nanog presos on the sc
On Nov 7, 2012, at 8:33 PM, Randy Bush
wrote:
>>> sita has cache and has agreed to arin's silliness. rama, trying not to
>>> put load on CA publishers, rsyncs sita's cache and wants to validate it.
>>> hanuman rsyncs rama's cache, ...
>>
>> In the above circumstance, how do rama and hanuman fi
>> sita has cache and has agreed to arin's silliness. rama, trying not to
>> put load on CA publishers, rsyncs sita's cache and wants to validate it.
>> hanuman rsyncs rama's cache, ...
>
> In the above circumstance, how do rama and hanuman find and consider
> the terms and conditions of the CA'
On Nov 7, 2012, at 6:17 PM, Randy Bush wrote:
>> which types of parties are expected to be subject to the relying party
>> agreement would also need to share the obtained information with
>> others? (others who would potentially be unaware of the RPA as well as
>> the CP and CPS, in all likelihoo
On Nov 7, 2012, at 7:48 PM, Michael Sinatra wrote:
>
> 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 t
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-
> which types of parties are expected to be subject to the relying party
> agreement would also need to share the obtained information with
> others? (others who would potentially be unaware of the RPA as well as
> the CP and CPS, in all likelihood...?)
sita has cache and has agreed to arin's sill
On Nov 7, 2012, at 2:28 PM, "Murphy, Sandra" wrote:
> My concerns derive from the section PROHIBITED CONDUCT.
>
> That section says it forbids the relying party (the one retrieving RPKI data
> from ARIN and validating wrt the ARIN trust anchor) from transferring, giving
> access to, copying, br
On Nov 7, 2012, at 2:28 PM, Murphy, Sandra wrote:
>
> I think that could impact the envisioned architecture and dominant use cases,
Agreed!
> A couple of people have suggested mechanisms that might suit ARIN and
> minimize the impact and might be worth exploring.
Can you (or those folks) shar
_
From: sidr-boun...@ietf.org [sidr-boun...@ietf.org] on behalf of Danny
McPherson [da...@tcb.net]
Sent: Wednesday, November 07, 2012 1:29 PM
To: Murphy, Sandra
Cc: sidr@ietf.org
Subject: Re: [sidr] additions and changes to agenda on Friday
On Nov 6, 2012, at 12:35 PM
On Nov 6, 2012, at 12:35 PM, Murphy, Sandra wrote:
>
> I would like to open a discussion with the wg concerning the recently
> announced ARIN relying party agreement. I have concerns about this
> agreement's impact on the envisioned RPKI architecture and dominant use. I
> think the wg needs
We have three new topics to add to the agenda on Friday.
Carlos Martinez would like to present a new version of
draft-rogaglia-sidr-multiple-publication-points.
Sue Hares, idr co-chair, would like to request a review of work she is doing in
a limited re-write of the base BGP spec, to fix errata
35 matches
Mail list logo
