Yes, indeed it was. It's a fairly standard, unsurprising response for this situation; doesn't try to be defensive, doesn't try to provoke. [Edit: I'm horribly under-perceptive, after reading other comments I see I'm a bit off.]
But... this bit.
> ... [JL] This is our web notification system, documented in RFC 6108 https://tools.ietf.org/html/rfc6108, which has been in place for many years now. ...
Oh, interesting, what Internet technology are they using?
> "RFC 6108: Comcast's Web Notification System Design"
> February 2011
Cue jawdrop. My instinctive response was to WAT and think "this is not what RFCs were for..."
But then I read this part,
> Status of This Memo
> This document is not an Internet Standards Track specification; it is published for informational purposes.
> This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; ...
Hmm.
Reading through, this outlines a way to avoid using deep packet inspection by using Squid and Tomcat instead.
Initially when I read this my brain was sort of going in the direction of "this kind of thing is where the net neutrality repeal thing started..." but now I've spent a bit of time reading it I don't actually think my snap response was particularly on point.
This is a bit of a stream-of-consciousness but I wanted to draw attention to that RFC.
An RFC is not always a standard - often they are simply 'informational'. For us, when we wrote the document, it was a way to document as transparently as possible how the system worked so that folks would not need to speculate about it and for us to explain the rationale and alternatives considered. This seemed to me at the time far better than being evasive about it. And a request for comment is often a way to solicit exactly that - good comments (e.g. suggestions on alternatives). In this case, it has led in part to things like the IETF's new(ish) CAPPORT working group being created to develop a better Internet-wide standard for how to interact with so-called captive portals. See https://datatracker.ietf.org/wg/capport/about/ for more details and feel free to join the mailing list and contribute!
>Reading through, this outlines a way to avoid using deep packet inspection by using Squid and Tomcat instead.
Huh? It sure seems to be using deep packet inspection to me. If it's looking at the data section of your packet, that's deep packet inspection. And Squid and Tomcat do that. They're not just inspecting the packets, they're altering them, creating new packets, splitting packets, etc. The "RFC" seems to be outright lying by claiming they don't do DPI.
Hmmmm.
> Pre-established TCP sessions on port 80 are identified by the SMB and forwarded with no impact.
(SMB = Session Management Broker)
How does the system identify a "pre-established session"?
This seems to corroborate what you're saying
That part just requires looking at the TCP header. So I guess the answer is "no deep packet inspection until it picks a connection to inject, and then it inspects everything in that connection". Which simplifies to "yes deep packet inspection".