[I2nsf] Service Level Policies - Post 4: differentiating between context, conditions, and Constraints

John Strassner <strazpdj@gmail.com> Thu, 07 January 2016 10:09 UTC

Return-Path: <strazpdj@gmail.com>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id BE9A71A8865 for <i2nsf@ietfa.amsl.com>; Thu, 7 Jan 2016 02:09:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id nN9jWhfnMmND for <i2nsf@ietfa.amsl.com>; Thu, 7 Jan 2016 02:09:11 -0800 (PST)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B9D71A8864 for <i2nsf@ietf.org>; Thu, 7 Jan 2016 02:09:11 -0800 (PST)
Received: by mail-lf0-x236.google.com with SMTP id c192so152923140lfe.2 for <i2nsf@ietf.org>; Thu, 07 Jan 2016 02:09:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=PNw8w2/vlf6UhEW/a0V9mauAyjxiRP6kWDAcb/lFnr0=; b=A5aKPm/XGVuk1QrOD7vOQnye6BfKDNHR4czifceUE6eebiNAcG5LGn4Xg4ab8EH1Kt NvxM7xDy/8HgI9HPNiLIwYeSJmIXPr3WWnSJL2gaWSymIMK4St2Wim6+8g3QuuL0ERom 9FXltBad+EJpg5WPTFSpfdfthwmSrb/cVg6wrDfjg/O61OPGXzsM81yft1hLPND8sWF/ LHZL/8OzoETDW3gcyQGv/GcjIqufONqhXW7dtkprRUPtBkWn8sKv1RN3TRRc8wMmdLyI sKbccjqTxETBZxECj47gJyT37HffJ05EIJO2abYkZZ4iCOzO0is1tV9eZDZul6iaPxNC 1F8Q==
MIME-Version: 1.0
X-Received: by with SMTP id f189mr20569475lfe.70.1452161349456; Thu, 07 Jan 2016 02:09:09 -0800 (PST)
Received: by with HTTP; Thu, 7 Jan 2016 02:09:09 -0800 (PST)
Date: Thu, 7 Jan 2016 02:09:09 -0800
Message-ID: <CAJwYUrGdNiYf5fbVQ+9r0E7pMXE8-0uErrX-qxL9AFirz_8kEQ@mail.gmail.com>
From: John Strassner <strazpdj@gmail.com>
To: i2nsf@ietf.org
Content-Type: multipart/alternative; boundary=001a114114c2641d650528bba9c1
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2nsf/yHHPDaLgCAgPJifDBWZe0cbrnmE>
Subject: [I2nsf] Service Level Policies - Post 4: differentiating between context, conditions, and Constraints
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2016 10:09:13 -0000

During IETF94, I expressed discomfort with the
"Subject-Object-Action-Function" paradigm. This note defines and
differentiates between the concepts of context, constraints, and conditions.

1.  Context

There are many definitions of context. One of the most popular [1] is:

   ‘‘Context is any information that can be used to characterize the
      of an entity. An entity is a person, place, or object that is
      relevant to the interaction between a user and an application,
      the user and application themselves’’.

As stated in [2], the above definition has a number of problems. Instead,
[2] proposes the following definition:

   "The Context of an Entity is a collection of measured and/or inferred
     knowledge that describe the state and the environment in which an
     Entity exists or has existed."

The above definition enables human and or machine inference to be used to
more fully characterize the context of an Entity.

2.  Conditions

An event-condition-action (ECA) policy rule consists of three Boolean
clauses, and has the following conceptual behavior:

   IF the event_clause evaluates to TRUE
      IF the condition_clause evaluates to TRUE
         THEN execute the actions in the action_clause

Each of the above clauses may consist of one or more statements. For
example, a condition clause could be:

   if userLogin = Error AND numLoginTries > 3

3.  Constraints

A constraint is a limitation or restriction. Constraints have been used in
programming and in modeling for a long time. Constraint programming refers
to the embedding of constraints in a language; for example, most Prolog
languages include good support for constraint programming. OCL (the Object
Constraint Language) is used to specify constraints in UML.

4. Putting Context, Conditions, and Constraints Together

Given a condition, a constraint can be used to further restrict how to
satisfy the condition. Then, if a context is specified, the condition and
its constraint are bound to that context. In an ECA policy rule, the effect
of this is typically to more fully specify the condition clause.

Note, however, that constraints do not have to be used solely with
Conditions. For example, a constraint can be used to specify when it is
safe to transition to a new state. As another, more powerful, example, the
concept of a software contract [3] uses constraints to extend the
definition of Abstract Data Types to formally define the behavior of
software components. Simplifying the theory, this says the following:

  In order for a method to execute,
      a set of pre-conditions must be satisfied before the method can
      a set of post-conditions must be satisfied when the method is finished
      a set of invariants must not change their value during the execution

The set of pre- and post-conditions, along with invariants, are all
5. Proposal

Context, conditions, and constraints are separate concepts, but they fit
together naturally.

With respect to policies, if a policy is viewed as a (software) container,
then context is applied to the container (and hence, to the components of
the container).

Constraints can be applied to terms in each of the event, condition, and
action clauses of an ECA policy rule to restrict their behavior, data type,
domain and range, and so forth. The most common examples are applying
constraints to conditions or to govern the behavior of actions.

[1] Dey, A., "Providing Architectural Support for Building Context-Aware
     Applications, Ph.D. Thesis, 2000

[2] Strassner, J., et al., "The Use of Context-Aware Policies and
     Ontologies to Facilitate Business-Aware Network Management",
     Journal of Network and Systems Management (17), pg 255-284, 2009

[3] Meyer, B., "Object-Oriented Software Construction, 2nd edition,
     Prentice-Hall, ISBN:  0-13-629155-4