# PANRG Interim Minutes - June 2022 Corine de Kater Mulhauser gave an [overview](https://datatracker.ietf.org/meeting/interim-2022-panrg-01/materials/slides-interim-2022-panrg-01-sessa-scion-overview-presentation-panrg-interim-meeting-010622-00) of the SCION architecture. Brian Trammell ([as chair](https://datatracker.ietf.org/meeting/interim-2022-panrg-01/materials/slides-interim-2022-panrg-01-sessa-chair-slides-00)) presided over a Q&A session and a discussion of next steps, including but not limited to: - (eventual) adoption of (parts of) SCION as RG drafts? - larger scale experiments with SCION within the auspices of the RG? - the RG as a conduit for (parts) of SCION into appropriate IETF WGs? ## Comments and Questions on Next Steps Suresh Krishnan asked how applications use SCION. Adrian Perrig noted that most users today use IP-to-SCION gateways, but pointed to ongoing work on client libraries, as well as userspace/applevel support using UDP encapsulation. He noted connections to Happy Eyeballs and work in the IETF [TAPS](https://datatracker.ietf.org/wg/taps) working group. Mirja Kühlewind asked what needs to be standardized here: what's missing in the documents is how we can split the parts of the system, and how we could use or extend existing protocols for some of those parts independently. For example, could IPv6 [Segment Routing](https://datatracker.ietf.org/wg/spring) be adapted to provide a data plane for SCION? Adrian Perrig noted that there are gaps in each existing protocol the SCION folks have looked at: SR doesn't provide the right security mechanisms, and there are path header / length scaling issues to work out, for example. Nicola Rustignoli asked whether a planned document presenting a gap analysis to current Internet protocols would be useful. Tommy Pauly noted that that's close: he'd like to see an Internet-Draft enumerating protocol bits thar *aren't* there. Presenting SCION as a system is hard; the IETF process doesn't do systems well. Spencer Dawkins presented the basic question as "what's research, and what's engineering?". HIP, for example, had an IRTF RG to work out the hard bits, and a WG to standardize things that were well-understood. A useful SCION approach to standardization would start by looking at which (existing) protocols can be reused, which protocols can be extended, and which protocols have to be invented. Explaining why SCION doesn't reuse existing protocols helps work on those other protocols, too. A good answer to these questions will be necessary for work on SCION to advance in the IETF. Additionally, splitting protocols avoids fate sharing: if all of SCION is one effort, each protocol in that effort lives or dies together. Spencer also recommended looking at [RFC 7418](https://www.rfc-editor.org/rfc/rfc7418.html) to understand the difference between things that make sense in an RG and things that can go to (one or more) WG(s). Brian Trammell (as an individual) suggested an analysis: what happens if you break up SCION and only implement and deploy one pillar. PKI only? Routing only? Dataplane only? Does each part of the system have independent utility? On a first analysis, dataplane-only seems to be the least independently useful of, so maybe not the first to focus on. Tommy said he's more interested in figuring out how to evolve the current stack, instead of completely replacing it. Though it's not clear that's possible, what do you (the SCION team) thinks makes SCION different from past attempts to do what it's doing. There are fundamental properties that will make something like this work -- can we find those properties in an existing Internet protocol? Or maybe we know we can't. But we should ask the question. Please come from this angle – what are the properties that make us successful and where could we add things to existing protocols. Just a gap analysis to the current Internet would be less helpful. Brian (as chair) followed up to note that SCION is unique among future Internet projects in that it has actually deployed stuff for real users. So deployment experience – positive or negative – would be super interesting and useful for PANRG. Especially negative experiences, that are less likely to be published in other academic venues. Colin Perkins addressed the question of SCION as a system: how can approach bringing the whole thing in? Should we bring the whole thing in? Clearly there are good ideas and deployment experience. But it is a system, and a large one, and the IETF is terrible at systems. We should be thinking about which bits make sense in the IRTF, but also about which bits we can say are not research, and which bits are, and figure out how to refer those that are not to the IETF. Suresh noted that we're mostly looking at reference implementations from ETH, which probably haven't addressed problems like interoperability across versions. How someone buids an interoperable implementation should be in a draft. How versioning works should be in a draft. Spencer noted at this point that all the feedback in the meeting was how to move forward, not whether to move forward. Brian, as chair, stated it was a bit early to take a hum along those lines, as it looked like consensus was emerging that the increasingly-inaccurately-named "gap analysis" document would provide more information. Instead, Brian asked whether a "component" or "decomposition" analysis of SCION, splitting it into its parts and evaluating existing protocols, or potential extensions thereof, for each of those component functions ## Outcomes As summarized by Colin, the sense of the RG is that we're interested in talking about SCION here. The general view (which Colin noted he agrees with) is that the IETF is bad at systems. So the next logical step is to figure out how to split SCION into components, that's good input to both the RG and a future standardization process. The proponents should be prepared to have a discussion in Philadelphia (IETF 114 in July) focused on this component analysis. This doesn't necessarily need to be a document, it can be a presentation, but if there's a document in progress feel free to submit a -00 with gaps in it. Brian (as chair) noted that the RG was prepared to schedule significant time at IETF 114 for this discussion, and additional interim meetings to iterate on this component analysis and next steps after IETF 114.