From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-002e3701.pphosted.com (mx0a-002e3701.pphosted.com [148.163.147.86]) by mx.groups.io with SMTP id smtpd.web09.18545.1574152713397544274 for ; Tue, 19 Nov 2019 00:38:33 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: hpe.com, ip: 148.163.147.86, mailfrom: prvs=02268f9a8b=abner.chang@hpe.com) Received: from pps.filterd (m0134421.ppops.net [127.0.0.1]) by mx0b-002e3701.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAJ8aUlH026023 for ; Tue, 19 Nov 2019 08:38:32 GMT Received: from g9t5009.houston.hpe.com (g9t5009.houston.hpe.com [15.241.48.73]) by mx0b-002e3701.pphosted.com with ESMTP id 2wby6u5swd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 19 Nov 2019 08:38:32 +0000 Received: from G2W6311.americas.hpqcorp.net (g2w6311.austin.hp.com [16.197.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g9t5009.houston.hpe.com (Postfix) with ESMTPS id 6B3DB94 for ; Tue, 19 Nov 2019 08:38:31 +0000 (UTC) Received: from G9W9210.americas.hpqcorp.net (16.220.66.155) by G2W6311.americas.hpqcorp.net (16.197.64.53) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 19 Nov 2019 08:38:27 +0000 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (15.241.52.12) by G9W9210.americas.hpqcorp.net (16.220.66.155) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Tue, 19 Nov 2019 08:38:27 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Xlzi44lrCeuHwpUvByYgHZHu+9xpSx21K4InsJRAul5OI7GVOPaVZ/lQkLMaP5iav1tzPiWHColNE6HEzVA7LjWUXiE1JS3UJoj8+/csz2Yr/JkLZF1Wf6Rvfyu9jBKeTeY0F1bqqWMfNX+zv9VfexOCY09IMmMpl6Q87TSqwkTE9N4HNZeemoFIG9GmPB/UKRrjzEgk6783P+tjlGr8K4VSycC0vFIz64VK0L0nU7zyUA4SiNaRHzwvDpe7EFemnY98XumbtP9mahZmXpExVYUFBSlHbFJ9oGBKuuVTP+tMSxx+xroTY4WtY7zoADci7rAzODcFWFxwLxTV1VTPkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9wlU46V60CswLPrFEed+aNMYVUr9VP6Exn8TAHv7LC4=; b=FTp+0ZhD2i66/NKieO8FFWILgUPQunCQwL70ZzMWE/P+rACf0Pq9ZyWkkITz3ASZbBNtTxmssgHeK3nMp7J4I6SuNA5W2rNVcZIgdB6C+kXBgGCY3S+5wBJyfqgTXxAYgflq7lpXYMZ15TWkAW7XL1zH0GrQoI3v/BrOshCEDK6Sc0nG8yeGsBKpMjRHrS78haS3ISJsTsIk65F0znKgo05pATn8SSBWfr3qjJyVSSgZdDx1o5h/Ln6XR4YXhgpCO0AozVqQnFoYp2Nm8scOj/HYOxMWLabz1vZPrtCKf3P3fHSMe6u9kZwM60HWDudiu+LGWMnyN9nj/yN0Ds8asQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=hpe.com; dmarc=pass action=none header.from=hpe.com; dkim=pass header.d=hpe.com; arc=none Received: from CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM (10.169.12.151) by CS1PR8401MB0408.NAMPRD84.PROD.OUTLOOK.COM (10.169.96.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.30; Tue, 19 Nov 2019 08:38:25 +0000 Received: from CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM ([fe80::b49a:cecb:54b0:29ac]) by CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM ([fe80::b49a:cecb:54b0:29ac%7]) with mapi id 15.20.2474.015; Tue, 19 Nov 2019 08:38:25 +0000 From: "Abner Chang" To: "Wu, Jiaxin" , "devel@edk2.groups.io" , "Rabeda, Maciej" Subject: Re: [edk2-devel] Which is the proper edk2 package the EFI REST Structure DXE driver should stay with? Thread-Topic: [edk2-devel] Which is the proper edk2 package the EFI REST Structure DXE driver should stay with? Thread-Index: AdWbBekFnGHFycz5Qx6FKZpWk4uEzQC6XgPAACbJVXAACAdxIAACT4oA Date: Tue, 19 Nov 2019 08:38:25 +0000 Message-ID: References: <40FBBD5C52E8B4429773266A45BDCC174C6899E5@IRSMSX104.ger.corp.intel.com> <895558F6EA4E3B41AC93A00D163B727416FA5A4B@SHSMSX107.ccr.corp.intel.com> In-Reply-To: <895558F6EA4E3B41AC93A00D163B727416FA5A4B@SHSMSX107.ccr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [16.242.247.131] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 58647c80-4dde-40b2-b9b4-08d76ccbd822 x-ms-traffictypediagnostic: CS1PR8401MB0408: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 022649CC2C x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(376002)(39860400002)(136003)(396003)(366004)(346002)(199004)(189003)(53754006)(71200400001)(74316002)(486006)(476003)(25786009)(6506007)(14444005)(5024004)(33656002)(5660300002)(2906002)(14454004)(256004)(66574012)(478600001)(3846002)(6436002)(186003)(102836004)(6116002)(54896002)(86362001)(53546011)(11346002)(6306002)(55016002)(6246003)(446003)(71190400001)(66946007)(66446008)(64756008)(66556008)(66476007)(76116006)(9686003)(236005)(110136005)(66066001)(8936002)(7736002)(76176011)(52536014)(2501003)(7696005)(81156014)(8676002)(81166006)(99286004)(26005)(229853002)(790700001)(76236002)(606006)(316002);DIR:OUT;SFP:1102;SCL:1;SRVR:CS1PR8401MB0408;H:CS1PR8401MB1192.NAMPRD84.PROD.OUTLOOK.COM;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1; received-spf: None (protection.outlook.com: hpe.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6Uhk8YFfrt5adVttS+g/l7In1UKDyngvDLbga/rtLRYJkhTCQ4pIGRLS3db9IeoGVhNbWUPsIam7DbEw4fD9LWnNaURXgmur56xK33/svpshC/or4r1e1pyGAF37rfvPqqJZhNEezI3VJlmVgq7fpMpM1eVO+i6HLB06h0jmuvTG0VihRZ36wil4RtD6TAHciWPZTsTEI355pBkrcELaRQfS19pt8EpGAjl4J+MaXSBCGuLKnTfOg13rUvYyrvvKeGWCQu/9/nkVqJNUG+/fqG42MKNo1R4izvd0Vjnpsu9zwMU7KCENsLVLSAAX8zEDjwp0dWbCNwF1PgFOM8TUNvair+Ug2vj/liObTCyESncqkOjqiUaRdH3gVrSz9jKE95H8WxgJTpkbNzRyZVabG89ogp//3LhpFH8EZWSr2g7blDFeY662wcgSvdYt6Hck x-ms-exchange-transport-forked: True X-MS-Exchange-CrossTenant-Network-Message-Id: 58647c80-4dde-40b2-b9b4-08d76ccbd822 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2019 08:38:25.4920 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: J/eJZ3iSRL9L8klbA2kYVCWPuV1fRp+XLd8rfV3xc0SXM6aih0nXG+AF2b2dQlSMohl4jxcRheNrq8ovpqeoaQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CS1PR8401MB0408 X-OriginatorOrg: hpe.com X-Proofpoint-UnRewURL: 10 URL's were un-rewritten MIME-Version: 1.0 X-HPE-SCL: -1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-19_01:2019-11-15,2019-11-19 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 phishscore=0 mlxscore=0 bulkscore=0 mlxlogscore=999 suspectscore=0 priorityscore=1501 malwarescore=0 spamscore=0 impostorscore=0 adultscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911190081 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_CS1PR8401MB119268D5E4B7DD4B97CC411EFF4C0CS1PR8401MB1192_" --_000_CS1PR8401MB119268D5E4B7DD4B97CC411EFF4C0CS1PR8401MB1192_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Yes, we do have REST(EX) driver instance for Redfish service under current = RedfishPkg. Redfish REST(EX) driver will stay in RedfishPkg and not moving = to Network because this driver is written for Redfish service. >>> In the future, based on the real usage case in UEFI, we can consider w= hether need to move that driver with the REST(EX) driver to NetworkPkg or n= ot. What do you think? Sure, we can keep EFI REST Structure DXE in RedfishPkg for now. I have no = problem with this at least we have consensus for this. Thanks! Abner From: Wu, Jiaxin [mailto:jiaxin.wu@intel.com] Sent: Tuesday, November 19, 2019 4:16 PM To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist) ; Rabeda, Maciej Subject: RE: [edk2-devel] Which is the proper edk2 package the EFI REST St= ructure DXE driver should stay with? Hi Abner, I just prefer put it with REST(EX) driver. So, how about keep it under Red= fishPkg since the REST driver will still under RedfishPkg (currently)? I kn= ow it's a generic and centralized driver to do the converting, but the fact= of the matter is no other consumer except for UEFI Redfish feature, or do = you have the real other usage cases? In the future, based on the real usage case in UEFI, we can consider wheth= er need to move that driver with the REST(EX) driver to NetworkPkg or not. = What do you think? Thanks, Jiaxin From: devel@edk2.groups.io > On Behalf Of Abner Chang Sent: Tuesday, November 19, 2019 12:02 PM To: Rabeda, Maciej >; devel@edk2.groups.io; Wu, Jiaxin > Subject: Re: [edk2-devel] Which is the proper edk2 package the EFI REST St= ructure DXE driver should stay with? Hi Maciej, EFI REST Structure driver is designed as a generic and centralized driver = for REST JSON payload to C structure convertors. Redfish payload in JSON fo= rmat is one of the REST services which consumes EFI REST Structure driver f= or registering the convertor, others services could be AWS or Openstack. Th= is driver is not really designed for Redfish only, although I believe Redfi= sh is the only one to use this protocol. Actually, this driver mainly deals= with the payload, less relationship to the specific REST service or underl= ying transports although HTTP is used for carrying REST payload in the most= of cases. In responding to your questions, >>>Is REST in UEFI going to be HTTP-based or is it planned to be tied to d= rivers outside of NetworkPkg? This driver doesn't depends on transport layer. >>>Is REST currently consumed only by Redfish or is going to be extensivel= y used outside that package? Yes, this driver is current consumed by Redfish JSON to C structure driver= s. But as mentioned above, this driver is not only for Redfish, could be ex= tensively used by other REST services. >>> I believe that, by default, REST driver build will be controlled by a = separate flag and disabled by default... Yes, this driver is not necessary to be built as default. this driver coul= d be pulled into build with the convertors according to the demand of platf= orm. Actually, neither RedfishPkg nor NetworkPkg are ideal packages to own EFI = REST Structure driver IMO. My thought to put this driver in NetworkPkg is j= ust because "REST" related driver is mentioned in Network Protocols in UEFI= spec. Which I feel more comfortable than put this driver in RedfishPkg. However, I don't have preference on this. We can keep this driver in Redfi= shPkg if one or more people think we should let this driver goes to Redfish= Pkg :). Yep, what's your opinion Jiaxin? Thanks Abner From: Rabeda, Maciej [mailto:maciej.rabeda@intel.com] Sent: Monday, November 18, 2019 5:52 PM To: devel@edk2.groups.io; Chang, Abner (HPS S= W/FW Technologist) >; Wu, J= iaxin > Subject: RE: Which is the proper edk2 package the EFI REST Structure DXE d= river should stay with? Hi Abner, REST as a more generic network API and could possibly be placed in Network= Pkg. My concerns are: Is REST in UEFI going to be HTTP-based or is it planned to be tied to driv= ers outside of NetworkPkg? If it is going to be more generic, I do not think that it = is a good idea to tie it with other network drivers within NetworkPkg Is REST currently consumed only by Redfish or is going to be extensively u= sed outside that package? Even if it is HTTP-based, question of maintenance arises. If Redfish is th= e only consumer of REST API, I would leave it within RedfishPkg so that Red= fish+REST could be treated as a whole solution by the package maintainer. In case REST is planned to be used outside of RedfishPkg, it could be adde= d to NetworkPkg with some extra work. I believe that, by default, REST driver build will be controlled by a sepa= rate flag and disabled by default (no need for it in regular network stack = use cases like PXE/iSCSI/HTTP boot). Additionally, if REST DXE build is requested, one would have to ensure tha= t dependant drivers like HttpDxe will be included and built within NetworkP= kg and outside of it (by consumers like OvmfPkg). For example: there is a preprocessor mechanism used in NetworkPkg/NetworkD= efines.dsc.inc to throw a compiler error in case TLS is not included if HTT= PS support is requested. Jiaxin, What do you think? Thanks, Maciej From: devel@edk2.groups.io > On Behalf Of Abner Chang Sent: Thursday, November 14, 2019 17:10 To: devel@edk2.groups.io Subject: [edk2-devel] Which is the proper edk2 package the EFI REST Struct= ure DXE driver should stay with? Hi all, I would like to get your suggestion with regard to the suitable edk2 packa= ge for EFI REST Structure DXE driver. We have POC code for this protocol (r= efer to UEFI spec 2.8, section 29.7.3) and currently this driver is impleme= nted in RedfishPkg. However, this driver is not for Redfish only. Either Ne= towrkPkg or MdeModulePkg is better than RedfishPkg. I prefer to put this dr= iver in NetworkPkg, but it's fine to me if you have other opinions. Thanks Abner --------------------------------------------------------------------- Intel Technology Poland sp. z o.o. ul. S=B3owackiego 173 | 80-298 Gda=F1sk | S=B1d Rejonowy Gda=F1sk P=F3=B3n= oc | VII Wydzia=B3 Gospodarczy Krajowego Rejestru S=B1dowego - KRS 101882 |= NIP 957-07-52-316 | Kapita=B3 zak=B3adowy 200.000 PLN. Ta wiadomo=B6=E6 wraz z za=B3=B1cznikami jest przeznaczona dla okre=B6lone= go adresata i mo=BFe zawiera=E6 informacje poufne. W razie przypadkowego ot= rzymania tej wiadomo=B6ci, prosimy o powiadomienie nadawcy oraz trwa=B3e je= j usuni=EAcie; jakiekolwiek przegl=B1danie lub rozpowszechnianie jest zabro= nione. This e-mail and any attachments may contain confidential material for the = sole use of the intended recipient(s). If you are not the intended recipien= t, please contact the sender and delete all copies; any review or distribut= ion by others is strictly prohibited. --_000_CS1PR8401MB119268D5E4B7DD4B97CC411EFF4C0CS1PR8401MB1192_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Yes, we do have REST(= EX) driver instance for Redfish service under current RedfishPkg. Redfish R= EST(EX) driver will stay in RedfishPkg and not moving to Network because th= is driver is written for Redfish service.

 

>>> In the future, based on the real usage= case in UEFI, we can consider whether need to move that driver with the RE= ST(EX) driver to NetworkPkg or not. What do you think?

Sure, we can keep EFI REST Structure DXE in RedfishPkg for = now. I have no problem with this at least we have consensus for this.

 

Thanks!

Abner

 

From: Wu, Jiaxin [mailto:jiaxin.wu@intel.com= ]
Sent: Tuesday, November 19, 2019 4:16 PM
To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist) <= ;abner.chang@hpe.com>; Rabeda, Maciej <maciej.rabeda@intel.com> Subject: RE: [edk2-devel] Which is the proper edk2 package the EFI = REST Structure DXE driver should stay with?

 

Hi Abner,

 

I just prefer put it with REST(EX) driver. So, how = about keep it under RedfishPkg since the REST driver will still under Redfi= shPkg (currently)? I know it’s a generic and centralized driver to do= the converting, but the fact of the matter is no other consumer except for UEFI Redfish feature, or do you have the = real other usage cases?

 

In the future, based on the real usage case in UEFI= , we can consider whether need to move that driver with the REST(EX) driver= to NetworkPkg or not. What do you think?

 

Thanks,

Jiaxin

 

 

 

 

From: devel@edk2.groups.io <devel= @edk2.groups.io> On Behalf Of Abner Chang
Sent: Tuesday, November 19, 2019 12:02 PM
To: Rabeda, Maciej <m= aciej.rabeda@intel.com>; devel@edk2.groups.io; Wu, Jiax= in <jiaxin.wu@intel.com> Subject: Re: [edk2-devel] Which is the proper edk2 package the EFI = REST Structure DXE driver should stay with?

 

Hi Maciej,=

EFI REST Structure dr= iver is designed as a generic and centralized driver for REST JSON payload = to C structure convertors. Redfish payload in JSON format is one of the RES= T services which consumes EFI REST Structure driver for registering the convertor, others services could be AWS or Ope= nstack. This driver is not really designed for Redfish only, although I bel= ieve Redfish is the only one to use this protocol. Actually, this driver ma= inly deals with the payload, less relationship to the specific REST service or underlying transports althou= gh HTTP is used for carrying REST payload in the most of cases.<= /span>

 

In responding to your= questions,

>>>Is REST in UEFI going to be HTTP-based = or is it planned to be tied to drivers outside of NetworkPkg?

This driver doesnR= 17;t depends on transport layer.

 

>>>Is REST currently consumed only by Redf= ish or is going to be extensively used outside that package?

Yes, this driver is c= urrent consumed by Redfish JSON to C structure drivers. But as mentioned ab= ove, this driver is not only for Redfish, could be extensively used by othe= r REST services.

 

>>> I believe that, by default, REST drive= r build will be controlled by a separate flag and disabled by default…= ;

Yes, this driver is n= ot necessary to be built as default. this driver could be pulled into build= with the convertors according to the demand of platform.=

 

Actually, neither Red= fishPkg nor NetworkPkg are ideal packages to own EFI REST Structure driver = IMO. My thought to put this driver in NetworkPkg is just because “RES= T” related driver is mentioned in Network Protocols in UEFI spec. Which I feel more comfortable than put this driver in Redfi= shPkg.

However, I don’= t have preference on this. We can keep this driver in RedfishPkg if one or = more people think we should let this driver goes to RedfishPkg J.

 

Yep, what’s you= r opinion Jiaxin?

 

Thanks

Abner

 

 

From: Rabeda, Maciej [mailto:maciej.rabeda@intel.com]
Sent: Monday, November 18, 2019 5:52 PM
To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>; Wu, Jiaxin <jiaxin.wu@intel.com>
Subject: RE: Which is the proper edk2 package the EFI REST Structur= e DXE driver should stay with?

 

Hi Abner,

 

REST as a more generic network API and could possib= ly be placed in NetworkPkg.

My concerns are:

Is REST in UEFI going to be HTTP-based or is it pla= nned to be tied to drivers outside of NetworkPkg?

        &nb= sp;       If it is going to be more generic, = I do not think that it is a good idea to tie it with other network drivers = within NetworkPkg

 

Is REST currently consumed only by Redfish or is go= ing to be extensively used outside that package?

Even if it is HTTP-based= , question of maintenance arises. If Redfish is the only consumer of REST A= PI, I would leave it within RedfishPkg so that Redfish+REST could be tr= eated as a whole solution by the package maintainer.

 

In case REST is planned = to be used outside of RedfishPkg, it could be added to NetworkPkg with some= extra work.

I believe that, by defau= lt, REST driver build will be controlled by a separate flag and disabled by= default (no need for it in regular network stack use cases like PXE/iSCSI/= HTTP boot).

Additionally, if REST DX= E build is requested, one would have to ensure that dependant drivers like = HttpDxe will be included and built within NetworkPkg and outside of it (by = consumers like OvmfPkg).

For example: there is a = preprocessor mechanism used in NetworkPkg/NetworkDefines.dsc.inc to throw a= compiler error in case TLS is not included if HTTPS support is requested.<= o:p>

 

Jiaxin,

 

What do you think?

 

Thanks,

Maciej

 

<Please disregard the legal disclaimer below. I&= #8217;m working on it.>

 

 

Hi all,

I would like to get your suggestion with regard to = the suitable edk2 package for EFI REST Structure DXE driver. We have POC co= de for this protocol (refer to UEFI spec 2.8, section 29.7.3) and currently= this driver is implemented in RedfishPkg. However, this driver is not for Redfish only. Either NetowrkPkg or MdeMod= ulePkg is better than RedfishPkg. I prefer to put this driver in NetworkPkg= , but it’s fine to me if you have other opinions.

 

Thanks

Abner

--------------------------------------------------------------------- Intel Technology Poland sp. z o.o.
ul. S=B3owackiego 173 | 80-298 Gda=F1sk | S= =B1d Rejonowy Gda=F1sk P=F3=B3noc | VII Wydzia=B3 Gospodarczy Krajowego Re= jestru S=B1dowego - KRS 101882 | NIP 957-07-52-316 | Kapita=B3 zak=B3adowy 200.000 PLN.

Ta wiadomo= =B6=E6 wraz z za=B3=B1cznikami jest przeznaczona dla okre=B6lonego adresat= a i mo=BFe zawiera=E6 informacje poufne. W razie przypadkowego otrzymania t= ej wiadomo=B6ci, prosimy o powiadomienie nadawcy oraz trwa=B3e jej usuni=EAcie; jakiekolwiek przegl=B1danie lub rozpowszechnian= ie jest zabronione.
This e-mail and any attachments may contain confidential material for the = sole use of the intended recipient(s). If you are not the intended recipien= t, please contact the sender and delete all copies; any review or distribut= ion by others is strictly prohibited.

 

--_000_CS1PR8401MB119268D5E4B7DD4B97CC411EFF4C0CS1PR8401MB1192_--