[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Minutes 11 September TC Meeting
|
Hi Erik, My issue was with the TC intent to reduce the status of the p-code from normative to non-normative. I don't think such an action should be taken without definite reason, which as my email explained appeared to me to be insufficient to justify. I have no objection to improving the text. I have generally used the p-code and never really scrutinized the text in much detail. However, now, when looking at the existing text, I can see if someone was using that as the basis for design they would have problems. I think the suggested text improves to soundness of the logic of the existing text, but it also takes away some of the motivating notions within the existing text. If those motivating factors could be preserved possibly as prelude to the suggested text and if the p-code was kept as is, then I think that would be a reasonable action to take. Thanks, Rich Erik Rissanen wrote: 48CDF88C.9010700@axiomatics.com" type="cite">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--------------------------------------------------------------------- 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]