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

[John Strassner <[e-mail]>]

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) <[e-mail]
> 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:[e-mail]] *代表 *John Strassner
> *发送时间:* 2016年1月12日 4:19
> *收件人:* Linda Dunbar; John Strassner
> *抄送:* [e-mail]
> *主题:* 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 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 <[e-mail]>
> wrote:
>
> 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:[e-mail]] *On Behalf Of *John
> Strassner
> *Sent:* Thursday, January 07, 2016 4:09 AM
> *To:* [e-mail]
> *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
>
>
>
> 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
>
>
>
>
> --
>
> regards,
>
> John
>



-- 
regards,
John