From nobody Wed Sep 15 05:51:51 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14D93A17AA; Wed, 15 Sep 2021 05:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.com 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 GjR3t12dLeUL; Wed, 15 Sep 2021 05:51:23 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 503963A17A8; Wed, 15 Sep 2021 05:51:23 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 18FCilam037459; Wed, 15 Sep 2021 08:51:19 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 3b2udpct16-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Sep 2021 08:51:18 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 18FCpH0B004481; Wed, 15 Sep 2021 08:51:17 -0400 Received: from zlp27130.vci.att.com (zlp27130.vci.att.com [135.66.87.38]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 18FCpEAA004432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 15 Sep 2021 08:51:15 -0400 Received: from zlp27130.vci.att.com (zlp27130.vci.att.com [127.0.0.1]) by zlp27130.vci.att.com (Service) with ESMTP id A7E854009E85; Wed, 15 Sep 2021 12:51:14 +0000 (GMT) Received: from MISOUT7MSGED1AA.ITServices.sbc.com (unknown [135.66.184.195]) by zlp27130.vci.att.com (Service) with ESMTP id 874BF4009E7D; Wed, 15 Sep 2021 12:51:14 +0000 (GMT) Received: from MISOUT7MSGEX2BA.ITServices.sbc.com (135.66.184.217) by MISOUT7MSGED1AA.ITServices.sbc.com (135.66.184.195) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14; Wed, 15 Sep 2021 08:51:14 -0400 Received: from MISOUT7MSGETA03.tmg.ad.att.com (144.160.12.222) by MISOUT7MSGEX2BA.ITServices.sbc.com (135.66.184.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.14 via Frontend Transport; Wed, 15 Sep 2021 08:51:14 -0400 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.47) by edgeso3.exch.att.com (144.160.12.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.14; Wed, 15 Sep 2021 08:51:12 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KAPoszcpWMFSa10+gDGZks0nbjgUhC+gEjQo+mebpQV1xu/atFVdOAKuViGh4AL76Nj22mJ48VQvCmmPAFOO6hUF2DCwc9Dg56ilXVmXqYip3wlE3MPZIgaBfeTe4Fxe5EJhianOC7Ai0k7GSmq2/Kgg9dYMnR8m+xXbEympe+vNKS1irjMscOMyqv/Pferce2M3eXEq45LB99pJvWa0McCI3X7g94rPGZ8ViYinKn1667nfl2gVkHT3YfIRXtxzkw/4O9YSIXe4GR/2xTD/7q5Rrm658N84cdveYYBv9BDtZqzt4TgwXg1NmK0ifY8oIsf17iNmHu4JLhg1Ne2+/g== 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; bh=ogv1kITgApH4detX0BpHCbmBLzPYbVjU4sKmU7r6+So=; b=BBHDFauKKnozap0qxL1cO0qlZRZ5cjoNCzrtIHujjXT/Z2ejn6qRajwVNVflBca52FmAATI0ljDf3DR8wA6xHiQcm+50/cTVVsUT8LFDQQIFe0Hj8n99hg9+Ub9wm0/D/WRaWe87B0vSOxNMYg2Gsj0EZqzm5qJO/dN5reMfyCVhPk5BVoVplymaLTRQczar266T68OxRcJanGXeMAZ2KE9XtCE5HM/5jOXzloNIThUuL37BX/7tGsjXaMkWZesD6k8nl3aa5Y1SFN6d8R5AhcY9OXEsPwkh7xv1WtCa3DEGvvOu8hlnPzO23X8HURDgR5YJU56CdcktVXZZ+xnJcg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ogv1kITgApH4detX0BpHCbmBLzPYbVjU4sKmU7r6+So=; b=VcXAKzX8oLfpTtFLju4yi2fL1tZir60bOQif35MQ6TvNtYoO3MTVJOPN14jbGi9Xk0rfQDXjQMEr6toIE+6vmSG2hihuIeX+xCpcazNs7QRraCB3BeSg+1+cpEGbKugGeB0wZQuHsoWEJ1X5Aicvr7TRJAhpsb774oSc0vS5TDo= Received: from DM6PR02MB6924.namprd02.prod.outlook.com (2603:10b6:5:25f::7) by DM6PR02MB4121.namprd02.prod.outlook.com (2603:10b6:5:a6::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.14; Wed, 15 Sep 2021 12:51:08 +0000 Received: from DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::ddec:9436:4971:5d1e]) by DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::ddec:9436:4971:5d1e%4]) with mapi id 15.20.4523.014; Wed, 15 Sep 2021 12:51:08 +0000 From: "STARK, BARBARA H" To: "'tom petch'" , "'Carsten Bormann'" , "'Juergen Schoenwaelder'" CC: "'netmod@ietf.org'" , "'Babel at IETF'" Thread-Topic: [netmod] [babel] NULL value for ip-address Thread-Index: AQHXqiC4Xf81t47+5kqGy4/Hbr6fHKulBCYg Date: Wed, 15 Sep 2021 12:51:08 +0000 Message-ID: References: <20210910200902.bic4rhyhp75bgsjz@anna.jacobs.jacobs-university.de> <20210913200455.xot7lihpmqiemm5c@anna.jacobs.jacobs-university.de> <20210914171729.ph5q77zm46z3zvxi@anna.jacobs.jacobs-university.de> <20210914191618.khcicr6o4x5sdki3@anna.jacobs.jacobs-university.de> <21E40C00-5C1B-4C54-9CDB-B99AC14B1F3E@tzi.org> <20210914235319.is4x5nzuqdz26dv4@anna.jacobs.jacobs-university.de> In-Reply-To: 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=att.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 97b20314-b337-4836-b786-08d978477d0c x-ms-traffictypediagnostic: DM6PR02MB4121: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NCK6+H2oZDbnlfsv3j+FdhfqI2kvKCZfmqyNGPgg5MMIZOwKLQYcqXF5eDq//LULaZA+F+GeHayP8OLn8aWmvStOTc4MgBiUHKuWZ8cuJx1dcrx/f8Wg9mrCSI5tjiJBR6g8Qt7st2vJ90wFWYHwNigUlY+qcYonocdlhCkPH/cMtIcKAzT95Flhv5GCRtj/vlXtu9Wk/knpW2gra0DnMOhts8DAEhBdPaSJJY26ST3QoHC7iyR2KhRa9mKQlReGppqMnZNABIfHPppzY1EmOZwogrDF8fNjsgEgaoYxCiaBqS5g4SvOZ5ZZxj+8tAQ0qJ7aPFrLaFvsiclm9k7oubwsqkxjCWBmm1tc5E9XUdmpbpDeWjjlHVXH7jquYU9pj1+imdfGLvaJwGAlQ9CgqQ7eARN/NmDQAjutQ0/Qw6LD/vr9OR4HimT3b59hxYo3qzcdZ4jlS5FhWna6c6p0gb+7XHEVcaqTL9XgFhG/QIoAML9E7n8DMJwyGqw8JU8cOBuUDdTegA8V7fNAPH0I/X+rmVlALVLRAbv+1iaaQ5kYqCEoyZPSODPnVQHVNK+ErHSMbi5q8BUwAuNWUKRBcNRoI7q30sIR6IOakAW9P0n57NUBFOWfaEYY6VHvC+SrgVWaohYKQDdON8Ihc+yzCLXJxBowk9YyhRQ3pPEyoQsR7a777QnwT5smYQv07+EvLR1cbbrg/7+vDkHrTYxoyKxz4r1iCMR/RU92O+nHIz1b0b4Xo1ZVvcMXzXsJMxlppdpHaIaOAEML8tnPP6ZuAb1ixfKUbZUY40VesGrzwic7qif7J9qukRYHBgBkVYyIEs4yC5sLFHdLK4xRFEhA/aH+38gas+X68JiBB1evQbU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR02MB6924.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(39860400002)(136003)(366004)(376002)(186003)(66446008)(8936002)(966005)(82202003)(26005)(64756008)(8676002)(66556008)(4326008)(40140700001)(296002)(316002)(478600001)(55016002)(86362001)(5660300002)(6506007)(54906003)(33656002)(71200400001)(2906002)(66574015)(38070700005)(52536014)(110136005)(76116006)(122000001)(66946007)(38100700002)(83380400001)(66476007)(7696005)(9686003)(309714004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?fMmIB9qT2UQ3sAYLJmi0+1LXnjE14jTloX8f+AeGQ/R23PQ+j0EiOtrj9G?= =?iso-8859-1?Q?OzGQVN2n8uckzNRf4wY4j2DEiR72nPR8gyXtWHZ093XvYFP0CAClftvHyb?= =?iso-8859-1?Q?nBzSjKWdZBETh8ExcB0jzS8+nuVacblp3yjp9yMuUh4Xw7ClhE9gnPYhED?= =?iso-8859-1?Q?03N+RJs4khGF5DXmErV2Gmoq9la9LQF7SJudvE2aq7gZtQkD2wqYmQfiPS?= =?iso-8859-1?Q?/xfbnZkD3WVDt9VHu9a/QU/bBGDLFlTjg1oN/eNi4RzcJmzwqnPC6STUJM?= =?iso-8859-1?Q?Myb53hPxmwZe26M8+ulkIPwJ7camrainZSrBDJwSAGS976yst7dTdnU25B?= =?iso-8859-1?Q?gd490L/4NQhTnwf+/l4BU5plxldEivDb2p8JU+x+CoZqX/pjLNSuaysXXq?= =?iso-8859-1?Q?6eJnCLYdnkTKmP5y3H9XMXRUUTg3tv/LrjyezUNuIw+md0/6QT8sJgH2+H?= =?iso-8859-1?Q?B51lzBByn7FAqs4CaJpmEMV08kxQR0vNWYlmHDB50LqLg/m016GALNH4cL?= =?iso-8859-1?Q?j3NDCBd/J3lvPftFeLtJGtt8i0onRZPTfusZiXuvGjXvvc/GfLeXVUzMny?= =?iso-8859-1?Q?T4Ilz0ZooxbwEns8QF/jYfq+crS1dPbr213RaWx2/VWor+i0tvevwuUBIZ?= =?iso-8859-1?Q?6bqcQxaUoXFuzwlA4dgpAO8OEYPi5A7ByoVMTT0wW2Mm5zpCE3L9qC/Xmm?= =?iso-8859-1?Q?+hcKVSZO6zl3wBKJrxKxBBuShuS52tL3itLYi3DD+CNNyHXFm2lL2nVk8M?= =?iso-8859-1?Q?rzAkRvyE9VfKO7HUsh5dMEMzK+Hjoda63ojSTvIYaGxIgY4SjZ4VoOe/7N?= =?iso-8859-1?Q?LVlo58iKelfyxVO+Rb9J5hJd4+9zuKgcS2AZJ7jR37aUI8Uf+ElX/hvV9s?= =?iso-8859-1?Q?JCrpsbBiaF4ybNoGYMXAyEH/FFU+B1GZuPkCA1dFvnh/KdwhmJY8XPId8s?= =?iso-8859-1?Q?sk0hLnMFZzZy4ibJw3CIHGeqKAEcGYSpnBQZjfU7qavP0XHhYlxYXCOF8+?= =?iso-8859-1?Q?ZIr/QfCJXLUwKZ0KzWc/TNpaLKl2s6gDkceRILISTq1CvltEhKCW63OogY?= =?iso-8859-1?Q?oirgsyrH5S1KeYQPve8/qUG1k/esrwoSs5a3f4q3Hw0GgGRsIwiL+N7WPx?= =?iso-8859-1?Q?w2qGco+iQHP3BiGl1iVzw+TfHuSE+pWxD5YtDOI6ZQSjuZVgQFQmWJUBu4?= =?iso-8859-1?Q?CNoE7u94l5rc4x01yZQbI6Gc9+MZn7K3fu9PzKRGINfmHhUpfMvRApIHQK?= =?iso-8859-1?Q?j5uFGQ2Jq74K9OFvMYN1FX/9jm+fToOpfTMRgcnyEj9l0mQzFHg5hlZdFu?= =?iso-8859-1?Q?SEsGx5mxS/ASP5pQqJohji5kYptWhQMF0GGqkThnsjWpOqo=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR02MB6924.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 97b20314-b337-4836-b786-08d978477d0c X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Sep 2021 12:51:08.4208 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8PPrL5hHdwEu8KG0Y9RN+DppXLp7t7IM82fqK8uAcQZnbD8GtQ6muIgkHgZGmxyU X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR02MB4121 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: F3F58A5E2B5C8CD1DEACAE9E6FDBCCAD18E919A1646E0519105AF5CA22775AAD2 X-Proofpoint-GUID: BIrFpDAYk014JriPbOIPita0QXyUWWaR X-Proofpoint-ORIG-GUID: BIrFpDAYk014JriPbOIPita0QXyUWWaR X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-09-15_03:2021-09-15, 2021-09-15 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 suspectscore=0 spamscore=0 impostorscore=0 mlxscore=0 phishscore=0 bulkscore=0 mlxlogscore=999 clxscore=1015 priorityscore=1501 adultscore=0 lowpriorityscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109030001 definitions=main-2109150082 Archived-At: Subject: Re: [babel] [netmod] NULL value for ip-address X-BeenThere: babel@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "A list for discussion of the Babel Routing Protocol." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2021 12:51:29 -0000 > Barbara >=20 > Top posting a slightly different question. >=20 > Belatedly doing my homework, I see that not all the NULL are uint16. One= , > next-hop, is ip-address. We have the options discussed for uint16 but co= uld also > use zero (or some other value) to mean NULL. Zero is of course the way t= he > default is commonly represented. >=20 > How is this handled in TR-181? How would you like it handled in YANG? >=20 > Tom Petch Hi Tom, In discussion with Mahesh, he has indicated preference for union with a "nu= ll" enumeration to handle the uint16 cases. He's also indicated he would pr= efer to do that for the ip-address. I see the YANG ip-address type is a union of ipv4-address and ipv6-address = types, both of which are strings. In BBF, there is the IPAddress datatype which is a string(45) with IPv4 and= IPv6 formats allowed. There are also IPv4Address and IPv6Address datatypes= that are defined as derivatives of the IPAddress datatype. An empty string= is used for "unspecified or inapplicable addresses". Strings, unlike ints,= have the luxury of being empty.=20 I'm perfectly fine with Mahesh's choice to use the union with a "null" enum= in all cases. It seems like a good solution.=20 Thx, Barbara =20 > From: netmod on behalf of tom petch > > Sent: 15 September 2021 10:04 >=20 > From: netmod on behalf of J=FCrgen Sch=F6nw=E4l= der > > Sent: 15 September 2021 00:53 >=20 > On Wed, Sep 15, 2021 at 01:01:11AM +0200, Carsten Bormann wrote: > > > If BBF already > > > defined to use -1, so be it. > > > > That works for me and is consistent with the information model in 9046. > > > > What I find not so great is the side effect of going from uint16 to int= 32. > > > > I don't see a big difference between > > Optional-uint16 =3D uint16 / -1 > > and > > Optional-uint16 =3D uint16 / empty > > > > I do not like > > > > Optional-uint16 =3D int32 >=20 > YANG leaves the bits business to the encodings. In YANG, you can of > course use >=20 > type int32 { range -1 | 0..65535 } >=20 > and then its left to the encodings. Im XML/JSON, -1 is 16 bits and > 65535 is 40 bits - and the name of the leaf is likely worse. I am too > lazy to lookup what the CBOR encoding would do with the range... >=20 > >=20 > I am with Juergen here, and in a previous post, that if that is the way i= t is done in > BBF, then that is a compelling reason to do the same. >=20 > Also, you can create a typedef for it, in one place in the model with a > description, both in the YANG and in the body of the I-D, and then use th= at type > in all the places that it applies, which, for me, makes for a clearer, ea= sier to > understand model. >=20 > I suggested boolean but agree that it is clumsy, not quite right (althoug= h I have > seen it somewhere). I suggested choice/case because that is what others = do but > as before, following BBF is a more compelling argument. >=20 > It also addresses the problem of access control making it a challenge to = know > what is going on. The one leaf, the one object, you get it or you do not= . Simple! >=20 > And if you want to save bits, then YANG is not for you; the design aim wa= s text > that anyone could read anywhere; if you want to save bits, then you need = a > compact binary representation:-) >=20 > Tom Petch > (who is on European time) >=20 > > > The alternative is to not >=20 > instantiate the leaf if there is no value > > > and to accept that a client can't tell the difference between 'there > > > is no value' and 'the value has been suppressed by authorization'. > > > > Interesting. I wasn't aware that this cannot be distinguished in YANG. >=20 > I have to correct what I wrote. Its the leaf that is suppressed, not > the value. >=20 > In XML, if does not exist, the client gets nothing. If > does exist (and it's value is empty in this example) and authorization > rules say 'don't tell the client', the client gets nothing. A client > not getting can't decide whether there is no because > does not exist or authorization prevented access to . >=20 > Authorization is not part of YANG. NACM started as an extension to > NETCONF in order to control access to data. Initially the acronym NACM > expanded to the 'NETCONF Access Control Model', RFC 6536. The revised > NACM also works with RESTCONF (and likely other protocols) and hence > the acronym now expands to the 'Network Configuration Access Control > Model', RFC 8341. >=20 > > But an "empty" would be present if it is chosen, no? >=20 > You grant or restrict access to and it does not matter what > type has or which value has (if it is a leaf) or whether > is the root of a deeply nested tree (if it is a container). If > a client has no permissions to read , then is silently > omitted. >=20 > Things are different if a client attempts to create/write/delete > , in this case the client will get an explicit authorization > failure error. For the details, see RFC 8341. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 university.de/__;!!BhdT!0lzj- > SsD4F_BXA2xA1cZKG6UywIiSir64JMs2nHWe4NhV6ltLH2pt1EFLdoxAw$ > >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/netmod_= _; > !!BhdT!0lzj- > SsD4F_BXA2xA1cZKG6UywIiSir64JMs2nHWe4NhV6ltLH2pt1Ew7T22Pw$ >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/netmod_= _; > !!BhdT!0lzj- > SsD4F_BXA2xA1cZKG6UywIiSir64JMs2nHWe4NhV6ltLH2pt1Ew7T22Pw$