You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ak...@apache.org> on 2007/10/28 01:09:28 UTC

Too much too intertwined (was Re: [Triplesec] [AuthZ] Comments on alex's proposed definitions)

David,

I divided the topic into separate threads so we can discuss each part
separately
in easy to read bite sized chunks.  This way most of us, mainly me, could
respond to
comments within a reasonable amount of time.  Divide and conquer!

These small chunks paraphrase concepts within NIST paper using simple yet
clear words
that many of us can relate to based on our experiences with authorization
without being
mathematicians.

We can elevate the conversation to that level later however we will loose
some people in
the process.  The idea is to engage as many people as possible with simple
clear descriptions.
Because we don't need to define things as a specification does to have users
give us good ideas
based on their experiences.  We just need to use clear language.  That was
the point, not to
reinvent the NIST terminology, but to state them in the IT vernacular.

There will be time for pulling out the material in the NIST paper and
discussing it's points
verbatim but first we need to discuss and identify the problem in clear
language without using
complex vocabulary on ideas that are mixed together across an email taking 5
pages.

I don't think you considered why I initially used this format. Perhaps you
may consider
breaking down your thoughts into smaller pieces?  Maybe you can reply to my
previous
posts instead of derailing those threads?

Alex

Re: Too much too intertwined (was Re: [Triplesec] [AuthZ] Comments on alex's proposed definitions)

Posted by Alex Karasulu <ak...@apache.org>.
Hi David,

Could you do me a favor and presume this conversation includes a community
of
people which have different amounts of time they can give to this. It's a
conversation
that's bigger than just you and I.  At least I think that's what we both
want it to be.

The volunteers out there don't have dedicated time like you to grok massive
emails and to read a research paper while expressing their opinions.  At
least
on the onset of the discussion.  Those that want to delve into some of the
other deeper aspects of RBAC (which there are not many) can do so and read
the NIST paper.

But we have to take this in smaller steps or we're going to loose valuable
information
that we can gather from others which may have less time they can contribute
to this
discussion.

Community and people take more than sticking to a set of facts.  We need the
wisdom
to understand that sometimes the approach matters as well.  Let's take this
slow and in
small bite sized chunks to be considerate to others.

Alex

On 10/28/07, David Jencks <da...@yahoo.com> wrote:
>
>
> On Oct 27, 2007, at 4:09 PM, Alex Karasulu wrote:
>
> > David,
> >
> > I divided the topic into separate threads so we can discuss each
> > part separately
> > in easy to read bite sized chunks.  This way most of us, mainly me,
> > could respond to
> > comments within a reasonable amount of time.  Divide and conquer!
>
> OK, I definitely should have talked about this before I commented on
> your proposed definitions.  I think we should keep all the terms in a
> proposed model in one email thread (e.g as I changed your posts to)
> since the terms are very dependent on one another and unless all
> parts of a proposed change are in one email we will not be able to
> get a consistent view of such a proposed change.  That's why I
> combined them: I can't even keep your original model in my head
> unless its on one "piece of paper".  However if you insist I will
> repost my comments as replies to your original emails.  I think that
> will result in much more confusion than keeping all the terms together.
>
> >
> > These small chunks paraphrase concepts within NIST paper using
> > simple yet clear words
> > that many of us can relate to based on our experiences with
> > authorization without being
> > mathematicians.
>
> OK, but as i tried to make clear in my comments I do not find all
> your definitions clear and they are not the same as the model in the
> NIST paper.  I believe you suggested we should make our terms and
> definitions as clear as possible so I think my pointing out where I
> find your language unclear is entirely appropriate.
> >
> > We can elevate the conversation to that level later however we will
> > loose some people in
> > the process.  The idea is to engage as many people as possible with
> > simple clear descriptions.
> > Because we don't need to define things as a specification does to
> > have users give us good ideas
> > based on their experiences.  We just need to use clear language.
> > That was the point, not to
> > reinvent the NIST terminology, but to state them in the IT vernacular.
> >
> > There will be time for pulling out the material in the NIST paper
> > and discussing it's points
> > verbatim but first we need to discuss and identify the problem in
> > clear language without using
> > complex vocabulary on ideas that are mixed together across an email
> > taking 5 pages.
> >
> > I don't think you considered why I initially used this format.
> > Perhaps you may consider
> > breaking down your thoughts into smaller pieces?  Maybe you can
> > reply to my previous
> > posts instead of derailing those threads?
>
> If you think that it is better to have shorter emails and no easy way
> to construct a proposed modified model after comments to many of
> those shorter emails, I'll be happy to take my comments apart into
> the individual emails rather than the verbatim aggregation I used.
>
> I'd like to mention why I like the NIST model:  it's really easy for
> me to figure out what it means.  I can easily see how to implement
> the data model in java, in a relational database, or even despite my
> relative lack of familiarity with ldap, in an ldap schema.  When I
> think of operations involving the model, whether it be deciding if a
> user can do something or changing their permissions or examining
> permissions, its really easy to see how to do it.  When I look at
> stuff thats not directly from the NIST model everything gets
> muddier.  This applies to my descriptions of scope and denied
> permissions and roles, and many of your proposed definitions.  I feel
> like if we don't start with the NIST model we will be wasting time
> reinventing the wheel.
> >
> > Alex
> >
>
>

Re: Too much too intertwined (was Re: [Triplesec] [AuthZ] Comments on alex's proposed definitions)

Posted by David Jencks <da...@yahoo.com>.
On Oct 27, 2007, at 4:09 PM, Alex Karasulu wrote:

> David,
>
> I divided the topic into separate threads so we can discuss each  
> part separately
> in easy to read bite sized chunks.  This way most of us, mainly me,  
> could respond to
> comments within a reasonable amount of time.  Divide and conquer!

OK, I definitely should have talked about this before I commented on  
your proposed definitions.  I think we should keep all the terms in a  
proposed model in one email thread (e.g as I changed your posts to)  
since the terms are very dependent on one another and unless all  
parts of a proposed change are in one email we will not be able to  
get a consistent view of such a proposed change.  That's why I  
combined them: I can't even keep your original model in my head  
unless its on one "piece of paper".  However if you insist I will  
repost my comments as replies to your original emails.  I think that  
will result in much more confusion than keeping all the terms together.

>
> These small chunks paraphrase concepts within NIST paper using  
> simple yet clear words
> that many of us can relate to based on our experiences with  
> authorization without being
> mathematicians.

OK, but as i tried to make clear in my comments I do not find all  
your definitions clear and they are not the same as the model in the  
NIST paper.  I believe you suggested we should make our terms and  
definitions as clear as possible so I think my pointing out where I  
find your language unclear is entirely appropriate.
>
> We can elevate the conversation to that level later however we will  
> loose some people in
> the process.  The idea is to engage as many people as possible with  
> simple clear descriptions.
> Because we don't need to define things as a specification does to  
> have users give us good ideas
> based on their experiences.  We just need to use clear language.   
> That was the point, not to
> reinvent the NIST terminology, but to state them in the IT vernacular.
>
> There will be time for pulling out the material in the NIST paper  
> and discussing it's points
> verbatim but first we need to discuss and identify the problem in  
> clear language without using
> complex vocabulary on ideas that are mixed together across an email  
> taking 5 pages.
>
> I don't think you considered why I initially used this format.  
> Perhaps you may consider
> breaking down your thoughts into smaller pieces?  Maybe you can  
> reply to my previous
> posts instead of derailing those threads?

If you think that it is better to have shorter emails and no easy way  
to construct a proposed modified model after comments to many of  
those shorter emails, I'll be happy to take my comments apart into  
the individual emails rather than the verbatim aggregation I used.

I'd like to mention why I like the NIST model:  it's really easy for  
me to figure out what it means.  I can easily see how to implement  
the data model in java, in a relational database, or even despite my  
relative lack of familiarity with ldap, in an ldap schema.  When I  
think of operations involving the model, whether it be deciding if a  
user can do something or changing their permissions or examining  
permissions, its really easy to see how to do it.  When I look at  
stuff thats not directly from the NIST model everything gets  
muddier.  This applies to my descriptions of scope and denied  
permissions and roles, and many of your proposed definitions.  I feel  
like if we don't start with the NIST model we will be wasting time  
reinventing the wheel.
>
> Alex
>