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

[John Strassner <[e-mail]>]

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) <[e-mail]
> 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
> *抄送:* [e-mail]; Linda Dunbar; John Strassner
> *主题:* RE: [I2nsf] 答复: Service Level Policies - Post 4: differentiating
> between context, conditions, and Constraints
>
>
>
> 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
>
>
>
>
>
> On 11 Jan 2016, at 22:59 , Xialiang (Frank) <[e-mail]>
> wrote:
>
>
>
> 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:[e-mail] <[e-mail]>]
> *代表* John Strassner
> *发送时间**:* 2016年1月12日 11:40
> *收件人**:* Xialiang (Frank); John Strassner
> *抄送**:* [e-mail]; 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) <
> [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
>
> _______________________________________________
> I2nsf mailing list
> [e-mail]
> 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: [e-mail]
> Tel:    [phone]
> Mobile: [phone]
> ----------------------------------
>
>
>
>
> ------------------------------
>
>
> 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