DM-006: Ephemerality

[jimsch]

Version -04

1. We seem to have a different definition of the word Ephemeral - to me it means things that are transient or short lived. What this requirement appears to me to be addressing is both async and incremental updates. I would suggest changing the item title to represent that.
2. This requirement does not appear to say anything about consistency of data provided to a customer. Is there such a requirement that should be expressed? (And if so how is consistency defined.)

[ncamwing]

Hi Jim,
I agree with #1, I think the original requirement was labeled "Asynchronous publication, updates or change modifications with filtering", but then got distilled in the restructuring.
How about "Full versus partial updates" as a title?

As to consistency, what do you mean by that? I don't think we've defined consistency.....

Thanks, Nancy.

[jimsch]

Sounds good as a title update

In terms of consistency, I was thinking of a reply being built from multiple sources. If they are in the middle of propagating data between them or some elements have been updated, but the appropriate consolidators have not run, then the view of the state given back to a client might not be time consistent. That is different attributes come from different times with different possible results. This is also an issue if the same attribute is published to different repositories by different entities. Which is returned and what happens if they have different ideas of state.

[llorenzin]

I would prefer to see this split into two separate requirements, since it really addresses two different concepts:

DM-00x: Full vs partial updates: The data model SHOULD include the ability to allow providers of data to provide the data as a whole or when updates occur. For example, a consumer can request a full update on initial engagement, then request to receive deltas (updates containing only the changes since the last update) on an ongoing basis as new data is generated.

DM-00y: Solicited vs. Unsolicited Updates: The data model SHOULD enable a provider to publish data either solicited (in response to a request from a from a consumer) or unsolicited (as new data is generated, without a request required). For example, an external collector can publish data in response to a request by a consumer for information about an endpoint, or can publish data as it observes new information about an endpoint, without any specific consumer request triggering the publication.

[jimsch]

Both of these are clear requirements. I like the text.

[ncamwing]

Will incorporate in -05

[jimsch]

Looks good in -05.