[onap-tsc] Srini Addepalli with be the Intel proxy for ONAP TSC tomorrow

[Gadiyar, Rajesh]

Hi Kenny: I am on business travel tomorrow. Srini Addepalli will be my proxy 
for tomorrow’s (5/10) ONAP TSC. I have updated the proxy sheet on ONAP wiki. 
Thanks!

--
Rajesh H Gadiyar | Vice President Data Center Group | CTO Network Platforms 
Group | Intel Corporation | +1.480.552.1068 (office) +1.480.399.0035 (mobile) | 
Twitter: @rgadiyar
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] TSC Members Composition Survey RFC - Respond by 18:00 Pacific time, May 7

[Gadiyar, Rajesh]

Hello Kenny,

Thanks! Section 2b reads:
b. TSC Voting Members
i. “Startup Period”: From date of creation of the ONAP Project a Series of
LF Projects, LLC (“Project Launch”) until June 30, 2018 (such period the
“Startup Period”), the TSC voting members will consist of one appointee
from each organization listed as having TSC appointees on ONAP.org.
All TSC voting members will be listed on ONAP.org.
ii. “Steady State”: After the Startup Period, the size, makeup and procedure
for determining voting members of the TSC will be as determined by the
TSC and documented on the ONAP web site.

I am NOT asking for a redefinition. I am proposing the following: B) 
Guaranteeing TSC seats for LFN's Platinum Member companies.

Another option that came to mind that has not been brought up before is 
guaranteeing 1 TSC seat for each of the top 15 code contributing companies 
(rewards meritocracy and actual code contributions to ONAP) and an additional 5 
seats reserved for Operators. This will bring the total TSC to 20 members which 
is reasonable.

Regards,
Rajesh


From: Kenny Paul 
Date: Friday, May 4, 2018 at 2:12 PM
To: Rajesh Gadiyar 
Cc: onap-tsc 
Subject: Re: [onap-tsc] TSC Members Composition Survey RFC - Respond by 18:00 
Pacific time, May 7

Hi Rajesh,
please refer to Section 2b of the ONAP Project a Series of LF Projects, LLC 
Technical 
Charter<https://www.onap.org/wp-content/uploads/sites/20/2018/01/ONAP-Project-a-Series-of-LF-Projects-LLC-Technical-Charter-12-22-2017-FINAL.pdf>
 below.
in the context of Question #1 unless your request is to redefine both the 
"Startup Period" and "Steady State" definitions, a specific date is required. I 
don't think that a redefinition is what you are really asking for.

My interpretation of your actual ask is that you would like to see a TSC 
Composition question added about A) guaranteeing seats for ONAP Platinum 
Members of record from 2017 or B) guaranteeing seats for any one of the LFN's 
Platinum Member companies.

An alternative interpretation may be that you would like to see qualification 
options added to Question #11 for C) only candidates from one of the ONAP 
Platinum Members of record from 2017 are qualified to hold a seat on the ONAP 
TSC, or D) only candidates from any one of the LFN's Platinum Member companies 
are qualified to hold a seat on the ONAP TSC.

Is A, B, C or D correct, or do you indeed want to redefine the state 
definitions?

b. TSC Voting Members
i. “Startup Period”: From date of creation of the ONAP Project a Series of LF 
Projects, LLC (“Project Launch”) until June 30, 2018 (such period the “Startup 
Period”), the TSC voting members will consist of one appointee from each 
organization listed as having TSC appointees on ONAP.org. All TSC voting 
members will be listed on ONAP.org.

ii. “Steady State”: After the Startup Period, the size, makeup and procedure 
for determining voting members of the TSC will be as determined by the TSC and 
documented on the ONAP web site.

Thanks!
-kenny

From: "Gadiyar, Rajesh" 
Date: Friday, May 4, 2018 at 11:08 AM
To: Kenny Paul 
Cc: onap-tsc 
Subject: Re: [onap-tsc] TSC Members Composition Survey RFC - Respond by 18:00 
Pacific time, May 7

Hi Kenny: please add an explicit option like I stated below; and let’s provide 
it as an option for TSC to vote. Many TSC members are supportive of this.

“Other” as a write in option does not capture my input. You can still add it as 
a separate option if you like.
Regards,
Rajesh

On May 4, 2018, at 10:46 AM, Kenny Paul 
mailto:kp...@linuxfoundation.org>> wrote:
Hi Rajesh,

Again #1 is a "When" question about moving to "Steady State" and not a "What" 
question about the composition of the TSC.
I will add "Other" as a write in option for Question #1 to address alternative 
time frames.

Thanks!
-kenny

From: "Gadiyar, Rajesh" 
mailto:rajesh.gadi...@intel.com>>
Date: Friday, May 4, 2018 at 9:37 AM
To: Kenny Paul mailto:kp...@linuxfoundation.org>>
Cc: onap-tsc mailto:onap-tsc@lists.onap.org>>
Subject: Re: [onap-tsc] TSC Members Composition Survey RFC - Respond by 18:00 
Pacific time, May 7

Hi Kenny: Never has a negative connotation. I am simply proposing an option 
where all LFN platinum members have a TSC membership (supplemented with a few 
exta seats for non platinum significant contributors). I am supportive of 
putting enough guardrails for the qualifications to be a TSC member and the 
contribution expectations.

/R

From: Kenny Paul mailto:kp...@linuxfoundation.org>>
Date: Friday, May 4, 2018 at 8:10 AM
To: Rajesh Gadiyar mailto:rajesh.gadi...@intel.com>>
Cc: onap-tsc mailto:onap-tsc@lists.onap.org>>
Subject: Re: [onap-tsc] TSC Members Composition Survey RFC - Respond by 18:00 
Pacific time, May 7

Hi Rajesh,
As this is a "when" question the implication of your suggested #4 is "Never". 
Am I u

Re: [onap-tsc] TSC Members Composition Survey RFC - Respond by 18:00 Pacific time, May 7

[Gadiyar, Rajesh]

Hi Kenny: please add an explicit option like I stated below; and let’s provide 
it as an option for TSC to vote. Many TSC members are supportive of this.

“Other” as a write in option does not capture my input. You can still add it as 
a separate option if you like.

Regards,
Rajesh

On May 4, 2018, at 10:46 AM, Kenny Paul 
mailto:kp...@linuxfoundation.org>> wrote:

Hi Rajesh,

Again #1 is a "When" question about moving to "Steady State" and not a "What" 
question about the composition of the TSC.
I will add "Other" as a write in option for Question #1 to address alternative 
time frames.

Thanks!
-kenny

From: "Gadiyar, Rajesh" 
mailto:rajesh.gadi...@intel.com>>
Date: Friday, May 4, 2018 at 9:37 AM
To: Kenny Paul mailto:kp...@linuxfoundation.org>>
Cc: onap-tsc mailto:onap-tsc@lists.onap.org>>
Subject: Re: [onap-tsc] TSC Members Composition Survey RFC - Respond by 18:00 
Pacific time, May 7

Hi Kenny: Never has a negative connotation. I am simply proposing an option 
where all LFN platinum members have a TSC membership (supplemented with a few 
exta seats for non platinum significant contributors). I am supportive of 
putting enough guardrails for the qualifications to be a TSC member and the 
contribution expectations.

/R

From: Kenny Paul mailto:kp...@linuxfoundation.org>>
Date: Friday, May 4, 2018 at 8:10 AM
To: Rajesh Gadiyar mailto:rajesh.gadi...@intel.com>>
Cc: onap-tsc mailto:onap-tsc@lists.onap.org>>
Subject: Re: [onap-tsc] TSC Members Composition Survey RFC - Respond by 18:00 
Pacific time, May 7

Hi Rajesh,
As this is a "when" question the implication of your suggested #4 is "Never". 
Am I understanding that correctly?

Thanks!
-kenny

From: "Gadiyar, Rajesh" 
mailto:rajesh.gadi...@intel.com>>
Date: Thursday, May 3, 2018 at 8:34 PM

1.  When should the ONAP TSC move from “Startup” to “Steady” state 
operations at which point the TSC should be populated, not by Platinum Member 
designates, but instead by some other means, for which the TSC is responsible 
for defining?
1.  As soon as the new method for populating the TSC is defined
2.  After the Beijing Release
3.  After the Casablanca Release
4.  Keep the current TSC composition with Platinum members automatically 
get a TSC seat.
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] TSC Members Composition Survey RFC - Respond by 18:00 Pacific time, May 7

[Gadiyar, Rajesh]

Hi Kenny: Never has a negative connotation. I am simply proposing an option 
where all LFN platinum members have a TSC membership (supplemented with a few 
exta seats for non platinum significant contributors). I am supportive of 
putting enough guardrails for the qualifications to be a TSC member and the 
contribution expectations.

/R

From: Kenny Paul 
Date: Friday, May 4, 2018 at 8:10 AM
To: Rajesh Gadiyar 
Cc: onap-tsc 
Subject: Re: [onap-tsc] TSC Members Composition Survey RFC - Respond by 18:00 
Pacific time, May 7

Hi Rajesh,
As this is a "when" question the implication of your suggested #4 is "Never". 
Am I understanding that correctly?

Thanks!
-kenny

From: "Gadiyar, Rajesh" 
Date: Thursday, May 3, 2018 at 8:34 PM

1.  When should the ONAP TSC move from “Startup” to “Steady” state 
operations at which point the TSC should be populated, not by Platinum Member 
designates, but instead by some other means, for which the TSC is responsible 
for defining?
1.  As soon as the new method for populating the TSC is defined
2.  After the Beijing Release
3.  After the Casablanca Release
4.  Keep the current TSC composition with Platinum members automatically 
get a TSC seat.
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] TSC MEMBERS Approval/Acknowledgment Needed- Requesting Nexus3 downtime

[Gadiyar, Rajesh]

+1


From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Yunxia Chen
Sent: Wednesday, May 02, 2018 4:12 AM
To: Kenny Paul mailto:kp...@linuxfoundation.org>>; 
onap-tsc mailto:onap-tsc@lists.onap.org>>
Cc: Jeremy Phelps 
mailto:jphe...@linuxfoundation.org>>; Anil Belur 
mailto:abe...@linuxfoundation.org>>
Subject: Re: [onap-tsc] TSC MEMBERS Approval/Acknowledgment Needed- Requesting 
Nexus3 downtime

(Nexus3 issue highly impacted the current ONAP pair wise testing and final 
integration testing: we need it get addressed asap. Please approve it).

Regards,

Helen Chen

From: mailto:onap-tsc-boun...@lists.onap.org>> 
on behalf of Kenny Paul 
mailto:kp...@linuxfoundation.org>>
Date: Tuesday, May 1, 2018 at 4:46 PM
To: onap-tsc mailto:onap-tsc@lists.onap.org>>
Cc: Anil Belur mailto:abe...@linuxfoundation.org>>, 
Jeremy Phelps mailto:jphe...@linuxfoundation.org>>
Subject: [onap-tsc] TSC MEMBERS Approval/Acknowledgment Needed- Requesting 
Nexus3 downtime

(bcc'd to onap-release to avoid cross posting)

When: Requesting May 2nd, 6:00 am to 7:00 am Pacific, Alternative: May 3, 6:00 
am to 7:00 am Pacific

What:  Increasing ONAP's Nexus3 server's heap size to 6 gig and enable 
additional logging

Why: Based upon a meeting today between the Community and LFIT - Part of 
ongoing work to address performance issues pulling docker images

Impact: Jenkins and Nexus3 will be unavailable during this time

Risk: Low

Background: Docker image pulls are subject to hanging in mid-stream for minutes 
at a time.  A recent network fix on the part of our service provider has 
addressed bandwidth issues which were contributing to this behavior, however 
with one bottleneck removed a new issue has been identified.   It is believed 
that the jobs are pausing whenever normal garbage collection tasks are 
triggered. The most likely cause of this is the result of the heap size being 
set to default values which is not taking full advantage of the memory 
available. This change will set the heap size to match what is currently in 
place for ONAP's Nexus2 server.  During this down time logging will also be 
enabled to track additional system information in the event that the planned 
fix does not correct the problem.

Alternative:  Leave system as-is until after the release



Best Regards,
-kenny

Kenny Paul, Technical Program Manager, The Linux Foundation
kp...@linuxfoundation.org, 510.766.5945
San Francisco Bay Area, Pacific Time Zone


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
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] TSC Composition Proposal

[Gadiyar, Rajesh]

+1

I agree with Frank. Would like to see an option for a larger TSC included. I 
like the focus on Operators but would also like to see a good mix of others in 
the ONAP ecosystem represented on the TSC.

--
Regards,
Rajesh

From:  on behalf of "Frank Brockners 
(fbrockne)" 
Date: Thursday, April 19, 2018 at 7:42 AM
To: Phil Robb 
Cc: "onap-tsc@lists.onap.org" 
Subject: Re: [onap-tsc] TSC Composition Proposal

Hi Phil,

thanks for the clarification – I missed the “end-user” constraint. Still IMHO 
it would make sense to have another option (“#4”) for a larger TSC included – 
which would allow for a broader organizational representation. Could you add 
that? Way we’d have pretty much the overall spectrum of options covered.

Thanks, Frank

From: Phil Robb 
Sent: Donnerstag, 19. April 2018 16:21
To: Frank Brockners (fbrockne) 
Cc: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] TSC Composition Proposal

Hi Frank.

The concern I'm trying to address is for the *service provider* platinum 
members, who a) are beginning plans to put ONAP as a critical piece of their 
infrastructure while b) not yet having had the chance to ramp up their 
developer teams and engage in the community because they are new to this whole 
process.  It was not intended to guarantee TSC representation by all Platinum 
Members, only the Service Provider Platinum members, so the TSC count would 
max-out in the low 20s not the low 30s.  However, some service providers will 
certainly be represented on the TSC by their developers so a likely TSC number 
would be high teens... 18 to 20; it's really the Service Providers that are 
"newer" to ONAP that we're trying to ensure have representation on the 
developer community leadership.  That's the fundamental concern I'm trying to 
address with the proposals #2 and #3.

Best,

Phil.

On Thu, Apr 19, 2018 at 7:56 AM, Frank Brockners (fbrockne) 
mailto:fbroc...@cisco.com>> wrote:
Thanks Phil. From reading through the options below, it seems as if there is a 
desire to get a broader representation of the contributing companies in the TSC 
than what would happen with just 15 TSC members. At the same time, with option 
#3 the TSC could eventually grow (worst case) to (15 + #of-LF-platinum 
members), which could be well above 40…. Could we consider some middle ground 
which caps the size of the TSC while still ensuring a broader representation of 
contributing companies? E.g.


•   Fully elected TSC (per Chris/Steven’s proposal)

•   Per company cap at 1 person

•   TSC size: 30

Thoughts?

Thanks, Frank

From: onap-tsc-boun...@lists.onap.org 
mailto:onap-tsc-boun...@lists.onap.org>> On 
Behalf Of Phil Robb
Sent: Mittwoch, 18. April 2018 01:25
To: onap-tsc@lists.onap.org

Subject: Re: [onap-tsc] TSC Composition Proposal

Hello ONAP TSC Members:

There has not been much discussion on this thread, so I assume that all 
relevant questions and comments have already been expressed regarding this 
topic of how best to populate the TSC and when to do it.  To that end, I will 
be calling for a vote on this topic during the TSC meeting on Thursday, April 
19th, 2018.  Please review the material below and provide comments or questions 
if you have any.  Also, please be prepared to vote on this topic, or have a 
delegate ready to vote in your stead on Thursday.  The format of the vote will 
be similar to the following:

First, we will vote on if we want to change the way we populate the TSC after 
Beijing or after Casablanca.  Remember that in order to change the date to 
after Casablanca (Nov. 2018), we will need a 2/3 super majority to modify the 
Charter with the new date.  So the first vote will be:

Shall the TSC modify the ONAP Charter to change the date in which the "Startup 
Period" ends (as defined in Section 2.b.i) to be November 16th, 2018? -1, 0, +1

If this vote passes, we are done for now.  If it does not pass with a 2/3 
approval, we will populate a new TSC shortly after Beijing is released.  To do 
so, we will vote on the following proposals:

Proposal #0
Abstain from voting on population method.

Proposal #1:
The TSC Accepts the "TSC Composition Proposal" presented by Chris Donley and 
Stephen Terrill during the TSC Meeting held on April 5th 2018.  The proposal in 
it's entirety is located here: 
https://wiki.onap.org/download/attachments/25439857/TSC%20Composition%20proposal%20v2.pdf?version=1&modificationDate=1522934062000&api=v2

Proposal #2:
The TSC Accepts the "TSC Composition Proposal" presented by Chris Donley and 
Stephen Terrill during the TSC Meeting held on April 5th 2018 with the 
following amendment:
​That i​
n addition to
​ the​
15 elected TSC members
​ in the original proposal​
, each end-user Platinum Member of LFN that ha
​s​
been a part of ONAP and/or LFN for less than 12 months from the time of the 
election,
​is​
allowed to appoint a representative to the TSC.

​Proposal #3:
The TSC Accepts t

Re: [onap-tsc] Community Announcement- PTL Self Code Merge Vote

[Gadiyar, Rajesh]

-1

same concern as Mazin.

From:  on behalf of "GILBERT, MAZIN E (MAZIN 
E)" 
Date: Saturday, March 17, 2018 at 4:53 AM
To: Kenny Paul 
Cc: "onap-tsc@lists.onap.org P" 
Subject: Re: [onap-tsc] Community Announcement- PTL Self Code Merge Vote

-1

On Mar 17, 2018, at 7:53 AM, GILBERT, MAZIN E (MAZIN E) 
mailto:ma...@research.att.com>> wrote:

But this will give PTLs in other companies the ability to push their own code,
or even code from their colleagues that they claim is theirs. This impacts code
quality process. I am not very comfortable letting this happen, frankly.




On Mar 15, 2018, at 6:30 PM, Kenny Paul 
mailto:kp...@linuxfoundation.org>> wrote:

This is to inform the community that the following item is being forwarded to 
the TSC for an email vote as per today’s TSC meeting.

The TSC approves changing the General Code Commit Rules as documented under 
Approved Operational 
Policies
 to allow PTLs merging their own commit provided there is a time critical need 
and provided that the justification for doing so is documented in the code 
review comments.


THIS IS NOT THE CALL TO VOTE!  The formal vote will occur on the onap-tsc-vote 
alias, not here.
A plus-one, minus-one, or zero here on this issue is null and void.

Best Regards,
-kenny

Kenny Paul, Technical Program Manager, The Linux Foundation
kp...@linuxfoundation.org, 510.766.5945
San Francisco Bay Area, Pacific Time Zone

___
ONAP-TSC mailing list
ONAP-TSC@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=IKSC5mg8GeOiSar1dax3GQ&m=7zFgm0XTqg3Zx-CI5PQJjIaYUEokDvu_xPWfdYtfc1U&s=E69yU-W3pvKTigIC3quTyF5mmRe3_RQBnjNiohgBzeo&e=



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

Re: [onap-tsc] Committer Promotion Request for [appc]

[Gadiyar, Rajesh]

+1

--
Regards,
Rajesh

From:  on behalf of "aayush.bhatna...@ril.com" 

Date: Wednesday, January 17, 2018 at 10:09 PM
To: "lxin...@vmware.com" , "rx1...@att.com" 
, "onap-tsc@lists.onap.org" , 
"kp...@linuxfoundation.org" 
Cc: "onap-disc...@lists.onap.org" 
Subject: Re: [onap-tsc] Committer Promotion Request for [appc]

+1

Regards

Aayush


From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Xinhui Li
Sent: 18 January 2018 04:48
To: MAHER, RANDA; onap-tsc@lists.onap.org; Kenny Paul
Cc: onap-disc...@lists.onap.org
Subject: Re: [onap-discuss] [onap-tsc] Committer Promotion Request for [appc]

+ 1

Xinhui

From: mailto:onap-tsc-boun...@lists.onap.org>> 
on behalf of "MAHER, RANDA" mailto:rx1...@att.com>>
Date: Wednesday, January 17, 2018 at 11:54 AM
To: "onap-tsc@lists.onap.org" 
mailto:onap-tsc@lists.onap.org>>, Kenny Paul 
mailto:kp...@linuxfoundation.org>>
Cc: "onap-disc...@lists.onap.org" 
mailto:onap-disc...@lists.onap.org>>
Subject: Re: [onap-tsc] Committer Promotion Request for [appc]

Hello TSC, Kenny:

Any chance we can get this committer promotion approved over email?
I have put this on the agenda for this week’s TSC meeting, but with M1 review, 
not sure we will get to it.

I have recorded five +1 thus far


  1.  Dhananjay Pavgi
  2.  Mazin Gilbert
  3.  Jamil Chawki
  4.  Alla Goldner
  5.  Stephen Terrill

Thanks, Randa

From: Stephen Terrill [mailto:stephen.terr...@ericsson.com]
Sent: Friday, January 12, 2018 4:28 AM
To: MAHER, RANDA mailto:rx1...@att.com>>; 
onap-tsc@lists.onap.org
Cc: onap-disc...@lists.onap.org
Subject: RE: [onap-tsc] Committer Promotion Request for [appc]

+1

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of MAHER, RANDA
Sent: 12 January 2018 00:58
To: onap-tsc@lists.onap.org
Cc: onap-disc...@lists.onap.org
Subject: [onap-tsc] Committer Promotion Request for [appc]

Dear TSC,

Please consider request below for Committer Promotion for APPC project.

https://wiki.onap.org/pages/viewpage.action?pageId=22251669

One of our existing committers has indicated that he will  step down from 
Committer to Contributor role.
Existing Committers have all voted +1 on Taka Cho promotion to Committer.

Thanks, Randa
APPC PTL

"Confidentiality Warning: This message and any attachments are intended only 
for the use of the intended recipient(s), are confidential and may be 
privileged. If you are not the intended recipient, you are hereby notified that 
any review, re-transmission, conversion to hard copy, copying, circulation or 
other use of this message and any attachments is strictly prohibited. If you 
are not the intended recipient, please notify the sender immediately by return 
email and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure 
no viruses are present in this email. The company cannot accept responsibility 
for any loss or damage arising from the use of this email or attachment."
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] We need to decide how to populate the ONAP Representative to the LFN TAC

[Gadiyar, Rajesh]

Yes.

--
Regards,
Rajesh

From: Phil Robb 
Date: Thursday, January 11, 2018 at 11:23 AM
To: Rajesh Gadiyar 
Cc: Jason Hunt , Dhananjay Pavgi 
, onap-tsc , 
"onap-tsc-boun...@lists.onap.org" 
Subject: Re: [onap-tsc] We need to decide how to populate the ONAP 
Representative to the LFN TAC

Hello Rajesh and Alla:

Just so I'm clear on your +1s, you are agreeing with Jason's comment, with a 
preference for #1 unless the TSC Chair does not want to sign up for the 
responsibility, in which case we move to #2?

Best,

Phil.

On Thu, Jan 11, 2018 at 12:41 PM, Gadiyar, Rajesh 
mailto:rajesh.gadi...@intel.com>> wrote:
+1

From: mailto:onap-tsc-boun...@lists.onap.org>> 
on behalf of Jason Hunt mailto:djh...@us.ibm.com>>
Date: Thursday, January 11, 2018 at 9:38 AM
To: Dhananjay Pavgi 
Cc: "onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org>" 
mailto:onap-tsc-boun...@lists.onap.org>>, 
onap-tsc mailto:onap-tsc@lists.onap.org>>

Subject: Re: [onap-tsc] We need to decide how to populate the ONAP 
Representative to the LFN TAC

#1 makes the most sense to me, but if Mazin feels it's too much for the chair 
to take on, #2 is a fine backup option.


Regards,
Jason Hunt
Executive Software Architect, IBM

Phone: 314-749-7422
Email: djh...@us.ibm.com<mailto:djh...@us.ibm.com>
Twitter: @DJHunt




From:Dhananjay Pavgi 
To:"HU, BIN" mailto:bh5...@att.com>>, Phil Robb 
mailto:pr...@linuxfoundation.org>>, onap-tsc 
mailto:onap-tsc@lists.onap.org>>
Date:01/11/2018 11:00 AM
Subject:Re: [onap-tsc] We need to decide how to populatethe 
   ONAPRepresentative to the LFN TAC
Sent by:
onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org>




Support Option 1; as TSC Chair for a particular stream has broader 360 view of 
the program including roadmap, priorities etc.

thanks & regards,
Dhananjay Pavgi
+91 98220 22264

From: onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org> 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of HU, BIN
Sent: Thursday, January 11, 2018 10:24 PM
To: Phil Robb mailto:pr...@linuxfoundation.org>>; 
onap-tsc mailto:onap-tsc@lists.onap.org>>
Subject: Re: [onap-tsc] We need to decide how to populate the ONAP 
Representative to the LFN TAC

Just FYI:
-  OPNFV TSC voted on Tuesday (Jan 9) to have TSC Chair to represent 
OPNFV in TAC
-  fd.io<http://fd.io> voted the same today to have TSC Chair represent 
fd.io<http://fd.io> in TAC, if I am not mistaken.

Option 1 is used by both of our sister communities under the same LFN.

Just an FYI.

Thanks
Bin

From: 
onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org>[mailto:onap-tsc-boun...@lists.onap.org]
 On Behalf Of Phil Robb
Sent: Thursday, January 11, 2018 7:08 AM
To: onap-tsc mailto:onap-tsc@lists.onap.org>>
Subject: [onap-tsc] We need to decide how to populate the ONAP Representative 
to the LFN TAC

Hello ONAP TSC Members:

Now that ONAP is a part of the Linux Foundation Networking (LFN) Directed Fund, 
we need to decide how we are going to populate our ONAP Representative in the 
LFN Technical Advisory Council (TAC).

As a reminder, the Scope of the responsibilities of the TAC are:
=
•Scope of responsibility
•Recommend acceptance or removal of projects under the Umbrella to be approved 
by the Governing Board
•Focus on activities that drive collaboration and integration across projects 
(e.g. collaborative development, testing, etc)
•Elected TAC Chair provides guidance to Governing Board on investment needs of 
the project communities

=

Some of the options for us to populate our representative include:
1) Just have the TSC Chair represent ONAP in the TAC
2) Have the TSC vote for some TSC member to represent ONAP in the TAC
3) Have the Committers vote for some Committer-At-Large to represent ONAP in 
the TAC
... etc.

I will be setting up the first TAC meeting to occur somewhere in the last third 
of January and it would be good for the ONAP community to have representation 
from the start.

I personally lean toward option #2 because a) it does not by default put more 
burden on the TSC Chair unless they choose to run for the position, and b) 
having the representative come from the TSC ensures that our representative is 
up to speed on all TSC conversations that have occurred.  However, I certainly 
believe the other options are viable as well.

Given our tight schedule during TSC meetings in the coming weeks, it would be 
nice if we can come to a decision on this topic via email.  Please respond with 
your thoughts and opinions and based on the feedback received, I'll try to put 
together a vote on this topic

Re: [onap-tsc] We need to decide how to populate the ONAP Representative to the LFN TAC

[Gadiyar, Rajesh]

+1

From:  on behalf of Jason Hunt 

Date: Thursday, January 11, 2018 at 9:38 AM
To: Dhananjay Pavgi 
Cc: "onap-tsc-boun...@lists.onap.org" , 
onap-tsc 
Subject: Re: [onap-tsc] We need to decide how to populate the ONAP 
Representative to the LFN TAC

#1 makes the most sense to me, but if Mazin feels it's too much for the chair 
to take on, #2 is a fine backup option.


Regards,
Jason Hunt
Executive Software Architect, IBM

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




From:Dhananjay Pavgi 
To:"HU, BIN" , Phil Robb , 
onap-tsc 
Date:01/11/2018 11:00 AM
Subject:Re: [onap-tsc] We need to decide how to populatethe 
   ONAPRepresentative to the LFN TAC
Sent by:onap-tsc-boun...@lists.onap.org




Support Option 1; as TSC Chair for a particular stream has broader 360 view of 
the program including roadmap, priorities etc.

thanks & regards,
Dhananjay Pavgi
+91 98220 22264

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of HU, BIN
Sent: Thursday, January 11, 2018 10:24 PM
To: Phil Robb ; onap-tsc 
Subject: Re: [onap-tsc] We need to decide how to populate the ONAP 
Representative to the LFN TAC

Just FYI:
-  OPNFV TSC voted on Tuesday (Jan 9) to have TSC Chair to represent 
OPNFV in TAC
-  fd.io voted the same today to have TSC Chair represent fd.io in TAC, 
if I am not mistaken.

Option 1 is used by both of our sister communities under the same LFN.

Just an FYI.

Thanks
Bin

From: 
onap-tsc-boun...@lists.onap.org[mailto:onap-tsc-boun...@lists.onap.org]
 On Behalf Of Phil Robb
Sent: Thursday, January 11, 2018 7:08 AM
To: onap-tsc mailto:onap-tsc@lists.onap.org>>
Subject: [onap-tsc] We need to decide how to populate the ONAP Representative 
to the LFN TAC

Hello ONAP TSC Members:

Now that ONAP is a part of the Linux Foundation Networking (LFN) Directed Fund, 
we need to decide how we are going to populate our ONAP Representative in the 
LFN Technical Advisory Council (TAC).

As a reminder, the Scope of the responsibilities of the TAC are:
=
•Scope of responsibility
•Recommend acceptance or removal of projects under the Umbrella to be approved 
by the Governing Board
•Focus on activities that drive collaboration and integration across projects 
(e.g. collaborative development, testing, etc)
•Elected TAC Chair provides guidance to Governing Board on investment needs of 
the project communities

=

Some of the options for us to populate our representative include:
1) Just have the TSC Chair represent ONAP in the TAC
2) Have the TSC vote for some TSC member to represent ONAP in the TAC
3) Have the Committers vote for some Committer-At-Large to represent ONAP in 
the TAC
... etc.

I will be setting up the first TAC meeting to occur somewhere in the last third 
of January and it would be good for the ONAP community to have representation 
from the start.

I personally lean toward option #2 because a) it does not by default put more 
burden on the TSC Chair unless they choose to run for the position, and b) 
having the representative come from the TSC ensures that our representative is 
up to speed on all TSC conversations that have occurred.  However, I certainly 
believe the other options are viable as well.

Given our tight schedule during TSC meetings in the coming weeks, it would be 
nice if we can come to a decision on this topic via email.  Please respond with 
your thoughts and opinions and based on the feedback received, I'll try to put 
together a vote on this topic in about a week.

Thanks,

Phil.
--
Phil Robb
VP Operations - Networking & Orchestration, The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb

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.htmlexternally
 
http://tim.techmahindra.com/tim/disclaimer.htmlinternally
 within TechMahindra.
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
ht

Re: [onap-tsc] Certificate and Secret Management Project to become subproject of AAF

[Gadiyar, Rajesh]

+1

Good outcome. Thanks for driving the alignment with AAF team.

From:  on behalf of "Addepalli, Srinivasa R" 

Date: Wednesday, January 10, 2018 at 8:25 PM
To: "onap-tsc@lists.onap.org" 
Subject: [onap-tsc] Certificate and Secret Management Project to become 
subproject of AAF


We (Intel and TM) have proposed ‘Certificate and Secret Management (CSM)’ as a 
separate project for Beijing release.

Details are here: https://wiki.onap.org/pages/viewpage.action?pageId=16008548.



Both architecture subcommittee and security subcommittee recommended us to make 
it part of AAF for following reasons:



-   Contain projects explosion.

-   Consolidate all security services in one project.

-   Why AAF? - AAF is already providing authentication and authorization 
services.



Based on recommendation, we have approached AAF team.  AAF team (thanks to Ram, 
Jonathan, Sai and Sunil) accepted it to be part of AAF for Beijing release.

All the scope of CSM is accepted by AAF team including certificate management, 
secret management, HW key protection and Mutual TLS among ONAP services.



With this, we will remove CSM from the “Proposed Projects” and put it under AAF.



Please do let us know if there are any questions.



Thanks

Intel & TM team (Original proposers of CSM)




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

Re: [onap-tsc] Planning for ONAP TSC Elections

[Gadiyar, Rajesh]

+1

I agree with the proposal as well – best to keep the current structure until 
Beijing Release (May-18). Also, I am happy to participate in the proposed WG to 
discuss/recommend the new TSC structure.

Regards,
Rajesh

From:  on behalf of Phil Robb 

Date: Wednesday, December 13, 2017 at 5:52 PM
To: "Frank Brockners (fbrockne)" 
Cc: onap-tsc 
Subject: Re: [onap-tsc] Planning for ONAP TSC Elections

Thanks for the feedback Frank and your willingness to help on the WG if we 
choose to go that way.

Other TSC members, please let me know your thoughts when you are able.

Thanks,

Phil.

On Wed, Dec 13, 2017 at 4:46 PM, Frank Brockners (fbrockne) 
mailto:fbroc...@cisco.com>> wrote:
Hi Phil,

your suggestion to keep the current structure stable until Beijing is released 
makes sense. I also support your proposal to form a task force which compiles a 
suggestion for TSC composition and membership in the “stable” phase moving 
forward. Other projects which move to LFN have taken a similar approach, i.e. 
form a WG and aggregate suggestions. Should such a task force be established, 
I’d like to participate.

Thanks, Frank


From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org]
 On Behalf Of Phil Robb
Sent: Mittwoch, 13. Dezember 2017 16:03
To: onap-tsc mailto:onap-tsc@lists.onap.org>>
Subject: [onap-tsc] Planning for ONAP TSC Elections

Hello ONAP TSC Members:

As documented in the ONAP Project Charter, the TSC is tasked with figuring out 
how to populate the TSC in a meritocratic manner beginning 12 months after the 
project launch, which was March 2017.  Hence it is time to start planning this 
transition.  To kick this process off, I have the following suggestions:

- Given that March 2018 is in the middle of the Beijing release cycle, I 
suggest we postpone the TSC election until directly after the Beijing release 
in late May.  We should discuss and approve our method of populating the TSC by 
the end of March, but not actually execute it until late May or early June.  
Please let me know if you think this is a good or bad idea.

- I suggest we form a small workgroup to create an initial proposal for 
discussion with the broader TSC.  Some topics to consider when architecting the 
TSC makeup include:
- Constituencies.  Are there different constituencies that need 
representation on the TSC?
- PTLs.  Having an election of PTLs to populate the TSC one possible way to 
do it.  These PTLs may be from different constituencies, or just At-Large.
- Committers-At-Large (CALs).  Some seats can come from the committer 
community at large.
- Particular Roles.  Possibly have the PTL from the Integration Team, or 
the Release Manager as voting members of the TSC as an example of "special" 
roles that should have TSC representation.
- Company Caps - To ensure that a single company does not have too much 
voting power within the TSC, a limit (usually defined as a percentage) is 
imposed on how many TSC members can come from the same organization (or 
affiliated organization).
- TSC size.  Common guidance is to keep the TSC size somewhere between 7 
and 19.  11,13, and 15 are common sizes.  Depending on how the TSC is populated 
the size may vary or may be static.

Please let me know your thoughts.  If you think a workgroup to put an initial 
proposal together is a good idea, please indicate that.  If you think we should 
have a few open discussions to set an initial direction please indicate that.  
If a workgroup seems reasonable, and you would like to participate in that 
group please indicate that as well.

I look forward to the discussion.

Thanks,

Phil.
--
Phil Robb
Executive Director, OpenDaylight Project
VP Operations - Networking & Orchestration, The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb



--
Phil Robb
Executive Director, OpenDaylight Project
VP Operations - Networking & Orchestration, The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] [onap-discuss] ONAP TSC measures of success

[Gadiyar, Rajesh]

Apologies for getting on this thread a bit late. One good metric for continued 
tracking/grading with be the API stability over successive ONAP releases – both 
APIs internal to ONAP (between ONAP components) and also external APIs. 
Stability of APIs would be a good testament to the solidity of ONAP 
architecture and also a key criterion for industry adoption and production 
deployments. I would like to discuss this at the Paris meeting and see if we 
can define some meaningful measurable metrics.

/R

From:  on behalf of Dhananjay Pavgi 

Date: Thursday, September 14, 2017 at 3:43 AM
To: "GILBERT, MAZIN E (MAZIN E)" , 
"onap-disc...@lists.onap.org" , 
"onap-tsc@lists.onap.org P" 
Subject: Re: [onap-discuss] ONAP TSC measures of success

Dear All,

Couple of other measures that could be considered:


1.  JUNit test coverage across LOC : Indicator of Code Quality (i.e. being 
unit tested)

2.  Number of VNFs successfully on boarded and tested : Indicator of VNF 
adoption rate for ONAP

3.  Number of Integration Test cases covered : Indicator of platform 
maturity for E-2-E use.

thanks & regards,
Dhananjay Pavgi
Mobile : +91 98220 22264
[id:image002.png@01CE7323.F2727500]   [NAP_logo_Sig]
www.techmahindra.com Platinum 
Member. Visit : http://www.onap.org

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of GILBERT, MAZIN E (MAZIN E)
Sent: Wednesday, September 13, 2017 10:26 PM
To: onap-disc...@lists.onap.org; onap-tsc@lists.onap.org P 

Subject: [onap-tsc] ONAP TSC measures of success

Dear ONAP Community,

I want to start an email dialog which we will follow up in our Paris meeting on 
technical measures of success of the ONAP platform.
What measures we should track and make publicly visible in PR events? I know 
LOC has been used already. This seems like one
of 2-3 other measures we should be tracking.

Those measures should be agnostic to any particular release and publicly 
recognized. Please share your thoughts and ideas.

thanks!
Mazin





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@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] R2 use cases planning

[Gadiyar, Rajesh]

Hi Alla: Thanks for sharing your views. This is a good discussion to be had – 
Focus on base ONAP capabilities or put some emphasis on new use cases. My 
opinion is the following:


1)   I see these two things as somewhat linked and not disjointed from each 
other. As we look at missing ONAP platform capabilities, it is helpful to look 
at them in the context of certain use cases. The use cases also help with 
continuous integration and validation of platform capabilities. We need to 
strike a balance for R2 – A) Not a laundry list of use cases, yet a couple of 
interesting use cases that allow us to drive mindshare for ONAP e.g. 5G Network 
Slicing and SDWAN and 2) It is important to address the capabilities gap in 
ONAP and ensure we continue to make it stable and a complete service 
orchestration platform.

2)   I would also emphasize what we agreed during the June F2F – The use 
cases are not intended to be fully featured, fully tested, commercially 
deployable solutions. The use cases are meant as a development vehicle for 
validating key capabilities of ONAP and to facilitate continuous integration 
and validation.

3)   We are quickly headed to the 5G transition which presents a host of 
interesting services and business opportunities for the service provider 
ecosystem. IMO, we need to look at a few base capabilities in support of 5G. 
Network Slicing would be an interesting use case to start with. We will need to 
define the scope carefully to ensure that it does not become a kitchen sink. I 
thought Vimal Begwani made a great start at defining this use case that some of 
us are contributing to.

4)   The SDWAN is a natural adjacency to vCPE use case in ONAP R1. This 
should not add a lot of complexity.

My summary is therefore to focus on: 1) a couple of prioritized use cases for 
R2 (5G Network Slicing and SDWAN) and 2) Drive continued emphasis on making 
ONAP architecture and base capabilities robust.

Regards,
Rajesh

From:  on behalf of Alla Goldner 

Date: Thursday, August 17, 2017 at 11:47 AM
To: "onap-tsc@lists.onap.org" 
Subject: [onap-tsc] R2 use cases planning

Hi again,

And in order to start the actual discussion… ☺

My own view is:


1.   We should concentrate on missing ONAP Platform capabilities

2.   New functional use cases can only be considered if

a.   They have big level of similarity/harmonization with R1 use case

b.   They are about extending ONAP Platform capabilities (no introduction 
of new functionality, new PNFs/VNFs, etc.)

3.   We should follow the high level milestones plan presented on the last 
slide



Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D31754.5538BDB0]

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Alla Goldner
Sent: Thursday, August 17, 2017 9:39 PM
To: onap-tsc@lists.onap.org
Subject: [onap-tsc] R2 use cases planning

Hi, TSC,

I forward the material I’ve presented today on Usecase subcommittee discussions 
and ask for your feedback.

We need to get guidelines on what to concentrate on for R2.



Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D31754.5538BDB0]

From: 
onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Alla Goldner
Sent: Thursday, August 10, 2017 8:21 PM
To: onap-tsc@lists.onap.org; 
'onap-disc...@lists.onap.org' 
mailto:onap-disc...@lists.onap.org>>
Cc: onap-usecase...@lists.onap.org
Subject: [onap-discuss] R2 use cases planning

Hi all,

Unfortunately, we didn’t have time during the TSC meeting to cover R2 use cases 
topic.

I would like to ask you to review the attached presentation, covering status of 
Usecase subcommittee discussions and asking TSC for guidelines on directions we 
should take going forward (Extending ONAP Platform capabilities or introducing 
new functional use cases).
Also, some initial proposal for R2 timelines is part of this input material, 
with emphasize given to pre-R2 milestones related to use cases approval.

It is part of the next meeting agenda, 
https://wiki.onap.org/display/DW/2017-08-17+Meeting+Agenda .
It would be great if we can start the related discussion by emails and get your 
feedback prior to TSC meeting next week.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D31754.5538BDB0]

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 

Re: [onap-tsc] Vote on Date & Location of Next ONAP Developer Face To Face

[Gadiyar, Rajesh]

+1


On Aug 2, 2017, at 2:49 PM, Phil Robb 
mailto:pr...@linuxfoundation.org>> wrote:

Hello ONAP TSC Members:

As was mentioned at the last TSC meeting, Nokia and Orange have offered to host 
the next ONAP Developer Face to Face meeting the week of September 25th, 2017 
at the Nokia Paris-Saclay facility approximately 25 Kilometers south west of 
the Paris Orly airport.  We will have access to an auditorium that holds 200 
people along with several conference/break-out rooms.  We are still finalizing 
the specific days of the event, but I would like to have the TSC approve this 
time/week, and location so that attendees who need visas can begin the process 
of getting them.

Therefore, please provide your vote via email to the following resolution:

Shall the TSC approve the next ONAP Developer Face to Face meeting to be held 
the week of September 25th, at the Nokia facility located in Paris-Saclay, 
France? +1, 0, -1

TSC Members, please provide your vote at your earliest opportunity.  If we 
reach an affirmative vote on this prior to the TSC meeting tomorrow, we'll 
simply make that announcement during the meeting.  If we do not reach an 
affirmative vote, we will discuss this topic and vote on it in the meeting 
tomorrow.

Thanks in advance for your response.

Best,

Phil.
--
Phil Robb
Executive Director, OpenDaylight Project
VP Operations - Networking & Orchestration, The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] [onap-discuss] Draft of TSC Charter Section 5.4.1 Changes

[Gadiyar, Rajesh]

+1

I like Steve’s suggestions below and am supportive.

Kenny: We also need to bottom out on the voting clause for PTLs. We had the 
draft text in the summary Bob, Susanna and I discussed and sent out.

From:  on behalf of Stephen Terrill 

Date: Tuesday, July 25, 2017 at 1:49 AM
To: Kenny Paul , onap-tsc 
Cc: "onap-disc...@lists.onap.org" 
Subject: Re: [onap-discuss] [onap-tsc] Draft of TSC Charter Section 5.4.1 
Changes

Hi,

Thanks Kenny.

To all, I have a few suggestions that we could consider.

Editorial:

After vice chair, we add “where applicable) in 5.4.1.2.  So it becomes: Each 
subcommittee may elect a Chair or Vice-Chair (where applicable)  who is 
responsible for leading meetings and representing the subcommittee to the TSC.
Motivation: To address the comment that the “or” can be read that we only have 
a vice-chair.

Proposed extra addition.
5.4.1.5 The elected chair (and/or vicechair) is submitted to the TSC for 
confirmation.  The TSC decides to accept the outcome or requests a new voting.
Motivation:  The sub-committees are support to the TSC, and in addition this is 
inline with the idea that the sub-committees make recommendations not 
decisions.  This would mean that there is no exception to that rule.  This can 
also enable the TSC, if it was felt to be applicable, consider leadership 
aspects beyond what is considered in one forum for the health of the overall 
community.

Best Regards,

Steve

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Kenny Paul
Sent: 24 July 2017 23:54
To: onap-tsc 
Cc: onap-disc...@lists.onap.org
Subject: [onap-tsc] Draft of TSC Charter Section 5.4.1 Changes

The proposed changes to Section 5.4.1 have been posted to the TSC wiki page
 https://wiki.onap.org/pages/viewpage.action?pageId=4719160

Sorry for the delay but I did not have an editable version of Charter v.7.1 
available to me to redlined and I got that this morning.

What is reflected in the v7.2.1 draft are:
- numbering changes to facilitate a line-by-line vote as was recommended by Ed 
Warnicke
- a page break for the sake of readability
- the text discussed at the July 20th TSC meeting below:

5.4.1.2   Each subcommittee may elect a Chair or Vice-Chair who is responsible 
for leading meetings and representing the subcommittee to the TSC.
5.4.1.3   The Chair or Vice-Chair will be elected by members of the 
subcommittee as of the date the nomination process starts for the election.

5.4.1.4   Voting for a Chair or Vice-Chair not limited to member companies 
however only 1 Subcommittee member from each company, or group of related 
companies (as defined in section 7.4 of the ONAP Project Charter) may vote in 
the election.

Not reflected in this draft is language around from Rajesh Gadiyar, Susana 
Sabater and Bob Monkman around the diversity of participation in leadership 
positions.
I did not include this as A) the language had been inadvertently omitted from 
the discussion and B) the intended scope of those provisions extends beyond the 
specific changes to the topic of Steering Committee elections to also include 
PTL and Community Coordinator roles.  I will with Susana, Bob and Rajesh on the 
specific language around that to be presented at the August 3rd TSC meeting.

Please let me know if you have any questions.

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] TSC VOTE on Repos for AAI, AAF, Modeling & MSB

[Gadiyar, Rajesh]

+1 ALL

--
Regards,
Rajesh


2017-07-23 2:49 GMT+08:00 Kenny Paul 
mailto:kp...@linuxfoundation.org>>:
As mentioned we have several repository requests queued up. Gildas has reviewed 
these and feels the requestors have done their due diligence regarding the data 
needed.

Please vote for each one individually OR respond with a (+1, 0, -1)  
“ALL” to approve or reject all requests
——

VOTE to approve the AAF Project's Requests for the creation of an incremental 
repository (+1, 0 -1)   +1
Components Name

Components Repository name

Maven Group ID

Components Description

luaplugin

aaf/luaplugin

org.onap.aaf.luaplugin

A lua plugin to integrate AAF with MSB, which provides centralized auth 
features at the API Gateway.



VOTE to approve the MSB Project's Requests for the creation of two incremental 
repositories (+1, 0 -1)  +1
Components Name

Components Repository name

Maven Group ID

Components Description

java-sdk

msb/java-sdk

org.onap.msb.sdk

Provides a JAVA SDK for rapid microservices development, including service 
registration, service discovery, request routing, load balancing, retry, etc.

swagger-sdk

msb/swagger-sdk

org.onap.msb.swagger-sdk

Swagger sdk helps to generate swagger.json and java client sdk during the build 
time, it also helps to provide the swagger.json at the given URI in the run 
time.



VOTE to approve the A&AI Project's Requests for the creation of two incremental 
repositories (+1, 0 -1)  +1
Components Name

Components Repository Name

Maven Group ID

Components Discription

esr-server

aai/esr-server

org.onap.aai.esr-server

ESR backend, mainly include the function of external system reachable check and 
data pretreatment

esr-gui

aai/esr-gui

org.onap.aai.esr-gui

External system management ui


VOTE to approve the Modeling Subcommittee’s requests for the creation of an 
incremental repository within the Modeling Project’s structure (+1, 0 -1)  +1
Components Name

Components Repository name

Maven Group ID

Components Description



 modelspec

 modeling/modelspec

 org.onap.modeling.modelspec

The repository for modeling specification

published by modeling subcommittee



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


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

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

Re: [onap-tsc] [onap-discuss] [modeling] Please vote for chairperson of ModelingSubcommittee

[Gadiyar, Rajesh]

+1

Regards,
Rajesh

On Jul 7, 2017, at 8:51 AM, Sandeep Shah2 
mailto:ss00473...@techmahindra.com>> wrote:

+1



Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone


 Original message 
From: "JANA, RITTWIK (RITTWIK)" 
mailto:rj...@research.att.com>>
Date: 7/7/17 7:48 AM (GMT-06:00)
To: Chengli Wang 
mailto:wangchen...@chinamobile.com>>, "denghui 
(L)" mailto:denghu...@huawei.com>>
Cc: onap-disc...@lists.onap.org, 
onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] [modeling] Please vote for chairperson of 
ModelingSubcommittee

+1
Rittwik



Sent via the Samsung Galaxy S® 5 ACTIVE™, an AT&T 4G LTE smartphone


 Original message 
From: Chengli Wang 
mailto:wangchen...@chinamobile.com>>
Date: 7/7/17 4:07 AM (GMT-05:00)
To: "denghui (L)" mailto:denghu...@huawei.com>>
Cc: onap-disc...@lists.onap.org, 
onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] [modeling] Please vote for chairperson of 
ModelingSubcommittee

+1

在 2017年7月7日，上午11:56，denghui (L) 
mailto:denghu...@huawei.com>> 写道：

Hello, Modelling members,

There is only one candidate for modeling subcommittee: Hui Deng

If you support Please help to vote “+1”,
If you are neutral, please vote “0”,
If you don’t please respond  “-1”

Members are listed here: 
https://wiki.onap.org/display/DW/Members

Thanks a lot

DENG Hui

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


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-discuss mailing list
onap-disc...@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] TSC Meeting Minute Approvals

[Gadiyar, Rajesh]

+1

From: Kenny Paul 
Date: Thursday, July 6, 2017 at 7:29 AM
To: Alla Goldner , "mg1...@att.com" , 
"Sauvageau, David" , Deng 
, "xiexj...@chinatelecom.cn" 
, Ed Warnicke , Stephen Terrill 
, Amir Levy , "Christopher 
Donley (Chris)" , Jason Hunt 
, Rajesh Gadiyar , "Haiby, Ranny 
(Nokia - US/San Jose USA)" , "jamil.cha...@orange.com" 
, "aayush.bhatna...@ril.com" 
, Dhananjay Pavgi , 
Xinhui Li , "susana.saba...@vodafone.com" 
, "meng.zhaoxi...@zte.com.cn" 

Cc: onap-tsc 
Subject: TSC Meeting Minute Approvals

TSC Members:
As agreed upon at last week’s TSC meeting we will pursue meeting minute 
approvals via email or a poll in order to maximize the amount of time available 
during the TSC meeting. Initially there are several weeks worth of meeting 
minutes that require approval. I have consolidated the approval requests into a 
single message in an effort to limit the volume of email generated. Going 
forward this will be done on a weekly basis.

Please provide a response to each line with a +1, 0, -1 vote

Approval of the TSC meeting minutes from June 29, 
2017
 (Vote +1, 0 -1)  : +1

Approval of the TSC meeting minutes from June 22, 
2017
 (Vote +1, 0 -1)  : +1

Approval of the TSC meeting minutes from June 15, 
2017
 (Vote +1, 0 -1)  : +1


Thank you.

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] [onap-discuss] Call for Self-Nominations for Modeling Project PTL

[Gadiyar, Rajesh]

Thank you Deng!

From: "denghui (L)" 
Date: Tuesday, June 20, 2017 at 1:22 PM
To: Rajesh Gadiyar , "onap-tsc@lists.onap.org" 
, "onap-disc...@lists.onap.org" 

Cc: "Vul, Alex" , "Elzur, Uri" 
Subject: RE: [onap-discuss] Call for Self-Nominations for Modeling Project PTL

Rajesh,

Sorry for late, was swamped by both OPNFV and LinuxCon in Beijing.
I just put the webpage for members of modeling project,  after couple of days, 
we will call for nominations of the chairs.

Thanks a lot for your remindness
Best regards,

DENG Hui

From: Gadiyar, Rajesh [mailto:rajesh.gadi...@intel.com]
Sent: Tuesday, June 20, 2017 9:30 PM
To: denghui (L) ; onap-tsc@lists.onap.org; 
onap-disc...@lists.onap.org
Cc: Vul, Alex ; Elzur, Uri 
Subject: Re: [onap-discuss] Call for Self-Nominations for Modeling Project PTL

Hello Deng and Rittwik – How about the Modeling sub-committee as we had 
discussed at Beijing F2F? Are you inviting nominees to lead the Modeling 
sub-committee as well?

Regards,
Rajesh


From: 
mailto:onap-discuss-boun...@lists.onap.org>>
 on behalf of "denghui (L)" mailto:denghu...@huawei.com>>
Date: Tuesday, June 20, 2017 at 8:53 AM
To: "onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>" 
mailto:onap-disc...@lists.onap.org>>, onap-tsc 
mailto:onap-tsc@lists.onap.org>>
Subject: [onap-discuss] Call for Self-Nominations for Modeling Project PTL

Hello all

The Modeling project is soliciting self nominations for its Project Technical 
Lead. Per TSC instructions, nominees should be from those listed as committers 
on the Modeling project proposal approved by the ONAP TSC 
(https://wiki.onap.org/pages/viewpage.action?pageId=3247202). The nomination 
period will end on Thursday, June 22. PDT

To nominate, please send an email to the onap-discuss list, stating your 
interest, and a short bio for helping people to know you better.
After the nomination period is closed, a voting poll will be set up for vote 
collection.

Thanks,

Rittwik & Denghui

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

Re: [onap-tsc] [onap-discuss] Call for Self-Nominations for Modeling Project PTL

[Gadiyar, Rajesh]

Hello Deng and Rittwik – How about the Modeling sub-committee as we had 
discussed at Beijing F2F? Are you inviting nominees to lead the Modeling 
sub-committee as well?

Regards,
Rajesh


From: 
mailto:onap-discuss-boun...@lists.onap.org>>
 on behalf of "denghui (L)" mailto:denghu...@huawei.com>>
Date: Tuesday, June 20, 2017 at 8:53 AM
To: "onap-disc...@lists.onap.org" 
mailto:onap-disc...@lists.onap.org>>, onap-tsc 
mailto:onap-tsc@lists.onap.org>>
Subject: [onap-discuss] Call for Self-Nominations for Modeling Project PTL

Hello all

The Modeling project is soliciting self nominations for its Project Technical 
Lead. Per TSC instructions, nominees should be from those listed as committers 
on the Modeling project proposal approved by the ONAP TSC 
(https://wiki.onap.org/pages/viewpage.action?pageId=3247202). The nomination 
period will end on Thursday, June 22. PDT

To nominate, please send an email to the onap-discuss list, stating your 
interest, and a short bio for helping people to know you better.
After the nomination period is closed, a voting poll will be set up for vote 
collection.

Thanks,

Rittwik & Denghui

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

Re: [onap-tsc] [ONAP TSC VOTE] vCPE Residential Broadband Use Case For Release-1

[Gadiyar, Rajesh]

Hello ONAP TSC Members:

As we left it on the ONAP TSC call this week, please review and vote on the 
vCPE Residential Broadband Use Case proposal for inclusion in Release-1 of the 
ONAP project.

The wiki page for your review is here: 
https://wiki.onap.org/display/DW/Use+Case%3A+Residential+Broadband+vCPE

Please include your vote below indicating a "+1" if you approve, a "-1" if you 
deny, and :"0" if you abstain from the vote:



This vote will close at 9:00pm PDT, 12:00 midnight EDT Tuesday 6/20, and 12:00 
noon Wednesday China Time.

Thanks,

Phil.
--
Phil Robb
Executive Director, OpenDaylight Project
VP Operations - Networking & Orchestration, The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb

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

Re: [onap-tsc] [onap-discuss] Tentative July ONAP Developers Face-to-Face Meeting

[Gadiyar, Rajesh]

+1 Good idea ☺

From:  on behalf of "GILBERT, MAZIN E (MAZIN 
E)" 
Date: Monday, June 12, 2017 at 2:01 PM
To: Kenny Paul 
Cc: "onap-disc...@lists.onap.org" , onap-tsc 

Subject: Re: [onap-tsc] [onap-discuss] Tentative July ONAP Developers 
Face-to-Face Meeting

I was not present for this discussion. We need to have a meeting around the 3rd 
week of
July to go through project by project progress. Phil and I discussed a virtual 
meeting
since folks will be too busy to travel, and some may not be able to.

Would like to get a sense from the TSC community if this is appropriate and more
convenient while voting for dates.

thanks
Mazin

On Jun 12, 2017, at 1:08 PM, Kenny Paul 
mailto:kp...@linuxfoundation.org>> wrote:

Please respond to the doodle poll below no later than:
Thurs. 01:00 PM UTC
Thurs. 09:00 PM China
Thurs: 09:00 AM Eastern
Thurs: 06:00 AM Pacific

https://doodle.com/poll/7zufivqebtnvrhdt

Thank You.

Best Regards,
-kenny

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

___
onap-discuss mailing list
onap-disc...@lists.onap.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=IKSC5mg8GeOiSar1dax3GQ&m=7n6f3RBF3LtkjuBpPhqrMbVfiHC_wqVOfDz5z3uutjM&s=8D2aZuG-pN820woJDvlHxyXQnkAsRt0bFjokAPWgc1E&e=

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

Re: [onap-tsc] ONAP TSC Members - Are you Attending the China Face To Face Next Week?

[Gadiyar, Rajesh]

+1 Attending in person; Getting to Beijing on Wed Evening and staying through 
Friday.

From:  on behalf of Phil Robb 

Date: Friday, June 2, 2017 at 7:57 AM
To: onap-tsc 
Subject: [onap-tsc] ONAP TSC Members - Are you Attending the China Face To Face 
Next Week?

Please +1 or -1 if you are attending or not.

Please respond ASAP so that we can know who can help facilitate different 
aspects of the event.

Thanks!

Phil.

--
Phil Robb
Executive Director, OpenDaylight Project
VP Operations - Networking & Orchestration, The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Usage of commercial VNF and NFVI+VIM solutions for ONAP R1 use cases, and open lab

[Gadiyar, Rajesh]

+1

I was taking this as a given. We need a robust vendor/commercial ecosystem of 
VNFs and NFVI software, in addition to open source. I see that the vCPE and 
vVoLTE use case documents on the wiki already incorporate this; which I am 
supportive.

From:  on behalf of Gil Hellmann 

Date: Thursday, June 1, 2017 at 2:08 PM
To: "onap-tsc@lists.onap.org" 
Subject: [onap-tsc] Usage of commercial VNF and NFVI+VIM solutions for ONAP R1 
use cases, and open lab

Dear TSC members,

It is very exciting to see the great momentum and grow in the ONAP community, I 
hear that there is different opinion / debate with regard to whether release 1 
of ONAP should be using commercial VNFs & NFVI+VIM’s solutions for the 
implementation of the proposed use cases and open lab / integration in release 
1 or should it be strictly limited to use only open source. I would suggest 
that the TSC will consider the following before making a decision:

As it was agreed by both the TSC and the wider ONAP community, using real life 
use case like the proposed VoLTE and vCPE use cases for release 1 is very 
important to ensure that ONAP is built from day 1 in a way that will provide 
close implementation to a real-life use case which can provide proper 
foundation to use ONAP in commercial deployment, and implementation of real 
life use case can have a great contribution to the success of this project.

ONAP as orchestration / MANO project require NFVI+VIMs (clouds) to run on, and 
VNFs to run to create the services. The use of commercial NFVI+VIMs and VNFs 
for the use case implementation and open lab / integration can have a big 
positive impact on our ability to be as close as possible to a real-life usage 
scenario. Limiting the usage *to only open source* solutions will limit 
dramatically the ability to get there. Not saying we should not use open source 
VNFs and NFVI+VIMs, but I hope we wouldn’t limit ourselves to only open source 
VNFs & NFVI+VIM in the open lab / integration lab and for the release 1 use 
cases, same like we would not limit yourself to only use open source hardware.

I hope this can be considered, and thanks for your consideration.

Regards,
Gil Hellmann, VP - Solutions Readiness
direct 289.553.5815  mobile 905.409.6878 
 skype ID gil.hellmann

[cid:image001.png@01D2DAE1.D4307D10]
 [cid:image002.png@01D2DAE1.D4307D10] 
  
[cid:image003.png@01D2DAE1.D4307D10] 
  
[cid:image004.png@01D2DAE1.D4307D10] 
  
[cid:image005.png@01D2DAE1.D4307D10] 


[cid:image006.gif@01D2DAE1.D4307D10]
“If you will it, it is no dream.” Theodor Herzl

“If you want to go fast, go alone. If you want to go far, go together.” An old 
African proverb

“The only way to avoid making mistakes is not to do anything. And that.. will 
be the ultimate mistake” Goh Keng Swee
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] [onap-tsc-private] Lab and Intgeration

[Gadiyar, Rajesh]

+1

Hello ONAP TSC:

Intel is considering hosting a physical lab for ONAP as well. I have added our 
proposal to the document on Wiki: 
https://wiki.onap.org/display/DW/Physical+Labs to co-host with the OPNFV lab 
that we currently host.

--
Regards,
Rajesh

From:  on behalf of Chen Yan 

Date: Thursday, May 25, 2017 at 6:39 PM
To: "onap-tsc@lists.onap.org" 
Cc: "xiexj...@chinatelecom.cn" 
Subject: Re: [onap-tsc] [onap-tsc-private] Lab and Intgeration

Dear TSC,

From the above discussions we learned the opinions of the ONAP members on Open 
Lab. As Xiaojun mentioned, China Telecom would like to provide a physical lab 
for ONAP. Actually,  in last year, China Telecom has already established a 
Physical Lab for Open-O mercury release, and finished the E2E connection test 
for vCPE extension use case.

In the near future, a Physical Lab is still important and necessary, especially 
for operators with intention to deploy operational systems to manage not only 
the NFV networks/VNFs but also PNFs.
China Telecom is going to introduce SDN techniques in our Backbone Network, 
e.g. Segment routing and TE. In this case, SDN enabled Physical Network and a 
corresponding Lab is our scope of works.

I would suggest to build up multiple labs, including Virtual labs and Physical 
labs, and solving connectivity issues under integration team/LF governance, in 
order to address on different use cases covering most of the operators 
interests.

Best Regards
Chen Yan

发件人: xiexj...@chinatelecom.cn 
[mailto:xiexj...@chinatelecom.cn]
发送时间: 2017年5月23日,星期二 09:56
收件人: Deng邓灵莉/Lingli; roberto.k...@orange.com; 
Haiby, Ranny (Nokia - US/San Jose USA); Christopher.Donley; 'Jason Hunt'; MAZIN 
E GILBERT; sunqiong.bri
抄送: tsc-priv...@lists.onap.org; SPATSCHECK, 
OLIVER \(OLIVER\); 'Yunxia Chen'
主题: Re: Re: [onap-tsc-private] Lab and Intgeration

China Telecom also has a lab for OPEN-O. Based on this lab, China Telecom is 
willing to provide a physical lab for ONAP too.

Best Regards,

Xiaojun

From: Lingli Deng
Date: 2017-05-23 09:05
To: roberto.k...@orange.com; 'Haiby, Ranny 
\(Nokia - US/San Jose USA\)'; 'Christopher Donley 
\(Chris\)'; 'Jason 
Hunt'; 
ma...@research.att.com
CC: tsc-private; 
spatsch; 'Yunxia 
Chen'
Subject: Re: [onap-tsc-private] Lab and Intgeration
China Mobile is willing to provide a physical lab too, based on the existing 
OPEN-O lab and do enhancement as needed.

Lingli

From: 
onap-tsc-private-boun...@lists.onap.org
 [mailto:onap-tsc-private-boun...@lists.onap.org] On Behalf Of 
roberto.k...@orange.com
Sent: 2017年5月23日 8:28
To: Haiby, Ranny (Nokia - US/San Jose USA) 
mailto:ranny.ha...@nokia.com>>; Christopher Donley 
(Chris) mailto:christopher.don...@huawei.com>>; 
Jason Hunt mailto:djh...@us.ibm.com>>; 
ma...@research.att.com
Cc: Yunxia Chen mailto:helen.c...@huawei.com>>; 
tsc-priv...@lists.onap.org; 
spat...@research.att.com
Subject: Re: [onap-tsc-private] Lab and Intgeration

Orange is willing to provide a physical lab with connectivity from remote, or 
be part of the set up of the virtual lab.

I think that what is important is to have clear specification of what is 
required (Open-O experience would help) asap, so that we can start to 
implement. This may be independent from the integration project if it allows us 
to be more efficient.

RK

PS: actually, today we have an operation lab that is shared (from our internal 
research, our work with universities to our testing for deployment). So the set 
up would be done marginally. We need to see the tooling of course.

De : 
onap-tsc-private-boun...@lists.onap.org
 [mailto:onap-tsc-private-boun...@lists.onap.org] De la part de Haiby, Ranny 
(Nokia - US/San Jose USA)
Envoyé : mardi 23 mai 2017 02:03
À : Christopher Donley (Chris); Jason Hunt; 
ma...@research.att.com
Cc : tsc-priv...@lists.onap.org; 
spat...@research.att.com; Yunxia Chen
Objet : Re: [onap-tsc-private] Lab and Intgeration

Chris,

You actually bring up an excellent point. In order to demonstrate and test real 
life scenarios we will need to tie in physical equipment.

However, it may not be practical to have all the necessary physical equipment 
in the lab. Therefore a more practical approach could be providing connectivity 
from the lab to physical equipment located on an operator or vendor

Re: [onap-tsc] Thoughts on next steps.

[Gadiyar, Rajesh]

+1. I like this approach given our focus to get a good release out in Nov.


From:  on behalf of "Haiby, Ranny (Nokia - 
US/San Jose USA)" 
Date: Tuesday, May 16, 2017 at 2:10 PM
To: "RATH, CHRISTOPHER A (CHRISTOPHER A)" , "SPATSCHECK, 
OLIVER (OLIVER)" , onap-tsc 
Subject: Re: [onap-tsc] Thoughts on next steps.

@Oliver – I share your concern about having 32 projects and gating the release 
with deliverables from each one.

What I would like to propose is categorization of “core” and “non-core” (or a 
less derogatory name) projects. Core projects are those that provide the 
minimum viable product functionality, e.g. A&AI, Modeling, SO, etc. Some 
projects seem like providing functionality beyond the MVP, such as CLAMP, 
Holmes, etc. Some projects will fall somewhere in between and we could use our 
common sense to categorize them.

This way the community could focus on reviewing the core projects first, and 
the release will be gated by deliverables from these projects only. This does 
not mean that non-core projects will not be approved and worked on in the first 
release, assuming they are defined, approved and have contributors.

There are of course some bad implementation examples of such categorization 
(OpenStack “Big Tent” anybody?) but I believe we can avoid past mistakes and 
make this approach work for the benefit of the community.

Ranny.


From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of RATH, CHRISTOPHER A (CHRISTOPHER A)
Sent: Tuesday, May 16, 2017 1:03 PM
To: SPATSCHECK, OLIVER (OLIVER) ; onap-tsc 

Subject: Re: [onap-tsc] Thoughts on next steps.

For the areas in which I have contributions to consider, here are some 
clarifications.

First, the Common Controller Framework should have overlap as far as scope with 
a lot of projects.  That is the point of that project, to find overlapping 
functionality, develop it in a single project, and reuse it among the other 
components.  So I would not be concerned with any overlap between CCF and the 
other projects dealing with deployment, management, orchestration, etc.  That 
is by design.

For DCAE: we have recognized an overlap with Holmes, which in my view should be 
a sub-project of DCAE, but it does not appear that sub-projects were proposed 
this way.  DMaaP does not have an overlap with DCAE.  DCAE uses DMaaP, as do 
many other components, but the scopes are completely different.  I believe the 
functionality in DMaaP for data processing does not exist today and it is not 
clear that it would be part of an open-source release of DMaaP or not anyway.

For DMaaP: The CCF overlap is by design.  It is our intention to provide a 
“Data Bus Controller” with responsibility for deploying and managing DMaaP data 
delivery components where they are needed and when they are needed.  That 
functionality exists in DCAE today, but needs to be pulled out to be generally 
available across ONAP components.

For MSB: I agree this should be part of CCF.  It could be used by DCAE and OOM.

—
Christopher A. Rath
Director Inventive Science – Intelligent Services and Platforms Research


From: mailto:onap-tsc-boun...@lists.onap.org>> 
on behalf of "SPATSCHECK, OLIVER (OLIVER)" 
mailto:spat...@research.att.com>>
Date: Tuesday, May 16, 2017 at 3:47 PM
To: onap-tsc mailto:onap-tsc@lists.onap.org>>
Subject: [onap-tsc] Thoughts on next steps.

***Security Advisory: This Message Originated Outside of AT&T ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.

I just went through the proposals and noticed that quite a few of them have not 
clearly defined boundaries between them which makes me wonder if they overlap 
(see table below). From experience overlapping project definitions rarely lead 
to good outcomes (duplicate work gets done and people are very upset at the 
end…) so I think we should resolve this before approving the projects.

When I built this table I focused on what’s written in the proposals. Now from 
discussions I think some of the perceived overlaps might just be a matter of 
cleaning up the writing. Others might actually be real. In either case I think 
we need to be clear and precise in the project description and can’t rely on 
various email exchanges for this.  I also don’t claim that my table is 
complete. If you want I can put the table on the Wiki so people can add there 
perceived or real overlaps.

I don’t know how you usually resolve those issues but I would think that the 
project leads for all projects which might have an overlap define a common 
statement which defines there relationship with each other in some level of 
detail. Thoughts?

I also looked at the use cases. Lingli and her team did a great job cleaning up 
the VoLTE use case:

https://wiki.onap.org/pages/viewpage.action?pageId=3246140

Re: [onap-tsc] Release Naming

[Gadiyar, Rajesh]

Option 2 (Famous Conductors) is my choice as well.

BTW, just as an FYI, Irvine is not a major Intel site ☺ If you decide to go the 
option 1 route: Hillsboro, Chandler, Santa Clara, Haifa are better options.

From:  on behalf of Alla Goldner 

Date: Tuesday, May 16, 2017 at 10:58 AM
To: "GILBERT, MAZIN E (MAZIN E)" , onap-tsc 

Subject: Re: [onap-tsc] Release Naming

Second option, in my view.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D2CE36.D1E30E40]

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of GILBERT, MAZIN E (MAZIN E)
Sent: Tuesday, May 16, 2017 8:23 PM
To: onap-tsc 
Subject: [onap-tsc] Release Naming

Team,

I have two  proposals for release naming. One from Rueben Klein and the other
from Gildas Lanilis.

The first is famous cities belonging to platinum members, and the other is 
famous conductors in
the domain of orchestrating:-) Both follow the alphabet style.
Please review and share comments before our TSC meeting on Thursday.

Thanks
Mazin


Option 1
Platinum Member

Country

Major Locations

IBM

US

Armonk

China Mobile/Telecom

China

Beijing

Amdocs

US

Chesterfield

AT&T

US

Dallas

Nokia

Finland

Espoo

VMWare

US (IL)

Herzliya

Intel

US

Irvine

Ericsson

Sweden

Kista

Tech Mahindra

India

Mumbai

Gigaspaces

US

New York

Bell Canada

Canada

Ottawa

Orange

France

Paris

Cisco

US

San Jose

Huawei

China

Shenzhen

ZTE

China

Tianjin



Option 2

Famous Conductors:
As ONAP plays in the domain of orchestrating, we could use the name of famous 
conductors.
Continuous Naming: Amadeus, Beethoven, Chopin, Debussy, Enescu, Foote, 
Gershwin, Handel, Ilyich, Johannes
Non-Continuous naming: Amadeus, Beethoven, Chopin, Debussy, Gershwin, Liszt, 
Puccini, Ravel, Schubert, Tchaikovsky, Vivaldi, Wagner
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
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Proposal: Architecture Subcommittee

[Gadiyar, Rajesh]

+1 for forming the Architecture Subcommittee; Also agree with Chris and Alla on 
the ‘advisory’ nature of the Architecture sub-committee, and the important 
overseeing role this committee needs to play to ensure the consistency across 
the ONAP modules, interfaces, contentious issues between projects etc.

Leading upto the Middletown meetings, the effort that Vimal and Lingli had 
started with a small team on the ONAP architecture evolution and the 
architecture principles had made excellent progress. I like a small team 
approach for the Architecture Subcommittee (perhaps 1 participant nominated by 
each TSC member from their respective company) with a regular (monthly?) synch 
point with the larger technical community.

Rajesh

From:  on behalf of Alla Goldner 

Date: Friday, May 12, 2017 at 10:46 AM
To: "Christopher Donley (Chris)" , "SPATSCHECK, 
OLIVER (OLIVER)" , "aayush.bhatna...@ril.com" 

Cc: "onap-tsc@lists.onap.org" 
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

+1, as also provided by my previous response to Aayush.

Architecture subcommittee, if created, should not deal with any specific 
architecture requirements, which are up to release/project to define.
Architecture subcommittee should review interactions between a different 
components/modules per defined Release goals, i.e. be responsible to validate 
whether e2e architecture across all modules is correct, whether all necessary 
interactions are covered etc.. It may also propose a new project, if gaps are 
identified, but it will be up to community to create such a project and up to 
TSC to approve/reject it.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D2CB21.F7B6FE50]

From: Christopher Donley (Chris) [mailto:christopher.don...@huawei.com]
Sent: Friday, May 12, 2017 8:38 PM
To: SPATSCHECK, OLIVER (OLIVER) ; 
aayush.bhatna...@ril.com
Cc: Alla Goldner ; Kanagaraj Manickam 
; bob.monk...@arm.com; onap-tsc@lists.onap.org
Subject: RE: [onap-tsc] Proposal: Architecture Subcommittee

+1.  The architecture subcommittee should NOT put gating requirements on any 
projects. Projects should be responsible for their own release plans and 
resources. I want to stress that my proposal is for an advisory committee, not 
a controlling committee. Specifically, the architecture subcommittee doesn’t 
have the power to make decisions or vote.  By Charter, that is solely the 
purview of the TSC. If decisions need to be made, such issues will be brought 
to the TSC.

The architecture subcommittee is advisory by nature, and not authoritative. It 
may provide advice to projects and to the TSC, such as by providing a forum to 
help resolve architectural questions that may arise.

The subcommittee should help to set a target functional architecture for the 
community (but not mandate it). That target may move over time, and it may take 
projects more than one release to catch up to it.  Scoping would be the 
responsibility of each project.  I also think there should be room for 
innovation. If a team has a good idea that would change the functional 
architecture, we may want to consider it.  I believe having a consensus target 
and a defined forum helps facilitate those conversations.

In the draft release plan, there is a checkpoint between functionality freeze 
and API freeze for an architecture check.  I think that would be a good spot 
for the architecture subcommittee to schedule a walk-through with each project 
to discuss the handoffs between each component to identify any gaps so that 
teams have time to respond prior to API freeze.  The subcommittee should be 
asking questions, not dictating answers.

Chris

From: SPATSCHECK, OLIVER (OLIVER) [mailto:spat...@research.att.com]
Sent: Friday, May 12, 2017 6:42 AM
To: aayush.bhatna...@ril.com
Cc: GOLDNER, ALLA; Kanagaraj Manickam; 
bob.monk...@arm.com; Christopher Donley (Chris); 
onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

Don’t get my comment wrong I am in full support of an architecture 
subcommittee. I am somewhat worried on scope and process though.

If the architecture team can put release gating requirements on the project as 
outlined below (maybe I didn’t understand that correctly …) what is the process 
to ensure that they are realistic in the next release (enough resources 
available in the project) and align with the priorities of the volunteers in 
the projects which do the  work.  If they don’t they won’t get implemented and 
we don’t have a release.

I thought release features are worked by the projects.

It always worries me if you separate the decision process from the resources as 
without resources even the best decision has no value.

Oliver


On May 12, 2017, at 2:01 AM, 
aayush.bhatna...@ril.com wrote:

+1 for the subcommittee formation.

Additional proposal on 

[onap-tsc] Congratulations to Lingli Deng - ONAP Vice Chair

[Gadiyar, Rajesh]

Dear friends,

Please join me in Congratulating my dear friend Lingli, a deserved winner for 
the ONAP Vice Chair. Her thorough, detail oriented approach will be a great 
asset for us in ONAP. Congratulations Lingli and I look forward to working 
closely with you.
--
Regards,
Rajesh


From:  on behalf of Phil Robb 

Date: Saturday, May 6, 2017 at 4:32 AM
To: "onap-tsc@lists.onap.org" 
Subject: [onap-tsc] The TSC Vice Chairperson Election Has Concluded

Hello ONAP TSC Members:

The TSC Vice Chairperson Election has concluded.  For the TSC members, there is 
a link on the email that was your original invitation to vote that has the 
results.  A copy of that information is also provided below for the rest of the 
community.

Congratulations Lingli, and thanks to all of the excellent candidates in this 
election.

Result
1. Lingli Deng  (Condorcet winner: wins contests with all other choices)

2. Chris Donley  loses to Lingli Deng by 9–5

3. Rajesh Gadiyar  loses to Lingli Deng by 10–5, loses to Chris Donley by 8–7

4. Alla Goldner  loses to Lingli Deng by 11–4, loses to Rajesh Gadiyar by 9–5

Result details Hide details




1

2

3

4

1. Lingli Deng



-

9

10

11

2. Chris Donley



5

-

8

9

3. Rajesh Gadiyar



5

7

-

9

4. Alla Goldner



4

6

5

-

Ballot report


Alla Goldner

Chris Donley

Lingli Deng

Rajesh Gadiyar

1.

1

3

4

2

2.

3

2

1

4

3.

3

4

1

2

4.

3

4

1

2

5.

4

3

2

1

6.

4

3

2

1

7.

1

4

2

3

8.

4

2

1

3

9.

3

1

4

2

10.

2

3

1

4

11.

4

1

2

3

12.

2

3

4

1

13.

3

2

1

4

14.

4

1

2

3

15.

4

1

1

4


Ballots are shown in a randomly generated order.

[Download ballots in CSV 
format]

The following matrix shows the strength of the strongest beatpath connecting 
each pair of choices. Choice 1 is ranked above choice 2 if there is a stronger 
beatpath leading from 1 to 2 than any leading from 2 to 1.




1.

2.

3.

4.

1. Lingli Deng



-

9–5

10–5

11–4

2. Chris Donley



.

-

8–7

9–6

3. Rajesh Gadiyar



.

.

-

9–5

4. Alla Goldner



.

.

.

-

Best,

Phil.
--
Phil Robb
Executive Director, OpenDaylight Project
VP Operations - Networking & Orchestration, The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

[onap-tsc] ONAP TSC VICE-CHAIRPERSON

[Gadiyar, Rajesh]

Dear ONAP TSC and the Technical Community,

I am interested in serving as the ONAP TSC Vice Chair and I request your 
support. As the vice-chair, I will focus on the following priorities and work 
closely with Mazin Gilbert and the TSC members:

1)  Focus on Deployments ? I will take a pragmatic view and look to 
prioritize ONAP features & capabilities that drive real deployments. I believe 
that, ensuring small successes quickly, will go a long way in motivating the 
community and driving business success.
2)  Build the ONAP Ecosystem ? My key focus over the next few months will 
be to help recruit other Service Providers, OEMs, VNF vendors and System 
Integrators to make ONAP the defacto standard for Service Orchestration.
3)  Drive Synergy with Open Source Projects ? I will promote collaboration 
and alignment with other communities such as OPNFV, ETSI-NFV, DPDK, FD.io, 
Openstack, ODL and TOSCA.

I have over 25 years of experience in the Telco industry. At Intel, I have led 
the creation of a strong networking capability on standard server platforms. My 
team and I have played a key role in creating the NFV vision in the industry 
and bringing it to fruition; This includes significant contributions to open 
source projects such as Data Plane Development Kit (DPDK), FD.io, ODL, OPNFV, 
ETSI, IETF, Openstack, Open VSwitch and others. I am excited to be a part of 
the ONAP project, which I believe is a critical element for fueling business 
growth by creating a nimble and efficient services infrastructure of tomorrow. 
My short bio is attached.

Regards,
Rajesh Gadiyar


Rajesh Gadiyar,
Sr. Director, Architecture & Systems Engineering,
Network Platforms Group, Intel Corp.

[../../../Desktop/2017MarchPassportPhoto.jpg]Rajesh Gadiyar is the Sr. Director 
of Architecture & Systems Engineering in the Network Platforms Group at Intel. 
He is focused on driving a scalable and efficient architecture for next 
generation communications platforms. He leads the architecture efforts to 
accelerate Network Function Virtualization (NFV).

Since joining Intel in 1996, he has held several positions in Engineering, 
Professional Services, Strategic Planning and Architecture. Prior to joining 
Intel, he led various engineering teams at Trillium Digital Systems and Wipro 
Ltd. He brings several years of experience in networking products, 
architecture, protocols, standards and software development for Voice over IP, 
cellular, broadband, mobile telephony and data networks. He represents Intel in 
standard committees such as ATIS TOPS council and TIA and is a TSC member of 
the Open Network Automation Platform (ONAP) initiative under Linux Foundation. 
He is a regular speaker at industry events and forums. Rajesh has a B.S. in 
Electronics and Telecommunications engineering from National Institute of 
Technology, Trichy, India and an MBA from UCLA Anderson School of Management.



From: mailto:onap-tsc-bounces at 
lists.onap.org>> on behalf of Phil Robb mailto:pr...@linuxfoundation.org>>
Date: Friday, April 28, 2017 at 3:49 PM
To: "onap-tsc at lists.onap.org<mailto:onap-tsc at lists.onap.org>" mailto:onap-tsc at lists.onap.org>>
Subject: [onap-tsc] [ONAP TSC VICE-CHAIRPERSON ELECTION] Kickoff of the ONAP 
TSC Vice-Chairperson Election

Hello ONAP TSC Members:

Please consider this email as the kickoff of the ONAP TSC Vice-Chair Election 
process.

There are two phases to the election process.  The first is the Nomination 
Phase where TSC Members may nominate themselves for the position of TSC 
Vice-Chairperson.  Once the Nomination Phase has concluded, we will enter the 
Election Phase, where all ONAP TSC Members are invited and encouraged to vote 
on the candidates whom have been nominated.

Timing:
?  Nominations open April 28th, 2017.
?  Nominations close May 2nd at 9:00pm Pacific Time
?  Voting begins May 3rd, 2017
?  Voting Ends May 5th, 2017 at 9:00pm Pacific Time

If you are an ONAP TSC member and wish to nominate yourself for the position of 
TSC Vice-Chairperson, please respond-all to this email with your picture 
(headshot), biography, and statement of interest on why you would wish to be 
the TSC Vice-Chairperson.  I wlll post this information to the wiki prior to 
the start of the election so that everyone in the technical community is able 
to become familiar with the candidates.

If you have any questions, please do not hesitate to contact me.

Best,

Phil.
--
Phil Robb
Executive Director, OpenDaylight Project
VP Operations - Networking & Orchestration, The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.onap.org/pipermail/onap-tsc/attachments/20170501/0079f61b/attachment-0001.html>
-- next part --
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 113045 bytes
Desc: imag

[onap-tsc] ONAP TSC VICE-CHAIRPERSON

[Gadiyar, Rajesh]

Dear ONAP TSC and the Technical Community,

I am interested in serving as the ONAP TSC Vice Chair and I request your 
support. As the vice-chair, I will focus on the following priorities and work 
closely with Mazin Gilbert and the TSC members:

1)   Focus on Deployments ? I will take a pragmatic view and look to 
prioritize ONAP features & capabilities that drive real deployments. I believe 
that, ensuring small successes quickly, will go a long way in motivating the 
community and driving business success.

2)   Build a strong ONAP Ecosystem ? My key focus over the next few months 
will be to help recruit other Service Providers, OEMs, VNF vendors and System 
Integrators to make ONAP the defacto standard for Service Orchestration.

3)   Drive Synergy with Open Source Projects ? I will promote collaboration 
and alignment with other communities such as OPNFV, ETSI-NFV, DPDK, FD.io, 
Openstack, ODL and TOSCA.

I have over 25 years of experience in the Telco industry. At Intel, I have led 
the creation of a strong networking capability on standard server platforms. My 
team and I have played a key role in creating the NFV vision in the industry 
and bringing it to fruition; This includes significant contributions to open 
source projects such as Data Plane Development Kit (DPDK), FD.io, ODL, OPNFV, 
ETSI, IETF, Openstack, Open VSwitch and others. I am excited to be a part of 
the ONAP project, which I believe is a critical element for fueling business 
growth by creating a nimble and efficient services infrastructure of tomorrow. 
My short bio is attached.

Regards,
Rajesh Gadiyar


Rajesh Gadiyar,
Sr. Director, Architecture & Systems Engineering,
Network Platforms Group, Intel Corp.

[../../../Desktop/2017MarchPassportPhoto.jpg]Rajesh Gadiyar is the Sr. Director 
of Architecture & Systems Engineering in the Network Platforms Group at Intel. 
He is focused on driving a scalable and efficient architecture for next 
generation communications platforms. He leads the architecture efforts to 
accelerate Network Function Virtualization (NFV).

Since joining Intel in 1996, he has held several positions in Engineering, 
Professional Services, Strategic Planning and Architecture. Prior to joining 
Intel, he led various engineering teams at Trillium Digital Systems and Wipro 
Ltd. He brings several years of experience in networking products, 
architecture, protocols, standards and software development for Voice over IP, 
cellular, broadband, mobile telephony and data networks. He represents Intel in 
standard committees such as ATIS TOPS council and TIA and is a TSC member of 
the Open Network Automation Platform (ONAP) initiative under Linux Foundation. 
He is a regular speaker at industry events and forums. Rajesh has a B.S. in 
Electronics and Telecommunications engineering from National Institute of 
Technology, Trichy, India and an MBA from UCLA Anderson School of Management.




From:  on behalf of Phil Robb 

Date: Friday, April 28, 2017 at 3:49 PM
To: "onap-tsc at lists.onap.org" 
Subject: [onap-tsc] [ONAP TSC VICE-CHAIRPERSON ELECTION] Kickoff of the ONAP 
TSC Vice-Chairperson Election

Hello ONAP TSC Members:

Please consider this email as the kickoff of the ONAP TSC Vice-Chair Election 
process.

There are two phases to the election process.  The first is the Nomination 
Phase where TSC Members may nominate themselves for the position of TSC 
Vice-Chairperson.  Once the Nomination Phase has concluded, we will enter the 
Election Phase, where all ONAP TSC Members are invited and encouraged to vote 
on the candidates whom have been nominated.

Timing:
?  Nominations open April 28th, 2017.
?  Nominations close May 2nd at 9:00pm Pacific Time
?  Voting begins May 3rd, 2017
?  Voting Ends May 5th, 2017 at 9:00pm Pacific Time

If you are an ONAP TSC member and wish to nominate yourself for the position of 
TSC Vice-Chairperson, please respond-all to this email with your picture 
(headshot), biography, and statement of interest on why you would wish to be 
the TSC Vice-Chairperson.  I wlll post this information to the wiki prior to 
the start of the election so that everyone in the technical community is able 
to become familiar with the candidates.

If you have any questions, please do not hesitate to contact me.

Best,

Phil.
--
Phil Robb
Executive Director, OpenDaylight Project
VP Operations - Networking & Orchestration, The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.onap.org/pipermail/onap-tsc/attachments/20170501/68de402a/attachment-0001.html>
-- next part --
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 113045 bytes
Desc: image001.jpg
URL: 
<http://lists.onap.org/pipermail/onap-tsc/attachments/20170501/68de402a/attachment-0001.jpg>
-- next part --
A no

[onap-tsc] Service Assurance Breakout Session on Friday May 5th

[Gadiyar, Rajesh]

Hello ONAP TSC and the Technical Community ?

Intel and AT&T are planning to host a breakout session on ?Service Assurance? 
during the upcoming ONAP developer summit in Middletown, NJ. Our plan is to 
reserve a 4 hour slot on Friday, May 5th. AT&T (Alok Gupta) and Intel (Tim 
Verrall, Maryam Tahhan) are leading this effort and will coordinate the 
session. Below is a short abstract:

In this breakout session we will cover the need for platform, infrastructure 
and NFV service assurance.
Providing tools and methodologies for tracking the service levels being 
delivered by NFV infrastructure and VNFs is a challenging area that has not 
been fully addressed as yet, we will discuss the types of telemetry and alarms 
required to locate and resolve points of contention or failure in these 
environments. Expanding on this, we will discuss collection methodologies and 
frameworks, common event and metric formats, common distribution schemes and 
the integration of this into management frameworks for the virtualized 
environments. We will also discuss the implications to ONAP and what we need to 
support ?Service Assurance? in ONAP.

Service Assurance
?In the Enterprise or Telco, Service Assurance is the application of 
policies and processes to ensure that services offered over networks meet a 
pre-defined service quality level for an optimal user or subscriber experience.
?Network Service Assurance practices enable the ability to identify 
faults and resolve these in a timely manner so as to minimize service downtime. 
This also includes the ability to proactively locate, diagnose and repair 
degradations or malfunctions in service quality before users or subscribers are 
impacted.
?Provisioning, monitoring and service impacting fault detection for 
infrastructure platforms
?Enable Reactive and Pro-active fault detection, fault reporting and 
support corrective actions
?Support current Industry Standard 
FCAPS, Platform Telemetry and flow 
Telemetry interfaces
?Support Open Interoperable Interfaces to integrate with High 
Availability, NFV MANO, and Service Assurance software elements

A detailed agenda will follow next week.

If you have interest in this key topic, please reach out to Alok, Tim and 
Maryam and they will invite you to this breakout.

Regards,
Rajesh Gadiyar
-- next part --
An HTML attachment was scrubbed...
URL: 

[onap-tsc] [onap-discuss] ONAP Project: Registration for May Developer Event

[Gadiyar, Rajesh]

Architecture Deep Dive, Code Merge Strategy, Release Planning and some initial 
discussions on project proposals are all good topics for the May F2F.

However, if at all possible, I would like to request that we hold these 
sessions during the later part of that week (at least avoid Day 1). A few of us 
have conflicts during Day 1 due to commitments at the NFV Congress and will be 
able to make it to NJ mid-week.

Regards,
Rajesh

From:  on behalf of "Sauvageau, David" 

Date: Tuesday, April 11, 2017 at 7:30 PM
To: Annie Fisher , "onap-tsc at lists.onap.org" 

Subject: Re: [onap-tsc] [onap-discuss] ONAP Project: Registration for May 
Developer Event

Hi Annie & TSC members,

I would like to propose some kind of a hackathon during the Developer event in 
order to really make it a developer-focused event.

I believe that architecture, code merger strategy and release planning is 
definitely required for that session but if we are to regroup 75-100 developers 
and architects together then we should probably leverage the opportunity to 
have them to start working together.

We could propose an agenda where day 1 is targeted for general audience in 
order to discuss high-level architecture, merging strategy, release planning 
etc, but maybe there could be a parallel track for a hackathon during days 2-3 
or something. We could even have limited ECOMP+Open-O integration POCs at the 
end of the event.

Thoughts?

From:  on behalf of Annie Fisher 

Date: Monday, April 10, 2017 at 8:23 PM
To: "onap-tsc at lists.onap.org" , "onap-discuss at 
lists.onap.org" 
Subject: [onap-discuss] ONAP Project: Registration for May Developer Event

[line image 1]

ONAP Project Developer Event
May 2 - 4, 2017
AT&T Labs Research, Middletown, NJ
Link to register:  https://www.regonline.com/ONAPDeveloper
Note: instructions for obtaining necessary visa letters as well at hotel 
information may be found by clicking this link.

Proposed Agenda/Subject Areas to be covered*:
Framework for code merger of Open-O and ECOMP code including:
- Agreement on Principles of merging the code
- Target applications to support in Release 1
- Consolidated Target Architecture of merged code for release 1
- Code modification & implementation methods for merging the code
- Other work to be done for first release
- Target date for first release
- Release cadence
.. *and more...


Annie Fisher, MPA CSM
Program Manager, The Linux Foundation
Location & Time-zone: San Francisco, CA, PST
web: https://www.linuxfoundation.org/
email: afisher at linuxfoundation.org
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 45522 bytes
Desc: image001.png
URL: