On Tue, Apr 10, 2012 at 9:15 PM, Danny McPherson <[email protected]> wrote: > > On Apr 10, 2012, at 8:56 PM, Christopher Morrow wrote: > >> yes, my goal was to have updated the wiki today at the office, work >> intruded... tomorrow I'll do that with some more content for each >> item, and hopefully better coordinates as well for the location. > > Thanks.
I think the 2 above items are done... please have a look when you get some time, comments/questions welcome. >>> Also, are we collecting requirements for these (e.g., object scale, RPs, >>> etc..)? Basing these discussions on requirements that exist somewhere >>> already? Or simply discussing solutions that have already been developed >>> and deployment experience? If the latter, then we can we ensure we >>> reference and prepare to discuss what requirements drive to the development >>> of those solutions? >>> >> >> I think the only bit in the 3 that has a current 'requirements' >> discussion is the 'freshness' (item 2). The first item 'deployment >> discussion' is really a discussion of: >> "Should there be some document that describes the top N (3?) >> deployment scenarios && where should that document/presentation/etc >> live?" (I suppose implicit in that is 'requirements for format, >> content, intended audience') > > I was thinking more simply along the lines of "a fully deployed RPKI today > would have o objects and r RPs a c churn and we ought to ensure our designs > accommodate that" -- only then can we have a reasonable discussion on, e.g., > data freshness? What have we based these design goals on thus far - do we > have a stable reference for this? > hopefully this is captured in the wiki update. > From there, we can discuss the issue of, for example, HOW TO onboard and > purge signing and validating certificates to routers from the RPKI -- [I > suspect the intention was to use rpki-rtr protocol for this, but it doesn't > currently support it, nor are the security implications clear]. > The rtr cert/ee-cert part was never planned/designed to be done via rpki-rtr. Ideally at provisioning time your ee-cert is dropped onto the box, similar to base-config today. Potentially your fav vendor has a methodology in their plan for this. I can't imagine it's too tough, nor that it's exact specification needs to be in an IETF doc (since it seems implementation specific). Could be wrong though. > Only when we get to that point will we really begin to understand the > dynamics of RPKI and it's employment for secure routing (well beyond > "authorized" origin policy configuration), and the impact of rate+state in > both the RPKI and it's effectuating in the routing system, and perhaps most > importantly, the inter-dependencies between the two (even basic stuff like > the rate of updates from an RPKI cache to a router in a fully loaded system > given today's RPKI object counts). > sure, some modelling seems like a good thing here, I think this was asked for at the mic in PAR as well, no? (in response to some discussions with Sriram?) >>> Also, it looks to me like we're in dire need of a charter update... >> >> for which? (I didn't think that any of the 3 items was actually >> outside of the current charter) > > I meant the goals and milestones, apologies for not being clear. we can chat about that on-list or in the meeting... I suppose there's a slew of milestones which are 'complete', there aren't really any changes (that I planned) from an 'adding things' perspective. The ops-documentation (see wiki) to me is probably NOT an ietf document, again happy to talk at the meeting about that though. -chris _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
