Re: [xacml] The road to 3.0?

[Erik Rissanen <erik@axiomatics.com>]

Prateek, see inline.

Prateek Mishra wrote:
> Comments are inline -
>> Prateek,
>>
>> I don't understand what you mean by "I think there are techniques 
>> available to handle the issue of certain drafts needing to show 
>> progress in the short term (e,g., CD, CS) without creating a new 
>> version". Could you clarify what you suggest?
>>
> [PM]
>
> I am suggesting that individual drafts can be voted to CD and 
> eventually to CS status, if there is a need for showing that progress 
> is being made. This is a much smaller step than voting in a new 
> standard and with much less collateral damage to on-going efforts to 
> advance XACML deployment.
>
> [\PM]

There is no need to "show progress". I want to close the work on the 
core so we can tackle the other issues, so I want to go to CD/CS. Then 
there will be a natural wait before we go OS. We have not really 
discussed yet how we want to go to OS.

>> Personally, I think we need to get out the new 3.0 core as soon as 
>> possible for several reasons:
>>
>> 1. Having it around in an unfinished state creates confusion about 
>> where the standard will be going, thus hindering adoption.
> [PM] I dont follow the logic here. What is the problem with XACML 2.0 
> that is hindering adoption? Can you point to some public sources where 
> these
> problems are described?  I understand this is your opinion but it 
> would be good to understand the basis behind it.
>
> In my experience, - which is based on my XACML presentation at RSA 
> 2007, the workshop organized by Burton/Concordia at Catalyst 2008 (San 
> Diego) and the Concordia mailing list,  as well as the Catalyst 2007 
> interop, - not a single person has mentioned to me that lack of XACML 
> 3.0 as an issue hindering adoption.
>
> Now people have mentioned many, many other issues with XACML and 
> reasons why its uptake has been modest. Most of these have to do with 
> gaps in the standard, missing profiles, deployment issues, lack of 
> guidance and best practices, lack of tooling and so on.
>
> [\PM]

What I meant is that it is not good if there is a 3.0 in the works, and 
customers do not know if and when 3.0 will appear. It would be better to 
finish 3.0 so the uncertainty of 3.0 is cleared up, so customers can 
have a better view of the XACML roadmap.

>>
>> 2. Currently the core is taking up the effort of the TC. Closing the 
>> 3.0 core frees up the TC to address the "practical issues".
> [PM] I would be comfortable with voting the core to CD and, after 
> suitable review, to CS at a later point in time. [\PM]

This is exactly what I think we should do. I would like to go OS as 
well, but I have not made up my mind yet about when and how. But 
regardless of that, going CD/CS now is the right thing.

>>
>> 3. The switch to 3.0 will be more difficult, the longer we wait since 
>> there will be more 2.0 deployments then.
> [PM] Hmmmmm,...I dont get the logic here - if XACML 3.0 does not have 
> any compelling value and strengths over XACML 2.0, if people are
> not convinced that they should upgrade, then the problem lies with 
> XACML 3.0.  If  so, then we should reopen the question of why we are 
> planning a major release of a standard that is still finding its place 
> in the security world.
> [\PM]

It does have value and strengths over 2.0. My customers in general 
choose 3.0 over 2.0.

>>
>> 4. The 3.0 core is a better core (even without delegation) than the 
>> 2.0 core. There are many small improvement fixing bugs and making 
>> higher performance possible.
>>
> [PM] Again, frankly, I havent heard a single customer or analyst 
> mention this issue to me. This kind of marginal improvement doesnt 
> merit creation of a major new version of a standard.
> [\PM]

This is not my experience.

Regards,
Erik