Internet Engineering Task Force Interim Meetings, 8 Sep 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF-PANRG-20220908-1500

Description

PANRG meeting session at IETF
2022/09/08 1500

https://datatracker.ietf.org/meeting//proceedings/

A

Good morning and afternoon everyone can, um can you all hear me.

B

Yes can hear you.

A

A

So I'm seeing we have nine people in I'm, going to wait a couple of minutes for people to pop in.

A

A

Pop hedge doc, out.

A

Sorry, it's a bit early here in uh california, I'm visiting the mothership this week, so this is breakfast.

C

A

All right, let me pull up the agenda.

A

So I will go ahead and get started with the introduction from the chair uh hi. I am uh brian trammell. I am one of the two co-chairs of pan-rg uh jen lenkova. My uh co-chair was unable to attend uh today, so I will be running this meeting on my own.

A

um I will be sort of tracking uh some of the discussion into the hedge dock, but um if uh so, it's like the little note-taking tool icon on the thing. If there are other people who are in attendance, who could help me out there? I would very much appreciate it um for some reason. I don't have access, I'm not getting the actual markdown the markdown is rendered when you look at it on the data tracker. That is possibly a.

A

If you defile with the tools team, um but we will model along so um today, we are talking primarily uh exclusively uh about um progress on the uh the scion drafts and the discussion um around like how best to engage with that. uh We will start with an update to the scion component analysis draft. So this we discussed in philadelphia and remotely and in the interim before, um and then we will dive into a focus on the pki components right. So if you recall from the last time um the.

A

The feedback from the last uh meeting was there seemed to be three major components here um in uh in scion um pulling things together. Yes, the room is in use, um pulling things together um like trying to standardize the whole thing, as once is not going to work very well in the ietf context.

A

uh We think these are the three components let's actually get into them. So, like then, we'll talk about updates to that that draft and then we'll get into the first component, uh which is sort of the pki. um Are there any bashes to the agenda? Anyone like to talk about something else.

A

Going once going twice, okay, then without further ado, um scion component analysis. Nikola, are you going to you're going to speak to that one.

C

A

You hear me: yes, uh I can, uh you can go ahead and grab the um the presentation tools.

C

I think on mitaiko it tells me that there's no slides, I'm not sure if you need to like reload them or if not I'll, share my screen.

A

Really meeting materials- yes there they are so try again.

C

Oh okay, yeah now it appeared yep. Okay! Here we are no nice. I think you probably have to I'm not sure I cannot share them. If I click it just opens the pdf.

A

uh I have passed slides control to you.

C

Oh okay, now, yes, now I got it.

C

All right: do you now see the slides? Yes, take it away. uh How do I, uh okay yeah? I was missing the slides and somehow they're still not coming up, but anyways um I'll get started and see if they they come up at some point, uh let me see it's weird, because I I don't even see the slice control like in the slides.

A

C

You go, you are.

A

You are controlling the slides. We are now on the second slide.

C

Okay, no, but I cannot see them so I don't know, I think something got stuck in my I.

C

I let me try to re rejoin. I think something got stuck in my browser because I I I see the controls, but I don't see that I.

A

Am I am seeing that you are actually controlling the slides, okay.

C

Can you from this light control again? Where do I still have it? Yes, okay and.

C

Okay, now that I see them, thank you. I think something got turned.

A

Off and back on again excellent.

C

All right cool, then, let's get started so first thanks a lot brian for for the introduction. So this is nico, I guess uh yeah. You already know me from the previous presentations if you were attending um so in this session we are presenting updates to the component analysis draft that brian mentioned.

C

So just to summarize, where we stand as of today. Well, we started uh bringing more of scion to the itf in general back in vienna, so we had an initial discussion at idr and at the site meeting and we were invited kindly by the chairs at panergy to also bring some of the work into the group, and this is why, in the last interim that we had back in june, we presented an initial overview draft. That is meant to give you a rough idea of what scion is what it does.

C

As brian mentioned, there were many questions about this system. We wanted to decompose the system into components and that's why we prepared this component analysis that we are that we have been updating and in the end as mentioned before, then we will look at one of the component, which is the pki I'm kind of assuming that if you are here, you already heard about scion.

C

So I will not say too much just remember it is this past aware inter-domain architecture, its focus is on availability, security and scalability, especially when it comes to having adversaries in your network. It is deployed in production, especially here in switzerland. We have the banking ecosystem that communicates over cyan.

C

I see that we also have some a member of one of the isps that runs ion here in the audience. So thank you for joining simon.

C

Well, so I will not say too much more about cyan. If, if you want to know more, please look at the overview draft that is also linked in this slide.

C

Moving on to the components, just to recap, what we discussed the architecture when you deploy scion in an autonomous system, you have three fundamental components that somehow you must deploy so going from top to the bottom. We have the pki that takes care of authentication certificates and so on, and this is what corrine will present later. We have the control plane that basically uh explores and discovers routing information and disseminates it to the end hosts and in the end we have the data plane that does uh the actual uh forwarding.

C

So when we uh presented a system, as I mentioned, we got these questions about uh what the key components are. Can they be decomposed? Can they be used independently? Are there any protocols that are reused or extended?

C

Why or if they are not reused or extended, why we are not reusing or extending them, and so that's why we uh took uh the initial draft and we tried to um to address some of the feedback that we got at uh 114 in philadelphia.

C

So I think first of all, people found the itf presentation a lot clearer in terms of structure and thought organization than than the draft. So this is something that we have been trying doing, especially for each component. We have been trying to clarify what the input output relationship is uh between all of these components.

C

In addition to this, um I think uh some of the content related to existing protocols was also. I think there was need to clarify that, so we have also been working on that.

C

So when it comes to the actual draft, what's uh actually uh changed well, first of all, the overall structure has been heavily modified and we try to take a more component-specific approach, so we try to look at each component independently and then for each one of them.

C

We try to look first of all at the properties that are provided by these components and, second of all, we look at the input and outputs. So we call these input dependencies or what each component needs to be able to function, and then we call the outputs what is provided to other components. So what are yeah really the outputs?

C

And ultimately, we also moved the discussion about existing protocols from a general paragraph to have a more component focused discussion. So each component now has its own discussion about about this topic.

C

So when it comes to the actual dependencies, then we also try to summarize this in a very simple graph I think going from top to bottom. When you look at the control plane, pki, that is in charge of doing authentication.

C

We already mentioned that this is the most independent component and it does not really require that many strong dependencies in the sense that it requires an initial boost, dropping of trust, which is manifested in the form of a ceremony.

C

It requires some form of communication between the pti entities and it requires time synchronization so that you can verify uh certificate and what the pki does is that it provides a cryptographic material to the scion control plane. This is manifested into two main things. One of it is this aes certificate, so each scion autonomous system is issued a certificate that is then used to authenticate all the control messages and pki also provides a roots of trust that is manifested as a trc and later today we will really dig into the details of how this works.

C

When you look at the control plane, it does all the routing, and so the way this uh this is exposed to to the lower layer, which is basically the data plane, is by providing these authenticated segments and in addition to this, there is also a somehow error management protocol, which is scmp, which is somehow similar to icmp, but it is extended with authentication, and this is used for some kind of data plane, error messages, for example, reacting to link failure in in some cases and in the end, when you look at the data plane itself.

C

Well, that's the last cyan component and, of course, as behind below the data plane, you also have applications on on nhos that, in the end, uh are the ones that are leveraging the past aware secure communication that um that is provided by cyan, and so this is something that uh that probably also will require an interface. For example, there were some discussions at tops, I think uh about how to expose path, awareness to the transport layer, and so this is also, I think, important to mention this in in this draft, because it is an important.

C

Part of the component, I see that brian raised the raise his hand so.

A

I I just want to ask a clarifying question here on on sort of like the top of this diagram, like I really.

D

A

Diagram that sort of, like you know, makes it very clear that we should be spending our time talking about the pki a little bit later, um like the agenda is correct. Yay, um the we talk about sort of like applications on the end host, but in the the situation where you're, using sort of like scion for network engineering sort of like for building tunnels, that the end host is actually a tunnel endpoint right or the application is the tunnel endpoint. So this is not just like all the way down like the transition mechanism.

A

That's going to be, you know, possibly something that's accepting other packets and and encapsulating them. Correct, cool, correct.

C

Good yeah, yes, to be honest, we usually use nhost as a word, but the way that we, I I think personally, we should maybe uh talk about endpoints. I I think I like the word better and, to be honest, one of the things that I had in the back of my mind is also at some point to look at the vocabulary of properties and try to maybe align our uh our draft to that. But I know that there was some work going on on that draft as well.

C

So it was just not top of my priorities, let's say, but that was a. That is a very good good point.

C

All right um so uh moving on yeah. uh This is basically a summary of the dependencies. I think last time we already had quite a discussion about that. So I'm not gonna, repeat myself. I do have some slides from the previous discussion as well. If, if we wanna dig into some of the specific topics uh uh or otherwise uh yeah you can get to the draft brian sorry, I see you're still with your hand, raised.

A

I'm managing the queue poorly so continue.

C

ah Okay, all right so moving on. One thing that I mentioned is that we restructure the uh the sections that regard relationships to existing protocols.

C

So the idea there is to mention what protocols are reused or how cyan plays with those existing protocols and in the cases where these are not reused, we try to highlight the differences or the motivation. Why why some protocols are not reused? So when we look at each component individually, starting from the pki, we we described quickly that it uses x509. So this is somehow reused built on top of it, but on the other hand, we also discuss why existing pkis um could not be really leveraged without losing some property.

C

So, for example, if you were to use the rpki, you would miss this concept of isolation domains. That is quite fundamental for for this ion pki in terms of trust model.

C

When it comes to the routing part, we discussed the relationship with existing igp, so we just reiterate that scion is inter domain, so we scion basically leaves it open to each autonomous system to decide whatever intra-domain routing protocol it is using.

C

We moved the discussion about lisp there, because there are, of course, some similarities and differences, so, uh as with lis, scion is separating this concept of uh an host, locator and endos identifier and locator, and this is somewhat similar. But then the way things are implemented.

C

There are some differences, and I think we already talked about that a bit last time, and we also mentioned the relationship with rpki from a routing perspective, in the sense that some of the scion extensions that bridge between scion and ip actually build on top of our pki in order to authenticate prefix, basically prefix origin. When it comes to iprefixes.

C

When it comes to the data plane, um we also mentioned how it interacts with intra domain forwarding. We also mentioned that in the early deployments, uh scion is uh deployed intra domain on top of ipudp, so that it can basically leverage the existing infrastructure quite easily, and in this section we also moved uh the discussion about segment routing. I think there was a topic of discussion last time.

C

We did not have time to look deeper at how they could be possibly combining details, but I think that the concept is still the same as the last time. The two technologies could potentially work one on the intra domain, and that would be segment routing and scion on the inter domain, but how the path, awareness properties of each one of them interact is still an open question that we have not investigated in detail.

C

So I think that's that's mostly it when it comes to the component analysis draft, so we hope that these changes help to make it clear what what each component is doing and also helps us to move forward in discussions about how to move forward.

C

So we would be very happy to get additional feedback also on the draft on specific parts, uh whether they are clear or not.

C

We were also, we would also like to start a bit tasting. What is the mood when it comes to potentially uh doing more work in in the group on some of the draft so, for example, on adopting it, and on this point I also wanted to remind that. We have also this fire and overview draft that we presented in the last interim, and there was some feedback there, but I feel it was overall not specifically on the draft. It was more about focusing on this component analysis.

C

So that's why we decided to create this draft that I presented today, but that draft is also something that could potentially deserve some further work. For example, we have a section about deployment uh that and experiences that I think would be handy. uh We also explain a bit uh the motivation behind science. We give a glimpse of what the components are so yeah. We would be happy to get some feedback from the group and eventually being able to push some of the the draft draft further.

A

So I think, on that point, I'm noticing that we have um 11 people in attendance here today, which is actually a somewhat smaller group than we've had at previous meetings. Talking about this, so I think I would want to take the question on adoption to um to the mailing list uh and also the question on just sort of like finding reviewers uh for the document who maybe haven't already seen it, um take that one to the mailing list as well.

A

um uh Obviously, people who are here in the room, um you know if you have not read this document, please do uh and some comments to the list, uh but I want a few more eyeballs on it. You know with my chair hat on. I want a few more eyeballs on it before we. You know before we issue a formal call for adoption so like. Hopefully we can get a little discussion going on the list between now and london and we could put that question on the agenda for london.

A

And on the overview draft, uh I don't like I, I think the sort of like the component analysis is probably one that we probably would like definitely even want to publish right, because that sort of like sets up the framework for here's, how we think you would.

A

um You would split this up in order to engage with it in the ietf and that's also sort of like a work example of how you would do new architecture development in the idf right like so those are like as a work as a worked example of how to do this. It. It actually makes sense to to publish as an rg draft, that's an individual opinion. um I want to also discuss that uh either here or on the list.

A

um The overview document, I think, is probably going to evolve quite a bit as we figure out how to engage with the specific components right like so things that we're talking about putting into the overview doc might come out into other docks, for example, so like that would be maybe one to adopt, and not necessarily not necessarily with the intent that we're definitely going to publish this in rfc.

A

But maybe as one sort of like to continue the discussion as we figure out how to parcel these things out right because the the things that feed into the overview dock might then go into their own working groups or into existing working groups or so on and so forth, so like whatever gets published in there, I would want to see- probably I would guess, probably would be shorter than what's there right now, but it can be sort of like a holding document until we figure out how to split things up.

A

Are there any other opinions? I notice I'm talking a lot.

E

um Yeah I mean just just following up on on the discussion of publishing it I mean we, we have to be a a little careful because, because this is a an irtf group, so we can't so into what the I etf should be doing, um a a components, draft that talks about what what are the pieces here, which are the areas which need uh potential further research, which are the areas that seem potentially mature enough.

E

That's a separate, a separate standard standardization activity could happen in the ietf uh would seem would seem like a reasonable uh discussion so to set the scene, for you know, what's what's future irtf research? What and what? What is? What isn't in need of future research?

E

um But then it's up to the ietf to decide whether that's something it wants to standardize. uh It's not something where we can say you go go ahead and standardize this we can say um we think this is mature enough for potential standardization. That's not quite not quite the same recommendations. We just have to be a little bit careful, but but yes uh fundamentally, I think I agree with what brian said.

A

And you can continue. Where is this last slide?.

C

Yeah, no, uh so I think uh I think that's it. um For from my component uh analysis, I mean I have similar slides to the ones that we had last time, but I think we had a discussion. So if we want to go into specific topics we can we can, but I mean, in terms of presenting, I try to focus more on the delta. I hope that.

A

C

Just following up on what what colin mentioned, I think what is important um for for us is uh to document. I think we already discussed a bit this in philadelphia.

C

It is important to document what exists today, so the goal would definitely not be aimed at in the short term, but it would be being able to somehow uh uh freeze or document what what is deployed today, how science works uh in in the deployment that are around today and then I think this could be used for future work uh as standardization, but I think it would be good to do it in steps. So first get something like this: it could maybe even be an independent uh drafts or it could be it well.

C

You know it's it's. It's.

A

C

A

So colin has probably jumped in to uh give the advice that I was about to give. So I will let colin give that advice, because I've been talking a lot so.

E

I I'm very happy to let you give the advice and see if we match.

A

Yeah so um like the documenting, what is is um done today as sort of the basis for sort of future standardization or future work in in a research group, as you alluded to, is pretty much exactly one of the functions of the independent submissions um stream right like so, it seems a lot like if so, that would be an alternate way to engage with the overview if you actually take the overview document and build it out with the existing component overview, not with a with a an eye toward decomposition, but with an eye tour just like here's, what we built and with the deployment models and experiences- and you say, like you- know, eth and the eth foundation's implementation of scion right, um and I think that that the the content in the document right now is a pretty good start on that and like that is, is pretty well established practice.

A

That is one of the things that the iet, the independent submission stream is for is here is a um here is a informatively referenceable thing that says what we did and then you can talk about deltas to that in any of the changes that um uh that get adopted the idf or that we adopt his research here in in panergy, um and you can also um well yeah just use those as a baseline um uh and as examples of in future idf discussions of yes.

A

Here is why we think this will work because of this deployment information. So I think that is. It is useful to build that document out, but, like that clearly belongs, you know my opinion in the independent submission stream. Let's see if colin agrees with me.

E

um Yeah, I I I think I do um so describing what what you have deployed now is you know it is a reasonable goal for the independent stream.

E

uh If you want to standardize it, the itf will want to take change control and uh will almost certainly make make significant changes, because I've never yet seen the itf just rubber stamper protocol and not make significant changes when it does this- um and you know so, you'll end up end up with something that probably looks quite different by the time the itf is finished with it, um and you know, on the irtf side, I think that the focus would have to be identifying the areas where there's there's new things to learn.

E

You know perhaps to make it scale or I don't know you know, I'm not familiar with it enough to know exactly what those would be um and we'd be identifying the the areas where more research is needed for the irtf side of things. So yeah.

A

Good good any other discussion uh go ahead. Nichola.

C

Yeah, just following up on that, uh maybe after the next presentation, when we look at one of the component, then we can pick up this discussion uh and I would have a question, but I think it's better if we answer later whether it would be uh whether a detailed component description like the pki would be a better candidate for any submission or whether it would be more the component analysis. But I would say: let's: let's go through the presentation first and then we can pick this up.

A

I agree that sounds like a good idea, so I think with that, uh is coding going to do the the next presentation excellent. So I will pass slides control.

A

A

B

B

Okay, it's there. Do you see it? Yes,.

A

I do and do you see it is the more important question I.

B

Can see it, and I can also, I think, yeah go to the next slide. Okay, perfect! So welcome everybody. Thank you for your uh presentation nicola and also thank uh penancy for inviting us again.

B

As nikola already announced, uh I'm going to introduce the sign control plane pki a little bit. I mean it's a bit more detailed than uh than just the overview of all the components, but it's also, of course, not not very detailed, very specified. In the end, it's just more like a summary of the draft I submitted two weeks ago.

B

um Oh, I can go here, okay, so, as nicola already said- and you now in in the meantime probably already know- sign is inter-domain internet architecture password internet architecture- it is all about routing, inter domain routing, multi-path routes are supported and when routing it focuses on availability, security and scalability.

B

But the question is: how can you be sure that science routing information is authentic and trustworthy bertie, because, as we all know, the internet is not such a safe place. Parties are inherently distrustful yeah how, and so, how can we be sure that information is really sign information, and for this the requirement is that that the integrity and authenticity of the control, plane, messages and path segments should be verifiable, and for this we have set up an authentication mechanism which is based on the public key infrastructure and the purpose of the sign control, plane.

B

Pki is providing a mechanism to distribute and authenticate the public keys which are used to verify control, plane messages.

B

So now I have to oh yes, so we set up um our own control, plane, pki, and when doing this, we try to meet the following requirements.

B

It was important that there is. It is resilient to a root of trust compromise, especially also single route of trust compromise, and then there would be a something would be compromised. A quick recovery must be possible.

B

We also want to have multilateral government, not one single body or entity. There must be support for versioning and updates, and uh that should be a flexible trust model. But what means that entities can select which trust routes they need to rely upon, which trust routes they trust or yeah.

B

So what would be ideal would be that the trust architecture allows allows multiple mutual trusting parties to form their own uh trust bond bond and also to decide freely whom they want to trust outside of this truss bubble.

B

And another requirement is also that the whole system remains highly available, so the pki infras of architecture should work also without being dependent on communication with pki servers, and this requirement is there to avoid cyclic dependency between routing updates and pki operation, and with this uh in mind, bf sign has uh has this isolation domains approach where they which they think can tackle these issues or meet the requirements we I mentioned before and while you may have known of heard of them now in the meantime, isolation demands domains are a logical grouping of a s's that share a uniform trust environment like a common jurisdiction- and here you see some isds- they are building blocks to achieve high availability and scalability support for heterogeneous trust, and then each isolation domain is administrated by several core asses.

B

Are these bytes um yeah? What is its uh circles in in within the isds and these core isds? They negotiate a trust policy or a contract which is called the trust root configuration and which is valid. For this specific isd, and also important to mention is that the certificate authentications authorities in an isd can only create certificates for the asses in this respective isd.

B

And we think that uh the sign control plane uh makes a difference if you compare it with other uh pki models, because we have no omnipotent trust route or certification authority, and what is also quite special is that the cost, this trust contract, which is valid for one isd and its updates must be approved by some a special voting mechanism, which includes more than one voting party. So this prevents one single party to compromise the entire isd, and it also enables multilateral governments.

B

He also hope that it enables trust agility, because uh users are free to select an isolation for internet service provider, which is an as a nas which uses sine is part of an isolation domain, and so because of this users can select, say the internet service provider. They they want to join, and they in a way can then, with this select which route they trust.

B

And then the members of an isolation domain can also freely decide which other isolation domain. They want to trust. Additionally,.

B

So I already mentioned this trust root configuration this kind of trust contract. This is the trust anchor of the isolation domain and because it holds the root certificates of the isolation domain's chain of trust. It also facilitates the validation of bindings between as's names and public keys, and it bootstraps authentication within an isolation domain, and this happens in a special signing ceremony where the initial the base trust root, configuration is created, and it also is a means to efficiently revoke compromised routes of trust.

B

So this is some kind of graphic of this trust root configuration and it collects it's basically, a collection of root certificates which are x, 509 formats, certificates, version 3 self-signed. There are also so-called voting certificates.

B

Then it also includes, like the trust policy, in a way, the the parameters that set the trust policy of the isolation domain like, for instance, the validity period of this trust root configuration the grace period, which is the periods uh during which two uh trust root configurations are valid, uh which are the it sets the core, uh as is of the trust, no not to thrust, but the isolation domain and several more parameters.

B

As I already said, the first truss route configuration in isd is called the base trc, but it is possible to update these drcs, and these update updates again must be signed by designating aes, which we call the voting asses, and this is all described in more detail in the draft which has been submitted a couple of weeks ago.

B

So the trc bootstraps in a way the chain of trust or is the at the root of the chain of trust of an isolation domain. We have the root certificates, which are part of this trust, root configuration they are needed. They are used to sign the ca certificates and this case dca sign the.

B

uh How do you say these certificates are used to verify these other certificates, but uh the corresponding private keys are used to sign these certificates, so the uh root private key is science to um ca certificate and the ca private key is used to sign the as certificate and then the other way around. The public keys are used to verify these certificates and then the asses they signed the control plane messages.

B

They used their private key for that, and if you want to verify these control play messages, you need the corresponding as certificates. So this is very very shortly. uh The chain of trust between an isd.

B

So, in its in a way, you can see the whole. This whole trust concept as some kind of function.

B

It is scoped on isd level and it transforms in a way that potential distrust or possible distrust among different parties into a mutually accepted trust bond, and it is important to mention that uh not all member members, member asses, do need to trust each other, but they shouldn't trust the core assets of an isd, the isd's certification authorities and the voting ass- and here you see also graphically this. This function, graphically displayed like inputs, are these policy parameters and the required keys and certificates. The function is in a way, the bootstrapping and then later on.

B

The update procedures and the outputs are the trust, contract, trc or the update of it and the as certificates.

B

These certificates, they are all. Oh yes, sorry, yes, brian! I see you raise a hand.

A

Yeah, I did um so uh pop back to the the last slide, real quick. um So like the thanks, the there's, the set of entities that need to be trusted by any member as these entities, don't necessarily each have their own.

A

Their own sort of like organization or corporate entity in sort of like the world right like so you might have like the set of corey s's and the cas, might be the same sort of like we'd, say administrative domain or might be the same sort of corporate entity or you might have it like you.

A

Might this structure doesn't necessarily have to overlay the organizational structure of how all of this is set up right like because there's the there's the cryptographic question of like who has the material to be able to sign a thing, um but then there's also sort of like the organizational structure of who can tell the people to sign things right like, and how does do? Do we get into like the question of what the organizational structure would have to look like in order to make the the the passive trust work?

A

Or is that, like a question at this time,.

B

It is not as in detail, it is not part of this uh presentation, but it is the cas, especially uh they. uh How do you say it? They can be uh asses which are a member of the of the isd, but they can also uh that can also be outsourced.

A

Right because, like when you, when you get into sort of like you know specifying how this is going to work, if you compare this, for example, to the rpki right, the rpk has a set of protocols, but it also has a set of practices and procedures at the irs, and those are also important for the general trustworthiness of the arrangement. So that's probably a different document. I just wanted to to raise it.

B

There is there is, especially in the draft. There is a bit more in more detail described how this signing ceremony should be set up, and but there is also a sign also explicitly at least members of the isd, some freedom in how they, how they organize how they set this up, and also yeah yeah, how they? How do you say this? Who, who are the voting uh asses, who are the core asses? That's something they have to isds- have to uh make this up among themselves.

A

So, okay, so the organizational the the interface between this and the organizational governance shows up in the signing syrup I'll take a closer look at the signing ceremony. Yes, thank you very much.

B

Yes, so that's uh can I continue okay, good so uh well about the certificates they. As I said already, they are x, 509 version, 3 format and base of this rfc 5280, and you already saw there are three kind of control: plane, certificates, roots certificates, ca certificates and as certificates, and they built the verification chain.

B

Then separate of this, there are the voting certificates, you have regular voting certificates and they are used to verify a regular periodic updates of trcs uh without uh important changes in core entities or policies.

B

So uh this is more like if, if a root certificate or a voting certificate expires and has to be replaced by a new one, but uh in case there are really uh yes changes in the set of core asses, for instance of or if one root key is compromised. uh That must that it can be possible to. uh There might be a sensitive update uh where you really replace a specific certificate, and this is called a sensitive uh update and for this unity, sensitive voting certificate and these details are all again described in the draft.

B

And then, of course, if you have certificates, they also maybe can be revoked, and this is also enabled by the control, pin pki.

B

And this is very shortly how a compromise certificate in sign can be revoked for the root certificate, voting certificate or core as certificates. This happens through updating the trc, and if too many certificates of this kind of certificates are compromised, it is even possible that a trc trust reset may be needed, and this I come back to this a bit later on, but ca certificates and also the non-core as certificates. They are in a way automatically revoked because they are short-lived certificates which only live for 11 respectively three days, and then they are reissued again.

B

So this is in a way how they are revoked and in cyan there is no revocation list. The revoked certificates are meant to be discovered via the scion pass exploration process.

B

And, of course, uh nth hosts or points are not. They do not only communicate with asses in their own isd, but they also communicate with other asses or maybe are even also part of other isds, so they need to. They need access to all these trcs of all the entities in isds they they communicate with, and the question is, of course, how do they get?

B

How do they obtain these rs trcs of these neighboring isds or relying parties, and at the moment, in the real life implementation this happens manually, so the operators of an isd they really receive can receive new or updated to us, these trcs through multiple channels, like really out-of-band mechanisms, but also, maybe that they discover updated trcs via pass exploration and what they do is that they add these new, updated trcs in the trust store manually, but we hope in the future to implement an automatic discovery mechanism uh which again is based on science, uh past exploration and resolution method.

B

I I do not uh go in details very much into this uh past exploration and razor resolution, past resolution methods. Now uh this will be part of the. If there will be another draft about the control plane- and you can also it's a bit more explained- also in the draft- so what is a trc life cycle?

B

First, we have this bootstrapping of trusts in an uh isd where you yeah, the first initial uh based trc of an isd is actually created. This is an in-person signing ceremony and the participants are a representative of the is the voting ass, a ceremony administrator and a neutral witness, and they have in advance of this signing ceremony.

B

They have to agree upon these parameters, which are which sets the policy the trust policy of an isd they also have to agree and on the set of route certificates and of, uh of course, also uh what you were talking about, brian also in itself on the organization of this. This um uh publicly.

B

This infrastructure in itself, so who is uh who will be voting, uh uh will be voting as who will be a a certification authority uh core, as a thing like that that that is, uh it is assumed that this is um how results negotiated in advance before this uh bootstrapping of trust ceremony ceremony.

B

uh What happens in the very first designing ceremony is that also the number of the isd is selected, and then there are four phases of this ceremony. First is that the certificates which are part of the trc are exchanged?

B

That is not, of course, the certificates, the public key, not the private keys, then the payload of the trc are is generated.

B

Then the parties which are present present sign the trc, and then it is validated, and if this all of this has been uh has been passed, then it is distributed out of band throughout our isd, and so it is also like. uh This is not something which is really fixed. uh Every isd can set up this ceremony itself like the way they they like it, but of course it should be more or less along these lines and, of course, the trc itself, how it should look like is defined. It's also written in this draft.

B

So in the the output of this ceremony should be a valid trc and then also for uh tlc updates, especially sensitive updates. You can uh it's up to the isds whether they will uh create another uh in-person ceremony or if they do this automatically. These aspects are a bit. We give the isd a little bit freedom in how they do this.

B

Then the other thing is, of course, how do all the member parties finds out that trc are updated?

B

First, they are usually updated as already said that when a root or voting certificate certificates expires and is replaced, so just a regular update and then it can also be necessary to update uh tier c when a one root key is compromised or when there is, for instance, a change in core asses, but if in very very catastrophe, uh situations or really serious situations, when more than so many keys are compromised that it is not possible anymore uh to vote for an updated trc, it must might be pos needed to really totally revoke on trc and uh reset it.

B

This is. This is called trust reset, and this is also something which I an isd or the members of the isd have to decide in the beginning already whether they allow this or not so it can be. You can set as one of the parameters. You can uh define a no trust resets. What is it parameter and and really explicitly say we do not want to have to have a truss reset, because it's it's too much of a hassle and too much of risk risk, but suppose it happens.

B

uh Then a new base trc is created and because this is really across resets, it cannot be verified with certificates which were in the previous trc. So this again this first, this new base tlc, must be actually axiomatically trusted and then it also must be distributed out of bands.

B

And how do are these updated or even reseted tlc discovered? This again is for this past exploration and pulse resolution mechanisms scion offers- and this is very very shortly- how it works.

B

There is a new trc which is signed by a number of votes defined in the previous trc, and then this the number of this new trc, the ids of this new trc, is announced in science control, plain messages and even ais then discovers that it does not have this new trc, because the trc it has that the number is is lower than the one of the new one. It can fetch it. It can ask for it.

B

uh It can ask them how to say the a s that sent a control play message to get the new trc and through this mechanism, the new, the new trc with the new truss roots, propagates quite rapidly through the network, so really within minutes or yeah in maybe in a bad case in hours. But this is this goes very fast or relatively fast. Maybe I don't so now. I have like explained a little bit in theory how how this works, but it's not only a theory. It is really also already deployed.

B

We have already two industry-grade implementations in switzerland. uh One is uh so this. The control plane pica, is in in use by the main financial infrastructure and service provider of switzerland, the sixth group, and if you click on this link, it goes to a page of six where they explain how they use it. And then there is another implementation which is based on the hashicorp hashicorp vault and the design implementation company anapaya has also a website where they explain how this works.

B

So, if you I don't know the the slides are available, I think uh afterwards and people who are interested in this. They can then click these links and have a look at it. How it works.

A

Yeah, these are all in the meeting materials. Okay,.

B

Yes- and there is also an open source implementation in our so-called sign proto. uh What is it open source? uh Yes, sign, lab installation, and there you can also there. You can also have a look and there you can also see how how it is implemented there. So it really it. It is really. It works.

B

uh Yes, brian you raise.

A

B

A

We have like three different implementations: uh do these interoperate with each other, like, as I understand it, sort of like the the like the scion lab and the industrial code bases are not yet, or at least the last I I I looked were not yet sort of aligned with each other. Are these implementations of the same protocol or they worked examples that this approach to doing trust root configuration works like could I connect?

A

Could I build something with cyan proto and connect to six group? Assuming that they would? You know.

B

Nikola you, you also raise your hands, maybe.

C

uh Yeah I wanted to I mean on this.

C

um So um as far as I'm aware, I think the general that this player is incorporable, but I think there might be some extensions that are not part of the core pki that are not equally deployed. So some of the extensions are only deployed on the experimental uh research network in lab, but not on the productive one.

C

A

Cool, so these are, these are theoretically mostly interoperable, independent implementations, but but at the end is not okay, that's cool! Thank you for the answer.

B

Yeah so, um but it's in it's an interesting point. Definitely I mean okay, so so now, I'm already coming to the end of the presentation which, as I already said, is very really some some summary of of what is explained in the drafts- and I also I mean nikola also also said it, and I was already even already in discussion that yeah we have now these three active drafts and and uh yeah we were. We are just thinking how. How can we?

B

What would be the next steps uh into the possible adoption process and well, we already discussed this a bit so um yeah. Maybe now that you, I don't know if anybody has seen the draft itself, I mean this was only the presentation but um yeah this. This could maybe also be, for instance, something which could go in the independent uh submission stream. I don't I don't know, but um so this is something we are really you. You realize, because also nikola had this question. We just are figuring out how we can continue from now on.

B

Yes and thank you very much for for your um attention and if there are questions, I'm very happy to answer them, maybe first on on the pki itself, the control, plane, pki and, and then also maybe we can discuss a bit further these uh these things we already discussed with nikola, okay,.

A

A

Questions discussion.

A

Clarifying anything karsten.

D

Yeah- this has already been said just not by me. um The word adoption here is is uh really confusing and uh there are very different things that that can be done by an adoption and in a research group. Adoption essentially means that the research group thinks this is interesting stuff. It doesn't mean that uh anything is good or works, or it could be the basis for for a major engineering effort. It's just interesting uh research, so I I wouldn't get my hopes up just because this research group thinks this. This is interesting stuff.

D

I said that the proof will be in the pudding in the end, um so um I I think that uh the the fact that that penergy hasn't been talking about anything uh for a few years for a few months already is an indication that cyan is is interesting. So we have already generated that and how we actually handle. The specific documents um depends on what we're trying to do. The ise, independent submission part is good for one actor just going ahead and describing what they did.

D

The the research group can actually help with getting a more fundamental analysis of what has been done so that that is still something that could be a good research uh group document.

D

Looking at this, this pki stuff, um there are certainly models that could be applied for describing uh what's going on in this pki uh draft, um and it would be useful to to see how these these models describe.

D

uh What you are doing so that that might actually be an interesting, a research group document which also might help setting up terminology uh that you can use in the future, which are less confusing than calling everything trust.

B

Yeah, that's a very good point, because uh the draft I also uh we submitted is really a very. It was a really very first version because we were asked to submit some submit something and we had not so much time. So, uh like things like this, we definitely want to have a section where we do. You know some kind of glossary where we define all these terms, which is now you are totally right.

B

It's it's not really very, not really very specifically defined yet or described yet, and so that is, that is definitely something we have to work on and uh yeah.

D

Yeah and I think getting the terminology right is really hard and that's something that a research group can can provide a really good service, because people come together that have very different backgrounds.

B

Yeah, I think you also, I mean the point is also that we we have this very broad question, because we are just a bit like. uh I think we we are just a bit trying to find out uh in what can be yeah. How can we proceed because uh in the end we have 10 drafts or something and- and you know we should- we want to try to continue in a way with some of the things we we started now. Yeah.

B

A

uh As as an individual, I will well second uh carson's point. I think that um talking about terminology is something that we do very well here, and we can do quite a lot of it. um Actually, we need to. I was reminded today that we need to get back to our our path properties uh vocabulary document because uh it expired, so that will also be on the agenda in london.

A

A

I I'm not sure how to do this, but the group of people who sort of showed up in panergy at the beginning because of like the work that started off at the beginning were were very transport protocol, oriented people and we kept doing things like scheduling against routing working group things, and that was not great and and now we do have people from the routing area looking at things, but digging into I'm not sure that the people who are in the room right now like so who generally are you know engaging on the panoramic list and showing up uh in the meetings as well as the interims, are necessarily of a security bent to like really have the the the most useful input on the terminology.

A

I I think that, like getting down and being very precise about like how this works and generalizing it a bit, I think that's something that the the rgp can do very well, but we're going to need to do some outreach and expand the room a little bit in order to do that right.

A

um The looking at the draft as it is right now like so like it's. It's sort of a description of what's there. uh I I think if we go the route of of you know adopting it and working on this draft a bit more in the research group before we send it somewhere, it's going to turn into a very different draft right, like it's going to be generalization of this approach, because there's a lot, that's very specific about right.

A

So I think the draft makes the case very well about why you can't just sort of lift and shift the rpki into like a scion-like network. Right like this idea of isolation. Domains is fairly fundamental um and that comes with sort of different ceremonies and existing uh pkis. It comes with different actors: you're, using a lot of the same sort of presentation, layer and application layer concepts where you're using x509 three you have like the the um the formats are are interoperable things that we already have.

A

We already have experience with, but the arrangement of the components is different, so um yeah. I think that, like focusing on bringing this into the research group and and talking about sort of like terminology and generalization seems quite interesting, I want to have a discussion on again. We have 11 people here right now.

A

I want to have a broader discussion on the list uh and then revisit this on the agenda in london, uh but we really would have to get um some security people interested in coming coming and hanging out with us to help with that work.

B

E

uh Yeah, I think I think I'd agree with that. I think that there's there's definitely scope for an interesting uh discussion about the different security models and how that and how to interoperate between the different models and what are the trade-offs and so on, and I think there's a bunch of interesting research questions there.

E

um I'm not sure that's what this this current draft is. um This seems more of a description of what what is implemented now um and I think how to proceed that I think, really depends on what your goal is. If your goal is to document, what's what exists now as a set of rfcs, then you know the independent stream would seem like the right way to do it.

E

If the goal is to understand the broader questions around you in this particular case, you know the pki and the security and trust models, and so on, then a research group as panagio one of the others, is something to think about.

E

You develop a standardized version and perhaps to understand which pieces you know how to um you know incorporate some of the trust models that exist in the current internet and how to interact with them and standardize it and and bridge that into the scion world. Then you possibly want some combination of the itf work and the irtf.

B

This is almost.

B

That would be almost academically like research, really about more, like how you say that, then you don't think any more about how it is implemented now. But you you are more like it's more like almost on a philosophical level, not not, of course, but uh more, like uh really uh talking about models and comparing them and seeing how they yeah.

E

I I think, if you, the sorts of things, a research group would do would be more on the academic side um she wants. You know, obviously it this seems like something that could be mature enough to standardize and that would involve taking it to the ietf and letting them take change control. And I would guess that one of the questions they would ask is well.

E

How can we interwork the the security model of scion with the security models, or lack thereof, that we have in the internet and there's going to be some things which are, um I think, clear? How to do it and the standards world could can advance that, and there are probably some some questions which would uh be more on the research side and you'd end up with a a bit of activity in both the ietf and the irtf.

C

E

But again that would be evolving what you have if uh in a particular direction versus. Are you just publishing what you have now as a record of the existing system.

C

E

Versus are you just saying? Well, you know w we've got what we have and we're happy with it, but there are some open research questions for the next generation of cyan in however many years, which might be a more research question. So really.

B

That's where you want to summarize what has been said, uh the the two documents, the overview document and and uh the cppi are really describing. What what is there now so you this would be more appropriate for the I, the independent ise stream over is its submission or and what uh the the draft of niklas draft is a bit more, uh maybe a bit more. uh How do you say it?

B

It's a bit more mature and it's better. Does this better.

E

Again, I think it depends what you want to do with it.

B

E

Yeah I mean the draft you have for the pka now, for example, looks to me as someone who doesn't really understand pkis. It looks to me like a perfectly reasonable protocol spec and if what you, if your goal, is to document what you have now then publishing that that, as an independent stream document would seem like a reasonable thing to do right now,.

B

E

Independent stream has done that in a bunch of occasions. You know company x's protocols do why um if the goal is to bring it into the ietf and turn it into a set of standards documents, then that might be a starting point for that process. But what you end up with might look quite different after the itf process is run.

E

If the goal is to see some research, then- uh and I'm not sure- that's quite the right document, because it's focusing on what you have rather than what are the open questions.

B

Okay, oh there are.

E

Dustin in the queue, so maybe he is yeah.

D

Yeah, I just wanted to point out that this is not an alternative right. You can go for an ic publication of of what you have today and still go to the research group and and ask for help uh putting this in into a more general, understandable uh framework and- and uh I haven't read the document- so I don't know whether it's it's ready for for ise publication, but uh I think that might be a quite attractive uh approach and you can even pursue this in in parallel.

D

So there is no written wait for one to complete to do the other, because the the researcher can work on the internet. Draft of the other uh document.

E

And it may even be that it may even be that all three of these happen in parallel in the you know, publishing what you have now on the independent stream while simultaneously saying okay, there are these bits which are standardizable, which we should try and take into the ietf. And there are these open research questions which we should bring into.

B

E

You know um yeah that it's a question: what are your goals.

B

Yeah, I think I think it's it's clear nicola. Do you have to add something? Do you want to mention something you do.

C

Thanks all right, sorry we're in nothing room so um so yeah. I think the goal. What uh what colin mentioned uh makes a lot of sense. So the goal is definitely to somehow document what is existing, especially because because of the existing deployments that I mean as we, for example, before we mentioned, there's different pkis. Some basically is interoperable, but some extensions are not so clearly defining a boundary there. What is let's say the per minimum would be very beneficial for uh for those initial deployments, so that would be.

C

uh I think it would be beneficial to go through the isc, uh but as mentioned, this does not exclude uh continuing the research part, because there is still a lot of uh research. I mean also here at ath. There is a lot of research and, besides that, there's also other people that sometimes join discussions here, mostly at banerjee, but also at other groups, because there's a lot of research on many aspects, for example, transition mechanisms and so on and of course, uh moving into the itf for a bigger standardization work.

C

I think this would also be beneficial because there are some engineering challenges that I mean. Some of them are already addressed with the early deployments, but I'm sure there are more where so far things are not very clearly defined. So I think this would also be very beneficial, but perhaps at the later stage. So I hope that adds something to what we discussed before I'll leave it to the next in the queue.

C

I think that is calling.

A

Are you still, are you yeah good.

E

That means I forgot to at least thank you.

A

Great, so it it seems like there's four documents. This is just me thinking aloud. This is not me with my chair hat on. um It seems like there are four documents that should go to the ise there's the overview, there's the pki, um there's the control plane and then there's the data plane right like so those four specifications and those would be sort of, like you know, a an exposition on the existing deployments of the scion internet architecture right and that that set of four documents would be would form the basis.

A

I think of everything else that that you all want to do in this space right like so that's you have a published thing. You can point to it. You have like a a uh you're engaging with the outer community and say these are the things that work. These are the things that didn't. This is how we why we built this. The way that we did, um those, I think, are going to be very useful.

A

Regardless of what uh like nicolas said like there are, there are engineering challenges that would be. That would be useful to address in a in a form like the ietf. uh Those are all going to push toward building sort of like interoperable components like in the component analysis um where you could actually sort of like you know. I mean build this into. You know the actual next internet right, which is the the long-term goal.

A

um I agree with with everything that colin and carson said here that, like you, don't have to pick one, but I would also say you have a finite amount of time, and I think probably the place to put the time now would be in refining the documents for ise publication like getting something there that you can, like. You know, stick a pin in the sand and say this is where we are starting.

A

um At the same time with you know, my pan rg chair, head on um I've, heard a few things um mentioned here. That would be documents that you could start in parallel and start a discussion within this research group. One is like, um let's actually explore the space of of pkis and architectures, that look like scion. One is developing a vocabulary that is more precise for dealing with with trust and authorization in pathway networks.

A

Right like so I mean that's even up that even like goes directly to a couple of the questions in the in the foundational document thing, and I think it's up to you about. You know where you want to focus your finite time. First versus later it it's, it seems like what I would advise again.

A

Chair, hat off is get the four documents into a state where they make sense to send the ise first right, because that will be the thing that you that you have that you can show to start all of the conversations in the research group as well as outside the research group.

B

Thanks this is really very helpful. I think I mean um for me yeah. Thank you very much, and uh I also uh for me it's also very clear. Now uh I've cleared the different. What is it the the difference between this ise and also what what you in your group would like to to see and discuss?

B

uh That's uh so definitely the the the ones uh the overview and the control plane. Pke are. How do you say it's much to play in a way for for for your group, I mean it's, it's just descriptive and and not uh how do you say it's not not so much uh food for salt. You know like uh yeah, yep,.

A

So I think that that, like something that I've seen and I see the queue growing, but I am going to address this one first, sorry chairs prerogative, um a thing that I've seen in the the three meetings that we've done um so far uh talking about sort of scion in general. Is that, like every time we have an overview there? Are people engaging in this room? Saying that's an interesting research question. That's an interesting research question! That's an interesting research question!

A

um I'm I'm not sure it makes sense to have sort of like the development of these ise documents, be a thing that happens in the research group right because they're like it's for a different thing, but I would like to see um sort of periodic updates within pan rg on here's. What we're working on right now because like when that gets presented in this forum like every time you've brought something here, you've gotten like feedback that I think is useful to the research community and useful to yourselves right like so.

A

I think this is that part of this this this. This interaction is working very well and I'd like to see that continue. So maybe it's focus a bit on the ise stuff now but give presentations about it here um and then we continue having like I. I hope that next time we have like slightly more attendance for the interim, I'm I'm um uh a little surprised that we're only 10 today, um but.

B

Maybe also because pki is not so part aware, I mean it's not yeah.

A

How to like, if we want to have those discussions here, and I think that we should like the stuff that carson was digging into about okay? How can we be more precise about how trust and authorization work in networks like this?

A

That's super interesting right, but um I I think we need to cast the net a little bit wider. Maybe in london um try to do a very fast presentation on this in this. What the security area open, sag.

A

To say: hey we're talking about this in banner.

B

Based on what you say, I think there will be. There are two type two uh horizons. We have the the documentation of what is really there and also implement it so so uh like, and then there is uh the what is this, the stream or what it? What how do you say?

B

It's, the the part where, uh where we have the more theoretical discussion which can be uh held in penalty- and I I guess this can also be very interesting- maybe I don't know- I'm really just thinking loud now for phds or or uh yeah like uh people who who really do research, so we should discuss it with adrian, of course, yeah how how we can uh streamline or organize this.

A

B

But thanks a lot.

A

You're welcome uh nicola go ahead. Let me catch up on the notes.

C

Yeah, I I think um I think you already partially answered my question, so it was really about the expectations from panergy and uh yeah how it should track. So I think that is somehow clear um regarding your next point. You you mentioned maybe presenting this somewhere at the security area or um how would this work if, if we are also perhaps developing something with a independent stream, would it be just presenting hey.

A

Like so, basically the the thing in sag would be. You basically just show up to the open meeting and you're you're, essentially giving an ad for coming to panergy right. It's like saying, hey. You know we're working on this.

A

There's this document which we're doing to the ise, but we're having discussions about research, questions that this document throws up right like so, um and we noticed that panergy is, is basically transporting routing geeks and we need some security geeks in there right like so that's you know you can send that out to the to the mailing list as well right like so the and the idea is that you get some you get some more. um You get some more eyeballs on the drafts that are going to the ise right.

A

Like I mean those drafts are still they're still internet drafts, anybody can read them right, um but you're being very clear that hey no! This is not. This is not the start of a standardization process, it might be the basis of future standardization. This is us documenting this for the benefit of future research and future standardization. But but um you know here are the documents, and we talk about research, questions that might pop up around this in panargy.

A

Please join us right. It's a little bit like. I think you want to send that to the list first, because um I'm going to be like very adamant that we don't schedule pan energy on friday, and I think sag is always on thursday afternoon right like so that the timing might not line up right, um but uh yeah I mean you can also like I've done it before. Where I go to like tsp area, I'm like hey, you just missed a great meeting. um Please join us in the mailing list right. This is like.

A

I think that one of the things that we should focus on in london is just sort of making sure that the the the community is is built up the right way, so we're gonna get the right feedback to to figure out what we're gonna focus on here on the research group, karsten.

D

Yeah, I just wanted to understand by pointing out that the iitf is more than just penergy.

D

So if we find something here that really can be or should be spin spun out uh to something that that is focusing on on security and authorization and so on, uh we probably want to discuss this in a larger irtf uh context. I mean the result, could be that we say: okay, that's still fine to do in penergy, but that should be the result of a discussion and not just the presumption.

A

Panergy, I am mortally offended by the the idea that there are other research groups, but I agree wholeheartedly with you yeah. I think that that yeah- I I don't want to say. Yes, we need to bring everybody into pan energy. I I want to say more: we need to make sure that we get this in front of the right. uh uh The right eyeballs- and I am- I am happy again tear hat on for this- to be the default form for those things, um but uh but yeah.

A

I think, actually, I'm going to call karsten or I'm going to call call into the microphone um to answer the question of sort of like the best way to engage irtf wide. With this.

E

um Yeah I mean, I think that the core of this is a puffer where critical, so for now, I think panachi is as good a home for it as any. um If the work starts drifting into much broader areas, then we can revisit that in the future.

E

um I think right now. If, if we tr, we try and move move it to a different home or um scatter the work too widely, then we're going to dilute the efforts and yeah we're not currently over overflowing with people in this group.

D

Custom- I I wasn't talking about moving so that the the interesting thing about all these uh uh groups we have in in the iitf is that they are all very virtual, uh so it's more like pulling in other groups uh and and making sure their specific expertise on on some aspects of this um could be used. um Obviously, the the the actual uh model of of players and and actors and objectives, and so on, is very pathway specific, so so pen will always be an anchor for this activity. I was just pointing out.

D

There may be other groups that may have something to to contribute here.

E

Yep absolutely absolutely.

A

Notetaker, at the same time, so I'm curiously typing over in the corner. I will continue catching up on that and publish some minutes at the end, but I um went to before uh you know, going off and doing the closing and giving everybody 32 minutes back. um Ask if there are any other points of discussion or questions that people would like to raise or any other questions that um the presenters would like to ask the room.

A

C

So maybe just in view of london, I guess we would just uh polish a bit the draft. So if there's any feedback, maybe also if people want to share it on the mail as well. I think this could be a thing and we could perhaps provide a short, updated panel tree just to check and yes, but I think more than that it would be difficult. We were also thinking to maybe organize some something into hackathons, so people could get their hands dirty but uh yeah.

C

A

C

A

That actually the way things are going in the the ietf now um you're, you might be more successful, attracting um security geeks to come and have a look at this by having a hackathon table, then by showing up at sag right, like so there's a lot more a lot more energy um over in the hackathon side of things. So I think that is like very good advice to yourself.

A

C

B

Yeah, brian, yes, I was not sure, but did I did you say what uh did you say that the penalty meeting is prob uh likely on friday in london? No.

A

It's likely not to be on friday, because.

B

A

Wait if I can make it to london, which is actually not certain right now, um then I have to leave on thursday and I wouldn't be able to attend remotely friday in any energy.

B

Okay, that's good to know because it's more from an organizational point of view. Yes, yes thanks.

A

Yeah, I will I we don't actually have the the um uh the request in yet. Actually one of the things I'm going to do, as I give everybody 30 minutes back, is take some of that time for myself to actually go make that happen, um and I will be you know I'll put the please please, please, please, please don't put due friday on there, because I would very much like to be able to go cherry.

A

Okay, any other business questions, comments, concerns.

A

Discussion about the existence of other research groups.

A

Okay, thank you all very much.

A

um Thanks to the presenters thanks to um uh thanks the participants, I will send the minutes out um as soon as I finish remembering what was said when I overran them um and we will see- um hopefully many or all of you in london thanks a lot. Everyone have a great day.

B

Bye-Bye thank you very much.

B