Slashdot Mirror

You wish.

All hardware is required to be NRTL approved before it can be sold *commercially*. The buyer or builder accepts all liability

Here's a good read on it.

http://electronics.stackexchan...

The problem isn't the software so much as the purchaser that rarely bothers to change default passwords or settings. Manufacturers are somewhat to blame for trying to make things as simple as possible and people are lazy.

The bottom line here is the consumer generally has no concept of the risk and everyone operates on the attitude 'I saw it on the news so it can't *possibly* happen to me. In reality the ISP should be blocking all RFC 1918, and spoofed traffic from a subscriber.

https://tools.ietf.org/html/rf...

Suffer no longer, AC, I have found the full spec on the web for you.

https://tools.ietf.org/html/rfc6749

In all seriousness, why don't you read the fucking manual instead of whining?

To be fair though, RFCs aren't software. If I write an RFC defining how software to teleport beer should work that is one thing, but actually writing the software and making it work is another matter.

I look at RFCs kind of like patents. They formally describe methods, behaviors, research, or innovations of something related to the internet. They let everyone know of an idea so that everyone implementing that idea has a basis for things to work together. And they allow people to build upon those ideas in creating derivative works.

If you look at RFC561 there is even a sample email message. Shiva Ayyadurai might have created the first full and complete email system as we know it today, but he didn't create the concept of email. Even the Smithsonian National Museum of American History says as much:

Exchanging messages through computer systems, what most people call âoeemail,â predates the work of Ayyadurai. However, the museum found that Ayyaduraiâ(TM)s materials served as signposts to several stories about the American experience.

But there's a difference between having an idea and actually building something.

The USPTO would differ with you on that idea.

> The RFCs that created the Arpanet email infrastructure that modern Internet email is built in were developed years before this fraud.

I'd say 'described' rather than 'created'.

Depending on what you consider email, it was going strong in the 70s and there were proto-email systems back in the 60s, whereas Postel's email RFC is from 1982.

https://tools.ietf.org/html/rf...

https://tools.ietf.org/html/rf...

These pretty much cover this...

https://tools.ietf.org/html/rf...

https://tools.ietf.org/html/rf...

These pretty much cover this...

Because the first option is expensive and ineffective.. as if criminal would not remove that features...

On the other hand, taking down the operator and arresting them is cheap, efficient and not dependent on the criminal willingness to get caught.

Proposing a "geoblocker" in drone is the same thing as rfc3514.

The Bergen Linux User group have actually done this for real (for all of 9 packets though), and it was also discussed here. Or course, that's now old hat as it doesn't implement QoS or IPv6oAC.

The Bergen Linux User group have actually done this for real (for all of 9 packets though), and it was also discussed here. Or course, that's now old hat as it doesn't implement QoS or IPv6oAC.

I was curious if anybody had implemented RFC 1149. Now I know!

Than you for taking the time to answer me.

I guess, because of the sheer size of the net, the calculation delay would have to be in the range of minutes to be effective. But that would effectively bring the net to a halt or back to mid-nineties, if you prefer.

While reading your post another idea popped up: forcing the devices to play nice by rate limiting on the client side. This could be achieved via a special device-mode setting in the (say: Linux) kernel which the manufacturer just activates at compile time. Then a rate limit will be enforced on outbound connections or possibly even setting the evil bit in outgoing packages when the rate is too high. The network infra structure can then choose to delay or block the tagged traffic.

Normal use will not be affected since the packages mostly are local only.

As you can see this is a very rough idea and I am not sure it will scale enough. It would probably also take some time to get the spread it would need to be effective. Further thoughts?

First email discusses a banal PR tweet.
Second email is a roundup of recent news programs.
From Wikipedia: "The OpenDKIM Project organized a data collection involving 21 mail servers and millions of messages. 92.3% of observed signatures were successfully verified, a success rate that drops slightly (90.5%) when only mailing list traffic is considered." [cite]
Verify emails when they come up; it makes no sense to point to two unverifiable emails as indicative of thousands.

I suspect the problem is that the kettle is RFC 2324 compliant, and was returning a 418 error.

No worries -- I hear they're working on a firmware update to make the kettle RFC 7168 compliant, which should make integration much easier.

Yaz

I suspect the problem is that the kettle is RFC 2324 compliant, and was returning a 418 error.

No worries -- I hear they're working on a firmware update to make the kettle RFC 7168 compliant, which should make integration much easier.

Yaz

CHECK THIS, THE MOST SHOCKING "JON PO" EMAIL!!!
Proof that this email thing has been going on for years.
Getting Down and Dirty with "John Po".

Wouldn't most if not all DDoS attacks be much harder if ISPs implemented BCP38? Of course IoT devices should be secure, but this is a dream as software will always contain bugs. The number of ISPs is much smaller than the number of devices connected to the internet, so blocking spoofed IP traffic is much cheaper solution.

That's the day the IPV6 transition actually happens. We don't have even IANA managing those - they don't need management because the supply exceeds the maximum theoretical demand a thousand times over.

That is incorrect, IANA delegates superblocks to RIRs just like with IPv4.

https://tools.ietf.org/html/rf...

This HAS to be done, or else it would literally be impossible to configure BGPv3 (and higher) to determine how to route traffic in the backbone.

Ugh -- sorry for the bad HTML tag -- the link should be to RFC 597

.

If we went back in time to when there only was 28 domains, I'd bet you a Mars Bar that there were only 28 websites.

You'd lose that bet, if only because from 1973 defines 81 existing hostnames on the Internet, and the Web wasn't online until 1991.

Thus if you did go back in time to when there were only 28 domains, there wouldn't be a web, and hence no websites.

FYI, I prefer the traditional Mars bar (no almonds or peanut butter or whatever). Snack-size is acceptable.

Yaz

Could we please get everyone to implement RFC3514?

https://www.ietf.org/rfc/rfc3514.txt

Also, could we please get everyone to implement hyperlinks

The write-up and TFA conflate the Internet and (what became known as web). Maybe, the slines don't know any better, but Slashdot users ought to... The hyperlinked documents weren't the first "killer application" — e-mail was. The first systems weren't even using the Internet, but, according to Wikipedia:

In 1971 the first ARPANET email was sent

And Sir Lee's was not even the first system for linking documents/files across the networks — Gopher was. And Gopher was not merely proposed in 1991, that's when an actual system became available (though protocol was codified in an RFC only in 1993).

If you want to get "technical" the web (aka http/html) was first (1990 vs 1991 for gopher), but the graphical browser mosaic didn't appear until '93 and not to many folks were using the non-graphical web servers that were in existence at the time.

If email was the killer app, inter-domain mail (via unix mail via rmail/UUCP) was probably the real killer app, not ARPANET email as ARPANET was mostly restricted to non-commercial use. Gopher like the "web" didn't really pop up until '91 when the NSFNET (the modern "internet") was winding down and the commercial internet was ramping up (the various NAPs like MAE and CIX, etc were taking off). Prior to inter-domain unix mail, commercial email was generally *unconnected* (needed to be on the same proprietary system like compuserve to send/receive mail).

In 1971 the first ARPANET email was sent

And Sir Lee's was not even the first system for linking documents/files across the networks — Gopher was. And Gopher was not merely proposed in 1991, that's when an actual system became available (though protocol was codified in an RFC only in 1993).

Then Yahoo isn't implementing RFC 5233, " Sieve Email Filtering: Subaddress Extension". Since yours is a paid account, I guess you don't always get what you pay for, and you can't use subaddressing to tag emails so you know who leaked your addy.

Subaddressing is the practice of augmenting the local-part of an [RFC2822] address with some 'detail' information in order to give some extra meaning to that address. One common way of encoding 'detail' information into the local-part is to add a 'separator character sequence', such as "+", to form a boundary between the 'user' (original local-part) and 'detail' sub-parts of the address, much like the "@" character forms the boundary between the local-part and domain.

Typical uses of subaddressing might be:

• o A message addressed to "ken+sieve@example.org" is delivered into a mailbox called "sieve" belonging to the user "ken".
• o A message addressed to "5551212#123@example.com" is delivered to the voice mailbox number "123" at phone number "5551212".

I read his statement as being facetious. Last few times we discussed IPv6, we did bring up the fact that the IETF officially endorses NPT - Network Prefix Translation - RFC 6296

Not for ever - they are working on a method of doing bridge-based WebRTC which is nevertheless end-to-end secure - see https://datatracker.ietf.org/w... . AIUI, the way it works is that it established point-to-point encrypted tunnels between the endpoints for key distribution so the bridge isn't able to decrypt the data even if it wanted to, and yet, you don't need N->N transmission of streams.

Gerv

> Same thing as with TCP/IP vs Token Ring

They are not even on the same level. Token Ring is layer 2, and you can run TCP/IP over it, the same way you can run it over the various Ethernet protocols (wired or wireless).

IPv4 and IPv6, so it's not "vs." in the sense of "using Token Ring rather than TCP/IP".

So "I instantaneously "got" TCP/IP, and only much later understood the point of Token Ring" presumably means "I understood why you'd use TCP/IP on various networks, and only much later understood why you'd use Token Ring for a network segment (rather than, say, Ethernet)", so it's not quite the same as "HTTP vs. Gopher".

> Same thing as with TCP/IP vs Token Ring

They are not even on the same level. Token Ring is layer 2, and you can run TCP/IP over it, the same way you can run it over the various Ethernet protocols (wired or wireless).

IPv4 and IPv6, so it's not "vs." in the sense of "using Token Ring rather than TCP/IP".

So "I instantaneously "got" TCP/IP, and only much later understood the point of Token Ring" presumably means "I understood why you'd use TCP/IP on various networks, and only much later understood why you'd use Token Ring for a network segment (rather than, say, Ethernet)", so it's not quite the same as "HTTP vs. Gopher".

The problem is substantially older than social media. I would argue the internet died the day they took IANA from Jon Postel.

That was the exact moment when humans were replaced with institutions, and morality with low. Add to that the introduction of asynchronous connections, and it was abundantly clear that there now were 2 Internets, one for the corporations and the institutions, and one for the plebeians. Balkanization as we have seen over the past few years is another logical step, as is the replacement of the general purpose OS, by the locked down OS.

Do I blame the companies? No, I blame us. You lot are all to willing to submit. Look at fucking Steam. I hate us.

What good does that do against people who follow no rules?

We can detect them with this.

What's the difference between a legitimate packet and an illegitimate one? How will MS', Apple's, and Google's operating systems distinguish between them in order to decide which to reject and which to accept?

Easy RFC3514 provides an unambiguous method of doing so.

No, wildcard certs only go one level (See http://www.ietf.org/rfc/rfc281...).

So we're throwing out the "better" in search for the "perfect?" Until tokens gain the ubiquity of phones (which seems unlikely), doing away with SMS-based two-factor authentication may just force many users back to the password-only era.

Two words: Google Authenticator.

There is no excuse for using SMS for 2FA when you have TOTP with a well-documented interoperability standard in RFC 6238.

How about this one: RFC 1149 needs to be revised to include sharks?

You read a modern spec? stop the presses.

Seriously, what HTTP was designed to do is described here https://tools.ietf.org/html/rf...

Read that one and you'll understand why people think REST is almost silly.

You have to use T-Mobile's API so that they can ensure the stream parameters are appropriate.

Okay, fine: what API? I looked for the RFC, but can't find it.

Link to the publicly-accessible documentation for it, explaining how any random server operator can implement it without "partnering" with T-Mobile, and I will be perfectly satisfied.

This message was carried via a flock of pigeons, a fleet of sled dogs and a herd of wildebeest, across 7 continents and via the Rot (it's like an encrypted Tor, but using snails at night) network.

I probably won't see your reply because it has to come back via the cats and they are to busy posing for photos.

There is no need for such complication. The IETF long ago created A Standard for the Transmission of IP Datagrams on Avian Carriers. You just need the pigeons.

Agreed. "Exposed ports" != "vulnerable ports".

I have no problem with telnet as long as you can't access anything too interactive (e.g., a shell) through it. After all, http, SMTP, POP, daytime, chargen and echo are all telnet-like protocols. (Ok, not really, but close enough,) It used to be quite fun to run a honeypot (fake) telnet server to see what was happening in the wild woolly internet.

Even open, unencrypted RDP and VNC have a [narrow] use case (broadcasting games and videos, anyone?)

Can't think of a good use case for open SQL ports though; except for very specialized applications.

RFC2468 details the story of Jon Postel, who tried to move US control of DNS zones to IANA. This battle still rages, but Ted Cruz hasn't realized other nations (e.g. Russia) have contingency plans to bring up their own root DNS if anything happens with their relationship to the U.S.; making US control of these root DNS zones not-that-important-anymore.

ARPANET was US funded as well was TCP/IP (made at Berkeley or MIT can't remember which),

If you mean the TCP and IP protocols, RFC 791, "INTERNET PROTOCOL/DARPA INTERNET PROGRAM/PROTOCOL SPECIFICATION" and RFC 793, "TRANSMISSION CONTROL PROTOCOL/DARPA INTERNET PROGRAM/PROTOCOL SPECIFICATION" were "Developed ... by Information Sciences Institute, University of Southern California". TCP was, to quote that RFC, "based on concepts first described by Cerf and Kahn in {Cerf, V., and R. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Transactions on Communications, Vol. COM-22, No. 5, pp 637-648, May 1974}".

If you mean implementations of those protocols, a very important implementation was done at Berkeley.

Time to get schooled:

Nope, no schooling involved; I already knew about CYCLADES.

However, the Internet Protocol and the Transmission Control Protocol, in particular - which are, respectively, one of the network layers and transport layers of the stack to which the person who started this thread was referring - were developed as part of a DARPA project; the original poster wasn't referring to the entire concept of packet switching, but was referring to the protocols on the Internet. That doesn't mean that every single idea involved with them was a US invention, but it does mean that the development IPv4 and TCP in particular was paid for by the US Department of Defense.

(And as for networking and governments, well, said Pouzin (misspelled "Pouzim" in the paper) was working for the Institut de Recherche d'lnformatique et d'Automatique, and IRIA was, err, umm, a French government organization, so that's even more gummint involvement.)

ARPANET was US funded as well was TCP/IP (made at Berkeley or MIT can't remember which),

If you mean the TCP and IP protocols, RFC 791, "INTERNET PROTOCOL/DARPA INTERNET PROGRAM/PROTOCOL SPECIFICATION" and RFC 793, "TRANSMISSION CONTROL PROTOCOL/DARPA INTERNET PROGRAM/PROTOCOL SPECIFICATION" were "Developed ... by Information Sciences Institute, University of Southern California". TCP was, to quote that RFC, "based on concepts first described by Cerf and Kahn in {Cerf, V., and R. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Transactions on Communications, Vol. COM-22, No. 5, pp 637-648, May 1974}".

If you mean implementations of those protocols, a very important implementation was done at Berkeley.

Time to get schooled:

Nope, no schooling involved; I already knew about CYCLADES.

However, the Internet Protocol and the Transmission Control Protocol, in particular - which are, respectively, one of the network layers and transport layers of the stack to which the person who started this thread was referring - were developed as part of a DARPA project; the original poster wasn't referring to the entire concept of packet switching, but was referring to the protocols on the Internet. That doesn't mean that every single idea involved with them was a US invention, but it does mean that the development IPv4 and TCP in particular was paid for by the US Department of Defense.

(And as for networking and governments, well, said Pouzin (misspelled "Pouzim" in the paper) was working for the Institut de Recherche d'lnformatique et d'Automatique, and IRIA was, err, umm, a French government organization, so that's even more gummint involvement.)

ARPANET was US funded as well was TCP/IP (made at Berkeley or MIT can't remember which),

If you mean the TCP and IP protocols, RFC 791, "INTERNET PROTOCOL/DARPA INTERNET PROGRAM/PROTOCOL SPECIFICATION" and RFC 793, "TRANSMISSION CONTROL PROTOCOL/DARPA INTERNET PROGRAM/PROTOCOL SPECIFICATION" were "Developed ... by Information Sciences Institute, University of Southern California". TCP was, to quote that RFC, "based on concepts first described by Cerf and Kahn in {Cerf, V., and R. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Transactions on Communications, Vol. COM-22, No. 5, pp 637-648, May 1974}".

If you mean implementations of those protocols, a very important implementation was done at Berkeley.

Time to get schooled:

https://en.wikipedia.org/wiki/CYCLADES

"The most important legacy of CYCLADES was in showing that moving the responsibility for reliability into the hosts was workable, and produced a well-functioning service network. It also showed that it greatly reduced the complexity of the packet switches. The concept became a cornerstone in the design of the Internet.[2]"

A Presales Engineer in the Know

ARPANET was US funded as well was TCP/IP (made at Berkeley or MIT can't remember which),

If you mean the TCP and IP protocols, RFC 791, "INTERNET PROTOCOL/DARPA INTERNET PROGRAM/PROTOCOL SPECIFICATION" and RFC 793, "TRANSMISSION CONTROL PROTOCOL/DARPA INTERNET PROGRAM/PROTOCOL SPECIFICATION" were "Developed ... by Information Sciences Institute, University of Southern California". TCP was, to quote that RFC, "based on concepts first described by Cerf and Kahn in {Cerf, V., and R. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Transactions on Communications, Vol. COM-22, No. 5, pp 637-648, May 1974}".

If you mean implementations of those protocols, a very important implementation was done at Berkeley.

Time to get schooled:

https://en.wikipedia.org/wiki/CYCLADES

"The most important legacy of CYCLADES was in showing that moving the responsibility for reliability into the hosts was workable, and produced a well-functioning service network. It also showed that it greatly reduced the complexity of the packet switches. The concept became a cornerstone in the design of the Internet.[2]"

A Presales Engineer in the Know

Packet switching - aka ARPANET- was US funded. The IP/TCP/HTTP/HTML stack was developed at CERN, EU.

To be clear - The foundation of the Internet as we know it today, the IP protocol stack, including IP (the Internet Protocol) https://tools.ietf.org/html/rfc791 and TCP (the Transmission Control Protocol) https://www.ietf.org/rfc/rfc793.txt, were most emphatically *not* developed at CERN or by any entity in Europe. Europe was busy working on the International Standards Organization (ISO) Open Systems Interconnect (OSI) protocol stack while the US was whipping up IP, TCP, UDP (et al.) as a follow-on to the original ARPAnet communications protocols. The ISO OSI reference model for networking survived (sort of); the OSI protocol stack largely sank beneath the waves. The Internet development model (rough consensus and running code) was a lot more productive than endless committee meetings and the attempt to put everything including the kitchen sink into a protocol stack (think of it as Agile development versus Waterfall development). I'm a bit touchy about this because I got embroiled in battles involving European agencies who tried to insist that major global communications networks should be based on ISO OSI long after TCP/IP was firmly established as the clear standard for internetworking.

This of course in no way diminishes the value of the introduction of HTTP/HTML to the Internet by Tim Berners-Lee while he worked at CERN.

Time to get schooled:

https://en.wikipedia.org/wiki/CYCLADES

"The most important legacy of CYCLADES was in showing that moving the responsibility for reliability into the hosts was workable, and produced a well-functioning service network. It also showed that it greatly reduced the complexity of the packet switches. The concept became a cornerstone in the design of the Internet.[2]"

A Presales Engineer in the Know

Packet switching - aka ARPANET- was US funded. The IP/TCP/HTTP/HTML stack was developed at CERN, EU.

To be clear - The foundation of the Internet as we know it today, the IP protocol stack, including IP (the Internet Protocol) https://tools.ietf.org/html/rfc791 and TCP (the Transmission Control Protocol) https://www.ietf.org/rfc/rfc793.txt, were most emphatically *not* developed at CERN or by any entity in Europe. Europe was busy working on the International Standards Organization (ISO) Open Systems Interconnect (OSI) protocol stack while the US was whipping up IP, TCP, UDP (et al.) as a follow-on to the original ARPAnet communications protocols. The ISO OSI reference model for networking survived (sort of); the OSI protocol stack largely sank beneath the waves. The Internet development model (rough consensus and running code) was a lot more productive than endless committee meetings and the attempt to put everything including the kitchen sink into a protocol stack (think of it as Agile development versus Waterfall development). I'm a bit touchy about this because I got embroiled in battles involving European agencies who tried to insist that major global communications networks should be based on ISO OSI long after TCP/IP was firmly established as the clear standard for internetworking.

This of course in no way diminishes the value of the introduction of HTTP/HTML to the Internet by Tim Berners-Lee while he worked at CERN.

Time to get schooled:

https://en.wikipedia.org/wiki/CYCLADES

"The most important legacy of CYCLADES was in showing that moving the responsibility for reliability into the hosts was workable, and produced a well-functioning service network. It also showed that it greatly reduced the complexity of the packet switches. The concept became a cornerstone in the design of the Internet.[2]"

A Presales Engineer in the Know

ARPANET was US funded as well was TCP/IP (made at Berkeley or MIT can't remember which),

If you mean the TCP and IP protocols, RFC 791, "INTERNET PROTOCOL/DARPA INTERNET PROGRAM/PROTOCOL SPECIFICATION" and RFC 793, "TRANSMISSION CONTROL PROTOCOL/DARPA INTERNET PROGRAM/PROTOCOL SPECIFICATION" were "Developed ... by Information Sciences Institute, University of Southern California". TCP was, to quote that RFC, "based on concepts first described by Cerf and Kahn in {Cerf, V., and R. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Transactions on Communications, Vol. COM-22, No. 5, pp 637-648, May 1974}".

If you mean implementations of those protocols, a very important implementation was done at Berkeley.

ARPANET was US funded as well was TCP/IP (made at Berkeley or MIT can't remember which),

If you mean the TCP and IP protocols, RFC 791, "INTERNET PROTOCOL/DARPA INTERNET PROGRAM/PROTOCOL SPECIFICATION" and RFC 793, "TRANSMISSION CONTROL PROTOCOL/DARPA INTERNET PROGRAM/PROTOCOL SPECIFICATION" were "Developed ... by Information Sciences Institute, University of Southern California". TCP was, to quote that RFC, "based on concepts first described by Cerf and Kahn in {Cerf, V., and R. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Transactions on Communications, Vol. COM-22, No. 5, pp 637-648, May 1974}".

If you mean implementations of those protocols, a very important implementation was done at Berkeley.

Since when were Vince Cerf, Bob Kahn, or IEEE European?
It's a good thing no one writes these things down

Since when were Vince Cerf, Bob Kahn, or IEEE European?
It's a good thing no one writes these things down

Packet switching - aka ARPANET- was US funded. The IP/TCP/HTTP/HTML stack was developed at CERN, EU.

To be clear - The foundation of the Internet as we know it today, the IP protocol stack, including IP (the Internet Protocol) https://tools.ietf.org/html/rfc791 and TCP (the Transmission Control Protocol) https://www.ietf.org/rfc/rfc793.txt, were most emphatically *not* developed at CERN or by any entity in Europe. Europe was busy working on the International Standards Organization (ISO) Open Systems Interconnect (OSI) protocol stack while the US was whipping up IP, TCP, UDP (et al.) as a follow-on to the original ARPAnet communications protocols. The ISO OSI reference model for networking survived (sort of); the OSI protocol stack largely sank beneath the waves. The Internet development model (rough consensus and running code) was a lot more productive than endless committee meetings and the attempt to put everything including the kitchen sink into a protocol stack (think of it as Agile development versus Waterfall development). I'm a bit touchy about this because I got embroiled in battles involving European agencies who tried to insist that major global communications networks should be based on ISO OSI long after TCP/IP was firmly established as the clear standard for internetworking.

This of course in no way diminishes the value of the introduction of HTTP/HTML to the Internet by Tim Berners-Lee while he worked at CERN.

Packet switching - aka ARPANET- was US funded. The IP/TCP/HTTP/HTML stack was developed at CERN, EU.

To be clear - The foundation of the Internet as we know it today, the IP protocol stack, including IP (the Internet Protocol) https://tools.ietf.org/html/rfc791 and TCP (the Transmission Control Protocol) https://www.ietf.org/rfc/rfc793.txt, were most emphatically *not* developed at CERN or by any entity in Europe. Europe was busy working on the International Standards Organization (ISO) Open Systems Interconnect (OSI) protocol stack while the US was whipping up IP, TCP, UDP (et al.) as a follow-on to the original ARPAnet communications protocols. The ISO OSI reference model for networking survived (sort of); the OSI protocol stack largely sank beneath the waves. The Internet development model (rough consensus and running code) was a lot more productive than endless committee meetings and the attempt to put everything including the kitchen sink into a protocol stack (think of it as Agile development versus Waterfall development). I'm a bit touchy about this because I got embroiled in battles involving European agencies who tried to insist that major global communications networks should be based on ISO OSI long after TCP/IP was firmly established as the clear standard for internetworking.

This of course in no way diminishes the value of the introduction of HTTP/HTML to the Internet by Tim Berners-Lee while he worked at CERN.