<div dir="ltr">
<p><span style="font-stretch:normal;font-size:13px;font-family:Arial">Summary from IRC chat 10/14/2014 on weekly meeting [1] [2]</span><br>
<span style="font-stretch:normal;font-size:13px;font-family:Arial"></span><br>
<span style="font-stretch:normal;font-size:13px;font-family:Arial">Topic: Declarative Language for Congress —> Enactor/Enforcer</span><br>
<span style="font-stretch:normal;font-size:13px;font-family:Arial"></span><br>
<span style="font-stretch:normal;font-size:13px;font-family:Arial">Question: Shall we specify a declarative language for communicating policy configured in Congress to enactors / enforcement systems</span><br>
<span style="font-stretch:normal;font-size:13px;font-family:Arial"></span><br>
<span style="font-stretch:normal;font-size:13px;font-family:Arial">Hypothesis (derived at conclusion of discussion): </span><br>
<span style="font-stretch:normal;font-size:13px;font-family:Arial"> - S</span><span style="font-stretch:normal;font-size:12px;font-family:Helvetica">pecify declarative protocol and framework for describing policy with extensible attributes/value fields described in a base ontology, with additional affinity ontologies, is what is needed earlier than later, to be able to achieve it as an end-state, before too many Enactors dive into one-offs.</span><br>
<span style="font-stretch:normal;font-size:12px;font-family:Helvetica"> - We could achieve that specification once we know the right structure</span><br>
<span style="font-stretch:normal;font-size:13px;font-family:Arial"></span><br>
<span style="font-stretch:normal;font-size:13px;font-family:Arial">Discussion:</span><br></p><ul><li><span style="font-family:Arial;font-size:13px">Given the following framework:</span><br></li><ul><li><span style="font-family:Arial;font-size:13px">Elements: </span></li><ul><li><span style="font-family:Arial;font-size:13px">Congress - The policy description point, a place where:</span></li><ul><li><span style="font-family:Arial;font-size:13px">(a) policy inputs are collected</span></li><li><span style="font-family:Arial;font-size:13px">(b) collected policy inputs are integrated</span></li><li><span style="font-family:Arial;font-size:13px">(c) policy is defined</span></li><li><span style="font-family:Arial;font-size:13px">(d) declares policy intent to enforcing / enacting systems </span></li><li><span style="font-family:Arial;font-size:13px">(e) observes state of environment, noting policy violations</span></li></ul><li><span style="font-family:Arial;font-size:13px">Feeders - provides policy inputs to Congress</span></li><li><span style="font-family:Arial;font-size:13px">Enactors / Enforcers - receives policy declarations from Congress and enacts / enforces the policy according to its capabilities</span></li><ul><li><span style="font-family:Arial;font-size:13px">E.g. Nova for VM placement, Neutron for interface connectivity, FWaaS for access control, etc. </span></li></ul></ul></ul></ul>
<span style="font-stretch:normal;font-size:13px;font-family:Arial">What will the protocol be for the Congress —> Enactors / Enforcers?</span><p></p><p><font face="Arial"><br></font>
<span style="font-stretch:normal;font-size:13px;font-family:Arial">thinrichs: we’ve </span><span style="font-stretch:normal;font-size:12px;font-family:Helvetica">we've been assuming that Congress will leverage whatever the Enactors (policy engines) and Feeders (and more generally datacenter services) that exist are using. For basic datacenter services, we had planned on teaching Congress what their API is and what it does. So there's no new protocol there—we'd just use HTTP or whatever the service expects. For Enactors, there are 2 pieces: (1) what policy does Congress push and (2) what protocol does it use to do that? We don't know the answer to (1) yet. (2) is less important, I think. For (2) we could use opflex, for example, or create a new one. (1) is hard because the Enactors likely have different languages that they understand. I’m not aware of anyone thinking about (2). I’m not thinking about (2) b/c I don't know the answer to (1). The *really* hard thing to understand IMO is how these Enactors should cooperate (in terms of the information they exchange and the functionality they provide). The bits they use to wrap the messages they send while cooperating is a lower-level question.</span><br>
<span style="font-stretch:normal;font-size:12px;font-family:Helvetica"><br></span></p><p><span style="font-stretch:normal;font-size:12px;font-family:Helvetica">jasonsb & glebo: feel the need to clarify (2)</span><br>
<span style="font-stretch:normal;font-size:12px;font-family:Helvetica"><br></span></p><p><span style="font-stretch:normal;font-size:12px;font-family:Helvetica">glebo: if we come out strongly with a framework spec that identifies a protocol for (2), and make it clear that Congress participants, including several data center Feeders and Enactors, are in consensus, then the other Feeders & Enactors will line up, in order to be useful in the modern deployments. Either that, or they will remain isolated from the new environment, or their customers will have to create custom connectors to the new environment. It seems that we have 2 options. (a) Congress learns any language spoken by Feeders and Enactors, or (b) specifies a single protocol for Congress —> Enactors policy declarations, including a highly adaptable public registry(ies) for defining the meaning of content blobs in those messages. For (a) Congress would get VERY bloated with an abstraction layer, modules, semantics and state for each different language it needed to speak. And there would be 10s of these languages. For (b), there would be one way to structure messages that were constructed of blobs in (e.g.) some sort of Type/Length/Value (TLV) method, where the Types and Values were specified in some Internet registry. </span><br>
<span style="font-stretch:normal;font-size:12px;font-family:Helvetica"><br></span></p><p><span style="font-stretch:normal;font-size:12px;font-family:Helvetica">jasonsb: Could we attack this from the opposite direction? E.g. if Congress wanted to provide an operational dashboard to show if things are in compliance, it would be better served by receiving the state and stats from the Enactors in a single protocol. Could a dashboard like this be a carrot to lure the various players into a single protocol for Congress —> Enactor?</span><br>
<span style="font-stretch:normal;font-size:12px;font-family:Helvetica"><br></span></p><p><span style="font-stretch:normal;font-size:12px;font-family:Helvetica">glebo & jasonsb: If Congress has to give Enactors precise instructions on what to do, then Congress will bloat, having to have intelligence about each Enactor type, and hold its state and such. If Congress can deliver generalized policy declarations, and the Enactor is responsible for interpreting it, and applying it, and gathering and analyzing the state so that it knows how to react, then the intelligence and state that it is specialized in knowing will live in the Enactor. A smaller Congress is better, and this provides cleaner “layering” of the problem space overall.</span><br>
<span style="font-stretch:normal;font-size:12px;font-family:Helvetica"><br></span></p><p><span style="font-stretch:normal;font-size:12px;font-family:Helvetica">thinrichs: would love to see a single (2) language, but doesn’t see that as a practical solution in the short term, dubious that anyone will use Congress if it only works when all of the Enactors speak the Congress language. It’s an insertion question.</span><br>
<span style="font-stretch:normal;font-size:12px;font-family:Helvetica"><br></span></p><p><span style="font-stretch:normal;font-size:12px;font-family:Helvetica">glebo: the key is NOT the bits on the wire, not at all (though having that format set is VERY helpful). The key is the lexicon, the registry of shared types/attributes and value codes that (i) get used over and over again across many Enactor/Enforcement domains, and (ii) have domain-specific registries for domain-only types / attributes & values. Eg. IPv4addr will be in the all-domains, thus a (i), and AccessControlAction, and it's value codes of Permit, Deny, Reset, SilentDrop, Log, etc., will live in (ii) FWaaS registry only. Just examples. This way, each domain (e.g. Neutron L2/L3, Nova-placement, FWaaS, LBaaS, StorageaaS) can define their own attributes and publish the TLVs for them, and do so VERY quickly, independent of the rest of the Congress domains. </span></p><p><font face="Helvetica"><span style="font-size:11.8181819915771px"><br></span></font>
<span style="font-stretch:normal;font-size:12px;font-family:Helvetica">thinrichs & glebo: Agree that domains should be empowered to build their own ontologies. We’ve shied away building them in Congress because we don’t believe we can succeed, too many different ontologies between problem domains (e.g., FWaaS vs StorageaaS) as well as vertical markets (e.g., Finance vs. Tech). E.g. maybe all the major financials get together and develop their own ontology and publish it, based on their needs. And there will probably need to be a base set of Types/Attributes for building policy that get used by 80% of the varying ontology domains that would need to be defined by Congress, to start, the specific Enactor groups can create their own extension ontologies.</span></p><p><font face="Helvetica"><span style="font-size:11.8181819915771px"><br></span></font>
<span style="font-stretch:normal;font-size:12px;font-family:Helvetica">glebo: So we need to specify a language / protocol for these various communities and vendors to send/receive their declarations of policy that are expressed using a wide set of types/attributes and values from a registry? And their would need to be allowance for vendor specific types/attributes.</span><br>
<span style="font-stretch:normal;font-size:12px;font-family:Helvetica">thinrichs & glebo: we need to look at this from the perspective of insertion. The above described is a great end state. How do we get from today to insertion to desired end-state? Once we gain traction, customers will start wanting more, and at that point we'll have the leverage to tell them "well we need the other vendors of services that we're supposed to manage to utilize some standard interface/language/protocol/whatever”, then the standardization of ontologies is very useful.</span></p><p><font face="Helvetica"><span style="font-size:11.8181819915771px"><br></span></font>
<span style="font-stretch:normal;font-size:12px;font-family:Helvetica">For some Enactor/Enforcer (we used GBP since it's logicy) figure out how Congress and that Enactor *should* interoperate. Some questions to think about: </span><br></p><ul><li><span style="font-family:Helvetica;font-size:12px">What information do that need to exchange?</span><br></li><li><span style="font-family:Helvetica;font-size:12px">What if someone other than Congress gives that Enactor instructions?</span><br></li><li><span style="font-family:Helvetica;font-size:12px">What happens when the policy cannot be completely delegated to Enactor?</span><br></li><li><span style="font-family:Helvetica;font-size:12px">What happens when Policy is delegated to Enactor and Enactor says, “I can’t do that today.”?</span><br></li><li><span style="font-family:Helvetica;font-size:12px">What if a hierarchy of policy (reflecting organizational stake holders) exists?</span><br></li><li><span style="font-family:Helvetica;font-size:12px">What if coordination is needed between two Enactor engines? The Enactor can’t bear sole burden in this case, can it?</span><br></li></ul>
<span style="font-stretch:normal;font-size:12px;font-family:Helvetica">Possible path forward, that considers insertion to end-state:</span><br><ul><li><span style="font-family:Helvetica;font-size:12px">Desired end-state for Congress —> Enactor declarations:</span><br></li><ul><li><span style="font-family:Helvetica;font-size:12px">single carrying protocol for bits on wire and ordering, etc.</span></li><li><span style="font-family:Helvetica;font-size:12px">single “base” ontology covering the 80 of types needed, published publicly (registry)</span></li><li><span style="font-family:Helvetica;font-size:12px">multiple domain-specific ontologies for various affinity groups published publicly (registries)</span></li><li><span style="font-family:Helvetica;font-size:12px">vendor-specific ontologies published publicly (registries). We want to keep these as small as possible, and encourage participation in the base or affinity group registries as much as possible.</span></li></ul><li><span style="font-family:Helvetica;font-size:12px">Note that there really are only 4 or 5 Enactor types today (although many more are popping up very quickly)</span><br></li><li><span style="font-family:Helvetica;font-size:12px">We want to put a stake in the ground now, ASAP, so emerging Enactor domains and vendors can start immediately toward the end-state </span><br></li><li><span style="font-family:Helvetica;font-size:12px">Meanwhile, we will support existing APIs (a very small number) for existing Enactor types, but on a short term basis only, with a published plan to deprecate the use of the multiple, and transition toward the use of the one protocol with many ontologies.</span></li></ul>
<span style="font-stretch:normal;font-size:13px;font-family:Arial"></span><br>
<span style="font-stretch:normal;font-size:13px;font-family:Arial">discussion started #openstack-meeting-3 Oct 14, 2014 at 17:24:00 [1]</span><br>
<span style="font-stretch:normal;font-size:13px;font-family:Arial">Discussion then moved to #congress 18:01:40 [2] </span><br>
<span style="font-stretch:normal;font-size:13px;font-family:Arial"></span><br>
<span style="font-stretch:normal;font-size:13px;font-family:Arial">[1] </span><span style="font-stretch:normal;font-size:13px;font-family:Arial;color:rgb(4,46,238)"><u><a href="http://eavesdrop.openstack.org/meetings/congressteammeeting/2014/congressteammeeting.2014-10-14-17.01.log.html">http://eavesdrop.openstack.org/meetings/congressteammeeting/2014/congressteammeeting.2014-10-14-17.01.log.html</a></u></span><span style="font-stretch:normal;font-size:13px;font-family:Arial"> 17:24:00</span><br>
<span style="font-stretch:normal;font-size:13px;font-family:Arial">[2] (could not find the transcript for #congress. Pointer appreciated) 18:01:40</span> <br><p></p><div>Hope it helps,</div>----<br>Open industry related email from<br>Gregory M. Lebovitz<br>
</div>