Thanks Bryan We will be more than happy to provide TOSCA primer, and much more. I will set something up after the face2face and have it recorded.
(for TOSCA itself - we already recorded some videos in: https://www.youtube.com/watch?v=aMkqLI6o-58 <https://www.youtube.com/watch?v=aMkqLI6o-58> and https://www.youtube.com/watch?v=6xGmpi--7-A <https://www.youtube.com/watch?v=6xGmpi--7-A> ) but my offer is to cater a TOSCA specific topics for the ONAP community - if the team interested? Thanks! ? amir > On Apr 25, 2017, at 11:42 AM, SULLIVAN, BRYAN L <bs3131 at att.com> wrote: > > I would recommend someone from Gigaspaces to help out with a TOSCA intro. > Cloudify has one of the most developed TOSCA-based data models. I?ve been > using the Cloudify model and also the more limited TOSCA for NFV Simple > Profile model features supported by Tacker in OPNFV as part of the Models > project ( <>https://wiki.opnfv.org/display/models > <https://wiki.opnfv.org/display/models>). > > Thanks, > Bryan Sullivan | AT&T > > From: onap-discuss-bounces at lists.onap.org <mailto:onap-discuss-bounces at > lists.onap.org> [mailto:onap-discuss-bounces at lists.onap.org > <mailto:onap-discuss-bounces at lists.onap.org>] On Behalf Of Ed Warnicke > Sent: Tuesday, April 25, 2017 11:18 AM > To: Brian Hedstrom <brian.hedstrom at oamtechnologies.com > <mailto:brian.hedstrom at oamtechnologies.com>> > Cc: onap-discuss <onap-discuss at lists.onap.org <mailto:onap-discuss at > lists.onap.org>> > Subject: Re: [onap-discuss] [onap-tsc] ???Re: Modelling discussion on Friday > May 5th > > Brian, > > I'm sympathetic. I had Model Driven Development experience with UML prior to > being involved in yang based modeling. There's unquestionably a learning > curve in learning a new modeling language. My experience in crossing that > chasm though is that had I tried to do modeling in UML intended for yang... I > would have been pushing deeply suboptimal models because yang is different > enough than UML that you loose a lot in the translation. I'm back to being > relatively new on Tosca, so again, I feel your pain. My gut though is that > the end experience will be the same: it's worth the investment to learn the > tools being used on the ground. > > Do we have someone in the community who would be willing to do some intro to > Tosca for modelers talks to help us close this gap and get our existing > modeling talent up to productive speed faster? It would be a great service > to the community. > > Ed > > On Tue, Apr 25, 2017 at 11:13 AM, Brian Hedstrom <brian.hedstrom at > oamtechnologies.com <mailto:brian.hedstrom at oamtechnologies.com>> wrote: > As a modeler, I had challenges with coming late to the game on the Open-O > project (FEB timeframe). Everything was TOSCA based and I didn't have TOSCA > data model experience. > As such, I wasn't able to effectively understand what the "information" model > was. > The barrier to entry was therefore needing to learn TOSCA data modeling > language. > It is unrealistic to assume a data modeler has mastery of all data modeling > languages, encodings, toolsets, etc. How does a domain expert who is not in > a developer role effectively communicate a set of requirements, architecture > and design to developers? Are we just skipping a design and architecture > phase? How do we capture and document what needs to be built, before building > it? I definitely support an agile iterative approach to all of this. > > On Tue, Apr 25, 2017 at 12:00 PM, Ed Warnicke <hagbard at gmail.com > <mailto:hagbard at gmail.com>> wrote: > I think the most productive thing we can do is figure out ways to 'embed' > good modeling folks (its a very real, and distinct skill) closer to the ground > in the projects with a more collaborative stance. Encouraging these kinds > of things were suggested as the role for the modeling coordinator. > > Ed > > On Tue, Apr 25, 2017 at 9:56 AM, Brijesh Khandelwal <kbrijesh at > techmahindra.com <mailto:kbrijesh at techmahindra.com>> wrote: > Greetings, > > Essentially, two kind of models > 1. Information Models: Which will define ?What? needs to be orchestrate. > These ?What? model to get inputs from Data model parts of TOSCA, YAML, YANG, > A&AI, and SDC for standardization. > 2. Behavior Models: Which will define ?How? to orchestrate. This is covered > by Workflow, BPMN/BPEL, UML-Activity/State models, Some behavior parts in > TOSCA, YANG/NETCONF. > 2a. While BPMN/BPEL is good for process/workflow orchestration, but > there is increasing need to include Event-Driven orchestration for > DCAE/Policy based closed-loops, dynamic changes to process definitions, > flexibility to execute parts of process. > > I think first focus on modeling standard can be on ?What? models. ?How? > models need to evolve further, can have multiple-options to use BPMN/BPEL, > custom state-machines or event-driven orchestration. > > -Brijesh > > > From: onap-discuss-bounces at lists.onap.org <mailto:onap-discuss-bounces at > lists.onap.org> [mailto:onap-discuss-bounces at lists.onap.org > <mailto:onap-discuss-bounces at lists.onap.org>] On Behalf Of Ash Young > Sent: Tuesday, April 25, 2017 8:35 AM > To: Sridhar Ramaswamy > Cc: onap-discuss > Subject: Re: [onap-discuss] [onap-tsc] ???Re: Modelling discussion on Friday > May 5th > > Can we please have parallel options then? This has disaster written all over > it. I have no problem with people moving fast. I have spent the past almost 5 > years listening to the same people going down this path. So while I fail to > see the speed that keeps being promised, I'm quite certain that our overall > manageability has not really improved across the industry with this TOSCA > only world. > > I really don't want to fight and this is Open Source. So can we leave room > for some of the other folks too? > > Thanks, > > Ash > > On Mon, Apr 24, 2017 at 11:54 PM, Sridhar Ramaswamy <srics.r at gmail.com > <mailto:srics.r at gmail.com>> wrote: > +1, couldn?t agree more. Also, we need to keep in mind the inherent time lag > in consuming Information Model -> Data Model -> Implementation which will > slow us down. > > Based on my experience working between TOSCA NFV and Tacker project, an > iterative approach works the best - consume an available, sufficiently > flexible data model in the implementation to validate and incorporate > feedback based its outcome back into the data model. I say this with a huge > respect for the modelers who are critical in taking us towards a harmonized > Data Model / Information model for NFV. > > - Sridhar > > On Mon, Apr 24, 2017 at 4:47 PM, Ed Warnicke <hagbard at gmail.com > <mailto:hagbard at gmail.com>> wrote: > I strongly second this. > > My experience is that there is a huge service for the good modelers who > engage with the community to do incredible good... but modeling in a vacuum, > away from the implementation, and then just expecting the implementers to > follow directions works poorly. > > I'd say that a far better activity for the long term health would be to plug > good model people into the places in the community where models are in > progress. Their wisdom as participants can be huge, but they need to > *participate*, not work off in a tower of UML. > > Ed > > On Mon, Apr 24, 2017 at 4:25 PM, Michael Brenner <michael at gigaspaces.com > <mailto:michael at gigaspaces.com>> wrote: > ... on the other hand, what does one do with a smooth cohesive model, if you > can't easily translate it to a data model? Without any intent to dive into a > debate about whether the example is right or not ... we have an ETSI NFV VNF > UML model ... and we cannot translate it into any data model - it takes > manual work. The other issue is sort of the reverse - i.e. you don't actually > KNOW that the UML model is right, until you implement it. And it is difficult > to implement it, when you don't have the automatic translation tools. So you > end up building an ideal model, but you don't know if it works ... until you > have the right translation tools. How long is one to wait ... instead of > implementing and iterating? > Like with any other project, it really comes down to a schedule, and knowing > what you want to achieve within that schedule. > > Best, > Michael > > On Mon, Apr 24, 2017 at 6:23 PM, Brian Hedstrom <brian.hedstrom at > oamtechnologies.com <mailto:brian.hedstrom at oamtechnologies.com>> wrote: > While the tools are maturing and advancing, if we choose to close that door > now, there's no cohesive UML Common Information Model for ONAP. > Consequently, we would lack a protocol agnostic information model and when > the next cool data modeling language or encoding scheme comes out, we have to > start again with working backward. Another key benefit is that UML is much > easier to comprehend due to it's graphical diagram nature, versus needing to > understand a data modeling language and/or data encoding mechanism. > Consensus can be made on class diagrams for example, then translation to a > data modeling language can be easily done by hand or by the emerging tools > (see my previous email with the links). > > On Mon, Apr 24, 2017 at 12:29 PM, Michael Brenner <michael at gigaspaces.com > <mailto:michael at gigaspaces.com>> wrote: > Hi all, > > I actually tend to agree with Ed. While it may be an ideal approach in > theory, tools for automatic generation from UML to Yang, or other modeling > languages for that matter are improving, they are still too far from perfect, > and require a lot of hand-holding so-to-speak, and as a result - too many > headaches. We may be mired in tool debugging, instead on progressing on ONAP. > > Michael > > From: Ash Young <ash at yunify.org <mailto:ash at yunify.org>> > Subject: Re: [onap-discuss] [onap-tsc] ???Re: Modelling discussion on Friday > May 5th > Date: April 24, 2017 at 10:09:22 AM PDT > To: Ed Warnicke <hagbard at gmail.com <mailto:hagbard at gmail.com>>, Brian > Hedstrom <brian.hedstrom at oamtechnologies.com <mailto:brian.hedstrom at > oamtechnologies.com>> > Cc: "JANA, RITTWIK \(RITTWIK\)" <rjana at research.att.com <mailto:rjana at > research.att.com>>, onap-discuss <onap-discuss at lists.onap.org > <mailto:onap-discuss at lists.onap.org>>, onap-tsc <onap-tsc at > lists.onap.org <mailto:onap-tsc at lists.onap.org>> > > I'm actually in agreement with Brian on approach and tool. So much work has > been going on here that I really don't want to see us go backwards by > thinking Yang solves everything. > > Ash > > Sent from my iPhone > > On Apr 24, 2017, at 12:01, Ed Warnicke <hagbard at gmail.com <mailto:hagbard > at gmail.com>> wrote: > > I love UML in a variety of contexts, but for expressing things that are > destined to be expressed in yang, or for creating things to be rendered to > yang, in my experience its been a very poor fit. > > Ed > > On Mon, Apr 24, 2017 at 9:41 AM, Brian Hedstrom <brian.hedstrom at > oamtechnologies.com <mailto:brian.hedstrom at oamtechnologies.com>> wrote: > The way to put all these different data models under a single umbrella is to > create a UML > <https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Unified-5FModeling-5FLanguage&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2-FskNSRL5sc9nQutgafCDIk3JbYrtcUwMwT5Zs1Tnk&m=SKU5wDAq-vdd_tKhLSqe4ZMbZvIYm_msbPt_QJB-6-I&s=uD4VtDsVcnXmLILI_BNZcd3yvPr411WcBFpu9xHt6Ko&e=> > Information Model using Eclipse/Papyrus (as an open source tool). > Unified Modeling Language (UML) is a standard syntax for describing the > architectural design of a system > ? Object Management Group (OMG) & ISO standard > ? Originated from object-oriented software development methods > UML includes many diagrams types to graphically represent parts of a system?s > model, including > ? Structural Views: The static nature of the system using objects, > attributes and relationships (e.g., information or components that must be > present in the system). This includes class diagrams and component diagrams. > ? Behavioral: The dynamic nature of the system through collaboration > of objects and state changes (e.g., activities performed by the system). This > includes use case diagrams, sequence diagrams, state machines. > UML is protocol agnostic and therefore these "Information Models" are > protocol agnostic. > > UML models can then be transformed into protocol specific data models such as > YANG, XML, SMIv2, etc. > > Creating a UML Information Model allows data cohesion across the various > interfaces in the system. Using Interface Realizations > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.uml-2Ddiagrams.org_realization.html&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2-FskNSRL5sc9nQutgafCDIk3JbYrtcUwMwT5Zs1Tnk&m=SKU5wDAq-vdd_tKhLSqe4ZMbZvIYm_msbPt_QJB-6-I&s=pr2shORg2uYEQ-d9q5abCpUNfFk3VyMbqWyB4I-9iP4&e=>, > specific interfaces can be modeled. In fact, an interface Information Model > could be transformed into multiple data models to support multiple management > protocols. > > Therefore, the focus first is on building a UML Information Model, then once > that's approved by the organization, then data models and encodings can be > generated based on the chosen interface protocols. > > Thanks, > Brian > > On Sun, Apr 23, 2017 at 5:13 AM, <zhao.huabing at zte.com.cn > <mailto:zhao.huabing at zte.com.cn>> wrote: > Hi Brijesh, > > You brought up a great topic, we may need to converge at the same aspect, but > for different aspects, there are different modelling languages which can > better meet the specific requirement of that aspect, and they are very > complementary. > > For example, TOSCA(Heat is another, come with openstack) is a good choice for > the topology modelling of cloud application , YANG can be used for the > configuration model( normally using for L2 L3, can be used for L4-L7 as > well), and BPMN is good at workflow orchestration. > > It's difficult to put all these different modelling capabilities in a single > data model or using an unique DSL, and we don't need to. But It's possible to > make them work together smoothly under a unified umbrella system to > accomplish the automated close loop and I'm glad to see ONAP has already make > a very good start at that job. > > Thanks, > Huabing > > ???? > ???: BrijeshKhandelwal; > ???:GILBERT, MAZIN E (MAZIN E); denghui (L); JANA,RITTWIK (RITTWIK); > onap-discuss at lists.onap.org <mailto:onap-discuss at lists.onap.org>; > onap-tsc at lists.onap.org <mailto:onap-tsc at lists.onap.org>; > ??: 2017-04-22 11:56:56 > ??:Re: [onap-discuss] [onap-tsc] Modelling discussion on Friday May 5th > > Greetings, > > Adding some thoughts on information model: > Orchestration need to interoperate among different interfaces, which in turn > need to deal with very different payloads in form of YAML, YANG, JSON etc. > There will be lots of data processing among these models to process complete > service. Handling these templates in orchestrator will impose limitations on > capability and performance of orchestrator. > So, there should have standardized data model for smooth processing among > orchestration steps. > > Probably first time, orchestration is composing 3 different worlds of > Network, Infra, IT, with different tunes of YANG, YAML, JSON/XML. > Is there a play to develop standardized data models for orchestration, which > will meet needs of each area? Is TOSCA sufficient? Or need some extended JSON > data models? > > > -Brijesh > > From: onap-tsc-bounces at lists.onap.org <mailto:onap-tsc-bounces at > lists.onap.org> [mailto:onap-tsc-bounces at lists.onap.org > <mailto:onap-tsc-bounces at lists.onap.org>] On Behalf Of GILBERT, MAZIN E > (MAZIN E) > Sent: Thursday, April 20, 2017 8:30 AM > To: denghui (L); JANA, RITTWIK (RITTWIK) > Cc: onap-discuss at lists.onap.org <mailto:onap-discuss at lists.onap.org>; > onap-tsc at lists.onap.org <mailto:onap-tsc at lists.onap.org> > Subject: Re: [onap-tsc] Modelling discussion on Friday May 5th > > Rittwik, Deng, > > This is great. Thank you for taking the lead. > > I realize the focus is on TOSCA and parsers. Wonderful! > I want to take you one level higher to start by discussing > what the framework look like for the information model. Perhaps invite folks > who have > operational experience. Then start describing the differernt > data models and how TOSCA plays a role in driving service chaining and micro > services > (like analytics, data collections, etc). > > It would be great if the outcome of this mini session to > be a recommendation position/paper or a proposal for a project. > > Mazin > > > > On Apr 20, 2017, at 4:34 AM, denghui (L) <denghui12 at huawei.com > <mailto:denghui12 at huawei.com>> wrote: > > Hello all > > We are happy to let you know that we are hosting a modeling session on > Friday, May 5th, AT&T Lab. > 9:00-10:30 Shitao moderate: TOSCA NFV Profile > 10:30-12:00 Rittwik moderate: AT&T Parser > 13:30-16:00 DengHui moderate: Modelling & Opendeployment > > Please kindly help to let us know if you are interested in joining us, so > that we can book a proper meeting room for our discussion > > Best regards, > > Rittwik & DENG Hui > _______________________________________________ > ONAP-TSC mailing list > ONAP-TSC at lists.onap.org <mailto:ONAP-TSC at lists.onap.org> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=2dwD7a5k4V9cZl09O7uTpejnZMF8aa01W3yMqrrZC5Y&m=HRoKLiOZCWLzl3Z-00DLQIUCwCAWqQL50mUFHtfYXYA&s=731fuCUnXbuPSOGHEcVf4U29cHpOGPKmwevRHGAoeiY&e= > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=2dwD7a5k4V9cZl09O7uTpejnZMF8aa01W3yMqrrZC5Y&m=HRoKLiOZCWLzl3Z-00DLQIUCwCAWqQL50mUFHtfYXYA&s=731fuCUnXbuPSOGHEcVf4U29cHpOGPKmwevRHGAoeiY&e=> > > ============================================================================================================================ > Disclaimer: This message and the information contained herein is proprietary > and confidential and subject to the Tech Mahindra policy statement, you may > review the policy at http://www.techmahindra.com/Disclaimer.html > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.techmahindra.com_Disclaimer.html&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2-FskNSRL5sc9nQutgafCDIk3JbYrtcUwMwT5Zs1Tnk&m=SKU5wDAq-vdd_tKhLSqe4ZMbZvIYm_msbPt_QJB-6-I&s=r-r5tJ8nrzkqK23gRhsLb8OPoVGsx0ZViv7wBIsDERs&e=> > externally http://tim.techmahindra.com/tim/disclaimer.html > <https://urldefense.proofpoint.com/v2/url?u=http-3A__tim.techmahindra.com_tim_disclaimer.html&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2-FskNSRL5sc9nQutgafCDIk3JbYrtcUwMwT5Zs1Tnk&m=SKU5wDAq-vdd_tKhLSqe4ZMbZvIYm_msbPt_QJB-6-I&s=I_E3sLggaT17cZNlg-j_fqEtbleQ6AgNJInp6wdwt90&e=> > internally within TechMahindra. > ============================================================================================================================ > > > _______________________________________________ > ONAP-TSC mailing list > ONAP-TSC at lists.onap.org <mailto:ONAP-TSC at lists.onap.org> > https://lists.onap.org/mailman/listinfo/onap-tsc > <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2-FskNSRL5sc9nQutgafCDIk3JbYrtcUwMwT5Zs1Tnk&m=SKU5wDAq-vdd_tKhLSqe4ZMbZvIYm_msbPt_QJB-6-I&s=P8L9j_gZwjGQC4tcknm4WXzU-JNDiYfG2m23mDtk3Uw&e=> > > > _______________________________________________ > onap-discuss mailing list > onap-discuss at lists.onap.org <mailto:onap-discuss at lists.onap.org> > https://lists.onap.org/mailman/listinfo/onap-discuss > <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2-FskNSRL5sc9nQutgafCDIk3JbYrtcUwMwT5Zs1Tnk&m=SKU5wDAq-vdd_tKhLSqe4ZMbZvIYm_msbPt_QJB-6-I&s=6x0gM_NY63X6tDI-POUFwDUKJCwsKIAwWfxEHDWspJU&e=> > > > > -- > Brian Hedstrom > Founder/CEO > OAM Technology Consulting LLC > oamtechnologyconsulting.com > <https://urldefense.proofpoint.com/v2/url?u=http-3A__oamtechnologyconsulting.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2-FskNSRL5sc9nQutgafCDIk3JbYrtcUwMwT5Zs1Tnk&m=SKU5wDAq-vdd_tKhLSqe4ZMbZvIYm_msbPt_QJB-6-I&s=nLt-NN81kUfdCyp2FUY63_q1q_-lbOawuPER4I99rZ0&e=> > brian.hedstrom at oamtechnologies.com <mailto:brian.hedstrom at > oamtechnologies.com> > 720-470-7091 <tel:(720)%20470-7091> > > > _______________________________________________ > onap-discuss mailing list > onap-discuss at lists.onap.org <mailto:onap-discuss at lists.onap.org> > https://lists.onap.org/mailman/listinfo/onap-discuss > <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2-FskNSRL5sc9nQutgafCDIk3JbYrtcUwMwT5Zs1Tnk&m=SKU5wDAq-vdd_tKhLSqe4ZMbZvIYm_msbPt_QJB-6-I&s=6x0gM_NY63X6tDI-POUFwDUKJCwsKIAwWfxEHDWspJU&e=> > > > _______________________________________________ > onap-discuss mailing list > onap-discuss at lists.onap.org <mailto:onap-discuss at lists.onap.org> > https://lists.onap.org/mailman/listinfo/onap-discuss > <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2-FskNSRL5sc9nQutgafCDIk3JbYrtcUwMwT5Zs1Tnk&m=SKU5wDAq-vdd_tKhLSqe4ZMbZvIYm_msbPt_QJB-6-I&s=6x0gM_NY63X6tDI-POUFwDUKJCwsKIAwWfxEHDWspJU&e=> > > > _______________________________________________ > onap-discuss mailing list > onap-discuss at lists.onap.org <mailto:onap-discuss at lists.onap.org> > https://lists.onap.org/mailman/listinfo/onap-discuss > <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2-FskNSRL5sc9nQutgafCDIk3JbYrtcUwMwT5Zs1Tnk&m=SKU5wDAq-vdd_tKhLSqe4ZMbZvIYm_msbPt_QJB-6-I&s=6x0gM_NY63X6tDI-POUFwDUKJCwsKIAwWfxEHDWspJU&e=> > > > _______________________________________________ > onap-discuss mailing list > onap-discuss at lists.onap.org <mailto:onap-discuss at lists.onap.org> > https://lists.onap.org/mailman/listinfo/onap-discuss > <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2-FskNSRL5sc9nQutgafCDIk3JbYrtcUwMwT5Zs1Tnk&m=SKU5wDAq-vdd_tKhLSqe4ZMbZvIYm_msbPt_QJB-6-I&s=6x0gM_NY63X6tDI-POUFwDUKJCwsKIAwWfxEHDWspJU&e=> > > > _______________________________________________ > onap-discuss mailing list > onap-discuss at lists.onap.org <mailto:onap-discuss at lists.onap.org> > https://lists.onap.org/mailman/listinfo/onap-discuss > <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2-FskNSRL5sc9nQutgafCDIk3JbYrtcUwMwT5Zs1Tnk&m=SKU5wDAq-vdd_tKhLSqe4ZMbZvIYm_msbPt_QJB-6-I&s=6x0gM_NY63X6tDI-POUFwDUKJCwsKIAwWfxEHDWspJU&e=> > > > > -- > Brian Hedstrom > Founder/CEO > OAM Technology Consulting LLC > oamtechnologyconsulting.com > <https://urldefense.proofpoint.com/v2/url?u=http-3A__oamtechnologyconsulting.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2-FskNSRL5sc9nQutgafCDIk3JbYrtcUwMwT5Zs1Tnk&m=SKU5wDAq-vdd_tKhLSqe4ZMbZvIYm_msbPt_QJB-6-I&s=nLt-NN81kUfdCyp2FUY63_q1q_-lbOawuPER4I99rZ0&e=> > brian.hedstrom at oamtechnologies.com <mailto:brian.hedstrom at > oamtechnologies.com> > 720-470-7091 <tel:(720)%20470-7091> > > _______________________________________________ > onap-discuss mailing list > onap-discuss at lists.onap.org <mailto:onap-discuss at lists.onap.org> > https://lists.onap.org/mailman/listinfo/onap-discuss > <https://lists.onap.org/mailman/listinfo/onap-discuss> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.onap.org/pipermail/onap-discuss/attachments/20170425/0f45ef2c/attachment.html>
