OASIS Key Management Interoperability Protocol (KMIP) TC

Submitter's message Updated proposal to include returning the Located Items count as per list discussion. -- Tim Hudson Document Name : Locate with Offset Description This document contains the (minor) changes required to add an offset field to the Locate call. This was discussed back at the last face-to-face. I'm submitting it as my last act before I leave Vormetric; Tim Hudson will be able to talk to it on the call this week. Download Latest Revision Public Download Link Submitter : Tim Hudson Group : OASIS Key Management Interoperability Protocol (KMIP) TC Folder : Drafts Date submitted : 2014-05-15 01:21:54 Revision : 1

An observation: I assume that there is no guarantee or requirement for separate Locate requests to, even with identical match criteria, return the matched objects in the same order. So then if, for example, there are say 100 objects on a server that match a Locate request, and if the client issues, say 10 sequential requests with offsets of 0, 10, 20, etc. respectively, each with a maximum object count of 10, there is no guarantee that the client will actually be returned the full set of 100 objects. In fact, worst case, although probably unlikely, but possible, the client could see the same 10 objects returned in each request.   Does anyone disagree that this is possible given the current specification? Is this an issue for anyone?   John   From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Tim Hudson Sent: Thursday, 15 May 2014 6:22 PM To: kmip@lists.oasis-open.org Subject: [kmip] Groups - Locate with Offset uploaded   Submitter's message Updated proposal to include returning the Located Items count as per list discussion. -- Tim Hudson Document Name : Locate with Offset Description This document contains the (minor) changes required to add an offset field to the Locate call. This was discussed back at the last face-to-face. I'm submitting it as my last act before I leave Vormetric; Tim Hudson will be able to talk to it on the call this week. Download Latest Revision Public Download Link Submitter : Tim Hudson Group : OASIS Key Management Interoperability Protocol (KMIP) TC Folder : Drafts Date submitted : 2014-05-15 01:21:54 Revision : 1  

On 15/05/2014 8:58 PM, John Leiseboer wrote: An observation: I assume that there is no guarantee or requirement for separate Locate requests to, even with identical match criteria, return the matched objects in the same order. There is no requirement on a KMIP server to return objects in any specified (or event consistent order) so a server is free to elect to be non-predicable if it so wishes. That has always been the case. Most sensible servers however do have a well defined order mechanism in place (the mechanism does vary between vendors). So a Locate require with a maximum items value repeated may return the same set of managed objects or a different set depending on the particular server vendors choice. New objects added between requests may appear or may not appear. So then if, for example, there are say 100 objects on a server that match a Locate request, and if the client issues, say 10 sequential requests with offsets of 0, 10, 20, etc. respectively, each with a maximum object count of 10, there is no guarantee that the client will actually be returned the full set of 100 objects. In fact, worst case, although probably unlikely, but possible, the client could see the same 10 objects returned in each request. If a server elects to implement with a non-consistent order in responses then this mechanism won't be much use for that type of server - although that type of server will have a pile of other issues entirely separate from supporting an offset items value.   Does anyone disagree that this is possible given the current specification? Is this an issue for anyone? The specification does not preclude a server vendor from implementing items in a manner that makes Locate responses less useful to a client then it should be. I recollect a discussion long ago on ordering of responses from Locate but no requirement was added into the specification to mandate a particular order. If you are suggesting that the order of objects returned from Locate should be made to be required to be deterministic then you should perhaps raise that as a separate proposal. Tim.

> If you are suggesting that the order of objects returned from Locate should be made to be required to be deterministic then you should perhaps raise that as a separate proposal. No. I am not suggesting this at all, as this would not solve the issue. Given the discussion at the last face to face I’m reluctant to raise much at all. I just wanted to point out, and you have confirmed, that the proposed solution is not consistent with the specification, and that it is not robust to implementation differences (or in other words, it relies on server implementations being “sensible”, where sensible does not mean designed in accordance with the specification). John From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Tim Hudson Sent: Friday, 16 May 2014 5:56 AM To: kmip@lists.oasis-open.org Subject: Re: [kmip] Groups - Locate with Offset uploaded   On 15/05/2014 8:58 PM, John Leiseboer wrote: An observation: I assume that there is no guarantee or requirement for separate Locate requests to, even with identical match criteria, return the matched objects in the same order. There is no requirement on a KMIP server to return objects in any specified (or event consistent order) so a server is free to elect to be non-predicable if it so wishes. That has always been the case. Most sensible servers however do have a well defined order mechanism in place (the mechanism does vary between vendors). So a Locate require with a maximum items value repeated may return the same set of managed objects or a different set depending on the particular server vendors choice. New objects added between requests may appear or may not appear. So then if, for example, there are say 100 objects on a server that match a Locate request, and if the client issues, say 10 sequential requests with offsets of 0, 10, 20, etc. respectively, each with a maximum object count of 10, there is no guarantee that the client will actually be returned the full set of 100 objects. In fact, worst case, although probably unlikely, but possible, the client could see the same 10 objects returned in each request. If a server elects to implement with a non-consistent order in responses then this mechanism won't be much use for that type of server - although that type of server will have a pile of other issues entirely separate from supporting an offset items value.  Does anyone disagree that this is possible given the current specification? Is this an issue for anyone? The specification does not preclude a server vendor from implementing items in a manner that makes Locate responses less useful to a client then it should be. I recollect a discussion long ago on ordering of responses from Locate but no requirement was added into the specification to mandate a particular order. If you are suggesting that the order of objects returned from Locate should be made to be required to be deterministic then you should perhaps raise that as a separate proposal. Tim.

On 16/05/2014 6:05 AM, John Leiseboer wrote: > If you are suggesting that the order of objects returned from Locate should be made to be required to be deterministic then you should perhaps raise that as a separate proposal. No. I am not suggesting this at all, as this would not solve the issue. Given the discussion at the last face to face I’m reluctant to raise much at all. I just wanted to point out, and you have confirmed, that the proposed solution is not consistent with the specification, and that it is not robust to implementation differences (or in other words, it relies on server implementations being “sensible”, where sensible does not mean designed in accordance with the specification). Actually no John - I'm pointing out that the item you are raising in the context of this issue is an item we have as a technical committee previously determined did not need to be set as a requirement. If you want to revisit that issue then you should raise the base issue independent of the proposal that updates a feature. This proposal is entirely consistent with the specification - it continues to not mandate (or preclude) a specific order. The specification does not mandate a particular design for a server (that is a non-goal) - it specifies an interoperability protocol - server design is left to the implementers of each server. Tim.

On 5/15/2014 4:18 PM, Tim Hudson wrote: On 16/05/2014 6:05 AM, John Leiseboer wrote: > If you are suggesting that the order of objects returned from Locate should be made to be required to be deterministic then you should perhaps raise that as a separate proposal. No. I am not suggesting this at all, as this would not solve the issue. Given the discussion at the last face to face I’m reluctant to raise much at all. I just wanted to point out, and you have confirmed, that the proposed solution is not consistent with the specification, and that it is not robust to implementation differences (or in other words, it relies on server implementations being “sensible”, where sensible does not mean designed in accordance with the specification). Actually no John - I'm pointing out that the item you are raising in the context of this issue is an item we have as a technical committee previously determined did not need to be set as a requirement. If you want to revisit that issue then you should raise the base issue independent of the proposal that updates a feature. This proposal is entirely consistent with the specification - it continues to not mandate (or preclude) a specific order. The specification does not mandate a particular design for a server (that is a non-goal) - it specifies an interoperability protocol - server design is left to the implementers of each server. Tim. Maybe I'm being dense (wouldn't be the first time), but one would assume the purpose of the offset is to allow someone to iterate through the values in chunks, but if there's no guaranteed order, using locate with an offset doesn't mean you'll ever be able to get the full set of results you may have been looking for.  Guess without ordering I just don't see the point of this option. Sue

> 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.   > If you want to revisit that issue… NO! I DO NOT WANT TO REVISIT THAT ISSUE. Is that clear to you?   I am asking the group, if anyone has an issue with the proposal, given the limitations that I have identified. Clearly, Tim, you do not have an issue. Thank you for responding. Does anyone else have a problem with this?   Again. Note, Everybody. I am not proposing any changes yet. I am just trying to learn if anyone else has an issue with this.   John   From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of Tim Hudson Sent: Friday, 16 May 2014 6:18 AM To: kmip@lists.oasis-open.org Subject: Re: [kmip] Groups - Locate with Offset uploaded   On 16/05/2014 6:05 AM, John Leiseboer wrote: > If you are suggesting that the order of objects returned from Locate should be made to be required to be deterministic then you should perhaps raise that as a separate proposal. No. I am not suggesting this at all, as this would not solve the issue. Given the discussion at the last face to face I’m reluctant to raise much at all. I just wanted to point out, and you have confirmed, that the proposed solution is not consistent with the specification, and that it is not robust to implementation differences (or in other words, it relies on server implementations being “sensible”, where sensible does not mean designed in accordance with the specification). Actually no John - I'm pointing out that the item you are raising in the context of this issue is an item we have as a technical committee previously determined did not need to be set as a requirement. If you want to revisit that issue then you should raise the base issue independent of the proposal that updates a feature. This proposal is entirely consistent with the specification - it continues to not mandate (or preclude) a specific order. The specification does not mandate a particular design for a server (that is a non-goal) - it specifies an interoperability protocol - server design is left to the implementers of each server. Tim.

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.

> 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.

On 16/05/2014 9:18 AM, John Leiseboer wrote: > 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 is - in that it solves the problem it is trying to solve - and doesn't solve the separate problem you are raising. Others have already indicated that solving that problem is of interest (most vendors have this capability in their servers already long before KMIP came along). That you don't see it as useful yourself is entirely up to you. KMIP is (mostly) stateless and so actions that impact the lists returned in Locate can occur between requests. You may get repeated items, you may get missed items. This is precisely how the design pattern from SQL for offset and limit works - correctly applied - where the transaction scope between separate invocations is handled separately -  i.e. where there isn't a transaction scope (stateful) required between requests. SQL allows for transaction state handling entirely separate from the offset and limit and even for user selectable levels of transaction consistency including running without transaction consistency at all. This is exactly the same context when you can perform the same Locate operation between two requests - it can return different answers. That it can doesn't mean that KMIP is broken or the sky is about to fall in - it is simply the choice of the technical committee. Pointing out that because there isn't a guaranteed transaction consistency cross-requests doesn't make that capability not fit for purpose. You can also perform a Locate then immediately follow up with a Get and have the Get fail because someone else has performed a Destroy - again that is a reflection of the choices within the protocol itself. It doesn't mean Locate is broken. It doesn't mean KMIP is broken. It does mean that a user of KMIP should be aware of this. But we don't include warnings in the documentation about that for each Operation noting that things may have changed from the previous request - we have error codes which provide for reporting that. This proposal isn't for a stateful iterator guaranteed to return all objects within a KMIP server across multiple requests (which seems to be what you are asking for) - its a paging mechanism over a (mostly) stateless Locate operation. It has exactly the same properties you would get if you used limit+offset within SQL statements in separate transactions. If you want to be able to perform a series of separate requests with generic stateful transaction handling between them then you can always raise that item again - but so far there has been no other support for that approach - and such a change would require broad support within the technical committee. Tim.