On Thu, Apr 12, 2012 at 7:59 PM, Arturo Servin <[email protected]> wrote:
>
> There has been a lot of discussion about different topics related, I wasn't
> sure what we were going to discuss.

hoping to actually get a running list started of 'topics that need
time for discussion', perhaps on the wiki even :)

> Thanks for clearing this out.

trying my best :)

> Regards,
> as
>
> On 12 Apr 2012, at 11:38, Tim Bruijnzeels wrote:
>
> Hi,
>
> On 12 Apr 2012, at 04:16, Christopher Morrow wrote:
>
> On Wed, Apr 11, 2012 at 5:25 PM, Arturo Servin <[email protected]> wrote:
>
> Chris,
>
>
>        For the agenda item: "Deployment Discussion -> Discuss the need, and
> publication location/method, for documentation that details rollout of SIDR
> technologies in an operational network." Are we going to discuss what Tim
> suggested in his e-mail on March 30th (subject:  rpki repository and
> validation issues). I think he pointed out three valid points to discuss (at
> least start with the first 2 as he suggested):
>
>
>
> Actually no, Tim wanted to be able to present/be-in-person so the next
> time he can do that is the coincident meeting with IETF in Vancouver,
> BC.
>
>
> Indeed, I can't make the 30 April interim meeting (not even remote). And
> it's also too short notice to bring more real measurements and experience (&
> measurements) from piloting possible alternatives to the table.
>
>
> I agree with Randy (if I understand his point correctly) that measurements
> are needed to substantiate any discussion about the problems and possible
> alternatives. So... we actually plan to work on this over the following
> weeks (after the RIPE meeting):
>
> - Add an automated feedback feature to our validator so that we can get
> statistics from wherever people run it (if they enable the feature). We're
> thinking of measuring:
>    = average time to validate enabled TAs
>    = frequency of rsync repositories being unavailable
>    = frequency of validation corner cases occurring because we get a repo
> *while it is being updated* (eg mft out-of-sync with some object)
>    = I am open to suggestions of other stuff to measure..
>
> - Do a quick pilot implementation of some ideas:
>    = Use an rss like notification mechanism to alert RPs of updates
>    = Use http to fetch *consistent* deltas
>    = And then do the same measurements as above and possibly more we can
> think of (like some controlled load stressing)
>
> Of course there are lots of details involved here that are interesting to
> discuss with other RP implementers, RPKI publishers and the sidr wg at
> large, but... we feel that at this stage we want to mature and try out our
> ideas first so that when we bring this to the table we'll have a reasonable
> idea of whether it actually works in real code and helps to solve the real
> issues that we see. In short: we want to invest some energy in trying it out
> first, and then discuss more, rather than the other way around..
>
> Planning can always change, but it looks like we should be able to do this
> without spending too many of our resources and in time to report about it in
> Vancouver.
>
> For the time being we will use the list of problems and requirements that I
> formulated as a guideline for this pilot, but I am well aware that that list
> is subject to change when it's discussed in more detail in sidr on-list or
> at a meeting..
>
>
> Tim
>
>
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to