I am moving this conversation out of onap-tsc-vote (bcc’d) and into onap-tsc.
onap-tsc-vote should not be used for discussions.

Best Regards, 
-kenny

> On Mar 21, 2018, at 9:30 AM, <[email protected]> 
> <[email protected]> wrote:
> 
> Can I have a clarification on
> Update APIs referenced to ETSI SOL003 and SOL005 ?
>  
>  
> De : Christopher Donley (Chris) [mailto:[email protected] 
> <mailto:[email protected]>] 
> Envoyé : mercredi 21 mars 2018 17:17
> À : CHAWKI Jamil IMT/OLN; Kenny Paul; [email protected] 
> <mailto:[email protected]>
> Objet : Re: [onap-tsc-vote] ONAP Beijing Architecture Approval (ends 5PM 
> Pacific, March 20)
>  
> Jamil,
>  
> Yan documented it here: 
> https://wiki.onap.org/display/DW/VF-C+R2+Architecture+Review 
> <https://wiki.onap.org/display/DW/VF-C+R2+Architecture+Review>.  Also, here’s 
> a link to the recording: zoom_0.mp4 
> <https://wiki.onap.org/download/attachments/25440127/zoom_0.mp4?version=2&modificationDate=1520617721000&api=v2>.
>   Yan called out that VF-C aligned its APIs with SOL-003 and SOL-005.  I’m 
> also attaching Yan’s email response.
>  
> When you raised your suggestion in mid-February, Yan and most of the VF-C 
> team was in the middle of the Chinese Spring Festival holiday, and was unable 
> to participate.  I raised the issue with them when they returned, and we 
> continued the discussion both via email and on ARC calls.  There were no 
> further comments following Yan’s email.
>  
> Chris
>  
> From: "[email protected] <mailto:[email protected]>" 
> <[email protected] <mailto:[email protected]>>
> Date: Wednesday, March 21, 2018 at 8:08 AM
> To: Chris Donley <[email protected] 
> <mailto:[email protected]>>, Kenny Paul 
> <[email protected] <mailto:[email protected]>>, 
> "[email protected] <mailto:[email protected]>" 
> <[email protected] <mailto:[email protected]>>
> Subject: RE: [onap-tsc-vote] ONAP Beijing Architecture Approval (ends 5PM 
> Pacific, March 20)
>  
> Chris
> Can I have a clear presentation on this alignment ? which SOL interface will 
> be implemented ?
> To my knowledge during a discussion on this topic in January we have 
> concluded that it will be functionary aligned.
> We need to stop this marketing message and to consider that only VFC is the 
> aligned components with ETSI NFV. The overall architecture is functionally 
> aligned. 
> Jamil
>  
> De : Christopher Donley (Chris) [mailto:[email protected] 
> <mailto:[email protected]>] 
> Envoyé : mercredi 21 mars 2018 16:01
> À : CHAWKI Jamil IMT/OLN; Kenny Paul; [email protected] 
> <mailto:[email protected]>
> Objet : Re: [onap-tsc-vote] ONAP Beijing Architecture Approval (ends 5PM 
> Pacific, March 20)
>  
> Jamil,
>  
> Your proposal was clear.  I shared it with Yan, the PTL of VF-C, on the 
> onap-arc list.  She countered that “ETSI-aligned” was the appropriate 
> terminology. She then explained how VF-C was ETSI-aligned during the M3 ARC 
> review.  We discussed the issue again at the following ARC meeting, and I 
> gave the team two extra days to respond to the email thread. No additional 
> comments were received, so we left the text the same as in the approved 
> Amsterdam version.
>  
> Chris
>  
> From: <[email protected] 
> <mailto:[email protected]>> on behalf of 
> "[email protected] <mailto:[email protected]>" 
> <[email protected] <mailto:[email protected]>>
> Date: Wednesday, March 21, 2018 at 6:35 AM
> To: Kenny Paul <[email protected] 
> <mailto:[email protected]>>, "[email protected] 
> <mailto:[email protected]>" <[email protected] 
> <mailto:[email protected]>>
> Subject: Re: [onap-tsc-vote] ONAP Beijing Architecture Approval (ends 5PM 
> Pacific, March 20)
>  
> Hi
> 
> I have voted -1 as we still have a mistake by considering VFC as aligned with 
> ETSI, I have made a proposal but it was not clear Chris feedback on my 
> proposal to change the VFC note to functionally aligned”  or “inspired.  
> 
> Regards
> 
> Jamil
> 
> 
> On 21 Mar 2018, at 01:31, Kenny Paul <[email protected] 
> <mailto:[email protected]>> wrote:
> 
> (Bcc’d to onap-tsc for Community visibility)
>  
> The proposed ONAP Beijing Architecture v2.0.3 was NOT approved.
>  
>  
> Votes needed to pass: 10
> Votes cast: 10
> Votes in favor: 9
> Votes against: 1
> Abstentions: 9
> 
> Company             Member                        Vote
> AMDOCS             Alla Goldner                  1
> AT&T                            Mazin Gilbert                 1
> Bell Canada          David Sauvageau
> China Mobile                 Lingli Deng          1
> China Telecom     Xiaojun Xie          1
> Cisco                    Frank Brockners
> Cloudify                        Amir Levy
> Ericsson                         Stephen Terrill
> Huawei                          Christopher Donley        1
> IBM                     Jason Hunt           1
> Intel                              Rajesh Gadiyar      
> Nokia                   Ranny Haiby                  
> Orange                           Jamil Chawki                 -1
> Reliance Jio          Aayush Bhatnagar
> Tech Mahindra     Dhananjay Pavgi            1
> Turk Telecom                Cosar Baykal
> VMWare                        Xinhui Li             
> Vodafone                       Susana Sabater      1
> ZTE                               Zhaoxing Meng    1
>  
>  
> For reference:
>  
> Section 3.c of the ONAP Technical Charter
> c. Except as provided in Section 7.c. and 8.a, decisions by vote at a meeting 
> require a majority vote of those in attendance, provided quorum is met. 
> Decisions made by electronic vote without a meeting require a majority vote 
> of all voting members of the TSC.
>  
> Vote thread archive: 
> https://lists.onap.org/pipermail/onap-tsc-vote/2018-March/000441.html 
> <https://lists.onap.org/pipermail/onap-tsc-vote/2018-March/000441.html>
>  
> Best Regards, 
> -kenny
> 
> Kenny Paul, Technical Program Manager, The Linux Foundation
> [email protected] <mailto:[email protected]>, 510.766.5945
> San Francisco Bay Area, Pacific Time Zone
> 
> 
> 
> 
> On Mar 15, 2018, at 11:18 AM, Kenny Paul <[email protected] 
> <mailto:[email protected]>> wrote:
>  
>  
> The TSC approves the ONAP Beijing Architecture v2.0.3 as documented here: 
> Beijing Architecture 
> <https://wiki.onap.org/display/DW/Beijing+Architecture?src=contextnavpagetreemode>
>  
> Please respond with a +1, 0 -1 
>  
>  
>  
> _______________________________________________
> onap-tsc-vote mailing list
> [email protected] <mailto:[email protected]>
> https://lists.onap.org/mailman/listinfo/onap-tsc-vote 
> <https://lists.onap.org/mailman/listinfo/onap-tsc-vote>
> _________________________________________________________________________________________________________________________
>  
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>  
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
> _________________________________________________________________________________________________________________________
>  
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
>  
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.

_______________________________________________
ONAP-TSC mailing list
[email protected]
https://lists.onap.org/mailman/listinfo/onap-tsc

Reply via email to