admin work done joel - sidrops overview two chairs - keyur patel/morowc remaining docs headed to sidrops from sidr. already in wg, so just migrating over from the existing wg. documents should get worked in sidrops more work will come when that's done Call to join list: sidrops@ietf.org charter display - important point to joel -> ops means not just ISP folks also CA and RiR/NIR/LIR folks, and relying party software folks. Finally the research/measurement folks as well. Questions? Charter questions from Dan about 'what about isp folks?' - joel -> we definitely included them perhaps implicitly? tim ripe ncc - charter 'work'/items - What if we need to add new work? Joel - Current WG will get closed out 'soon'. New items will get pulled into the wg as approrpiate No real impediment to moving docs into sidrops. Sandy - Movement of docs into the new queue, do those need to get renamed? Joel - nope. Fairly sure not.. but will verify. Declan ma - Slurm update Motivation discussion(s) - Selective overrides and protections from adverse actions. The overview of the update - reorganize the layout, rewrite usecases update security concernts. Reorg - updated slurm mechanisms and rpki/rp slurm integration. usecase revisions include proviate INR and referring to the adverse-actions draft as well. A display of the RP stack and SLURM's placement in that stack. Security considerations cover also - assertions about non-private INRs errors in the slurm file && authenticity/integrity of the slurm file. There were some considerations to take in to account with other RP software authors. Providers of software are free to define their own config file, and not required to use ABNF for that format, the ABNF is solely to describe the content, not the format of the result. Keeping ABNF in the document provides well known defintions, examples in the appendix for json/xml can provide worked examples. RPSTIR has supporting SLURM in the near future, fyi. Thanx to the previous authors, and existing RP authors for consultations. Questions - Tim @ ripencc - move this to sidrops, more work will likely be required so lets do that there. tim @ ripencc - comments about previous versions of this effort, and about how to handle 'ignore filters' (what SLURM provides). Push for a single file format for slurm. The ABNF format is well defined, but library support is 'rough'. Of the other options xml is available, json as well the best options . (fixed: YAML) Lastly, future work here should move toward an API, not just a file. Suggest as well that in sidrops we should include other RP authors as well Rudiger - Agree that one format is better, Preferring ABNF instead of others seems XML can include the schema and grammar (abnf) are 'equivalent', though not exactly the same. There is software to support some of these formats as well. RelaxNG grammar looks a lot like ABNF, and exposes syntax/structure for semantics as well. Tim - Tree Validation slides This document is listed for SIDROPS, The goals and process of the document are the goal here today. This is a document to cover (informational document) how the RIPE implementation operates. Why to take this to the WG? because this is transparency and review request from the WG folks about how the software operates. These concerns were included in the document, without changing the text of what the document actually does. The document discusses TODAY's software, tomorrow's may change, How does that work? Should we do that long term? Option proposed here is to: move the doc to WGLC Future updates should be included with release of the software After enough, take those back to sidrops and -bis/etc. Alternately - just publish with software, no document in the WG... less transparency, less review, perhaps less good for the community? Questions? Rudiger - DT - works to publish document, and perhaps later user-forum to get feedback/etc as well. Not every revision necessarily needs to go through the RFC process. John - jnpr - There's a comment about how unique the request is, however it seems that review is good here. Sandy - review seems good, we could also move things over to the wiki instead? Randy - Perhaps there are lots of people making overviews of existing protocols... so this seems normal, yes? Tim ripe - Comments about how the particular draft covers the validation process only, not the software overall work... and wiki work may be less controlled and thus a bit more hard to manage, prefer to not do this route. joel - ad - A question to the ML should wait until more folks show up there. If you want to manage just as a draft that's also .. fine, though no consensus happens, which may not be the goal. Asking for consensus may not have the same view as today's WG... that may not fit your needs/requirements. Oliver - MIST - BIRD/Quagga interop and BGPSEC-IO! BGPSEC-IO makes large scale traffic easily to use in test labs. scripting can be done as well as output being usefully formatted. 'Ixia for bgpsec' Neat work for crypto testing as well... you can provide just bgpsec path attributes which can then get crypto testing done. A set of testing platform and output on a laptop/etc which shows the test harness and shows quagga/etc output. (lots of images, less words to work around) showing a progression of testing bgp paths and bgpsec, then the impacts to paths and routes as bgpsec takes effect. (origin validation failures show up as path selections despite the shorter path(s)) New scenario, with a craftier AS100 ... moar evile! Paths show that still the proper path keeps the win, path and origin validation. COOL! Randy/Tim - Testing stuff discussion - No pink square for Randy - Blaming the chairs for the requested talk, despite..... anyway! Tests which may be possible: CA interop Caches make the same results? Do caches fetch from eachother properly? Are routers making the same validation results? Do routers validate at all? For CA testing: Do the CA's interoperate - (randy) see complex pict in slide (5) (point being that global ISPs may have resources from more than 1 CA, does the validation/etc set actually work??) For Validators/Caches - (tim) Do these make consistent results? With multiple redundant fetching processes? A possible architecture is that a frontend cache polls the world, that cache is used to feed the network distributed caches... does this work properly? Randy points that RPKI-RTR has pulled crypto out, so routers are much more dependent upon the infra being corect here... relying upon external parties can lend to bad answers as people play games. Router testing - (randy) Semantics with continual regression testing... make sure that old bugs do not zombie on us. Same here. A large 7513 image with ins/outs/digestion and perhaps gas. Assuming that the RPKI implementaiton is tested and the cache is and the rpki-rtr protocol/etc... only thing changing here should be the RTR, not the other outlying parts. How to test these constantly and reliably. Question - sandy - how to bring up a new ISP without previous knowledge. Randy - Should 'just work' since 'unknown' means 'i have no rpki-rtr data' Oliver - testing routers could be done with 'bright' - which permits connecitng a router to test systems, which sends roas, traffic and monitors results to see if the ins/outs are what are expected. (sounds like using routers instead of bird as in his example/presos) Tim - having a solid framework to test would provide benefits. NOT UNH person - Could you perhaps approach UNH for this work? Carlos - sees benefit, but seems that a more detailed list of requirements could make the decision process here simpler. Finding outsourcing opportunities is simpler when there's clear requirements. Test CA instances exist at some places (DT/Lacnic/etc) can there be commitment to provide test infrastructure from the current versions/etc and use that for future deployments and upgrades/changes. Rudiger - Perhaps having the test instances deployed and available would make this possible too? Mark@arin - there is an OE&T environment, which has full sets of tooling and such, those should be possible to be used as well. Oliver - Are there caches available? with 6810-bis ports? (rrdp) randy - yes Tim - there's a test environment, it's mostly up... but some requirements about 'how to play' are still to be worked out. Suggested to talk later about this. Tom - apnic - there's a testbed available, it's public, let's do this! Dan Shaw -afrnic - there's no public testbed, but we can make available to the public folks ondemand. Taiji - jpnic - There's a testbed testing 3 things, one of which is counts of public roa, YuFu - cnnic - there's a test bed here as well.