Re: [xacml] The known issues in XACML 3.0 CS 01

[Bill Parducci <bill@parducci.net>]

As a counter point I offer that we currently only have 1 official adoption on record so: (1) nothing is being held up at the moment in the specification process; (2) the Errata cannot officially exist until there is something to reference. We can take a number of steps to shrink the duration of the process to get back to candidacy status quickly, particularly since the changes are not structural and you have done an excellent job of documenting/addressing them.

Weekly meetings work for me if deemed necessary by the TC.

b

On Mar 28, 2011, at 7:42 AM, Erik Rissanen wrote:

> All,
> 
> I have collected from the mailing lists all issues found in the current committee specifications for XACML 3.0. (Let me know if I have missed something.) I have added my personal comment to each issue. Some of these are non-issues, but a couple of them should be fixed sooner or later.
> 
> Now, regarding how to fix this. The problem is that it takes so long time to do a round of approval. It's several months. For instance, I posted XACML 3.0 WD 18 on the 23rd of June, 2010. It was approved as a CS on the 10th of August 2010, which is close to two months, and this was done using weekly meetings, so it would be much longer with bi-weekly meetings.
> 
> So given how long it takes to drop back to WD, I would prefer that we go with the specs as they are and publish errata at a later stage. None of the issues are extremely severe. Issues 1, 4 and 6 or probably the most significant ones.
> 
> If we would do it through the whole thing again, I would ask that: Please respond to this email on the list now!! This way I can have a new spec ready for approval and public review vote for the next call. It's so slow to work in the TC because everything ends up being a four week cycle of no discussion on the list, discussion on the call, and then deferring to the next call. Also, I would ask us to go to weekly meetings until the process has completed again since it is so slow otherwise.
> 
> Anyway, here are the issues:
> 
> 1 -- Missing functions for the new dayTimeDuration andyearMonthDuration datatypes
> 
> http://lists.oasis-open.org/archives/xacml-comment/201012/msg00000.html
> 
> Yes, these function identifiers should be added to the lists, and yes, the old ones should be listed as deprecated.
> 
> Severity: incorrect conformance spec with some missing identifiers
> 
> 
> 2 -- Inappropriate use of xsi:type in SAML profile protocol schemas
> 
> http://lists.oasis-open.org/archives/xacml-comment/201012/msg00001.html
> 
> Yes, it should say “type” instead of xsi:type. (Note though that the schemas work, as pointed out by the reporter of the issue.)
> 
> Severity: works in an implementation, but the schema is not as strict as it could be. Fairly limited real world impact. (An implementation should check the content of the XML messages more carefully after schema validation has been passed.)
> 
> 
> 3 -- The x500Name-match function is not clearly defined
> 
> http://lists.oasis-open.org/archives/xacml-comment/201101/msg00005.html
> 
> I don’t agree that there is an ambiguity. See my response here:
> 
> http://lists.oasis-open.org/archives/xacml-comment/201103/msg00004.html
> 
> Severity: non-issue.
> 
> 
> 4 -- Inconsistent definition for the any-of-all function
> 
> http://lists.oasis-open.org/archives/xacml-comment/201101/msg00006.html
> 
> I agree with the poster that the Haskel definition does not appear to match the English language definition, and his suggested alternative does match the English text. I think the English description is the one which was intended, so we should change the Haskel definition.
> 
> Personally, I would prefer to take out the Haskel definitions altogether, rather than providing the missing ones, since it’s better to have only one normative definition.
> 
> Severity: there are two descriptions of a couple of functions, where some or wrong or incomplete. There are also correct definitions for everything. Not nice, but practical impact is probably small.
> 
> 
> 5 -- A suggestion for better handling of multi-valued attributes in conditions
> 
> http://lists.oasis-open.org/archives/xacml-comment/201101/msg00007.html
> 
> This is not errata, rather a suggestion for a new feature, so I am not commenting on it further in this list.
> 
> Severity: non-issue (for 3.0).
> 
> 
> 6 -- Specification of extended indeterminate in combining algorithms is incomplete
> 
> http://lists.oasis-open.org/archives/xacml-comment/201103/msg00000.html
> 
> This points out a couple of cases where the new combining algorithms do not have undefined behavior. My suggestions are here:
> 
> http://lists.oasis-open.org/archives/xacml-comment/201103/msg00001.html
> 
> Severity: incomplete definition of functions. In practice implementation can be made correct by errata or discussion here.
> 
> 
> 7 -- Erratum concerning the 'Expression Substitution Group'
> 
> http://lists.oasis-open.org/archives/xacml/201103/msg00036.html
> 
> This is an error. The <Condition> element should be removed from this list. (Though I don’t think this change has any impact on any implementation since the normative schema file is correct.)
> 
> Severity: probably no impact.
> 
> 
> 8 -- Obligations problem
> 
> http://lists.oasis-open.org/archives/xacml/201103/msg00037.html
> 
> There is no incorrectness here, just awkward use of language. See my response:
> 
> http://lists.oasis-open.org/archives/xacml/201103/msg00053.html
> 
> Severity: non-issue
> 
> Best regards,
> Erik
> 
> 
> ---------------------------------------------------------------------
> 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