Re: [I2nsf] Service Layer Policies - Post 0: note structure

[John Strassner <[e-mail]>]

Hi Linda,

you are jumping ahead :-)

First, read post 1. Aligning to PCIM is a BAD idea. Note that PCIMe will
have
a **different** set of problems, but jumping ahead, that is not advised
either.

Second, here are two fundamental problems with
subject-object-action-function:

   1) subject is currently also a condition :-(
   2) the current definition of subject prohibits deontic logic in general
        and authorization policies in particular

More later.

best regards,
John



On Mon, Dec 7, 2015 at 1:25 PM, Linda Dunbar <[e-mail]>
wrote:

> John,
>
>
>
> Thank you very much for structuring the discussion. This is very helpful.
>
>
>
>
>
> Maybe I am jumping ahead. For Post 5,  the “object” currently used in
> I2NSF framework is same as the  “Condition” in PCIM to describe the
> constraints. If no one disagree, I propose to align with PCIM, i.e. call it
> “Subject-Condition-Action-Function”.
>
>
>
> Regards,
>
> Linda
>
>
>
> *From:* I2nsf [mailto:[e-mail]] *On Behalf Of *John
> Strassner
> *Sent:* Sunday, December 06, 2015 7:00 PM
> *To:* [e-mail]
> *Subject:* [I2nsf] Service Layer Policies - Post 0: note structure
>
>
>
> The I2NSF framework draft mentions PCIM (RFC3060) and PCIMe (RFC3460) as
> possible candidates for guiding the policy structure that can be mapped to
> the Capability Layer's "Subject-Object-Action-Function" paradigm.
>
> During IETF94, I expressed discomfort with the above paradigm. However,
> this is a complex subject, and is more easily understood by breaking this
> up into smaller discussions. Here is the order of notes that I will post:
>
>
>
>    Post 0:  this post
>
>    Post 1:  problems in using PCIM
>
>    Post 2:  problems in using PCIMe
>
>    Post 3:  differentiating between groups and roles
>
>    Post 4:  differentiating between context, constraints, and conditions
>
>    Post 5:  specific worries about the "Subject-Object-Action-Function"
> paradigm
>
>    Post 6:  proposed replacement policy structure
>
>
>
> Posts 1 and 2 clarify the problems in using PCIM and PCIMe, respectively,
> which I volunteered to do.
>
>
>
> Posts 3 and 4 are fundamental to posts 5 and 6, as they represent software
> building blocks that are critical for designing and implementing Service
> Policies in a scalable and robust manner. These also expand on points in
> posts 1 and 2.
>
>
>
> Post 5 is the heart of the manner, but can't really be tackled until the
> preceding posts were done. Post 6 builds on the previous posts.
>
>
>
> regards,
>
> John
> --
>
> regards,
>
> John
>



-- 
regards,
John