We have other more up-to-date representations of this information at https://cilium.io/ and in the docs; several of the sections below are out-of-date and I'm not sure whether the text is putting the right highlights on the featureset we think is most important to users. I think it's a fair proposal.

We might want to make sure that viewers that find this repository can be easily redirected towards cilium.io for getting this sort of information. Interestingly we link to ebpf.io but not the main website from this page. 😅

I would guess a lot of people arriving at this page may have already come from cilium.io, but it wouldn't hurt to encourage readers that find this page to explore the use cases on cilium.io in case they didn't already. We could do this either by integrating that encouragement into the first paragraph, or maybe place it into the "Getting Started" section. On a related note we might want to link the labs as well since that would also be a great way to get started.

I think I've addressed all of this feedback now

We might want to make sure that viewers that find this repository can be easily redirected towards cilium.io for getting this sort of information. Interestingly we link to ebpf.io but not the main website from this page. 😅

I would guess a lot of people arriving at this page may have already come from cilium.io, but it wouldn't hurt to encourage readers that find this page to explore the use cases on cilium.io in case they didn't already. We could do this either by integrating that encouragement into the first paragraph, or maybe place it into the "Getting Started" section. On a related note we might want to link the labs as well since that would also be a great way to get started.

The first sentence should provide a concise encapsulation of what the project is, which we then expand on. The framing of "began as..." and "became ..." is not relevant for the first paragraph IMHO. Right from the beginning Cilium was built from the perspective of "how could we rethink networking to do it better?", and the details of container networking vs. CNI is not particularly relevant to that scope. But I also digress! The reader should come away from the first paragraph with a good grasp of the core functionality. A subsequent paragraph can expand on that to paint the picture of the existing technology landscape and our role in it (including technology selections, bets we made, how we contributed, etc).

I think that this new text is slightly downplaying the involvement we Cilium contributors have had in building core eBPF. I am undoubtedly going to read a lot more into this text than the average reader, but I read this first paragraph to have the perspective "we tried to create a project then we found this CNI thing and this eBPF thing and then we figured yeah we should bet on those things". Yes, we bet on eBPF, but we also participated in the upstream communities and collaborated with others to forge capabilities in eBPF that were not previously possible.

I know it's tricky to try to rewrite these core pieces so I'm trying not to have too much attachment to the existing text, but maybe it's worth highlighting +/- of the existing text for contrast:

• The existing text refers strongly to Linux and Docker, both of which still play very important roles in the ecosystem but both of which we do not expect to be required for Cilium in the coming years.

• key points are included: OSS, security, networking, for containers, connectivity for applications

I'm not sure it makes sense to drop the paragraph with emphasis on eBPF as the core technology behind Cilium. I think we should keep it (or some variation).

I recognize that eBPF is not particularly new at this stage, but I wonder if we can still convey the same emphasis in any new text. Even if we drop the word 'new' I think that would improve on it.

I recognize also that there is an over-emphasis on 'Linux' in the existing text, meanwhile eBPF on Windows is rising in prominence. The common parlance in the eBPF Foundation is "privileged context such as operating system kernel", but that's a bit of a mouthful. Maybe we can iterate on the existing text a bit just to address this shortfall. We could refer to the IETF standard rather than the target platform if we think that's worth emphasizing.

The second sentence probably had more meaning in the past, but it still speaks to the comparison with in-app security protections or sidecar based approaches. I don't know if that's necessarily the thing I would highlight as part of the "emphasise eBPF" paragraph but I don't think it's necessarily dated or inaccurate.

This has some minor divergences vs. the README version, notably ... with Cilium Cluster Mesh. The sentence already describes that it spans multiple clusters, so this doesn't add new information. As we iterate on this functionality page we could add a whole section and refer to cluster mesh. Interested users could either use the search bar or navigation bar to find the multi-cluster docs, so I don't know if we need to emphasize Cilium Cluster Mesh as a brand at this point of the docs given it's one of many features.

Briefly looking at Google Trends I think that we would benefit from referring to DNS features by the acronym DNS rather than FQDN. FQDN (Fully Qualified Domain Name) is a more niche technical term, and though we use it heavily in the policy specification, it is not likely to have much meaning to readers of this primer.

The addition of FQDN is something I think worth highlighting as a key feature, probably in an ideal text I might add it in a sentence afterwards describing some of the policy capabilities within "Layer 3 to Layer 7" like matching on services, DNS, groups of IP addresses. The danger of putting it in the middle of this existing sentence is just that we complicate the reading experience for the target audience, which is already people who have less familiarity with the subject.

I think I missed last time that this actually drops the only functionality overview we have from the docs website. Is there a plan to provide another summary of features to replace it or do we think that this role is now better served by cilium.io?