[00:00.000 --> 00:01.000]  Charles.
[00:01.000 --> 00:02.000]  Okay.
[00:02.000 --> 00:03.000]  Welcome.
[00:03.000 --> 00:04.000]  Thank you.
[00:04.000 --> 00:05.000]  Great.
[00:05.000 --> 00:06.000]  Thank you.
[00:06.000 --> 00:07.000]  We get some applause for Charles, please.
[00:07.000 --> 00:08.000]  Thanks for that.
[00:08.000 --> 00:10.000]  Thanks for being here around the lunch hour, too.
[00:10.000 --> 00:12.000]  I appreciate you're making a little extra sacrifice.
[00:12.000 --> 00:26.000]  And just thanks for being here as part of the community dev room, too, right?
[00:26.000 --> 00:28.000]  And contributing to the discussion here.
[00:28.000 --> 00:31.000]  First, AV question.
[00:31.000 --> 00:33.000]  Can you hear me okay?
[00:33.000 --> 00:35.000]  Is the audio all right?
[00:35.000 --> 00:36.000]  Okay, great.
[00:36.000 --> 00:37.000]  Okay.
[00:37.000 --> 00:39.000]  So, super excited to be here.
[00:39.000 --> 00:44.000]  And especially because I get to talk with all of you about two things that I'm extremely
[00:44.000 --> 00:45.000]  passionate about.
[00:45.000 --> 00:47.000]  The first one is open source.
[00:47.000 --> 00:53.000]  And since you're here in this room, I'm guessing there's a very good chance you share that
[00:53.000 --> 00:54.000]  passion with me.
[00:54.000 --> 00:56.000]  The second one is standards.
[00:56.000 --> 00:59.000]  I really enjoy working with standards.
[00:59.000 --> 01:01.000]  It's a big part of my job.
[01:01.000 --> 01:04.000]  I'm in the standards group at Cisco.
[01:04.000 --> 01:11.000]  Hopefully some of you are consider yourself a supporter of standards.
[01:11.000 --> 01:14.000]  But all right, we've got a few.
[01:14.000 --> 01:20.000]  And what I really want to talk with you about is what I think is an opportunity for the
[01:20.000 --> 01:25.000]  standards community and the open source communities to work a bit better together and to help
[01:25.000 --> 01:28.000]  other with navigating across those communities.
[01:28.000 --> 01:34.000]  Because it is very common for many people to really primarily associate themselves with
[01:34.000 --> 01:36.000]  one community or the other.
[01:36.000 --> 01:41.000]  So anything we can do to help the other community better understand what we're doing, how we're
[01:41.000 --> 01:46.000]  doing it, how to leverage the resources we have, I think is very helpful.
[01:46.000 --> 01:49.000]  And that's the subject of my talk.
[01:49.000 --> 01:54.000]  To cover that missing link, the linkage between all the great things we're doing in open
[01:54.000 --> 02:01.000]  source and the great things we're doing with standards to the benefit of both communities.
[02:01.000 --> 02:07.000]  So I was a little late watching this, but I imagine many of you saw Game of Thrones.
[02:07.000 --> 02:10.000]  Is this a familiar sort of image to you?
[02:10.000 --> 02:17.000]  Even if you didn't, the idea is on the left hand side, I guess to your left, yeah, you
[02:17.000 --> 02:18.000]  have John Snow.
[02:18.000 --> 02:22.000]  He's leading, he's kind of the lead of the people of the north.
[02:22.000 --> 02:27.000]  On the right, you have this big guy, Tormund Giant Spain.
[02:27.000 --> 02:33.000]  And he's kind of one of the leads of the wildlings that are even further north.
[02:33.000 --> 02:40.000]  And those two communities are separated first by a very large wall.
[02:40.000 --> 02:45.000]  And they really don't trust each other, they don't understand each other.
[02:45.000 --> 02:51.000]  However, during the course of the series, they come to understand each other a bit better
[02:51.000 --> 02:59.000]  and find really some common goals that they have in mind and to work together and to achieve
[02:59.000 --> 03:01.000]  some greater good.
[03:01.000 --> 03:07.000]  And I think there's some similarity there with open source and with standards where by working
[03:07.000 --> 03:12.000]  more closely with each other, we can really benefit each other.
[03:12.000 --> 03:15.000]  So first of all, why standards?
[03:15.000 --> 03:18.000]  Why do I think standards is important here?
[03:18.000 --> 03:26.000]  And I think for most industries, standards have really played a key role for many, many
[03:26.000 --> 03:27.000]  years.
[03:27.000 --> 03:35.000]  Large players in those industries, whether you're talking about telecom or networking
[03:35.000 --> 03:44.000]  or communications, it's mandatory to support a wide variety of standards in order to solve
[03:44.000 --> 03:50.000]  equipment or solutions to provide those into that market.
[03:50.000 --> 03:55.000]  And compliance with these standards is important for a number of reasons.
[03:55.000 --> 04:01.000]  And two of them that I want to call out is for interoperability so that when you have
[04:01.000 --> 04:05.000]  components from many different vendors, you can actually get them to work together.
[04:05.000 --> 04:10.000]  And also just to make sure that you never get stuck with a single vendor lock-in where,
[04:10.000 --> 04:15.000]  you know, once you start down a path, you can never use anything from anyone else
[04:15.000 --> 04:18.000]  without prohibitive cost or churn.
[04:18.000 --> 04:25.000]  And as a result of this importance of standards in those industries, fierce competitors come
[04:25.000 --> 04:30.000]  together and actually collaborate quite well on the standards because they have a vested
[04:30.000 --> 04:36.000]  interest in those standards in establishing them so that they can add support for them
[04:36.000 --> 04:41.000]  into their products. And it's also important for them to be able to interoperate because
[04:41.000 --> 04:46.000]  many times they'll be coming in that they have some product or some solution that they
[04:46.000 --> 04:50.000]  want to sell into an existing larger solution.
[04:50.000 --> 04:54.000]  And, you know, their stuff needs to work with their competitors.
[04:54.000 --> 05:02.000]  In order to enter into this new market, they can't get the person buying their stuff to,
[05:02.000 --> 05:06.000]  you know, start over from scratch, right? You need to insert yourself in sort of incrementally
[05:06.000 --> 05:11.000]  into it. And so interoperability is super important there to interop with not only your
[05:11.000 --> 05:14.000]  competitors but your partners.
[05:14.000 --> 05:18.000]  So, you know, that actually works quite well. However, there's definitely challenges with
[05:18.000 --> 05:24.000]  standards. And one of the main ones is it can take a long time.
[05:24.000 --> 05:30.000]  Just getting a standard from the time you start defining it in a community to the time it's
[05:30.000 --> 05:36.000]  actually a completed published standard oftentimes can take a few years.
[05:36.000 --> 05:40.000]  And then if you think that now once you have that standard, a lot of companies will wait
[05:40.000 --> 05:45.000]  until the standard actually exists before they go off and start implementing it.
[05:45.000 --> 05:49.000]  So that's going to take a little bit more time now to add support for it.
[05:49.000 --> 05:54.000]  And then you go and you take implementations from multiple different vendors and you try to
[05:54.000 --> 06:00.000]  use them together and the interoperability isn't there because, you know, these standards
[06:00.000 --> 06:04.000]  are complicated. There's some ambiguity in how you might interpret certain parts of it
[06:04.000 --> 06:09.000]  or which feature sets from them you support and how well.
[06:09.000 --> 06:14.000]  So it takes a bit longer to really get that interoperability that was the goal from the
[06:14.000 --> 06:20.000]  start. And sometimes that will even require going back and, you know, changing the standard.
[06:20.000 --> 06:25.000]  But in any case, no matter what, it tends to take quite a long time.
[06:25.000 --> 06:31.000]  And, you know, that becomes a challenge because you may not have your standard already and
[06:31.000 --> 06:37.000]  adopted and deployed in time for it to do the thing that you really needed it to do.
[06:37.000 --> 06:40.000]  You might kind of miss that window of opportunity.
[06:40.000 --> 06:46.000]  So with open source, I think we see a very, very different dynamic.
[06:46.000 --> 06:53.000]  We see open source fueling the transformation of industries very, very quickly in many cases.
[06:53.000 --> 06:59.000]  And a vast community of people like what we see here at FOSDEM comes together, you know,
[06:59.000 --> 07:07.000]  around some common goals and really can create fantastic software very quickly.
[07:07.000 --> 07:18.000]  And this rapid innovation is so, I mean, it's a very desirable thing.
[07:18.000 --> 07:23.000]  And so I think these industries that have mandated a really needed support for standards
[07:23.000 --> 07:28.000]  for many, many years, they're seeing open source as this great opportunity to speed things up.
[07:28.000 --> 07:32.000]  And so they're saying, well, you also need to support open source.
[07:32.000 --> 07:37.000]  You need to understand how to work with it because, you know, in my network or in my overall solution,
[07:37.000 --> 07:40.000]  I'm going to have equipment from a lot of different people.
[07:40.000 --> 07:43.000]  And some of that, I really think, needs to be open source.
[07:43.000 --> 07:47.000]  So how does your stuff work with these open source components?
[07:47.000 --> 07:53.000]  And sometimes that the open source can become so widely deployed that it actually will become
[07:53.000 --> 08:00.000]  sort of a de facto standard maybe before that standards group ever defined anything in that space,
[08:00.000 --> 08:04.000]  maybe before they were able to complete their work.
[08:04.000 --> 08:11.000]  So open source is really bringing some great things, but I think we would all agree there are some challenges.
[08:11.000 --> 08:17.000]  Open source projects, from the point of view of someone who's trying to build a solution,
[08:17.000 --> 08:21.000]  it's really just like, I think of it as a tool set, right?
[08:21.000 --> 08:26.000]  There's a lot of different projects out there, but none of them offer a complete solution.
[08:26.000 --> 08:29.000]  And so then what you need to be able to do is understand each of them,
[08:29.000 --> 08:31.000]  know how to put them together.
[08:31.000 --> 08:37.000]  And, you know, these are often open source projects that weren't designed, you know,
[08:37.000 --> 08:44.000]  the people working on them really didn't have working with these other projects in mind, right?
[08:44.000 --> 08:45.000]  They didn't design for that.
[08:45.000 --> 08:52.000]  They may not have documented it at all how to make it work with these other things.
[08:52.000 --> 08:55.000]  Or, you know, that documentation may not be great.
[08:55.000 --> 09:01.000]  The other thing is, I mean, in the open source community, it sort of has a mind of its own, right?
[09:01.000 --> 09:06.000]  So perhaps you want to use an open source project in a certain way,
[09:06.000 --> 09:13.000]  but if you're not actively contributing to it, it might move in a way that, you know,
[09:13.000 --> 09:15.000]  you weren't expecting or you weren't wanting.
[09:15.000 --> 09:21.000]  And so it may not ultimately meet, you know, the need that you had for your overall solution.
[09:21.000 --> 09:25.000]  And, you know, some projects just fade away, the community loses interest
[09:25.000 --> 09:29.000]  and starts spending their time on something else that looks even more interesting.
[09:29.000 --> 09:35.000]  So this challenge of integrating open source together with perhaps some other open source projects
[09:35.000 --> 09:41.000]  and maybe even some proprietary stuff, you know, that's a real challenge.
[09:41.000 --> 09:47.000]  So where I think there's a lot of potential benefit is by bringing some of these characteristics
[09:47.000 --> 09:51.000]  of standards and open source together.
[09:51.000 --> 09:56.000]  By those two communities working better together, you can really bring some of that,
[09:56.000 --> 10:02.000]  if you could bring some of that speed and collaborative spirit that we see with open source into standards,
[10:02.000 --> 10:09.000]  actually think about creating open source implementations of standards as they're being developed
[10:09.000 --> 10:12.000]  and then be able to feed that back into the standards
[10:12.000 --> 10:17.000]  and improve the quality of them early on, not after they've been published,
[10:17.000 --> 10:21.000]  and, you know, after several years, but actually very early in those,
[10:21.000 --> 10:24.000]  the first iterations of the standards.
[10:24.000 --> 10:32.000]  Then when you do have these standards, if you can add support for them into popular open source projects,
[10:32.000 --> 10:36.000]  then those projects suddenly become much more consumable by the industry
[10:36.000 --> 10:41.000]  that's built these big solutions around all these standards, right?
[10:41.000 --> 10:48.000]  Now all of a sudden, your open source project can interoperate in that larger environment
[10:48.000 --> 10:51.000]  because it does support these key standards.
[10:51.000 --> 10:55.000]  And then also, if you have some code that's being developed
[10:55.000 --> 10:59.000]  that implements, you know, either the complete or part of the standard,
[10:59.000 --> 11:04.000]  then when the standard is actually ready, it's going to be much, much faster to deploy it
[11:04.000 --> 11:08.000]  if you already have some running code, right, rather than having to start from scratch,
[11:08.000 --> 11:12.000]  implementing just what was written down on a sheet of paper.
[11:12.000 --> 11:17.000]  So I think you can really have time to, you can speed up the time for adoption
[11:17.000 --> 11:22.000]  by having that code available in parallel with the standard.
[11:22.000 --> 11:27.000]  So just one example where I think helps illustrate the opportunity here,
[11:27.000 --> 11:32.000]  this is a relatively, it's a little bit dated slide from the Lenox Foundation,
[11:32.000 --> 11:37.000]  but I think it demonstrates some of the points I'm trying to make quite well.
[11:37.000 --> 11:41.000]  This is looking at the network automation space.
[11:41.000 --> 11:45.000]  And on the left-hand side, you can see that there's a lot of open source projects
[11:45.000 --> 11:51.000]  just in the Lenox Foundation alone that play a role in this space.
[11:51.000 --> 11:57.000]  So it's kind of layered from, like the networking stack from top to bottom,
[11:57.000 --> 11:59.000]  or bottom to up, you can look at it either way.
[11:59.000 --> 12:01.000]  So you see the different open source projects,
[12:01.000 --> 12:04.000]  sometimes several of them playing at the same level of the stack
[12:04.000 --> 12:08.000]  because, you know, we allow multiple different projects
[12:08.000 --> 12:11.000]  that do some of the same things to coexist, right?
[12:11.000 --> 12:13.000]  I mean, that's very common in open source.
[12:13.000 --> 12:15.000]  So you have all these different projects,
[12:15.000 --> 12:19.000]  some of them you may look at and say, hey, that project doesn't even exist anymore.
[12:19.000 --> 12:22.000]  That's an example that I was saying of, you know, the projects,
[12:22.000 --> 12:24.000]  some of them actually fade away.
[12:24.000 --> 12:28.000]  So if you're trying to put together a solution
[12:28.000 --> 12:31.000]  that involves these different open source components,
[12:31.000 --> 12:34.000]  even if you're taking them all from the Lenox Foundation,
[12:34.000 --> 12:38.000]  you still have a fair amount of integration that you're going to need to be able to do.
[12:38.000 --> 12:45.000]  On the right-hand side, you see similarly going up and down the networking stack here,
[12:45.000 --> 12:50.000]  the standards groups that play a role in that space.
[12:50.000 --> 12:54.000]  And where I think there's the greatest opportunity for collaboration
[12:54.000 --> 12:57.000]  is going east-west across, right?
[12:57.000 --> 13:02.000]  So standards organizations like, for example, IETF,
[13:02.000 --> 13:08.000]  and playing at the same level as perhaps an FDIO or an OVS
[13:08.000 --> 13:11.000]  or even with Lenox,
[13:11.000 --> 13:16.000]  you start to see the opportunity for something that's being done in the standards area
[13:16.000 --> 13:21.000]  what needs to be implemented, probably is implemented in these open source projects.
[13:21.000 --> 13:28.000]  So to the point that you can make that interaction and collaboration
[13:28.000 --> 13:33.000]  across these communities better, you can really help both sides.
[13:33.000 --> 13:37.000]  So as an example where I think we're making some progress here,
[13:37.000 --> 13:39.000]  I mentioned the IETF just a minute ago,
[13:39.000 --> 13:43.000]  and that's one standard organization that I'm involved in.
[13:43.000 --> 13:46.000]  It's Internet Engineering Task Force,
[13:46.000 --> 13:53.000]  and it was created back in the mid-80s with the goal of making the Internet really,
[13:53.000 --> 13:57.000]  all the protocols on top of which the Internet's built.
[13:57.000 --> 14:01.000]  And now today, the goal remains to make the Internet better
[14:01.000 --> 14:05.000]  and over time to refine and add new protocols that are needed.
[14:05.000 --> 14:10.000]  So household names like TCPIP, DNS, DHCP,
[14:10.000 --> 14:14.000]  these things that we all end up using every day,
[14:14.000 --> 14:18.000]  those all came out of IETF.
[14:18.000 --> 14:22.000]  And I think IETF is a kind of good example here
[14:22.000 --> 14:26.000]  and that IETF even behaves a little bit, if you're not familiar with it,
[14:26.000 --> 14:29.000]  it behaves a little bit more closely to an open source community
[14:29.000 --> 14:33.000]  and that when you go there, you participate as an individual.
[14:33.000 --> 14:35.000]  There's no company affiliation.
[14:35.000 --> 14:38.000]  It's free to participate.
[14:38.000 --> 14:42.000]  Anyone can do that, much like you often see with open source.
[14:42.000 --> 14:46.000]  And this quote on the right-hand side, I think helps pull that out.
[14:46.000 --> 14:49.000]  You see, you know, we reject Kings, presidents, voting.
[14:49.000 --> 14:52.000]  We believe in rough consensus and running code.
[14:52.000 --> 14:56.000]  And that idea of running code was really important to the IETF early on.
[14:56.000 --> 15:01.000]  I think maybe there was a drifting away from that over time.
[15:01.000 --> 15:07.000]  And I see there being a lot of potential in getting back to that idea of running code,
[15:07.000 --> 15:13.000]  sorry, that's related to standards.
[15:13.000 --> 15:19.000]  So one thing that the IETF did, I think as a realization
[15:19.000 --> 15:24.000]  that its processes and ways of working need to change
[15:24.000 --> 15:27.000]  and to try to make it a little bit easier for developers
[15:27.000 --> 15:29.000]  and the open source community to get involved
[15:29.000 --> 15:33.000]  is just taking a look at the way that standards are actually written
[15:33.000 --> 15:38.000]  and developed over time and how consensus is built around them.
[15:38.000 --> 15:42.000]  Traditionally, it's been done using a pretty arcane set of tools
[15:42.000 --> 15:45.000]  that have been built in the IETF over time.
[15:45.000 --> 15:48.000]  And if you've been working in the IETF for a long time,
[15:48.000 --> 15:52.000]  you're probably pretty comfortable with writing your drafts in XML
[15:52.000 --> 15:56.000]  and then converting them into this RFC format.
[15:56.000 --> 16:00.000]  But if you're not, that's kind of a barrier to entry.
[16:00.000 --> 16:03.000]  And so there was actually a working group defined to say,
[16:03.000 --> 16:08.000]  hey, how can we make our processes work a bit better
[16:08.000 --> 16:11.000]  to meet developers, to make it more developer friendly?
[16:11.000 --> 16:17.000]  And so this GitHub integration and tooling, what it did,
[16:17.000 --> 16:22.000]  was to find a way that IETF drafts could be posted
[16:22.000 --> 16:25.000]  and worked on in a GitHub repo.
[16:25.000 --> 16:28.000]  And instead of using XML and having to translate,
[16:28.000 --> 16:30.000]  it could be written and marked down,
[16:30.000 --> 16:34.000]  something that many developers are pretty familiar with
[16:34.000 --> 16:36.000]  just from writing their own readme's.
[16:36.000 --> 16:42.000]  And so now the drafts, although they're still just really text,
[16:42.000 --> 16:44.000]  but they're stored in GitHub
[16:44.000 --> 16:46.000]  and you have the version control around them
[16:46.000 --> 16:48.000]  and you can do pull requests and all that.
[16:48.000 --> 16:52.000]  So really, it's really meeting developers where they are,
[16:52.000 --> 16:54.000]  making it easier, more comfortable,
[16:54.000 --> 16:56.000]  straightforward for them to contribute
[16:56.000 --> 17:01.000]  by using things that the developers are already pretty familiar with.
[17:01.000 --> 17:03.000]  And you can see if, maybe a little small,
[17:03.000 --> 17:05.000]  but when you're looking at, I'm showing you
[17:05.000 --> 17:09.000]  what the working group page for the draft,
[17:09.000 --> 17:11.000]  there's a section called Additional Resources.
[17:11.000 --> 17:15.000]  And what this takes you here was a newly defined additional resource,
[17:15.000 --> 17:17.000]  which is the GitHub repo,
[17:17.000 --> 17:22.000]  what the draft that people are collaborating on is stored.
[17:22.000 --> 17:25.000]  Another thing that's been done,
[17:25.000 --> 17:27.000]  and this is where I've spent a lot of time,
[17:27.000 --> 17:29.000]  is in running the IETF hackathons.
[17:29.000 --> 17:32.000]  And the idea there is to do exactly that thing
[17:32.000 --> 17:36.000]  that I mentioned earlier of speeding up the pace
[17:36.000 --> 17:38.000]  and relevance of IETF standards
[17:38.000 --> 17:41.000]  by implementing them in parallel with defining them
[17:41.000 --> 17:44.000]  and taking the things that you learn from implementing them
[17:44.000 --> 17:49.000]  and working them back into future iterations of the draft.
[17:49.000 --> 17:54.000]  So I think that way you end up with a higher quality standard
[17:54.000 --> 17:56.000]  in a shorter amount of time.
[17:56.000 --> 17:59.000]  But another goal is to, again, attract developers
[17:59.000 --> 18:03.000]  and kind of new participants from, say, universities,
[18:03.000 --> 18:06.000]  younger people in general into the IETF
[18:06.000 --> 18:10.000]  by creating an environment that's a little bit more interesting,
[18:10.000 --> 18:11.000]  perhaps, to contribute.
[18:11.000 --> 18:14.000]  Rather than reviewing drafts and commenting on them
[18:14.000 --> 18:16.000]  on mailing lists or something like that,
[18:16.000 --> 18:20.000]  you can actually use tools and techniques and code
[18:20.000 --> 18:22.000]  and contribute in that way too
[18:22.000 --> 18:25.000]  and point out where maybe there's a problem in the standard
[18:25.000 --> 18:28.000]  or a better way to do it by actually implementing it
[18:28.000 --> 18:32.000]  and using that to help build your feedback.
[18:32.000 --> 18:35.000]  And these are free and open to everyone
[18:35.000 --> 18:37.000]  and very collaborative.
[18:37.000 --> 18:39.000]  Some hackathons are competitive,
[18:39.000 --> 18:42.000]  but this is really about learning, moving things forward
[18:42.000 --> 18:45.000]  and improving all standards that the IETF works on.
[18:45.000 --> 18:47.000]  So it's non-competitive.
[18:47.000 --> 18:50.000]  And on the right-hand side, I just have a chart.
[18:50.000 --> 18:54.000]  You can see we ran the first one, I think, back in 2015
[18:54.000 --> 18:56.000]  and attracted about 45 people,
[18:56.000 --> 18:59.000]  and I thought that was quite successful.
[18:59.000 --> 19:01.000]  Then a couple of years later,
[19:01.000 --> 19:04.000]  after having these at every IETF meeting,
[19:04.000 --> 19:08.000]  it's now common to have three to 400 people at one of these.
[19:08.000 --> 19:10.000]  And if you think of an entire IETF meeting
[19:10.000 --> 19:12.000]  being about 1,000 people,
[19:12.000 --> 19:15.000]  that's 30 or 40% of the people are coming
[19:15.000 --> 19:17.000]  and actually spending the weekend before it
[19:17.000 --> 19:20.000]  to work on code together,
[19:20.000 --> 19:23.000]  which I think has had a huge impact on the IETF.
[19:26.000 --> 19:28.000]  So another thing we did then,
[19:28.000 --> 19:30.000]  as a result of these hackathons,
[19:30.000 --> 19:32.000]  was, well, let's create a GitHub org
[19:32.000 --> 19:35.000]  and we can store the projects that we work on in the hackathon
[19:35.000 --> 19:37.000]  and we can store them there.
[19:37.000 --> 19:40.000]  So in case the project wasn't already hosted somewhere else,
[19:40.000 --> 19:44.000]  oftentimes we'll put the project in this GitHub org.
[19:44.000 --> 19:47.000]  And that makes it a little bit easier then
[19:47.000 --> 19:49.000]  to find code related to standards
[19:49.000 --> 19:51.000]  because you can go look in this GitHub org.
[19:51.000 --> 19:55.000]  So at least you find some code that's related to standards.
[19:55.000 --> 19:57.000]  You can find it there.
[19:57.000 --> 19:59.000]  So that helps out a bit too.
[19:59.000 --> 20:01.000]  Another thing we've done is,
[20:01.000 --> 20:03.000]  if you look at, we always have a wiki
[20:03.000 --> 20:06.000]  that lists the various projects for an IETF hackathon.
[20:06.000 --> 20:10.000]  And this is a good example where they've done an important thing
[20:10.000 --> 20:13.000]  where you can see the key IETF drafts
[20:13.000 --> 20:15.000]  that the project is working on.
[20:15.000 --> 20:16.000]  There's links to them.
[20:16.000 --> 20:18.000]  You may not be able to read them well,
[20:18.000 --> 20:20.000]  but if you can download the slides, I've uploaded them.
[20:20.000 --> 20:22.000]  And you can see those.
[20:22.000 --> 20:27.000]  And then down below, it's talking about where the code is
[20:27.000 --> 20:28.000]  that they're writing.
[20:28.000 --> 20:30.000]  And in this case, it's a GitHub repo.
[20:30.000 --> 20:32.000]  They're working on VPP.
[20:32.000 --> 20:38.000]  It's a network processing open source project.
[20:38.000 --> 20:42.000]  And they're implementing these drafts in VPP,
[20:42.000 --> 20:46.000]  which is a great example of the type of thing we want to have see.
[20:46.000 --> 20:48.000]  So right here in their project description,
[20:48.000 --> 20:50.000]  they're showing you the drafts and the code,
[20:50.000 --> 20:55.000]  which is a nice way of linking those things together.
[20:55.000 --> 20:57.000]  So we made progress,
[20:57.000 --> 21:03.000]  but it's not all rainbows and unicorns yet by any means.
[21:03.000 --> 21:09.000]  And so I think we're just scratching the surface here
[21:09.000 --> 21:11.000]  with what we can do.
[21:11.000 --> 21:16.000]  I go back and I show you this GitHub org that we have.
[21:16.000 --> 21:19.000]  There's maybe 20 projects there.
[21:19.000 --> 21:24.000]  It's probably 1% of the code that is related to standards
[21:24.000 --> 21:27.000]  that exist in the open source world.
[21:27.000 --> 21:31.000]  So you can get a little bit of code that way,
[21:31.000 --> 21:34.000]  but it's really just a few things.
[21:34.000 --> 21:40.000]  And this wiki, the problem with this is if you look closely,
[21:40.000 --> 21:44.000]  you'll see that one of the draft names has even changed over time.
[21:44.000 --> 21:46.000]  So they're not maintained.
[21:46.000 --> 21:50.000]  People use them extensively in the lead-up to the hackathon,
[21:50.000 --> 21:53.000]  during the hackathon, and for maybe a week or so after.
[21:53.000 --> 21:56.000]  But they're not maintained.
[21:56.000 --> 22:00.000]  This isn't really a good way to, over time,
[22:00.000 --> 22:03.000]  find the linkage between code and drafts.
[22:03.000 --> 22:09.000]  So I think there's definitely things that we need to do to improve.
[22:09.000 --> 22:14.000]  So what I did was, for those of you who work in the ITF,
[22:14.000 --> 22:17.000]  if you want to improve something, what do you do?
[22:17.000 --> 22:18.000]  You write a draft.
[22:18.000 --> 22:22.000]  So I wrote a draft about more systematically going
[22:22.000 --> 22:28.000]  and creating this linkage between ITF drafts
[22:28.000 --> 22:31.000]  and code that's related to them.
[22:31.000 --> 22:34.000]  And to set up a process that you could think of becoming
[22:34.000 --> 22:36.000]  a standard way of doing this.
[22:36.000 --> 22:40.000]  And so that everyone keeps this in mind
[22:40.000 --> 22:42.000]  when they're writing their drafts
[22:42.000 --> 22:44.000]  and to point out where to find the code.
[22:44.000 --> 22:48.000]  So earlier I showed this additional information
[22:48.000 --> 22:51.000]  that you could have point to a GitHub repo.
[22:51.000 --> 22:56.000]  What we've done now is we added another type of additional resource,
[22:56.000 --> 22:58.000]  and that's a related implementation.
[22:58.000 --> 23:03.000]  And so now what you can do is when you're writing your Internet draft,
[23:03.000 --> 23:07.000]  you have an idea, you can point to relevant code,
[23:07.000 --> 23:12.000]  whether it's an implementation of, say, the protocol you're defining.
[23:12.000 --> 23:17.000]  Perhaps it's a tool that helps you sniff that protocol
[23:17.000 --> 23:21.000]  when it appears on the network, right, to sniff it on the wire.
[23:21.000 --> 23:27.000]  So anything that's going to help with implementing, supporting, deploying,
[23:27.000 --> 23:31.000]  maintaining, operating the standards that you're defining,
[23:31.000 --> 23:33.000]  you can point to them here.
[23:33.000 --> 23:38.000]  And all you need to do is you can go and you can edit those resources
[23:38.000 --> 23:41.000]  and maybe, again, a little hard to see,
[23:41.000 --> 23:45.000]  but the first one is pointing to the GitHub repo where the draft is stored,
[23:45.000 --> 23:48.000]  and the second one is pointing to a related implementation,
[23:48.000 --> 23:53.000]  where, in this case, because it's a sort of a process document,
[23:53.000 --> 23:57.000]  the related implementation is actually pointing to another RFC,
[23:57.000 --> 23:59.000]  which is about how to run the hackathon.
[23:59.000 --> 24:04.000]  So maybe not the greatest example, but I wanted to show how you use this.
[24:04.000 --> 24:07.000]  Now, applying it to a more real-world example,
[24:07.000 --> 24:10.000]  I'm going back to that hackathon project I showed you before
[24:10.000 --> 24:14.000]  that has the links to the Internet draft,
[24:14.000 --> 24:17.000]  and then it's pointing to a GitHub repo.
[24:17.000 --> 24:23.000]  So you can see here, I'm looking at the draft here that's highlighted in red,
[24:23.000 --> 24:30.000]  this one on draft IETF, OpsAWG, IPfix, SRV6,
[24:30.000 --> 24:35.000]  and if I go look at it in the IETF data tracker,
[24:35.000 --> 24:40.000]  I can see there's related implementations defined for it down there at the bottom,
[24:40.000 --> 24:45.000]  and if I click on that, it'll actually take me to that GitHub repo.
[24:45.000 --> 24:50.000]  So now I'm not relying on the Wiki anymore and something that's not being maintained.
[24:50.000 --> 24:54.000]  Now, actually, I'm putting the linkage between the code and the draft
[24:54.000 --> 24:59.000]  right in the tooling that's used to work on the IETF draft.
[24:59.000 --> 25:04.000]  So in this way, it's a much more stable, easier to find reference for everyone,
[25:04.000 --> 25:08.000]  whether they knew about the IETF hackathons or not.
[25:08.000 --> 25:15.000]  And so I think that's the type of thing that it's starting to gain traction in the IETF,
[25:15.000 --> 25:20.000]  and I'm trying to get it to be much more common,
[25:20.000 --> 25:23.000]  and perhaps even there's better ways to do it,
[25:23.000 --> 25:26.000]  so people can also comment on the draft that I showed before
[25:26.000 --> 25:31.000]  if they have a better idea of how to do it.
[25:31.000 --> 25:37.000]  So I guess my ask to all of you is I hope that you see some value
[25:37.000 --> 25:41.000]  in creating this linkage between open source and standards,
[25:41.000 --> 25:46.000]  but you can help do your part to create that linkage.
[25:46.000 --> 25:50.000]  So if you're working for me or others in the standards community,
[25:50.000 --> 25:55.000]  if you're working on internet standards and you happen to know of some open source code,
[25:55.000 --> 25:59.000]  create that linkage, show people where there's code related to the standards.
[25:59.000 --> 26:02.000]  Perhaps you're working on an open source project, though,
[26:02.000 --> 26:05.000]  and you know that project very well,
[26:05.000 --> 26:08.000]  and you know you've implemented some key standards in it.
[26:08.000 --> 26:11.000]  So make sure that that's well documented in your readmeer
[26:11.000 --> 26:15.000]  or easy for someone who's not familiar with your project to see
[26:15.000 --> 26:18.000]  that, oh yes, you do support these standards,
[26:18.000 --> 26:23.000]  because that might hopefully make your open source project much more valuable
[26:23.000 --> 26:28.000]  and easier for them to consume and to use for their purposes.
[26:28.000 --> 26:34.000]  So by making this linkage easier for people to find and use,
[26:34.000 --> 26:39.000]  I think we can make standards much more consumable by developers
[26:39.000 --> 26:45.000]  and the other way around, the open source community and the things that we build there
[26:45.000 --> 26:50.000]  become much more consumable by these industries that have relied on standards
[26:50.000 --> 26:53.000]  for a number of years.
[26:53.000 --> 26:56.000]  So with that I thank you for your time.
[26:56.000 --> 26:59.000]  I maybe have a couple minutes for questions still.
[26:59.000 --> 27:01.000]  You absolutely have a couple minutes for questions.
[27:01.000 --> 27:03.000]  Excellent, I'm on my way.
[27:03.000 --> 27:07.000]  And I'd also love feedback on the IETF draft.
[27:07.000 --> 27:11.000]  If any of you are like, hey, I want to provide comments on an IETF draft,
[27:11.000 --> 27:13.000]  I've never done that before.
[27:13.000 --> 27:16.000]  This is a good opportunity.
[27:16.000 --> 27:18.000]  Thanks for this pitch.
[27:18.000 --> 27:20.000]  It was really enlightening.
[27:20.000 --> 27:26.000]  I think there's really a link between open source and standard.
[27:26.000 --> 27:29.000]  So my question is, in one of your previous pictures,
[27:29.000 --> 27:35.000]  you were showing like standardizing organization and open source.
[27:35.000 --> 27:46.000]  And I've seen that there was like the image of open config on the open source.
[27:46.000 --> 27:48.000]  Let's see, not this one, right?
[27:48.000 --> 27:50.000]  No, I think I know.
[27:50.000 --> 27:52.000]  One of the initial slides you were showing.
[27:52.000 --> 27:54.000]  This one maybe.
[27:54.000 --> 28:01.000]  Yeah, so I recently had to develop something related to the open config group, right?
[28:01.000 --> 28:05.000]  And somehow they are also defining a standard.
[28:05.000 --> 28:07.000]  So what do you think about this?
[28:07.000 --> 28:12.000]  Yeah, that's a good question.
[28:12.000 --> 28:19.000]  So that's an example of sort of a community
[28:19.000 --> 28:23.000]  that's not traditionally maybe considered a standard group.
[28:23.000 --> 28:26.000]  But they're defining their own standards within it.
[28:26.000 --> 28:30.000]  And it has been a little bit of a challenge, I'd say, historically,
[28:30.000 --> 28:34.000]  because you had some standards being defined in IETF
[28:34.000 --> 28:40.000]  and kind of alternative standards rather than being argued within the IETF
[28:40.000 --> 28:42.000]  and used to influence IETF standards.
[28:42.000 --> 28:46.000]  It's kind of standards in a similar space,
[28:46.000 --> 28:51.000]  but being done by another organization now, by open config.
[28:51.000 --> 28:58.000]  And so I guess in some ways it's similar to having multiple open source projects
[28:58.000 --> 29:00.000]  that are trying to do the same thing.
[29:00.000 --> 29:08.000]  So I'd say the one thing is, as long as the open config is open to community consensus
[29:08.000 --> 29:13.000]  and taking input, then ideally we'd have one set of standards,
[29:13.000 --> 29:17.000]  but if we have two and they have different communities working behind them,
[29:17.000 --> 29:20.000]  perhaps they each meet a separate need.
[29:20.000 --> 29:22.000]  So it's not necessarily a bad thing.
[29:22.000 --> 29:28.000]  The important thing is that both communities are very open to input from their members,
[29:28.000 --> 29:31.000]  and hopefully they collaborate a bit where they can.
[29:31.000 --> 29:33.000]  So you don't see anything against this?
[29:33.000 --> 29:41.000]  I'd say it's not ideal, similar to competing open source projects existing,
[29:41.000 --> 29:44.000]  but you can't always force everyone.
[29:44.000 --> 29:46.000]  That's kind of the beauty, I guess, of open source,
[29:46.000 --> 29:49.000]  is you can go off and explore different things.
[29:49.000 --> 29:51.000]  And that's kind of what's happened here.
[29:51.000 --> 29:54.000]  It's like a fork, almost.
[29:54.000 --> 29:57.000]  And whether they come back together at some point,
[29:57.000 --> 30:02.000]  I don't know, probably not at this point, but who knows?
[30:02.000 --> 30:07.000]  Okay, so we have time for one more question, and I see one hand.
[30:07.000 --> 30:12.000]  Great when it works out that way.
[30:12.000 --> 30:20.000]  Yes, thank you for the talk, for these implementations linked to a specification.
[30:20.000 --> 30:27.000]  Would you preferably distinguish between an implementation and, let's say, a reference implementation?
[30:27.000 --> 30:30.000]  Yeah, great point.
[30:30.000 --> 30:34.000]  That's actually one of the challenges we had in the IHF too,
[30:34.000 --> 30:41.000]  that people thought, I guess one of the concerns was perhaps pointing to some code
[30:41.000 --> 30:46.000]  that is, you know, it's just a little bit of a science project,
[30:46.000 --> 30:49.000]  or a quick demo, maybe even at one of these hackathons,
[30:49.000 --> 30:52.000]  as opposed to something that is a full-fledged,
[30:52.000 --> 30:57.000]  hey, I can go off and use this in my mission-critical software.
[30:57.000 --> 31:00.000]  So I think the important thing there is in the README.
[31:00.000 --> 31:03.000]  It hasn't really come up with a better solution than that,
[31:03.000 --> 31:06.000]  than to say, hey, document what this is.
[31:06.000 --> 31:08.000]  Are you just getting going?
[31:08.000 --> 31:10.000]  Is this a proof of concept?
[31:10.000 --> 31:13.000]  Is this something that you want people to contribute to,
[31:13.000 --> 31:16.000]  to make sure you have your contributing file there?
[31:16.000 --> 31:22.000]  So it's kind of just letting people know through the README, I think, is the best way to go.
[31:22.000 --> 31:24.000]  Thank you so much, Charles. Very much appreciated.
[31:24.000 --> 31:40.000]  Thank you.