Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IM-002: Ephemerality #25

Closed
jimsch opened this issue Apr 11, 2015 · 5 comments
Closed

IM-002: Ephemerality #25

jimsch opened this issue Apr 11, 2015 · 5 comments

Comments

@jimsch
Copy link
Contributor

jimsch commented Apr 11, 2015

Version -04

  1. s/by a requestor/by an endpoint/ requestors do not provide information.
  2. I don't understand what this requirement is trying to say. It needs to be expanded.
  3. when can the SHOULD be violated - is it a killer for an IM?
@ncamwing
Copy link
Contributor

ncamwing commented May 4, 2015

Updated "requestor" to "endpoint".

The requirement is really trying to state that a data model SHOULD support at least one but can support both solicited and unsolicited requests (e.g. query and/or pub-sub).

How about if we updated it to read:
"Posture Data requests: The Information Model SHOULD account for the Posture information's ephemerality as the data may be provided by an endpoint either solicited or unsolicited. That is, data models MUST support at least one or both means to request data: solicited or unsolicited."

That way, we don't have to clarify "ephemerality" either ...
Nancy

@llorenzin
Copy link

The endpoint generates the data, but is not necessarily (and probably won't be, in most cases) the component publishing the information. The provider is the component publishing the information. Further, this requirement refers not to a means to request data (requested data is by definition solicited), but a means to publish data. So I'd revise to:

"Posture Data Publication: The Information Model SHOULD account for the Posture information's ephemerality as the data may be provided by an endpoint either solicited or unsolicited. That is, data models MUST support at least one or both means to publish data: solicited or unsolicited. For example, a compliance-server provider may publish endpoint posture information in response to a request from a consumer (solicited), or it may publish posture information driven by a change in the posture of the endpoint (unsolicited)."

@jimsch
Copy link
Contributor Author

jimsch commented May 8, 2015

I find the update from llorenzin to be clearer in terms of what is being required. I am still not sure what the word 'ephemerality' is supposed to mean here, but pulling it out of the pithy title means I don't care as much.

@ncamwing
Copy link
Contributor

ncamwing commented May 8, 2015

So, I think the first sentence is not clear....and yes, I had to look up the definition of "ephemeral" to see if we were using it correctly and I believe we are not:

From http://www.merriam-webster.com/dictionary/ephemeral:
adjective ephem·er·al \i-ˈfem-rəl, -ˈfēm-; -ˈfe-mə-, -ˈfē-
1
: lasting one day only
2
: lasting a very short time

Which is NOT the intent of requirement; I believe the requirement is about ensuring the Information Model allow for the information to be acquired solicted or unsolicited. So, another suggested update:

"Posture Data Publication: The Information Model SHOULD allow for the data to be provided by an endpoint either solicited or unsolicited. That is, data models MUST support at least one or both means to publish data: solicited or unsolicited. For example, a compliance-server provider may publish endpoint posture information in response to a request from a consumer (solicited), or it may publish posture information driven by a change in the posture of the endpoint (unsolicited)."

@jimsch
Copy link
Contributor Author

jimsch commented May 10, 2015

Looks fine in -05.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants