Hi Jianguo, I would fully agree with you, if we implemented use cases in their full form, as in Amsterdam Release. Once we break the use cases into a separate requirements and bring them for discussion, this may not work well.
But, I guess, we need to take this discussion back to the Usecase subcommittee, as we should have a consensus before bringing it further. In order to make a constructive discussion, if possible, please look on one of the requirements, already prepared for endorsement, and bring the points of what is missing there. I will send the next meeting agenda by a separate email. Best regards, Alla Goldner Open Network Division Amdocs Technology [cid:[email protected]] From: Zengjianguo (OSS Design) [mailto:[email protected]] Sent: Friday, November 10, 2017 12:09 PM To: Alla Goldner <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Subject: 答复: [onap-tsc] Usecase subcommittee meeting Nov 6 - themeeting'ssummary Hi Alla I agreed to Yuan’s point, it’s too hard to make decision without clear requirements/description for UseCase. My understanding for the clear UseCase requirement is, assume ONAP as a black box, then need to define: the input/output and outside components, and what action/function for ONAP in beijing release. The more members, the more difficult to reach any decision, so it will be helpful, if UseCase subcommittee can define a more clear description for the UseCase. It’s too challenge for TSC or project to make plan based on a wish-list that may cross more than 1 releases. Best regards 发件人: [email protected]<mailto:[email protected]> [mailto:[email protected]] 代表 Alla Goldner 发送时间: 2017年11月9日 20:47 收件人: [email protected]<mailto:[email protected]> 抄送: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> 主题: Re: [onap-tsc] Usecase subcommittee meeting Nov 6 - themeeting'ssummary Hi Yuan, We can definitely consider this, though I believe that the specific information you require below belongs to the next level of details. Perhaps even more points will be raised when we present it. And, as I said, this is “endorsement” not “approval”, and definitely needs future work/refining by a different projects. The question I was asked about is whether one or another requirement is indeed considered for Beijing, and this is why it is important to start bringing those requirements for the TSC. Best regards, Alla Goldner Open Network Division Amdocs Technology [cid:[email protected]] From: [email protected]<mailto:[email protected]> [mailto:[email protected]] Sent: Thursday, November 09, 2017 12:09 PM To: Alla Goldner <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: 答复: RE: Re: [onap-tsc] Usecase subcommittee meeting Nov 6 - themeeting'ssummary Hi Alla, Thank for your reply, it's clear to me. I does not object we bring the requirements to TSC for approval but from my view, the requirements need next level of detials before it goes to component design. The requirements looks too generic for different project teams reaching consensus on what they should design. My proposal is use case subcommittee should add some examples into usecase which would help developers understand related requirement. Like we add which PNF we should model and manage, what kind of API the PNF support for management, CLI, SNMP or restful? It does not mean the PNF requirement is specific to this PNF, it works to help people understand what problem they are facing. Maybe we can let TSC make the decision where the refining work would be took place. Regards, Yuan Yue 袁越 yuanyue 资深战略规划师 Senior Strategy Planner 技术规划部/技术规划部/系统产品 Technology Planning Dept./Technology Planning Dept./System Product [cid:[email protected]] [cid:[email protected]] 南京市雨花区软件大道50号中兴通讯3号楼 1/F,Building 3, ZTE Nanjing R&D Center II, No.50, Software Avenue,YuHua District,Nanjing,P.R.China 210012 T: +025 88013478 M: +86 13851446442 E: [email protected]<mailto:[email protected]> www.zte.com.cn<http://www.zte.com.cn/> 原始邮件 发件人： <[email protected]<mailto:[email protected]>>; 收件人：袁越10008526; 抄送人： <[email protected]<mailto:[email protected]>>; <[email protected]<mailto:[email protected]>>; <[email protected]<mailto:[email protected]>>; <[email protected]<mailto:[email protected]>>; <[email protected]<mailto:[email protected]>>; 日 期 ：2017年11月08日 16:24 主 题 ：RE: Re: [onap-tsc] Usecase subcommittee meeting Nov 6 - themeeting'ssummary Hi Yuan, Thanks a lot for your questions. I provide my answers below embedded into your text. Please let me know if you have any follow-up questions. Best regards, Alla Goldner Open Network Division Amdocs Technology [cid:[email protected]] From: [email protected]<mailto:[email protected]> [mailto:[email protected]] Sent: Wednesday, November 08, 2017 4:59 AM To: Alla Goldner <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: Re: [onap-tsc] Usecase subcommittee meeting Nov 6 - the meeting'ssummary Hi Alla and all, Two points for clarification: 1. Please correct me if I misunderstand your conclusion on 5G requirements part. The text on this item looks like all 5G requirerments except Conflict resolution will be part of Beijing release. But during the discussion I heard many times the requirements are long term not fixed to Beijing release. My understanding is we do have these requirements like 5G network slicing include vNFs and PNFs, but it is really hard to decide how far each project can go in Beijing Release based on the description of the requirements this days. May I propose that usecase subcommittee accept these requirement as phased output. The implementaion plan for different requirements in future releases, Beijing or some others, would be decided after comprehensive discussing with PTLs. Personally I think developing teams would ask for more detail info about the requirement items. AG> Usecase subcommittee doesn’t decide on including specific requirements into one or another Release, fully agree with you. Use case subcommittee receives the use cases, and responsible to extract functional and non-functional requirements, mostly on “what” and not “how”, while “how” would be defined by the projects themselves. For all the requirements, we define whether they are defined with sufficient level of details for bringing to TSC discussion. In some cases, some additional discussions with architecture/modelling subcommittees are required. In case we find requirement as ready to be presented to tSC for endorsement we do so. Then, if TSC endorses the requirement, it will be up to each one of the projects to define the next level of details. 2. I humbly ask what kind of endorsement usecase subcommittee is expecting from TSC? I remember Mazin has mentioned that Beijing release would not be driven by use cases in previous TSC weekly meeting. Beijing release will focus on carrer-grade enhancement with existing use cases and new use cases could be tested in if integration team could accept. I don't know if use case subcommittee has talked with Integration team on testing of the use case and related requirement? AG> yes, Beijing Release focus is on carrier grade, this is one of the major reasons we decided to move forward with a separate requirements, strengthening the platform and improving its quality, not with the full new use cases implementation. Eventually, once requirements are approved by the TSC, Usecase subcommittee along with the Integration team will see if there is possibility to showcase new use cases composed from those newly introduced requirements, but we are not there yet. Best Regards, Yuan Yue 袁越 yuanyue 资深战略规划师 Senior Strategy Planner 技术规划部/技术规划部/系统产品 Technology Planning Dept./Technology Planning Dept./System Product [cid:[email protected]] [cid:[email protected]] 南京市雨花区软件大道50号中兴通讯3号楼 1/F,Building 3, ZTE Nanjing R&D Center II, No.50, Software Avenue,YuHua District,Nanjing,P.R.China 210012 T: +025 88013478 M: +86 13851446442 E: [email protected]<mailto:[email protected]> www.zte.com.cn<http://www.zte.com.cn/> 原始邮件 发件人： <[email protected]<mailto:[email protected]>>; 收件人： <[email protected]<mailto:[email protected]>>; 抄送人： <[email protected]<mailto:[email protected]>>; <[email protected]<mailto:[email protected]>>; <[email protected]<mailto:[email protected]>>; <[email protected]<mailto:[email protected]>>; 日 期 ：2017年11月07日 22:42 主 题 ：Re: [onap-tsc] Usecase subcommittee meeting Nov 6 - the meeting'ssummary Hi all, Thanks to all meeting’s participants! Please find the meeting summary below and vVoLTE use cases status attached to this email. 1. R1 use cases status a. Please see the attachment about vVoLTE status (Yang’s report) b. Regarding R-vCPE (Kang’s report) i. The team has been testing and fixing various kinds of bugs over the weekend ii. As of Mon 1pm EST, we almost passed the custom workflow test. One last bug to fix but the solution is known. The plan is to fully retest the flows on Tue afternoon. We did use manual set up and hacks in multiple places. Hopefully we will finishing all test items later this week. 2. R2 requirements proposals a. VNF scaling use case/requirements presentation took place. Some follow up questions were asked. Steve Wright and his team will work on extending functional requirements and bringing them to the next Usecase subcommittee meeting. Alla will make sure team gets all related information on how those requirements should be written and presented b. Recent additional inputs on requirements extracted from 5G use cases. Lots of work was recently done to extend requirements description and add commitment section. It was agreed during the discussion that Conflict resolution requirement will be delayed (will not be a part of Beijing Release), while the rest of the requirements will be added to the TSC endorsement request this week. Team will prepare several slides covering those requirements c. E-vCPE ONAP Atomic Capability Management was presented by Luman. Follow-up questions were asked and was decided it requires more discussions. Luman will bring extended E-vCPE requirements for the next meeting and also discuss this specific new requirement by emails/bring it for more discussions next time. d. Vodafone has requested time during the next meeting to present Centralized parsers distribution related requirements Best regards, Alla Goldner Open Network Division Amdocs Technology [cid:[email protected]] This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer <https://www.amdocs.com/about/email-disclaimer>
_______________________________________________ ONAP-TSC mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-tsc
