Modelling Boundaries
draft-davis-netmod-modelling-boundaries-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Nigel Davis | ||
| Last updated | 2022-10-24 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-davis-netmod-modelling-boundaries-00
WG Working Group N. Davis
Internet-Draft Ciena
Intended status: Informational 24 October 2022
Expires: 27 April 2023
Modelling Boundaries
draft-davis-netmod-modelling-boundaries-00
Abstract
Current modelling techniques appear to have boundaries that make
representation of some concepts in modern problems, such as intent
and capability, challenging. The concepts all have in common the
need to represent uncertainty and vagueness. The challenge results
from the rigidity of boundary representation, including the
absoluteness of instance value and the process of classification
itself, provided by current techniques.
When describing solutions, a softer approach seems necessary where
the emphasis is on the focus of a particular thing. Intelligent
control (use of AI/ML etc.) could take advantage of partial
compatibilities etc. if a softer representation was achieved.
The solution representation appears to require
* Expression of range, preference and focus as a fundamental part of
the metamodel
* Recursive tightening of constraints as a native approach of the
modeling technique
This lead to need to enhance the metamodel of languages that define
properties. It appears that the enhancement could be within, as
extensions to, and compatible with current definitions.
YANG is a language used to define properties and it appears that YANG
is appropriately formed to accommodate such extensions.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://example.com/LATEST. Status information for this document may
be found at https://datatracker.ietf.org/doc/draft-davis-netmod-
modelling-boundaries/.
Davis Expires 27 April 2023 [Page 1]
Internet-Draft Mobo October 2022
Discussion of this document takes place on the WG Working Group
mailing list (mailto:WG@example.com), which is archived at
https://example.com/WG.
Source for this draft and an issue tracker can be found at
https://github.com/USER/REPO.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 27 April 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Observation: Terminology . . . . . . . . . . . . . . . . 5
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Specific challenge areas - some terminology . . . . . . . 5
3.1.1. Specification of *Expectation* and *Intention* . . . 6
3.1.2. Specification of *Capability* . . . . . . . . . . . . 6
3.1.3. Expression of *Partial Visibility* (of state etc.) . 7
Davis Expires 27 April 2023 [Page 2]
Internet-Draft Mobo October 2022
3.2. Observation: Progressive Narrowing of definition . . . . 7
3.3. Observation: Definition expansion . . . . . . . . . . . . 8
3.4. Observation: Expression of capabilities . . . . . . . . . 9
3.5. Observation: Application of expression of capability . . 9
3.6. Observation: Compatibility . . . . . . . . . . . . . . . 10
3.7. Observation: Defining the boundary . . . . . . . . . . . 11
3.8. Exploration: The nature of the solution . . . . . . . . . 12
3.9. Clarification: Complex/Blurry/Fuzzy boundaries in the
solution . . . . . . . . . . . . . . . . . . . . . . . . 13
3.10. Observation: Artificial Intelligence and uncertainty . . 14
3.11. Observation: No longer instance config, everything is
expectation-intention . . . . . . . . . . . . . . . . . 15
3.12. Observation: Intention-Expectation interaction . . . . . 16
3.13. Observation: Instance state . . . . . . . . . . . . . . . 17
3.14. Observation: Foldaway complexity . . . . . . . . . . . . 17
3.15. Exploration: Focusses, boundaries and partial
descriptions . . . . . . . . . . . . . . . . . . . . . . 19
3.16. Observation: Two distinct perspectives and viewpoints . . 20
3.17. Observation: Capability in more detail . . . . . . . . . 22
3.18. Observation: Occurrence . . . . . . . . . . . . . . . . . 22
3.19. Observation: One model . . . . . . . . . . . . . . . . . 23
3.20. Observation: Partially satisfied request . . . . . . . . 24
3.21. Observation: Other solution elements that benefit . . . . 25
3.22. Observation: Outcome and Experience . . . . . . . . . . . 25
3.23. Observation: Metamodel v Model . . . . . . . . . . . . . 26
4. Solution: Formulation . . . . . . . . . . . . . . . . . . . . 26
4.1. Solution: Methodology . . . . . . . . . . . . . . . . . . 27
4.2. Solution: Considering the property . . . . . . . . . . . 27
4.3. Solution: Occurrence Specification . . . . . . . . . . . 28
4.4. Observation: Uniformity of expression . . . . . . . . . . 28
4.5. Solution: Tooling support . . . . . . . . . . . . . . . . 28
5. Target and next steps . . . . . . . . . . . . . . . . . . . . 28
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
9. Informative References . . . . . . . . . . . . . . . . . . . 30
10. Normative References . . . . . . . . . . . . . . . . . . . . 30
Appendix A. Appendix A - Problem/Solution Examples . . . . . . . 31
Appendix B. Appendix B - Sketch of an enhanced YANG form . . . . 31
B.1. Progression . . . . . . . . . . . . . . . . . . . . . . . 32
B.2. Language . . . . . . . . . . . . . . . . . . . . . . . . 32
B.3. Key concepts . . . . . . . . . . . . . . . . . . . . . . 33
B.4. Observation . . . . . . . . . . . . . . . . . . . . . . . 33
B.5. Progressing to the language . . . . . . . . . . . . . . . 34
B.6. JSONized YANG . . . . . . . . . . . . . . . . . . . . . . 34
B.6.1. JSONised Header . . . . . . . . . . . . . . . . . . . 34
B.6.2. JSONized body . . . . . . . . . . . . . . . . . . . . 36
B.7. Schema for the schema . . . . . . . . . . . . . . . . . . 38
Davis Expires 27 April 2023 [Page 3]
Internet-Draft Mobo October 2022
B.8. An example of spec occurrence and rules . . . . . . . . . 45
B.8.1. Rough notes . . . . . . . . . . . . . . . . . . . . . 45
B.9. The current schema . . . . . . . . . . . . . . . . . . . 46
B.10. YANG tree . . . . . . . . . . . . . . . . . . . . . . . . 46
B.11. Instance example . . . . . . . . . . . . . . . . . . . . 46
B.12. The extended schema . . . . . . . . . . . . . . . . . . . 46
B.13. Versioning considerations . . . . . . . . . . . . . . . . 46
Appendix C. Appendix C - My ref / your ref . . . . . . . . . . . 46
Appendix D. Appendix D - Occurrence . . . . . . . . . . . . . . 46
Appendix E. Appendix E - Narrowing, splitting and merging . . . 48
E.1. Narrowing . . . . . . . . . . . . . . . . . . . . . . . . 48
E.2. Splitting . . . . . . . . . . . . . . . . . . . . . . . . 50
E.3. Merging . . . . . . . . . . . . . . . . . . . . . . . . . 50
Appendix F. Appendix F - A traffic example . . . . . . . . . . . 51
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 51
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction
The essential challenge being considered in this paper is that of
statement of partially constrained definition of a thing (property,
collection of properties, entity, collection of entities etc.) and of
progression through stages of refinement of constraints leading
eventually potentially to precise single value forms of refinements
of that thing.
The constrained definition of a thing requires the expression of a
boundary that surrounds all allowed/possible values for that thing.
The paper will introduce the term "Occurrence" and explain that
through the progression, a single occurrence gives rise to multiple
occurrences at the next stage of refinement and that this expansion
repeats from one stage to the next.
It appears that many aspects of the industries' problems/solutions
require such a progression of gradual refinement and hence statement
of partial constraint and occurrence. However, it seems that current
languages do not readily accommodate the necessary structures. It is
possible to use existing languages, but the realization seems clumsy
and bolted on as opposed to inherent to the language.
Davis Expires 27 April 2023 [Page 4]
Internet-Draft Mobo October 2022
Considering the apparent prevalence of need for expression of ranges
and uncertainty, it seems strange that there should be no readily
available language, so part of the purpose of this paper is to
stimulate discussion to help find an appropriate existing language.
If, as appears to be the case, there is no well-suited language, then
the next obvious step is to consider extension of YANG so that it can
accommodate the need.
This paper works through an analysis expressed via threads of
observation and exploration that are then woven together to form the
fabric of the problem and solution.
In an appendix, a sketch of a YANG form of solution is set out to
assist in the understanding of the problem. It is anticipated that
the YANG form will seed advancements to the YANG language in this
area.
1.1. Observation: Terminology
We all recognize the challenge with any terminology. Terms are for
communication convenience (they are not fundamental). Unfortunately,
each term comes with baggage and each of us has a different
understanding of each term. Sometimes these differences are subtle,
but sometimes a term spreads across a very wide space.
Each key term used in this document has specific local meaning which
the authors attempt to clarify. However, it is probable that the
definitions here are too vague to ensure full shared understanding.
Ongoing work will be required.
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Analysis
The following section introduces concepts and associated terminology
and gradually assembles a picture of the needs.
3.1. Specific challenge areas - some terminology
Each of the following require, for any property, expression of range,
preference, uncertainty, interdependency etc. The specific
challenges will be discussed in following sections.
Davis Expires 27 April 2023 [Page 5]
Internet-Draft Mobo October 2022
The solution to the problem appears to need a language that supports
expression narrowing of definition such that that language can be
applied recursively to form a progression of increasingly narrowed
definitions from the very broad to the very specific.
3.1.1. Specification of *Expectation* and *Intention*
Specification of Expectation/Intention is a statement of desired
outcome/experience in terms of constraints which includes statement
of preference and acceptable value ranges etc.
This has resulted from some negotiation (or imposition) where, in a
simple case, a client and provider have formed an agreement and where
the client has an Expectation that the agreement will be fulfilled,
and the provider has an Intention to fulfil the agreement.
The expression of outcome/experience is as viewed from the outside of
the provider solution, i.e., what is exposed by the provider.
Intention is a sub-case of "Specification of *Capability*" (and
expectation is a sub-case of "Specification of *Need*" - note that
"Need" is not covered in detail in this document).
Related terms
* intent
* service
3.1.2. Specification of *Capability*
This is a statement of opportunity for behaviour to be exhibited
which includes statement of possible ranges and interdependencies
etc.
The expression of capability of a provider system, presented as that
of an opaque component, results from consideration, by the provider,
of various potential assemblies of their internal capabilities (e.g.,
can be considered as a recursion of systems of components), governed
by their business purpose etc.
It is becoming increasingly apparent that there is a need for a
machine interpretable expression of capability and hence a language
for such expression.
Most recently, specific cases of need have been identified as
automation solutions in the following areas mature:
Davis Expires 27 April 2023 [Page 6]
Internet-Draft Mobo October 2022
* Advertising capability (both at a commercial boundary and for
components in a solution)
* Negotiation towards contract (where capability requirement and
offer are refined)
* Planning infrastructure buildout (where capability of solution and
of components is required)
* Intent solution formation (intent is the result of negotiation,
expressing solution capability)
* Any situation where specialized components need to be assembled
3.1.3. Expression of *Partial Visibility* (of state etc.)
Any real environment will suffer imprecision, loss and disruption.
Any statement made about properties (behaviour, characteristics,
etc.) of things in that environment may not be fully available
(temporarily due to some impairment or permanently due to cost/
complexity (the measure is an approximation as it is not practical to
measure precisely)).
This leads to the need, for any property, to be able to state
absence, probability, uncertainty and vagueness (varying over the
lifecycle etc. as will be discussed later).
3.2. Observation: Progressive Narrowing of definition
Traditional modeling tends to lead to a class model (potentially with
inheritance), which provides precise definitions of properties etc.
(current YANG models are of this form), where each class is realized
as instances in the solution and where each instance provides a
precise value for each property defined as mandatory in the class
etc.
However, what actually appears to happen in many areas of the
solution is a process of gradual narrowing of definition where that
narrowing takes place in a progression of discrete steps.
Consider the following rough example progression (stages may be
omitted/repeated):
* A version of a standard may provide a definition of technology
capability.
Davis Expires 27 April 2023 [Page 7]
Internet-Draft Mobo October 2022
* A vendor solution may have a narrower capability than the
standard, perhaps due to a target price point etc. A vendor may
have several solutions, each with a different narrowing
* An application of the vendor solution may have a further narrowing
of capability, perhaps due to some combinatorial effect in the
deployment
* The use of a vendor capability at a particular point in a
structure of a solution may have a further narrowing of capability
as a result of need or policy at that point
* At a particular point in a structure of a solution under
particular circumstances there may be an even narrower allowed
capability, for example under certain environmental conditions the
thermal considerations may require the solution to run at low
power etc.
* Proof of concept (PoC) of the solution may have an even narrower
allowed capability
* An example diagram related to a single use case for a PoC may
require an extremely narrow definition
* Where there is delegated control, even the fully refined
"instance", perhaps in the single use case for the PoC mentioned
above, may be specified in terms of constrained definition as
opposed to absolute value.
* Etc.
Traditional Classification and statement of instance specification do
not deal with the above. Some constraint mechanisms deal with the
above in part, but these are often an afterthought, are clumsy and
have significant shortfalls as will be illustrated.
3.3. Observation: Definition expansion
In addition to the recursive reduction discussed above at each level
definition may be introduced that did not appear in the previous
stage as a result of capability from the intersection with a separate
narrowing. For example, the vendor solution may extend with
proprietary features not defined in the standard
Further, there will be evolution and growth so the next development
of the standard etc. may extend/adjust the statements.
Davis Expires 27 April 2023 [Page 8]
Internet-Draft Mobo October 2022
Of course, any definition introduced at any point in the progression
can be narrowed at the next stage of the progression.
The ultimate progression is an intertwining of expansion and
reduction stages.
3.4. Observation: Expression of capabilities
For any control solution component at any stage of the above
intertwined progression, it is necessary to understand the capability
and indeed some of the progression.
This requires runtime interpretation of expression, in normalized
uniform machine interpretable form, of the capabilities (properties
and constraints) exposed by the relevant assembly.
Traditional classification is too blunt a tool for this purpose as
will be illustrated.
3.5. Observation: Application of expression of capability
In a control system context, capability expression applies to:
* the controlled system with respect to the exposed model and
allowed activities
* the control system and its exposed capabilities (both the control
provider and control client)
Each of the above:
* is always an abstraction/view of the underling real system
* applies for any interaction at any boundary
The above may have further depth such, for example:
* the controlled system exposure can be controlled and adjusted
* the control system exposure can be controlled and adjusted
* etc.
The capability descriptions need to detail all deterministic per case
variations (not just a broad- brush statement on the model versions
supported).
Davis Expires 27 April 2023 [Page 9]
Internet-Draft Mobo October 2022
3.6. Observation: Compatibility
The following applies to any interacting entities with respect to any
aspect of interaction (e.g., a control system component interacting
with another control system component about things that are
controlled).
Note that here a component is a conceptual functional construct that
has ports through which it can communicate with other components and
that encapsulates some functional capability. Generalized component
is described in [ONF TR-512.A.2]
Two components are suitably compatible and can interact with respect
to a particular application so long as their exposed capabilities
have an appropriate/sufficient intersection.
Interaction between Semi-Compatible Entities is possible where:
* Semantic intersection enables a subset of capabilities (resulting
in a meaningful capability set).
* Partially mappable expression provides sufficient meaning (some
mappings may be approximate and partially ambiguous, but only in
areas where the this is not overly relevant)
The result of the intersection is usually a narrower statement of
capability than the statement for the two components (it most it can
be the full statement). In some cases, the intersection may be the
empty set and hence there can be no interaction opportunity.
* Where a feature is preferred but not mandatory, the empty set
intersection is acceptable
* Very few properties are fundamentally mandatory, importance is
dependent upon specific application and specific interaction
within that application.
For any interaction between two components A and B compatibility is
determined by the intersection of:
* application interaction semantic
* interface transfer capability
* component A capabilities/needs
* component B capabilities/needs
Davis Expires 27 April 2023 [Page 10]
Internet-Draft Mobo October 2022
If any of the mandatory application interaction semantic elements are
eliminated, then the interaction cannot be supported. If preferred
or optional semantic elements are eliminated, then the interaction
can be supported at some degree of degraded capability.
Note that this discussion fragment focusses on the direct interaction
and not on the implications for other interactions etc.
Compatibility must be considered over the intertwined lifecycles of
the interacting components as each independently evolves in terms of
both functional capability and interface expression. This also
includes migration of boundaries.
3.7. Observation: Defining the boundary
The general problem identified is the representation of a semantic
space by defining its boundary. Clearly, the boundary is itself
defined in terms of ranges, however, the boundary is not necessarily
defined with absolute range values, and it is not necessarily fixed
in time.
The boundary may, for example,:
* change, in position and in precision, through the lifecycle of the
thing (as it matures... where it tends to become tighter)
* be interdependent with other boundaries
* have uncertainty in position of boundary and/or limited interest
in positioning of boundary (don't know, somewhere round about
here, don't care, that's precise enough)
* also have specification (and measurement) of acceptable, degraded
and unacceptable positioning (there is also a need to indicate
other aspects, e.g., for how long a particular degradation is
acceptable or what the degradation costs etc.)
* changes of positioning and precision over time or over stages of
lifecycle
* have associated probability (likelihood of a particular
positioning) and preference (for a particular position)
The above considerations apply similarly to intent specification,
capability specification and partial visibility.
Davis Expires 27 April 2023 [Page 11]
Internet-Draft Mobo October 2022
The same challenges also appear in planning and in negotiation where
there is a need to state vaguely understood and interdependent
properties etc.
Considering lifecycle stages, a property defining a boundary of a
thing, e.g., the property acceptable temperature range, may have one
defined range at one part of the lifecycle and another defined range
at another part of the lifecycle where this variation is known at the
time of specification such that the specification needs to include
this lifecycle aspect.
The variation may be temporal or may be dependent upon some other
variable property.
3.8. Exploration: The nature of the solution
Considering the observations and other considerations above, the
solution requires support for a property to
* Be stated in terms of ranges with focusses and complex
(potentially fuzzy) boundaries where that statement defines a
semantic volume and where the boundary may not be sharp
* Have statements that interrelate it with another property (or
properties)
* Have multiple boundary preference levels and/or probability levels
where the preference/importance level is per interaction and not
an aspect of fundamental property definition
* Be defined in terms of a narrowing of a previously expressed
volume (i.e., a further narrowing) where a single point value is a
very narrow range (many single values are actually abstractions of
complex ranges, e.g. 2Mbit/s is +/-15ppm)
* Be defined in such a way that simple property definitions are not
burdened by the structures that enable sophisticated definition
(i.e., the expression should be such that the complexity of
expression "folds away" for simple statements)
* Use a representation where there is no distinction in expression
opportunity between a statement of capability definition, intent
definition, actual value etc. such that all expressions are of the
same essential form
Davis Expires 27 April 2023 [Page 12]
Internet-Draft Mobo October 2022
This is a fundamental change in the nature of the solution... a
change in paradigm and metamodel where the properties are defined by
complex/fuzzy bounded/focused spaces related to other complex/fuzzy
bounded/focused spaces with preferred/probable positions etc.
3.9. Clarification: Complex/Blurry/Fuzzy boundaries in the solution
To illustrate the complex/fuzzy boundaries, partial compatibility and
several other aspects, an example of color usage is helpful. Whilst
color may not be the most important aspect of the solution in key
industries related to this work, it is an easy example to understand.
It is suggested here that the same challenge applies to ALL
properties at least to some relevant degree.
Consider a request for a physical item that has a color where the
requestor, whilst interested in the color is not overly concerned.
Their request for the item may include an expectation on color where
that expectation is that the choice of color is not a showstopper but
there is a preference for red and if not red then green. The request
does not need to include the color and if not included a choice will
be made by the provider on some basis outside the interaction.
The provider may not know what red is but may know green and have the
item in green which will be appreciated by the client.
Even if the provider does not have green any color will do. In fact,
the provider, in its response, need not even say what the color
actually is!
However, if the client indicates that the item provided must not be
pink, then unless the provider knows what pink is, it cannot satisfy
the request and the boundary now has a hard edge, so an aspect of the
request is now mandatory.
In this case, assuming the provider does know what pink is, the
provider could respond with "the color is not pink" but provide no
more details.
In the example above the definition of color was complex/fuzzy to
some degree, the providers understanding of pink may not match the
client's exactly and the definition if the boundary between pink and
red may be unclear and vary from occasion to occasion.
Davis Expires 27 April 2023 [Page 13]
Internet-Draft Mobo October 2022
The color was specified by the client using colors by name as
enumerated literals. Now consider that the provider understand color
in RGB. It is possible that the color Red is not just 255,0,0, but
is actually a range of colors in a volume bounded on the red scale by
255 at one extreme and 240 at the other. Further, red is a complex
volume including on its boundary 255,10,10 and 250,8,8 etc.
Now when the client asks for red, the provider can select color in
the range defined.
But it may also be the case that the color is not perfect so that
there is always a little green and blue somewhere between 2 and 3 on
both scales and the red coloration process is inaccurate so that the
color produced is somewhere between 253 and 250.
Further the color fades a little over time and in some lights looks a
little more bluish. These factors may need to be taken into account
(as interactions between properties) if the request is for red and
the duration of use is to be 10 years where the usage will be in
various different lights.
So, the request for red must be qualified by the above. In a
negotiation the requestor may even have broadened their view of red
to include some maroon shades in their preference for Red, so that
may now be a list of similar colors etc.
The example above illustrates the need for the opportunity to specify
range and interrelationship as a fundamental aspect of specification
of color. The color attribute needs the opportunity to deal with the
above within its scope, not as a pile of arbitrary other properties.
On the measurement side, it may not be possible to distinguish
between anything within a range of 255 and 252 red etc. and further
if the light level is low the color measurement may dither etc.
In general, when a specific value is specified, e.g., "A" must equal
5, this equates to a fuzzy setting that has hard boundaries.
It is argued here that the above consideration applies to all
properties.
3.10. Observation: Artificial Intelligence and uncertainty
As the spread of system automation progresses, the problem becomes
increasingly complex. This leads to the necessary expansion of use
of AI/ML techniques in the solution.
Davis Expires 27 April 2023 [Page 14]
Internet-Draft Mobo October 2022
These techniques deal well with uncertainty, approximation and
fuzziness unlike traditional systems that tend to only work as
precise coded solutions and absolute values with the occasional
specific hack to deal with ranges and approximation.
AI/ML solutions would benefit from the opportunity to express range,
uncertainty etc. in any/all values/structures and to see uncertainty
in all inputs. Considering that the problem space is one of range,
preference, approximation as discussed, it seems fundamentally
necessary to expand the opportunity for expression as discussed in
this document.
3.11. Observation: No longer instance config, everything is
expectation-intention
The idea of Expectation/Intention as discussed earlier can be further
developed. Consider an example where a client has an expectation
that the integer property "A" (perhaps a temperature of an "oven"
containing a component that needs to operate within a particular
range) is to take a value between 5 and 10 (with some unit, e.g.,
Celsius. It is OK to leave the units open when there are no specific
values, but once values are being expressed, the units MUST be
provided) . The provider could have the intention to make A take the
value between 5 and 10 as requested, but to achieve this a complex
process needs to be performed so it will take time to achieve a value
in the range and there is some progression that needs to be reported.
Eventually the provider achieves a value in the target range, but it
is unable to state the value precisely as there is high-rate jitter
and hence it can report that the value is between 6 and 9.
The above example reflects the need to be able to state and report
ranges for a property.
Now consider the case where the system is more precise. The client
requires and has the expectation for A to take the value 5 (which is
simply a very narrow range from 5 to 5) and the provider has the
intention to achieve this, but again this will take time. The
provider reports progress towards 5 and eventually reports that 5 has
been achieved.
The above example reflects the need to be able report convergence on
a property value even where the value is simple. In general, the
client may want to state a maximum time allowed to achieve any
specific outcome and/or the provider may want to state a predicted
time for any specific interaction.
Davis Expires 27 April 2023 [Page 15]
Internet-Draft Mobo October 2022
Finally consider a case where the system has greater performance.
The client requires and has the expectation for A to take the value 5
and the provider the intention to achieve this. The value can be
achieved immediately, so the provider can simply report this back
directly. In this case the provider would predict an effective delay
of 0 seconds (which can be implied as the value is returned
immediately).
The final case could be viewed as a SET the property of an instance
of a class and hence special, but it is no less of an intent-
expectation case than any of the others. Indeed, it is possible that
for a particular specific intent-expectation, on some occasions the
achievement is immediate and on others it takes a while and for some
parts of the range of possible settings the value is precise, but for
other parts it is a range (perhaps at the extreme ends of operation).
Clearly, it is highly beneficial (and even arguably, necessary) to
have one uniform representation that caters for all cases. Ideally,
this method would appear as light as a SET where the value is precise
and the achievement is immediate but would deal with the
sophistication required where the value is a range, the result is a
sub-range, and it takes time to achieve the result.
Assuming that such a representation is achieved, then a traditional
"instance specification" is actually sub-case of intention/
achievement (or "intent" as defined by rough common usage) and hence
not something distinct. Indeed, the notion is that an instance is
simply an occurrence at the most extreme narrowing, the lowest and
most detailed available view, of definition and as noted above, this
lowest available (visible) view of a realization may not be precise.
There are always many details "below" this "lowest available visible
view" that are not exposed.
Any expectation/intention statement expression may have a mix of
degrees of tightness of statement from vague to single value (and
hence suitable to use for all cases of "instance specification") and
allow representation of a mix of ranges and of single values.
3.12. Observation: Intention-Expectation interaction
Clearly, a solution does not operate on a single requirement in
isolation, there may be multiple agreements and hence multiple
Intention-Expectations competing for the solution resources. Within
the expression of each Intention-Expectation there is a need to state
importance and this will interact with preemption policy.
Davis Expires 27 April 2023 [Page 16]
Internet-Draft Mobo October 2022
3.13. Observation: Instance state
As discussed above, an instance is an occurrence at the lowest and
most detailed available view at the extreme end of the narrowing. In
addition to state related to progression of achievement of
expectation/intention (traditional "config"), there is also state
related to monitored/measured properties of the solution (not
directly related to config).
These properties are derived from monitoring devices that perform
some processing of events within the solution. The events are
detected by a detector. Very few of all of the possible event
sources are monitored by detectors.
All detectors are ultimately imprecise and may fail to operate. The
information from a detector may be temporarily unavailable, delayed,
degraded etc.
The representation of the simple detected value should include
qualifications related to its quality etc.
A machine interpretable specification of capability for the property
should provide details of its derivation from other less abstracted
properties. For example, there may be a property that is detected
where the detections are counted over some period and compared with a
threshold
where the crossing of that threshold is reflected by another property
that is itself counted and compared with another threshold that if
crossed changes the state of the property of concern. An example of
a property resulting from this pattern is the Severely Error Second
alert.
Understanding this pattern and other related patterns would enable a
control solution to interpret the relationship between the various
properties (currently, at best, solutions are explicitly coded to
deal with properties with human oriented similarities).
3.14. Observation: Foldaway complexity
It was noted in an earlier section that "Ideally, this method would
appear as light ... where the value is precise and the achievement is
immediate but would deal with the sophistication required where the
value is a range, the result is a sub-range, and it takes time to
achieve the result.".
Davis Expires 27 April 2023 [Page 17]
Internet-Draft Mobo October 2022
In general, it is highly desirable for the representation of common
and simple cases to look/be simple and not be burdened by the more
sophisticated structures that allow for more complex cases. Ideally
the representation has "foldaway complexity".
An analogy can be drawn with human language grammar where the
structure that allows sophisticated speech is not visible in simple
speech.
Several sketches (in rough JSON) of a configuration statement for a
property "temperature" follow.
Basic:
"temperature":"5",
More versatile:
"temperature":{
"acceptable-range":"5-12",
"preferred-range":"7-9"
}
More sophisticated:
"temperature":{
"acceptable-range":"5-12",
"preferred-range":"7-9",
"upper-warn-threshold":"11",
"lower-warn-threshold":"6",
"Fail-alarm"{
"less-than":"5",
"greater-than":"12"
}
}
Davis Expires 27 April 2023 [Page 18]
Internet-Draft Mobo October 2022
In this example the schema for:
"temperature":{
"acceptable-range":"5-12",
"preferred-range":"7-9"
}
would identify preferred-range as optional, would identify
"acceptable-range" as mandatory and the primary property and would
identify the foldaway nature if only one value is provided in the
range:
"temperature":"6"
is conformant with the schema.
In addition, in a simple case a subset schema could be designed that
was compatible with the main schema that only allowed the single
value temperature.
Ideally, considering the common requirements across all properties,
the terms used in the schema nested within the property name would be
standard terms etc.
3.15. Exploration: Focusses, boundaries and partial descriptions
Considering the progressive narrowing of boundaries, it is possible
to consider anything as represented by a fully capable generalized
thing with constraints (everything is a focused thing). It is also
possible to consider a subset of things where the focus is thing with
ports. Not all things have ports. A thing with one or more ports
can be called a component. The component is a thing which has ports.
Anything that has ports is a component. The boundary around this
focus is the presence of ports.
A physical thing is a thing that can be measured with a ruler. Some,
but not all, things that are physical that can be measured with a
ruler have ports.
A functional thing is a thing that has behavior. A functional thing
is not physical, although it must be realized eventually by physical
things. Functional things have ports, as this is where the behavior
is exposed (although they need not be represented).
Davis Expires 27 April 2023 [Page 19]
Internet-Draft Mobo October 2022
So, there is a set of physical things disjoint from a set of
functional things and a set of components that has an intersection
with both the physical thing set and the functional thing set where
the functional thing set is a subset of the component set.
Anything that has ports is a component (as per the component-system
patter described in [ONF TR-512.A.2]). Many components will not yet
be known etc., but the semantic of "component" remains unchanged when
they are exposed. As not all components are known, not all
properties that can apply to components are known. Adding properties
does not change the semantics of "component", but it does improve the
clarity.
The progression above is essentially, specialization by narrowing of
focus. The broadest "Thing" has all possible characteristics and
capabilities. Specific semantics relate to the model of a specific
thing where that is the narrowing of the broadest thing. The
definitions do NOT need to be orthogonal/disjoint.
Consider the thing "Termination". The Termination:
* Covers all aspects of "carrier" signal processing
* includes recursive definition of encapsulated forwarding
* includes all possible properties of termination for any signal
(including those not yet defined)
* includes capabilities to extract signal content and further adapt
to anther signal
* etc.
3.16. Observation: Two distinct perspectives and viewpoints
Considering a system taking a provider role, there are two distinct
perspectives
The external perspective (the effect) - "exposed"
* Capability (advertised to enable negotiation and selection)
* Intention (the agreement resulting from the selection at the end
of negotiation)
* Achievement of intention
The internal perspective (the realization)
Davis Expires 27 April 2023 [Page 20]
Internet-Draft Mobo October 2022
* Realizations (alternative system design approaches to achieve
exposed capabilities)
* Specific chosen realization (the system to be deployed)
* Actual realization achievement
Both perspectives are expressed using the same model pattern and
model elements, i.e., the component-system pattern, where a component
is described in terms of a system of components and components are
specialized as appropriate (as discussed earlier).
There are two viewpoints:
* that of the client where only the external perspective is
available
* that of the provider where both the internal (which is private)
and external perspective are available
The provider also has control of the mapping between internal and
external perspective.
Note that:
* the provider may have distinct roles where each has access to a
subset of the provider viewpoint.
* the perspectives and viewpoints apply to both the capabilities
being controlled by the system and the capabilities supporting the
control system (which are controlled by another system).
* the external perspective relates to "Customer Facing Service" (TM
Forum, what is exposed to the customer) and the internal
perspective to "Resource Facing Service" (how it is realized
(roughly))
* At any arbitrary demarcation, the same approach may be applied
* The actual chosen demarcation may shift as the solution is
developed and evolves
* This can be stated as how it looks from the outside and how it
looks on the inside
Davis Expires 27 April 2023 [Page 21]
Internet-Draft Mobo October 2022
This is discussed further in [ONF TR-512.8] where it is noted that a
client talks through a provider port to the provider functions about
the controlled system where that controlled system is presented as a
projection that has been mapped to an appropriate abstraction of the
underlying detail.
3.17. Observation: Capability in more detail
A Capability statement is the statement of visible effect of a thing
and is not a statement of the specific realization of that thing.
The visible effect may be complex. The thing may have many ports and
activity at one port may affect activity at another. Capability
statements will include performance and cost (environmental footprint
etc.).
It is important to recognized that the statement of capability is NOT
exposing intellectual property related to how the capability is
achieved.
Expression of externally visible capability and expression of
realization of that capability can both use a model of the same types
of things, but the specific arrangement will often be very different
as the externally visible capability is a severe abstraction of the
internal realization where a subset of the capabilities of the
underlying system are offered potentially in different terminology
and in a different name space.
The approach of expression of capability can be applied recursively
at all levels of control abstraction from deep within the device to
the most abstract business level.
3.18. Observation: Occurrence
As system is constructed from components. Often a system will make
repeated use of the same type of component. Whilst in a realization
of that system the components are considered as instances, in the
design, they are clearly not instances. But there are many. The
term "Occurrence" has been used in ONF work (see [ONF TR-512]).
In a component-system approach, an Occurrence is a single use of a
particular component type in a system design structure. There may be
many uses of that type in that system design structure, and hence
many Occurrences, where each use of that type may have subtly
different narrowing of capabilities to each other use and certainly
different interconnectivity.
Capability, intent and realization are all specified in terms of
system structures and hence all require the use of Occurrence.
Davis Expires 27 April 2023 [Page 22]
Internet-Draft Mobo October 2022
Considering the "progressive narrowing" observation earlier in this
document, what is a singular thing at one level may result in several
separate things at the next level, each of which is a slightly
different narrowing of the definition of the original singular thing.
These things are Occurrences.
Hence, the progressive narrowing starts with a single Occurrence of
thing at the first level and splits this into multiple Occurrence at
the next and then each may split at the next etc.
Note that:
* the pictures of devices in a network structure example diagram are
essentially Occurrences.
* the presentation of an instance in a management view can be argued
to also be an Occurrence.
* that through each progressive narrowing of definition, what was a
single "type" at one level of narrowing may cause many
"occurrences" at the next level.
* a type is simply an Occurrence with a particular definition where
that Occurrence is used in the next level of definition as a type.
3.19. Observation: One model
From a model perspective there appears to be no relevant distinction
between what can be requested and what can be achieved. A single
model representation of the things and their effect, based upon the
recursive/fractal component-system pattern appears appropriate.
The intention/expectation is expressed in terms of a structure of
occurrence and what is realized is in terms of a similar structure of
occurrence (where at the extreme the structure is exactly the same).
There are however several stages and consequent perspectives:
* the original request (the expectation retained by the client)
* the accepted request (the intention, retained by the provider,
normally the same as the expectation)
* the achievable outcome (expressed by the provider, normally the
same as the intention)
* the current realization (more precise than the intention)
Davis Expires 27 April 2023 [Page 23]
Internet-Draft Mobo October 2022
* the effects of the realization in the perspective of the original
request (achievement)
* the difference between the client expectation and the achievement
(discrepancy)
For example:
* the client may wish to request an E-Tree with particular
characteristics including endpoints, bandwidth, temporal
characteristics etc.
* the provider may accept this minus one endpoint.
* the provider may not be able to achieve the accepted request
initially as some hardware is not yet in place
* the realization will provide subordinate details.
* the effect of the realization can be abstracted back, freed from
some irrelevant detail, to form the achievement (reflecting the
details of the original E-Tree request)
* the provider can represent the differences between the original
request and the achievement
For all of the above, the key model elements are a multi-pointed
connection and a set of terminations. The detail of the realization
is supported by a recursion of multi-pointed connections. There is
no reason for different representational forms of the different
stages of development.
3.20. Observation: Partially satisfied request
The original request from the client may not be satisfiable
* during the progression of activities formulating the solution and
acting on that formulation
* initially, although it may be later
* at some intermediate stage in the lifecycle, although it was
initially and will be again shortly
* ever
Davis Expires 27 April 2023 [Page 24]
Internet-Draft Mobo October 2022
Where there is knowledge of a temporary shortfall, expression of what
is achievable as a lifecycle of related statements appears necessary
and beneficial. Parts of this lifecycle appear to be definable
within individual properties using the mechanism in the metamodel
suggested by the various observation here.
3.21. Observation: Other solution elements that benefit
The progressive narrowing approach that yields levels of Occurrences
where those Occurrences are defined in terms of semi-constrained
properties (as discussed in this document) appears beneficial in the
construction of:
-Policy (as per general definition): The condition statement could
benefit from a generalized metamodel approach to range etc.
* Profile/Template (for all the various interpretations of these
terms): Various methods that support the specification of
constraints in a single statement to be applied multiple instances
simultaneously.
The constraint statement would benefit modeling in general. For
example, in UML, OCL is an add-on that tends to be "beyond" the
normal model. An advancement to the essential metamodel would
inherently include interaction constraints etc.
3.22. Observation: Outcome and Experience
The term Outcome is being used here to relate to the apparent/
emergent structure/capability made available by the provider and the
ongoing behavior of that structure/capability.
The term Experience is being used here to relate to the client
perception of the effect that the provider Outcome has (i.e., the
client perception of the Outcome). It can also be argued that the
Experience is the client Outcome and that the provider Experience
includes the feedback by the client on their overall experience of
the provided capability etc.
An Outcome/Experience may be a:
* Momentary event of set of events
* Constant state or set of states over time (first order)
* Constant change of state or set of state changes over time (second
order)
Davis Expires 27 April 2023 [Page 25]
Internet-Draft Mobo October 2022
* ... (nth order)
* Change of state defined some algorithm or set of changes of state
defined by a set of algorithms
* Etc.
Both outcome and experience can be expressed in using the same
approach discussed in this document.
In the connectivity example discussed earlier, considering the
client:
* the expectation for the Outcome is an E-Tree (a resource!)
* the Experience is effect of the E-Tree which is complex apparent
adjacency (the true "service", a change of apparent proximity).
3.23. Observation: Metamodel v Model
The metamodel is a model that constrains one or more other model(s).
The term metamodel is essentially about the role of the model in the
relationship to other models. The model with the metamodel role when
related to another model influences that other model and is
specifically designed to do so.
A model taking a metamodel role may express how another related model
may express properties to be represented.
Clearly a model that takes a metamodel role is just a model and hence
may have a related model that takes a metamodel role for it etc.
Note that meta means "providing information about members of its own
category" (Merriam Webster).
4. Solution: Formulation
The following subsections consider the observations from the earlier
sections and point to aspects of a potential solution.
The first few subsections consider the solution in general
independent of specific realization. The final subsection considers
the applicability of YANG. Some considerations in the realization
independent sections are already supported by YANG, others are not.
Davis Expires 27 April 2023 [Page 26]
Internet-Draft Mobo October 2022
4.1. Solution: Methodology
Each type/structure/property is specified in terms of constraints
narrowing prior definition/specification. Note that this is a common
approach, but the recursive nature is not well represented, and each
level of the recursion tends to seem special.
Examples are as discussed earlier:
* A standard may narrow an integer range
* A usage may narrow the standard integer range
* Etc.
The prior definitions must be explicitly (efficiently) referenced.
Note that this is a common approach but the specific usage here is
distinct from normal usage. Examples relate to earlier discussion:
* A prior definition may be used for several Occurrences in the same
specification
* A definition syntax may be transformed, but the semantics cannot
be changed, only narrowed
* A property may have preferred values etc.
* Etc.
4.2. Solution: Considering the property
Extending the approach could lead to a more uniform specification of
properties in a control system context.
Any property, e.g., temperature, may have combinations of the
following features:
* A detector: Allowing opportunity for approximate, unknown, range
etc. and allowing notification of change with definable approach
to hysteresis etc.
* An associated control: Which has intent, achievement etc. and,
especially where it takes time to take the control action, may
have some progress on the action etc.
* Thresholds based alerts: Which has intent (as above) and which has
an associated state (allowing opportunity for approximate etc.),
notification etc.
Davis Expires 27 April 2023 [Page 27]
Internet-Draft Mobo October 2022
* Have inter-property interrelationships for any of the above
* Have Units for any of the above
* etc.
4.3. Solution: Occurrence Specification
Any property and its range of opportunities is stated in a
specification. Any invariant values in the specification need not be
reported in the state of the "instance" (unless the instance is no
longer behaving as defined in its specification).
Ideally the metamodel should be such that, when a model designer
chooses to define a property, they pick which of the above features
are relevant and need not specify each separately. This would lead
to automatic name generation etc. where the name structure can be
predefined.
A uniform way of expressing each of the above features could be
developed as could tooling to generate the representation (e.g.,
YANG) for each feature given a property name. The application of
each feature to a property is essentially the occurrence of the
feature.
4.4. Observation: Uniformity of expression
Using a uniform and consistent expression for "occurrences" at all
levels of refinement naturally allows for expression of a mix of
constraints and absolute values.
4.5. Solution: Tooling support
Clearly, tooling support will be vital for any initiatives in this
area to be successful.
5. Target and next steps
There does not seem to be readily available terminology to label/
define the concepts in the problem space
* Hence it has been difficult to discuss what properties the
language needs to possess.
* Action: Improve terminology definitions
It appears that there is not a good language suited to solve this
problem fully.
Davis Expires 27 April 2023 [Page 28]
Internet-Draft Mobo October 2022
* This may only appear to be the case, i.e., there may be a language
out there (as it has proved very difficult to describe the
problem)
* Action: Continue to explore and refine
It is possible that YANG could evolve to be more suitable
* YANG does not have all the necessary structures or recursion
* Progress sketch for a JSON form of YANG as an illustration of the
unification of class and instance statement representation. Work
the proposal to suitable maturity (requirements first)
6. Conclusion
Tackling the challenge of modelling of boundaries leads to a more
complete method of specification of gradual refinement of definition
and of statement of "occurrences" including classes, instances and
various forms between.
This method allows for:
* Expression of range, preference and focus as a fundamental part of
the metamodel
* Gradual refinement and recursive tightening of constraints as a
native approach of the modeling technique
Gradual refinement is required in many areas of the problem/solution
space and this more complete method naturally allows for the
necessary representation of uncertainty and vagueness. The rigid
boundary representation of the current approaches (e.g., class,
instance) is accommodated within the method as a narrow case of
application of the method.
This softer and more continuous approach to specification refinement
with the opportunity for uncertainty, ranges and biases better
describes any real-world situation and hence appears more appropriate
for an intelligent control solution (using AI/ML etc.) where that
solution could take advantage of partial compatibilities etc.
It appears that the enhancements to the language metamodel could be
within, as extensions to, and compatible with current definitions of
YANG as it appears that YANG is appropriately formed to accommodate
such extensions.
Note that the problem appears in expression:
Davis Expires 27 April 2023 [Page 29]
Internet-Draft Mobo October 2022
* Intent
* Capability
* Partial Visibility
* Planning
* Negotiation
* Policy
* Profile/Template
* Occurrence
* Etc.
7. Security Considerations
None
8. IANA Considerations
This document has no IANA actions.
9. Informative References
[ONF TR-512] TR-512 Core Information Model (CoreModel) v1.5 at
https://opennetworking.org/wp- content/uploads/2021/11/TR-
512_v1.5_OnfCoreIm-info.zip (also published by ITU-T as G.7711 at
https://www.itu.int/rec/T-REC-G.7711/
recommendation.asp?lang=en&parent=T-REC-G.7711-202202-I)
[ONF TR-512.A.2] TR-512.A.2 Appendix: Model Structure, Patterns and
Architecture (in Model Description Document within [ONF TR-512])
[ONF TR-512.8]TR-512.8 Control (in Model Description Document within
[ONF TR-512])
10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Davis Expires 27 April 2023 [Page 30]
Internet-Draft Mobo October 2022
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Appendix A. Appendix A - Problem/Solution Examples
This appendix lists examples (to be expanded).
* A circuit pack with a fixed mapping that supports a narrow subset
of the capability defined in the relevant standards...
* A slot in a shelf that takes specific circuit packs
* A temperature sensor with particular range and precision
* A detector that is temporarily absent
* A detector that is degraded due to some temperature issue
* A use of an ethernet termination in a particular configuration of
functionality such as the ethernet termination in a G.8032 ring
that deals specifically with the termination of signaling traffic
* A request for an e-line where the bandwidth requirement varies
over the day
* A request for an e-line where there is an acceptable range of
bandwidths and/or a cost profile for bandwidth
* A request for an e-tree where the connectivity requirement varies
over the week
* An initial position for planning some infrastructure where the
capacity of termination is known and the building is known, but
not the specific device
* slicing where the request is for some range of capability and the
solution is an approximation to that capability where the
approximation is stated as a bounded space.
Appendix B. Appendix B - Sketch of an enhanced YANG form
In this appendix a sketch of a language, that is a development of
YANG, that resolves some of the issues is set out. The language is
not completely formed, and it is not the intention that this
necessarily be the eventual expression, this is simply used for
illustrative purposes.
Davis Expires 27 April 2023 [Page 31]
Internet-Draft Mobo October 2022
B.1. Progression
Using this language, a progression of increasingly specific models
can be set out (as set out in the main body of this document). The
refinements at each stage would be in terms of reduction of semantic
scope compared to the previous stage. At an early stage of
refinement, the component-system pattern emerges.
The language provides definitions for terminology (in a name space)
where each term is defined by the specific narrowing (note that the
terms are simply a human convenience).
The progression is not a partition. It does not divide the space up
into a taxonomy. The progression does lead to sets of capability
where those sets may intersect etc.
A traditional model is replaced by what is emergent at a stage in the
recursion. A label (in a label space) chosen for a semantic volume
should not be reused for anything else. Once defined the label
should never be deleted, although it can be obsoleted (i.e., not
expected to be used).
If the label is encountered, its definition should be available such
that it can be fully interpreted. The label may apply in a narrow
application and hence the narrowing definition should be available.
B.2. Language
As noted, it appears that there is not a good language suited to
solve this problem fully. This may only appear to be the case, i.e.,
there may be a language out there, as it has proved very difficult to
describe the problem (there does not seem to be readily available
terminology for the concepts in the problem space) and hence it has
been difficult to discuss what properties the language needs to
possess.
To cut through this, the best approach appeared to be to sketch a
language and show how it could be applied to hopefully tease out an
existing language that could then solve the problem (or so it can be
a basis of a new language).
As noted earlier, considering the general and apparently broad extent
of the problem, it seems strange that there is not an appropriate
machine interpretable language of expression available. It is
possible that existing languages can be used to deal with the problem
in a somewhat cumbersome way and that this has not yet been observed.
Cumbersomeness can be refined out over time. Preferably there will
not need to be Yet Another Language!
Davis Expires 27 April 2023 [Page 32]
Internet-Draft Mobo October 2022
B.3. Key concepts
Recursive narrowing appears to give rise to "occurrences", where each
of a set of occurrences is in part the same as and in part different
from each other. Curiously:
* there also appears to be a parallel with the specific approach to
specialization taken in ONF (and in YANG models using augment)
where a "class" is actually a narrowed "occurrence" of a more
general metaclass (see earlier discussion). The distinction in
the general thinking is that there are no specific meta-levels.
Narrowing can take place through a recursive continuum until all
properties have been constrained to absolute precision (which is
actually never possible as there is always some uncertainty,
rounding etc.).
* When all properties have been constrained the result is the
statement of a unique instance at a moment in time (where each
occurrence has a lifecycle which intertwines with the lifecycles
of other occurrences). But this instance is itself an opaque
representation of the effect of underlying detail.
* this approach seems to point to some usages of the term "instance"
being flawed and that actually the supposed instance is an
"occurrence".
Definitions may be of some type and may cover a subrange of that
type. Even in an occurrence that is traditionally called an
instance, the property values may be ranges. The key difference for
the properties of an instance is that they are unlikely to be further
decomposed.
B.4. Observation
At all levels of the recursion there is a mix of schema definition
and absolute value (instance values). So, some of the information in
a spec looks like instance data and some like schema. This should
not be surprising when observing through the lens of recursive
narrowing and of occurrence.
Curiously a YANG model definition has instance like data and schema
data in it. For example, there is instance like data at the
beginning of the definition with things like module, namespace,
prefix etc. YANG does not appear uniform in its representation of
instance like data and schema data.
The example language developed here attempts to achieve greater
uniformity.
Davis Expires 27 April 2023 [Page 33]
Internet-Draft Mobo October 2022
B.5. Progressing to the language
Taking JSON as a language of expression of instances and setting out
a YANG definition in a JSONized form appeared to allow a uniform
blend of instance and schema.
It has been recognized that YIN is a more well-structured form of
YANG that points further towards this, and a JSONized form of YIN
looked like the hand crafted JSONized YANG that has been constructed
here (exploring the expression of recursive narrowing).
JSON has also been simplified here in that every property value is
considered as a string and hence in quotes (even numeric quantities).
It is not intended that any eventual language is restricted in this
way, the approach just simplifies the representation and resultant
discussion.
Note that regardless of the form of language chosen, there will be a
need to enhance tooling etc. It is intended that the approach should
evolve in small backward compatible increments and hence it may be
possible to identify value-justified increments in tooling.
B.6. JSONized YANG
The following two snippets show the instance-like header and the
schema data in a JSONized form.
B.6.1. JSONised Header
The opening of a YANG module (called a header in this document) is
normally of a form illustrated in the example below:
module equipment-spec-xyz {
yang version "1.1";
namespace "urn:onf:otim:yang:spec-occurrence:equp-spec-xyz{uuid}";
prefix equip;
etc.
In the JSONized form all of the fields are assumed to be "instance"
values (where it is assumed that a higher level of specification has
specified these). The JSONized form of the example (extended with
some other suggested fields) is:
"module" : {
Davis Expires 27 April 2023 [Page 34]
Internet-Draft Mobo October 2022
"name": "equipment-spec-xyz{uuid}"
"yang-version" : "x.y",
"namespace" : "urn:onf:otim:yang:spec-occurrence:equp-spec-xyz{uuid}",
"prefix" : "equip",
"import" : [
{
"name" : "module",
"prefix" : "mod"
}
{
....
"occurrence-encoding" : "JSON", //Field to explain encoding
"rule-encoding" : "OCL", //Field to explain encoding
"utilized-schema": [ //Ref schema at next higher "occurrence" level
{
"namespace" : "urn:company:yang:holder-schema-xyz{uuid}",
"prefix" : "holder"
}
{
"namespace" : "urn:company:yang:tapi-spec",
"prefix" : "tapi-spec"
}
{
"namespace" : "urn:onf:otcc:yang:tapi-equipment",
Davis Expires 27 April 2023 [Page 35]
Internet-Draft Mobo October 2022
"prefix" : "tapi-equipment"
...
}
{
"namespace" : "urn:onf:otcc:yang:tapi-occurrence",
...
}
{
"namespace" : "urn:company:yang:equp-schema-abc{uuid}",
"prefix" : "equipment"
}
...
"augment": [
{
"path" : "..."
}
...
B.6.2. JSONized body
The core of a YANG module (called a body in this document) is
normally of a form illustrated in the example of a fragment below:
Davis Expires 27 April 2023 [Page 36]
Internet-Draft Mobo October 2022
grouping connection {
list connection-end-point {
uses connection-end-point-ref;
key 'topology-uuid node-uuid nep-uuid cep-uuid';
config false;
min-elements 2;
description "none";
}
list lower-connection {
uses connection-ref;
key 'connection-uuid';
....
In the JSONized form all of the fields are assumed to be "instance"
values (where it is assumed that a higher level of specification has
specified these). The JSONized form of the example (extended with
some other suggested fields) is:
Davis Expires 27 April 2023 [Page 37]
Internet-Draft Mobo October 2022
"grouping":{
"name" : "connection",
"list": {
"name" : "connection-end-point",
"uses" : "connection-end-point-ref",
"key" : "topology-uuid node-uuid nep-uuid cep-uuid",
"config" : "false",
"min-elements" : "2",
"description" : "none"
},
"list": {
"name" : "lower-connection",
"uses" : "connection-ref",
"key" : "connection-uuid",
"config" : "false",
"description" : "none"
},
Notice the uniformity/consistency between the representations of the
header and the body.
B.7. Schema for the schema
With this a YANG model can define a YANG model (within reason... and
probably similar to other self-defining languages - improvements
could probably be made to make this more possible).
Considering an extract from tapi-equipment formulated in JSONized
YANG:
Davis Expires 27 April 2023 [Page 38]
Internet-Draft Mobo October 2022
"grouping":{
"name":"common-equipment-properties",
"description":"Properties common to all aspects of equipment",
"leaf": {
"name" : "asset-instance-identifier",
"type" : "string",
"description" : "none"
},
"leaf": {
"name" : "is-powered",
"type" : "string",
"description" : "none"
},
"leaf": {
"name" : "equipment-type-name",
"type" : "string",
"description" : "none"
},
"leaf": {
"name" : "manufacture-date",
"type" : "string",
"description" : "none"
},
"leaf": {
Davis Expires 27 April 2023 [Page 39]
Internet-Draft Mobo October 2022
"name" : "serial-number",
"type" : "string",
"description" : "none"
},
"leaf": {
"name" : "temperature",
"type" : "decimal64",
"description" : "none"
},
It is expected that the above model would have been derived from a
broader model and that it would reference that model.
In the following development of the model a reference would be
provided back to the model above.
This could be used as a general definition, then constrained for a
particular application as follows:
"grouping":{
"name":"common-equipment-properties",
"description":"Properties common to all aspects of equipment",
"leaf": {
"name" : "asset-instance-identifier",
"type" : "string",
"pattern" : "^[0-9a-zA-Z]+"$, // A narrowing constraint.
"description" : "none"
},
"leaf": {
"name" : "is-powered",
Davis Expires 27 April 2023 [Page 40]
Internet-Draft Mobo October 2022
"type" : "string",
"supported-constraint" : "NOT_SUPPORTED",//A narrowing.
"description" : "none"
},
"leaf": {
"name" : "equipment-type-name",
"type" : "string",
"description" : "none"
},
"leaf": {
"name" : "manufacturer-date",
"type" : "string",
"description" : "none"
},
"leaf": {
"name" : "serial-number",
"type" : "string",
"description" : "none"
},
"leaf": {
"name" : "temperature",
"type" : {
"name":"decimal64",
"fraction-digits":"1", // A narrowing constraint.
Davis Expires 27 April 2023 [Page 41]
Internet-Draft Mobo October 2022
"range" : "0.0..100.0",
"precision":"+0.2,-0.2"
},
"units" : "Celcius", // A narrowing constraint.
"description" : "The temperature of the boiler."
},
Which could be summarized with a reference to the earlier schema and
then as follows, where the absent fields are unchanged from the
earlier schema and the fields mentioned simply show the change/
addition:
Davis Expires 27 April 2023 [Page 42]
Internet-Draft Mobo October 2022
"grouping":{
"name":"common-equipment-properties",
"utilized-schema" : "tapi-equipment", //The reference
"leaf": {
"name" : "asset-instance-identifier",
"pattern" : "[0-9a-zA-Z]"
},
"leaf": {
"name" : "is-powered",
"supported-constraint" : "NOT_SUPPORTED"
},
"leaf": {
"name" : "temperature",
"fraction-digits": "1",
"range" : "0.0... 100.0",
"units" : "Celcius"
},
And eventually instance values can be mixed with schema...
"grouping":{
"name":"common-equipment-properties",
"description":"Properties common to all aspects of equipment",
"utilized-schema" : "tapi-equipment",
"asset-instance-identifier" : "JohnsAsset"
"leaf": {
Davis Expires 27 April 2023 [Page 43]
Internet-Draft Mobo October 2022
"name" : "equipment-type-name",
"type" : "string",
"description" : "none"
},
"leaf": {
"name" : "manufacturer-date",
"type" : "string",
"description" : "none"
},
"leaf": {
"name" : "serial-number",
"type" : "string",
"description" : "none"
},
"leaf": {
"name" : "temperature",
"type" : "decimal64",
"range" : "0.0... 100.0",
"units" : "Celcius",
"description" : "none"
},
Davis Expires 27 April 2023 [Page 44]
Internet-Draft Mobo October 2022
Notice that as with normal JSON the name of the property "asset-
instance-identifier" is followed by its value (or json-object). The
"utilized-schema" has defined "asset-instance-identifier" and the
utilization method hence allows the property to either be defined
further or narrowed to a fixed value. There are clearly "key words"
such as "leaf" that will have been defined in an "earlier" schema, so
something like:
"field": {
"name":"leaf",
"type": "strings"
...
And further there would need to be a definition of "name" and "type"
etc. and their usage in a structure.
B.8. An example of spec occurrence and rules
This example detail will be added in a later version.
B.8.1. Rough notes
Considering an occurrence of holder in a spec for an equipment, there
is a need to identify all compatible equipment types (i.e., that that
holder can accommodate). Each type would be associated with a
general spec of capability and that spec would relate to the specific
application (in the holder) either directly (as the holder is fully
capable or the spec is specific to the holder) or via some variables
in the spec (that allow modulation of the spec statements).
There are also combinatorial rules. For example, a slot may not be
equipped if blocked by a wide card. This can be represented
by....Wide card
It is possible that there are multi-slot compatibility rules.
The functional capability may be simply the capability of the
equipment type, but there is often functionality that emerges from a
combination of hardware.
In this case an equipment may support some fully formed capabilities
and some capability fragments that need to be brought together with
other fragments to support a meaningful function.
Davis Expires 27 April 2023 [Page 45]
Internet-Draft Mobo October 2022
In some cases, functionality from one piece of hardware might compete
with functionality from another or functionality might be completely
nullified by the presence of another specific piece of hardware.
The equipment-type-identifier is the reference to the equipment spec.
This brings details of size and capability.
It is assumed that the holder specification would provide width,
position etc. and that there could be a general understanding of
size, or there could be a more abstract representation to enable
overlap to be accounted for.
B.9. The current schema
This detail will be added in a later version of this document.
B.10. YANG tree
This detail will be added in a later version of this document.
B.11. Instance example
This example detail will be added in a later version of this
document.
B.12. The extended schema
This detail will be added in a later version of this document.
B.13. Versioning considerations
This detail will be added in a later version of this document.
Appendix C. Appendix C - My ref / your ref
This appendix will cover "my ref/your ref" naming in relationship to
intention/expectation. The detail will be added in a later version
of this document.
Appendix D. Appendix D - Occurrence
An "occurrence" at one level of specification is a narrow
("specialized") use of an "occurrence" at the previous higher level
of specification. There will be many "occurrences" at a lower level
derived from an "occurrence" at a higher level. The "occurrences" at
the lower level will be distinct from each other.
Davis Expires 27 April 2023 [Page 46]
Internet-Draft Mobo October 2022
Considering the problem space, "Thing" has the broadest spread of
semantics covering everything. Function could be considered as a
narrowed thing covering only functional aspects and not physical
aspects. Termination covers only those functions related to
terminating a signal (and not those related to conveying it
unchanged.
Considering the formulation of a traditional model, a specific
object-class (e.g., Termination Point) is a specific name for an
"occurrence" at one level of narrowing ("specialization"). The name
object-class is a specific "name" for an "occurrence" at the previous
higher level. That previous higher level is called the metamodel in
this naming scheme. This is more a narrowing of how to express as
opposed to what to express.
Considering the traditional model, "Thing" is effectively an object-
class. Considering "Component-System", "Thing" has ports/facets, as
do all of its derivatives (unless, of course, they have been narrowed
away). The "Component-System" formulation is essentially a narrowing
of the expression opportunity in the broadest of problem space
considerations at a higher level than "Thing". It effectively
provides a quantized representation of a continuous space allowing
representation of a refinement of conceptual parts.
In the generalized "occurrence" approach, no specific names are given
to the levels and the levels are intentionally not normalized. The
approach allows any number of levels, and the number of levels in one
"branch" does not need to match the number of levels in another. The
approach allows for whatever degrees of gradual refinement are
necessary.
So, a traditional "instance" is also an "occurrence" where it is an
"occurrence" of specific object- class, i.e., of an "occurrence" at
the previous higher level. The "instances" is a leaf in the
metamodel structure.
In the generalized "occurrence" approach there is no specific end
leaf. Even when the model level has only fully resolved specific
values, it is possible to merge in a model with non-specific value
"occurrences" and continue to refine.
A specific occurrence:
* Is narrowing of a previously defined occurrence (where there may
be many separate distinct narrowings defined at that "level", many
occurrences
* Is a mixture of absolute values and definitions
Davis Expires 27 April 2023 [Page 47]
Internet-Draft Mobo October 2022
* May be a merge of narrowed previously defined occurrences (where
the semantic phase is shifting)
* Is the basis for further narrowing
It also appears that an absolute value of a property at one level may
be considered as an unstated approximation of a non-fully resolved
property at the next level down. For example, a statement of 2 at
one level, refines to 2+/- 15ppm over a short period at the next as
the visibility "improves". This seems to say that all levels have a
natural uncertainty that may not be known and hence need not be
stated.
Appendix E. Appendix E - Narrowing, splitting and merging
E.1. Narrowing
On the most abstract level is "thing" - without any stated parameter,
hence without any constraints. "thing" is anything without
restriction and can take any shape etc. All possible properties are
allowed without restriction (they do have to be declared, but there
is no boundary as to what is allowed to be declared). The declared
properties are of "thing". It is a semantic set including every
possible behavior etc. and all parameters possible.
At the next level of narrowing, some behaviors and hence possible
parameters are eliminated and some constrained versions of allowed
parameters are exposed. At this point, a convenient name for the
specific narrowing can be provided and later references. However,
this can also be considered still as "thing".
In the most complete realization, the semantic boundary would be
fully defined such that properties on the boundary were appropriately
constrained and properties beyond the boundary eliminated. For
example, a termination-point cannot have a temperature. So, an
expression eliminating this possibility would be necessary and so on
for all other properties that cannot be supported. In a more
practical implementation, most properties that are beyond the
boundary can be assumed to be known to be beyond the boundary and
only those with complex constraints need to be stated.
When narrowing "thing", what it can be is reduced and hence so are
the parameters that can be exposed. For example, if it is not
physical, I cannot expose the parameters for weight.
As the "thing" is narrowed the properties that are allowed to be
exposed reduces, but there is a tendency to have more properties
exposed as more and more properties become constrained. For example,
Davis Expires 27 April 2023 [Page 48]
Internet-Draft Mobo October 2022
color may be irrelevant and hence not exposed or constrained for some
of the broader "occurrences", but as the narrowing process approaches
the useful definitions, the color becomes constrained and useful, and
hence exposed.
Through the narrowing process the set of opportunities becomes
smaller and "lighter weight" (possibilities), but more is exposed
(semantic mass reduces, semantic visibility increases).
Consider an equipment. It is a physical thing. It may be narrowed
to the point where it is constrained such that it can only be plugged
into a slot. It is still an equipment, albeit a constrained forms of
the general equipment properties for an application. The equipment
has a property "requires-slot" set to true. During the first
formulation, color may be of no relevance and hence is not exposed.
Just because it is not important does not mean that the equipment
does not have a color, it means that it is not relevant. It can take
any color and I don't care.
Later, the color becomes important and hence it is exposed and later
still it becomes necessary to choose to constrain the allowable
colors for an application. It is still an equipment, but it has a
spec that constrains what is allowed. The spec is for a narrow form
of equipment. It can still be considered as an equipment even though
it is a narrow case. It can also be considered as a "thing" with
exactly the stated property with some further directly stated
constraints.
Narrowing could be considered as pruning (removal of unwanted parts).
For example, take a property (leaf/structure in general) from the
higher occurrence and potentially:
* Reduce its legal range (perhaps to a single value) of the type.
Note that changing the type is allowed if the new type covers the
same semantics as the old type. So, Integer to real seems OK and
Enum to its corresponding semantic space dimensions seems OK
(e.g., color Enum to RGB ranges)
* Specify the units where relevant (or change the units)
* Relate its value to other property values such that its value is
constrained
* Remove the property completely
* Change its name (label) to one that represents the narrow version
of the broader property, for example, component --> termination-
point
Davis Expires 27 April 2023 [Page 49]
Internet-Draft Mobo October 2022
This is how modelling is often carried out although it is never
formally described as a method. Consider the termination point, the
model is for any connection at any layer etc, and there are
"profiles" of parameters for particular technologies which augment
the termination point. The profiles may may add (actually expose)
further parameters for the same technology or for new technologies,
but termination point can never have weight as a parameter and
certainly cannot be sat on!!
YANG augment is the same process in general, so YANG is positioned
appropriately to be the language for this approach.
Interestingly, an AI solution may eventually prefer to use semantics
closer to thing than to EthernetTerminationPoint as it can deal with
the shades of specification of general things.
E.2. Splitting
Splitting semantics is relatively straight forward. Two distinct
occurrences each narrowed from the same higher-level occurrence where
the two new occurrences have distinct characteristics.
E.3. Merging
As everything is an "occurrence" of thing, everything has a common
highest level of thing. When merging, it may be necessary to go some
way back towards that common highest level.
Where the two occurrences are disjoint in distinct characteristics
and identical in common characteristics, merging is simply a union.
The result may adopt the label of the shared higher level or may have
a new label depending upon the labeling (naming) strategy.
Where common characteristics are not identical:
* one may be a simple superset of the other in which case the
superset is adopted.
* There may be contradictions in the two specifications in which
case there needs to be a simple precedence, e.g., Not overrides
Must,
Where merging two (or more) properties from higher models into one
property
* There must be a new name for this rephasing of the semantic if
neither of the source properties were derived from an origin with
the same breadth of space as the new property
Davis Expires 27 April 2023 [Page 50]
Internet-Draft Mobo October 2022
* One of the names can be taken if it earlier in the narrowing
corresponded to the superset of the new merged result
For example, TerminationPoint narrowed to have no OAM capabilities
and then OAM picked up and merged in (again) at some later stage so
that this is still TerminationPoint (but it is NOT OAM).
For example, a narrow form of TerminationPoint (processes of traffic
at a point) and a narrow form Connection (conveys traffic of space
with no transformation) merged into a (strange) long termination that
does some distributed processing of traffic. This is neither a
TerminationPoint nor a Connection. It could revert to Component with
full spec, or it could become a ProcessingSpan (or similar).
Appendix F. Appendix F - A traffic example
This example detail will be added in a later version of this
document.
Acknowledgments
Contributors
Martin Skorupski
highstreet technologies
Email: martin.skorupski@highstreet-technologies.com
Author's Address
Nigel Davis
Ciena
Email: ndavis@ciena.com
Davis Expires 27 April 2023 [Page 51]