[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Minutes 11 September TC Meeting
Hi Rich, Improving/correcting the text and making the pseudo code normative would be good for me. Regards, Erik Rich.Levinson wrote: > 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: >> 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]