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.web12.16699.1574136150685351511 for ; Mon, 18 Nov 2019 20:02:31 -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 (m0148663.ppops.net [127.0.0.1]) by mx0a-002e3701.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAJ41NZq017170 for ; Tue, 19 Nov 2019 04:02:29 GMT Received: from g2t2354.austin.hpe.com (g2t2354.austin.hpe.com [15.233.44.27]) by mx0a-002e3701.pphosted.com with ESMTP id 2wc4xh1jrj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 19 Nov 2019 04:02:29 +0000 Received: from G4W10204.americas.hpqcorp.net (g4w10204.houston.hpecorp.net [16.207.82.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by g2t2354.austin.hpe.com (Postfix) with ESMTPS id 8F57E83 for ; Tue, 19 Nov 2019 04:02:28 +0000 (UTC) Received: from G9W9209.americas.hpqcorp.net (2002:10dc:429c::10dc:429c) by G4W10204.americas.hpqcorp.net (2002:10cf:5210::10cf:5210) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 19 Nov 2019 04:02:28 +0000 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (15.241.52.10) by G9W9209.americas.hpqcorp.net (16.220.66.156) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Tue, 19 Nov 2019 04:02:27 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SShTEUm20CIr95d7s9dU/QMr49OAAE69ADNFcvZxuy7RNL5bYws1z7BRVDhoGGC3fzRfQ2NjC6DFef+yKsVB1eHt4886LGxt9rO/+AAOT9E3SzUndA+CjoajAMB5vIxNgWs+SUTQlw3HnfMjRK+HIQnd7GyGaNTlwFBuz8ipCA4pu5D6EtrOs6VyeOSo2gORs/hSQW3HAP9OlCSsF26vx0StlSw+Vz6mBDCcGv2PYOxidxnzxKZs1jwn0voM7f8Uxdvp+35j4OaBqCgR+3nEF0SiAkaJfEcy/EGzKwqFzAryRZiYIrenMAsJsUjyd82yD61Xry8ev1qqJxQ1f6Iexg== 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=KZNe3p/miHFtlMzrpO1w5BM2XxsZ9IecoyzylgwMs+Y=; b=cQ9FBNK0luKoXd6t6LT583cvnbPKjm2Dobg/Oa154JSbWoD/l4oJsjbsYlpI8kc/2LeUqgkrp+7y9Ozv7gsvpkAchP6hXl31PNojbX+elikDVuTGDQGOTaY/mWIJjA6mped0A0WEmwFqX3LQJMncJLp2hik8A4ScVIcyFpEqLtvulhlPqkS7S3lscbVnUhCIFvrZPzG5bxwDGnW3H3GSRaO2lMRDT/YUPcXBtXPtokdnPlSkcXiU3l51zK/9IjBnb3ZjWutp7kJx2fdddwxnCDUXocvj94et6o60sAKDvZ96QkC2YIQDV++J1oj1DKf+BT+tp7Tq0xc24qFYK/szSg== 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 CS1PR8401MB0904.NAMPRD84.PROD.OUTLOOK.COM (10.169.96.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.27; Tue, 19 Nov 2019 04:02:21 +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 04:02:21 +0000 From: "Abner Chang" To: "Rabeda, Maciej" , "devel@edk2.groups.io" , "Wu, Jiaxin" Subject: Re: Which is the proper edk2 package the EFI REST Structure DXE driver should stay with? Thread-Topic: Which is the proper edk2 package the EFI REST Structure DXE driver should stay with? Thread-Index: AdWbBekFnGHFycz5Qx6FKZpWk4uEzQC6XgPAACbJVXA= Date: Tue, 19 Nov 2019 04:02:21 +0000 Message-ID: References: <40FBBD5C52E8B4429773266A45BDCC174C6899E5@IRSMSX104.ger.corp.intel.com> In-Reply-To: <40FBBD5C52E8B4429773266A45BDCC174C6899E5@IRSMSX104.ger.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: a89091f3-cb58-474e-de13-08d76ca5473d x-ms-traffictypediagnostic: CS1PR8401MB0904: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 022649CC2C x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(366004)(346002)(39860400002)(136003)(396003)(376002)(53754006)(199004)(189003)(5660300002)(64756008)(66556008)(52536014)(66476007)(25786009)(9326002)(66446008)(8936002)(81156014)(8676002)(33656002)(81166006)(6436002)(446003)(102836004)(7696005)(76176011)(26005)(55016002)(229853002)(9686003)(54896002)(6306002)(236005)(53546011)(186003)(6246003)(6506007)(74316002)(7736002)(86362001)(486006)(476003)(11346002)(66946007)(76116006)(66574012)(606006)(3846002)(790700001)(110136005)(6116002)(478600001)(256004)(71190400001)(71200400001)(14444005)(5024004)(316002)(14454004)(99286004)(66066001)(76236002)(2906002)(2501003);DIR:OUT;SFP:1102;SCL:1;SRVR:CS1PR8401MB0904;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: 4ekfgjV/dld2JSBfkRc2Q/ks43Dtrd4K0AYCGOnV3u+20YDvxO8jx8ZDlecm0E00iaUditVooa06oBKRWwRw6EnICOPzR67SJZIn9YDrlAgj3xz27hHwRPPfUMVxC0aMhUtlK2t4mmxQZGyWDnSqDP0+USvP6p4WQAD+4Pw5MmAswZtLfRtM0rCqMy+1FgFLkgt/sNBXS+ehh4mXSUiaAzH2GmCGSXWDtGxWWHIAmXdvuQF1JCmyGb/WMZow+MQNisO2ERhs/SLInk8ZuqtGcrW+3CgmbPOS6AMwtAAFqZXR36cSOHZvntODIecTfQMmlLkzm80k3neRzWG5tx0IVAlD8e72X75nIkJpi/rQIX4wolr2S8ZMSiHPYjM2kukCXuLaOt4RebPBXxPKsCIvog2vkkbHwZtQ8fckdE42IBgfsFf6gXTDdOFhhQyipEiL x-ms-exchange-transport-forked: True X-MS-Exchange-CrossTenant-Network-Message-Id: a89091f3-cb58-474e-de13-08d76ca5473d X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2019 04:02:21.6095 (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: rgWR3XN+gCmpB85LDg1YlGKk1qNZ0GUxJ6p8P7kkalEqfX0YAovh2qEtyNBTy4djaj+Lc9/ObSeerldpNNpGWA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CS1PR8401MB0904 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-18_08:2019-11-15,2019-11-18 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 priorityscore=1501 impostorscore=0 suspectscore=0 mlxscore=0 bulkscore=0 mlxlogscore=999 malwarescore=0 adultscore=0 spamscore=0 clxscore=1015 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911190035 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_CS1PR8401MB11920BB535D93933F44E7F48FF4C0CS1PR8401MB1192_" --_000_CS1PR8401MB11920BB535D93933F44E7F48FF4C0CS1PR8401MB1192_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable 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 SW/FW Technologist) ; Wu, Jiaxin 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_CS1PR8401MB11920BB535D93933F44E7F48FF4C0CS1PR8401MB1192_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

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 other 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@i= ntel.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_CS1PR8401MB11920BB535D93933F44E7F48FF4C0CS1PR8401MB1192_--