Subject: [hackathon] Open Source Software and network protocol standards

From: Stuart Cheshire <[email-masked]>
Date: Sat, 19 Mar 2022 00:47:13 +0100

Dear Hackathon crew!

I have a question about the relationship between Open Source Software and network protocol standards.

My intuition is that in recent years Open Source Software has had a significant impact on network protocol standards, both in the availability of easily accessible open implementations contributing to the success of network protocol standards, and, in contrast, the lack of easily accessible open implementations contributing to less success for those network protocol standards.

I suspect that many in the IETF Hackathon community share this intuition, but it would be interesting to back up that intuition with concrete data.

I’d like to build a list of compelling examples.

Can you think of cases where an Open Source Software implementation clearly helped a networking protocol become successful? Was that Open Source implementation driven by the people (or companies) actively working on the protocol standard? Or was it created by an independent community following the standards development process?

Are there cases of a networking protocol that did not become successful where, in retrospect, it seems clear that the availability of an easily accessible Open Source implementation would have helped?

And, of course, counterexamples are also interesting: recent protocols that failed despite having a robust Open Source implementation, or recent protocols that succeeded despite having no Open Source implementation.

I am not the first person to think about the growing influence of Open Source on protocol development. Indeed, the existence of the IETF Hackathon itself is, in part, an acknowledgment of this new direction in protocol development. And others have written about it in the past:

2015: <https://www.ietfjournal.org/open-standards-open-source-open-loop/>
2016: <https://datatracker.ietf.org/doc/html/draft-arkko-ietf-trends-and-observations-00>
2018: <https://www.ietfjournal.org/three-years-on-open-standards-open-source-open-loop/>

Looking back now, in 2022, how have those earlier predictions played out? Do we have clear winners we can point to? Clear losers? This will help inform companies how they might want to engage with Open Source. Should companies embrace Open Source for protocol development? Or should companies go back to the old way, with open specifications and private implementations?

Please reply on the list or to me privately, and I will compile a list of responses.

Stuart Cheshire

---

From: Chris Inacio <[email-masked]>
Date: Sat, 19 Mar 2022 00:32:02 +0000

-----Original Message-----
From: Stuart Cheshire <cheshire=[email-masked]>
Date: March 18, 2022 at 7:47:38 PM
To: [email-masked] <[email-masked]>
Subject:  [hackathon] Open Source Software and network protocol standards

> My intuition is that in recent years Open Source Software has had a significant impact  
> on network protocol standards, both in the availability of easily accessible open implementations  
> contributing to the success of network protocol standards, and, in contrast, the lack  
> of easily accessible open implementations contributing to less success for those network  
> protocol standards.
>  
> I suspect that many in the IETF Hackathon community share this intuition, but it would  
> be interesting to back up that intuition with concrete data.
>  
> Can you think of cases where an Open Source Software implementation clearly helped a  
> networking protocol become successful? Was that Open Source implementation driven  
> by the people (or companies) actively working on the protocol standard? Or was it created  
> by an independent community following the standards development process?
>  
> Are there cases of a networking protocol that did not become successful where, in retrospect,  
> it seems clear that the availability of an easily accessible Open Source implementation  
> would have helped?
>  
> And, of course, counterexamples are also interesting: recent protocols that failed  
> despite having a robust Open Source implementation, or recent protocols that succeeded  
> despite having no Open Source implementation.
>  
> I am not the first person to think about the growing influence of Open Source on protocol  
> development. Indeed, the existence of the IETF Hackathon itself is, in part, an acknowledgment  
> of this new direction in protocol development. And others have written about it in the  
> past:
>  
> 2015:  
> 2016:  
> 2018:  
>  
> Looking back now, in 2022, how have those earlier predictions played out? Do we have clear  
> winners we can point to? Clear losers? This will help inform companies how they might  
> want to engage with Open Source. Should companies embrace Open Source for protocol development?  
> Or should companies go back to the old way, with open specifications and private implementations?  
>  
> _______________________________________________
> hackathon mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hackathon
> Unsubscribe: mailto:[email-masked]?subject=unsubscribe
>  

Stuart,

Not that this necessarily changes an answer I have, but how far back would you like to go, roughly?

Mostly reacting to your “recent years” start of the question.

--
Chris Inacio
[email-masked]

---

From: Lars Eggert <[email-masked]>
Date: Sat, 19 Mar 2022 15:03:05 +0100

Hi,

> Can you think of cases where an Open Source Software implementation clearly helped a networking protocol become successful? Was that Open Source implementation driven by the people (or companies) a…

QUIC qualifies, I think. Almost all the implementations (including the initial Google-proprietary version) are open source, and for the IETF version, implementations and standardization were tightly coupled. We did combined WG interims plus interop events six times a year for several years.

Thanks,
Lars

---

From: Sean DuBois <[email-masked]>
Date: Sat, 19 Mar 2022 14:57:37 -0400

> QUIC qualifies, I think. Almost all the implementations (including the initial Google-proprietary version) are open source, and for the IETF version, implementations and standardization were tightl…

WebRTC

As a WebRTC user in ~2013 it was only useful because of Open Source
SFUs. Building your own SFU wasn't something smaller companies could do.

janus[0] and mediasoup[1] are good examples. The authors were
independent and involved with standards.

[0] https://github.com/meetecho/janus-gateway
[1] https://github.com/versatica/mediasoup

---

From: Randy Bush <[email-masked]>
Date: Sat, 19 Mar 2022 12:35:52 -0700

the rpki and rpki-based protocols and implementations.  though,
similarly to quic, a lot was done before being brought into the sausage
machine.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 20 Mar 2022 08:58:03 +1300

> QUIC qualifies, I think. Almost all the implementations (including the initial Google-proprietary version) are open source, and for the IETF version, implementations and standardization were tightl…

I don't remember, if I ever knew, the historical sequence that led to the original BSD license, but didn't an early BSD Unix release include a small package called TCP/IP? At least by 1988, when worldwide growth of TCP/IP really took off, it carried a primitive form of the BSD license.

Another well known case is the public domain release of the original HTTP code in April 1993. That code probably didn't survive long but its release with no strings attached was very significant. See https://cds.cern.ch/record/1164399?ln=en

    Brian

---

From: "MORTON JR., AL" <[email-masked]>
Date: Sat, 19 Mar 2022 20:30:57 +0000

> From: hackathon <[email-masked]> On Behalf Of Brian E Carpenter
> Sent: Saturday, March 19, 2022 3:58 PM
> To: [email-masked]
> Subject: Re: [hackathon] Open Source Software and network protocol standards
> 
> >> Can you think of cases where an Open Source Software implementation clearly
> helped a networking protocol become successful? Was that Open Source
> implementation driven by the people (or companies) actively working on the
> protocol standard? Or was it created by an independent community following the
> standards development process?
> >
> > QUIC qualifies, I think. Almost all the implementations (including the
> initial Google-proprietary version) are open source, and for the IETF version,
> implementations and standardization were tightly coupled. We did combined WG
> interims plus interop events six times a year for several years.
> 
> I don't remember, if I ever knew, the historical sequence that led to the
> original BSD license, but didn't an early BSD Unix release include a small
> package called TCP/IP? At least by 1988, when worldwide growth of TCP/IP
> really took off, it carried a primitive form of the BSD license.
> 
> Another well known case is the public domain release of the original HTTP code
> in April 1993. That code probably didn't survive long but its release with no
> strings attached was very significant. See
> https://urldefense.com/v3/__https://cds.cern.ch/record/1164399?ln=en__;!!BhdT!
> moHma6ShHkDJOSshEb6hQ9QlK6MinUv8JJKPoWmSLGKPRxC0CAtVczs7P-Hf1p6G2KWTsL14hK2Z1-
> SrAPQMmQ8$
> 
>     Brian
> 
[acm] 
an example from the past is NTP.  When the NTP WG started-up again in ~2005*, quite a bit of the history was shared and it seemed that the Dave Mill's running code was the success factor (RFC 1305). There were very few other implementations, if any in 2005. The new NTP wg's goal was to bring the specification up-to-date with the current code (NTP v4). Anyone still working in timing distribution might want to tweak the above for accuracy.

* I believe someone hired a car to bring Dave to the wg-forming BoF meeting, a really nice gesture and the only time I met Dave in-person.

Al

---

From: Bob Hinden <[email-masked]>
Date: Sat, 19 Mar 2022 13:39:47 -0700

Stuart,

> On Mar 18, 2022, at 4:47 PM, Stuart Cheshire <cheshire=[email-masked]> wrote:
> 

The Kame project as part of the WIDE project developed open source projects for IPv6, IPsec, and Mobile IPv6 for BSD variants.  See:

https://www.kame.net

These were used as the basis of many IPv6 implementations.

Bob

---

From: Stuart Cheshire <[email-masked]>
Date: Sat, 19 Mar 2022 21:59:31 +0100

> Mostly reacting to your “recent years” start of the question.

Good point Chris. Let’s remove the “recent” caveat. Examples others have given, like TCP/IP and HTTP, are very relevant data points too.

Stuart Cheshire

---

From: Omer Shapira <[email-masked]>
Date: Sat, 19 Mar 2022 14:34:40 -0700

Stuart,

Apache Kafka comes to mind as an example of Open-Source protocol which had displaced many closed-source alternatives. 

Another example is the adoption of BLE (Bluetooth Low Energy) for biometric sensors (e.g. heart rate monitors). BLE has Open-Source implementations and is steadily displacing proprietary protocols such as Garmin ANT.

Other than that, the evolution of peer-to-peer file sharing protocols can be relevant:
Closed-source protocols such as Kazaa or eD2k gained initial popularity in the early 2000s but failed eventually.

On the other hand, Bit Torrent remained relevant for more than 30 years. As you probably know, the LEDBAT CCA has originated from Bit Torrent.

Omer

> On Mar 19, 2022, at 1:59 PM, Stuart Cheshire <cheshire=[email-masked]> wrote:
>

---

From: guest271314 <[email-masked]>
Date: Sat, 19 Mar 2022 14:48:58 -0700

IPFS appears to meet the criteria.

InterPlanetary File System:
https://en.wikipedia.org/wiki/InterPlanetary_File_System#Creators[relevant?]

According to its website and that of the World Economic Forum, Protocol
> Labs is "an open-source research, development, and deployment laboratory
> for blockchain technology" that "creates software systems that tackle
> significant challenges" and whose goal is to "make human existence orders
> of magnitude better through technology."

IPFS - Content Addressed, Versioned, P2P File System (DRAFT 3):
https://github.com/ipfs/papers/raw/master/ipfs-cap2pfs/ipfs-p2p-file-system.pdf

I think Open Source Software development and specification is superior to
in-house, private development due to Kurt Godel's Incompleteness Theorem
https://en.wikipedia.org/wiki/Kurt_G%C3%B6del#Incompleteness_Theorem

1. If a (logical or axiomatic formal) system is [omega] consistent, it
cannot be [syntactically] complete.
2. The consistency of axioms cannot be proved within their own system.

Even the smartest people in the world, when confined in their own
laboratories or small or even large groups or organizations, cannot
conceive of every potential use case, test and verify or prove their own
claims. External testing and verification of claims is necessary to prove
the claims are true and correct, which is not really possible when the
source code is private. In fact, organizations might go so far as to ban
external entities from contributing to development or filing bugs, which
further limits the potential to find or fix bugs in the implementation or
specification.

Kind regards,
/guest271314/

On Fri, Mar 18, 2022 at 4:48 PM Stuart Cheshire <cheshire=
[email-masked]> wrote:

> My intuition is that in recent years Open Source Software has had a
> significant impact on network protocol standards, both in the availability
> of easily accessible open implementations contributing to the success of
> network protocol standards, and, in contrast, the lack of easily accessible
> open implementations contributing to less success for those network
> protocol standards.
>
> I suspect that many in the IETF Hackathon community share this intuition,
> but it would be interesting to back up that intuition with concrete data.
>
> Can you think of cases where an Open Source Software implementation
> clearly helped a networking protocol become successful? Was that Open
> Source implementation driven by the people (or companies) actively working
> on the protocol standard? Or was it created by an independent community
> following the standards development process?
>
> Are there cases of a networking protocol that did not become successful
> where, in retrospect, it seems clear that the availability of an easily
> accessible Open Source implementation would have helped?
>
> And, of course, counterexamples are also interesting: recent protocols
> that failed despite having a robust Open Source implementation, or recent
> protocols that succeeded despite having no Open Source implementation.
>
> I am not the first person to think about the growing influence of Open
> Source on protocol development. Indeed, the existence of the IETF Hackathon
> itself is, in part, an acknowledgment of this new direction in protocol
> development. And others have written about it in the past:
>
> 2016: <
> https://datatracker.ietf.org/doc/html/draft-arkko-ietf-trends-and-observations-00
> >
> 2018: <
> https://www.ietfjournal.org/three-years-on-open-standards-open-source-open-loop/
> >
>
> Looking back now, in 2022, how have those earlier predictions played out?
> Do we have clear winners we can point to? Clear losers? This will help
> inform companies how they might want to engage with Open Source. Should
> companies embrace Open Source for protocol development? Or should companies
> go back to the old way, with open specifications and private
> implementations?
>

---

From: Maxim Sharabayko <[email-masked]>
Date: Sun, 20 Mar 2022 13:25:33 +0000

Hi Stuart,

The Secure Reliable Transport (SRT) protocol might be an interesting example.
https://github.com/Haivision/srt
It has become an extremely popular network protocol for a sub-second latency live video contribution and distribution.

It is an implementation-driven protocol built on top of UDP. First created in 2013 based on the UDT<https://datatracker.ietf.org/doc/html/draft-gg-udt-03>. Made free and open source in 2017.
The protocol has gained a notable success because anyone could take the library, easily integrate it in his/her project and have things ready for live streaming in quite a short time. Later the protocol was also included into open-source projects like FFmpeg, VLC, GStreamer, Wireshark, etc. That had further simplified the effort needed to get things up and running.

The  SRT RFC draft<https://datatracker.ietf.org/doc/html/draft-sharabayko-srt-01> followed in 2021 to provide a normative description of how the protocol works, and to serve a reference point for further improvements and extensions.

--
Kind regards,
Maxim Sharabayko

From: hackathon <[email-masked]> on behalf of Stuart Cheshire <cheshire=[email-masked]>
Date: Saturday, 19. March 2022 at 00:47
To: [email-masked] <[email-masked]>
Subject: [EXTERNAL] [hackathon] Open Source Software and network protocol standards
Dear Hackathon crew!

Stuart Cheshire

***[EXTERNAL] This message comes from an external organization. Exercise caution when opening attachments or clicking links, especially from unknown senders.***

---

From: Paul Wouters <[email-masked]>
Date: Sun, 20 Mar 2022 10:01:47 -0400 (EDT)

> My intuition is that in recent years Open Source Software has had a significant impact on network protocol standards, both in the availability of easily accessible open implementations contributing…

For IKEv1 / IPsec there were a number of "bake off" [tm][r] events where
FreeSWAN was the main interop target for all commercial implementations
for a number of years in the late '90s.

The software and protocol were evolving/implementing at the same time.

Paul

---

From: Robert Sparks <[email-masked]>
Date: Sun, 20 Mar 2022 09:55:07 -0500

Guess I should point to the SIPits here (www.sipit.net) - there were 
open source SIP stacks that were core elements of many of the 
implementations at the event and their existence made it easy to 
prototype proposed changes to the specs when we discovered the need at 
the events (such as for what became RFC5393).

RjS

On 3/20/22 9:01 AM, Paul Wouters wrote:
>> significant impact on network protocol standards, both in the 
>> availability of easily accessible open implementations contributing 
>> to the success of network protocol standards, and, in contrast, the 
>> lack of easily accessible open implementations contributing to less 
>> success for those network protocol standards.
>

---

From: Tom Henderson <[email-masked]>
Date: Sun, 20 Mar 2022 11:20:45 -0700

> Can you think of cases where an Open Source Software implementation clearly helped a networking protocol become successful? Was that Open Source implementation driven by the people (or companies) a…

HIP (Host Identity Protocol) development was done in coordination with 
two open source implementations for Linux:  OpenHIP and HIPL.  Many of 
the same people working on the drafts were implementing at the same 
time, and holding interop/debugging sessions during IETF week in the 
IETF terminal room.

- Tom

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 20 Mar 2022 19:53:57 +0100

> On 19. Mar 2022, at 00:47, Stuart Cheshire <cheshire=[email-masked]> wrote:
> 
> Dear Hackathon crew!
> 
Hi Stuart,

in the case of SCTP we always had in the past Open Source implementations available
when documents reached the WGLC. A lot of times it was the FreeBSD kernel implementation.
I really helped to understand if the specification is complete and allowed other
implementers to test against it.

Best regards
Michael

---

From: Robert Moskowitz <[email-masked]>
Date: Sun, 20 Mar 2022 14:54:01 -0400

I ran MOST of those early IPsec/IKEv1 interop sessions until I wasn't.   
Running them, that is.

Michael and Tero were there for most of it, but Cisco, FTP Software, 
SSH, Checkpoint, NIST!, were as key along with FreeSWAN.

I would say that the need for Inter-vendor connections (between 
companies running different products) was as much of a driver as open 
software for vpn use.  Further, that open vpn use was the beneficiary of 
commercial needs.

Lots of interesting history of the early 'hackathons'.  In our first in 
Dallas, hosted by MCI, we found that we could not get SHA1 interop 
between to code libraries.  One had the endian wrong!

Then in another, we blew the fuse on power draw for all the network gear 
and computers.  Some lost coding.

Also it was 'fun' (not) to get security code back out of the US at that 
time.  SSH was faxing their diffs back home and wiping their drives to 
get them out of the US.

Later interops were using FreeSwan as a target, but that was after the 
first interops worked out the kinks.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 20 Mar 2022 20:16:31 +0100

On Mar 20, 2022, at 19:55, Robert Moskowitz <[email-masked]> wrote:

I stand corrected. My hearsay seems to have been a tad subjective. As always it’s great to hear IETF histories from the people who we actually there !

Paul

> 
> I ran MOST of those early IPsec/IKEv1 interop sessions until I wasn't.   Running them, that is.
> 
> Michael and Tero were there for most of it, but Cisco, FTP Software, SSH, Checkpoint, NIST!, were as key along with FreeSWAN.
> 
> I would say that the need for Inter-vendor connections (between companies running different products) was as much of a driver as open software for vpn use.  Further, that open vpn use was the beneficiary of commercial needs.
> 
> Lots of interesting history of the early 'hackathons'.  In our first in Dallas, hosted by MCI, we found that we could not get SHA1 interop between to code libraries.  One had the endian wrong!
> 
> Then in another, we blew the fuse on power draw for all the network gear and computers.  Some lost coding.
> 
> Also it was 'fun' (not) to get security code back out of the US at that time.  SSH was faxing their diffs back home and wiping their drives to get them out of the US.
> 
> Later interops were using FreeSwan as a target, but that was after the first interops worked out the kinks.
> 
>

---

From: Tom Henderson <[email-masked]>
Date: Sun, 20 Mar 2022 13:24:41 -0700

>> Source implementation driven by the people (or companies) actively 
>> working on the protocol standard? Or was it created by an independent 
>> community following the standards development process?
> 
I neglected to mention two other open source implementations of HIP that 
were part of the development process-- a team at Ericsson developed a 
HIP for NetBSD implementation, and Andrew McGregor wrote and posted an 
early userspace implementation in Python (PyHIP).  Julien Laganier also 
had one going at some point, if I remember correctly, but I can't find 
artifacts of it today.  So in summary, there were four or five HIP open 
source implementations during the standards development process.

- Tom

---

From: Tom Pusateri <[email-masked]>
Date: Sun, 20 Mar 2022 16:55:57 -0400

> On Mar 19, 2022, at 5:00 PM, Stuart Cheshire <cheshire=[email-masked]> wrote:
> 

OSPF is a good example. We did a lot of interop testing and Rob Colton (UMD) did an open source implementation that landed in gated (Cornell) which I was a part of. John Moy (Protocol author/inventor, Proteon), Fred Baker (at ACC at the time), Dino Farinacci (3com at the time), Der-Hwa Gan (also 3com), and someone from Wellfleet who I don’t recall would do bake-offs where we would gather in a hotel conference room and connect all the routers and look for interop problems. Everyone would test against the open source version back at their labs as well as some of the closed source versions if you had the right equipment. I remember a bake-off in Boston where we discovered a bug in one of the closed source vendor implementations and everyone from all the companies just gathered around the laptop and looked at the source code trying to find the bug. Those were the good old days! (1989) The bug was discovered and fixed right then.

Tom

---

From: RJ A <[email-masked]>
Date: Mon, 21 Mar 2022 16:41:14 -0400

NRL’s open-source IPv6+IPsec for 4.4 BSD UNIX was the 1st with IPv6 packets on the wire and also the 1st implementation of IPsec.  It was the basis for many (most ?) 1st generation commercial IPsec implementations and also was used in some early IPv6 implementations.  It was developed/tested both on SPARC and x86 hardware.

Without NRL’s open-source implementation, IPsec would have taken years longer to make it both into standards and into products.

Ran

---

From: RA <[email-masked]>
Date: Mon, 21 Mar 2022 16:44:24 -0400

NRL’s open-source IPv6+IPsec for 4.4 BSD UNIX was the basis for many (most ?) 1st generation commercial IPsec implementations and also was used in some early IPv6 implementations.  It was developed/tested both on SPARC and x86.

IPsec would have taken years longer without the NRL open-source implementation, both to standardize and to ship in products.

Ran

> On Mar 20, 2022, at 10:01, Paul Wouters <[email-masked]> wrote:
> 
>

---

From: "Shoichi Sakane (ssakane)" <[email-masked]>
Date: Tue, 22 Mar 2022 06:12:16 +0000

I would be happy if you all IPsec guys remembered the KAME IPv6/IPsec implemetation and racoon for IKEv1/v2 which is ported on MacOS and Linux.

Shoichi
________________________________
From: hackathon <[email-masked]> on behalf of RA <[email-masked]>
Sent: Tuesday, March 22, 2022 5:44
To: [email-masked] <[email-masked]>
Cc: Stuart Cheshire <[email-masked]>
Subject: Re: [hackathon] Open Source Software and network protocol standards

Ran

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 22 Mar 2022 05:51:00 -0400

Thanks.  I was struggling to remember all the product participants and 
knew there was one from Japan...

I don't recall if you made it to any of the in-person interops, but you 
were part of the remote ones I ran out of my basement office. It was a 
challenge to coordinate everyone's testing time, with some of us doing 
the testing in the middle of local night to accommodate others.  I still 
have the world timezone map up on my wall down in that office that I 
used to figure out what time it was for each of you, and the chat server 
(I ran down there) logs I used for our progress reports.

Challenge was you were already at IPv6 and it made connecting to other 
testers limited.

On 3/22/22 02:12, Shoichi Sakane (ssakane) wrote:
> I would be happy if you all IPsec guys remembered the KAME IPv6/IPsec 
> implemetation and racoon for IKEv1/v2 which is ported on MacOS and Linux.
>
> Shoichi
> ------------------------------------------------------------------------
> *From:* hackathon <[email-masked]> on behalf of RA 
> <[email-masked]>
> *Sent:* Tuesday, March 22, 2022 5:44
> *To:* [email-masked] <[email-masked]>
> *Cc:* Stuart Cheshire <[email-masked]>
> *Subject:* Re: [hackathon] Open Source Software and network protocol 
> standards
> NRL’s open-source IPv6+IPsec for 4.4 BSD UNIX was the basis for many 
> (most ?) 1st generation commercial IPsec implementations and also was 
> used in some early IPv6 implementations.  It was developed/tested both 
> on SPARC and x86.
>
> IPsec would have taken years longer without the NRL open-source 
> implementation, both to standardize and to ship in products.
>
> Ran
>
>
> availability of easily accessible open implementations contributing to 
> the success of network protocol standards, and, in contrast, the lack 
> of easily accessible open implementations contributing to less success 
> for those network protocol standards.
> >
> <mailto:[email-masked]?subject=unsubscribe>
>
> <mailto:[email-masked]?subject=unsubscribe>
>
> Unsubscribe:mailto:[email-masked]?subject=unsubscribe

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit

---

From: "Shoichi Sakane (ssakane)" <[email-masked]>
Date: Tue, 22 Mar 2022 10:34:14 +0000

Yes, timezone was a big problem.  So, I and Itojun joined many times of the bakeoff events in person.  Our implementation supported both IPv6 and IPv4 so that any participants was able to check interoperability with us.

Shoichi
________________________________
From: Robert Moskowitz <[email-masked]>
Sent: Tuesday, March 22, 2022 18:51
To: Shoichi Sakane (ssakane) <[email-masked]>; RA <[email-masked]>; [email-masked] <[email-masked]>
Cc: Stuart Cheshire <[email-masked]>
Subject: Re: [hackathon] Open Source Software and network protocol standards

Thanks.  I was struggling to remember all the product participants and knew there was one from Japan...

I don't recall if you made it to any of the in-person interops, but you were part of the remote ones I ran out of my basement office.  It was a challenge to coordinate everyone's testing time, with some of us doing the testing in the middle of local night to accommodate others.  I still have the world timezone map up on my wall down in that office that I used to figure out what time it was for each of you, and the chat server (I ran down there) logs I used for our progress reports.

Challenge was you were already at IPv6 and it made connecting to other testers limited.

Shoichi
________________________________
From: hackathon <[email-masked]><mailto:[email-masked]> on behalf of RA <[email-masked]><mailto:[email-masked]>
Sent: Tuesday, March 22, 2022 5:44
To: [email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Cc: Stuart Cheshire <[email-masked]><mailto:[email-masked]>
Subject: Re: [hackathon] Open Source Software and network protocol standards

Ran

> On Mar 20, 2022, at 10:01, Paul Wouters <[email-masked]><mailto:[email-masked]> wrote:
>
>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
hackathon mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/hackathon
Unsubscribe: mailto:[email-masked]?subject=unsubscribe

_______________________________________________
hackathon mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/hackathon
Unsubscribe: mailto:[email-masked]?subject=unsubscribe

--
Robert Moskowitz
Owner
HTT Consulting
C:      248-219-2059
F:      248-968-2824
E:      [email-masked]<mailto:[email-masked]>

There's no limit to what can be accomplished if it doesn't matter who gets the credit

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 22 Mar 2022 07:42:05 -0400

I would like to think we all had fun back then.  Really accomplishing 
something.

On 3/22/22 06:34, Shoichi Sakane (ssakane) wrote:
> Yes, timezone was a big problem.  So, I and Itojun joined many times 
> of the bakeoff events in person.  Our implementation supported both 
> IPv6 and IPv4 so that any participants was able to check 
> interoperability with us.
>
> Shoichi
> *From:* Robert Moskowitz <[email-masked]>
> *Sent:* Tuesday, March 22, 2022 18:51
> *To:* Shoichi Sakane (ssakane) <[email-masked]>; RA 
> <[email-masked]>; [email-masked] <[email-masked]>
> I don't recall if you made it to any of the in-person interops, but 
> you were part of the remote ones I ran out of my basement office.  It 
> was a challenge to coordinate everyone's testing time, with some of us 
> doing the testing in the middle of local night to accommodate others.  
> I still have the world timezone map up on my wall down in that office 
> that I used to figure out what time it was for each of you, and the 
> chat server (I ran down there) logs I used for our progress reports.
>
>> *From:* hackathon <[email-masked]> 
>> <mailto:[email-masked]> on behalf of RA 
>> <[email-masked]> <mailto:[email-masked]>
>> *To:* [email-masked] <mailto:[email-masked]> 
>> <[email-masked]> <mailto:[email-masked]>
>> *Cc:* Stuart Cheshire <[email-masked]> <mailto:[email-masked]>
>> used in some early IPv6 implementations.  It was developed/tested 
>> both on SPARC and x86.
>>
>> >> My intuition is that in recent years Open Source Software has had 
>> a significant impact on network protocol standards, both in the 
>> > [email-masked] <mailto:[email-masked]>
>> <https://www.ietf.org/mailman/listinfo/hackathon>
>> [email-masked] <mailto:[email-masked]>
>> <https://www.ietf.org/mailman/listinfo/hackathon>
>> [email-masked]  <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/hackathon  <https://www.ietf.org/mailman/listinfo/hackathon>
>> Unsubscribe:mailto:[email-masked]?subject=unsubscribe  <mailto:[email-masked]?subject=unsubscribe>
>
> -- 
> Robert Moskowitz
> Owner
> HTT Consulting
> C: 248-219-2059
> F: 248-968-2824
> E: [email-masked] <mailto:[email-masked]>
>

---

From: Paul Wouters <[email-masked]>
Date: Tue, 22 Mar 2022 08:44:41 -0400 (EDT)

On Tue, 22 Mar 2022, Robert Moskowitz wrote:

> I would like to think we all had fun back then.  Really accomplishing something.

We are ALL individual implementations ! :)

Paul

---

From: RJ A <[email-masked]>
Date: Tue, 22 Mar 2022 10:46:38 -0400

>> I would be happy if you all IPsec guys remembered the KAME IPv6/IPsec implemetation and racoon for IKEv1/v2 which is ported on MacOS and Linux.

Yes.  I remember very well working with Itojun on many IPv6 things.  It is a very big loss that he is gone.

At the time, I was hearing that the KAME IPv6+IPsec also was widely referenced by commercial implementers.  

The Racoon implementation of IKEv1 was especially important.  I am not certain, but I think Racoon was the 1st open-source implementation of IKEv1 for BSD. As far as I know, NRL never implemented IKE, because it was too difficult to get release permissions for IKE.

Ran

---

From: Diego Dujovne <[email-masked]>
Date: Tue, 22 Mar 2022 11:53:33 -0300

Stuart,
           I would like to mention OpenWSN,
which is the reference for the 6tisch WG IoT stack. It was also used at the
Interop
sessions.
Regards,

                           Diego

On Tue, Mar 22, 2022 at 8:43 AM Robert Moskowitz <[email-masked]>
wrote:

> Yes, timezone was a big problem.  So, I and Itojun joined many times of
> the bakeoff events in person.  Our implementation supported both IPv6 and
> IPv4 so that any participants was able to check interoperability with us.
>
> Shoichi
> ------------------------------
> <[email-masked]>
> *To:* Shoichi Sakane (ssakane) <[email-masked]> <[email-masked]>;
> RA <[email-masked]> <[email-masked]>; [email-masked]
> <[email-masked]> <[email-masked]>
> *Cc:* Stuart Cheshire <[email-masked]> <[email-masked]>
> challenge to coordinate everyone's testing time, with some of us doing the
> testing in the middle of local night to accommodate others.  I still have
> the world timezone map up on my wall down in that office that I used to
> figure out what time it was for each of you, and the chat server (I ran
> down there) logs I used for our progress reports.
>
> ------------------------------
> <[email-masked]> on behalf of RA <[email-masked]>
> <[email-masked]>
> *To:* [email-masked] <[email-masked]> <[email-masked]>
> *Cc:* Stuart Cheshire <[email-masked]> <[email-masked]>
> NRL’s open-source IPv6+IPsec for 4.4 BSD UNIX was the basis for many (most
> ?) 1st generation commercial IPsec implementations and also was used in
> some early IPv6 implementations.  It was developed/tested both on SPARC and
> x86.
>
> > On Mar 20, 2022, at 10:01, Paul Wouters <[email-masked]>
> <[email-masked]> wrote:
> >
> >
> <[email-masked]?subject=unsubscribe>
>
> <[email-masked]?subject=unsubscribe>
>
> hackathon mailing [email-masked]://www.ietf.org/mailman/listinfo/hackathon
> Unsubscribe: mailto:[email-masked]?subject=unsubscribe <[email-masked]?subject=unsubscribe>
>
>
> --
> Robert Moskowitz
> Owner
> HTT Consulting
> C:      248-219-2059
> F:      248-968-2824
> E:      [email-masked]
>
> hackathon mailing [email-masked]://www.ietf.org/mailman/listinfo/hackathon
> Unsubscribe: mailto:[email-masked]?subject=unsubscribe <[email-masked]?subject=unsubscribe>
>
>
> --
> Robert Moskowitz
> Owner
> HTT Consulting
> C:      248-219-2059
> F:      248-968-2824
> E:      [email-masked]
>