OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [kmip] Groups - Locate with Offset uploaded


> Right now we have a simple proposal that solves enough of a known problem. It doesn't attempt to do everything.

Right now we have a simple proposal that does not solve the problem at all. It cannot be relied upon. It is not consistent with the KMIP protocol. It relies on consistent ordering in the Locate, AND it only “works” when uncontrollable external factors (that would influence the set of objects found by a Locate request) do not arrive at the server during the sequence of Locate requests. The first condition is not a requirement of the standard. The second condition is well outside the scope of the standard.

 

Can this proposal be relied upon by clients to deliver objects without duplication, or omission?

No.

 

Can constraints on server implementation (like ordered Locate results) fix the proposal?

No. The proposal is fundamentally flawed.

 

Given the possibility of duplicated and omitted objects, should this proposal be accepted?

That’s the question I am asking. Note that the probability of duplicated and omitted objects will reach 100% under conditions that can be very easily induced by authenticated, authorised users of the system operating in full conformance with the KMIP specification.

> Mandating ordering of Locate responses would be a separate item.

Red herring. Consistent ordering is not why the proposal is broken, and will not fix it. It is the stateless nature of the KMIP protocol.

 

> Mandating stateful multi-request responses would be a separate item.

Red herring. Stateful multi-request responses are not required.

 

> But you are revisiting the whole topic of the offset+limit approach to Locate…

Given that this proposal is all about the topic of offset+limit approach to Locate, by definition any discussion is revisiting the topic. By your logic, nobody should review or discuss this proposal, lest they be accused of revisiting the topic. What I was not revisiting is the specific topic that I raised with respect to message flow control. Granted, what I raised at the face to face would have solved the problem, and indeed many others. But this is of course, yet another red herring. The topic we’re discussing is the current proposal. We’re not discussing alternate proposals. Indeed, as a group, the decision may to be to accept this flawed proposal, not bother with offset+limit for Locate at all, or to solicit alternate proposals. That’s to be decided. And if this is revisiting the topic, then I am guilty, and I make absolutely no apologies for it.

 

> Does it implement a well known and well understood design pattern that is widely used?
> Yes.
The proposal is incorrectly using a design pattern that cannot be applied to KMIP. Using a well-known, well understood design pattern incorrectly is a mistake.

 

> Do I think server vendors who haven't implemented a consistent order in Locate responses have made the wrong choice?
> Yes.

Red herring. Consistent ordering is not why the proposal is broken, and will not fix it. It is the stateless nature of the KMIP protocol.

 

> Does this preclude a server vendor from implementing this as a server-side preserved SQL transaction state against the client request?
No. Nor does it require it.

Red herring. Server implementation is not the issue. This is a protocol issue that needs to be addressed at protocol level.

 

> Now if we wanted to add some more Query functions to return items like whether or not the Locate response has a well defined order for a given implementation I can add that as a separate proposal.

Red herring. Consistent ordering is not why the proposal is broken, and will not fix it. It is the stateless nature of the KMIP protocol.

 

> If there is consensus that there should be a consistent order for items returned in Locate…

Red herring. Consistent ordering is not why the proposal is broken, and will not fix it. It is the stateless nature of the KMIP protocol.

 

John

 

From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Tim Hudson
Sent: Friday, 16 May 2014 7:47 AM
To: kmip@lists.oasis-open.org
Subject: Re: [kmip] Groups - Locate with Offset uploaded

 

On 16/05/2014 6:28 AM, John Leiseboer wrote:

> This proposal is entirely consistent with the specification

The proposal does not address the lack of ordering. The proposal does not address stateless server design.

Nor was it intended to address those issues. Mandating ordering of Locate responses would be a separate item. Mandating stateful multi-request responses would be a separate item. This proposal does neither of those.


> If you want to revisit that issue…

NO! I DO NOT WANT TO REVISIT THAT ISSUE. Is that clear to you?

But you are revisiting the whole topic of the offset+limit approach to Locate which was discussed at the face to face and we had a consensus to proceed down that path with a simple proposal and there was no support for taking the different approach you roughly outlined in the face to face meeting. You withdrew from moving forward on that item given the lack of support from others within the TC and indicated you accepted the consensus of the group at the time and simply disagreed with it. I think that is a fair and accurate reflection on that discussion.

In between two Locate operations another client (or the server admin) could add or remove multiple objects from the list which matches the Locate parameters. This isn't suggesting or requiring that the server provide a single consistent transaction across multiple requests - that isn't what it is about - this is about providing the typical paging mechanism in independent requests which is what is normally handled.

Most server vendors already have this sort of mechanism in place with well understood semantics. That you are looking for effectively a guaranteed cross-request transaction state with what you raised previously at the face to face which is aimed at a different problem domain.

Does this proposal do everything?
No.

Does it implement a well known and well understood design pattern that is widely used?
Yes.

Do I think server vendors who haven't implemented a consistent order in Locate responses have made the wrong choice?
Yes. But the specification allows for that choice to be made as it does in a whole pile of areas. It tends to make the server responses a lot less useful for dealing with any lists of managed objects (entirely independent of this proposal). I would suspect that server vendors with such a design approach would find less success in the market - but as a technical committee we don't mandate a particular server internal design approach and we have kept a lot of things clearly open to different design approaches.

Does this preclude a server vendor from implementing this as a server-side preserved SQL transaction state against the client request?
No. Nor does it require it. That is left up to the server vendor as a design choice.

Now if we wanted to add some more Query functions to return items like whether or not the Locate response has a well defined order for a given implementation I can add that as a separate proposal.

If there is consensus that there should be a consistent order for items returned in Locate then I can add that as a separate proposal.

Right now we have a simple proposal that solves enough of a known problem. It doesn't attempt to do everything.

Tim.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]