[ih] Gateway Issue: Certification (was Re: booting linux on a 4004)

[Greg Skinner]

On Oct 3, 2024, at 10:43 AM, Jack Haverty via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> Hi Craig,
> 
> Thanks for the history; it helped me fill in the gaps of what happened after I was directly involved.
> 
> But... (there's always a but)
> 
> Those RFCs are not part of the issue I was remembering.  That issue was "Certification", which is distinct from "Specification". Specifications are documents which delineate what an implementation MUST, SHOULD, MAY, or MAY NOT do.  Certification is a process whereby a specific implementation is tested, often by an independent third party, to see if it actually does what the Specifications dictate.
> 
> Around the time that TCP/IP became a DoD Standard in the 1980s, NIST/NBS also created a Certification methodology.   DoD altered its procurement regulations to require such Certifications for everything it purchased.  I've never learned who specifically made either of those things happen.  But someone did.  Perhaps Vint remembers more?
> 
> The RFCs you mention are a follow-on to the Specifications that Jon orchestrated.  Bob Braden was also on the ICCB during that time, so it was probably natural for him to champion subsequent rounds of Specifications for NSF.
> 
> But, AFAIK, no one continued the work that NIST/NBS had started, to further evolve Certification for the Internet.  I also never heard that DoD's procurement regulations were changed to require compliance with additional RFCs.   Maybe it happened, but I suspect they couldn't do that unless there was some well-defined way to Certify that a product met those Specifications.
> 
> It's curious to me that such mechanisms have not been created for the Internet Industry.    Other computing technologies did develop such mechanisms.  For example, in the Database Industry where I worked in the 1990s, there were concepts like "Transactions", and testing procedures to see how a particular software/hardware combination actually worked in standard tests.  For example, vendors touted their particular hardware and software products as Certified to achieve some number of TPS (Transactions Per Second).
> 
> Similarly, even today there are lots of "Benchmarks" that are used today to evaluate computers and their component software and hardware.   Magazines and websites compare products and show graphs indicating how their test results compare, so that customers can make informed purchase decisions based on independent test results.
> 
> Most devices we can now buy contain hardware and software that enables them to interact on the Internet.  But, other than raw speed, I've never seen any of such test results that even mention conformance with any RFC Specifications.
> 
> Why not?
> 
> IMHO, such testing and certification is more important in a networked environment than in a single computer.  In network environments, there are at least two, and probably many more computers involved in anything a user does.  Some of them are servers, some are clients, some are routers, modems, switches, etc. etc.  All of these affect the users' experience, as well as affecting the network and the experience of others using it.
> 
> The ongoing discussions about source quench, congestion, queue management, et al made we wonder.  My home LAN has more than 50 "devices" attached to it, and contains a bunch of switches, modems, routers, cables, and other such stuff we all grew up with.
> 
> How can I tell if they all implement <pick some acronym>?   Or if any of them do?
> 
> Jack Haverty
> 

I decided to apply your questions to the device I’m currently typing on (a MacBook Pro running macOS Sonoma), pretending that I didn’t know anything about any IETF standards that are supported.  After a bit of googling, I found an Apple Support page detailing which TCP and UDP ports are used by Apple software products. [1]

But that doesn’t tell the entire story.  So I cheated a bit, taking into account that I know that Darwin is the OS that supports macOS, and via its Wikipedia page [2], found the Apple open source page. [3] From there, it is possible to visit several GitHub repos that have more details about which IETF standards are supported.

[1] https://support.apple.com/en-us/103229
[2] https://en.wikipedia.org/wiki/Darwin_(operating_system)
[3] https://opensource.apple.com

You might be asking if someone should have to go to all of this trouble to find out which IETF specifications are supported on a MacBook Pro running macOS Sonoma. Let’s see what Bing Copilot has to say:

====

macOS Sonoma supports a wide range of IETF (Internet Engineering Task Force) specifications, particularly those related to networking, security, and internet protocols. Here are some key IETF specifications that are typically supported:

1. **IPv6**: The latest version of the Internet Protocol, which provides an identification and location system for computers on networks and routes traffic across the Internet.
2. **TLS (Transport Layer Security)**: Protocols for secure communication over a computer network.
3. **HTTP/2 and HTTP/3**: Versions of the Hypertext Transfer Protocol used for transmitting hypermedia documents, such as HTML.
4. **DNS (Domain Name System)**: Protocols for translating domain names into IP addresses.
5. **SMTP, IMAP, and POP3**: Protocols for email transmission and retrieval.

These specifications ensure that macOS Sonoma can handle modern networking and security requirements efficiently. If you have specific IETF specifications in mind, feel free to ask! 😊

Source: Conversation with Copilot, 10/3/2024
(1) macOS Sonoma is compatible with these computers - Apple Support. https://support.apple.com/en-us/105113.
(2) macOS Compatibility Checker: What macOS Can My Mac Run? - MacBook Journal. https://macbookjournal.com/macos-compatibility-checker-all-macos-updates/.
(3) macOS Sonoma (macOS 14) Q&A - EveryMac.com. https://everymac.com/mac-answers/macos-14-sonoma-faq/macos-sonoma-macos-14-compatbility-list-system-requirements.html.
(4) macOS Sonoma compatibility: The Macs that run macOS 14. https://www.macworld.com/article/1942421/macos-14-sonoma-compatibility-features.html.
(5) macOS Sonoma System Requirements - iTechScreen. https://www.itechscreen.com/blogs/macos-sonoma-system-requirements/.

====

I don’t know if this meets your criteria for “findability", but it seems that the information is available for those willing and able to spend time looking for it.  The other thing (which is a valid concern) is because much of it is open source, it is not “supported”, per se, in the same sense the DoD Standard RFCs were.  Depending upon how carefully people read the EULAs, they may understand the difference between what is and isn’t open source, and adjust their expectations.

--gregbo