Re: [onap-tsc] Vulnerability Management subcommittee (and TSC Action)

[Stephen Terrill]

Hi,

Just to summarize the status of this:

I have a seen a +1 from:

  *   VMware
  *   Amdocs
  *   Ericsson
  *   China Mobile
  *   China Telecom
  *   IBM
  *   Orange
  *   Gigaspaces
  *   AT
And Incognito

I  believe that gives us a majority, so I hope that we can consider this 
approved by the TSC.


To: Phil/Casey/Kenny: Once approved, please add the above to the security email 
list.

BR,

Steve

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of xiexj...@chinatelecom.cn
Sent: 13 July 2017 17:03
To: Pete Koat 
Cc: t...@lists.onap.org
Subject: Re: [onap-tsc] Vulnerability Management subcommittee (and TSC Action)

+1


From: Pete Koat
Date: 2017-07-13 09:39
To: Xinhui Li
CC: t...@lists.onap.org; 
spat...@research.att.com; 
david.j...@gmail.com; 
ruan...@orange.com; 
onap-sec...@lists.onap.org
Subject: Re: [onap-tsc] Vulnerability Management subcommittee (and TSC Action)
+1

On Jul 12, 2017 5:55 PM, "Xinhui Li" 
> wrote:
+1

From: > 
on behalf of Lingli Deng 
>
Date: Thursday, 13 July 2017 at 8:43 AM
To: 'Alla Goldner' >, 
'Jason Hunt' >, 
"stephen.terr...@ericsson.com" 
>
Cc: "onap-sec...@lists.onap.org" 
>, 
"david.j...@gmail.com" 
>, 
"ruan...@orange.com" 
>, 
"t...@lists.onap.org" 
>, 
"spat...@research.att.com" 
>
Subject: Re: [onap-tsc] Vulnerability Management subcommittee (and TSC Action)

+1

Lingli

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org]
 On Behalf Of Alla Goldner
Sent: 2017年7月13日 2:50
To: Jason Hunt >; 
stephen.terr...@ericsson.com
Cc: onap-sec...@lists.onap.org; 
david.j...@gmail.com; 
ruan...@orange.com; 
t...@lists.onap.org; 
spat...@research.att.com
Subject: Re: [onap-tsc] Vulnerability Management subcommittee (and TSC Action)

+1

 Original Message 
Subject: Re: [onap-tsc] Vulnerability Management subcommittee (and TSC Action)
From: Jason Hunt >
Date: Jul 12, 2017, 7:24 PM
To: stephen.terr...@ericsson.com
+1


Regards,
Jason Hunt
Executive Software Architect, IBM

Phone: +1-314-749-7422
Email: djh...@us.ibm.com
Twitter: @DJHunt


- Original message -
From: Stephen Terrill 
>
Sent by: onap-tsc-boun...@lists.onap.org
To: "t...@lists.onap.org" 
>
Cc: David Jorm >, 
"SPATSCHECK, OLIVER \(OLIVER\)" 
>, 
"ruan...@orange.com" 
>, 
"onap-sec...@lists.onap.org" 
>
Subject: [onap-tsc] Vulnerability Management subcommittee (and TSC Action)
Date: Sat, Jul 8, 2017 4:22 PM


Hi Fellow TSC members,



As indicated in the last TSC meeting I will forward the proposed participants 
for the vulnerability management sub-committee and who should be on that list.



As a reminder, the vulnerability management subcommittee is to handle the 
reception to resolution of received vulnerabilities according to our agreed 
procedures: 

[onap-tsc] ONAP User Group

[SPATSCHECK, OLIVER (OLIVER)]

I think ONAP should have an ONAP User Group. The goal of this group would be to 
foster the use of ONAP rather then handle the development of ONAP which we have 
been so focused on.  I think if we intermingle the two to much we are just 
slowing things down. Now I don’t know what form this should take on. It could 
be a subcommittee, something else or handled outside the LF entirely as it has 
no code impact. To define the scope a bit clearer I added a a mock up welcome 
page below.

Any thoughts/suggestions on the topic?

Thx

Oliver




Welcome to the ONAP User Community page. This is the place where you can:

- exchange information on how to use ONAP
- post ONAP use cases you might have created (documentation, source code, 
configuration or whatever else you might want to share)
- find others which might want to work with you in prototyping an ONAP use case
- keep the community updated on what you are trying out


Note: It is OK to post links to propietery use cases here.

The goal of this community  is to foster collaboration but also to collect as 
much information as possible on how ONAP is being used with as little 
constrains/overhead as possible (no approval required you work with whom you 
want to work doing what you want).

The user community meets once a week to discuss issues and ideas from the user 
community and might organize work shops colocated with other events 
occasionally.

This is not the place where you define use cases which drive new features into 
the platform or any other platform development questions. To define use cases 
which drive new features into the platform please go through the process 
defined in the ONAP use case sub committee.
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Solicit PTL feedback for ONAP RESTful API Design Specification //Fw:[ptls] proposed topic for the next week's PTL meeting

[Stephen Terrill]

Hi Huabing,

Thank-you for bringing this topic up for discussion and proposal.

I have some input for you to consider:


  *   It has been brought to my attention that similar needs have also being 
raised in other communities, and one such being the ETSI specifications where 
this has been documented in NFVSOL 00050.  It could make sense to avoid 
unnecessary misalignment where possible 
(https://docbox.etsi.org/ISG/NFV/SOL/05-CONTRIBUTIONS/2017/NFVSOL(17)50r3_SOL_REST_API_convention_collection_living_document.zip
 (if you have access to ETSI,  or hopefully it can be made open), also some 
patterns are described in SOL3 which are not represented in the conventions 
document yet 
(https://docbox.etsi.org/ISG/NFV/SOL/05-CONTRIBUTIONS/2017/NFVSOL(17)50r3_SOL_REST_API_convention_collection_living_document.zip
  *   
https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL003_Or-Vnfm_protocols/NFV-SOL003v0100.zip
 )
 *   E.g. this proposes hyphons “-“ where ETSI propose underscore “_”
 *   Others ..
 *   (Perhaps there could be help from the stds coordinator appointed for 
ETSI-NFV to help you here???)
  *   For security reasons, should we use HTTPS instead of HTTP.
  *   Also, on the theme of the token, we would probably needs some explanation 
around the handling of the token – i.e. who generates it, how is it validated 
etc.
  *   In versioning, is the compatibility for minor revisions only? (i.e. major 
revisions may not be or?)
  *   Regarding versioning, we should describe the behavior regarding version 
negotiation/discovery, i.e. if the client supports x.1.2 and the server 
supports x.1.1 should the client fallback to x.1.1 or is it assumed that the 
server politely ignores what it doesn’t understand.
  *   What is the recommendation if the “verb” cannot be mapped granularly 
enough to Post/get/put/delete?  (e.g. “tell bailey to come” “tell bailey to 
sit” “Clean bailey”, “tell bailey to bark”, … etc.

BR,

Steve

From: zhao.huab...@zte.com.cn [mailto:zhao.huab...@zte.com.cn]
Sent: 11 July 2017 05:10
To: gg2...@att.com; ml6...@intl.att.com; sw3...@att.com; 
kanagaraj.manic...@huawei.com; gn4...@intl.att.com; lxin...@vmware.com; 
denglin...@chinamobile.com; jf2...@att.com; helen.c...@huawei.com; 
ah0...@intl.att.com; david.sauvag...@bell.ca; am8...@att.com; 
talas...@research.att.com; dtimo...@att.com; rx1...@att.com; 
denghu...@huawei.com; wangchen...@chinamobile.com; shen...@chinamobile.com; 
rk5...@att.com; pr...@linuxfoundation.org; gildas.lani...@huawei.com; 
denghu...@hotmail.com; Stephen Terrill ; 
es4...@att.com; cc...@linuxfoundation.org; fu.guangr...@zte.com.cn; 
pdrag...@research.att.com; sa...@research.att.com; l...@research.att.com; 
mp...@amdocs.com; seshu.kuma...@huawei.com
Cc: onap-tsc@lists.onap.org
Subject: Solicit PTL feedback for ONAP RESTful API Design Specification 
//Fw:[onap-tsc][ptls] proposed topic for the next week's PTL meeting


Hi Gregory and PTLs,



At the this week's PTL meeting, I get the action item to contact documentation 
team and PTLs to continues the RESTFul API Design discussion.  
http://ircbot.wl.linuxfoundation.org/meetings/onap-meeting/2017/onap-meeting.2017-07-10-13.22.html



The reasoning behind this:

API is very important because it's hard to make significant changes to your API 
once it's released, so we want to get as much right as possible at first. 
Currently, most of the projects have already passed their M1 review, the 
Release Planning. And developers start to write codes.I went through some of 
the existing API documents of a bunch of projects, it seems that there's no 
consistent way for Restful API design and some of the API definition are not 
very appropriate.

Because it's a cross-project issue, I proposed this topic at this week's PTL 
meeting,  I'd like to suggest that we figure out a unified approach across ONAP 
projects for the Restful API design before we jump into the coding work.


I came up with a draft as the start point for discussion on this wiki page: 
https://wiki.onap.org/display/DW/RESTful+API+Design+Specification+for+ONAP  
.These items in this pages are based on some best practices in the industry, 
such as the URL, resource hierarchy, the versioning, the use of HTTP method, 
API documentation Specification, etc.



Please discuss the specification within your team. If anything needs to be 
modified or added, just send feedback here by mail or comment on the wiki page. 
I hope we could get a revised and improved version ready for next week's PTL 
meeting.



Thank you for your attention to this matter.

Huabing




Original Mail
Sender:  >;
To:  >; 
>; 
>; 
>; 

[onap-tsc] [modeling] remove some committers and add some contributors

[denghui (L)]

Hello all,

After one to one engagement, some of people have decided to move from the 
committers to contributors, some of them would like to join the contributors.
Please kindly help to check the latest version.
https://wiki.onap.org/display/DW/Resources+and+Repositories

Thanks a lot

DENG Hui
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] What Do You Need From The July Developers Event?

[Liu Yuan]

Hi,

I add a topic about the VoLTE Use Case Control Loop Automation in the following 
link. For meeting the requirements of VoLTE use case, it is time to discuss the 
control loop for fault correlation and auto-healing in a more detail level. So, 
we would like to invite CLAMP, DCAE, Policy, Holmes, VF-C and other related 
projects to join in the topic. Thanks.

https://wiki.onap.org/pages/viewpage.action?pageId=8232264 
VoLTE Use Case Control Loop Automation 
Description:  In the Amsterdam release, VoLTE use case has a requirement on 
fault correlation and auto-healing, which is closely related to Control loop, 
including but not limited to CLAMP, DCAE, Policy, Holmes, and VF-C projects. 
During the previously discussion in the weekly meeting, the workflow of control 
loop has been introduced, but some actual example files are not provided. It is 
time to design the control loop for VoLTE use case to ensure deliver on time. 
Here are the gaps need to discuss.
Examples of DCAE template, CLAMP/Cloudify Blueprint, Config Policy, Operational 
Policy and related files needed to be designed and used in the control loop. If 
a series of practical examples can be provided, like all related examples of 
the vFW demo, which is better for us to understand.
Developer guidelines to design the control loop to achieve the requirement of 
VoLTE. Demo of the entire process, e.g. create, deploy, etc., which is a better 
way help us to learn, if it can be provided.
Holmes deployment, integrated with DCAE or separately deployment, e.g. 
workflow, DCAE Template, API, etc.
The solution of design, creating and distributing Holmes rules, e.g. refer to 
Policy, or other solutions, etc.
The requirement of Policy to invoke the API of VF-C.
The API document of VES collector in DCAE is used by VF-C to report VNF FCAPS 
data.
Topic Leader: Yuan Liu
Link to data Source (if applicable)
Interested In Attending: We would like to invite CLAMP, DCAE, Policy, Holmes, 
VF-C and other related projects to join in this topic.
Lingli Deng - denglin...@chinamobile.com
Yan Yang - yangya...@chinamobile.com
Guangrong Fu - fu.guangr...@zte.com.cn

Regards,
Yuan


刘媛 / Liu Yuan
网络技术研究所 / Department of Network Technology
中国移动通信研究院 / China Mobile Research Institute
Mobile: +86 15810024078
Email: liuyuan...@chinamobile.com 
 
From: Kenny Paul
Date: 2017-07-18 06:17
To: onap-discuss
CC: onap-tsc
Subject: [onap-tsc] What Do You Need From The July Developers Event?
The July Virtual Developers Event is next week and your contributions are what 
will drive all of these sessions.

As Phil Robb mentioned at the close of the PTL call this morning, we are 
looking to the community to suggest topics for discussion which we will use to 
build the agenda from.  Ideally these are areas where you need a deeper 
understanding of in order to make progress, or deep-dive information sharing in 
a particular area you wish to provide.  It is critically important to extract a 
list of questions/decisions/agreements that each project needs to close on so 
that they can successfully execute their development cycle for Amsterdam.  

The following wiki page has been created for this purpose: DISCUSSION TOPICS / 
QUESTIONS

To to add a new topic please provide your project name and topic using the 
template provided on the wiki page. If there is a topic that you would like 
discussed, but you do not feel that you can lead it, please add the topic and 
indicate that you are "Interested in Attending", then indicate TBD as the 
"Topic Leader”. 

For any existing topic(s) you would like to lead and/or attend simply add your 
name to the list as appropriate.  

The page has been populated with a few topics based upon input we have already 
received.

Thank you in advance for your contributions and participation.

Best Regards, 
-kenny

Kenny Paul,  Technical Program Manager
kp...@linuxfoundation.org
510.766.5945

___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Use case subcommittee - agenda for tomorrow's (17/07/2017) meeting

[Alla Goldner]

Dear all,

Thanks for attending yesterday's meeting.

Here is meeting's summary:


1.   I will approach separately all relevant PTLs (see more detailed 
summary below) urging them to attend corresponding use cases meetings



2.   Going forward, we move to weekly meetings, following doodle poll 
results. Next week we will also require slot during virtual meeting


3.   R1 use cases: vCPE and vVoLTE use cases were presented by Kang Xi/Jon 
Fannar and Yang Xe/Chengli Wang correspondingly. Both use cases leaders report 
good progress and good chances of completing all definitions and close on 
required functionality with all projects this week. The following points still 
pending discussions though:

a.   vCPE

   i.  Today 
meeting will be held with SO/SDC/SDN-C teams.  Gil Bullard will present an 
updated version of the vCPE service model in this meeting. PTLs - please 
attend, this is critical for correct projects' interpretation of what is 
required to do

 ii.  
DCAE/Intel discussion to close packets' format has already started, will be 
completed this week

iii.  Brian 
Freeman started experimenting with onboarding a vCPE VNF with generic Unix 
machine heat templates



b.  vVoLTE

   i.  Meetings 
with CLAMP/DCAE/HOLMES teams were held. There is pending issue on direct 
connection of HOLMES (not via DCAE) and this need to be handled by Architecture 
subcommittee ASAP. I will issue separate email on this

 ii.  Meetings 
with SDC/SDN-C team will be held this week. PTLs - please attend, this is 
critical for correct projects' interpretation of what is required to do

iii.  Gil 
Bullard wil be requested to help with defining a model which drives the use case

   iv.  A question 
on whether vIMS+vEPC is enforced as a single request coming from SO (i.e. as a 
single network service or not). It was clarified that it is up to 
implementation, as VF-C can support it both ways. It will also be checked with 
SO team, and the corresponding clarification will be included in the use case 
description

 v.  For 
overlay - whether Openstack or hardware will be used - discussions with Brian 
Freeman were initiated, once agreed, an update on results will be provided



4.   Helen (Integration Project PTL) requested to review all use cases till 
the end of this month, to make sure that all functionality is well understood 
and closed before functionality freeze (beginning of August). We will have 
meeting during next week's virtual meeting and also the following week to 
review and close on this. Integration team members will join this meeting.



5.   R2 use cases:

a.   MEC (mobile edge computing, based on ETSI MEC specifications) will be 
added as one of potential 5G use cases

b.  Timeframe for Use case subcommittee's  R2 use cases consolidated 
proposal to the TSC - September's f2f meeting

c.   Long (China Telecom) presented revised version of Enterprise vCPE use 
case. It was asked to move it under R2 use cases definitions 
https://wiki.onap.org/display/DW/Release+2+Use+Cases

d.  Network Function Change Management will also be revised by AT as use 
case and included in R2 use cases proposal

e.  It was clarified that, based on proposals, we will see if/how to merge 
different proposals and which exact functionality we target for R2

f.All - you are more than welcomed to submit your proposals and 
initiate email discussions. We will then take discussions during our meetings, 
as time permits (first priority - R1 use cases required discussions and actions)

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D2FFBC.B558DCC0]

From: Alla Goldner
Sent: Sunday, July 16, 2017 5:22 PM
To: 'onap-usecase...@lists.onap.org' 
Cc: onap-tsc 
Subject: Use case subcommittee - agenda for tomorrow's (17/07/2017) meeting

Hi all,

Here is agenda for tomorrow's Use case subcommittee meeting. R1 use cases are 
of highest priority. We must see if/what is needed to complete use cases 
interactions with a different projects this week.
We will start going over R2 use case only if time permits.
PTLs of a different projects, please indicate before tomorrow's meeting if 
additional clarifications on R1 use cases are needed.

Please upload your suggested R2 use cases 
https://wiki.onap.org/display/DW/Release+2+Use+Cases, so we can start some 
offline discussions as well.


  1.  R1 use cases