2. as the "Select Path Report Interpretation" is composed only of
one observation point and selector Id(s), we simply assume that
the non-selector ID(s) is the observation point. This way, we
avoid the sentence "The observationPointID SHOULD be first
Information Element and the optional processes SHOULD be last ones ."
that impose a new rule in IPFIX: the meaning of a specific I.E.
depends on the order of the I.E. in the record
I do not like this approach. If we keep the IE observationPointId,
there is no need to care about the position in the option record
where it occurs, because its semantics is always clear.
This rule has been proposed specifically so that the order is not
important.
3. If a more complex observation point is required such as an unique
ID representing a list of interfaces, a new Information Element is
defined and can be used right away.
What about a combination of 1. and 3.?
We could allow 1. for simple observation points that can be
unambiguously identified by an identifier such as the lineCardId.
In case of a complex observation point, say three line cards,
we could use an observationPointId and have another option record
that defines the observation point that is identified by
observationPointId.
We could go for that solution, even if I think that it adds complexity
to the protocol
However, I don't think that this is a good idea to specify this new
option template record with scope=observationPointId, as it can quickly
become complex and asy ou have to define the logic between multiple I.Es
Example:
- logical OR of three line cards?
- logical AND of ingress line card and egress line card ?
- <ingressInterface, LineCard> means AND, OR, CONTAINED
So I would propose a generic sentence such as: "if the
observationPointId is used in the Selection Sequence Report
Interpretation, another options template record should clearly described
the meaning of the observationPointId"