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

From: John Strassner <[email-masked]>
Date: Thu, 7 Jan 2016 02:09:09 -0800

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
situation
      of an entity. An entity is a person, place, or object that is
considered
      relevant to the interaction between a user and an application,
including
      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
      ENDIF
   ENDIF

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
execute
      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
constraints.
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

-- 
regards,
John

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 8 Jan 2016 17:51:14 +0000

John,

Thank you very much for clarifying the differences among

The term “Object” in I2NSF was intended for describing all three “Context, Conditions and Constraints”.
I agree it is not very straight forward definition.

Do you Suggest I2NSF should have something like:

Within the frame of “Subject - <xxx> - Action –Function”, <xxx> is the combination of “Context, Conditions and Constraints”.

Should we call it “CCC”?  Or do you have a better term?

Linda

From: I2nsf [mailto:[email-masked]] On Behalf Of John Strassner
Sent: Thursday, January 07, 2016 4:09 AM
To: [email-masked]
Subject: [I2nsf] Service Level Policies - Post 4: differentiating between context, conditions, and Constraints

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

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

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

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:

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

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.

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 execute
      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 constraints.
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

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

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Mon, 11 Jan 2016 12:19:22 -0800

Hi Linda,

The answer depends if I2NSF wants to pursue authorization policies and/or
deontic or alethic logic.

If any of the above three are true, then "Subject" must change.

If we step back for a moment and think about the definition of an ECA
policy rule (event-condition-action), then I remain unconvinced why this is
not sufficient for us at the moment. More specifically:

   1) Subject-Object-Action-Function does not have a facility for
representing Events, which start policy processing
   2) Subject, as currently defined, is just part of a condition
   3) Object, as currently defined, is also just part of a condition (more
specifically, object constraints do NOT apply to anything else)
   4) Function(al profile) needs more specificity, but appears to be able
to be covered by metadata (see below).

So, if we view a policy rule as a **container**, then the container
aggregates both metadata and content. Metadata can be prescriptive and/or
descriptive; content is the type of policy (or set of policies) contained
in the container.

This is the subject of my last 2 remaining posts, but in a nutshell, I do
not see a need for using Subject-Object-Action-Function, since this
introduces non-standard terminology, and the terms are unclear. If the
objective is **just** to categorize what type of processing can be done by
an NSF, **and if** it is desired to link I2NSF to policy, then I don't see
why we can't use a standard ECA policy, augmented with metadata, to do this.

regards,
John

On Fri, Jan 8, 2016 at 9:51 AM, Linda Dunbar <[email-masked]>
wrote:

> Within the frame of “Subject - <xxx> - Action –Function”, <xxx> is the
> combination of “Context, Conditions and Constraints”.
>
>
>
> *From:* I2nsf [mailto:[email-masked]] *On Behalf Of *John
> Strassner
> *Sent:* Thursday, January 07, 2016 4:09 AM
> *To:* [email-masked]
> *Subject:* [I2nsf] Service Level Policies - Post 4: differentiating
> between context, conditions, and Constraints
>
>
>
> ·  The set of pre- and post-conditions, along with invariants, are all
> constraints.
>
> 5. Proposal
>
>
>
> ·  [1] Dey, A., "Providing Architectural Support for Building
> Context-Aware
> ·  [3] Meyer, B., "Object-Oriented Software Construction, 2nd edition,

-- 
regards,
John

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Tue, 12 Jan 2016 02:29:20 +0000

Hi all,
John, thanks a lot for the clarification of “context, condition, constraint”.
And I think your understanding about current I2NSF capability interface IM design below is correct. So, I am not against to use ECA model instead of current “subject-object-action-function” model.
My concern is even we agree ECA is a more complete and standard model for I2NSF, we still need to specify an extended ECA model which incorporate necessary security characteristic, which is our next step work.

B.R.
Frank

发件人: I2nsf [mailto:[email-masked]] 代表 John Strassner
发送时间: 2016年1月12日 4:19
收件人: Linda Dunbar; John Strassner
抄送: [email-masked]
主题: Re: [I2nsf] Service Level Policies - Post 4: differentiating between context, conditions, and Constraints

Hi Linda,

The answer depends if I2NSF wants to pursue authorization policies and/or deontic or alethic logic.

If we step back for a moment and think about the definition of an ECA policy rule (event-condition-action), then I remain unconvinced why this is not sufficient for us at the moment. More specifically:

   1) Subject-Object-Action-Function does not have a facility for representing Events, which start policy processing
   2) Subject, as currently defined, is just part of a condition
   3) Object, as currently defined, is also just part of a condition (more specifically, object constraints do NOT apply to anything else)
   4) Function(al profile) needs more specificity, but appears to be able to be covered by metadata (see below).

So, if we view a policy rule as a **container**, then the container aggregates both metadata and content. Metadata can be prescriptive and/or descriptive; content is the type of policy (or set of policies) contained in the container.

This is the subject of my last 2 remaining posts, but in a nutshell, I do not see a need for using Subject-Object-Action-Function, since this introduces non-standard terminology, and the terms are unclear. If the objective is **just** to categorize what type of processing can be done by an NSF, **and if** it is desired to link I2NSF to policy, then I don't see why we can't use a standard ECA policy, augmented with metadata, to do this.

regards,
John

On Fri, Jan 8, 2016 at 9:51 AM, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
John,

Linda

From: I2nsf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of John Strassner
Sent: Thursday, January 07, 2016 4:09 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [I2nsf] Service Level Policies - Post 4: differentiating between context, conditions, and Constraints

1.  Context

2.  Conditions

3.  Constraints

--
regards,
John

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Mon, 11 Jan 2016 19:39:59 -0800

Hi Frank,

by "extended ECA model which incorporate necessary security characteristic",
do you mean adding a new clause to the ECA model, or can these extensions
be handled by extending the individual event, condition, and action clauses
with metadata (applied to the container and/or the clauses)?

regards,
John

On Mon, Jan 11, 2016 at 6:29 PM, Xialiang (Frank) <[email-masked]

> And I think your understanding about current I2NSF capability interface IM
> design below is correct. So, I am not against to use ECA model instead of
> current “subject-object-action-function” model.
>
> My concern is even we agree ECA is a more complete and standard model for
> I2NSF, we still need to specify an extended ECA model which incorporate
> necessary security characteristic, which is our next step work.
>
>
>
> B.R.
>
> Frank
>
>
>
> *发件人:* I2nsf [mailto:[email-masked]] *代表 *John Strassner
> *发送时间:* 2016年1月12日 4:19
> *收件人:* Linda Dunbar; John Strassner
> *抄送:* [email-masked]
> *主题:* Re: [I2nsf] Service Level Policies - Post 4: differentiating

-- 
regards,
John

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Tue, 12 Jan 2016 05:59:38 +0000

Hi John,
Maybe both. Right now I am not sure~~
But I hope the latter case is enough to address the whole problems.

BTW, I want to note that your ECA model is not essentially different from current “subject-object-action-function” model. Of course, ECA is more mature and widely used.

B.R.
Frank

发件人: I2nsf [mailto:[email-masked]] 代表 John Strassner
发送时间: 2016年1月12日 11:40
收件人: Xialiang (Frank); John Strassner
抄送: [email-masked]; Linda Dunbar
主题: Re: [I2nsf] 答复: Service Level Policies - Post 4: differentiating between context, conditions, and Constraints

Hi Frank,

by "extended ECA model which incorporate necessary security characteristic", do you mean adding a new clause to the ECA model, or can these extensions be handled by extending the individual event, condition, and action clauses with metadata (applied to the container and/or the clauses)?

regards,
John

On Mon, Jan 11, 2016 at 6:29 PM, Xialiang (Frank) <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,
John, thanks a lot for the clarification of “context, condition, constraint”.
And I think your understanding about current I2NSF capability interface IM design below is correct. So, I am not against to use ECA model instead of current “subject-object-action-function” model.
My concern is even we agree ECA is a more complete and standard model for I2NSF, we still need to specify an extended ECA model which incorporate necessary security characteristic, which is our next step work.

B.R.
Frank

发件人: I2nsf [mailto:[email-masked]<mailto:[email-masked]>] 代表 John Strassner
发送时间: 2016年1月12日 4:19
收件人: Linda Dunbar; John Strassner
抄送: [email-masked]<mailto:[email-masked]>
主题: Re: [I2nsf] Service Level Policies - Post 4: differentiating between context, conditions, and Constraints

Hi Linda,

regards,
John

Linda

1.  Context

2.  Conditions

3.  Constraints

--
regards,
John

--
regards,
John

--
regards,
John

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Tue, 12 Jan 2016 15:01:36 +0000

Hi Frank,

While the informal semantics of ECA-plus-metadata and subject-object-action-function may be essentially the same (and I agree they are) I think we should look for a sound formal framework, well aligned with current practice in the field, and therefore I’d support moving in the direction proposed by John.

Be goode,

On 11 Jan 2016, at 22:59 , Xialiang (Frank) <[email-masked]<mailto:[email-masked]>> wrote:

Hi John,

B.R.
Frank

发件人: I2nsf [mailto:[email-masked]] 代表 John Strassner
发送时间: 2016年1月12日 11:40
收件人: Xialiang (Frank); John Strassner
抄送: [email-masked]<mailto:[email-masked]>; Linda Dunbar
主题: Re: [I2nsf] 答复: Service Level Policies - Post 4: differentiating between context, conditions, and Constraints

Hi Frank,

regards,
John

B.R.
Frank

Hi Linda,

regards,
John

Linda

1.  Context

2.  Conditions

3.  Constraints

5. Proposal

--
regards,
John

--
regards,
John

--
regards,
John
_______________________________________________
I2nsf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2nsf

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 12 Jan 2016 17:53:46 +0000

John, ,

I always think that ECA (Event- Condition-Action) is a big Umbrella, with

-        Event == Packet reception

-        Condition == “subject”  (which are the bits & bytes in the incoming packets)  & “object” (which is not from the incoming packets, i.e. timer, states, buffer value, threshold, constraints, etc).

-        Action == “simple actions” || “function calls” || etc.

What do you think?

Linda

From: Xialiang (Frank)
Sent: Tuesday, January 12, 2016 12:00 AM
To: John Strassner
Cc: [email-masked]; Linda Dunbar
Subject: 答复: [I2nsf] 答复: Service Level Policies - Post 4: differentiating between context, conditions, and Constraints

Hi John,

B.R.
Frank

Hi Frank,

regards,
John

B.R.
Frank

Hi Linda,

regards,
John

Linda

1.  Context

2.  Conditions

3.  Constraints

--
regards,
John

--
regards,
John

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Tue, 12 Jan 2016 21:51:45 +0000

Hi Frank,

I view ECA as slightly different than "subject-object-action-function" (SOAF) in two areas:

1.       ECA has events that trigger policy evaluation; SOAF does not
Benefits:

·         Events are used to deterministically define if and when a policy is evaluated

·         Simulated events can be used to test and debug the system

2.       Constraints can be applied to event, condition, and action clauses; SOAF forces constraints to be bound to conditions
Benefits:

·         constraints enable the characteristics of clauses to be dynamically modified at runtime without having to modify the actual clause (e.g., same clause can be fine-tuned to take contextual changes into account)

regards,
John

Hi John,

B.R.
Frank

Hi Frank,

regards,
John

B.R.
Frank

Hi Linda,

regards,
John

Linda

1.  Context

2.  Conditions

3.  Constraints

--
regards,
John

--
regards,
John

Dr Diego R. Lopez
Telefonica I+D

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Wed, 13 Jan 2016 01:13:52 +0000

Hi John,
Can you give a simple example for further clarification?
Thanks!

B.R.
Frank

发件人: John Strassner
发送时间: 2016年1月13日 5:52
收件人: Xialiang (Frank); John Strassner
抄送: [email-masked]; Linda Dunbar; John Strassner
主题: RE: [I2nsf] 答复: Service Level Policies - Post 4: differentiating between context, conditions, and Constraints

Hi Frank,

regards,
John

Hi John,

B.R.
Frank

Hi Frank,

regards,
John

B.R.
Frank

Hi Linda,

regards,
John

Linda

1.  Context

2.  Conditions

3.  Constraints

--
regards,
John

--
regards,
John

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]<mailto:[email-masked]>
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

---

From: John Strassner <[email-masked]>
Date: Fri, 15 Jan 2016 19:48:25 -0800

Hi Frank,

I'm not sure what you are asking for; I'm assuming that the first part
about Events is self-explanatory.

With respect to the second difference, a constraint is different than a
condition. Think of a constraint as an assertion that is defined in the
model itself. (An assertion is a predicate (i.e., a statement that
evaluates to either true or false); examples of assertions date back to
Hoare logic (1969) and Design by Contract [3]).

Constraints may be made up of three elements:

   - invariants:  rules that are always true for an object during its
lifetime
   - pre-condition: must be true prior to executing an operation
   - post-condition: must be true after an operation has finished execution

All three of these specify behavior without stating the algorithm or
implementation responsible for the behavior.

This definition of constraints is far more complete than that contained in
the current framework document, and can be used to more precisely specify
operation in a system. Which, for security, is typically a good thing. :-)

regards,
John

-

On Tue, Jan 12, 2016 at 5:13 PM, Xialiang (Frank) <[email-masked]

> *发件人:* John Strassner
> *发送时间:* 2016年1月13日 5:52
> *收件人:* Xialiang (Frank); John Strassner
> *抄送:* [email-masked]; Linda Dunbar; John Strassner
> *主题:* RE: [I2nsf] 答复: Service Level Policies - Post 4: differentiating
> 2.       Constraints can be applied to event, condition, and action
> clauses; SOAF forces constraints to be bound to conditions
> Benefits:
>
> ·         constraints enable the characteristics of clauses to be
> dynamically modified at runtime without having to modify the actual clause
> (e.g., same clause can be fine-tuned to take contextual changes into
> account)
>
>
>
> regards,
>
> John
>
>
>
>
>
> On 11 Jan 2016, at 22:59 , Xialiang (Frank) <[email-masked]>
> wrote:
>
>
>
> Hi John,
>
> BTW, I want to note that your ECA model is not essentially different from
> current “subject-object-action-function” model. Of course, ECA is more
> mature and widely used.
>
>
>
> B.R.
>
> Frank
>
>
>
> *发件人**:* I2nsf [mailto:[email-masked] <[email-masked]>]
> *代表* John Strassner
> *发送时间**:* 2016年1月12日 11:40
> *收件人**:* Xialiang (Frank); John Strassner
> *抄送**:* [email-masked]; Linda Dunbar
> *主**题**:* Re: [I2nsf] 答复: Service Level Policies - Post 4:
> differentiating between context, conditions, and Constraints
>
>
>
> Hi Frank,
>
>
>
> On Mon, Jan 11, 2016 at 6:29 PM, Xialiang (Frank) <
> [email-masked]> wrote:
>
> Hi all,
>
> *发件人**:* I2nsf [mailto:[email-masked]] *代表* John Strassner
> *发送时间**:* 2016年1月12日 4:19
> *收件人**:* Linda Dunbar; John Strassner
> *抄送**:* [email-masked]
> *主**题**:* Re: [I2nsf] Service Level Policies - Post 4: differentiating
> [email-masked]
> ------------------------------
>
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
>

-- 
regards,
John

---

From: John Strassner <[email-masked]>
Date: Sat, 16 Jan 2016 14:51:55 -0800

Hi Linda,

sorry for the delay, I missed this email. For me, I don't think of packet
reception as an event. This is because semantically, you would be using
both the event and the condition clause to say that something is happening
in the packet. I realize I am possibly being nit-picky here.

For me, events are occurrences that are significant to the management
system, such as logon and logoff events, and the receipt of alarms.

regards,
John

On Tue, Jan 12, 2016 at 9:53 AM, Linda Dunbar <[email-masked]>
wrote:

> -        Condition == “subject”  (which are the bits & bytes in the
> incoming packets)  & “object” (which is not from the incoming packets, i.e.
> timer, states, buffer value, threshold, constraints, etc).
>
> *From:* Xialiang (Frank)
> *Sent:* Tuesday, January 12, 2016 12:00 AM
> *To:* John Strassner
> *Cc:* [email-masked]; Linda Dunbar
> *Subject:* 答复: [I2nsf] 答复: Service Level Policies - Post 4:
> *主题**:* Re: [I2nsf] 答复: Service Level Policies - Post 4: differentiating
> *主题**:* Re: [I2nsf] Service Level Policies - Post 4: differentiating

-- 
regards,
John

---

From: "Xialiang (Frank)" <[email-masked]>
Date: Mon, 18 Jan 2016 07:42:00 +0000

Hi John,
Thank you! I can understand your clarification in theory.
I just think a concrete example for the use of event and constraint is very useful for us to be more clear~~

B.R.
Frank

发件人: John Strassner [mailto:[email-masked]]
发送时间: 2016年1月16日 11:48
收件人: Xialiang (Frank); John Strassner
抄送: John Strassner; [email-masked]; Linda Dunbar
主题: Re: 答复: [I2nsf] 答复: Service Level Policies - Post 4: differentiating between context, conditions, and Constraints

Hi Frank,

I'm not sure what you are asking for; I'm assuming that the first part about Events is self-explanatory.

With respect to the second difference, a constraint is different than a condition. Think of a constraint as an assertion that is defined in the model itself. (An assertion is a predicate (i.e., a statement that evaluates to either true or false); examples of assertions date back to Hoare logic (1969) and Design by Contract [3]).

   - invariants:  rules that are always true for an object during its lifetime
   - pre-condition: must be true prior to executing an operation
   - post-condition: must be true after an operation has finished execution

All three of these specify behavior without stating the algorithm or implementation responsible for the behavior.

This definition of constraints is far more complete than that contained in the current framework document, and can be used to more precisely specify operation in a system. Which, for security, is typically a good thing. :-)

regards,
John

•

On Tue, Jan 12, 2016 at 5:13 PM, Xialiang (Frank) <[email-masked]<mailto:[email-masked]>> wrote:
Hi John,
Can you give a simple example for further clarification?
Thanks!

B.R.
Frank

发件人: John Strassner
发送时间: 2016年1月13日 5:52
收件人: Xialiang (Frank); John Strassner
抄送: [email-masked]<mailto:[email-masked]>; Linda Dunbar; John Strassner
主题: RE: [I2nsf] 答复: Service Level Policies - Post 4: differentiating between context, conditions, and Constraints

Hi Frank,

•         Events are used to deterministically define if and when a policy is evaluated

•         Simulated events can be used to test and debug the system

•         constraints enable the characteristics of clauses to be dynamically modified at runtime without having to modify the actual clause (e.g., same clause can be fine-tuned to take contextual changes into account)

regards,
John

Hi John,

B.R.
Frank

Hi Frank,

regards,
John

B.R.
Frank

Hi Linda,

regards,
John

Linda

1.  Context

2.  Conditions

3.  Constraints

--
regards,
John

--
regards,
John

Dr Diego R. Lopez
Telefonica I+D

e-mail: [email-masked]<mailto:[email-masked]>
Tel:    +34 913 129 041<tel:%2B34%20913%20129%20041>
Mobile: +34 682 051 091<tel:%2B34%20682%20051%20091>
----------------------------------

--
regards,
John

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 27 Jan 2016 21:53:56 +0000

John,

For the Interface to Flow based Network Security Functions, we would assume that the NSF has a ON session with the Controller. Therefore,  the relevant events for I2NSF should be more limited, shouldn’t include “logon or off”, should it?

I can see “Alarms” or “Threshold crossing” can relevant events for I2NSF. What do you think?

Linda

From: John Strassner [mailto:[email-masked]]
Sent: Saturday, January 16, 2016 4:52 PM
To: Linda Dunbar; John Strassner
Cc: Xialiang (Frank); [email-masked]
Subject: Re: ECA umbrella - with "Condition" being the I2NSF's Subject-Object : [I2nsf] 答复: Service Level Policies - Post 4: differentiating between context, conditions, and Constraints

Hi Linda,

sorry for the delay, I missed this email. For me, I don't think of packet reception as an event. This is because semantically, you would be using both the event and the condition clause to say that something is happening in the packet. I realize I am possibly being nit-picky here.

For me, events are occurrences that are significant to the management system, such as logon and logoff events, and the receipt of alarms.

regards,
John

On Tue, Jan 12, 2016 at 9:53 AM, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
John, ,

What do you think?

Linda

From: Xialiang (Frank)
Sent: Tuesday, January 12, 2016 12:00 AM
To: John Strassner
Cc: [email-masked]<mailto:[email-masked]>; Linda Dunbar
Subject: 答复: [I2nsf] 答复: Service Level Policies - Post 4: differentiating between context, conditions, and Constraints

Hi John,

B.R.
Frank

Hi Frank,

regards,
John

B.R.
Frank

Hi Linda,

regards,
John

Linda

1.  Context

2.  Conditions

3.  Constraints

--
regards,
John

--
regards,
John

--
regards,
John

--
regards,
John

---

From: John Strassner <[email-masked]>
Date: Wed, 27 Jan 2016 16:02:47 -0800

Hi Linda,

logon and logoff were simply examples, and certainly were not exclusive.
Though personally, I am not sure why security functions wouldn't care about
logon and logoff events.

I dislike the notion of a threshold crossing as an event, because threshold
values are typically test in the condition part of the rule. This would
"double count" the threshold event.

regards,
John

On Wed, Jan 27, 2016 at 1:53 PM, Linda Dunbar <[email-masked]>
wrote:

> John,
>
>
>
> For the Interface to Flow based Network Security Functions, we would
> assume that the NSF has a ON session with the Controller. Therefore,  the
> relevant events for I2NSF should be more limited, shouldn’t include “logon
> or off”, should it?
>
>
>
> *From:* John Strassner [mailto:[email-masked]]
> *Sent:* Saturday, January 16, 2016 4:52 PM
> *To:* Linda Dunbar; John Strassner
> *Cc:* Xialiang (Frank); [email-masked]
> *Subject:* Re: ECA umbrella - with "Condition" being the I2NSF's
> Subject-Object : [I2nsf] 答复: Service Level Policies - Post 4:

-- 
regards,
John

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 28 Jan 2016 20:45:28 +0000

John,

Are you saying a  Controller  “logging on/off”  to the NSFs?  In order for NSFs to get dynamic rules (policies) from a Controller, the controller has to be logged on to the NSFs.

Or do you mean a specific Virtual Network controller “logging on/off” to the NSFs?

Would you think that “Starting Time” can be  classified as an event for rules to NSFs?

Thanks, Linda

From: John Strassner [mailto:[email-masked]]
Sent: Wednesday, January 27, 2016 6:03 PM
To: Linda Dunbar
Cc: Xialiang (Frank); [email-masked]
Subject: Re: ECA umbrella - with "Condition" being the I2NSF's Subject-Object : [I2nsf] 答复: Service Level Policies - Post 4: differentiating between context, conditions, and Constraints

Hi Linda,

logon and logoff were simply examples, and certainly were not exclusive. Though personally, I am not sure why security functions wouldn't care about logon and logoff events.

I dislike the notion of a threshold crossing as an event, because threshold values are typically test in the condition part of the rule. This would "double count" the threshold event.

regards,
John

On Wed, Jan 27, 2016 at 1:53 PM, Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
John,

Linda

From: John Strassner [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Saturday, January 16, 2016 4:52 PM
To: Linda Dunbar; John Strassner
Cc: Xialiang (Frank); [email-masked]<mailto:[email-masked]>
Subject: Re: ECA umbrella - with "Condition" being the I2NSF's Subject-Object : [I2nsf] 答复: Service Level Policies - Post 4: differentiating between context, conditions, and Constraints

Hi Linda,

regards,
John

What do you think?

Linda

From: Xialiang (Frank)

Hi John,

B.R.
Frank

Hi Frank,

regards,
John

B.R.
Frank

Hi Linda,

regards,
John

Linda

1.  Context

2.  Conditions

3.  Constraints

--
regards,
John

--
regards,
John

--
regards,
John

--
regards,
John

--
regards,
John

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 29 Jan 2016 14:12:35 -0500

On 01/27/2016 07:02 PM, John Strassner wrote:
> Hi Linda,
>
> logon and logoff were simply examples, and certainly were not 
> exclusive. Though personally, I am not sure why security functions 
> wouldn't care about logon and logoff events.

I see logon/logoff events reported in my logwatch emails all the time.  
I consider them security events.

>
> I dislike the notion of a threshold crossing as an event, because 
> threshold values are typically test in the condition part of the rule. 
> This would "double count" the threshold event.
>
> regards,
> John
>
>     For the Interface to Flow based Network Security Functions, we
>     would assume that the NSF has a ON session with the Controller.
>     Therefore,  the relevant events for I2NSF should be more limited,
>     shouldn’t include “logon or off”, should it?
>
>     *From:*John Strassner [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     *Cc:* Xialiang (Frank); [email-masked] <mailto:[email-masked]>
>     sorry for the delay, I missed this email. For me, I don't think of
>     packet reception as an event. This is because semantically, you
>     would be using both the event and the condition clause to say that
>     something is happening in the packet. I realize I am possibly
>     being nit-picky here.
>
>     For me, events are occurrences that are significant to the
>     management system, such as logon and logoff events, and the
>     receipt of alarms.
>
>     regards,
>
>     John
>
>     On Tue, Jan 12, 2016 at 9:53 AM, Linda Dunbar
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     John, ,
>
>     -Event == Packet reception
>
>     -Condition == “subject”  (which are the bits & bytes in the
>     incoming packets)  & “object” (which is not from the incoming
>     packets, i.e. timer, states, buffer value, threshold, constraints,
>     etc).
>
>     -Action == “simple actions” || “function calls” || etc.
>
>     What do you think?
>
>     Linda
>
>     *From:*Xialiang (Frank)
>     *Cc:* [email-masked] <mailto:[email-masked]>; Linda Dunbar
>     BTW, I want to note that your ECA model is not essentially
>     different from current “subject-object-action-function” model. Of
>     course, ECA is more mature and widely used.
>
>     B.R.
>
>     Frank
>
>     *发件人**:*I2nsf [mailto:[email-masked]] *代表***John
>     Strassner
>     *发送时间**:*2016年1月12日11:40
>     *收件人**:*Xialiang (Frank); John Strassner
>     *抄送**:[email-masked] <mailto:[email-masked]>; Linda Dunbar
>     *主题**:*Re: [I2nsf] 答复: Service Level Policies - Post 4:
>     by "extended ECA model which incorporate necessary security
>     characteristic", do you mean adding a new clause to the ECA model,
>     or can these extensions be handled by extending the individual
>     event, condition, and action clauses with metadata (applied to the
>     container and/or the clauses)?
>
>     regards,
>
>     John
>
>     On Mon, Jan 11, 2016 at 6:29 PM, Xialiang (Frank)
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>     And I think your understanding about current I2NSF capability
>     interface IM design below is correct. So, I am not against to use
>     ECA model instead of current “subject-object-action-function” model.
>
>     My concern is even we agree ECA is a more complete and standard
>     model for I2NSF, we still need to specify an extended ECA model
>     which incorporate necessary security characteristic, which is our
>     next step work.
>
>     B.R.
>
>     Frank
>
>     *发件人**:*I2nsf [mailto:[email-masked]
>     <mailto:[email-masked]>] *代表***John Strassner
>     *发送时间**:*2016年1月12日4:19
>     *收件人**:*Linda Dunbar; John Strassner
>     *抄送**:[email-masked] <mailto:[email-masked]>
>     *主题**:*Re: [I2nsf] Service Level Policies - Post 4:
>     If we step back for a moment and think about the definition of an
>     ECA policy rule (event-condition-action), then I remain
>     unconvinced why this is not sufficient for us at the moment. More
>     specifically:
>
>        3) Object, as currently defined, is also just part of a
>     condition (more specifically, object constraints do NOT apply to
>     anything else)
>
>        4) Function(al profile) needs more specificity, but appears to
>     be able to be covered by metadata (see below).
>
>     So, if we view a policy rule as a **container**, then the
>     container aggregates both metadata and content. Metadata can be
>     prescriptive and/or descriptive; content is the type of policy (or
>     set of policies) contained in the container.
>
>     This is the subject of my last 2 remaining posts, but in a
>     nutshell, I do not see a need for using
>     Subject-Object-Action-Function, since this introduces non-standard
>     terminology, and the terms are unclear. If the objective is
>     **just** to categorize what type of processing can be done by an
>     NSF, **and if** it is desired to link I2NSF to policy, then I
>     don't see why we can't use a standard ECA policy, augmented with
>     metadata, to do this.
>
>     regards,
>
>     John
>
>     On Fri, Jan 8, 2016 at 9:51 AM, Linda Dunbar
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     John,
>
>     Within the frame of “Subject - <xxx> - Action –Function”, <xxx> is
>     the combination of “Context, Conditions and Constraints”.
>
>     *From:*I2nsf [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *John Strassner
>     *To:* [email-masked] <mailto:[email-masked]>
>     *Subject:* [I2nsf] Service Level Policies - Post 4:
>     As stated in [2], the above definition has a number of problems.
>     Instead, [2] proposes the following definition:
>
>     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:
>
>     Each of the above clauses may consist of one or more statements.
>     For example, a condition clause could be:
>
>     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.
>
>     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.
>
>     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:
>
>     · The set of pre- and post-conditions, along with invariants, are
>     all constraints.
>
>     5. Proposal
>
>     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.
>

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 29 Jan 2016 14:15:16 -0500

On 01/28/2016 03:45 PM, Linda Dunbar wrote:
>
> John,
>
> Are you saying a  Controller  “logging on/off”  to the NSFs?  In order 
> for NSFs to get dynamic rules (policies) from a Controller, the 
> controller has to be logged on to the NSFs.
>

Any system that is important to network security should have its 
logon/off monitored.  I might expect that any Controller interaction 
will be over long running sessions, so there logging of rekeying of said 
sessions.

> *From:*John Strassner [mailto:[email-masked]]
> *Sent:* Wednesday, January 27, 2016 6:03 PM
> *To:* Linda Dunbar
> assume that the NSF has a ON session with the Controller. Therefore, 
>  the relevant events for I2NSF should be more limited, shouldn’t 
> include “logon or off”, should it?
>
> Subject-Object : [I2nsf] 答 复: Service Level Policies - Post 4: 
> packet reception as an event. This is because semantically, you would 
> be using both the event and the condition clause to say that something 
> is happening in the packet. I realize I am possibly being nit-picky here.
>
> -Condition == “subject”  (which are the bits & bytes in the incoming 
> packets)  & “object” (which is not from the incoming packets, i.e. 
> BTW, I want to note that your ECA model is not essentially different 
> from current “subject-object-action-function” model. Of course, ECA is 
> more mature and widely used.
>
> B.R.
>
> Frank
>
> *发件人**:*I2nsf [mailto:[email-masked]] *代表***John Strassner
> *发送时间**:*2016年1月12日11:40
> characteristic", do you mean adding a new clause to the ECA model, or 
> can these extensions be handled by extending the individual event, 
> condition, and action clauses with metadata (applied to the container 
> and/or the clauses)?
>
> regards,
>
> John
>
> interface IM design below is correct. So, I am not against to use ECA 
> model instead of current “subject-object-action-function” model.
>
> My concern is even we agree ECA is a more complete and standard model 
> for I2NSF, we still need to specify an extended ECA model which 
> incorporate necessary security characteristic, which is our next step 
> work.
>
> B.R.
>
> Frank
>
> *主题**:*Re: [I2nsf] Service Level Policies - Post 4: differentiating 
> policy rule (event-condition-action), then I remain unconvinced why 
> this is not sufficient for us at the moment. More specifically:
>
> 3) Object, as currently defined, is also just part of a condition 
> (more specifically, object constraints do NOT apply to anything else)
>
> aggregates both metadata and content. Metadata can be prescriptive 
> and/or descriptive; content is the type of policy (or set of policies) 
> contained in the container.
>
> This is the subject of my last 2 remaining posts, but in a nutshell, I 
> do not see a need for using Subject-Object-Action-Function, since this 
> objective is **just** to categorize what type of processing can be 
> done by an NSF, **and if** it is desired to link I2NSF to policy, then 
> I don't see why we can't use a standard ECA policy, augmented with 
> metadata, to do this.
>
> regards,
>
> John
>
> The above definition enables human and or machine inference to be used 
> to more fully characterize the context of an Entity.
>
> 2. Conditions
>
> 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.
>
> 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.
>
> 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:
>
> 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