Re: [kmip] Attribute Index re-use

[Bruce Rich <brich@us.ibm.com>]

On the last question...

3) What about the situation when a single instance
of a multi-instance 
attribute is added (with index 0) and then deleted. If a new instance
is added, does it get index 0 or 1? 

It's the server's choice as to what
index to return.  The server MAY only be marking instances deleted
and getting around to doing more than that when it runs out of preallocated
table space.  So an observant client might see the indices monotonically
increasing to a certain value, then an index reuse occurrence, or it might
see immediate reuse upon DeleteAttribute+AddAttribute.  It should
not care.  The clients should not be doing any reasoning about the
indices.  For the most part, they don't need to care, as multi-instance
attributes are more the exception than the rule.  If there are multiple
instances, and the client is smart enough to try to do something to one
of them, it has the tooling to identify which instance they mean.  The
server only has the obligation to not allow things to shift around under
the client's feet...that indices don't change when the client deletes an
instance.  Think of the index as a short UUID, valid only in the context
of the main object's UUID.  (We could be having a similar discussion
about UUID reuse by a server, but for some reason, that one never comes
up and we only have this discussion about the attribute instance index...oops,
did I just say that out loud?)

Bruce A Rich
brich at-sign us dot ibm dot com




From:      
 Mathias Bjoerkqvist1
<MBJ@zurich.ibm.com>
To:      
 kmip@lists.oasis-open.org
Cc:      
 jl@quintessencelabs.com,
tjh@cryptsoft.com, "Pochuev,Denis" <Denis.Pochuev@safenet-inc.com>,
"Clark, John (Atalla)" <john.w.clark@hp.com>, John Peck/Endicott/IBM@IBMUS
Date:      
 09/22/2011 11:10 AM
Subject:    
   [kmip] Attribute
Index re-use
Sent by:    
   <kmip@lists.oasis-open.org>

---

All, 

Currently, Section 2.1.1 in the KMIP specification says the following:

The Attribute Index of an attribute SHALL NOT change when other
instances are added or deleted. For example, if a particular attribute
has 4 instances with Attribute Indices 0, 1, 2 and 3, and the instance
with Attribute Index 2 is deleted, then the Attribute Index of instance
3 is not changed. 

However, nothing is said about attribute re-use. In the example above,
if a new attribute instance is added, can it receive attribute index 2,
or would the next available index value be 4?

Discussion on the interop call today revealed that we currently have
implementations of both alternatives. Clarifying the behavior would
be desirable. Suggested behavior or mandatory requirements (SHOULD,
SHALL) are both possible. 

Disallowing index re-use would eventually lead to overflow of the index
value. This situation could be resolved by allowing the index to wrap
around, which essentially is a delayed re-use.

Allowing index re-use can lead to confusion for clients. The fact that
we do allow the index to change for existing instances indicates that
the original intent was to avoid confusion. 

Some questions: 

1) Are clients making use of the attribute index in ways that would
prefer one solution over another, and/or are there other compelling
arguments for one or the other alternative? 

2) In a server implementation, is it required to have index values
up to 2^32, instead of e.g. 1024 or even 16? Smaller maximum values
would lead to faster wrapping and re-use even if re-use is disallowed
according to the alternative mentioned on the interop call. We allow
servers to limit the maximum number of attribute instances for any
multi-instance attribute. 

3) What about the situation when a single instance of a multi-instance
attribute is added (with index 0) and then deleted. If a new instance
is added, does it get index 0 or 1? 


Any feedback is appreciated: comments, questions or corrections if
my summary is not accurate or clear enough. 


Regards, 
Mathias