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

John Strassner <strazpdj@gmail.com> Tue, 12 January 2016 03:40 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2371ACD9F for <i2nsf@ietfa.amsl.com>; Mon, 11 Jan 2016 19:40:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.099
X-Spam-Level:
X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_82=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-eU2yVY4-h5 for <i2nsf@ietfa.amsl.com>; Mon, 11 Jan 2016 19:40:02 -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 BC4F21ACDA8 for <i2nsf@ietf.org>; Mon, 11 Jan 2016 19:40:01 -0800 (PST)
Received: by mail-lf0-x236.google.com with SMTP id h129so30757055lfh.3 for <i2nsf@ietf.org>; Mon, 11 Jan 2016 19:40:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oT2HO2DF4Pox4fDThAovm8jjQRLYnQtRCNGL9VOfsPY=; b=dr3k2lA0x7TvOWSPJ7j05byuBkYHwdByGTAscgwRz05PwXagfzcALT9pmKRDut7OdH WBgkC29yEReoosn9+c4tGU687v+oWGYSkg59DrcnrEN/ue/5uVfrX80xuGHgy7XdC5Bx hgr6Z/HoIUuOlxL+pKyYUjp97tFyA9ZUUr162vl+BVk/2kU3cMwqnFx9/c0C4HnLjnQd 4nIW0/tkw1Z174LGQ9uEUt7jBSXoA/hV0GJ3H+DKConQSMLwTzYzCt0MbLx02ZWs0mwx KY0q0tJaSyv4n8T5SGTsNX5HS0lhcx6yY2GfXX/O3grECRYgFRwiYgDTWfUSYcKqb9FE eUxw==
MIME-Version: 1.0
X-Received: by 10.25.211.17 with SMTP id k17mr5687244lfg.16.1452569999979; Mon, 11 Jan 2016 19:39:59 -0800 (PST)
Received: by 10.25.89.12 with HTTP; Mon, 11 Jan 2016 19:39:59 -0800 (PST)
In-Reply-To: <C02846B1344F344EB4FAA6FA7AF481F12AED6E7A@SZXEMA502-MBS.china.huawei.com>
References: <CAJwYUrGdNiYf5fbVQ+9r0E7pMXE8-0uErrX-qxL9AFirz_8kEQ@mail.gmail.com> <4A95BA014132FF49AE685FAB4B9F17F657DB9CCD@dfweml701-chm> <CAJwYUrGo_zQtcO6g_fs=p-kegStKpXz5sY0X0Ug+9=aNtYEQ8w@mail.gmail.com> <C02846B1344F344EB4FAA6FA7AF481F12AED6E7A@SZXEMA502-MBS.china.huawei.com>
Date: Mon, 11 Jan 2016 19:39:59 -0800
Message-ID: <CAJwYUrFV=yv5zFk1Qjyv000tLuPbW3snozS7nyjcKWh7gnwDzA@mail.gmail.com>
From: John Strassner <strazpdj@gmail.com>
To: "Xialiang (Frank)" <frank.xialiang@huawei.com>, John Strassner <strazpdj@gmail.com>
Content-Type: multipart/alternative; boundary="001a114128b6dc3bf505291aceca"
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2nsf/GSeI2M0NipXd4233JjSxr-IBgWM>
Cc: "i2nsf@ietf.org" <i2nsf@ietf.org>, Linda Dunbar <linda.dunbar@huawei.com>
Subject: Re: [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: Tue, 12 Jan 2016 03:40:05 -0000

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) <frank.xialiang@huawei.com
> 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:i2nsf-bounces@ietf.org] *代表 *John Strassner
> *发送时间:* 2016年1月12日 4:19
> *收件人:* Linda Dunbar; John Strassner
> *抄送:* i2nsf@ietf.org
> *主题:* 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 <linda.dunbar@huawei.com>
> 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:i2nsf-bounces@ietf.org] *On Behalf Of *John
> Strassner
> *Sent:* Thursday, January 07, 2016 4:09 AM
> *To:* i2nsf@ietf.org
> *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