Clarify "entity"

[renghardt]

From Jake's review:

  I think there's a lot of use of the word "entity" when a narrower "Host" or "Node" would be better.

I'm getting a vague impression that in some situations, like when information is exposed to an entity that can use it to achieve goals, like in "3. Use Cases for Path Properties", "entity" is intended to capture nodes in general plus things like traffic engineering controllers that might have no part in a traffic path, whereas in other cases I think it refers only to a host (like in "3.2 Protocol Selection"--is there any non-host that can select a protocol for its data traffic? When it's sending data traffic it's acting as a host, right?), and it would be nicer if I wasn't guessing at the intended scope.

I think there's a few ways to handle it, but my first suggestion would be to use "entity" or "entities" as-is in the definitions, and try to excise those terms from the rest of the doc, and if there are cases that can't use a word that's in the terminology section (or combinations like "nodes or links") as a substitution without losing the intended meaning, it suggests another term might be needed.

Yes, "entity" is intended to be broader than just nodes on the path and can include off-path devices like traffic engineering controllers. It doesn't have to be a physical device either, it could also be a service running "in the cloud".

I agree it would be good to substitute "entity" with a more specific term in many instances later in the document.

However, I am not sure what a good term for these is, as I'm not sure I want to overload "Node". But maybe it actually is a Node, which may be on-path or off-path, and maybe in some cases it has to be on-path? (Though I imagine there could be cases where an off-path Node actually selects a protocol that some on-path Node then uses, or at least attempts to use.)

[renghardt]

Comment from Med:

[Med] Agree. That can be captured by making sure to convey the message that these entities may not belong necessary to the data plane, but to the control plane.

 However, I am not sure what a good term for these is, as I'm not sure I want to overload "Node". But maybe it actually is a Node, which may be on-path or off-path, and maybe in some cases it has to be on-path?

[Med] Not sure about this. I'd prefer to add an entry for "entity" in Section 2 to cover the intended usage (data plane, control plane, on-path, off-path, can be a node/host).

  (Though I imagine there could be cases where an off-path Node actually selects a protocol that some on-path Node then uses, or at least attempts to use.)

[Med] Yeah, this is for example the case of ATSSS (https://tools.ietf.org/html/draft-bonaventure-quic-atsss-overview-00#section-5.3) where the network instructs the host which protocol to use for traffic steering.

[renghardt]

Feedback from the IETF 111 PANRG session: We need to be more specific.

Richard basically said it only makes sense to have the entity term if all entities have something in common, otherwise it's too abstract.

This makes me think that perhaps our list of examples of what an entity could be doing is not enough. But maybe we can distill some commonalities from that list and/or our use cases? Maybe something like, an entity observes/measures path properties (or is somehow aware of them), and it can influence the path taken by flows (e.g., Path Selection) or the flow itself (e.g., Protocol Selection and Service invocation).