Re: [onap-tsc] Proposal: Architecture Subcommittee

[Stephen Terrill]

Hi,

My view is that architecture alignment is needed and in particular during this 
formative phase.  I think that during this phase, the architecture output will 
be listened to irrespective of the organizational approach we have.  I would 
like, however, that the projects have freedom within the bounds of the 
direction as well, and can indeed challenge the architecture – which I am 
hoping will make a stronger solution over time but attracting innovative people 
to try and propose new approaches.  What I would not like to see is that we 
cannot try innovative ideas due to “not being decided in the architecture”.  
For this reason I like the balance that Chris provides with a committee 
approach.  Just my 5c.

Best Regards,

Steve

From: Kanagaraj Manickam [mailto:kanagaraj.manic...@huawei.com]
Sent: 16 May 2017 15:14
To: Stephen Terrill <stephen.terr...@ericsson.com>; Bob Monkman 
<bob.monk...@arm.com>; Christopher Donley (Chris) 
<christopher.don...@huawei.com>; onap-tsc <onap-tsc@lists.onap.org>
Subject: RE: Re: [onap-tsc] Proposal: Architecture Subcommittee

Hi Steve,
That is the point,  project perspective brings more of authorative in nature, 
to support different projects align as directed by arch. committee.

And I tried to suggest the project repo here, helps to store the artifacts, 
which are approved the project’s committers. Also it keeps track of 
architecture evolution and API versions across different releases and 
milestones.
Your thoughts.

Regards
Kanagaraj M

***
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！**

***
This e-mail and its attachments contain confidential information from HUAWEI, 
which is intended only for the person  or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not   
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is  prohibited. If you receive 
this e-mail in error, please notify the sender by phone or email immediately 
and delete it!
***

From: Stephen Terrill [mailto:stephen.terr...@ericsson.com]
Sent: Monday, May 15, 2017 2:40 AM
To: Kanagaraj Manickam; Bob Monkman; Christopher Donley (Chris); onap-tsc
Subject: RE: Re: [onap-tsc] Proposal: Architecture Subcommittee

Hi All,

@Chris,  thanks for the proposal, I think it’s a good approach.  I appreciate 
very much that its proposed to be open to all.

I am responding to this email as it both brings up a few interesting aspects 
and proposes an alternative approach, which is to have a project for the 
architecture.

I would like to address the proposal for a project based approach.  For the 
complexity we have facing us going forward, we do need alignment in the 
architecture, however we also benefit from the projects being as autonomous as 
possible. It’s a balance.  I feel that the committee approach, as proposed,  
can balance between providing guidance and holding things together while 
allowing at the same time the projects to own the APIs and have innovation in 
their own architecture, whereas I feel that an architecture project approach 
would take the balance towards being less advisory in nature and more 
authorative in nature, which in the long run could be limiting.

I think it would be good that the architecture committee could recommend which 
projects own which interfaces/APIS, and when required, provide guidance on the 
capabilities of the interface (not how, the project is best position to produce 
that).   One way to express these capabilities is in capturing the e2e 
informational call flows for the decided use cases.

This email contains another proposal, which may actually have being a 
motivation for a project to have a repo for the artifacts (e.g. UML, or other). 
 There is a point behind this, however I wonder whether we could address this 
in another way?

BR,

Steve





From: onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org> 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Kanagaraj Manickam
Sent: 12 May 2017 01:55
To: Bob Monkman <bob.monk...@arm.com<mailto:bob.monk...@arm.com>>; Christopher 
Donley (Chris) 
<christopher.don...@huawei.com<mailto:christopher.don...@huawei.com>>; onap-tsc 
<onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>>
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

IMHO, its really an important and critical team for onap community to ride in 
right path and to maintain the integrity of onap projects as a whole. so w

Re: [onap-tsc] Proposal: Architecture Subcommittee

[Alla Goldner]

Hi Steve, all,

My impression was that the requirements mentioned by you will be covered by the 
Documentation project: 
https://wiki.onap.org/pages/viewpage.action?pageId=3247185

Thus, perhaps, if we indeed create architecture subcommittee, it would be good 
to mention that it provides recommendations to Documentation project on what 
and how should be covered (e.g. flows, APIs etc.) per use cases and/or modules 
interactions.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D2CD4A.BAD263F0]

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Stephen Terrill
Sent: Monday, May 15, 2017 12:10 AM
To: Kanagaraj Manickam <kanagaraj.manic...@huawei.com>; Bob Monkman 
<bob.monk...@arm.com>; Christopher Donley (Chris) 
<christopher.don...@huawei.com>; onap-tsc <onap-tsc@lists.onap.org>
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

Hi All,

@Chris,  thanks for the proposal, I think it’s a good approach.  I appreciate 
very much that its proposed to be open to all.

I am responding to this email as it both brings up a few interesting aspects 
and proposes an alternative approach, which is to have a project for the 
architecture.

I would like to address the proposal for a project based approach.  For the 
complexity we have facing us going forward, we do need alignment in the 
architecture, however we also benefit from the projects being as autonomous as 
possible. It’s a balance.  I feel that the committee approach, as proposed,  
can balance between providing guidance and holding things together while 
allowing at the same time the projects to own the APIs and have innovation in 
their own architecture, whereas I feel that an architecture project approach 
would take the balance towards being less advisory in nature and more 
authorative in nature, which in the long run could be limiting.

I think it would be good that the architecture committee could recommend which 
projects own which interfaces/APIS, and when required, provide guidance on the 
capabilities of the interface (not how, the project is best position to produce 
that).   One way to express these capabilities is in capturing the e2e 
informational call flows for the decided use cases.

This email contains another proposal, which may actually have being a 
motivation for a project to have a repo for the artifacts (e.g. UML, or other). 
 There is a point behind this, however I wonder whether we could address this 
in another way?

BR,

Steve





From: onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org> 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Kanagaraj Manickam
Sent: 12 May 2017 01:55
To: Bob Monkman <bob.monk...@arm.com<mailto:bob.monk...@arm.com>>; Christopher 
Donley (Chris) 
<christopher.don...@huawei.com<mailto:christopher.don...@huawei.com>>; onap-tsc 
<onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>>
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

IMHO, its really an important and critical team for onap community to ride in 
right path and to maintain the integrity of onap projects as a whole. so would 
like to suggest an idea to systematically handle it as below

- should we consider architecture as a project, which will have ptl, committers 
and any contributors and importantly git repository. so that we formalize the 
approval process of the given change in onap architecture.
-  instead of ppt format, should we  use uml and store it in XML in git 
repository for architecture diagram and use some tool automate the creation of 
architecture diagram from XML
- as part of it, could we bring approval process for nbi and sbi of each 
component of architecture as well.
- in addition, should integration project  automate the validation of nbi and 
sbi of  the project deliverable whether it meets the approved ones by 
architecture committee, who already had committed the nbi and sbi in 
architecture git repository in the appropriate form like one of   yang, 
swagger, etc. interoperability will be taken care by this way.

this end2end process will govern the integrity of onap architecture as a whole.

and i am not sure, but it could bring opportunities to non tsc member as a 
committer in architecture project☺ for bringing his(er) expertise to onap.

your thoughts.
---
Kanagaraj M
From:Bob Monkman
To:Christopher Donley (Chris),onap-tsc,
Date:2017-05-12 00:44:28
Subject:Re: [onap-tsc] Proposal: Architecture Subcommittee

+1  

Robert (Bob) Monkman
Networking Software Strategy & Ecosystem Programs
ARM
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490
Skype: robert.monkman

From: Christopher Donley (Chris) [mailto:christopher.don...@huawei.com]
Sent: Thursday, May 11, 2017 12:03 PM
To: Bob Monkman <bob.monk...@arm.com<mailto:bob.monk...@arm.com>>; 
onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.

Re: [onap-tsc] Proposal: Architecture Subcommittee

[Stephen Terrill]

Hi All,

@Chris,  thanks for the proposal, I think it’s a good approach.  I appreciate 
very much that its proposed to be open to all.

I am responding to this email as it both brings up a few interesting aspects 
and proposes an alternative approach, which is to have a project for the 
architecture.

I would like to address the proposal for a project based approach.  For the 
complexity we have facing us going forward, we do need alignment in the 
architecture, however we also benefit from the projects being as autonomous as 
possible. It’s a balance.  I feel that the committee approach, as proposed,  
can balance between providing guidance and holding things together while 
allowing at the same time the projects to own the APIs and have innovation in 
their own architecture, whereas I feel that an architecture project approach 
would take the balance towards being less advisory in nature and more 
authorative in nature, which in the long run could be limiting.

I think it would be good that the architecture committee could recommend which 
projects own which interfaces/APIS, and when required, provide guidance on the 
capabilities of the interface (not how, the project is best position to produce 
that).   One way to express these capabilities is in capturing the e2e 
informational call flows for the decided use cases.

This email contains another proposal, which may actually have being a 
motivation for a project to have a repo for the artifacts (e.g. UML, or other). 
 There is a point behind this, however I wonder whether we could address this 
in another way?

BR,

Steve





From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Kanagaraj Manickam
Sent: 12 May 2017 01:55
To: Bob Monkman <bob.monk...@arm.com>; Christopher Donley (Chris) 
<christopher.don...@huawei.com>; onap-tsc <onap-tsc@lists.onap.org>
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

IMHO, its really an important and critical team for onap community to ride in 
right path and to maintain the integrity of onap projects as a whole. so would 
like to suggest an idea to systematically handle it as below

- should we consider architecture as a project, which will have ptl, committers 
and any contributors and importantly git repository. so that we formalize the 
approval process of the given change in onap architecture.
-  instead of ppt format, should we  use uml and store it in XML in git 
repository for architecture diagram and use some tool automate the creation of 
architecture diagram from XML
- as part of it, could we bring approval process for nbi and sbi of each 
component of architecture as well.
- in addition, should integration project  automate the validation of nbi and 
sbi of  the project deliverable whether it meets the approved ones by 
architecture committee, who already had committed the nbi and sbi in 
architecture git repository in the appropriate form like one of   yang, 
swagger, etc. interoperability will be taken care by this way.

this end2end process will govern the integrity of onap architecture as a whole.

and i am not sure, but it could bring opportunities to non tsc member as a 
committer in architecture project☺ for bringing his(er) expertise to onap.

your thoughts.
---
Kanagaraj M
From:Bob Monkman
To:Christopher Donley (Chris),onap-tsc,
Date:2017-05-12 00:44:28
Subject:Re: [onap-tsc] Proposal: Architecture Subcommittee

+1  

Robert (Bob) Monkman
Networking Software Strategy & Ecosystem Programs
ARM
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490
Skype: robert.monkman

From: Christopher Donley (Chris) [mailto:christopher.don...@huawei.com]
Sent: Thursday, May 11, 2017 12:03 PM
To: Bob Monkman <bob.monk...@arm.com<mailto:bob.monk...@arm.com>>; 
onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>
Subject: RE: Proposal: Architecture Subcommittee

Bob,

I propose that it’s open to anyone, regardless of membership level (if any).

Thanks,
Chris

From: Bob Monkman [mailto:bob.monk...@arm.com]
Sent: Thursday, May 11, 2017 11:32 AM
To: Christopher Donley (Chris); 
onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>
Subject: RE: Proposal: Architecture Subcommittee

Chris, TSC,
  Can Silver members put forth a representative to contribute to 
the architecture subcommittee, or will this be only available to TSC members or 
representatives from member companies of a certain level?

  This would seem to be to be a very important step for ONAP, btw. 
Very helpful to the success of this project.
Regards,
Bob

Robert (Bob) Monkman
Networking Software Strategy & Ecosystem Programs
ARM
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490
Skype: robert.monkman

From: onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org> 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Christopher Donley (Chris)
Sent: Thursday, May 11, 2017 10:53 AM
To: onap-ts

Re: [onap-tsc] Proposal: Architecture Subcommittee

[Dhananjay Pavgi]

+1 for Architecture subcommittee.

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

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Gadiyar, Rajesh
Sent: Saturday, May 13, 2017 6:17 AM
To: Alla Goldner <alla.gold...@amdocs.com>; Christopher Donley (Chris) 
<christopher.don...@huawei.com>; SPATSCHECK, OLIVER (OLIVER) 
<spat...@research.att.com>; aayush.bhatna...@ril.com
Cc: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

+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: <onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org>> 
on behalf of Alla Goldner 
<alla.gold...@amdocs.com<mailto:alla.gold...@amdocs.com>>
Date: Friday, May 12, 2017 at 10:46 AM
To: "Christopher Donley (Chris)" 
<christopher.don...@huawei.com<mailto:christopher.don...@huawei.com>>, 
"SPATSCHECK, OLIVER (OLIVER)" 
<spat...@research.att.com<mailto:spat...@research.att.com>>, 
"aayush.bhatna...@ril.com<mailto:aayush.bhatna...@ril.com>" 
<aayush.bhatna...@ril.com<mailto:aayush.bhatna...@ril.com>>
Cc: "onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>" 
<onap-tsc@lists.onap.org<mailto: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:image004.png@01D2CBD0.3A563510]

From: Christopher Donley (Chris) [mailto:christopher.don...@huawei.com]
Sent: Friday, May 12, 2017 8:38 PM
To: SPATSCHECK, OLIVER (OLIVER) 
<spat...@research.att.com<mailto:spat...@research.att.com>>; 
aayush.bhatna...@ril.com<mailto:aayush.bhatna...@ril.com>
Cc: Alla Goldner <alla.gold...@amdocs.com<mailto:alla.gold...@amdocs.com>>; 
Kanagaraj Manickam 
<kanagaraj.manic...@huawei.com<mailto:kanagaraj.manic...@huawei.com>>; 
bob.monk...@arm.com<mailto:bob.monk...@arm.com>; 
onap-tsc@lists.onap.org<mailto: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 

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: <onap-tsc-boun...@lists.onap.org> on behalf of Alla Goldner 
<alla.gold...@amdocs.com>
Date: Friday, May 12, 2017 at 10:46 AM
To: "Christopher Donley (Chris)" <christopher.don...@huawei.com>, "SPATSCHECK, 
OLIVER (OLIVER)" <spat...@research.att.com>, "aayush.bhatna...@ril.com" 
<aayush.bhatna...@ril.com>
Cc: "onap-tsc@lists.onap.org" <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) <spat...@research.att.com>; 
aayush.bhatna...@ril.com
Cc: Alla Goldner <alla.gold...@amdocs.com>; Kanagaraj Manickam 
<kanagaraj.manic...@huawei.com>; 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<mailto:aayush.bhatna...@ril.com>
Cc: GOLDNER, ALLA; Kanagaraj Manickam; 
bob.monk...@arm.com<mailto:bob.monk...@arm.com>; Christopher Donley (Chris); 
onap-tsc@lists.onap.org<mailto: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 rel

Re: [onap-tsc] Proposal: Architecture Subcommittee

[Casem Majd (Cas Majd)]

+1
Keeping the architecture subcommittee open promotes distribution of information 
and is ultimately good for the community.

Cas


From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Christopher Donley (Chris)
Sent: Friday, May 12, 2017 3:26 PM
To: Haiby, Ranny (Nokia - US/San Jose USA); Alla Goldner; SPATSCHECK, OLIVER 
(OLIVER); aayush.bhatna...@ril.com
Cc: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

Ranny,

What’s the saying?  If you want to go fast, go alone; if you want to go far, go 
together

You’re right that there are risks to having an open membership. The alternative 
is to impose restrictions such as the number of participants per company.  
However, that could leave some ideas out of the conversation, and foster 
mistrust in people who are not invited to participate.  My preference is to err 
on the side of openness, and impose limitations down the road if the committee 
becomes unwieldy. I want to set the right note at the beginning that we value 
community input and transparency, and are not making decisions in the 
proverbial smoke-filled room. (Also why I’m proposing this as an advisory body 
and not a decision making body).

My experience is that some people will be more interested in architecture than 
others, and people will self-select.  I expect that we would see a fairly 
stable core group, and others who come and go based on the topic. Yes, in 
OPEN-O, some people opted out.  We regularly had about 30 people attending 
(+/-), compared to 45 or so who showed up on TSC calls and 100+ contributing to 
the codebase.   Generally, about 10 people were active participants.  I don’t 
know how many people from ONAP will want to join - so far, about 10 have 
reached out to me.  I expect we’ll have more step forward if this proposal is 
approved and we have an open call for participation.

You could  have architecture discussions outside of the subcommittee, but it 
becomes difficult for people to know when or where conversations are taking 
place, and many such conversations de facto become private.  I think having a 
defined forum helps build trust in the community.

As with other aspects of open source communities, the architecture subcommittee 
would be contribution-driven.  I expect that the chair would schedule regular 
meetings, solicit contributions for particular topics, and publish an agenda in 
advance.  People who have a contribution or question could schedule a slot on 
the agenda.

Chris

From: Haiby, Ranny (Nokia - US/San Jose USA) [mailto:ranny.ha...@nokia.com]
Sent: Friday, May 12, 2017 11:33 AM
To: Alla Goldner; Christopher Donley (Chris); SPATSCHECK, OLIVER (OLIVER); 
aayush.bhatna...@ril.com
Cc: onap-tsc@lists.onap.org
Subject: RE: [onap-tsc] Proposal: Architecture Subcommittee

Chris,

I am having a hard time figuring out the difference between an architecture 
subcommittee member and a “plain” member of the community. Architectural 
discussions take place in the community on a regular basis and they are open to 
all. With the current definition of the subcommittee I don’t think any member 
of the community will opt-out for participation. I am missing some kind of 
required commitment from subcommittee members. Unless some commitment is 
involved (meeting participations, contributions to documentations, etc.) I 
hardly see how we can have an efficient subcommittee in a community as large as 
ours.

What was your experience in Open-O? What was the size of the subcommittee? Did 
any community member opt-out?

Would love to hear your thought on that matter.

Ranny.


From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Alla Goldner
Sent: Friday, May 12, 2017 10:47 AM
To: Christopher Donley (Chris) <christopher.don...@huawei.com>; SPATSCHECK, 
OLIVER (OLIVER) <spat...@research.att.com>; 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@01D2CB12.A5B18490]

From: Christopher Donley (Chris) [mailto:christopher.don...@huawei.com]
Sent: Friday, May 12, 2017 8:38 PM
To: SPATSCHECK, OLIVER (OLIVER) 
<spat...@research.att.com<mailto:spat...@research.att.com>>; 
aayush.bhatna...@ril.

Re: [onap-tsc] Proposal: Architecture Subcommittee

[Christopher Donley (Chris)]

Ranny,

What’s the saying?  If you want to go fast, go alone; if you want to go far, go 
together

You’re right that there are risks to having an open membership. The alternative 
is to impose restrictions such as the number of participants per company.  
However, that could leave some ideas out of the conversation, and foster 
mistrust in people who are not invited to participate.  My preference is to err 
on the side of openness, and impose limitations down the road if the committee 
becomes unwieldy. I want to set the right note at the beginning that we value 
community input and transparency, and are not making decisions in the 
proverbial smoke-filled room. (Also why I’m proposing this as an advisory body 
and not a decision making body).

My experience is that some people will be more interested in architecture than 
others, and people will self-select.  I expect that we would see a fairly 
stable core group, and others who come and go based on the topic. Yes, in 
OPEN-O, some people opted out.  We regularly had about 30 people attending 
(+/-), compared to 45 or so who showed up on TSC calls and 100+ contributing to 
the codebase.   Generally, about 10 people were active participants.  I don’t 
know how many people from ONAP will want to join - so far, about 10 have 
reached out to me.  I expect we’ll have more step forward if this proposal is 
approved and we have an open call for participation.

You could  have architecture discussions outside of the subcommittee, but it 
becomes difficult for people to know when or where conversations are taking 
place, and many such conversations de facto become private.  I think having a 
defined forum helps build trust in the community.

As with other aspects of open source communities, the architecture subcommittee 
would be contribution-driven.  I expect that the chair would schedule regular 
meetings, solicit contributions for particular topics, and publish an agenda in 
advance.  People who have a contribution or question could schedule a slot on 
the agenda.

Chris

From: Haiby, Ranny (Nokia - US/San Jose USA) [mailto:ranny.ha...@nokia.com]
Sent: Friday, May 12, 2017 11:33 AM
To: Alla Goldner; Christopher Donley (Chris); SPATSCHECK, OLIVER (OLIVER); 
aayush.bhatna...@ril.com
Cc: onap-tsc@lists.onap.org
Subject: RE: [onap-tsc] Proposal: Architecture Subcommittee

Chris,

I am having a hard time figuring out the difference between an architecture 
subcommittee member and a “plain” member of the community. Architectural 
discussions take place in the community on a regular basis and they are open to 
all. With the current definition of the subcommittee I don’t think any member 
of the community will opt-out for participation. I am missing some kind of 
required commitment from subcommittee members. Unless some commitment is 
involved (meeting participations, contributions to documentations, etc.) I 
hardly see how we can have an efficient subcommittee in a community as large as 
ours.

What was your experience in Open-O? What was the size of the subcommittee? Did 
any community member opt-out?

Would love to hear your thought on that matter.

Ranny.


From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Alla Goldner
Sent: Friday, May 12, 2017 10:47 AM
To: Christopher Donley (Chris) <christopher.don...@huawei.com>; SPATSCHECK, 
OLIVER (OLIVER) <spat...@research.att.com>; 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@01D2CB12.A5B18490]

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

+1.  The architecture subcommittee should NOT put gating requirements on a

Re: [onap-tsc] Proposal: Architecture Subcommittee

[Haiby, Ranny (Nokia - US/San Jose USA)]

Chris,

I am having a hard time figuring out the difference between an architecture 
subcommittee member and a “plain” member of the community. Architectural 
discussions take place in the community on a regular basis and they are open to 
all. With the current definition of the subcommittee I don’t think any member 
of the community will opt-out for participation. I am missing some kind of 
required commitment from subcommittee members. Unless some commitment is 
involved (meeting participations, contributions to documentations, etc.) I 
hardly see how we can have an efficient subcommittee in a community as large as 
ours.

What was your experience in Open-O? What was the size of the subcommittee? Did 
any community member opt-out?

Would love to hear your thought on that matter.

Ranny.


From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Alla Goldner
Sent: Friday, May 12, 2017 10:47 AM
To: Christopher Donley (Chris) <christopher.don...@huawei.com>; SPATSCHECK, 
OLIVER (OLIVER) <spat...@research.att.com>; 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@01D2CB12.A5B18490]

From: Christopher Donley (Chris) [mailto:christopher.don...@huawei.com]
Sent: Friday, May 12, 2017 8:38 PM
To: SPATSCHECK, OLIVER (OLIVER) 
<spat...@research.att.com<mailto:spat...@research.att.com>>; 
aayush.bhatna...@ril.com<mailto:aayush.bhatna...@ril.com>
Cc: Alla Goldner <alla.gold...@amdocs.com<mailto:alla.gold...@amdocs.com>>; 
Kanagaraj Manickam 
<kanagaraj.manic...@huawei.com<mailto:kanagaraj.manic...@huawei.com>>; 
bob.monk...@arm.com<mailto:bob.monk...@arm.com>; 
onap-tsc@lists.onap.org<mailto: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<mailto:aayush.bhatna...@ril.com>
Cc: GOLDNER, ALLA; Kanagaraj Manickam; 
bob.monk...@arm.com<mailto:bob.monk...@arm.com>; Christopher Donley (Chris); 
onap-tsc@lists.onap.org<mailto: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 

Re: [onap-tsc] Proposal: Architecture Subcommittee

[Christopher Donley (Chris)]

That’s the intention, and one of the reasons I’m proposing a subcommittee, 
rather than a project. If we form this as a project, then decisions would be 
made by the ptl and committers. It also clouds the relationship with other 
projects.

As proposed, the architecture subcommittee would be an advisory body open to 
the community. There are not restrictions on who can participate:
The architecture subcommittee is open to all interested participants, and 
meetings are open.

I believe the subcommittee should be open to the community, whether or not you 
are a member of the TSC or an employee of a member company.

I specifically do NOT believe that this subcommittee should have approval 
power. That should rest with the projects. This group would advise the projects 
and ask questions about how does project A interact with project B, but should 
NOT dictate the answer.

Chris

From: Alla Goldner [mailto:alla.gold...@amdocs.com]
Sent: Thursday, May 11, 2017 9:59 PM
To: Kanagaraj Manickam; Bob Monkman; Christopher Donley (Chris); onap-tsc
Subject: RE: Re: [onap-tsc] Proposal: Architecture Subcommittee

Hi,

According to the Charter,

It is expected that subcommittee membership shall be open to all ONAP 
Contributors; however,
subcommittees may impose restrictions such as the number of participants from a 
single company.
While the desire may be to keep its size and scope limited, each subcommittee 
shall be open to the
ONAP membership. In particular, a Platinum member has the right to appoint its 
TSC representative or
a designate to such a subcommittee. Also, all elected TSC members are eligible 
to join a subcommittee

Thus, I guess, this one will follow the same rules.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D2CB08.6E07D670]

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Kanagaraj Manickam
Sent: Friday, May 12, 2017 2:55 AM
To: Bob Monkman <bob.monk...@arm.com>; Christopher Donley (Chris) 
<christopher.don...@huawei.com>; onap-tsc <onap-tsc@lists.onap.org>
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

IMHO, its really an important and critical team for onap community to ride in 
right path and to maintain the integrity of onap projects as a whole. so would 
like to suggest an idea to systematically handle it as below

- should we consider architecture as a project, which will have ptl, committers 
and any contributors and importantly git repository. so that we formalize the 
approval process of the given change in onap architecture.
-  instead of ppt format, should we  use uml and store it in XML in git 
repository for architecture diagram and use some tool automate the creation of 
architecture diagram from XML
- as part of it, could we bring approval process for nbi and sbi of each 
component of architecture as well.
- in addition, should integration project  automate the validation of nbi and 
sbi of  the project deliverable whether it meets the approved ones by 
architecture committee, who already had committed the nbi and sbi in 
architecture git repository in the appropriate form like one of   yang, 
swagger, etc. interoperability will be taken care by this way.

this end2end process will govern the integrity of onap architecture as a whole.

and i am not sure, but it could bring opportunities to non tsc member as a 
committer in architecture project☺ for bringing his(er) expertise to onap.

your thoughts.
---
Kanagaraj M
From:Bob Monkman
To:Christopher Donley (Chris),onap-tsc,
Date:2017-05-12 00:44:28
Subject:Re: [onap-tsc] Proposal: Architecture Subcommittee

+1  

Robert (Bob) Monkman
Networking Software Strategy & Ecosystem Programs
ARM
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490
Skype: robert.monkman

From: Christopher Donley (Chris) [mailto:christopher.don...@huawei.com]
Sent: Thursday, May 11, 2017 12:03 PM
To: Bob Monkman <bob.monk...@arm.com<mailto:bob.monk...@arm.com>>; 
onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>
Subject: RE: Proposal: Architecture Subcommittee

Bob,

I propose that it’s open to anyone, regardless of membership level (if any).

Thanks,
Chris

From: Bob Monkman [mailto:bob.monk...@arm.com]
Sent: Thursday, May 11, 2017 11:32 AM
To: Christopher Donley (Chris); 
onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>
Subject: RE: Proposal: Architecture Subcommittee

Chris, TSC,
  Can Silver members put forth a representative to contribute to 
the architecture subcommittee, or will this be only available to TSC members or 
representatives from member companies of a certain level?

  This would seem to be to be a very important step for ONAP, btw. 
Very helpful to the success of this project.
Regards,
Bob

Robert (Bob) Monkman
Networking Software Strategy & Ecosystem Programs
ARM
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490
Skype: robert.monkman

Fro

Re: [onap-tsc] Proposal: Architecture Subcommittee

[SPATSCHECK, OLIVER (OLIVER)]

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<mailto:aayush.bhatna...@ril.com> wrote:

+1 for the subcommittee formation.

Additional proposal on the deliverables of the architectural subcommittee -

- Create the deployment architecture for ONAP especially for multi-DC VNF 
orchestration. This aspect is important as ONAP components such as the DCAE 
follow an edge-lake architecture which becomes relevant only when we visualize 
a multi-site deployment.

- Define the architectural principles of disaster recovery (DR) orchestrated by 
the MSO and Policy Engine for VNFs.
​

Regards

Aayush

From: onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org> 
<onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org>> on 
behalf of Alla Goldner <alla.gold...@amdocs.com<mailto:alla.gold...@amdocs.com>>
Sent: Friday, May 12, 2017 10:29 AM
To: Kanagaraj Manickam; Bob Monkman; Christopher Donley (Chris); onap-tsc
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

Hi,

According to the Charter,

It is expected that subcommittee membership shall be open to all ONAP 
Contributors; however,
subcommittees may impose restrictions such as the number of participants from a 
single company.
While the desire may be to keep its size and scope limited, each subcommittee 
shall be open to the
ONAP membership. In particular, a Platinum member has the right to appoint its 
TSC representative or
a designate to such a subcommittee. Also, all elected TSC members are eligible 
to join a subcommittee

Thus, I guess, this one will follow the same rules.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology




From: onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org> 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Kanagaraj Manickam
Sent: Friday, May 12, 2017 2:55 AM
To: Bob Monkman <bob.monk...@arm.com<mailto:bob.monk...@arm.com>>; Christopher 
Donley (Chris) 
<christopher.don...@huawei.com<mailto:christopher.don...@huawei.com>>; onap-tsc 
<onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>>
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

IMHO, its really an important and critical team for onap community to ride in 
right path and to maintain the integrity of onap projects as a whole. so would 
like to suggest an idea to systematically handle it as below

- should we consider architecture as a project, which will have ptl, committers 
and any contributors and importantly git repository. so that we formalize the 
approval process of the given change in onap architecture.
-  instead of ppt format, should we  use uml and store it in XML in git 
repository for architecture diagram and use some tool automate the creation of 
architecture diagram from XML
- as part of it, could we bring approval process for nbi and sbi of each 
component of architecture as well.
- in addition, should integration project  automate the validation of nbi and 
sbi of  the project deliverable whether it meets the approved ones by 
architecture committee, who already had committed the nbi and sbi in 
architecture git repository in the appropriate form like one of   yang, 
swagger, etc. interoperability will be taken care by this way.

this end2end process will govern the integrity of onap architecture as a whole.

and i am not sure, but it could bring opportunities to non tsc member as a 
committer in architecture project☺ for bringing his(er) expertise to onap.

your thoughts.
---
Kanagaraj M
From:Bob Monkman
To:Christopher Donley (Chris),onap-tsc,
Date:2017-05-12 00:44:28
Subject:Re: [onap-tsc] Proposal: Architecture Subcommittee

+1  

Robert (Bob) Monkman
Networking Software Strategy & Ecosystem Programs
ARM
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490
Skype: robert.monkman

From: Christopher Donley (Chris) [mailto:christopher.don...@huawei.com]
Sent: Thursday, May 11, 2017 12:03 PM
To: Bob Monkman <bob.monk...@arm.com<mailto:bob.monk...@arm.com>>; 
onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>
Subject: RE: Proposal: Architecture Subcommittee

Bob,

I propose 

Re: [onap-tsc] Proposal: Architecture Subcommittee

[Aayush.Bhatnagar]

+1 for the subcommittee formation.


Additional proposal on the deliverables of the architectural subcommittee -


- Create the deployment architecture for ONAP especially for multi-DC VNF 
orchestration. This aspect is important as ONAP components such as the DCAE 
follow an edge-lake architecture which becomes relevant only when we visualize 
a multi-site deployment.


- Define the architectural principles of disaster recovery (DR) orchestrated by 
the MSO and Policy Engine for VNFs.

​


Regards


Aayush


From: onap-tsc-boun...@lists.onap.org <onap-tsc-boun...@lists.onap.org> on 
behalf of Alla Goldner <alla.gold...@amdocs.com>
Sent: Friday, May 12, 2017 10:29 AM
To: Kanagaraj Manickam; Bob Monkman; Christopher Donley (Chris); onap-tsc
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

Hi,

According to the Charter,

It is expected that subcommittee membership shall be open to all ONAP 
Contributors; however,
subcommittees may impose restrictions such as the number of participants from a 
single company.
While the desire may be to keep its size and scope limited, each subcommittee 
shall be open to the
ONAP membership. In particular, a Platinum member has the right to appoint its 
TSC representative or
a designate to such a subcommittee. Also, all elected TSC members are eligible 
to join a subcommittee

Thus, I guess, this one will follow the same rules.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D2CAF5.A9A66BA0]

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Kanagaraj Manickam
Sent: Friday, May 12, 2017 2:55 AM
To: Bob Monkman <bob.monk...@arm.com>; Christopher Donley (Chris) 
<christopher.don...@huawei.com>; onap-tsc <onap-tsc@lists.onap.org>
Subject: Re: [onap-tsc] Proposal: Architecture Subcommittee

IMHO, its really an important and critical team for onap community to ride in 
right path and to maintain the integrity of onap projects as a whole. so would 
like to suggest an idea to systematically handle it as below

- should we consider architecture as a project, which will have ptl, committers 
and any contributors and importantly git repository. so that we formalize the 
approval process of the given change in onap architecture.
-  instead of ppt format, should we  use uml and store it in XML in git 
repository for architecture diagram and use some tool automate the creation of 
architecture diagram from XML
- as part of it, could we bring approval process for nbi and sbi of each 
component of architecture as well.
- in addition, should integration project  automate the validation of nbi and 
sbi of  the project deliverable whether it meets the approved ones by 
architecture committee, who already had committed the nbi and sbi in 
architecture git repository in the appropriate form like one of   yang, 
swagger, etc. interoperability will be taken care by this way.

this end2end process will govern the integrity of onap architecture as a whole.

and i am not sure, but it could bring opportunities to non tsc member as a 
committer in architecture project☺ for bringing his(er) expertise to onap.

your thoughts.
---
Kanagaraj M
From:Bob Monkman
To:Christopher Donley (Chris),onap-tsc,
Date:2017-05-12 00:44:28
Subject:Re: [onap-tsc] Proposal: Architecture Subcommittee

+1  

Robert (Bob) Monkman
Networking Software Strategy & Ecosystem Programs
ARM
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490
Skype: robert.monkman

From: Christopher Donley (Chris) [mailto:christopher.don...@huawei.com]
Sent: Thursday, May 11, 2017 12:03 PM
To: Bob Monkman <bob.monk...@arm.com<mailto:bob.monk...@arm.com>>; 
onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>
Subject: RE: Proposal: Architecture Subcommittee

Bob,

I propose that it’s open to anyone, regardless of membership level (if any).

Thanks,
Chris

From: Bob Monkman [mailto:bob.monk...@arm.com]
Sent: Thursday, May 11, 2017 11:32 AM
To: Christopher Donley (Chris); 
onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>
Subject: RE: Proposal: Architecture Subcommittee

Chris, TSC,
  Can Silver members put forth a representative to contribute to 
the architecture subcommittee, or will this be only available to TSC members or 
representatives from member companies of a certain level?

  This would seem to be to be a very important step for ONAP, btw. 
Very helpful to the success of this project.
Regards,
Bob

Robert (Bob) Monkman
Networking Software Strategy & Ecosystem Programs
ARM
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490
Skype: robert.monkman

From: onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org> 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Christopher Donley (Chris)
Sent: Thursday, May 11, 2017 10:53 AM
To: onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org&

Re: [onap-tsc] Proposal: Architecture Subcommittee

[Kanagaraj Manickam]

IMHO, its really an important and critical team for onap community to ride in 
right path and to maintain the integrity of onap projects as a whole. so would 
like to suggest an idea to systematically handle it as below

- should we consider architecture as a project, which will have ptl, committers 
and any contributors and importantly git repository. so that we formalize the 
approval process of the given change in onap architecture.
-  instead of ppt format, should we  use uml and store it in XML in git 
repository for architecture diagram and use some tool automate the creation of 
architecture diagram from XML
- as part of it, could we bring approval process for nbi and sbi of each 
component of architecture as well.
- in addition, should integration project  automate the validation of nbi and 
sbi of  the project deliverable whether it meets the approved ones by 
architecture committee, who already had committed the nbi and sbi in 
architecture git repository in the appropriate form like one of   yang, 
swagger, etc. interoperability will be taken care by this way.

this end2end process will govern the integrity of onap architecture as a whole.

and i am not sure, but it could bring opportunities to non tsc member as a 
committer in architecture project☺ for bringing his(er) expertise to onap.

your thoughts.
---
Kanagaraj M
From:Bob Monkman
To:Christopher Donley (Chris),onap-tsc,
Date:2017-05-12 00:44:28
Subject:Re: [onap-tsc] Proposal: Architecture Subcommittee

+1  

Robert (Bob) Monkman
Networking Software Strategy & Ecosystem Programs
ARM
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490
Skype: robert.monkman

From: Christopher Donley (Chris) [mailto:christopher.don...@huawei.com]
Sent: Thursday, May 11, 2017 12:03 PM
To: Bob Monkman ; onap-tsc@lists.onap.org
Subject: RE: Proposal: Architecture Subcommittee

Bob,

I propose that it’s open to anyone, regardless of membership level (if any).

Thanks,
Chris

From: Bob Monkman [mailto:bob.monk...@arm.com]
Sent: Thursday, May 11, 2017 11:32 AM
To: Christopher Donley (Chris); 
onap-tsc@lists.onap.org
Subject: RE: Proposal: Architecture Subcommittee

Chris, TSC,
  Can Silver members put forth a representative to contribute to 
the architecture subcommittee, or will this be only available to TSC members or 
representatives from member companies of a certain level?

  This would seem to be to be a very important step for ONAP, btw. 
Very helpful to the success of this project.
Regards,
Bob

Robert (Bob) Monkman
Networking Software Strategy & Ecosystem Programs
ARM
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490
Skype: robert.monkman

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Christopher Donley (Chris)
Sent: Thursday, May 11, 2017 10:53 AM
To: onap-tsc@lists.onap.org
Subject: [onap-tsc] Proposal: Architecture Subcommittee

Dear TSC,
I'd like to propose the formation of an architecture subcommittee to develop 
and maintain a functional architecture for ONAP.

Please see the details below.

Chris

• TSC subcommittee name:
Architecture Subcommittee (ARC)

• TSC subcommittee purpose:
The architecture subcommittee is responsible for developing and maintaining a 
functional ONAP architecture. This functional architecture helps inform 
relationships and interaction between functional modules, which may include 
high level information flows between the modules supporting the use case(s) 
driving each release. It also helps the community with project proposals by 
clarifying the new project relationship with existing components.
The architecture subcommittee will not make decisions regarding internal 
functioning of projects.

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 architecture subcommittee operates on a rough consensus basis.  If the 
subcommittee is unable to reach consensus on what advice to offer, the 
subcommittee will refer the matter to the TSC or inform the project that advice 
cannot be rendered.

The architecture subcommittee will consult with Projects to help drive 
alignment between components and with the functional architecture.

• TSC subcommittee expected deliverables:
The architecture subcommittee will develop and maintain a functional 
architecture diagram and any explanatory material.

Periodically, or midway through a release, the architecture subcommittee will 
schedule a walk-through with each project to understand API interactions 
between components.

• TSC subcommittee starting participants:
The architecture subcommittee is open to all interested participants, and 
meetings are open.
IMPORTANT NOTICE: The contents of this email and any 

Re: [onap-tsc] Proposal: Architecture Subcommittee

[Bob Monkman]

+1  

Robert (Bob) Monkman
Networking Software Strategy & Ecosystem Programs
ARM
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490
Skype: robert.monkman

From: Christopher Donley (Chris) [mailto:christopher.don...@huawei.com]
Sent: Thursday, May 11, 2017 12:03 PM
To: Bob Monkman ; onap-tsc@lists.onap.org
Subject: RE: Proposal: Architecture Subcommittee

Bob,

I propose that it’s open to anyone, regardless of membership level (if any).

Thanks,
Chris

From: Bob Monkman [mailto:bob.monk...@arm.com]
Sent: Thursday, May 11, 2017 11:32 AM
To: Christopher Donley (Chris); 
onap-tsc@lists.onap.org
Subject: RE: Proposal: Architecture Subcommittee

Chris, TSC,
  Can Silver members put forth a representative to contribute to 
the architecture subcommittee, or will this be only available to TSC members or 
representatives from member companies of a certain level?

  This would seem to be to be a very important step for ONAP, btw. 
Very helpful to the success of this project.
Regards,
Bob

Robert (Bob) Monkman
Networking Software Strategy & Ecosystem Programs
ARM
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490
Skype: robert.monkman

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Christopher Donley (Chris)
Sent: Thursday, May 11, 2017 10:53 AM
To: onap-tsc@lists.onap.org
Subject: [onap-tsc] Proposal: Architecture Subcommittee

Dear TSC,
I'd like to propose the formation of an architecture subcommittee to develop 
and maintain a functional architecture for ONAP.

Please see the details below.

Chris

• TSC subcommittee name:
Architecture Subcommittee (ARC)

• TSC subcommittee purpose:
The architecture subcommittee is responsible for developing and maintaining a 
functional ONAP architecture. This functional architecture helps inform 
relationships and interaction between functional modules, which may include 
high level information flows between the modules supporting the use case(s) 
driving each release. It also helps the community with project proposals by 
clarifying the new project relationship with existing components.
The architecture subcommittee will not make decisions regarding internal 
functioning of projects.

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 architecture subcommittee operates on a rough consensus basis.  If the 
subcommittee is unable to reach consensus on what advice to offer, the 
subcommittee will refer the matter to the TSC or inform the project that advice 
cannot be rendered.

The architecture subcommittee will consult with Projects to help drive 
alignment between components and with the functional architecture.

• TSC subcommittee expected deliverables:
The architecture subcommittee will develop and maintain a functional 
architecture diagram and any explanatory material.

Periodically, or midway through a release, the architecture subcommittee will 
schedule a walk-through with each project to understand API interactions 
between components.

• TSC subcommittee starting participants:
The architecture subcommittee is open to all interested participants, and 
meetings are open.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Proposal: Architecture Subcommittee

[Christopher Donley (Chris)]

Bob,

I propose that it's open to anyone, regardless of membership level (if any).

Thanks,
Chris

From: Bob Monkman [mailto:bob.monk...@arm.com]
Sent: Thursday, May 11, 2017 11:32 AM
To: Christopher Donley (Chris); onap-tsc@lists.onap.org
Subject: RE: Proposal: Architecture Subcommittee

Chris, TSC,
  Can Silver members put forth a representative to contribute to 
the architecture subcommittee, or will this be only available to TSC members or 
representatives from member companies of a certain level?

  This would seem to be to be a very important step for ONAP, btw. 
Very helpful to the success of this project.
Regards,
Bob

Robert (Bob) Monkman
Networking Software Strategy & Ecosystem Programs
ARM
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490
Skype: robert.monkman

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Christopher Donley (Chris)
Sent: Thursday, May 11, 2017 10:53 AM
To: onap-tsc@lists.onap.org
Subject: [onap-tsc] Proposal: Architecture Subcommittee

Dear TSC,
I'd like to propose the formation of an architecture subcommittee to develop 
and maintain a functional architecture for ONAP.

Please see the details below.

Chris

* TSC subcommittee name:
Architecture Subcommittee (ARC)

* TSC subcommittee purpose:
The architecture subcommittee is responsible for developing and maintaining a 
functional ONAP architecture. This functional architecture helps inform 
relationships and interaction between functional modules, which may include 
high level information flows between the modules supporting the use case(s) 
driving each release. It also helps the community with project proposals by 
clarifying the new project relationship with existing components.
The architecture subcommittee will not make decisions regarding internal 
functioning of projects.

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 architecture subcommittee operates on a rough consensus basis.  If the 
subcommittee is unable to reach consensus on what advice to offer, the 
subcommittee will refer the matter to the TSC or inform the project that advice 
cannot be rendered.

The architecture subcommittee will consult with Projects to help drive 
alignment between components and with the functional architecture.

* TSC subcommittee expected deliverables:
The architecture subcommittee will develop and maintain a functional 
architecture diagram and any explanatory material.

Periodically, or midway through a release, the architecture subcommittee will 
schedule a walk-through with each project to understand API interactions 
between components.

* TSC subcommittee starting participants:
The architecture subcommittee is open to all interested participants, and 
meetings are open.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] Proposal: Architecture Subcommittee

[Bob Monkman]

Chris, TSC,
  Can Silver members put forth a representative to contribute to 
the architecture subcommittee, or will this be only available to TSC members or 
representatives from member companies of a certain level?

  This would seem to be to be a very important step for ONAP, btw. 
Very helpful to the success of this project.
Regards,
Bob

Robert (Bob) Monkman
Networking Software Strategy & Ecosystem Programs
ARM
150 Rose Orchard Way
San Jose, Ca 95134
M: +1.510.676.5490
Skype: robert.monkman

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Christopher Donley (Chris)
Sent: Thursday, May 11, 2017 10:53 AM
To: onap-tsc@lists.onap.org
Subject: [onap-tsc] Proposal: Architecture Subcommittee

Dear TSC,
I'd like to propose the formation of an architecture subcommittee to develop 
and maintain a functional architecture for ONAP.

Please see the details below.

Chris

* TSC subcommittee name:
Architecture Subcommittee (ARC)

* TSC subcommittee purpose:
The architecture subcommittee is responsible for developing and maintaining a 
functional ONAP architecture. This functional architecture helps inform 
relationships and interaction between functional modules, which may include 
high level information flows between the modules supporting the use case(s) 
driving each release. It also helps the community with project proposals by 
clarifying the new project relationship with existing components.
The architecture subcommittee will not make decisions regarding internal 
functioning of projects.

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 architecture subcommittee operates on a rough consensus basis.  If the 
subcommittee is unable to reach consensus on what advice to offer, the 
subcommittee will refer the matter to the TSC or inform the project that advice 
cannot be rendered.

The architecture subcommittee will consult with Projects to help drive 
alignment between components and with the functional architecture.

* TSC subcommittee expected deliverables:
The architecture subcommittee will develop and maintain a functional 
architecture diagram and any explanatory material.

Periodically, or midway through a release, the architecture subcommittee will 
schedule a walk-through with each project to understand API interactions 
between components.

* TSC subcommittee starting participants:
The architecture subcommittee is open to all interested participants, and 
meetings are open.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc