Subject: Re: [sacm] [draft-ietf-sacm-requirements] DM-006: Ephemerality (#30)

From: ncamwing <[email-masked]>
Date: Sun, 03 May 2015 19:42:52 -0700

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.

---
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/30#issuecomment-98572974

---

From: Jim Schaad <[email-masked]>
Date: Mon, 04 May 2015 09:28:07 -0700

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.

---
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/30#issuecomment-98772557

---

From: llorenzin <[email-masked]>
Date: Fri, 08 May 2015 13:41:11 -0700

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.

---
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/30#issuecomment-100356616

---

From: Jim Schaad <[email-masked]>
Date: Fri, 08 May 2015 15:18:37 -0700

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

---
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/30#issuecomment-100381727

---

From: ncamwing <[email-masked]>
Date: Fri, 08 May 2015 20:14:23 -0700

Will incorporate in -05

---
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/30#issuecomment-100416507