Re: [CCAMP] Question about identities with multiple bases

"Rob Wilton (rwilton)" <rwilton@cisco.com> Mon, 08 June 2020 17:06 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91ACF3A0DA7; Mon, 8 Jun 2020 10:06:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=jLiGjBEa; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=xjtPjfR4
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBjFpRrW30ds; Mon, 8 Jun 2020 10:06:50 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3A73A0D7F; Mon, 8 Jun 2020 10:06:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12214; q=dns/txt; s=iport; t=1591636010; x=1592845610; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=osK0b7Ypg4w5e4as99A60IR8DL5tmL5iXl6E2097FkE=; b=jLiGjBEa0ZgfcF9xq54FqoILTRTuY3ppc3HK6EjmszFZc7G7f8nshm88 +TMMKGI4Bj37/MRAveAxd2c/pcOxGx0S/nx2MmkOfetS08l/LYEa2+2ql C2DF8aq43/0JnrK+N3HZdokxRAh/Yow6+EcdNcorVp8DI5LpJhddEtcsJ k=;
IronPort-PHdr: =?us-ascii?q?9a23=3AGNm3lhFLsVsNd0piiLOa+p1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401gWbV5nQ7PRChuHK9avnXD9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7Yvna16zgfEQ?= =?us-ascii?q?m5Pg1wdaz5H4fIhJGx0Oa/s5TYfwRPgm+7ZrV/ZBW7pAncrI8Ym4xnf60w0R?= =?us-ascii?q?DO5HBPfrdb?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CgBQCKb95e/4ENJK1dCRwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBQIFKgVIpKQdvWC8sCoQag0YDjUCYUoFCgRADVQsBAQEMAQE?= =?us-ascii?q?jCgIEAQGERAIXgh0CJDgTAgMBAQsBAQUBAQECAQYEbYUuBicMhXIBAQEBAxI?= =?us-ascii?q?REQwBAQcpBwELBAIBCBEEAQEDAiMDAgICMBQBCAgBAQQBCQQFCBMHgwWCSwM?= =?us-ascii?q?uAQMLpWMCgTmIYXaBMoMBAQEFhVcYgg4JgQ4qgmSIToEfGoFBPyZqAUOCHy4?= =?us-ascii?q?+gmcBAYEiDgEIAwcBIwUQDwYMAoJaM4ItjmMBHAaDB4ZUmykKglmIN4sFgm2?= =?us-ascii?q?CfYJoNYhdjH6FUpEDigCQYYMvAgQCBAUCDgEBBYFqIik9cHAVgyQJRxcCDYd?= =?us-ascii?q?tiFMMF4EDAQKCSYpWdDcCBgEHAQEDCXyMUIE1AYEPAQE?=
X-IronPort-AV: E=Sophos;i="5.73,487,1583193600"; d="scan'208";a="503535141"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jun 2020 17:06:46 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 058H6iUq022493 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Jun 2020 17:06:46 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 8 Jun 2020 12:06:38 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 8 Jun 2020 13:06:34 -0400
Received: from NAM04-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 8 Jun 2020 13:06:34 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EoW1VF1QQ6UAIwp0EiiRhfr5kIG7wlrj1VGdyfJnP25JlVuXgAIALtDyR2IygdfyiSOxi8PvFmGz/KQOwen/JnET4zEhW9VC4B9deQs9xji7sn37UZpAye0MxOQP7MmK70/5n54yV+wvp7K38lMAMAFyTlZhW1QVHIdNm3xwT8RBiwwmQOfMNcm5b6BovAh+RP13kgfZLBT88HFfr3MJQTCzLbTgpgKs3CZ7V13kZOAVGIjU5GW8ztqha9sTjnUJDkEuB97rMnlT5jRAoeBCBnXk4yRhj2KArzUMje6A6dqeiqioVUtp7jvUgz6tjhyFJ9bAmzoU0ln/6GXM6wt9nA==
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=osK0b7Ypg4w5e4as99A60IR8DL5tmL5iXl6E2097FkE=; b=LeHRKaNbQRJ/69XeDglRFg8usef6mssPTE/aTxy0G2UxHYln5Fg17UoT8h0wdp43UdJYYPFd/o2EP4P41N/bJkQ405iImBsEuaBaSCUD7yYICjCfmTP2kNYldHz15OhWeQCCrolPIY/CLQ9lSX29aPOfe1sOSJAUuSvdUktUZRcDOzWKJ8PWaRtfSKnIgMetrwWia4w3UM5A4xYoE38Ov/rb4EV5GIGqfCcblCr33PJClzZ+5rVVvC1wTuWv1Xinx8jWU325qQW6vYLSg9DJxauvVctIIRAx8xvh7HE5DxJlXH4KEQNhTcLzEAGqYfHbw/iPHgHCws87i1cjH0B/Ig==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=osK0b7Ypg4w5e4as99A60IR8DL5tmL5iXl6E2097FkE=; b=xjtPjfR4crjKT/Oo91twafcjKJnXluClQxWkhKtrRQbPcs/cszSWyEVJ5/Z/kCQhTNigM/FdY1KuffLhR6ypGDSGHLYEn8ACmOwQkKj4xHxCkgwsz1ct8JPM1oilKuwPdisxuEXgMpcrleqMITVW1m+JvyR5L8EgJXtYf+n9RzM=
Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4679.namprd11.prod.outlook.com (2603:10b6:208:26b::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Mon, 8 Jun 2020 17:06:33 +0000
Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::e9d4:79b5:aef1:be18]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::e9d4:79b5:aef1:be18%5]) with mapi id 15.20.3066.023; Mon, 8 Jun 2020 17:06:33 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: tom petch <ietfc@btconnect.com>, Italo Busi <Italo.Busi@huawei.com>
CC: "draft-ietf-ccamp-l1csm-yang@ietf.org" <draft-ietf-ccamp-l1csm-yang@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>, "draft-ietf-ccamp-layer1-types@ietf.org" <draft-ietf-ccamp-layer1-types@ietf.org>
Thread-Topic: Question about identities with multiple bases
Thread-Index: AdYt/QXkQkytytjGRQiDq8TRiq1jdANKy38BAAjATCA=
Date: Mon, 8 Jun 2020 17:06:33 +0000
Message-ID: <MN2PR11MB43669C01061BFF58EB927F5BB5850@MN2PR11MB4366.namprd11.prod.outlook.com>
References: <c73e49b9141b45e1afaa0b76725141eb@huawei.com> <DBAPR07MB7016CC2892E97DA12094EB61A0860@DBAPR07MB7016.eurprd07.prod.outlook.com>
In-Reply-To: <DBAPR07MB7016CC2892E97DA12094EB61A0860@DBAPR07MB7016.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: btconnect.com; dkim=none (message not signed) header.d=none;btconnect.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [82.15.79.32]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a00a6aa8-6682-4dd8-c591-08d80bce4bed
x-ms-traffictypediagnostic: MN2PR11MB4679:
x-microsoft-antispam-prvs: <MN2PR11MB4679813369ED5FA317C69790B5850@MN2PR11MB4679.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 042857DBB5
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Y5UhEsIvo8BJ+SP8MrJjQQbBGxBp9Ozx3JCpvKIFVE+eD2XGNBMnCcUj8Aem3V450mIN2ea0yitI15DkdZOIDQ6E+1a5kP5ZEvx5pFdFyAV34w3Lww0l1RKBCVLlZLPsoa3PT6/dDGeb6euobb0RqhPbSRQycYIil7yYdbijXg+EcccJNzyUrDwd29k142cFjvdIQE2fhsMRVWqOT7Sn3SI4ooQAkNgxJCsV2ij8ZE5EkMFMopXhhS5yWF0q1NrjNJKwQKUyK6gXIWU2wkcACglBWs/D3Q6Dx/m1AhBFnYNXImSCoM9/Vgac8A86X6QmDmObQ0Jl72eiIh28ul2pw+Z5ab/Vuxt+UNPYeocDma1yddLkm1B8TXLhW9abCDLo21ixOKqI9A5W1W3YOFQ9PDHcg58BRFohVImp1ku5qKllAGpFp9knwTQFsFuxXpT7FIbZL4wngeESKNQBD3sAmg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(376002)(396003)(366004)(346002)(52536014)(15974865002)(26005)(33656002)(5660300002)(186003)(110136005)(966005)(478600001)(6506007)(316002)(76116006)(64756008)(296002)(66476007)(71200400001)(86362001)(66446008)(66556008)(54906003)(53546011)(66946007)(7696005)(2906002)(8936002)(83380400001)(9686003)(55016002)(4326008)(8676002)(473944003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: RVdc7sqcQEaU5G9Da7cmjiTBQqCgP49FNlk1fNDhEp49k5EiwpAU3i9YMI4B36c9prcsf2LttKS/+8IV6bsOHw5v72EDo1ecYXriWhiS/9p7RfPmSWn0+QStIiLxnhrmuFc9mFR3QRak+94QtGzJ1Gc7BDvrc1awrIOBRIp5JAM8CK0GbG54mGQ3OPtXKE+7H9vO4pAwmA7AnYFSy4YZzPkOwX7mrdgpHIktXrIkFaIS5bhyrtzhoKFAjtWG/ZxPcwPYXuYeSuv+Gjo5hpKxGof8OLHWFOzRAopbhv7EotEqtgJZw9MOCrNbXSK2K4b7F285YUpgwPkbWcjC8NYdn7S/lqMWlNMrIK+UExHEGdWauwoDK2XWaKBJFgjDjRVAVznSHSA9tKsF5eWBcHqJcnzh+73WYvK60RKtYSmU80K7/xxJJzXlg47AMOBatCis649YO4q1Nf2PPea3top1+uZjsX2wETpyrTi/uBavQHo=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a00a6aa8-6682-4dd8-c591-08d80bce4bed
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2020 17:06:33.6808 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: CQPzjncQVddHRMqt4o3Id9rl807mcJpwJSJQDMIVxPrq2uHwXy6tNgkKhuwvTFISaHpvCaLZueSFI9Vln6Eq1g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4679
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/gRkuOCxJbdqFnDGeTJL0BDzDrDg>
Subject: Re: [CCAMP] Question about identities with multiple bases
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jun 2020 17:06:53 -0000

Hi,

Apologies for the delayed reply.

Tom, I would be interested if you can provide your feedback on the quirks in the English.  It would be useful to get them fixed/tweaked now rather than later in the process.

Some thoughts of the main question regarding multiple base identities:

I think that you might be using base identities in two different ways here.  One of those seems reasonable, the other, I'm not so sure about.

The first way, that I think is reasonable, is if you want to tag a subset of identities that all derive from a common base as having the same property.
E.g. if you have lots of identities that derive from "client-signal", then it might be reasonable to group a subset of them as also deriving from the "Ethernet" base identity.  In this scenario, the set of identities that derive from "Ethernet" would be a subset of identities that derive from "client-signal".  I have no issues with this approach and have considering using this formulation myself.  

The second way, that I'm not convinced by, is where I think that you are trying to share the same identity in different sets (e.g. client-signal vs coding-func).  In this case, I think that it would be much better to define separate identities, either by prefixing the name of the set in the identity name (to make the names unique), or perhaps more cleanly by putting them in separate YANG source files, where the module name/prefix can be used to use the same textual identity name different scoped names.

Further discussion, perhaps involving the YANG doctors' alias might be helpful.

Thanks,
Rob



-----Original Message-----
From: tom petch <ietfc@btconnect.com> 
Sent: 05 June 2020 12:11
To: Italo Busi <Italo.Busi@huawei.com>om>; Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: draft-ietf-ccamp-l1csm-yang@ietf.org; ccamp@ietf.org; draft-ietf-ccamp-layer1-types@ietf.org
Subject: Re: Question about identities with multiple bases

From: CCAMP <ccamp-bounces@ietf.org> on behalf of Italo Busi <Italo.Busi@huawei.com>
Sent: 19 May 2020 17:49

Hi Rob,

We have discussed an open issue with the ietf-l1csm which is impacting the ietf-layer1-types YANG model, for which we are addressing CCAMP WG LC comments

See slides 3 and 4 of the attached presentation made during the CCAMP WG virtual meeting last week

Since we have not much experience with identities having multiple bases, we would like to get a feedbacks from you about whether the proposed solution would work
<tp>
Italo

I have not seen a response to your question.  I had a look and it seems ok but like you I do not see much of this construct in IETF modules.

So while it may be ok, that does make me wonder; is this approach too complicated?  If you and I are uncertain about it, then what about future users - will they be comfortable with it?  I had to look up which Boolean operator applied with multiple bases!

Separately, having persuaded my obstructionist ESP to let me send an e-mail, I see a number of quirks in the English of layer1-types.  Are you interested in hearing about them? (assuming that my ESP lets me:-)

Tom Petch



You can check initial changes to ETH-1GbE, FICON-4G and STM-1 identities in github:

https://github.com/haomianzheng/IETF-ACTN-YANG-Model/pull/65

Let me report here the key ones:

  identity ETH-1Gb {
    base client-signal;
    description
      "Client signal type of 1GbE";
    reference "RFC7139/ITU-T G.709";
  }

  identity FICON-4G {
    base client-signal;
    description
      "Client signal type of Fibre Connection 4G";
    reference "RFC4328/RFC7139";
  }

  identity ETH-1000X {
    base "coding-func";
    base Ethernet;
    description
      "1000BASE-X PCS clause 36 coding function.";
    reference "MEF63: Subscriber Layer 1 Service Attributes";
  }

  identity STM-1 {
    base client-signal;
    base "coding-func";
    base SDH;
    description
      "STM-1 client signal;
       STM-1 G.707 (N=1) coding function.";
    reference
      "RFC7139/ITU-T G.709
       MEF63: Subscriber Layer 1 Service Attributes";
  }

              leaf client-signal {
                type identityref {
                  base "l1-types:client-signal";
                }
                mandatory true;
                description
                  "The client signal being used at the UNI";
              }

Then ETH-1GbE, FICON-4G and STM-1 would be valid configuration for the client-signa leaf, while ETH-1000X will not be valid

    leaf coding {
      type identityref {
        base "l1-types:coding-func";
      }
      must 'derived-from(../coding, ../protocol)';
      mandatory true;
      description "The coding function being used at the UNI.";
    }

Then:
- ETH-1000X would be valid configuration of the coding leaf, if Ethernet is configured, otherwise it is invalid;
- STM-1 would be valid configuration of the coding leaf, if SDH is configure as protocol, otherwise it is invalid;
- ETH-1GbE and FICON-4G would never be valid configuration of the coding leaf

Before applying these changes to a lot of identities, it would be good to check that our understanding is correct

What do you think?

Thanks in advance

Italo

Italo Busi
Principal Optical Transport Network Research Engineer

[cid:image001.jpg@01D5AC11.9575BB40]
____________________________________________________________________

Huawei Technologies Italia S.r.l.
Address: Centro Direzionale Milano 2, Palazzo Verrocchio, 20090 Segrate (MI)
Tel: +39 345 4721946 - Mobile: Italo.busi@huawei.com<mailto:Italo.busi@huawei.com>

__________________________________________________________________________________
Huawei Technologies Italia S.r.l. is a company registered in Italy at the Company Registration Office of Milan, with registered number 04501190963 and equity capital €3,000,000 fully paid up, whose registered office is in Milan, Via Lorenteggio 240, Tower A, 20147 Milan, Italy. Huawei Technologies Italia S.r.l. is 100% owned by Huawei Technologies Cooperatief U.A.
CONAI Reg. No. cc 12639454 - A.E.E. Registry No. IT10010000006521 - Batteries and Accumulators Registry No. IT12050P00002839.
________________________________________________________________________________________________________________________
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! Thank you.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
PRIVACY NOTICE: Pursuant to Art. 13 of the General Data Protection Regulation 2016/679 (GDPR), Huawei Technologies Italia S.r.l. informs you that the personal data contained in this email will be collected and treated for the acquisition of information preliminary to the conclusion of contracts, for the definition of the contractual relationship, as well as for the fulfillment of legal requirements related to civil, tax and accounting law or any other legal obligation to which Huawei may be subject. Personal data will not be subject to disclosure and spread unless otherwise required by law. Huawei will take appropriate security measures to protect personal data against loss, misuse disclosure or destruction of the information. Personal Data held may be transferred to countries outside the European Union, however Huawei Italia has put in place appropriate safeguards for the transfer of personal data to third countries by adopting the standard data protection clauses of the EU Commission. Personal Data are kept for a period necessary for the fulfillment of contract obligations unless otherwise required by law. You can exercise your rights under Art. 15 and following of the GDPR (i.e. right of access, rectification, erasure, restriction, portability, object) by contacting Huawei at this email address: dataprotection@huawei.com<mailto:dataprotection@huawei.com> or through the following channel: www.huawei.com/en/personal-data-request<http://www.huawei.com/en/personal-data-request>st>. You have also the right to lodge a complaint with the competent supervisory authorities. If you need any further information or have any queries on how Huawei process your personal data, please send an email to our Data Protection Officer at dpo@huawei.com<mailto:dpo@huawei.com>.The Data Controller is Huawei Technologies Italia S.r.l. with registered office in Milan, Via Lorenteggio 240 Tower A, 20147.