Consider adding "Target property"

[renghardt]

Via Last Call comment by @boucadair:

(1) Several application/services manipulate not only observed/assessed values, but can also set objectives/targets. I suggest we provision a new entry to cover that:

NEW: Target property: An objective that is set for a property over a path, subpath, or network. For example, the maximum one-way delay to be observed by packets transmitted from a node. Such properties can be captured on service requests (e.g., Section 4.1.1.1 of [I-D.ietf-teas-ietf-network-slices]).

[cyrill-k]

If I understand the idea of a target property and the IETF network slicing draft correctly, then a target property would be either an SLO or an SLE, right?

I think it could be useful to have a target property, but I'm not convinced it is necessary to have a separate definition for it. In Section 3.1, we more-or-less describe such a target property with different objectives (must involve specific nodes such as firewalls, low one-way delay paths, high BW paths). If we introduce a new definition of target property, then some of this text could be written more concisely.

Also, similar to Spencer's point, since target properties relate to how endpoints interact with the PAN, it may make more sense to not define it in this document but a later, more appropriate document. In this document in Section 3.1, we could then just use existing terms to describe the use cases, such as SLO and SLE and reference the IETF network slicing draft.

@theri what do you think?

[renghardt]

Having read Section 4.1 of draft-ietf-teas-ietf-network-slices, I agree that an SLO is essentially a target path property. Not sure about SLEs, they appear to be somewhat more abstract, and Section 4.1.2 of draft-ietf-teas-ietf-network-slices says "SLEs may be seen as aspirational on the part of the customer, and they are expressed as behaviors that the provider is expected to apply to the network resources used to deliver the IETF Network Slice service. Of course, over time, it is possible that mechanisms will be developed that enable a customer to verify the provision of an SLE, at which point it effectively becomes an SLO." Path properties in draft-irtf-panrg-path-properties can be observed/measured or assessed (we have definitions for these), which means that there are "mechanisms […] that enable a customer to verify the provision of an SLE". That said, I guess Section 3.1 of draft-irtf-panrg-path-properties does describe both SLOs and SLEs, i.e., involving a specific firewall seems more like a "Security SLE" than an SLO.

I am not sure if draft-irtf-panrg-path-properties should attempt to neatly classify target properties as SLOs or SLEs, and I actually think it might be easier to just add the "Target Property" definition, give SLOs and SLEs as an example (there are other ways to conceptualize target properties for sure), and then use "target property" in Section 3.1. When doing so, Section 3.1 could also explicitly point out the relationship between target properties and observed/assessed properties. Currently, we define observed property and assessed property, but we never use these definitions.

I agree that a future document could expand on the interaction between entities when doing Path Selection, who exactly measures properties and how, etc. But I don't think this should preclude us from talking about target properties in this draft already.

So, what do you think about adding the "target property" definition and rewriting Section 2.1 to use that definition as well as the "observed property" and "assessed property"?