[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] New core and multiple resource profile and hierarchical
Daniel, These replies contain no explanation as to their basis. You are simply making opposite assertions and not backing it up with any basis. For example: "DAG describes what to apply precisely."DAG only selects ancestors. It decides which ancestors based only on the fact a relation exists and does not distinguish one relation from another. It uses limited information and produces limited results based on that information. Unfortunately, it throws away useful information which is why it is more limited, less useful model than forest. It is fine for applications that do not require the additional info, but useless for those that do. Here is a second example: "What ever is the intended chain of command can be presented to PDP as a list of ancestors without any problem."The DAG presents list of ancestors as described in section 3.2. If that works for some application like source code control or subassemblies, then I agree there is no problem. If you need accountable lines of authority then DAG "is the problem". And this: "You have created a definition of "hierarchy" that is not applicable and trying to shoehorn it into the profile."If you read the text you quoted as the basis of this comment, you would see that I asserted that "The DAG is inherently is multiple "overlapping" hierarchies that can be combined into a "single multiroot hierarchy"" and gave a reference for that assertion. In addition, the original Hierarchical Profile defines "In this Profile, a resource organized as a hierarchy may be a “tree” (a hierarchy with a single root) or a “forest” (a hierarchy with multiple roots), but the hierarchy may not have cycles. Another term for these two types of hierarchy is “Directed Acyclic Graph” or “DAG”." This definition clearly combines trees (hierarchies with single roots) into a forest (a hierarchy with multiple roots) and calls it a DAG. The reference I gave provides substance around this assertion and also provides the necessary context to begin to disambiguate what is clearly a problem with this spec that it incorrectly equates DAG and forest. It is when we disambiguate that we find that both models are indeed represented in the spec, however incompletely and in a confusing manner. I am concerned that none of the DAG proponents seem to be able to give any kind of explanation of precisely how DAG can avoid finding policies that it considers "applicable" when no such applicability is intended. I expect the reason is that DAG simply cannot do this and for some reason, the DAG proponents choose to assert that "one size fits all". Again, I repeat, my proposal does not remove any DAG capabilities. It simply provides clarity as to the choice of DAG and forest and allows implementers and policy designers to pick what is appropriate for their applications. And, again I repeat, I am not adding any functionality to the spec, I am simply explaining what is already there by disentangling the current confusing presentation and simply saying these capabilities apply to DAG, and these other capabilities apply to forest. Unfortunately, the only rebuttal appears to be that only DAG will be supported and anything else frowned upon, which requires removing clearly intended functionality from what is currently in the spec. Thanks, Rich Daniel Engovatov wrote:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]