[Onsen] Dynamic service requirements: how intent handles them as process

[Christopher Janz <[e-mail]>]

Hi all -

At the Vienna meeting, one line of discussion concerned whether to extend
service models to represent dynamic, time-varying behaviour. I would
suggest we look first at how that need may be met by process rather than in
a model, because work on intent has already addressed it as process

In the intent paradigm a requirement that varies over time is carried by a
negotiation before acceptance and re-negotiated during a life cycle after
it, over a nominally stable intent form. The framework is specified:
normatively in ETSI GS ZSM 016 (intent-driven closed loops), on the generic
aspects in ETSI GR ZSM 011, and in TM Forum's consonant intent management
(IG1253, with feasibility, best and judge operations and a life-cycle
interface). (On the IETF/IRTF side, RFC 9315 has intent and its
pre-acceptance refinement, but does not address negotiation and life
cycle.) So before extending service YANG models with temporal constructs,
it is worth considering whether the negotiation-and-life-cycle pattern
already suffices.

This bears on another topic from the meeting too: the expressed interest in
more parametric and less technology-specific service models, though the
connection is not quite an obvious one. It is tempting to ask how abstract
a model must be before it counts as intent, but in truth that is something
of a red herring. What actually distinguishes intent is functional: intent
suits a strict partition between a service consumer and a service provider
- a buyer and a seller where that fits - and keeps their decision realms
unblurred. A service expression that does not require the consumer to learn
anything of a provider's environment and concerns, or to take part in any
degree in its delivery decision-making, is an intent, however abstract or
not it appears. One that does blur in that way is not intent, whatever its
abstraction. A connectivity service given as topology, endpoints in
consumer-native terms and parametric descriptions of attributes, reposes
fully on the consumer native-information side and is definitely an
intent-compatible model/expression. But a model that is merely
technology-specific but otherwise implementation-neutral is at least
intent-proximate, depending on how it is used.

I've attached a short factual note comparing how RFC 9315, ETSI ZSM and TM
Forum treat intent interaction and life cycle, with clause references, in
case helpful.

Best,

Chris