Re: [onap-discuss] [VNFSDK]New bridge for this week VNFSDK meeting
Let's try my ZOOM: Hi there, Brian Hedstrom is inviting you to a scheduled Zoom meeting. Topic: Brian Hedstrom's Personal Meeting Room Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/8672717796 Or iPhone one-tap : US: +16465588656,,8672717796# or +16699006833,,8672717796# Or Telephone: Dial(for higher quality, dial a number based on your current location): US: +1 646 558 8656 or +1 669 900 6833 Meeting ID: 867 271 7796 International numbers available: https://zoom.us/u/jWaq2 On Fri, Aug 10, 2018 at 7:06 AM, gaoweitao wrote: > Hi VNFSDK Team Member, > > > > Since Chris is enjoying his vacation, his personal bridge doesn’t > work. Please use this bridge for today’s meeting: > https://welink-meeting.zoom.us/j/151217618 > > > > BR > > Victor > > > -- Brian Hedstrom Founder/CEO OAM Technology Consulting LLC oam.technology brian.hedst...@oamtechnologies.com 720-470-7091 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11821): https://lists.onap.org/g/onap-discuss/message/11821 Mute This Topic: https://lists.onap.org/mt/24247816/21656 Group Owner: onap-discuss+ow...@lists.onap.org Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[onap-discuss] [modeling] Modeling Project Casablanca M1 Scope
Modeling Subcommittee: I was reviewing the Casablanca Release Deck <https://wiki.onap.org/display/DW/TSC+2018-07-05+Meeting+Agenda?preview=%2F33067338%2F36963870%2FONAP+Casablanca+M1+Status+Summary+Version4.pdf> which Gildas presented today on the TSC call and the TSC approved. In looking at the Modeling Project Casablanca M1 checklist <https://wiki.onap.org/pages/viewpage.action?pageId=35524278> (R3 Scope), I noticed that most all of the Epics and Stories are for developing service and resource Information Models and Data Models and their mappings. These items are not part of the Modeling Project scope <https://wiki.onap.org/pages/viewpage.action?pageId=3247202>, but are part of the Modeling Subcommittee activities. This has created a lot of confusion as to what the Modeling Project scope and responsibility is versus the Modeling Subcommittee. Can we get clarification? In addition, I (again) recommend we change the name of the modeling project to eliminate confusion. For example, Model Parsers project. Thanks -- Brian Hedstrom Founder/CEO OAM Technology Consulting LLC oam.technology brian.hedst...@oamtechnologies.com 720-470-7091 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10896): https://lists.onap.org/g/onap-discuss/message/10896 Mute This Topic: https://lists.onap.org/mt/23168988/21656 Group Owner: onap-discuss+ow...@lists.onap.org Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[onap-discuss] [vnfsdk] VNF SDK Meeting Agenda for 3/2/18
Team, Agenda for tomorrow's VNF SDK Meeting is posted at: https://wiki.onap.org/display/DW/VNF+SDK+03-02-2018+Meeting Thanks, -- Brian Hedstrom Founder/CEO OAM Technology Consulting LLC oam.technology brian.hedst...@oamtechnologies.com 720-470-7091 ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
[onap-discuss] [vnfsdk] VNF SDK Meeting Agenda for 2/23/18
Team, Agenda for tomorrow's VNF SDK Meeting is posted at: https://wiki.onap.org/display/DW/VNF+SDK+02-23-2018+Meeting Thanks, -- Brian Hedstrom Founder/CEO OAM Technology Consulting LLC oam.technology brian.hedst...@oamtechnologies.com 720-470-7091 ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
[onap-discuss] [vnfsdk] VNF SDK Meeting Agenda for 2/16/18
Team, Agenda for tomorrow's VNF SDK Meeting is posted at: https://wiki.onap.org/display/DW/VNF+SDK+02-16-2018+Meeting Thanks, -- Brian Hedstrom Founder/CEO OAM Technology Consulting LLC oam.technology brian.hedst...@oamtechnologies.com 720-470-7091 ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
[onap-discuss] [vnfsdk] VNF SDK Meeting Agenda for 2/9/18
Team, Agenda for tomorrow's VNF SDK Meeting is posted at: https://wiki.onap.org/display/DW/VNF+SDK+02-09-2018+Meeting Thanks -- Brian Hedstrom Founder/CEO OAM Technology Consulting LLC oam.technology brian.hedst...@oamtechnologies.com 720-470-7091 ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
Re: [onap-discuss] [modeling] Whether How and when we should move to Github for modeling spec update process
Hi Deng, I'm in favor of using Git for model development. Do we want to add a Poll page to the wiki to track participant voting on this topic? Thanks Brian On Wed, Jan 31, 2018 at 7:31 PM, denghui (L) <denghu...@huawei.com> wrote: > Hello modeling subcommittee, > > > > Many Thanks to Jessie’s kind presentation on GitHub for Papyrus model. > > https://wiki.onap.org/display/DW/Modeling+sub-committee+Contributions > > https://wiki.onap.org/download/attachments/16003450/ > GitHub%20for%20Papyrus%20Model.pptx?api=v2 > > > > Due to time limitation, we would like to discussion in the list together > with the communities whether, how and when we should move to Github to > manage the modeling spec update process. > > > > Thanks a lot for your advice > > Best regards, > > > > DENG Hui > -- Brian Hedstrom Founder/CEO OAM Technology Consulting LLC oam.technology brian.hedst...@oamtechnologies.com 720-470-7091 ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
[onap-discuss] [vnfsdk] VNF SDK Meeting Agenda for 2/2/18
Team, Agenda for tomorrow's VNF SDK Meeting is posted at: https://wiki.onap.org/display/DW/VNF+SDK+02-02-2018+Meeting Thanks -- Brian Hedstrom Founder/CEO OAM Technology Consulting LLC oam.technology brian.hedst...@oamtechnologies.com 720-470-7091 ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
[onap-discuss] [vnfsdk] VNF SDK Meeting Agenda for 1/19/18
Team, Agenda for tomorrow's VNF SDK Meeting is posted at: https://wiki.onap.org/display/DW/VNF+SDK+01-19-2018+Meeting Thanks -- Brian Hedstrom Founder/CEO OAM Technology Consulting LLC oam.technology brian.hedst...@oamtechnologies.com 720-470-7091 ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
[onap-discuss] [vnfsdk] VNF SDK Meeting Agenda for 12/22/17
Team, Agenda for tomorrow's VNF SDK Meeting is posted at: https://wiki.onap.org/display/DW/VNF+SDK+12-22-2017+Meeting Please review epics and bring proposed user stories. Thanks -- Brian Hedstrom Founder/CEO OAM Technology Consulting LLC oamtechnologyconsulting.com brian.hedst...@oamtechnologies.com 720-470-7091 ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
[onap-discuss] [vnfsdk] VNF SDK Meeting Agenda for 12/1/17
Team, Agenda for tomorrow's VNF SDK Meeting is posted at: https://wiki.onap.org/display/DW/VNF+SDK+12-01-2017+Meeting Please see assigned action items. Thanks -- Brian Hedstrom Founder/CEO OAM Technology Consulting LLC oamtechnologyconsulting.com brian.hedst...@oamtechnologies.com 720-470-7091 ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
[onap-discuss] [vnfsdk] VNF SDK Meeting tomorrow (11/17/17) is CANCELLED
Hi Team, Chris would like to cancel tomorrow's meeting and hold it via email. Look for an email from Chris later tonight or tomorrow. Thanks, -- Brian Hedstrom Founder/CEO OAM Technology Consulting LLC oamtechnologyconsulting.com brian.hedst...@oamtechnologies.com 720-470-7091 ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
[onap-discuss] [vnfsdk] Agenda posted for 8/18/17 meeting
VNF SDK Team, Agenda for tomorrow's meeting is posted here: https://wiki.onap.org/display/DW/VNF+SDK+08-18-2017+Meeting There are several outstanding JIRA issues remaining to complete Sprint 2. Thanks, -- Brian Hedstrom Founder/CEO OAM Technology Consulting LLC oamtechnologyconsulting.com brian.hedst...@oamtechnologies.com 720-470-7091 ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
[onap-discuss] [vnfsdk] Copied Open-O VNF SDK Wiki content into ONAP
VNF SDK Team, I've exported the VNF SDK Wiki project from the Open-O Wiki <https://wiki.open-o.org/display/VS/VNF+SDK+Project+Home+Page> and uploaded the files to https://wiki.onap.org/display/DW/VNF+SDK+Legacy+Artifacts/ There's a PDF, an HTML and an XML file done as three separate exports. We should be able to import the XML file into the ONAP Wiki to reconstruct all the pages inside the ONAP Wiki, but I don't have experience with that and it may require an administrator to perform the action. We'll want to follow up with an admin for the ONAP Confluence space. Thanks, -- Brian Hedstrom Founder/CEO OAM Technology Consulting LLC oamtechnologyconsulting.com brian.hedst...@oamtechnologies.com 720-470-7091 ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
Re: [onap-discuss] [Modeling] agenda for today teleconf
our, agenda would be: > > 1) Working through other Modeling related projects, suggested > influence. (All) > > 2) Combination of declarative and imperative workflow with BPMN > (Huabin Zhao) > > > > Thanks > > > > Rittwik and Deng Hui > > ___ > onap-discuss mailing list > onap-discuss@lists.onap.org > https://lists.onap.org/mailman/listinfo/onap-discuss > > -- Brian Hedstrom Founder/CEO OAM Technology Consulting LLC oamtechnologyconsulting.com brian.hedst...@oamtechnologies.com 720-470-7091 ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
[onap-discuss] [onap-tsc] 答复：Re: Modelling discussion on Friday May 5th
e 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 >> 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> 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 >> 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 >> >> *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 , Brian Hedstrom < >> brian.hedstrom at oamtechnologies.com> >> >> *Cc: *"JANA, RITTWIK \(RITTWIK\)" , onap-discuss >> , onap-tsc >> >> >> >> 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 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 > chnologies.com> wrote: >> >> The way to put all these different data models under a single umbrella is >> to create a UML <https://en.wikipedia.org/wiki/Unified_Modeling_Language> >> 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
[onap-discuss] [onap-tsc] 答复：Re: Modelling discussion on Friday May 5th
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 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 > *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 , Brian Hedstrom < > brian.hedstrom at oamtechnologies.com> > *Cc: *"JANA, RITTWIK \(RITTWIK\)" , onap-discuss < > onap-discuss at lists.onap.org>, onap-tsc > > 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 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 chnologies.com> wrote: > >> The way to put all these different data models under a single umbrella is >> to create a UML <https://en.wikipedia.org/wiki/Unified_Modeling_Language> >> 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 >> <http://www.uml-diagrams.org/realization.html>, 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, 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
[onap-discuss] [onap-tsc] 答复：Re: Modelling discussion on Friday May 5th
See https://tools.ietf.org/html/draft-betts-netmod-framework-data-schema-uml-04 *Framework for Deriving Interface Data Schema from UML Information Models* See https://tools.ietf.org/html/draft-mansfield-netmod-uml-to-yang-03 *Guidelines for Translation of UML Information Model to YANG Data Model* On Mon, Apr 24, 2017 at 11:01 AM, Ed Warnicke 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@ > oamtechnologies.com> wrote: > >> The way to put all these different data models under a single umbrella is >> to create a UML <https://en.wikipedia.org/wiki/Unified_Modeling_Language> >> 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 >> <http://www.uml-diagrams.org/realization.html>, 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, 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; 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 proce
[onap-discuss] [onap-tsc] 答复：Re: Modelling discussion on Friday May 5th
> > > 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) wrote: > > > > Hello all > > > > We are happy to let you know that we are hosting a modeling session on > Friday, May 5th, AT Lab. > > 9:00-10:30 Shitao moderate: TOSCA NFV Profile > > 10:30-12:00 Rittwik moderate: AT 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 > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists. > onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg= > 2dwD7a5k4V9cZl09O7uTpejnZMF8aa01W3yMqrrZC5Y=HRoKLiOZCWLzl3Z- > 00DLQIUCwCAWqQL50mUFHtfYXYA=731fuCUnXbuPSOGHEcVf4U29cHpOGP > KmwevRHGAoeiY= > > > > > > > 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 externally http://tim.techmahindra.com/tim/disclaimer.html > internally within TechMahindra. > > > > > > ___ > ONAP-TSC mailing list > ONAP-TSC at lists.onap.org > https://lists.onap.org/mailman/listinfo/onap-tsc > > -- Brian Hedstrom Founder/CEO OAM Technology Consulting LLC oamtechnologyconsulting.com brian.hedstrom at oamtechnologies.com 720-470-7091 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.onap.org/pipermail/onap-discuss/attachments/20170424/55ea7fc9/attachment.html>
