RE: [xacml] minor bug in the XACML 3.0 core spec

Lets 
talk about it on the call. 

 

I 
beleive that if the changes are non-substantive we can do all the necessary 
votes on a single call. We can vote to CD based on a WD. We can then vote to 
have the chairs request a CS ballot once the CD version has been created. The 
actual CS ballot has to be online anyway.

 

The 
changes proposed by Jan are to examples. The changes proposed by Ludwick are to 
non-normative schema fragments. It seems clear to me that all these changes are 
non-substantive.

 

Legally we can ignore these comments because a) they 
were made after the end of the PR and b) they are not in scope for the PR sicen 
they were not changed since the 1st PR.

 

I 
understand the frustration on how long this has all taken, but I hate to go 
final with known errata.

 

Hal

  
-----Original Message-----
From: Erik Rissanen 
  [mailto:]
Sent: Thursday, June 17, 2010 3:47 
  AM
To: 
Subject: Re: [xacml] 
  minor bug in the XACML 3.0 core spec

Hal,

I don't 
  think we can change the content of the spec without reissuing a new working 
  draft and redoing all the votes. To what level are we supposed to go next? How 
  many steps is that to redo? And how quickly can we do the votes?

The 
  problem is that I think in many cases we cannot vote forward without having 
  the intermediate docs actually present, which means that there is a two week 
  cycle between each vote.

Best regards,
Erik

On 06/16/2010 
  09:33 PM, Harold Lockhart wrote: 
  
    

    
Erik,

    
 

    
Can we fix this easily? As far I can see there were no other comments 
    during th epublic review.

    
 

    
Hal

    
      
-----Original Message-----
From: Jan Herrmann [mailto:]
Sent: 
      Wednesday, June 09, 2010 5:48 AM
To: XACML TC
Subject: 
      [xacml] minor bug in the XACML 3.0 core spec

      

      
Dear 
      all,

      
while using the XACML 3.0 
      docs, I noticed that in some examples the old RequestContextPath XML 
      Attribute of the <AttributeSelector> is used. 
      

      
In order to be consistent with 
      the AttributeSelector definition under section 5.30, we should change this 
      and replace RequestContextPath by Path in the examples in section 
      2.

      
Best 
      regards

      
jan