Re: Groups - oasis - Ballot "Straw poll on whether to allow "mutating attributes" in KMIP V1.0." has closed

[Robert Haas <rha@zurich.ibm.com>]

Hi,

The poll results indicate that the preference
goes for the combination of 2) and 3) (although only 25% of the eligible
voters cast their votes, maybe because we did not have our weekly call
and many of us were on holidays):
http://www.oasis-open.org/apps/org/workgroup/kmip/ballot.php?id=1731

I am trying to identify now what changes
we have to make to the specification for the two options:

2) "Modify KMIP specification to
make explicit the list of attributes that a server is allowed to mutate"
I assume what is meant is the list of
attribute values passed by the client as parameters to an operation request
for which the client does not want their value to be changed by the server
(the server can always fail the operation if necessary, but should it indicate
which attribute value(s) caused the failure?). These attribute values are
provided through a Template-Attribute object that contains template names
as well as individual attribute values. Note that there are precedence
rules for single-valued attributes if provided multiple times, whereas
for multi-valued attributes a union is made with all values provided.

3) "Modify KMIP specification to
allow the client to inform the server whether or not it will accept mutated
attributes"
I assume what is meant is to have the
client indicate in each operation request whether none or all of the attribute
values it passes can be mutated.

While 3) is relatively straightforward
(and IMHO would be sufficient to accommodate most client needs, at least
for a first version), there are many ways to do 2). So it would be good
to see now concrete ideas how to implement both 2) and 3).

Regards,
-Robert

workgroup_mailer@lists.oasis-open.org wrote on 07/02/2009
08:01:03 PM:

> [image removed] 
> 
> Groups - oasis - Ballot "Straw poll on whether to allow "mutating
> attributes" in KMIP V1.0." has closed
> 
> workgroup_mailer 
> 
> to:
> 
> rha
> 
> 07/02/2009 08:05 PM
> 
> OASIS Key Management Interoperability Protocol (KMIP) TC member,
> 
> A ballot presented to OASIS Key Management Interoperability Protocol
> (KMIP) TC has closed.
> The text of this closed ballot is as follows:
> ---
> "Straw poll on whether to allow "mutating attributes"
in KMIP V1.0."
> This straw poll is intended to gather input on what approach should
> be taken in allowing or restricting mutating attributes in KMIP V1.
> 0. See the email posting from Alan Frindell on 10-June, "[kmip]
> Mutating Attributes" for discussion of this question.
> 
> - No change to the current specification. Servers are allowed to 
> mutate any attribute.
> - Modify KMIP specification to make explicit the list of attributes
> that a server is allowed to mutate.
> - Modify KMIP specification to allow the client to inform the server
> whether or not it will accept mutated attributes.
> - Modify KMIP specification to include both 2 and 3 above.
> 
> ---
> 
> Quick Summary of Voting Results: 
>  - No change to the current specification. Servers are allowed
to 
> mutate any attribute. received 0 Votes
>  - Modify KMIP specification to make explicit the list of attributes
> that a server is allowed to mutate. received 5 Votes
>  - Modify KMIP specification to allow the client to inform the
> server whether or not it will accept mutated attributes. received
4 Votes
>  - Modify KMIP specification to include both 2 and 3 above. received
7 Votes
> 
>  16 of 63 eligible voters cast their vote before the deadline.
> 
> Voting results for all closed ballots are available on the kmip 
> eVote Archive at:
> http://www.oasis-open.org/apps/org/workgroup/kmip/ballot_archive.php
> 
> Thank you,
> OASIS Open Administration