Re: [kmip] Groups - KMIP-ReKey-Examples-v1d.pdf uploaded

On 27/05/2013 2:28 PM, John Leiseboer wrote:
    
      
      
      
      
      

        
The proposal put forward by Bruce to narrow the
            scope of the Re-* operations to key value and
            lifecycle-related change seem reasonable to me. I think
            Bruce's suggested changes are sensible, consistent, a
            reasonable interpretation of intent, and will help with
            interoperability.

      

    
    

    John - do you support Bruce's proposed changes (the various marked
    up word documents) as-is or not? That is the feedback that Bruce was
    seeking and the presentation we put together was to aid discussion
    on the topic to see if there was a reasonable level of interest in
    looking at this for KMIP 1.2 (with the assumption that there
    probably was not given no one had indicated support so far). 

    

    
      

        

        
If consensus is that this is too much change for
            v1.2, then I would propose that text be added somewhere
            (main specification? User Guide?) to warn implementers of a
            possible future change.

      

    
    

    That would not be a sensible approach to take IMHO - warning in a
    document about a change which the group as a whole has not indicated
    support for so far. 

    

    The nature of the change Bruce is suggesting is to make it clear
    that the current behaviour (analogous to Create) remains entirely
    allowed and there is a recommendation to limit to changing just a
    few "special" attributes noted. This will do absolutely nothing for
    interoperability other than to clearly document two very different
    (and incompatible) views as both being acceptable leaving clients to
    not know which view a server supports. Bruce was very clear that he
    marked it SHOULD rather than SHALL in order to try to make it more
    acceptable to the group for inclusion within KMIP 1.2 by being able
    to state that all existing behaviours remain supported - but that
    approach does not help interoperability at all.

    

    Both Judy and I have expressed our contrary views to making this
    change on the list (and in the call last week). 

    

    More test cases will be added (a work in progress) to cover as many
    of the areas we have been discussing as possible. 

    That will at least address the issue of leaving items open to change
    absent test cases demonstrating use of functionality.

    

    Tim.