Must be new-style label selector. See Job, ReplicaSet, Deployment, or DaemonSet.

Applies to all selectors.

Experiments have showed that a single selector per policy element leads to tons of policy elements which need to be maintained with each unique pod selection label combination requiring a separate object. In particular if the labels change, a ton of files need to be touched.

Allowing for both, specifying a selector per element and allowing to extend (or negate parts) on a per rule basis drastically reduced the number of required policy elements and allowed to group policy into logical groups easily consumable and understandable by humans :-)

I therefore suggest to extend the rule struct with an optional selector.

IIRC the previous discussion brought this up, and we explicitly wanted to create separate NP objects for each rule, to prevent having gigantic objects that weren't easily parseable. eg, more smaller NP objects instead of fewer much larger objects.

Understood and that might be preferred by some. What I propose does not prevent anybody from doing that. The additional per rule selector is optional. OTOH, the current proposal requires to have a separate object for every label combination. We started out with the same assumption and ended up with several hundred policy elements when converting an existing network policy.

To be clear, you're saying that withing a single Namespace you had O(hundreds) of distinct selectors? Did those selectors all have the same policies or were they unique {selector, policy} tuples?

From a practical POV, Kubernetes has a limit to the size of the serialized API objects, currently 1MB. That is a lot, but we don't want to encourage monolith objects.

It's the cross product of label combinations that blows it up, a simple example:
You have pods app=A => app=B => app=C and you use the labels env={qa|prod|dev} and tenant={Birds|Lizards} to isolate the pods in a multi tenant environment. Maybe not the best example but it really applies to any scenario where you leverage multiple labels to isolate things from each other.

This would result in the following individual policy elements to be required to enforce it:

selector: app=B, env=qa, tenant=Birds
allow: app=A, env=qa, tenant=Birds
selector: app=C, env=qa, tenant=Birds
allow: app=B, env=qa, tenant=Birds
selector: app=B, env=prod, tenant=Birds
allow: app=A, env=prod, tenant=Birds
selector: app=C, env=prod, tenant=Birds
allow: app=B, env=prod, tenant=Birds
selector: app=B, env=dev, tenant=Birds
allow: app=A, env=dev, tenant=Birds
selector: app=C, env=dev, tenant=Birds
allow: app=B, env=dev, tenant=Birds
selector: app=B, env=qa, tenant=Lizards
allow: app=A, env=qa, tenant=Lizards
selector: app=C, env=qa, tenant=Lizards
allow: app=B, env=qa, tenant=Lizards
selector: app=B, env=prod, tenant=Lizards
allow: app=A, env=prod, tenant=Lizards
selector: app=C, env=prod, tenant=Lizards
allow: app=B, env=prod, tenant=Lizards
selector: app=B, env=dev, tenant=Lizards
allow: app=A, env=dev, tenant=Lizards
selector: app=C, env=dev, tenant=Lizards
allow: app=B, env=dev, tenant=Lizards

A lot of what you're describing here would naturally be split into namespaces (de/prod and birds/lizards), so they must necessarily be different objects. The question then remains whether one NP object per "app" makes sense (in this case app={a,b,c}) or whether one NP object per selector. ISTR discussing this and deciding to go simple, but I think it is a fair concern.

@caseydavenport what do you think about adding an "open questions" section at the bottom and including this question?

I just saw your comment further down regarding namespaces + pod selector which would resolve my main concern around using namespaces for tenancy which is how to allow exposing individual pods across tenants. I think you will still eventually end up with people defining cross products for constructs where namespaces is not a great fit. Initial users will probably be able to give appropriate feedback.

need to define the semantics. Can I specify both pods and namespaces in a single entry? Or is this a one-of?

i.e.

from:
 - pods: { role: fe }
   namespaces: { tenant: coke }

vs

from:
 - pods: { role: fe }
 - namespaces: { tenant: coke }

The former sort of implies "and" but I don't think we are offering an "and" semantic at all. Do we need to?

This was clarified later. All the more reason to describe this as a Go struct with rigorous comments on each field.

Since we do not have negative actions, how about
s/prevent/not allow/
or, more to the point,
s/if policy is in place that would prevent/if no policy is in place that would allow/
?

I thought we agreed this should say to return clusterDefault(traffic, pod) instead of True

No, the cluster default is what applies when namespace.networkPolicy.ingress.isolation is undefined; otherwise traffic is refused if it is neither for probing (health checking or lifecycle) or allowed by a NetworkPolicy.
If this is not clear yet, just consider this: where does this code ever return "False"?

or lifecycle probes, I presume