[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Minutes 11 September TC Meeting
Rich, All, I think the pseudo code is fine as well, so either way is good for me. But I don't understand all your objections in your email. The proposed description is not written in a formal logic, it's written in English, which I think is fine for this purpose. I don't think there is any ambiguity in the proposed text. Perhaps it's missing the implied step "0. Evaluate all rules". The remaining steps refer to the results from this initial step. And the pseudo code is not formal logic either, so it is as ambiguous as the natural language text. In any case, we need to change the specification in some manner because: 1. There are currently two descriptions for each combining algorithm, one in English and one in pseudo code, and no statement of which of them is the normative one. 2. The natural language description is currently not correct. It does not cover all possible cases. So we need to fix the natural language description and then choose either it or the pseudo code as the normative one. I don't mind which one, as long as they are both right. :-) Best regards, Erik Rich.Levinson wrote: > To TC: > > Having now had a chance to look over the implications of > the decision to make the p-code non-normative and be > replaced by so-called "simpler text" > > "Rule combining algorithms - The TC will create simpler text > description to describe combining algorithms as suggested on the > list. The pseudo code will be listed as non-normative." > > *I must express strong disagreement with this decision.* > > I assert that the "simpler text" is only simpler because it > throws out the well thought out and technically unambiguous > logic of the p-code. > > A simple comparison of the suggested text vs the p-code > makes this obvious. From the message: > http://lists.oasis-open.org/archives/xacml-comment/200808/msg00024.html > > we have this logic suggested: > > Def.: Deny-overrides rule combining algorithm > 1. If any rule evaluates to "Deny", the result is "Deny". > 2. Otherwise, if any rule having Effect="Deny" evaluates to > "Indeterminate", the result is "Indeterminate". > 3. Otherwise, if any rule evaluates to "Permit", the result is > "Permit". > 4. Otherwise, if any rule having Effect="Permit" evaluates to > "Indeterminate", the result is "Indeterminate". > 5. Otherwise, the result is "NotApplicable". > > First problem: we have to define this logic so that it > is equally unambiguous. Therefore we have to say > that the "order" of the evaluation of the "conditionals" > is normative. We also have to define what a "conditional" is. > > Second problem: the text within the so-called "conditionals" > is also ambiguous. What exactly does "if any rule" mean > that you have to do? Probably it means you have to > evaluate every rule. Therefore one is then looking at > a list of "conditionals", the first four of which require > going thru this loop of all the rules. > > Now one can easily say, "Oh, combine the "conditionals" into > a single loop for optimization purposes.". Therefore the whole > concept of some kind of standalone "conditional" breaks > down which further challenges us to define what a > "conditional" is in unambiguous terms. > > I assert that going thru this exercise of replacing perfectly > good, unambiguous, tried and tested p-code with an > untested, ambiguous, non-standard, and as yet undefined > "language" of "conditionals" is a total waste of time for the > members of this TC. > > The p-code is well thought out and known to be accurate. > If someone has trouble understanding it and needs the > "aid" of this proposed language of "conditionals", I have > no objection to adding such text as non-normative > addition to each section containing an algorithm with > some introductory text saying something like > > "The above p-code may be thought of as functionally > equivalent to the following non-normative set of > conditional statements:" > > However, I will not be able to vote to approve any version > of the document that tries to replace the accurate p-code > with the clearly less-definitive text suggested above. > > Thanks, > Rich > > > > > Bill Parducci wrote: >> 1. Roll Call >> Hal Lockhart (minutes) >> Bill Parducci (Co-chair, minutes) >> Erik Rissanen >> Anthony Nadalin >> Rich Levinson >> Hal Lockhart >> Anil Saldhana >> John Tolbert >> Duane DeCouteau (non-voting) >> >> Quorum reached 7 of 9 (77%) >> >> >> 2. Administrivia >> Vote on minutes postponed to next meeting due to late posting >> to list. >> >> 3. Issues >> >> Open Issues on list >> http://lists.oasis-open.org/archives/xacml/200809/msg00000.html >> >> The TC has no objections to those Issues Erik suggests should be >> considered No Action. >> >> The TC has no objections to the Proposed Actions Erik presented on >> the list. >> >> Identifier conflict – the TC has chosen to resolve this by using: >> urn:oasis:names:tc:xacml:1.0:subject:authentication-method >> >> String comparison - the general consensus is this issue requires >> more consideration. A possible source is XQuery's implementation. >> >> Multiply function arguments - The TC agrees that 0 or 1 argument >> will not be supported. The TC also agrees that Add and Multiply >> arguments will BOTH allow multiple arguments in v3. V2 will not >> be updated. The identifier will remain the same in V3. >> >> Interger overflow - The TC agreed that interger overflow during >> upon type conversion should be handled as an Indeterminate result. >> >> Rule combining algorithms - The TC will create simpler text >> description to describe combining algorithms as suggested on the >> list. The pseudo code will be listed as non-normative. >> >> Issue 72 SAML:Where should passed-in policies be inserted >> >> Hal noted that the spec currently says that there is a top level >> combining algorithm in an implied policy set. The TC decided that >> the provided policies shall be inserted in the presented order >> at the top of this policy set. Hal took an action item to propose >> text which would include more explicit wording on the TLP set. >> >> Issue 75: Defining an interface for closely coupled PEP/PDP >> This will not be considered part of the core schema, rather it >> will be addressed via a Profile. This is not on the V3 critical >> path. >> >> Issue 66: Missing attributes may be underspecified >> This will discussed further on the list and will be taken up >> on the next call. >> >> meeting adjourned. >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]