Subject: Re: [sacm] [draft-ietf-sacm-architecture] Figure 1- Simple Architecture Model (#21)

From: llorenzin <[email-masked]>
Date: Wed, 08 Jul 2015 10:24:01 -0700

We discussed this in the original development of the architecture draft and came to consensus that a controller can either be a broker (no data interaction, simply providing control functions for clients to find each other and share information), a proxy (receiving a consumer request, retrieving data from the appropriate providing, and sharing it with the requestor), or a repository (receiving data from providers, storing it, and sharing it with consumers upon request).  Each of these modes enables a different (sometimes overlapping) set of use cases.

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Wednesday, July 08, 2015 8:54 AM
To: sacmwg/draft-ietf-sacm-architecture
Subject: [draft-ietf-sacm-architecture] Figure 1- Simple Architecture Model (#21)

Version -03

I have a minor problem with the picture. I think that a "Repository" is a Provider and not a Controller. (I don't know if I also think that a "Repository" is also a consumer or not - It would depend if it was actively looking for data or not.) The controller plane controls access to data but not data itself.

—
Reply to this email directly or view it on GitHub <https://github.com/sacmwg/draft-ietf-sacm-architecture/issues/21> . <https://github.com/notifications/beacon/AKcH1fDjBzMpetDNUdsSkU4ioShLd-KXks5obT77gaJpZM4FUigD.gif> 

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

---

From: henkbirkholz <[email-masked]>
Date: Wed, 08 Jul 2015 10:38:07 -0700

The "center piece" in the figure - the controller - represents different sets of data plane and control plane functions (and maybe even management plane functions). Three separate mixes of functions to be precise, which are labeled broker, proxy and repository.
Only the broker (probably) contains only control plane funtions. The repository most certainly contains a considerable set of data plane functions with interfaces that can act as provider and consumer.

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

---

From: henkbirkholz <[email-masked]>
Date: Wed, 08 Jul 2015 12:49:46 -0700

I agree with your observation, I think. Maybe a repository could be a prominent example of a SACM component that is potentially composed of a variety of functions that enable it to act as a provider/publisher, consumer/subscriber, broker or even as proxy in some cases (therefore, potentially placing it at multiple possible positions or planes in the point of view illustrated by the picture).

Maybe this could also imply that there could be different variants of repositories with more powerful sets or more basic sets of functions, depending on their purpose or the environment (it might not have to act as a broker or proxy on the control plane in some scenarios)?

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

---

From: david-waltermire-nist <[email-masked]>
Date: Wed, 08 Jul 2015 12:56:34 -0700

+1

From: henkbirkholz [mailto:[email-masked]]
Sent: Wednesday, July 08, 2015 3:50 PM
To: sacmwg/draft-ietf-sacm-architecture
Subject: Re: [draft-ietf-sacm-architecture] Figure 1- Simple Architecture Model (#21)

—
Reply to this email directly or view it on GitHub<https://github.com/sacmwg/draft-ietf-sacm-architecture/issues/21#issuecomment-119711546>.

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

---

From: Nancy <[email-masked]>
Date: Sun, 19 Jul 2015 13:44:46 -0700

So, is the suggestion converging on removing "repository" from the "Control plane" arrow and adding "Repository" as another SACM component (that can be either a publisher or subscriber)?

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

---

From: llorenzin <[email-masked]>
Date: Mon, 20 Jul 2015 01:13:13 -0700

I'm happy to clarify that a repository can also be either a consumer or a provider (or both) in the SACM components descriptions. However, I do not agree with removing repository from the control plane.  The repository model of controller supports the loose coupling and unsolicited publication requirements - SACM publishers can publish information to a repository at will, rather than in response to a request, and that information is then available for any (authorized) consumer to retrieve without any dependency on the original publisher being available or even known. (The Ice Station Zebra use case is one of the best-fit use cases for a repository as controller.) Also, the repository model is one of the few running-code implementations - and the only standards-based example - of existing real-world SACM-style security automation.

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

---

From: llorenzin <[email-masked]>
Date: Thu, 23 Jul 2015 14:49:13 -0700

Done in -04

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

---

From: Jim Schaad <[email-masked]>
Date: Thu, 23 Jul 2015 23:35:43 -0700

Closed #21.

---
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-architecture/issues/21#event-364158189