Subject: Re: [sacm] SACM Architecture Draft

From: Jarrett Lu <[email-masked]>
Date: Thu, 14 Feb 2019 17:27:27 -0800

Hi Adam & SACM,

I read the (active) architecture draft, and I believe it's a good one. 
The hackathon work reflected in the draft definitely carries some weight.

Some architecture entities could be expanded and described at a more 
abstract level. For example, this draft appears to equate "capabilities" 
with set of interfaces. Are SACM capabilities supposed to be 
discoverable? If so, how should it be represented? If 
capabilities/functional interfaces are described in more general terms, 
and use XMPP-grid+ as an example of how it meets the functional 
requirements, this may make it appear less solution-centric.

I vote for including workflows in the architecture document. It just 
reads better that way. It will increase the document size and takes 
longer to finish. As long as good progress is being made, is it really 
urgent to finish and publisher the architecture document.

I think the Security Consideration section of the old architecture draft 
is pretty good. Do XMPP-grid XEPs adress the MitM, transport integrity 
and confidentiality concerns mentioned there?

Regards.

- Jarrett

On 12/27/18 01:29 PM, Adam Montville wrote:
> Dear SACM,
>
> Happy (belated) Holidays and a Happy New Year to you!
>
> At our recent virtual interim meeting I promised to post a note to the 
> list regarding our architecture draft to do three things:
>
>  1. Request review
>  2. Indicate whether we (the authors) believe it's on the right track
>  3. Assuming 2 is good, a list of what's left to be done.
>
> So, we're going to start with 2, move on to 3, and then end with 1...
>
> Bill and I both believe that the architecture draft is, indeed, on the 
> right track. Henk, and possibly others (Nancy?), have described this 
> draft as being too solutions-specific. Section 3, "Architectural 
> Overview" is intended to be the place in this draft to describe the 
> abstract ideas in the architecture. Section 3.1 talks a little bit 
> about the roles of the SACM Components, and Section 3.2 provides the 
> known information about an XMPP-based instantiation of the 
> architecture (note Appendix A maps this instantiation back to our SACM 
> requirements, RFC8248).
>
> Assuming that we are on the right track, then here's what we think yet 
> needs to be done:
>
>   * Document specific Components, Capabilities, Interfaces, and Workflows
>       o IT Asset Management could probably stand to be fleshed out
>       o Vulnerability Management is reasonable documented in this
>         draft, but may need work
>       o Configuration management probably needs to be fleshed out as
>         well (needs to be tied to SACM Use Cases)
>   * Determine where to document the above (in this draft or in new
>     drafts), which will determine how long this draft takes to complete.
>   * Prague hackathon to continue the trend of discovering an
>     XMPP-based solution
>   * TODOs in the draft
>       o Privacy Considerations
>       o Security Considerations
>   * Flesh out our IANA Considerations
>       o Will likely result in additional draft work
>
>
>
> Clearly, there's a lot to be done here, and we really need your 
> specific, actionable feedback on this draft. Feel free to reach out 
> here or to either of us directly.
>
> This draft in GitHub: https://github.com/sacmwg/draft-ietf-sacm-arch
>
> This draft on the SACM documents page: 
> https://datatracker.ietf.org/doc/draft-ietf-sacm-arch/
>
>
> Kind regards,
>
> Adam & Bill
>
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: Adam Montville <[email-masked]>
Date: Fri, 15 Feb 2019 06:05:10 -0600

Hi Jarret, 

Thank you for reading through the draft. Happy to talk about some of these things today during the interim. I think we would prefer that interfaces/capabilities are first described abstractly — irrespective of any specific messaging solution — and then use XMPP-Grid+ as an implementation example.

Kind regards,

Adam

> On Feb 14, 2019, at 7:27 PM, Jarrett Lu <[email-masked]> wrote:
> 
> Hi Adam & SACM,
> 
> I read the (active) architecture draft, and I believe it's a good one. The hackathon work reflected in the draft definitely carries some weight. 
> 
> Some architecture entities could be expanded and described at a more abstract level. For example, this draft appears to equate "capabilities" with set of interfaces. Are SACM capabilities supposed to be discoverable? If so, how should it be represented? If capabilities/functional interfaces are described in more general terms, and use XMPP-grid+ as an example of how it meets the functional requirements, this may make it appear less solution-centric. 
> 
> I vote for including workflows in the architecture document. It just reads better that way. It will increase the document size and takes longer to finish. As long as good progress is being made, is it really urgent to finish and publisher the architecture document.
> 
> I think the Security Consideration section of the old architecture draft is pretty good. Do XMPP-grid XEPs adress the MitM, transport integrity and confidentiality concerns mentioned there?
> 
> Regards.
> 
> - Jarrett
> 
> 
>> At our recent virtual interim meeting I promised to post a note to the list regarding our architecture draft to do three things:
>> Request review
>> Indicate whether we (the authors) believe it's on the right track
>> Assuming 2 is good, a list of what's left to be done.
>> Bill and I both believe that the architecture draft is, indeed, on the right track. Henk, and possibly others (Nancy?), have described this draft as being too solutions-specific. Section 3, "Architectural Overview" is intended to be the place in this draft to describe the abstract ideas in the architecture. Section 3.1 talks a little bit about the roles of the SACM Components, and Section 3.2 provides the known information about an XMPP-based instantiation of the architecture (note Appendix A maps this instantiation back to our SACM requirements, RFC8248). 
>> 
>> Assuming that we are on the right track, then here's what we think yet needs to be done:
>> 
>> Document specific Components, Capabilities, Interfaces, and Workflows
>> IT Asset Management could probably stand to be fleshed out
>> Vulnerability Management is reasonable documented in this draft, but may need work
>> Configuration management probably needs to be fleshed out as well (needs to be tied to SACM Use Cases)
>> Determine where to document the above (in this draft or in new drafts), which will determine how long this draft takes to complete.
>> Prague hackathon to continue the trend of discovering an XMPP-based solution
>> TODOs in the draft
>> Privacy Considerations
>> Security Considerations
>> Flesh out our IANA Considerations
>> Will likely result in additional draft work
>> 
>> 
>> Clearly, there's a lot to be done here, and we really need your specific, actionable feedback on this draft. Feel free to reach out here or to either of us directly.
>> 
>> This draft in GitHub: https://github.com/sacmwg/draft-ietf-sacm-arch <https://github.com/sacmwg/draft-ietf-sacm-arch> 
>> 
>> This draft on the SACM documents page: https://datatracker.ietf.org/doc/draft-ietf-sacm-arch/ <https://datatracker.ietf.org/doc/draft-ietf-sacm-arch/>
>> 
>> 
>> Kind regards,
>> 
>> Adam & Bill
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/sacm <https://www.ietf.org/mailman/listinfo/sacm>
>

---

From: Sherif Mansour <[email-masked]>
Date: Mon, 18 Feb 2019 19:05:41 +0000

Hey Everyone,
Sorry for popping in so infrequently. I have taken a brief look at the
architecture, and I have some feedback:
Should the downstream users pull their data from the repo (an authoritative
data source) instead of the message bus?
That way, there is a consistent view of that the current state of an
end-point security posture and analysis can be built on top if it. I would
not think it can be done directly from the message bus. I also would think
the information from the repo would be bi directional?
Equally had some question on the data ingest (message bus) I assume there
is an Access model as not everything on the message bus is to be accessible
by everyone, is that taken into consideration?
Should the Orchstrator have a direct connection to the Repo, there are
cases where the orchestrator needs reference data in order to tell the
posture managers what to do and not just react to them. Additionally there
are cases where what the posture manager finds from the collectors will be
different than what is on file in inventory and the discrepancy.

On Fri, Feb 15, 2019 at 12:05 PM Adam Montville <[email-masked]>
wrote:

> Hi Jarret,
>
> Thank you for reading through the draft. Happy to talk about some of these
> things today during the interim. I think we would prefer that
> interfaces/capabilities are first described abstractly — irrespective of
> any specific messaging solution — and then use XMPP-Grid+ as an
> implementation example.
>
> Kind regards,
>
> Adam
>
> I read the (active) architecture draft, and I believe it's a good one. The
> hackathon work reflected in the draft definitely carries some weight.
>
> with set of interfaces. Are SACM capabilities supposed to be discoverable?
> If so, how should it be represented? If capabilities/functional interfaces
> are described in more general terms, and use XMPP-grid+ as an example of
> how it meets the functional requirements, this may make it appear less
> solution-centric.
>
> I vote for including workflows in the architecture document. It just reads
> better that way. It will increase the document size and takes longer to
> finish. As long as good progress is being made, is it really urgent to
> finish and publisher the architecture document.
>
> is pretty good. Do XMPP-grid XEPs adress the MitM, transport integrity and
> confidentiality concerns mentioned there?
>
> Regards.
>
> - Jarrett
>
> right track. Henk, and possibly others (Nancy?), have described this draft
> as being too solutions-specific. Section 3, "Architectural Overview" is
> intended to be the place in this draft to describe the abstract ideas in
> the architecture. Section 3.1 talks a little bit about the roles of the
> SACM Components, and Section 3.2 provides the known information about an
> XMPP-based instantiation of the architecture (note Appendix A maps this
> instantiation back to our SACM requirements, RFC8248).
>
>    - Document specific Components, Capabilities, Interfaces, and Workflows
>       - IT Asset Management could probably stand to be fleshed out
>       - Vulnerability Management is reasonable documented in this draft,
>       but may need work
>       - Configuration management probably needs to be fleshed out as well
>       (needs to be tied to SACM Use Cases)
>    - Determine where to document the above (in this draft or in new
>    - Prague hackathon to continue the trend of discovering an XMPP-based
>    solution
>    - TODOs in the draft
>       - Privacy Considerations
>       - Security Considerations
>    - Flesh out our IANA Considerations
>       - Will likely result in additional draft work
>
>
>
> Clearly, there's a lot to be done here, and we really need your specific,
> actionable feedback on this draft. Feel free to reach out here or to either
> of us directly.
>
> sacm mailing [email-masked]://www.ietf.org/mailman/listinfo/sacm
>
>

---

From: Bill Munyan <[email-masked]>
Date: Tue, 19 Feb 2019 09:54:21 -0500

Sherif,

Thanks for reading the draft and providing feedback!  We really appreciate
it...  I have some comments/questions in-line:

> Should the downstream users pull their data from the repo (an
authoritative data source) instead of the message bus?
end-point security posture and analysis can be built on top if it. I would
not think it can be > done directly from the message bus. I also would
think the information from the repo would be bi directional?

[Bill M]:
The idea behind the message transfer system is to help define the
interfaces between components.  The intent here is really to help create a
"cooperative ecosystem", enabling vendors to plug in components where they
fit in the architecture, develop custom components where necessary, etc.

Whether the "message transfer system" exists over a message bus,
integration pattern, REST interface, or other, the downstream functions
would have access to the repository (or repositories) over some sort of
"query" interface.  In the case of XMPP being used as the message transfer
system, that interface could be a request using a custom IQ stanza with
query information, and a response with the requested information.  In a
solution which consolidates a results repository with reporting, there may
just be a simple web application to visualize the data.

I agree the information in the repository is bi-directional, and the
diagram is intended to reflect that.

is an Access model as not everything on the message bus is to be accessible
by > everyone, is that taken into consideration?

[Bill M]:
I would also agree there would be an access model necessary, but that can
be solution-specific.  Again using the XMPP-based solution, that access
model could be maintained through the orchestrator's roster, roster groups,
various pub-sub nodes, etc.  Is there a particular access model you had in
mind when asking this question?  Any solution-based ideas on this certainly
help me personally in visualizing all the concepts.

cases where the orchestrator needs reference data in order to tell the
posture > managers what to do and not just react to them. Additionally
there are cases where what the posture manager finds from the collectors
will be different than > what is on file in inventory and the discrepancy.

[Bill M]:
In the first diagram, the orchestrator would have a connection to the repo
via the message transfer system.  This is a great question that will help
us discover more about the interfaces we need to describe further in the
document.  That "query" interface from the orchestrator can assist in
getting the necessary reference data before sending collection requests off
to the various collectors in the ecosystem.

Hope that helps!  Glad to keep the conversation going as well, so thank you
again for your review and feedback.

Cheers,
Bill M.

On Mon, Feb 18, 2019 at 2:06 PM Sherif Mansour <[email-masked]>
wrote:

> Should the downstream users pull their data from the repo (an
> authoritative data source) instead of the message bus?
> On Fri, Feb 15, 2019 at 12:05 PM Adam Montville <
> [email-masked]> wrote:
>
>> Hi Jarret,
>>
>> Thank you for reading through the draft. Happy to talk about some of
>> these things today during the interim. I think we would prefer that
>> reads better that way. It will increase the document size and takes longer
>> to finish. As long as good progress is being made, is it really urgent to
>>       - Configuration management probably needs to be fleshed out as

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Tue, 19 Feb 2019 15:28:42 +0000

Organizations will need to interact with repositories operated by other organizations (e.g., the National Vulnerability Database, CVE project, etc.) as well as local repositories that host historic information. In some cases, clients might not know what to specifically query, but may instead need to browse through hosted data to find what information they are interested in. A request/response communication pattern is ideal for this type of interaction.

A message bus is ideal for exchanging up-to-date information or for notifying participating clients when new information is available from a service. It might be best to allow for both types of solutions in the SACM architecture. There are numerous ways to provide for a common authentication model without performing all authentication/communications through a message bus.

Where I see value in a message bus is for discovery of services, for notifications of new data being available in a service, and to flow new data through the system. I don’t think it is practical to force all components to communicate only through the message bus.

Here is a potential flow with a hybrid of both types of communications.

1) Client authenticates to the message bus and subscribes to notifications of new configuration checklist data.
2) A ROLIE server syndicates new checklist data from the NVD, from the national checklist program repository using the ROLIE protocol.
3) The ROLIE server notifies all clients that this data is available over the message bus.
4) A collection client queries the ROLIE server to retrieve new checklist data, and to find relevant historic checklist data it needs to collect for. It may also request SWID tags, OVAL definitions, and other supporting information from local or remote services to determine what to collect.
5) Collection in performed, perhaps on an ongoing basis, and collected data can then be published over the message bus and also stored to directly associated storage locations (e.g., CMDBs).

A message bus only solution would complicate the communication in #4 above, and would not account for remote communications in #2 and #4 at all. In all cases above, communication can occur using standardized interfaces. Some use a message bus, others use interfaces provided by other protocols like ROLIE. This also allows for a cooperative ecosystem, and doesn’t diminish from vendors providing solutions that can plug in.

Regards,
Dave

From: sacm <[email-masked]> On Behalf Of Bill Munyan
Sent: Tuesday, February 19, 2019 9:54 AM
To: Sherif Mansour <[email-masked]>
Cc: Jarrett Lu <[email-masked]>; Adam Montville <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [sacm] SACM Architecture Draft

Sherif,

Thanks for reading the draft and providing feedback!  We really appreciate it...  I have some comments/questions in-line:

> Should the downstream users pull their data from the repo (an authoritative data source) instead of the message bus?
> That way, there is a consistent view of that the current state of an end-point security posture and analysis can be built on top if it. I would not think it can be > done directly from the message bus. I also would think the information from the repo would be bi directional?

[Bill M]:
The idea behind the message transfer system is to help define the interfaces between components..  The intent here is really to help create a "cooperative ecosystem", enabling vendors to plug in components where they fit in the architecture, develop custom components where necessary, etc.

Whether the "message transfer system" exists over a message bus, integration pattern, REST interface, or other, the downstream functions would have access to the repository (or repositories) over some sort of "query" interface.  In the case of XMPP being used as the message transfer system, that interface could be a request using a custom IQ stanza with query information, and a response with the requested information.  In a solution which consolidates a results repository with reporting, there may just be a simple web application to visualize the data.

I agree the information in the repository is bi-directional, and the diagram is intended to reflect that.

> Equally had some question on the data ingest (message bus) I assume there is an Access model as not everything on the message bus is to be accessible by > everyone, is that taken into consideration?

[Bill M]:
I would also agree there would be an access model necessary, but that can be solution-specific.  Again using the XMPP-based solution, that access model could be maintained through the orchestrator's roster, roster groups, various pub-sub nodes, etc.  Is there a particular access model you had in mind when asking this question?  Any solution-based ideas on this certainly help me personally in visualizing all the concepts.

> Should the Orchstrator have a direct connection to the Repo, there are cases where the orchestrator needs reference data in order to tell the posture > managers what to do and not just react to them. Additionally there are cases where what the posture manager finds from the collectors will be different than > what is on file in inventory and the discrepancy.

[Bill M]:
In the first diagram, the orchestrator would have a connection to the repo via the message transfer system.  This is a great question that will help us discover more about the interfaces we need to describe further in the document.  That "query" interface from the orchestrator can assist in getting the necessary reference data before sending collection requests off to the various collectors in the ecosystem.

Hope that helps!  Glad to keep the conversation going as well, so thank you again for your review and feedback.

Cheers,
Bill M.

On Mon, Feb 18, 2019 at 2:06 PM Sherif Mansour <[email-masked]<mailto:[email-masked]>> wrote:
Hey Everyone,
Sorry for popping in so infrequently. I have taken a brief look at the architecture, and I have some feedback:
Should the downstream users pull their data from the repo (an authoritative data source) instead of the message bus?
That way, there is a consistent view of that the current state of an end-point security posture and analysis can be built on top if it. I would not think it can be done directly from the message bus. I also would think the information from the repo would be bi directional?
Equally had some question on the data ingest (message bus) I assume there is an Access model as not everything on the message bus is to be accessible by everyone, is that taken into consideration?
Should the Orchstrator have a direct connection to the Repo, there are cases where the orchestrator needs reference data in order to tell the posture managers what to do and not just react to them. Additionally there are cases where what the posture manager finds from the collectors will be different than what is on file in inventory and the discrepancy.

On Fri, Feb 15, 2019 at 12:05 PM Adam Montville <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jarret,

Kind regards,

Adam

On Feb 14, 2019, at 7:27 PM, Jarrett Lu <[email-masked]<mailto:[email-masked]>> wrote:

Hi Adam & SACM,

Regards.

- Jarrett

  1.  Request review

     *   IT Asset Management could probably stand to be fleshed out
     *   Vulnerability Management is reasonable documented in this draft, but may need work
     *   Configuration management probably needs to be fleshed out as well (needs to be tied to SACM Use Cases)

  *   Determine where to document the above (in this draft or in new drafts), which will determine how long this draft takes to complete.
  *   Prague hackathon to continue the trend of discovering an XMPP-based solution
  *   TODOs in the draft

     *   Privacy Considerations
     *   Security Considerations

     *   Will likely result in additional draft work

This draft on the SACM documents page: https://datatracker.ietf.org/doc/draft-ietf-sacm-arch/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-sacm-arch%2F&data=02%7C01%7Cdavid.waltermire%40nist.gov%7Ccefa6df9e0a9432bedc908d6967a3e1d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636861849106737807&sdata=mgt4EPWcuBsLx3DR1sx01TbCEUlt6F37FpqKroSJNjI%3D&reserved=0>

Kind regards,

Adam & Bill

sacm mailing list

sacm@ietf..org<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/sacm<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsacm&data=02%7C01%7Cdavid.waltermire%40nist.gov%7Ccefa6df9e0a9432bedc908d6967a3e1d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636861849106747816&sdata=YVjK0x2u12K9Ds3GWE4ekxjJrQsGu7CxVlEXHyLduik%3D&reserved=0>

_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsacm&data=02%7C01%7Cdavid.waltermire%40nist.gov%7Ccefa6df9e0a9432bedc908d6967a3e1d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636861849106757821&sdata=g%2Bt4sWCXGlkpiUnrQcAUFZir6pSmRODJgcOSYI%2FWrZs%3D&reserved=0>

_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsacm&data=02%7C01%7Cdavid.waltermire%40nist.gov%7Ccefa6df9e0a9432bedc908d6967a3e1d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636861849106757821&sdata=g%2Bt4sWCXGlkpiUnrQcAUFZir6pSmRODJgcOSYI%2FWrZs%3D&reserved=0>
_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsacm&data=02%7C01%7Cdavid.waltermire%40nist.gov%7Ccefa6df9e0a9432bedc908d6967a3e1d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636861849106767830&sdata=RDvylTUYEQKBFEyoecw35wfzIIBRGG7K4YxJ5250Lw8%3D&reserved=0>

---

From: Sherif Mansour <[email-masked]>
Date: Tue, 19 Feb 2019 17:59:17 +0000

Hello David,

Do you think there should be a distinction between reference data feeds
such as NVD/Mitre/Other Threat Intel feeds, Inventory, and a security
repository? I was assuming the repository in an authoritative data source
which maps an asset to a security result and enriched with external feed
sources e.g. NVD.
The reason being you would need a data model and the ability of
consistently tie the data sets together. I wasn't to focused on the
interface, but it would be helpful to have an ADS that provides a source of
truth of the security posture for any given point in time.

I dug up an old diagram I sent out last year - it can use an update to give
you an idea where I was going with this.
The light blue boxes are end clients or CI/CD systems which would leverage
SCAM orchestration
The pink and orange boxes are inventories/datafeed/reference data which all
feed into a repo which acts as a source of truth of the security posture
for any given point in time.

On Tue, Feb 19, 2019 at 3:28 PM Waltermire, David A. (Fed) <
[email-masked]> wrote:

> Organizations will need to interact with repositories operated by other
> organizations (e.g., the National Vulnerability Database, CVE project,
> etc.) as well as local repositories that host historic information. In some
> cases, clients might not know what to specifically query, but may instead
> need to browse through hosted data to find what information they are
> interested in. A request/response communication pattern is ideal for this
> type of interaction.
>
>
>
> A message bus is ideal for exchanging up-to-date information or for
> notifying participating clients when new information is available from a
> service. It might be best to allow for both types of solutions in the SACM
> architecture. There are numerous ways to provide for a common
> authentication model without performing all authentication/communications
> through a message bus.
>
>
>
> Where I see value in a message bus is for discovery of services, for
> notifications of new data being available in a service, and to flow new
> data through the system. I don’t think it is practical to force all
> components to communicate only through the message bus.
>
>
>
> 2) A ROLIE server syndicates new checklist data from the NVD, from the
> national checklist program repository using the ROLIE protocol.
>
> 4) A collection client queries the ROLIE server to retrieve new checklist
> data, and to find relevant historic checklist data it needs to collect for.
> It may also request SWID tags, OVAL definitions, and other supporting
> information from local or remote services to determine what to collect.
>
> 5) Collection in performed, perhaps on an ongoing basis, and collected
> data can then be published over the message bus and also stored to directly
> associated storage locations (e.g., CMDBs).
>
>
>
> A message bus only solution would complicate the communication in #4
> above, and would not account for remote communications in #2 and #4 at all.
> In all cases above, communication can occur using standardized interfaces.
> Some use a message bus, others use interfaces provided by other protocols
> like ROLIE. This also allows for a cooperative ecosystem, and doesn’t
> diminish from vendors providing solutions that can plug in.
>
>
>
> Regards,
>
> Dave
>
>
>
> *From:* sacm <[email-masked]> *On Behalf Of * Bill Munyan
> *Sent:* Tuesday, February 19, 2019 9:54 AM
> *To:* Sherif Mansour <[email-masked]>
> *Cc:* Jarrett Lu <[email-masked]>; Adam Montville <
> [email-masked]>; <[email-masked]> <[email-masked]>
> *Subject:* Re: [sacm] SACM Architecture Draft
>
>
>
> Sherif,
>
>
>
> interfaces between components..  The intent here is really to help create a
> > Equally had some question on the data ingest (message bus) I assume
> there is an Access model as not everything on the message bus is to be
> accessible by > everyone, is that taken into consideration?
>
>
>
> [Bill M]:
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-sacm-arch%2F&data=02%7C01%7Cdavid.waltermire%40nist.gov%7Ccefa6df9e0a9432bedc908d6967a3e1d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636861849106737807&sdata=mgt4EPWcuBsLx3DR1sx01TbCEUlt6F37FpqKroSJNjI%3D&reserved=0>
>
>
>
>
>
> Kind regards,
>
>
>
> Adam & Bill
>
>
>
> sacm@ietf..org <[email-masked]>
>
> https://www.ietf.org/mailman/listinfo/sacm <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsacm&data=02%7C01%7Cdavid.waltermire%40nist.gov%7Ccefa6df9e0a9432bedc908d6967a3e1d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636861849106747816&sdata=YVjK0x2u12K9Ds3GWE4ekxjJrQsGu7CxVlEXHyLduik%3D&reserved=0>
>
>
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsacm&data=02%7C01%7Cdavid.waltermire%40nist.gov%7Ccefa6df9e0a9432bedc908d6967a3e1d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636861849106757821&sdata=g%2Bt4sWCXGlkpiUnrQcAUFZir6pSmRODJgcOSYI%2FWrZs%3D&reserved=0>
>
>
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsacm&data=02%7C01%7Cdavid.waltermire%40nist.gov%7Ccefa6df9e0a9432bedc908d6967a3e1d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636861849106757821&sdata=g%2Bt4sWCXGlkpiUnrQcAUFZir6pSmRODJgcOSYI%2FWrZs%3D&reserved=0>
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsacm&data=02%7C01%7Cdavid.waltermire%40nist.gov%7Ccefa6df9e0a9432bedc908d6967a3e1d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636861849106767830&sdata=RDvylTUYEQKBFEyoecw35wfzIIBRGG7K4YxJ5250Lw8%3D&reserved=0>
>
>