From nobody Tue Sep 3 04:55:17 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233AD12011E for ; Tue, 3 Sep 2019 04:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=ericsson.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 wM6weTdesuGx for ; Tue, 3 Sep 2019 04:55:12 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40083.outbound.protection.outlook.com [40.107.4.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 048F4120108 for ; Tue, 3 Sep 2019 04:55:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AQkNFYV8pHlfeLksoFD4QEX3uxgr3AJ5cdYCzMtSd41MdzMS3e1+pmEjRZDODG5k55DpsLKof6VYBfn4JBcnWE6mGzCnrOeh7KJbnX56FPxz27SrwPVA2BS8siEit9EZUyN9fb/Su+cNn9YBObgRShtytrhaZR67tns/vQErTCxUcsaiaFuvwpOHw+COxsmiKPFuZ3sCXE7UqEU5lQ9ue0sPrXBBGuuJUE9OqijrKpDwUJHW/MsYMAs3RXUvZHxhxNd1YfMnEU+HMFNmBukvYnX+0m43ak9GMT9vicmQVSVEoK1kNf/55DzlTrpmoTmR8yryZYTAUEdbwnCNN4fwtA== 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=+3RP9ciU4lLPceHzGg3oQ8P2JlVtd7AI0oljqd3KMVU=; b=jHzJzr9u9NVY4GtYx8+jmYi13RQ3f+wEtuXSDECsXwIXIpBpYeqf5jIcQeiCRc5EzNNqP2tAS29NbFs4ov6NxSRhPcPlIpVeQWe7kYiTYHdxze4Y5DbYbA3hZlpDQPy1xhxVH6+I/0jOdLvcL4cSvWCrQTz0NTlSNY7j1PnynDcuqCrM7zYFdjsSYdcPsI1CaWXDaMOAgXx+rKjsLzneR/10MF1AMCRGvREJU+gBe+5Szxa+EiGCOr5BrBgGmDvTSgZ7GWDSlSzntJ5RDe59zwK6x5vvPCkRZi9L6AbLDXax5Q3Cug9mS+hNoxvisagQkjI9bJPnyYQwpgOu+i/ehw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+3RP9ciU4lLPceHzGg3oQ8P2JlVtd7AI0oljqd3KMVU=; b=Bpmd7GXtTya8OF2LiJmRVKItTHnHseUGErKlTZTh2go/tEU6MTjXL5iEaMfQL5JjCxAax6497YQd4H6WNxkzYp4CT9wP+D9+17aIuiurvH/vK/zCOYrVQwAudCtf0CS2rCN1rrwfKsWEagdMH7TTSvNkxRC8i6mn141kjilggYQ= Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com (10.169.137.153) by VI1PR0701MB2541.eurprd07.prod.outlook.com (10.168.138.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2241.12; Tue, 3 Sep 2019 11:55:09 +0000 Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com ([fe80::f44b:854c:51cf:c69f]) by VI1PR0701MB2286.eurprd07.prod.outlook.com ([fe80::f44b:854c:51cf:c69f%7]) with mapi id 15.20.2241.013; Tue, 3 Sep 2019 11:55:09 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: Kent Watsen , "netconf@ietf.org" Thread-Topic: Multiple servers and endpoint Thread-Index: AdViTOjzrXZiF0DlSEidIjNi0b8UoA== Date: Tue, 3 Sep 2019 11:55:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3240663c-d4f9-4f5d-9af4-08d730659229 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:VI1PR0701MB2541; x-ms-traffictypediagnostic: VI1PR0701MB2541: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 01494FA7F7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(376002)(136003)(39860400002)(346002)(189003)(199004)(6436002)(76116006)(66946007)(476003)(7696005)(45776006)(6506007)(54896002)(6306002)(102836004)(186003)(26005)(99936001)(486006)(71200400001)(71190400001)(53936002)(99286004)(316002)(66476007)(478600001)(66446008)(25786009)(52536014)(256004)(66616009)(66556008)(64756008)(3480700005)(110136005)(2501003)(14454004)(9686003)(74316002)(2906002)(8936002)(86362001)(3846002)(8676002)(55016002)(790700001)(6116002)(81166006)(81156014)(7736002)(66066001)(5660300002)(33656002)(9326002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2541; H:VI1PR0701MB2286.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Aq2YWnoB6KEXLvuBUUkOF7Z3TEoxkJkvlzhvvNq7g3Ih+I8B9JkQ2B3nkc+CxIVRCGjw0ItxIyfo/D9uAVxG7LzXybXMgjcaUlUk0/gjxUPGYPMc0YIDm6MUEeQcN9MZlEhahN9ZDQEhHRXJyyUgXNcIQDENGEDSdOWO3+NLCnAAX+QW/d4VNMn4kIYFgMk1MnsS43Q+FE9eX07M5oxZrg4uashEAuFPMRJkUNiMV5dFLt2t5wijL5iDfJVpxUzjTu+Qg6KAGvkL1ewLIysewDBWw3zoSrfk3rOp9jzVNxcID941XkUSiLYw1vgK3uXy5bxwTrw/zavF8/anBE+DJenquo2NAlOMQh+fqhyOmm19Qe34UUAaf9JfPdjoMN51j0ooWuzOQKXvaHcWbuA3VOBdYYvmWTqFJORHb1KmEek= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01EC_01D5625F.31F1C100" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3240663c-d4f9-4f5d-9af4-08d730659229 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2019 11:55:09.2427 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: aN6mFtPfzv3jaes/3fhG4VTvg75yijiYq06RWDf714vw3DDa35tnJl+/nOLeGGTZh/+5695RqKunX3PieBp42VgAaqBYlG+wdVMHlWmyiPw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2541 Archived-At: Subject: [netconf] Multiple servers and endpoint X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2019 11:55:15 -0000 ------=_NextPart_000_01EC_01D5625F.31F1C100 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01ED_01D5625F.31F1C100" ------=_NextPart_001_01ED_01D5625F.31F1C100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello Kent, In some client models you have multiple remote servers defined and multiple endpoints for each server. I would like to clarify the desired behavior for these. E.g. netconf-client-grouping { the end-point description states: "A user-ordered list of endpoints that the NETCONF client will attempt to connect to in the specified sequence. Defining more than one enables high-availability." As I understand this means the client will try to connect to the first endpoint. If that fails it tries the next one. Correct? For servers the description states: "List of NETCONF servers the NETCONF client is to initiate connections to in parallel." What does parallel men here? * Will it try to connect all, and abort all connection attempts after the first succeeds? * Try to send the same information to multiple servers? * Try to do some load-sharing between multiple servers? Regards Balazs -- Balazs Lengyel Senior Specialist Ericsson Hungary Ltd. Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com ------=_NextPart_001_01ED_01D5625F.31F1C100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Kent,

In some = client models you have multiple remote servers defined and multiple = endpoints for each server. I would like to clarify the desired behavior = for these. 

E.g. netconf-client-grouping =
{

the end-point description states: = 

 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 "A user-ordered list of endpoints that the =
NETCONF
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 client will attempt to connect to in the =
specified
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 sequence.=A0 Defining more than one =
enables
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 high-availability."

As = I understand this means the client will try to connect to the first = endpoint. If that fails it tries the next one. Correct?

 

 

For servers = the description states: 

"List of NETCONF =
servers the NETCONF client is to
=A0=A0 =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0initiate connections to in =
parallel."

What does parallel = men here?

  • Will it try to connect all, and abort all connection attempts = after the first succeeds?
  • Try to send the same = information to multiple servers?
  • Try to do some load-sharing between multiple = servers?

Regards = Balazs

 

--

Balazs = Lengyel=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Senior = Specialist=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 Ericsson Hungary Ltd.

Mobile: = +36-70-330-7909=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 email: = Balazs.Lengyel@ericsson.com

 

------=_NextPart_001_01ED_01D5625F.31F1C100-- ------=_NextPart_000_01EC_01D5625F.31F1C100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVbjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF/zCCA+egAwIBAgIR AOm+1xFswMzmixU1jNT/MSEwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMB4XDTE3MTAw OTE1MjQ1OFoXDTIwMTAwOTE1MjQ1N1owajERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD0Jh bMOhenMgTGVuZ3llbDEqMCgGCSqGSIb3DQEJARYbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t MQ8wDQYDVQQFEwZFVEhCTEwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUUtnneUfH i428YPkvW+AsCNeKCCKq72SzUZpBggijy+oLVO0cgTXXHygrZ+KT8TbyEkPwuHi+V4TQxWAyMhGa nWZHWZXe9ghEZrJDJbCzFMHOqR+wEDnI1vM3sfQQ68iSsWQLd9opnb2/ihiJlt9up75VRpyj5lea bvzxOLQimJgZiXaZzsPPT2nROyytKxOsE5KbfT3mNof3bMG1bggZtGGA1GBJchwdFJwQKIShfPVm 1CdulvJV1hPVecxttMJNPzSfSfryb/b64QnR5yc/pSx8SxD0h0rnNT73Al3Af2iRghdXN4omDKZY OcdK/sE5HTmLTFuWoZAnL/RntOK9AgMBAAGjggHBMIIBvTBIBgNVHR8EQTA/MD2gO6A5hjdodHRw Oi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggr BgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYI KwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNlcjAmBgNVHREEHzAdgRtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBSkJw2vbyMFmf9tY1urk9NeYfiMgTAfBgNVHSMEGDAWgBQcexmel5x2rCA92Nzj kWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAD1RCVf5Df2uCXwPveXz LBGIjsz3k2la5UUlioC+i4Ms6vGstqXIX7K24+Wc41npi+G5xFhvkAkmuTP/j29F5xJJuJcy3OcL 0br02vKe2WJJnlivB+X9plPg0kMUBS0lLq7kHPUrO/BLeIIFRuaky05eZlTnGNcLbn5VpZdjX4Ic XZV78qpZI3L67Po1UgHzOTiWolc75jrKOx3UOw98fWRrgJPBUIeqDeD1NDfF7PlM4Cqlad062o6L lM9wfAnoLzz0z04dPXtJkOcTiZgOLdPoKIm7LR1wZ9c6mYw4sgtoVAs16Y2cCPBxqWpsW+9ZCcDK PPZzeBezCKyicpDJbTqCVMILd3j38HWUPWFuVITZNgANzHW1CpgqmiLIAADiznCCtudTE+fcB3O9 duuu/yuEME17LMy1GYMKXs1QCXmTq2hrqTJQ2AA2TsWZtoxl3ViqJgNBWjnQiMwdCl5Dural2jZP /iU6MmiauUNYn9YW/ViUluoBBdaUHMpnP/7kM0Wk8j3Wzhcggx+Biml2gCopMaK1EJYjQH/2J95N GEkSdZfVzFUmwV3yMd4mOhIaxW0SEq9b1eWICZ/BAcVBpSyU0sE1gpnBO5wLxj+IpSdiGlS4jc37 qCr/39xdv1Unu93glCmHq0xgX54N8EsyMBPC3+zSSu1qhCbU7VJWIz2aMIIGwjCCBKqgAwIBAgIQ U7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEf MB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcx MjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy 3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt 8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6j RrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFl hFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/2 0aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCY rEqHMRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuT LUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMd ay0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqd GTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMB AAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVz dC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9j cmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpec dqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5 s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90 BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRy pF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86 IWst821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QD Xnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7 C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbN QUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbH XSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i 6Ds5j0Qpj5aQMYIDBTCCAwECAQEwXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MAkGBSsOAwIaBQCgggF+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTE5MDkwMzExNTUwN1owIwYJKoZIhvcNAQkEMRYEFJ1dVTS9X/Vp5Tew4rHS4BNVHgiPMEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQCuY0m/7eS5Pt+g50SuyrwYn1NBxtlIPBs1CX7pgaA/CZ6VBHDhs+h3 LclqWRrCvKi0I8M0iDjzBBUwxlaVCBVyHK6JJFHaLK88krL3FvZfStLROTZA8jXS4/0qvazjxvC8 OnwTJFWSAh37xsElJc1R3JmQrz4Nl0s61haeKRJqKv9XH52bZQQ067wl45UpzvUocx0TFzuhoJCa 0MmPZVnKKqMQOyjk5XQg12QIpyq6Xo3Fxr4wG5zrad1i5sDhvWKFLEgIqYys8v31VyhfzEmLeW9F fPyxyXV3TW10l1bJu1elgU5vvGRXibJrLSk/03DPWefPRzHapf89VjXKPZtjAAAAAAAA ------=_NextPart_000_01EC_01D5625F.31F1C100-- From nobody Tue Sep 3 06:46:25 2019 Return-Path: <0100016cf7602cc5-c01011cb-f32d-4989-985a-f5d6070f7abd-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751C1120818 for ; Tue, 3 Sep 2019 06:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 gFz9o5Fq2Q2Z for ; Tue, 3 Sep 2019 06:46:12 -0700 (PDT) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C61612084C for ; Tue, 3 Sep 2019 06:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1567518371; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=EmZ67wwMi2LSx62XknmfIWsbsVHoR4V7RkGYwcJnLI0=; b=bEHWidok3bsRXYd5fmP63e2elkisHaD+snDFn6gBa/HjYMicBJGhUn9lhGvCW6DS +5SbTjW27oJNA0BpJ+lQuQosTIGD5lbt/AUyYPL8SsW8l1gvStmd0T8/scMKjKNpqKO 8jj9wE27gtLBZw1oE/ishES8pkGGUeOPKpwvMIFY= From: Kent Watsen Message-ID: <0100016cf7602cc5-c01011cb-f32d-4989-985a-f5d6070f7abd-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4B862D29-A0B1-460D-BA07-07E180A01C6B" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 3 Sep 2019 13:46:11 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: =?utf-8?Q?Bal=C3=A1zs_Lengyel?= References: X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.03-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Multiple servers and endpoint X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2019 13:46:23 -0000 --Apple-Mail=_4B862D29-A0B1-460D-BA07-07E180A01C6B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 3, 2019, at 7:55 AM, Bal=C3=A1zs Lengyel = wrote: >=20 > Hello Kent, > In some client models you have multiple remote servers defined and = multiple endpoints for each server. I would like to clarify the desired = behavior for these.=20 > E.g. netconf-client-grouping { > the end-point description states:=20 > =20 > "A user-ordered list of endpoints that the NETCONF > client will attempt to connect to in the specified > sequence. Defining more than one enables > high-availability." > As I understand this means the client will try to connect to the first = endpoint. If that fails it tries the next one. Correct? Correct. That is the intention behind it being user-ordered. > For servers the description states:=20 > "List of NETCONF servers the NETCONF client is to > initiate connections to in parallel." > What does parallel men here?=20 > Will it try to connect all, and abort all connection attempts after = the first succeeds? > Try to send the same information to multiple servers? > Try to do some load-sharing between multiple servers? The intention is that these are, e.g., distinct applications the client = wishes to establish a connection with. For instance, a firewall might = want to connect to a cloud-based deep-inspection engine as well as a = cloud-based spam-analyzer. For each application then, there may be a = user-ordered list of "endpoints" for high-availability. The word "parallel" may be overstated, as it doesn't matter if the = implementation actually connects in parallel or not, especially in = context of each connection being long-lived (periodic or persistent), = the sequence of the initial connections loses its meaning. Perhaps the = text should instead say "maintain parallel or simultaneous connections = with"? Thanks, Kent --Apple-Mail=_4B862D29-A0B1-460D-BA07-07E180A01C6B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Sep 3, 2019, at 7:55 AM, Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com> wrote:

Hello = Kent,
In some = client models you have multiple remote servers defined and multiple = endpoints for each server. I would like to clarify the desired behavior = for these. 
E.g. netconf-client-grouping {
the end-point description states: 
 
          &nb=
sp;      "A user-ordered list of endpoints that =
the NETCONF
          &nb=
sp;       client will attempt to connect =
to in the specified
          &nb=
sp;       sequence.  Defining more =
than one enables
          &nb=
sp;       high-availability."
As I = understand this means the client will try to connect to the first = endpoint. If that fails it tries the next one. = Correct?


Correct.  That is the intention behind it = being user-ordered.


 For = servers the description states: 
"List of NETCONF servers the NETCONF client is to
   =
           initiate=
 connections to in parallel."
What does parallel men here? 
  • Will it try to connect all, and abort all = connection attempts after the first succeeds?
  • Try to send the same information to multiple servers?
  • Try to do some load-sharing between multiple servers?

The intention is that these are, e.g., = distinct applications the client wishes to establish a connection with. = For instance, a firewall might want to connect to a cloud-based = deep-inspection engine as well as a cloud-based spam-analyzer.  For = each application then, there may be a user-ordered list of "endpoints" = for high-availability.

The word "parallel" may be overstated, as it doesn't matter = if the implementation actually connects in parallel or not, especially = in context of each connection being long-lived (periodic or persistent), = the sequence of the initial connections loses its meaning.  Perhaps = the text should instead say "maintain parallel or simultaneous = connections with"?

Thanks,
Kent

= --Apple-Mail=_4B862D29-A0B1-460D-BA07-07E180A01C6B-- From nobody Tue Sep 3 08:00:55 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCD01208DC for ; Tue, 3 Sep 2019 08:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=ZjBurSeD; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=I3FCRIgY 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 KRa81CTJLgMJ for ; Tue, 3 Sep 2019 08:00:45 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 439F7120948 for ; Tue, 3 Sep 2019 08:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15253; q=dns/txt; s=iport; t=1567522845; x=1568732445; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ffCX/F0mF+7hy5LeRKRIThXZQ0nLnIE6vjbXL0D3O1M=; b=ZjBurSeD1fsLrRbbXsjpjrkwJTmgtg4vCP/nyO3XMFO5l/rr95yZHVX/ 7dKudwybJN3gkXRoyPq92qEf9OsTz8BW/xARXs6ib2rVfUvJ61l+rtDR3 3XD6+QNwT77lWjgv9OsyY2+iwFvdHLWRtsomzjROWPdiB3Xv9+X5o49IY U=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3AyJU2HxTL+E0LjgFpk/6ikpDHVdpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESUDdfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOiEkG8VefFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAADzfm5d/5tdJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwQBAQEBAQsBgRUvKScDbVYgBAsqCodeA4RShieCXIc?= =?us-ascii?q?/i1GEXIEuFIEQA1QCBwEBAQkDAQEjCgIBAYQ/AoJ2IzQJDgIDCAEBBAEBAQI?= =?us-ascii?q?BBgRthS4MhUoBAQEEEgsQEwEBNwEPAgEIEQQBAQ4hAjAdCAIEAQ0FCAYNB4I?= =?us-ascii?q?1TIEdTQMdAQIMnywCgTiIYYIlgnwBAQWBNgKDVhiCDwcDBoE0AYFQiicYgUA?= =?us-ascii?q?/gRFGgkw+gmEBAQOBKwESASErgxCCJoxMiQCIDY1XbQqCH4M4gimBEo4DgjO?= =?us-ascii?q?HNo59jXaHdZBUAgQCBAUCDgEBBYFQOGdxcBU7gmyCQoNyhRSFP3OBKYxYgSI?= =?us-ascii?q?BgSIBAQ?= X-IronPort-AV: E=Sophos;i="5.64,463,1559520000"; d="p7s'?scan'208,217";a="625174123" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Sep 2019 15:00:42 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x83F0g4P006341 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 Sep 2019 15:00:42 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 3 Sep 2019 10:00:42 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 3 Sep 2019 10:00:41 -0500 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 3 Sep 2019 10:00:41 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B8jz8gYV/BKja4GXswzb41VL4t/uVfa1eFFWD7fHkNRZTFo3NhQK/3i/fT1HoxwPAlQlA7z4UcUXWyqJrSKqLjyIeGqBV2pxJgCmCXDpRPlYSrQpeYdhM7WLoeWvSpwgns07OBDpVK1klqnxcsnAEAevJvKk9e0uvM8VgQSACoEUnzqHaXe9U2C5xGE8S1cpAdWkj4bTl+yxd2DNK5n5UNihS1/tAWQqIE/hGmS64LonsKpFmNFsI0xuS4As/Eq7Do7sL8Cl8iwOd6YaqZq/7Cc/YWyN6dgssa/054srJCSkf6OkpkgXe4Bpxs9IYlc2oGliceBfCID+SJa6VEDu7g== 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=xYA4JALX9ZhMO/hnA1h5rsdDqpFifVi39FjJTBe+5H8=; b=FH7Vx3VBgcCijgG7ylYD+NMuIe46NYCieZAsnKJoyHJnaZ3WsMUZAktpSXPEt0ZUATLJYSG62svQLT3lWm9M+eyVQ4gVW+Xe1ZFa6BqWu8dksl0JQR1GzFU2ZVTPfmdZrYm7VffVvruVszrYzXlTjBYmB/t8r+3DVJ/XYkULfVTMOZ6TPjkA6yQEPdFOTN7pOVGOiST8e4bN9SKc6UqHW2AaSDAKcmnK3vz53mFD+g/EVPzDBDaNUj9O438UxXfM4AxyUl55bWmYDQeH5/oGrRiHguVRSWQTul9z3skQBwAL4evhpWZzaMxU+53iWHi3RDtcp/ZoI5XzQtAUUVyasA== 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=xYA4JALX9ZhMO/hnA1h5rsdDqpFifVi39FjJTBe+5H8=; b=I3FCRIgYKa3DFrTdKUdmrq/j/9QSDDIAo7cmaAh+OsaSNsM522ycKkJoe5oYJO4ZyUhA9Hge3RmHe7bW9i6ck9+TUhxOYYDLtdDRykzQy9S1HMHL2ggxYRvi5/HL3TGQPG4z8wRO7kdjj9wyrAUFqKojCTSBqEmVb61sfEWGBGE= Received: from SN6PR11MB2638.namprd11.prod.outlook.com (52.135.91.149) by SN6PR11MB2894.namprd11.prod.outlook.com (20.176.241.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.18; Tue, 3 Sep 2019 15:00:40 +0000 Received: from SN6PR11MB2638.namprd11.prod.outlook.com ([fe80::a545:a4eb:27b:bac7]) by SN6PR11MB2638.namprd11.prod.outlook.com ([fe80::a545:a4eb:27b:bac7%7]) with mapi id 15.20.2220.013; Tue, 3 Sep 2019 15:00:40 +0000 From: "Eric Voit (evoit)" To: Kent Watsen , Mahesh Jethanandani CC: "netconf@ietf.org" Thread-Topic: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 Thread-Index: AQHVXFoPNB92Y7jVYEStg347+aEuhKcaAhVg Date: Tue, 3 Sep 2019 15:00:39 +0000 Message-ID: References: <0100016ccff35064-9da3c8b6-263c-47f6-a4f2-4db9495bc8b7-000000@email.amazonses.com> In-Reply-To: <0100016ccff35064-9da3c8b6-263c-47f6-a4f2-4db9495bc8b7-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=evoit@cisco.com; x-originating-ip: [173.38.117.88] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: be411211-f4e1-48d6-292c-08d7307f7c65 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:SN6PR11MB2894; x-ms-traffictypediagnostic: SN6PR11MB2894: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01494FA7F7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(376002)(136003)(346002)(366004)(199004)(189003)(4326008)(7736002)(74316002)(81156014)(81166006)(8676002)(76176011)(26005)(186003)(6506007)(53546011)(8936002)(14444005)(256004)(446003)(11346002)(486006)(476003)(229853002)(99936001)(102836004)(52536014)(66066001)(6436002)(55016002)(6306002)(54896002)(9686003)(5660300002)(236005)(478600001)(53936002)(86362001)(14454004)(606006)(33656002)(966005)(316002)(71200400001)(110136005)(71190400001)(2906002)(3846002)(6116002)(790700001)(6246003)(7696005)(99286004)(76116006)(25786009)(66446008)(66946007)(66616009)(66556008)(64756008)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR11MB2894; H:SN6PR11MB2638.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: sZqpomUFjL343MHUUCJH7XZ4uCmLLyGTWqjuSEg840PBEpKPs9slR0pnkn1DSKZd+qTgVC09vVLkDSa0MMvO/BqyfYR8aMeyU8WQ8USFUkImmbgnpKagjtyYqOPTdDazLw0FVaMQQdCzOlUaHoVFOsMCTpHkbFNFYlulBJErA8KcajPCzCc7pCIg1Q3xYmFTP6/cg1R3PQzIGpW/L+FAtAfmx3VVNp69wbiHOUc1W0oNy9ZOW422tSGy7TGgJGtQF3CTFyzLC3qQzNW/qYIRS1kho0ibbNUdAcNq0WdFneLU3DFSrC+b+9+OEY/FN82po2K3dT4mc+lhXabVfaia8RiRAwFMysPRI9hwYbJ9cqUghEKCOFv+t3xzDKzb4LqS8GD9qgoEifcLWF6Ygy5LuOau32Zu5rmnxM9sgKS4Ln4= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_025A_01D56246.BD7CC080" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: be411211-f4e1-48d6-292c-08d7307f7c65 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Sep 2019 15:00:40.0849 (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: MFb+D929qaF8fZ9j2pqgOswOmLw8CvJokQOVDS5hKBZ4HtGMYWsPnvqZt7c8R06O X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2894 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2019 15:00:54 -0000 ------=_NextPart_000_025A_01D56246.BD7CC080 Content-Type: multipart/alternative; boundary="----=_NextPart_001_025B_01D56246.BD7CC080" ------=_NextPart_001_025B_01D56246.BD7CC080 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I support the adoption. Building upon that, there are a few elements which would be good to consider in future iterations. (1) Understanding the capabilities of the configured receiver is important. One or more publishers of configured subscriptions could be used to overwhelm a receiver which doesn't even support subscriptions. This document should include ways to ensure a configured stream won't be established with an endpoint unequipped to deal with the inbound notifications. As a starting point for these discussions, there are mechanisms in draft-ietf-netconf-restconf-notif v5 to address this. E.g., the HTTP transport augmentation on the receiver must send an "HTTP OK" to a "subscription-started" notification before the publisher starts streaming any subscribed content. (2) Multiple versions of draft-ietf-netconf-restconf-notif include topics/text which might be useful, even as an appendix. For example Section B.2 of v5 includes example config operations and interaction models. Side comment: there are advantages in subscriptions over HTTP2 transports, which I don't believe it will be covered in this draft. GRPC has the ability to optimize based its leverage of HTTP2. To examples from draft-ietf-netconf-restconf-notif v5 which are good to think about are: (a) optimizing multiple configured subscription streams to a single receiver (such as a controller). (b) it can be easier overwhelm a receiver which is unable to control or handle the volume of Event Notifications received It would be good to somehow capture the implications of using different underlying HTTP capabilities as part of these discussions. Thanks, Eric From: netconf On Behalf Of Kent Watsen Sent: Monday, August 26, 2019 6:02 PM To: netconf@ietf.org Subject: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 This email begins a 2-week adoption poll for: https://tools.ietf.org/html/draft-mahesh-netconf-https-notif-00 In-room support for this draft was noted but, as always, it is necessary to confirm WG consensus on the list. If interested in the WG defining an HTTPS-based solution for *configured subscriptions* (for which there are none to date), please voice your support for this draft's adoption. If objecting, please state your reasons. PS: Authors, please additionally respond to as if there is any IPR to disclose. Kent and Mahesh // as chairs ------=_NextPart_001_025B_01D56246.BD7CC080 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support = the adoption.

 

Building upon that, there are a few elements which = would be good to consider in future iterations.

 

(1) =  Understanding the capabilities of the configured receiver is = important.  One or more publishers of configured subscriptions = could be used to overwhelm a receiver which doesn't even support = subscriptions.    This document should include ways to = ensure a configured stream won't be established with an endpoint = unequipped to deal with the inbound notifications.  As a starting = point for these discussions, there are mechanisms in = draft-ietf-netconf-restconf-notif v5 to address this.   E.g., = the  HTTP transport augmentation on the receiver must send an = "HTTP OK" to a "subscription-started" notification = before the publisher starts streaming any subscribed = content.

 

(2)  Multiple versions of = draft-ietf-netconf-restconf-notif include topics/text which might be = useful, even as an appendix.   For example Section B.2 of v5 = includes example config operations and interaction = models.

 

Side comment:  there are advantages in = subscriptions over HTTP2 transports, which I don't believe it will be = covered in this draft.  GRPC has the ability to optimize based its = leverage of HTTP2.    To examples from = draft-ietf-netconf-restconf-notif v5 which are good to think about = are:

(a) optimizing multiple = configured subscription streams to a single receiver (such as a = controller).

(b) it can be easier = overwhelm a receiver which is unable to control or handle the volume of = Event Notifications received 

It would be good to somehow capture the implications = of using different underlying HTTP capabilities as part of these = discussions.

 

Thanks,

Eric

 

From: = netconf <netconf-bounces@ietf.org> On Behalf Of Kent = Watsen
Sent: Monday, August 26, 2019 6:02 PM
To: = netconf@ietf.org
Subject: [netconf] Adoption Call for = draft-mahesh-netconf-https-notif-00

 

This email begins a 2-week = adoption poll for:

 

    = https://tools.ietf.org/html/draft-mahesh-netconf-https-notif-00

In-room = support for this draft was noted but, as always, it is necessary to = confirm WG consensus on the list.  If interested in the WG defining = an HTTPS-based solution for *configured subscriptions* (for which there = are none to date), please voice your support for this draft's = adoption.  If objecting, please state your reasons. =  

 

PS: Authors, = please additionally respond to as if there is any IPR to = disclose.


Kent and = Mahesh // as = chairs

------=_NextPart_001_025B_01D56246.BD7CC080-- ------=_NextPart_000_025A_01D56246.BD7CC080 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwOTAzMTUwMDA0WjAjBgkqhkiG 9w0BCQQxFgQUZG+l5yfRTqK/Nn+FXlTm8b+Gs7EwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQBDt5SO1lPQcbT0RSov3h5QRyN/lMgxs5RYudBDRyXXKQkSerzzwL43ertyMulua0aX diSqMx5MgTmi+DZrBzpK+8M822BVU7uBPUPn6iOeoWK4rKwPKVJ05/JN0DJybfcAEh+N/1/PVFM1 yGcTXGDsd9Y/D4/g9CkPZg8a/eHkYKVSaKOuikQZKL9fOPSkQRzxWVP1kxF2dIfA6BI4HQQt3R68 7WHjn6n6rF32kNSvO9MefDvEYshFGXQVlDQeZ98xr75rhN1clNtr6S5hzUa8HvV7gj5E7G5vfxUg 2oSTojCZIiFP65RMYw285ZdqYymfdqTUEycxmWcq2kaztHT4AAAAAAAA ------=_NextPart_000_025A_01D56246.BD7CC080-- From nobody Thu Sep 5 06:01:07 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E235312006A; Thu, 5 Sep 2019 06:00:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <156768845683.22739.11665043649728201861@ietfa.amsl.com> Date: Thu, 05 Sep 2019 06:00:56 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-notification-capabilities-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Sep 2019 13:00:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : Yang-Push Notification Capabilities Authors : Balazs Lengyel Alexander Clemm Benoit Claise Filename : draft-ietf-netconf-notification-capabilities-04.txt Pages : 18 Date : 2019-09-05 Abstract: This document proposes a YANG module that allows a server to specify server capabilities related to "Subscription to YANG Datastores" (Yang-Push). It proposes to use YANG Instance Data to document this information and make it already available at implementation time, but also allow it to be reported at run-time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-notification-capabilities-04 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-capabilities-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-notification-capabilities-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Sep 6 07:57:19 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0EB81200C7; Fri, 6 Sep 2019 07:57:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ibagdona@gmail.com, mjethanandani@gmail.com, netconf-chairs@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156778183779.21968.4865450271994186957.idtracker@ietfa.amsl.com> Date: Fri, 06 Sep 2019 07:57:17 -0700 Archived-At: Subject: [netconf] netconf - Update to a Meeting Session Request for IETF 106 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2019 14:57:18 -0000 An update to a meeting session request has just been submitted by Mahesh Jethanandani, a Chair of the netconf working group. --------------------------------------------------------- Working Group Name: Network Configuration Area Name: Operations and Management Area Session Requester: Mahesh Jethanandani Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 65 Conflicts to Avoid: Chair Conflict: netmod Technology Overlap: opsarea opsawg Key Participant Conflict: babel tcpm bfd anima idr rats People who must be present: Mahesh Jethanandani Kent Watsen Ignas Bagdonas Resources Requested: Special Requests: One of the key participants has requested for this WG session to be in the early part of the week, preferably Monday or Tuesday. --------------------------------------------------------- From nobody Sun Sep 8 16:36:10 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E14F7120086 for ; Sun, 8 Sep 2019 16:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 2nouEDbsDPWO for ; Sun, 8 Sep 2019 16:36:07 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 848B3120024 for ; Sun, 8 Sep 2019 16:36:07 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id f4so23961418ion.2 for ; Sun, 08 Sep 2019 16:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DfR/nNOXBQhMKztAtb1pFf2Y9GsJOpB5v9nF/PUrHIg=; b=JV7AOrJPWAMhCfAbZevzUie6/j8Czx4vajCBDCRJpMA+/60CGeK25mSX6P+xUoFVAi gECBEMB7twyoWYp+HELe/sfaWfBYIMkkHS1ZnF1HQ9Gg3p2gI++c+KtWrztcztVHhHB3 mNLkNnxqVSGyv33xIYiRTT0Kg1UO8hHsj3rq73JA6Sfx9hWeCHl6EbMqQtytAuIUBdkZ bVSY7UuRiz9fJDHG9Ns69E0yBdAwsXvZaMaYhviXMKVwGpzMJtX7RW7EbdzMdzct8eyZ Puvgm1HxPpJ5s2X0bLt7zuwHfMi6zr3Hc8kmfDXNw4Vg66j58/MYyhP3L18ZTg70QPpv XApw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DfR/nNOXBQhMKztAtb1pFf2Y9GsJOpB5v9nF/PUrHIg=; b=IBcz2KiT2QWw1ri2ZmhkHPfHUyT3HVBPwzECf50fNHaeSuMQywmo/AJ550VxbhlXtr /qMs5Lq1m/YnUUd327YoozEwrhRAUnv6xmzNesjETFR93roOxXF+GHFHESPK9Q9TMH8T hgkQ8zBBS7femyHrhlPCG6EAq4hqc2J2nSXbLXjVsleFv7uXFSvsFCsTwByrt+MF7X2z M0UgXr0R8afJor6gDSOIANHf5xQM1yF1HPn6fdCyo84Ryawr6iYxre3+/pELtmp0UunI Dph4W/FSlvoRkKttUK/FIeJpXc+K11F0YiKSEDZfATPt1l7juGkVhyfu21yVM7w8rxOC UCyQ== X-Gm-Message-State: APjAAAXdcLz5XILGgYd9ywAD3Xw/v2mO+MmHMA+IYa+08RN0oco0c4oF TEsFmBjVW5YWeygdJbhRiREP9/XkhCcOwi8TZEM= X-Google-Smtp-Source: APXvYqx/M+ElVbo6Tkf3wvWA3qzC9x/x26U+Im6PlN1wsczrCTCcvY9JZW016/TFMA1uNiQiQI+fkDt8GHz+2ZPAFsU= X-Received: by 2002:a02:b882:: with SMTP id p2mr22892354jam.16.1567985766700; Sun, 08 Sep 2019 16:36:06 -0700 (PDT) MIME-Version: 1.0 References: <0100016ccff35064-9da3c8b6-263c-47f6-a4f2-4db9495bc8b7-000000@email.amazonses.com> In-Reply-To: <0100016ccff35064-9da3c8b6-263c-47f6-a4f2-4db9495bc8b7-000000@email.amazonses.com> From: Xufeng Liu Date: Sun, 8 Sep 2019 19:35:55 -0400 Message-ID: To: Kent Watsen Cc: "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a31b37059213225d" Archived-At: Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2019 23:36:10 -0000 --000000000000a31b37059213225d Content-Type: text/plain; charset="UTF-8" Support the adoption. Thanks, - Xufeng On Mon, Aug 26, 2019 at 6:03 PM Kent Watsen wrote: > This email begins a 2-week adoption poll for: > > https://tools.ietf.org/html/draft-mahesh-netconf-https-notif-00 > > In-room support for this draft was noted but, as always, it is necessary > to confirm WG consensus on the list. If interested in the WG defining an > HTTPS-based solution for *configured subscriptions* (for which there are > none to date), please voice your support for this draft's adoption. If > objecting, please state your reasons. > > PS: Authors, please additionally respond to as if there is any IPR to > disclose. > > Kent and Mahesh // as chairs > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000a31b37059213225d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Support the adoption.
Thanks,
- X= ufeng

On Mon, Aug 26, 2019 at 6:03 PM Kent Watsen <kent+ietf@watsen.net&g= t; wrote:
<= div>This email begins a 2-week = adoption poll for:

=C2=A0 =C2=A0=C2=A0https://tools.ietf.org/html/draft-m= ahesh-netconf-https-notif-00

In-room supp= ort for this draft was noted but, as always, it is necessary to confirm WG = consensus on the list.=C2=A0 If interested in the WG defining an HTTPS-base= d solution for *configured subscriptions* (for which there are none to date= ), please=C2=A0voice your support for this draft's ad= option.=C2=A0 If objecting, please state your reasons. =C2=A0
<= div>

PS: Authors, please a= dditionally respond to as if there is any IPR to disclose.

Kent and Mahesh // as chairs
______= _________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000a31b37059213225d-- From nobody Mon Sep 9 13:40:35 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FAB120020 for ; Mon, 9 Sep 2019 13:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.023 X-Spam-Level: X-Spam-Status: No, score=-2.023 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, SPF_NONE=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=futurewei.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 eCfb_IUsc2Nv for ; Mon, 9 Sep 2019 13:40:31 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-eopbgr800092.outbound.protection.outlook.com [40.107.80.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21DAB12001A for ; Mon, 9 Sep 2019 13:40:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VowPNCUcC1nacihP/3zBZFMMml0o/MxEVV5pY6r7Pzc75HWyQKpyZ4VnIVEvD28W8tEresyyQORbGWW0ft1gmAo8tA8FkW7Mil6ww0NUWsLioWTix0gkAvPdl0q19B1ZxOlEnAoe520hL8kT95WqbWYe3/F7oTdvFNs98iBAg07EGY2FzYAZmFqq30vGSDbwrXFl1q8O2NggpuqJsaYDhTKmdPm9IgnGRw/8sA47VpXmUK3D7qtE57HqtKgQg0ea35ncntiR2wtNvWuNU7qGybx99GXC+XjC7YDP+uRALmG7lfu4IbmcY/9jIsaifwzg48/LblB8x7QolcTlNjaChw== 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=3RbT6WuUk1FKuVStsBsKjrjePN1PaCRX7XHasiV/sBg=; b=PMHGQ2jhTKjj/PHpPnTGdQX7xpHlqVnIf8RWTC9ILbBj/VKsr22WP4ngGbzlq6z0/x8KmHuL1IRR2fBvQZkZZCS4zO4cWbQTyRmtAaLcoYwbFicrJUxkA3bpzXt6UGa+T2u0E4S8aPRuXPYFDoCVyRr1Oh/rA0nrHsPxEUFHq4pcJ8yCxOEyRCB0/mQLF17E+/9ifft7/u9J6oPaDFqmepM0bKIjrFdDlVxFw2KlfjEfEq/ZvGwEaNZyytd9llmXfgvvsd3uEQWlm5/Dl5R/ikd0j5R3+CH2VlKtstBsXKVgdOJvAq6D68VIO8D8EpxnmpL4YLFUdkuEtScq6ZAlxA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3RbT6WuUk1FKuVStsBsKjrjePN1PaCRX7XHasiV/sBg=; b=EmxATqhfZpZBJakjgtpWDfKnAba45Vi5pyvOBby6oJ2QXbu8NU63dLnqK5BOxw/9wpiLUPUGZrrUXeUaRLVNiy9gUTHtWYxEmR3eXxEHbFthwwd2/KVRhALAZDAA+oAf6ZJp9ihI8b0gyfloFXHqbe4bT0DiXKk4F4AI1VqJjRg= Received: from BYAPR13MB2296.namprd13.prod.outlook.com (52.135.229.14) by BYAPR13MB2775.namprd13.prod.outlook.com (20.178.238.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.7; Mon, 9 Sep 2019 20:40:28 +0000 Received: from BYAPR13MB2296.namprd13.prod.outlook.com ([fe80::b074:b87f:8cc2:20fb]) by BYAPR13MB2296.namprd13.prod.outlook.com ([fe80::b074:b87f:8cc2:20fb%7]) with mapi id 15.20.2263.005; Mon, 9 Sep 2019 20:40:28 +0000 From: Alexander Clemm To: "Eric Voit (evoit)" , Kent Watsen , Mahesh Jethanandani CC: "netconf@ietf.org" Thread-Topic: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 Thread-Index: AQHVXFoF1JLX5XWF20GBl+HLnnfsu6caF/6AgAnLn2A= Date: Mon, 9 Sep 2019 20:40:28 +0000 Message-ID: References: <0100016ccff35064-9da3c8b6-263c-47f6-a4f2-4db9495bc8b7-000000@email.amazonses.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=alex@futurewei.com; x-originating-ip: [12.111.81.95] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6ed66543-c8b9-4381-e455-08d73565f363 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR13MB2775; x-ms-traffictypediagnostic: BYAPR13MB2775: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01559F388D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39850400004)(396003)(346002)(376002)(366004)(136003)(189003)(199004)(53546011)(66946007)(76116006)(110136005)(33656002)(14454004)(66556008)(66476007)(3846002)(2906002)(790700001)(6116002)(99286004)(7696005)(966005)(7736002)(8676002)(478600001)(316002)(66446008)(64756008)(74316002)(14444005)(86362001)(606006)(71200400001)(71190400001)(256004)(25786009)(81166006)(66066001)(486006)(6436002)(476003)(186003)(6306002)(26005)(102836004)(4326008)(446003)(229853002)(55016002)(236005)(9686003)(6506007)(8936002)(76176011)(5660300002)(11346002)(6246003)(53936002)(54896002)(52536014)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR13MB2775; H:BYAPR13MB2296.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ZFYA6YhiotfUtvbouvlONp7TsdlNodQJvCOEy+je5gcgUJYeFxDS79TCtISRvQpjT58SYkHns6rF+3E3qjXuDiAsgzksEm2oGTcCS8dtO58C/KVEXQ/DAk2r9UUu60nPv9BuyzmJ3zFm+UKAOfPO2FQhvgl9nGmU+8uY5WoUJcUfnCf2gDEsNMdJ/UTbH6t/ZKjlEIaHE1bcUOkJHFNVM2Ya28/K0f/mmDJ76ak2QhGnnP/SBW74PWfutosjTtPpvb0ifILIdgFEaWGLf3Jyfnaa065HUWSv3/riACQ0j9Hq6i/grivFw/MDvSVsu8mgVtAflrZ6xBLv7sSIBaT67WICaYf8WMIk0HUmr0AjI+ymt4ybRMabInsxBa74PprGTmwT2ngJTaJaZBDQM6vestbczLPLJBtF6LyHp4fssKY= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR13MB2296EF1D3A2EC47AD57FAA89DBB70BYAPR13MB2296namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6ed66543-c8b9-4381-e455-08d73565f363 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2019 20:40:28.5364 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: AGDAWlYHVQJuZGYyZUL8CP5W5d0spqi/g4L8itGrUB/qBswTVUYr51RnB0S7dezBJodqTQcZziuCP/3vjqWTgQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR13MB2775 Archived-At: Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2019 20:40:34 -0000 --_000_BYAPR13MB2296EF1D3A2EC47AD57FAA89DBB70BYAPR13MB2296namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support the adoption as well. --- Alex From: netconf On Behalf Of Eric Voit (evoit) Sent: Tuesday, September 03, 2019 8:01 AM To: Kent Watsen ; Mahesh Jethanandani Cc: netconf@ietf.org Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-0= 0 I support the adoption. Building upon that, there are a few elements which would be good to conside= r in future iterations. (1) Understanding the capabilities of the configured receiver is important= . One or more publishers of configured subscriptions could be used to over= whelm a receiver which doesn't even support subscriptions. This document= should include ways to ensure a configured stream won't be established wit= h an endpoint unequipped to deal with the inbound notifications. As a star= ting point for these discussions, there are mechanisms in draft-ietf-netcon= f-restconf-notif v5 to address this. E.g., the HTTP transport augmentati= on on the receiver must send an "HTTP OK" to a "subscription-started" notif= ication before the publisher starts streaming any subscribed content. (2) Multiple versions of draft-ietf-netconf-restconf-notif include topics/= text which might be useful, even as an appendix. For example Section B.2 = of v5 includes example config operations and interaction models. Side comment: there are advantages in subscriptions over HTTP2 transports,= which I don't believe it will be covered in this draft. GRPC has the abil= ity to optimize based its leverage of HTTP2. To examples from draft-ietf= -netconf-restconf-notif v5 which are good to think about are: (a) optimizing multiple configured subscription streams to a single receive= r (such as a controller). (b) it can be easier overwhelm a receiver which is unable to control or han= dle the volume of Event Notifications received It would be good to somehow capture the implications of using different und= erlying HTTP capabilities as part of these discussions. Thanks, Eric From: netconf > O= n Behalf Of Kent Watsen Sent: Monday, August 26, 2019 6:02 PM To: netconf@ietf.org Subject: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 This email begins a 2-week adoption poll for: https://tools.ietf.org/html/draft-mahesh-netconf-https-notif-00 In-room support for this draft was noted but, as always, it is necessary to= confirm WG consensus on the list. If interested in the WG defining an HTT= PS-based solution for *configured subscriptions* (for which there are none = to date), please voice your support for this draft's adoption. If objectin= g, please state your reasons. PS: Authors, please additionally respond to as if there is any IPR to discl= ose. Kent and Mahesh // as chairs --_000_BYAPR13MB2296EF1D3A2EC47AD57FAA89DBB70BYAPR13MB2296namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support the adoption as well. 

--- Alex

 

From: netconf <netconf-bounces@ietf.org>= ; On Behalf Of Eric Voit (evoit)
Sent: Tuesday, September 03, 2019 8:01 AM
To: Kent Watsen <kent+ietf@watsen.net>; Mahesh Jethanandan= i <mjethanandani@gmail.com>
Cc: netconf@ietf.org
Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-= notif-00

 

I support the adoption.

 

Building upon that, there are a few elements which w= ould be good to consider in future iterations.

 

(1)  Understanding the capabilities of the conf= igured receiver is important.  One or more publishers of configured su= bscriptions could be used to overwhelm a receiver which doesn't even suppor= t subscriptions.    This document should include ways to ensure a configured stream won't be established with an endpoint u= nequipped to deal with the inbound notifications.  As a starting point= for these discussions, there are mechanisms in draft-ietf-netconf-restconf= -notif v5 to address this.   E.g., the  HTTP transport augmentation on the receiver must send an "HTTP = OK" to a "subscription-started" notification before the publ= isher starts streaming any subscribed content.

 

(2)  Multiple versions of draft-ietf-netconf-re= stconf-notif include topics/text which might be useful, even as an appendix= .   For example Section B.2 of v5 includes example config operati= ons and interaction models.

 

Side comment:  there are advantages in subscrip= tions over HTTP2 transports, which I don't believe it will be covered in th= is draft.  GRPC has the ability to optimize based its leverage of HTTP= 2.    To examples from draft-ietf-netconf-restconf-notif v5 which are good to think about are:

(a) optimizing multiple configured subscription stre= ams to a single receiver (such as a controller).

(b) it can be easier overwhelm a receiver which is u= nable to control or handle the volume of Event Notifications received 

It would be good to somehow capture the implications= of using different underlying HTTP capabilities as part of these discussio= ns.

 

Thanks,

Eric

 

From: netconf <netconf-bounces@ietf.org> On Behalf Of Kent Watsen
Sent: Monday, August 26, 2019 6:02 PM
To: netconf@ietf.org
Subject: [netconf] Adoption Call for draft-mahesh-netconf-https-noti= f-00

 

This email begins a 2-week adoption poll for:

 

    https://tools.ietf.org/html/d= raft-mahesh-netconf-https-notif-00

In-room support for this draft was noted but, as alwa= ys, it is necessary to confirm WG consensus on the list.  If intereste= d in the WG defining an HTTPS-based solution for *configured subscriptions* (for which there are none to date), please voice your = support for this draft's adoption.  If objecting, please state your re= asons.  

 

PS: Authors, please additionally respond to as if the= re is any IPR to disclose.


Kent and Mahesh // as chairs

--_000_BYAPR13MB2296EF1D3A2EC47AD57FAA89DBB70BYAPR13MB2296namp_-- From nobody Mon Sep 9 15:15:28 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74CB12003F for ; Mon, 9 Sep 2019 15:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 xcBeHsStFTAd for ; Mon, 9 Sep 2019 15:15:23 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 7F97D120013 for ; Mon, 9 Sep 2019 15:15:23 -0700 (PDT) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id CDCBFD4825F6DADC532A; Mon, 9 Sep 2019 23:15:20 +0100 (IST) Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 9 Sep 2019 23:15:20 +0100 Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 9 Sep 2019 23:15:20 +0100 Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Mon, 9 Sep 2019 23:15:19 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0439.000; Tue, 10 Sep 2019 06:15:14 +0800 From: Tianran Zhou To: Alexander Clemm , "Eric Voit (evoit)" , Kent Watsen , Mahesh Jethanandani CC: netconf Thread-Topic: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 Thread-Index: AQHVZ1wNaJDIFQ93NESUh5lnPdOP/Q== Date: Mon, 9 Sep 2019 22:15:13 +0000 Message-ID: References: <0100016ccff35064-9da3c8b6-263c-47f6-a4f2-4db9495bc8b7-000000@email.amazonses.com> , In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F21BEFAEF40NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2019 22:15:27 -0000 --_000_BBA82579FD347748BEADC4C445EA0F21BEFAEF40NKGEML515MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IHRoZSBhZG9wdGlvbi4NCg0KVGlhbnJhbg0KDQoNCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KU2VudCBmcm9tIFdlTGluaw0KDQq3orz+yMujuiBBbGV4YW5k ZXIgQ2xlbW08YWxleEBmdXR1cmV3ZWkuY29tPG1haWx0bzphbGV4QGZ1dHVyZXdlaS5jb20+Pg0K ytW8/sjLo7ogRXJpYyBWb2l0IChldm9pdCk8ZXZvaXRAY2lzY28uY29tPG1haWx0bzpldm9pdEBj aXNjby5jb20+PjtLZW50IFdhdHNlbjxrZW50K2lldGZAd2F0c2VuLm5ldDxtYWlsdG86a2VudCtp ZXRmQHdhdHNlbi5uZXQ+PjtNYWhlc2ggSmV0aGFuYW5kYW5pPG1qZXRoYW5hbmRhbmlAZ21haWwu Y29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4+DQqzrcvNo7ogbmV0Y29uZjxuZXRj b25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPj4NCtb3zOKjuiBSZTogW25ldGNv bmZdIEFkb3B0aW9uIENhbGwgZm9yIGRyYWZ0LW1haGVzaC1uZXRjb25mLWh0dHBzLW5vdGlmLTAw DQrKsbzko7ogMjAxOS0wOS0xMCAwNDo0MDo1OQ0KDQpJIHN1cHBvcnQgdGhlIGFkb3B0aW9uIGFz IHdlbGwuDQotLS0gQWxleA0KDQpGcm9tOiBuZXRjb25mIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5v cmc+IE9uIEJlaGFsZiBPZiBFcmljIFZvaXQgKGV2b2l0KQ0KU2VudDogVHVlc2RheSwgU2VwdGVt YmVyIDAzLCAyMDE5IDg6MDEgQU0NClRvOiBLZW50IFdhdHNlbiA8a2VudCtpZXRmQHdhdHNlbi5u ZXQ+OyBNYWhlc2ggSmV0aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCkNjOiBu ZXRjb25mQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW25ldGNvbmZdIEFkb3B0aW9uIENhbGwgZm9y IGRyYWZ0LW1haGVzaC1uZXRjb25mLWh0dHBzLW5vdGlmLTAwDQoNCkkgc3VwcG9ydCB0aGUgYWRv cHRpb24uDQoNCkJ1aWxkaW5nIHVwb24gdGhhdCwgdGhlcmUgYXJlIGEgZmV3IGVsZW1lbnRzIHdo aWNoIHdvdWxkIGJlIGdvb2QgdG8gY29uc2lkZXIgaW4gZnV0dXJlIGl0ZXJhdGlvbnMuDQoNCigx KSAgVW5kZXJzdGFuZGluZyB0aGUgY2FwYWJpbGl0aWVzIG9mIHRoZSBjb25maWd1cmVkIHJlY2Vp dmVyIGlzIGltcG9ydGFudC4gIE9uZSBvciBtb3JlIHB1Ymxpc2hlcnMgb2YgY29uZmlndXJlZCBz dWJzY3JpcHRpb25zIGNvdWxkIGJlIHVzZWQgdG8gb3ZlcndoZWxtIGEgcmVjZWl2ZXIgd2hpY2gg ZG9lc24ndCBldmVuIHN1cHBvcnQgc3Vic2NyaXB0aW9ucy4gICAgVGhpcyBkb2N1bWVudCBzaG91 bGQgaW5jbHVkZSB3YXlzIHRvIGVuc3VyZSBhIGNvbmZpZ3VyZWQgc3RyZWFtIHdvbid0IGJlIGVz dGFibGlzaGVkIHdpdGggYW4gZW5kcG9pbnQgdW5lcXVpcHBlZCB0byBkZWFsIHdpdGggdGhlIGlu Ym91bmQgbm90aWZpY2F0aW9ucy4gIEFzIGEgc3RhcnRpbmcgcG9pbnQgZm9yIHRoZXNlIGRpc2N1 c3Npb25zLCB0aGVyZSBhcmUgbWVjaGFuaXNtcyBpbiBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNv bmYtbm90aWYgdjUgdG8gYWRkcmVzcyB0aGlzLiAgIEUuZy4sIHRoZSAgSFRUUCB0cmFuc3BvcnQg YXVnbWVudGF0aW9uIG9uIHRoZSByZWNlaXZlciBtdXN0IHNlbmQgYW4gIkhUVFAgT0siIHRvIGEg InN1YnNjcmlwdGlvbi1zdGFydGVkIiBub3RpZmljYXRpb24gYmVmb3JlIHRoZSBwdWJsaXNoZXIg c3RhcnRzIHN0cmVhbWluZyBhbnkgc3Vic2NyaWJlZCBjb250ZW50Lg0KDQooMikgIE11bHRpcGxl IHZlcnNpb25zIG9mIGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1ub3RpZiBpbmNsdWRlIHRv cGljcy90ZXh0IHdoaWNoIG1pZ2h0IGJlIHVzZWZ1bCwgZXZlbiBhcyBhbiBhcHBlbmRpeC4uICAg Rm9yIGV4YW1wbGUgU2VjdGlvbiBCLjIgb2YgdjUgaW5jbHVkZXMgZXhhbXBsZSBjb25maWcgb3Bl cmF0aW9ucyBhbmQgaW50ZXJhY3Rpb24gbW9kZWxzLg0KDQpTaWRlIGNvbW1lbnQ6ICB0aGVyZSBh cmUgYWR2YW50YWdlcyBpbiBzdWJzY3JpcHRpb25zIG92ZXIgSFRUUDIgdHJhbnNwb3J0cywgd2hp Y2ggSSBkb24ndCBiZWxpZXZlIGl0IHdpbGwgYmUgY292ZXJlZCBpbiB0aGlzIGRyYWZ0LiAgR1JQ QyBoYXMgdGhlIGFiaWxpdHkgdG8gb3B0aW1pemUgYmFzZWQgaXRzIGxldmVyYWdlIG9mIEhUVFAy LiAgICBUbyBleGFtcGxlcyBmcm9tIGRyYWZ0LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1ub3RpZiB2 NSB3aGljaCBhcmUgZ29vZCB0byB0aGluayBhYm91dCBhcmU6DQooYSkgb3B0aW1pemluZyBtdWx0 aXBsZSBjb25maWd1cmVkIHN1YnNjcmlwdGlvbiBzdHJlYW1zIHRvIGEgc2luZ2xlIHJlY2VpdmVy IChzdWNoIGFzIGEgY29udHJvbGxlcikuDQooYikgaXQgY2FuIGJlIGVhc2llciBvdmVyd2hlbG0g YSByZWNlaXZlciB3aGljaCBpcyB1bmFibGUgdG8gY29udHJvbCBvciBoYW5kbGUgdGhlIHZvbHVt ZSBvZiBFdmVudCBOb3RpZmljYXRpb25zIHJlY2VpdmVkDQpJdCB3b3VsZCBiZSBnb29kIHRvIHNv bWVob3cgY2FwdHVyZSB0aGUgaW1wbGljYXRpb25zIG9mIHVzaW5nIGRpZmZlcmVudCB1bmRlcmx5 aW5nIEhUVFAgY2FwYWJpbGl0aWVzIGFzIHBhcnQgb2YgdGhlc2UgZGlzY3Vzc2lvbnMuDQoNClRo YW5rcywNCkVyaWMNCg0KRnJvbTogbmV0Y29uZiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgS2VudCBXYXRzZW4N ClNlbnQ6IE1vbmRheSwgQXVndXN0IDI2LCAyMDE5IDY6MDIgUE0NClRvOiBuZXRjb25mQGlldGYu b3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0KU3ViamVjdDogW25ldGNvbmZdIEFkb3B0aW9u IENhbGwgZm9yIGRyYWZ0LW1haGVzaC1uZXRjb25mLWh0dHBzLW5vdGlmLTAwDQoNClRoaXMgZW1h aWwgYmVnaW5zIGEgMi13ZWVrIGFkb3B0aW9uIHBvbGwgZm9yOg0KDQogICAgaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1haGVzaC1uZXRjb25mLWh0dHBzLW5vdGlmLTAwPGh0dHBz Oi8vbmFtMDMuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUy RiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LW1haGVzaC1uZXRjb25mLWh0dHBzLW5v dGlmLTAwJmRhdGE9MDIlN0MwMSU3Q2FsZXglNDBmdXR1cmV3ZWkuY29tJTdDMTZhMmRjMTgwNmI3 NGUzNWFkMDMwOGQ3MzA3ZjhjNzQlN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVkYyU3 QzElN0MwJTdDNjM3MDMxMTk2Njg5NzQxODUzJnNkYXRhPXpkUmg0VTJvNTdXJTJGMGpjVEFhUHQ0 ckVpYSUyRkZ6ZTREYm9xOE1kVEZ2b3lBJTNEJnJlc2VydmVkPTA+DQpJbi1yb29tIHN1cHBvcnQg Zm9yIHRoaXMgZHJhZnQgd2FzIG5vdGVkIGJ1dCwgYXMgYWx3YXlzLCBpdCBpcyBuZWNlc3Nhcnkg dG8gY29uZmlybSBXRyBjb25zZW5zdXMgb24gdGhlIGxpc3QuICBJZiBpbnRlcmVzdGVkIGluIHRo ZSBXRyBkZWZpbmluZyBhbiBIVFRQUy1iYXNlZCBzb2x1dGlvbiBmb3IgKmNvbmZpZ3VyZWQgc3Vi c2NyaXB0aW9ucyogKGZvciB3aGljaCB0aGVyZSBhcmUgbm9uZSB0byBkYXRlKSwgcGxlYXNlIHZv aWNlIHlvdXIgc3VwcG9ydCBmb3IgdGhpcyBkcmFmdCdzIGFkb3B0aW9uLiAgSWYgb2JqZWN0aW5n LCBwbGVhc2Ugc3RhdGUgeW91ciByZWFzb25zLg0KDQpQUzogQXV0aG9ycywgcGxlYXNlIGFkZGl0 aW9uYWxseSByZXNwb25kIHRvIGFzIGlmIHRoZXJlIGlzIGFueSBJUFIgdG8gZGlzY2xvc2UuDQoN CktlbnQgYW5kIE1haGVzaCAvLyBhcyBjaGFpcnMNCg== --_000_BBA82579FD347748BEADC4C445EA0F21BEFAEF40NKGEML515MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
I support the adopti= on.

Tianran




Sent from WeLink

=B7=A2=BC=FE=C8=CB=A3=BA Alexander Clemm<alex@futurewei.com>
=CA=D5=BC=FE=C8=CB=A3=BA Eric Voit (evoit)<evoit@cisco.com>;Kent Watsen<kent+ietf@watsen.net>;Mahesh Jethanand= ani<mjethanandani@gmail.com>
=D6=F7=CC=E2=A3=BA Re: [netconf] Adoption Call for draft-mahesh= -netconf-https-notif-00
=CA=B1=BC=E4=A3=BA 2019-09-10 04:40:59

I support the adoption as well. 

--- Alex

 

From: netconf <netconf-bounces@ietf.org>= ; On Behalf Of Eric Voit (evoit)
Sent: Tuesday, September 03, 2019 8:01 AM
To: Kent Watsen <kent+ietf@watsen.net>; Mahesh Jethanandan= i <mjethanandani@gmail.com>
Cc: netconf@ietf.org
Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-= notif-00

 

I support the adoption.

 

Building upon that, there are a few elements which w= ould be good to consider in future iterations.

 

(1)  Understanding the capabilities of the conf= igured receiver is important.  One or more publishers of configured su= bscriptions could be used to overwhelm a receiver which doesn't even suppor= t subscriptions.    This document should include ways to ensure a configured stream won't be established with an endpoint u= nequipped to deal with the inbound notifications.  As a starting point= for these discussions, there are mechanisms in draft-ietf-netconf-restconf= -notif v5 to address this.   E.g., the  HTTP transport augmentation on the receiver must send an "HTTP = OK" to a "subscription-started" notification before the publ= isher starts streaming any subscribed content.

 

(2)  Multiple versions of draft-ietf-netconf-re= stconf-notif include topics/text which might be useful, even as an appendix= ..   For example Section B.2 of v5 includes example config operat= ions and interaction models.

 

Side comment:  there are advantages in subscrip= tions over HTTP2 transports, which I don't believe it will be covered in th= is draft.  GRPC has the ability to optimize based its leverage of HTTP= 2.    To examples from draft-ietf-netconf-restconf-notif v5 which are good to think about are:

(a) optimizing multiple configured subscription stre= ams to a single receiver (such as a controller).

(b) it can be easier overwhelm a receiver which is u= nable to control or handle the volume of Event Notifications received 

It would be good to somehow capture the implications= of using different underlying HTTP capabilities as part of these discussio= ns.

 

Thanks,

Eric

 

From: netconf <netconf-bounces@ietf.org> On Behalf Of Kent Watsen
Sent: Monday, August 26, 2019 6:02 PM
To: netconf@ietf.org
Subject: [netconf] Adoption Call for draft-mahesh-netconf-https-noti= f-00

 

This email begins a 2-week adoption poll for:

 

    https://tools.ietf.org/html/d= raft-mahesh-netconf-https-notif-00

In-room support for this draft was noted but, as alw= ays, it is necessary to confirm WG consensus on the list.  If interest= ed in the WG defining an HTTPS-based solution for *configured subscriptions* (for which there are none to date), please voice your = support for this draft's adoption.  If objecting, please state your re= asons.  

 

PS: Authors, please additionally respond to as if th= ere is any IPR to disclose.


Kent and Mahesh // as chairs

--_000_BBA82579FD347748BEADC4C445EA0F21BEFAEF40NKGEML515MBXchi_-- From nobody Mon Sep 9 18:05:43 2019 Return-Path: <0100016d18b462b3-38420cd3-1259-47ea-aa1b-f250a8238c9b-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA25120033 for ; Mon, 9 Sep 2019 18:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 ESPEbj-24exQ for ; Mon, 9 Sep 2019 18:05:39 -0700 (PDT) Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C7A0120024 for ; Mon, 9 Sep 2019 18:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568077538; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=efDrcRE5mgjXUk6Qu9Onu3m07XCJgWN+DBq5vuxlJFU=; b=AKvPK6w4f7FB+PGjLRUYbqvvOL4CmMPT71Hq7vxXqqvOc6ZDF7QwRU8wC4awYdSw noH3BRQU8kZ70fy4bE/+LbPkLD7XwW8mDoNexgMaBjA2E0fanlr3Iv4tmBPwJ9SvxQs cipSgsKTtp89INQDrO9+LQczqYOEm4Q2PUD1mmbg= From: Kent Watsen Message-ID: <0100016d18b462b3-38420cd3-1259-47ea-aa1b-f250a8238c9b-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F707A7ED-FD87-4DC2-897F-BE6114381922" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 10 Sep 2019 01:05:38 +0000 In-Reply-To: <20190827.091531.2170309439792906317.mbj@tail-f.com> Cc: "netconf@ietf.org" To: Martin Bjorklund References: <0100016ccff35064-9da3c8b6-263c-47f6-a4f2-4db9495bc8b7-000000@email.amazonses.com> <20190827.091531.2170309439792906317.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.10-54.240.8.32 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2019 01:05:42 -0000 --Apple-Mail=_F707A7ED-FD87-4DC2-897F-BE6114381922 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, Mahesh reminded me that this message still needs a response... > I think that defining a "simple" protocol for notification delivery > only is an interesting problem to work on. However, this document > doesn't define this protocol. It just says "https". But how is the > client supposed to deliver the notifs? PUT? POST? To which uri? > Further, it doesn't discuss authorization at all (which "user" will be > used for NACM checks of the notifications?) Many good points here. Firstly, while ietf-http-client defines HTTP "basic" authentication = parameters, the example in the I-D didn't show them, even though the = YANG module uses the ietf-http-client module. That said, = ietf-http-client fails to define a "path" field, so that appears to be = something that should be added to it (to your point about it being good = to have a user of the client-server drafts to validate the design). = Thusly that part of the example in the I-D should be: foo my-receiver.my-domain.com 443 explicitly-trusted-server-ca-certs explicitly-trusted-server-certs my-name my-passsord /some/path For high-availability, note that ietf-tcp-client defines the = "remote-address" field as follows: leaf remote-address { type inet:host; mandatory true; description "The IP address or hostname of the remote peer to establish a connection with. If a domain name is configured, then the DNS resolution should happen on each connection attempt. If the DNS resolution results in multiple IP addresses, the IP addresses are tried according to local preference order until a connection has been established or until all IP addresses have failed."; } As for the HTTP operation and request body, POST-ing a stream of = notifications seems right. Assuming `notification` statements ("foo", "bar", and "baz") are defined = in a module called "my-foobar-module" (with xmlns = "https://example.com/my-foobar-module"), an example HTTP/1.1 = notification-delivery message might be (blank lines added for = readability): POST /some/path HTTP/1.1 Host: my-receiver.my-domain.com Content-Type: application/yang-data+xml 2019-03-22T12:35:00Z ... 2019-03-22T12:35:00Z ... 2019-03-22T12:35:00Z ... With response: HTTP/1.1 204 No Content Date: Thu, 26 Jan 2017 20:56:30 GMT Server: my-receiver.my-domain.com Thoughts? Kent --Apple-Mail=_F707A7ED-FD87-4DC2-897F-BE6114381922 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Martin,

Mahesh = reminded me that this message still needs a response...


I think that = defining a "simple" protocol for notification delivery
only = is an interesting problem to work on.  However, this document
doesn't define this protocol.  It just says "https". =  But how is the
client supposed to deliver the = notifs?  PUT?  POST?  To which uri?
Further, = it doesn't discuss authorization at all (which "user" will be
used for NACM checks of the notifications?)

Many = good points here.

Firstly, while = ietf-http-client defines HTTP "basic" authentication parameters, the = example in the I-D didn't show them, even though the YANG module uses = the ietf-http-client module.  That said, ietf-http-client fails to = define a "path" field, so that appears to be something that should be = added to it (to your point about it being good to have a user of the = client-server drafts to validate the design).  Thusly that part of = the example in the I-D should be:

  <receivers
    =   = xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-https-notif">
      <receiver>
        = <name>foo</name>
      =   <tcp-params>
      =     <remote-address>my-receiver.my-domain.com</remote-address>
          = <remote-port>443</remote-port>
  =       </tcp-params>
  =       <tls-params>
  =         <server-authentication>
            = <ca-certs>explicitly-trusted-server-ca-certs</ca-certs>
<= div class=3D"">            = <server-certs>explicitly-trusted-server-certs</server-certs>
          = </server-authentication>
      =   </tls-params>
      =   <http-params>
      =     <client-identity>
      =       <basic>
    =         =   <user-id>my-name</user-id>
  =           =   <password>my-passsord</password>
          =   </basic>
        =  </client-identity>
      =    <path>/some/path</path>
        = <http-params>
      = </receiver>
  = </receivers>


For high-availability, note that = ietf-tcp-client defines the "remote-address" field as = follows:

    leaf = remote-address {
      type = inet:host;
      mandatory true;
      description
  =       "The IP address or hostname of the remote peer = to
         establish a = connection with.  If a domain name is
  =        configured, then the DNS resolution should = happen on
         each = connection attempt.  If the DNS resolution
  =        results in multiple IP addresses, the IP = addresses
         are tried = according to local preference order until
    =      a connection has been established or until all IP
         addresses have failed.";
    }


As for the HTTP = operation and request body, POST-ing a stream of notifications seems = right.

Assuming `notification` = statements ("foo", "bar", and "baz") are defined in a module called = "my-foobar-module" (with xmlns "https://example.com/my-foobar-module"), an example = HTTP/1.1 notification-delivery message might be (blank lines added for = readability):


    POST /some/path HTTP/1.1
    Host: my-receiver.my-domain.com
    = Content-Type: application/yang-data+xml

    <notification
  =     = xmlns=3D"urn:ietf:params:xml:ns:netconf:notification:1.0">
      = <eventTime>2019-03-22T12:35:00Z</eventTime>
      <foo xmlns=3D"https://example.com/my-foobar-module">
  =       ...
      = </foo>
    </notification>

    = <notification
      = xmlns=3D"urn:ietf:params:xml:ns:netconf:notification:1.0">
      = <eventTime>2019-03-22T12:35:00Z</eventTime>
      <bar xmlns=3D"https://example.com/my-foobar-module">
        ...
    =   </bar>
    = </notification>

    <notification
  =     = xmlns=3D"urn:ietf:params:xml:ns:netconf:notification:1.0">
      = <eventTime>2019-03-22T12:35:00Z</eventTime>
      <baz xmlns=3D"https://example.com/my-foobar-module">
        ...
    =   </baz>
    </notification>


With = response:

  =     HTTP/1.1 204 No Content
    =   Date: Thu, 26 Jan 2017 20:56:30 GMT
  =     Server: my-receiver.my-domain.com


Thoughts?

Kent



= --Apple-Mail=_F707A7ED-FD87-4DC2-897F-BE6114381922-- From nobody Mon Sep 9 22:13:46 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C5612081E; Mon, 9 Sep 2019 22:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 CFgujzxzovhp; Mon, 9 Sep 2019 22:13:38 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64D0812081A; Mon, 9 Sep 2019 22:13:38 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D1121B81CDC; Mon, 9 Sep 2019 22:13:36 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, netconf@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190910051336.D1121B81CDC@rfc-editor.org> Date: Mon, 9 Sep 2019 22:13:36 -0700 (PDT) Archived-At: Subject: [netconf] =?utf-8?q?RFC_8639_on_Subscription_to_YANG_Event_Notif?= =?utf-8?q?ications?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2019 05:13:40 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8639 Title: Subscription to YANG Notifications Author: E. Voit, A. Clemm, A. Gonzalez Prieto, E. Nilsen-Nygaard, A. Tripathy Status: Standards Track Stream: IETF Date: September 2019 Mailbox: evoit@cisco.com, ludwig@clemm.org, alberto.gonzalez@microsoft.com, einarnn@cisco.com, ambtripa@cisco.com Pages: 77 Characters: 160549 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netconf-subscribed-notifications-26.txt URL: https://www.rfc-editor.org/info/rfc8639 DOI: 10.17487/RFC8639 This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request and receive a continuous, customized feed of publisher-generated information. This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Sep 9 22:14:06 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B0212088F; Mon, 9 Sep 2019 22:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 uOPTXgcRTLNb; Mon, 9 Sep 2019 22:13:49 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF8F7120888; Mon, 9 Sep 2019 22:13:49 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 67D95B81CE7; Mon, 9 Sep 2019 22:13:48 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, netconf@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190910051348.67D95B81CE7@rfc-editor.org> Date: Mon, 9 Sep 2019 22:13:48 -0700 (PDT) Archived-At: Subject: [netconf] =?utf-8?q?RFC_8640_on_Dynamic_Subscription_to_YANG_Eve?= =?utf-8?q?nts_and_Datastores_over_NETCONF?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2019 05:13:57 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8640 Title: Dynamic Subscription to YANG Events and Datastores over NETCONF Author: E. Voit, A. Clemm, A. Gonzalez Prieto, E. Nilsen-Nygaard, A. Tripathy Status: Standards Track Stream: IETF Date: September 2019 Mailbox: evoit@cisco.com, ludwig@clemm.org, alberto.gonzalez@microsoft.com, einarnn@cisco.com, ambtripa@cisco.com Pages: 19 Characters: 34177 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netconf-netconf-event-notifications-22.txt URL: https://www.rfc-editor.org/info/rfc8640 DOI: 10.17487/RFC8640 This document provides a Network Configuration Protocol (NETCONF) binding to the dynamic subscription capability of both subscribed notifications and YANG-Push. This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Sep 9 22:14:12 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCAE12089A; Mon, 9 Sep 2019 22:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 DfGHLk0fx0at; Mon, 9 Sep 2019 22:13:55 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9318F120899; Mon, 9 Sep 2019 22:13:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 04C61B81CEC; Mon, 9 Sep 2019 22:13:54 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, netconf@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190910051354.04C61B81CEC@rfc-editor.org> Date: Mon, 9 Sep 2019 22:13:54 -0700 (PDT) Archived-At: Subject: [netconf] =?utf-8?q?RFC_8641_on_Subscription_to_YANG_Notificatio?= =?utf-8?q?ns_for_Datastore_Updates?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2019 05:14:02 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8641 Title: Subscription to YANG Notifications for Datastore Updates Author: A. Clemm, E. Voit Status: Standards Track Stream: IETF Date: September 2019 Mailbox: ludwig@clemm.org, evoit@cisco.com Pages: 58 Characters: 120700 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netconf-yang-push-25.txt URL: https://www.rfc-editor.org/info/rfc8641 DOI: 10.17487/RFC8641 This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state. This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Sep 10 00:08:39 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D170E120089 for ; Tue, 10 Sep 2019 00:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 xwE4g6FOZ-OV for ; Tue, 10 Sep 2019 00:08:30 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1673712004F for ; Tue, 10 Sep 2019 00:08:30 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id E0D121AE0187; Tue, 10 Sep 2019 09:08:27 +0200 (CEST) Date: Tue, 10 Sep 2019 09:08:03 +0200 (CEST) Message-Id: <20190910.090803.448863675820254782.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016d18b462b3-38420cd3-1259-47ea-aa1b-f250a8238c9b-000000@email.amazonses.com> References: <0100016ccff35064-9da3c8b6-263c-47f6-a4f2-4db9495bc8b7-000000@email.amazonses.com> <20190827.091531.2170309439792906317.mbj@tail-f.com> <0100016d18b462b3-38420cd3-1259-47ea-aa1b-f250a8238c9b-000000@email.amazonses.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2019 07:08:33 -0000 Kent Watsen wrote: > Hi Martin, > > Mahesh reminded me that this message still needs a response... Hmm, I have apparently missed this. I was wondering why noone replied to my comments ;-) > > I think that defining a "simple" protocol for notification delivery > > only is an interesting problem to work on. However, this document > > doesn't define this protocol. It just says "https". But how is the > > client supposed to deliver the notifs? PUT? POST? To which uri? > > Further, it doesn't discuss authorization at all (which "user" will be > > used for NACM checks of the notifications?) > > Many good points here. > > Firstly, while ietf-http-client defines HTTP "basic" authentication > parameters, the example in the I-D didn't show them, even though the > YANG module uses the ietf-http-client module. I am not sure what this reply means exactly. My comment about authorization above was for outgoing notifications (section 3.4.6 in RFC 8341). I.e., the device needs a local username for the configured subscription. > That said, > ietf-http-client fails to define a "path" field, so that appears to be > something that should be added to it I don't think 'path' belongs in http-client; not all http client configs require a 'path' (e.g. restconf uses it's own mechanism wih ".well-known"). > (to your point about it being > good to have a user of the client-server drafts to validate the > design). Thusly that part of the example in the I-D should be: > > xmlns="urn:ietf:params:xml:ns:yang:ietf-https-notif"> > > foo > > my-receiver.my-domain.com > 443 > > > > explicitly-trusted-server-ca-certs > explicitly-trusted-server-certs > > > > > > my-name > my-passsord > > > /some/path > > > > > > For high-availability, note that ietf-tcp-client defines the > "remote-address" field as follows: > > leaf remote-address { > type inet:host; > mandatory true; > description > "The IP address or hostname of the remote peer to > establish a connection with. If a domain name is > configured, then the DNS resolution should happen on > each connection attempt. If the DNS resolution > results in multiple IP addresses, the IP addresses > are tried according to local preference order until > a connection has been established or until all IP > addresses have failed."; > } > > > As for the HTTP operation and request body, POST-ing a stream of > notifications seems right. Yes POST seems right. I'm not so sure about the streaming though. Perhaps pipelining is the right mechanism. For "bulk" sending, the "bundled-message" defined in draft-ietf-netconf-notification-messages seems right. My point is that the document needs quite a lot of work, and I think that the WG should spend its energy on getting the "client-server" documents ready. NOTE again that I do think that this is good work, and we should work on it, the sooner the better (but after the existing documents). /martin > Assuming `notification` statements ("foo", "bar", and "baz") are > defined in a module called "my-foobar-module" (with xmlns > "https://example.com/my-foobar-module"), an example HTTP/1.1 > notification-delivery message might be (blank lines added for > readability): > > > POST /some/path HTTP/1.1 > Host: my-receiver.my-domain.com > Content-Type: application/yang-data+xml > > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > 2019-03-22T12:35:00Z > > ... > > > > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > 2019-03-22T12:35:00Z > > ... > > > > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > 2019-03-22T12:35:00Z > > ... > > > > > With response: > > HTTP/1.1 204 No Content > Date: Thu, 26 Jan 2017 20:56:30 GMT > Server: my-receiver.my-domain.com > > > Thoughts? > > Kent > > > From nobody Tue Sep 10 14:05:26 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96742120255 for ; Tue, 10 Sep 2019 14:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 eeYO4b0JAlT6 for ; Tue, 10 Sep 2019 14:05:23 -0700 (PDT) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D32D41200A1 for ; Tue, 10 Sep 2019 14:05:22 -0700 (PDT) Received: by mail-qt1-x844.google.com with SMTP id v11so22483413qto.13 for ; Tue, 10 Sep 2019 14:05:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=5eIDkh1Dz9PiPH6kqdQEgz3b8O8z479HSmV8cpbbC+o=; b=WCTZ52KwYm7hugtctspgj4tIz0rKy/tDL9SJ6do1y8zfmNNQcpVPgpNVcf04bFiyPF 2yeambaJLQTNlR7Gk1Qw9cWTvH2FMKwTFXvpCyFT+9gfOCRJwga76NwWzv55olUJvMGe xyQZwlN05sNcjR+meO8LKeAh2IrPP1QGA1T3y/T85z4k3vumLKksKlkr4hBQN9WIE6aB wa265LQdmKwPpd9I6yUBU4qyzngrORi9kSZtstUzHN17g5RTYuV/1EHcIudeN+yzwAIN JWg4CB2+Ed7m2HVyNHgl3gt4NJypamXLsHR7+RF6cU4QthpblZTJDj2NKNdyBM1z2ZR4 TPnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5eIDkh1Dz9PiPH6kqdQEgz3b8O8z479HSmV8cpbbC+o=; b=lIxu6tjXm4bnAjFefmfClwYzn/yqE0uCKoT1wZUvV+19bWuNAC/14ukSpxy6fdAFtm 9jT8xmPemkSj98SG4seL9t2hSmoBVEitPEMtoS1nDWSuA/UDmV4ldJU7T83y1l41WYg+ +cbBCJkZCanc+lldqI/gDqItsoMMZREzmDBT80TPDRt6zVzsZFDadfcMaltT/QOuGkHN /og8ee/j54oW0mzdILEnmOKdU3oqNJWQpypYBEVhcGUMxyVfldAPMwIH0yALxSK2eSyl Ib1qMuEO++7eJfbbW4vaZPeFPVX2Fu6xWX9JB3Qk1x7HPy/LwxLMTRYRvP5c0jAQG1Y/ sBfA== X-Gm-Message-State: APjAAAXQJVMQsPOOsPjSgAJDgtnVNB+PZPF3ST3wAQyHqi0wCVETHTYR +emX5IhG3yKxzYWObDe6hNPHmmN5fMpU4E0m4xCE9bYlQfc= X-Google-Smtp-Source: APXvYqwU68DW0pxKQm5YC0v2iuAFHrNhHlZeiVQMjTC/jQMs8ro/rTLzMXBRuhKFk1rpQbioMpBnZAUFpk9udkG+H4M= X-Received: by 2002:aed:2f42:: with SMTP id l60mr30638561qtd.315.1568149521152; Tue, 10 Sep 2019 14:05:21 -0700 (PDT) MIME-Version: 1.0 From: Warren Kumari Date: Tue, 10 Sep 2019 17:04:45 -0400 Message-ID: To: netconf@ietf.org, Ignas Bagdonas , Alissa Cooper Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [netconf] Results of "Adoption Call for draft-mahesh-netconf-https-notif-00" X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2019 21:05:25 -0000 Hi there all, As both Netconf chairs are also authors of draft-mahesh-netconf-https-notif, they felt that it was inappropriate for them to also call consensus on this adoptionI'd suggest that the chair deputize a WG participant to make and needed consensus calls which may , and so have asked me to do so. I've reviewed the meeting video, the minutes, and also the call for adoption thread (I wasn't subscribed to the mailing list, and so I read it on the archives, and cannot reply to the original thread). I view there being consensus for adoption of this document -- authors, please resubmit as draft-ietf-netconf-... I'd also suggest that the chair deputize a WG participant to make and needed consensus calls which may come up during progression of the document. As noted by Kent in https://mailarchive.ietf.org/arch/msg/netconf/ndUBag_lngpt5nyBVol-CylPQpE, Martin made a number of good points -- not sure if you'd like to address there before or after submitting the WG version of the document. There was also a view that the WG should be focusing on getting the client-server work done -- this seems like a fine idea, but I think that, if the authors have time, they can work on this in parallel... Thank you all, W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Tue Sep 10 15:39:32 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A40512006B for ; Tue, 10 Sep 2019 15:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.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 RtmFgluS1DuQ for ; Tue, 10 Sep 2019 15:39:28 -0700 (PDT) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53910120019 for ; Tue, 10 Sep 2019 15:39:28 -0700 (PDT) Received: by mail-pf1-x434.google.com with SMTP id y22so12413511pfr.3 for ; Tue, 10 Sep 2019 15:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=/g68koUEbGm/Ij/NMdcRNTlxLajZnsnakAw0cxx6p5U=; b=nl/AVCbFOhMOsSdev2GJZuEHQr2wn0lam7wVG6+5vvsMy0tcbutCSG62nWZG7sVjRz KeXNqVOM+Nh3YERcczqyuZOdu0OeJQGNPzeYZZ2as0fZGCD2cuxzZ52qXQRwYBgGjzuN ZJi2srd33rtosinImcs0oaZDHagIzCBgTLy539EVYTA8V1KP0KAlDsQgTIVmRGC5Kws2 Q9EcTqYAQaYBCf+jywpLilkYwQUjkj3ys9bwGEPlzugy+lvNT2Gc7+DUKoJ7Yx8Y5h8O 1M/zPlIyfhyKt2m5jYinKLTd4TQezksVx0AY3WQgVD7D2b9IRDJyLsstJICNy1l+tsRZ ja2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=/g68koUEbGm/Ij/NMdcRNTlxLajZnsnakAw0cxx6p5U=; b=ucqNYGTmhqGDYOLxXDd9VK+2KCRLWiFkBUpcArIlxwnduCQ68UEZb9KW4FQtHKAJlX b9BQ6Mx7v8Yz3nTa6F3b1qfj9wbYXcC6xDVBj19/QnrxsUB90dMdrpRaY9yNuc4ytzvw 8ez+EQZzTgK32zs/PPINq9HsQweCVgkOWDY1qMU1j2lqm01/aOvWpLLBkVQJn+eD4vi0 T1dcHS/DHBjLajJwda7OoBIOPmR4rCWtZB6sdFtbgKQsOTXsA1o41G4lUCx7LXARSFJf c/lYPnGkYLynynmWfDTfiQdINJYdQ0mZItipPuvOx1e9az6uIcnIBj8glpzcvkEQVxLD z9Mg== X-Gm-Message-State: APjAAAVhIvsopM3ZFKIjAzsob0kSeCZLlmwYAGG2ZVG7pH8g8WPfQmXF m0gNKcVbCykyWPQvafkB8KoPjv6T X-Google-Smtp-Source: APXvYqwVnSdUQHAGaLX0DADeqQxAU/BmUC138a48xee6FdnrnAdzA/T/uIHFW41zidn2hShmvAYC2g== X-Received: by 2002:a65:66c8:: with SMTP id c8mr3433954pgw.318.1568155167376; Tue, 10 Sep 2019 15:39:27 -0700 (PDT) Received: from [10.33.122.240] ([66.170.99.1]) by smtp.gmail.com with ESMTPSA id j7sm19898413pfi.96.2019.09.10.15.39.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Sep 2019 15:39:26 -0700 (PDT) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_06C1CFC5-2629-4122-8841-82542ECDF8F8" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: Date: Tue, 10 Sep 2019 15:39:26 -0700 To: Netconf X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [netconf] WGLC for draft-ietf-netconf-notification-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2019 22:39:30 -0000 --Apple-Mail=_06C1CFC5-2629-4122-8841-82542ECDF8F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Authors have published -04 = version of the draft, which addresses comments they received in IETF = 105. If you provided comments please check to make sure your comments = have been addressed. At this point, the authors believe that the = document is ready for WGLC. This therefore starts a two week LC, ending on September 24th. Please = provide any technical comments you might have on the document. If you = believe the document is not ready for LC, please state your reasons. We will issue a IPR poll separately.=20 Mahesh & Kent (as co-chairs) --Apple-Mail=_06C1CFC5-2629-4122-8841-82542ECDF8F8 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Authors have published -04 version of the draft, which addresses comments they received in IETF 105. If you provided comments please check to make sure your comments have been addressed. At this point, the authors believe that the document is ready for WGLC.

This therefore starts a two week LC, ending on September 24th. Please provide any technical comments you might have on the document. If you believe the document is not ready for LC, please state your reasons.

We will issue a IPR poll separately. 

Mahesh & Kent (as co-chairs)



--Apple-Mail=_06C1CFC5-2629-4122-8841-82542ECDF8F8-- From nobody Tue Sep 10 18:10:58 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5781208BA for ; Tue, 10 Sep 2019 18:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 h4Q0GzkwzXAd for ; Tue, 10 Sep 2019 18:10:48 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 23B2F12084A for ; Tue, 10 Sep 2019 18:10:48 -0700 (PDT) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 2CCAF668F3A8CBB74E0A; Wed, 11 Sep 2019 02:10:46 +0100 (IST) Received: from lhreml704-chm.china.huawei.com (10.201.108.53) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 11 Sep 2019 02:10:45 +0100 Received: from lhreml704-chm.china.huawei.com (10.201.108.53) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Wed, 11 Sep 2019 02:10:45 +0100 Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Wed, 11 Sep 2019 02:10:45 +0100 Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.20]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0439.000; Wed, 11 Sep 2019 09:10:40 +0800 From: Qin Wu To: Mahesh Jethanandani , Netconf Thread-Topic: [netconf] WGLC for draft-ietf-netconf-notification-capabilities Thread-Index: AdVoPX4GqtZOaS4LR8qYtgUDtxKZ8Q== Date: Wed, 11 Sep 2019 01:10:39 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.31.203] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA92F6FCFdggeml511mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 01:10:56 -0000 --_000_B8F9A780D330094D99AF023C5877DABAA92F6FCFdggeml511mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VwcG9ydCB0byBtb3ZlIHRoaXMgd29yayBmb3J3YXJkLCAgb25lIHF1aWNrIHF1ZXN0aW9uIGlz DQpTaW5jZSB5b3UgaGF2ZSBkYXRhc3RvcmUgbGV2ZWwgYW5kIG5vZGUgbGV2ZWwgY2FwYWJpbGl0 eSwgSXMgdGhlcmUgYW55IHJlYXNvbiB3aHkgbW9kdWxlIGxldmVsIGNhcGFiaWxpdHkgaXMgbm90 IGluY2x1ZGVkPw0KDQotUWluDQq3orz+yMs6IG5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5j ZXNAaWV0Zi5vcmddILT6se0gTWFoZXNoIEpldGhhbmFuZGFuaQ0Kt6LLzcqxvOQ6IDIwMTnE6jnU wjExyNUgNjozOQ0KytW8/sjLOiBOZXRjb25mIDxuZXRjb25mQGlldGYub3JnPg0K1vfM4jogW25l dGNvbmZdIFdHTEMgZm9yIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tY2FwYWJpbGl0 aWVzDQoNCkF1dGhvcnMgaGF2ZSBwdWJsaXNoZWQgLTA0PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLWNhcGFiaWxpdGllcy0wND4gdmVy c2lvbiBvZiB0aGUgZHJhZnQsIHdoaWNoIGFkZHJlc3NlcyBjb21tZW50cyB0aGV5IHJlY2VpdmVk IGluIElFVEYgMTA1LiBJZiB5b3UgcHJvdmlkZWQgY29tbWVudHMgcGxlYXNlIGNoZWNrIHRvIG1h a2Ugc3VyZSB5b3VyIGNvbW1lbnRzIGhhdmUgYmVlbiBhZGRyZXNzZWQuIEF0IHRoaXMgcG9pbnQs IHRoZSBhdXRob3JzIGJlbGlldmUgdGhhdCB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIFdHTEMu DQoNClRoaXMgdGhlcmVmb3JlIHN0YXJ0cyBhIHR3byB3ZWVrIExDLCBlbmRpbmcgb24gU2VwdGVt YmVyIDI0dGguIFBsZWFzZSBwcm92aWRlIGFueSB0ZWNobmljYWwgY29tbWVudHMgeW91IG1pZ2h0 IGhhdmUgb24gdGhlIGRvY3VtZW50LiBJZiB5b3UgYmVsaWV2ZSB0aGUgZG9jdW1lbnQgaXMgbm90 IHJlYWR5IGZvciBMQywgcGxlYXNlIHN0YXRlIHlvdXIgcmVhc29ucy4NCg0KV2Ugd2lsbCBpc3N1 ZSBhIElQUiBwb2xsIHNlcGFyYXRlbHkuDQoNCk1haGVzaCAmIEtlbnQgKGFzIGNvLWNoYWlycykN Cg0KDQoNCg== --_000_B8F9A780D330094D99AF023C5877DABAA92F6FCFdggeml511mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Support to move this w= ork forward,  one quick question is

Since you have datasto= re level and node level capability, Is there any reason why module level ca= pability is not included?

 

-Qin=

=B7=A2=BC=FE=C8=CB: netconf [mailt= o:netconf-bounces@ietf.org] =B4=FA=B1=ED Mahesh Jethanandani
=B7=A2=CB=CD=CA=B1=BC=E4:<= /span> 2019=C4=EA9=D4=C211=C8=D5 6:39
=CA=D5=BC=FE=C8=CB: Netconf <netconf@ietf.org>
=D6=F7=CC=E2: [netconf] WGLC for draft-ietf-netconf-notification-capabilities

 

Authors have published -04 version of the draft, which addresses comments they = received in IETF 105. If you provided comments please check to make sure your comments have been addressed. At this point, the a= uthors believe that the document is ready for WGLC.

 

This therefore starts a two wee= k LC, ending on September 24th. Please provide any technical comments you m= ight have on the document. If you believe the document is not ready for LC,= please state your reasons.

 

We will issue a IPR poll separa= tely. 

 

Mahesh & Kent (as co-chairs= )

 

 

 

--_000_B8F9A780D330094D99AF023C5877DABAA92F6FCFdggeml511mbxchi_-- From nobody Tue Sep 10 18:55:21 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB08120273 for ; Tue, 10 Sep 2019 18:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 8Lvq-U--CgvI for ; Tue, 10 Sep 2019 18:55:16 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 7CC9D1200E0 for ; Tue, 10 Sep 2019 18:55:16 -0700 (PDT) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 3B049D860075F181FAD8; Wed, 11 Sep 2019 02:55:14 +0100 (IST) Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 11 Sep 2019 02:55:13 +0100 Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Wed, 11 Sep 2019 02:55:13 +0100 Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Wed, 11 Sep 2019 02:55:13 +0100 Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.20]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0439.000; Wed, 11 Sep 2019 09:55:06 +0800 From: Qin Wu To: Warren Kumari , "netconf@ietf.org" , Ignas Bagdonas , Alissa Cooper Thread-Topic: [netconf] Results of "Adoption Call for draft-mahesh-netconf-https-notif-00" Thread-Index: AdVoPgUMJ6y89+PdQdOCN3TjxhUq6w== Date: Wed, 11 Sep 2019 01:55:06 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.31.203] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Results of "Adoption Call for draft-mahesh-netconf-https-notif-00" X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 01:55:19 -0000 QWdyZWUgd2l0aCBXYXJyZW4ncyBzdWdnZXN0aW9uLiBJIGFsc28gYmVsaWV2ZSB0aGlzIHdvcmsg Y2FuIGJlIHByb2dyZXNzZWQgaW4gcGFyYWxsZWwgd2l0aCBjbGllbnQgc2VydmVyIG1vZGVsIGRy YWZ0LCBhdCBsZWFzdCBUQ1AgY2xpZW50IHNlcnZlciAsIFRMUyBjbGllbnQgc2VydmVyIG1vZGVs IGRyYWZ0LiANClRoZSBtb2RlbCBkZWZpbmVkIGluIHRoZXNlIGRvY3VtZW50cyBjYW4gYmUgZnVy dGhlciByZXVzZWQgaW4gTkVUQ09ORiBjbGllbnQgc2VydmVyIG1vZGVsIGRyYWZ0IGFuZCBSRVNU Q09ORiBjbGllbnQgc2VydmVyIG1vZGVsIGRyYWZ0LiANCldoYXQgaXMgdHJpY2t5IGlzIHdoZXJl IGRvZXMgaWV0Zi1odHRwLWNsaWVudCBjb21lIGZyb20/IEl0IHNlZW1zIHRvIG1lIGl0IGNvbWUg ZnJvbSBkcmFmdC1rd2F0c2VuLW5ldGNvbmYtaHR0cC1jbGllbnQtc2VydmVyLTAzLCB3aGljaCBp cyBzdGlsbCBhbiBpbmRpdmlkdWFsIGRyYWZ0Lg0KDQpJIGFsc28gYmVsaWV2ZSBNYXJ0aW4ncyBj b21tZW50cyBzaG91bGQgYmUgYWRkcmVzc2VkLg0KDQotUWluDQotLS0tLdPKvP7Urbz+LS0tLS0N CreivP7IyzogbmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBX YXJyZW4gS3VtYXJpDQq3osvNyrG85DogMjAxOcTqOdTCMTHI1SA1OjA1DQrK1bz+yMs6IG5ldGNv bmZAaWV0Zi5vcmc7IElnbmFzIEJhZ2RvbmFzIDxpYmFnZG9uYS5pZXRmQGdtYWlsLmNvbT47IEFs aXNzYSBDb29wZXIgPGFsaXNzYUBjb29wZXJ3LmluPg0K1vfM4jogW25ldGNvbmZdIFJlc3VsdHMg b2YgIkFkb3B0aW9uIENhbGwgZm9yIGRyYWZ0LW1haGVzaC1uZXRjb25mLWh0dHBzLW5vdGlmLTAw Ig0KDQpIaSB0aGVyZSBhbGwsDQoNCkFzIGJvdGggTmV0Y29uZiBjaGFpcnMgYXJlIGFsc28gYXV0 aG9ycyBvZiBkcmFmdC1tYWhlc2gtbmV0Y29uZi1odHRwcy1ub3RpZiwgdGhleSBmZWx0IHRoYXQg aXQgd2FzIGluYXBwcm9wcmlhdGUgZm9yIHRoZW0gdG8gYWxzbyBjYWxsIGNvbnNlbnN1cyBvbiB0 aGlzIGFkb3B0aW9uSSdkIHN1Z2dlc3QgdGhhdCB0aGUgY2hhaXIgZGVwdXRpemUgYSBXRyBwYXJ0 aWNpcGFudCB0byBtYWtlIGFuZCBuZWVkZWQgY29uc2Vuc3VzIGNhbGxzIHdoaWNoIG1heSAsIGFu ZCBzbyBoYXZlIGFza2VkIG1lIHRvIGRvIHNvLg0KDQpJJ3ZlIHJldmlld2VkIHRoZSBtZWV0aW5n IHZpZGVvLCB0aGUgbWludXRlcywgYW5kIGFsc28gdGhlIGNhbGwgZm9yIGFkb3B0aW9uIHRocmVh ZCAoSSB3YXNuJ3Qgc3Vic2NyaWJlZCB0byB0aGUgbWFpbGluZyBsaXN0LCBhbmQgc28gSSByZWFk IGl0IG9uIHRoZSBhcmNoaXZlcywgYW5kIGNhbm5vdCByZXBseSB0byB0aGUgb3JpZ2luYWwgdGhy ZWFkKS4gSSB2aWV3IHRoZXJlIGJlaW5nIGNvbnNlbnN1cyBmb3IgYWRvcHRpb24gb2YgdGhpcyBk b2N1bWVudCAtLSBhdXRob3JzLCBwbGVhc2UgcmVzdWJtaXQgYXMgZHJhZnQtaWV0Zi1uZXRjb25m LS4uLiAgSSdkIGFsc28gc3VnZ2VzdCB0aGF0IHRoZSBjaGFpciBkZXB1dGl6ZSBhIFdHIHBhcnRp Y2lwYW50IHRvIG1ha2UgYW5kIG5lZWRlZCBjb25zZW5zdXMgY2FsbHMgd2hpY2ggbWF5IGNvbWUg dXAgZHVyaW5nIHByb2dyZXNzaW9uIG9mIHRoZSBkb2N1bWVudC4NCg0KQXMgbm90ZWQgYnkgS2Vu dCBpbg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9uZXRjb25mL25kVUJh Z19sbmdwdDVueUJWb2wtQ3lsUFFwRSwNCk1hcnRpbiBtYWRlIGEgbnVtYmVyIG9mIGdvb2QgcG9p bnRzIC0tIG5vdCBzdXJlIGlmIHlvdSdkIGxpa2UgdG8gYWRkcmVzcyB0aGVyZSBiZWZvcmUgb3Ig YWZ0ZXIgc3VibWl0dGluZyB0aGUgV0cgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQuDQpUaGVyZSB3 YXMgYWxzbyBhIHZpZXcgdGhhdCB0aGUgV0cgc2hvdWxkIGJlIGZvY3VzaW5nIG9uIGdldHRpbmcg dGhlIGNsaWVudC1zZXJ2ZXIgd29yayBkb25lIC0tIHRoaXMgc2VlbXMgbGlrZSBhIGZpbmUgaWRl YSwgYnV0IEkgdGhpbmsgdGhhdCwgaWYgdGhlIGF1dGhvcnMgaGF2ZSB0aW1lLCB0aGV5IGNhbiB3 b3JrIG9uIHRoaXMgaW4gcGFyYWxsZWwuLi4NCg0KVGhhbmsgeW91IGFsbCwNClcNCg0KLS0NCkkg ZG9uJ3QgdGhpbmsgdGhlIGV4ZWN1dGlvbiBpcyByZWxldmFudCB3aGVuIGl0IHdhcyBvYnZpb3Vz bHkgYSBiYWQgaWRlYSBpbiB0aGUgZmlyc3QgcGxhY2UuDQpUaGlzIGlzIGxpa2UgcHV0dGluZyBy YWJpZCB3ZWFzZWxzIGluIHlvdXIgcGFudHMsIGFuZCBsYXRlciBleHByZXNzaW5nIHJlZ3JldCBh dCBoYXZpbmcgY2hvc2VuIHRob3NlIHBhcnRpY3VsYXIgcmFiaWQgd2Vhc2VscyBhbmQgdGhhdCBw YWlyIG9mIHBhbnRzLg0KICAgLS0tbWFmDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpuZXRjb25mIG1haWxpbmcgbGlzdA0KbmV0Y29uZkBpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo= From nobody Tue Sep 10 18:55:56 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7189D120273 for ; Tue, 10 Sep 2019 18:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 0_n__sqDFRS7 for ; Tue, 10 Sep 2019 18:55:53 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 5B9EC1200E0 for ; Tue, 10 Sep 2019 18:55:53 -0700 (PDT) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id D1F7F3C7AB9198936F5E for ; Wed, 11 Sep 2019 02:55:51 +0100 (IST) Received: from lhreml715-chm.china.huawei.com (10.201.108.66) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 11 Sep 2019 02:55:51 +0100 Received: from lhreml715-chm.china.huawei.com (10.201.108.66) by lhreml715-chm.china.huawei.com (10.201.108.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 11 Sep 2019 02:55:51 +0100 Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml715-chm.china.huawei.com (10.201.108.66) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Wed, 11 Sep 2019 02:55:51 +0100 Received: from DGGEMM527-MBX.china.huawei.com ([169.254.6.177]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0439.000; Wed, 11 Sep 2019 09:55:44 +0800 From: wangzitao To: Kent Watsen , "netconf@ietf.org" Thread-Topic: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 Thread-Index: AdVoQ89VzTpEtqqWS2+ny5Ww5i2YAA== Date: Wed, 11 Sep 2019 01:55:44 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.142.117] Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EA2DAF6B83DGGEMM527MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 01:55:56 -0000 --_000_E6BC9BBCBCACC246846FC685F9FF41EA2DAF6B83DGGEMM527MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgV0csDQoNCkkgc3VwcG9ydCB0aGUgYWRvcHRpb24uDQpJTUhPLCB0aGlzIG1vZGVsIGNhbiBi ZSB1c2VkIGluIGNhbGwtaG9tZSBzY2VuYXJpb3MsIGZvciBleGFtcGxlIHRoZSBzZXJ2ZXIgY2Fu IGluaXRpYXRlIGEgdHJhbnNwb3J0IHNlc3Npb24gdG8gdGhvc2UgcmVjZWl2ZXJzIGluIHRoZSBz dWJzY3JpcHRpb24gdXNpbmcgdGhlIGFkZHJlc3MgYW5kIHBvcnQgc3BlY2lmaWVkLg0KVGhlcmVm b3JlLCBJIHN1Z2dlc3QgdG8gYWRkIHNvbWUgYXR0cmlidXRlcywgc3VjaCBhcyBMaXN0ZW4gUG9y dCwgdG8gc3VwcG9ydCBjYWxsLWhvbWUuDQoNCkJlc3QgUmVnYXJkcyENCi1NaWNoYWVsDQoNCrei vP7IyzogbmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBLZW50 IFdhdHNlbg0Kt6LLzcqxvOQ6IDIwMTnE6jjUwjI3yNUgNjowMg0KytW8/sjLOiBuZXRjb25mQGll dGYub3JnDQrW98ziOiBbbmV0Y29uZl0gQWRvcHRpb24gQ2FsbCBmb3IgZHJhZnQtbWFoZXNoLW5l dGNvbmYtaHR0cHMtbm90aWYtMDANCg0KVGhpcyBlbWFpbCBiZWdpbnMgYSAyLXdlZWsgYWRvcHRp b24gcG9sbCBmb3I6DQoNCiAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFo ZXNoLW5ldGNvbmYtaHR0cHMtbm90aWYtMDANCkluLXJvb20gc3VwcG9ydCBmb3IgdGhpcyBkcmFm dCB3YXMgbm90ZWQgYnV0LCBhcyBhbHdheXMsIGl0IGlzIG5lY2Vzc2FyeSB0byBjb25maXJtIFdH IGNvbnNlbnN1cyBvbiB0aGUgbGlzdC4gIElmIGludGVyZXN0ZWQgaW4gdGhlIFdHIGRlZmluaW5n IGFuIEhUVFBTLWJhc2VkIHNvbHV0aW9uIGZvciAqY29uZmlndXJlZCBzdWJzY3JpcHRpb25zKiAo Zm9yIHdoaWNoIHRoZXJlIGFyZSBub25lIHRvIGRhdGUpLCBwbGVhc2Ugdm9pY2UgeW91ciBzdXBw b3J0IGZvciB0aGlzIGRyYWZ0J3MgYWRvcHRpb24uICBJZiBvYmplY3RpbmcsIHBsZWFzZSBzdGF0 ZSB5b3VyIHJlYXNvbnMuDQoNClBTOiBBdXRob3JzLCBwbGVhc2UgYWRkaXRpb25hbGx5IHJlc3Bv bmQgdG8gYXMgaWYgdGhlcmUgaXMgYW55IElQUiB0byBkaXNjbG9zZS4NCg0KS2VudCBhbmQgTWFo ZXNoIC8vIGFzIGNoYWlycw0K --_000_E6BC9BBCBCACC246846FC685F9FF41EA2DAF6B83DGGEMM527MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi WG,

 

I support the adoption= .

IMHO, this model can b= e used in call-home scenarios, for example the server can initiate a transp= ort session to those receivers in the subscription using the address and port specified.

Therefore, I suggest t= o add some attributes, such as Listen Port, to support call-home.

 

Best Regards!

-Michael

 

=B7=A2=BC=FE=C8=CB: netconf [mailt= o:netconf-bounces@ietf.org] =B4=FA=B1=ED Kent Watsen
=B7=A2=CB=CD=CA=B1=BC=E4:<= /span> 2019=C4=EA8=D4=C227=C8=D5 6:02
=CA=D5=BC=FE=C8=CB: netconf@ietf.org
=D6=F7=CC=E2: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00

 

This email begins a 2-week adoption poll for:

 

    https://tools.iet= f.org/html/draft-mahesh-netconf-https-notif-00

In-room support for this draft was noted but, as always,= it is necessary to confirm WG consensus on the list.  If interested i= n the WG defining an HTTPS-based solution for *configured subscriptions* (for which there are none to date), please = ;voice your support for this draft's adoption.  If objecting, please s= tate your reasons.  

 

PS: Authors, please additionally respond to as if there = is any IPR to disclose.


Kent and Mahesh // as chairs

--_000_E6BC9BBCBCACC246846FC685F9FF41EA2DAF6B83DGGEMM527MBXchi_-- From nobody Tue Sep 10 18:57:48 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1ED1207FE for ; Tue, 10 Sep 2019 18:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 zldI8UR_tHVJ for ; Tue, 10 Sep 2019 18:57:44 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 135771200E0 for ; Tue, 10 Sep 2019 18:57:44 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id B9F00C851679A73D0C49 for ; Wed, 11 Sep 2019 02:57:42 +0100 (IST) Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 11 Sep 2019 02:57:42 +0100 Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.20]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0439.000; Wed, 11 Sep 2019 09:57:36 +0800 From: Qin Wu To: "netconf@ietf.org" Thread-Topic: [netconf] RFC 8641 on Subscription to YANG Notifications for Datastore Updates Thread-Index: AdVoRCGEYQX207DsQyKyY2BUHzfgEQ== Date: Wed, 11 Sep 2019 01:57:35 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.31.203] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] RFC 8641 on Subscription to YANG Notifications for Datastore Updates X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 01:57:47 -0000 Q29uZ3JhdHVsYXRpb24gdG8gYXV0aG9ycyBvZiBZQU5HIFB1c2ggc2VyaWVzIGRyYWZ0cywgZ29v ZCBwcm9ncmVzcy4NCg0KLVFpbg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IG5ldGNvbmYg W21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gcmZjLWVkaXRvckByZmMtZWRp dG9yLm9yZw0Kt6LLzcqxvOQ6IDIwMTnE6jnUwjEwyNUgMTM6MTQNCsrVvP7IyzogaWV0Zi1hbm5v dW5jZUBpZXRmLm9yZzsgcmZjLWRpc3RAcmZjLWVkaXRvci5vcmcNCrOty806IGRyYWZ0cy11cGRh dGUtcmVmQGlhbmEub3JnOyBuZXRjb25mQGlldGYub3JnOyByZmMtZWRpdG9yQHJmYy1lZGl0b3Iu b3JnDQrW98ziOiBbbmV0Y29uZl0gUkZDIDg2NDEgb24gU3Vic2NyaXB0aW9uIHRvIFlBTkcgTm90 aWZpY2F0aW9ucyBmb3IgRGF0YXN0b3JlIFVwZGF0ZXMNCg0KQSBuZXcgUmVxdWVzdCBmb3IgQ29t bWVudHMgaXMgbm93IGF2YWlsYWJsZSBpbiBvbmxpbmUgUkZDIGxpYnJhcmllcy4NCg0KICAgICAg ICANCiAgICAgICAgUkZDIDg2NDENCg0KICAgICAgICBUaXRsZTogICAgICBTdWJzY3JpcHRpb24g dG8gWUFORyBOb3RpZmljYXRpb25zIGZvciANCiAgICAgICAgICAgICAgICAgICAgRGF0YXN0b3Jl IFVwZGF0ZXMgDQogICAgICAgIEF1dGhvcjogICAgIEEuIENsZW1tLA0KICAgICAgICAgICAgICAg ICAgICBFLiBWb2l0DQogICAgICAgIFN0YXR1czogICAgIFN0YW5kYXJkcyBUcmFjaw0KICAgICAg ICBTdHJlYW06ICAgICBJRVRGDQogICAgICAgIERhdGU6ICAgICAgIFNlcHRlbWJlciAyMDE5DQog ICAgICAgIE1haWxib3g6ICAgIGx1ZHdpZ0BjbGVtbS5vcmcsIA0KICAgICAgICAgICAgICAgICAg ICBldm9pdEBjaXNjby5jb20NCiAgICAgICAgUGFnZXM6ICAgICAgNTgNCiAgICAgICAgQ2hhcmFj dGVyczogMTIwNzAwDQogICAgICAgIFVwZGF0ZXMvT2Jzb2xldGVzL1NlZUFsc286ICAgTm9uZQ0K DQogICAgICAgIEktRCBUYWc6ICAgIGRyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1c2gtMjUudHh0 DQoNCiAgICAgICAgVVJMOiAgICAgICAgaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9y ZmM4NjQxDQoNCiAgICAgICAgRE9JOiAgICAgICAgMTAuMTc0ODcvUkZDODY0MQ0KDQpUaGlzIGRv Y3VtZW50IGRlc2NyaWJlcyBhIG1lY2hhbmlzbSB0aGF0IGFsbG93cyBzdWJzY3JpYmVyIGFwcGxp Y2F0aW9ucyB0byByZXF1ZXN0IGEgY29udGludW91cyBhbmQgY3VzdG9taXplZCBzdHJlYW0gb2Yg dXBkYXRlcyBmcm9tIGEgWUFORyBkYXRhc3RvcmUuICBQcm92aWRpbmcgc3VjaCB2aXNpYmlsaXR5 IGludG8gdXBkYXRlcyBlbmFibGVzIG5ldyBjYXBhYmlsaXRpZXMgYmFzZWQgb24gdGhlIHJlbW90 ZSBtaXJyb3JpbmcgYW5kIG1vbml0b3Jpbmcgb2YgY29uZmlndXJhdGlvbiBhbmQgb3BlcmF0aW9u YWwgc3RhdGUuDQoNClRoaXMgZG9jdW1lbnQgaXMgYSBwcm9kdWN0IG9mIHRoZSBOZXR3b3JrIENv bmZpZ3VyYXRpb24gV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCg0KVGhpcyBpcyBub3cgYSBQ cm9wb3NlZCBTdGFuZGFyZC4NCg0KU1RBTkRBUkRTIFRSQUNLOiBUaGlzIGRvY3VtZW50IHNwZWNp ZmllcyBhbiBJbnRlcm5ldCBTdGFuZGFyZHMgVHJhY2sgcHJvdG9jb2wgZm9yIHRoZSBJbnRlcm5l dCBjb21tdW5pdHksIGFuZCByZXF1ZXN0cyBkaXNjdXNzaW9uIGFuZCBzdWdnZXN0aW9ucyBmb3Ig aW1wcm92ZW1lbnRzLiAgUGxlYXNlIHJlZmVyIHRvIHRoZSBjdXJyZW50IGVkaXRpb24gb2YgdGhl IE9mZmljaWFsIEludGVybmV0IFByb3RvY29sIFN0YW5kYXJkcyAoaHR0cHM6Ly93d3cucmZjLWVk aXRvci5vcmcvc3RhbmRhcmRzKSBmb3IgdGhlIHN0YW5kYXJkaXphdGlvbiBzdGF0ZSBhbmQgc3Rh dHVzIG9mIHRoaXMgcHJvdG9jb2wuICBEaXN0cmlidXRpb24gb2YgdGhpcyBtZW1vIGlzIHVubGlt aXRlZC4NCg0KVGhpcyBhbm5vdW5jZW1lbnQgaXMgc2VudCB0byB0aGUgSUVURi1Bbm5vdW5jZSBh bmQgcmZjLWRpc3QgbGlzdHMuDQpUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUsIHNlZQ0KICBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lldGYtYW5ub3VuY2UNCiAgaHR0 cHM6Ly9tYWlsbWFuLnJmYy1lZGl0b3Iub3JnL21haWxtYW4vbGlzdGluZm8vcmZjLWRpc3QNCg0K Rm9yIHNlYXJjaGluZyB0aGUgUkZDIHNlcmllcywgc2VlIGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iu b3JnL3NlYXJjaCBGb3IgZG93bmxvYWRpbmcgUkZDcywgc2VlIGh0dHBzOi8vd3d3LnJmYy1lZGl0 b3Iub3JnL3JldHJpZXZlL2J1bGsNCg0KUmVxdWVzdHMgZm9yIHNwZWNpYWwgZGlzdHJpYnV0aW9u IHNob3VsZCBiZSBhZGRyZXNzZWQgdG8gZWl0aGVyIHRoZSBhdXRob3Igb2YgdGhlIFJGQyBpbiBx dWVzdGlvbiwgb3IgdG8gcmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZy4gIFVubGVzcyBzcGVjaWZp Y2FsbHkgbm90ZWQgb3RoZXJ3aXNlIG9uIHRoZSBSRkMgaXRzZWxmLCBhbGwgUkZDcyBhcmUgZm9y IHVubGltaXRlZCBkaXN0cmlidXRpb24uDQoNCg0KVGhlIFJGQyBFZGl0b3IgVGVhbQ0KQXNzb2Np YXRpb24gTWFuYWdlbWVudCBTb2x1dGlvbnMsIExMQw0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0Y29uZiBtYWlsaW5nIGxpc3QNCm5ldGNvbmZA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0K From nobody Tue Sep 10 20:39:07 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156EE120048 for ; Tue, 10 Sep 2019 20:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 HMsBhf4XyrMi for ; Tue, 10 Sep 2019 20:39:04 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 180F2120024 for ; Tue, 10 Sep 2019 20:39:04 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 580B1B81207; Tue, 10 Sep 2019 20:39:01 -0700 (PDT) To: andy@yumaworks.com, mbj@tail-f.com, kwatsen@juniper.net, ibagdona@gmail.com, warren@kumari.net, kent+ietf@watsen.net, mjethanandani@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: bill.wu@huawei.com, netconf@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190911033901.580B1B81207@rfc-editor.org> Date: Tue, 10 Sep 2019 20:39:01 -0700 (PDT) Archived-At: Subject: [netconf] [Technical Errata Reported] RFC8040 (5857) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 03:39:06 -0000 The following errata report has been submitted for RFC8040, "RESTCONF Protocol". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5857 -------------------------------------- Type: Technical Reported by: Qin WU Section: 3.1 Original Text ------------- The server might respond as follows: HTTP/1.1 200 OK Date: Thu, 26 Jan 2017 20:56:30 GMT Server: example-server Cache-Control: no-cache Last-Modified: Thu, 26 Jan 2017 16:00:14 GMT Content-Type: application/yang-data+json { "operations" : { "example-jukebox:play" : [null] } } Corrected Text -------------- The server might respond as follows: HTTP/1.1 200 OK Date: Thu, 26 Jan 2017 20:56:30 GMT Server: example-server Cache-Control: no-cache Last-Modified: Thu, 26 Jan 2017 16:00:14 GMT Content-Type: application/yang-data+json { "operations" :[ { "example-jukebox:play" : [null] } ]} Notes ----- Returned operations in the RESTCONF response should be an array of the particular type, therefore the brackets are needed to enclose a list of operations associated with example-jukebox. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8040 (draft-ietf-netconf-restconf-18) -------------------------------------- Title : RESTCONF Protocol Publication Date : January 2017 Author(s) : A. Bierman, M. Bjorklund, K. Watsen Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue Sep 10 21:02:44 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85606120108 for ; Tue, 10 Sep 2019 21:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 9kd1jKRf-287 for ; Tue, 10 Sep 2019 21:02:41 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1530B1200C7 for ; Tue, 10 Sep 2019 21:02:41 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4CD72B81289; Tue, 10 Sep 2019 21:02:38 -0700 (PDT) To: andy@yumaworks.com, mbj@tail-f.com, kwatsen@juniper.net, ibagdona@gmail.com, warren@kumari.net, kent+ietf@watsen.net, mjethanandani@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: bill.wu@huawei.com, netconf@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190911040238.4CD72B81289@rfc-editor.org> Date: Tue, 10 Sep 2019 21:02:38 -0700 (PDT) Archived-At: Subject: [netconf] [Technical Errata Reported] RFC8040 (5858) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 04:02:43 -0000 The following errata report has been submitted for RFC8040, "RESTCONF Protocol". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5858 -------------------------------------- Type: Technical Reported by: Qin WU Section: 5.3.1,5.3.2 Original Text ------------- GET /restconf/data/interfaces/interface=eth1 ?with-defaults=report-all-tagged HTTP/1.1 Host: example.com Accept: application/yang-data+xml GET /restconf/data/interfaces/interface=eth1\ ?with-defaults=report-all-tagged HTTP/1.1 Host: example.com Accept: application/yang-data+json Corrected Text -------------- GET /restconf/data/ietf-interfaces:interfaces/interface=eth1 ?with-defaults=report-all-tagged HTTP/1.1 Host: example.com Accept: application/yang-data+xml GET /restconf/data/ietf-interfaces:interfaces/interface=eth1\ ?with-defaults=report-all-tagged HTTP/1.1 Host: example.com Accept: application/yang-data+json Notes ----- Based on the rule defined in section 3.5.3 of RFC8040, the module name ietf-interface followed by a colon character (":") should be prepended to the node name interfaces. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8040 (draft-ietf-netconf-restconf-18) -------------------------------------- Title : RESTCONF Protocol Publication Date : January 2017 Author(s) : A. Bierman, M. Bjorklund, K. Watsen Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Tue Sep 10 21:55:51 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8CD12026E for ; Tue, 10 Sep 2019 21:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.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 1auorED7o4UF for ; Tue, 10 Sep 2019 21:55:48 -0700 (PDT) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCFE6120168 for ; Tue, 10 Sep 2019 21:55:47 -0700 (PDT) Received: by mail-pl1-x629.google.com with SMTP id s17so4698040plp.2 for ; Tue, 10 Sep 2019 21:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=WwZI5u3f+MYSUZUOdY+ccLLR2+hboO9Sk5xl7ftZGOg=; b=jP0itzzxwyMItyS9WYxS3HWFGGNVomCdwjs5D4jO3cxWx7kSL1ZCdZ45DgJFxOZn0C bKNKJyBpw51fShJlImv6I0Q2dnFs1LKQcLoWZRLA4VDlQ69F/Z+z0aYc2lDNj4kf8JYy EqrMS2cAdSGVAd9wAbU1VjtveOfsX5CQf1PqRAxtjepgoZDqUXTSgj/nK4O83wDySQbX yrKeM7RovAOvo0vwf+awIJ21O7Jj1UF5L3yFL+IOlcVnoii7GwMcr/pqZfS0SCNmmtRB 1JB9qnFHUC6hAwFODOlERrFebAI7efF8rTKtzfNEu9sSf4SKSGD5S+18Nb39dAit2i3c ywrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=WwZI5u3f+MYSUZUOdY+ccLLR2+hboO9Sk5xl7ftZGOg=; b=F1f7byOk8RHiABDaD1q7HsTp1Zu8sng5Vb3dHe4WF7CnUKHiFNr1ta7KnqpwsiSgjX Hey/qXQirS27U81KIwyDPhmyJxvy/o2EkQb99ONDQOtUxlngcLgkSePdctz1vuzQV+78 DQGI+D78jiRfYaFCn1Sa/QUVea3LITpaU+tZS86SimUZzy/aa2rcXbRqBNsxGYaKDRR4 +z0yAe3p1cdXTIGhHuLa865arNpZto2fSY8cm6S7hs2eNGlFwUD/rtIbh8wtiAJUqkVN zw67nIPUNocTpxoT+eK3P18K4AgmpRPi3xbV051KIpgKIjXbpMz34rSAjXee5EEtK+HQ NK3g== X-Gm-Message-State: APjAAAXFMgx7uA01YXu7yAHMqFIKb6sfT6aP2zpg2AoyfngyiVhNwvoI f+0IpQq81hbrkm6XxtyhhPw= X-Google-Smtp-Source: APXvYqw1BiYUnqSLWi0I5u7wgMIAcYZeqASfHkpMFLlq3+8rgYQn+9ZOmjSeeCSgArXA9dQhyl4Esg== X-Received: by 2002:a17:902:ba96:: with SMTP id k22mr16604999pls.219.1568177747367; Tue, 10 Sep 2019 21:55:47 -0700 (PDT) Received: from ?IPv6:2601:647:5600:5020:6d00:42da:b8bb:6fe4? ([2601:647:5600:5020:6d00:42da:b8bb:6fe4]) by smtp.gmail.com with ESMTPSA id y14sm16533390pge.7.2019.09.10.21.55.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Sep 2019 21:55:46 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <29622E5B-7E1B-4123-8282-6E2816109E84@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FDFD8157-E840-4A89-9DAB-653E44B91D46" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 10 Sep 2019 21:55:44 -0700 In-Reply-To: Cc: netconf@ietf.org, Ignas Bagdonas , Alissa Cooper To: Warren Kumari References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [netconf] Results of "Adoption Call for draft-mahesh-netconf-https-notif-00" X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 04:55:50 -0000 --Apple-Mail=_FDFD8157-E840-4A89-9DAB-653E44B91D46 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Sep 10, 2019, at 2:04 PM, Warren Kumari wrote: >=20 > As noted by Kent in > = https://mailarchive.ietf.org/arch/msg/netconf/ndUBag_lngpt5nyBVol-CylPQpE = , > Martin made a number of good points -- not sure if you'd like to > address there before or after submitting the WG version of the > document. Thanks Warren. In principal, we the authors, agree with the comments provided by = Martin, and we plan to address them. Since the individual draft (-00) was polled for adoption, I like to = publish the same draft as a WG item to establish the base version before = making changes. Unless there is a objection against that, that is = exactly what we will do. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_FDFD8157-E840-4A89-9DAB-653E44B91D46 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Sep 10, 2019, at 2:04 PM, Warren Kumari <warren@kumari.net> = wrote:

As noted by Kent in
https://mailarchive.ietf.org/arch/msg/netconf/ndUBag_lngpt5nyBV= ol-CylPQpE,
Martin made a number of good = points -- not sure if you'd like to
address there before or after submitting the WG version of = the
document.

Thanks Warren.

In principal, we the authors, agree with the comments = provided by Martin, and we plan to address them.

Since the individual draft (-00) was = polled for adoption, I like to publish the same draft as a WG item to = establish the base version before making changes. Unless there is a = objection against that, that is exactly what we will do.

Mahesh Jethanandani



= --Apple-Mail=_FDFD8157-E840-4A89-9DAB-653E44B91D46-- From nobody Tue Sep 10 22:07:00 2019 Return-Path: <0100016d1eb7a7c3-6db38fa6-1c81-45ae-a907-dadb52a5bf78-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15C3120168 for ; Tue, 10 Sep 2019 22:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 Ta3ZU7BILi-O for ; Tue, 10 Sep 2019 22:06:57 -0700 (PDT) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01F72120020 for ; Tue, 10 Sep 2019 22:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568178415; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=Ihv/BgIyZ+WhKQjfEI6A5Egv7TBVmE4uvmTGurK67qU=; b=SV5dpXpepit+4Ep7TC53kYlMVrcmC1Q1rMQR5eNfChzZbzlbb66IUfsiKT4m7F2M 7dX4w8pPAiULMM5RQZDay8W131eNbbJ6w9Zacky8N0puFcK2Fd0Jzze3Z4oqoq41Nz+ sO+8bxu46vlWcmqtCVq/loTjvjZPJsI7SDJMtCpw= From: Kent Watsen Message-ID: <0100016d1eb7a7c3-6db38fa6-1c81-45ae-a907-dadb52a5bf78-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_09154D71-1D08-44B7-B4D9-A2E58B4654C1" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 11 Sep 2019 05:06:55 +0000 In-Reply-To: Cc: Warren Kumari , "netconf@ietf.org" , Ignas Bagdonas , Alissa Cooper To: Qin Wu References: X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.11-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Results of "Adoption Call for draft-mahesh-netconf-https-notif-00" X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 05:06:59 -0000 --Apple-Mail=_09154D71-1D08-44B7-B4D9-A2E58B4654C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Qin, > Agree with Warren's suggestion. I also believe this work can be = progressed in parallel with client server model draft, at least TCP = client server , TLS client server model draft.=20 > The model defined in these documents can be further reused in NETCONF = client server model draft and RESTCONF client server model draft.=20 > What is tricky is where does ietf-http-client come from? It seems to = me it come from draft-kwatsen-netconf-http-client-server-03, which is = still an individual draft. If you recall, we tried to adopt http-client-server at the same time as = tcp-client-server, but the HTTPBIS chairs were troubled (the NETCONF = chairs reached out to them as a curtesy). We didn't have the energy at = the time to walk them thru it, and the adoption didn't have to happen = *immediately* (i.e., it's not one of the first three drafts NETCONF is = trying to bring to Last Call). All this to explain why it is still an = I-D. I think that this having both the https-notif and = restconf-client-server drafts depending on http-client-server draft will = help the HTTPBIS chairs understand the scope, specifically that it is = minimal, which is what they wanted.=20 Kent= --Apple-Mail=_09154D71-1D08-44B7-B4D9-A2E58B4654C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Qin,

Agree with Warren's = suggestion. I also believe this work can be progressed in parallel with = client server model draft, at least TCP client server , TLS client = server model draft.
The model defined in these documents = can be further reused in NETCONF client server model draft and RESTCONF = client server model draft.
What is tricky is where does = ietf-http-client come from? It seems to me it come from = draft-kwatsen-netconf-http-client-server-03, which is still an = individual draft.

If you recall, we tried to adopt = http-client-server at the same time as tcp-client-server, but the = HTTPBIS chairs were troubled (the NETCONF chairs reached out to them as = a curtesy).  We didn't have the energy at the time to walk them = thru it, and the adoption didn't have to happen *immediately* (i.e., = it's not one of the first three drafts NETCONF is trying to bring to = Last Call).  All this to explain why it is still an I-D.   I = think that this having both the https-notif and restconf-client-server = drafts depending on http-client-server draft will help the HTTPBIS = chairs understand the scope, specifically that it is minimal, which is = what they wanted. 

Kent
= --Apple-Mail=_09154D71-1D08-44B7-B4D9-A2E58B4654C1-- From nobody Tue Sep 10 22:15:47 2019 Return-Path: <0100016d1ebfb4e0-9a8da9f1-686e-4d72-b682-e13338db20db-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D04512026E for ; Tue, 10 Sep 2019 22:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 mKuxALeyJHkL for ; Tue, 10 Sep 2019 22:15:45 -0700 (PDT) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C73C4120168 for ; Tue, 10 Sep 2019 22:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568178943; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=rTPBYyg22g1SbxqX5hX37DH3dT7brnc3GjXgSaJKYZ4=; b=adYsc6kL+Y5oye8IhjPxonZjGn/0S9gqipzis9zDrHedbG3kStjWfze2L0yHCxl4 hJ0dbQWNgIc1AGQoRXl7JsBUgSXQCtJ9WPKx/bhzvCgjw72/fMtfo4OutB5JgD7hq/e CHNpwr7JvncleCA+idmCl/m9950zY+n7HjzLdUOI= From: Kent Watsen Message-ID: <0100016d1ebfb4e0-9a8da9f1-686e-4d72-b682-e13338db20db-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_96BA2B1A-C6C7-43F5-B618-7846BF2ED3C7" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 11 Sep 2019 05:15:43 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: wangzitao References: X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.11-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 05:15:47 -0000 --Apple-Mail=_96BA2B1A-C6C7-43F5-B618-7846BF2ED3C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Michael, > IMHO, this model can be used in call-home scenarios, for example the = server can initiate a transport session to those receivers in the = subscription using the address and port specified.=20 > Therefore, I suggest to add some attributes, such as Listen Port, to = support call-home. I'm not entirely sure I follow you. =20 Firstly, the draft is describing the NC/RC server initiating a protocol = connection to a remote peer (the receiver). So, in this since, it is = "call home" already. That said, maybe you mean "call home" in the sense of protocol-reversals = (e.g., reverse TLS). If so, note that the protocol being discussed here = is more like Syslog than RESTCONF. If it were Syslog, would you also = to think there is a need to have a protocol-reversal? Kent // as co-author --Apple-Mail=_96BA2B1A-C6C7-43F5-B618-7846BF2ED3C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Michael,

IMHO, this model can be used in call-home scenarios, = for example the server can initiate a transport session to those = receivers in the subscription using the address and port = specified. 
Therefore, I suggest to = add some attributes, such as Listen Port, to support = call-home.

I'm not entirely sure I follow you. =   

Firstly, the draft is = describing the NC/RC server initiating a protocol connection to a remote = peer (the receiver).  So, in this since, it is "call home" = already.

That said, maybe you mean = "call home" in the sense of protocol-reversals (e.g., reverse = TLS).  If so, note that the protocol being discussed here is more = like Syslog than RESTCONF.   If it were Syslog, would you also to = think there is a need to have a protocol-reversal?

Kent // as co-author

= --Apple-Mail=_96BA2B1A-C6C7-43F5-B618-7846BF2ED3C7-- From nobody Wed Sep 11 00:14:35 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3A012026E for ; Wed, 11 Sep 2019 00:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=ericsson.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 LIhA6XrntRtU for ; Wed, 11 Sep 2019 00:14:32 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30085.outbound.protection.outlook.com [40.107.3.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8F551200B9 for ; Wed, 11 Sep 2019 00:14:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ckyO/KMfVMf2vpWoim3Yy9d0SWYfAoT0Mjq2DvM3Hyqkvr5Bagygxn0UrzfMz9voON8aT5yYcivyV1Bo7fty3tY75GekEL6TsNr9Ige3gZSHipCOn0qbvDw83obr/ly+gttuOhdLEVL4ZrWmIf4zXkdOusxhgWGiwQX3H+tIk1Kp3bLl+LVvBj1vzE7AbxFQ/bqirSJqPbyD6D3MDq2Ar9E/gE2WdrGhDNvaZMt8xb3Em5mV9OKlAmqGky+Dfblzcnuwf+mbTkldsBYMVSM7DVEHmEnkH4jK1zAhZqNRWZCnu4VFSe/Tk0739eZA4wbUmk6tO56xCOIn20sRis/Pqw== 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=n4dPh2/PNQUHZu4uNJGle05OBIBzwKJf76IO2fjbjLA=; b=c39zRXnSVi/FoIuUQHBB+PMdCOFKviRMtBUWjQ89I3+l+fMN6+GtDV8Hqsb771BUOgZQNPFjr4euaajP6D1pAOD6v19l4aLhhJX7VeGCIDlhHw7LnhuUGvhs8wTWLLiVcQZPRxgvKsSeYYC5BKF92+cnN4U044EOZIt6Dj4ylF6mjOINQvoDn4sMBjeKEpHu8rhRhiisXJahA5q86IXuOdkQXVe29t5KmMXlyoJqz8mwiiDa3qF9ZiAofD1jpObNf1EdC+OgtQPNT+cdAp9GqD9FFPBrvKzAlKz1VhZyb0JEnQyAM2JZgaUqakaIc7hvHbPcEcacBA+Hp9sOHVI1Sw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n4dPh2/PNQUHZu4uNJGle05OBIBzwKJf76IO2fjbjLA=; b=ndn/PeFUQEKgnZquj1WvGZR9olEVz3eoE1NRMKQW9u+tBg0YSMU1wsytI+m0L3EmSBNO0g0M1VRa7WqcfH5jcILoCVw8z5uunJWNwpis4Gz0wjdK1vO9c3jwdqphmtKpXlAr12WAHK8/84Gi5LDEW9dYFCmrXD96WBw2wXXTsro= Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com (10.169.137.153) by VI1PR0701MB2605.eurprd07.prod.outlook.com (10.173.82.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.11; Wed, 11 Sep 2019 07:14:29 +0000 Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com ([fe80::f44b:854c:51cf:c69f]) by VI1PR0701MB2286.eurprd07.prod.outlook.com ([fe80::f44b:854c:51cf:c69f%7]) with mapi id 15.20.2263.015; Wed, 11 Sep 2019 07:14:29 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Qin Wu , Warren Kumari , "netconf@ietf.org" , Ignas Bagdonas , Alissa Cooper Thread-Topic: [netconf] Results of "Adoption Call for draft-mahesh-netconf-https-notif-00" Thread-Index: AdVoPgUMJ6y89+PdQdOCN3TjxhUq6wAMoDMw Date: Wed, 11 Sep 2019 07:14:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a6ff2f19-cabf-434d-a52d-08d73687afbb x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:VI1PR0701MB2605; x-ms-traffictypediagnostic: VI1PR0701MB2605: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0157DEB61B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(136003)(376002)(346002)(366004)(51444003)(53754006)(189003)(199004)(13464003)(229853002)(99936001)(486006)(86362001)(476003)(7696005)(66066001)(76176011)(2501003)(446003)(33656002)(110136005)(102836004)(186003)(53546011)(26005)(6506007)(76116006)(316002)(81156014)(81166006)(25786009)(8676002)(8936002)(85202003)(99286004)(11346002)(3846002)(55016002)(6306002)(85182001)(9686003)(478600001)(14454004)(74316002)(305945005)(71200400001)(71190400001)(966005)(7736002)(5660300002)(52536014)(66946007)(256004)(53936002)(2906002)(66556008)(66446008)(64756008)(6436002)(66616009)(66476007)(6246003)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2605; H:VI1PR0701MB2286.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: QBraCyOjyMC4KEE3gsoEdWP9aq/FUa+QZ0f9l+3jeyUE02lRqD0Z7KYxPpkw94Kx+pFymobLL2UWtf4vzAEpK8uri7unE7BsBaWXOBhHej5RTJd8EsC50lGmIejc+3ISqT4wckqQdtjvaCKDxxtuh2pPtjl/10fapUsDDX5Li55KzaTr1l/dI0DtMMeCVY+2mvL/U9K5yoghecjgqwutopHok8osDTAC0EU27Zjo2rTjutstHA2GRQsXpsq25lzQTvtDkc3Fj6gcGk4eIRGcrejSnuyJqrJDqDdXesKtXdZWKIKoPULMcVXD2dZc5szfE2oNHxYBx0FeTr67jD76Rpu45aLe03PRekSOptQ+fN2G55tG82QGUPs0pXuyYZ91oUhYSu5CDDxcF7WuNKzgvwvcVShkoeozISoj+K/8ShM= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00F8_01D56881.4FB612E0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: a6ff2f19-cabf-434d-a52d-08d73687afbb X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2019 07:14:29.1630 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: R65F4KHvP/4pW3iauGj+g0hHRxrdqM1A5o4lxQCsYEjRQUIJj3LJnofrAeZxvA20CPh0jhfUF9V3hdMG6y8r3XG17/sWlEeV8s8uGlAlC3U= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2605 Archived-At: Subject: Re: [netconf] Results of "Adoption Call for draft-mahesh-netconf-https-notif-00" X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 07:14:35 -0000 ------=_NextPart_000_00F8_01D56881.4FB612E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable +1 Balazs -----Original Message----- From: netconf On Behalf Of Qin Wu Sent: 2019. szeptember 11., szerda 3:55 To: Warren Kumari ; netconf@ietf.org; Ignas Bagdonas = ; Alissa Cooper Subject: Re: [netconf] Results of "Adoption Call for = draft-mahesh-netconf-https-notif-00" Agree with Warren's suggestion. I also believe this work can be = progressed in parallel with client server model draft, at least TCP = client server , TLS client server model draft.=20 The model defined in these documents can be further reused in NETCONF = client server model draft and RESTCONF client server model draft.=20 What is tricky is where does ietf-http-client come from? It seems to me = it come from draft-kwatsen-netconf-http-client-server-03, which is still = an individual draft. I also believe Martin's comments should be addressed. -Qin -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: netconf [mailto:netconf-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Warren Kumari =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B49=E6=9C=8811=E6=97=A5 = 5:05 =E6=94=B6=E4=BB=B6=E4=BA=BA: netconf@ietf.org; Ignas Bagdonas = ; Alissa Cooper =E4=B8=BB=E9=A2=98: [netconf] Results of "Adoption Call for = draft-mahesh-netconf-https-notif-00" Hi there all, As both Netconf chairs are also authors of = draft-mahesh-netconf-https-notif, they felt that it was inappropriate = for them to also call consensus on this adoptionI'd suggest that the = chair deputize a WG participant to make and needed consensus calls which = may , and so have asked me to do so. I've reviewed the meeting video, the minutes, and also the call for = adoption thread (I wasn't subscribed to the mailing list, and so I read = it on the archives, and cannot reply to the original thread). I view = there being consensus for adoption of this document -- authors, please = resubmit as draft-ietf-netconf-... I'd also suggest that the chair = deputize a WG participant to make and needed consensus calls which may = come up during progression of the document. As noted by Kent in https://mailarchive.ietf.org/arch/msg/netconf/ndUBag_lngpt5nyBVol-CylPQpE= , Martin made a number of good points -- not sure if you'd like to address = there before or after submitting the WG version of the document. There was also a view that the WG should be focusing on getting the = client-server work done -- this seems like a fine idea, but I think = that, if the authors have time, they can work on this in parallel... Thank you all, W -- I don't think the execution is relevant when it was obviously a bad idea = in the first place. This is like putting rabid weasels in your pants, and later expressing = regret at having chosen those particular rabid weasels and that pair of = pants. ---maf _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_000_00F8_01D56881.4FB612E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVbjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF/zCCA+egAwIBAgIR AOm+1xFswMzmixU1jNT/MSEwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMB4XDTE3MTAw OTE1MjQ1OFoXDTIwMTAwOTE1MjQ1N1owajERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD0Jh bMOhenMgTGVuZ3llbDEqMCgGCSqGSIb3DQEJARYbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t MQ8wDQYDVQQFEwZFVEhCTEwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUUtnneUfH i428YPkvW+AsCNeKCCKq72SzUZpBggijy+oLVO0cgTXXHygrZ+KT8TbyEkPwuHi+V4TQxWAyMhGa nWZHWZXe9ghEZrJDJbCzFMHOqR+wEDnI1vM3sfQQ68iSsWQLd9opnb2/ihiJlt9up75VRpyj5lea bvzxOLQimJgZiXaZzsPPT2nROyytKxOsE5KbfT3mNof3bMG1bggZtGGA1GBJchwdFJwQKIShfPVm 1CdulvJV1hPVecxttMJNPzSfSfryb/b64QnR5yc/pSx8SxD0h0rnNT73Al3Af2iRghdXN4omDKZY OcdK/sE5HTmLTFuWoZAnL/RntOK9AgMBAAGjggHBMIIBvTBIBgNVHR8EQTA/MD2gO6A5hjdodHRw Oi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggr BgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYI KwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNlcjAmBgNVHREEHzAdgRtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBSkJw2vbyMFmf9tY1urk9NeYfiMgTAfBgNVHSMEGDAWgBQcexmel5x2rCA92Nzj kWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAD1RCVf5Df2uCXwPveXz LBGIjsz3k2la5UUlioC+i4Ms6vGstqXIX7K24+Wc41npi+G5xFhvkAkmuTP/j29F5xJJuJcy3OcL 0br02vKe2WJJnlivB+X9plPg0kMUBS0lLq7kHPUrO/BLeIIFRuaky05eZlTnGNcLbn5VpZdjX4Ic XZV78qpZI3L67Po1UgHzOTiWolc75jrKOx3UOw98fWRrgJPBUIeqDeD1NDfF7PlM4Cqlad062o6L lM9wfAnoLzz0z04dPXtJkOcTiZgOLdPoKIm7LR1wZ9c6mYw4sgtoVAs16Y2cCPBxqWpsW+9ZCcDK PPZzeBezCKyicpDJbTqCVMILd3j38HWUPWFuVITZNgANzHW1CpgqmiLIAADiznCCtudTE+fcB3O9 duuu/yuEME17LMy1GYMKXs1QCXmTq2hrqTJQ2AA2TsWZtoxl3ViqJgNBWjnQiMwdCl5Dural2jZP /iU6MmiauUNYn9YW/ViUluoBBdaUHMpnP/7kM0Wk8j3Wzhcggx+Biml2gCopMaK1EJYjQH/2J95N GEkSdZfVzFUmwV3yMd4mOhIaxW0SEq9b1eWICZ/BAcVBpSyU0sE1gpnBO5wLxj+IpSdiGlS4jc37 qCr/39xdv1Unu93glCmHq0xgX54N8EsyMBPC3+zSSu1qhCbU7VJWIz2aMIIGwjCCBKqgAwIBAgIQ U7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEf MB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcx MjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy 3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt 8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6j RrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFl hFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/2 0aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCY rEqHMRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuT LUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMd ay0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqd GTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMB AAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVz dC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9j cmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpec dqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5 s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90 BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRy pF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86 IWst821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QD Xnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7 C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbN QUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbH XSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i 6Ds5j0Qpj5aQMYIDBTCCAwECAQEwXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MAkGBSsOAwIaBQCgggF+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTE5MDkxMTA3MTQyN1owIwYJKoZIhvcNAQkEMRYEFJApO/JX/ffI/hBBQSJsO39cd5U2MEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQBjrvq9tYxq+ZToZjgbMFCHcpIlKEaBx+5TMnmkRK1lc7SNn4CKBUCI vfqCt8YFClX8ZxQqw36Nf9QdndmaTOjiOoWSKeARAPak04eOB09Yi3wdb5a9L38wx9qH5OE4ykdm 2P3O9ghthnmnpoQNduTQ4M8c2AOIfjKG+4m0bg6CQDq7oAoIT69F0G63M8HhN2Keu0n0IR1I3U7U Zx4DepwY3PGWHb3mwufXWd9iXygSW+jWk2BU2CJNa6XMMYhWfQrO3Dn5UUZXIOvWHzA2a2+c2jIl ItnhIKbsQoK1JZeYElfKBU2/zUxfuwOsATKYPZz1Oa+aBGGHDhVTkfhXOgnaAAAAAAAA ------=_NextPart_000_00F8_01D56881.4FB612E0-- From nobody Wed Sep 11 00:58:19 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411AE120810 for ; Wed, 11 Sep 2019 00:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 OKfD5-zUh9rs for ; Wed, 11 Sep 2019 00:58:16 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 A1FFC120143 for ; Wed, 11 Sep 2019 00:58:15 -0700 (PDT) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 3AAA83B357742B4CC8D0 for ; Wed, 11 Sep 2019 08:58:13 +0100 (IST) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 11 Sep 2019 08:58:12 +0100 Received: from DGGEMM527-MBX.china.huawei.com ([169.254.6.177]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0439.000; Wed, 11 Sep 2019 15:58:07 +0800 From: wangzitao To: Kent Watsen CC: "netconf@ietf.org" Thread-Topic: =?gb2312?B?UkWjuiBbbmV0Y29uZl0gQWRvcHRpb24gQ2FsbCBmb3IgZHJhZnQtbWFoZXNo?= =?gb2312?Q?-netconf-https-notif-00?= Thread-Index: AdVodYbehJUK94P6T123JJPZgOneJg== Date: Wed, 11 Sep 2019 07:58:06 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.142.117] Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EA2DAF7D5BDGGEMM527MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netconf] =?gb2312?b?UkWjuiAgQWRvcHRpb24gQ2FsbCBmb3IgZHJhZnQt?= =?gb2312?b?bWFoZXNoLW5ldGNvbmYtaHR0cHMtbm90aWYtMDA=?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 07:58:18 -0000 --_000_E6BC9BBCBCACC246846FC685F9FF41EA2DAF7D5BDGGEMM527MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgS2VudCwNCg0KVGhhbmsgeW91IGZvciB5b3VyIHJlcGx5Lg0KSSBhbSB0cnlpbmcgdG8gdW5k ZXJzdGFuZCB0aGUgcmVsYXRpb25zaGlwIGFuZCB1c2FnZSBvZiB0aGlzIGRyYWZ0IGFuZCBhIHNl dCBvZiBuZXRjb25mIGRyYWZ0czoNClRoaXMgbW9kZWwgcHJlc2VudCB0aGUgcmVjZWl2ZXIncyBp bmZvcm1hdGlvbiAoc3VjaCBhcyBJUCwgcG9ydCwgZXRjKSBhbmQgaXQgYXVnbWVudCB0aGUgaWV0 Zi1zdWJzY3JpcHRpb24tbm90aWZpY2F0aW9uIG1vZGVsIHRoYXQgdGhlIHVzZXIgY2FuIHNwZWNp ZnkgbXVsdGlwbGUgc3Vic2NyaXB0aW9uIHJlY2VpdmVycy4NCkFuZCB0aGUgdXNlciBhbHNvIG5l ZWQgdG8gY29uZmlndXJlIHRoZSBzZXJ2ZXIgdG8gc3BlY2lmeSByZWNlaXZlcidzIHBvcnQgYW5k IElQICh2aWEgaWV0Zi1jbGllbnQtc2VydmVyPykuIFRoYXQgdGhlIHNlcnZlciBjYW4gY2FsbCBo b21lIHRvIHRoZSByZWNlaXZlcnMuDQpJcyBteSB1bmRlcnN0YW5kaW5nIGNvcnJlY3Q/IElmIHll cywgSSBzdWdnZXN0IHRoYXQgYSBicmllZiBkZXNjcmlwdGlvbiBvZiB0aGUgd29ya2Zsb3cgc2hv dWxkIGJlIHByZXNlbnQgaW4gdGhlIGRyYWZ0Lg0KDQpCZXN0IFJlZ2FyZHMhDQotTWljaGFlbA0K DQq3orz+yMs6IEtlbnQgV2F0c2VuIFttYWlsdG86a2VudCtpZXRmQHdhdHNlbi5uZXRdDQq3osvN yrG85DogMjAxOcTqOdTCMTHI1SAxMzoxNg0KytW8/sjLOiB3YW5neml0YW8gPHdhbmd6aXRhb0Bo dWF3ZWkuY29tPg0Ks63LzTogbmV0Y29uZkBpZXRmLm9yZw0K1vfM4jogUmU6IFtuZXRjb25mXSBB ZG9wdGlvbiBDYWxsIGZvciBkcmFmdC1tYWhlc2gtbmV0Y29uZi1odHRwcy1ub3RpZi0wMA0KDQpI aSBNaWNoYWVsLA0KDQoNCklNSE8sIHRoaXMgbW9kZWwgY2FuIGJlIHVzZWQgaW4gY2FsbC1ob21l IHNjZW5hcmlvcywgZm9yIGV4YW1wbGUgdGhlIHNlcnZlciBjYW4gaW5pdGlhdGUgYSB0cmFuc3Bv cnQgc2Vzc2lvbiB0byB0aG9zZSByZWNlaXZlcnMgaW4gdGhlIHN1YnNjcmlwdGlvbiB1c2luZyB0 aGUgYWRkcmVzcyBhbmQgcG9ydCBzcGVjaWZpZWQuDQpUaGVyZWZvcmUsIEkgc3VnZ2VzdCB0byBh ZGQgc29tZSBhdHRyaWJ1dGVzLCBzdWNoIGFzIExpc3RlbiBQb3J0LCB0byBzdXBwb3J0IGNhbGwt aG9tZS4NCg0KSSdtIG5vdCBlbnRpcmVseSBzdXJlIEkgZm9sbG93IHlvdS4NCg0KRmlyc3RseSwg dGhlIGRyYWZ0IGlzIGRlc2NyaWJpbmcgdGhlIE5DL1JDIHNlcnZlciBpbml0aWF0aW5nIGEgcHJv dG9jb2wgY29ubmVjdGlvbiB0byBhIHJlbW90ZSBwZWVyICh0aGUgcmVjZWl2ZXIpLiAgU28sIGlu IHRoaXMgc2luY2UsIGl0IGlzICJjYWxsIGhvbWUiIGFscmVhZHkuDQoNClRoYXQgc2FpZCwgbWF5 YmUgeW91IG1lYW4gImNhbGwgaG9tZSIgaW4gdGhlIHNlbnNlIG9mIHByb3RvY29sLXJldmVyc2Fs cyAoZS5nLiwgcmV2ZXJzZSBUTFMpLiAgSWYgc28sIG5vdGUgdGhhdCB0aGUgcHJvdG9jb2wgYmVp bmcgZGlzY3Vzc2VkIGhlcmUgaXMgbW9yZSBsaWtlIFN5c2xvZyB0aGFuIFJFU1RDT05GLiAgIElm IGl0IHdlcmUgU3lzbG9nLCB3b3VsZCB5b3UgYWxzbyB0byB0aGluayB0aGVyZSBpcyBhIG5lZWQg dG8gaGF2ZSBhIHByb3RvY29sLXJldmVyc2FsPw0KDQpLZW50IC8vIGFzIGNvLWF1dGhvcg0KDQo= --_000_E6BC9BBCBCACC246846FC685F9FF41EA2DAF7D5BDGGEMM527MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Kent,

 

Thank you for your rep= ly.

I am trying to underst= and the relationship and usage of this draft and a set of netconf drafts:

This model present the= receiver's information (such as IP, port, etc) and it augment the ietf-sub= scription-notification model that the user can specify multiple subscription receivers.

And the user also need= to configure the server to specify receiver's port and IP (via ietf-client= -server?). That the server can call home to the receivers.

Is my understanding co= rrect? If yes, I suggest that a brief description of the workflow should be= present in the draft.

 

Best Regards!

-Michael

 

=B7=A2=BC=FE=C8=CB: Kent Watsen [m= ailto:kent+ietf@watsen.net]
=B7=A2=CB=CD=CA=B1=BC=E4:<= /span> 2019=C4=EA9=D4=C211=C8=D5 13:16
=CA=D5=BC=FE=C8=CB: wangzitao <wangzitao@huawei.com>
=B3=AD=CB=CD: netconf@ietf.org
=D6=F7=CC=E2: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00<= /o:p>

 

Hi Michael,



IMHO, this model can b= e used in call-home scenarios, for example the server can initiate a transp= ort session to those receivers in the subscription using the address and port specified. 

Therefore, I suggest t= o add some attributes, such as Listen Port, to support call-home.

 

I'm not entirely sure I follow = you.   

 

Firstly, the draft is describin= g the NC/RC server initiating a protocol connection to a remote peer (the r= eceiver).  So, in this since, it is "call home" already.

 

That said, maybe you mean "= ;call home" in the sense of protocol-reversals (e.g., revers= e TLS).  If so, note that the protocol being discussed here is more li= ke Syslog than RESTCONF.   If it were Syslog, would you also to think there is a need to have a protocol-reversal?

 

Kent // as co-author=

 

--_000_E6BC9BBCBCACC246846FC685F9FF41EA2DAF7D5BDGGEMM527MBXchi_-- From nobody Wed Sep 11 02:33:53 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE51F120845 for ; Wed, 11 Sep 2019 02:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 D0gPdZVROrX4 for ; Wed, 11 Sep 2019 02:33:49 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 6E7E6120844 for ; Wed, 11 Sep 2019 02:33:49 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 683AA9B2F7F514603358 for ; Wed, 11 Sep 2019 10:33:47 +0100 (IST) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 11 Sep 2019 10:33:46 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0439.000; Wed, 11 Sep 2019 17:33:43 +0800 From: Tianran Zhou To: Kent Watsen , "netconf@ietf.org" Thread-Topic: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 Thread-Index: AQHVXFoPOUn3XT57XkG9BuZUaItVxKcmTP+Q Date: Wed, 11 Sep 2019 09:33:43 +0000 Message-ID: References: <0100016ccff35064-9da3c8b6-263c-47f6-a4f2-4db9495bc8b7-000000@email.amazonses.com> In-Reply-To: <0100016ccff35064-9da3c8b6-263c-47f6-a4f2-4db9495bc8b7-000000@email.amazonses.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F21BEFB1420NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 09:33:52 -0000 --_000_BBA82579FD347748BEADC4C445EA0F21BEFB1420NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kent, Considering the multiple stream originator case, I would suggest this https= -notif to add a channel level configuration. i.e. +--receivers +--receiver +--channels +--channel +--here put the http client server configurations This is compatible with the single originator case with only one channel co= nfiguration. If you do not like this, I think existing https-notif model also works. i.e. each receiver configuration stands for one channel. But this is not clear IMO. Best, Tianran From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent Watsen Sent: Tuesday, August 27, 2019 6:02 AM To: netconf@ietf.org Subject: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 This email begins a 2-week adoption poll for: https://tools.ietf.org/html/draft-mahesh-netconf-https-notif-00 In-room support for this draft was noted but, as always, it is necessary to= confirm WG consensus on the list. If interested in the WG defining an HTT= PS-based solution for *configured subscriptions* (for which there are none = to date), please voice your support for this draft's adoption. If objectin= g, please state your reasons. PS: Authors, please additionally respond to as if there is any IPR to discl= ose. Kent and Mahesh // as chairs --_000_BBA82579FD347748BEADC4C445EA0F21BEFB1420NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kent,

 

Considering the multiple stream originator ca= se, I would suggest this https-notif to add a channel level configuration.<= o:p>

i.e.

 

+--receivers

   +--receiver

      +--channel= s

       &nb= sp; +--channel

       &nb= sp;    +--here put the http client server configurations=

 

This is compatible with the single originator= case with only one channel configuration.

 

If you do not like this, I think existing htt= ps-notif model also works.

i.e. each receiver configuration stands for o= ne channel.

But this is not clear IMO.<= /p>

 

Best,

Tianran

 

From: = netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent Watsen
Sent: Tuesday, August 27, 2019 6:02 AM
To: netconf@ietf.org
Subject: [netconf] Adoption Call for draft-mahesh-netconf-https-noti= f-00

 

This email begins a 2-week adoption poll for:

 

    = https://tools.ietf.org/html/draft-mahesh-netconf-https-notif-00=

In-room support for this draft was not= ed but, as always, it is necessary to confirm WG consensus on the list. &nb= sp;If interested in the WG defining an HTTPS-based solution for *configured subscriptions* (for which there are none to date), please&= nbsp;voice your support for this draft's adoption.  If objecting, plea= se state your reasons.  =

 

PS: Authors, please additionally respo= nd to as if there is any IPR to disclose.


Kent and Mahesh // as chairs

--_000_BBA82579FD347748BEADC4C445EA0F21BEFB1420NKGEML515MBXchi_-- From nobody Wed Sep 11 03:18:28 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF8B12085D for ; Wed, 11 Sep 2019 03:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=ericsson.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 MMdRGetlbatv for ; Wed, 11 Sep 2019 03:18:24 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30071.outbound.protection.outlook.com [40.107.3.71]) (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 B5F41120854 for ; Wed, 11 Sep 2019 03:18:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cgw/SdL2wTnUxzbAOvAOwOfEZbaxftNkcPVxLrSmv6mE+TYPiUN+fZxU6M0e/B0VJb0t8v6W2aqQ7sQ8XiD4jfsA9i1qiRdaBizQCvwtJNRAWxYseWhRnOznFz0oGXHy/CisimDedcHLBO55D2/zypkUHnLelKwH9SDXuyZpaOevGjeuEdaVaELCZJFhGJY6HGhWcyHI9vzgpOjZL3U20/5RBpXbLEErwGuAln6kA8I6Sogqnr7Y3xk2vEqTcMUr5WQUcyB7HigCRxqf5IYZ9xrxMYsITglLR210X040+vrQ/J46YTHGCPgzCS9fb6Wkm278oR6VkZb8RBMixiZMVA== 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=zuY0dRsos3gXi1YkpxDEmyV2alvPE2N2faTKH3n1Yr4=; b=lhvNGRfzx6y3zpl4t2hucXfFEX5KkEPS9Wk+kUJsiHXZJJcF1zKr+EBmrWeXWwYkGbr+b00qmDoU76S94uHjqbqylPvjakwrd3K9MdTWET3JyRfLQD6GGUI6soP1HwvI0Zb2ndDdtzHA/d8+5RXtF5PX3LEfaLkiQPAsYLNc1U5UhgDUem8+3laP8MN3r9pPJ4XA2WAaQi4rF3KQvcWld56L8QTeR080D8iI7sHOfOfpId9ij1GB3MOH7SnOL06W3y8bSs1lH0Vr5viahhjWecCtjywLTJVXmPSImMXboPHHNESWfeBpmRVAPZGY0nKxT0ieSeE6az0MrEC1nVed+Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zuY0dRsos3gXi1YkpxDEmyV2alvPE2N2faTKH3n1Yr4=; b=HlT1l6B/etXDO9XLSQE+ij6RQ/TzHbhpYZo11LliBBFMOGCOC+J3SjsCZnpRFgZOVB2TU/YKE5dI0QVvWV5QbfMdzYDCXGl/xQFo76Xoe5+PY9LfooyVY/pC6AXWZ+Ka4mOpjxZZV6l3ZO2wsbh0aXba2sxbMDWGcTU8BOXoFwE= Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com (10.169.137.153) by VI1PR0701MB2990.eurprd07.prod.outlook.com (10.173.72.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.6; Wed, 11 Sep 2019 10:18:21 +0000 Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com ([fe80::f44b:854c:51cf:c69f]) by VI1PR0701MB2286.eurprd07.prod.outlook.com ([fe80::f44b:854c:51cf:c69f%7]) with mapi id 15.20.2263.015; Wed, 11 Sep 2019 10:18:21 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Qin Wu , Mahesh Jethanandani , Netconf Thread-Topic: [netconf] WGLC for draft-ietf-netconf-notification-capabilities Thread-Index: AdVoPX4GqtZOaS4LR8qYtgUDtxKZ8QAMsgqg Date: Wed, 11 Sep 2019 10:18:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cfcfffdf-840e-452d-4359-08d736a15f68 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:VI1PR0701MB2990; x-ms-traffictypediagnostic: VI1PR0701MB2990: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0157DEB61B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(366004)(396003)(39860400002)(136003)(199004)(189003)(2420400007)(76116006)(15650500001)(478600001)(7696005)(66446008)(64756008)(86362001)(9326002)(606006)(26005)(6246003)(110136005)(229853002)(85182001)(25786009)(99286004)(53546011)(6506007)(8936002)(76176011)(53936002)(7110500001)(7736002)(33656002)(52536014)(74316002)(9686003)(5660300002)(3846002)(6116002)(55016002)(790700001)(236005)(102836004)(54896002)(2906002)(6306002)(85202003)(6436002)(66066001)(446003)(256004)(14444005)(476003)(66616009)(486006)(11346002)(14454004)(71200400001)(66556008)(186003)(71190400001)(316002)(99936001)(81156014)(81166006)(66476007)(8676002)(66946007); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2990; H:VI1PR0701MB2286.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: P/OPq+PDjDHCwZKy4BfTkmw2aob+rQ+VzPwVBvMVlsId6SwiNiuyA0tPRnwA2/zvLeg1ElI9zaiJUwgAjaOqEM+LkfEzl9HXRAuVV1UJk+yG2L4BtRwjbRh/FtaKDD96MqxkYTVQytlK3EzVv9pbWsK4i0qAJ8VIVU1se/pNnSQfqC1guPimRerQVmITo9F/Fl5kAHmafR6lFFAC1/TnBC0a+Z5o9lOO3ynRF5E9r60bQ0LmbrVnGZgcqxO7ga5MMmbm9S1m8XI7nN8eDW/Qdc0j+xcnFBaS4WajKWQ/FC2NdiZt+jTL79i2yPGF3cIKN2l1NFhqqafV38deLGlOhkUez3AVcJIFtxaf4jgLMEw/sI0vpDj8xID0RZIWWtG21NjywRxj3U7zNUIjpMpXZAbs40HxYwCrgg8jap2Ga/0= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0161_01D5689A.FF2E62E0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: cfcfffdf-840e-452d-4359-08d736a15f68 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2019 10:18:21.3228 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rQ4Qll9T17JQaJZqrfW5uXr8swj+hpvghoocVL3OVMu4Tpn8ZcFRSkQUL7aCBwYKjhVQVq2ijpe60PzxNQk568pdLfDjSHri86jvtIidniI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2990 Archived-At: Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 10:18:26 -0000 ------=_NextPart_000_0161_01D5689A.FF2E62E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0162_01D5689A.FF2E62E0" ------=_NextPart_001_0162_01D5689A.FF2E62E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Qin, I did not add module level capabilities because: In 99% of the cases module level capabilities can be handled defining = per-node-capabilities on one or a few top level containers, lists. =20 No one proposed a use-case that could not be handled by the current YAM = (Yang Module). Adding a 4th level beside server/datastore/per-node would make the = solution more complex, more difficult to understand. Regards Balazs =20 From: netconf On Behalf Of Qin Wu Sent: 2019. szeptember 11., szerda 3:11 To: Mahesh Jethanandani ; Netconf = Subject: Re: [netconf] WGLC for = draft-ietf-netconf-notification-capabilities =20 Support to move this work forward, one quick question is=20 Since you have datastore level and node level capability, Is there any = reason why module level capability is not included? =20 -Qin =E5=8F=91=E4=BB=B6=E4=BA=BA: netconf [ = mailto:netconf-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Mahesh Jethanandani =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B49=E6=9C=8811=E6=97=A5 = 6:39 =E6=94=B6=E4=BB=B6=E4=BA=BA: Netconf < = netconf@ietf.org> =E4=B8=BB=E9=A2=98: [netconf] WGLC for = draft-ietf-netconf-notification-capabilities =20 Authors have published -04 = version of the draft, which addresses comments they received in = IETF 105. If you provided comments please check to make sure your = comments have been addressed. At this point, the authors believe that = the document is ready for WGLC. =20 This therefore starts a two week LC, ending on September 24th. Please = provide any technical comments you might have on the document. If you = believe the document is not ready for LC, please state your reasons. =20 We will issue a IPR poll separately.=20 =20 Mahesh & Kent (as co-chairs) =20 =20 =20 ------=_NextPart_001_0162_01D5689A.FF2E62E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello Qin,

I did not add module level capabilities = because:

In 99% of =
the cases module level capabilities can be handled =C2=A0defining =
per-node-capabilities on one or a =
few top level containers, lists. =
=C2=A0=C2=A0
No one =
proposed a use-case that could not be handled by the current YAM (Yang =
Module).
Adding a =
4th level beside server/datastore/per-node would make the =
solution more complex, more difficult to =
understand.
Regards =
Balazs

 

From:<= /b> = netconf <netconf-bounces@ietf.org> On Behalf Of Qin = Wu
Sent: 2019. szeptember 11., szerda 3:11
To: = Mahesh Jethanandani <mjethanandani@gmail.com>; Netconf = <netconf@ietf.org>
Subject: Re: [netconf] WGLC for = draft-ietf-netconf-notification-capabilities

<= /div>

 

Support to move this work forward,  one quick question is =

Since you have datastore level and node level capability, Is there any = reason why module level capability is not = included?

 

-Qin

=E5=8F=91=E4=BB=B6=E4=BA=BA: = netconf [mailto:netconf-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Mahesh = Jethanandani
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B49=E6=9C=8811=E6=97=A5 6:39
=E6=94=B6=E4=BB=B6=E4=BA=BA: Netconf = <netconf@ietf.org>
=E4=B8=BB=E9=A2=98: [netconf] WGLC for = draft-ietf-netconf-notification-capabilities

<= /div>

 

Authors have published -04 version of the draft, which addresses comments = they received in IETF 105. If you provided comments please check to make = sure your comments have been addressed. At this point, the authors = believe that the document is ready for WGLC.

 

This therefore starts a two week LC, ending on = September 24th. Please provide any technical comments you might have on = the document. If you believe the document is not ready for LC, please = state your reasons.

 

We will issue a IPR poll = separately. 

 

Mahesh & Kent (as = co-chairs)

 

 

 

------=_NextPart_001_0162_01D5689A.FF2E62E0-- ------=_NextPart_000_0161_01D5689A.FF2E62E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVbjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF/zCCA+egAwIBAgIR AOm+1xFswMzmixU1jNT/MSEwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMB4XDTE3MTAw OTE1MjQ1OFoXDTIwMTAwOTE1MjQ1N1owajERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD0Jh bMOhenMgTGVuZ3llbDEqMCgGCSqGSIb3DQEJARYbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t MQ8wDQYDVQQFEwZFVEhCTEwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUUtnneUfH i428YPkvW+AsCNeKCCKq72SzUZpBggijy+oLVO0cgTXXHygrZ+KT8TbyEkPwuHi+V4TQxWAyMhGa nWZHWZXe9ghEZrJDJbCzFMHOqR+wEDnI1vM3sfQQ68iSsWQLd9opnb2/ihiJlt9up75VRpyj5lea bvzxOLQimJgZiXaZzsPPT2nROyytKxOsE5KbfT3mNof3bMG1bggZtGGA1GBJchwdFJwQKIShfPVm 1CdulvJV1hPVecxttMJNPzSfSfryb/b64QnR5yc/pSx8SxD0h0rnNT73Al3Af2iRghdXN4omDKZY OcdK/sE5HTmLTFuWoZAnL/RntOK9AgMBAAGjggHBMIIBvTBIBgNVHR8EQTA/MD2gO6A5hjdodHRw Oi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggr BgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYI KwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNlcjAmBgNVHREEHzAdgRtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBSkJw2vbyMFmf9tY1urk9NeYfiMgTAfBgNVHSMEGDAWgBQcexmel5x2rCA92Nzj kWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAD1RCVf5Df2uCXwPveXz LBGIjsz3k2la5UUlioC+i4Ms6vGstqXIX7K24+Wc41npi+G5xFhvkAkmuTP/j29F5xJJuJcy3OcL 0br02vKe2WJJnlivB+X9plPg0kMUBS0lLq7kHPUrO/BLeIIFRuaky05eZlTnGNcLbn5VpZdjX4Ic XZV78qpZI3L67Po1UgHzOTiWolc75jrKOx3UOw98fWRrgJPBUIeqDeD1NDfF7PlM4Cqlad062o6L lM9wfAnoLzz0z04dPXtJkOcTiZgOLdPoKIm7LR1wZ9c6mYw4sgtoVAs16Y2cCPBxqWpsW+9ZCcDK PPZzeBezCKyicpDJbTqCVMILd3j38HWUPWFuVITZNgANzHW1CpgqmiLIAADiznCCtudTE+fcB3O9 duuu/yuEME17LMy1GYMKXs1QCXmTq2hrqTJQ2AA2TsWZtoxl3ViqJgNBWjnQiMwdCl5Dural2jZP /iU6MmiauUNYn9YW/ViUluoBBdaUHMpnP/7kM0Wk8j3Wzhcggx+Biml2gCopMaK1EJYjQH/2J95N GEkSdZfVzFUmwV3yMd4mOhIaxW0SEq9b1eWICZ/BAcVBpSyU0sE1gpnBO5wLxj+IpSdiGlS4jc37 qCr/39xdv1Unu93glCmHq0xgX54N8EsyMBPC3+zSSu1qhCbU7VJWIz2aMIIGwjCCBKqgAwIBAgIQ U7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEf MB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcx MjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy 3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt 8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6j RrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFl hFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/2 0aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCY rEqHMRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuT LUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMd ay0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqd GTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMB AAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVz dC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9j cmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpec dqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5 s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90 BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRy pF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86 IWst821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QD Xnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7 C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbN QUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbH XSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i 6Ds5j0Qpj5aQMYIDBTCCAwECAQEwXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MAkGBSsOAwIaBQCgggF+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTE5MDkxMTEwMTgxOVowIwYJKoZIhvcNAQkEMRYEFMD9GxsVNrzMFFl8e4sIQ2Lffnc8MEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQCusZ1NYGFNiE/g3MEjOZ2HN7e3Du/IZ+QCc4UnpzbTh9bG40hl/I8G IYOiHk0lM+FHPMZIm9ICjRicXDC1ogFmO7+2FF+4K41ofF1cMAnWR2rmNmFIfm0u29kO56ltfy2+ RHJgp+ZH+GM8JajFeBgPIjmYvW0SzoB69p3nRx7/NEoHnasrRgSAXkQPO7g5hDHfIOsW60B0bJAA ewi68wg5houbtIupEJLQDJN1PhKsiIEkeL9Qp+6r3cxujT+GEn7hbBEaQ+J768tN9KoFxS8leORq TU0HZ0sJ4GlQw5vZY2aF3wSE/hbSmjmPR4/Sr+xNX2sapgfZwEbmRE2aZnyPAAAAAAAA ------=_NextPart_000_0161_01D5689A.FF2E62E0-- From nobody Wed Sep 11 03:44:56 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3A8120052 for ; Wed, 11 Sep 2019 03:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.997 X-Spam-Level: X-Spam-Status: No, score=-6.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=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=nic.cz 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 zdVWpZOXlk9Q for ; Wed, 11 Sep 2019 03:44:42 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 5552B1200EB for ; Wed, 11 Sep 2019 03:44:42 -0700 (PDT) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id 6238B1414E6; Wed, 11 Sep 2019 12:44:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1568198680; bh=najN++bUkmRar4c4Q2Pd0dCk/+34hc2I/y7gxdb3iFE=; h=From:To:Date; b=T8C67yR6AJc3ap5LVYLV4nMSNyC7tX1LyQpxK/kzym2H6QXhdOs89DTFpBUPSUse9 RxBY46yEPugD2WCd7e12LMdYiKDb74n9YDEew8RiaMmyxiJgUL4f+ESsphw95rI4eT flf5Tw9GkPsd8v8IOvOY/B+DagftsveXcp1kG5aY= Message-ID: From: Ladislav Lhotka To: RFC Errata System , andy@yumaworks.com, mbj@tail-f.com, kwatsen@juniper.net, ibagdona@gmail.com, warren@kumari.net, kent+ietf@watsen.net, mjethanandani@gmail.com Cc: netconf@ietf.org Date: Wed, 11 Sep 2019 12:44:40 +0200 In-Reply-To: <20190911033901.580B1B81207@rfc-editor.org> References: <20190911033901.580B1B81207@rfc-editor.org> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.4 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.100.3 at mail.nic.cz X-Virus-Status: Clean Archived-At: Subject: Re: [netconf] [Technical Errata Reported] RFC8040 (5857) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 10:44:47 -0000 Hi, this erratum should be rejected: "operations" is defined as a container in the ietf-restconf module, so according to RFC 7951 (sec. 5.2) it is represented as a name/object pair in JSON. Lada On Tue, 2019-09-10 at 20:39 -0700, RFC Errata System wrote: > The following errata report has been submitted for RFC8040, > "RESTCONF Protocol". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5857 > > -------------------------------------- > Type: Technical > Reported by: Qin WU > > Section: 3.1 > > Original Text > ------------- > The server might respond as follows: > > HTTP/1.1 200 OK > Date: Thu, 26 Jan 2017 20:56:30 GMT > Server: example-server > Cache-Control: no-cache > Last-Modified: Thu, 26 Jan 2017 16:00:14 GMT > Content-Type: application/yang-data+json > > { "operations" : { "example-jukebox:play" : [null] } } > > Corrected Text > -------------- > The server might respond as follows: > > HTTP/1.1 200 OK > Date: Thu, 26 Jan 2017 20:56:30 GMT > Server: example-server > Cache-Control: no-cache > Last-Modified: Thu, 26 Jan 2017 16:00:14 GMT > Content-Type: application/yang-data+json > > { "operations" :[ { "example-jukebox:play" : [null] } ]} > > Notes > ----- > Returned operations in the RESTCONF response should be an array of the > particular type, therefore the brackets are needed to enclose a list of > operations associated with example-jukebox. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8040 (draft-ietf-netconf-restconf-18) > -------------------------------------- > Title : RESTCONF Protocol > Publication Date : January 2017 > Author(s) : A. Bierman, M. Bjorklund, K. Watsen > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Sep 11 09:58:23 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0448120AE8 for ; Wed, 11 Sep 2019 09:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.347 X-Spam-Level: * X-Spam-Status: No, score=1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 4lJ4oAXM7tlv for ; Wed, 11 Sep 2019 09:58:20 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 979B2120B10 for ; Wed, 11 Sep 2019 09:58:20 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=97.112.17.31; From: "Susan Hares" To: References: In-Reply-To: Date: Wed, 11 Sep 2019 12:58:17 -0400 Message-ID: <015d01d568c2$1c3ea7b0$54bbf710$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHWStv2pVUYme54xO2vuIA7NhyHMKcku63Q Content-Language: en-us X-Antivirus: AVG (VPS 190911-2, 09/11/2019), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [netconf] RFC 8641 on Subscription to YANG Notifications for Datastore Updates X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 16:58:22 -0000 I want to seconded Qin's congratulations for the authors of the = notification drafts.=20 I also want to thank the authors as the I2RS co-chair and IDR chair for their=20 hard work in developing and progressing these needed features for management.=20 Sue Hares=20 ---------- Congratulation to authors of YANG Push series drafts, good progress. -Qin -----=D3=CA=BC=FE=D4=AD=BC=FE----- =B7=A2=BC=FE=C8=CB: netconf [mailto:netconf-bounces@ietf.org] = =B4=FA=B1=ED rfc-editor@rfc-editor.org =B7=A2=CB=CD=CA=B1=BC=E4: 2019=C4=EA9=D4=C210=C8=D5 13:14 =CA=D5=BC=FE=C8=CB: ietf-announce@ietf.org; rfc-dist@rfc-editor.org =B3=AD=CB=CD: drafts-update-ref@iana.org; netconf@ietf.org; rfc-editor@rfc-editor.org =D6=F7=CC=E2: [netconf] RFC 8641 on Subscription to YANG Notifications = for Datastore Updates A new Request for Comments is now available in online RFC libraries. =20 RFC 8641 Title: Subscription to YANG Notifications for=20 Datastore Updates=20 Author: A. Clemm, E. Voit Status: Standards Track Stream: IETF Date: September 2019 Mailbox: ludwig@clemm.org,=20 evoit@cisco.com Pages: 58 Characters: 120700 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netconf-yang-push-25.txt URL: https://www.rfc-editor.org/info/rfc8641 DOI: 10.17487/RFC8641 This document describes a mechanism that allows subscriber applications = to request a continuous and customized stream of updates from a YANG = datastore. Providing such visibility into updates enables new capabilities based on = the remote mirroring and monitoring of configuration and operational state. This document is a product of the Network Configuration Working Group of = the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and = suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for = the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the = author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for = unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Sep 11 13:05:23 2019 Return-Path: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB5312021D for ; Wed, 11 Sep 2019 13:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 0XonuM0Rpp2X for ; Wed, 11 Sep 2019 13:05:19 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B10941201CE for ; Wed, 11 Sep 2019 13:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568232317; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:Cc:To:Feedback-ID; bh=1MhFn3hJ0/bvIrsaE7f9e+aSSR6mTCIzpCNyXBhICDI=; b=g0fn30WSrD3AJb+8tMAbW6yWV/BQ8XPc16G/DzaA0/UqKBIZtxKScU+H/Lwc3JpK oUhNQNSGBhJMhpJAxUspgT3svCo9HVtEH22vGVwS6F/IwCeQnMQwSVBaAEpwtYEZbfA 7OZCucM/sC4dKVfp5pqOEfc7awTXzZKZRZErmBEw= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_0E0FAB74-D0FE-4202-9CE1-84E92770F248" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-ID: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> Date: Wed, 11 Sep 2019 20:05:17 +0000 Cc: Rifaat Shekh-Yusef , Russ Housley , Sean Turner To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.11-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 20:05:22 -0000 --Apple-Mail=_0E0FAB74-D0FE-4202-9CE1-84E92770F248 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [warning: wide-screen needed] Folks, It seems that there is little appetite to pursue a solution that entails = defining many algorithm identifiers/enumerations in YANG. In Montreal, I presented a "fallback" strategy (see slide 9 here: = https://datatracker.ietf.org/meeting/105/materials/slides-105-netconf-clie= nt-server-suite-of-drafts-00 = ) that sought to leverage ASN.1 structures = (that are heavily used by TLS) as much as possible and, in particular, = rather than crypto-types defining many algorithms, the YANG module = instead uses existing OIDs (ASN.1 object identifiers) to identify the = algorithms and ASN.1 structures to encode them. Testing, I've determined that: 1) `openssl genrsa -out rsa_private_key.pem 2048` creates an = RSAPrivateKey (from rfc3447) - this is a raw key; there is no OID identifying the structure, or = attributes indicating how it should be used. 2) `openssl rsa -in rsa_private_key.pem -pubout -out rsa_public_key.pem` = creates a SubjectPublicKeyInfo (from rfc5280) - the "algorithm" field is "rsaEncryption" (thus indicating how the = key is expected to be used) - the "parameters" field is NULL (which for some reason is actually = the value b'\x05\x00') - the "subjectPublicKey" field is an RSAPublicKey (from rfc5480) 3) `openssl ecparam -genkey -name prime256v1 -out ec_private_key.pem` = creates an ECPrivateKey (from rfc5915) - this is a raw key; there is no OID identifying the structure, or = attributes indicating how it should be used. 4) `openssl ec -in ec_private_key.pem -pubout -out ec_public_key.pem` = creates a SubjectPublicKeyInfo (from rfc5280) - the "algorithm" field is "id_ecPublicKey" (but, unlike = rsaEncryption, this doesn't seem to indicate how the key should be used) - the "parameters" field is a ECParameters (from rfc5480) and (for = me) contains 'namedCurve' being an OID containing value "secp256r1" - the "subjectPublicKey" field is an ECPoint (from rfc5480), which = contains the value of a point on the curve. I've been discussing all this offline with security experts (especially = wrt all these ASN.1 structures) Russ Housley and Sean Turner (CC-ed) for = about a week now. I now feel the need to get some WG feedback before = proceeding much further... Here are some options: OPTION A =3D=3D=3D=3D=3D=3D=3D=3D - Continue pursuing the solution in the draft as is - a holistic mapping = of many algorithm identifiers (more than needed for our use). - Note that everyone that showed interest before haven't been heard from = in awhile. OPTION B =3D=3D=3D=3D=3D=3D=3D=3D - move towards a fallback strategy (two variants are proposed below) - both variations share the following common attributes: a) remove all the crypto-algorithm enumerations from the YANG module = (~70% of the lines) b) use ASN.1 structures to encode symmetric and asymmetric key, both = unencrypted and encrypted. c) figure out a plan for SSH later (the risk level is pretty low, = e.g., I've seen code to key SSH keys from TLS keys) Okay, so now for the two variants: B1 and B2... OPTION B1 (use raw/native keys) ---------------------------------------------- PROs: mostly supported by OpenSSL command line (see commands 1-4 above) = [missing: commands illustrating key-encryption] CONs: private keys have no way to declare their intended use (encrypt vs = sign) or modes (CBS vs GCM). some usage information could be stored in = the public key. no key usage information stored for symmetric keys. module: ietf-keystore +--rw keystore +--rw asymmetric-keys | +--rw asymmetric-key* [name] | +--rw name arbitrary = user-set value | +--rw algorithm <---- this = becomes an OID (e.g., "rsaEncryption") | +--rw public-key <---- this = becomes SubjectPublicKeyInfo ASN.1 structure | +--rw (private-key-type) | +--:(private-key) | | +--rw private-key? <---- this = becomes a raw ASN.1 key (e.g., RSAPrivateKey, ECPrivateKey) | +--:(encrypted-private-key) | +--rw encrypted-private-key | +--rw (key-type) | | +--:(symmetric-key-ref) | | | +--rw symmetric-key-ref? leafref // ref = to another key in keystore | | +--:(asymmetric-key-ref) | | +--rw asymmetric-key-ref? leafref // ref = to another key in keystore | +--rw value? <--- this = becomes an CMS EncryptedData structure containing an OneAsymmetricKey = (from rfc5958) | +--rw symmetric-keys +--rw symmetric-key* [name] +--rw name // arbitrary = user-set value +--rw algorithm <---- TBD, = mostly likely an AlgID value from rfc7210 +--rw (key-type) +--:(key) | +--rw key? <---- this = becomes an OctetString (ASN.1 structure) +--:(encrypted-key) +--rw encrypted-key +--rw (key-type) | +--:(symmetric-key-ref) | | +--rw symmetric-key-ref? // leafref to = another key in keystore | +--:(asymmetric-key-ref) | +--rw asymmetric-key-ref? // leafref to = another key in keystore +--rw value? <---- this = becomes an CMS EncryptedData structure containing an OneSymmetricKey = (from rfc6031) OPTION B2 (use OneSymmetricKey and OneAsymmetricKey) = --------------------------------------------------------------------------= ---------- PROs: private keys can declare their intended use (encrypt vs sign) and = modes (CBS vs GCM) CONs: not supported by OpenSSL command line (but are by languages, e.g., = Python) module: ietf-keystore +--rw keystore +--rw asymmetric-keys | +--rw asymmetric-key* [name] | +--rw name // arbitrary = user-set value | +--rw algorithm <---- this = could be deleted, or set to the same OID as in B1 | +--rw public-key <---- = SubjectPublicKeyInfo ASN.1 structure (same as in B1) | +--rw (private-key-type) | +--:(private-key) | | +--rw private-key? <---- this = becomes a ASN.1 OneAsymmetricKey (from rfc5958) | +--:(encrypted-private-key) | +--rw encrypted-private-key | +--rw (key-type) | | +--:(symmetric-key-ref) | | | +--rw symmetric-key-ref? // leafref to = another key in keystore | | +--:(asymmetric-key-ref) | | +--rw asymmetric-key-ref? // leafref to = another key in keystore | +--rw value? <---- CMS = EncryptedData ASN.1 structure (same as in B1) | +--rw symmetric-keys +--rw symmetric-key* [name] +--rw name arbitrary = user-set value +--rw algorithm <---- this = could be deleted, or set to the same AlgID value from B1 +--rw (key-type) +--:(key) | +--rw key? <---- this = becomes a ASN.1 OneSymmetricKey (from rfc6031) +--:(encrypted-key) +--rw encrypted-key +--rw (key-type) | +--:(symmetric-key-ref) | | +--rw symmetric-key-ref? leafref to = another key in keystore | +--:(asymmetric-key-ref) | +--rw asymmetric-key-ref? leafref to = another key in keystore +--rw value? <--- CMS = EncryptedData ASN.1 structure (same as in B1) In summary: - B1 is easier to support unencrypted keys, but fails to support = some things important to some security folks (not me). - B1 complexity to support encrypted keys is TBD (I'm told OpenSSL = command line can do it, but have yet to verify) - B2 is preferred by crypto folks, but lack an OpenSSL command line = will thwart the development of simple scripts. - NC/RC are programmatic APIs, so complexity shouldn't be driving = factor, though it may affect solution adoption. Thoughts? Kent // co-author --Apple-Mail=_0E0FAB74-D0FE-4202-9CE1-84E92770F248 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
[warning: wide-screen needed]

Folks,

It seems that there is little appetite to pursue a solution = that entails defining many algorithm identifiers/enumerations in = YANG.

In = Montreal, I presented a "fallback" strategy (see slide 9 here: https://datatracker.ietf.org/meeting/105/materials/slides-105-n= etconf-client-server-suite-of-drafts-00) that sought to leverage = ASN.1 structures (that are heavily used by TLS) as much as possible and, = in particular, rather than crypto-types defining many algorithms, the = YANG module instead uses existing OIDs (ASN.1 object identifiers) to = identify the algorithms and ASN.1 structures to encode them.

Testing, I've determined = that:

1) = `openssl genrsa -out rsa_private_key.pem 2048` creates an RSAPrivateKey = (from rfc3447)
     - this is a raw key; = there is no OID identifying the structure, or attributes indicating how = it should be used.

2) `openssl rsa -in = rsa_private_key.pem -pubout -out rsa_public_key.pem` creates a = SubjectPublicKeyInfo (from rfc5280)
     - = the "algorithm" field is "rsaEncryption" (thus indicating how the key is = expected to be used)
     - the = "parameters" field is NULL (which for some reason is actually the value = b'\x05\x00')
     - the "subjectPublicKey" = field is an RSAPublicKey (from rfc5480)

3) = `openssl ecparam -genkey -name prime256v1 -out ec_private_key.pem` = creates an ECPrivateKey (from rfc5915)
    =   - this is a raw key; there is no OID identifying the structure, = or attributes indicating how it should be used.

4) `openssl ec -in ec_private_key.pem -pubout -out = ec_public_key.pem` creates a SubjectPublicKeyInfo (from rfc5280)
     - the "algorithm" field is = "id_ecPublicKey" (but, unlike rsaEncryption, this doesn't seem to = indicate how the key should be used)
    =  - the "parameters" field is a ECParameters (from rfc5480) and (for = me) contains 'namedCurve' being an OID containing = value "secp256r1"
     - the = "subjectPublicKey" field is an ECPoint (from rfc5480), which contains = the value of a point on the curve.

I've been discussing all this offline with security experts = (especially wrt all these ASN.1 structures) Russ Housley and Sean Turner = (CC-ed) for about a week now.  I now feel the need to get some WG = feedback before proceeding much further...

Here are some options:

OPTION A
=3D=3D=3D=3D=3D=3D=3D=3D
- Continue = pursuing the solution in the draft as is - a holistic mapping of many = algorithm identifiers (more than needed for our use).
- Note that everyone that showed interest before haven't been = heard from in awhile.

OPTION B
=3D=3D=3D=3D=3D=3D=3D=3D
- move towards a fallback strategy (two variants are = proposed below)
- both variations share the = following common attributes:
    a) = remove all the crypto-algorithm enumerations from the YANG module (~70% = of the lines)
    b) use = ASN.1 structures to encode symmetric and asymmetric key, both = unencrypted and encrypted.
    c) = figure out a plan for SSH later (the risk level is pretty low, e.g., = I've seen code to key SSH keys from TLS keys)

Okay, so now for the two variants: =  B1 and B2...



OPTION B1  (use raw/native keys)
----------------------------------------------
PROs: mostly supported by OpenSSL command line (see commands = 1-4 above) [missing: commands illustrating key-encryption]
CONs: private keys have no way to declare their intended use = (encrypt vs sign) or modes (CBS vs GCM).  some usage information = could be stored in the public key.  no key usage information stored = for symmetric keys.

module: ietf-keystore
     +--rw = keystore
      =   +--rw asymmetric-keys
    =     |  +--rw asymmetric-key* [name]
  =       |     +--rw name       =                     =        arbitrary user-set value
  =       |     +--rw algorithm     =                     =     <---- this becomes an OID (e.g., "rsaEncryption")
        |     +--rw public-key =                     =        <---- this becomes SubjectPublicKeyInfo = ASN.1 structure
        |   =   +--rw (private-key-type)
      =   |        +--:(private-key)
 =       |        |  +--rw = private-key?                 =   <---- this becomes a raw ASN.1 key (e.g., RSAPrivateKey, = ECPrivateKey)
        |     =    +--:(encrypted-private-key)
    =     |           +--rw = encrypted-private-key
        |   =            +--rw (key-type)
        |         =      |  +--:(symmetric-key-ref)
  =       |              | =  |  +--rw symmetric-key-ref?     leafref // ref = to another key in keystore
        | =              | =  +--:(asymmetric-key-ref)
        = |              |     +--rw = asymmetric-key-ref?    leafref // ref to another key in = keystore
        |     =          +--rw value?       =                 <--- = this becomes an CMS EncryptedData structure containing an = OneAsymmetricKey (from rfc5958)
      =   |
        = +--rw symmetric-keys
        =    +--rw symmetric-key* [name]
    =           +--rw name       =                     =        // arbitrary user-set value
              +--rw = algorithm                   =          <---- TBD, mostly likely = an AlgID value from rfc7210
      =         +--rw (key-type)
    =              +--:(key)
                =  |  +--rw key?             =                 =  <---- this becomes an OctetString (ASN.1 structure)
                =  +--:(encrypted-key)
        =             +--rw encrypted-key
                =        +--rw (key-type)
    =                    | =  +--:(symmetric-key-ref)
        =                |  | =  +--rw symmetric-key-ref?      // leafref to = another key in keystore
          =              | =  +--:(asymmetric-key-ref)
        =                |     = +--rw asymmetric-key-ref?    // leafref to another = key in keystore
            =            +--rw value?     =                   =  <---- this becomes an CMS EncryptedData structure containing an = OneSymmetricKey (from rfc6031)



OPTION B2  (use = OneSymmetricKey and OneAsymmetricKey)
---------------------------------------------------------------= ---------------------
PROs: private keys can declare their intended use = (encrypt vs sign) and modes (CBS vs GCM)
CONs: not = supported by OpenSSL command line (but are by languages, e.g., = Python)

module: ietf-keystore
     +--rw = keystore
      =   +--rw asymmetric-keys
    =     |  +--rw asymmetric-key* [name]
  =       |     +--rw name       =                     =         // arbitrary user-set value
        |     +--rw algorithm =                     =         <---- this could be deleted, or set to = the same OID as in B1
        | =     +--rw public-key             =                <---- = SubjectPublicKeyInfo ASN.1 structure  (same as in B1)
        |     +--rw = (private-key-type)
        |   =      +--:(private-key)
      =   |        |  +--rw private-key?   =                 <---- this = becomes a ASN.1 OneAsymmetricKey (from rfc5958)
        |       =  +--:(encrypted-private-key)
      =   |           +--rw = encrypted-private-key
        |   =            +--rw (key-type)
        |         =      |  +--:(symmetric-key-ref)
  =       |              | =  |  +--rw symmetric-key-ref?      // leafref to = another key in keystore
        | =              | =  +--:(asymmetric-key-ref)
        = |              |     +--rw = asymmetric-key-ref?    // leafref to another key in = keystore
        |     =          +--rw value?       =                   <---- = CMS EncryptedData ASN.1 structure (same as in B1)
        |
  =       +--rw symmetric-keys
  =          +--rw symmetric-key* [name]
              +--rw name =                     =              arbitrary user-set = value
              = +--rw algorithm                 =            <---- this could be deleted, = or set to the same AlgID value from B1
    =           +--rw (key-type)
  =                +--:(key)
                =  |  +--rw key?             =                 =  <---- this becomes a ASN.1 OneSymmetricKey (from = rfc6031)
              =    +--:(encrypted-key)
      =               +--rw encrypted-key
                =        +--rw (key-type)
    =                    | =  +--:(symmetric-key-ref)
        =                |  | =  +--rw symmetric-key-ref?     leafref to another key = in keystore
            =            | =  +--:(asymmetric-key-ref)
        =                |     = +--rw asymmetric-key-ref?    leafref to another key in = keystore
              =          +--rw value?       =               =    <---  CMS EncryptedData ASN.1 = structure (same as in B1)




In = summary:
    - B1 is easier to support = unencrypted keys, but fails to support some things important to some = security folks (not me).
    - B1 = complexity to support encrypted keys is TBD (I'm told OpenSSL command = line can do it, but have yet to verify)
  =   - B2 is preferred by crypto folks, but lack an OpenSSL command = line will thwart the development of simple scripts.
    - NC/RC are programmatic APIs, so complexity = shouldn't be driving factor, though it may affect solution = adoption.


Thoughts?

Kent // co-author




= --Apple-Mail=_0E0FAB74-D0FE-4202-9CE1-84E92770F248-- From nobody Wed Sep 11 13:27:10 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612C0120227 for ; Wed, 11 Sep 2019 13:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 R91RSVLIiM9G for ; Wed, 11 Sep 2019 13:27:07 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 10D7F1201CE for ; Wed, 11 Sep 2019 13:27:06 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x8BKR2HB012376; Wed, 11 Sep 2019 21:27:05 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=f4RL/rLUzLinaXJAOUcIduzLUM3Mx94TB2Og3nfeHvA=; b=MeiVJmc3dObLZ8uugZEyS73aPuFhhMaV2PcZKuDAQ+j8Q/bQMZg7ptBlMLqjU6/ZYM/f oU83SltNxdnU1sxUC7mPYWvU3zIGs8n04QbrG/dTEN6jA4jaL+16L5FBo/ec25DH1OYv 4WHhUEGwGFOLIBSPBXA+KswIUCv4Wxi8MHi2CeHvRHY0xXWzKqEEFv7bYbYc3heCewo6 Yqq4qufo3idjIJuhFXGXGMQfqbLyJjYzfYc7AtT9KjBOygEDBjhaKDNHJ/tW31wCw4+R J3dJo158y4v/yxk+U6E18KRZS76sKjyobuAbVWFaKCBvoFwAoT2ghFjREz2MXhoUCebC qw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2uv4y8mhw7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Sep 2019 21:27:05 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x8BKHt77027510; Wed, 11 Sep 2019 16:27:04 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint1.akamai.com with ESMTP id 2uv7vwe8s5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 11 Sep 2019 16:27:04 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 11 Sep 2019 16:27:03 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Wed, 11 Sep 2019 16:27:03 -0400 From: "Salz, Rich" To: Kent Watsen , "netconf@ietf.org" CC: Russ Housley , Rifaat Shekh-Yusef , Sean Turner Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxGVhFlbERW30moo9Q8WhnpJqcm7NKA Date: Wed, 11 Sep 2019 20:27:03 +0000 Message-ID: <47C71B4D-DC22-4090-B60C-5AC7B1ECF4B9@akamai.com> References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> In-Reply-To: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.227] Content-Type: multipart/alternative; boundary="_000_47C71B4DDC224090B60C5AC7B1ECF4B9akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-11_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=962 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1909110182 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-11_10:2019-09-11,2019-09-11 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 impostorscore=0 lowpriorityscore=0 mlxlogscore=942 adultscore=0 malwarescore=0 clxscore=1011 phishscore=0 spamscore=0 bulkscore=0 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1909110184 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2019 20:27:09 -0000 --_000_47C71B4DDC224090B60C5AC7B1ECF4B9akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSXQgc2VlbXMgdGhhdCB0aGVyZSBpcyBsaXR0bGUgYXBwZXRpdGUgdG8gcHVyc3VlIGEg c29sdXRpb24gdGhhdCBlbnRhaWxzIGRlZmluaW5nIG1hbnkgYWxnb3JpdGhtIGlkZW50aWZpZXJz L2VudW1lcmF0aW9ucyBpbiBZQU5HLg0KDQpJIGFtIGdsYWQgb2YgdGhpcy4NCg0KQW4gaW1wb3J0 YW50IHRoaW5nIHRvIHJlYWxpemUgaXMgdGhhdCBtYW55IGNyeXB0b2dyYXBoaWMgZGF0YXR5cGVz IHdlcmUgZGVzaWduZWQgZm9yIHNwZWNpYWwgcHVycG9zZXMsIGFuZCBicmVha2luZyBldmVyeXRo aW5nIGRvd24gaW50byBpdHMgY29tcG9uZW50IHBhcnRzIGRlZmVhdHMgc29tZSBvZiB0aGUgc2Vj dXJpdHkgKHNlcGFyYXRpbmcgdGhlIHBhcmFtZXRlcnMgZnJvbSBhbiBSU0EtUFNTIGtleSwgZm9y IGV4YW1wbGUpLCBvciBkZXBsb3ltZW50IGlzc3VlcyAoc3VjaCBhcyBzZXBhcmF0aW5nIHRoZSBz aWduYXR1cmUgZnJvbSB0aGUgY2VydGlmaWNhdGUgcmVxdWVzdCBvciBzcGxpdHRpbmcgdXAgYSBD QSBjZXJ0IGNoYWluIGludG8gdGhlIGluZGl2aWR1YWwgY2VydHMpLg0KDQpEbyBub3QgdHJ5IGZv ciBhbiBvbW5pYnVzIG9mIGNyeXB0b2dyYXBoaWMgdHlwZXMg4oCTIGFueSBnaXZlbiBhcHBsaWNh dGlvbiB3aWxsIGFsbW9zdCBkZWZpbml0ZWx5IG5ldmVyIGhhdmUgdG8gdXNlIGFsbCB0aGUgdHlw ZXMgaW4gYSBtb2R1bGUuIFN0YXJ0IHdpdGggc29tZXRoaW5nIHNtYWxsLCBzdWNoIGFzIHdoYXQg aXMgbmVlZGVkIHRvIGNvbmZpZ3VyZSBhbiBIVFRQUyBzZXJ2ZXIg4oCTIGEgY2VydCBjaGFpbiwg YW4gZW5kLWVudGl0eSBjZXJ0LCBhbmQgYSBwcml2YXRlIGtleS4gIEFsbCBvZiB0aGVzZSBjYW4g YmUgaGFuZGxlZCBieSBPcGVuU1NMIGNvbW1hbmQtbGluZS4gIEZ1dHVyZSBtb2R1bGVzIGNvdWxk IGFkZCBTU0ggcHJvdmlzaW9uaW5nLCBWUE4ga2V5IG1hbmFnZW1lbnQsIEtlcmJlcm9zIGxvZ2lu IGFjdGlvbnMsIGFuZCBzdWNobGlrZS4NCg0KU3RhcnRpbmcgd2l0aCB0aGUgSFRUUFMgc2VydmVy LCBhbGwgb2YgdGhvc2Ugb2JqZWN0cyBhcmUsIGFzIHlvdSBwb2ludCBvdXQsIHN0cnVjdHVyZXMg ZGVmaW5lZCBpbiBBU04xIGFuZCBlbmNvZGVkIGluIERFUi4gRm9yIGNvbmZpZ3VyYXRpb24sIHRo ZXkgYXJlIGdlbmVyYWxseSBtYWludGFpbmVkIGFzIGJhc2UtNjQgZW5jb2RlZCBmaWxlcywgd2l0 aCBhIGtub3duIGhlYWRlciBhbmQgdHJhaWxlciBsaW5lLiBUaGlzIGlzIHBvcHVsYXJpemVkIGJ5 IE9wZW5TU0wgYXMgdGhlIFBFTSBmb3JtYXQsIHdoaWNoIGhhcmtlbnMgYmFjayB0byBSRkMgMTQy MS4gUkZDIDc0NjggaXMgYW4gZXhjZWxsZW50IHN0YXJ0aW5nIHBvaW50IGZvciBhY3R1YWwgdXNl IG9mIHRoYXQuDQoNCkhvcGUgdGhpcyBoZWxwcy4gIEkgd291bGQgYmUgZ2xhZCB0byBjb250cmli dXRlIHRvIGEgZHJhZnQgZGV2ZWxvcGVkIGFsb25nIHRoZXNlIGxpbmVzLg0KDQo= --_000_47C71B4DDC224090B60C5AC7B1ECF4B9akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNzI5NDU1OTk1Ow0KCW1zby1saXN0LXR5 cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNjgwMDA1MDQ4IC03MTExNjQwMzQg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDow Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1m YW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpv bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48 L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRv cDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5JdCBzZWVtcyB0aGF0IHRo ZXJlIGlzIGxpdHRsZSBhcHBldGl0ZSB0byBwdXJzdWUgYSBzb2x1dGlvbiB0aGF0IGVudGFpbHMg ZGVmaW5pbmcgbWFueSBhbGdvcml0aG0gaWRlbnRpZmllcnMvZW51bWVyYXRpb25zIGluIFlBTkcu PG86cD48L286cD48L2xpPjwvdWw+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIGdsYWQgb2YgdGhpcy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW4gaW1wb3J0YW50IHRoaW5n IHRvIHJlYWxpemUgaXMgdGhhdCBtYW55IGNyeXB0b2dyYXBoaWMgZGF0YXR5cGVzIHdlcmUgZGVz aWduZWQgZm9yIHNwZWNpYWwgcHVycG9zZXMsIGFuZCBicmVha2luZyBldmVyeXRoaW5nIGRvd24g aW50byBpdHMgY29tcG9uZW50IHBhcnRzIGRlZmVhdHMgc29tZSBvZiB0aGUgc2VjdXJpdHkgKHNl cGFyYXRpbmcgdGhlIHBhcmFtZXRlcnMgZnJvbSBhbiBSU0EtUFNTIGtleSwgZm9yDQogZXhhbXBs ZSksIG9yIGRlcGxveW1lbnQgaXNzdWVzIChzdWNoIGFzIHNlcGFyYXRpbmcgdGhlIHNpZ25hdHVy ZSBmcm9tIHRoZSBjZXJ0aWZpY2F0ZSByZXF1ZXN0IG9yIHNwbGl0dGluZyB1cCBhIENBIGNlcnQg Y2hhaW4gaW50byB0aGUgaW5kaXZpZHVhbCBjZXJ0cykuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkRvIG5vdCB0cnkgZm9yIGFuIG9tbmlidXMgb2YgY3J5cHRvZ3JhcGhpYyB0eXBlcyDigJMgYW55 IGdpdmVuIGFwcGxpY2F0aW9uIHdpbGwgYWxtb3N0IGRlZmluaXRlbHkgbmV2ZXIgaGF2ZSB0byB1 c2UgYWxsIHRoZSB0eXBlcyBpbiBhIG1vZHVsZS4gU3RhcnQgd2l0aCBzb21ldGhpbmcgc21hbGws IHN1Y2ggYXMgd2hhdCBpcyBuZWVkZWQgdG8gY29uZmlndXJlIGFuIEhUVFBTIHNlcnZlciDigJMg YSBjZXJ0IGNoYWluLA0KIGFuIGVuZC1lbnRpdHkgY2VydCwgYW5kIGEgcHJpdmF0ZSBrZXkuJm5i c3A7IEFsbCBvZiB0aGVzZSBjYW4gYmUgaGFuZGxlZCBieSBPcGVuU1NMIGNvbW1hbmQtbGluZS4m bmJzcDsgRnV0dXJlIG1vZHVsZXMgY291bGQgYWRkIFNTSCBwcm92aXNpb25pbmcsIFZQTiBrZXkg bWFuYWdlbWVudCwgS2VyYmVyb3MgbG9naW4gYWN0aW9ucywgYW5kIHN1Y2hsaWtlLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5TdGFydGluZyB3aXRoIHRoZSBIVFRQUyBzZXJ2ZXIsIGFsbCBvZiB0 aG9zZSBvYmplY3RzIGFyZSwgYXMgeW91IHBvaW50IG91dCwgc3RydWN0dXJlcyBkZWZpbmVkIGlu IEFTTjEgYW5kIGVuY29kZWQgaW4gREVSLiBGb3IgY29uZmlndXJhdGlvbiwgdGhleSBhcmUgZ2Vu ZXJhbGx5IG1haW50YWluZWQgYXMgYmFzZS02NCBlbmNvZGVkIGZpbGVzLCB3aXRoIGEga25vd24g aGVhZGVyIGFuZCB0cmFpbGVyIGxpbmUuDQogVGhpcyBpcyBwb3B1bGFyaXplZCBieSBPcGVuU1NM IGFzIHRoZSBQRU0gZm9ybWF0LCB3aGljaCBoYXJrZW5zIGJhY2sgdG8gUkZDIDE0MjEuIFJGQyA3 NDY4IGlzIGFuIGV4Y2VsbGVudCBzdGFydGluZyBwb2ludCBmb3IgYWN0dWFsIHVzZSBvZiB0aGF0 LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3BlIHRoaXMgaGVscHMuJm5ic3A7IEkgd291bGQg YmUgZ2xhZCB0byBjb250cmlidXRlIHRvIGEgZHJhZnQgZGV2ZWxvcGVkIGFsb25nIHRoZXNlIGxp bmVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_47C71B4DDC224090B60C5AC7B1ECF4B9akamaicom_-- From nobody Thu Sep 12 02:13:14 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A5112006A for ; Thu, 12 Sep 2019 02:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 eTHGqFl2NoP0 for ; Thu, 12 Sep 2019 02:13:09 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDCE12004E for ; Thu, 12 Sep 2019 02:13:09 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id D069A1AE0187; Thu, 12 Sep 2019 11:13:06 +0200 (CEST) Date: Thu, 12 Sep 2019 11:12:42 +0200 (CEST) Message-Id: <20190912.111242.323252506550752617.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: netconf@ietf.org, housley@vigilsec.com, rifaat.ietf@gmail.com, sean@sn3rd.com From: Martin Bjorklund In-Reply-To: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 09:13:12 -0000 Hi, Kent Watsen wrote: > [warning: wide-screen needed] > > Folks, > > It seems that there is little appetite to pursue a solution that > entails defining many algorithm identifiers/enumerations in YANG. > > In Montreal, I presented a "fallback" strategy (see slide 9 here: > https://datatracker.ietf.org/meeting/105/materials/slides-105-netconf-client-server-suite-of-drafts-00 > ) > that sought to leverage ASN.1 structures (that are heavily used by > TLS) as much as possible and, in particular, rather than crypto-types > defining many algorithms, the YANG module instead uses existing OIDs > (ASN.1 object identifiers) to identify the algorithms and ASN.1 > structures to encode them. > > Testing, I've determined that: > > 1) `openssl genrsa -out rsa_private_key.pem 2048` creates an > RSAPrivateKey (from rfc3447) > - this is a raw key; there is no OID identifying the structure, or > - attributes indicating how it should be used. > > 2) `openssl rsa -in rsa_private_key.pem -pubout -out > rsa_public_key.pem` creates a SubjectPublicKeyInfo (from rfc5280) > - the "algorithm" field is "rsaEncryption" (thus indicating how the key > - is expected to be used) > - the "parameters" field is NULL (which for some reason is actually the > - value b'\x05\x00') > - the "subjectPublicKey" field is an RSAPublicKey (from rfc5480) > > 3) `openssl ecparam -genkey -name prime256v1 -out ec_private_key.pem` > creates an ECPrivateKey (from rfc5915) > - this is a raw key; there is no OID identifying the structure, or > - attributes indicating how it should be used. > > 4) `openssl ec -in ec_private_key.pem -pubout -out ec_public_key.pem` > creates a SubjectPublicKeyInfo (from rfc5280) > - the "algorithm" field is "id_ecPublicKey" (but, unlike rsaEncryption, > - this doesn't seem to indicate how the key should be used) > - the "parameters" field is a ECParameters (from rfc5480) and (for me) > - contains 'namedCurve' being an OID containing value "secp256r1" > - the "subjectPublicKey" field is an ECPoint (from rfc5480), which > - contains the value of a point on the curve. > > > I've been discussing all this offline with security experts > (especially wrt all these ASN.1 structures) Russ Housley and Sean > Turner (CC-ed) for about a week now. I now feel the need to get some > WG feedback before proceeding much further... > > Here are some options: > > OPTION A > ======== > - Continue pursuing the solution in the draft as is - a holistic mapping > - of many algorithm identifiers (more than needed for our use). > - Note that everyone that showed interest before haven't been heard from > - in awhile. > > OPTION B > ======== > - move towards a fallback strategy (two variants are proposed below) > - both variations share the following common attributes: > a) remove all the crypto-algorithm enumerations from the YANG module > (~70% of the lines) > b) use ASN.1 structures to encode symmetric and asymmetric key, both > unencrypted and encrypted. I'm not a security expert so I don't have any input on which ASN.1 structure to support. But it seems to me that in both B1 and B2, the "algorithm" leaf isn't really necessary in the config, right? I guess it is still needed when a key is generated though. But then note that "rsaEncryption" is not an OID ("1.2.840.113549.1.1.1" is the OID). If you want to use a symbolic name you need something else. Is the idea that the module becomes ietf-tls-keystore with top-level node tls-keystore? > c) figure out a plan for SSH later Hmm, what does this mean? That we won't do ietf-netconf-server now? > Okay, so now for the two variants: B1 and B2... > > > > OPTION B1 (use raw/native keys) > ---------------------------------------------- > PROs: mostly supported by OpenSSL command line (see commands 1-4 > above) [missing: commands illustrating key-encryption] > CONs: private keys have no way to declare their intended use (encrypt > vs sign) or modes (CBS vs GCM). some usage information could be > stored in the public key. no key usage information stored for > symmetric keys. > > module: ietf-keystore > +--rw keystore > +--rw asymmetric-keys > | +--rw asymmetric-key* [name] > | +--rw name arbitrary user-set value > | +--rw algorithm <---- this becomes an OID (e.g., "rsaEncryption") > | +--rw public-key <---- this becomes SubjectPublicKeyInfo ASN.1 > | structure > | +--rw (private-key-type) > | +--:(private-key) > | | +--rw private-key? <---- this becomes a raw ASN.1 key > | | (e.g., RSAPrivateKey, ECPrivateKey) > | +--:(encrypted-private-key) > | +--rw encrypted-private-key > | +--rw (key-type) > | | +--:(symmetric-key-ref) > | | | +--rw symmetric-key-ref? leafref // ref to > | | | another key in keystore > | | +--:(asymmetric-key-ref) > | | +--rw asymmetric-key-ref? leafref // ref to > | | another key in keystore > | +--rw value? <--- this becomes an CMS EncryptedData > | structure containing an OneAsymmetricKey (from rfc5958) > | > +--rw symmetric-keys > +--rw symmetric-key* [name] > +--rw name // arbitrary user-set value > +--rw algorithm <---- TBD, mostly likely an AlgID value from > rfc7210 > +--rw (key-type) > +--:(key) > | +--rw key? <---- this becomes an OctetString (ASN.1 > | structure) > +--:(encrypted-key) > +--rw encrypted-key > +--rw (key-type) > | +--:(symmetric-key-ref) > | | +--rw symmetric-key-ref? // leafref to another > | | key in keystore > | +--:(asymmetric-key-ref) > | +--rw asymmetric-key-ref? // leafref to another > | key in keystore > +--rw value? <---- this becomes an CMS EncryptedData > structure containing an OneSymmetricKey (from rfc6031) > > > > OPTION B2 (use OneSymmetricKey and OneAsymmetricKey) > ------------------------------------------------------------------------------------ > PROs: private keys can declare their intended use (encrypt vs sign) > and modes (CBS vs GCM) > CONs: not supported by OpenSSL command line (but are by languages, > e.g., Python) > > module: ietf-keystore > +--rw keystore > +--rw asymmetric-keys > | +--rw asymmetric-key* [name] > | +--rw name // arbitrary user-set value > | +--rw algorithm <---- this could be deleted, or set to the same > | OID as in B1 > | +--rw public-key <---- SubjectPublicKeyInfo ASN.1 structure (same > | as in B1) > | +--rw (private-key-type) > | +--:(private-key) > | | +--rw private-key? <---- this becomes a ASN.1 > | | OneAsymmetricKey (from rfc5958) > | +--:(encrypted-private-key) > | +--rw encrypted-private-key > | +--rw (key-type) > | | +--:(symmetric-key-ref) > | | | +--rw symmetric-key-ref? // leafref to another > | | | key in keystore > | | +--:(asymmetric-key-ref) > | | +--rw asymmetric-key-ref? // leafref to another > | | key in keystore > | +--rw value? <---- CMS EncryptedData ASN.1 structure > | (same as in B1) > | > +--rw symmetric-keys > +--rw symmetric-key* [name] > +--rw name arbitrary user-set value > +--rw algorithm <---- this could be deleted, or set to the same > AlgID value from B1 > +--rw (key-type) > +--:(key) > | +--rw key? <---- this becomes a ASN.1 OneSymmetricKey > | (from rfc6031) > +--:(encrypted-key) > +--rw encrypted-key > +--rw (key-type) > | +--:(symmetric-key-ref) > | | +--rw symmetric-key-ref? leafref to another key > | | in keystore > | +--:(asymmetric-key-ref) > | +--rw asymmetric-key-ref? leafref to another key > | in keystore > +--rw value? <--- CMS EncryptedData ASN.1 structure > (same as in B1) > > > > > In summary: > - B1 is easier to support unencrypted keys, but fails to support some > things important to some security folks (not me). > - B1 complexity to support encrypted keys is TBD (I'm told OpenSSL > command line can do it, but have yet to verify) > - B2 is preferred by crypto folks, but lack an OpenSSL command line will > thwart the development of simple scripts. > - NC/RC are programmatic APIs, so complexity shouldn't be driving > factor, though it may affect solution adoption. Yes, NC/RC are programmatic APIs, but simplicity is always goodness... /martin > > > Thoughts? > > Kent // co-author > > > > From nobody Thu Sep 12 05:43:12 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6B312006D for ; Thu, 12 Sep 2019 05:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=J1VT+Kgc; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Yy8Wsqa5 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 kOqtHMvgcZxG for ; Thu, 12 Sep 2019 05:43:08 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65ED812008A for ; Thu, 12 Sep 2019 05:43:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7165; q=dns/txt; s=iport; t=1568292188; x=1569501788; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=obO6aC5sNyYE10yhJEgXGjiHSdq0K6DKBP7I9H7pFVY=; b=J1VT+KgcjPWq1wtY41cimcQiUlk+PhfyttP88GgtlLAUAgyGkbe9RgQt 4RAWZH87+s0SFPJvlw7eOV96/oYG4L0Q3oTG7wpPImd/urM4qrD4tG/iH lpOgIrsJHl1losHEO1llLXI/dryn7sbxb/Hm01IYWEslJv8VUldpFwuxh w=; IronPort-PHdr: =?us-ascii?q?9a23=3AXdtMfha758sdjMsTYi3VYfr/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gebRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavwdSU6Gc1EfFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AtAACtPHpd/5RdJa1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVgIBAQEBCwGBFS9QA21WIAQLKgqEF4NHA4ppTYFqJYlliS+?= =?us-ascii?q?EXIJSA1QJAQEBDAEBJQgCAQGEPwIXgkUjNwYOAgMBAwIDAQEEAQEBAgEGBG2?= =?us-ascii?q?FLgyFSgEBAQEDEhEdAQE1Aw8CAQgOAwMBAisCAgIfER0IAgQBEiKDAAGBHU0?= =?us-ascii?q?DHQECDKBLAoE4iGFzgTKCfQEBBYE2AoEPgkINC4IWAwaBNAGLdxiBQD+BESc?= =?us-ascii?q?ME4JMPoIaRwEBA4F+DYJeMoImj0CFIYkYjhFBCoIhhwGJdoQAG4I0h0CPFo1?= =?us-ascii?q?/iASCBo5kAgQCBAUCDgEBBYFoIoFYcBVlAYJBUBAUgU6DcoUUhT9zgSmNXAG?= =?us-ascii?q?BIgEB?= X-IronPort-AV: E=Sophos;i="5.64,497,1559520000"; d="scan'208,217";a="336143102" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Sep 2019 12:43:07 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x8CCh7LA013274 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Sep 2019 12:43:07 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 12 Sep 2019 07:43:06 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 12 Sep 2019 07:43:03 -0500 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 12 Sep 2019 08:43:03 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IIzU2ripirPIcxVo1jIth9LRYhfjvFJhr5M5JrtewnaHjLRhh50YoOOO3cHeHeKqI6gmKLEdXk73dSAiogZ4irj81Ad/nOkParvPqb2pmAeB5/UlbTC1NeIPwuvBEx7u9F0tYrdMNhIwaJNBlUJ1I7ofQdeatHfX2PC72V+ha3HFMc3n0yGQXOTd+NWq8vKh+6/ER6zUpJqwaxIKkvP3+B8HefrOY87T8NlMAL/ZUXEZXY38Nzv4aK9xAwQZ1TEV7ORoas15Fn18cAwoxpKQKRXaluQ9XPGoc9RJeVljUZeMH3rOqt0HLAHSqxXEQtWyNIY7n/6xUF0Nmo8qIZOENg== 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=obO6aC5sNyYE10yhJEgXGjiHSdq0K6DKBP7I9H7pFVY=; b=IDYCc0RIuZgLhM6XE6TBsXNOoWTkC2D8RKmS69hLKo+e2NBZLwdo47UtHjIED5IPaKnS9qcHxIrO1+bzXTx9TOTS4fSLBmjmWsnzWMHqxz0eHhsRYzb3FomMdYKqPHf6MXJF+pfYVYFkbTsygNZnRp/bimhfO0IZY6a7Fe+/3yXNXaRX2UDqn2TgOnnKG4SzCwx5bfk3W/WM3DS8eEuUclpo7UxuP8p6EPmfy657jQ0yAjdD9WVA9/JnqMNLXOIW0MEH3qzVaL1dKolhOI1JCJGExhU+qwm7muhWMKg7YhM3gK4skc3jhf3ITIltBPfLS8BR8LRlZJnhyyKRDyQIOw== 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=obO6aC5sNyYE10yhJEgXGjiHSdq0K6DKBP7I9H7pFVY=; b=Yy8Wsqa5x0oZN6MXKsaK2rU3JY+1sQMxSALAin7LR8tFLVLVeyU/7sdDGxwX6a2nClYJzYPg/tK1M1aY+Q0fcOzJSBDX5ES7esibLBbvPYqQC8wfIg2o7cPyraAivlxr+JcfT3Jd7C405clkOUcGQl9P+fOlHl1WUhPns3jIrAw= Received: from DM6PR11MB4155.namprd11.prod.outlook.com (20.176.126.216) by DM6PR11MB3386.namprd11.prod.outlook.com (20.176.123.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.17; Thu, 12 Sep 2019 12:43:00 +0000 Received: from DM6PR11MB4155.namprd11.prod.outlook.com ([fe80::61bb:bf98:d88b:405f]) by DM6PR11MB4155.namprd11.prod.outlook.com ([fe80::61bb:bf98:d88b:405f%6]) with mapi id 15.20.2241.022; Thu, 12 Sep 2019 12:43:00 +0000 From: "Reshad Rahman (rrahman)" To: Mahesh Jethanandani , Netconf Thread-Topic: [netconf] WGLC for draft-ietf-netconf-notification-capabilities Thread-Index: AQHVaCiuNUb+vAgu8kyXBpQ7JPAaw6cnu9YA Date: Thu, 12 Sep 2019 12:42:59 +0000 Message-ID: <14B831D9-41BF-4132-B1BE-E71B032817F7@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1c.0.190812 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-originating-ip: [173.38.117.65] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ca79edd4-0cd3-4f31-66c8-08d7377ebeb9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM6PR11MB3386; x-ms-traffictypediagnostic: DM6PR11MB3386: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01583E185C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(366004)(396003)(39860400002)(346002)(199004)(189003)(8936002)(256004)(14444005)(110136005)(486006)(66066001)(58126008)(476003)(229853002)(316002)(6486002)(86362001)(81166006)(33656002)(36756003)(606006)(478600001)(2906002)(25786009)(8676002)(81156014)(6512007)(6116002)(14454004)(236005)(53936002)(54896002)(6436002)(2420400007)(15650500001)(6306002)(3846002)(99286004)(71200400001)(76176011)(71190400001)(7736002)(186003)(6506007)(11346002)(66556008)(2616005)(5660300002)(7110500001)(53546011)(102836004)(446003)(26005)(66446008)(64756008)(91956017)(76116006)(66476007)(66946007)(4744005)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB3386; H:DM6PR11MB4155.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 6L6R5CfhEKzegjJU7WxXpexSMlvwE6ObjyPqhaFBQqzyKicxNqiEFcsfd8Ki8p7ej52jBkq2fhcg1CXH8QfCwXA3BPoIsy2xPt13dPHGnN665JwHyC1obmF0BwmjQDRfdkS7frAYC0HPGFEvmAjWrzpJlj8xcmFFVeS9HQwVMNLRn0Mk/bzgs64ZRVgg/Y6bqVCkM2HqQ91cOt/YkAQmyLf7+lKRCvnSll+mO2vROfEUldwjWB4G4qWYeIojac2dzvkcaA+KlG1Lalubffvamp5c/YUrNfWnWy8oV+Tkb0go5crk/2D/+EB3hivvq/PWWn44/Sy7OtRhmExYQGEJ9jbNEI5poG7qEZ65I/StiukCVhOJH/erP/xQ4XyD+RGwa9c2BZi0TRa6LXke1XDHB/X3Fh6fDJd2xGHX1tecDow= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_14B831D941BF4132B1BEE71B032817F7ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ca79edd4-0cd3-4f31-66c8-08d7377ebeb9 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Sep 2019 12:43:00.0123 (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: NpLeokIlJDbSReNOOE2EDyWQSVpjxntqFJ2clXAJD2knPNXjxh/BkqpRPBkQv58X9I/YHueYuNcij6dPr1FemA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3386 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 12:43:11 -0000 --_000_14B831D941BF4132B1BEE71B032817F7ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBiZWxpZXZlIHRoaXMgZG9jdW1lbnQgaXMgcmVhZHkgdG8gbW92ZSBmb3J3YXJkLiBJIGhhdmUg Y2hlY2tlZCB0aGF0IG15IGNvbW1lbnRzIGhhdmUgYmVlbiBhZGRyZXNzZWQgaW4gdGhlIGxhdGVz dCByZXYuDQoNClJlZ2FyZHMsDQpSZXNoYWQuDQoNCkZyb206IG5ldGNvbmYgPG5ldGNvbmYtYm91 bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIE1haGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRoYW5h bmRhbmlAZ21haWwuY29tPg0KRGF0ZTogVHVlc2RheSwgU2VwdGVtYmVyIDEwLCAyMDE5IGF0IDY6 NDAgUE0NClRvOiBOZXRjb25mIDxuZXRjb25mQGlldGYub3JnPg0KU3ViamVjdDogW25ldGNvbmZd IFdHTEMgZm9yIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tY2FwYWJpbGl0aWVzDQoN CkF1dGhvcnMgaGF2ZSBwdWJsaXNoZWQgLTA0PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLWNhcGFiaWxpdGllcy0wND4gdmVyc2lvbiBv ZiB0aGUgZHJhZnQsIHdoaWNoIGFkZHJlc3NlcyBjb21tZW50cyB0aGV5IHJlY2VpdmVkIGluIElF VEYgMTA1LiBJZiB5b3UgcHJvdmlkZWQgY29tbWVudHMgcGxlYXNlIGNoZWNrIHRvIG1ha2Ugc3Vy ZSB5b3VyIGNvbW1lbnRzIGhhdmUgYmVlbiBhZGRyZXNzZWQuIEF0IHRoaXMgcG9pbnQsIHRoZSBh dXRob3JzIGJlbGlldmUgdGhhdCB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIFdHTEMuDQoNClRo aXMgdGhlcmVmb3JlIHN0YXJ0cyBhIHR3byB3ZWVrIExDLCBlbmRpbmcgb24gU2VwdGVtYmVyIDI0 dGguIFBsZWFzZSBwcm92aWRlIGFueSB0ZWNobmljYWwgY29tbWVudHMgeW91IG1pZ2h0IGhhdmUg b24gdGhlIGRvY3VtZW50LiBJZiB5b3UgYmVsaWV2ZSB0aGUgZG9jdW1lbnQgaXMgbm90IHJlYWR5 IGZvciBMQywgcGxlYXNlIHN0YXRlIHlvdXIgcmVhc29ucy4NCg0KV2Ugd2lsbCBpc3N1ZSBhIElQ UiBwb2xsIHNlcGFyYXRlbHkuDQoNCk1haGVzaCAmIEtlbnQgKGFzIGNvLWNoYWlycykNCg0KDQoN Cg== --_000_14B831D941BF4132B1BEE71B032817F7ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0 IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1DQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JIGJlbGlldmUgdGhpcyBkb2N1bWVudCBpcyByZWFk eSB0byBtb3ZlIGZvcndhcmQuIEkgaGF2ZSBjaGVja2VkIHRoYXQgbXkgY29tbWVudHMgaGF2ZSBi ZWVuIGFkZHJlc3NlZCBpbiB0aGUgbGF0ZXN0IHJldi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlJlc2hhZC48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5uZXRjb25mICZs dDtuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBNYWhlc2ggSmV0aGFu YW5kYW5pICZsdDttamV0aGFuYW5kYW5pQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+ VHVlc2RheSwgU2VwdGVtYmVyIDEwLCAyMDE5IGF0IDY6NDAgUE08YnI+DQo8Yj5UbzogPC9iPk5l dGNvbmYgJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltuZXRj b25mXSBXR0xDIGZvciBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLWNhcGFiaWxpdGll czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B dXRob3JzIGhhdmUgcHVibGlzaGVkJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tY2FwYWJpbGl0aWVzLTA0Ij4t MDQ8L2E+Jm5ic3A7dmVyc2lvbiBvZiB0aGUgZHJhZnQsIHdoaWNoIGFkZHJlc3NlcyBjb21tZW50 cyB0aGV5IHJlY2VpdmVkIGluIElFVEYgMTA1LiBJZiB5b3UgcHJvdmlkZWQgY29tbWVudHMgcGxl YXNlIGNoZWNrIHRvIG1ha2UNCiBzdXJlIHlvdXIgY29tbWVudHMgaGF2ZSBiZWVuIGFkZHJlc3Nl ZC4gQXQgdGhpcyBwb2ludCwgdGhlIGF1dGhvcnMgYmVsaWV2ZSB0aGF0IHRoZSBkb2N1bWVudCBp cyByZWFkeSBmb3IgV0dMQy4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhpcyB0aGVyZWZvcmUgc3RhcnRzIGEgdHdvIHdlZWsgTEMsIGVuZGluZyBvbiBT ZXB0ZW1iZXIgMjR0aC4gUGxlYXNlIHByb3ZpZGUgYW55IHRlY2huaWNhbCBjb21tZW50cyB5b3Ug bWlnaHQgaGF2ZSBvbiB0aGUgZG9jdW1lbnQuIElmIHlvdSBiZWxpZXZlIHRoZSBkb2N1bWVudCBp cyBub3QgcmVhZHkgZm9yIExDLCBwbGVhc2Ugc3RhdGUgeW91ciByZWFzb25zLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSB3aWxsIGlzc3Vl IGEgSVBSIHBvbGwgc2VwYXJhdGVseS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+TWFoZXNoICZhbXA7IEtlbnQgKGFzIGNvLWNoYWlycyk8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_14B831D941BF4132B1BEE71B032817F7ciscocom_-- From nobody Thu Sep 12 07:58:08 2019 Return-Path: <0100016d25fb3271-68ef0906-3386-4045-99aa-c9befc840ce6-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DC7120106 for ; Thu, 12 Sep 2019 07:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 WdQPxGUUIweD for ; Thu, 12 Sep 2019 07:58:05 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA21F120041 for ; Thu, 12 Sep 2019 07:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568300282; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=U2WS+DnrGpSSROEmCsdcwb1pVPsitFPMwyqsDBuVru8=; b=H7/cQ8rB9xIooRWwXC5UQfbr0SZLxe5Tktr5VBWgxm3fwUuoAX2i1LTdhH4rJo3G sY3XF1NEZ/R6OKziPYmF2Z5bbaODotORd+H0sKYiuS0hMF9Rxb6Ow+13p/owVJMQ6qx 4FTiEdzHMPByi9pxRPqUnwCQnHDr+y2R7ayASiGc= From: Kent Watsen Message-ID: <0100016d25fb3271-68ef0906-3386-4045-99aa-c9befc840ce6-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8B8A07C7-7606-4D80-B558-48C6494D5D23" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 12 Sep 2019 14:58:02 +0000 In-Reply-To: <47C71B4D-DC22-4090-B60C-5AC7B1ECF4B9@akamai.com> Cc: "netconf@ietf.org" , Russ Housley , Rifaat Shekh-Yusef , Sean Turner To: "Salz, Rich" References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <47C71B4D-DC22-4090-B60C-5AC7B1ECF4B9@akamai.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.12-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 14:58:06 -0000 --Apple-Mail=_8B8A07C7-7606-4D80-B558-48C6494D5D23 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Rich, > Hope this helps. I would be glad to contribute to a draft developed = along these lines. We would be happy to have your eyes on this draft. Thank you.=20 Kent --Apple-Mail=_8B8A07C7-7606-4D80-B558-48C6494D5D23 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Rich,

 Hope = this helps.  I would be glad to contribute to a draft developed = along these lines.

We would be happy to have your eyes on = this draft.  Thank you. 
Kent


= --Apple-Mail=_8B8A07C7-7606-4D80-B558-48C6494D5D23-- From nobody Thu Sep 12 09:39:39 2019 Return-Path: <0100016d265824b0-313d5248-5aba-4b96-8f21-768be7784568-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FD3120142 for ; Thu, 12 Sep 2019 09:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 6KU4r-NLOJ7I for ; Thu, 12 Sep 2019 09:39:35 -0700 (PDT) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5541F120130 for ; Thu, 12 Sep 2019 09:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568306374; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=DlbB+R9lHY/byKvpQSuOlagP0vuWeBdXE7ibhsJa7WQ=; b=Ln0bL4biAquSnBpn/PL61o2i96TgQ8D26eG8iqAi/OSVizh5Z5NLU0Zn91VKjQYc VLVhNw0coCt5zFGq6Ef+sq3tBaHbjZ4t+WEbAK1xg9NwErmA79RjRW1UkvKClbLzEm5 HelQTY6N1Kdk6G+6N1Rxo9Uou3OWS3Nl2Bxs2XM4= From: Kent Watsen Message-ID: <0100016d265824b0-313d5248-5aba-4b96-8f21-768be7784568-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CBC41791-CC70-4D83-8A9A-089D5EECF605" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 12 Sep 2019 16:39:33 +0000 In-Reply-To: <20190912.111242.323252506550752617.mbj@tail-f.com> Cc: "netconf@ietf.org" , housley@vigilsec.com, rifaat.ietf@gmail.com, sean@sn3rd.com To: Martin Bjorklund References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <20190912.111242.323252506550752617.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.12-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 16:39:38 -0000 --Apple-Mail=_CBC41791-CC70-4D83-8A9A-089D5EECF605 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, > I'm not a security expert so I don't have any input on which ASN.1 > structure to support. >=20 > But it seems to me that in both B1 and B2, the "algorithm" leaf isn't > really necessary in the config, right? =20 The "algorithm" leaf is needed, because a "private-key" itself enough. = The RSAPrivateKey and ECPrivateKey ASN.1 structures contain just the raw = key fields (e.g., RSA --> [d, p, q, n,e]). The two structures do not = share a common base type that would presumably identify if the payload = is an RSAPrivate key or ECPrivateKey, so the the correct parser can be = used. We could argue that private keys should always come with a public = key, in which case we could claim that, for B1, the typing of the = private key is done via the typing of the public key. I don't prefer = this approach and, as you say, the same algorithm identifier would have = to be passed into the generate-asymmetric-key() and = generate-symmetric-key() actions, so having the field in the = configuration seems right. > I guess it is still needed > when a key is generated though. But then note that "rsaEncryption" is > not an OID ("1.2.840.113549.1.1.1" is the OID). If you want to use a > symbolic name you need something else. Isn't it? Check https://tools.ietf.org/html/rfc3279#section-2.3.1 = . > Is the idea that the module becomes ietf-tls-keystore with top-level > node tls-keystore? There is no need to change the "keystore" module's name. ASN.1 is not = TLS-specific, it just so happens to be heavily used by TLS. Already, and for awhile now, the ietf-crypto-types module has defined = the private-key and public-key using type "binary" with a description = statement saying that how it is parsed is defined by the "algorithm" = field. The description statements even say that the = RSAPublicKey/RSAPrivateKey formats are defined in RFC8017 and the EC = public/private key formats are defined in rfc5915. These unnamed = formats are actually the same ASN.1 structures mentioned in my OP. So = this was/is sort of been the plan all along. =20 >> c) figure out a plan for SSH later >=20 > Hmm, what does this mean? That we won't do ietf-netconf-server now? More fully, that line says:=20 c) figure out a plan for SSH later (the risk level is pretty = low, e.g., I've seen code to key SSH keys from TLS keys) The intention was to signal that it should be easy to determine how to = support SSH, to support the netconf-client-server draft. Nothing is = blocked. We just need to discuss a plan for what to do. The easiest = thing would be to 1) update the mapping table in the ssh-client-server = drafts from mapping SSH-specific algorithm identifiers (e.g., in = rfc4253) to OIDs, and 2) this could get moved into a section called = "Implementation Considerations" that also notes that is an = implementation convert between the ASN.1 structures used by, e.g., = keystore, and the local SSH implementation (e.g., OpenSSH). > Yes, NC/RC are programmatic APIs, but simplicity is always goodness... ACK, but let's be clear that the "simplicity" is in the ready access to = tooling, not from an algorithmic perspective. =20 According to [1], the private-key format is identical to OpenSSL's = private key format (i.e., it uses RSAPrivateKey/ECPrivateKey, not = OneAsymmetricKey or something else). Thus, the only conversion needed = is to/from OpenSSH's public key format. This does not appear to be = hard, e.g., [2] has code showing how to do this using Python. [1] = http://www.sysmic.org/dotclear/index.php?post/2010/03/24/Convert-keys-betw= eens-GnuPG%2C-OpenSsh-and-OpenSSL = [2] = https://blog.oddbit.com/post/2011-05-08-converting-openssh-public-keys/ = Kent // as author --Apple-Mail=_CBC41791-CC70-4D83-8A9A-089D5EECF605 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Martin,

I'm not a security expert so = I don't have any input on which ASN.1
structure to = support.

But it seems to me that in both B1 = and B2, the "algorithm" leaf isn't
really necessary in the = config, right?  

The "algorithm" leaf is needed, because a "private-key" = itself enough.  The RSAPrivateKey and ECPrivateKey ASN.1 structures = contain just the raw key fields (e.g., RSA --> [d, p, q, n,e]). =  The two structures do not share a common base type that would = presumably identify if the payload is an RSAPrivate key or ECPrivateKey, = so the the correct parser can be used.  We could argue that private = keys should always come with a public key, in which case we could claim = that, for B1, the typing of the private key is done via the typing of = the public key.  I don't prefer this approach and, as you say, the = same algorithm identifier would have to be passed into the = generate-asymmetric-key() and generate-symmetric-key() actions, so = having the field in the configuration seems right.


I guess it is still needed
when a key is generated though.  But then note that = "rsaEncryption" is
not an OID ("1.2.840.113549.1.1.1" is = the OID).  If you want to use a
symbolic name you = need something else.



Is the idea that the module becomes ietf-tls-keystore with = top-level
node tls-keystore?

There = is no need to change the "keystore" module's name.  ASN.1 is not = TLS-specific, it just so happens to be heavily used by = TLS.

Already, and for awhile now, = the ietf-crypto-types module has defined the private-key and public-key = using type "binary" with a description statement saying that how it is = parsed is defined by the "algorithm" field.   The description = statements even say that the RSAPublicKey/RSAPrivateKey formats are = defined in RFC8017 and the EC public/private key formats are defined in = rfc5915.  These unnamed formats are actually the same ASN.1 = structures mentioned in my OP.   So this was/is sort of been the = plan all along.  



   c) figure out a plan for SSH later

Hmm, what does this mean? =  That we won't do ietf-netconf-server now?

More = fully, that line says: 

c) figure = out a plan for SSH later (the risk level is pretty low, e.g., I've seen = code to key SSH keys from TLS keys)

The = intention was to signal that it should be easy to determine how to = support SSH, to support the netconf-client-server draft.  Nothing = is blocked.  We just need to discuss a plan for what to do. =  The easiest thing would be to 1) update the mapping table in the = ssh-client-server drafts from mapping SSH-specific algorithm identifiers = (e.g., in rfc4253) to OIDs, and 2) this could get moved into a section = called "Implementation Considerations" that also notes that is an = implementation convert between the ASN.1 structures used by, e.g., = keystore, and the local SSH implementation (e.g., = OpenSSH).



Yes, NC/RC are programmatic = APIs, but simplicity is always goodness...

ACK, = but let's be clear that the "simplicity" is in the ready access to = tooling, not from an algorithmic perspective.   

According to [1], the private-key format is = identical to OpenSSL's private key format (i.e., it uses = RSAPrivateKey/ECPrivateKey, not OneAsymmetricKey or something else). =  Thus, the only conversion needed is to/from OpenSSH's public key = format.  This does not appear to be hard, e.g., [2] has code = showing how to do this using Python.




Kent // as = author


= --Apple-Mail=_CBC41791-CC70-4D83-8A9A-089D5EECF605-- From nobody Thu Sep 12 10:02:38 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336441208A7 for ; Thu, 12 Sep 2019 10:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 nxnOJZVf_aIh for ; Thu, 12 Sep 2019 10:02:32 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 09EFC12088A for ; Thu, 12 Sep 2019 10:02:32 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x8CH2865014942; Thu, 12 Sep 2019 18:02:31 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=tFBM6APWQZeYjNuI9tpbSlHA86lpqJ5zvauyCgVc0go=; b=HHpMGPRBSZaRSDFpdzA2EHg5ZcU4iVXkRwquV05vOp2hWWsnAyX3CXN0NDvVqyxf7Vm4 ZYM+yqrMe499N7yuqp7wwlR7yjKHrKv0pC8C/6JqkJGeMbveCkvMnMJjyCSLuBKw6gDf TSUOJCKjGj5I14JnvTUvb6tC+kU64DcnH6cB2CxbNx9iA6Dfkilysf4roU1pvNk/YR3g GzyzQ0WyLD7W6JevGl41H1wjHzalRKf5JNNzWlNf2AzT0RbhzsIEgCflzJ37/J/SDaVk u0h9qvJpcOXEvwPG5VFXR1E93nlJ4tjFV49VF7r+A6ufxd099/rk3k08nH7nEeFjahDU 1A== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2uv434gk82-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 Sep 2019 18:02:30 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x8CGlZTd029526; Thu, 12 Sep 2019 13:02:29 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2uv7vwaqan-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 12 Sep 2019 13:02:29 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 12 Sep 2019 13:02:28 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Thu, 12 Sep 2019 13:02:27 -0400 From: "Salz, Rich" To: Kent Watsen , Martin Bjorklund CC: "housley@vigilsec.com" , "netconf@ietf.org" , "sean@sn3rd.com" , "rifaat.ietf@gmail.com" Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxGVhFlbERW30moo9Q8WhnpJqcoBcwAgAB82YD//8NYgA== Date: Thu, 12 Sep 2019 17:02:27 +0000 Message-ID: <65A6D989-0BA6-4755-AA76-21BACB8E0559@akamai.com> References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <20190912.111242.323252506550752617.mbj@tail-f.com> <0100016d265824b0-313d5248-5aba-4b96-8f21-768be7784568-000000@email.amazonses.com> In-Reply-To: <0100016d265824b0-313d5248-5aba-4b96-8f21-768be7784568-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.36] Content-Type: multipart/alternative; boundary="_000_65A6D9890BA64755AA7621BACB8E0559akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-12_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=773 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1909120175 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-12_09:2019-09-11,2019-09-12 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=754 adultscore=0 lowpriorityscore=0 mlxscore=0 clxscore=1011 priorityscore=1501 suspectscore=0 malwarescore=0 bulkscore=0 impostorscore=0 phishscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1909120178 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 17:02:37 -0000 --_000_65A6D9890BA64755AA7621BACB8E0559akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IHNob3VsZCBub3QgcmVxdWlyZSBldmVyeSBwcml2YXRlIGtleSB0byBoYXZlICB0aGUgcHVi bGljIGtleTsgdGhleSBhcmUgb2Z0ZW4gc2VwYXJhdGVkIOKAkyBlLmcuLCBtb3N0IFNTSCBpbXBs ZW1lbnRhdGlvbnMgc2VwYXJhdGUgdGhlbS4gQXMgeW91IHBvaW50IG91dCwgdGhleSBkb27igJl0 IHNoYXJlIHRoZSBzYW1lIEFTTjEgZGF0YSBzdHJ1Y3R1cmVzOiBhIOKAnDI1NTE54oCdIGtleSBp cyBhIGJ5dGVzdHJpbmcsIGEgREgga2V5IGlzIHR3byDigJxiaWdudW1z4oCdIChpbiBPcGVuU1NM IHRlcm1zKSwgYW4gUlNBIGtleSBpcyBkaWZmZXJlbnQgZnJvbSBhIERTQSBrZXksIGFuZCBzbyBv bi4NCg0KSSB0aGluayBzYXlpbmcg4oCcdXNlZCBieSBUTFPigJ0gaXMgbm90IGEgZ29vZCByZWFz b24sIHdlIHNob3VsZCByZWFsbHkgdGFsayBhYm91dCB0aGUgYXBwbGljYXRpb25zIHdlIGFyZSB0 cnlpbmcgdG8gY29uZmlndXJlIGFuZCBtYW5hZ2UuICBPciBhbSBJIGhvcGVsZXNzbHkgd3Jvbmcg YWJvdXQgbmV0Y29uZj8gIFRoYXQgY291bGQgYmUgbGlrZWx5LCBJ4oCZbSBvbmx5IGhlcmUgZm9y IHRoZSBjcnlwdG8gb2JqZWN0cyBkaWN1c3Npb25zLg0K --_000_65A6D9890BA64755AA7621BACB8E0559akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5h cHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10YWItc3Bhbjt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+WW91IHNob3VsZCBub3QgcmVxdWlyZSBldmVyeSBwcml2YXRlIGtleSB0byBoYXZl Jm5ic3A7IHRoZSBwdWJsaWMga2V5OyB0aGV5IGFyZSBvZnRlbiBzZXBhcmF0ZWQg4oCTIGUuZy4s IG1vc3QgU1NIIGltcGxlbWVudGF0aW9ucyBzZXBhcmF0ZSB0aGVtLiBBcyB5b3UgcG9pbnQgb3V0 LCB0aGV5IGRvbuKAmXQgc2hhcmUgdGhlIHNhbWUgQVNOMSBkYXRhIHN0cnVjdHVyZXM6IGEg4oCc MjU1MTnigJ0ga2V5IGlzIGEgYnl0ZXN0cmluZywNCiBhIERIIGtleSBpcyB0d28g4oCcYmlnbnVt c+KAnSAoaW4gT3BlblNTTCB0ZXJtcyksIGFuIFJTQSBrZXkgaXMgZGlmZmVyZW50IGZyb20gYSBE U0Ega2V5LCBhbmQgc28gb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgc2F5aW5n IOKAnHVzZWQgYnkgVExT4oCdIGlzIG5vdCBhIGdvb2QgcmVhc29uLCB3ZSBzaG91bGQgcmVhbGx5 IHRhbGsgYWJvdXQgdGhlIGFwcGxpY2F0aW9ucyB3ZSBhcmUgdHJ5aW5nIHRvIGNvbmZpZ3VyZSBh bmQgbWFuYWdlLiZuYnNwOyBPciBhbSBJIGhvcGVsZXNzbHkgd3JvbmcgYWJvdXQgbmV0Y29uZj8m bmJzcDsgVGhhdCBjb3VsZCBiZSBsaWtlbHksIEnigJltIG9ubHkgaGVyZSBmb3IgdGhlIGNyeXB0 byBvYmplY3RzDQogZGljdXNzaW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_65A6D9890BA64755AA7621BACB8E0559akamaicom_-- From nobody Thu Sep 12 10:46:35 2019 Return-Path: <0100016d269570a7-1d38d4fb-97e7-43b5-9439-2f84deab2c83-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAF71201C6 for ; Thu, 12 Sep 2019 10:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 1dVntCeONgh2 for ; Thu, 12 Sep 2019 10:46:32 -0700 (PDT) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9077E120178 for ; Thu, 12 Sep 2019 10:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568310391; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=jaoGnW/ycokMgi1fp1K58FmE212KyuC77JEeEuZY8ZA=; b=GL545s2CXgi9bQcvjsRS4ReYXmco9uIRgmLmtbNawTS1yCNAIlyMWI6UQg4aZwRd domMvSLd8HDXHEzQRuhbaWiXurakuxTHwsIL2xhi3mrX8ScvVZ3aOMrqdiM67jpcl5s VVCfrta5+uo7I4o3w1E5j3DzC9gyYe7TFd5Z7mao= From: Kent Watsen Message-ID: <0100016d269570a7-1d38d4fb-97e7-43b5-9439-2f84deab2c83-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D268A51B-9190-428A-BF7F-4DBF670E4707" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 12 Sep 2019 17:46:31 +0000 In-Reply-To: <65A6D989-0BA6-4755-AA76-21BACB8E0559@akamai.com> Cc: Martin Bjorklund , "housley@vigilsec.com" , "netconf@ietf.org" , "sean@sn3rd.com" , "rifaat.ietf@gmail.com" To: "Salz, Rich" References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <20190912.111242.323252506550752617.mbj@tail-f.com> <0100016d265824b0-313d5248-5aba-4b96-8f21-768be7784568-000000@email.amazonses.com> <65A6D989-0BA6-4755-AA76-21BACB8E0559@akamai.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.12-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 17:46:34 -0000 --Apple-Mail=_D268A51B-9190-428A-BF7F-4DBF670E4707 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Rich, > I think saying =E2=80=9Cused by TLS=E2=80=9D is not a good reason, we = should really talk about the applications we are trying to configure and = manage.=20 For reference, the full sentence was: ASN.1 is not TLS-specific, it just = so happens to be heavily used by TLS. The focus of this work is primarily to enable the configuration of = NETCONF and RESTCONF servers. NETCONF can use either SSH or TLS as a = transport, and RESTCONF is always HTTPS. The current structure of the = suite of client-server drafts includes generic SSH and TLS layers (and = likely a DTLS layer someday) that have already been adopted by other = work-in-progress at the IETF (e.g., models for PCEP, Syslog, etc.), so = the scope of the SSH and TLS layers is a little wider than just NETCONF = and RESTCONF. That said, I can't think of anything that has been done = to date to cater to any external effort. > Or am I hopelessly wrong about netconf? That could be likely, I=E2=80=99= m only here for the crypto objects dicussions. Right. My claim is that ASN.1 for storing keys is a pretty universal. = I don't think we give up much by formally claiming all the key values = are ASN.1 structures but, importantly, by doing so, using OIDs becomes = natural, thus obsoleting the need to define our own set of algorithm = identifiers in YANG, which significantly motivates this thread. Makes = sense? Kent --Apple-Mail=_D268A51B-9190-428A-BF7F-4DBF670E4707 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Rich,

I think saying =E2=80=9Cused by = TLS=E2=80=9D is not a good reason, we should really talk about the = applications we are trying to configure and = manage. 

For reference, the full sentence = was: ASN.1 is not TLS-specific, it just so happens to be heavily = used by TLS.

The= focus of this work is primarily to enable the configuration of NETCONF = and RESTCONF servers.   NETCONF can use either SSH or TLS as a = transport, and RESTCONF is always HTTPS.    The current = structure of the suite of client-server drafts includes generic SSH and = TLS layers (and likely a DTLS layer someday) that have already been = adopted by other work-in-progress at the IETF (e.g., models for PCEP, = Syslog, etc.), so the scope of the SSH and TLS layers is a little wider = than just NETCONF and RESTCONF.  That said, I can't think of = anything that has been done to date to cater to any external = effort.


Or am = I hopelessly wrong about netconf?  That could be likely, I=E2=80=99m = only here for the crypto objects dicussions.

Right.  My claim = is that ASN.1 for storing keys is a pretty universal.   I don't = think we give up much by formally claiming all the key values are ASN.1 = structures but, importantly, by doing so, using OIDs becomes natural, = thus obsoleting the need to define our own set of algorithm identifiers = in YANG, which significantly motivates this thread.  Makes = sense?


Kent

= --Apple-Mail=_D268A51B-9190-428A-BF7F-4DBF670E4707-- From nobody Thu Sep 12 10:59:05 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98591201E0 for ; Thu, 12 Sep 2019 10:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 0doopDK8jK7F for ; Thu, 12 Sep 2019 10:59:01 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5689C120152 for ; Thu, 12 Sep 2019 10:59:01 -0700 (PDT) Received: from localhost (h-46-233.A165.priv.bahnhof.se [46.59.46.233]) by mail.tail-f.com (Postfix) with ESMTPSA id 122A51AE0187; Thu, 12 Sep 2019 19:59:00 +0200 (CEST) Date: Thu, 12 Sep 2019 19:58:59 +0200 (CEST) Message-Id: <20190912.195859.497068783415208339.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: netconf@ietf.org, housley@vigilsec.com, rifaat.ietf@gmail.com, sean@sn3rd.com From: Martin Bjorklund In-Reply-To: <0100016d265824b0-313d5248-5aba-4b96-8f21-768be7784568-000000@email.amazonses.com> References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <20190912.111242.323252506550752617.mbj@tail-f.com> <0100016d265824b0-313d5248-5aba-4b96-8f21-768be7784568-000000@email.amazonses.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 17:59:04 -0000 Kent Watsen wrote: > Hi Martin, > > > I'm not a security expert so I don't have any input on which ASN.1 > > structure to support. > > > > But it seems to me that in both B1 and B2, the "algorithm" leaf isn't > > really necessary in the config, right? > > The "algorithm" leaf is needed, because a "private-key" itself enough. > The RSAPrivateKey and ECPrivateKey ASN.1 structures contain just the > raw key fields (e.g., RSA --> [d, p, q, n,e]). The two structures do > not share a common base type that would presumably identify if the > payload is an RSAPrivate key or ECPrivateKey, so the the correct > parser can be used. We could argue that private keys should always > come with a public key, in which case we could claim that, for B1, the > typing of the private key is done via the typing of the public key. I > don't prefer this approach and, as you say, the same algorithm > identifier would have to be passed into the generate-asymmetric-key() > and generate-symmetric-key() actions, so having the field in the > configuration seems right. > > > > I guess it is still needed > > when a key is generated though. But then note that "rsaEncryption" is > > not an OID ("1.2.840.113549.1.1.1" is the OID). If you want to use a > > symbolic name you need something else. > > Isn't it? Check https://tools.ietf.org/html/rfc3279#section-2.3.1 > . The symbolic name is not (guaranteed to be) globally unique. > > Is the idea that the module becomes ietf-tls-keystore with top-level > > node tls-keystore? > > There is no need to change the "keystore" module's name. So where would keys for SSH go? Your reasoning was (which I agree with) don't create a super-generic module for all things crypto / keys, but let's focus on what we need (you wrote "to configure an HTTPS server). If we limit ourselves to TLS it should be reflected in the naming. But perhaps I misunderstood your intention. > ASN.1 is not > TLS-specific, it just so happens to be heavily used by TLS. > > Already, and for awhile now, the ietf-crypto-types module has defined > the private-key and public-key using type "binary" with a description > statement saying that how it is parsed is defined by the "algorithm" > field. The description statements even say that the > RSAPublicKey/RSAPrivateKey formats are defined in RFC8017 and the EC > public/private key formats are defined in rfc5915. These unnamed > formats are actually the same ASN.1 structures mentioned in my OP. So > this was/is sort of been the plan all along. Right, but at that time the idea was to be able to have very generic "algorithm", and have each alg define its own format, right? As soon as we limit "algorithm" and the format for the key, we are no longer generic. Hence we should have a less generic name, that more precisely decribe what it is. > >> c) figure out a plan for SSH later > > > > Hmm, what does this mean? That we won't do ietf-netconf-server now? > > More fully, that line says: > > c) figure out a plan for SSH later (the risk level is pretty low, > e.g., I've seen code to key SSH keys from TLS keys) > > The intention was to signal that it should be easy to determine how to > support SSH, to support the netconf-client-server draft. Nothing is > blocked. We just need to discuss a plan for what to do. The easiest > thing would be to 1) update the mapping table in the ssh-client-server > drafts from mapping SSH-specific algorithm identifiers (e.g., in > rfc4253) to OIDs But do these OIDs exist already? >, and 2) this could get moved into a section called > "Implementation Considerations" that also notes that is an > implementation convert between the ASN.1 structures used by, e.g., > keystore, and the local SSH implementation (e.g., OpenSSH). > > > Yes, NC/RC are programmatic APIs, but simplicity is always goodness... > > ACK, but let's be clear that the "simplicity" is in the ready access > to tooling, not from an algorithmic perspective. But the solution becomes more robust if you can use the format you're used to w/o additional conversion. > According to [1], the private-key format is identical to OpenSSL's > private key format (i.e., it uses RSAPrivateKey/ECPrivateKey, not > OneAsymmetricKey or something else). Thus, the only conversion needed > is to/from OpenSSH's public key format. This does not appear to be > hard, e.g., [2] has code showing how to do this using Python. > > [1] > http://www.sysmic.org/dotclear/index.php?post/2010/03/24/Convert-keys-betweens-GnuPG%2C-OpenSsh-and-OpenSSL > > [2] > https://blog.oddbit.com/post/2011-05-08-converting-openssh-public-keys/ > /martin From nobody Thu Sep 12 11:04:43 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A64120219 for ; Thu, 12 Sep 2019 11:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 bTtVLo5TLr49 for ; Thu, 12 Sep 2019 11:04:39 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 6E406120241 for ; Thu, 12 Sep 2019 11:04:36 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x8CHv8Sd009381; Thu, 12 Sep 2019 19:04:32 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=55p2KQWH9ye4K+MEMMcUamFFyinXyFr191++SJUR7i0=; b=WKL2rfwiyGOD1W40xhd8j0CvW7YZ89Y4PDqJQo9ShgWCIrJwa8duFngndLiOQr8q4yU/ /sWw3POzj2WNDORH3SQkQJPLzPTjzFzjqeNeWRac3D0KPK0xjOgEUnfCld8ncZg6xsJQ GK3gY7l0JMknXZmX7D0u9xlnIYIQ1K/1cKHFqnjQvaLm0LsgmpHVJVIBzIAEemKKo+nd 8PWlqolDR3C4uXWdn/zCCRd1N/ZG3YRvgXxNckI3hyksAjAp5hLFhwpe4Kje7rgXKhCh SB0MQMKFs42mFOfTmAZDnObCAKVHJRcjn3Cc3oSJwO3jbEJD5biRPzwgCE+TL6mb4BnI Gw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2uytcjg4ne-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 12 Sep 2019 19:04:32 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x8CI243G007629; Thu, 12 Sep 2019 14:04:31 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2uyth1r5f5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 12 Sep 2019 14:04:31 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 12 Sep 2019 14:04:30 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Thu, 12 Sep 2019 14:04:30 -0400 From: "Salz, Rich" To: Kent Watsen CC: Martin Bjorklund , "housley@vigilsec.com" , "netconf@ietf.org" , "sean@sn3rd.com" , "rifaat.ietf@gmail.com" Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxGVhFlbERW30moo9Q8WhnpJqcoBcwAgAB82YD//8NYgIAAT16A///B+AA= Date: Thu, 12 Sep 2019 18:04:30 +0000 Message-ID: <37FAF82E-D2E1-40BD-8B59-06726E518208@akamai.com> References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <20190912.111242.323252506550752617.mbj@tail-f.com> <0100016d265824b0-313d5248-5aba-4b96-8f21-768be7784568-000000@email.amazonses.com> <65A6D989-0BA6-4755-AA76-21BACB8E0559@akamai.com> <0100016d269570a7-1d38d4fb-97e7-43b5-9439-2f84deab2c83-000000@email.amazonses.com> In-Reply-To: <0100016d269570a7-1d38d4fb-97e7-43b5-9439-2f84deab2c83-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.36] Content-Type: multipart/alternative; boundary="_000_37FAF82ED2E140BD8B5906726E518208akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-12_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=667 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909120189 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-12_09:2019-09-11,2019-09-12 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 suspectscore=0 adultscore=0 spamscore=0 mlxlogscore=647 malwarescore=0 priorityscore=1501 lowpriorityscore=0 phishscore=0 bulkscore=0 clxscore=1015 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909120189 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2019 18:04:41 -0000 --_000_37FAF82ED2E140BD8B5906726E518208akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLCBpdOKAmXMgcmVhc29uYWJsZSA6KQ0KDQo= --_000_37FAF82ED2E140BD8B5906726E518208akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5h cHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10YWItc3Bhbjt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIw DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGFua3MsIGl04oCZcyByZWFzb25hYmxlIDopPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_37FAF82ED2E140BD8B5906726E518208akamaicom_-- From nobody Fri Sep 13 01:48:23 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C46120233 for ; Fri, 13 Sep 2019 01:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=SulUrJn1; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=YS0Uso5R 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 oLalrz-iu5z6 for ; Fri, 13 Sep 2019 01:48:16 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D4461200B9 for ; Fri, 13 Sep 2019 01:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41653; q=dns/txt; s=iport; t=1568364496; x=1569574096; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2cvqMa3LBrz+f0nfbBhA4aZFA8Cq6CApZLEsU++LOuM=; b=SulUrJn1X+tuTujdzmIf92g7kbst/X1axejU1Vdl6YcXI8uI3iWEfavc v3KLISRot9TmrwEYGmhp8bZWhyA12WJYjZqe3aApHCSBgPo1xL41dbbuJ PGQNqGqvhutF94tnPXZ5dntPhBfelm3xUikXp2wrbbmxSORHTR0iGZXSb Y=; IronPort-PHdr: =?us-ascii?q?9a23=3AQzBY8RHSYtid57xHLEUoXJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1A3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeT1bigmG8JqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AdAACaV3td/51dJa1cChoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVQEAQEBAQsBgRUvJCwDbVYgBAsqCodeA4prglyJZYkjhGi?= =?us-ascii?q?BLoEkA1QJAQEBDAEBJQgCAQGEPwKCXyM1CA4CAwkBAQQBAQECAQYEbYUuDIV?= =?us-ascii?q?KAQEBAQMSGxMBASkOAQ8CAQgRBAEBIQENIREdCAIEAQ0FCBMHgwGBHU0DHQE?= =?us-ascii?q?CDJ8nAoE4iGGCJYJ9AQEFgTIBAwICg1INC4IWAwaBNAGKNIElAR0YgUA/gRF?= =?us-ascii?q?Ggkw+ghoiJQIDgTMVGCuDEIImjGCIASSXBUEKgiGHAYIOh2iEG5kKjX+IBII?= =?us-ascii?q?GjmQCBAIEBQIOAQEFgVQBNYFYcBWDJ4FKeAwXg0+FFIU/c4EpjVwBgSIBAQ?= X-IronPort-AV: E=Sophos;i="5.64,500,1559520000"; d="scan'208,217";a="325486959" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Sep 2019 08:48:09 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x8D8m9wN004272 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Sep 2019 08:48:09 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 13 Sep 2019 03:48:08 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 13 Sep 2019 04:48:07 -0400 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 13 Sep 2019 03:48:07 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WINcarN04QGgtGEQBq0ZN6C3yTNCsHBAGxvS4XHIQS3Fz69Xklf0aK/Ha9IITlAgCHqh+i5U8HDiIP7m4urmubkazUZdy3TNf9M12Oj+iHTABP3+ihwMD4jmqcAXUmYhfZgZc/n7O7a0lB4HFOgOvXsmO+QuBFMUFUMBkAKA/Uk6Pt+29sSUevPqxGYzynl7pPGKWHeXXYbhB4+exw4TjJMiGedPESlqu4318x6BhH2fxtYjuXGpLPa4m4rDrjBW5t1SC4PA/1XV0TmKawTAF8O5pU+5Qsj9+FNK052eix80A1qHRNYrA8dP+/z0s/jFZcFtwqDib1NeiRalqfO7Bg== 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=6+jh4e6R0IGhfdIgvMK4MjJRh7NHNrytfFI8UX8UJLU=; b=hVvyaEDd7j8wh3HCmUbMCtY+kqIXiQFXuJiOq76/IP5FLpoLbd1rgcYeu2sUtg3tbVKQlSsoHXGpsXmYHEiqgQLzQQ+lAVAZHHtQr+jXb06WM0FWF0hqWEh8ILHaPgrXj4A7qHoHYQSGEn1tV5muxZTB3fDAcRsm1oLxFRHQWV0z480ik25SBaugfDZ9+yhJNF+qnGXOnxiAi/3QDfxgZHdO89GDeSkeE3rblsnQ9R4OUTvenpk/hMIDeaCvlYSyZRhdgWM6mHq+x+1HGQFXLWemcx4fl8i3RIrRX0NSQyVEBsz1JylhDN7DD/e6TCzqKYn8UiI4Cze6tusHsbKi+w== 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=6+jh4e6R0IGhfdIgvMK4MjJRh7NHNrytfFI8UX8UJLU=; b=YS0Uso5RBj1Dy48hfOlDwJrFwWYibj+rpDkhOsBJYg6qZuyZWr1ViqHdu1ZPLu/8mO/3r5BGKm3qp0HEi83ZGYeiyeNnpF/kp3NenMF+Tm6e5OJv/aKjLMRx8AJiZp6D7N54xo0Ma3qZew53TKQVg1Usl6CRfpe/WEsIuWW9WbI= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB4013.namprd11.prod.outlook.com (10.255.181.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.21; Fri, 13 Sep 2019 08:48:05 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6%7]) with mapi id 15.20.2263.021; Fri, 13 Sep 2019 08:48:05 +0000 From: "Rob Wilton (rwilton)" To: Kent Watsen , "netconf@ietf.org" CC: Russ Housley , Rifaat Shekh-Yusef , Sean Turner Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxVu0aQE+n/K0iPwVgOy8FH/KcpQIdQ Date: Fri, 13 Sep 2019 08:48:05 +0000 Message-ID: References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> In-Reply-To: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [173.38.220.61] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d366cc4a-f018-4d58-72b1-08d73827182a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB4013; x-ms-traffictypediagnostic: MN2PR11MB4013: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0159AC2B97 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(136003)(39860400002)(346002)(366004)(54094003)(51444003)(189003)(199004)(966005)(33656002)(71200400001)(71190400001)(6506007)(64756008)(66556008)(66476007)(66946007)(7696005)(102836004)(76176011)(99286004)(53546011)(5660300002)(6246003)(790700001)(66446008)(478600001)(229853002)(14454004)(2906002)(6306002)(54896002)(6116002)(3846002)(9686003)(236005)(55016002)(86362001)(6436002)(486006)(53936002)(66066001)(7736002)(74316002)(52536014)(4326008)(25786009)(256004)(14444005)(8936002)(81166006)(81156014)(26005)(316002)(54906003)(110136005)(8676002)(446003)(11346002)(76116006)(186003)(606006)(9326002)(2501003)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4013; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 5O6QXi+U3PkPtjbu3+oFWXx9cyJw4wvf3S3KiCzx/AiA2kbkXrWrPhUb7f624OntNaTojoSpNpNfSBAdAdEW1lWoVxnwze6shaPjmxnZ41NvOzZj/T6xwYEs30enWKirXv4JAj77zj05PkgAxgIouscY0zk2nHmwx3Zt5kSvH/b4ziyVl6/eryMtxE4pF/HETK54OMOSIIkvua6uWk8gzQ4R4Uc+h9CvvXtelZLPm7HbPFodDgPyK02/cEIZNaRBHeQ9XQ0WsZItl7wLnU1IpOMJJGdjxBfqXmTQvQOoHLfMDmcqisf9cvZU6lxVL/E8AcXpwwzr6u5BBCBy9mL/cIAs/+svwrGoAB78z9YD8+c2Q0wzyAzhYXNp7f0GP5HooKNOZjOUFahxJ0/ZPae9SWiSxX4E/cU4MofMl20uH84= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366AE6CF9E03B15EBEA3A39B5B30MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d366cc4a-f018-4d58-72b1-08d73827182a X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Sep 2019 08:48:05.4770 (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: V0FyAfnPuYMJV3sk6qzef4A3MOS+k/++K3xeKXPhlSauvDIFqhAaklGB/xdeD5CNg+MsYJ5sIcLjha1K26dMQw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4013 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.24, xch-aln-014.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2019 08:48:20 -0000 --_000_MN2PR11MB4366AE6CF9E03B15EBEA3A39B5B30MN2PR11MB4366namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kent, I feel that this is outside my area of expertise, and hence I have a slight= concern that my comments may needless derail a discussion rather than prov= ide useful input. But I have three comments: 1. I think that using a numerical OID to identify crypto algorithms does= n't seem like a great choice. Seeing a config file say something like "rsa= Encryption" instead of some OID string seems to be much more human friendly= . And as Martin says, using the OID name has no guarantees of being unique= . 1. I wonder if changing from identifiers to enums was a mistake. If we = were to use YANG identifiers then we wouldn't need to define them all now, = and they wouldn't all need to be defined in the same YANG module. In fact,= if we were to go back to using identifiers then perhaps NETCONF should res= trict itself to only defining the identifiers that we actually need now, an= d leave the rest to the security folks to figure out, probably as separate = modules defining the extra identifiers that they need, or as a bis version = of the crypto-types draft if required. 1. I'm not sure that I understand why we would always want to always use= ASN.1 to describe the keys for all algorithms. Could we just leave the al= gorithm identities to define what format they use? If we were to go back = to using identities when we could have the choice of using multiple inherit= ance and then have a separate set of identities to allow the key formats to= be defined. Note, I have no objection to ASN.1 being used for some/most t= he keys if that is the right encoding. Hopefully the comments are useful, apologies if they are not! Thanks, Rob From: netconf On Behalf Of Kent Watsen Sent: 11 September 2019 21:05 To: netconf@ietf.org Cc: Russ Housley ; Rifaat Shekh-Yusef ; Sean Turner Subject: [netconf] crypto-types fallback strategy [warning: wide-screen needed] Folks, It seems that there is little appetite to pursue a solution that entails de= fining many algorithm identifiers/enumerations in YANG. In Montreal, I presented a "fallback" strategy (see slide 9 here: https://d= atatracker.ietf.org/meeting/105/materials/slides-105-netconf-client-server-= suite-of-drafts-00) that sought to leverage ASN.1 structures (that are heav= ily used by TLS) as much as possible and, in particular, rather than crypto= -types defining many algorithms, the YANG module instead uses existing OIDs= (ASN.1 object identifiers) to identify the algorithms and ASN.1 structures= to encode them. Testing, I've determined that: 1) `openssl genrsa -out rsa_private_key.pem 2048` creates an RSAPrivateKey = (from rfc3447) - this is a raw key; there is no OID identifying the structure, or att= ributes indicating how it should be used. 2) `openssl rsa -in rsa_private_key.pem -pubout -out rsa_public_key.pem` cr= eates a SubjectPublicKeyInfo (from rfc5280) - the "algorithm" field is "rsaEncryption" (thus indicating how the ke= y is expected to be used) - the "parameters" field is NULL (which for some reason is actually th= e value b'\x05\x00') - the "subjectPublicKey" field is an RSAPublicKey (from rfc5480) 3) `openssl ecparam -genkey -name prime256v1 -out ec_private_key.pem` creat= es an ECPrivateKey (from rfc5915) - this is a raw key; there is no OID identifying the structure, or at= tributes indicating how it should be used. 4) `openssl ec -in ec_private_key.pem -pubout -out ec_public_key.pem` creat= es a SubjectPublicKeyInfo (from rfc5280) - the "algorithm" field is "id_ecPublicKey" (but, unlike rsaEncryption= , this doesn't seem to indicate how the key should be used) - the "parameters" field is a ECParameters (from rfc5480) and (for me)= contains 'namedCurve' being an OID containing value "secp256r1" - the "subjectPublicKey" field is an ECPoint (from rfc5480), which con= tains the value of a point on the curve. I've been discussing all this offline with security experts (especially wrt= all these ASN.1 structures) Russ Housley and Sean Turner (CC-ed) for about= a week now. I now feel the need to get some WG feedback before proceeding= much further... Here are some options: OPTION A =3D=3D=3D=3D=3D=3D=3D=3D - Continue pursuing the solution in the draft as is - a holistic mapping of= many algorithm identifiers (more than needed for our use). - Note that everyone that showed interest before haven't been heard from in= awhile. OPTION B =3D=3D=3D=3D=3D=3D=3D=3D - move towards a fallback strategy (two variants are proposed below) - both variations share the following common attributes: a) remove all the crypto-algorithm enumerations from the YANG module (~= 70% of the lines) b) use ASN.1 structures to encode symmetric and asymmetric key, both un= encrypted and encrypted. c) figure out a plan for SSH later (the risk level is pretty low, e.g.,= I've seen code to key SSH keys from TLS keys) Okay, so now for the two variants: B1 and B2... OPTION B1 (use raw/native keys) ---------------------------------------------- PROs: mostly supported by OpenSSL command line (see commands 1-4 above) [mi= ssing: commands illustrating key-encryption] CONs: private keys have no way to declare their intended use (encrypt vs si= gn) or modes (CBS vs GCM). some usage information could be stored in the p= ublic key. no key usage information stored for symmetric keys. module: ietf-keystore +--rw keystore +--rw asymmetric-keys | +--rw asymmetric-key* [name] | +--rw name arbitrary user-se= t value | +--rw algorithm <---- this become= s an OID (e.g., "rsaEncryption") | +--rw public-key <---- this become= s SubjectPublicKeyInfo ASN.1 structure | +--rw (private-key-type) | +--:(private-key) | | +--rw private-key? <---- this becomes= a raw ASN.1 key (e.g., RSAPrivateKey, ECPrivateKey) | +--:(encrypted-private-key) | +--rw encrypted-private-key | +--rw (key-type) | | +--:(symmetric-key-ref) | | | +--rw symmetric-key-ref? leafref // ref to= another key in keystore | | +--:(asymmetric-key-ref) | | +--rw asymmetric-key-ref? leafref // ref to= another key in keystore | +--rw value? <--- this becomes= an CMS EncryptedData structure containing an OneAsymmetricKey (from rfc595= 8) | +--rw symmetric-keys +--rw symmetric-key* [name] +--rw name // arbitrary user= -set value +--rw algorithm <---- TBD, mostly = likely an AlgID value from rfc7210 +--rw (key-type) +--:(key) | +--rw key? <---- this beco= mes an OctetString (ASN.1 structure) +--:(encrypted-key) +--rw encrypted-key +--rw (key-type) | +--:(symmetric-key-ref) | | +--rw symmetric-key-ref? // leafref to an= other key in keystore | +--:(asymmetric-key-ref) | +--rw asymmetric-key-ref? // leafref to ano= ther key in keystore +--rw value? <---- this becom= es an CMS EncryptedData structure containing an OneSymmetricKey (from rfc60= 31) OPTION B2 (use OneSymmetricKey and OneAsymmetricKey) ---------------------------------------------------------------------------= --------- PROs: private keys can declare their intended use (encrypt vs sign) and mod= es (CBS vs GCM) CONs: not supported by OpenSSL command line (but are by languages, e.g., Py= thon) module: ietf-keystore +--rw keystore +--rw asymmetric-keys | +--rw asymmetric-key* [name] | +--rw name // arbitrary use= r-set value | +--rw algorithm <---- this could = be deleted, or set to the same OID as in B1 | +--rw public-key <---- SubjectPubl= icKeyInfo ASN.1 structure (same as in B1) | +--rw (private-key-type) | +--:(private-key) | | +--rw private-key? <---- this becomes= a ASN.1 OneAsymmetricKey (from rfc5958) | +--:(encrypted-private-key) | +--rw encrypted-private-key | +--rw (key-type) | | +--:(symmetric-key-ref) | | | +--rw symmetric-key-ref? // leafref to an= other key in keystore | | +--:(asymmetric-key-ref) | | +--rw asymmetric-key-ref? // leafref to ano= ther key in keystore | +--rw value? <---- CMS Encry= ptedData ASN.1 structure (same as in B1) | +--rw symmetric-keys +--rw symmetric-key* [name] +--rw name arbitrary user-se= t value +--rw algorithm <---- this could b= e deleted, or set to the same AlgID value from B1 +--rw (key-type) +--:(key) | +--rw key? <---- this beco= mes a ASN.1 OneSymmetricKey (from rfc6031) +--:(encrypted-key) +--rw encrypted-key +--rw (key-type) | +--:(symmetric-key-ref) | | +--rw symmetric-key-ref? leafref to anothe= r key in keystore | +--:(asymmetric-key-ref) | +--rw asymmetric-key-ref? leafref to anothe= r key in keystore +--rw value? <--- CMS Encryp= tedData ASN.1 structure (same as in B1) In summary: - B1 is easier to support unencrypted keys, but fails to support some t= hings important to some security folks (not me). - B1 complexity to support encrypted keys is TBD (I'm told OpenSSL comm= and line can do it, but have yet to verify) - B2 is preferred by crypto folks, but lack an OpenSSL command line wil= l thwart the development of simple scripts. - NC/RC are programmatic APIs, so complexity shouldn't be driving facto= r, though it may affect solution adoption. Thoughts? Kent // co-author --_000_MN2PR11MB4366AE6CF9E03B15EBEA3A39B5B30MN2PR11MB4366namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kent,<= o:p>

&nbs= p;

I feel th= at this is outside my area of expertise, and hence I have a slight concern = that my comments may needless derail a discussion rather than provide usefu= l input.

&nbs= p;

But I hav= e three comments:

&nbs= p;

  1. I think that using a numer= ical OID to identify crypto algorithms doesn’t seem like a great choi= ce.  Seeing a config file say something like “rsaEncryption” instead of some OID string seems to be = much more human friendly.  And as Martin says, using the OID name has = no guarantees of being unique.

&nbs= p;

  1. I wonder if changing from = identifiers to enums was a mistake.  If we were to use YANG identifier= s then we wouldn’t need to define them all now, and they wouldn’t all need to be defined in the same YANG modul= e.  In fact, if we were to go back to using identifiers then perhaps N= ETCONF should restrict itself to only defining the identifiers that we actu= ally need now, and leave the rest to the security folks to figure out, probably as separate modules defining the extra ident= ifiers that they need, or as a bis version of the crypto-types draft if req= uired. 

 

  1. I’m not sure that I = understand why we would always want to always use ASN.1 to describe the key= s for all algorithms.  Could we just leave the algorithm identities to define what format they use?   If we wer= e to go back to using identities when we could have the choice of using mul= tiple inheritance and then have a separate set of identities to allow the k= ey formats to be defined.  Note, I have no objection to ASN.1 being used for some/most the keys if that is the right = encoding.

&nbs= p;

Hopefully= the comments are useful, apologies if they are not!

&nbs= p;

Thanks,

Rob<= /o:p>

&nbs= p;

&nbs= p;

&nbs= p;

From: netconf <netconf-bounces@ietf.org= > On Behalf Of Kent Watsen
Sent: 11 September 2019 21:05
To: netconf@ietf.org
Cc: Russ Housley <housley@vigilsec.com>; Rifaat Shekh-Yusef &l= t;rifaat.ietf@gmail.com>; Sean Turner <sean@sn3rd.com>
Subject: [netconf] crypto-types fallback strategy<= /p>

 

[warning: wide-screen n= eeded]

 

Folks,

 

It seems that there is = little appetite to pursue a solution that entails defining many algorithm i= dentifiers/enumerations in YANG.

 

In Montreal, I presente= d a "fallback" strategy (see slide 9 here: https://datatracker.ietf.org/meeting/105/materials/s= lides-105-netconf-client-server-suite-of-drafts-00) that sought to leverage ASN.1 structures (that are heavily used by TLS) as= much as possible and, in particular, rather than crypto-types defining man= y algorithms, the YANG module instead uses existing OIDs (ASN.1 object iden= tifiers) to identify the algorithms and ASN.1 structures to encode them.

 

Testing, I've determine= d that:

 

1) `openssl genrsa -out= rsa_private_key.pem 2048` creates an RSAPrivateKey (from rfc3447)
     - this is a raw key; there is no OID identifying the st= ructure, or attributes indicating how it should be used.

2) `openssl rsa -in rsa_private_key.pem -pubout -out rsa_public_key.pem` cr= eates a SubjectPublicKeyInfo (from rfc5280)
     - the "algorithm" field is "rsaEncryptio= n" (thus indicating how the key is expected to be used)
     - the "parameters" field is NULL (which for s= ome reason is actually the value b'\x05\x00')
     - the "subjectPublicKey" field is an RSAPubli= cKey (from rfc5480)

3) `openssl ecparam -genkey -name prime256v1 -out ec_private_key.pem` creat= es an ECPrivateKey (from rfc5915)
      - this is a raw key; there is no OID identifying the s= tructure, or attributes indicating how it should be used.

4) `openssl ec -in ec_private_key.pem -pubout -out ec_public_key.pem` creat= es a SubjectPublicKeyInfo (from rfc5280)
     - the "algorithm" field is "id_ecPublicK= ey" (but, unlike rsaEncryption, this doesn't seem to indicate how the = key should be used)
     - the "parameters" field is a ECParameters (f= rom rfc5480) and (for me) contains 'namedCurve' being an OID containing val= ue "secp256r1"
     - the "subjectPublicKey" field is an ECPoint = (from rfc5480), which contains the value of a point on the curve.

 

 

I've been discussing al= l this offline with security experts (especially wrt all these ASN.1 struct= ures) Russ Housley and Sean Turner (CC-ed) for about a week now.  I no= w feel the need to get some WG feedback before proceeding much further...

 

Here are some options:<= o:p>

 

OPTION A

=3D=3D=3D=3D=3D=3D=3D= =3D

- Continue pursuing the= solution in the draft as is - a holistic mapping of many algorithm identif= iers (more than needed for our use).

- Note that everyone th= at showed interest before haven't been heard from in awhile.

 

OPTION B

=3D=3D=3D=3D=3D=3D=3D= =3D

- move towards a fallba= ck strategy (two variants are proposed below)

- both variations share= the following common attributes:

    a) remove= all the crypto-algorithm enumerations from the YANG module (~70% of the li= nes)

    b) use AS= N.1 structures to encode symmetric and asymmetric key, both unencrypted and= encrypted.

    c) figure= out a plan for SSH later (the risk level is pretty low, e.g., I've seen co= de to key SSH keys from TLS keys)

 

Okay, so now for the tw= o variants:  B1 and B2...

 

 

 

OPTION B1  (use ra= w/native keys)

-----------------------= -----------------------

PROs: mostly supported = by OpenSSL command line (see commands 1-4 above) [missing: commands illustr= ating key-encryption]

CONs: private keys have= no way to declare their intended use (encrypt vs sign) or modes (CBS vs GC= M).  some usage information could be stored in the public key.  n= o key usage information stored for symmetric keys.

 

module: ietf-keystore
     +--rw keystore
        +--rw asymmetric-keys
        |  +--rw asymmetric-key* [name]
        |     +--rw name     &n= bsp;                     =        arbitrary user-set value
        |     +--rw algorithm   &nbs= p;                     &n= bsp;   <---- this becomes an OID (e.g., "rsaEncryption")<= br>         |     +--rw public-key   &nb= sp;                     &= nbsp;  <---- this becomes SubjectPublicKeyInfo ASN.1 structure
        |     +--rw (private-key-type)         |        +--:(private-k= ey)
        |        |  +--rw = private-key?                  = <---- this becomes a raw ASN.1 key (e.g., RSAPrivateKey, ECPrivateKey)<= br>         |        +--:(encrypted= -private-key)
        |           +--rw = encrypted-private-key
        |             &nb= sp;+--rw (key-type)
        |             &nb= sp;|  +--:(symmetric-key-ref)
        |             &nb= sp;|  |  +--rw symmetric-key-ref?     leafref = // ref to another key in keystore
        |             &nb= sp;|  +--:(asymmetric-key-ref)
        |             &nb= sp;|     +--rw asymmetric-key-ref?    leafref = // ref to another key in keystore
        |             &nb= sp;+--rw value?                =       <--- this becomes an CMS EncryptedData struct= ure containing an OneAsymmetricKey (from rfc5958)
        |
        +--rw symmetric-keys
           +--rw symmetric-key* [name]               +--rw name   &nbs= p;                     &n= bsp;        // arbitrary user-set value
              +--rw algorithm  =                     &nbs= p;    <---- TBD, mostly likely an AlgID value from rfc721= 0
              +--rw (key-type)
                 +--:(key)=
                 |  += --rw key?                   &n= bsp;          <---- this becomes an OctetS= tring (ASN.1 structure)
                 +--:(encr= ypted-key)
                    += --rw encrypted-key
                     = ;  +--rw (key-type)
                     = ;  |  +--:(symmetric-key-ref)
                     = ;  |  |  +--rw symmetric-key-ref?      //=  leafref to another key in keystore
                     = ;  |  +--:(asymmetric-key-ref)
                     = ;  |     +--rw asymmetric-key-ref?    //&= nbsp;leafref to another key in keystore
                     = ;  +--rw value?               &= nbsp;        <---- this becomes an CMS EncryptedData= structure containing an OneSymmetricKey (from rfc6031)

 

 

OPTION B2  (use On= eSymmetricKey and OneAsymmetricKey)

-----------------------= -------------------------------------------------------------

PROs: private keys= can declare their intended use (encrypt vs sign) and modes (CBS vs GCM)

CONs: not supported by = OpenSSL command line (but are by languages, e.g., Python)

 

module: ietf-keystore      +--rw keystore
        +--rw asymmetric-keys
        |  +--rw asymmetric-key* [name]
        |     +--rw name     &n= bsp;                     =         // arbitrary user-set value
        |     +--rw algorithm   &nbs= p;                     &n= bsp;   <---- this could be deleted, or set to the same OID as = in B1
        |     +--rw public-key   &nb= sp;                     &= nbsp;  <---- SubjectPublicKeyInfo ASN.1 structure  (same as in= B1)
        |     +--rw (private-key-type)         |        +--:(private-k= ey)
        |        |  +--rw = private-key?                  = <---- this becomes a ASN.1 OneAsymmetricKey (from rfc5958)         |        +--:(encrypted= -private-key)
        |           +--rw = encrypted-private-key
        |             &nb= sp;+--rw (key-type)
        |             &nb= sp;|  +--:(symmetric-key-ref)
        |             &nb= sp;|  |  +--rw symmetric-key-ref?      // leaf= ref to another key in keystore
        |             &nb= sp;|  +--:(asymmetric-key-ref)
        |             &nb= sp;|     +--rw asymmetric-key-ref?    // leafref to= another key in keystore
        |             &nb= sp;+--rw value?                =         <---- CMS EncryptedData ASN.1 structure&nbs= p;(same as in B1)
        |
        +--rw symmetric-keys
           +--rw symmetric-key* [name]               +--rw name   &nbs= p;                     &n= bsp;        arbitrary user-set value
              +--rw algorithm  =                     &nbs= p;    <---- this could be deleted, or set to the same Alg= ID value from B1
              +--rw (key-type)
                 +--:(key)=
                 |  += --rw key?                   &n= bsp;          <---- this becomes a AS= N.1 OneSymmetricKey (from rfc6031)
                 +--:(encr= ypted-key)
                    += --rw encrypted-key
                     = ;  +--rw (key-type)
                     = ;  |  +--:(symmetric-key-ref)
                     = ;  |  |  +--rw symmetric-key-ref?     lea= fref to another key in keystore
                     = ;  |  +--:(asymmetric-key-ref)
                     = ;  |     +--rw asymmetric-key-ref?    lea= fref to another key in keystore
                     = ;  +--rw value?               &= nbsp;        <---  CMS EncryptedData ASN.1= structure (same as in B1)

 

 

 

 

In summary:<= /p>

    - B1 is e= asier to support unencrypted keys, but fails to support some things importa= nt to some security folks (not me).

    - B1 comp= lexity to support encrypted keys is TBD (I'm told OpenSSL command line can = do it, but have yet to verify)

    - B2 is p= referred by crypto folks, but lack an OpenSSL command line will thwart the = development of simple scripts.

    - NC/RC a= re programmatic APIs, so complexity shouldn't be driving factor, though it = may affect solution adoption.

 

 

Thoughts?

 

Kent // co-author<= /o:p>

 

 

 

 

--_000_MN2PR11MB4366AE6CF9E03B15EBEA3A39B5B30MN2PR11MB4366namp_-- From nobody Fri Sep 13 06:41:18 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883D8120806 for ; Fri, 13 Sep 2019 06:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 (2048-bit key) header.d=akamai.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 NZtemKy415xG for ; Fri, 13 Sep 2019 06:41:15 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 05F9E120288 for ; Fri, 13 Sep 2019 06:41:14 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8DDbvaY027007; Fri, 13 Sep 2019 14:41:11 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=90UIJNbc8s0Y8OfMWKURKpy0d1bvSgr6FeeJmEQbL5g=; b=Hvnc/hnDptelvhFHuHISpdqMb1jytRQANzmjbmj6XxR8obxog2nakRPbmKAegD9b0gbk E0FefpAoNng6fxul2I+prNQM/imOVwmaorPBBs+v9Radl91krKEzoRGsvZejWFWHqetl p0YJ9TNZQCtSi/miE1c0S5F6fMdMk+gvyvDXhXufkReZ/v5uoQXHSbovAwUze0VQ+a6f kDt2OoQls+H9LZ3u6ysIzH+05F892JSWeQ89e35FTKHO1vvo3v91Jd8/stQLnjKvv7Fc q4N/y4w588LR3ZXNFccT7AUSyKN0lsucjaxYboTCl17SB2NZIzd+SjydAUHLx7N9XzFg ng== Received: from prod-mail-ppoint7 (prod-mail-ppoint7.akamai.com [96.6.114.121] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2uytckkhyv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Sep 2019 14:41:11 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x8DDXfmX031544; Fri, 13 Sep 2019 09:41:09 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint7.akamai.com with ESMTP id 2uyth7q018-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 13 Sep 2019 09:41:08 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 13 Sep 2019 09:41:06 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 13 Sep 2019 09:41:06 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Fri, 13 Sep 2019 09:41:06 -0400 From: "Salz, Rich" To: "Rob Wilton (rwilton)" , Kent Watsen , "netconf@ietf.org" CC: Russ Housley , Rifaat Shekh-Yusef , Sean Turner Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxGVhFlbERW30moo9Q8WhnpJqcpkUCAgAAOz4A= Date: Fri, 13 Sep 2019 13:41:05 +0000 Message-ID: References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.151] Content-Type: multipart/alternative; boundary="_000_D67400427CD9466F911ABA4339042B5Dakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-13_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=500 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909130134 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-13_06:2019-09-11,2019-09-13 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 priorityscore=1501 mlxlogscore=481 spamscore=0 lowpriorityscore=0 impostorscore=0 phishscore=0 adultscore=0 clxscore=1011 mlxscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909130135 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2019 13:41:17 -0000 --_000_D67400427CD9466F911ABA4339042B5Dakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQo+IEkgdGhpbmsgdGhhdCB1c2luZyBhIG51bWVyaWNhbCBPSUQgdG8gaWRlbnRpZnkgY3J5cHRv IGFsZ29yaXRobXMgZG9lc27igJl0IHNlZW0gbGlrZSBhIGdyZWF0IGNob2ljZQ0KDQpFdmVyeSBP SUQgZGVmaW5pdGlvbiBJ4oCZdmUgc2VlbiBoYXMgYSBuYW1lLCBvZnRlbiBib3RoIGEgc2hvcnQg bmFtZSBhbmQgYSBsb25nIG5hbWUuICBMb29rIGF0IGh0dHBzOi8vb2lkLWluZm8uY29tICBUaGVy ZSBpcyBhbHNvIGEgVVJOIHN5bnRheCBmb3IgT0lE4oCZcy4gVGhlIHdpZGVseS11c2VkIE9wZW5T U0wgaGFzIGEgYnVpbHQtaW4gbWFwcGluZzsgc2VlIGh0dHBzOi8vZ2l0aHViLmNvbS9vcGVuc3Ns L29wZW5zc2wvYmxvYi9tYXN0ZXIvY3J5cHRvL29iamVjdHMvb2JqZWN0cy50eHQgLg0KDQo+IEkg d29uZGVyIGlmIGNoYW5naW5nIGZyb20gaWRlbnRpZmllcnMgdG8gZW51bXMgd2FzIGEgbWlzdGFr ZS4gIElmIHdlIHdlcmUgdG8gdXNlIFlBTkcgaWRlbnRpZmllcnMgdGhlbiB3ZSB3b3VsZG7igJl0 IG5lZWQgdG8gZGVmaW5lIHRoZW0gYWxsIG5vdywgYW5kIHRoZXkgd291bGRu4oCZdCBhbGwgbmVl ZCB0byBiZSBkZWZpbmVkIGluIHRoZSBzYW1lIFlBTkcgbW9kdWxlLiAgSW4gZmFjdCwgaWYgd2Ug d2VyZSB0byBnbyBiYWNrIHRvIHVzaW5nIGlkZW50aWZpZXJzIHRoZW4gcGVyaGFwcyBORVRDT05G IHNob3VsZCByZXN0cmljdCBpdHNlbGYgdG8gb25seSBkZWZpbmluZyB0aGUgaWRlbnRpZmllcnMg dGhhdCB3ZSBhY3R1YWxseSBuZWVkIG5vdywgYW5kIGxlYXZlIHRoZSByZXN0IHRvIHRoZSBzZWN1 cml0eSBmb2xrcyB0byBmaWd1cmUgb3V0LCBwcm9iYWJseSBhcyBzZXBhcmF0ZSBtb2R1bGVzIGRl ZmluaW5nIHRoZSBleHRyYSBpZGVudGlmaWVycyB0aGF0IHRoZXkgbmVlZCwgb3IgYXMgYSBiaXMg dmVyc2lvbiBvZiB0aGUgY3J5cHRvLXR5cGVzIGRyYWZ0IGlmIHJlcXVpcmVkLg0KDQpJIGFtIHN0 cm9uZ2x5IGluIGZhdm9yIG9mIG5vdCB0cnlpbmcgdG8gY3JlYXRlIGEgdW5pZmllZCBtb2R1bGUg Zm9yICphbGwqIGNyeXB0b2dyYXBoeSwgYXMgSSBoYXZlIHBvc3RlZCBiZWZvcmUuICBJIGRvbuKA mXQga25vdyBlbm91Z2ggYWJvdXQgWUFORyB0byBrbm93IGlmIHRoaXMgaXMgdGhlIG9ubHkgd2F5 IHRvIGFjaGlldmUgdGhhdCwgYnV0IHRoaXMgc2VlbXMgbGlrZSB0aGUgcmlnaHQgdGhpbmcgdG8g ZG8uIFRoZXJlIGFyZSBuZXcgdHlwZXMgb2YgY3J5cHRvIGNvbWluZyAobG9vayBhdCB3aGF0IENG UkcgaXMgZG9pbmcpLCBhbmQgdGhleSBhcmUgbGlrZWx5IHRvIGNyZWF0ZSBuZXcgb2JqZWN0IHR5 cGVzLg0KDQo= --_000_D67400427CD9466F911ABA4339042B5Dakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <477691E031FF1344BF6D82B255F049ED@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3Jt YWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFu LkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjM0 MzI4ODAyMDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MjUyNDkzMjE4O30NCkBsaXN0IGwwOmxl dmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjM4NDk4OTc2NDsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6LTE3MjczNDc5NjY7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6ODMyNTMyNTE2Ow0KCW1z by1saXN0LXRlbXBsYXRlLWlkczotMzMwODk1NzUwO30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28t bGV2ZWwtc3RhcnQtYXQ6MzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwzDQoJ e21zby1saXN0LWlkOjE1NjgyOTkyOTI7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOi0xMjIwMzU3MTk2IDEzNDgwNzU2NyAxMzQ4MDc1NzcgMTM0ODA3NTc5 IDEzNDgwNzU2NyAxMzQ4MDc1NzcgMTM0ODA3NTc5IDEzNDgwNzU2NyAxMzQ4MDc1NzcgMTM0ODA3 NTc5O30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBs MzpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4t bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDM6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJ dGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21h cmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW4iPiZndDsgSSB0aGluayB0aGF0IHVz aW5nIGEgbnVtZXJpY2FsIE9JRCB0byBpZGVudGlmeSBjcnlwdG8gYWxnb3JpdGhtcyBkb2VzbuKA mXQgc2VlbSBsaWtlIGEgZ3JlYXQgY2hvaWNlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV2ZXJ5 IE9JRCBkZWZpbml0aW9uIEnigJl2ZSBzZWVuIGhhcyBhIG5hbWUsIG9mdGVuIGJvdGggYSBzaG9y dCBuYW1lIGFuZCBhIGxvbmcgbmFtZS4mbmJzcDsgTG9vayBhdA0KPGEgaHJlZj0iaHR0cHM6Ly9v aWQtaW5mby5jb20iPmh0dHBzOi8vb2lkLWluZm8uY29tPC9hPiZuYnNwOyBUaGVyZSBpcyBhbHNv IGEgVVJOIHN5bnRheCBmb3IgT0lE4oCZcy4gVGhlIHdpZGVseS11c2VkIE9wZW5TU0wgaGFzIGEg YnVpbHQtaW4gbWFwcGluZzsgc2VlDQo8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vb3BlbnNz bC9vcGVuc3NsL2Jsb2IvbWFzdGVyL2NyeXB0by9vYmplY3RzL29iamVjdHMudHh0Ij4NCmh0dHBz Oi8vZ2l0aHViLmNvbS9vcGVuc3NsL29wZW5zc2wvYmxvYi9tYXN0ZXIvY3J5cHRvL29iamVjdHMv b2JqZWN0cy50eHQ8L2E+IC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5k ZW50Oi4yNWluIj4mZ3Q7IDxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SSB3b25kZXIgaWYgY2hh bmdpbmcgZnJvbSBpZGVudGlmaWVycyB0byBlbnVtcyB3YXMgYSBtaXN0YWtlLiZuYnNwOyBJZiB3 ZSB3ZXJlIHRvIHVzZSBZQU5HIGlkZW50aWZpZXJzIHRoZW4gd2Ugd291bGRu4oCZdCBuZWVkIHRv IGRlZmluZSB0aGVtIGFsbCBub3csIGFuZCB0aGV5IHdvdWxkbuKAmXQgYWxsIG5lZWQgdG8gYmUg ZGVmaW5lZA0KIGluIHRoZSBzYW1lIFlBTkcgbW9kdWxlLiZuYnNwOyBJbiBmYWN0LCBpZiB3ZSB3 ZXJlIHRvIGdvIGJhY2sgdG8gdXNpbmcgaWRlbnRpZmllcnMgdGhlbg0KPC9zcGFuPnBlcmhhcHMg TkVUQ09ORiBzaG91bGQgcmVzdHJpY3QgaXRzZWxmIHRvIG9ubHkgZGVmaW5pbmcgdGhlIGlkZW50 aWZpZXJzIHRoYXQgd2UgYWN0dWFsbHkgbmVlZCBub3csIGFuZCBsZWF2ZSB0aGUgcmVzdCB0byB0 aGUgc2VjdXJpdHkgZm9sa3MgdG8gZmlndXJlIG91dCwgcHJvYmFibHkgYXMgc2VwYXJhdGUgbW9k dWxlcyBkZWZpbmluZyB0aGUgZXh0cmEgaWRlbnRpZmllcnMgdGhhdCB0aGV5IG5lZWQsIG9yIGFz IGEgYmlzIHZlcnNpb24NCiBvZiB0aGUgY3J5cHRvLXR5cGVzIGRyYWZ0IGlmIHJlcXVpcmVkLiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIHN0cm9uZ2x5IGluIGZhdm9yIG9mIG5v dCB0cnlpbmcgdG8gY3JlYXRlIGEgdW5pZmllZCBtb2R1bGUgZm9yICo8Yj5hbGw8L2I+KiBjcnlw dG9ncmFwaHksIGFzIEkgaGF2ZSBwb3N0ZWQgYmVmb3JlLiZuYnNwOyBJIGRvbuKAmXQga25vdyBl bm91Z2ggYWJvdXQgWUFORyB0byBrbm93IGlmIHRoaXMgaXMgdGhlIG9ubHkgd2F5IHRvIGFjaGll dmUgdGhhdCwgYnV0IHRoaXMgc2VlbXMgbGlrZSB0aGUgcmlnaHQgdGhpbmcNCiB0byBkby4gVGhl cmUgYXJlIG5ldyB0eXBlcyBvZiBjcnlwdG8gY29taW5nIChsb29rIGF0IHdoYXQgQ0ZSRyBpcyBk b2luZyksIGFuZCB0aGV5IGFyZSBsaWtlbHkgdG8gY3JlYXRlIG5ldyBvYmplY3QgdHlwZXMuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D67400427CD9466F911ABA4339042B5Dakamaicom_-- From nobody Fri Sep 13 07:05:14 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61199120047 for ; Fri, 13 Sep 2019 07:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=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=jacobsuniversity.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 Jg9qD5qFpooE for ; Fri, 13 Sep 2019 07:05:09 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on0630.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::630]) (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 98E3612002F for ; Fri, 13 Sep 2019 07:05:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AbBXvLKx4QAoOnsJZfi9/uvE6/j2/t67xnB3Ze07IwqmIZ7UumT9qxZVhFOc54v5Vg38Puh+CnUiiU5GL7tOcUwXYrAW9NRyVqFcJIlRqtrTy9bPcpIi/pgBmW8cCC851wJf++a0gK5s2/oR4/J/sf/iWzEdZQ1e/jnaySxcQw7n/xbUrQUyxBWKRZ7STqjgmLmsiJZp784g+PdYVFBqua+H5NMdCFK68Vlmy99DRYau/DyUAG78cSoPM7RM3dIhSnmuaxw2adeiIvKwyh7UaF9fSUOvoSBftpWgfGZnQVVvaofbjQ/SNX8zeRgsFaoNTHadEesz/79LKPh/9qY9cw== 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=eeVAlvYx+nkte2NO1apJW1F3RqUjEVBHT3RL+06ArmA=; b=VrTV9YK5QGEFwPRRD+42n500TFGtL6CeA8phKn4owOcoYt3qwfgl5rtDojdNT70qyfYKay1rs4agr7veJIqPIjc0ZkSFBLQbiIaozj8oo+qULxnF13Zuif5tsnQpczupn6ma5VK7bjBK2ieIjfjnkHrxkchGrSqCXcy0VO2ao+uM5pZdC1LGBdjzSruxudqgOphK39jHPBpCwklYFtzQXVFdb3IWaVU6jPwVBhuz/y625eYYRGouE9iUosxAel8KSVU5BZneIjlgK+7nCOP3JuZ6+7o4XMwx9SIEn7HBGZVg7maxJnPS/w/pAuI7PChkVU6KBHqKURaDyHENZALSVg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eeVAlvYx+nkte2NO1apJW1F3RqUjEVBHT3RL+06ArmA=; b=cH70gcQ7tZ60/O0i/LOWh+6HjaWQUeWzGi64oM/D0sQtFuIF7orwA4TTYbr0BZeCFMyBxSSXss5YCvTHs3K+34+kqUxH1DlJ7RnCnifPsQ7bIUEVmYQgqOazxTECsDoUpnxF/myHMobF2KRKa0Q4LqUYYgE/fm6cIOJOpRb6hNE= Received: from VI1P190MB0686.EURP190.PROD.OUTLOOK.COM (10.186.159.71) by VI1P190MB0238.EURP190.PROD.OUTLOOK.COM (10.172.80.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.15; Fri, 13 Sep 2019 14:05:06 +0000 Received: from VI1P190MB0686.EURP190.PROD.OUTLOOK.COM ([fe80::d48a:ffa3:4fff:141e]) by VI1P190MB0686.EURP190.PROD.OUTLOOK.COM ([fe80::d48a:ffa3:4fff:141e%2]) with mapi id 15.20.2263.021; Fri, 13 Sep 2019 14:05:06 +0000 From: =?utf-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= To: "Salz, Rich" CC: "Rob Wilton (rwilton)" , Kent Watsen , "netconf@ietf.org" , Russ Housley , Rifaat Shekh-Yusef , Sean Turner Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxGVhFlbERW30moo9Q8WhnpJqcpkUCAgAAOz4CAAAa0gA== Date: Fri, 13 Sep 2019 14:05:06 +0000 Message-ID: <20190913140505.2ivwf34byefaafli@anna.jacobs.jacobs-university.de> References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> In-Reply-To: Reply-To: =?utf-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: AM4PR0202CA0021.eurprd02.prod.outlook.com (2603:10a6:200:89::31) To VI1P190MB0686.EURP190.PROD.OUTLOOK.COM (2603:10a6:800:12e::7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:638:709:5::7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 54a49956-3eb5-45af-cc33-08d73853614f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:VI1P190MB0238; x-ms-traffictypediagnostic: VI1P190MB0238: x-ms-exchange-purlcount: 3 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0159AC2B97 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400004)(396003)(366004)(376002)(136003)(346002)(199004)(189003)(486006)(7736002)(316002)(76176011)(52116002)(186003)(66946007)(8936002)(6306002)(6512007)(99286004)(46003)(1076003)(4326008)(6916009)(5660300002)(66476007)(66556008)(64756008)(66446008)(25786009)(86362001)(478600001)(14454004)(966005)(2906002)(229853002)(3450700001)(71190400001)(6436002)(71200400001)(6486002)(6246003)(6116002)(43066004)(85202003)(476003)(6506007)(54906003)(386003)(305945005)(85182001)(8676002)(81166006)(81156014)(11346002)(446003)(53936002)(786003)(102836004)(256004)(777600001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P190MB0238; H:VI1P190MB0686.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 05I9n3grvbgft70qOt4oSTqRiiS43FpzFBESdl+cWfBmuSePqCdNGjqOY5LFQ98VSlCqQUFU3aXG10clQsXoYMQNHoVKK1xfb11B7/0WdGIm1cyhXv/9SmbqRaC57qSDUVizsqViasFkXDFVzC5h9NwvJVOYuEPZKlPN91mUmaeg1S3QJ3m/IhpGPt4g9GGTwLGxAv47Dz1viYlCNA3uyPBd7nL/HIBGlahQBWlwwiR0CMUSQWOTD0JsELZs+kFzr9cKIIonOX9p8E62gjpyHnRcxTFLw+zdTmj/G32g0T5v134HZjPQFXMf2udmlJw3tqBqX//xeRzfOB9dEdmQuCXDAtABa/JRovxxEAQXXd1Y9hW5LGbDe1aZBMBPVv2Se8ujYB9W2ajOezuQrkmvxn9ml8sa8WO+Ihekr/tyVHk= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 54a49956-3eb5-45af-cc33-08d73853614f X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Sep 2019 14:05:06.3205 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: p4YcNZK6PcuhbOemygP0qTL7vviHrlHgbyPIyG76L2fEbB3lCwOwapnVkIvGRFJkpety/EJJZp/ovjSE+kI4Orf8Ud+ma6CdPnzS7seJdL0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P190MB0238 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Sep 2019 14:05:13 -0000 T24gRnJpLCBTZXAgMTMsIDIwMTkgYXQgMDE6NDE6MDVQTSArMDAwMCwgU2FseiwgUmljaCB3cm90 ZToNCj4gDQo+IEV2ZXJ5IE9JRCBkZWZpbml0aW9uIEnigJl2ZSBzZWVuIGhhcyBhIG5hbWUsIG9m dGVuIGJvdGggYSBzaG9ydCBuYW1lIGFuZCBhIGxvbmcgbmFtZS4gIExvb2sgYXQgaHR0cHM6Ly9v aWQtaW5mby5jb20gIFRoZXJlIGlzIGFsc28gYSBVUk4gc3ludGF4IGZvciBPSUTigJlzLiBUaGUg d2lkZWx5LXVzZWQgT3BlblNTTCBoYXMgYSBidWlsdC1pbiBtYXBwaW5nOyBzZWUgaHR0cHM6Ly9n aXRodWIuY29tL29wZW5zc2wvb3BlbnNzbC9ibG9iL21hc3Rlci9jcnlwdG8vb2JqZWN0cy9vYmpl Y3RzLnR4dCAuDQo+IA0KDQpUaGlzIGNhbiBnZXQgbmFzdHkuIFRoZXJlIGFyZSBpbnRlcnByZXRh dGlvbnMgb2Ygd2hhdCBPSURzIGFuZA0KYXNzb2NpYXRlZCAnbmFtZXMnIGFyZSBidXQgaW4gZ29v ZCBvbGQgQVNOLjEgdGhpbmdzIG9mdGVuIGxvb2sgcXVpdGUNCmRpZmZlcmVudC4gRXZlbiB0aGUg ZG90dGVkIG51bWVyaWMgbm90YXRpb24gMS4zLjYuMSBpcyBhbiBJRVRGDQppbnZlbnRpb24sIG5v dCBhbiBBU04uMSBub3RhdGlvbi4gVGhlIE9JRCBVUk4gbm90YXRpb24gaXMgYWN0dWFsbHkNCnVz aW5nIGEgc2VxdWVuY2Ugb2YgbnVtYmVycyAoc2VlIFJGQyAzMDYxKS4gSW4gQVNOLjEsIHlvdSB3 b3VsZCB3cml0ZQ0KYW4gT0lEIHZhbHVlIGFzIHsgaXNvKDEpIG9yZygzKSBkb2QoNikgaWFuYSgx KSB9IGFuZCB5b3UgY2FuIGFzc29jaWF0ZQ0KJ2Rlc2NyaXB0b3JzJyB0byB0aGUgbnVtYmVycyBi dXQgdGhleSBhcmUgc2NvcGVkIHRvIHRoZSBicmFuY2hpbmcNCmxldmVsIGFuZCBJIHRoaW5rIHRo ZXkgb25seSBuZWVkIHRvIGJlIHVuaXF1ZSB3aXRoaW4gdGhlIHVzYWdlDQpjb250ZXh0LiBUaGUg YWJvdmUgZG9lcyBub3QgZGVmaW5lIHRoYXQgJ2RvZCcgYWx3YXlzIHJlc29sdmVzIHRvDQoxLjMu Niwgb3IgbW9yZSBjb3JyZWN0bHksIHRvIHsgaXNvKDEpIG9yZygzKSBkb2QoNikgfS4gSW4gZmFj dCwgew0KaXNvKDEpIG9yZygzKSBmb28oNikgfSBpcyBqdXN0IGFzIGdvb2QuIEluIHNvbWUgY29u dGV4dCB0aGUgdW5pcXVlbmVzcw0KaXNzdWUgaGFzIGJlZW4gYWRkcmVzc2VzIGJ5IHVzaW5nIEFT Ti4xIG1vZHVsZSBuYW1lcyBhcyBwcmVmaXhlcyB3aXRoDQpkaWZmZXJlbnQgbm90YXRpb25hbCBt YXJrdXAgYW5kIHNvIG9uLiBUaGUgY3J5cHRvIHBlb3BsZSBzZWVtIHRvDQpieXBhc3MgdGhpcyBp c3N1ZSBieSBjcmVhdGluZyBsb25nIGRlc2NyaXB0b3JzIHRoYXQgaG9wZWZ1bGx5IGhhdmUgYQ0K bG93IHByb2JhYmlsaXR5IHRvIGNsYXNoIGFuZCB0aGV5IHNlZW0gdG8gdHJlYXQgdGhlc2UgZGVz Y3JpcHRvciBhcw0KcmVnaXN0ZXJlZCBuYW1lcywgd2hpY2ggZnJvbSBhbiBBU04uMSBwZXJzcGVj dGl2ZSB0aGV5IGFyZSBub3QuDQoNClBlcmhhcHMgaXQgaXMgYmVzdCB0byBub3QgbG9vayB0b28g bXVjaCBiZWhpbmQgdGhlIGN1cnRhaW4gYW5kIGp1c3QNCnRhbGsgYWJvdXQgdXNpbmcgZXhpc3Rp bmcgbmFtZXMsIGF2b2lkaW5nIHRvIGRpdmUgaW50byBkZXRhaWxzIHdoYXQNCnRoZXNlIG5hbWVz IHJlYWxseSBhcmUgYW5kIHdoZXJlIHRoZXkgY29tZSBmcm9tLiBQZXJoYXBzIHdlIG5lZWQgdG8N Cm1vdmUgdG8gYSBtb3JlIG9wYXF1ZSB0eXBlIHRoYXQgY2FuIGhvbGQgbmFtZXMgb2YgY3J5cHRv IGFsZ29yaXRobXMNCmFuZCB3ZSBwb2ludCB0byB3ZWxsLWtub3duIG5hbWVzIChpLmUuLCBkZWZp bmVkIGluIHNvbWUgSUFOQQ0KcmVnaXN0cmllcykgdGhhdCBhcHBseSB0byBjZXJ0YWluIHByb3Rv Y29sIGNvbnRleHRzLg0KDQovanMNCg0KLS0gDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAg ICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1 ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KRmF4OiAg ICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHku ZGUvPg0K From nobody Mon Sep 16 08:56:36 2019 Return-Path: <0100016d3aca212d-1791071e-66b5-4730-9cf2-6b4f16217d21-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEB3120112 for ; Mon, 16 Sep 2019 08:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 tm_SPE6QDvJ4 for ; Mon, 16 Sep 2019 08:56:31 -0700 (PDT) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88CF7120052 for ; Mon, 16 Sep 2019 08:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568649388; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=DsAp+97E5VIEkipf7x0/Tj1326cGrr70CN5SB4HzTUI=; b=dzAgnhFDQ5XBgbeJz8B7KQ5KcxFMDMmwMsyidETsZZ1INnscJXIvSyziboZQR4uw iwuuw5tRMpIPXFZdq7CwycCAN1YTf/h8FVZCk7SAz+oZKOZAWRfIrXVnSlZSrmTLZNq 4vEFjifwv1Ref751TWl+kEJClstEd6tfnE0BX7ps= From: Kent Watsen Message-ID: <0100016d3aca212d-1791071e-66b5-4730-9cf2-6b4f16217d21-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_60FF4810-7632-485F-A695-81CD9BF67357" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 16 Sep 2019 15:56:28 +0000 In-Reply-To: <20190910.090803.448863675820254782.mbj@tail-f.com> Cc: "netconf@ietf.org" To: Martin Bjorklund References: <0100016ccff35064-9da3c8b6-263c-47f6-a4f2-4db9495bc8b7-000000@email.amazonses.com> <20190827.091531.2170309439792906317.mbj@tail-f.com> <0100016d18b462b3-38420cd3-1259-47ea-aa1b-f250a8238c9b-000000@email.amazonses.com> <20190910.090803.448863675820254782.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.16-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 15:56:35 -0000 --Apple-Mail=_60FF4810-7632-485F-A695-81CD9BF67357 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, >> Firstly, while ietf-http-client defines HTTP "basic" authentication >> parameters, the example in the I-D didn't show them, even though the >> YANG module uses the ietf-http-client module. >=20 > I am not sure what this reply means exactly. My comment about > authorization above was for outgoing notifications (section 3.4.6 in > RFC 8341). I.e., the device needs a local username for the configured > subscription. Do you mean to add to the draft a new section called something like = "Authorization" that mimics what's in the SN draft regarding, e.g., = NACM? >> That said, >> ietf-http-client fails to define a "path" field, so that appears to = be >> something that should be added to it >=20 > I don't think 'path' belongs in http-client; not all http client > configs require a 'path' (e.g. restconf uses it's own mechanism wih > ".well-known"). True, path isn't needed for RESTCONF clients. This draft doesn't assume anything about the server (if this is a valid = assumption is discussed below) and, presumably, this assumption may be a = common. So maybe ietf-http-client should also define a feature = statement for the new "path" leaf, thus servers have an easy way to turn = it on. It would be mandatory false, with the description statement = indicating that it is only needed for some protocols. Alternatively, = this draft could augment in a "path" leaf into the "http-params" = section, or define a new section for just the path. Thoughts? Regarding the validity of the assumption that this draft must also (in = addition to http-client-server) assume nothing about the remote server. = It seems like the completion to that assumption is, why is it not a = RESTCONF server. The reason is that we don't want to burden the remote = server with needing to implement a full RESTCONF server. But, if the = server were to implement only one module that implements only one RPC = (e.g., receive-notifications) and otherwise has no protocol accessible = nodes, then a fully-compliant server-implementation could be very small = (e.g., returning either an HTTP error code or an empty response for = datastore oriented HTTP/RESTCONF requests). Just an idea, it may not be = too much of a jump for this draft, and the benefits a questionable = (ability to assume discovery and have well-defined URL construction = (i.e., {+restconf}/operations/receive-notifications). >> As for the HTTP operation and request body, POST-ing a stream of >> notifications seems right. >=20 > Yes POST seems right. I'm not so sure about the streaming though. > Perhaps pipelining is the right mechanism. For "bulk" sending, the > "bundled-message" defined in draft-ietf-netconf-notification-messages > seems right. These sound like good conversations to have. > My point is that the document needs quite a lot of work, and I think > that the WG should spend its energy on getting the "client-server" > documents ready. NOTE again that I do think that this is good work, > and we should work on it, the sooner the better (but after the > existing documents). We can slow-walk this draft. As you say, we need to prioritize other = drafts... Kent // as co-author --Apple-Mail=_60FF4810-7632-485F-A695-81CD9BF67357 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Martin,

Firstly, while ietf-http-client defines HTTP "basic" = authentication
parameters, the example in the I-D didn't = show them, even though the
YANG module uses the = ietf-http-client module.

I am = not sure what this reply means exactly.  My comment about
authorization above was for outgoing notifications (section = 3.4.6 in
RFC 8341).  I.e., the device needs a local = username for the configured
subscription.

Do you = mean to add to the draft a new section called something like = "Authorization" that mimics what's in the SN draft regarding, e.g., = NACM?



That said,
ietf-http-client fails to define a "path" field, so that = appears to be
something that should be added to it

I don't think 'path' belongs in = http-client; not all http client
configs require a 'path' = (e.g. restconf uses it's own mechanism wih
".well-known").
True, path isn't needed for RESTCONF = clients.

This draft doesn't assume = anything about the server (if this is a valid assumption is discussed = below) and, presumably, this assumption may be a common.  So maybe = ietf-http-client should also define a feature statement for the new = "path" leaf, thus servers have an easy way to turn it on.   It = would be mandatory false, with the description statement indicating that = it is only needed for some protocols.  Alternatively, this draft = could augment in a "path" leaf into the "http-params" section, or define = a new section for just the path.  Thoughts?

Regarding the validity of the assumption that this = draft must also (in addition to http-client-server) assume nothing about = the remote server.  It seems like the completion to that assumption = is, why is it not a RESTCONF server.   The reason is that we don't = want to burden the remote server with needing to implement a full = RESTCONF server.  But, if the server were to implement only one = module that implements only one RPC (e.g., receive-notifications) and = otherwise has no protocol accessible nodes, then a fully-compliant = server-implementation could be very small (e.g., returning either an = HTTP error code or an empty response for datastore oriented = HTTP/RESTCONF requests).  Just an idea, it may not be too much of a = jump for this draft, and the benefits a questionable (ability to assume = discovery and have well-defined URL construction (i.e., = {+restconf}/operations/receive-notifications).



As for the HTTP = operation and request body, POST-ing a stream of
notifications seems right.

Yes POST seems right.  I'm not so sure about the = streaming though.
Perhaps pipelining is the right = mechanism.  For "bulk" sending, the
"bundled-message" = defined in draft-ietf-netconf-notification-messages
seems = right.

These sound like good conversations to = have.


My point is = that the document needs quite a lot of work, and I think
that the WG should spend its energy on getting the = "client-server"
documents ready.   NOTE again = that I do think that this is good work,
and we should work = on it, the sooner the better (but after the
existing = documents).


We can slow-walk this = draft.   As you say, we need to prioritize other = drafts...


Kent // as co-author


= --Apple-Mail=_60FF4810-7632-485F-A695-81CD9BF67357-- From nobody Mon Sep 16 09:01:04 2019 Return-Path: <0100016d3ace18a6-d033851a-d81b-4d07-8726-4d816a924e34-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52D5120890 for ; Mon, 16 Sep 2019 09:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 00cScMb7i5Vi for ; Mon, 16 Sep 2019 09:00:50 -0700 (PDT) Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E40D91208C0 for ; Mon, 16 Sep 2019 09:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568649648; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=xPjzzFWeNtFaHeyiuH0khtKCbdftRzJxoRwSHYphYQ4=; b=dHoOK1xh4JkDWxS7+ovvL3cOuJi7/uwERHlEo4NZYSXXlnm53lRISZkCcfNmeMt5 iXjo8pfec57q0SD2QMb+KqLKBkW5o5b96Ibo5KMhZW5jvrwf6SNmI8lLArT//3okh5Q D+1RJueMAoH7YglqDXzsbM1Er76lETRYQtDXyqy4= From: Kent Watsen Message-ID: <0100016d3ace18a6-d033851a-d81b-4d07-8726-4d816a924e34-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9D1A4B61-BA24-400B-9EB1-C37C14173B06" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 16 Sep 2019 16:00:48 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: wangzitao References: X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.16-54.240.8.32 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 16:01:04 -0000 --Apple-Mail=_9D1A4B61-BA24-400B-9EB1-C37C14173B06 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Michael, > I am trying to understand the relationship and usage of this draft and = a set of netconf drafts: > This model present the receiver's information (such as IP, port, etc) = and it augment the ietf-subscription-notification model that the user = can specify multiple subscription receivers. > And the user also need to configure the server to specify receiver's = port and IP (via ietf-client-server?). What is " ietf-client-server" ? > That the server can call home to the receivers. > Is my understanding correct? If yes, I suggest that a brief = description of the workflow should be present in the draft. This is a good suggestion. We will add a section showing context. Kent > =20 > Best Regards! > -Michael --Apple-Mail=_9D1A4B61-BA24-400B-9EB1-C37C14173B06 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Michael,


I am trying to = understand the relationship and usage of this draft and a set of netconf = drafts:
This model present the receiver's information (such as IP, = port, etc) and it augment the ietf-subscription-notification model that = the user can specify multiple subscription receivers.
And the user = also need to configure the server to specify receiver's port and IP (via = ietf-client-server?).

What is " ietf-client-server" ?


That the server can call home to the = receivers.
Is = my understanding correct? If yes, I suggest that a brief description of = the workflow should be present in the = draft.

This is a good suggestion.  We will add a = section showing context.

Kent


 
Best Regards!
-Michael

= --Apple-Mail=_9D1A4B61-BA24-400B-9EB1-C37C14173B06-- From nobody Mon Sep 16 09:05:55 2019 Return-Path: <0100016d3ad2b4f2-e591bc21-9b47-49a0-81df-3e8d9ca23fce-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A231312008A for ; Mon, 16 Sep 2019 09:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 YqcxrExR3wBL for ; Mon, 16 Sep 2019 09:05:52 -0700 (PDT) Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC5712004F for ; Mon, 16 Sep 2019 09:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568649950; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=bhcKLQpKht4GOygc0LUw9dubzkWvGHnUY7VFdGbQWPg=; b=lGkTyKKN9kW+P4S7RprCe8TtRIh7Zs8MsdU4wSyzaOGelL7Je6ClcR8FmiJVkw2K VmHzICpCVY/sB8EPpQzbPo1UmRWFLit0lJ4EOJays752BxJRwN4KM73rQ/MzS4tw1bQ iBCDHkVhyBzKCH3yt3Xuja+9q4AXw7tJlv6m4Z34= From: Kent Watsen Message-ID: <0100016d3ad2b4f2-e591bc21-9b47-49a0-81df-3e8d9ca23fce-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_AB856DFA-CAFB-4797-B166-A2EF10FA9C9D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 16 Sep 2019 16:05:50 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: Tianran Zhou References: <0100016ccff35064-9da3c8b6-263c-47f6-a4f2-4db9495bc8b7-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.16-54.240.8.32 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 16:05:54 -0000 --Apple-Mail=_AB856DFA-CAFB-4797-B166-A2EF10FA9C9D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Tianran, > Considering the multiple stream originator case, I would suggest this = https-notif to add a channel level configuration. > i.e. > =20 > +--receivers > +--receiver > +--channels > +--channel > +--here put the http client server configurations > =20 > This is compatible with the single originator case with only one = channel configuration. We can look at this. Maybe use a choice statement between the two = options... Kent // co-author > =20 > If you do not like this, I think existing https-notif model also = works. > i.e. each receiver configuration stands for one channel. > But this is not clear IMO. > =20 > Best, > Tianran --Apple-Mail=_AB856DFA-CAFB-4797-B166-A2EF10FA9C9D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Hi Tianran,


Considering the multiple stream originator case, I would = suggest this https-notif to add a channel level configuration.

i.e.

 

+--receivers

   +--receiver

      +--channels

         = +--channel

          &nb= sp; +--here put the http client server configurations

 

This is compatible with the single originator case with only = one channel = configuration.


We can look at this.  Maybe use a choice = statement between the two options...

Kent // co-author

 

If= you do not like this, I think existing https-notif model also = works.

i.e. each receiver configuration stands for one channel.

But this is not clear IMO.

 

Best,

Tianran

= --Apple-Mail=_AB856DFA-CAFB-4797-B166-A2EF10FA9C9D-- From nobody Mon Sep 16 09:41:36 2019 Return-Path: <0100016d3af34c5a-846fdcd1-9398-4266-84d4-5abec5c0fad1-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFB3120046 for ; Mon, 16 Sep 2019 09:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 o3YdWLKpRGPx for ; Mon, 16 Sep 2019 09:41:28 -0700 (PDT) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1077E120026 for ; Mon, 16 Sep 2019 09:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568652086; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=qybDz9VpP2Xgt+tOhz4iOxVvhheGY0qorLgIZifvZIE=; b=MpUPyqzfn32pjsfjE4+sp0k2u/J5+cHtX2gGHC0ZkquhOR8r3omOo0Qq6LaGpiUP 6GefA3xRVWfS8Y1KviKbhaaYJClmVb9/GRPkupjxu9r8BXLqXaebSJhX9D8ynBLGaqu uCeEhiZef2ny86iFULWt70bnZ4ePJywZp5J/k/kE= From: Kent Watsen Message-ID: <0100016d3af34c5a-846fdcd1-9398-4266-84d4-5abec5c0fad1-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_02FEE243-A112-482A-95C8-ACD349871623" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 16 Sep 2019 16:41:26 +0000 In-Reply-To: <20190912.195859.497068783415208339.mbj@tail-f.com> Cc: "netconf@ietf.org" , Russ Housley , rifaat.ietf@gmail.com, sean@sn3rd.com To: Martin Bjorklund References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <20190912.111242.323252506550752617.mbj@tail-f.com> <0100016d265824b0-313d5248-5aba-4b96-8f21-768be7784568-000000@email.amazonses.com> <20190912.195859.497068783415208339.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.16-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 16:41:35 -0000 --Apple-Mail=_02FEE243-A112-482A-95C8-ACD349871623 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, >>> I guess it is still needed >>> when a key is generated though. But then note that "rsaEncryption" = is >>> not an OID ("1.2.840.113549.1.1.1" is the OID). If you want to use = a >>> symbolic name you need something else. >>=20 >> Isn't it? Check https://tools.ietf.org/html/rfc3279#section-2.3.1 >> . >=20 > The symbolic name is not (guaranteed to be) globally unique. Probably... >>> Is the idea that the module becomes ietf-tls-keystore with top-level >>> node tls-keystore? >>=20 >> There is no need to change the "keystore" module's name. >=20 > So where would keys for SSH go? Your reasoning was (which I agree > with) don't create a super-generic module for all things crypto / > keys, but let's focus on what we need (you wrote "to configure an > HTTPS server). If we limit ourselves to TLS it should be reflected in > the naming. But perhaps I misunderstood your intention. Some options: 1) use a 'union' between the two key types (binary vs string) 2) add a new 'case' to the "private-key" choice called "ssh-key" 3) go back to -04 draft with top-level "host-keys" container Of these, (2) is the obvious choice.=20 > Right, but at that time the idea was to be able to have very generic > "algorithm", and have each alg define its own format, right? As soon > as we limit "algorithm" and the format for the key, we are no longer > generic. Hence we should have a less generic name, that more > precisely decribe what it is. s/ ietf-crypto-types / ietf-asn1-types /? >> More fully, that line says:=20 >>=20 >> c) figure out a plan for SSH later (the risk level is pretty = low, >> e.g., I've seen code to key SSH keys from TLS keys) >>=20 >> The intention was to signal that it should be easy to determine how = to >> support SSH, to support the netconf-client-server draft. Nothing is >> blocked. We just need to discuss a plan for what to do. The easiest >> thing would be to 1) update the mapping table in the = ssh-client-server >> drafts from mapping SSH-specific algorithm identifiers (e.g., in >> rfc4253) to OIDs >=20 > But do these OIDs exist already? Probably. Regardless, we have to map them to something. Look at = ssh-client-server draft. >>> Yes, NC/RC are programmatic APIs, but simplicity is always = goodness... >>=20 >> ACK, but let's be clear that the "simplicity" is in the ready access >> to tooling, not from an algorithmic perspective. >=20 > But the solution becomes more robust if you can use the format you're > used to w/o additional conversion. Right, see option (2) above. Kent --Apple-Mail=_02FEE243-A112-482A-95C8-ACD349871623 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Martin,


I guess it is still needed
when a key is = generated though.  But then note that "rsaEncryption" is
not an OID ("1.2.840.113549.1.1.1" is the OID).  If you = want to use a
symbolic name you need something else.

Isn't it?  Check https://tools.ietf.org/html/rfc3279#section-2.3.1
<https://tools.ietf.org/html/rfc3279#section-2.3.1>.

The symbolic name is not = (guaranteed to be) globally unique.

Probably...



Is the idea that the = module becomes ietf-tls-keystore with top-level
node = tls-keystore?

There is no need = to change the "keystore" module's name.

So where would keys for SSH go?  Your reasoning was = (which I agree
with) don't create a super-generic module = for all things crypto /
keys, but let's focus on what we = need (you wrote "to configure an
HTTPS server).  If = we limit ourselves to TLS it should be reflected in
the = naming.   But perhaps I misunderstood your intention.

Some = options:

1) use a 'union' between = the two key types (binary vs string)
2) add a new 'case' to = the "private-key" choice called "ssh-key"
3) go back to -04 = draft with top-level "host-keys" container

Of these, (2) is the obvious = choice. 


Right, but at that time the idea was to be able to have very = generic
"algorithm", and have each alg define its own = format, right?  As soon
as we limit "algorithm" and = the format for the key, we are no longer
generic. =  Hence we should have a less generic name, that more
precisely decribe what it is.

s/ = ietf-crypto-types / ietf-asn1-types /?




More fully, that line = says:

c) figure out a plan for SSH = later (the risk level is pretty low,
e.g., = I've seen code to key SSH keys from TLS keys)

The intention was to signal that it should be easy to = determine how to
support SSH, to support the = netconf-client-server draft.  Nothing is
blocked. =  We just need to discuss a plan for what to do.  The = easiest
thing would be to 1) update the mapping table in = the ssh-client-server
drafts from mapping SSH-specific = algorithm identifiers (e.g., in
rfc4253) to OIDs

But do these OIDs exist = already?

Probably.  Regardless, we have to map them to = something.  Look at ssh-client-server draft.



Yes, NC/RC = are programmatic APIs, but simplicity is always goodness...

ACK, but let's be clear that the = "simplicity" is in the ready access
to tooling, not from = an algorithmic perspective.

But = the solution becomes more robust if you can use the format you're
used to w/o additional conversion.

Right, = see option (2) above.



Kent


= --Apple-Mail=_02FEE243-A112-482A-95C8-ACD349871623-- From nobody Mon Sep 16 09:49:16 2019 Return-Path: <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F300B12011D for ; Mon, 16 Sep 2019 09:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 5SpbD0JLnyCO for ; Mon, 16 Sep 2019 09:49:14 -0700 (PDT) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17639120046 for ; Mon, 16 Sep 2019 09:49:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568652552; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=XzAse/tUa/roVPVKHJYo0WfCE5lVYWGykaC0ARttHF0=; b=gKFBgwkG86/jRJWof0Q3Raon+b4YSWNH1Iop0EHZ8wb5HHePHooopZlw1mKNsZLG 8ttr54YNDuERJu+DcKrXaQX5rEqFZfXIuQJBRPAl9DceC1gfzhkY6eV9z7ckOJeg8ky fm/QQ3nobTDRNTHZ+4RimWCIUVuuLZfB4IcrUV9I= From: Kent Watsen Message-ID: <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_35DE00FD-3D4A-4CC4-AD2A-10AE1AC69E85" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 16 Sep 2019 16:49:12 +0000 In-Reply-To: Cc: "netconf@ietf.org" , Russ Housley , Rifaat Shekh-Yusef , Sean Turner To: "Rob Wilton (rwilton)" References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.16-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 16:49:16 -0000 --Apple-Mail=_35DE00FD-3D4A-4CC4-AD2A-10AE1AC69E85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Rob, =20 > I think that using a numerical OID to identify crypto algorithms = doesn=E2=80=99t seem like a great choice. Seeing a config file say = something like =E2=80=9CrsaEncryption=E2=80=9D instead of some OID = string seems to be much more human friendly. And as Martin says, using = the OID name has no guarantees of being unique. On only this very last point, I'm unsure about that. =20 > I wonder if changing from identifiers to enums was a mistake. If we = were to use YANG identifiers then we wouldn=E2=80=99t need to define = them all now, and they wouldn=E2=80=99t all need to be defined in the = same YANG module. In fact, if we were to go back to using identifiers = then perhaps NETCONF should restrict itself to only defining the = identifiers that we actually need now, and leave the rest to the = security folks to figure out, probably as separate modules defining the = extra identifiers that they need, or as a bis version of the = crypto-types draft if required.=20 Seems like a reasonable approach, but I don't know how that differs, in = the end, from the uber definition some folks have voiced a concern for. = Maybe we need to understand better what that concern is better. =20 > I=E2=80=99m not sure that I understand why we would always want to = always use ASN.1 to describe the keys for all algorithms. Could we just = leave the algorithm identities to define what format they use? If we = were to go back to using identities when we could have the choice of = using multiple inheritance and then have a separate set of identities to = allow the key formats to be defined. Note, I have no objection to ASN.1 = being used for some/most the keys if that is the right encoding. Perhaps we can do both, say that the field is parsed according to its = "algorithm" value, but for now, all algorithm identifiers happen to = point to ASN.1 structures. > Hopefully the comments are useful, apologies if they are not! All good. Keep them coming. Kent --Apple-Mail=_35DE00FD-3D4A-4CC4-AD2A-10AE1AC69E85 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Rob,

 
  1. I = think that using a numerical OID to identify crypto algorithms doesn=E2=80= =99t seem like a great choice.  Seeing a config file say something = like =E2=80=9CrsaEncryption=E2=80=9D instead of some OID string seems = to be much more human friendly.  And as Martin says, using the OID = name has no guarantees of being unique.


On only this very last point, I'm unsure about = that.

 
  1. I = wonder if changing from identifiers to enums was a mistake.  If we = were to use YANG identifiers then we wouldn=E2=80=99t need to define = them all now, and they wouldn=E2=80=99t all need to be defined in the same YANG = module.  In fact, if we were to go back to using identifiers then = perhaps NETCONF should restrict itself to only defining the identifiers = that we actually need now, and leave the rest to the security folks to figure out, probably as separate modules defining the extra = identifiers that they need, or as a bis version of the crypto-types = draft if required. 


Seems like a reasonable approach, but I don't know = how that differs, in the end, from the uber definition some folks have = voiced a concern for.  Maybe we need to understand better what that = concern is better.


 
  1. I=E2=80= =99m not sure that I understand why we would always want to always use = ASN.1 to describe the keys for all algorithms.  Could we just leave = the algorithm identities to define what format they use?   If we = were to go back to using identities when we could have the choice of = using multiple inheritance and then have a separate set of identities to = allow the key formats to be defined.  Note, I have no objection to ASN.1 being used for some/most the keys if that is the = right encoding.

Perhaps we can do both, say that the field is = parsed according to its "algorithm" value, but for now, all algorithm = identifiers happen to point to ASN.1 structures.



Hopefully the comments are useful, apologies if they are = not!


All = good.  Keep them coming.


Kent

= --Apple-Mail=_35DE00FD-3D4A-4CC4-AD2A-10AE1AC69E85-- From nobody Mon Sep 16 09:50:12 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155F812011D for ; Mon, 16 Sep 2019 09:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 cyOsn-hETyLr for ; Mon, 16 Sep 2019 09:50:07 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 351F5120046 for ; Mon, 16 Sep 2019 09:50:07 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8GGHEa2012139; Mon, 16 Sep 2019 17:50:06 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=lakQMaV+9Q6DpD5tdjCRgpTttk84TdHdwmLKlnsMCJE=; b=jdNhxMj2iwa8gbBWdeTiv7yqw9gwbh7h5WYChnafvHkdTn+3jsseiCTrvxXzkzMS2TIZ CUDy+dhY+eO4RQPuPQ5xUYwwtB7NXFG+q9okbA7pU8td8zmu+LmyCdcHOEdPasxp13nq h5s6ZmPl2nsMtRG7/hY5jUfR1+zWlfPwNuSStm0rp6EIfQXS10UPmLQIpQSZGJWyEw6x LklZG8dm3EPikR/1hpX+lXK2+Z1FooFIwjWi6DaNZtpuAQhWCPgqOn+hKOlIxNqxkXnN s1dQADAn7d4HSDW66BO2QouZReA6lIFcepRuM1xNhUzrhC0lnBNGU6zkNQRYd0V24pA4 5Q== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2v0qf6suhd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Sep 2019 17:50:05 +0100 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x8GGJE4Y006567; Mon, 16 Sep 2019 12:50:04 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint6.akamai.com with ESMTP id 2v0uhw2wha-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 16 Sep 2019 12:50:04 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 16 Sep 2019 12:50:04 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Mon, 16 Sep 2019 12:50:04 -0400 From: "Salz, Rich" To: Kent Watsen , Martin Bjorklund CC: Russ Housley , "netconf@ietf.org" , "sean@sn3rd.com" , "rifaat.ietf@gmail.com" Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxGVhFlbERW30moo9Q8WhnpJqcoBcwAgAB82YCAABYxgIAGM6kA//+/WoA= Date: Mon, 16 Sep 2019 16:50:03 +0000 Message-ID: <457BBD20-FBE0-4FD5-AD89-1902E45E5DA5@akamai.com> References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <20190912.111242.323252506550752617.mbj@tail-f.com> <0100016d265824b0-313d5248-5aba-4b96-8f21-768be7784568-000000@email.amazonses.com> <20190912.195859.497068783415208339.mbj@tail-f.com> <0100016d3af34c5a-846fdcd1-9398-4266-84d4-5abec5c0fad1-000000@email.amazonses.com> In-Reply-To: <0100016d3af34c5a-846fdcd1-9398-4266-84d4-5abec5c0fad1-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.21] Content-Type: multipart/alternative; boundary="_000_457BBD20FBE04FD5AD891902E45E5DA5akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-16_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=958 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909160167 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-16_07:2019-09-11,2019-09-16 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 lowpriorityscore=0 mlxlogscore=929 malwarescore=0 suspectscore=0 phishscore=0 clxscore=1015 adultscore=0 impostorscore=0 bulkscore=0 priorityscore=1501 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909160167 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 16:50:10 -0000 --_000_457BBD20FBE04FD5AD891902E45E5DA5akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pj4gQnV0IHRoZW4gbm90ZSB0aGF0ICJyc2FFbmNyeXB0aW9uIiBpcyBub3QgYW4gT0lEICgiMS4y Ljg0MC4xMTM1NDkuMS4xLjEiIGlzIHRoZSBPSUQpLiAgSWYgeW91IHdhbnQgdG8gdXNlIGEgc3lt Ym9saWMgbmFtZSB5b3UgbmVlZCBzb21ldGhpbmcgZWxzZS4NCg0KPiBJc24ndCBpdD8gIENoZWNr IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzMjc5I3NlY3Rpb24tMi4zLjE8aHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRm Lm9yZ19odG1sX3JmYzMyNzktMjNzZWN0aW9uLTJEMi4zLjEmZD1Ed01GQWcmYz05NlpiWlpjYU1G NHcwRjRqcE42TFpnJnI9NExNMEdiUjBoOUZ2eDg2RnRzS0ktdyZtPXVZRThmWGU2UjIzdGF2a3Ru YUlTOW43SGFPdGpMZ1hhaWgtMlVMd25UM3Mmcz1GLVNXVzNNN0VRYktwcFBzYU1xTUttdHBsZ2t6 ZzZJTy1SY1JTcGxqQXRVJmU9Pg0KDQoNCklmIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHRoaXMgbGlu ZToNCg0KICAgICAgICAgICByc2FFbmNyeXB0aW9uIE9CSkVDVCBJREVOVElGSUVSIDo6PSAgeyBw a2NzLTEgMX0NCg0KVGhlIGludGVudCBpcyB0aGF0IGl0IG9ubHkgZGVmaW5lcyBhIHN5bWJvbGlj IG5hbWUgdG8gYmUgdXNlZCBhcyBhIHNob3J0LWhhbmQgcHJlZml4IG9mIGFuIE9JRCBzdHJpbmcg d2l0aGluIHRoYXQgc3BlY2lmaWMgQVNOMSBtb2R1bGUgZGVmaW5pdGlvbi4gIEZvciBleGFtcGxl LCBwa2NzLTEgaXMgYSBwcmVmaXggaXMgYSBwcmVmaXggZm9yIDEuMi44NDAuMTEzNTQ5LjEuMSBh bmQgaXMgbm90IGV4cGVjdGVkIG9yIHJlcXVpcmVkIHRvIGJlIHVuaXF1ZSBnbG9iYWxseS4NCg0K --_000_457BBD20FBE04FD5AD891902E45E5DA5akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAs IGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1h bDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBwbGUtdGFi LXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxl MTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0 ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZn dDsgQnV0IHRoZW4gbm90ZSB0aGF0ICZxdW90O3JzYUVuY3J5cHRpb24mcXVvdDsgaXMgbm90IGFu IE9JRCAoJnF1b3Q7MS4yLjg0MC4xMTM1NDkuMS4xLjEmcXVvdDsgaXMgdGhlIE9JRCkuICZuYnNw O0lmIHlvdSB3YW50IHRvIHVzZSBhIHN5bWJvbGljIG5hbWUgeW91IG5lZWQgc29tZXRoaW5nIGVs c2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQomZ3Q7IElzbid0 IGl0PyAmbmJzcDtDaGVjayA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfcmZjMzI3OS0yM3NlY3Rp b24tMkQyLjMuMSZhbXA7ZD1Ed01GQWcmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7 cj00TE0wR2JSMGg5RnZ4ODZGdHNLSS13JmFtcDttPXVZRThmWGU2UjIzdGF2a3RuYUlTOW43SGFP dGpMZ1hhaWgtMlVMd25UM3MmYW1wO3M9Ri1TV1czTTdFUWJLcHBQc2FNcU1LbXRwbGdremc2SU8t UmNSU3BsakF0VSZhbXA7ZT0iPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMyNzkj c2VjdGlvbi0yLjMuMTwvYT48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tcmlnaHQ6MS4waW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgeW91IGFyZSByZWZlcnJpbmcgdG8gdGhpcyBsaW5l OjxvOnA+PC9vOnA+PC9wPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgPC9zcGFuPiZuYnNwOyByc2FFbmNyeXB0aW9uIE9CSkVDVCBJREVOVElG SUVSIDo6PSZuYnNwOyB7IHBrY3MtMSAxfTxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBp bnRlbnQgaXMgdGhhdCBpdCBvbmx5IGRlZmluZXMgYSBzeW1ib2xpYyBuYW1lIHRvIGJlIHVzZWQg YXMgYSBzaG9ydC1oYW5kIHByZWZpeCBvZiBhbiBPSUQgc3RyaW5nIHdpdGhpbiB0aGF0IHNwZWNp ZmljIEFTTjEgbW9kdWxlIGRlZmluaXRpb24uJm5ic3A7IEZvciBleGFtcGxlLCBwa2NzLTEgaXMg YSBwcmVmaXggaXMgYSBwcmVmaXggZm9yIDEuMi44NDAuMTEzNTQ5LjEuMSBhbmQgaXMgbm90IGV4 cGVjdGVkIG9yDQogcmVxdWlyZWQgdG8gYmUgdW5pcXVlIGdsb2JhbGx5LjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_457BBD20FBE04FD5AD891902E45E5DA5akamaicom_-- From nobody Mon Sep 16 09:58:20 2019 Return-Path: <0100016d3b02a96b-a8f419e4-09f7-45b4-927f-bb715bf4d5e8-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C51120122 for ; Mon, 16 Sep 2019 09:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 lca6z2x9v4jN for ; Mon, 16 Sep 2019 09:58:14 -0700 (PDT) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A76B7120072 for ; Mon, 16 Sep 2019 09:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568653093; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=JaFXvGTm3AeF4n4P6bnavTwGjifayySWiSqrGZ3wtyY=; b=Wi8EUDrU1BXHby2awDxCG5thS9MwUebfjsUkLjnnsyYhagychvUN9VNDom3IIBp2 taVKgDLoIjAyMr0q9wFMhgJtLtnGrOvm3Yh5Psr4HubniUt6kwnrSwNz1/QNwi8HSMi MdD3+xz/tHkctuA8v37nO2ib1I2MNDSd5f30sENM= From: Kent Watsen Message-ID: <0100016d3b02a96b-a8f419e4-09f7-45b4-927f-bb715bf4d5e8-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_54B11531-6661-4EF3-929B-CB9F4DEA14B0" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 16 Sep 2019 16:58:13 +0000 In-Reply-To: Cc: "Rob Wilton (rwilton)" , "netconf@ietf.org" , Russ Housley , Rifaat Shekh-Yusef , Sean Turner To: "Salz, Rich" References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.16-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 16:58:18 -0000 --Apple-Mail=_54B11531-6661-4EF3-929B-CB9F4DEA14B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Rich, Rob, > > I think that using a numerical OID to identify crypto algorithms = doesn=E2=80=99t seem like a great choice > =20 > Every OID definition I=E2=80=99ve seen has a name, often both a short = name and a long name. Look at https://oid-info.com = There is also a URN syntax for OID=E2=80=99s. = The widely-used OpenSSL has a built-in mapping; see = https://github.com/openssl/openssl/blob/master/crypto/objects/objects.txt = . I believe that each OID has a common name that can be used. nit: s/https/http/ (the site didn't resolve until I removed the 's') > > I wonder if changing from identifiers to enums was a mistake. If we = were to use YANG identifiers then we wouldn=E2=80=99t need to define = them all now, and they wouldn=E2=80=99t all need to be defined in the = same YANG module. In fact, if we were to go back to using identifiers = then perhaps NETCONF should restrict itself to only defining the = identifiers that we actually need now, and leave the rest to the = security folks to figure out, probably as separate modules defining the = extra identifiers that they need, or as a bis version of the = crypto-types draft if required.=20 > =20 > I am strongly in favor of not trying to create a unified module for = *all* cryptography, as I have posted before. I don=E2=80=99t know = enough about YANG to know if this is the only way to achieve that, but = this seems like the right thing to do. There are new types of crypto = coming (look at what CFRG is doing), and they are likely to create new = object types. Rich, can you explain why not try to define a unified module for all = cryptography? Is it because it is a monster effort? Would many = smaller efforts that, together, achieve the same thing be different in a = meaningful way? Kent --Apple-Mail=_54B11531-6661-4EF3-929B-CB9F4DEA14B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hi Rich, Rob,

> I think that using a numerical OID to = identify crypto algorithms doesn=E2=80=99t seem like a great choice

 
Every OID = definition I=E2=80=99ve seen has a name, often both a short name and a = long name.  Look at https://oid-info.com = There is also a URN syntax for OID=E2=80=99s. The widely-used OpenSSL = has a built-in mapping; see = https://github.com/openssl/openssl/blob/master/crypto/objects/objects.txt<= /a> .





> I wonder if = changing from identifiers to enums was a mistake.  If we were to = use YANG identifiers then we wouldn=E2=80=99t need to define them all = now, and they wouldn=E2=80=99t all need to be defined in the same YANG module.  In fact, if we were to go back to using = identifiers then perhaps NETCONF should restrict itself to only defining the = identifiers that we actually need now, and leave the rest to the = security folks to figure out, probably as separate modules defining the = extra identifiers that they need, or as a bis version of the crypto-types draft if required. 

 
I am strongly in = favor of not trying to create a unified module for *all*= cryptography, as I have posted before.  I don=E2=80=99t know = enough about YANG to know if this is the only way to achieve that, but = this seems like the right thing to do. There are new types of crypto coming (look at what CFRG is = doing), and they are likely to create new object types.






= --Apple-Mail=_54B11531-6661-4EF3-929B-CB9F4DEA14B0-- From nobody Mon Sep 16 10:04:43 2019 Return-Path: <0100016d3b08795d-2e86aef5-b98a-4a15-b8b2-c11cd0d417de-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25597120867 for ; Mon, 16 Sep 2019 10:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 AE0nqEWQ_Doo for ; Mon, 16 Sep 2019 10:04:37 -0700 (PDT) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCEE7120145 for ; Mon, 16 Sep 2019 10:04:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568653474; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=dWxpPVgVRT6i2w2D5LWbk2b7ie10MsZrGe1GqVoSrV0=; b=X3S242U2aBA5aMq+CosURkxThmK0Vzz0Nm0yc4+Uty4Xpt5Gjc4J186AXpjzfja5 X8dbwhI6V7y5FcSUO50ayV3eMG2U8GvkhN5AkqF8j7JZL861vQarcDr178GETlGzyD0 +AnOuD+XJEovhJkjS/icOEyH5ie1T7ud3MgzOvbA= From: Kent Watsen Message-ID: <0100016d3b08795d-2e86aef5-b98a-4a15-b8b2-c11cd0d417de-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E71470E8-EC57-4958-989B-23AD5F1B4AB6" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 16 Sep 2019 17:04:34 +0000 In-Reply-To: <20190913140505.2ivwf34byefaafli@anna.jacobs.jacobs-university.de> Cc: "Salz, Rich" , "Rob Wilton (rwilton)" , "netconf@ietf.org" , Russ Housley , Rifaat Shekh-Yusef , Sean Turner To: Juergen Schoenwaelder References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <20190913140505.2ivwf34byefaafli@anna.jacobs.jacobs-university.de> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.16-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 17:04:42 -0000 --Apple-Mail=_E71470E8-EC57-4958-989B-23AD5F1B4AB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Juergen, > Perhaps it is best to not look too much behind the curtain and just > talk about using existing names, avoiding to dive into details what > these names really are and where they come from. Perhaps we need to > move to a more opaque type that can hold names of crypto algorithms > and we point to well-known names (i.e., defined in some IANA > registries) that apply to certain protocol contexts. I use thinking that we'd use numbers only, or more precisely, the ASN.1 = OID structure. An OID's common "name" value is only "needed" for = presentation; though it makes using `genarate-asymmetric-key" and = `generate-symmetric-key` more complicated, as both actions need to take = an "algorithm" parameter. Kent // co -author --Apple-Mail=_E71470E8-EC57-4958-989B-23AD5F1B4AB6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Hi Juergen,

Perhaps it is best to not look too much behind the curtain = and just
talk about using existing names, avoiding to dive = into details what
these names really are and where they = come from. Perhaps we need to
move to a more opaque type = that can hold names of crypto algorithms
and we point to = well-known names (i.e., defined in some IANA
registries) = that apply to certain protocol contexts.

I use = thinking that we'd use numbers only, or more precisely, the ASN.1 OID = structure.   An OID's common "name" value is only "needed" for = presentation; though it makes using `genarate-asymmetric-key" and = `generate-symmetric-key` more complicated, as both actions need to take = an "algorithm" parameter.

Kent // = co -author


= --Apple-Mail=_E71470E8-EC57-4958-989B-23AD5F1B4AB6-- From nobody Mon Sep 16 10:10:34 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B957120090 for ; Mon, 16 Sep 2019 10:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 bJ_S6ZTzi47E for ; Mon, 16 Sep 2019 10:10:28 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 7BA41120072 for ; Mon, 16 Sep 2019 10:10:28 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x8GH7OB5010334; Mon, 16 Sep 2019 18:10:14 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=iabnD/m2xy3XKODseuDmZujXBERAtNgMoKuzAPqOJOc=; b=eTffiftTUsycc+fiFrsFyoUZfuSPCwf0xQYxYhxM4EJMn++n2E3aRTYe8hy0HSf/KDHb +9xV0KfFLW50EHO8nh9/EwMncNOtYy/hooTKJ9C4k8GX9cUj9DGRamNAlG2a22E9CKCg jXw8TaA/QNrXE7s/oRogMWxOl65WJ+VfeKFZZbvJzxgYXdy315YDsq6+vCu4nmLabDGg 8YKy7dSIrGsh947/GBvAiP8j6akqDOFcDbWKHQd5OpM4hPJsK/GeJsYFY/cI2ri1FlfN jIKxoXqZk9vZt6z0ezvkrcKEdYQY59/vtErB1PKUrKAQWp0bxyScM9YF6LOchh7n+ILJ Vw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2v0tehh716-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Sep 2019 18:10:14 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x8GH3wbS017532; Mon, 16 Sep 2019 13:10:11 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2v0uhw07t0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 16 Sep 2019 13:10:10 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 16 Sep 2019 13:10:09 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Mon, 16 Sep 2019 13:10:09 -0400 From: "Salz, Rich" To: Kent Watsen CC: "Rob Wilton (rwilton)" , "netconf@ietf.org" , Russ Housley , Rifaat Shekh-Yusef , Sean Turner Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxGVhFlbERW30moo9Q8WhnpJqcpkUCAgAAOz4CABTEggP//wEiA Date: Mon, 16 Sep 2019 17:10:09 +0000 Message-ID: <2F75E025-45AF-4F91-8E44-98B957DC9F32@akamai.com> References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <0100016d3b02a96b-a8f419e4-09f7-45b4-927f-bb715bf4d5e8-000000@email.amazonses.com> In-Reply-To: <0100016d3b02a96b-a8f419e4-09f7-45b4-927f-bb715bf4d5e8-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.21] Content-Type: multipart/alternative; boundary="_000_2F75E02545AF4F918E4498B957DC9F32akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-16_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=774 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909160169 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-16_07:2019-09-11,2019-09-16 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 lowpriorityscore=0 malwarescore=0 spamscore=0 adultscore=0 mlxlogscore=766 priorityscore=1501 bulkscore=0 phishscore=0 impostorscore=0 suspectscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909160169 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 17:10:33 -0000 --_000_2F75E02545AF4F918E4498B957DC9F32akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCiAgKiAgIEkgYmVsaWV2ZSB0aGF0IGVhY2ggT0lEIGhhcyBhIGNvbW1vbiBuYW1lIHRoYXQg Y2FuIGJlIHVzZWQuDQoNCllvdSBjYW4gdXNlIHRob3NlIG5hbWVzIHdpdGhpbiBhIG1vZHVsZSB0 aGF0IHlvdSBhcmUgZGVmaW5pbmcsIGJ1dCBiZSBwcmVwYXJlZCB0byBoYW5kbGUgY29sbGlzaW9u cyB3aGVuIHlvdSBpbXBvcnQgbXVsdGlwbGUgbW9kdWxlcy4gIEkgYW0gbm90IGF3YXJlIG9mIGFu eSwgYnV0IHRoZXJlIGlzIGFic29sdXRlbHkgbm8gcmVxdWlyZW1lbnQgdGhhdCBvbmUgbW9kdWxl IHdpbGwgbm90IGhhdmUgc29tZXRoaW5nIGxpa2U6DQogICAgICAgICAgICAgICAgZm9vIDo6PSBP QkpFQ1QgSURFTlRJRklFUiB7IDEgMiAzIC4gLiAuIH0NCmFuZCBhbm90aGVyIHdpbGwgaGF2ZQ0K ICAgICAgICAgICAgICAgIGZvbyA6Oj0gT0JKRUNUIElERU5USUZJRVIgeyAxIDIgNSAuIC4gLiB9 DQoNCg0KICAqICAgUmljaCwgY2FuIHlvdSBleHBsYWluIHdoeSBub3QgdHJ5IHRvIGRlZmluZSBh IHVuaWZpZWQgbW9kdWxlIGZvciBhbGwgY3J5cHRvZ3JhcGh5PyAgIElzIGl0IGJlY2F1c2UgaXQg aXMgYSBtb25zdGVyIGVmZm9ydD8gICBXb3VsZCBtYW55IHNtYWxsZXIgZWZmb3J0cyB0aGF0LCB0 b2dldGhlciwgYWNoaWV2ZSB0aGUgc2FtZSB0aGluZyBiZSBkaWZmZXJlbnQgaW4gYSBtZWFuaW5n ZnVsIHdheT8NCg0KVHdvIHJlYXNvbnM6DQoNCg0KICAxLiAgVGhlIGRhdGEgc3RydWN0dXJlcyBh cmUgZGlmZmVyZW50LCBhbmQgdGhlIHNlY3VyaXR5IGNvbW11bml0aWVzIGFyZSBkaWZmZXJlbnQu ICBUaGVyZSBhcmUgbWFueSBwZW9wbGUgZmFtaWxpYXIgd2l0aCBIVFRQUyBjb25maWd1cmF0aW9u IGFuZCBUTFMsIGFuZCB0aGVyZSBhcmUgbWFueSBwZW9wbGUgZmFtaWxpYXIgd2l0aCBTU0gga2V5 IG1hbmFnZW1lbnQsIGJ1dCB0aGUgb3ZlcmxhcCBiZXR3ZWVuIHRob3NlIHR3byBjb21tdW5pdGll cyBpcyBhIGZyYWN0aW9uIG9mIGVpdGhlciBvbmUuDQoNCg0KICAxLiAgSSBwcmVmZXIgYml0ZS1z aXplZCBjaHVua3MgcmF0aGVyIHRoYW4gYSBib2lsIHRoZSBvY2VhbiBlZmZvcnQuDQoNCg0KDQog IDEuICBUaGV5IGFyZSBzZXBhcmF0ZSB0aGluZ3M7IFRMUyB1c2VzIFg1MDkgYW5kIFBLQ1Mgc3Ry dWN0dXJlcywgZ2VuZXJhbGx5OyBTU0ggb2Z0ZW4gdXNlcyDigJxyYXfigJ0gcHVibGljIGtleXMu ICBTZWUgaHR0cHM6Ly9ibG9nLm9kZGJpdC5jb20vcG9zdC8yMDExLTA1LTA4LWNvbnZlcnRpbmct b3BlbnNzaC1wdWJsaWMta2V5cy8gZm9yIGFuIGV4cGxhbmF0aW9uLg0KDQpNYWtlIHNlbnNlPw0K DQo= --_000_2F75E02545AF4F918E4498B957DC9F32akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <6ED35C1FE886DC4381818623AA993AD6@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K c3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1p ZDo0NjYwOTMxMjk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOjE4NTM5MTk0OTIgOTMzNDEzNzY2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVs MQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDA6bGV2ZWwy DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6NDk0NjE2NTgw Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMjAyMDI5 ODc0NiA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcx NSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTps ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0 LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0 O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwx OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJn aW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRp c2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGlu O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5JIGJlbGlldmUgdGhhdCBlYWNoIE9JRCBoYXMgYSBj b21tb24gbmFtZSB0aGF0IGNhbiBiZSB1c2VkLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Zb3UgY2FuIHVzZSB0aG9zZSBuYW1lcyB3aXRoaW4gYSBtb2R1bGUg dGhhdCB5b3UgYXJlIGRlZmluaW5nLCBidXQgYmUgcHJlcGFyZWQgdG8gaGFuZGxlIGNvbGxpc2lv bnMgd2hlbiB5b3UgaW1wb3J0IG11bHRpcGxlIG1vZHVsZXMuJm5ic3A7IEkgYW0gbm90IGF3YXJl IG9mIGFueSwgYnV0IHRoZXJlIGlzIGFic29sdXRlbHkgbm8gcmVxdWlyZW1lbnQgdGhhdCBvbmUg bW9kdWxlIHdpbGwgbm90IGhhdmUgc29tZXRoaW5nDQogbGlrZTo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBmb28g Ojo9IE9CSkVDVCBJREVOVElGSUVSIHsgMSAyIDMgLiAuIC4gfTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+YW5kIGFub3RoZXIgd2lsbCBoYXZlPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZm9v IDo6PSBPQkpFQ1QgSURFTlRJRklFUiB7IDEgMiA1IC4gLiAuIH08bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPlJpY2gsIGNhbiB5b3UgZXhwbGFpbiB3aHkgbm90IHRyeSB0byBkZWZpbmUgYSB1bmlmaWVk IG1vZHVsZSBmb3IgYWxsIGNyeXB0b2dyYXBoeT8gJm5ic3A7IElzIGl0IGJlY2F1c2UgaXQgaXMg YSBtb25zdGVyIGVmZm9ydD8gJm5ic3A7IFdvdWxkIG1hbnkgc21hbGxlciBlZmZvcnRzIHRoYXQs IHRvZ2V0aGVyLCBhY2hpZXZlIHRoZQ0KIHNhbWUgdGhpbmcgYmUgZGlmZmVyZW50IGluIGEgbWVh bmluZ2Z1bCB3YXk/PG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlR3byByZWFzb25zOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlw ZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDow aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPlRoZSBkYXRhIHN0cnVjdHVyZXMgYXJlIGRpZmZl cmVudCwgYW5kIHRoZSBzZWN1cml0eSBjb21tdW5pdGllcyBhcmUgZGlmZmVyZW50LiZuYnNwOyBU aGVyZSBhcmUgbWFueSBwZW9wbGUgZmFtaWxpYXIgd2l0aCBIVFRQUyBjb25maWd1cmF0aW9uIGFu ZCBUTFMsIGFuZCB0aGVyZSBhcmUgbWFueSBwZW9wbGUgZmFtaWxpYXINCiB3aXRoIFNTSCBrZXkg bWFuYWdlbWVudCwgYnV0IHRoZSBvdmVybGFwIGJldHdlZW4gdGhvc2UgdHdvIGNvbW11bml0aWVz IGlzIGEgZnJhY3Rpb24gb2YgZWl0aGVyIG9uZS48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4t dG9wOjBpbiIgc3RhcnQ9IjIiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj5JIHByZWZl ciBiaXRlLXNpemVkIGNodW5rcyByYXRoZXIgdGhhbiBhIGJvaWwgdGhlIG9jZWFuIGVmZm9ydC48 bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIzIiB0eXBl PSIxIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBp bjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+VGhleSBhcmUgc2VwYXJhdGUgdGhpbmdzOyBUTFMg dXNlcyBYNTA5IGFuZCBQS0NTIHN0cnVjdHVyZXMsIGdlbmVyYWxseTsgU1NIIG9mdGVuIHVzZXMg 4oCccmF34oCdIHB1YmxpYyBrZXlzLiZuYnNwOyBTZWUNCjxhIGhyZWY9Imh0dHBzOi8vYmxvZy5v ZGRiaXQuY29tL3Bvc3QvMjAxMS0wNS0wOC1jb252ZXJ0aW5nLW9wZW5zc2gtcHVibGljLWtleXMv Ij4NCmh0dHBzOi8vYmxvZy5vZGRiaXQuY29tL3Bvc3QvMjAxMS0wNS0wOC1jb252ZXJ0aW5nLW9w ZW5zc2gtcHVibGljLWtleXMvPC9hPiBmb3IgYW4gZXhwbGFuYXRpb24uPG86cD48L286cD48L2xp Pjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk1ha2Ugc2Vuc2U/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_2F75E02545AF4F918E4498B957DC9F32akamaicom_-- From nobody Mon Sep 16 11:31:50 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79AEE12003E for ; Mon, 16 Sep 2019 11:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.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 WOXF6X7QEGfa for ; Mon, 16 Sep 2019 11:31:41 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80054.outbound.protection.outlook.com [40.107.8.54]) (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 9411D12004A for ; Mon, 16 Sep 2019 11:31:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TUBx4SENxScn2S0j8WmttOkG1HxFobIBYIO6Gpr5OgGDSFNiENnJpwU9Qr76VNux+yz3F1eEJmUgitagNkaRenOwAsvffIaOv/uMYTthOkBretovudvxgD66Fgz11iLO/nX9hMA5WxuHf0REDPyLX5CcPuccQsfOjV1mDgmz04q5KBs6Ytl4egyVDhFtD+CZP0Yw30rSkbkaMlegY1UXal2P2/8diVy4W4FP+A+AqNkQ3a23O6nXsPK65b7xR/vqpUOzZxDQoLOLv7ZmYtrvYIGZihKUt+h5Jpaapzu4B15uSr1NOmWtZwsDgsx2O3Kuac0ykGaGzCZSCDIkqCeg6A== 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=wLb3spDonIjmI2YTdofjE1alovJNlGfMOpGiRWtsADU=; b=iqtI7W4UhVsnp+eX814ekPUqwER/FmkAm5mae8p22MOnmdvIaqvwqA79nLoN0qjUrkN5DDyLMitDbXSPWHBwrCqjqa0yapmoGANIzV2pLSSA2jKJAlmFhyS5WW/MIm4W0mmiSumPAPt4t9ulVdFUfiHfOaAVNDyizyriIsb4mojkrXFN3qJaXKv/gaEQuDksXZaQqREXYy56ha+hRO+G5rJglc0wU9TXs7JkgIHScvhgXpDq8/nslJnmOisjaW3Cf0MziVa8RyGxVsmlf6E59UcV+Ksc3Z4SrgP81TE5F+zhoVhO4qx2dLxlPWxMx3UgWim72lie/bDIgnIVR3dIkw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wLb3spDonIjmI2YTdofjE1alovJNlGfMOpGiRWtsADU=; b=eR12x405YQDJ1g253Th7y8qOS0p59mQpDCGf/PIfQhsIdgM+yGG8kVSKEWpNeg1KQ4D4XOQk78UPHdyf93Q/pbDTUMG6Qk8sG3w8xeZB8zxb3waI3VqWclN0QHMfWtkzjk7mNzPzWbHefzKptonNEI53q1NH1u8dDzMVoqv+TlA= Received: from VI1P190MB0686.EURP190.PROD.OUTLOOK.COM (10.186.159.71) by VI1P190MB0016.EURP190.PROD.OUTLOOK.COM (10.172.13.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.24; Mon, 16 Sep 2019 18:31:38 +0000 Received: from VI1P190MB0686.EURP190.PROD.OUTLOOK.COM ([fe80::d48a:ffa3:4fff:141e]) by VI1P190MB0686.EURP190.PROD.OUTLOOK.COM ([fe80::d48a:ffa3:4fff:141e%2]) with mapi id 15.20.2263.023; Mon, 16 Sep 2019 18:31:38 +0000 From: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= To: Kent Watsen CC: "Salz, Rich" , "Rob Wilton (rwilton)" , "netconf@ietf.org" , Russ Housley , Rifaat Shekh-Yusef , Sean Turner Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxGVhFlbERW30moo9Q8WhnpJqcpkUCAgAAOz4CAAAa0gIAE6SQAgAAYUQA= Date: Mon, 16 Sep 2019 18:31:37 +0000 Message-ID: <20190916183136.w5rvwlmjobfzhbtz@anna.jacobs.jacobs-university.de> References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <20190913140505.2ivwf34byefaafli@anna.jacobs.jacobs-university.de> <0100016d3b08795d-2e86aef5-b98a-4a15-b8b2-c11cd0d417de-000000@email.amazonses.com> In-Reply-To: <0100016d3b08795d-2e86aef5-b98a-4a15-b8b2-c11cd0d417de-000000@email.amazonses.com> Reply-To: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: AM0PR05CA0004.eurprd05.prod.outlook.com (2603:10a6:208:55::17) To VI1P190MB0686.EURP190.PROD.OUTLOOK.COM (2603:10a6:800:12e::7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:638:709:5::7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bc911f0b-3351-4bb2-4bf0-08d73ad41c37 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:VI1P190MB0016; x-ms-traffictypediagnostic: VI1P190MB0016: x-ms-exchange-purlcount: 1 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 0162ACCC24 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(39850400004)(136003)(346002)(366004)(189003)(199004)(43066004)(71200400001)(71190400001)(4326008)(86362001)(6486002)(1076003)(305945005)(6436002)(53936002)(186003)(66556008)(66446008)(6306002)(6512007)(256004)(476003)(45776006)(446003)(11346002)(8676002)(46003)(478600001)(229853002)(81166006)(81156014)(8936002)(14454004)(7736002)(99286004)(25786009)(486006)(316002)(786003)(6246003)(66946007)(66476007)(64756008)(6116002)(52116002)(5660300002)(54906003)(3450700001)(102836004)(76176011)(386003)(6506007)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P190MB0016; H:VI1P190MB0686.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 8tNfrwcZiP4qxmE98N2ey43vyBLdh9rP56+z8i8Spk7Ie/EkrlGrSuLhN2LdNEIfhI5K/5Cdg1UVXLQhxnXNuIoqCsVVAI/tZVwZopTnojHIM8e9jPZsKotejeEr1emgtMLn/UuJuMEGRljogkBKO41oNWghTAwMG5XnHQ5WzPwOLlxjfZ6k97sAIkDpemjFLdAVrZvuwsVAuVm5NhVZWwrKzYs3yFz8nFnrrZ3MIZXEvyTz8CzWRTKjV144bk8T8qRJXvWMCCqw4E8hUXp1wu5Ma/s01Dn9nCzdfceLwKKxcUyYfoUDWvIIcpP6Z6yYRtkS2PY760fXw/YM5G2kErEXZYX+rP6AyNLqjsiqnXabrSRNfTQw81ypSxtk1q7mRjgP9DwnDAHshH3jteBJpLILgqgu0kkjnom9/XxAeKc= Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: bc911f0b-3351-4bb2-4bf0-08d73ad41c37 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Sep 2019 18:31:38.0640 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FVZpPFnzm9IDjIpghpwUXaokew/AxCUVmQlupP7S7LuQf9qY+Njdv9p7wCoPURHVfisf3hDba+lf5UYV1sRXVLG8rAgeQ4bEXr5I8FbeDMk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P190MB0016 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 18:31:49 -0000 On Mon, Sep 16, 2019 at 05:04:34PM +0000, Kent Watsen wrote: >=20 > Hi Juergen, >=20 > > Perhaps it is best to not look too much behind the curtain and just > > talk about using existing names, avoiding to dive into details what > > these names really are and where they come from. Perhaps we need to > > move to a more opaque type that can hold names of crypto algorithms > > and we point to well-known names (i.e., defined in some IANA > > registries) that apply to certain protocol contexts. >=20 > I use thinking that we'd use numbers only, or more precisely, the ASN.1 O= ID structure. An OID's common "name" value is only "needed" for presentat= ion; though it makes using `genarate-asymmetric-key" and `generate-symmetri= c-key` more complicated, as both actions need to take an "algorithm" parame= ter. >=20 If there is one thing almost everybody did hate about SNMP, then it is ASN.1 OIDs. And with OID I mean a sequence of numbers (not any descriptors or such things). There is a reason why YANG has support for other naming systems. It feels odd to go back to OIDs. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Sep 16 12:25:46 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7001200CC for ; Mon, 16 Sep 2019 12:25:44 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 QQXD9B-N-edW for ; Mon, 16 Sep 2019 12:25:37 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E4AE3120129 for ; Mon, 16 Sep 2019 12:25:28 -0700 (PDT) Received: from localhost (h-46-233.A165.priv.bahnhof.se [46.59.46.233]) by mail.tail-f.com (Postfix) with ESMTPSA id AF7D21AE0187; Mon, 16 Sep 2019 21:25:26 +0200 (CEST) Date: Mon, 16 Sep 2019 21:25:26 +0200 (CEST) Message-Id: <20190916.212526.427039138127777720.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016d3aca212d-1791071e-66b5-4730-9cf2-6b4f16217d21-000000@email.amazonses.com> References: <0100016d18b462b3-38420cd3-1259-47ea-aa1b-f250a8238c9b-000000@email.amazonses.com> <20190910.090803.448863675820254782.mbj@tail-f.com> <0100016d3aca212d-1791071e-66b5-4730-9cf2-6b4f16217d21-000000@email.amazonses.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 19:25:44 -0000 Kent Watsen wrote: > Hi Martin, > > >> Firstly, while ietf-http-client defines HTTP "basic" authentication > >> parameters, the example in the I-D didn't show them, even though the > >> YANG module uses the ietf-http-client module. > > > > I am not sure what this reply means exactly. My comment about > > authorization above was for outgoing notifications (section 3.4.6 in > > RFC 8341). I.e., the device needs a local username for the configured > > subscription. > > Do you mean to add to the draft a new section called something like > "Authorization" that mimics what's in the SN draft regarding, e.g., > NACM? No I mean that when the device generates a notification, NACM needs a user name to find the access control rules. What is the user name with this new protocol? > >> That said, > >> ietf-http-client fails to define a "path" field, so that appears to be > >> something that should be added to it > > > > I don't think 'path' belongs in http-client; not all http client > > configs require a 'path' (e.g. restconf uses it's own mechanism wih > > ".well-known"). > > True, path isn't needed for RESTCONF clients. > > This draft doesn't assume anything about the server (if this is a > valid assumption is discussed below) and, presumably, this assumption > may be a common. So maybe ietf-http-client should also define a > feature statement for the new "path" leaf, thus servers have an easy > way to turn it on. It would be mandatory false, with the description > statement indicating that it is only needed for some protocols. > Alternatively, this draft could augment in a "path" leaf into the > "http-params" section, or define a new section for just the path. > Thoughts? I prefer the latter. I think the 'path' leaf will not be very common whe the http-client grouping is used. > Regarding the validity of the assumption that this draft must also (in > addition to http-client-server) assume nothing about the remote > server. It seems like the completion to that assumption is, why is it > not a RESTCONF server. The reason is that we don't want to burden the > remote server with needing to implement a full RESTCONF server. But, > if the server were to implement only one module that implements only > one RPC (e.g., receive-notifications) and otherwise has no protocol > accessible nodes, then a fully-compliant server-implementation could > be very small (e.g., returning either an HTTP error code or an empty > response for datastore oriented HTTP/RESTCONF requests). Just an > idea, it may not be too much of a jump for this draft, and the > benefits a questionable (ability to assume discovery and have > well-defined URL construction (i.e., > {+restconf}/operations/receive-notifications). I'm fine with this being a new "protocol", not RESTCONF. > >> As for the HTTP operation and request body, POST-ing a stream of > >> notifications seems right. > > > > Yes POST seems right. I'm not so sure about the streaming though. > > Perhaps pipelining is the right mechanism. For "bulk" sending, the > > "bundled-message" defined in draft-ietf-netconf-notification-messages > > seems right. > > These sound like good conversations to have. > > > > My point is that the document needs quite a lot of work, and I think > > that the WG should spend its energy on getting the "client-server" > > documents ready. NOTE again that I do think that this is good work, > > and we should work on it, the sooner the better (but after the > > existing documents). > > > We can slow-walk this draft. As you say, we need to prioritize other > drafts... Ok. /martin From nobody Mon Sep 16 12:27:36 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C87812012E for ; Mon, 16 Sep 2019 12:27:35 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 jcsooUg7PNZe for ; Mon, 16 Sep 2019 12:27:29 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C354B120131 for ; Mon, 16 Sep 2019 12:27:19 -0700 (PDT) Received: from localhost (h-46-233.A165.priv.bahnhof.se [46.59.46.233]) by mail.tail-f.com (Postfix) with ESMTPSA id 125341AE0187; Mon, 16 Sep 2019 21:27:19 +0200 (CEST) Date: Mon, 16 Sep 2019 21:27:18 +0200 (CEST) Message-Id: <20190916.212718.107254905075592848.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: zhoutianran@huawei.com, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016d3ad2b4f2-e591bc21-9b47-49a0-81df-3e8d9ca23fce-000000@email.amazonses.com> References: <0100016ccff35064-9da3c8b6-263c-47f6-a4f2-4db9495bc8b7-000000@email.amazonses.com> <0100016d3ad2b4f2-e591bc21-9b47-49a0-81df-3e8d9ca23fce-000000@email.amazonses.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2019 19:27:35 -0000 Kent Watsen wrote: > > Hi Tianran, > > > > Considering the multiple stream originator case, I would suggest this https-notif to add a channel level configuration. > > i.e. > > > > +--receivers > > +--receiver > > +--channels > > +--channel > > +--here put the http client server configurations > > > > This is compatible with the single originator case with only one channel configuration. > > We can look at this. Maybe use a choice statement between the two options... I don't think this is a good idea. But then I don't really understand the 'channel' concept. I don't understand why the client needs to be aware of these channels, but this should probably be discussed in a separate thread. /martin > > Kent // co-author > > > > > > If you do not like this, I think existing https-notif model also works. > > i.e. each receiver configuration stands for one channel. > > But this is not clear IMO. > > > > Best, > > Tianran From nobody Mon Sep 16 18:41:29 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A5E120026 for ; Mon, 16 Sep 2019 18:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 pVpSqap0x3Jr for ; Mon, 16 Sep 2019 18:41:26 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 18A6D1200D7 for ; Mon, 16 Sep 2019 18:41:26 -0700 (PDT) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 68D4B57A59ADEEA8BE95 for ; Tue, 17 Sep 2019 02:41:24 +0100 (IST) Received: from lhreml715-chm.china.huawei.com (10.201.108.66) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 17 Sep 2019 02:41:23 +0100 Received: from lhreml715-chm.china.huawei.com (10.201.108.66) by lhreml715-chm.china.huawei.com (10.201.108.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 17 Sep 2019 02:41:24 +0100 Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml715-chm.china.huawei.com (10.201.108.66) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Tue, 17 Sep 2019 02:41:23 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0439.000; Tue, 17 Sep 2019 09:41:16 +0800 From: Tianran Zhou To: Martin Bjorklund , "kent+ietf@watsen.net" CC: "netconf@ietf.org" Thread-Topic: configuring multi-channels Thread-Index: AdVs9BeNNLIBQRFAQtOat+1DuA9kNw== Date: Tue, 17 Sep 2019 01:41:16 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netconf] configuring multi-channels X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 01:41:28 -0000 Hi Martin, The channel is concept is from=20 https://datatracker.ietf.org/doc/draft-zhou-netconf-multi-stream-originator= s/ There are multiple publication channels per device/subscription. It should be better if the client is not aware of the channels. These can b= e achieved by using the UDP based publication channel as in: https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-pub-channel/ The publishers can use the same IP as the subscription channel, and use dyn= amic ports. So no per channel configurations need. For https-notif, we can consider to pre-configure all the possible/potentia= l publication channels. But the usage of which channels is decided by the d= evice dynamically during the run time. Regards, Tianran > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Tuesday, September 17, 2019 3:27 AM > To: kent+ietf@watsen.net > Cc: Tianran Zhou ; netconf@ietf.org > Subject: Re: [netconf] Adoption Call for > draft-mahesh-netconf-https-notif-00 >=20 > Kent Watsen wrote: > > > > Hi Tianran, > > > > > > > Considering the multiple stream originator case, I would suggest this > https-notif to add a channel level configuration. > > > i.e. > > > > > > +--receivers > > > +--receiver > > > +--channels > > > +--channel > > > +--here put the http client server configurations > > > > > > This is compatible with the single originator case with only one chan= nel > configuration. > > > > We can look at this. Maybe use a choice statement between the two opti= ons... >=20 > I don't think this is a good idea. But then I don't really understand th= e > 'channel' concept. I don't understand why the client needs to be aware o= f > these channels, but this should probably be discussed in a separate threa= d. >=20 >=20 > /martin >=20 >=20 > > > > Kent // co-author > > > > > > > > > > If you do not like this, I think existing https-notif model also work= s. > > > i.e. each receiver configuration stands for one channel. > > > But this is not clear IMO. > > > > > > Best, > > > Tianran From nobody Mon Sep 16 20:28:57 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4EF12006E for ; Mon, 16 Sep 2019 20:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 EtwlvnftGBfX for ; Mon, 16 Sep 2019 20:28:52 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 7E5CB12006D for ; Mon, 16 Sep 2019 20:28:52 -0700 (PDT) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 5E6F6E3FEB7C2C7AE6FC for ; Tue, 17 Sep 2019 04:28:50 +0100 (IST) Received: from lhreml727-chm.china.huawei.com (10.201.108.78) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 17 Sep 2019 04:28:50 +0100 Received: from lhreml727-chm.china.huawei.com (10.201.108.78) by lhreml727-chm.china.huawei.com (10.201.108.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 17 Sep 2019 04:28:49 +0100 Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml727-chm.china.huawei.com (10.201.108.78) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Tue, 17 Sep 2019 04:28:49 +0100 Received: from DGGEMM527-MBX.china.huawei.com ([169.254.6.177]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0439.000; Tue, 17 Sep 2019 11:28:45 +0800 From: wangzitao To: Kent Watsen CC: "netconf@ietf.org" Thread-Topic: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 Thread-Index: AdVtB/z6FCRUy5flRC6mfDV5ok21pQ== Date: Tue, 17 Sep 2019 03:28:44 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.142.117] Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EA2DAFF493DGGEMM527MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 03:28:55 -0000 --_000_E6BC9BBCBCACC246846FC685F9FF41EA2DAFF493DGGEMM527MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgS2VudCwNCg0KU2VlIG15IHJlcGx5IGlubGluZS4NCg0KQi5SLg0KLU1pY2hhZWwNCg0Kt6K8 /sjLOiBLZW50IFdhdHNlbiBbbWFpbHRvOmtlbnQraWV0ZkB3YXRzZW4ubmV0XQ0Kt6LLzcqxvOQ6 IDIwMTnE6jnUwjE3yNUgMDowMQ0KytW8/sjLOiB3YW5neml0YW8gPHdhbmd6aXRhb0BodWF3ZWku Y29tPg0Ks63LzTogbmV0Y29uZkBpZXRmLm9yZw0K1vfM4jogUmU6IFtuZXRjb25mXSBBZG9wdGlv biBDYWxsIGZvciBkcmFmdC1tYWhlc2gtbmV0Y29uZi1odHRwcy1ub3RpZi0wMA0KDQpIaSBNaWNo YWVsLA0KDQoNCkkgYW0gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhlIHJlbGF0aW9uc2hpcCBhbmQg dXNhZ2Ugb2YgdGhpcyBkcmFmdCBhbmQgYSBzZXQgb2YgbmV0Y29uZiBkcmFmdHM6DQpUaGlzIG1v ZGVsIHByZXNlbnQgdGhlIHJlY2VpdmVyJ3MgaW5mb3JtYXRpb24gKHN1Y2ggYXMgSVAsIHBvcnQs IGV0YykgYW5kIGl0IGF1Z21lbnQgdGhlIGlldGYtc3Vic2NyaXB0aW9uLW5vdGlmaWNhdGlvbiBt b2RlbCB0aGF0IHRoZSB1c2VyIGNhbiBzcGVjaWZ5IG11bHRpcGxlIHN1YnNjcmlwdGlvbiByZWNl aXZlcnMuDQpBbmQgdGhlIHVzZXIgYWxzbyBuZWVkIHRvIGNvbmZpZ3VyZSB0aGUgc2VydmVyIHRv IHNwZWNpZnkgcmVjZWl2ZXIncyBwb3J0IGFuZCBJUCAodmlhIGlldGYtY2xpZW50LXNlcnZlcj8p Lg0KDQpXaGF0IGlzICIgaWV0Zi1jbGllbnQtc2VydmVyIiA/DQpTb3JyeSwgaXQgc2hvdWxkIGJl IKGwTkVUQ09ORiBDbGllbnQgYW5kIFNlcnZlciBNb2RlbHOhsS4NCg0KVGhhdCB0aGUgc2VydmVy IGNhbiBjYWxsIGhvbWUgdG8gdGhlIHJlY2VpdmVycy4NCklzIG15IHVuZGVyc3RhbmRpbmcgY29y cmVjdD8gSWYgeWVzLCBJIHN1Z2dlc3QgdGhhdCBhIGJyaWVmIGRlc2NyaXB0aW9uIG9mIHRoZSB3 b3JrZmxvdyBzaG91bGQgYmUgcHJlc2VudCBpbiB0aGUgZHJhZnQuDQoNClRoaXMgaXMgYSBnb29k IHN1Z2dlc3Rpb24uICBXZSB3aWxsIGFkZCBhIHNlY3Rpb24gc2hvd2luZyBjb250ZXh0Lg0KDQpD b29sLg0KDQoNCktlbnQNCg0KDQoNCg0KDQpCZXN0IFJlZ2FyZHMhDQotTWljaGFlbA0KDQo= --_000_E6BC9BBCBCACC246846FC685F9FF41EA2DAFF493DGGEMM527MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Kent,

 

See my reply inline.

 

B.R.=

-Michael

 

=B7=A2=BC=FE=C8=CB: Kent Watsen [m= ailto:kent+ietf@watsen.net]
=B7=A2=CB=CD=CA=B1=BC=E4:<= /span> 2019=C4=EA9=D4=C217=C8=D5 0:01
=CA=D5=BC=FE=C8=CB: wangzitao <wangzitao@huawei.com>
=B3=AD=CB=CD: netconf@ietf.org
=D6=F7=CC=E2: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00<= /o:p>

 

Hi Michael,

 

I am trying to underst= and the relationship and usage of this draft and a set of netconf drafts:

This model present the= receiver's information (such as IP, port, etc) and it augment the ietf-sub= scription-notification model that the user can specify multiple subscription receivers.

And the user also need= to configure the server to specify receiver's port and IP (via ietf-client= -server?).

 

What is " ietf-client-serv= er" ?

Sorry, it should be =A1=B0NETCONF Client and Server Models=A1= =B1.

<= /h1>

That the server can ca= ll home to the receivers.

Is my understanding co= rrect? If yes, I suggest that a brief description of the workflow should be= present in the draft.

 

This is a good suggestion. &nbs= p;We will add a section showing context.

 

Cool.

 

 

Kent

 

 



 

Best Regards!

-Michael

 

--_000_E6BC9BBCBCACC246846FC685F9FF41EA2DAFF493DGGEMM527MBXchi_-- From nobody Mon Sep 16 23:36:03 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88CA7120098 for ; Mon, 16 Sep 2019 23:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 gHloe_snP4Se for ; Mon, 16 Sep 2019 23:36:00 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7909C12008C for ; Mon, 16 Sep 2019 23:36:00 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id D09171AE0115; Tue, 17 Sep 2019 08:35:57 +0200 (CEST) Date: Tue, 17 Sep 2019 08:35:33 +0200 (CEST) Message-Id: <20190917.083533.892234744068366075.mbj@tail-f.com> To: zhoutianran@huawei.com Cc: kent+ietf@watsen.net, netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] configuring multi-channels X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 06:36:03 -0000 Tianran Zhou wrote: > Hi Martin, > > The channel is concept is from > https://datatracker.ietf.org/doc/draft-zhou-netconf-multi-stream-originators/ > There are multiple publication channels per device/subscription. In that document, the word "channel" is present three times + one (broken) XML example. The concept of a channel needs to be explained in detail so that we can have a meaningful discussion. /martin > It should be better if the client is not aware of the > channels. These can be achieved by using the UDP based publication > channel as in: > https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-pub-channel/ > The publishers can use the same IP as the subscription channel, and > use dynamic ports. So no per channel configurations need. > > For https-notif, we can consider to pre-configure all the > possible/potential publication channels. > But the usage of which > channels is decided by the device dynamically during the run time. > > Regards, > Tianran > > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > Sent: Tuesday, September 17, 2019 3:27 AM > > To: kent+ietf@watsen.net > > Cc: Tianran Zhou ; netconf@ietf.org > > Subject: Re: [netconf] Adoption Call for > > draft-mahesh-netconf-https-notif-00 > > > > Kent Watsen wrote: > > > > > > Hi Tianran, > > > > > > > > > > Considering the multiple stream originator case, I would suggest this > > https-notif to add a channel level configuration. > > > > i.e. > > > > > > > > +--receivers > > > > +--receiver > > > > +--channels > > > > +--channel > > > > +--here put the http client server configurations > > > > > > > > This is compatible with the single originator case with only one channel > > configuration. > > > > > > We can look at this. Maybe use a choice statement between the two options... > > > > I don't think this is a good idea. But then I don't really understand the > > 'channel' concept. I don't understand why the client needs to be aware of > > these channels, but this should probably be discussed in a separate thread. > > > > > > /martin > > > > > > > > > > Kent // co-author > > > > > > > > > > > > > > If you do not like this, I think existing https-notif model also works. > > > > i.e. each receiver configuration stands for one channel. > > > > But this is not clear IMO. > > > > > > > > Best, > > > > Tianran > From nobody Mon Sep 16 23:51:06 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03128120098 for ; Mon, 16 Sep 2019 23:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 s--cgRDJVo3w for ; Mon, 16 Sep 2019 23:51:02 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 54FA912004E for ; Mon, 16 Sep 2019 23:51:02 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id AB0E7E933B53EC82BC0B for ; Tue, 17 Sep 2019 07:51:00 +0100 (IST) Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 17 Sep 2019 07:51:00 +0100 Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 17 Sep 2019 07:51:00 +0100 Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Tue, 17 Sep 2019 07:50:59 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0439.000; Tue, 17 Sep 2019 14:50:55 +0800 From: Tianran Zhou To: Martin Bjorklund CC: "kent+ietf@watsen.net" , "netconf@ietf.org" Thread-Topic: configuring multi-channels Thread-Index: AdVs9BeNNLIBQRFAQtOat+1DuA9kN///1euA//92JkA= Date: Tue, 17 Sep 2019 06:50:54 +0000 Message-ID: References: <20190917.083533.892234744068366075.mbj@tail-f.com> In-Reply-To: <20190917.083533.892234744068366075.mbj@tail-f.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] configuring multi-channels X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 06:51:05 -0000 In this document, we defined two types of publication channels: Master Publication Channel: the session between the Master Publisher and the Receiver. Agent Publication Channel: the session between the Agent Publisher and the Receiver Do you think it's enough or anything you think should be clarified? Thanks, Tianran > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Tuesday, September 17, 2019 2:36 PM > To: Tianran Zhou > Cc: kent+ietf@watsen.net; netconf@ietf.org > Subject: Re: configuring multi-channels >=20 > Tianran Zhou wrote: > > Hi Martin, > > > > The channel is concept is from > > https://datatracker.ietf.org/doc/draft-zhou-netconf-multi-stream-origi > > nators/ There are multiple publication channels per > > device/subscription. >=20 > In that document, the word "channel" is present three times + one > (broken) XML example. The concept of a channel needs to be explained in > detail so that we can have a meaningful discussion. >=20 >=20 >=20 > /martin >=20 >=20 > > It should be better if the client is not aware of the channels. These > > can be achieved by using the UDP based publication channel as in: > > https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-pub-channel/ > > The publishers can use the same IP as the subscription channel, and > > use dynamic ports. So no per channel configurations need. > > > > For https-notif, we can consider to pre-configure all the > > possible/potential publication channels. > > But the usage of which > > channels is decided by the device dynamically during the run time. >=20 >=20 >=20 >=20 > > > > Regards, > > Tianran > > > > > -----Original Message----- > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > Sent: Tuesday, September 17, 2019 3:27 AM > > > To: kent+ietf@watsen.net > > > Cc: Tianran Zhou ; netconf@ietf.org > > > Subject: Re: [netconf] Adoption Call for > > > draft-mahesh-netconf-https-notif-00 > > > > > > Kent Watsen wrote: > > > > > > > > Hi Tianran, > > > > > > > > > > > > > Considering the multiple stream originator case, I would suggest > > > > > this > > > https-notif to add a channel level configuration. > > > > > i.e. > > > > > > > > > > +--receivers > > > > > +--receiver > > > > > +--channels > > > > > +--channel > > > > > +--here put the http client server configurations > > > > > > > > > > This is compatible with the single originator case with only one > > > > > channel > > > configuration. > > > > > > > > We can look at this. Maybe use a choice statement between the two > options... > > > > > > I don't think this is a good idea. But then I don't really > > > understand the 'channel' concept. I don't understand why the client > > > needs to be aware of these channels, but this should probably be disc= ussed > in a separate thread. > > > > > > > > > /martin > > > > > > > > > > > > > > Kent // co-author > > > > > > > > > > > > > > > > > > If you do not like this, I think existing https-notif model also = works. > > > > > i.e. each receiver configuration stands for one channel. > > > > > But this is not clear IMO. > > > > > > > > > > Best, > > > > > Tianran > > From nobody Tue Sep 17 00:14:28 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19EBD1200F3 for ; Tue, 17 Sep 2019 00:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 OzkdaoXe2dVP for ; Tue, 17 Sep 2019 00:14:25 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E925C120018 for ; Tue, 17 Sep 2019 00:14:24 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id D01D61AE08F5; Tue, 17 Sep 2019 09:14:22 +0200 (CEST) Date: Tue, 17 Sep 2019 09:13:58 +0200 (CEST) Message-Id: <20190917.091358.915537665807173240.mbj@tail-f.com> To: zhoutianran@huawei.com Cc: kent+ietf@watsen.net, netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <20190917.083533.892234744068366075.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] configuring multi-channels X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 07:14:27 -0000 Tianran Zhou wrote: > In this document, we defined two types of publication channels: > Master Publication Channel: the session between the Master Publisher > and the Receiver. > Agent Publication Channel: the session between the Agent Publisher > and the Receiver > > Do you think it's enough or anything you think should be clarified? These are just names. But why does these names imply that the client has to configure anything? /martin > > Thanks, > Tianran > > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > Sent: Tuesday, September 17, 2019 2:36 PM > > To: Tianran Zhou > > Cc: kent+ietf@watsen.net; netconf@ietf.org > > Subject: Re: configuring multi-channels > > > > Tianran Zhou wrote: > > > Hi Martin, > > > > > > The channel is concept is from > > > https://datatracker.ietf.org/doc/draft-zhou-netconf-multi-stream-origi > > > nators/ There are multiple publication channels per > > > device/subscription. > > > > In that document, the word "channel" is present three times + one > > (broken) XML example. The concept of a channel needs to be explained in > > detail so that we can have a meaningful discussion. > > > > > > > > /martin > > > > > > > It should be better if the client is not aware of the channels. These > > > can be achieved by using the UDP based publication channel as in: > > > https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-pub-channel/ > > > The publishers can use the same IP as the subscription channel, and > > > use dynamic ports. So no per channel configurations need. > > > > > > For https-notif, we can consider to pre-configure all the > > > possible/potential publication channels. > > > But the usage of which > > > channels is decided by the device dynamically during the run time. > > > > > > > > > > > > > > Regards, > > > Tianran > > > > > > > -----Original Message----- > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > Sent: Tuesday, September 17, 2019 3:27 AM > > > > To: kent+ietf@watsen.net > > > > Cc: Tianran Zhou ; netconf@ietf.org > > > > Subject: Re: [netconf] Adoption Call for > > > > draft-mahesh-netconf-https-notif-00 > > > > > > > > Kent Watsen wrote: > > > > > > > > > > Hi Tianran, > > > > > > > > > > > > > > > > Considering the multiple stream originator case, I would suggest > > > > > > this > > > > https-notif to add a channel level configuration. > > > > > > i.e. > > > > > > > > > > > > +--receivers > > > > > > +--receiver > > > > > > +--channels > > > > > > +--channel > > > > > > +--here put the http client server configurations > > > > > > > > > > > > This is compatible with the single originator case with only one > > > > > > channel > > > > configuration. > > > > > > > > > > We can look at this. Maybe use a choice statement between the two > > options... > > > > > > > > I don't think this is a good idea. But then I don't really > > > > understand the 'channel' concept. I don't understand why the client > > > > needs to be aware of these channels, but this should probably be discussed > > in a separate thread. > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > Kent // co-author > > > > > > > > > > > > > > > > > > > > > > If you do not like this, I think existing https-notif model also works. > > > > > > i.e. each receiver configuration stands for one channel. > > > > > > But this is not clear IMO. > > > > > > > > > > > > Best, > > > > > > Tianran > > > > From nobody Tue Sep 17 00:56:42 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE07F120255 for ; Tue, 17 Sep 2019 00:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Bf-N9uILX3ch for ; Tue, 17 Sep 2019 00:56:31 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 0C4CF120170 for ; Tue, 17 Sep 2019 00:56:31 -0700 (PDT) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 59AFCAC7E04D6D05809F for ; Tue, 17 Sep 2019 08:56:29 +0100 (IST) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 17 Sep 2019 08:56:28 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0439.000; Tue, 17 Sep 2019 15:56:24 +0800 From: Tianran Zhou To: Martin Bjorklund CC: "kent+ietf@watsen.net" , "netconf@ietf.org" Thread-Topic: configuring multi-channels Thread-Index: AdVs9BeNNLIBQRFAQtOat+1DuA9kN///1euA//92JkCAAJSVAP//crMg Date: Tue, 17 Sep 2019 07:56:23 +0000 Message-ID: References: <20190917.083533.892234744068366075.mbj@tail-f.com> <20190917.091358.915537665807173240.mbj@tail-f.com> In-Reply-To: <20190917.091358.915537665807173240.mbj@tail-f.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] configuring multi-channels X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 07:56:42 -0000 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Tuesday, September 17, 2019 3:14 PM > To: Tianran Zhou > Cc: kent+ietf@watsen.net; netconf@ietf.org > Subject: Re: configuring multi-channels >=20 > Tianran Zhou wrote: > > In this document, we defined two types of publication channels: > > Master Publication Channel: the session between the Master Publisher > > and the Receiver. > > Agent Publication Channel: the session between the Agent Publisher > > and the Receiver > > > > Do you think it's enough or anything you think should be clarified? >=20 > These are just names. But why does these names imply that the client has > to configure anything? Several kinds of transport protocol can be used to carry data between the p= ublisher and the receiver. UDP based, TCP based. Transport like https-notif need client-server configuration. That is to say the configuration is about the transport like in draft-mahes= h-netconf-https-notif-00. Tianran > /martin >=20 >=20 >=20 > > > > Thanks, > > Tianran > > > > > -----Original Message----- > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > Sent: Tuesday, September 17, 2019 2:36 PM > > > To: Tianran Zhou > > > Cc: kent+ietf@watsen.net; netconf@ietf.org > > > Subject: Re: configuring multi-channels > > > > > > Tianran Zhou wrote: > > > > Hi Martin, > > > > > > > > The channel is concept is from > > > > https://datatracker.ietf.org/doc/draft-zhou-netconf-multi-stream-o > > > > rigi nators/ There are multiple publication channels per > > > > device/subscription. > > > > > > In that document, the word "channel" is present three times + one > > > (broken) XML example. The concept of a channel needs to be > > > explained in detail so that we can have a meaningful discussion. > > > > > > > > > > > > /martin > > > > > > > > > > It should be better if the client is not aware of the channels. > > > > These can be achieved by using the UDP based publication channel as > in: > > > > https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-pub-channe > > > > l/ The publishers can use the same IP as the subscription channel, > > > > and use dynamic ports. So no per channel configurations need. > > > > > > > > For https-notif, we can consider to pre-configure all the > > > > possible/potential publication channels. > > > > But the usage of which > > > > channels is decided by the device dynamically during the run time. > > > > > > > > > > > > > > > > > > > > Regards, > > > > Tianran > > > > > > > > > -----Original Message----- > > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > > Sent: Tuesday, September 17, 2019 3:27 AM > > > > > To: kent+ietf@watsen.net > > > > > Cc: Tianran Zhou ; netconf@ietf.org > > > > > Subject: Re: [netconf] Adoption Call for > > > > > draft-mahesh-netconf-https-notif-00 > > > > > > > > > > Kent Watsen wrote: > > > > > > > > > > > > Hi Tianran, > > > > > > > > > > > > > > > > > > > Considering the multiple stream originator case, I would > > > > > > > suggest this > > > > > https-notif to add a channel level configuration. > > > > > > > i.e. > > > > > > > > > > > > > > +--receivers > > > > > > > +--receiver > > > > > > > +--channels > > > > > > > +--channel > > > > > > > +--here put the http client server > > > > > > > configurations > > > > > > > > > > > > > > This is compatible with the single originator case with only > > > > > > > one channel > > > > > configuration. > > > > > > > > > > > > We can look at this. Maybe use a choice statement between the > > > > > > two > > > options... > > > > > > > > > > I don't think this is a good idea. But then I don't really > > > > > understand the 'channel' concept. I don't understand why the > > > > > client needs to be aware of these channels, but this should > > > > > probably be discussed > > > in a separate thread. > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > Kent // co-author > > > > > > > > > > > > > > > > > > > > > > > > > > If you do not like this, I think existing https-notif model a= lso > works. > > > > > > > i.e. each receiver configuration stands for one channel. > > > > > > > But this is not clear IMO. > > > > > > > > > > > > > > Best, > > > > > > > Tianran > > > > > > From nobody Tue Sep 17 01:28:29 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E861D1201E3 for ; Tue, 17 Sep 2019 01:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ZT78Z4seEPqr for ; Tue, 17 Sep 2019 01:28:25 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB1A120220 for ; Tue, 17 Sep 2019 01:28:25 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 1D4A91AE08F5; Tue, 17 Sep 2019 10:28:23 +0200 (CEST) Date: Tue, 17 Sep 2019 10:27:58 +0200 (CEST) Message-Id: <20190917.102758.2020337184594988909.mbj@tail-f.com> To: zhoutianran@huawei.com Cc: kent+ietf@watsen.net, netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <20190917.091358.915537665807173240.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] configuring multi-channels X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 08:28:28 -0000 Tianran Zhou wrote: > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > Sent: Tuesday, September 17, 2019 3:14 PM > > To: Tianran Zhou > > Cc: kent+ietf@watsen.net; netconf@ietf.org > > Subject: Re: configuring multi-channels > > > > Tianran Zhou wrote: > > > In this document, we defined two types of publication channels: > > > Master Publication Channel: the session between the Master Publisher > > > and the Receiver. > > > Agent Publication Channel: the session between the Agent Publisher > > > and the Receiver > > > > > > Do you think it's enough or anything you think should be clarified? > > > > These are just names. But why does these names imply that the client > > has > > to configure anything? > > Several kinds of transport protocol can be used to carry data between > the publisher and the receiver. UDP based, TCP based. > Transport like https-notif need client-server configuration. > That is to say the configuration is about the transport like in > draft-mahesh-netconf-https-notif-00. With the POST-based HTTP protocol in draft-mahesh-netconf-https-notif, why can't the agent publisher simply POST to the receiver? It is probably useful if the *server* can indicate to the client that this will/may happen, but I don't understand why the client needs to configure anything special. /martin > > Tianran > > > /martin > > > > > > > > > > > > Thanks, > > > Tianran > > > > > > > -----Original Message----- > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > Sent: Tuesday, September 17, 2019 2:36 PM > > > > To: Tianran Zhou > > > > Cc: kent+ietf@watsen.net; netconf@ietf.org > > > > Subject: Re: configuring multi-channels > > > > > > > > Tianran Zhou wrote: > > > > > Hi Martin, > > > > > > > > > > The channel is concept is from > > > > > https://datatracker.ietf.org/doc/draft-zhou-netconf-multi-stream-o > > > > > rigi nators/ There are multiple publication channels per > > > > > device/subscription. > > > > > > > > In that document, the word "channel" is present three times + one > > > > (broken) XML example. The concept of a channel needs to be > > > > explained in detail so that we can have a meaningful discussion. > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > It should be better if the client is not aware of the channels. > > > > > These can be achieved by using the UDP based publication channel as > > in: > > > > > https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-pub-channe > > > > > l/ The publishers can use the same IP as the subscription channel, > > > > > and use dynamic ports. So no per channel configurations need. > > > > > > > > > > For https-notif, we can consider to pre-configure all the > > > > > possible/potential publication channels. > > > > > But the usage of which > > > > > channels is decided by the device dynamically during the run time. > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > Tianran > > > > > > > > > > > -----Original Message----- > > > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > > > Sent: Tuesday, September 17, 2019 3:27 AM > > > > > > To: kent+ietf@watsen.net > > > > > > Cc: Tianran Zhou ; netconf@ietf.org > > > > > > Subject: Re: [netconf] Adoption Call for > > > > > > draft-mahesh-netconf-https-notif-00 > > > > > > > > > > > > Kent Watsen wrote: > > > > > > > > > > > > > > Hi Tianran, > > > > > > > > > > > > > > > > > > > > > > Considering the multiple stream originator case, I would > > > > > > > > suggest this > > > > > > https-notif to add a channel level configuration. > > > > > > > > i.e. > > > > > > > > > > > > > > > > +--receivers > > > > > > > > +--receiver > > > > > > > > +--channels > > > > > > > > +--channel > > > > > > > > +--here put the http client server > > > > > > > > configurations > > > > > > > > > > > > > > > > This is compatible with the single originator case with only > > > > > > > > one channel > > > > > > configuration. > > > > > > > > > > > > > > We can look at this. Maybe use a choice statement between the > > > > > > > two > > > > options... > > > > > > > > > > > > I don't think this is a good idea. But then I don't really > > > > > > understand the 'channel' concept. I don't understand why the > > > > > > client needs to be aware of these channels, but this should > > > > > > probably be discussed > > > > in a separate thread. > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > > > Kent // co-author > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you do not like this, I think existing https-notif model also > > works. > > > > > > > > i.e. each receiver configuration stands for one channel. > > > > > > > > But this is not clear IMO. > > > > > > > > > > > > > > > > Best, > > > > > > > > Tianran > > > > > > > > > From nobody Tue Sep 17 01:48:35 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC470120104 for ; Tue, 17 Sep 2019 01:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 DXz8BBZyAljl for ; Tue, 17 Sep 2019 01:48:31 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 48E1C12080E for ; Tue, 17 Sep 2019 01:48:31 -0700 (PDT) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id E9AB3A755D0330CD5098 for ; Tue, 17 Sep 2019 09:48:28 +0100 (IST) Received: from lhreml722-chm.china.huawei.com (10.201.108.73) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 17 Sep 2019 09:48:28 +0100 Received: from lhreml722-chm.china.huawei.com (10.201.108.73) by lhreml722-chm.china.huawei.com (10.201.108.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 17 Sep 2019 09:48:28 +0100 Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml722-chm.china.huawei.com (10.201.108.73) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Tue, 17 Sep 2019 09:48:27 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0439.000; Tue, 17 Sep 2019 16:48:22 +0800 From: Tianran Zhou To: Martin Bjorklund CC: "kent+ietf@watsen.net" , "netconf@ietf.org" Thread-Topic: configuring multi-channels Thread-Index: AdVs9BeNNLIBQRFAQtOat+1DuA9kN///1euA//92JkCAAJSVAP//crMggACh+gD//3goMA== Date: Tue, 17 Sep 2019 08:48:21 +0000 Message-ID: References: <20190917.091358.915537665807173240.mbj@tail-f.com> <20190917.102758.2020337184594988909.mbj@tail-f.com> In-Reply-To: <20190917.102758.2020337184594988909.mbj@tail-f.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] configuring multi-channels X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 08:48:34 -0000 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Tuesday, September 17, 2019 4:28 PM > To: Tianran Zhou > Cc: kent+ietf@watsen.net; netconf@ietf.org > Subject: Re: configuring multi-channels >=20 > Tianran Zhou wrote: > > > -----Original Message----- > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > Sent: Tuesday, September 17, 2019 3:14 PM > > > To: Tianran Zhou > > > Cc: kent+ietf@watsen.net; netconf@ietf.org > > > Subject: Re: configuring multi-channels > > > > > > Tianran Zhou wrote: > > > > In this document, we defined two types of publication channels: > > > > Master Publication Channel: the session between the Master Publi= sher > > > > and the Receiver. > > > > Agent Publication Channel: the session between the Agent Publish= er > > > > and the Receiver > > > > > > > > Do you think it's enough or anything you think should be clarified? > > > > > > These are just names. But why does these names imply that the > > > client has to configure anything? > > > > Several kinds of transport protocol can be used to carry data between > > the publisher and the receiver. UDP based, TCP based. > > Transport like https-notif need client-server configuration. > > That is to say the configuration is about the transport like in > > draft-mahesh-netconf-https-notif-00. >=20 > With the POST-based HTTP protocol in draft-mahesh-netconf-https-notif, wh= y > can't the agent publisher simply POST to the receiver? It is probably us= eful > if the *server* can indicate to the client that this will/may happen, but > I don't understand why the client needs to configure anything special. I agree with you. My understanding to draft-mahesh-netconf-https-notif is t= hat the configuration is on the *server* side. The configuration need to indicate both client and server information. For = example: module: ietf-https-notif +--rw receivers +--rw receiver* [name] +--rw name string +--rw tcp-params | +--rw remote-address inet:host | +--rw remote-port? inet:port-number | +--rw local-address? inet:ip-address | +--rw local-port? inet:port-number | +--rw keepalives! Include both remote and local IP. I am sorry, could you point out if there is any that mislead you. :-)=20 Best, Tianran > /martin >=20 >=20 > > > > Tianran > > > > > /martin > > > > > > > > > > > > > > > > > Thanks, > > > > Tianran > > > > > > > > > -----Original Message----- > > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > > Sent: Tuesday, September 17, 2019 2:36 PM > > > > > To: Tianran Zhou > > > > > Cc: kent+ietf@watsen.net; netconf@ietf.org > > > > > Subject: Re: configuring multi-channels > > > > > > > > > > Tianran Zhou wrote: > > > > > > Hi Martin, > > > > > > > > > > > > The channel is concept is from > > > > > > https://datatracker.ietf.org/doc/draft-zhou-netconf-multi-stre > > > > > > am-o rigi nators/ There are multiple publication channels per > > > > > > device/subscription. > > > > > > > > > > In that document, the word "channel" is present three times + > > > > > one > > > > > (broken) XML example. The concept of a channel needs to be > > > > > explained in detail so that we can have a meaningful discussion. > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > It should be better if the client is not aware of the channels. > > > > > > These can be achieved by using the UDP based publication > > > > > > channel as > > > in: > > > > > > https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-pub-ch > > > > > > anne l/ The publishers can use the same IP as the subscription > > > > > > channel, and use dynamic ports. So no per channel > > > > > > configurations need. > > > > > > > > > > > > For https-notif, we can consider to pre-configure all the > > > > > > possible/potential publication channels. > > > > > > But the usage of which > > > > > > channels is decided by the device dynamically during the run ti= me. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > Tianran > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > > > > Sent: Tuesday, September 17, 2019 3:27 AM > > > > > > > To: kent+ietf@watsen.net > > > > > > > Cc: Tianran Zhou ; netconf@ietf.org > > > > > > > Subject: Re: [netconf] Adoption Call for > > > > > > > draft-mahesh-netconf-https-notif-00 > > > > > > > > > > > > > > Kent Watsen wrote: > > > > > > > > > > > > > > > > Hi Tianran, > > > > > > > > > > > > > > > > > > > > > > > > > Considering the multiple stream originator case, I would > > > > > > > > > suggest this > > > > > > > https-notif to add a channel level configuration. > > > > > > > > > i.e. > > > > > > > > > > > > > > > > > > +--receivers > > > > > > > > > +--receiver > > > > > > > > > +--channels > > > > > > > > > +--channel > > > > > > > > > +--here put the http client server > > > > > > > > > configurations > > > > > > > > > > > > > > > > > > This is compatible with the single originator case with > > > > > > > > > only one channel > > > > > > > configuration. > > > > > > > > > > > > > > > > We can look at this. Maybe use a choice statement between > > > > > > > > the two > > > > > options... > > > > > > > > > > > > > > I don't think this is a good idea. But then I don't really > > > > > > > understand the 'channel' concept. I don't understand why > > > > > > > the client needs to be aware of these channels, but this > > > > > > > should probably be discussed > > > > > in a separate thread. > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kent // co-author > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you do not like this, I think existing https-notif > > > > > > > > > model also > > > works. > > > > > > > > > i.e. each receiver configuration stands for one channel. > > > > > > > > > But this is not clear IMO. > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > Tianran > > > > > > > > > > > > From nobody Tue Sep 17 02:05:32 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC96120104 for ; Tue, 17 Sep 2019 02:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 yYqvg35LBZyj for ; Tue, 17 Sep 2019 02:05:27 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 72B9E1200FF for ; Tue, 17 Sep 2019 02:05:27 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 3DDE31AE08F5; Tue, 17 Sep 2019 11:05:25 +0200 (CEST) Date: Tue, 17 Sep 2019 11:05:00 +0200 (CEST) Message-Id: <20190917.110500.1456377062440780828.mbj@tail-f.com> To: zhoutianran@huawei.com Cc: kent+ietf@watsen.net, netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <20190917.102758.2020337184594988909.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] configuring multi-channels X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 09:05:30 -0000 Tianran Zhou wrote: > > > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > Sent: Tuesday, September 17, 2019 4:28 PM > > To: Tianran Zhou > > Cc: kent+ietf@watsen.net; netconf@ietf.org > > Subject: Re: configuring multi-channels > > > > Tianran Zhou wrote: > > > > -----Original Message----- > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > Sent: Tuesday, September 17, 2019 3:14 PM > > > > To: Tianran Zhou > > > > Cc: kent+ietf@watsen.net; netconf@ietf.org > > > > Subject: Re: configuring multi-channels > > > > > > > > Tianran Zhou wrote: > > > > > In this document, we defined two types of publication channels: > > > > > Master Publication Channel: the session between the Master Publisher > > > > > and the Receiver. > > > > > Agent Publication Channel: the session between the Agent Publisher > > > > > and the Receiver > > > > > > > > > > Do you think it's enough or anything you think should be clarified? > > > > > > > > These are just names. But why does these names imply that the > > > > client has to configure anything? > > > > > > Several kinds of transport protocol can be used to carry data between > > > the publisher and the receiver. UDP based, TCP based. > > > Transport like https-notif need client-server configuration. > > > That is to say the configuration is about the transport like in > > > draft-mahesh-netconf-https-notif-00. > > > > With the POST-based HTTP protocol in draft-mahesh-netconf-https-notif, > > why > > can't the agent publisher simply POST to the receiver? It is probably > > useful > > if the *server* can indicate to the client that this will/may happen, > > but > > I don't understand why the client needs to configure anything special. > > I agree with you. My understanding to draft-mahesh-netconf-https-notif > is that the configuration is on the *server* side. > The configuration need to indicate both client and server > information. For example: > module: ietf-https-notif > +--rw receivers > +--rw receiver* [name] > +--rw name string > +--rw tcp-params > | +--rw remote-address inet:host > | +--rw remote-port? inet:port-number > | +--rw local-address? inet:ip-address > | +--rw local-port? inet:port-number > | +--rw keepalives! > > Include both remote and local IP. The local-address and -port are conditional on an if-feature, but I agree that this is problematic in the case that an publisher agent on a line card wants to push directly to the receiver. /martin > > I am sorry, could you point out if there is any that mislead you. :-) > > Best, > Tianran > > > > /martin > > > > > > > > > > Tianran > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > Tianran > > > > > > > > > > > -----Original Message----- > > > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > > > Sent: Tuesday, September 17, 2019 2:36 PM > > > > > > To: Tianran Zhou > > > > > > Cc: kent+ietf@watsen.net; netconf@ietf.org > > > > > > Subject: Re: configuring multi-channels > > > > > > > > > > > > Tianran Zhou wrote: > > > > > > > Hi Martin, > > > > > > > > > > > > > > The channel is concept is from > > > > > > > https://datatracker.ietf.org/doc/draft-zhou-netconf-multi-stre > > > > > > > am-o rigi nators/ There are multiple publication channels per > > > > > > > device/subscription. > > > > > > > > > > > > In that document, the word "channel" is present three times + > > > > > > one > > > > > > (broken) XML example. The concept of a channel needs to be > > > > > > explained in detail so that we can have a meaningful discussion. > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > It should be better if the client is not aware of the channels. > > > > > > > These can be achieved by using the UDP based publication > > > > > > > channel as > > > > in: > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-pub-ch > > > > > > > anne l/ The publishers can use the same IP as the subscription > > > > > > > channel, and use dynamic ports. So no per channel > > > > > > > configurations need. > > > > > > > > > > > > > > For https-notif, we can consider to pre-configure all the > > > > > > > possible/potential publication channels. > > > > > > > But the usage of which > > > > > > > channels is decided by the device dynamically during the run time. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > Tianran > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > > > > > Sent: Tuesday, September 17, 2019 3:27 AM > > > > > > > > To: kent+ietf@watsen.net > > > > > > > > Cc: Tianran Zhou ; netconf@ietf.org > > > > > > > > Subject: Re: [netconf] Adoption Call for > > > > > > > > draft-mahesh-netconf-https-notif-00 > > > > > > > > > > > > > > > > Kent Watsen wrote: > > > > > > > > > > > > > > > > > > Hi Tianran, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Considering the multiple stream originator case, I would > > > > > > > > > > suggest this > > > > > > > > https-notif to add a channel level configuration. > > > > > > > > > > i.e. > > > > > > > > > > > > > > > > > > > > +--receivers > > > > > > > > > > +--receiver > > > > > > > > > > +--channels > > > > > > > > > > +--channel > > > > > > > > > > +--here put the http client server > > > > > > > > > > configurations > > > > > > > > > > > > > > > > > > > > This is compatible with the single originator case with > > > > > > > > > > only one channel > > > > > > > > configuration. > > > > > > > > > > > > > > > > > > We can look at this. Maybe use a choice statement between > > > > > > > > > the two > > > > > > options... > > > > > > > > > > > > > > > > I don't think this is a good idea. But then I don't really > > > > > > > > understand the 'channel' concept. I don't understand why > > > > > > > > the client needs to be aware of these channels, but this > > > > > > > > should probably be discussed > > > > > > in a separate thread. > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kent // co-author > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you do not like this, I think existing https-notif > > > > > > > > > > model also > > > > works. > > > > > > > > > > i.e. each receiver configuration stands for one channel. > > > > > > > > > > But this is not clear IMO. > > > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > > Tianran > > > > > > > > > > > > > > > > From nobody Tue Sep 17 02:18:11 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B44A12082A for ; Tue, 17 Sep 2019 02:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 kD0XKXTzerGZ for ; Tue, 17 Sep 2019 02:17:59 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 E0D9D120839 for ; Tue, 17 Sep 2019 02:17:58 -0700 (PDT) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id D5CE78B11C04CD698C7A for ; Tue, 17 Sep 2019 10:17:56 +0100 (IST) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 17 Sep 2019 10:17:27 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0439.000; Tue, 17 Sep 2019 17:17:23 +0800 From: Tianran Zhou To: Martin Bjorklund CC: "kent+ietf@watsen.net" , "netconf@ietf.org" Thread-Topic: configuring multi-channels Thread-Index: AdVs9BeNNLIBQRFAQtOat+1DuA9kN///1euA//92JkCAAJSVAP//crMggACh+gD//3goMAASRjAA//94jtA= Date: Tue, 17 Sep 2019 09:17:22 +0000 Message-ID: References: <20190917.102758.2020337184594988909.mbj@tail-f.com> <20190917.110500.1456377062440780828.mbj@tail-f.com> In-Reply-To: <20190917.110500.1456377062440780828.mbj@tail-f.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] configuring multi-channels X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 09:18:10 -0000 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Tuesday, September 17, 2019 5:05 PM > To: Tianran Zhou > Cc: kent+ietf@watsen.net; netconf@ietf.org > Subject: Re: configuring multi-channels >=20 > Tianran Zhou wrote: > > > > > > > -----Original Message----- > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > Sent: Tuesday, September 17, 2019 4:28 PM > > > To: Tianran Zhou > > > Cc: kent+ietf@watsen.net; netconf@ietf.org > > > Subject: Re: configuring multi-channels > > > > > > Tianran Zhou wrote: > > > > > -----Original Message----- > > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > > Sent: Tuesday, September 17, 2019 3:14 PM > > > > > To: Tianran Zhou > > > > > Cc: kent+ietf@watsen.net; netconf@ietf.org > > > > > Subject: Re: configuring multi-channels > > > > > > > > > > Tianran Zhou wrote: > > > > > > In this document, we defined two types of publication channels: > > > > > > Master Publication Channel: the session between the Master > Publisher > > > > > > and the Receiver. > > > > > > Agent Publication Channel: the session between the Agent > Publisher > > > > > > and the Receiver > > > > > > > > > > > > Do you think it's enough or anything you think should be clarif= ied? > > > > > > > > > > These are just names. But why does these names imply that the > > > > > client has to configure anything? > > > > > > > > Several kinds of transport protocol can be used to carry data > > > > between the publisher and the receiver. UDP based, TCP based. > > > > Transport like https-notif need client-server configuration. > > > > That is to say the configuration is about the transport like in > > > > draft-mahesh-netconf-https-notif-00. > > > > > > With the POST-based HTTP protocol in > > > draft-mahesh-netconf-https-notif, why can't the agent publisher > > > simply POST to the receiver? It is probably useful if the *server* > > > can indicate to the client that this will/may happen, but I don't > > > understand why the client needs to configure anything special. > > > > I agree with you. My understanding to draft-mahesh-netconf-https-notif > > is that the configuration is on the *server* side. > > The configuration need to indicate both client and server information. > > For example: > > module: ietf-https-notif > > +--rw receivers > > +--rw receiver* [name] > > +--rw name string > > +--rw tcp-params > > | +--rw remote-address inet:host > > | +--rw remote-port? inet:port-number > > | +--rw local-address? inet:ip-address > > | +--rw local-port? inet:port-number > > | +--rw keepalives! > > > > Include both remote and local IP. >=20 > The local-address and -port are conditional on an if-feature, but I agree > that this is problematic in the case that an publisher agent on a line ca= rd > wants to push directly to the receiver. Right. Thanks for your clarification. So for TCP based transports, we have to preconfigure all the potential loca= l-remote pairs, aka the channel information in my words:-), on the server. For each subscription, the device can decide which set of publishers to ser= ve. Thanks, Tianran > /martin >=20 >=20 > > > > I am sorry, could you point out if there is any that mislead you. :-) > > > > Best, > > Tianran > > > > > > > /martin > > > > > > > > > > > > > > Tianran > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > Tianran > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > > > > Sent: Tuesday, September 17, 2019 2:36 PM > > > > > > > To: Tianran Zhou > > > > > > > Cc: kent+ietf@watsen.net; netconf@ietf.org > > > > > > > Subject: Re: configuring multi-channels > > > > > > > > > > > > > > Tianran Zhou wrote: > > > > > > > > Hi Martin, > > > > > > > > > > > > > > > > The channel is concept is from > > > > > > > > https://datatracker.ietf.org/doc/draft-zhou-netconf-multi- > > > > > > > > stre am-o rigi nators/ There are multiple publication > > > > > > > > channels per device/subscription. > > > > > > > > > > > > > > In that document, the word "channel" is present three times > > > > > > > + one > > > > > > > (broken) XML example. The concept of a channel needs to be > > > > > > > explained in detail so that we can have a meaningful discussi= on. > > > > > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > It should be better if the client is not aware of the chann= els. > > > > > > > > These can be achieved by using the UDP based publication > > > > > > > > channel as > > > > > in: > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-pu > > > > > > > > b-ch anne l/ The publishers can use the same IP as the > > > > > > > > subscription channel, and use dynamic ports. So no per > > > > > > > > channel configurations need. > > > > > > > > > > > > > > > > For https-notif, we can consider to pre-configure all the > > > > > > > > possible/potential publication channels. > > > > > > > > But the usage of which > > > > > > > > channels is decided by the device dynamically during the ru= n > time. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > Tianran > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > > > > > > Sent: Tuesday, September 17, 2019 3:27 AM > > > > > > > > > To: kent+ietf@watsen.net > > > > > > > > > Cc: Tianran Zhou ; > > > > > > > > > netconf@ietf.org > > > > > > > > > Subject: Re: [netconf] Adoption Call for > > > > > > > > > draft-mahesh-netconf-https-notif-00 > > > > > > > > > > > > > > > > > > Kent Watsen wrote: > > > > > > > > > > > > > > > > > > > > Hi Tianran, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Considering the multiple stream originator case, I > > > > > > > > > > > would suggest this > > > > > > > > > https-notif to add a channel level configuration. > > > > > > > > > > > i.e. > > > > > > > > > > > > > > > > > > > > > > +--receivers > > > > > > > > > > > +--receiver > > > > > > > > > > > +--channels > > > > > > > > > > > +--channel > > > > > > > > > > > +--here put the http client server > > > > > > > > > > > configurations > > > > > > > > > > > > > > > > > > > > > > This is compatible with the single originator case > > > > > > > > > > > with only one channel > > > > > > > > > configuration. > > > > > > > > > > > > > > > > > > > > We can look at this. Maybe use a choice statement > > > > > > > > > > between the two > > > > > > > options... > > > > > > > > > > > > > > > > > > I don't think this is a good idea. But then I don't > > > > > > > > > really understand the 'channel' concept. I don't > > > > > > > > > understand why the client needs to be aware of these > > > > > > > > > channels, but this should probably be discussed > > > > > > > in a separate thread. > > > > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kent // co-author > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you do not like this, I think existing > > > > > > > > > > > https-notif model also > > > > > works. > > > > > > > > > > > i.e. each receiver configuration stands for one chann= el. > > > > > > > > > > > But this is not clear IMO. > > > > > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > > > Tianran > > > > > > > > > > > > > > > > > > > > From nobody Tue Sep 17 02:58:43 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8514C120804 for ; Tue, 17 Sep 2019 02:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 UQl0FIFLYpVd for ; Tue, 17 Sep 2019 02:58:38 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D028412080A for ; Tue, 17 Sep 2019 02:58:37 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 0032F1AE08F5; Tue, 17 Sep 2019 11:58:34 +0200 (CEST) Date: Tue, 17 Sep 2019 11:58:08 +0200 (CEST) Message-Id: <20190917.115808.1894012459057925338.mbj@tail-f.com> To: zhoutianran@huawei.com Cc: kent+ietf@watsen.net, netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <20190917.110500.1456377062440780828.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] configuring multi-channels X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 09:58:41 -0000 Tianran Zhou wrote: > > > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > Sent: Tuesday, September 17, 2019 5:05 PM > > To: Tianran Zhou > > Cc: kent+ietf@watsen.net; netconf@ietf.org > > Subject: Re: configuring multi-channels > > > > Tianran Zhou wrote: > > > > > > > > > > -----Original Message----- > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > Sent: Tuesday, September 17, 2019 4:28 PM > > > > To: Tianran Zhou > > > > Cc: kent+ietf@watsen.net; netconf@ietf.org > > > > Subject: Re: configuring multi-channels > > > > > > > > Tianran Zhou wrote: > > > > > > -----Original Message----- > > > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > > > Sent: Tuesday, September 17, 2019 3:14 PM > > > > > > To: Tianran Zhou > > > > > > Cc: kent+ietf@watsen.net; netconf@ietf.org > > > > > > Subject: Re: configuring multi-channels > > > > > > > > > > > > Tianran Zhou wrote: > > > > > > > In this document, we defined two types of publication channels: > > > > > > > Master Publication Channel: the session between the Master > > Publisher > > > > > > > and the Receiver. > > > > > > > Agent Publication Channel: the session between the Agent > > Publisher > > > > > > > and the Receiver > > > > > > > > > > > > > > Do you think it's enough or anything you think should be clarified? > > > > > > > > > > > > These are just names. But why does these names imply that the > > > > > > client has to configure anything? > > > > > > > > > > Several kinds of transport protocol can be used to carry data > > > > > between the publisher and the receiver. UDP based, TCP based. > > > > > Transport like https-notif need client-server configuration. > > > > > That is to say the configuration is about the transport like in > > > > > draft-mahesh-netconf-https-notif-00. > > > > > > > > With the POST-based HTTP protocol in > > > > draft-mahesh-netconf-https-notif, why can't the agent publisher > > > > simply POST to the receiver? It is probably useful if the *server* > > > > can indicate to the client that this will/may happen, but I don't > > > > understand why the client needs to configure anything special. > > > > > > I agree with you. My understanding to draft-mahesh-netconf-https-notif > > > is that the configuration is on the *server* side. > > > The configuration need to indicate both client and server information. > > > For example: > > > module: ietf-https-notif > > > +--rw receivers > > > +--rw receiver* [name] > > > +--rw name string > > > +--rw tcp-params > > > | +--rw remote-address inet:host > > > | +--rw remote-port? inet:port-number > > > | +--rw local-address? inet:ip-address > > > | +--rw local-port? inet:port-number > > > | +--rw keepalives! > > > > > > Include both remote and local IP. > > > > The local-address and -port are conditional on an if-feature, but I agree > > that this is problematic in the case that an publisher agent on a line card > > wants to push directly to the receiver. > > Right. Thanks for your clarification. > So for TCP based transports, we have to preconfigure all the > potential local-remote pairs, aka the channel information in my > words:-), on the server. No I don't think that's the (correct) solution. Why is it important to configure this at all? /martin > For each subscription, the device can decide which set of publishers to serve. > > Thanks, > Tianran > > > /martin > > > > > > > > > > I am sorry, could you point out if there is any that mislead you. :-) > > > > > > Best, > > > Tianran > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > Tianran > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > Tianran > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > > > > > Sent: Tuesday, September 17, 2019 2:36 PM > > > > > > > > To: Tianran Zhou > > > > > > > > Cc: kent+ietf@watsen.net; netconf@ietf.org > > > > > > > > Subject: Re: configuring multi-channels > > > > > > > > > > > > > > > > Tianran Zhou wrote: > > > > > > > > > Hi Martin, > > > > > > > > > > > > > > > > > > The channel is concept is from > > > > > > > > > https://datatracker.ietf.org/doc/draft-zhou-netconf-multi- > > > > > > > > > stre am-o rigi nators/ There are multiple publication > > > > > > > > > channels per device/subscription. > > > > > > > > > > > > > > > > In that document, the word "channel" is present three times > > > > > > > > + one > > > > > > > > (broken) XML example. The concept of a channel needs to be > > > > > > > > explained in detail so that we can have a meaningful discussion. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > > It should be better if the client is not aware of the channels. > > > > > > > > > These can be achieved by using the UDP based publication > > > > > > > > > channel as > > > > > > in: > > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-netconf-udp-pu > > > > > > > > > b-ch anne l/ The publishers can use the same IP as the > > > > > > > > > subscription channel, and use dynamic ports. So no per > > > > > > > > > channel configurations need. > > > > > > > > > > > > > > > > > > For https-notif, we can consider to pre-configure all the > > > > > > > > > possible/potential publication channels. > > > > > > > > > But the usage of which > > > > > > > > > channels is decided by the device dynamically during the run > > time. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > Tianran > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > > > > > > > Sent: Tuesday, September 17, 2019 3:27 AM > > > > > > > > > > To: kent+ietf@watsen.net > > > > > > > > > > Cc: Tianran Zhou ; > > > > > > > > > > netconf@ietf.org > > > > > > > > > > Subject: Re: [netconf] Adoption Call for > > > > > > > > > > draft-mahesh-netconf-https-notif-00 > > > > > > > > > > > > > > > > > > > > Kent Watsen wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Tianran, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Considering the multiple stream originator case, I > > > > > > > > > > > > would suggest this > > > > > > > > > > https-notif to add a channel level configuration. > > > > > > > > > > > > i.e. > > > > > > > > > > > > > > > > > > > > > > > > +--receivers > > > > > > > > > > > > +--receiver > > > > > > > > > > > > +--channels > > > > > > > > > > > > +--channel > > > > > > > > > > > > +--here put the http client server > > > > > > > > > > > > configurations > > > > > > > > > > > > > > > > > > > > > > > > This is compatible with the single originator case > > > > > > > > > > > > with only one channel > > > > > > > > > > configuration. > > > > > > > > > > > > > > > > > > > > > > We can look at this. Maybe use a choice statement > > > > > > > > > > > between the two > > > > > > > > options... > > > > > > > > > > > > > > > > > > > > I don't think this is a good idea. But then I don't > > > > > > > > > > really understand the 'channel' concept. I don't > > > > > > > > > > understand why the client needs to be aware of these > > > > > > > > > > channels, but this should probably be discussed > > > > > > > > in a separate thread. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kent // co-author > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you do not like this, I think existing > > > > > > > > > > > > https-notif model also > > > > > > works. > > > > > > > > > > > > i.e. each receiver configuration stands for one channel. > > > > > > > > > > > > But this is not clear IMO. > > > > > > > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > > > > Tianran > > > > > > > > > > > > > > > > > > > > > > > > > From nobody Tue Sep 17 03:06:18 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC6B12080E for ; Tue, 17 Sep 2019 03:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 4p4RI5L8bIYx for ; Tue, 17 Sep 2019 03:06:14 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 3C17F12080A for ; Tue, 17 Sep 2019 03:06:14 -0700 (PDT) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 9A8093F79FE53602F33E for ; Tue, 17 Sep 2019 11:06:12 +0100 (IST) Received: from lhreml715-chm.china.huawei.com (10.201.108.66) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 17 Sep 2019 11:06:12 +0100 Received: from lhreml715-chm.china.huawei.com (10.201.108.66) by lhreml715-chm.china.huawei.com (10.201.108.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 17 Sep 2019 11:06:12 +0100 Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml715-chm.china.huawei.com (10.201.108.66) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Tue, 17 Sep 2019 11:06:11 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0439.000; Tue, 17 Sep 2019 18:06:04 +0800 From: Tianran Zhou To: Martin Bjorklund CC: "kent+ietf@watsen.net" , "netconf@ietf.org" Thread-Topic: configuring multi-channels Thread-Index: AdVs9BeNNLIBQRFAQtOat+1DuA9kN///1euA//92JkCAAJSVAP//crMggACh+gD//3goMAASRjAA//94jtD//2m1AP/+TBRw Date: Tue, 17 Sep 2019 10:06:03 +0000 Message-ID: References: <20190917.110500.1456377062440780828.mbj@tail-f.com> <20190917.115808.1894012459057925338.mbj@tail-f.com> In-Reply-To: <20190917.115808.1894012459057925338.mbj@tail-f.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] configuring multi-channels X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 10:06:17 -0000 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Tuesday, September 17, 2019 5:58 PM > To: Tianran Zhou > Cc: kent+ietf@watsen.net; netconf@ietf.org > Subject: Re: configuring multi-channels >=20 > Tianran Zhou wrote: > > > > > > > -----Original Message----- > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > Sent: Tuesday, September 17, 2019 5:05 PM > > > To: Tianran Zhou > > > Cc: kent+ietf@watsen.net; netconf@ietf.org > > > Subject: Re: configuring multi-channels > > > > > > Tianran Zhou wrote: > > > > > > > > > > > > > -----Original Message----- > > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > > Sent: Tuesday, September 17, 2019 4:28 PM > > > > > To: Tianran Zhou > > > > > Cc: kent+ietf@watsen.net; netconf@ietf.org > > > > > Subject: Re: configuring multi-channels > > > > > > > > > > Tianran Zhou wrote: > > > > > > > -----Original Message----- > > > > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > > > > Sent: Tuesday, September 17, 2019 3:14 PM > > > > > > > To: Tianran Zhou > > > > > > > Cc: kent+ietf@watsen.net; netconf@ietf.org > > > > > > > Subject: Re: configuring multi-channels > > > > > > > > > > > > > > Tianran Zhou wrote: > > > > > > > > In this document, we defined two types of publication chann= els: > > > > > > > > Master Publication Channel: the session between the > > > > > > > > Master > > > Publisher > > > > > > > > and the Receiver. > > > > > > > > Agent Publication Channel: the session between the > > > > > > > > Agent > > > Publisher > > > > > > > > and the Receiver > > > > > > > > > > > > > > > > Do you think it's enough or anything you think should be cl= arified? > > > > > > > > > > > > > > These are just names. But why does these names imply that > > > > > > > the client has to configure anything? > > > > > > > > > > > > Several kinds of transport protocol can be used to carry data > > > > > > between the publisher and the receiver. UDP based, TCP based. > > > > > > Transport like https-notif need client-server configuration. > > > > > > That is to say the configuration is about the transport like > > > > > > in draft-mahesh-netconf-https-notif-00. > > > > > > > > > > With the POST-based HTTP protocol in > > > > > draft-mahesh-netconf-https-notif, why can't the agent publisher > > > > > simply POST to the receiver? It is probably useful if the > > > > > *server* can indicate to the client that this will/may happen, > > > > > but I don't understand why the client needs to configure anything > special. > > > > > > > > I agree with you. My understanding to > > > > draft-mahesh-netconf-https-notif is that the configuration is on th= e > *server* side. > > > > The configuration need to indicate both client and server informati= on. > > > > For example: > > > > module: ietf-https-notif > > > > +--rw receivers > > > > +--rw receiver* [name] > > > > +--rw name string > > > > +--rw tcp-params > > > > | +--rw remote-address inet:host > > > > | +--rw remote-port? inet:port-number > > > > | +--rw local-address? inet:ip-address > > > > | +--rw local-port? inet:port-number > > > > | +--rw keepalives! > > > > > > > > Include both remote and local IP. > > > > > > The local-address and -port are conditional on an if-feature, but I > > > agree that this is problematic in the case that an publisher agent > > > on a line card wants to push directly to the receiver. > > > > Right. Thanks for your clarification. > > So for TCP based transports, we have to preconfigure all the potential > > local-remote pairs, aka the channel information in my words:-), on the > > server. >=20 > No I don't think that's the (correct) solution. Why is it important to > configure this at all? Then, could you give any hint on the correct solution in your mind? What configuration should be avoided in an idea solution? Thanks, Tianran >=20 > /martin >=20 >=20 > > For each subscription, the device can decide which set of publishers to > serve. > > > > Thanks, > > Tianran > > > > > /martin > > > > > > > > > > > > > > I am sorry, could you point out if there is any that mislead you. > > > > :-) > > > > > > > > Best, > > > > Tianran > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > Tianran > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Tianran > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > > > > > > Sent: Tuesday, September 17, 2019 2:36 PM > > > > > > > > > To: Tianran Zhou > > > > > > > > > Cc: kent+ietf@watsen.net; netconf@ietf.org > > > > > > > > > Subject: Re: configuring multi-channels > > > > > > > > > > > > > > > > > > Tianran Zhou wrote: > > > > > > > > > > Hi Martin, > > > > > > > > > > > > > > > > > > > > The channel is concept is from > > > > > > > > > > https://datatracker.ietf.org/doc/draft-zhou-netconf-mu > > > > > > > > > > lti- stre am-o rigi nators/ There are multiple > > > > > > > > > > publication channels per device/subscription. > > > > > > > > > > > > > > > > > > In that document, the word "channel" is present three > > > > > > > > > times > > > > > > > > > + one > > > > > > > > > (broken) XML example. The concept of a channel needs to > > > > > > > > > be explained in detail so that we can have a meaningful > discussion. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > It should be better if the client is not aware of the c= hannels. > > > > > > > > > > These can be achieved by using the UDP based > > > > > > > > > > publication channel as > > > > > > > in: > > > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-netconf-ud > > > > > > > > > > p-pu b-ch anne l/ The publishers can use the same IP > > > > > > > > > > as the subscription channel, and use dynamic ports. So > > > > > > > > > > no per channel configurations need. > > > > > > > > > > > > > > > > > > > > For https-notif, we can consider to pre-configure all > > > > > > > > > > the possible/potential publication channels. > > > > > > > > > > But the usage of which channels is decided by the > > > > > > > > > > device dynamically during the run > > > time. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Tianran > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > > > > > > > > Sent: Tuesday, September 17, 2019 3:27 AM > > > > > > > > > > > To: kent+ietf@watsen.net > > > > > > > > > > > Cc: Tianran Zhou ; > > > > > > > > > > > netconf@ietf.org > > > > > > > > > > > Subject: Re: [netconf] Adoption Call for > > > > > > > > > > > draft-mahesh-netconf-https-notif-00 > > > > > > > > > > > > > > > > > > > > > > Kent Watsen wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi Tianran, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Considering the multiple stream originator case, > > > > > > > > > > > > > I would suggest this > > > > > > > > > > > https-notif to add a channel level configuration. > > > > > > > > > > > > > i.e. > > > > > > > > > > > > > > > > > > > > > > > > > > +--receivers > > > > > > > > > > > > > +--receiver > > > > > > > > > > > > > +--channels > > > > > > > > > > > > > +--channel > > > > > > > > > > > > > +--here put the http client server > > > > > > > > > > > > > configurations > > > > > > > > > > > > > > > > > > > > > > > > > > This is compatible with the single originator > > > > > > > > > > > > > case with only one channel > > > > > > > > > > > configuration. > > > > > > > > > > > > > > > > > > > > > > > > We can look at this. Maybe use a choice statement > > > > > > > > > > > > between the two > > > > > > > > > options... > > > > > > > > > > > > > > > > > > > > > > I don't think this is a good idea. But then I don't > > > > > > > > > > > really understand the 'channel' concept. I don't > > > > > > > > > > > understand why the client needs to be aware of these > > > > > > > > > > > channels, but this should probably be discussed > > > > > > > > > in a separate thread. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kent // co-author > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you do not like this, I think existing > > > > > > > > > > > > > https-notif model also > > > > > > > works. > > > > > > > > > > > > > i.e. each receiver configuration stands for one c= hannel. > > > > > > > > > > > > > But this is not clear IMO. > > > > > > > > > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > Tianran > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From nobody Tue Sep 17 03:10:59 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF84412080F for ; Tue, 17 Sep 2019 03:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=i+IXzA1e; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0j8OE5JT 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 n0TGcyBUJovB for ; Tue, 17 Sep 2019 03:10:54 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81CDD12080A for ; Tue, 17 Sep 2019 03:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33622; q=dns/txt; s=iport; t=1568715054; x=1569924654; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=13uQTxHo46S9OdzlY+CyVU5iQycikRWyfgNB95UfEzg=; b=i+IXzA1eIAJ2cmswIVCrQtjnjwxFuWCixYMcIVEsLAVAgXrBSN9sbGvx E5ZFa50jKo1kLDDtmuYG8b1E1glHlf/Pi9fATzrLmd1Hpg8b+E9HlzKAd wkkxr1RklMFNSQUsFphmQhTGWeanUtrPEetNMRTRDhUPDAyGDsJXnv7t1 c=; IronPort-PHdr: =?us-ascii?q?9a23=3AJofsdRyNRCGYtw3XCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhSN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZufFkz/MPnsRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAADmsIBd/4ENJK1bAQkaAQEBAQE?= =?us-ascii?q?CAQEBAQcCAQEBAYFUBAEBAQELAYEVLyQsA21WIAQLKgqEF4NHA4pyglyJZYk?= =?us-ascii?q?khGmBLoEkA1QJAQEBDAEBLQIBAYQ/AheCWyM1CA4CAwkBAQQBAQECAQUEbYU?= =?us-ascii?q?uDIVKAQEBBBIRChMBATcBDwIBCBEEAQEhCgICAh8RHQgCBA4FCBqDAYEdTQM?= =?us-ascii?q?dAQKiKgKBOIhhc4Eygn0BAQWFEg0LghcJgTQBijSBQxiBQD+BV4FOfj6CGoF?= =?us-ascii?q?/ASwVgnQygiaPUYUlJJcYQQqCIokVh2yEG5kamB6OcAIEAgQFAg4BAQWBVAM?= =?us-ascii?q?zgVhwFYMngkILAReDT4pTc4EpjioBgSIBAQ?= X-IronPort-AV: E=Sophos;i="5.64,516,1559520000"; d="scan'208,217";a="635324889" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Sep 2019 10:10:34 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x8HAAYpr029625 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Sep 2019 10:10:34 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 17 Sep 2019 05:10:33 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 17 Sep 2019 05:10:33 -0500 Received: from NAM04-CO1-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.1473.3 via Frontend Transport; Tue, 17 Sep 2019 06:10:33 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bQvE7jYlvr87OamNjc05GZDKe6OKpo1fVwoawrZ5jhqsQMpP9ZPhbTmM2KyreY0npLbavaeHVkqE+0wxEyqHp80M7apAF0i7otYV8k/0e3mJh3kCsS/z8bivDnJxz/Zz5/WnBuvrZzqJGX4dDNS0lSIZyJSY9NW4KnsTUkcflrIpsP5bzeyuHiRXxsXwJS+9b0WNZ8zfG76feWJjeI6eUEs8gpbhsyYBwlljk84ZeVuL1KWPKZNnN8kmlcENigmMh8HOaJyaXvz92gRjSAQBt0hngJ/Vt5JtCAFdhkM0vdTo79lu9mCvN6o1y5HxjkE/ROSnkEBC8qaZzd26PwQSgA== 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=13uQTxHo46S9OdzlY+CyVU5iQycikRWyfgNB95UfEzg=; b=lESdaacQjK1WB7hM3psIl9V5zgs0GtC8DbtqCbEXNTSkKyrnwrsC83EKYJKStOAMbF8dLI/u7oF8rBspL/PFXvL06qH2rpGjhGyzrHdYuF5H7azV3LWU298n9cSM2qAEgulRZ014A2IRbFZj8oLt1Qyadx/CxNtq1TuNzg/Bj4H84X1GISLSVbpGDIzfEewvytvwQ1Or99H40t7TMGepsSRKbP+Ew0GBQBmhsR7TmdWFyWnhD4pG6GewT3BnCb/8CxqINVXXC55y1/tBIhJQn11YmM1+q8HNZQHqfmcS7vYybrhjMPKTZi5CcwTJa/cozXe6g4LgIog/9gJpNm8rNA== 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=13uQTxHo46S9OdzlY+CyVU5iQycikRWyfgNB95UfEzg=; b=0j8OE5JTangCsd0OVuJVPjciLoDQ9b1lyhh4aqHfWbDexXF2AiDartPPym8phjc21fXGepz+Ll2f/iwp72zR9F4q+hLcR6YP9oErJHIewHfxNiY620e/zmKIb50JaCSFz/+aA5ZQjx8PdaMI88T59x605XveP/2pJYAtct6coWw= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3933.namprd11.prod.outlook.com (10.255.180.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.20; Tue, 17 Sep 2019 10:10:32 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6%7]) with mapi id 15.20.2263.023; Tue, 17 Sep 2019 10:10:32 +0000 From: "Rob Wilton (rwilton)" To: Kent Watsen CC: "netconf@ietf.org" , Russ Housley , Rifaat Shekh-Yusef , "Sean Turner" Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxVu0aQE+n/K0iPwVgOy8FH/KcpQIdQgAVLFQCAARKfAA== Date: Tue, 17 Sep 2019 10:10:31 +0000 Message-ID: References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@email.amazonses.com> In-Reply-To: <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [173.38.220.61] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d6ffb689-bd87-4c82-2a70-08d73b57461f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB3933; x-ms-traffictypediagnostic: MN2PR11MB3933: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01630974C0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(4636009)(396003)(39860400002)(136003)(346002)(376002)(366004)(51444003)(199004)(54094003)(189003)(66556008)(8936002)(476003)(2906002)(71190400001)(86362001)(486006)(25786009)(71200400001)(14444005)(256004)(66446008)(6436002)(54906003)(55016002)(9686003)(229853002)(316002)(54896002)(33656002)(64756008)(66476007)(4326008)(81156014)(66946007)(76116006)(6306002)(8676002)(81166006)(7696005)(478600001)(7736002)(446003)(74316002)(99286004)(52536014)(66066001)(186003)(9326002)(6246003)(11346002)(102836004)(3846002)(5660300002)(790700001)(6506007)(53546011)(26005)(14454004)(6116002)(76176011)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3933; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: MMwBLfMegA44jVKs9FQCYhiDoImkDmkoUL2bDVOO+NRnlthYm87+l476X1y27t2K3YkCuiSIg7LPCWHcwQbkwjvl9aVAmYZ2C2SbhHE8nHnEx5LeggWgN84Yz0N0sGS+79NPYhoUZpCc3AY3oZs1hF9/n6lQlskTJ9urVlHXK+DoagxAqeJ7iFHiuNWWuu+Q+8BG4ID9JCjl8qrpQr0ClHFNGnHLU87a4gnlNvlfdAl3J9G+DmSAkRQRa2RCVPOv2GnOmWswjdMcUOdj1UkE60rtLGpoWRC4PfI6OX0lvfMc4ddbAIlElkp7plRK9dJXP2OnawjdE6C2YyaIQj7JEJydkUYbWLtqByxrouQWJpkhqwLnaKj9OML9PSlycW4Vq0ZNPgDTS4vpw/3PIYZD3CN6lJM+z7BYDOeGuHj5Czg= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366F63419F6BD4EF106766FB58F0MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d6ffb689-bd87-4c82-2a70-08d73b57461f X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2019 10:10:31.9006 (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: vvLDuOI/f4ETtGy0DgBVwdwNyYnpnQRCVbJbErxxYAh+/mSOYfsMrWzB/JMP6YUXOD3qP62EG3ha7JfinHECqw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3933 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 10:10:58 -0000 --_000_MN2PR11MB4366F63419F6BD4EF106766FB58F0MN2PR11MB4366namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2VudCwNCg0KRnJvbTogS2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0Pg0KU2Vu dDogMTYgU2VwdGVtYmVyIDIwMTkgMTc6NDkNClRvOiBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndp bHRvbkBjaXNjby5jb20+DQpDYzogbmV0Y29uZkBpZXRmLm9yZzsgUnVzcyBIb3VzbGV5IDxob3Vz bGV5QHZpZ2lsc2VjLmNvbT47IFJpZmFhdCBTaGVraC1ZdXNlZiA8cmlmYWF0LmlldGZAZ21haWwu Y29tPjsgU2VhbiBUdXJuZXIgPHNlYW5Ac24zcmQuY29tPg0KU3ViamVjdDogUmU6IFtuZXRjb25m XSBjcnlwdG8tdHlwZXMgZmFsbGJhY2sgc3RyYXRlZ3kNCg0KDQpIaSBSb2IsDQoNCg0KDQoNCjEu ICAgICAgSSB0aGluayB0aGF0IHVzaW5nIGEgbnVtZXJpY2FsIE9JRCB0byBpZGVudGlmeSBjcnlw dG8gYWxnb3JpdGhtcyBkb2VzbuKAmXQgc2VlbSBsaWtlIGEgZ3JlYXQgY2hvaWNlLiAgU2VlaW5n IGEgY29uZmlnIGZpbGUgc2F5IHNvbWV0aGluZyBsaWtlIOKAnHJzYUVuY3J5cHRpb27igJ0gaW5z dGVhZCBvZiBzb21lIE9JRCBzdHJpbmcgc2VlbXMgdG8gYmUgbXVjaCBtb3JlIGh1bWFuIGZyaWVu ZGx5LiAgQW5kIGFzIE1hcnRpbiBzYXlzLCB1c2luZyB0aGUgT0lEIG5hbWUgaGFzIG5vIGd1YXJh bnRlZXMgb2YgYmVpbmcgdW5pcXVlLg0KDQpPbiBvbmx5IHRoaXMgdmVyeSBsYXN0IHBvaW50LCBJ J20gdW5zdXJlIGFib3V0IHRoYXQuDQpbUlddDQpUaGUgZnVsbCBudW1lcmljYWwgT0lEIHN0cmlu ZyBpcyB1bmlxdWUsIGJ1dCB2ZXJ5IGhhcmQgdG8gYmUgaW50ZXJwcmV0ZWQgYnkgYSBodW1hbi4g IFRoZSBodW1hbiByZWFkYWJsZSBPSUQgbmFtZSAoZS5nLiBmb3IganVzdCB0aGUgbGFzdCBlbGVt ZW50KSBpcyBub3QgdW5pcXVlLg0KDQpJIGFncmVlIHdpdGggSnVlcmdlbiwgaW4gdGhhdCBJIHRo aW5rIHRoYXQgdXNpbmcgT0lEcyBhcyBuYW1lcyBmb3IgZW5jcnlwdGlvbiBwcm90b2NvbHMgaXMg cHJvYmFibHkgYSBtaXN0YWtlIGFuZCB0eWluZyB1cyBpbnRvIHRoZSBwYXN0Lg0KDQoNCg0KDQoN CjIuICAgICAgSSB3b25kZXIgaWYgY2hhbmdpbmcgZnJvbSBpZGVudGlmaWVycyB0byBlbnVtcyB3 YXMgYSBtaXN0YWtlLiAgSWYgd2Ugd2VyZSB0byB1c2UgWUFORyBpZGVudGlmaWVycyB0aGVuIHdl IHdvdWxkbuKAmXQgbmVlZCB0byBkZWZpbmUgdGhlbSBhbGwgbm93LCBhbmQgdGhleSB3b3VsZG7i gJl0IGFsbCBuZWVkIHRvIGJlIGRlZmluZWQgaW4gdGhlIHNhbWUgWUFORyBtb2R1bGUuICBJbiBm YWN0LCBpZiB3ZSB3ZXJlIHRvIGdvIGJhY2sgdG8gdXNpbmcgaWRlbnRpZmllcnMgdGhlbiBwZXJo YXBzIE5FVENPTkYgc2hvdWxkIHJlc3RyaWN0IGl0c2VsZiB0byBvbmx5IGRlZmluaW5nIHRoZSBp ZGVudGlmaWVycyB0aGF0IHdlIGFjdHVhbGx5IG5lZWQgbm93LCBhbmQgbGVhdmUgdGhlIHJlc3Qg dG8gdGhlIHNlY3VyaXR5IGZvbGtzIHRvIGZpZ3VyZSBvdXQsIHByb2JhYmx5IGFzIHNlcGFyYXRl IG1vZHVsZXMgZGVmaW5pbmcgdGhlIGV4dHJhIGlkZW50aWZpZXJzIHRoYXQgdGhleSBuZWVkLCBv ciBhcyBhIGJpcyB2ZXJzaW9uIG9mIHRoZSBjcnlwdG8tdHlwZXMgZHJhZnQgaWYgcmVxdWlyZWQu DQoNClNlZW1zIGxpa2UgYSByZWFzb25hYmxlIGFwcHJvYWNoLCBidXQgSSBkb24ndCBrbm93IGhv dyB0aGF0IGRpZmZlcnMsIGluIHRoZSBlbmQsIGZyb20gdGhlIHViZXIgZGVmaW5pdGlvbiBzb21l IGZvbGtzIGhhdmUgdm9pY2VkIGEgY29uY2VybiBmb3IuICBNYXliZSB3ZSBuZWVkIHRvIHVuZGVy c3RhbmQgYmV0dGVyIHdoYXQgdGhhdCBjb25jZXJuIGlzIGJldHRlci4NCltSV10NCk9vcHMsIG15 IGNvbW1lbnQgYWJvdXQgc2hvdWxkIGhhdmUgYmVlbiBpZGVudGl0aWVzIHJhdGhlciB0aGFuIGlk ZW50aWZpZXJzIQ0KDQpJIHRoaW5rIHRoYXQgaXQgaXMgaGVscGZ1bCB0aGF0IGlkZW50aXRpZXMg YXJlIGV4dGVuc2libGUgYW5kIGNhbiBlYXNpbHkgYmUgY29uc3RydWN0ZWQgaW4gYSBtb2R1bGFy IHdheS4gIEUuZy4gZGVmaW5pbmcgaWRlbnRpdGllcyBpbiBkaWZmZXJlbnQgWUFORyBtb2R1bGVz LCBhbmQvb3IgcHV0dGluZyB0aGVtIHVuZGVyIGlmLWZlYXR1cmUgYWxsb3dzIGltcGxlbWVudGF0 aW9ucyB0byBjaG9vc2Ugd2hpY2ggb25lcyB0aGV5IGFjdHVhbGx5IHN1cHBvcnQuDQoNCkluIGll dGYtY3J5cHRvLXR5cGVzIEkgd291bGQgZGVmaW5lIHRoZSBiYXNlIGlkZW50aXRpZXMgZm9yOg0K DQoNCmhhc2gtYWxnb3JpdGhtLCBhc3ltbWV0cmljLWtleS1hbGdvcml0aG0sIG1hYy1hbGdvcml0 aG0sIGVuY3J5cHRpb24tYWxnb3JpdGhtLCBlbmNyeXB0aW9uLWFuZC1tYWMtYWxnb3JpdGhtLCBz aWduYXR1cmUtYWxnb3JpdGhtLCBrZXktZXhjaGFuZ2UtYWxnb3JpdGhtDQoNCk5vdGUsIGFzIGFu IGFzaWRlLCBJIGFtIEkgYWxzbyB3b25kZXJpbmcgd2hldGhlciB0aGUg4oCcZW5jcnlwdGlvbi1h bmQtbWFjLWFsZ29yaXRobeKAnSBpZGVudGl0eSBzaG91bGQgZGVyaXZlIGZyb20gYm90aCDigJxt YWMtYWxnb3JpdGht4oCdIGFuZCDigJxlbmNyeXB0aW9uLWFsZ29yaXRobeKAnT8gIE9yIHBlcmhh cHMgaXQgZG9lc27igJl0IG5lZWQgdG8gYmUgZGVmaW5lZCBhdCBhbGwsIGFuZCB0aGUgYWN0dWFs IGlkZW50aXRpZXMgY2FuIGp1c3QgZGVyaXZlIGZyb20gdHdvIGJhc2UgaWRlbnRpdGllcz8NCg0K SSB0aGVuIHN1Z2dlc3QgdGhhdCB3ZSBwdXQgZGlmZmVyZW50IGlkZW50aXRpZXMgaW50byBkaWZm ZXJlbnQgWUFORyBtb2R1bGVzLCBwZXJoYXBzIHNvbWV0aGluZyByb3VnaGx5IGxpa2U6DQoNCiAg KiAgIElldGYtY3J5cHRvLXNoYS10eXBlcy55YW5nIGZvciB0aGUgU0hBIGhhc2ggaWRlbnRpdGll cyAoUkZDIDYyMzQpDQogICogICBJZXRmLWNyeXB0by1yc2EtdHlwZXMgZm9yIFJTQSBhc3ltbWV0 cmljLWtleS1hbGdvcml0aG0gKFJDIDgwMTcpDQogICogICBJZXRmLWNyeXB0by1lbGxpcHRpYy1j dXJ2ZS10eXBlcyBmb3IgdGhlIEVsbGlwdGljIEN1cnZlIGJhc2VkIGFsZ29yaXRobXMgKFJGQyA2 MDkwLCA1NDgwLCA4NDIyKQ0KICAqICAgSWV0Zi1jcnlwdG8tbWFjLXR5cGVzIOKAkyBJ4oCZbSBu b3QgcmVhbGx5IHN1cmUgaG93IHRvIG9yZ2FuaXplIHRoZSBNQUMgYWxnb3JpdGhtIHR5cGVzLCBv ciBldmVuIGlmIHRoZXkgbmVlZCB0byBiZSBkZWZpbmVkIG5vdy4NCiAgKiAgIElldGYtY3J5cHRv LWFlcy10eXBlcyDigJMgQUVTIGVuY3J5cHRpb24gdHlwZXMgKFJGQyA0MzA5KQ0KICAqICAgSWV0 Zi1jcnlwdG8tc3NoLXR5cGVzIOKAkyBkYXMtc2hhMSwgcnNhYXNhLXBrY3MxLXNoYTEgKFJGQyA0 MjUzKQ0KICAqICAgSWV0Zi1jcnlwdG8tdGxzLXR5cGVzIOKAkyAoUkZDIDg0NDYpDQogICogICBJ ZXRmLWN5cHJ0by1kaGUtdHlwZXMg4oCTIERpZmZpZXIgSGVsbG1hbiBrZXkgZXhjaGFuZ2UgKFJG QyA3OTE5KS4gIEFjdHVhbGx5LCB0aGUga2V5LWV4Y2hhbmdlcyBhbGdvcml0aG0gdHlwZXMgbWln aHQgbmVlZCB0byBiZSBzcGxpdCB1cCBhIGJpdCBmdXJ0aGVyLg0KDQpUaGUga2V5IHN0ZXAgaXMg dGhhdCBJIHdvdWxkIHNheSB0aGF0IE5FVENPTkYgc2hvdWxkIG9ubHkgc3RhbmRhcmRpemVzIHRo ZSBvbmVzIHRoYXQgd2UgbmVlZCBub3cuICBGb3IgdGhlIG90aGVycywgd2UgY291bGQgcG90ZW50 aWFsbHkgY3JlYXRlIHRoZSBZQU5HIG1vZHVsZXMgYW5kIGVpdGhlciBoYW5kIHRoaXMgb2ZmIHRv IHRoZSBzZWN1cml0eSBncm91cHMsIG9yIHdvcmsgd2hldGhlciB0aGVtIHRvIHN0YW5kYXJkaXpl IHRoZXNlIHRocm91Z2ggdGhlIGFwcHJvcHJpYXRlIFdHcy4NCg0KDQoNCg0KMy4gICAgICBJ4oCZ bSBub3Qgc3VyZSB0aGF0IEkgdW5kZXJzdGFuZCB3aHkgd2Ugd291bGQgYWx3YXlzIHdhbnQgdG8g YWx3YXlzIHVzZSBBU04uMSB0byBkZXNjcmliZSB0aGUga2V5cyBmb3IgYWxsIGFsZ29yaXRobXMu ICBDb3VsZCB3ZSBqdXN0IGxlYXZlIHRoZSBhbGdvcml0aG0gaWRlbnRpdGllcyB0byBkZWZpbmUg d2hhdCBmb3JtYXQgdGhleSB1c2U/ICAgSWYgd2Ugd2VyZSB0byBnbyBiYWNrIHRvIHVzaW5nIGlk ZW50aXRpZXMgd2hlbiB3ZSBjb3VsZCBoYXZlIHRoZSBjaG9pY2Ugb2YgdXNpbmcgbXVsdGlwbGUg aW5oZXJpdGFuY2UgYW5kIHRoZW4gaGF2ZSBhIHNlcGFyYXRlIHNldCBvZiBpZGVudGl0aWVzIHRv IGFsbG93IHRoZSBrZXkgZm9ybWF0cyB0byBiZSBkZWZpbmVkLiAgTm90ZSwgSSBoYXZlIG5vIG9i amVjdGlvbiB0byBBU04uMSBiZWluZyB1c2VkIGZvciBzb21lL21vc3QgdGhlIGtleXMgaWYgdGhh dCBpcyB0aGUgcmlnaHQgZW5jb2RpbmcuDQoNClBlcmhhcHMgd2UgY2FuIGRvIGJvdGgsIHNheSB0 aGF0IHRoZSBmaWVsZCBpcyBwYXJzZWQgYWNjb3JkaW5nIHRvIGl0cyAiYWxnb3JpdGhtIiB2YWx1 ZSwgYnV0IGZvciBub3csIGFsbCBhbGdvcml0aG0gaWRlbnRpZmllcnMgaGFwcGVuIHRvIHBvaW50 IHRvIEFTTi4xIHN0cnVjdHVyZXMuDQpbUlddDQpZZXMsIGluIGVzc2VuY2UgSSB0aGluayB0aGF0 IGlzIHdoYXQgSeKAmW0gc3VnZ2VzdGluZy4NCg0KSWYgdGhpcyBpcyByZWFsbHkgY29tbW9uLCB0 aGVuIGFuIGlkZW50aXR5IGZvciDigJxBU04uMSBlbmNvZGVk4oCdIGNvdWxkIGFsc28gYmUgZGVm aW5lZCBhbmQgaW5oZXJpdGVkIGJ5IGNyeXB0byB0eXBlIGlkZW50aXRpZXMgYWJvdmUuICBJIHRo aW5rIHRoYXQgdGhpcyBkZXBlbmRzIG9uIGhvdyB1c2VmdWwgaXQgaXMgdG8gcHJvZ3JhbW1hdGlj YWxseSBrbm93IHRoYXQgdGhleSBhcmUgZW5jb2RlZCBpbiBBU04uMQ0KDQpUaGFua3MsDQpSb2IN Cg0KSG9wZWZ1bGx5IHRoZSBjb21tZW50cyBhcmUgdXNlZnVsLCBhcG9sb2dpZXMgaWYgdGhleSBh cmUgbm90IQ0KDQpBbGwgZ29vZC4gIEtlZXAgdGhlbSBjb21pbmcuDQoNCg0KS2VudA0KDQo= --_000_MN2PR11MB4366F63419F6BD4EF106766FB58F0MN2PR11MB4366namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3Jh cGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHls ZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1h cmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5 bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8q IExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjU3NzA2MTk3ODsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MjYzNzk4MjA7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21z by1sZXZlbC1zdGFydC1hdDozOw0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDA6bGV2ZWwyDQoJe21zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwz DQoJe21zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28t bGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLXRh Yi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC10YWItc3RvcDoy MTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9 DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDA6bGV2ZWw5DQoJe21zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxDQoJe21z by1saXN0LWlkOjgwMDgwNzYzMjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTA5MzgyOTgxMDt9 DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs MTpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDMN Cgl7bXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1s ZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFi LXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIx Ni4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30N CkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs MTpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDINCgl7bXNv LWxpc3QtaWQ6MTExMzk0MDE0MTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MzM2NTA2ODE2O30N CkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NzIu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0O30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpA bGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6 bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsNg0K CXttc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxl dmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC10YWIt c3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MzI0 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoxMjQxMjA4MzQzOw0KCW1zby1saXN0LXR5 cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTc3NTIyMTczMCAxOTAxMTAzOTc2 IDEzNDgwNzU1NSAxMzQ4MDc1NTcgMTM0ODA3NTUzIDEzNDgwNzU1NSAxMzQ4MDc1NTcgMTM0ODA3 NTUzIDEzNDgwNzU1NSAxMzQ4MDc1NTc7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC1z dGFydC1hdDoyOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC41cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjpibGFjazt9DQpAbGlzdCBsMzpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz dCBsMzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPkhpIEtlbnQsPG86cD48L286cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIGxh bmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBLZW50IFdhdHNl biAmbHQ7a2VudCYjNDM7aWV0ZkB3YXRzZW4ubmV0Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IDE2 IFNlcHRlbWJlciAyMDE5IDE3OjQ5PGJyPg0KPGI+VG86PC9iPiBSb2IgV2lsdG9uIChyd2lsdG9u KSAmbHQ7cndpbHRvbkBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBuZXRjb25mQGlldGYu b3JnOyBSdXNzIEhvdXNsZXkgJmx0O2hvdXNsZXlAdmlnaWxzZWMuY29tJmd0OzsgUmlmYWF0IFNo ZWtoLVl1c2VmICZsdDtyaWZhYXQuaWV0ZkBnbWFpbC5jb20mZ3Q7OyBTZWFuIFR1cm5lciAmbHQ7 c2VhbkBzbjNyZC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0Y29uZl0gY3J5 cHRvLXR5cGVzIGZhbGxiYWNrIHN0cmF0ZWd5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SGkgUm9iLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDs8YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDtt c28tbGlzdDpsMSBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PkkgdGhpbmsgdGhhdCB1c2luZyBhIG51bWVyaWNhbCBPSUQgdG8gaWRlbnRpZnkgY3J5cHRvIGFs Z29yaXRobXMgZG9lc27igJl0IHNlZW0gbGlrZSBhIGdyZWF0IGNob2ljZS4mbmJzcDsgU2VlaW5n IGEgY29uZmlnIGZpbGUgc2F5IHNvbWV0aGluZyBsaWtlIOKAnDwvc3Bhbj5yc2FFbmNyeXB0aW9u 4oCdIGluc3RlYWQgb2Ygc29tZSBPSUQgc3RyaW5nIHNlZW1zDQogdG8gYmUgbXVjaCBtb3JlIGh1 bWFuIGZyaWVuZGx5LiZuYnNwOyBBbmQgYXMgTWFydGluIHNheXMsIHVzaW5nIHRoZSBPSUQgbmFt ZSBoYXMgbm8gZ3VhcmFudGVlcyBvZiBiZWluZyB1bmlxdWUuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9u IG9ubHkgdGhpcyB2ZXJ5IGxhc3QgcG9pbnQsIEknbSB1bnN1cmUgYWJvdXQgdGhhdC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPltSV108bzpwPjwvbzpwPjwvaT48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT5UaGUgZnVsbCBudW1lcmljYWwgT0lEIHN0cmluZyBp cyB1bmlxdWUsIGJ1dCB2ZXJ5IGhhcmQgdG8gYmUgaW50ZXJwcmV0ZWQgYnkgYSBodW1hbi4mbmJz cDsgVGhlIGh1bWFuIHJlYWRhYmxlIE9JRCBuYW1lIChlLmcuIGZvciBqdXN0IHRoZSBsYXN0IGVs ZW1lbnQpIGlzIG5vdCB1bmlxdWUuPG86cD48L286cD48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGk+PG86cD4mbmJzcDs8L286cD48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGk+SSBhZ3JlZSB3aXRoIEp1ZXJnZW4sIGluIHRoYXQgSSB0aGluayB0aGF0IHVzaW5nIE9JRHMg YXMgbmFtZXMgZm9yIGVuY3J5cHRpb24gcHJvdG9jb2xzIGlzIHByb2JhYmx5IGEgbWlzdGFrZSBh bmQgdHlpbmcgdXMgaW50byB0aGUgcGFzdC48bzpwPjwvbzpwPjwvaT48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+Jm5ic3A7PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4w cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMiBsZXZlbDEgbGZvMiI+DQo8IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgd29uZGVyIGlmIGNoYW5naW5nIGZyb20gaWRlbnRp ZmllcnMgdG8gZW51bXMgd2FzIGEgbWlzdGFrZS4mbmJzcDsgSWYgd2Ugd2VyZSB0byB1c2UgWUFO RyBpZGVudGlmaWVycyB0aGVuIHdlIHdvdWxkbuKAmXQgbmVlZCB0byBkZWZpbmUgdGhlbSBhbGwg bm93LCBhbmQgdGhleSB3b3VsZG7igJl0IGFsbCBuZWVkIHRvIGJlIGRlZmluZWQgaW4gdGhlDQog c2FtZSBZQU5HIG1vZHVsZS4mbmJzcDsgSW4gZmFjdCwgaWYgd2Ugd2VyZSB0byBnbyBiYWNrIHRv IHVzaW5nIGlkZW50aWZpZXJzIHRoZW4gcGVyaGFwcyBORVRDT05GIHNob3VsZCByZXN0cmljdCBp dHNlbGYgdG8gb25seSBkZWZpbmluZyB0aGUgaWRlbnRpZmllcnMgdGhhdCB3ZSBhY3R1YWxseSBu ZWVkIG5vdywgYW5kIGxlYXZlIHRoZSByZXN0IHRvIHRoZSBzZWN1cml0eSBmb2xrcyB0byBmaWd1 cmUgb3V0LCBwcm9iYWJseSBhcyBzZXBhcmF0ZSBtb2R1bGVzDQogZGVmaW5pbmcgdGhlIGV4dHJh IGlkZW50aWZpZXJzIHRoYXQgdGhleSBuZWVkLCBvciBhcyBhIGJpcyB2ZXJzaW9uIG9mIHRoZSBj cnlwdG8tdHlwZXMgZHJhZnQgaWYgcmVxdWlyZWQuJm5ic3A7DQo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+U2VlbXMgbGlrZSBhIHJlYXNvbmFibGUgYXBwcm9hY2gsIGJ1dCBJIGRvbid0IGtub3cg aG93IHRoYXQgZGlmZmVycywgaW4gdGhlIGVuZCwgZnJvbSB0aGUgdWJlciBkZWZpbml0aW9uIHNv bWUgZm9sa3MgaGF2ZSB2b2ljZWQgYSBjb25jZXJuIGZvci4gJm5ic3A7TWF5YmUgd2UgbmVlZCB0 byB1bmRlcnN0YW5kIGJldHRlciB3aGF0IHRoYXQgY29uY2VybiBpcyBiZXR0ZXIuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT5bUlddIDxvOnA+PC9vOnA+PC9pPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPk9vcHMsIG15IGNvbW1lbnQgYWJvdXQgc2hvdWxkIGhh dmUgYmVlbiBpZGVudGl0aWVzIHJhdGhlciB0aGFuIGlkZW50aWZpZXJzITxvOnA+PC9vOnA+PC9p PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPjxvOnA+Jm5ic3A7PC9vOnA+PC9pPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPkkgdGhpbmsgdGhhdCBpdCBpcyBoZWxwZnVsIHRoYXQg aWRlbnRpdGllcyBhcmUgZXh0ZW5zaWJsZSBhbmQgY2FuIGVhc2lseSBiZSBjb25zdHJ1Y3RlZCBp biBhIG1vZHVsYXIgd2F5LiZuYnNwOyBFLmcuIGRlZmluaW5nIGlkZW50aXRpZXMgaW4gZGlmZmVy ZW50IFlBTkcgbW9kdWxlcywgYW5kL29yIHB1dHRpbmcgdGhlbSB1bmRlciBpZi1mZWF0dXJlIGFs bG93cyBpbXBsZW1lbnRhdGlvbnMgdG8gY2hvb3NlIHdoaWNoDQogb25lcyB0aGV5IGFjdHVhbGx5 IHN1cHBvcnQuPG86cD48L286cD48L2k+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT5JbiBpZXRmLWNyeXB0by10 eXBlcyBJIHdvdWxkIGRlZmluZSB0aGUgYmFzZSBpZGVudGl0aWVzIGZvcjo8YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvaT48L3A+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJhLWJvcmRlci1k aXY7Ym9yZGVyOnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzo4LjBwdCA4LjBwdCA4LjBwdCA4 LjBwdDtiYWNrZ3JvdW5kOiNGRkZERjUiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3Ljlw dDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFk ZGluZzowY20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5oYXNo LWFsZ29yaXRobSwgYXN5bW1ldHJpYy1rZXktYWxnb3JpdGhtLCBtYWMtYWxnb3JpdGhtLCBlbmNy eXB0aW9uLWFsZ29yaXRobSwgZW5jcnlwdGlvbi1hbmQtbWFjLWFsZ29yaXRobSwgc2lnbmF0dXJl LWFsZ29yaXRobSwga2V5LWV4Y2hhbmdlLWFsZ29yaXRobTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxpPk5vdGUsIGFzIGFuIGFzaWRlLCBJIGFtIEkgYWxzbyB3b25k ZXJpbmcgd2hldGhlciB0aGUg4oCcPC9pPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2NvbG9yOmJsYWNrIj5lbmNyeXB0aW9uLWFuZC1tYWMtYWxnb3JpdGht4oCdIGlkZW50aXR5IHNo b3VsZCBkZXJpdmUgZnJvbSBib3RoIOKAnG1hYy1hbGdvcml0aG3igJ0gYW5kIOKAnGVuY3J5cHRp b24tYWxnb3JpdGht4oCdPyZuYnNwOyBPciBwZXJoYXBzIGl0IGRvZXNu4oCZdA0KIG5lZWQgdG8g YmUgZGVmaW5lZCBhdCBhbGwsIGFuZCB0aGUgYWN0dWFsIGlkZW50aXRpZXMgY2FuIGp1c3QgZGVy aXZlIGZyb20gdHdvIGJhc2UgaWRlbnRpdGllcz88bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+SSB0 aGVuIHN1Z2dlc3QgdGhhdCB3ZSBwdXQgZGlmZmVyZW50IGlkZW50aXRpZXMgaW50byBkaWZmZXJl bnQgWUFORyBtb2R1bGVzLCBwZXJoYXBzIHNvbWV0aGluZyByb3VnaGx5IGxpa2U6PG86cD48L286 cD48L3NwYW4+PC9pPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHR5cGU9ImRpc2Mi Pg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21z by1saXN0OmwzIGxldmVsMSBsZm80Ij48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtj b2xvcjpibGFjayI+SWV0Zi1jcnlwdG8tc2hhLXR5cGVzLnlhbmcgZm9yIHRoZSBTSEEgaGFzaCBp ZGVudGl0aWVzIChSRkMgNjIzNCk8L3NwYW4+PC9pPjxpPjxvOnA+PC9vOnA+PC9pPjwvbGk+PGxp IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0 OmwzIGxldmVsMSBsZm80Ij48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi bGFjayI+SWV0Zi1jcnlwdG8tcnNhLXR5cGVzIGZvciBSU0EgYXN5bW1ldHJpYy1rZXktYWxnb3Jp dGhtIChSQyA4MDE3KTwvc3Bhbj48L2k+PGk+PG86cD48L286cD48L2k+PC9saT48bGkgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDMgbGV2 ZWwxIGxmbzQiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5J ZXRmLWNyeXB0by1lbGxpcHRpYy1jdXJ2ZS10eXBlcyBmb3IgdGhlIEVsbGlwdGljIEN1cnZlIGJh c2VkIGFsZ29yaXRobXMgKFJGQyA2MDkwLCA1NDgwLCA4NDIyKTwvc3Bhbj48L2k+PGk+PG86cD48 L286cD48L2k+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDowY207bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzQiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOmJsYWNrIj5JZXRmLWNyeXB0by1tYWMtdHlwZXMg4oCTIEnigJltIG5v dCByZWFsbHkgc3VyZSBob3cgdG8gb3JnYW5pemUgdGhlIE1BQyBhbGdvcml0aG0gdHlwZXMsIG9y IGV2ZW4gaWYgdGhleSBuZWVkIHRvIGJlIGRlZmluZWQgbm93Ljwvc3Bhbj48L2k+PGk+PG86cD48 L286cD48L2k+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDowY207bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzQiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOmJsYWNrIj5JZXRmLWNyeXB0by1hZXMtdHlwZXMg4oCTIEFFUyBlbmNy eXB0aW9uIHR5cGVzIChSRkMgNDMwOSk8L3NwYW4+PC9pPjxpPjxvOnA+PC9vOnA+PC9pPjwvbGk+ PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1s aXN0OmwzIGxldmVsMSBsZm80Ij48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xv cjpibGFjayI+SWV0Zi1jcnlwdG8tc3NoLXR5cGVzIOKAkyBkYXMtc2hhMSwgcnNhYXNhLXBrY3Mx LXNoYTEgKFJGQyA0MjUzKTwvc3Bhbj48L2k+PGk+PG86cD48L286cD48L2k+PC9saT48bGkgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDMg bGV2ZWwxIGxmbzQiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNr Ij5JZXRmLWNyeXB0by10bHMtdHlwZXMg4oCTIChSRkMgODQ0Nik8L3NwYW4+PC9pPjxpPjxvOnA+ PC9vOnA+PC9pPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MGNtO21zby1saXN0OmwzIGxldmVsMSBsZm80Ij48aT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtjb2xvcjpibGFjayI+SWV0Zi1jeXBydG8tZGhlLXR5cGVzIOKAkyBEaWZmaWVy IEhlbGxtYW4ga2V5IGV4Y2hhbmdlIChSRkMgNzkxOSkuJm5ic3A7IEFjdHVhbGx5LCB0aGUga2V5 LWV4Y2hhbmdlcyBhbGdvcml0aG0gdHlwZXMgbWlnaHQgbmVlZCB0byBiZSBzcGxpdCB1cA0KIGEg Yml0IGZ1cnRoZXIuPC9zcGFuPjwvaT48aT48bzpwPjwvbzpwPjwvaT48L2xpPjwvdWw+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48aT48bzpwPiZuYnNwOzwvbzpwPjwvaT48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48aT5UaGUga2V5IHN0ZXAgaXMgdGhhdCBJIHdvdWxkIHNheSB0aGF0IE5FVENP TkYgc2hvdWxkIG9ubHkgc3RhbmRhcmRpemVzIHRoZSBvbmVzIHRoYXQgd2UgbmVlZCBub3cuJm5i c3A7IEZvciB0aGUgb3RoZXJzLCB3ZSBjb3VsZCBwb3RlbnRpYWxseSBjcmVhdGUgdGhlIFlBTkcg bW9kdWxlcyBhbmQgZWl0aGVyIGhhbmQgdGhpcyBvZmYgdG8gdGhlIHNlY3VyaXR5IGdyb3Vwcywg b3Igd29yayB3aGV0aGVyIHRoZW0gdG8NCiBzdGFuZGFyZGl6ZSB0aGVzZSB0aHJvdWdoIHRoZSBh cHByb3ByaWF0ZSBXR3MuPG86cD48L286cD48L2k+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4w cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+DQo8IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4zLjxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPknigJltIG5vdCBzdXJlIHRoYXQgSSB1bmRlcnN0YW5k IHdoeSB3ZSB3b3VsZCBhbHdheXMgd2FudCB0byBhbHdheXMgdXNlIEFTTi4xIHRvIGRlc2NyaWJl IHRoZSBrZXlzIGZvciBhbGwgYWxnb3JpdGhtcy4mbmJzcDsgQ291bGQgd2UganVzdCBsZWF2ZSB0 aGUgYWxnb3JpdGhtIGlkZW50aXRpZXMgdG8gZGVmaW5lIHdoYXQgZm9ybWF0IHRoZXkgdXNlPyZu YnNwOw0KICZuYnNwO0lmIHdlIHdlcmUgdG8gZ28gYmFjayB0byB1c2luZyBpZGVudGl0aWVzIHdo ZW4gd2UgY291bGQgaGF2ZSB0aGUgY2hvaWNlIG9mIHVzaW5nIG11bHRpcGxlIGluaGVyaXRhbmNl IGFuZCB0aGVuIGhhdmUgYSBzZXBhcmF0ZSBzZXQgb2YgaWRlbnRpdGllcyB0byBhbGxvdyB0aGUg a2V5IGZvcm1hdHMgdG8gYmUgZGVmaW5lZC4gJm5ic3A7Tm90ZSwgSSBoYXZlIG5vIG9iamVjdGlv biB0byBBU04uMSBiZWluZyB1c2VkIGZvciBzb21lL21vc3QgdGhlIGtleXMNCiBpZiB0aGF0IGlz IHRoZSByaWdodCBlbmNvZGluZy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+UGVyaGFwcyB3ZSBj YW4gZG8gYm90aCwgc2F5IHRoYXQgdGhlIGZpZWxkIGlzIHBhcnNlZCBhY2NvcmRpbmcgdG8gaXRz ICZxdW90O2FsZ29yaXRobSZxdW90OyB2YWx1ZSwgYnV0IGZvciBub3csIGFsbCBhbGdvcml0aG0g aWRlbnRpZmllcnMgaGFwcGVuIHRvIHBvaW50IHRvIEFTTi4xIHN0cnVjdHVyZXMuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT5bUlddIDxvOnA+PC9vOnA+PC9pPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPlllcywgaW4gZXNzZW5jZSBJIHRoaW5rIHRoYXQgaXMg d2hhdCBJ4oCZbSBzdWdnZXN0aW5nLjxvOnA+PC9vOnA+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxpPjxvOnA+Jm5ic3A7PC9vOnA+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxpPklmIHRoaXMgaXMgcmVhbGx5IGNvbW1vbiwgdGhlbiBhbiBpZGVudGl0eSBmb3Ig4oCcQVNO LjEgZW5jb2RlZOKAnSBjb3VsZCBhbHNvIGJlIGRlZmluZWQgYW5kIGluaGVyaXRlZCBieSBjcnlw dG8gdHlwZSBpZGVudGl0aWVzIGFib3ZlLiZuYnNwOyBJIHRoaW5rIHRoYXQgdGhpcyBkZXBlbmRz IG9uIGhvdyB1c2VmdWwgaXQgaXMgdG8gcHJvZ3JhbW1hdGljYWxseSBrbm93IHRoYXQgdGhleSBh cmUgZW5jb2RlZCBpbiBBU04uMTxvOnA+PC9vOnA+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxpPjxvOnA+Jm5ic3A7PC9vOnA+PC9pPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxp PlRoYW5rcyw8YnI+DQpSb2I8bzpwPjwvbzpwPjwvaT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Ib3BlZnVsbHkgdGhlIGNvbW1lbnRz IGFyZSB1c2VmdWwsIGFwb2xvZ2llcyBpZiB0aGV5IGFyZSBub3QhPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ QWxsIGdvb2QuICZuYnNwO0tlZXAgdGhlbSBjb21pbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ S2VudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MN2PR11MB4366F63419F6BD4EF106766FB58F0MN2PR11MB4366namp_-- From nobody Tue Sep 17 03:13:04 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9819C120813 for ; Tue, 17 Sep 2019 03:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 u_w9qdM9metw for ; Tue, 17 Sep 2019 03:12:52 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B5B45120840 for ; Tue, 17 Sep 2019 03:12:52 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 355091AE08F5; Tue, 17 Sep 2019 12:12:51 +0200 (CEST) Date: Tue, 17 Sep 2019 12:12:26 +0200 (CEST) Message-Id: <20190917.121226.1164447711500530993.mbj@tail-f.com> To: zhoutianran@huawei.com Cc: kent+ietf@watsen.net, netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <20190917.115808.1894012459057925338.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] configuring multi-channels X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 10:12:59 -0000 Tianran Zhou wrote: > > > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > Sent: Tuesday, September 17, 2019 5:58 PM > > To: Tianran Zhou > > Cc: kent+ietf@watsen.net; netconf@ietf.org > > Subject: Re: configuring multi-channels > > > > Tianran Zhou wrote: > > > > > > > > > > -----Original Message----- > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > Sent: Tuesday, September 17, 2019 5:05 PM > > > > To: Tianran Zhou > > > > Cc: kent+ietf@watsen.net; netconf@ietf.org > > > > Subject: Re: configuring multi-channels > > > > > > > > Tianran Zhou wrote: > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > > > Sent: Tuesday, September 17, 2019 4:28 PM > > > > > > To: Tianran Zhou > > > > > > Cc: kent+ietf@watsen.net; netconf@ietf.org > > > > > > Subject: Re: configuring multi-channels > > > > > > > > > > > > Tianran Zhou wrote: > > > > > > > > -----Original Message----- > > > > > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > > > > > Sent: Tuesday, September 17, 2019 3:14 PM > > > > > > > > To: Tianran Zhou > > > > > > > > Cc: kent+ietf@watsen.net; netconf@ietf.org > > > > > > > > Subject: Re: configuring multi-channels > > > > > > > > > > > > > > > > Tianran Zhou wrote: > > > > > > > > > In this document, we defined two types of publication channels: > > > > > > > > > Master Publication Channel: the session between the > > > > > > > > > Master > > > > Publisher > > > > > > > > > and the Receiver. > > > > > > > > > Agent Publication Channel: the session between the > > > > > > > > > Agent > > > > Publisher > > > > > > > > > and the Receiver > > > > > > > > > > > > > > > > > > Do you think it's enough or anything you think should be clarified? > > > > > > > > > > > > > > > > These are just names. But why does these names imply that > > > > > > > > the client has to configure anything? > > > > > > > > > > > > > > Several kinds of transport protocol can be used to carry data > > > > > > > between the publisher and the receiver. UDP based, TCP based. > > > > > > > Transport like https-notif need client-server configuration. > > > > > > > That is to say the configuration is about the transport like > > > > > > > in draft-mahesh-netconf-https-notif-00. > > > > > > > > > > > > With the POST-based HTTP protocol in > > > > > > draft-mahesh-netconf-https-notif, why can't the agent publisher > > > > > > simply POST to the receiver? It is probably useful if the > > > > > > *server* can indicate to the client that this will/may happen, > > > > > > but I don't understand why the client needs to configure anything > > special. > > > > > > > > > > I agree with you. My understanding to > > > > > draft-mahesh-netconf-https-notif is that the configuration is on the > > *server* side. > > > > > The configuration need to indicate both client and server information. > > > > > For example: > > > > > module: ietf-https-notif > > > > > +--rw receivers > > > > > +--rw receiver* [name] > > > > > +--rw name string > > > > > +--rw tcp-params > > > > > | +--rw remote-address inet:host > > > > > | +--rw remote-port? inet:port-number > > > > > | +--rw local-address? inet:ip-address > > > > > | +--rw local-port? inet:port-number > > > > > | +--rw keepalives! > > > > > > > > > > Include both remote and local IP. > > > > > > > > The local-address and -port are conditional on an if-feature, but I > > > > agree that this is problematic in the case that an publisher agent > > > > on a line card wants to push directly to the receiver. > > > > > > Right. Thanks for your clarification. > > > So for TCP based transports, we have to preconfigure all the potential > > > local-remote pairs, aka the channel information in my words:-), on the > > > server. > > > > No I don't think that's the (correct) solution. Why is it important to > > configure this at all? > > Then, could you give any hint on the correct solution in your mind? > What configuration should be avoided in an idea solution? I don't exactly know; my original comment was that I don't think we should add 'channel' to this model at this time. But for this protocol, perhaps the local-address and local-port is not needed; it should be ok for the receiver to get POSTs from any local ip / port. /martin > > Thanks, > Tianran > > > > > /martin > > > > > > > For each subscription, the device can decide which set of publishers to > > serve. > > > > > > Thanks, > > > Tianran > > > > > > > /martin > > > > > > > > > > > > > > > > > > I am sorry, could you point out if there is any that mislead you. > > > > > :-) > > > > > > > > > > Best, > > > > > Tianran > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > > > Tianran > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Tianran > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > > > > > > > Sent: Tuesday, September 17, 2019 2:36 PM > > > > > > > > > > To: Tianran Zhou > > > > > > > > > > Cc: kent+ietf@watsen.net; netconf@ietf.org > > > > > > > > > > Subject: Re: configuring multi-channels > > > > > > > > > > > > > > > > > > > > Tianran Zhou wrote: > > > > > > > > > > > Hi Martin, > > > > > > > > > > > > > > > > > > > > > > The channel is concept is from > > > > > > > > > > > https://datatracker.ietf.org/doc/draft-zhou-netconf-mu > > > > > > > > > > > lti- stre am-o rigi nators/ There are multiple > > > > > > > > > > > publication channels per device/subscription. > > > > > > > > > > > > > > > > > > > > In that document, the word "channel" is present three > > > > > > > > > > times > > > > > > > > > > + one > > > > > > > > > > (broken) XML example. The concept of a channel needs to > > > > > > > > > > be explained in detail so that we can have a meaningful > > discussion. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It should be better if the client is not aware of the channels. > > > > > > > > > > > These can be achieved by using the UDP based > > > > > > > > > > > publication channel as > > > > > > > > in: > > > > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-netconf-ud > > > > > > > > > > > p-pu b-ch anne l/ The publishers can use the same IP > > > > > > > > > > > as the subscription channel, and use dynamic ports. So > > > > > > > > > > > no per channel configurations need. > > > > > > > > > > > > > > > > > > > > > > For https-notif, we can consider to pre-configure all > > > > > > > > > > > the possible/potential publication channels. > > > > > > > > > > > But the usage of which channels is decided by the > > > > > > > > > > > device dynamically during the run > > > > time. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > Tianran > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > > > > > > > > > > > Sent: Tuesday, September 17, 2019 3:27 AM > > > > > > > > > > > > To: kent+ietf@watsen.net > > > > > > > > > > > > Cc: Tianran Zhou ; > > > > > > > > > > > > netconf@ietf.org > > > > > > > > > > > > Subject: Re: [netconf] Adoption Call for > > > > > > > > > > > > draft-mahesh-netconf-https-notif-00 > > > > > > > > > > > > > > > > > > > > > > > > Kent Watsen wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Tianran, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Considering the multiple stream originator case, > > > > > > > > > > > > > > I would suggest this > > > > > > > > > > > > https-notif to add a channel level configuration. > > > > > > > > > > > > > > i.e. > > > > > > > > > > > > > > > > > > > > > > > > > > > > +--receivers > > > > > > > > > > > > > > +--receiver > > > > > > > > > > > > > > +--channels > > > > > > > > > > > > > > +--channel > > > > > > > > > > > > > > +--here put the http client server > > > > > > > > > > > > > > configurations > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is compatible with the single originator > > > > > > > > > > > > > > case with only one channel > > > > > > > > > > > > configuration. > > > > > > > > > > > > > > > > > > > > > > > > > > We can look at this. Maybe use a choice statement > > > > > > > > > > > > > between the two > > > > > > > > > > options... > > > > > > > > > > > > > > > > > > > > > > > > I don't think this is a good idea. But then I don't > > > > > > > > > > > > really understand the 'channel' concept. I don't > > > > > > > > > > > > understand why the client needs to be aware of these > > > > > > > > > > > > channels, but this should probably be discussed > > > > > > > > > > in a separate thread. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Kent // co-author > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you do not like this, I think existing > > > > > > > > > > > > > > https-notif model also > > > > > > > > works. > > > > > > > > > > > > > > i.e. each receiver configuration stands for one channel. > > > > > > > > > > > > > > But this is not clear IMO. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > > > > > > Tianran > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From nobody Tue Sep 17 04:05:02 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D7F120822 for ; Tue, 17 Sep 2019 04:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, 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=ericsson.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 HL5hvVNNoNCW for ; Tue, 17 Sep 2019 04:04:57 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10080.outbound.protection.outlook.com [40.107.1.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FABD12081D for ; Tue, 17 Sep 2019 04:04:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mnVHjVunfCqthOBXRWVq2vViyBVMZWLt7YJPovLCVabjNaUb/xLZ7YgOuVeY1tmZYKH+sZdHu0K1OHRZyLxqas7yu39va8U9XMzEHYBnjmTWqC7UjmGGNI91MphsqeX0v5rNi7oVtTHN8CThChftnol++yPbKaFKkITwdWW4Yb9KH8Lmnp/vjK53Qg4jPPB7yBhH62cGjp5ILLDWQAPJHX5GMtleuaHcTTj2+QHfUFgntj+A8EPIMwrovb9fXgf/3yHqt6KDY7Ip+Q6XlANLKdr6Y8KVFPMgH+g0LQ6h5OH6gg9wIHKSSB5mE69gsxygl/h6ZSpfEm+DzZQzxBBT/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:X-MS-Exchange-SenderADCheck; bh=H1iVLzp4vqjfKZd7LShv4WiwvxAoQGZlwnXyAJPr+HM=; b=U4iKnAKwhgHnhURBcK6Y8HrQNN5BCA3Ao/I+2jeGocZX83dH7fszS30xDKPh4eUczbTkn1o1NOxN6yLOQIIWFtUDUmKEZymri4keqOK3lUbi5r8SfqTSSkiVUGIuZA+nvBGQwp8O7Q1gy69H/y4eQcCzHOJ27eDnVzuwGpDL7dAVkustA+BovbAv3R/bBtEOxZpAOWQP2CWnqt7S7YS1T4wh+/7I9LXQHwD03AfvPt20f/g6FJYfoPRFu4QkX0eb5cv22aZV1UmWtvDFrg4EGOpe9gyxbrFgsZaC3DqS3tJOe+Y8AdWNQvKRfvdmiq/KKygcuCaFDmbV8tz0aGtXKw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=H1iVLzp4vqjfKZd7LShv4WiwvxAoQGZlwnXyAJPr+HM=; b=G/J6dYGE8pRAyHBJqoLRHQ/39eqvO+UazDZDn/m4V7PUUyA2TZk9bpdBsCnAmgk2DHTppi0ucIg+4gYgxWE8M14uyhN7y2kX8yMzYU+Q+JQZDWhKA8KaTKiz2lOQVZMgh66Wk6VZ6HLOjyqW37l8d74nWjxKFv2Zr+RGojm+nBg= Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com (10.169.137.153) by VI1PR0701MB2400.eurprd07.prod.outlook.com (10.168.138.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.13; Tue, 17 Sep 2019 11:04:53 +0000 Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com ([fe80::f44b:854c:51cf:c69f]) by VI1PR0701MB2286.eurprd07.prod.outlook.com ([fe80::f44b:854c:51cf:c69f%7]) with mapi id 15.20.2284.009; Tue, 17 Sep 2019 11:04:53 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Netconf Thread-Topic: http client draft Thread-Index: AdVsc6Z2V8qszT4sTLyEa3zmCo1E5gAN2JUAACbRvUA= Date: Tue, 17 Sep 2019 11:04:52 +0000 Message-ID: References: <88BAEBEC-7C31-4642-81A2-C1C5CF666D78@gmail.com> In-Reply-To: <88BAEBEC-7C31-4642-81A2-C1C5CF666D78@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4e0ffb7b-87e2-4eb2-c484-08d73b5eddcb x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(49563074)(7193020); SRVR:VI1PR0701MB2400; x-ms-traffictypediagnostic: VI1PR0701MB2400: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-forefront-prvs: 01630974C0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(346002)(136003)(376002)(366004)(189003)(199004)(99286004)(11346002)(66556008)(476003)(7116003)(76176011)(478600001)(26005)(102836004)(486006)(606006)(7696005)(81156014)(8936002)(81166006)(446003)(33656002)(53546011)(85202003)(52536014)(64756008)(66446008)(66476007)(25786009)(66616009)(256004)(7736002)(14444005)(66946007)(790700001)(86362001)(229853002)(3480700005)(74316002)(316002)(6916009)(6506007)(186003)(8676002)(3846002)(66066001)(6116002)(99936001)(2906002)(5660300002)(6436002)(55016002)(85182001)(71190400001)(236005)(71200400001)(14454004)(6246003)(66574012)(6306002)(9686003)(54896002)(76116006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2400; H:VI1PR0701MB2286.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: YBXMJMDxF5I/syC2t43oA77G+ILSMsg3BbCmzpZ+3z6UvErKG/1eZS/tWPCO+2BqK8msfJl56qpde21239yvfLztl8m7rK2G6ZCMi6K8gC9wZVZ2XBF87xeiBUGxGQXri0j+daDwB9JByLW+M6vwt+Wd6FGo3Ccyy2MY/XcERrfFyDgVI3K1LwXSJVxv5QQK/LZrnwypWY+86CWFoYCHIIq4GrnRaOMNzSN5XMTBxsTyGzExIN3wSK5LHyEUY7hHALL2y2CgPF1ljlPx7QKmvqlPbpz9Evsu+zxIfRH9S8Tw5yBdD1r37Hl9kXEee/vGdXXUE96wXz9idMFV1mIliJIjzsiczkqlD3Oh3ejNlwgLVPA314QeZl/DDspUdWzBpLGXkUzFgi7yn6fQ2YN5CX2pLIWnrg9PV6nXPhQ9WmE= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00CE_01D56D58.7D742150" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4e0ffb7b-87e2-4eb2-c484-08d73b5eddcb X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2019 11:04:52.7469 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qNd1F0qduim5M1T9FH8PwG0T93uCRYZSDyB7I7BPzHFsaRoQEF5LTlqftbsMKmjwrsImd2ET5vMN91kD5GhsLxdDOs/3vYwoB422Mw8+b64= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2400 Archived-At: Subject: Re: [netconf] http client draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 11:05:00 -0000 ------=_NextPart_000_00CE_01D56D58.7D742150 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00CF_01D56D58.7D742150" ------=_NextPart_001_00CF_01D56D58.7D742150 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Mahesh Jethanandani =20 Sent: 2019. szeptember 16., h=C3=A9tf=C5=91 18:23 To: Bal=C3=A1zs Lengyel Cc: Kent Watsen Subject: Re: http client draft =20 Hi Balasz, On Sep 16, 2019, at 2:49 AM, Bal=C3=A1zs Lengyel = > = wrote: =20 Hello Kent, As I need something like = = draft-mahesh-netconf-https-notif asap I am trying to look into some of = the details. (I might even propose a temporary extreme-simplified = version to some industry bodies.) Looking at the HTTP client draft I am missing the =E2=80=9Cpath=E2=80=9D = section of the URI. Is that just a mistake or intentional? =20 [mj] You must have seen Kent=E2=80=99s discussion with Martin on the = same topic. What is your preference to either one of the options. =20 - feature statement around a =E2=80=9Cpath=E2=80=9D leaf - augment http-params module to add a =E2=80=9Cpath=E2=80=9D leaf - add a new section for =E2=80=9Cpath=E2=80=9D =20 You can respond to the thread in the netconf mailing list. =20 [BALAZS]: In our practice PATH is nearly always used for HTTP based = communications. Most of the times it is a fixed path that could be = configured for the receiver/endpoint, so my proposals in order of = preference would be to=20 1. add path to the http-client model as a mandatory=3Dfalse leaf. (or = defaulting to an empty string) 2. feature statement around a =E2=80=9Cpath=E2=80=9D leaf 3. augment http-params module to add a =E2=80=9Cpath=E2=80=9D leaf =20 regards Balazs ------=_NextPart_001_00CF_01D56D58.7D742150 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

From: Mahesh Jethanandani = <mjethanandani@gmail.com>
Sent: 2019. szeptember 16., = h=C3=A9tf=C5=91 18:23
To: Bal=C3=A1zs Lengyel = <balazs.lengyel@ericsson.com>
Cc: Kent Watsen = <kent+ietf@watsen.net>
Subject: Re: http client = draft

 

Hi Balasz,



 

As I need something like draft-mahesh-netconf-https-notif asap I am trying to look into = some of the details.  (I might even propose a temporary = extreme-simplified version to some industry = bodies.)

Looking at the = HTTP client draft I am missing the =E2=80=9Cpath=E2=80=9D section of the = URI. Is that just a mistake or = intentional?

 

[mj] You must have seen Kent=E2=80=99s discussion = with Martin on the same topic. What is your preference to either one of = the options.

 

- = feature statement around a =E2=80=9Cpath=E2=80=9D = leaf

- augment http-params = module to add a =E2=80=9Cpath=E2=80=9D leaf

- add a new section for = =E2=80=9Cpath=E2=80=9D

 

You can respond to the thread in the netconf mailing = list.

 

[BALAZS]: In our practice PATH is nearly always used = for HTTP based communications. Most of the times it is a fixed path that = could be configured for the receiver/endpoint, so my proposals in order = of preference would be to

  1. add path to the = http-client model as a mandatory=3Dfalse leaf. (or defaulting to an = empty string)
  2. feature statement = around a =E2=80=9Cpath=E2=80=9D leaf
  3. augment http-params module to add a =E2=80=9Cpath=E2=80=9D = leaf

 

regards Balazs

------=_NextPart_001_00CF_01D56D58.7D742150-- ------=_NextPart_000_00CE_01D56D58.7D742150 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVbjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF/zCCA+egAwIBAgIR AOm+1xFswMzmixU1jNT/MSEwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMB4XDTE3MTAw OTE1MjQ1OFoXDTIwMTAwOTE1MjQ1N1owajERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD0Jh bMOhenMgTGVuZ3llbDEqMCgGCSqGSIb3DQEJARYbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t MQ8wDQYDVQQFEwZFVEhCTEwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUUtnneUfH i428YPkvW+AsCNeKCCKq72SzUZpBggijy+oLVO0cgTXXHygrZ+KT8TbyEkPwuHi+V4TQxWAyMhGa nWZHWZXe9ghEZrJDJbCzFMHOqR+wEDnI1vM3sfQQ68iSsWQLd9opnb2/ihiJlt9up75VRpyj5lea bvzxOLQimJgZiXaZzsPPT2nROyytKxOsE5KbfT3mNof3bMG1bggZtGGA1GBJchwdFJwQKIShfPVm 1CdulvJV1hPVecxttMJNPzSfSfryb/b64QnR5yc/pSx8SxD0h0rnNT73Al3Af2iRghdXN4omDKZY OcdK/sE5HTmLTFuWoZAnL/RntOK9AgMBAAGjggHBMIIBvTBIBgNVHR8EQTA/MD2gO6A5hjdodHRw Oi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggr BgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYI KwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNlcjAmBgNVHREEHzAdgRtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBSkJw2vbyMFmf9tY1urk9NeYfiMgTAfBgNVHSMEGDAWgBQcexmel5x2rCA92Nzj kWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAD1RCVf5Df2uCXwPveXz LBGIjsz3k2la5UUlioC+i4Ms6vGstqXIX7K24+Wc41npi+G5xFhvkAkmuTP/j29F5xJJuJcy3OcL 0br02vKe2WJJnlivB+X9plPg0kMUBS0lLq7kHPUrO/BLeIIFRuaky05eZlTnGNcLbn5VpZdjX4Ic XZV78qpZI3L67Po1UgHzOTiWolc75jrKOx3UOw98fWRrgJPBUIeqDeD1NDfF7PlM4Cqlad062o6L lM9wfAnoLzz0z04dPXtJkOcTiZgOLdPoKIm7LR1wZ9c6mYw4sgtoVAs16Y2cCPBxqWpsW+9ZCcDK PPZzeBezCKyicpDJbTqCVMILd3j38HWUPWFuVITZNgANzHW1CpgqmiLIAADiznCCtudTE+fcB3O9 duuu/yuEME17LMy1GYMKXs1QCXmTq2hrqTJQ2AA2TsWZtoxl3ViqJgNBWjnQiMwdCl5Dural2jZP /iU6MmiauUNYn9YW/ViUluoBBdaUHMpnP/7kM0Wk8j3Wzhcggx+Biml2gCopMaK1EJYjQH/2J95N GEkSdZfVzFUmwV3yMd4mOhIaxW0SEq9b1eWICZ/BAcVBpSyU0sE1gpnBO5wLxj+IpSdiGlS4jc37 qCr/39xdv1Unu93glCmHq0xgX54N8EsyMBPC3+zSSu1qhCbU7VJWIz2aMIIGwjCCBKqgAwIBAgIQ U7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEf MB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcx MjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy 3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt 8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6j RrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFl hFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/2 0aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCY rEqHMRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuT LUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMd ay0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqd GTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMB AAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVz dC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9j cmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpec dqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5 s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90 BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRy pF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86 IWst821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QD Xnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7 C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbN QUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbH XSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i 6Ds5j0Qpj5aQMYIDBTCCAwECAQEwXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MAkGBSsOAwIaBQCgggF+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTE5MDkxNzExMDQ1MFowIwYJKoZIhvcNAQkEMRYEFPRoZe3C7ZJlwd6CCPkLOrTTT2+aMEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQCfucanqcqUyB034Kfi6RrXiH8qEN2KqnPU2yHmD9ZIBvI3WtcMypbH WgEdE+QnVm9qlG0fFN92Bp7ag7k+O4JI/qxdUcxaRvOmn1pSJaNd5bQbZX9zqkT1AEzf/IZy8imH Gi18l69jrsoaOxjcMs/E0jynz5kcd5j93FF/uH8QvutdPzVAaXaVe9gPuwBwRIXm1RDErjDrQB0i gqrk0Vkwi+DYitCIqDf/qywId/7is3+paF5p+bqDngw7l3mPwLTJp25xLQR7BMaGX2xd2rRH6utr pOxmycbFVtSdAIc7B24caup4o3D7aAGfSSsXGaBqynuK/tzdyPmzCCJ4EnPiAAAAAAAA ------=_NextPart_000_00CE_01D56D58.7D742150-- From nobody Tue Sep 17 05:51:58 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AD4120850 for ; Tue, 17 Sep 2019 05:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=etas.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 NsqRQPewLLQY for ; Tue, 17 Sep 2019 05:51:53 -0700 (PDT) Received: from de-out1.bosch-org.com (de-out1.bosch-org.com [139.15.230.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 660CA120846 for ; Tue, 17 Sep 2019 05:51:52 -0700 (PDT) Received: from si0vm1947.rbesz01.com (unknown [139.15.230.188]) by fe0vms0187.rbdmz01.com (Postfix) with ESMTPS id 46Xjfs60Kfz1XLDQx for ; Tue, 17 Sep 2019 14:51:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=etas.com; s=key1-intmail; t=1568724709; bh=mMRLNv6nWqhKp5VQEcU3zAzJs0Kro4w0sek951h9umA=; l=10; h=From:Subject:From:Reply-To:Sender; b=iY/aLwSHbPL2SN2AZktNgHoj5KMmLYFyzw8NORghNFj081mx4tSsZxMu8uFJxRYgO GaLhEurLM9oCi/C8lCgLNoXAQkSb1B4XZTVBwEj2ll8KQYj8iJu5wjf/J4YiE5uetO rwVw+E9hzUYnfRq9p9nR2dWAt6Gs9JyUJXvRAVgM= Received: from fe0vm1741.rbesz01.com (unknown [10.58.172.176]) by si0vm1947.rbesz01.com (Postfix) with ESMTPS id 46Xjfs5kCpz6CjY1l for ; Tue, 17 Sep 2019 14:51:49 +0200 (CEST) X-AuditID: 0a3aad15-537ff70000003bb6-62-5d80d6e547a4 Received: from si0vm1950.rbesz01.com ( [10.58.173.29]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by fe0vm1741.rbesz01.com (SMG Outbound) with SMTP id 2C.05.15286.5E6D08D5; Tue, 17 Sep 2019 14:51:49 +0200 (CEST) Received: from SI-MBX2055.de.bosch.com (unknown [10.3.230.149]) by si0vm1950.rbesz01.com (Postfix) with ESMTPS id 46Xjfs3dNKzC9P for ; Tue, 17 Sep 2019 14:51:49 +0200 (CEST) Received: from SI-MBX2054.de.bosch.com (10.3.230.148) by SI-MBX2055.de.bosch.com (10.3.230.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Tue, 17 Sep 2019 14:51:49 +0200 Received: from SI-MBX2054.de.bosch.com ([fe80::187:74e0:f8c8:c9b1]) by SI-MBX2054.de.bosch.com ([fe80::187:74e0:f8c8:c9b1%4]) with mapi id 15.01.1713.009; Tue, 17 Sep 2019 14:51:49 +0200 From: "Schwarz Albrecht (ETAS/ESY1)" To: "netconf@ietf.org" Thread-Topic: Digital Twins in context of YANG and NETCONF Datastore Thread-Index: AdVtOy/e8x/GzuO3Qz6xXy+qg7LMCw== Date: Tue, 17 Sep 2019 12:51:49 +0000 Message-ID: <929a628b61804f9887f479f128eea20a@etas.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.132.146] Content-Type: multipart/alternative; boundary="_000_929a628b61804f9887f479f128eea20aetascom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA21Tf0xTVxTmvj7g0vHW56MdxyrJ9gJmuFnKBtHNzZi4xSVzmWaZxm0NPuD1 xywt6StGyYgYt5WVEWVOVyoKYw0xGpkgVWALbJ0/kQWiFkFINqW4ACbW0bChjO09XrH9Y/+c fPc75/vOuefmYgVTg7XYYnPyDhtnZZOUpPLV0xmrxgcrDfprn69Yc7htJHE9esvnmyU2ow+U rxXzVssu3pGzbofS3F7XTZa6jbs9N0NkJRrf7kYpGOg8+HusPtmNlJihPQQET9ST8uEXBJH7 /mjmAYJLw/3RQzeCaw1TpKRPotfD1cH9SRJW09mwzxtOdCOM00S+sytTgmr6Tfh0AMkVOuia +4qQMElnQfCCawFT9Groam9QSBjRGXDmTP8CVtDpcDvUQMiT0uD7UeaB1sDE2HyijJ+FfZEm Qq4vgJbab5DsuQSu1oXIgyjNG2fljSvzxpXJ/IvQ+MOfSTJ+AZq/nVIs4r6fxoh4vhEln0Qa I6/fVZK7Oi9X5yjkhXJ9rq7IXtKG5GfRdKDwhDGACIwCKB8TrIbyfl1pYJ4utBfvMXOCucBR ZuUFVkv5M9YYmLQntFBWWGIRBIvdFkCAFaya2lyx18BQxdyect5hl2UBtAyTbDplwu9+xNAm zsnv5PlS3rGYXYsxC5QyKDZc4uBN/G6jxepcTLMZFEpISGCeic/EtyVwSgC9jFPF3vabogUl lHIlgsUUlS+V5cwiG5P2og/xwYljTQrcefG4GH9eiA9P+sT4lxQZ0ma38dp0yiv50pKDucz2 ZDLtcgpUFQZGE5eIuU+iIYQRm0Ydk8Sp4j+IzQTUxvAO8bJRMiZ6ySdqaFcqRPwq6Bm+gaCj PUDAHX81CdU9j0mYvl2bDJ7vzqfA6PnPlBDp/e0peFR3WAXn2q+rwBPsp+FiqJmBvlNVauip 8Wtg1DcCMDR/WQutf/RpYajz3jI48IXvORi9dYmF2Vu/slA1/3smeObuZUHV3RMroHbelQ3/ Hj+bDWePfLkSpmfdq6C1+XEODN9v1UPf/jH9pLhvQtx3dlGFtG8n5/yffUfZ2OW0lShvZ/Do hndytrjftr7f22GDmqmif0z5k9066m7LyCffv7d9ncczZ62eeH5QHT7NbVx+aKuJGXJdd5lm Hg7ccDnLQ87wBuKVhupNmcGZpoh6Zjwy/ODK2vo3CnSH2i6/Pqiaqkq/8vG5AfWdli3GrFOz 41T+gQvbpktVNY3JqW0KYi9LCmYud6XCIXD/ASDbHZegBAAA Archived-At: Subject: [netconf] Digital Twins in context of YANG and NETCONF Datastore X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 12:51:57 -0000 --_000_929a628b61804f9887f479f128eea20aetascom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All! I'm curious whether the IETF NETCONF/OPSAWG experts did already discuss how= "digital twin" related concepts could/would be mapped on our management ar= chitectures. Being aware that there's probably still a precise term definition lacking i= n the IETF, I guess that we could make at least the rough working assumptio= n that e.g. "a digital twin relates to a virtual representation of a techni= cal entity". Thus, when looking at the types of technical entities in scope of these IET= F WGs, then the two twin entities (let's term them A and M) would/could be = related to * twin "A" =3D managed system (acting in management agent or manage= ment server role) and * twin "M" =3D managing system (acting in management manager or man= agement client role). Consequently, the digital twins would relate to managed objects (MO), const= ituted by management data models. If such a working assumption and management concept wouldn't be completely = nonsense, then I could imagine that a digital twin could be equated with e.= g., a) a dedicated YANG module (covering all management data as part of a digit= al twin related management services) or b) an existent or dedicated NETCONF datastore instance "digital twin" (eith= er explicit or implicit (using filtering))? Could you follow such an interpretation and mapping concept of "digital twi= n" to NETCONF/YANG? Did you already touch/discuss the digital twin conceptually in IETF meeting= s? I think it's worth to provide some statements or recommendations how NETCON= F/YANG technologies could be used for the realization of digital twins (or = course in specific system contexts only). I think it's feasible. Thanks and regards, Albrecht PS I would firstly postpone the aspect whether the Internet architecture is of= type IoT or non-IoT. (The IoT assumption would be that the twins would be = located at IoT device and application layers.) --_000_929a628b61804f9887f479f128eea20aetascom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All!

 

I'm curious whether the IETF NETCONF/OPSAWG experts did= already discuss how "digital twin" related concepts could/would = be mapped on our management architectures.

Being aware that there's probably still a precise term = definition lacking in the IETF, I guess that we could make at least the rou= gh working assumption that e.g. "a digital twin relates to a virtual representation of a technical entity".

 

Thus, when looking at the types of technical entities i= n scope of these IETF WGs, then the two twin entities (let’s term the= m A and M) would/could be related to

·         twin "A" =3D managed system (acting in m= anagement agent or management server role) and

·         twin "M" =3D managing system (acting in = management manager or management client role).

 

Consequently, the digital twins would relate to managed= objects (MO), constituted by management data models.

If such a working assumption and management concept wou= ldn't be completely nonsense, then I could imagine that a digital twin coul= d be equated with e.g.,

a) a dedicated YANG module (covering all management dat= a as part of a digital twin related management services) or

b) an existent or dedicated NETCONF datastore instance = "digital twin" (either explicit or implicit (using filtering))?

 

Could you follow such an interpretation and mapping con= cept of “digital twin” to NETCONF/YANG?

Did you already touch/discuss the digital twin conceptu= ally in IETF meetings?

 

I think it’s worth to provide some statements or = recommendations how NETCONF/YANG technologies could be used for the realiza= tion of digital twins (or course in specific system contexts only). I think it's feasible.

 

Thanks and regards,

Albrecht

 

PS

I would firstly postpone the aspect whether the Interne= t architecture is of type IoT or non-IoT. (The IoT assumption would be that= the twins would be located at IoT device and application layers.)

 

 

--_000_929a628b61804f9887f479f128eea20aetascom_-- From nobody Tue Sep 17 06:55:05 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4251120855 for ; Tue, 17 Sep 2019 06:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 Zt9-WQnwnFy3 for ; Tue, 17 Sep 2019 06:55:02 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 052DC120801 for ; Tue, 17 Sep 2019 06:55:01 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8HDfkDb017682; Tue, 17 Sep 2019 14:54:57 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=oDIAMkwkLH4IXAl71kLtkFQ1uWZ+xMAY9oYnJPM+1Sw=; b=NdNm89hNWTMiLjlhtUjPkKznTm5RS82bld7zdBnnJbMeo7JXxsPiRIqs5TvQVFU8Z6nI 8fE7RswFOBSDB1ma2Xp4BQC4GPt/H4brEZQgY6I+oEQKtPaS5UzIX5NSLen4EhdneCBM yF6y7ueV8nWX9QhDDN01EosPgxy9Sbfx1jZarsdRlDumwRnkGCxPKY79EOYnNYlrofWR prrxQpHn6UcoHiB1/9ARJ7LhOdqABfK36c/dDvLpe8kaM/8jLxZrKs97IJOtJ8K8C8xy seIv5wXiJsuwiDNIY5o9AHVsq8B3eJsc6l8ufg4nFjMM0tyY6V9PLn65LTF2w5CCcWcq 7g== Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2v0quuw0u9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Sep 2019 14:54:57 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x8HDngqk007673; Tue, 17 Sep 2019 09:54:56 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint3.akamai.com with ESMTP id 2v0uhx8vnf-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 17 Sep 2019 09:54:55 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 17 Sep 2019 09:54:47 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Tue, 17 Sep 2019 09:54:47 -0400 From: "Salz, Rich" To: "Rob Wilton (rwilton)" , Kent Watsen CC: Russ Housley , "netconf@ietf.org" , Sean Turner , Rifaat Shekh-Yusef Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxGVhFlbERW30moo9Q8WhnpJqcpkUCAgAU9agCAASLxgP//+5oA Date: Tue, 17 Sep 2019 13:54:46 +0000 Message-ID: <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@email.amazonses.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.45] Content-Type: multipart/alternative; boundary="_000_8053FDA077EA488FB5A7F203359105E0akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-17_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=751 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909170136 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-17_06:2019-09-17,2019-09-17 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 adultscore=0 phishscore=0 spamscore=0 priorityscore=1501 malwarescore=0 mlxscore=0 bulkscore=0 suspectscore=0 clxscore=1015 mlxlogscore=743 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909170136 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 13:55:04 -0000 --_000_8053FDA077EA488FB5A7F203359105E0akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSW4gaWV0Zi1jcnlwdG8tdHlwZXMgSSB3b3VsZCBkZWZpbmUgdGhlIGJhc2UgaWRlbnRp dGllcyBmb3I6DQoNCg0KDQpoYXNoLWFsZ29yaXRobSwgYXN5bW1ldHJpYy1rZXktYWxnb3JpdGht LCBtYWMtYWxnb3JpdGhtLCBlbmNyeXB0aW9uLWFsZ29yaXRobSwgZW5jcnlwdGlvbi1hbmQtbWFj LWFsZ29yaXRobSwgc2lnbmF0dXJlLWFsZ29yaXRobSwga2V5LWV4Y2hhbmdlLWFsZ29yaXRobQ0K DQpJIGFtIG5vdCB2ZXJ5IGNvbWZvcnRhYmxlIHdpdGggdGhhdCBkaXZpc2lvbiwgYXMgdGhlIHNh bWUga2V5IG1hdGVyaWFsIGNhbiBiZSB1c2VkIGluIG11bHRpcGxlIHBsYWNlcywgYW5kIHdl4oCZ cmUgdHJhbnNwb3J0aW5nIGtleSBtYXRlcmlhbC4gIEEgc3ltbWV0cmljIGtleSBjYW4gYmUgdXNl ZCB0byBib3RoIGVuY3J5cHQgZGF0YSwgYW5kIHRvIGRvIGFuIEhNQUMg4oCcc2lnbmF0dXJlLuKA nSAgQXMgYSBtaW5vciBub3RlLCBpdCBvbWl0cyBLZXkgRGVyaXZhdGlvbiBGdW5jdGlvbnMsIEtE Riwgd2hpY2ggYXJlIGEga2V5IHBhcnQgb2YgVExTIDEuMyBhbmQgdXNlZCBmb3Ig4oCcZXhwb3J0 aW5n4oCdIGtleXMgZnJvbSBUTFMgdXAgdG8gdGhlIGFwcGxpY2F0aW9uIGxheWVyIGFtb25nIG90 aGVyIHRoaW5ncy4NCg0KDQogICogICBUaGUga2V5IHN0ZXAgaXMgdGhhdCBJIHdvdWxkIHNheSB0 aGF0IE5FVENPTkYgc2hvdWxkIG9ubHkgc3RhbmRhcmRpemVzIHRoZSBvbmVzIHRoYXQgd2UgbmVl ZCBub3cuDQoNCkEgdmVyeSBzdHJvbmcgeWVzIGZvciB0aGlzLg0KDQoNCiAgKiAgICAgRm9yIHRo ZSBvdGhlcnMsIHdlIGNvdWxkIHBvdGVudGlhbGx5IGNyZWF0ZSB0aGUgWUFORyBtb2R1bGVzIGFu ZCBlaXRoZXIgaGFuZCB0aGlzIG9mZiB0byB0aGUgc2VjdXJpdHkgZ3JvdXBzLCBvciB3b3JrIHdo ZXRoZXIgdGhlbSB0byBzdGFuZGFyZGl6ZSB0aGVzZSB0aHJvdWdoIHRoZSBhcHByb3ByaWF0ZSBX R3MuDQoNCkkgdGhpbmsgaXQgd291bGQgYmUgd29ydGh3aGlsZSB0byBjb250YWN0IHRoZSBTZWN1 cml0eSBBROKAmXMgYW5kIGFzayBmb3IgdGltZSB0byBwcmVzZW50IHRoaXMgc29tZXdoZXJlLCBs aWtlIHRoZSBvcGVuIFNBQUcgbWVldGluZy4NCg0K --_000_8053FDA077EA488FB5A7F203359105E0akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5t c29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u RW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo1NzcwNjE5Nzg7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOjI2Mzc5ODIwO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28t bGV2ZWwtc3RhcnQtYXQ6MzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxl dmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNv LWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWIt c3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6 bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXtt c28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLXRh Yi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6ODAwODA3NjMyOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczoxMDkzODI5ODEwO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVs NQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxl dmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3Rv cDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDINCgl7 bXNvLWxpc3QtaWQ6MTExMzk0MDE0MTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MzM2NTA2ODE2 O30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDI6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsNQ0K CXttc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVs LXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDoz LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDMNCgl7bXNv LWxpc3QtaWQ6MTIwNjg3Mjc1MDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6LTIzMjQ2MTE1NiAtMTM5Nzg4MDYyMCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5 ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlz dCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJbXNvLWFuc2ktZm9udC1zdHlsZTppdGFsaWM7fQ0KQGxpc3QgbDM6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsMzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwzOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQNCgl7bXNvLWxpc3QtaWQ6MTI0 MTIwODM0MzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTE3NzUyMjE3MzAgMTkwMTEwMzk3NiAxMzQ4MDc1NTUgMTM0ODA3NTU3IDEzNDgwNzU1MyAxMzQ4 MDc1NTUgMTM0ODA3NTU3IDEzNDgwNzU1MyAxMzQ4MDc1NTUgMTM0ODA3NTU3O30NCkBsaXN0IGw0 OmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MjsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjpibGFjazt9 DQpAbGlzdCBsNDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGw0OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0OmxldmVsNA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDQ6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDQ6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsNDpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNQ0KCXttc28t bGlzdC1pZDoxNTU1MzkwNjc2Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMjE4OTY0Mzc0O30N CkBsaXN0IGw1OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDU6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDU6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow aW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8dWwgc3R5bGU9 Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMyBsZXZlbDEgbGZvMTAiPjxpPklu IGlldGYtY3J5cHRvLXR5cGVzIEkgd291bGQgZGVmaW5lIHRoZSBiYXNlIGlkZW50aXRpZXMgZm9y Ojxicj4NCjxicj4NCjxicj4NCjwvaT48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6OC4wcHQgOC4wcHQgOC4wcHQgOC4w cHQiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7 d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9y OmJsYWNrIj5oYXNoLWFsZ29yaXRobSwgYXN5bW1ldHJpYy1rZXktYWxnb3JpdGhtLCBtYWMtYWxn b3JpdGhtLCBlbmNyeXB0aW9uLWFsZ29yaXRobSwgZW5jcnlwdGlvbi1hbmQtbWFjLWFsZ29yaXRo bSwgc2lnbmF0dXJlLWFsZ29yaXRobSwga2V5LWV4Y2hhbmdlLWFsZ29yaXRobTwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gbm90IHZlcnkgY29tZm9ydGFibGUg d2l0aCB0aGF0IGRpdmlzaW9uLCBhcyB0aGUgc2FtZSBrZXkgbWF0ZXJpYWwgY2FuIGJlIHVzZWQg aW4gbXVsdGlwbGUgcGxhY2VzLCBhbmQgd2XigJlyZSB0cmFuc3BvcnRpbmcga2V5IG1hdGVyaWFs LiZuYnNwOyBBIHN5bW1ldHJpYyBrZXkgY2FuIGJlIHVzZWQgdG8gYm90aCBlbmNyeXB0IGRhdGEs IGFuZCB0byBkbyBhbiBITUFDIOKAnHNpZ25hdHVyZS7igJ0mbmJzcDsgQXMgYSBtaW5vciBub3Rl LA0KIGl0IG9taXRzIEtleSBEZXJpdmF0aW9uIEZ1bmN0aW9ucywgS0RGLCB3aGljaCBhcmUgYSBr ZXkgcGFydCBvZiBUTFMgMS4zIGFuZCB1c2VkIGZvciDigJxleHBvcnRpbmfigJ0ga2V5cyBmcm9t IFRMUyB1cCB0byB0aGUgYXBwbGljYXRpb24gbGF5ZXIgYW1vbmcgb3RoZXIgdGhpbmdzLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMyBsZXZlbDEgbGZv MTAiPjxpPlRoZSBrZXkgc3RlcCBpcyB0aGF0IEkgd291bGQgc2F5IHRoYXQgTkVUQ09ORiBzaG91 bGQgb25seSBzdGFuZGFyZGl6ZXMgdGhlIG9uZXMgdGhhdCB3ZSBuZWVkIG5vdy48L2k+PG86cD48 L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgdmVyeSBzdHJvbmcgeWVzIGZvciB0aGlzLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMyBsZXZlbDEgbGZv MTAiPjxpPiZuYnNwOyBGb3IgdGhlIG90aGVycywgd2UgY291bGQgcG90ZW50aWFsbHkgY3JlYXRl IHRoZSBZQU5HIG1vZHVsZXMgYW5kIGVpdGhlciBoYW5kIHRoaXMgb2ZmIHRvIHRoZSBzZWN1cml0 eSBncm91cHMsIG9yIHdvcmsgd2hldGhlciB0aGVtIHRvIHN0YW5kYXJkaXplIHRoZXNlIHRocm91 Z2ggdGhlIGFwcHJvcHJpYXRlDQogV0dzLjwvaT48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgdGhpbmsgaXQgd291bGQgYmUgd29ydGh3aGlsZSB0byBjb250YWN0IHRoZSBT ZWN1cml0eSBBROKAmXMgYW5kIGFzayBmb3IgdGltZSB0byBwcmVzZW50IHRoaXMgc29tZXdoZXJl LCBsaWtlIHRoZSBvcGVuIFNBQUcgbWVldGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8053FDA077EA488FB5A7F203359105E0akamaicom_-- From nobody Tue Sep 17 07:00:35 2019 Return-Path: <0100016d3f864f24-aeab9f9b-fd8f-4688-89ba-a66f7571c943-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C762120801 for ; Tue, 17 Sep 2019 07:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 4uZbmr3ZFVpx for ; Tue, 17 Sep 2019 07:00:32 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF52B120059 for ; Tue, 17 Sep 2019 07:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568728830; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=laWz+4bGDPvI9NHNsFdqhhYscUKIWR4Z3hwoo6nZ11g=; b=MI2h3EmcCGHpQ3QTThHr951uNEKUpxlvd9ZsKD/k0zzNtZbIYV2kVqRqPELBjVRG cXuf0PZMhwnzhTVZWi6jJZj7IgZJIWZSICcDc+Abr15wuObQn5gn/30zaC5hiH0xYD3 tLyA3MBZ45lJb/fsAIgbIxl/35HBXjLwoxlIlcwI= From: Kent Watsen Message-ID: <0100016d3f864f24-aeab9f9b-fd8f-4688-89ba-a66f7571c943-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E7D97B06-7D48-48E5-B28B-D4D3A12D2E21" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 17 Sep 2019 14:00:29 +0000 In-Reply-To: <20190916.212526.427039138127777720.mbj@tail-f.com> Cc: "netconf@ietf.org" To: Martin Bjorklund References: <0100016d18b462b3-38420cd3-1259-47ea-aa1b-f250a8238c9b-000000@email.amazonses.com> <20190910.090803.448863675820254782.mbj@tail-f.com> <0100016d3aca212d-1791071e-66b5-4730-9cf2-6b4f16217d21-000000@email.amazonses.com> <20190916.212526.427039138127777720.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.17-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 14:00:34 -0000 --Apple-Mail=_E7D97B06-7D48-48E5-B28B-D4D3A12D2E21 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> Do you mean to add to the draft a new section called something like >> "Authorization" that mimics what's in the SN draft regarding, e.g., >> NACM? >=20 > No I mean that when the device generates a notification, NACM needs a > user name to find the access control rules. What is the user name > with this new protocol? Now I understand. There isn't a set answer for this yet. Two = approaches: 1) We could claim that it is the "system" that is the publisher = (effectively no NACM) 2) We could have an explicit field for the "send as" user. (default to = "system"?) >> This draft doesn't assume anything about the server (if this is a >> valid assumption is discussed below) and, presumably, this assumption >> may be a common. So maybe ietf-http-client should also define a >> feature statement for the new "path" leaf, thus servers have an easy >> way to turn it on. It would be mandatory false, with the description >> statement indicating that it is only needed for some protocols. >> Alternatively, this draft could augment in a "path" leaf into the >> "http-params" section, or define a new section for just the path. >> Thoughts? >=20 > I prefer the latter. I think the 'path' leaf will not be very common > whe the http-client grouping is used. Sure, and by "latter", do you mean a) augment in a "path" leaf into the "http-params" section, or b) define a new section for just the path? > I'm fine with this being a new "protocol", not RESTCONF. Okay. Kent --Apple-Mail=_E7D97B06-7D48-48E5-B28B-D4D3A12D2E21 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Do you mean to add to = the draft a new section called something like
"Authorization" that mimics what's in the SN draft regarding, = e.g.,
NACM?

No I = mean that when the device generates a notification, NACM needs a
user name to find the access control rules.  What is the = user name
with this new protocol?

Now I = understand.   There isn't a set answer for this yet.   Two = approaches:

1) We could claim that = it is the "system" that is the publisher (effectively no = NACM)
2) We could have an explicit field for the "send as" = user.  (default to "system"?)

This = draft doesn't assume anything about the server (if this is a
valid assumption is discussed below) and, presumably, this = assumption
may be a common.  So maybe = ietf-http-client should also define a
feature statement = for the new "path" leaf, thus servers have an easy
way to = turn it on.  It would be mandatory false, with the description
statement indicating that it is only needed for some = protocols.
Alternatively, this draft could augment in a = "path" leaf into the
"http-params" section, or define a = new section for just the path.
Thoughts?

I prefer the latter.  I = think the 'path' leaf will not be very common
whe the = http-client grouping is used.


Sure, and by "latter", do you mean a) augment in a = "path" leaf into the
"http-params" section, or b) define a new = section for just the path?



I'm fine with this being a new "protocol", = not RESTCONF.

Okay.



Kent


= --Apple-Mail=_E7D97B06-7D48-48E5-B28B-D4D3A12D2E21-- From nobody Tue Sep 17 07:09:42 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC678120059 for ; Tue, 17 Sep 2019 07:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=VHXgA/bA; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=JnNCs9qb 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 iqTM2RmwdAee for ; Tue, 17 Sep 2019 07:09:38 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75BC912002E for ; Tue, 17 Sep 2019 07:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32470; q=dns/txt; s=iport; t=1568729378; x=1569938978; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BQxOU5Miht74y4JltH/P9VM5nbWYLFg9gqA6Q9Zvo1s=; b=VHXgA/bA8AHhg6aRM98fxc2ptqUuftJHKtMwB+4otUIPgQg5ZUlnsj5Q uDbS3mNl5eJce8PrwSPkVm7FkzxUOfeaj5pNIJDkM81kCfYrq9TjZGvBE BfewbavvXVjvZhoTtywonIFgPX52H//VycDWmYGbT/HkM5a5/zxzwGWG6 g=; IronPort-PHdr: =?us-ascii?q?9a23=3AaSyA1Ra0MHxEmZjKIHHYoz//LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gebRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavwcC0+AMNEfFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAACh6IBd/5BdJa1dCRoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVQEAQEBAQsBgRUvKScDbVYgBAsqCoQXg0cDineCXIlljg2?= =?us-ascii?q?BLoEkA1QJAQEBDAEBLQIBAYQ/AheCZSM1CA4CAwkBAQQBAQECAQUEbYUuDIV?= =?us-ascii?q?KAQEBAQMSEQoTAQE3AQ8CAQgRBAEBIQoCAgIfER0IAgQBDQUIGoMBgR1NAx0?= =?us-ascii?q?BAqJhAoE4iGFzgTKCfQEBBYUPDQuCFwmBNAGKNIElHhiBQD+BEUaCTD6CGoI?= =?us-ascii?q?ALIMJMoImj1GFJYkdjh9BCoIikQGEG5kajgqKFI5wAgQCBAUCDgEBBYFUATW?= =?us-ascii?q?BWHAVgyeCQgsYgQQBB4JDilNzgSmOKgGBIgEB?= X-IronPort-AV: E=Sophos;i="5.64,516,1559520000"; d="scan'208,217";a="632353886" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Sep 2019 14:09:36 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x8HE9aBh017748 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Sep 2019 14:09:36 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 17 Sep 2019 09:09:35 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 17 Sep 2019 10:09:35 -0400 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 17 Sep 2019 09:09:34 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R2O69CZ7/RcoGrAMN8b6BBvMJrnAlQXHxZjL9VlR6fAUiJoMBv3mzPatESPvP3F4Ofg1vGWNNw4pDY3VQPzussvQBgjPopA2cHlumUAS17+PWy7NChgYXz1ESRQVXc2V/7KfVpQpA4ZsOeKkBMEngdmJuNn1je3VwH1RLdvBs2EvfTouIuGis10c7GzepIuS6yCv6jJtGNNBMuYcv89SdnS5QVDHO+J8Ptp5l6f4dq5rchQcx3rli1R3GWiIQv3DKZQsoPDkd9gnMq7Gts5SKIR7cPqpVrDVfmw4As6ieX2Ih4B7qLjr8wJotZHiIQUQKgoh9wFkhycGS4s5k0ndTg== 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=BQxOU5Miht74y4JltH/P9VM5nbWYLFg9gqA6Q9Zvo1s=; b=oGMX4wuxb9lzuuC/mlEvOHKlxsTnGOUebnvzRODazD6Rxt62zDGlUxpaJGmYdt1xgHs6gROczTBoawasu2OfIctCREMyt2vwG+b3sE/cUfOQPefLvuq+Pn9zGU3oU2GHNxtPs1b96UKdbk96IM8RvMZjOsY6pOj9BAPyHtgfiFBWcHd68V4vXt20uvqfFQgaLHunZ8UtZ66sQsREQmCdrK8CfVoQbxwbHYsWKydey7H8L5euq7M55xjw6R5jN3pz4xyzgUgCsr9Hry5n5A9ZBYfgnt6vXRvT6y/fPFsPRVUImj3mOFy3ieiQybkAxLyKqZOzT5GDRH25dG5vTL8C7Q== 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=BQxOU5Miht74y4JltH/P9VM5nbWYLFg9gqA6Q9Zvo1s=; b=JnNCs9qbJw0LbQ8AWaByp8vzv681m9gEvIKMWgp36OPIKo9la5f3lMRAwddFqZq6Gtou9sUcQ8AABjUd/SSwRorRRDCtoszBj8DRRzlRCDADf6gp1lBYZhckx5tiFa3b3ByrkVDS337doXZ8HWVwohBm49G7vgBhrYNngnAfuCE= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3968.namprd11.prod.outlook.com (10.255.180.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.23; Tue, 17 Sep 2019 14:09:33 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6%7]) with mapi id 15.20.2263.023; Tue, 17 Sep 2019 14:09:33 +0000 From: "Rob Wilton (rwilton)" To: "Salz, Rich" , Kent Watsen CC: Russ Housley , "netconf@ietf.org" , Sean Turner , Rifaat Shekh-Yusef Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxVu0aQE+n/K0iPwVgOy8FH/KcpQIdQgAVLFQCAARKfAIAATvkAgAABvxA= Date: Tue, 17 Sep 2019 14:09:33 +0000 Message-ID: References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@email.amazonses.com> <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> In-Reply-To: <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [173.38.220.61] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 668e57ec-68a7-48b4-a5a2-08d73b78aa78 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB3968; x-ms-traffictypediagnostic: MN2PR11MB3968: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01630974C0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(39860400002)(136003)(346002)(396003)(189003)(199004)(51444003)(76176011)(55016002)(71200400001)(54906003)(110136005)(66946007)(66066001)(66556008)(6246003)(74316002)(11346002)(446003)(66476007)(229853002)(76116006)(6436002)(64756008)(9686003)(186003)(6306002)(99286004)(54896002)(8936002)(486006)(81166006)(9326002)(81156014)(7696005)(8676002)(26005)(102836004)(6506007)(2906002)(71190400001)(33656002)(14454004)(66446008)(25786009)(52536014)(5660300002)(7736002)(476003)(478600001)(3846002)(6116002)(4326008)(53546011)(14444005)(316002)(256004)(86362001)(790700001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3968; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: mn8o4Wgb1sB+pZ0tVMn6+Omhu/vwLxkuPlTKWIi654DhDTTEL3LhGC/LcMUykJNko10b4pxfhxOwveTCWN0olttXyuQgKdxCfUAuguya2YKHZL+SP8gHDOJyYyAKoEuIhmdb2tPyu5A3ntjKzm54K7RABRbKqb4C95hPQ50pnv4WZ3EkvFwkNNmxHG0BPvlWh9ChhRdhhyXganrAwaGV6HKKZ8XBee37gNELBd/2ebvMb5CWSYH7BubsDtBJkA+aRpQsX+o55vhEmgyXTDFpsct+Vy7wLNI4Y6z50B2l8VbMtuKAz+7l0mA8r77VMoYV1bUJ+fjWfXUXn6thUzVUbQUtIIIYrKuodh5mzSe6g7S7MWnCe04fs42s7qUf/ogwU7DMRHn9fKM8COBVjgwQeq+ikHOPekUaF4uftkKKbKs= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB43669B3A47A39FD93B47292FB58F0MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 668e57ec-68a7-48b4-a5a2-08d73b78aa78 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2019 14:09:33.6693 (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: Ckb2Pr8F2tQQOYCTiGc+SIg+zM0LypTKYl4UJoZfdPhs0AloTpxc3ser1MSRIoY7BTIQNmV/TPz176d/RqJmoA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3968 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.27, xch-rcd-017.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 14:09:41 -0000 --_000_MN2PR11MB43669B3A47A39FD93B47292FB58F0MN2PR11MB4366namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmljaCwNCg0KRnJvbTogU2FseiwgUmljaCA8cnNhbHpAYWthbWFpLmNvbT4NClNlbnQ6IDE3 IFNlcHRlbWJlciAyMDE5IDE0OjU1DQpUbzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25A Y2lzY28uY29tPjsgS2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0Pg0KQ2M6IFJ1c3Mg SG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+OyBuZXRjb25mQGlldGYub3JnOyBTZWFuIFR1 cm5lciA8c2VhbkBzbjNyZC5jb20+OyBSaWZhYXQgU2hla2gtWXVzZWYgPHJpZmFhdC5pZXRmQGdt YWlsLmNvbT4NClN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gY3J5cHRvLXR5cGVzIGZhbGxiYWNrIHN0 cmF0ZWd5DQoNCg0Kw5ggIEluIGlldGYtY3J5cHRvLXR5cGVzIEkgd291bGQgZGVmaW5lIHRoZSBi YXNlIGlkZW50aXRpZXMgZm9yOg0KDQoNCmhhc2gtYWxnb3JpdGhtLCBhc3ltbWV0cmljLWtleS1h bGdvcml0aG0sIG1hYy1hbGdvcml0aG0sIGVuY3J5cHRpb24tYWxnb3JpdGhtLCBlbmNyeXB0aW9u LWFuZC1tYWMtYWxnb3JpdGhtLCBzaWduYXR1cmUtYWxnb3JpdGhtLCBrZXktZXhjaGFuZ2UtYWxn b3JpdGhtDQoNCltSV10NClRoZXNlIGJhc2UgaWRlbnRpdGllcyBhcmUganVzdCB0aGUgb25lcyB0 aGF0IHdlcmUgYWxyZWFkeSBkZWZpbmVkIGluIGN5cHRvLXR5cGVzLTA4LiAgSS5lLiByZWFsbHkg SSBhbSBqdXN0IHNheWluZyB0aGF0IGRlZmluaW5nIHRoZSBiYXNlIGlkZW50aXRpZXMgaW4gdGhl IGNyeXB0byB0eXBlcyBkcmFmdCBpcyB0aGUgcmlnaHQgdGhpbmcgdG8gZG8sIHdoZXJlYXMgdGhl IGFjdHVhbCBpZGVudGl0aWVzIGNhbiBiZSBkZWZpbmVkIGluIHNlcGFyYXRlIHR5cGVzIG1vZHVs ZXMuDQoNCg0KSSBhbSBub3QgdmVyeSBjb21mb3J0YWJsZSB3aXRoIHRoYXQgZGl2aXNpb24sIGFz IHRoZSBzYW1lIGtleSBtYXRlcmlhbCBjYW4gYmUgdXNlZCBpbiBtdWx0aXBsZSBwbGFjZXMsIGFu ZCB3ZeKAmXJlIHRyYW5zcG9ydGluZyBrZXkgbWF0ZXJpYWwuICBBIHN5bW1ldHJpYyBrZXkgY2Fu IGJlIHVzZWQgdG8gYm90aCBlbmNyeXB0IGRhdGEsIGFuZCB0byBkbyBhbiBITUFDIOKAnHNpZ25h dHVyZS7igJ0gIEFzIGEgbWlub3Igbm90ZSwgaXQgb21pdHMgS2V5IERlcml2YXRpb24gRnVuY3Rp b25zLCBLREYsIHdoaWNoIGFyZSBhIGtleSBwYXJ0IG9mIFRMUyAxLjMgYW5kIHVzZWQgZm9yIOKA nGV4cG9ydGluZ+KAnSBrZXlzIGZyb20gVExTIHVwIHRvIHRoZSBhcHBsaWNhdGlvbiBsYXllciBh bW9uZyBvdGhlciB0aGluZ3MuDQpbUlddDQpJZiB5b3UgaGFkIGFuIGFsZ29yaXRobSB0aGF0IGNh biBiZSB1c2VkIGZvciBtdWx0aXBsZSB0aGluZ3MgdGhlbiBpdCBjYW4ganVzdCBkZXJpdmUgZnJv bSBtdWx0aXBsZSBiYXNlIGlkZW50aXRpZXMuDQoNCkUuZy4gaWYgeW91IHRha2Ug4oCcYWVzLTEy OC1jY23igJ0gKGZyb20gZHJhZnQtaWV0Zi1uZXRjb25mLWNyeXB0by10eXBlcy0wOCkgdGhhdCBp cyBjdXJyZW50bHkgaGFzIOKAnGVuY3J5cHRpb24tYW5kLW1hYy1hbGdvcml0aG3igJ0gYXMgaXRz IGJhc2UsIGl0IGNvdWxkIGJlIGRlZmluZWQgYXMgZm9sbG93cywgYWxsb3dpbmcgaXQgdG8gYmUg dXNlZCBlaXRoZXIgYXMgYSBtYWMtYWxnb3JpdGhtIG9yIGFuIGVuY3J5cHRpb24gYWxnb3JpdGht Og0KDQogICAgaWRlbnRpdHkgYWVzLTEyOC1jY20gew0KICAgICAgYmFzZSBlbmNyeXB0aW9uLWFs Z29yaXRobTsNCiAgICAgIGJhc2UgbWFjLWFsZ29yaXRobTsNCiAgICAgIGRlc2NyaXB0aW9uDQog ICAgICAgICJFbmNyeXB0IG1lc3NhZ2Ugd2l0aCBBRVMgYWxnb3JpdGhtIGluIENDTSBtb2RlIHdp dGggYSBrZXkNCiAgICAgICAgIGxlbmd0aCBvZiAxMjggYml0czsgaXQgY2FuIGFsc28gYmUgdXNl ZCBmb3IgZ2VuZXJhdGluZyBNQUMiOw0KICAgICAgcmVmZXJlbmNlDQogICAgICAgICJSRkMgNDMw OToNCiAgICAgICAgICAgVXNpbmcgQWR2YW5jZWQgRW5jcnlwdGlvbiBTdGFuZGFyZCAoQUVTKSBD Q00gTW9kZSB3aXRoDQogICAgICAgICAgIElQc2VjIEVuY2Fwc3VsYXRpbmcgU2VjdXJpdHkgUGF5 bG9hZCAoRVNQKSI7DQogICAgfQ0KDQoNCg0KDQoNCsOYICBUaGUga2V5IHN0ZXAgaXMgdGhhdCBJ IHdvdWxkIHNheSB0aGF0IE5FVENPTkYgc2hvdWxkIG9ubHkgc3RhbmRhcmRpemVzIHRoZSBvbmVz IHRoYXQgd2UgbmVlZCBub3cuDQoNCkEgdmVyeSBzdHJvbmcgeWVzIGZvciB0aGlzLg0KDQoNCsOY ICAgIEZvciB0aGUgb3RoZXJzLCB3ZSBjb3VsZCBwb3RlbnRpYWxseSBjcmVhdGUgdGhlIFlBTkcg bW9kdWxlcyBhbmQgZWl0aGVyIGhhbmQgdGhpcyBvZmYgdG8gdGhlIHNlY3VyaXR5IGdyb3Vwcywg b3Igd29yayB3aGV0aGVyIHRoZW0gdG8gc3RhbmRhcmRpemUgdGhlc2UgdGhyb3VnaCB0aGUgYXBw cm9wcmlhdGUgV0dzLg0KDQpJIHRoaW5rIGl0IHdvdWxkIGJlIHdvcnRod2hpbGUgdG8gY29udGFj dCB0aGUgU2VjdXJpdHkgQUTigJlzIGFuZCBhc2sgZm9yIHRpbWUgdG8gcHJlc2VudCB0aGlzIHNv bWV3aGVyZSwgbGlrZSB0aGUgb3BlbiBTQUFHIG1lZXRpbmcuDQpbUlddDQpJIGFncmVlIHRoYXQg c2VlbXMgbGlrZSBhIGdvb2QgaWRlYS4gIEJ1dCBJIHRoaW5rIHRoYXQgbmFycm93aW5nIHRoZSBz Y29wZSB0byBnZXQgdGhlc2UgZG9jdW1lbnRzIGZpbmlzaGVkIGlzIHRoZSBoaWdoZXN0IHByaW9y aXR5Lg0KDQpUaGFua3MsDQpSb2INCg0KDQo= --_000_MN2PR11MB43669B3A47A39FD93B47292FB58F0MN2PR11MB4366namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3Jh cGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHls ZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1h cmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K c3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWls U3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4ubWZ0cg0KCXttc28tc3R5bGUtbmFtZTptX2Z0cjt9DQpzcGFuLm1o ZHINCgl7bXNvLXN0eWxlLW5hbWU6bV9oZHI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0 IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExp c3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjg3OTc4NjczNzsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE3NTM1NzIxMDQ7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjEyMDY4NzI3NTA7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMzI0NjExNTYgLTEzOTc4 ODA2MjAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2 ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFt aWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYW5zaS1m b250LXN0eWxlOml0YWxpYzt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6 bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjEyNzg3NTMyNTY7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOi0xOTYzOTQ3Mjc4O30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoyMDk3NDgwNzA5Ow0KCW1zby1saXN0LXRlbXBs YXRlLWlkczotMTE2ODc1OTc4Njt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6 bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4 MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2 ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMyNC4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgUmljaCw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIj4gU2FseiwgUmljaCAmbHQ7cnNhbHpAYWthbWFpLmNvbSZndDsNCjxicj4NCjxi PlNlbnQ6PC9iPiAxNyBTZXB0ZW1iZXIgMjAxOSAxNDo1NTxicj4NCjxiPlRvOjwvYj4gUm9iIFdp bHRvbiAocndpbHRvbikgJmx0O3J3aWx0b25AY2lzY28uY29tJmd0OzsgS2VudCBXYXRzZW4gJmx0 O2tlbnQmIzQzO2lldGZAd2F0c2VuLm5ldCZndDs8YnI+DQo8Yj5DYzo8L2I+IFJ1c3MgSG91c2xl eSAmbHQ7aG91c2xleUB2aWdpbHNlYy5jb20mZ3Q7OyBuZXRjb25mQGlldGYub3JnOyBTZWFuIFR1 cm5lciAmbHQ7c2VhbkBzbjNyZC5jb20mZ3Q7OyBSaWZhYXQgU2hla2gtWXVzZWYgJmx0O3JpZmFh dC5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRjb25mXSBj cnlwdG8tdHlwZXMgZmFsbGJhY2sgc3RyYXRlZ3k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9t OjEyLjBwdDttYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDps MSBsZXZlbDEgbGZvMyI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxpPjxzcGFuIGxhbmc9IkVO LVVTIj5JbiBpZXRmLWNyeXB0by10eXBlcyBJIHdvdWxkIGRlZmluZSB0aGUgYmFzZSBpZGVudGl0 aWVzIGZvcjo8YnI+DQo8YnI+DQo8L3NwYW4+PC9pPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjguMHB0IDguMHB0IDguMHB0IDguMHB0Ij4NCjxwcmUgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjcuOXB0O21hcmdpbi1s ZWZ0OjM2LjBwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+aGFzaC1h bGdvcml0aG0sIGFzeW1tZXRyaWMta2V5LWFsZ29yaXRobSwgbWFjLWFsZ29yaXRobSwgZW5jcnlw dGlvbi1hbGdvcml0aG0sIGVuY3J5cHRpb24tYW5kLW1hYy1hbGdvcml0aG0sIHNpZ25hdHVyZS1h bGdvcml0aG0sIGtleS1leGNoYW5nZS1hbGdvcml0aG08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0i RU4tVVMiPltSV10gPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyI+VGhlc2UgYmFzZSBpZGVudGl0aWVzIGFy ZSBqdXN0IHRoZSBvbmVzIHRoYXQgd2VyZSBhbHJlYWR5IGRlZmluZWQgaW4gY3lwdG8tdHlwZXMt MDguJm5ic3A7IEkuZS4gcmVhbGx5IEkgYW0ganVzdCBzYXlpbmcgdGhhdCBkZWZpbmluZyB0aGUg YmFzZSBpZGVudGl0aWVzIGluIHRoZSBjcnlwdG8gdHlwZXMgZHJhZnQgaXMgdGhlIHJpZ2h0IHRo aW5nIHRvIGRvLCB3aGVyZWFzIHRoZQ0KIGFjdHVhbCBpZGVudGl0aWVzIGNhbiBiZSBkZWZpbmVk IGluIHNlcGFyYXRlIHR5cGVzIG1vZHVsZXMuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgYW0g bm90IHZlcnkgY29tZm9ydGFibGUgd2l0aCB0aGF0IGRpdmlzaW9uLCBhcyB0aGUgc2FtZSBrZXkg bWF0ZXJpYWwgY2FuIGJlIHVzZWQgaW4gbXVsdGlwbGUgcGxhY2VzLCBhbmQgd2XigJlyZSB0cmFu c3BvcnRpbmcga2V5IG1hdGVyaWFsLiZuYnNwOyBBIHN5bW1ldHJpYyBrZXkgY2FuIGJlIHVzZWQg dG8gYm90aCBlbmNyeXB0IGRhdGEsDQogYW5kIHRvIGRvIGFuIEhNQUMg4oCcc2lnbmF0dXJlLuKA nSZuYnNwOyBBcyBhIG1pbm9yIG5vdGUsIGl0IG9taXRzIEtleSBEZXJpdmF0aW9uIEZ1bmN0aW9u cywgS0RGLCB3aGljaCBhcmUgYSBrZXkgcGFydCBvZiBUTFMgMS4zIGFuZCB1c2VkIGZvciDigJxl eHBvcnRpbmfigJ0ga2V5cyBmcm9tIFRMUyB1cCB0byB0aGUgYXBwbGljYXRpb24gbGF5ZXIgYW1v bmcgb3RoZXIgdGhpbmdzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIj5bUlddIDxvOnA+PC9vOnA+PC9zcGFuPjwvaT48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiPklm IHlvdSBoYWQgYW4gYWxnb3JpdGhtIHRoYXQgY2FuIGJlIHVzZWQgZm9yIG11bHRpcGxlIHRoaW5n cyB0aGVuIGl0IGNhbiBqdXN0IGRlcml2ZSBmcm9tIG11bHRpcGxlIGJhc2UgaWRlbnRpdGllcy48 bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxp PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIj5FLmcuIGlmIHlv dSB0YWtlIOKAnGFlcy0xMjgtY2Nt4oCdIChmcm9tIGRyYWZ0LWlldGYtbmV0Y29uZi1jcnlwdG8t dHlwZXMtMDgpIHRoYXQgaXMgY3VycmVudGx5IGhhcyDigJxlbmNyeXB0aW9uLWFuZC1tYWMtYWxn b3JpdGht4oCdIGFzIGl0cyBiYXNlLCBpdCBjb3VsZCBiZSBkZWZpbmVkIGFzIGZvbGxvd3MsIGFs bG93aW5nIGl0IHRvIGJlIHVzZWQgZWl0aGVyIGFzIGEgbWFjLWFsZ29yaXRobQ0KIG9yIGFuIGVu Y3J5cHRpb24gYWxnb3JpdGhtOjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvaT48L2I+PC9wPg0KPGRpdiBzdHlsZT0ibXNvLWVsZW1lbnQ6cGFyYS1ib3JkZXIt ZGl2O2JvcmRlcjpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6OC4wcHQgOC4wcHQgOC4wcHQg OC4wcHQ7YmFja2dyb3VuZDojRkZGREY1Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFs bDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGlkZW50aXR5IGFlcy0xMjgtY2NtIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3Jv dW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20i Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBi YXNlIGVuY3J5cHRpb24tYWxnb3JpdGhtOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRG NTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJhc2UgbWFjLWFs Z29yaXRobTs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVh ay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2Jh Y2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5n OjBjbSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZxdW90O0VuY3J5cHQgbWVzc2FnZSB3aXRoIEFFUyBhbGdvcml0aG0g aW4gQ0NNIG1vZGUgd2l0aCBhIGtleTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3 b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGxlbmd0aCBvZiAxMjggYml0czsgaXQgY2FuIGFsc28gYmUgdXNlZCBmb3IgZ2VuZXJhdGlu ZyBNQUMmcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6 YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVmZXJlbmNlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7 YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRp bmc6MGNtIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7UkZDIDQzMDk6PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3Vu ZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVXNpbmcgQWR2YW5jZWQgRW5jcnlwdGlvbiBTdGFu ZGFyZCAoQUVTKSBDQ00gTW9kZSB3aXRoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDojRkZGREY1 O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgSVBzZWMgRW5jYXBzdWxhdGluZyBTZWN1cml0eSBQYXlsb2FkIChF U1ApJnF1b3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJy ZWFrLWFsbDtib3JkZXI6bm9uZTtwYWRkaW5nOjBjbSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4 LjBwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxp PjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUga2V5IHN0ZXAgaXMgdGhhdCBJIHdvdWxkIHNheSB0aGF0 IE5FVENPTkYgc2hvdWxkIG9ubHkgc3RhbmRhcmRpemVzIHRoZSBvbmVzIHRoYXQgd2UgbmVlZCBu b3cuPC9zcGFuPjwvaT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5BIHZlcnkg c3Ryb25nIHllcyBmb3IgdGhpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBs ZXZlbDEgbGZvMyI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxpPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDsgRm9yIHRoZSBvdGhlcnMsIHdlIGNvdWxkIHBvdGVudGlhbGx5IGNyZWF0ZSB0aGUg WUFORyBtb2R1bGVzIGFuZCBlaXRoZXIgaGFuZCB0aGlzIG9mZiB0byB0aGUgc2VjdXJpdHkgZ3Jv dXBzLCBvciB3b3JrIHdoZXRoZXIgdGhlbSB0byBzdGFuZGFyZGl6ZSB0aGVzZSB0aHJvdWdoIHRo ZSBhcHByb3ByaWF0ZSBXR3MuPC9zcGFuPjwvaT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBsYW5nPSJFTi1VUyI+SSB0aGluayBpdCB3b3VsZCBiZSB3b3J0aHdoaWxlIHRvIGNvbnRhY3Qg dGhlIFNlY3VyaXR5IEFE4oCZcyBhbmQgYXNrIGZvciB0aW1lIHRvIHByZXNlbnQgdGhpcyBzb21l d2hlcmUsIGxpa2UgdGhlIG9wZW4gU0FBRyBtZWV0aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIj5bUlddIDxvOnA+ PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNw YW4gbGFuZz0iRU4tVVMiPkkgYWdyZWUgdGhhdCBzZWVtcyBsaWtlIGEgZ29vZCBpZGVhLiZuYnNw OyBCdXQgSSB0aGluayB0aGF0IG5hcnJvd2luZyB0aGUgc2NvcGUgdG8gZ2V0IHRoZXNlIGRvY3Vt ZW50cyBmaW5pc2hlZCBpcyB0aGUgaGlnaGVzdCBwcmlvcml0eS48bzpwPjwvbzpwPjwvc3Bhbj48 L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3MsPGJyPg0KUm9iPG86cD48L286cD48 L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_MN2PR11MB43669B3A47A39FD93B47292FB58F0MN2PR11MB4366namp_-- From nobody Tue Sep 17 07:23:54 2019 Return-Path: <0100016d3f9ba629-c9560411-e18a-4416-a1c7-f66040928d07-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803271208A3 for ; Tue, 17 Sep 2019 07:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 hjQ7sdGGdpGO for ; Tue, 17 Sep 2019 07:23:50 -0700 (PDT) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 198EB12087E for ; Tue, 17 Sep 2019 07:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568730228; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=mRNTk9B6sm/xP/jIFdcZEmmhsvcIiHRzVjtmlviBMcQ=; b=DLZ7xVQJTbBSeHB9r4UC7GjbK8yJaBBllLzD6eXOWP3cNk3Nf3qu+WjqvvkFw72I ZoeeVWgSgKgRPxCKOPUO6q0g1NTGrcwVVKQMzbUJeJTnkqIzADWF529Qhm6ttXDzffE arN+nN9qnR2CjOF7RTorW6yUur3TsTJq7UBEnKt8= From: Kent Watsen Message-ID: <0100016d3f9ba629-c9560411-e18a-4416-a1c7-f66040928d07-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3207F03D-BE60-4424-80F0-5481AD4A0679" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 17 Sep 2019 14:23:48 +0000 In-Reply-To: Cc: "netconf@ietf.org" , Russ Housley , Rifaat Shekh-Yusef , Sean Turner To: "Rob Wilton (rwilton)" References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.17-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 14:23:53 -0000 --Apple-Mail=_3207F03D-BE60-4424-80F0-5481AD4A0679 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Rob (also Rich and Juergen) > [RW] > The full numerical OID string is unique, but very hard to be = interpreted by a human. The human readable OID name (e.g. for just the = last element) is not unique. > =20 > I agree with Juergen, in that I think that using OIDs as names for = encryption protocols is probably a mistake and tying us into the past. I was somewhat expecting that response ;) =20 Fine, now we're aligned to the need to define something for the = "algorithm" field. > [RW] > Oops, my comment about should have been identities rather than = identifiers! > =20 > I think that it is helpful that identities are extensible and can = easily be constructed in a modular way. E.g. defining identities in = different YANG modules, and/or putting them under if-feature allows = implementations to choose which ones they actually support. > =20 > In ietf-crypto-types I would define the base identities for: >=20 > hash-algorithm, asymmetric-key-algorithm, mac-algorithm, = encryption-algorithm, encryption-and-mac-algorithm, signature-algorithm, = key-exchange-algorithm > =20 > Note, as an aside, I am I also wondering whether the = =E2=80=9Cencryption-and-mac-algorithm=E2=80=9D identity should derive = from both =E2=80=9Cmac-algorithm=E2=80=9D and = =E2=80=9Cencryption-algorithm=E2=80=9D? Or perhaps it doesn=E2=80=99t = need to be defined at all, and the actual identities can just derive = from two base identities? > =20 > I then suggest that we put different identities into different YANG = modules, perhaps something roughly like: > Ietf-crypto-sha-types.yang for the SHA hash identities (RFC 6234) > Ietf-crypto-rsa-types for RSA asymmetric-key-algorithm (RC 8017) > Ietf-crypto-elliptic-curve-types for the Elliptic Curve based = algorithms (RFC 6090, 5480, 8422) > Ietf-crypto-mac-types =E2=80=93 I=E2=80=99m not really sure how to = organize the MAC algorithm types, or even if they need to be defined = now. > Ietf-crypto-aes-types =E2=80=93 AES encryption types (RFC 4309) > Ietf-crypto-ssh-types =E2=80=93 das-sha1, rsaasa-pkcs1-sha1 (RFC 4253) > Ietf-crypto-tls-types =E2=80=93 (RFC 8446) > Ietf-cyprto-dhe-types =E2=80=93 Diffier Hellman key exchange (RFC = 7919). Actually, the key-exchanges algorithm types might need to be = split up a bit further. > =20 > The key step is that I would say that NETCONF should only standardizes = the ones that we need now. For the others, we could potentially create = the YANG modules and either hand this off to the security groups, or = work whether them to standardize these through the appropriate WGs. This is a good path forward: flip back to identities and only define the = identities hierarchies needed now. Having multiple modules make sense = (they'd all still be defined in the crypto-types draft). Only possible = discussion point is if these should be "iana-" modules rather than = "ietf-" modules? [The hope being that, if maintained by IANA, it might = be possible to get auto-updates]. >=20 > Perhaps we can do both, say that the field is parsed according to its = "algorithm" value, but for now, all algorithm identifiers happen to = point to ASN.1 structures. > [RW] > Yes, in essence I think that is what I=E2=80=99m suggesting. Sounds good. > If this is really common, then an identity for =E2=80=9CASN.1 = encoded=E2=80=9D could also be defined and inherited by crypto type = identities above. I think that this depends on how useful it is to = programmatically know that they are encoded in ASN.1 Just knowing that it is ASN.1 encoded isn't enough, unless we say all = ASN.1 encoded keys must be a OneSymmetricKey or OneAsymmetricKey (i.e., = option 'B2' from before). Otherwise, the description statement needs = to say something like "This identity indicates that the 'private-key' = node is a DER-encoded RSAPrivateKey and 'public-key' is a DER-encoded = RSAPublicKey." Personally, I think this is okay. An alternative to this may be to use a "choice" statement for = "private-key" whereby one of the options is "asn1". Kent // contributor --Apple-Mail=_3207F03D-BE60-4424-80F0-5481AD4A0679 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Rob (also Rich and Juergen)

[RW]

The full numerical OID string is unique, but very hard to be = interpreted by a human.  The human readable OID name (e.g. for just = the last element) is not unique.

 

I agree with Juergen, in that I think = that using OIDs as names for encryption protocols is probably a mistake = and tying us into the = past.


I was somewhat expecting that response ;) =  

Fine, now we're aligned to = the need to define something for the "algorithm" field.



[RW]

Oops, my comment about should have = been identities rather than identifiers!

 

I think that it is helpful that = identities are extensible and can easily be constructed in a modular = way.  E.g. defining identities in different YANG modules, and/or = putting them under if-feature allows implementations to choose which ones they actually support.

 

In ietf-crypto-types I would define = the base identities for:

hash-algorithm, asymmetric-key-algorithm, mac-algorithm, =
encryption-algorithm, encryption-and-mac-algorithm, signature-algorithm, =
key-exchange-algorithm

 

Note, as an aside, I am I also = wondering whether the =E2=80=9Cencryption-and-mac-algorithm=E2=80=9D identity = should derive from both =E2=80=9Cmac-algorithm=E2=80=9D and = =E2=80=9Cencryption-algorithm=E2=80=9D?  Or perhaps it doesn=E2=80=99= t need to be defined at all, and the actual identities can just derive = from two base identities?

 

I then suggest that we put different identities into = different YANG modules, perhaps something roughly like:

  • Ietf-crypto-sha-types.yang for the SHA hash identities (RFC = 6234)
  • Ietf-crypto-rsa-types for RSA asymmetric-key-algorithm (RC = 8017)
  • Ietf-crypto-elliptic-curve-types for the Elliptic Curve based = algorithms (RFC 6090, 5480, 8422)
  • Ietf-crypto-mac-types =E2=80=93 = I=E2=80=99m not really sure how to organize the MAC algorithm types, or = even if they need to be defined now.
  • Ietf-crypto-aes-types =E2=80=93 = AES encryption types (RFC 4309)
  • Ietf-crypto-ssh-types =E2=80=93 = das-sha1, rsaasa-pkcs1-sha1 (RFC 4253)
  • Ietf-crypto-tls-types =E2=80=93 = (RFC 8446)
  • Ietf-cyprto-dhe-types =E2=80=93 Diffier Hellman key exchange = (RFC 7919).  Actually, the key-exchanges algorithm types might need = to be split up a bit further.

 

The = key step is that I would say that NETCONF should only standardizes the = ones that we need now.  For the others, we could potentially create = the YANG modules and either hand this off to the security groups, or = work whether them to standardize these through the appropriate = WGs.


This is a good path forward: flip back to = identities and only define the identities hierarchies needed now. =  Having multiple modules make sense (they'd all still be defined in = the crypto-types draft).  Only possible discussion point is if = these should be "iana-" modules rather than "ietf-" modules?   [The = hope being that, if maintained by IANA, it might be possible to get = auto-updates].



Perhaps we can do both, say that the field = is parsed according to its "algorithm" value, but for now, all algorithm = identifiers happen to point to ASN.1 structures.

[RW]

Yes, in = essence I think that is what I=E2=80=99m = suggesting.


Sounds good.


 If this is really common, then an = identity for =E2=80=9CASN.1 encoded=E2=80=9D could also be defined and = inherited by crypto type identities above.  I think that this = depends on how useful it is to programmatically know that they are = encoded in ASN.1


Just knowing that it is ASN.1 encoded isn't = enough, unless we say all ASN.1 encoded keys must be a OneSymmetricKey = or OneAsymmetricKey (i.e., option 'B2' from before).   Otherwise, = the description statement needs to say something like "This identity = indicates that the 'private-key' node is a DER-encoded RSAPrivateKey and = 'public-key' is a DER-encoded RSAPublicKey."   Personally, I think = this is okay.

An alternative to this = may be to use a "choice" statement for "private-key" whereby one of the = options is "asn1".



Kent = // contributor


= --Apple-Mail=_3207F03D-BE60-4424-80F0-5481AD4A0679-- From nobody Tue Sep 17 07:42:32 2019 Return-Path: <0100016d3fac842c-22414d8e-ad04-4e56-b2c9-8f25a246affa-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4831208D4 for ; Tue, 17 Sep 2019 07:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 e7YSeZ2EB8cc for ; Tue, 17 Sep 2019 07:42:22 -0700 (PDT) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AB5B1208B7 for ; Tue, 17 Sep 2019 07:42:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568731333; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=CSynvAr32dYoO7/XxQ8JwwX/gx09MpvPcfrvLL4W8EU=; b=nT8WURqtKyT1Tbi4CI711aYTnjtV8F0QPoQmLS9Ne9zH+BnZO64D2YYE8fI5KlH8 KFxVxFUvJQZHlSL6S5FfENXNTv/TO30ymzbW+ku7XigrGpPj4/feNQqmZBZ6nR0743u BBYvize8VOegh9MWWVNEfylJE1AwpvA9Vb4MsITo= From: Kent Watsen Message-ID: <0100016d3fac842c-22414d8e-ad04-4e56-b2c9-8f25a246affa-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_79B36046-637E-4CA0-9741-A907F4294707" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 17 Sep 2019 14:42:13 +0000 In-Reply-To: <20190917.121226.1164447711500530993.mbj@tail-f.com> Cc: zhoutianran@huawei.com, "netconf@ietf.org" To: Martin Bjorklund References: <20190917.115808.1894012459057925338.mbj@tail-f.com> <20190917.121226.1164447711500530993.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.17-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] configuring multi-channels X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 14:42:31 -0000 --Apple-Mail=_79B36046-637E-4CA0-9741-A907F4294707 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Martin, As for why there is a need to configure anything on a per-channel basis, = here are some possible reasons: - different TCP-level parameters (source IP, possibly a VRF) - different TLS-level parameters (TA cert, client cert) - different HTTP-level parameters (basic auth) Does any of this matter? Is the only issue if the receiver can know = which line card sent the message? Or is it needed to enable the = networking connection to be established, which can somehow be different = amongst the line cards? If we purposely shun variations, then the need to configure anything = per-channel goes away, which would make things much easier all around. = But then we'd have to ask, what remains in the multi-stream-originators = draft? Kent // contributor= --Apple-Mail=_79B36046-637E-4CA0-9741-A907F4294707 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Martin,

As for why there is a need to configure anything on a = per-channel basis, here are some possible reasons:

  - different = TCP-level parameters (source IP, possibly a VRF)
  - different TLS-level parameters (TA cert, client = cert)
  - different HTTP-level parameters = (basic auth)

Does any of this matter?  Is the only issue if the = receiver can know which line card sent the message?  Or is it = needed to enable the networking connection to be established, which can = somehow be different amongst the line cards?

If we purposely shun variations, then = the need to configure anything per-channel goes away, which would make = things much easier all around.  But then we'd have to ask, what = remains in the multi-stream-originators draft?

Kent // contributor
= --Apple-Mail=_79B36046-637E-4CA0-9741-A907F4294707-- From nobody Tue Sep 17 07:48:33 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288B512006A for ; Tue, 17 Sep 2019 07:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 rY_oJOjY8rZf for ; Tue, 17 Sep 2019 07:48:29 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 34FCE120856 for ; Tue, 17 Sep 2019 07:48:29 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 83DE01AE0D72; Tue, 17 Sep 2019 16:48:27 +0200 (CEST) Date: Tue, 17 Sep 2019 16:48:03 +0200 (CEST) Message-Id: <20190917.164803.146080986857670528.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: zhoutianran@huawei.com, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016d3fac842c-22414d8e-ad04-4e56-b2c9-8f25a246affa-000000@email.amazonses.com> References: <20190917.121226.1164447711500530993.mbj@tail-f.com> <0100016d3fac842c-22414d8e-ad04-4e56-b2c9-8f25a246affa-000000@email.amazonses.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] configuring multi-channels X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 14:48:31 -0000 Kent Watsen wrote: > > Martin, > > As for why there is a need to configure anything on a per-channel > basis, here are some possible reasons: > > - different TCP-level parameters (source IP, possibly a VRF) Perhaps. But setting this per linecard would require the client to know all the line cards and which IP each line card can use. > - different TLS-level parameters (TA cert, client cert) Do you see a use for this? > - different HTTP-level parameters (basic auth) Do you see a use for this? > Does any of this matter? Is the only issue if the receiver can know > which line card sent the message? Or is it needed to enable the > networking connection to be established, which can somehow be > different amongst the line cards? > > If we purposely shun variations, then the need to configure anything > per-channel goes away, which would make things much easier all around. > But then we'd have to ask, what remains in the > multi-stream-originators draft? I don't know, but if we can solve the problem w/o an additional specification, that seems like a good thing! /martin From nobody Tue Sep 17 08:20:24 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B631208BF for ; Tue, 17 Sep 2019 08:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 NH_abB0rwvu4 for ; Tue, 17 Sep 2019 08:20:20 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A9051208C1 for ; Tue, 17 Sep 2019 08:20:19 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id y23so3959962ljn.5 for ; Tue, 17 Sep 2019 08:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/jGdOyb0n5/WeM/bNkp62PGjeWo3B2AsiMhv/F00Tio=; b=DGj19C2WnN6AbIdkqAfAVI10lVJFav9JeVDQvViaVLO/D1P7UXJYXYjQSZKO29/mvn f//sirRhHQ0n4TGyu2PsYUr7x3j1/fQigI5b2dGlrVjwazgFSPi/XmL143SxlXHVhMDm KAETjPB6a05Ejnp4XMjQyLcNm8wGPWCYPx70lj8RIHGD92zecWcRRjCf6XFYrhgjMYGl lF8qfjhuDOZHeG/Mi7YlA3ZlTtwtZi0ta0+m6MnwwGsQ4sPJGqnjqQq2Rcao031w8ssq 7eutsrdD9hO/GoxPRO1LaJez9E8ptKiP5Z/cfFKJKpI0dSgzMhH51QXNI8UXgC9ScDTK 7yWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/jGdOyb0n5/WeM/bNkp62PGjeWo3B2AsiMhv/F00Tio=; b=gbdsovWvs4fbuc826wEZbXiaE5OwzD6vbwGf5q9uQBdI0JCWdLGcAayz9mn+gVO22N 4pTlnmfsSCnR/CzoQ6gNe8xyg+SNA2MJqDS/noaQV357r3JWltyjIcZeM57DNWHmxv+K i02rHsYKZgstVBFFpl0dEMu5atnA5/Q11lHAjqkFRJ0X6AP1ulhYA61SIqYu7C3rE7LM b7k4mGoLXHgAI6/0zD2yCrsqwr/jx3mpJMLyJMyXqOmTNnK76PO3DchblL50SQOFavTL BP1Uv9QzFlyKzmhBbx2xGAprate2G0AjFDov/kQZi/jXRuWqnD/nWeoTI+bgfmmK8Zbw iZhg== X-Gm-Message-State: APjAAAWsmXHT5+L1hkH3Id0EwVGEFGVnzEQm4eDy8Gj0z522kqMpYSVB lXk/SH65rqtxbjh1xpKcrTqfRHfXeyTJb56yda/L0A== X-Google-Smtp-Source: APXvYqxAmGMSbX/yVGxonsoHTVmi4bi+QlHokHjqmd13I5BZf9tt2xJQ4YCpGXOesGwTeFzcmsUvlXN37ElI3gd95gc= X-Received: by 2002:a2e:860c:: with SMTP id a12mr2176644lji.116.1568733617425; Tue, 17 Sep 2019 08:20:17 -0700 (PDT) MIME-Version: 1.0 References: <20190917.121226.1164447711500530993.mbj@tail-f.com> <0100016d3fac842c-22414d8e-ad04-4e56-b2c9-8f25a246affa-000000@email.amazonses.com> <20190917.164803.146080986857670528.mbj@tail-f.com> In-Reply-To: <20190917.164803.146080986857670528.mbj@tail-f.com> From: Andy Bierman Date: Tue, 17 Sep 2019 08:20:06 -0700 Message-ID: To: Martin Bjorklund Cc: Kent Watsen , Netconf Content-Type: multipart/alternative; boundary="00000000000003a4e70592c14285" Archived-At: Subject: Re: [netconf] configuring multi-channels X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 15:20:23 -0000 --00000000000003a4e70592c14285 Content-Type: text/plain; charset="UTF-8" Hi, On Tue, Sep 17, 2019 at 7:48 AM Martin Bjorklund wrote: > Kent Watsen wrote: > > > > Martin, > > > > As for why there is a need to configure anything on a per-channel > > basis, here are some possible reasons: > > > > - different TCP-level parameters (source IP, possibly a VRF) > > Perhaps. But setting this per linecard would require the client to know > all the line cards and which IP each line card can use. > > > - different TLS-level parameters (TA cert, client cert) > > Do you see a use for this? > > > - different HTTP-level parameters (basic auth) > > Do you see a use for this? > > > > Does any of this matter? Is the only issue if the receiver can know > > which line card sent the message? Or is it needed to enable the > > networking connection to be established, which can somehow be > > different amongst the line cards? > > > > If we purposely shun variations, then the need to configure anything > > per-channel goes away, which would make things much easier all around. > > But then we'd have to ask, what remains in the > > multi-stream-originators draft? > > I don't know, but if we can solve the problem w/o an additional > specification, that seems like a good thing! > > > +1 to all of Martin's concerns. The notification already has a subscription-id, maybe a message-generator-id. Is the proposal to add an arbitrary channel-id to the notification header? It seems simpler and possibly useful to the client to retrieve the read-only message-generator-id that is being used for connection (from this new module). This should not be configurable by the client and a new arbitrary number should not be invented for it. > /martin > Andy > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --00000000000003a4e70592c14285 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,


On Tue, Sep 17, 2019 at= 7:48 AM Martin Bjorklund <mbj@tail-f.com> wrote:
Kent Watsen <kent+ietf@watsen.net> wrote:
>
> Martin,
>
> As for why there is a need to configure anything on a per-channel
> basis, here are some possible reasons:
>
>=C2=A0 =C2=A0- different TCP-level parameters (source IP, possibly a VR= F)

Perhaps.=C2=A0 But setting this per linecard would require the client to kn= ow
all the line cards and which IP each line card can use.

>=C2=A0 =C2=A0- different TLS-level parameters (TA cert, client cert)
Do you see a use for this?

>=C2=A0 =C2=A0- different HTTP-level parameters (basic auth)

Do you see a use for this?


> Does any of this matter?=C2=A0 Is the only issue if the receiver can k= now
> which line card sent the message?=C2=A0 Or is it needed to enable the<= br> > networking connection to be established, which can somehow be
> different amongst the line cards?
>
> If we purposely shun variations, then the need to configure anything > per-channel goes away, which would make things much easier all around.=
> But then we'd have to ask, what remains in the
> multi-stream-originators draft?

I don't know, but if we can solve the problem w/o an additional
specification, that seems like a good thing!




+1 to all of Martin'= ;s concerns.

The notification already has a subscr= iption-id, maybe a message-generator-id.
Is the proposal to add a= n arbitrary channel-id to the notification header?

It seems simpler and possibly useful to the client to retrieve the read-on= ly message-generator-id
that is being used for connection (from t= his new module).=C2=A0
This should not be configurable by the cli= ent and a new arbitrary number should not be invented for it.


=C2=A0
/martin

Andy
=C2=A0

_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--00000000000003a4e70592c14285-- From nobody Tue Sep 17 08:37:04 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5015120045 for ; Tue, 17 Sep 2019 08:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=jzamzgkP; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=c0tSDUrD 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 8woBJj-2dadV for ; Tue, 17 Sep 2019 08:36:59 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B9011200D8 for ; Tue, 17 Sep 2019 08:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36414; q=dns/txt; s=iport; t=1568734619; x=1569944219; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+cDbtbEleinEEwYKunCo5oJP4jdhqJqJx0zaItyXM8w=; b=jzamzgkPwH279I0v9fux5gCrxlm/dWXCG7TdYx0p9OozF84VgDQef9qp W43iXL9euoZaf0j/GiFOf0e7NzYvPILofAm87wsVkoQFxrMan2EQCpFMG 8gn9sI6tfTaG7CtTStdXMo7I6edkSQfKwyhcKTh94b8Gdam5xC0FXfqVY k=; IronPort-PHdr: =?us-ascii?q?9a23=3AWcrh7xc18onkoTO6xy99lPH1lGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGRD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dTM7GNhFUndu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAABk/IBd/49dJa1dCRoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVYCAQEBAQsBgRUvJCwDbVYgBAsqCoQXg0cDineCXH6IZ44?= =?us-ascii?q?NglIDVAkBAQEMAQEtAgEBhD8CF4JlIzcGDgIDCQEBBAEBAQIBBQRthS4MhUo?= =?us-ascii?q?BAQEBAxIRChMBATcBDwIBCBEEAQEhAQkCAgIfER0IAgQOBQgagwGBHU0DHQE?= =?us-ascii?q?Coy4CgTiIYXOBMoJ9AQEFhRQNC4IXCYE0AYo0gUMYgUA/gRFGghc1PoIaggA?= =?us-ascii?q?sFYJ0MoImj1GFJSSIeY4fQQqCIpEBhBuCNYdHjx6PQohcjnACBAIEBQIOAQE?= =?us-ascii?q?FgWgigVhwFYMngkILAReDT4pTc4EpjioBgSIBAQ?= X-IronPort-AV: E=Sophos;i="5.64,517,1559520000"; d="scan'208,217";a="632403432" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Sep 2019 15:36:57 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x8HFavdZ012041 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Sep 2019 15:36:57 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 17 Sep 2019 10:36:57 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 17 Sep 2019 11:36:56 -0400 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 17 Sep 2019 10:36:56 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Fw9VYpJ2fzIHUMjPAZlW3ZYF5z+c7Lxl/IQggtA3nrizzWXcGD/VbR2TAwAYAPFWU2hsBpD8/g4QnkXrR4xD8vI6LGKtmuZ/eKSABCrdva6W4De7GUpR0CLz/peAZYe34wqnY0q7PGvwikoqs+y+SStK+y9XIc57phmjkaI0fsCy+pIEld/AkB34dK4OuOhasmkYe3va6/feV8Gl615YA/VCn61kRshIOY+PLyzBcbC5feiSRslEnpvT/694kHl+TDJ1fmzi/JR9uVrq5qLEBQENEJrw/XH17doxlQh/LTQtmCg1mJ/iKE+jKLByW5cwWW5W+TBd5LhEaGCEz9ugkQ== 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=+cDbtbEleinEEwYKunCo5oJP4jdhqJqJx0zaItyXM8w=; b=bF1kIaEgYJkO4kg2VotHH7xyNeyBM2IxTQNZ+j+GL0K5g51QmdGhHR9dyMPkxKPAzlbcmPNixX2zJauoOn7OiRMhvvXcjs61p/r8W6RjbulOACdclOHgGIf4frTmJHfD0eGkDrNwj0Fvj9B9kW4NVGhIQLq0Wk+Dy9TKIIytnRcnxdnh3AimaO1XBiDSQxml4QRqPYJxAfTGtiBhJX7ut3ygQoNG6pVIWOiGSKzJbTaemul/deW5RKa3wreDi56P0rM6RJYtjMAvZ8icG533lhriKc1pTZO9pxmphxy6waNdVvwS5sqQICY3WKPqJPCNaL4U371DI+0OlkqYWxU04w== 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=+cDbtbEleinEEwYKunCo5oJP4jdhqJqJx0zaItyXM8w=; b=c0tSDUrDKPMZz3uxCRNTO3u5AMgUADgNyeXsQ3veOCoQvOMyamoZHkoCn+NoXqxKSFBRtvip3ztybO6j1mFm4jfD0H27aJRtU97sxUIIWsj45+2XWwDQec85z+gVZgqFWQuiTao6G/UYlCQkJaPlJMpun9pe4db2c0owezB+oTc= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3744.namprd11.prod.outlook.com (20.178.253.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.23; Tue, 17 Sep 2019 15:36:55 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6%7]) with mapi id 15.20.2263.023; Tue, 17 Sep 2019 15:36:55 +0000 From: "Rob Wilton (rwilton)" To: Kent Watsen CC: "netconf@ietf.org" , Russ Housley , Rifaat Shekh-Yusef , "Sean Turner" Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxVu0aQE+n/K0iPwVgOy8FH/KcpQIdQgAVLFQCAARKfAIAAVxYAgAAFC6A= Date: Tue, 17 Sep 2019 15:36:55 +0000 Message-ID: References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@email.amazonses.com> <0100016d3f9ba629-c9560411-e18a-4416-a1c7-f66040928d07-000000@email.amazonses.com> In-Reply-To: <0100016d3f9ba629-c9560411-e18a-4416-a1c7-f66040928d07-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [173.38.220.61] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a905c76c-9f9a-4588-ea74-08d73b84deb7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB3744; x-ms-traffictypediagnostic: MN2PR11MB3744: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01630974C0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(346002)(39860400002)(136003)(376002)(199004)(189003)(51444003)(14454004)(25786009)(256004)(316002)(3846002)(9326002)(76116006)(76176011)(99286004)(66066001)(11346002)(446003)(7696005)(102836004)(476003)(33656002)(5660300002)(478600001)(7736002)(6506007)(53546011)(186003)(74316002)(2906002)(790700001)(54906003)(6246003)(71190400001)(14444005)(4326008)(486006)(6116002)(64756008)(26005)(86362001)(8936002)(6436002)(52536014)(6306002)(81156014)(54896002)(8676002)(9686003)(66946007)(229853002)(66476007)(66446008)(66556008)(81166006)(55016002)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3744; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: etlJGMrGgnPg6iKxkFR2DMD3dWYhLQwl7tYdxNM1+KnKkEgRtDTN8CfeqwOUxXW22d8PDDJNdbJ7ENyoYHJq8em5thzAG0OhcyviIX2FKLFpoenHSHfnGGvwj0YXV7iSdhSkYnrAbL03z332hK+TDaaPZhin1FyiA5IJ1mXvx4lpZCfcq+jT2kYUPdLknhO0/RIDgZlGFd6Fp8Of1fxp2Zi+DMsZIRtRn3Zxq0R7Ww/D5xhnPMnzuaAiF8s0SgLlTxE0EdFw412X5l7FDgoQfbVMQcQIFiENvjMq8Dzxds/uj1A8MAokP3RuoXiL7Jq0/nZcJLVhBbCx1OyvkhLr2lHeQ1EMAQx4sxyinJlJsje7FeM2yr65qKIHU7UwgzuCvDnu0DHYZPiS2VeXFL0PdsPILNNesqCuiO77SAWl66g= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB43669CA5E57F7D4695214E31B58F0MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a905c76c-9f9a-4588-ea74-08d73b84deb7 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2019 15:36:55.2882 (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: v3otR6Ly11Fit+Boe9kVxQXg7B2ZX+sTmUIXMsePmCdYzkCUGsewQ3ZNj4W60SNSuktPIgpqOSE981EaKSTQQA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3744 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 15:37:03 -0000 --_000_MN2PR11MB43669CA5E57F7D4695214E31B58F0MN2PR11MB4366namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2VudCwNCg0KUGxlYXNlIHNlZSBpbmxpbmUg4oCmDQoNCkZyb206IEtlbnQgV2F0c2VuIDxr ZW50K2lldGZAd2F0c2VuLm5ldD4NClNlbnQ6IDE3IFNlcHRlbWJlciAyMDE5IDE1OjI0DQpUbzog Um9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPg0KQ2M6IG5ldGNvbmZAaWV0 Zi5vcmc7IFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+OyBSaWZhYXQgU2hla2gt WXVzZWYgPHJpZmFhdC5pZXRmQGdtYWlsLmNvbT47IFNlYW4gVHVybmVyIDxzZWFuQHNuM3JkLmNv bT4NClN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gY3J5cHRvLXR5cGVzIGZhbGxiYWNrIHN0cmF0ZWd5 DQoNCkhpIFJvYiAoYWxzbyBSaWNoIGFuZCBKdWVyZ2VuKQ0KDQpbUlddDQpUaGUgZnVsbCBudW1l cmljYWwgT0lEIHN0cmluZyBpcyB1bmlxdWUsIGJ1dCB2ZXJ5IGhhcmQgdG8gYmUgaW50ZXJwcmV0 ZWQgYnkgYSBodW1hbi4gIFRoZSBodW1hbiByZWFkYWJsZSBPSUQgbmFtZSAoZS5nLiBmb3IganVz dCB0aGUgbGFzdCBlbGVtZW50KSBpcyBub3QgdW5pcXVlLg0KDQpJIGFncmVlIHdpdGggSnVlcmdl biwgaW4gdGhhdCBJIHRoaW5rIHRoYXQgdXNpbmcgT0lEcyBhcyBuYW1lcyBmb3IgZW5jcnlwdGlv biBwcm90b2NvbHMgaXMgcHJvYmFibHkgYSBtaXN0YWtlIGFuZCB0eWluZyB1cyBpbnRvIHRoZSBw YXN0Lg0KDQpJIHdhcyBzb21ld2hhdCBleHBlY3RpbmcgdGhhdCByZXNwb25zZSA7KQ0KDQpGaW5l LCBub3cgd2UncmUgYWxpZ25lZCB0byB0aGUgbmVlZCB0byBkZWZpbmUgc29tZXRoaW5nIGZvciB0 aGUgImFsZ29yaXRobSIgZmllbGQuDQoNCltSV10NCk9LDQoNCg0KW1JXXQ0KT29wcywgbXkgY29t bWVudCBhYm91dCBzaG91bGQgaGF2ZSBiZWVuIGlkZW50aXRpZXMgcmF0aGVyIHRoYW4gaWRlbnRp ZmllcnMhDQoNCkkgdGhpbmsgdGhhdCBpdCBpcyBoZWxwZnVsIHRoYXQgaWRlbnRpdGllcyBhcmUg ZXh0ZW5zaWJsZSBhbmQgY2FuIGVhc2lseSBiZSBjb25zdHJ1Y3RlZCBpbiBhIG1vZHVsYXIgd2F5 LiAgRS5nLiBkZWZpbmluZyBpZGVudGl0aWVzIGluIGRpZmZlcmVudCBZQU5HIG1vZHVsZXMsIGFu ZC9vciBwdXR0aW5nIHRoZW0gdW5kZXIgaWYtZmVhdHVyZSBhbGxvd3MgaW1wbGVtZW50YXRpb25z IHRvIGNob29zZSB3aGljaCBvbmVzIHRoZXkgYWN0dWFsbHkgc3VwcG9ydC4NCg0KSW4gaWV0Zi1j cnlwdG8tdHlwZXMgSSB3b3VsZCBkZWZpbmUgdGhlIGJhc2UgaWRlbnRpdGllcyBmb3I6DQoNCg0K DQpoYXNoLWFsZ29yaXRobSwgYXN5bW1ldHJpYy1rZXktYWxnb3JpdGhtLCBtYWMtYWxnb3JpdGht LCBlbmNyeXB0aW9uLWFsZ29yaXRobSwgZW5jcnlwdGlvbi1hbmQtbWFjLWFsZ29yaXRobSwgc2ln bmF0dXJlLWFsZ29yaXRobSwga2V5LWV4Y2hhbmdlLWFsZ29yaXRobQ0KDQpOb3RlLCBhcyBhbiBh c2lkZSwgSSBhbSBJIGFsc28gd29uZGVyaW5nIHdoZXRoZXIgdGhlIOKAnGVuY3J5cHRpb24tYW5k LW1hYy1hbGdvcml0aG3igJ0gaWRlbnRpdHkgc2hvdWxkIGRlcml2ZSBmcm9tIGJvdGgg4oCcbWFj LWFsZ29yaXRobeKAnSBhbmQg4oCcZW5jcnlwdGlvbi1hbGdvcml0aG3igJ0/ICBPciBwZXJoYXBz IGl0IGRvZXNu4oCZdCBuZWVkIHRvIGJlIGRlZmluZWQgYXQgYWxsLCBhbmQgdGhlIGFjdHVhbCBp ZGVudGl0aWVzIGNhbiBqdXN0IGRlcml2ZSBmcm9tIHR3byBiYXNlIGlkZW50aXRpZXM/DQoNCkkg dGhlbiBzdWdnZXN0IHRoYXQgd2UgcHV0IGRpZmZlcmVudCBpZGVudGl0aWVzIGludG8gZGlmZmVy ZW50IFlBTkcgbW9kdWxlcywgcGVyaGFwcyBzb21ldGhpbmcgcm91Z2hseSBsaWtlOg0KDQrCtyAg ICAgICAgSWV0Zi1jcnlwdG8tc2hhLXR5cGVzLnlhbmcgZm9yIHRoZSBTSEEgaGFzaCBpZGVudGl0 aWVzIChSRkMgNjIzNCkNCg0KwrcgICAgICAgIElldGYtY3J5cHRvLXJzYS10eXBlcyBmb3IgUlNB IGFzeW1tZXRyaWMta2V5LWFsZ29yaXRobSAoUkMgODAxNykNCg0KwrcgICAgICAgIElldGYtY3J5 cHRvLWVsbGlwdGljLWN1cnZlLXR5cGVzIGZvciB0aGUgRWxsaXB0aWMgQ3VydmUgYmFzZWQgYWxn b3JpdGhtcyAoUkZDIDYwOTAsIDU0ODAsIDg0MjIpDQoNCsK3ICAgICAgICBJZXRmLWNyeXB0by1t YWMtdHlwZXMg4oCTIEnigJltIG5vdCByZWFsbHkgc3VyZSBob3cgdG8gb3JnYW5pemUgdGhlIE1B QyBhbGdvcml0aG0gdHlwZXMsIG9yIGV2ZW4gaWYgdGhleSBuZWVkIHRvIGJlIGRlZmluZWQgbm93 Lg0KDQrCtyAgICAgICAgSWV0Zi1jcnlwdG8tYWVzLXR5cGVzIOKAkyBBRVMgZW5jcnlwdGlvbiB0 eXBlcyAoUkZDIDQzMDkpDQoNCsK3ICAgICAgICBJZXRmLWNyeXB0by1zc2gtdHlwZXMg4oCTIGRh cy1zaGExLCByc2Fhc2EtcGtjczEtc2hhMSAoUkZDIDQyNTMpDQoNCsK3ICAgICAgICBJZXRmLWNy eXB0by10bHMtdHlwZXMg4oCTIChSRkMgODQ0NikNCg0KwrcgICAgICAgIElldGYtY3lwcnRvLWRo ZS10eXBlcyDigJMgRGlmZmllciBIZWxsbWFuIGtleSBleGNoYW5nZSAoUkZDIDc5MTkpLiAgQWN0 dWFsbHksIHRoZSBrZXktZXhjaGFuZ2VzIGFsZ29yaXRobSB0eXBlcyBtaWdodCBuZWVkIHRvIGJl IHNwbGl0IHVwIGEgYml0IGZ1cnRoZXIuDQoNClRoZSBrZXkgc3RlcCBpcyB0aGF0IEkgd291bGQg c2F5IHRoYXQgTkVUQ09ORiBzaG91bGQgb25seSBzdGFuZGFyZGl6ZXMgdGhlIG9uZXMgdGhhdCB3 ZSBuZWVkIG5vdy4gIEZvciB0aGUgb3RoZXJzLCB3ZSBjb3VsZCBwb3RlbnRpYWxseSBjcmVhdGUg dGhlIFlBTkcgbW9kdWxlcyBhbmQgZWl0aGVyIGhhbmQgdGhpcyBvZmYgdG8gdGhlIHNlY3VyaXR5 IGdyb3Vwcywgb3Igd29yayB3aGV0aGVyIHRoZW0gdG8gc3RhbmRhcmRpemUgdGhlc2UgdGhyb3Vn aCB0aGUgYXBwcm9wcmlhdGUgV0dzLg0KDQpUaGlzIGlzIGEgZ29vZCBwYXRoIGZvcndhcmQ6IGZs aXAgYmFjayB0byBpZGVudGl0aWVzIGFuZCBvbmx5IGRlZmluZSB0aGUgaWRlbnRpdGllcyBoaWVy YXJjaGllcyBuZWVkZWQgbm93LiAgSGF2aW5nIG11bHRpcGxlIG1vZHVsZXMgbWFrZSBzZW5zZSAo dGhleSdkIGFsbCBzdGlsbCBiZSBkZWZpbmVkIGluIHRoZSBjcnlwdG8tdHlwZXMgZHJhZnQpLiAg T25seSBwb3NzaWJsZSBkaXNjdXNzaW9uIHBvaW50IGlzIGlmIHRoZXNlIHNob3VsZCBiZSAiaWFu YS0iIG1vZHVsZXMgcmF0aGVyIHRoYW4gImlldGYtIiBtb2R1bGVzPyAgIFtUaGUgaG9wZSBiZWlu ZyB0aGF0LCBpZiBtYWludGFpbmVkIGJ5IElBTkEsIGl0IG1pZ2h0IGJlIHBvc3NpYmxlIHRvIGdl dCBhdXRvLXVwZGF0ZXNdLg0KW1JXXQ0KSUFOQSBtaWdodCBiZSBPSywgSeKAmW0gbm90IHN1cmUu DQoNCk15IG9yaWdpbmFsIHRob3VnaHQgd2FzIHRoYXQgaWYgYSBuZXcgc2VjdXJpdHkgUkZDIGlz IHdyaXR0ZW4gdGhlbiBpdCBjb3VsZCBob3BlZnVsbHkgYWxzbyBkZWZpbmUgYSBZQU5HIG1vZHVs ZSB0aGF0IGRlZmluZXMgdGhlIG5ldyBpZGVudGl0aWVzIHJlbGF0ZWQgdG8gdGhhdCBzZWN1cml0 eSBwcm90b2NvbC4gIEJ1dCB0aGF0IG1heSB3ZWxsIGRlcGVuZCBvbiB0aGUgc2NvcGUgb2YgdGhl IFJGQy4NCg0KRS5nLiBsb29raW5nIGF0IHNheSBkcmFmdC1pZXRmLWN1cmRsZS1zc2gtZWQyNTUx OS1lZDQ0OC0xMS50eHQsIHRoYXQgaGFzIGp1c3QgYmVlbiBhcHByb3ZlZCBieSB0aGUgSUVTRywg aXQgd291bGQgc2VlbSB0aGF0IHRoaXMgY291bGQgcHJvYmFibHkganVzdCB1cGRhdGUgaWFuYS1j cnlwdG8tc3NoLXR5cGVzIHdpdGggc29tZSBuZXcgaWRlbnRpdGllcy4gIEJ1dCBvdGhlciBkb2N1 bWVudHMgbWlnaHQgbmVlZCB0byBpbnRyb2R1Y2UgbmV3IGNhdGVnb3JpZXMgKGkuZS4gbmV3IGNy eXB0byB0eXBlcyBtb2R1bGVzKSBhbHRvZ2V0aGVyLCB3aGljaCBJIHRoaW5rIGlzIE9LLg0KDQoN Cg0KDQoNClBlcmhhcHMgd2UgY2FuIGRvIGJvdGgsIHNheSB0aGF0IHRoZSBmaWVsZCBpcyBwYXJz ZWQgYWNjb3JkaW5nIHRvIGl0cyAiYWxnb3JpdGhtIiB2YWx1ZSwgYnV0IGZvciBub3csIGFsbCBh bGdvcml0aG0gaWRlbnRpZmllcnMgaGFwcGVuIHRvIHBvaW50IHRvIEFTTi4xIHN0cnVjdHVyZXMu DQpbUlddDQpZZXMsIGluIGVzc2VuY2UgSSB0aGluayB0aGF0IGlzIHdoYXQgSeKAmW0gc3VnZ2Vz dGluZy4NCg0KU291bmRzIGdvb2QuDQoNCg0KDQoNCiBJZiB0aGlzIGlzIHJlYWxseSBjb21tb24s IHRoZW4gYW4gaWRlbnRpdHkgZm9yIOKAnEFTTi4xIGVuY29kZWTigJ0gY291bGQgYWxzbyBiZSBk ZWZpbmVkIGFuZCBpbmhlcml0ZWQgYnkgY3J5cHRvIHR5cGUgaWRlbnRpdGllcyBhYm92ZS4gIEkg dGhpbmsgdGhhdCB0aGlzIGRlcGVuZHMgb24gaG93IHVzZWZ1bCBpdCBpcyB0byBwcm9ncmFtbWF0 aWNhbGx5IGtub3cgdGhhdCB0aGV5IGFyZSBlbmNvZGVkIGluIEFTTi4xDQoNCkp1c3Qga25vd2lu ZyB0aGF0IGl0IGlzIEFTTi4xIGVuY29kZWQgaXNuJ3QgZW5vdWdoLCB1bmxlc3Mgd2Ugc2F5IGFs bCBBU04uMSBlbmNvZGVkIGtleXMgbXVzdCBiZSBhIE9uZVN5bW1ldHJpY0tleSBvciBPbmVBc3lt bWV0cmljS2V5IChpLmUuLCBvcHRpb24gJ0IyJyBmcm9tIGJlZm9yZSkuDQoNCg0KICBPdGhlcndp c2UsIHRoZSBkZXNjcmlwdGlvbiBzdGF0ZW1lbnQgbmVlZHMgdG8gc2F5IHNvbWV0aGluZyBsaWtl ICJUaGlzIGlkZW50aXR5IGluZGljYXRlcyB0aGF0IHRoZSAncHJpdmF0ZS1rZXknIG5vZGUgaXMg YSBERVItZW5jb2RlZCBSU0FQcml2YXRlS2V5IGFuZCAncHVibGljLWtleScgaXMgYSBERVItZW5j b2RlZCBSU0FQdWJsaWNLZXkuIiAgIFBlcnNvbmFsbHksIEkgdGhpbmsgdGhpcyBpcyBva2F5Lg0K W1JXXQ0KT0ssIHNvIHRoaXMgaXMgd2hlcmUgSSBhbSBiZXlvbmQgdGhlIGJvdW5kYXJ5IG9mIG15 IGtub3dsZWRnZSwgYW5kIGRvbuKAmXQgcmVhbGx5IGtub3cgaG93IGtleXMgYXJlIHByb2dyYW1t YXRpY2FsbHkgdXNlZCwgYnV0IG15IGh1bmNoIGlzIHRoYXQgIlRoaXMgaWRlbnRpdHkgaW5kaWNh dGVzIHRoYXQgdGhlICdwcml2YXRlLWtleScgbm9kZSBpcyBhIERFUi1lbmNvZGVkIFJTQVByaXZh dGVLZXkgYW5kICdwdWJsaWMta2V5JyBpcyBhIERFUi1lbmNvZGVkIFJTQVB1YmxpY0tleeKAnSBz b3VuZHMgbGlrZSB0aGUgcmlnaHQgb3B0aW9uLiAgSSB0aGluayB0aGF0IHdlIHdhbnQgdGhlIGtl eXMgdG8gYmUgaW4gd2hhdGV2ZXIgZm9ybSBhcHBsaWNhdGlvbnMgY2FuIG1vc3QgcmVhZGlseSB1 c2UgdGhlbSB3aXRob3V0IGhhdmluZyB0byBwZXJmb3JtIGFuIGFyYml0cmFyeSBjb252ZXJzaW9u Lg0KDQpUaGFua3MsDQpSb2INCg0KDQoNCkFuIGFsdGVybmF0aXZlIHRvIHRoaXMgbWF5IGJlIHRv IHVzZSBhICJjaG9pY2UiIHN0YXRlbWVudCBmb3IgInByaXZhdGUta2V5IiB3aGVyZWJ5IG9uZSBv ZiB0aGUgb3B0aW9ucyBpcyAiYXNuMSIuDQoNCg0KDQpLZW50IC8vIGNvbnRyaWJ1dG9yDQoNCg0K --_000_MN2PR11MB43669CA5E57F7D4695214E31B58F0MN2PR11MB4366namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0 UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7 DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBj bTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkhU TUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHls ZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBs aXN0IGwwDQoJe21zby1saXN0LWlkOjY4MDU0NTk3MzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 MTc3MTM1NTcxMDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFy Z2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgS2VudCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UGxlYXNlIHNlZSBpbmxpbmUg 4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IEtlbnQgV2F0c2VuICZsdDtrZW50JiM0Mztp ZXRmQHdhdHNlbi5uZXQmZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMTcgU2VwdGVtYmVyIDIwMTkg MTU6MjQ8YnI+DQo8Yj5Ubzo8L2I+IFJvYiBXaWx0b24gKHJ3aWx0b24pICZsdDtyd2lsdG9uQGNp c2NvLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IG5ldGNvbmZAaWV0Zi5vcmc7IFJ1c3MgSG91c2xl eSAmbHQ7aG91c2xleUB2aWdpbHNlYy5jb20mZ3Q7OyBSaWZhYXQgU2hla2gtWXVzZWYgJmx0O3Jp ZmFhdC5pZXRmQGdtYWlsLmNvbSZndDs7IFNlYW4gVHVybmVyICZsdDtzZWFuQHNuM3JkLmNvbSZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRjb25mXSBjcnlwdG8tdHlwZXMgZmFsbGJh Y2sgc3RyYXRlZ3k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+SGkgUm9iIChhbHNvIFJpY2ggYW5kIEp1ZXJnZW4pPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPGk+W1JXXTwvaT48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0K PGk+VGhlIGZ1bGwgbnVtZXJpY2FsIE9JRCBzdHJpbmcgaXMgdW5pcXVlLCBidXQgdmVyeSBoYXJk IHRvIGJlIGludGVycHJldGVkIGJ5IGEgaHVtYW4uJm5ic3A7IFRoZSBodW1hbiByZWFkYWJsZSBP SUQgbmFtZSAoZS5nLiBmb3IganVzdCB0aGUgbGFzdCBlbGVtZW50KSBpcyBub3QgdW5pcXVlLjwv aT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4w cHQiPg0KPGk+Jm5ic3A7PC9pPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8aT5JIGFncmVlIHdpdGggSnVlcmdlbiwgaW4gdGhhdCBJ IHRoaW5rIHRoYXQgdXNpbmcgT0lEcyBhcyBuYW1lcyBmb3IgZW5jcnlwdGlvbiBwcm90b2NvbHMg aXMgcHJvYmFibHkgYSBtaXN0YWtlIGFuZCB0eWluZyB1cyBpbnRvIHRoZSBwYXN0LjwvaT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SSB3YXMgc29tZXdoYXQgZXhwZWN0aW5nIHRo YXQgcmVzcG9uc2UgOykgJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPkZpbmUsIG5vdyB3ZSdyZSBhbGlnbmVkIHRvIHRoZSBuZWVkIHRvIGRl ZmluZSBzb21ldGhpbmcgZm9yIHRoZSAmcXVvdDthbGdvcml0aG0mcXVvdDsgZmllbGQuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxpPltSV10gPG86cD48L286cD48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxpPk9LPC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MzYuMHB0Ij4NCjxpPltSV10gPC9pPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8aT5Pb3BzLCBteSBjb21tZW50IGFib3V0IHNo b3VsZCBoYXZlIGJlZW4gaWRlbnRpdGllcyByYXRoZXIgdGhhbiBpZGVudGlmaWVycyE8L2k+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4N CjxpPiZuYnNwOzwvaT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDozNi4wcHQiPg0KPGk+SSB0aGluayB0aGF0IGl0IGlzIGhlbHBmdWwgdGhhdCBpZGVu dGl0aWVzIGFyZSBleHRlbnNpYmxlIGFuZCBjYW4gZWFzaWx5IGJlIGNvbnN0cnVjdGVkIGluIGEg bW9kdWxhciB3YXkuJm5ic3A7IEUuZy4gZGVmaW5pbmcgaWRlbnRpdGllcyBpbiBkaWZmZXJlbnQg WUFORyBtb2R1bGVzLCBhbmQvb3IgcHV0dGluZyB0aGVtIHVuZGVyIGlmLWZlYXR1cmUgYWxsb3dz IGltcGxlbWVudGF0aW9ucyB0byBjaG9vc2Ugd2hpY2ggb25lcyB0aGV5IGFjdHVhbGx5DQogc3Vw cG9ydC48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MzYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8aT5JbiBpZXRmLWNyeXB0by10eXBlcyBJIHdvdWxkIGRl ZmluZSB0aGUgYmFzZSBpZGVudGl0aWVzIGZvcjo8YnI+DQo8YnI+DQo8YnI+DQo8L2k+PG86cD48 L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjguMHB0IDguMHB0IDguMHB0IDguMHB0Ij4NCjxwcmUgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjcuOXB0O21hcmdpbi1sZWZ0OjM2 LjBwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0Ij5oYXNoLWFsZ29yaXRobSwgYXN5bW1ldHJpYy1rZXktYWxnb3Jp dGhtLCBtYWMtYWxnb3JpdGhtLCBlbmNyeXB0aW9uLWFsZ29yaXRobSwgZW5jcnlwdGlvbi1hbmQt bWFjLWFsZ29yaXRobSwgc2lnbmF0dXJlLWFsZ29yaXRobSwga2V5LWV4Y2hhbmdlLWFsZ29yaXRo bTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8aT5Ob3RlLCBhcyBhbiBhc2lkZSwgSSBh bSBJIGFsc28gd29uZGVyaW5nIHdoZXRoZXIgdGhlIOKAnDwvaT48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdCI+ZW5jcnlwdGlvbi1hbmQtbWFjLWFsZ29yaXRobeKAnSBpZGVudGl0eSBz aG91bGQgZGVyaXZlIGZyb20gYm90aCDigJxtYWMtYWxnb3JpdGht4oCdIGFuZCDigJxlbmNyeXB0 aW9uLWFsZ29yaXRobeKAnT8mbmJzcDsgT3IgcGVyaGFwcyBpdCBkb2VzbuKAmXQgbmVlZCB0byBi ZSBkZWZpbmVkIGF0IGFsbCwgYW5kIHRoZQ0KIGFjdHVhbCBpZGVudGl0aWVzIGNhbiBqdXN0IGRl cml2ZSBmcm9tIHR3byBiYXNlIGlkZW50aXRpZXM/PC9zcGFuPjwvaT48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOzwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxpPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0Ij5JIHRoZW4gc3VnZ2VzdCB0aGF0IHdlIHB1dCBkaWZmZXJlbnQg aWRlbnRpdGllcyBpbnRvIGRpZmZlcmVudCBZQU5HIG1vZHVsZXMsIHBlcmhhcHMgc29tZXRoaW5n IHJvdWdobHkgbGlrZTo8L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBw dDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdCI+SWV0Zi1jcnlwdG8tc2hhLXR5cGVzLnlhbmcgZm9yIHRoZSBTSEEgaGFzaCBpZGVu dGl0aWVzIChSRkMgNjIzNCk8L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4 LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48aT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdCI+SWV0Zi1jcnlwdG8tcnNhLXR5cGVzIGZvciBSU0EgYXN5bW1ldHJpYy1rZXkt YWxnb3JpdGhtIChSQyA4MDE3KTwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDot MTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxpPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0Ij5JZXRmLWNyeXB0by1lbGxpcHRpYy1jdXJ2ZS10eXBlcyBmb3IgdGhlIEVs bGlwdGljIEN1cnZlIGJhc2VkIGFsZ29yaXRobXMgKFJGQyA2MDkwLCA1NDgwLCA4NDIyKTwvc3Bh bj48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVs MSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5JZXRmLWNyeXB0 by1tYWMtdHlwZXMg4oCTIEnigJltIG5vdCByZWFsbHkgc3VyZSBob3cgdG8gb3JnYW5pemUgdGhl IE1BQyBhbGdvcml0aG0gdHlwZXMsIG9yIGV2ZW4gaWYgdGhleSBuZWVkIHRvIGJlIGRlZmluZWQg bm93Ljwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5J ZXRmLWNyeXB0by1hZXMtdHlwZXMg4oCTIEFFUyBlbmNyeXB0aW9uIHR5cGVzIChSRkMgNDMwOSk8 L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+SWV0Zi1j cnlwdG8tc3NoLXR5cGVzIOKAkyBkYXMtc2hhMSwgcnNhYXNhLXBrY3MxLXNoYTEgKFJGQyA0MjUz KTwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Omww IGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij5JZXRm LWNyeXB0by10bHMtdHlwZXMg4oCTIChSRkMgODQ0Nik8L3NwYW4+PC9pPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7 dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1i b2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48aT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+SWV0Zi1jeXBydG8tZGhlLXR5cGVzIOKAkyBEaWZm aWVyIEhlbGxtYW4ga2V5IGV4Y2hhbmdlIChSRkMgNzkxOSkuJm5ic3A7IEFjdHVhbGx5LCB0aGUg a2V5LWV4Y2hhbmdlcyBhbGdvcml0aG0gdHlwZXMgbWlnaHQgbmVlZCB0byBiZSBzcGxpdCB1cCBh IGJpdCBmdXJ0aGVyLjwvc3Bhbj48L2k+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxpPiZuYnNwOzwvaT48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPGk+VGhlIGtleSBz dGVwIGlzIHRoYXQgSSB3b3VsZCBzYXkgdGhhdCBORVRDT05GIHNob3VsZCBvbmx5IHN0YW5kYXJk aXplcyB0aGUgb25lcyB0aGF0IHdlIG5lZWQgbm93LiZuYnNwOyBGb3IgdGhlIG90aGVycywgd2Ug Y291bGQgcG90ZW50aWFsbHkgY3JlYXRlIHRoZSBZQU5HIG1vZHVsZXMgYW5kIGVpdGhlciBoYW5k IHRoaXMgb2ZmIHRvIHRoZSBzZWN1cml0eSBncm91cHMsIG9yIHdvcmsgd2hldGhlciB0aGVtIHRv IHN0YW5kYXJkaXplIHRoZXNlIHRocm91Z2gNCiB0aGUgYXBwcm9wcmlhdGUgV0dzLjwvaT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5UaGlzIGlzIGEgZ29vZCBwYXRo IGZvcndhcmQ6IGZsaXAgYmFjayB0byBpZGVudGl0aWVzIGFuZCBvbmx5IGRlZmluZSB0aGUgaWRl bnRpdGllcyBoaWVyYXJjaGllcyBuZWVkZWQgbm93LiAmbmJzcDtIYXZpbmcgbXVsdGlwbGUgbW9k dWxlcyBtYWtlIHNlbnNlICh0aGV5J2QgYWxsIHN0aWxsIGJlIGRlZmluZWQgaW4gdGhlIGNyeXB0 by10eXBlcyBkcmFmdCkuICZuYnNwO09ubHkgcG9zc2libGUNCiBkaXNjdXNzaW9uIHBvaW50IGlz IGlmIHRoZXNlIHNob3VsZCBiZSAmcXVvdDtpYW5hLSZxdW90OyBtb2R1bGVzIHJhdGhlciB0aGFu ICZxdW90O2lldGYtJnF1b3Q7IG1vZHVsZXM/ICZuYnNwOyBbVGhlIGhvcGUgYmVpbmcgdGhhdCwg aWYgbWFpbnRhaW5lZCBieSBJQU5BLCBpdCBtaWdodCBiZSBwb3NzaWJsZSB0byBnZXQgYXV0by11 cGRhdGVzXS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPltSV10g PG86cD48L286cD48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPklBTkEg bWlnaHQgYmUgT0ssIEnigJltIG5vdCBzdXJlLjxvOnA+PC9vOnA+PC9pPjwvYj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48aT48bzpwPiZuYnNwOzwvbzpwPjwvaT48L2I+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+TXkgb3JpZ2luYWwgdGhvdWdodCB3YXMgdGhhdCBpZiBh IG5ldyBzZWN1cml0eSBSRkMgaXMgd3JpdHRlbiB0aGVuIGl0IGNvdWxkIGhvcGVmdWxseSBhbHNv IGRlZmluZSBhIFlBTkcgbW9kdWxlIHRoYXQgZGVmaW5lcyB0aGUgbmV3IGlkZW50aXRpZXMgcmVs YXRlZCB0byB0aGF0IHNlY3VyaXR5IHByb3RvY29sLiZuYnNwOyBCdXQgdGhhdCBtYXkgd2VsbCBk ZXBlbmQgb24gdGhlIHNjb3BlIG9mIHRoZSBSRkMuPG86cD48L286cD48L2k+PC9iPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxvOnA+Jm5ic3A7PC9vOnA+PC9pPjwvYj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT5FLmcuIGxvb2tpbmcgYXQgc2F5IGRyYWZ0LWlldGYt Y3VyZGxlLXNzaC1lZDI1NTE5LWVkNDQ4LTExLnR4dCwgdGhhdCBoYXMganVzdCBiZWVuIGFwcHJv dmVkIGJ5IHRoZSBJRVNHLCBpdCB3b3VsZCBzZWVtIHRoYXQgdGhpcyBjb3VsZCBwcm9iYWJseSBq dXN0IHVwZGF0ZSBpYW5hLWNyeXB0by1zc2gtdHlwZXMgd2l0aCBzb21lIG5ldyBpZGVudGl0aWVz LiZuYnNwOyBCdXQgb3RoZXIgZG9jdW1lbnRzIG1pZ2h0DQogbmVlZCB0byBpbnRyb2R1Y2UgbmV3 IGNhdGVnb3JpZXMgKGkuZS4gbmV3IGNyeXB0byB0eXBlcyBtb2R1bGVzKSBhbHRvZ2V0aGVyLCB3 aGljaCBJIHRoaW5rIGlzIE9LLjxvOnA+PC9vOnA+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NClBlcmhhcHMgd2UgY2FuIGRvIGJvdGgsIHNh eSB0aGF0IHRoZSBmaWVsZCBpcyBwYXJzZWQgYWNjb3JkaW5nIHRvIGl0cyAmcXVvdDthbGdvcml0 aG0mcXVvdDsgdmFsdWUsIGJ1dCBmb3Igbm93LCBhbGwgYWxnb3JpdGhtIGlkZW50aWZpZXJzIGhh cHBlbiB0byBwb2ludCB0byBBU04uMSBzdHJ1Y3R1cmVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8aT5bUlddIDwvaT48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPGk+ WWVzLCBpbiBlc3NlbmNlIEkgdGhpbmsgdGhhdCBpcyB3aGF0IEnigJltIHN1Z2dlc3RpbmcuPC9p PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5Tb3VuZHMgZ29vZC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8aT4m bmJzcDtJZiB0aGlzIGlzIHJlYWxseSBjb21tb24sIHRoZW4gYW4gaWRlbnRpdHkgZm9yIOKAnEFT Ti4xIGVuY29kZWTigJ0gY291bGQgYWxzbyBiZSBkZWZpbmVkIGFuZCBpbmhlcml0ZWQgYnkgY3J5 cHRvIHR5cGUgaWRlbnRpdGllcyBhYm92ZS4mbmJzcDsgSSB0aGluayB0aGF0IHRoaXMgZGVwZW5k cyBvbiBob3cgdXNlZnVsIGl0IGlzIHRvIHByb2dyYW1tYXRpY2FsbHkga25vdyB0aGF0IHRoZXkg YXJlIGVuY29kZWQgaW4gQVNOLjE8L2k+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi Pkp1c3Qga25vd2luZyB0aGF0IGl0IGlzIEFTTi4xIGVuY29kZWQgaXNuJ3QgZW5vdWdoLCB1bmxl c3Mgd2Ugc2F5IGFsbCBBU04uMSBlbmNvZGVkIGtleXMgbXVzdCBiZSBhIE9uZVN5bW1ldHJpY0tl eSBvciBPbmVBc3ltbWV0cmljS2V5IChpLmUuLCBvcHRpb24gJ0IyJyBmcm9tIGJlZm9yZSkuDQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPiZuYnNwOzxvOnA+PC9v OnA+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48bzpwPiZuYnNwOzwv bzpwPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+Jm5ic3A7IE90aGVyd2lzZSwgdGhlIGRlc2NyaXB0aW9uIHN0YXRlbWVudCBuZWVk cyB0byBzYXkgc29tZXRoaW5nIGxpa2UgJnF1b3Q7VGhpcyBpZGVudGl0eSBpbmRpY2F0ZXMgdGhh dCB0aGUgJ3ByaXZhdGUta2V5JyBub2RlIGlzIGEgREVSLWVuY29kZWQgUlNBUHJpdmF0ZUtleSBh bmQgJ3B1YmxpYy1rZXknIGlzIGEgREVSLWVuY29kZWQgUlNBUHVibGljS2V5LiZxdW90OyAmbmJz cDsgUGVyc29uYWxseSwNCiBJIHRoaW5rIHRoaXMgaXMgb2theS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPltSV10gPG86cD48L286cD48L2k+PC9iPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPk9LLCBzbyB0aGlzIGlzIHdoZXJlIEkgYW0gYmV5b25k IHRoZSBib3VuZGFyeSBvZiBteSBrbm93bGVkZ2UsIGFuZCBkb27igJl0IHJlYWxseSBrbm93IGhv dyBrZXlzIGFyZSBwcm9ncmFtbWF0aWNhbGx5IHVzZWQsIGJ1dCBteSBodW5jaCBpcyB0aGF0ICZx dW90O1RoaXMgaWRlbnRpdHkgaW5kaWNhdGVzIHRoYXQgdGhlICdwcml2YXRlLWtleScgbm9kZSBp cyBhIERFUi1lbmNvZGVkIFJTQVByaXZhdGVLZXkgYW5kDQogJ3B1YmxpYy1rZXknIGlzIGEgREVS LWVuY29kZWQgUlNBUHVibGljS2V54oCdIHNvdW5kcyBsaWtlIHRoZSByaWdodCBvcHRpb24uJm5i c3A7IEkgdGhpbmsgdGhhdCB3ZSB3YW50IHRoZSBrZXlzIHRvIGJlIGluIHdoYXRldmVyIGZvcm0g YXBwbGljYXRpb25zIGNhbiBtb3N0IHJlYWRpbHkgdXNlIHRoZW0gd2l0aG91dCBoYXZpbmcgdG8g cGVyZm9ybSBhbiBhcmJpdHJhcnkgY29udmVyc2lvbi48bzpwPjwvbzpwPjwvaT48L2I+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PG86cD4mbmJzcDs8L286cD48L2k+PC9iPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPlRoYW5rcyw8YnI+DQpSb2I8bzpwPjwvbzpwPjwv aT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PG86cD4mbmJzcDs8L286cD48 L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5BbiBhbHRlcm5hdGl2ZSB0byB0aGlz IG1heSBiZSB0byB1c2UgYSAmcXVvdDtjaG9pY2UmcXVvdDsgc3RhdGVtZW50IGZvciAmcXVvdDtw cml2YXRlLWtleSZxdW90OyB3aGVyZWJ5IG9uZSBvZiB0aGUgb3B0aW9ucyBpcyAmcXVvdDthc24x JnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPktlbnQgLy8gY29udHJpYnV0b3I8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_MN2PR11MB43669CA5E57F7D4695214E31B58F0MN2PR11MB4366namp_-- From nobody Tue Sep 17 09:47:19 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E6C1208E2 for ; Tue, 17 Sep 2019 09:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 ccBsCgFfd5W8 for ; Tue, 17 Sep 2019 09:47:16 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 CCB1B1208D6 for ; Tue, 17 Sep 2019 09:47:16 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8HGlAxm031549; Tue, 17 Sep 2019 17:47:14 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=NPKRCylfNaynnZmoyZXA7nkofTz99TLk3WqSyHmpqAs=; b=abgUhRHQZx9sAerhBx/pZR0J8oaC3DyCo0hMsr3wjDr5JErDqXyTNpwnrF7nLJU7FDPP bPv5TIj+hfuOS3adbLsEA5jdvCJVH7qPSRPGikVNpeNIiC1Bl+/3z3hw/zIdz/PVwtJK /DzbCsCIu8gqlNcyKz+Y10Obf7CFs7bdWYsFVxr0NovksMqZk7GRCSTQw9390sNmSJ3r 96+cFP1WukTtC3RH6V7XR6LIu9miqUvGEmPNV+caR1xYVjv0NVFTSNcZp5zKCJvzSYze 49i4/fH5DTdP7leaVnlJHi4YgM3xdAihT85JM6eOsVMFAEEPwv9hrCHDL/0xPQkQe38R 8g== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2v0n2tp3c1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Sep 2019 17:47:14 +0100 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x8HGXjTn031146; Tue, 17 Sep 2019 12:47:13 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint6.akamai.com with ESMTP id 2v0uhw4pgs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 17 Sep 2019 12:47:13 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 17 Sep 2019 12:47:12 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Tue, 17 Sep 2019 12:47:12 -0400 From: "Salz, Rich" To: "Rob Wilton (rwilton)" , Kent Watsen CC: Russ Housley , "netconf@ietf.org" , Sean Turner , Rifaat Shekh-Yusef Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxGVhFlbERW30moo9Q8WhnpJqcpkUCAgAU9agCAASLxgP//+5oAgABHL4D//+j+AA== Date: Tue, 17 Sep 2019 16:47:12 +0000 Message-ID: <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@email.amazonses.com> <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.151] Content-Type: multipart/alternative; boundary="_000_6924CAD5F74045128689E0307AF0BD88akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-17_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=856 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909170158 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-17_08:2019-09-17,2019-09-17 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 impostorscore=0 lowpriorityscore=0 mlxscore=0 phishscore=0 priorityscore=1501 suspectscore=0 malwarescore=0 bulkscore=0 adultscore=0 spamscore=0 mlxlogscore=848 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909170161 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 16:47:19 -0000 --_000_6924CAD5F74045128689E0307AF0BD88akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgcmVwbHkuDQoNCkkgdGhpbmsgdGhlIG1vc3QgaW1wb3J0YW50IHRoaW5n IGlzIHRvIGdldCBpdCAqcmlnaHQqIGFuZCBpbiBhIHdheSB0aGF0IHRoZSBzZWN1cml0eSBmb2xr cyAoaW5jbHVkaW5nIHRob3NlIHdheSBtdWNoIG1vcmUga25vd2xlZGdlYWJsZSB0aGFuIEkpIHdp bGwgYWNjZXB0IGl0LiBXZSBzZWVtIHRvIGFncmVlIHRoYXQgbmFycm93aW5nIHRoZSBzY29wZSBp cyBhIGdvb2Qgd2F5IHRvIGdldCB0aGVyZS4NCg0KSSBhbHNvIHN0aWxsIHRoaW5rLCBtb3JlIHN0 cm9uZ2x5IG5vdywgdGhhdCBidWlsZGluZyBkZWZpbml0aW9ucyBhcm91bmQgdGhlIGFsZ29yaXRo bXMsIHJhdGhlciB0aGFuIHRoZSB0eXBlIG9mIGtleSBtYXRlcmlhbCwgaXMgd3JvbmcuDQo= --_000_6924CAD5F74045128689E0307AF0BD88akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <5BA0DCF2703C624090DF9CC7FB68F750@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5t c29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u RW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubWZ0cg0KCXttc28tc3R5bGUtbmFtZTptX2Z0cjt9 DQpzcGFuLm1oZHINCgl7bXNvLXN0eWxlLW5hbWU6bV9oZHI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0 IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMjA2ODcyNzUwOw0KCW1z by1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMjMyNDYxMTU2IC0x Mzk3ODgwNjIwIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3 Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYW5z aS1mb250LXN0eWxlOml0YWxpYzt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rcyBmb3IgdGhlIHJlcGx5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRo aW5rIHRoZSBtb3N0IGltcG9ydGFudCB0aGluZyBpcyB0byBnZXQgaXQgKjxiPnJpZ2h0PC9iPiog YW5kIGluIGEgd2F5IHRoYXQgdGhlIHNlY3VyaXR5IGZvbGtzIChpbmNsdWRpbmcgdGhvc2Ugd2F5 IG11Y2ggbW9yZSBrbm93bGVkZ2VhYmxlIHRoYW4gSSkgd2lsbCBhY2NlcHQgaXQuIFdlIHNlZW0g dG8gYWdyZWUgdGhhdCBuYXJyb3dpbmcgdGhlIHNjb3BlIGlzIGEgZ29vZCB3YXkgdG8gZ2V0IHRo ZXJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFsc28gc3RpbGwgdGhpbmssIG1vcmUgc3Ry b25nbHkgbm93LCB0aGF0IGJ1aWxkaW5nIGRlZmluaXRpb25zIGFyb3VuZCB0aGUgYWxnb3JpdGht cywgcmF0aGVyIHRoYW4gdGhlIHR5cGUgb2Yga2V5IG1hdGVyaWFsLCBpcyB3cm9uZy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6924CAD5F74045128689E0307AF0BD88akamaicom_-- From nobody Tue Sep 17 09:59:47 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70BCA120858 for ; Tue, 17 Sep 2019 09:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=ecX5YBDt; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=WUOAUFNe 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 h0o79ddKyfuu for ; Tue, 17 Sep 2019 09:59:44 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE8AB1200EC for ; Tue, 17 Sep 2019 09:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17152; q=dns/txt; s=iport; t=1568739583; x=1569949183; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=x5V5wLluPh0H8L34Kg5PXSTjg82cef/OwFiC0lKZ+UY=; b=ecX5YBDto1eMOBK31jo5lIA8SaNiAXdffXZC8rHraTnW2+dSRMAV7L1J HrHX4V1DdIw9jAMLaxwvgk9t3yaae6rGQ8YLU5e5t1jS11/f6B47G8ETg 7Sb+lqZtJiXGX7yYTT6YYQ4nRiuHnCtjO0P2DLsBOqynxr9c+SgAHC++Z E=; IronPort-PHdr: =?us-ascii?q?9a23=3A5uwuoRGo1tTg/c/9eVfpW51GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1A3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeT1bigmG8JqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAACHEIFd/4QNJK1dCRoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVMFAQEBAQsBgRUvUANtViAECyoKhBeDRwOEUoYlglyJZYk?= =?us-ascii?q?whF2BLoEkA1QJAQEBDAEBLQIBAYQ/AheCZSM0CQ4CAwkBAQQBAQECAQUEbYU?= =?us-ascii?q?uDIVKAQEBAQMSEQoTAQE3AQ8CAQgRBAEBKwICAh8RHQgCBAENBQgagwGBHU0?= =?us-ascii?q?DHQECo10CgTiIYXOBMoJ9AQEFhRINC4IXCYE0AYo0gUMYgUA/gVeCTD6CGoI?= =?us-ascii?q?ALBWCdDKCJo9RhSWJHY4fQQqCIpEBhBuCNYdHjx6OCooUjnACBAIEBQIOAQE?= =?us-ascii?q?FgVI4gVhwFYMngkILGINPilNzgSmOKgGBIgEB?= X-IronPort-AV: E=Sophos;i="5.64,517,1559520000"; d="scan'208,217";a="632443142" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Sep 2019 16:59:42 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x8HGxgLB024604 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 Sep 2019 16:59:42 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 17 Sep 2019 11:59:42 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 17 Sep 2019 12:59:41 -0400 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 17 Sep 2019 11:59:41 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kMiNpVgexQe9SUCSnd7Vb+oLttNqknGKgIL6zxv/Lo810oj5J1D4sjJtgViLtXELQfcVGh8uAVoPdio1qo5UWzswX9tQLvIHBA+swKmaGjZ+UP8aVjOGarifKYJfVlhtj1oT4IL4BRHKq7w3A0aWXePvWCp6bkMNT83isJ9tS26GqDOGmdhpoTlUZdWx3kw2sOv0osOwrXvV3ctJzvYkwluPdBePujJyoBZRYwB+uuWTgZI2wpmTmgQXxLgg8sVpleH9VRbo1u87ZRfpEPrHpl6hlEqdG0ManIbnQj8BgjILR2aoC5fN2W77rSVBfKDgtXs+Jz2BmFU2suVsm6qsWQ== 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=x5V5wLluPh0H8L34Kg5PXSTjg82cef/OwFiC0lKZ+UY=; b=iaDkUgNB8nSHLjpEL5JD5gUpEAy26kosqKwyeG1Sa2BLHRxa/pkEPAUJB4/9b/aCW9zpjcE+FA1GSUVRCYXmFoSeDdlkbu06W5ovYLYKYHNi/xZ1CDEpEpFFA9+JZMNguTNcbkQ3jlMu1KG7j8A35KMRciX49nMhtXAHP0Tf+VODp3BkWGC6BgGzlgIuACCheHRN6Az3E85Ydj3n0TiEYdw4hfQcnXoO1Rd8gVWYTAHjiyS18x95eTun9Dc+rJPlxH+4dpT9669oJJc7agP+5z2ynTpmPgh7Nq7Vb/bzSNS3zqEGIql2qtg33Q3EHGshjqNsjKjWVu/eC2nlCDazog== 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=x5V5wLluPh0H8L34Kg5PXSTjg82cef/OwFiC0lKZ+UY=; b=WUOAUFNeWFfw3NpwAU5J0QVQTSXSlLJCHlF4bl+67eVhtbyT7UuAZtyW5cOWIjUiwrcx926+hpNiY8jDZ9m9acRqSalj1cc3lwFp8I7GNKiIS5F0ZUDd9voq6ED2uLJ5jLLWjlh+Oo72xX/AXy7Fn3VmKa2QXhyg5vk57NqU8BA= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB4064.namprd11.prod.outlook.com (20.179.150.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.17; Tue, 17 Sep 2019 16:59:39 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6%7]) with mapi id 15.20.2263.023; Tue, 17 Sep 2019 16:59:39 +0000 From: "Rob Wilton (rwilton)" To: "Salz, Rich" , Kent Watsen CC: Russ Housley , "netconf@ietf.org" , Sean Turner , Rifaat Shekh-Yusef Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxVu0aQE+n/K0iPwVgOy8FH/KcpQIdQgAVLFQCAARKfAIAATvkAgAABvxCAAC5vAIAAAggg Date: Tue, 17 Sep 2019 16:59:39 +0000 Message-ID: References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@email.amazonses.com> <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> In-Reply-To: <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [173.38.220.61] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3b17b6e2-084b-4878-5617-08d73b906da9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB4064; x-ms-traffictypediagnostic: MN2PR11MB4064: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01630974C0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(376002)(136003)(366004)(346002)(51914003)(189003)(199004)(64756008)(66556008)(66446008)(4326008)(256004)(14444005)(54906003)(446003)(11346002)(6306002)(99286004)(476003)(486006)(316002)(110136005)(7736002)(26005)(9326002)(8676002)(81156014)(81166006)(7696005)(8936002)(74316002)(6436002)(66066001)(5660300002)(54896002)(6506007)(76176011)(66476007)(66946007)(86362001)(14454004)(2906002)(52536014)(102836004)(76116006)(186003)(9686003)(71200400001)(55016002)(3846002)(33656002)(478600001)(790700001)(6116002)(6246003)(229853002)(71190400001)(53546011)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4064; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: WDP7JLAqvvr9GqclBsu4mGDhAuB0sA1N7I1U91fy2fVgr/OIQGEK5I2W6tAcCEeUkgWc4HEU+YnpDCmq8F+qjRnH0PUFU6FKN9KTsDjc585x7Du1kmQV2Z9+8xLVhK4fXRWryiSgTkiBcoy+YybFKmsR5lTNMO1Cts5OFwDOXPeFURkLnFk04oZ2gxF3ANA0U6x+kM7nCSyG7RZvsA+tLaZmBsj2ZScXp8c0LjtLOtTGMiUn73gyUAfPYwL1YCPCQDnv5PLm+1vzYbQgT5YGAnTip3uvc1+dQyKP3drPe8Gcp85lg7fuuoV5XQ15MIZmmMtf4KSPm/jjCkfoelmdR00zO+mRWGHUdb9odUHj+w3Ns+es1wOxwUqZ+83IhauI7ATWuKd8FnFlQAjvhhaAtC24NbUmmgdQy4pPV8cGgy4= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366B5C09B4348FDAE33E2BCB58F0MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3b17b6e2-084b-4878-5617-08d73b906da9 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2019 16:59:39.3910 (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: BL24rdfi4XQ0jhb5YTHMIbU3lypaO5TnjTsmmafCMUmtzWMDVnzloBj5fSRSTXigdOYblhYCwPVNFUF3HqKhEw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4064 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 16:59:47 -0000 --_000_MN2PR11MB4366B5C09B4348FDAE33E2BCB58F0MN2PR11MB4366namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmljaCwNCg0KRnJvbTogU2FseiwgUmljaCA8cnNhbHpAYWthbWFpLmNvbT4NClNlbnQ6IDE3 IFNlcHRlbWJlciAyMDE5IDE3OjQ3DQpUbzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25A Y2lzY28uY29tPjsgS2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0Pg0KQ2M6IFJ1c3Mg SG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+OyBuZXRjb25mQGlldGYub3JnOyBTZWFuIFR1 cm5lciA8c2VhbkBzbjNyZC5jb20+OyBSaWZhYXQgU2hla2gtWXVzZWYgPHJpZmFhdC5pZXRmQGdt YWlsLmNvbT4NClN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gY3J5cHRvLXR5cGVzIGZhbGxiYWNrIHN0 cmF0ZWd5DQoNClRoYW5rcyBmb3IgdGhlIHJlcGx5Lg0KDQpJIHRoaW5rIHRoZSBtb3N0IGltcG9y dGFudCB0aGluZyBpcyB0byBnZXQgaXQgKnJpZ2h0KiBhbmQgaW4gYSB3YXkgdGhhdCB0aGUgc2Vj dXJpdHkgZm9sa3MgKGluY2x1ZGluZyB0aG9zZSB3YXkgbXVjaCBtb3JlIGtub3dsZWRnZWFibGUg dGhhbiBJKSB3aWxsIGFjY2VwdCBpdC4gV2Ugc2VlbSB0byBhZ3JlZSB0aGF0IG5hcnJvd2luZyB0 aGUgc2NvcGUgaXMgYSBnb29kIHdheSB0byBnZXQgdGhlcmUuDQoNCkkgYWxzbyBzdGlsbCB0aGlu aywgbW9yZSBzdHJvbmdseSBub3csIHRoYXQgYnVpbGRpbmcgZGVmaW5pdGlvbnMgYXJvdW5kIHRo ZSBhbGdvcml0aG1zLCByYXRoZXIgdGhhbiB0aGUgdHlwZSBvZiBrZXkgbWF0ZXJpYWwsIGlzIHdy b25nLg0KW1JXXQ0KUGxlYXNlIG1heSBJIGFzayB5b3UgdG8gY2xhcmlmeSB3aGF0IHlvdSBtZWFu IGJ5IHRoaXMgbGFzdCBjb21tZW50Lg0KDQpEbyB5b3UgbWVhbiB0aGF0IHlvdSBkb27igJl0IGxp a2UgdGhlIGJhc2UgaWRlbnRpdGllcyAoZS5nLiBoYXNoLWFsZ29yaXRobSwgYXN5bW1ldHJpYy1r ZXktYWxnb3JpdGhtLCBtYWMtYWxnb3JpdGhtLCBlbmNyeXB0aW9uLWFsZ29yaXRobSwgZW5jcnlw dGlvbi1hbmQtbWFjLWFsZ29yaXRobSwgc2lnbmF0dXJlLWFsZ29yaXRobSwga2V5LWV4Y2hhbmdl LWFsZ29yaXRobSksIHdoaWNoIHJlYWxseSBqdXN0IGRlZmluZSBob3cgdGhlIGlkZW50aXRpZXMg Y2FuIGJlIHVzZWQuDQoNCk9yIGlzIHlvdXIgb2JqZWN0aW9uIHRvIG15IHN1Z2dlc3Rpb24gb2Yg cHV0dGluZyB0aGUgaWRlbnRpdHkgZGVmaW5pdGlvbnMgaW50byBkaWZmZXJlbnQgWUFORyBtb2R1 bGVzIChlLmcuDQoNCiAgKiAgIElldGYtY3J5cHRvLXNoYS10eXBlcy55YW5nIGZvciB0aGUgU0hB IGhhc2ggaWRlbnRpdGllcyAoUkZDIDYyMzQpDQogICogICBJZXRmLWNyeXB0by1yc2EtdHlwZXMg Zm9yIFJTQSBhc3ltbWV0cmljLWtleS1hbGdvcml0aG0gKFJDIDgwMTcpDQogICogICBJZXRmLWNy eXB0by1lbGxpcHRpYy1jdXJ2ZS10eXBlcyBmb3IgdGhlIEVsbGlwdGljIEN1cnZlIGJhc2VkIGFs Z29yaXRobXMgKFJGQyA2MDkwLCA1NDgwLCA4NDIyKQ0KICAqICAgSWV0Zi1jcnlwdG8tbWFjLXR5 cGVzIOKAkyBJ4oCZbSBub3QgcmVhbGx5IHN1cmUgaG93IHRvIG9yZ2FuaXplIHRoZSBNQUMgYWxn b3JpdGhtIHR5cGVzLCBvciBldmVuIGlmIHRoZXkgbmVlZCB0byBiZSBkZWZpbmVkIG5vdy4NCiAg KiAgIElldGYtY3J5cHRvLWFlcy10eXBlcyDigJMgQUVTIGVuY3J5cHRpb24gdHlwZXMgKFJGQyA0 MzA5KQ0KICAqICAgSWV0Zi1jcnlwdG8tc3NoLXR5cGVzIOKAkyBkYXMtc2hhMSwgcnNhYXNhLXBr Y3MxLXNoYTEgKFJGQyA0MjUzKQ0KICAqICAgSWV0Zi1jcnlwdG8tdGxzLXR5cGVzIOKAkyAoUkZD IDg0NDYpDQogICogICBJZXRmLWN5cHJ0by1kaGUtdHlwZXMg4oCTIERpZmZpZXIgSGVsbG1hbiBr ZXkgZXhjaGFuZ2UgKFJGQyA3OTE5KS4gIEFjdHVhbGx5LCB0aGUga2V5LWV4Y2hhbmdlcyBhbGdv cml0aG0gdHlwZXMgbWlnaHQgbmVlZCB0byBiZSBzcGxpdCB1cCBhIGJpdCBmdXJ0aGVyLg0KKSwg ZS5nLiB3aGljaCBpcyByZWFsbHkganVzdCBhbiBvcmdhbml6YXRpb24gc3RydWN0dXJlIGZvciB0 aGUgaWRlbnRpdGllcz8NCg0KVGhhbmtzLA0KUm9iDQo= --_000_MN2PR11MB4366B5C09B4348FDAE33E2BCB58F0MN2PR11MB4366namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3Jh cGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHls ZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1h cmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K c3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWls U3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4ubWZ0cg0KCXttc28tc3R5bGUtbmFtZTptX2Z0cjt9DQpzcGFuLm1oZHINCgl7 bXNvLXN0eWxlLW5hbWU6bV9oZHI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjgNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpA bGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMjQxMjA4MzQzOw0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTc3NTIyMTczMCAxOTAxMTAzOTc2IDEzNDgwNzU1 NSAxMzQ4MDc1NTcgMTM0ODA3NTUzIDEzNDgwNzU1NSAxMzQ4MDc1NTcgMTM0ODA3NTUzIDEzNDgw NzU1NSAxMzQ4MDc1NTc7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoy Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC41cHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6Q2FsaWJyaTsNCgljb2xvcjpibGFjazt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdp bi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIFJp Y2gsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFNhbHosIFJpY2ggJmx0O3JzYWx6QGFrYW1h aS5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMTcgU2VwdGVtYmVyIDIwMTkgMTc6NDc8YnI+ DQo8Yj5Ubzo8L2I+IFJvYiBXaWx0b24gKHJ3aWx0b24pICZsdDtyd2lsdG9uQGNpc2NvLmNvbSZn dDs7IEtlbnQgV2F0c2VuICZsdDtrZW50JiM0MztpZXRmQHdhdHNlbi5uZXQmZ3Q7PGJyPg0KPGI+ Q2M6PC9iPiBSdXNzIEhvdXNsZXkgJmx0O2hvdXNsZXlAdmlnaWxzZWMuY29tJmd0OzsgbmV0Y29u ZkBpZXRmLm9yZzsgU2VhbiBUdXJuZXIgJmx0O3NlYW5Ac24zcmQuY29tJmd0OzsgUmlmYWF0IFNo ZWtoLVl1c2VmICZsdDtyaWZhYXQuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbbmV0Y29uZl0gY3J5cHRvLXR5cGVzIGZhbGxiYWNrIHN0cmF0ZWd5PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRo YW5rcyBmb3IgdGhlIHJlcGx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SSB0aGluayB0aGUgbW9zdCBpbXBv cnRhbnQgdGhpbmcgaXMgdG8gZ2V0IGl0ICo8Yj5yaWdodDwvYj4qIGFuZCBpbiBhIHdheSB0aGF0 IHRoZSBzZWN1cml0eSBmb2xrcyAoaW5jbHVkaW5nIHRob3NlIHdheSBtdWNoIG1vcmUga25vd2xl ZGdlYWJsZSB0aGFuIEkpIHdpbGwgYWNjZXB0IGl0LiBXZSBzZWVtIHRvIGFncmVlIHRoYXQgbmFy cm93aW5nDQogdGhlIHNjb3BlIGlzIGEgZ29vZCB3YXkgdG8gZ2V0IHRoZXJlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+SSBhbHNvIHN0aWxsIHRoaW5rLCBtb3JlIHN0cm9uZ2x5IG5vdywgdGhhdCBidWlsZGlu ZyBkZWZpbml0aW9ucyBhcm91bmQgdGhlIGFsZ29yaXRobXMsIHJhdGhlciB0aGFuIHRoZSB0eXBl IG9mIGtleSBtYXRlcmlhbCwgaXMgd3JvbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiPltSV10gPG86cD48L286cD48 L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5n PSJFTi1VUyI+UGxlYXNlIG1heSBJIGFzayB5b3UgdG8gY2xhcmlmeSB3aGF0IHlvdSBtZWFuIGJ5 IHRoaXMgbGFzdCBjb21tZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFu Zz0iRU4tVVMiPkRvIHlvdSBtZWFuIHRoYXQgeW91IGRvbuKAmXQgbGlrZSB0aGUgYmFzZSBpZGVu dGl0aWVzIChlLmcuIGhhc2gtYWxnb3JpdGhtLCBhc3ltbWV0cmljLWtleS1hbGdvcml0aG0sIG1h Yy1hbGdvcml0aG0sIGVuY3J5cHRpb24tYWxnb3JpdGhtLCBlbmNyeXB0aW9uLWFuZC1tYWMtYWxn b3JpdGhtLCBzaWduYXR1cmUtYWxnb3JpdGhtLCBrZXktZXhjaGFuZ2UtYWxnb3JpdGhtKSwNCiB3 aGljaCByZWFsbHkganVzdCBkZWZpbmUgaG93IHRoZSBpZGVudGl0aWVzIGNhbiBiZSB1c2VkLjxv OnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiPk9yIGlzIHlvdXIg b2JqZWN0aW9uIHRvIG15IHN1Z2dlc3Rpb24gb2YgcHV0dGluZyB0aGUgaWRlbnRpdHkgZGVmaW5p dGlvbnMgaW50byBkaWZmZXJlbnQgWUFORyBtb2R1bGVzIChlLmcuPG86cD48L286cD48L3NwYW4+ PC9pPjwvYj48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiB0eXBlPSJkaXNjIj4NCjxs aSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlz dDpsMCBsZXZlbDEgbGZvMSI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6YmxhY2siPklldGYtY3J5cHRvLXNoYS10eXBlcy55YW5nIGZvciB0aGUgU0hBIGhhc2ggaWRl bnRpdGllcyAoUkZDIDYyMzQpPC9zcGFuPjwvaT48L2I+PGI+PGk+PG86cD48L286cD48L2k+PC9i PjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNt O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjpibGFjayI+SWV0Zi1jcnlwdG8tcnNhLXR5cGVzIGZvciBSU0EgYXN5bW1ldHJp Yy1rZXktYWxnb3JpdGhtIChSQyA4MDE3KTwvc3Bhbj48L2k+PC9iPjxiPjxpPjxvOnA+PC9vOnA+ PC9pPjwvYj48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjBjbTttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPklldGYtY3J5cHRvLWVsbGlwdGljLWN1cnZlLXR5cGVz IGZvciB0aGUgRWxsaXB0aWMgQ3VydmUgYmFzZWQgYWxnb3JpdGhtcyAoUkZDIDYwOTAsIDU0ODAs IDg0MjIpPC9zcGFuPjwvaT48L2I+PGI+PGk+PG86cD48L286cD48L2k+PC9iPjwvbGk+PGxpIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0Omww IGxldmVsMSBsZm8xIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi bGFjayI+SWV0Zi1jcnlwdG8tbWFjLXR5cGVzIOKAkyBJ4oCZbSBub3QgcmVhbGx5IHN1cmUgaG93 IHRvIG9yZ2FuaXplIHRoZSBNQUMgYWxnb3JpdGhtIHR5cGVzLCBvciBldmVuIGlmIHRoZXkgbmVl ZCB0byBiZSBkZWZpbmVkIG5vdy48L3NwYW4+PC9pPjwvYj48Yj48aT48bzpwPjwvbzpwPjwvaT48 L2I+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDow Y207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOmJsYWNrIj5JZXRmLWNyeXB0by1hZXMtdHlwZXMg4oCTIEFFUyBlbmNyeXB0 aW9uIHR5cGVzIChSRkMgNDMwOSk8L3NwYW4+PC9pPjwvYj48Yj48aT48bzpwPjwvbzpwPjwvaT48 L2I+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDow Y207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOmJsYWNrIj5JZXRmLWNyeXB0by1zc2gtdHlwZXMg4oCTIGRhcy1zaGExLCBy c2Fhc2EtcGtjczEtc2hhMSAoUkZDIDQyNTMpPC9zcGFuPjwvaT48L2I+PGI+PGk+PG86cD48L286 cD48L2k+PC9iPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MGNtO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48Yj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+SWV0Zi1jcnlwdG8tdGxzLXR5cGVzIOKAkyAoUkZD IDg0NDYpPC9zcGFuPjwvaT48L2I+PGI+PGk+PG86cD48L286cD48L2k+PC9iPjwvbGk+PGxpIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0Omww IGxldmVsMSBsZm8xIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi bGFjayI+SWV0Zi1jeXBydG8tZGhlLXR5cGVzIOKAkyBEaWZmaWVyIEhlbGxtYW4ga2V5IGV4Y2hh bmdlIChSRkMgNzkxOSkuJm5ic3A7IEFjdHVhbGx5LCB0aGUga2V5LWV4Y2hhbmdlcyBhbGdvcml0 aG0gdHlwZXMgbWlnaHQgbmVlZCB0byBiZSBzcGxpdA0KIHVwIGEgYml0IGZ1cnRoZXIuPC9zcGFu PjwvaT48L2I+PGI+PGk+PG86cD48L286cD48L2k+PC9iPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxpPiksIGUuZy4gd2hpY2ggaXMgcmVhbGx5IGp1c3QgYW4gb3JnYW5pemF0 aW9uIHN0cnVjdHVyZSBmb3IgdGhlIGlkZW50aXRpZXM/PG86cD48L286cD48L2k+PC9iPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxvOnA+Jm5ic3A7PC9vOnA+PC9pPjwvYj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT5UaGFua3MsPGJyPg0KUm9iPG86cD48L286cD48 L2k+PC9iPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MN2PR11MB4366B5C09B4348FDAE33E2BCB58F0MN2PR11MB4366namp_-- From nobody Tue Sep 17 10:07:14 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20D11208BC for ; Tue, 17 Sep 2019 10:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 fS2hVsXAMtJr for ; Tue, 17 Sep 2019 10:07:10 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 E4F98120112 for ; Tue, 17 Sep 2019 10:07:10 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x8HH6wr2006653; Tue, 17 Sep 2019 18:07:08 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=9TJ6GVxPAqgK2o+x9yVotA+gVTxCuDS24AAdfV3wXPY=; b=m0RPjqk6FRgIu5RaJKoHF+RvYmUyjOQALzd0StxwdDetlsqssMmCnBkTBXcfZDGlVWtb HzygcbWfY/XaT+jCyT5tBurHYNNvaz+L63LDjoiKC8iXQ7oMyBh4L/CXKI7q2SZNMzVP 0Y6e92lgLqMUWu2YlREAD7oLOWGAp5/FEIozpmgh1Sn/dlWveCPAHD/lMMXRgZIMjqrd uX2s+HrHyKgubazK9iv8SGyT90xa2U1JZWWukLAsJP/uQAKewj8QbmeShlp/PKQGyVf4 bR/ylTbgZyPNOKRf0u9moj+5keQAQwVRcvjpIRfFZ08ZV90lU1gChcmuHymHynLsXBau 0g== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2v0qr3ytqb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Sep 2019 18:07:08 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x8HH372e017319; Tue, 17 Sep 2019 13:07:07 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2v0uhw5khp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 17 Sep 2019 13:07:06 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 17 Sep 2019 13:07:05 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Tue, 17 Sep 2019 13:07:04 -0400 From: "Salz, Rich" To: "Rob Wilton (rwilton)" , Kent Watsen CC: Russ Housley , "netconf@ietf.org" , Sean Turner , Rifaat Shekh-Yusef Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxGVhFlbERW30moo9Q8WhnpJqcpkUCAgAU9agCAASLxgP//+5oAgABHL4D//+j+AIAARomA//+/BAA= Date: Tue, 17 Sep 2019 17:07:04 +0000 Message-ID: <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@email.amazonses.com> <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.151] Content-Type: multipart/alternative; boundary="_000_99BFF3576A2A49E0BB3837C25DB04213akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-17_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=780 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909170163 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-17_08:2019-09-17,2019-09-17 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 bulkscore=0 suspectscore=0 malwarescore=0 adultscore=0 phishscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 spamscore=0 mlxlogscore=773 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909170164 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2019 17:07:13 -0000 --_000_99BFF3576A2A49E0BB3837C25DB04213akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkbyBub3QgdGhpbmsgdXNpbmcgYWxnb3JpdGhtcyBhcyB0aGUgYmFzZSBjbGFzc2VzIGlzIGEg Z29vZCBpZGVhLiAgSSB0aGluayBpdCBpcyBtdWNoIGJldHRlciB0byBoYXZlIHRoZSB0eXBlIG9m IGtleSBtYXRlcmlhbCBhcyB0aGUgYmFzZSBjbGFzczoNCiAgICAgICAgICAgICAgICBhc3ltbWV0 cmljLWtleSAoUlNBLCBFQ0MsIGV0YykNCiAgICAgICAgICAgICAgICBzeW1tZXRyaWMta2V5IChB RVMgM0RFUyBldGMpDQogICAgICAgICAgICAgICAgYnl0ZSBzdHJpbmcgKG1heWJl4oCmKQ0Kbm9u Y2UgKG5vbi1yZXVzZWQgc3RyZWFtIG9mIGJpdHMgdXNlZCBpbiBBRVMtR0NNLCBFZERTQSBzaWdu YXR1cmUsIEVERFNBIHNpZ25hdHVyZXMsIGV0YykNCiAgICAgICAgICAgICAgICB0YWcgKHVzZWQg aW4gS0RGIGZ1bmN0aW9ucywgYWxtb3N0IGFsd2F5cyBhIHRleHQgc3RyaW5nKQ0KDQpUaGUgKnVz ZSogb2YgdGhlIGlkZW50aXRpZXMgc2hvdWxkIGJlIGltcGxpZWQgYnkgdGhlIG9wZXJhdGlvbi4N Cg0KSSBsaWtlIHRoZSBpZGVhIG9mIHBhcnRpdGlvbmluZyBieSDigJxoZXJlIGlzIHdoYXQgeW91 IG5lZWQgdG8gY29uZmlndXJlIGEgdHlwaWNhbCBIVFRQUyBzZXJ2ZXLigJ0gaW4gb25lIGRvY3Vt ZW50IGFuZCDigJxoZXJlIGlzIHdoYXQgeW91IG5lZWQgdG8gY29uZmlndXJlIGEgdHlwaWNhbCBT U0ggc2VydmVy4oCdDQoNCkRvZXMgdGhhdCBhbnN3ZXIgeW91ciBxdWVzdGlvbj8NCg0K --_000_99BFF3576A2A49E0BB3837C25DB04213akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5t c29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u RW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubWZ0cg0KCXttc28tc3R5bGUtbmFtZTptX2Z0cjt9 DQpzcGFuLm1oZHINCgl7bXNvLXN0eWxlLW5hbWU6bV9oZHI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyOQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTMwDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6MTEzOTYxMjg1MjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTExMjc4NDQyODI7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxMjQxMjA4MzQz Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTc3NTIy MTczMCAxOTAxMTAzOTc2IDEzNDgwNzU1NSAxMzQ4MDc1NTcgMTM0ODA3NTUzIDEzNDgwNzU1NSAx MzQ4MDc1NTcgMTM0ODA3NTUzIDEzNDgwNzU1NSAxMzQ4MDc1NTc7fQ0KQGxpc3QgbDE6bGV2ZWwx DQoJe21zby1sZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjVwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOmJsYWNrO30NCkBsaXN0 IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGlu O30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkbyBub3QgdGhpbmsgdXNpbmcg YWxnb3JpdGhtcyBhcyB0aGUgYmFzZSBjbGFzc2VzIGlzIGEgZ29vZCBpZGVhLiZuYnNwOyBJIHRo aW5rIGl0IGlzIG11Y2ggYmV0dGVyIHRvIGhhdmUgdGhlIHR5cGUgb2Yga2V5IG1hdGVyaWFsIGFz IHRoZSBiYXNlIGNsYXNzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFzeW1tZXRyaWMta2V5IChSU0EsIEVDQywg ZXRjKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN5bW1ldHJpYy1rZXkgKEFFUyAzREVTIGV0Yyk8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBieXRlIHN0cmluZyAobWF5YmXigKYpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LjVpbiI+bm9uY2UgKG5vbi1yZXVzZWQgc3RyZWFt IG9mIGJpdHMgdXNlZCBpbiBBRVMtR0NNLCBFZERTQSBzaWduYXR1cmUsIEVERFNBIHNpZ25hdHVy ZXMsIGV0Yyk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0YWcgKHVzZWQgaW4gS0RGIGZ1bmN0aW9ucywgYWxtb3N0 IGFsd2F5cyBhIHRleHQgc3RyaW5nKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgKjxiPnVz ZTwvYj4qIG9mIHRoZSBpZGVudGl0aWVzIHNob3VsZCBiZSBpbXBsaWVkIGJ5IHRoZSBvcGVyYXRp b24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgbGlrZSB0aGUgaWRlYSBvZiBwYXJ0aXRpb25p bmcgYnkg4oCcaGVyZSBpcyB3aGF0IHlvdSBuZWVkIHRvIGNvbmZpZ3VyZSBhIHR5cGljYWwgSFRU UFMgc2VydmVy4oCdIGluIG9uZSBkb2N1bWVudCBhbmQg4oCcaGVyZSBpcyB3aGF0IHlvdSBuZWVk IHRvIGNvbmZpZ3VyZSBhIHR5cGljYWwgU1NIIHNlcnZlcuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Eb2VzIHRoYXQgYW5zd2VyIHlvdXIgcXVlc3Rpb24/PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_99BFF3576A2A49E0BB3837C25DB04213akamaicom_-- From nobody Tue Sep 17 17:53:16 2019 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D931712006F; Tue, 17 Sep 2019 17:53:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.101.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <156876798781.17479.1875478559527524485@ietfa.amsl.com> Date: Tue, 17 Sep 2019 17:53:07 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-https-notif-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 00:53:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration WG of the IETF. Title : An HTTPS-based Transport for Configured Subscriptions Authors : Mahesh Jethanandani Kent Watsen Filename : draft-ietf-netconf-https-notif-00.txt Pages : 11 Date : 2019-09-17 Abstract: This document defines a YANG data module for configuring HTTPS based configured subscription, as defined I-D.ietf-netconf-subscribed- notifications. The use of HTTPS maximizes transport-level interoperability, while allowing for encoding selection from text, e.g. XML or JSON, to binary. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-https-notif/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-https-notif-00 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Sep 17 18:48:07 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC74D120131 for ; Tue, 17 Sep 2019 18:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 kbcb6jTwi9wV for ; Tue, 17 Sep 2019 18:47:57 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 8900012011E for ; Tue, 17 Sep 2019 18:47:57 -0700 (PDT) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 979673534C4BFB4EF309 for ; Wed, 18 Sep 2019 02:47:55 +0100 (IST) Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 18 Sep 2019 02:47:54 +0100 Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Wed, 18 Sep 2019 02:47:54 +0100 Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Wed, 18 Sep 2019 02:47:54 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0439.000; Wed, 18 Sep 2019 09:47:47 +0800 From: Tianran Zhou To: Andy Bierman , Martin Bjorklund CC: Netconf Thread-Topic: [netconf] configuring multi-channels Thread-Index: AdVs9BeNNLIBQRFAQtOat+1DuA9kN///1euA//92JkCAAJSVAP//crMggACh+gD//3goMAASRjAA//94jtD//2m1AP/+TBRw//0bfwD/+euegP/z1ZuA/+eiQQD/zhQBEA== Date: Wed, 18 Sep 2019 01:47:46 +0000 Message-ID: References: <20190917.121226.1164447711500530993.mbj@tail-f.com> <0100016d3fac842c-22414d8e-ad04-4e56-b2c9-8f25a246affa-000000@email.amazonses.com> <20190917.164803.146080986857670528.mbj@tail-f.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F21BEFB8820NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] configuring multi-channels X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 01:48:00 -0000 --_000_BBA82579FD347748BEADC4C445EA0F21BEFB8820NKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSBhbmQgTWFydGluLA0KDQpUaGUgcHJvcG9zYWwgaW4gZHJhZnQtemhvdS1uZXRjb25m LW11bHRpLXN0cmVhbS1vcmlnaW5hdG9ycyBpcyB0byBhZGQgdGhlIHJlYWQgb25seSBtZXNzYWdl LWdlbmVyYXRvci1pZC4NClNvIHRoYXQgdGhlIHJlY2VpdmVyIGNhbiB2ZXJpZnkgdGhlIGZ1bGwg c2V0IG9mIFlBTkcgb2JqZWN0cyBwcm9taXNlZCBhcmUgYmVpbmcgcHJvdmlkZWQgYWNyb3NzIHRo ZSBzdW0gb2Ygc3RyZWFtIG9yaWdpbmF0b3JzLg0KDQogICBtb2R1bGU6IGlldGYtbXVsdGlwbGUt c3RyZWFtLW9yaWdpbmF0b3JzDQogICAgIGF1Z21lbnQgL3NuOnN1YnNjcmlwdGlvbnMvc246c3Vi c2NyaXB0aW9uOg0KICAgICAgICstLXJvIG1lc3NhZ2UtZ2VuZXJhdG9yLWlkKiAgIHN0cmluZw0K ICAgICBhdWdtZW50IC9zbjpzdWJzY3JpcHRpb24tc3RhcnRlZDoNCiAgICAgICArLS1ybyBtZXNz YWdlLWdlbmVyYXRvci1pZCogICBzdHJpbmcNCiAgICAgYXVnbWVudCAvc246c3Vic2NyaXB0aW9u LW1vZGlmaWVkOg0KICAgICAgICstLXJvIG1lc3NhZ2UtZ2VuZXJhdG9yLWlkKiAgIHN0cmluZw0K ICAgICBhdWdtZW50IC9zbjplc3RhYmxpc2gtc3Vic2NyaXB0aW9uL3NuOm91dHB1dDoNCiAgICAg ICArLS1ybyBtZXNzYWdlLWdlbmVyYXRvci1pZCogICBzdHJpbmcNCiAgICAgYXVnbWVudCAvc246 bW9kaWZ5LXN1YnNjcmlwdGlvbi9zbjpvdXRwdXQ6DQogICAgICAgKy0tcm8gbWVzc2FnZS1nZW5l cmF0b3ItaWQqICAgc3RyaW5nDQoNClNvIHdlIGFyZSBub3QgZ29pbmcgdG8gY29uZmlndXJlIGEg Y2hhbm5lbC1pZCBvciBtZXNzYWdlLWdlbmVyYXRvci1pZC4NCg0KSSBhbSBqdXN0IHRoaW5raW5n IGhvdyB0byBjb25maWd1cmUgdGhlIHRyYW5zcG9ydCB3aGVuIHRoZXJlIGFyZSBtdWx0aSBvcmln aW5hdG9ycy4gSWYgZHJhZnQtemhvdS1uZXRjb25mLW11bHRpLXN0cmVhbS1vcmlnaW5hdG9ycyBu ZWVkIHRvIHByb3ZpZGUgc29tZSBndWlkZWxpbmVzIG9yIGl04oCZcyBkZWZlcnJlZCB0byB0aGUg dHJhbnNwb3J0IGRvY3VtZW50cyBsaWtlIGh0dHBzLW5vdGlmLg0KDQpCZXN0LA0KVGlhbnJhbg0K DQpGcm9tOiBuZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgQW5keSBCaWVybWFuDQpTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMTcsIDIwMTkgMTE6 MjAgUE0NClRvOiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4NCkNjOiBOZXRjb25m IDxuZXRjb25mQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtuZXRjb25mXSBjb25maWd1cmluZyBt dWx0aS1jaGFubmVscw0KDQpIaSwNCg0KDQpPbiBUdWUsIFNlcCAxNywgMjAxOSBhdCA3OjQ4IEFN IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPG1haWx0bzptYmpAdGFpbC1mLmNvbT4+ IHdyb3RlOg0KS2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0PG1haWx0bzprZW50JTJC aWV0ZkB3YXRzZW4ubmV0Pj4gd3JvdGU6DQo+DQo+IE1hcnRpbiwNCj4NCj4gQXMgZm9yIHdoeSB0 aGVyZSBpcyBhIG5lZWQgdG8gY29uZmlndXJlIGFueXRoaW5nIG9uIGEgcGVyLWNoYW5uZWwNCj4g YmFzaXMsIGhlcmUgYXJlIHNvbWUgcG9zc2libGUgcmVhc29uczoNCj4NCj4gICAtIGRpZmZlcmVu dCBUQ1AtbGV2ZWwgcGFyYW1ldGVycyAoc291cmNlIElQLCBwb3NzaWJseSBhIFZSRikNCg0KUGVy aGFwcy4gIEJ1dCBzZXR0aW5nIHRoaXMgcGVyIGxpbmVjYXJkIHdvdWxkIHJlcXVpcmUgdGhlIGNs aWVudCB0byBrbm93DQphbGwgdGhlIGxpbmUgY2FyZHMgYW5kIHdoaWNoIElQIGVhY2ggbGluZSBj YXJkIGNhbiB1c2UuDQoNCj4gICAtIGRpZmZlcmVudCBUTFMtbGV2ZWwgcGFyYW1ldGVycyAoVEEg Y2VydCwgY2xpZW50IGNlcnQpDQoNCkRvIHlvdSBzZWUgYSB1c2UgZm9yIHRoaXM/DQoNCj4gICAt IGRpZmZlcmVudCBIVFRQLWxldmVsIHBhcmFtZXRlcnMgKGJhc2ljIGF1dGgpDQoNCkRvIHlvdSBz ZWUgYSB1c2UgZm9yIHRoaXM/DQoNCg0KPiBEb2VzIGFueSBvZiB0aGlzIG1hdHRlcj8gIElzIHRo ZSBvbmx5IGlzc3VlIGlmIHRoZSByZWNlaXZlciBjYW4ga25vdw0KPiB3aGljaCBsaW5lIGNhcmQg c2VudCB0aGUgbWVzc2FnZT8gIE9yIGlzIGl0IG5lZWRlZCB0byBlbmFibGUgdGhlDQo+IG5ldHdv cmtpbmcgY29ubmVjdGlvbiB0byBiZSBlc3RhYmxpc2hlZCwgd2hpY2ggY2FuIHNvbWVob3cgYmUN Cj4gZGlmZmVyZW50IGFtb25nc3QgdGhlIGxpbmUgY2FyZHM/DQo+DQo+IElmIHdlIHB1cnBvc2Vs eSBzaHVuIHZhcmlhdGlvbnMsIHRoZW4gdGhlIG5lZWQgdG8gY29uZmlndXJlIGFueXRoaW5nDQo+ IHBlci1jaGFubmVsIGdvZXMgYXdheSwgd2hpY2ggd291bGQgbWFrZSB0aGluZ3MgbXVjaCBlYXNp ZXIgYWxsIGFyb3VuZC4NCj4gQnV0IHRoZW4gd2UnZCBoYXZlIHRvIGFzaywgd2hhdCByZW1haW5z IGluIHRoZQ0KPiBtdWx0aS1zdHJlYW0tb3JpZ2luYXRvcnMgZHJhZnQ/DQoNCkkgZG9uJ3Qga25v dywgYnV0IGlmIHdlIGNhbiBzb2x2ZSB0aGUgcHJvYmxlbSB3L28gYW4gYWRkaXRpb25hbA0Kc3Bl Y2lmaWNhdGlvbiwgdGhhdCBzZWVtcyBsaWtlIGEgZ29vZCB0aGluZyENCg0KDQoNCisxIHRvIGFs bCBvZiBNYXJ0aW4ncyBjb25jZXJucy4NCg0KVGhlIG5vdGlmaWNhdGlvbiBhbHJlYWR5IGhhcyBh IHN1YnNjcmlwdGlvbi1pZCwgbWF5YmUgYSBtZXNzYWdlLWdlbmVyYXRvci1pZC4NCklzIHRoZSBw cm9wb3NhbCB0byBhZGQgYW4gYXJiaXRyYXJ5IGNoYW5uZWwtaWQgdG8gdGhlIG5vdGlmaWNhdGlv biBoZWFkZXI/DQoNCkl0IHNlZW1zIHNpbXBsZXIgYW5kIHBvc3NpYmx5IHVzZWZ1bCB0byB0aGUg Y2xpZW50IHRvIHJldHJpZXZlIHRoZSByZWFkLW9ubHkgbWVzc2FnZS1nZW5lcmF0b3ItaWQNCnRo YXQgaXMgYmVpbmcgdXNlZCBmb3IgY29ubmVjdGlvbiAoZnJvbSB0aGlzIG5ldyBtb2R1bGUpLg0K VGhpcyBzaG91bGQgbm90IGJlIGNvbmZpZ3VyYWJsZSBieSB0aGUgY2xpZW50IGFuZCBhIG5ldyBh cmJpdHJhcnkgbnVtYmVyIHNob3VsZCBub3QgYmUgaW52ZW50ZWQgZm9yIGl0Lg0KDQoNCg0KDQov bWFydGluDQoNCkFuZHkNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KbmV0Y29uZiBtYWlsaW5nIGxpc3QNCm5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRv Om5ldGNvbmZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldGNvbmYNCg== --_000_BBA82579FD347748BEADC4C445EA0F21BEFB8820NKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuaWsOWui+S9kzsNCglwYW5vc2UtMToyIDEgNiA5IDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IlxA5paw5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiA5IDMgMSAxIDEg MSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OuaWsOWui+S9kzsNCgljb2xvcjojMUY0OTdE Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29y YXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OuaWsOWui+S9kztjb2xvcjojMUY0OTdE Ij5IaSBBbmR5IGFuZCBNYXJ0aW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OuaWsOWui+S9kztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk65paw5a6L5L2TO2NvbG9yOiMxRjQ5N0QiPlRoZSBwcm9w b3NhbCBpbiBkcmFmdC16aG91LW5ldGNvbmYtbXVsdGktc3RyZWFtLW9yaWdpbmF0b3JzIGlzIHRv IGFkZCB0aGUgcmVhZCBvbmx5IG1lc3NhZ2UtZ2VuZXJhdG9yLWlkLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTrmlrDlrovkvZM7Y29sb3I6IzFGNDk3RCI+U28gdGhh dCB0aGUgcmVjZWl2ZXIgY2FuIHZlcmlmeSB0aGUgZnVsbCBzZXQgb2YgWUFORyBvYmplY3RzIHBy b21pc2VkIGFyZSBiZWluZyBwcm92aWRlZCBhY3Jvc3MgdGhlIHN1bSBvZiBzdHJlYW0gb3JpZ2lu YXRvcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OuaWsOWui+S9 kztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk65paw5a6L5L2TO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBtb2R1bGU6IGll dGYtbXVsdGlwbGUtc3RyZWFtLW9yaWdpbmF0b3JzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OuaWsOWui+S9kztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgYXVnbWVudCAvc246c3Vic2NyaXB0aW9ucy9zbjpzdWJzY3JpcHRpb246PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OuaWsOWui+S9kztjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJvIG1lc3Nh Z2UtZ2VuZXJhdG9yLWlkKiAmbmJzcDsmbmJzcDtzdHJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk65paw5a6L5L2TO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBhdWdtZW50IC9zbjpzdWJzY3JpcHRpb24tc3RhcnRlZDo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk65paw5a6L5L2TO2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcm8gbWVzc2FnZS1n ZW5lcmF0b3ItaWQqJm5ic3A7Jm5ic3A7IHN0cmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTrmlrDlrovkvZM7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGF1Z21lbnQgL3NuOnN1YnNjcmlwdGlvbi1tb2RpZmllZDo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk65paw5a6L5L2TO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcm8gbWVzc2FnZS1nZW5l cmF0b3ItaWQqJm5ic3A7Jm5ic3A7IHN0cmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTrmlrDlrovkvZM7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGF1Z21lbnQgL3NuOmVzdGFibGlzaC1zdWJzY3JpcHRpb24vc246b3V0cHV0OjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTrmlrDlrovkvZM7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ybyBtZXNz YWdlLWdlbmVyYXRvci1pZCombmJzcDsmbmJzcDsgc3RyaW5nPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OuaWsOWui+S9kztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgYXVnbWVudCAvc246bW9kaWZ5LXN1YnNjcmlwdGlvbi9zbjpvdXRwdXQ6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OuaWsOWui+S9kztjb2xv cjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJv IG1lc3NhZ2UtZ2VuZXJhdG9yLWlkKiZuYnNwOyZuYnNwOyBzdHJpbmc8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk65paw5a6L5L2TO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTrmlrDlrovkvZM7Y29s b3I6IzFGNDk3RCI+U28gd2UgYXJlIG5vdCBnb2luZyB0byBjb25maWd1cmUgYSBjaGFubmVsLWlk IG9yIG1lc3NhZ2UtZ2VuZXJhdG9yLWlkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTrmlrDlrovkvZM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OuaWsOWui+S9kztjb2xvcjojMUY0OTdEIj5JIGFt IGp1c3QgdGhpbmtpbmcgaG93IHRvIGNvbmZpZ3VyZSB0aGUgdHJhbnNwb3J0IHdoZW4gdGhlcmUg YXJlIG11bHRpIG9yaWdpbmF0b3JzLiBJZiBkcmFmdC16aG91LW5ldGNvbmYtbXVsdGktc3RyZWFt LW9yaWdpbmF0b3JzIG5lZWQgdG8gcHJvdmlkZSBzb21lIGd1aWRlbGluZXMNCiBvciBpdDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3 RCI+4oCZPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTrmlrDlrovkvZM7Y29sb3I6IzFGNDk3RCI+cyBkZWZlcnJlZCB0byB0aGUgdHJh bnNwb3J0IGRvY3VtZW50cyBsaWtlIGh0dHBzLW5vdGlmLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTrmlrDlrovkvZM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OuaWsOWui+S9kztjb2xvcjojMUY0 OTdEIj5CZXN0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTrmlrDl rovkvZM7Y29sb3I6IzFGNDk3RCI+VGlhbnJhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTrmlrDlrovkvZM7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ IG5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkFuZHkgQmllcm1hbjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBTZXB0ZW1iZXIg MTcsIDIwMTkgMTE6MjAgUE08YnI+DQo8Yj5Ubzo8L2I+IE1hcnRpbiBCam9ya2x1bmQgJmx0O21i akB0YWlsLWYuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gTmV0Y29uZiAmbHQ7bmV0Y29uZkBpZXRm Lm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRjb25mXSBjb25maWd1cmluZyBt dWx0aS1jaGFubmVsczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFR1ZSwgU2VwIDE3LCAyMDE5IGF0IDc6NDggQU0gTWFy dGluIEJqb3JrbHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIiB0YXJnZXQ9 Il9ibGFuayI+bWJqQHRhaWwtZi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+S2VudCBXYXRzZW4gJmx0OzxhIGhyZWY9Im1haWx0bzprZW50JTJC aWV0ZkB3YXRzZW4ubmV0IiB0YXJnZXQ9Il9ibGFuayI+a2VudCYjNDM7aWV0ZkB3YXRzZW4ubmV0 PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE1hcnRpbiw8YnI+DQomZ3Q7IDxi cj4NCiZndDsgQXMgZm9yIHdoeSB0aGVyZSBpcyBhIG5lZWQgdG8gY29uZmlndXJlIGFueXRoaW5n IG9uIGEgcGVyLWNoYW5uZWw8YnI+DQomZ3Q7IGJhc2lzLCBoZXJlIGFyZSBzb21lIHBvc3NpYmxl IHJlYXNvbnM6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOy0gZGlmZmVyZW50IFRD UC1sZXZlbCBwYXJhbWV0ZXJzIChzb3VyY2UgSVAsIHBvc3NpYmx5IGEgVlJGKTxicj4NCjxicj4N ClBlcmhhcHMuJm5ic3A7IEJ1dCBzZXR0aW5nIHRoaXMgcGVyIGxpbmVjYXJkIHdvdWxkIHJlcXVp cmUgdGhlIGNsaWVudCB0byBrbm93PGJyPg0KYWxsIHRoZSBsaW5lIGNhcmRzIGFuZCB3aGljaCBJ UCBlYWNoIGxpbmUgY2FyZCBjYW4gdXNlLjxicj4NCjxicj4NCiZndDsmbmJzcDsgJm5ic3A7LSBk aWZmZXJlbnQgVExTLWxldmVsIHBhcmFtZXRlcnMgKFRBIGNlcnQsIGNsaWVudCBjZXJ0KTxicj4N Cjxicj4NCkRvIHlvdSBzZWUgYSB1c2UgZm9yIHRoaXM/PGJyPg0KPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDstIGRpZmZlcmVudCBIVFRQLWxldmVsIHBhcmFtZXRlcnMgKGJhc2ljIGF1dGgpPGJyPg0K PGJyPg0KRG8geW91IHNlZSBhIHVzZSBmb3IgdGhpcz88YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IERv ZXMgYW55IG9mIHRoaXMgbWF0dGVyPyZuYnNwOyBJcyB0aGUgb25seSBpc3N1ZSBpZiB0aGUgcmVj ZWl2ZXIgY2FuIGtub3c8YnI+DQomZ3Q7IHdoaWNoIGxpbmUgY2FyZCBzZW50IHRoZSBtZXNzYWdl PyZuYnNwOyBPciBpcyBpdCBuZWVkZWQgdG8gZW5hYmxlIHRoZTxicj4NCiZndDsgbmV0d29ya2lu ZyBjb25uZWN0aW9uIHRvIGJlIGVzdGFibGlzaGVkLCB3aGljaCBjYW4gc29tZWhvdyBiZTxicj4N CiZndDsgZGlmZmVyZW50IGFtb25nc3QgdGhlIGxpbmUgY2FyZHM/PGJyPg0KJmd0OyA8YnI+DQom Z3Q7IElmIHdlIHB1cnBvc2VseSBzaHVuIHZhcmlhdGlvbnMsIHRoZW4gdGhlIG5lZWQgdG8gY29u ZmlndXJlIGFueXRoaW5nPGJyPg0KJmd0OyBwZXItY2hhbm5lbCBnb2VzIGF3YXksIHdoaWNoIHdv dWxkIG1ha2UgdGhpbmdzIG11Y2ggZWFzaWVyIGFsbCBhcm91bmQuPGJyPg0KJmd0OyBCdXQgdGhl biB3ZSdkIGhhdmUgdG8gYXNrLCB3aGF0IHJlbWFpbnMgaW4gdGhlPGJyPg0KJmd0OyBtdWx0aS1z dHJlYW0tb3JpZ2luYXRvcnMgZHJhZnQ/PGJyPg0KPGJyPg0KSSBkb24ndCBrbm93LCBidXQgaWYg d2UgY2FuIHNvbHZlIHRoZSBwcm9ibGVtIHcvbyBhbiBhZGRpdGlvbmFsPGJyPg0Kc3BlY2lmaWNh dGlvbiwgdGhhdCBzZWVtcyBsaWtlIGEgZ29vZCB0aGluZyE8YnI+DQo8YnI+DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+JiM0MzsxIHRvIGFsbCBvZiBNYXJ0aW4ncyBjb25jZXJucy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBub3RpZmlj YXRpb24gYWxyZWFkeSBoYXMgYSBzdWJzY3JpcHRpb24taWQsIG1heWJlIGEgbWVzc2FnZS1nZW5l cmF0b3ItaWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPklzIHRoZSBwcm9wb3NhbCB0byBhZGQgYW4g YXJiaXRyYXJ5IGNoYW5uZWwtaWQgdG8gdGhlIG5vdGlmaWNhdGlvbiBoZWFkZXI/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JdCBzZWVtcyBzaW1wbGVy IGFuZCBwb3NzaWJseSB1c2VmdWwgdG8gdGhlIGNsaWVudCB0byByZXRyaWV2ZSB0aGUgcmVhZC1v bmx5IG1lc3NhZ2UtZ2VuZXJhdG9yLWlkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnRoYXQgaXMgYmVp bmcgdXNlZCBmb3IgY29ubmVjdGlvbiAoZnJvbSB0aGlzIG5ldyBtb2R1bGUpLiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5UaGlzIHNob3VsZCBub3QgYmUgY29uZmlndXJhYmxlIGJ5IHRoZSBj bGllbnQgYW5kIGEgbmV3IGFyYml0cmFyeSBudW1iZXIgc2hvdWxkIG5vdCBiZSBpbnZlbnRlZCBm b3IgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+L21hcnRpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkFuZHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCm5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRjb25mQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BBA82579FD347748BEADC4C445EA0F21BEFB8820NKGEML515MBXchi_-- From nobody Wed Sep 18 00:33:53 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B790120129 for ; Wed, 18 Sep 2019 00:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=ericsson.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 lTSkOpQYBuvh for ; Wed, 18 Sep 2019 00:33:50 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10074.outbound.protection.outlook.com [40.107.1.74]) (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 662EA120098 for ; Wed, 18 Sep 2019 00:33:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EV5Z/fXvID7A/KucVe4Bjxsz5s85tJNB69/vCvCn3IZ8W/q+uYmQ38pWKA/iEjVlRyELURO0oxFonRiw4ErklUzakP3KMELi/4nYDRlzIzRZyflHKe+8Lm6FGbPYFjZ1B7jc80Gc366fbvk757lVGTvyZOle/HGVYAFAw5e+m4d8R3FrkHu/4oEgNUO5zBCL7ONzjcTf3RPwxDAYzUB3xPCXAOxR/hBt9TOsqF3AsWmD3XMoLx05RYT+J2YABvj0JZN9oTqSAKJOR4a951q61p7t2hAKhyGHm5Pc1JFTBvb25oZueVegZQS/YaRUaVwjZG3c+gRg3sOVlpCjt06yRQ== 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=IlfnWVpXvm2cRYfFZP1vJG+m8pVMFrv7aVhcS02oCxM=; b=UPZ2comAX5fQB2/rqHHCCd42q/SNSdQtYWDI/LovJW+8y0dkH/5QzQ/Imekd6IaOwTi9h81dnzdhobVShAfMZZF3xOZwbbTPWnMxiQPiDGg4M8gwS3oyQ/QPcJe3O5nQIsdphcQLehVWEpN3h1pyqRSrsJ6InUBF8YCkDJ+WEQh7vxv3GJOWaIAAhzdQYkWQzK3Pbr+dEjHInI5sO2BbgIqmROyZtRXhwTfZzSOlfhAu2xaFYp0fqliA5SJmuJUdkvwBfoAS7SCS4umSbpr1GpgXZLR4yZoEOAbmqmGOx1EeGssDa4G2Ea7WOz2RtNQyEAVK/wUthpEY6l6gDLtxUA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IlfnWVpXvm2cRYfFZP1vJG+m8pVMFrv7aVhcS02oCxM=; b=S99TsDVYqZbYtSlqWgIUmk8Se2jOYNbXozvdhHx8s2s4rn2k2Kck5eqRuFEPkKSOmHKLgQpaW1s0Ec6rAM5RDlyRCpzHRa0+GLXhBvzKB7I9A0hiWgb/XmCiSzknWM0M3rKT16shqtW0iH787YY70OySvYF/7hTfGS3T9dkADHY= Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com (10.169.137.153) by VI1PR0701MB2399.eurprd07.prod.outlook.com (10.168.139.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.13; Wed, 18 Sep 2019 07:33:46 +0000 Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com ([fe80::f44b:854c:51cf:c69f]) by VI1PR0701MB2286.eurprd07.prod.outlook.com ([fe80::f44b:854c:51cf:c69f%7]) with mapi id 15.20.2284.009; Wed, 18 Sep 2019 07:33:46 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: Kent Watsen , Martin Bjorklund CC: "netconf@ietf.org" Thread-Topic: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 Thread-Index: AQHVXFoK0TesLYidkkOIF6piEQcN7acOlbeAgBWZTACAAGVCgIAKAaAAgAA6YgCAATeLgIABJTgQ Date: Wed, 18 Sep 2019 07:33:46 +0000 Message-ID: References: <0100016d18b462b3-38420cd3-1259-47ea-aa1b-f250a8238c9b-000000@email.amazonses.com> <20190910.090803.448863675820254782.mbj@tail-f.com> <0100016d3aca212d-1791071e-66b5-4730-9cf2-6b4f16217d21-000000@email.amazonses.com> <20190916.212526.427039138127777720.mbj@tail-f.com> <0100016d3f864f24-aeab9f9b-fd8f-4688-89ba-a66f7571c943-000000@email.amazonses.com> In-Reply-To: <0100016d3f864f24-aeab9f9b-fd8f-4688-89ba-a66f7571c943-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dd1f7a4d-3f5d-46b2-75e2-08d73c0a8a59 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(49563074)(7193020); SRVR:VI1PR0701MB2399; x-ms-traffictypediagnostic: VI1PR0701MB2399: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01644DCF4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(136003)(366004)(396003)(39860400002)(189003)(199004)(186003)(7736002)(316002)(476003)(446003)(11346002)(110136005)(14444005)(256004)(486006)(33656002)(26005)(6506007)(53546011)(7696005)(14454004)(76176011)(102836004)(99286004)(66476007)(66556008)(64756008)(66446008)(66946007)(66616009)(6436002)(86362001)(45776006)(55016002)(6306002)(54896002)(9686003)(74316002)(8936002)(81166006)(76116006)(8676002)(81156014)(5660300002)(52536014)(71200400001)(478600001)(99936001)(71190400001)(2906002)(3846002)(790700001)(6116002)(66066001)(25786009)(229853002)(4326008)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2399; H:VI1PR0701MB2286.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: OW9n9V+4c3vQnaRNPuDQw40NQ263UTeKAGpcpSRCb6Y2Lut2gvhMZA9V9L2d06xPmoTzLZH0qDpwB/H6YY4T+qF7gWLB+UEIj/zhdvOC+h5MNFBS45M7DDEjFjygL1fzXwXogweXBw3KGz0BP8JOBKnfX+UsStrB+zh4jL9x3gMLmIbFUyvp7jqO6Yt15w7ROT+RpEzWBqhhBSdloZH7W5YOJYcH+hBcZkhxnMOth5mqqqdS77mJcKXh2ns2fh3NJL+uNWv7xw/6s4ftg2+W3acL7uYiGOMwruNwC4aS/pCTwk9oBHeSKaVEX24zS4C9ELwiI0AjTgYglc8IlgIXAruCTogM89uiZyxC6fxzUR0q7OEbZZ4nsNViwpkV7c1GS5GFVSUzaW5fQE5f8N0Uucn57mC3zlVbukvcBz/40HQ= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0168_01D56E04.2A31F7E0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: dd1f7a4d-3f5d-46b2-75e2-08d73c0a8a59 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2019 07:33:46.4102 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YTuWqYrdE84nDc6ITF/LETFnWANTE0mFAjh+f45mAeZnAm9lAcMj6AaJihEWyAaoW1HJHbXjXbLEyZCOpCrZr30bb98gd9N9uEaY9i5p/AQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2399 Archived-At: Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 07:33:53 -0000 ------=_NextPart_000_0168_01D56E04.2A31F7E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0169_01D56E04.2A31F7E0" ------=_NextPart_001_0169_01D56E04.2A31F7E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Maybe we could use as userId which configured the receiver as the userId of the publisher. After all he is the one that decides to send the notifications, if he has the correct rights, he can share the information with whoever he wants. Regards Balazs From: netconf On Behalf Of Kent Watsen Sent: 2019. szeptember 17., kedd 16:00 To: Martin Bjorklund Cc: netconf@ietf.org Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00 Do you mean to add to the draft a new section called something like "Authorization" that mimics what's in the SN draft regarding, e.g., NACM? No I mean that when the device generates a notification, NACM needs a user name to find the access control rules. What is the user name with this new protocol? Now I understand. There isn't a set answer for this yet. Two approaches: 1) We could claim that it is the "system" that is the publisher (effectively no NACM) 2) We could have an explicit field for the "send as" user. (default to "system"?) ------=_NextPart_001_0169_01D56E04.2A31F7E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Maybe we could use as userId which configured the = receiver as the userId of the publisher. After all he is the one that = decides to send the notifications, if he has the correct rights, he can = share the information with whoever he wants.

Regards Balazs

 

From: netconf = <netconf-bounces@ietf.org> On Behalf Of Kent = Watsen
Sent: 2019. szeptember 17., kedd 16:00
To: = Martin Bjorklund <mbj@tail-f.com>
Cc: = netconf@ietf.org
Subject: Re: [netconf] Adoption Call for = draft-mahesh-netconf-https-notif-00

 

 

Do = you mean to add to the draft a new section called something = like
"Authorization" that mimics what's in the SN draft = regarding, e.g.,
NACM?


No I mean that when the device generates a = notification, NACM needs a
user name to find the access control = rules.  What is the user name
with this new = protocol?

 

Now I understand.   There isn't a set answer for = this yet.   Two approaches:

 

1) We could claim that it is the "system" = that is the publisher (effectively no NACM)

2) We could have an explicit field for the "send = as" user.  (default to = "system"?)

 

------=_NextPart_001_0169_01D56E04.2A31F7E0-- ------=_NextPart_000_0168_01D56E04.2A31F7E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVbjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF/zCCA+egAwIBAgIR AOm+1xFswMzmixU1jNT/MSEwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMB4XDTE3MTAw OTE1MjQ1OFoXDTIwMTAwOTE1MjQ1N1owajERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD0Jh bMOhenMgTGVuZ3llbDEqMCgGCSqGSIb3DQEJARYbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t MQ8wDQYDVQQFEwZFVEhCTEwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUUtnneUfH i428YPkvW+AsCNeKCCKq72SzUZpBggijy+oLVO0cgTXXHygrZ+KT8TbyEkPwuHi+V4TQxWAyMhGa nWZHWZXe9ghEZrJDJbCzFMHOqR+wEDnI1vM3sfQQ68iSsWQLd9opnb2/ihiJlt9up75VRpyj5lea bvzxOLQimJgZiXaZzsPPT2nROyytKxOsE5KbfT3mNof3bMG1bggZtGGA1GBJchwdFJwQKIShfPVm 1CdulvJV1hPVecxttMJNPzSfSfryb/b64QnR5yc/pSx8SxD0h0rnNT73Al3Af2iRghdXN4omDKZY OcdK/sE5HTmLTFuWoZAnL/RntOK9AgMBAAGjggHBMIIBvTBIBgNVHR8EQTA/MD2gO6A5hjdodHRw Oi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggr BgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYI KwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNlcjAmBgNVHREEHzAdgRtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBSkJw2vbyMFmf9tY1urk9NeYfiMgTAfBgNVHSMEGDAWgBQcexmel5x2rCA92Nzj kWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAD1RCVf5Df2uCXwPveXz LBGIjsz3k2la5UUlioC+i4Ms6vGstqXIX7K24+Wc41npi+G5xFhvkAkmuTP/j29F5xJJuJcy3OcL 0br02vKe2WJJnlivB+X9plPg0kMUBS0lLq7kHPUrO/BLeIIFRuaky05eZlTnGNcLbn5VpZdjX4Ic XZV78qpZI3L67Po1UgHzOTiWolc75jrKOx3UOw98fWRrgJPBUIeqDeD1NDfF7PlM4Cqlad062o6L lM9wfAnoLzz0z04dPXtJkOcTiZgOLdPoKIm7LR1wZ9c6mYw4sgtoVAs16Y2cCPBxqWpsW+9ZCcDK PPZzeBezCKyicpDJbTqCVMILd3j38HWUPWFuVITZNgANzHW1CpgqmiLIAADiznCCtudTE+fcB3O9 duuu/yuEME17LMy1GYMKXs1QCXmTq2hrqTJQ2AA2TsWZtoxl3ViqJgNBWjnQiMwdCl5Dural2jZP /iU6MmiauUNYn9YW/ViUluoBBdaUHMpnP/7kM0Wk8j3Wzhcggx+Biml2gCopMaK1EJYjQH/2J95N GEkSdZfVzFUmwV3yMd4mOhIaxW0SEq9b1eWICZ/BAcVBpSyU0sE1gpnBO5wLxj+IpSdiGlS4jc37 qCr/39xdv1Unu93glCmHq0xgX54N8EsyMBPC3+zSSu1qhCbU7VJWIz2aMIIGwjCCBKqgAwIBAgIQ U7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEf MB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcx MjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy 3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt 8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6j RrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFl hFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/2 0aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCY rEqHMRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuT LUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMd ay0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqd GTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMB AAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVz dC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9j cmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpec dqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5 s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90 BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRy pF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86 IWst821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QD Xnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7 C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbN QUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbH XSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i 6Ds5j0Qpj5aQMYIDBTCCAwECAQEwXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MAkGBSsOAwIaBQCgggF+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTE5MDkxODA3MzM0NFowIwYJKoZIhvcNAQkEMRYEFJ8cPpd+BMk5FVrwAQA0dsehTzXsMEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQAhyVBna7ypX7M9E/LOAEl+EMAOv0x614nHacaa3+f4zFCxO1GkUx2J lpimUgQ1YUTQLrJjPS/MQhaCMqDx9AWIowbK5iC8DlB/WzlBXMZ8XJZoQ5TCqJg/jlqaTtMFbDPm uP/X5tIkjt8MUSwlu4gDI86JHL4sxxdVP1/QiIAYZRQJGGQne1Wz8p7USyRJLnHJAIHOyNVubZJh o4atvITZYooEI1DNyh8kaUW+ECT7yg1Zczkqj8Uamql+Yi6ZBD4McMin4dpF0i/Uj57jsXtiv499 u5YtUfLZiamiwQVtA3phT9MG3eJtxqIGW6co5L73StHOJ/pUMS5RTIyAnyGCAAAAAAAA ------=_NextPart_000_0168_01D56E04.2A31F7E0-- From nobody Wed Sep 18 02:36:12 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F9D1201E4 for ; Wed, 18 Sep 2019 02:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=Ci9vcZYF; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Dl/hmFuA 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 2sU9ONrJaGHe for ; Wed, 18 Sep 2019 02:36:08 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C67F81201C6 for ; Wed, 18 Sep 2019 02:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15970; q=dns/txt; s=iport; t=1568799367; x=1570008967; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aVXP3tltMMzvzHgTjiqimBF+Hf4mfQR+fSVbMFPvcx8=; b=Ci9vcZYFsdLRTYRivxpLRqODUwz7J/l4fqbFdtQ+9V+apqmAm7zTdn5p cWLoLinF86I28WFLeoFBI9soahWPKQA+SG8FsCdHTH8I0f3vi6ERkYikK d9c0alGto06pbYTD5kxyUY0ybYQb8uS1UMbOObU23VxE1g6LuMpvijyWX A=; IronPort-PHdr: =?us-ascii?q?9a23=3AAUvSahBF+koxShWJCSE4UyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs13kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNuHrazA9GuxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAAAg+oFd/4MNJK1dCRoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVQEAQEBAQsBgRUvUANtViAECyoKhBiDRwOKd4JciWaJMIR?= =?us-ascii?q?dgS6BJANUCQEBAQwBAS0CAQGEPwIXgmwjNQgOAgMJAQEEAQEBAgEFBG2FLQy?= =?us-ascii?q?FSgEBAQEDEhEKEwEBNwEPAgEGAhEEAQErAgICHxEdCAIEAQ0FCBqDAYEdTQM?= =?us-ascii?q?dAQKUY5BhAoE4iGFzgTKCfQEBBYUCDQuCFwmBNAGKRYFDGIFAP4FXgkw+ghq?= =?us-ascii?q?CABQYgwkygiaPVIUnJJccQQqCIpEDhBuZII4PihaOcwIEAgQFAg4BAQWBUwE?= =?us-ascii?q?2gVhwFYMngkKDcopTc4EpjioBgSIBAQ?= X-IronPort-AV: E=Sophos;i="5.64,520,1559520000"; d="scan'208,217";a="633049017" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Sep 2019 09:36:06 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x8I9a6Gi015942 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 18 Sep 2019 09:36:06 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 18 Sep 2019 04:36:05 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 18 Sep 2019 05:36:04 -0400 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 18 Sep 2019 04:36:04 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fZFKD5iq6vVuXT77S/NqvC8XmA9fxWscJNCxnmWPJnhteyd5J1oRfSgK2fhAOmvFJh604EY4a8FA69Ve4zOR6EBlXa06C8Dt394yfby9AZbvfUlINQcqIItVtaLP6m+3ZbuilBR2ZOcfyf0hTkKMISSkgWRGXAGdmULhWX4+24HLz2WfohINQCcoIcWZN52+urQJ3d6p/YnjLQ4ZIh2s0Jw9CWcEWo3YhpfP6QbW2nIvTUzRkmqMvgjzJzQEQYBT67/fOdRUJVUzKaolClwSi+piZXaofweFZDi6sYWzdKnslpopEQOwfRq1BvixXl+mI7pzEL+x4jCThUfDv1m2bg== 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=aVXP3tltMMzvzHgTjiqimBF+Hf4mfQR+fSVbMFPvcx8=; b=YFyMhxSFRFQ8kAyDkF7v/OYuoFyNadQBVSqqfBMuDmPicWxGKhNefZmT1Xbvf6zJQsloh+z3nowSHf8Q6AWJl3FaZQvd28TnyWXtzIEuROoJnirc1xpErrcpn8+fWckhl6FmrBZrE3gpQk8UfnpQOyO6rIyGsHMyOhJEF1zt86oL5JN1uPmuczSE5lIUiv+uW3kzx8RMmdCmN2cezMIzEERbgLS7i7GpFpSqn4vWe+7F68VTfBT/jN6A/TnuMXweFDZAhCV2jOZ+gjf2QkBqwlZghQ9bLq3/3CeRn+q9e+2iD7WBVigPkXZdOOaFNnSxQJkVa90K143FlwPTQQTyrA== 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=aVXP3tltMMzvzHgTjiqimBF+Hf4mfQR+fSVbMFPvcx8=; b=Dl/hmFuAs5iShHq6Wlgb65NeNuX4rJlwDaK15NHhf07vzKCZtjUQuPV9Utr2kgv0Lia+u77ZlW/40uqK+aqRctmYIVZSCLcs/DjnwQ/kDuM9xib3N5Jp1IlhRDuYSGzKY2IQG6GB3DzVa6AGAMA795cBawGgSwBPZN85q671SjI= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3630.namprd11.prod.outlook.com (20.178.253.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.20; Wed, 18 Sep 2019 09:36:03 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6%7]) with mapi id 15.20.2263.023; Wed, 18 Sep 2019 09:36:03 +0000 From: "Rob Wilton (rwilton)" To: "Salz, Rich" , Kent Watsen CC: Russ Housley , "netconf@ietf.org" , Sean Turner , Rifaat Shekh-Yusef Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxVu0aQE+n/K0iPwVgOy8FH/KcpQIdQgAVLFQCAARKfAIAATvkAgAABvxCAAC5vAIAAAggggAADhQCAAQHLcA== Date: Wed, 18 Sep 2019 09:36:03 +0000 Message-ID: References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@email.amazonses.com> <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> In-Reply-To: <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [173.38.220.61] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6590751b-f9dc-44c7-0f99-08d73c1b9fd2 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB3630; x-ms-traffictypediagnostic: MN2PR11MB3630: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01644DCF4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(39860400002)(376002)(396003)(366004)(199004)(189003)(7696005)(66066001)(86362001)(478600001)(54906003)(8676002)(71200400001)(71190400001)(14454004)(74316002)(316002)(7736002)(110136005)(6436002)(256004)(81156014)(229853002)(6306002)(54896002)(55016002)(52536014)(186003)(5660300002)(76176011)(66946007)(102836004)(6506007)(53546011)(446003)(476003)(11346002)(66556008)(64756008)(66446008)(66476007)(26005)(486006)(4326008)(99286004)(6246003)(9686003)(76116006)(33656002)(81166006)(25786009)(9326002)(8936002)(3846002)(6116002)(790700001)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3630; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: c/MBofD0/w0aY7gzid4jhP5RUa3WWOp1miunmA3TX+JTadzsnepguuhdwNY/0bQavglc+sex0hXwRB2IV8nZMluISxdxkVjTXLBc2yrA75pJ/baYv9VIo5QtgZWwpc4IOJsNJdI3QKcFPeSnRZ/p/W/x6j4l+yc/i/dyQQoDscA6lkaKbbsH5+DEEZJanxDx9IVEVVPQ4t21+Jh4VSqehddnLTkWxw4pUyf3RrPuYsXDvC1BsjaEG0li9lC2UBGXtCxonG0WlDK3xNxqAWDve60n14wgSukSOZRCI+cA/aXvI1kRLxIaBbjHo3mGvBVrZfbrojWsyDUBoAN8raVsVQO1J4vv4q8eSkevla2QSx0Q3dp45NYAI6EvyJkJathkQBVXKQhpVp8vWMa6rI9x44lDjJVqAgwY+EfTWtcR5lU= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366F20EE2FD6DF04B965125B58E0MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6590751b-f9dc-44c7-0f99-08d73c1b9fd2 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2019 09:36:03.8632 (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: U17I3FRsRhjGAv2pgMqBVdLmL9EKBc6ZJ+y8i8HwwqMmxvdMrTHPZLl4myA77sAc2m96gDlMPwp+1FghG3LcwA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3630 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.23, xch-rcd-013.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 09:36:11 -0000 --_000_MN2PR11MB4366F20EE2FD6DF04B965125B58E0MN2PR11MB4366namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmljaCwNCg0KRnJvbTogU2FseiwgUmljaCA8cnNhbHpAYWthbWFpLmNvbT4NClNlbnQ6IDE3 IFNlcHRlbWJlciAyMDE5IDE4OjA3DQpUbzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25A Y2lzY28uY29tPjsgS2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0Pg0KQ2M6IFJ1c3Mg SG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+OyBuZXRjb25mQGlldGYub3JnOyBTZWFuIFR1 cm5lciA8c2VhbkBzbjNyZC5jb20+OyBSaWZhYXQgU2hla2gtWXVzZWYgPHJpZmFhdC5pZXRmQGdt YWlsLmNvbT4NClN1YmplY3Q6IFJlOiBbbmV0Y29uZl0gY3J5cHRvLXR5cGVzIGZhbGxiYWNrIHN0 cmF0ZWd5DQoNCkkgZG8gbm90IHRoaW5rIHVzaW5nIGFsZ29yaXRobXMgYXMgdGhlIGJhc2UgY2xh c3NlcyBpcyBhIGdvb2QgaWRlYS4gIEkgdGhpbmsgaXQgaXMgbXVjaCBiZXR0ZXIgdG8gaGF2ZSB0 aGUgdHlwZSBvZiBrZXkgbWF0ZXJpYWwgYXMgdGhlIGJhc2UgY2xhc3M6DQogICAgICAgICAgICAg ICAgYXN5bW1ldHJpYy1rZXkgKFJTQSwgRUNDLCBldGMpDQogICAgICAgICAgICAgICAgc3ltbWV0 cmljLWtleSAoQUVTIDNERVMgZXRjKQ0KICAgICAgICAgICAgICAgIGJ5dGUgc3RyaW5nIChtYXli ZeKApikNCm5vbmNlIChub24tcmV1c2VkIHN0cmVhbSBvZiBiaXRzIHVzZWQgaW4gQUVTLUdDTSwg RWREU0Egc2lnbmF0dXJlLCBFRERTQSBzaWduYXR1cmVzLCBldGMpDQogICAgICAgICAgICAgICAg dGFnICh1c2VkIGluIEtERiBmdW5jdGlvbnMsIGFsbW9zdCBhbHdheXMgYSB0ZXh0IHN0cmluZykN Cg0KVGhlICp1c2UqIG9mIHRoZSBpZGVudGl0aWVzIHNob3VsZCBiZSBpbXBsaWVkIGJ5IHRoZSBv cGVyYXRpb24uDQpbUlddDQpPSy4gIFNvLCBpbiBZQU5HIEkgdGhpbmsgdGhlIGRlZmluaXRpb24g b2YgYSBiYXNlIGlkZW50aXR5IGlzIGVmZmVjdGl2ZWx5IGRlZmluZWQgYnkgaG93IGl0IGlzIGlu dGVuZGVkIHRvIGJlIHVzZWQuICBJLmUuIHNvbWV3aGVyZSBpbiB0aGUgbW9kZWwgdGhlcmUgaXMg YW4gaWRlbnRpdHkgcmVmZXJlbmNlIHRoYXQgaW5kaWNhdGVzIHRoYXQgaXQgY2FuIHRha2UgYW55 IGlkZW50aXR5IHZhbHVlIHRoYXQgaXMgZGVyaXZlZCBmcm9tIHRoYXQgYmFzZSBpZGVudGl0eS4N Cg0KU28sIGZyb20gdGhlIGtleXN0b3JlIG1vZGVsIEkgY2FuIHNlZToNCg0K4oCca2V5c3RvcmUv YXN5bW1ldHJpYy1rZXlzL2FzeW1tZXRyaWMta2V5L2FsZ29yaXRobeKAnSB1c2VzIGFueSBpZGVu dGl0eSBkZXJpdmVkIGZyb20g4oCcYXN5bW1ldHJpYy1rZXktYWxnb3JpdGht4oCdDQrigJxrZXlz dG9yZS9zeW1tZXRyaWMta2V5cy9zeW1tZXRyaWMta2V5L2FsZ29yaXRobeKAnSB1c2VzIGFueSBp ZGVudGl0eSBkZXJpdmVkIGZyb20g4oCcZW5jcnlwdGlvbi1hbGdvcml0aG3igJ0NCg0KSSBhc3N1 bWUgdGhhdCB0aGUgb3RoZXIgYmFzZSBpZGVudGl0aWVzIGFyZSB1c2VkIGluIHRoZSBvdGhlciBk cmFmdHMuDQoNCkkgYWxzbyB0aGluayB0aGF0IHRoZSBpZGVudGl0aWVzIGFyZSBpZGVudGlmeWlu ZyBlbmNyeXB0aW9uLWtleS1hbGdvcml0aG1zLCBub3QgdGhlIGtleXMgdGhlbXNlbHZlcywgc28g aGF2aW5nIGFsZ29yaXRobSBpbiB0aGUgbmFtZSBkb2VzbuKAmXQgc2VlbSBwYXJ0aWN1bGFybHkg c3RyYW5nZS4NCg0KDQpJIGxpa2UgdGhlIGlkZWEgb2YgcGFydGl0aW9uaW5nIGJ5IOKAnGhlcmUg aXMgd2hhdCB5b3UgbmVlZCB0byBjb25maWd1cmUgYSB0eXBpY2FsIEhUVFBTIHNlcnZlcuKAnSBp biBvbmUgZG9jdW1lbnQgYW5kIOKAnGhlcmUgaXMgd2hhdCB5b3UgbmVlZCB0byBjb25maWd1cmUg YSB0eXBpY2FsIFNTSCBzZXJ2ZXLigJ0NCltSV10NCldlIHN0aWxsIG5lZWQgdG8gaGF2ZSBjYXJl IGhlcmUuICBQcmVzdW1hYmx5IHRoZXJlIHdpbGwgYmUgY2FzZXMgd2hlcmUgdGhlIHNhbWUga2V5 IGFsZ29yaXRobSBpcyB1c2VkIGluIG11bHRpcGxlIHBsYWNlcy4gIEkgd2FzIHBhcnRseSB0cnlp bmcgdG8gdGllIHRoZSBwYXJ0aXRpb25pbmcgaW50byBtb2R1bGVzIGFib3V0IHdoZXJlIHRoZSBh bGdvcml0aG1zIGFyZSBiZWluZyBkZWZpbmVkIChpLmUuIHdoaWNoIFJGQ3MpIHJhdGhlciB0aGVu IHdoZXJlIHRoZXkgYXJlIG5lY2Vzc2FyaWx5IHVzZWQuDQoNCg0KRG9lcyB0aGF0IGFuc3dlciB5 b3VyIHF1ZXN0aW9uPw0KW1JXXQ0KWWVzLCB0aGFuayB5b3UuDQoNClRoYW5rcywNClJvYg0KDQo= --_000_MN2PR11MB4366F20EE2FD6DF04B965125B58E0MN2PR11MB4366namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0 UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7 DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBj bTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5I VE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAs IGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1h bDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHls ZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1m dHINCgl7bXNvLXN0eWxlLW5hbWU6bV9mdHI7fQ0Kc3Bhbi5taGRyDQoJe21zby1zdHlsZS1uYW1l Om1faGRyO30NCnNwYW4uRW1haWxTdHlsZTI4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K c3Bhbi5FbWFpbFN0eWxlMjkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWls U3R5bGUzMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTMxDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIFJpY2gsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyI+IFNhbHosIFJpY2ggJmx0O3JzYWx6QGFrYW1haS5jb20mZ3Q7DQo8YnI+DQo8 Yj5TZW50OjwvYj4gMTcgU2VwdGVtYmVyIDIwMTkgMTg6MDc8YnI+DQo8Yj5Ubzo8L2I+IFJvYiBX aWx0b24gKHJ3aWx0b24pICZsdDtyd2lsdG9uQGNpc2NvLmNvbSZndDs7IEtlbnQgV2F0c2VuICZs dDtrZW50JiM0MztpZXRmQHdhdHNlbi5uZXQmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBSdXNzIEhvdXNs ZXkgJmx0O2hvdXNsZXlAdmlnaWxzZWMuY29tJmd0OzsgbmV0Y29uZkBpZXRmLm9yZzsgU2VhbiBU dXJuZXIgJmx0O3NlYW5Ac24zcmQuY29tJmd0OzsgUmlmYWF0IFNoZWtoLVl1c2VmICZsdDtyaWZh YXQuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0Y29uZl0g Y3J5cHRvLXR5cGVzIGZhbGxiYWNrIHN0cmF0ZWd5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgZG8gbm90IHRoaW5rIHVzaW5n IGFsZ29yaXRobXMgYXMgdGhlIGJhc2UgY2xhc3NlcyBpcyBhIGdvb2QgaWRlYS4mbmJzcDsgSSB0 aGluayBpdCBpcyBtdWNoIGJldHRlciB0byBoYXZlIHRoZSB0eXBlIG9mIGtleSBtYXRlcmlhbCBh cyB0aGUgYmFzZSBjbGFzczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFzeW1tZXRyaWMta2V5IChSU0EsIEVDQywgZXRj KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgc3ltbWV0cmljLWtleSAoQUVTIDNERVMgZXRjKTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYnl0ZSBz dHJpbmcgKG1heWJl4oCmKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7dGV4dC1pbmRlbnQ6MzYuMHB0Ij48c3BhbiBs YW5nPSJFTi1VUyI+bm9uY2UgKG5vbi1yZXVzZWQgc3RyZWFtIG9mIGJpdHMgdXNlZCBpbiBBRVMt R0NNLCBFZERTQSBzaWduYXR1cmUsIEVERFNBIHNpZ25hdHVyZXMsIGV0Yyk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRh ZyAodXNlZCBpbiBLREYgZnVuY3Rpb25zLCBhbG1vc3QgYWx3YXlzIGEgdGV4dCBzdHJpbmcpPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IGxhbmc9IkVOLVVTIj5UaGUgKjxiPnVzZTwvYj4qIG9mIHRoZSBpZGVudGl0aWVzIHNob3VsZCBi ZSBpbXBsaWVkIGJ5IHRoZSBvcGVyYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiPltSV10gPG86cD48L286cD48 L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5n PSJFTi1VUyI+T0suICZuYnNwO1NvLCBpbiBZQU5HIEkgdGhpbmsgdGhlIGRlZmluaXRpb24gb2Yg YSBiYXNlIGlkZW50aXR5IGlzIGVmZmVjdGl2ZWx5IGRlZmluZWQgYnkgaG93IGl0IGlzIGludGVu ZGVkIHRvIGJlIHVzZWQuJm5ic3A7IEkuZS4gc29tZXdoZXJlIGluIHRoZSBtb2RlbCB0aGVyZSBp cyBhbiBpZGVudGl0eSByZWZlcmVuY2UgdGhhdCBpbmRpY2F0ZXMgdGhhdCBpdCBjYW4gdGFrZSBh bnkNCiBpZGVudGl0eSB2YWx1ZSB0aGF0IGlzIGRlcml2ZWQgZnJvbSB0aGF0IGJhc2UgaWRlbnRp dHkuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48aT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyI+U28sIGZy b20gdGhlIGtleXN0b3JlIG1vZGVsIEkgY2FuIHNlZTo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9i PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxpPjxzcGFuIGxhbmc9IkVOLVVTIj7igJxrZXlzdG9yZS9hc3ltbWV0cmljLWtleXMvYXN5bW1l dHJpYy1rZXkvYWxnb3JpdGht4oCdIHVzZXMgYW55IGlkZW50aXR5IGRlcml2ZWQgZnJvbSDigJxh c3ltbWV0cmljLWtleS1hbGdvcml0aG3igJ08bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIj7igJxrZXlzdG9y ZS9zeW1tZXRyaWMta2V5cy9zeW1tZXRyaWMta2V5L2FsZ29yaXRobeKAnSB1c2VzIGFueSBpZGVu dGl0eSBkZXJpdmVkIGZyb20g4oCcZW5jcnlwdGlvbi1hbGdvcml0aG3igJ08bzpwPjwvbzpwPjwv c3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGFzc3VtZSB0aGF0IHRoZSBvdGhl ciBiYXNlIGlkZW50aXRpZXMgYXJlIHVzZWQgaW4gdGhlIG90aGVyIGRyYWZ0cy48bzpwPjwvbzpw Pjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGFsc28gdGhpbmsgdGhhdCB0 aGUgaWRlbnRpdGllcyBhcmUgaWRlbnRpZnlpbmcgZW5jcnlwdGlvbi1rZXktYWxnb3JpdGhtcywg bm90IHRoZSBrZXlzIHRoZW1zZWx2ZXMsIHNvIGhhdmluZyBhbGdvcml0aG0gaW4gdGhlIG5hbWUg ZG9lc27igJl0IHNlZW0gcGFydGljdWxhcmx5IHN0cmFuZ2UuPG86cD48L286cD48L3NwYW4+PC9p PjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz cGFuIGxhbmc9IkVOLVVTIj5JIGxpa2UgdGhlIGlkZWEgb2YgcGFydGl0aW9uaW5nIGJ5IOKAnGhl cmUgaXMgd2hhdCB5b3UgbmVlZCB0byBjb25maWd1cmUgYSB0eXBpY2FsIEhUVFBTIHNlcnZlcuKA nSBpbiBvbmUgZG9jdW1lbnQgYW5kIOKAnGhlcmUgaXMgd2hhdCB5b3UgbmVlZCB0byBjb25maWd1 cmUgYSB0eXBpY2FsIFNTSCBzZXJ2ZXLigJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyI+W1JXXSA8bzpwPjwvbzpwPjwv c3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9 IkVOLVVTIj5XZSBzdGlsbCBuZWVkIHRvIGhhdmUgY2FyZSBoZXJlLiZuYnNwOyBQcmVzdW1hYmx5 IHRoZXJlIHdpbGwgYmUgY2FzZXMgd2hlcmUgdGhlIHNhbWUga2V5IGFsZ29yaXRobSBpcyB1c2Vk IGluIG11bHRpcGxlIHBsYWNlcy4mbmJzcDsgSSB3YXMgcGFydGx5IHRyeWluZyB0byB0aWUgdGhl IHBhcnRpdGlvbmluZyBpbnRvIG1vZHVsZXMgYWJvdXQgd2hlcmUgdGhlIGFsZ29yaXRobXMgYXJl DQogYmVpbmcgZGVmaW5lZCAoaS5lLiB3aGljaCBSRkNzKSByYXRoZXIgdGhlbiB3aGVyZSB0aGV5 IGFyZSBuZWNlc3NhcmlseSB1c2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1V UyI+RG9lcyB0aGF0IGFuc3dlciB5b3VyIHF1ZXN0aW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIj5bUlddIDxvOnA+ PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNw YW4gbGFuZz0iRU4tVVMiPlllcywgdGhhbmsgeW91LjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PGk+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIj5Sb2I8L3Nw YW4+PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_MN2PR11MB4366F20EE2FD6DF04B965125B58E0MN2PR11MB4366namp_-- From nobody Wed Sep 18 05:41:34 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87EFD12004D for ; Wed, 18 Sep 2019 05:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 G_bMjeEXhkwX for ; Wed, 18 Sep 2019 05:41:31 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 C4EF4120025 for ; Wed, 18 Sep 2019 05:41:31 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8ICax4v004633; Wed, 18 Sep 2019 13:41:28 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=U+wXtmk9QSoFIv74L+K0hSr0xJYwlMzMMTLG2ILGcEM=; b=jXHeFdeRP86ngEFyhJR9dBCnoTowxDpnkGEHvJzltOXhs6GdM7jnEMty1n6KvGgraY5v n2A/wNNjawv8MKNL2a5sFRSB9IJe6LagbmX5XbRSM3tagLMudyR5qJGcLBNemBKHlVqU sfndXhvBU5uN8VmQ8Um4qiNhSrjcNizS+y3vL8j92CXTk+NEuFAWbjrdnpb0AFCFUjcw w7lZG+8Xv1a4mP0IXBg8jiG2xkXZgldzIGgAeud3LXX0n1oR2CMSfThpMPwA6mRMFmlj 7guPGEcMdNvg9cruZhsiP6RZUdXqOEbP7LvviZpWxeYzjPDNKPUXtkQoZUcwYvS7e2KQ Zg== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2v37vyk3pp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Sep 2019 13:41:27 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x8ICYWYi027018; Wed, 18 Sep 2019 08:41:26 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2v37r1k9vw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 18 Sep 2019 08:41:26 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 18 Sep 2019 08:41:26 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Wed, 18 Sep 2019 08:41:25 -0400 From: "Salz, Rich" To: "Rob Wilton (rwilton)" , Kent Watsen CC: Russ Housley , "netconf@ietf.org" , Sean Turner , Rifaat Shekh-Yusef Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxGVhFlbERW30moo9Q8WhnpJqcpkUCAgAU9agCAASLxgP//+5oAgABHL4D//+j+AIAARomA//+/BAAAKuwGgP//8LyA Date: Wed, 18 Sep 2019 12:41:24 +0000 Message-ID: References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@email.amazonses.com> <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.155] Content-Type: multipart/alternative; boundary="_000_EBE4757DE99E41EBA52BA25F023BF4BCakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-18_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=675 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909180128 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-18_07:2019-09-17,2019-09-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 priorityscore=1501 mlxlogscore=999 phishscore=0 lowpriorityscore=0 impostorscore=0 mlxscore=0 adultscore=0 spamscore=0 clxscore=1015 suspectscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909180129 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 12:41:34 -0000 --_000_EBE4757DE99E41EBA52BA25F023BF4BCakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgT0suICBTbywgaW4gWUFORyBJIHRoaW5rIHRoZSBkZWZpbml0aW9uIG9mIGEgYmFzZSBp ZGVudGl0eSBpcyBlZmZlY3RpdmVseSBkZWZpbmVkIGJ5IGhvdyBpdCBpcyBpbnRlbmRlZCB0byBi ZSB1c2VkLiAgSS5lLiBzb21ld2hlcmUgaW4gdGhlIG1vZGVsIHRoZXJlIGlzIGFuIGlkZW50aXR5 IHJlZmVyZW5jZSB0aGF0IGluZGljYXRlcyB0aGF0IGl0IGNhbiB0YWtlIGFueSBpZGVudGl0eSB2 YWx1ZSB0aGF0IGlzIGRlcml2ZWQgZnJvbSB0aGF0IGJhc2UgaWRlbnRpdHkuDQoNCkkgd2lsbCBo YXZlIHRvIGdvIGxlYXJuIGEgaGVjayBvZiBhIGxvdCBtb3JlIGFib3V0IFlBTkcgYmVmb3JlIHRo ZSBuZXh0IElFVEYuDQoNCg0KICAqICAgV2Ugc3RpbGwgbmVlZCB0byBoYXZlIGNhcmUgaGVyZS4g IFByZXN1bWFibHkgdGhlcmUgd2lsbCBiZSBjYXNlcyB3aGVyZSB0aGUgc2FtZSBrZXkgYWxnb3Jp dGhtIGlzIHVzZWQgaW4gbXVsdGlwbGUgcGxhY2VzLiAgSSB3YXMgcGFydGx5IHRyeWluZyB0byB0 aWUgdGhlIHBhcnRpdGlvbmluZyBpbnRvIG1vZHVsZXMgYWJvdXQgd2hlcmUgdGhlIGFsZ29yaXRo bXMgYXJlIGJlaW5nIGRlZmluZWQgKGkuZS4gd2hpY2ggUkZDcykgcmF0aGVyIHRoZW4gd2hlcmUg dGhleSBhcmUgbmVjZXNzYXJpbHkgdXNlZC4NCg0KTHVja2lseSBUTFMgYW5kIFNTSCBhcmUgZGVm aW5lZCBpbiBzZXBhcmF0ZSBSRkPigJlzLiA6KQ0KDQo= --_000_EBE4757DE99E41EBA52BA25F023BF4BCakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <3D943B6CB9D94B46B911F3A0F12A3878@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5t c29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u RW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubWZ0cg0KCXttc28tc3R5bGUtbmFtZTptX2Z0cjt9 DQpzcGFuLm1oZHINCgl7bXNvLXN0eWxlLW5hbWU6bV9oZHI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyOQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTMwDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpz cGFuLkVtYWlsU3R5bGUzMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlk OjE4OTc1NDQ5NTk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOi05NTQxNjU4NjYgLTYyNzMwNDIgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwx DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIjsNCgltc28tYmlkaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1hbnNpLWZv bnQtd2VpZ2h0OmJvbGQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+ PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8dWwgc3R5bGU9Im1hcmdpbi10 b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PGI+PGk+T0suICZuYnNw O1NvLCBpbiBZQU5HIEkgdGhpbmsgdGhlIGRlZmluaXRpb24gb2YgYSBiYXNlIGlkZW50aXR5IGlz IGVmZmVjdGl2ZWx5IGRlZmluZWQgYnkgaG93IGl0IGlzIGludGVuZGVkIHRvIGJlIHVzZWQuJm5i c3A7IEkuZS4gc29tZXdoZXJlIGluIHRoZSBtb2RlbCB0aGVyZSBpcyBhbiBpZGVudGl0eSByZWZl cmVuY2UNCiB0aGF0IGluZGljYXRlcyB0aGF0IGl0IGNhbiB0YWtlIGFueSBpZGVudGl0eSB2YWx1 ZSB0aGF0IGlzIGRlcml2ZWQgZnJvbSB0aGF0IGJhc2UgaWRlbnRpdHkuPC9pPjwvYj48bzpwPjwv bzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPiZuYnNwOzxvOnA+PC9v OnA+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdpbGwgaGF2ZSB0byBnbyBs ZWFybiBhIGhlY2sgb2YgYSBsb3QgbW9yZSBhYm91dCBZQU5HIGJlZm9yZSB0aGUgbmV4dCBJRVRG LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PG86cD4mbmJzcDs8 L286cD48L2k+PC9iPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2Mi Pg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21z by1saXN0OmwwIGxldmVsMSBsZm8xIj48Yj48aT5XZSBzdGlsbCBuZWVkIHRvIGhhdmUgY2FyZSBo ZXJlLiZuYnNwOyBQcmVzdW1hYmx5IHRoZXJlIHdpbGwgYmUgY2FzZXMgd2hlcmUgdGhlIHNhbWUg a2V5IGFsZ29yaXRobSBpcyB1c2VkIGluIG11bHRpcGxlIHBsYWNlcy4mbmJzcDsgSSB3YXMgcGFy dGx5IHRyeWluZyB0byB0aWUgdGhlIHBhcnRpdGlvbmluZyBpbnRvIG1vZHVsZXMNCiBhYm91dCB3 aGVyZSB0aGUgYWxnb3JpdGhtcyBhcmUgYmVpbmcgZGVmaW5lZCAoaS5lLiB3aGljaCBSRkNzKSBy YXRoZXIgdGhlbiB3aGVyZSB0aGV5IGFyZSBuZWNlc3NhcmlseSB1c2VkLjwvaT48L2I+PG86cD48 L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkx1Y2tpbHkgVExTIGFuZCBTU0ggYXJlIGRlZmluZWQg aW4gc2VwYXJhdGUgUkZD4oCZcy4gOik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_EBE4757DE99E41EBA52BA25F023BF4BCakamaicom_-- From nobody Wed Sep 18 05:45:28 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63BC120241 for ; Wed, 18 Sep 2019 05:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=VJ7sTyJV; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=jQu0Chea 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 dSq-xVINmHGv for ; Wed, 18 Sep 2019 05:45:23 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7C79120825 for ; Wed, 18 Sep 2019 05:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20400; q=dns/txt; s=iport; t=1568810723; x=1570020323; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NuXGWRiIUBN6tSL3TNVPy1y/oVfpKDu6JkVO0pG3iCs=; b=VJ7sTyJVApnkp+dzePibTG3oqGIp7Hd3UFy/EiGuP/LNSlp9LWKQ6YuL z/Qh/aXQy7JgSrhqta6BUZqpFxNiQH9lXWfeMS0eVvdY/T5RDlzZg//zY zNFNytP+pemOzSDz330+mMqSXl0Bs9prCiXqwLcNYLRs/XfnZ1wpXVu44 Q=; IronPort-PHdr: =?us-ascii?q?9a23=3A/6WO8BfM1snp+nNS+1iGjj9tlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGRD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/dTM7GNhFUndu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAADWJYJd/4YNJK1dCRoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVUDAQEBAQsBgRUvUANtViAECyoKhBiDRwOKd4JciWaODYE?= =?us-ascii?q?ugSQDVAkBAQEMAQEtAgEBhD8CF4JsIzYHDgIDCQEBBAEBAQIBBQRthS0MhUo?= =?us-ascii?q?BAQEBAxIRChMBATcBDwIBBgIRBAEBKwICAh8RHQgCBAENBQgagwGBHU0DHQE?= =?us-ascii?q?ClFGQYQKBOIhhc4Eygn0BAQWFCA0LghcJgTQBikWBQxiBQD+BV4JMPoIaggA?= =?us-ascii?q?sgwkygiaPVIUnl0BBCoIikQOEG5kgjg+KFo5zAgQCBAUCDgEBBYFZAi+BWHA?= =?us-ascii?q?VgydQEBSBToNyilNzgSmOKgGBHQUBAQ?= X-IronPort-AV: E=Sophos;i="5.64,520,1559520000"; d="scan'208,217";a="328565324" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Sep 2019 12:45:22 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x8ICjMnc009284 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 18 Sep 2019 12:45:22 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 18 Sep 2019 07:45:21 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 18 Sep 2019 07:45:21 -0500 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 18 Sep 2019 07:45:21 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MbzDvgMiScHvHts/HVADTu0xBorsCM3Fox+LiRT4mb/6B63tpYOzstmScN3122KPFZ16K9Gp0kdxBFPX+SEHdDZblwnP6EiYZsPUu5fMH2FHT+dW3uSr7qLMENUYcIoHVykLv0HdP6XH2EnXE84fxHkInhM96Jx27D11foVE1bGPynIBMtimVxyAXYZjpFL0jz6vxPHv5sx5H+HlpD2JYo3yqke2nlpjOlULyMlgFOQDGt+Iivxb6SP35kExryYoaBcNT5SL54hyraH3l7sSuLOnWOLDSWFbcuwz0T2zjvz7RHWFc6qFWSXj2AWJ4TFCU3iN+0YJgaD0mmsh/52Xkw== 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=NuXGWRiIUBN6tSL3TNVPy1y/oVfpKDu6JkVO0pG3iCs=; b=l+G3un4HFuRt2u3mNbQEyRuzLXS2K4P5k1QAaPfxccVgsk8kfh0FuIwmNr4/nHaPYM7Xlpp5mlfMY4ex+uoXVdi51TJ3wjX2ZIC4xDEk4ZfCzs9CkJLouMf+ruz+FbB7pLWeDq15mL6FnMWxDDOBgTN6dprNcZvVsU71hHv4yNUxhAPWYFh4Y1BnAqUBKZQhVm+3TmVqhB03W3usaWXDjse3yLbvzwrNacoyxpHSwuexHKewl+19HosS7bfWimKtyAMjdKJ/rcBi36jCMhIX7UpaCQH9E2ooemY/K9iG7hy/JjjI0sq0L/99UO8SwoHUzNv3FlGlveZ25GIWFAmSNQ== 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=NuXGWRiIUBN6tSL3TNVPy1y/oVfpKDu6JkVO0pG3iCs=; b=jQu0CheadE9ntiEZILn11O0CDWlYkzy4FoCFO96SyBLqZEvJeE73k8rm6t8R1EcPbLPWV9RCh3Mfp8LvGtlzDLnMXI8A7vs6QwarViZtV8CSrb0nnozuODhXXYO/4ELde+g7TebMxUDvGaqoDJchdUCZ9EScMQ+0w01TOtpTdrk= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB4030.namprd11.prod.outlook.com (10.255.181.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.17; Wed, 18 Sep 2019 12:45:20 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6%7]) with mapi id 15.20.2263.023; Wed, 18 Sep 2019 12:45:20 +0000 From: "Rob Wilton (rwilton)" To: "Salz, Rich" , Kent Watsen CC: Russ Housley , "netconf@ietf.org" , Sean Turner , Rifaat Shekh-Yusef Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxVu0aQE+n/K0iPwVgOy8FH/KcpQIdQgAVLFQCAARKfAIAATvkAgAABvxCAAC5vAIAAAggggAADhQCAAQHLcIAARlAAgAAAT1A= Date: Wed, 18 Sep 2019 12:45:19 +0000 Message-ID: References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@email.amazonses.com> <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [173.38.220.61] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 62beb5e4-d6e7-4053-bb6c-08d73c3610a8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB4030; x-ms-traffictypediagnostic: MN2PR11MB4030: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2582; x-forefront-prvs: 01644DCF4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(376002)(346002)(366004)(396003)(199004)(189003)(7696005)(3846002)(110136005)(71200400001)(6246003)(64756008)(6306002)(71190400001)(66556008)(476003)(6436002)(486006)(5660300002)(256004)(7736002)(86362001)(9686003)(55016002)(66476007)(66946007)(33656002)(66066001)(66446008)(54896002)(74316002)(76116006)(316002)(2906002)(8936002)(6116002)(53546011)(790700001)(8676002)(4326008)(52536014)(229853002)(81156014)(102836004)(81166006)(26005)(99286004)(11346002)(446003)(478600001)(25786009)(14454004)(54906003)(6506007)(186003)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4030; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: CxS45q+KE1D8w37Bcb1hXkDau7aIk9wNrjKgLz7Wn1z7aosTp2OOeUbLVEArru/Jgz476W/uBTO0fP6O5hbuW2B8TGSgxSmnD6DKygQH2s1Ma7HyrRFQd/JRchPpKemDMO2yYLppESsrqSRPF9d8o+FEqBpTtgifiG7tSeEjMCi8eNnqXw4K5hBar46XBLGaFBC75OBXZdkXnH9Tl+zg6WNhJImhtQ13YsWpMQxL62LFtCVvBP3Q+B4cXvD5CGzj/GM4e6ozuuxqSZlkt4M2IX1PV84uWARjQOKrqkMJv5QVM6kFGlALut81TgWSTlDXUkVQKiN1KqLxaybKRYVfvyKAyFdZtS+uGRo2q33E4FvN4sJdB82tHrhbKiIZfmVn6wwjkpswihqdPYsl9mq384oJSSpjGjHR9R6EkYDfRx0= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366E4ECE10DFB018941BA5FB58E0MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 62beb5e4-d6e7-4053-bb6c-08d73c3610a8 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2019 12:45:20.0349 (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: 7jbpfzb3MhXLTC8kwci5pT8wFjvSTmgFXqBBm4kXtWLJshx50edVftHRECp/bOMa8IlWcGFatuX0INBUewgwfw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4030 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 12:45:26 -0000 --_000_MN2PR11MB4366E4ECE10DFB018941BA5FB58E0MN2PR11MB4366namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IFNhbHosIFJpY2ggPHJzYWx6QGFrYW1haS5jb20+DQpTZW50OiAxOCBTZXB0ZW1i ZXIgMjAxOSAxMzo0MQ0KVG86IFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNv bT47IEtlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD4NCkNjOiBSdXNzIEhvdXNsZXkg PGhvdXNsZXlAdmlnaWxzZWMuY29tPjsgbmV0Y29uZkBpZXRmLm9yZzsgU2VhbiBUdXJuZXIgPHNl YW5Ac24zcmQuY29tPjsgUmlmYWF0IFNoZWtoLVl1c2VmIDxyaWZhYXQuaWV0ZkBnbWFpbC5jb20+ DQpTdWJqZWN0OiBSZTogW25ldGNvbmZdIGNyeXB0by10eXBlcyBmYWxsYmFjayBzdHJhdGVneQ0K DQoNCsOYICBPSy4gIFNvLCBpbiBZQU5HIEkgdGhpbmsgdGhlIGRlZmluaXRpb24gb2YgYSBiYXNl IGlkZW50aXR5IGlzIGVmZmVjdGl2ZWx5IGRlZmluZWQgYnkgaG93IGl0IGlzIGludGVuZGVkIHRv IGJlIHVzZWQuICBJLmUuIHNvbWV3aGVyZSBpbiB0aGUgbW9kZWwgdGhlcmUgaXMgYW4gaWRlbnRp dHkgcmVmZXJlbmNlIHRoYXQgaW5kaWNhdGVzIHRoYXQgaXQgY2FuIHRha2UgYW55IGlkZW50aXR5 IHZhbHVlIHRoYXQgaXMgZGVyaXZlZCBmcm9tIHRoYXQgYmFzZSBpZGVudGl0eS4NCg0KSSB3aWxs IGhhdmUgdG8gZ28gbGVhcm4gYSBoZWNrIG9mIGEgbG90IG1vcmUgYWJvdXQgWUFORyBiZWZvcmUg dGhlIG5leHQgSUVURi4NCltSV10NClByb2JhYmx5IHNlY3Rpb25zIDcuMTggSWRlbnRpdGllcyBh bmQgOS4xMCBJZGVudGl0eS1yZWYgb2YgUkZDIDc5NTAgYXJlIHByb2JhYmx5IHRoZSBrZXkgb25l cyBmb3IgdGhpcyBkaXNjdXNzaW9uLg0KDQoNCg0Kw5ggIFdlIHN0aWxsIG5lZWQgdG8gaGF2ZSBj YXJlIGhlcmUuICBQcmVzdW1hYmx5IHRoZXJlIHdpbGwgYmUgY2FzZXMgd2hlcmUgdGhlIHNhbWUg a2V5IGFsZ29yaXRobSBpcyB1c2VkIGluIG11bHRpcGxlIHBsYWNlcy4gIEkgd2FzIHBhcnRseSB0 cnlpbmcgdG8gdGllIHRoZSBwYXJ0aXRpb25pbmcgaW50byBtb2R1bGVzIGFib3V0IHdoZXJlIHRo ZSBhbGdvcml0aG1zIGFyZSBiZWluZyBkZWZpbmVkIChpLmUuIHdoaWNoIFJGQ3MpIHJhdGhlciB0 aGVuIHdoZXJlIHRoZXkgYXJlIG5lY2Vzc2FyaWx5IHVzZWQuDQoNCkx1Y2tpbHkgVExTIGFuZCBT U0ggYXJlIGRlZmluZWQgaW4gc2VwYXJhdGUgUkZD4oCZcy4gOikNCg0KW1JXXQ0KWWVzLCDwn5iJ DQoNCg0K --_000_MN2PR11MB4366E4ECE10DFB018941BA5FB58E0MN2PR11MB4366namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3Jh cGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHls ZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1h cmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K c3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWls U3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4ubWZ0cg0KCXttc28tc3R5bGUtbmFtZTptX2Z0cjt9DQpzcGFuLm1oZHINCgl7 bXNvLXN0eWxlLW5hbWU6bV9oZHI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjgNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4uRW1haWxTdHlsZTMwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5F bWFpbFN0eWxlMzENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUz Mg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTMzDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjgzMTk0NTM5ODsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6LTI0NDc4NzgwNDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTIzOTI0Mzc5MjsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6MTUwNTQwMjE3MDt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6 bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMy NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTg5NzU0NDk1OTsNCgltc28tbGlzdC10eXBlOmh5 YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTk1NDE2NTg2NiAtNjI3MzA0MiA2NzY5ODY5 MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2 NzY5ODY5Mzt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28t ZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS1mb250LWZh bWlseTpDYWxpYnJpOw0KCW1zby1hbnNpLWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KQGxpc3QgbDI6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBj bTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBsYW5n PSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gU2FseiwgUmljaCAm bHQ7cnNhbHpAYWthbWFpLmNvbSZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiAxOCBTZXB0ZW1iZXIg MjAxOSAxMzo0MTxicj4NCjxiPlRvOjwvYj4gUm9iIFdpbHRvbiAocndpbHRvbikgJmx0O3J3aWx0 b25AY2lzY28uY29tJmd0OzsgS2VudCBXYXRzZW4gJmx0O2tlbnQmIzQzO2lldGZAd2F0c2VuLm5l dCZndDs8YnI+DQo8Yj5DYzo8L2I+IFJ1c3MgSG91c2xleSAmbHQ7aG91c2xleUB2aWdpbHNlYy5j b20mZ3Q7OyBuZXRjb25mQGlldGYub3JnOyBTZWFuIFR1cm5lciAmbHQ7c2VhbkBzbjNyZC5jb20m Z3Q7OyBSaWZhYXQgU2hla2gtWXVzZWYgJmx0O3JpZmFhdC5pZXRmQGdtYWlsLmNvbSZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRjb25mXSBjcnlwdG8tdHlwZXMgZmFsbGJhY2sgc3Ry YXRlZ3k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0 ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwyIGxldmVsMSBsZm8zIj4NCjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTpXaW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyI+T0su ICZuYnNwO1NvLCBpbiBZQU5HIEkgdGhpbmsgdGhlIGRlZmluaXRpb24gb2YgYSBiYXNlIGlkZW50 aXR5IGlzIGVmZmVjdGl2ZWx5IGRlZmluZWQgYnkgaG93IGl0IGlzIGludGVuZGVkIHRvIGJlIHVz ZWQuJm5ic3A7IEkuZS4gc29tZXdoZXJlIGluIHRoZSBtb2RlbCB0aGVyZSBpcyBhbiBpZGVudGl0 eSByZWZlcmVuY2UgdGhhdCBpbmRpY2F0ZXMgdGhhdCBpdCBjYW4NCiB0YWtlIGFueSBpZGVudGl0 eSB2YWx1ZSB0aGF0IGlzIGRlcml2ZWQgZnJvbSB0aGF0IGJhc2UgaWRlbnRpdHkuPC9zcGFuPjwv aT48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxpPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5J IHdpbGwgaGF2ZSB0byBnbyBsZWFybiBhIGhlY2sgb2YgYSBsb3QgbW9yZSBhYm91dCBZQU5HIGJl Zm9yZSB0aGUgbmV4dCBJRVRGLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIj5bUlddIDxvOnA+PC9vOnA+PC9zcGFuPjwv aT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMi PlByb2JhYmx5IHNlY3Rpb25zIDcuMTggSWRlbnRpdGllcyBhbmQgOS4xMCBJZGVudGl0eS1yZWYg b2YgUkZDIDc5NTAgYXJlIHByb2JhYmx5IHRoZSBrZXkgb25lcyBmb3IgdGhpcyBkaXNjdXNzaW9u LjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxpPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4w cHQ7bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5n cyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIj5XZSBzdGlsbCBuZWVkIHRvIGhh dmUgY2FyZSBoZXJlLiZuYnNwOyBQcmVzdW1hYmx5IHRoZXJlIHdpbGwgYmUgY2FzZXMgd2hlcmUg dGhlIHNhbWUga2V5IGFsZ29yaXRobSBpcyB1c2VkIGluIG11bHRpcGxlIHBsYWNlcy4mbmJzcDsg SSB3YXMgcGFydGx5IHRyeWluZyB0byB0aWUgdGhlIHBhcnRpdGlvbmluZyBpbnRvIG1vZHVsZXMg YWJvdXQgd2hlcmUgdGhlIGFsZ29yaXRobXMNCiBhcmUgYmVpbmcgZGVmaW5lZCAoaS5lLiB3aGlj aCBSRkNzKSByYXRoZXIgdGhlbiB3aGVyZSB0aGV5IGFyZSBuZWNlc3NhcmlseSB1c2VkLjwvc3Bh bj48L2k+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPkx1Y2tpbHkgVExT IGFuZCBTU0ggYXJlIGRlZmluZWQgaW4gc2VwYXJhdGUgUkZD4oCZcy4gOik8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyI+W1JXXSA8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9i PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIj5ZZXMs IDwvc3Bhbj48L2k+PC9iPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssc2Fucy1zZXJpZiI+JiMxMjg1MjE7PC9zcGFu PjwvaT48L2I+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MN2PR11MB4366E4ECE10DFB018941BA5FB58E0MN2PR11MB4366namp_-- From nobody Wed Sep 18 07:19:08 2019 Return-Path: <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE88120829 for ; Wed, 18 Sep 2019 07:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 e8Y_wUXjaaxV for ; Wed, 18 Sep 2019 07:19:03 -0700 (PDT) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E8FE120818 for ; Wed, 18 Sep 2019 07:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568816342; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=n2PyrzGgFV1OCJC0pzC6dAxN3m7UMYuuWrkpSP4hOHI=; b=iEglHaFggjwsbw3yugpXSOgJ4YLFKZY17Sl2uBGqhfTOZqGrHITVqhAUyG38HYHm LzycsVHA8W2aCOPRwvetFCa80Y/YJi66nJ1cvGXN+pAn+1PRWR9T+B/fc/VizgJIoGa eKINysElQ0PoRMmih5DaPkxfPFkQjNnlJCcPUals= From: Kent Watsen Message-ID: <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BBECC583-AEB4-4E6C-AD91-3AE43CC11107" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 18 Sep 2019 14:19:01 +0000 In-Reply-To: Cc: "Salz, Rich" , Russ Housley , "netconf@ietf.org" , Sean Turner , Rifaat Shekh-Yusef To: "Rob Wilton (rwilton)" References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@email.amazonses.com> <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.18-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 14:19:06 -0000 --Apple-Mail=_BBECC583-AEB4-4E6C-AD91-3AE43CC11107 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The authors are looking for clear direction for the next update to the = draft(s). =46rom the gist of the discussion, the punch list appears to be: - revert back to using identities, as they were in the -08 revision. - only define base identities for what's needed immediately for TLS and = SSH and keystore key-encryption. - define these base identities in distinct YANG modules - have each identity's description statement indicate what the binary = key data is encoded. A bit separate from the above, but still in mind: - specify that all TLS public-keys are a DER-encoded = SubjectPublicKeyInfo structure - specify that all SSH public-keys are a "ssh-public-key-type" type = (see below) - specify that all encrypted symmetric keys are a DER-encoded = OneSymmetricKey structure - specify that all encrypted asymmetric keys are a DER-encoded = OneAsymmetricKey structure The "ssh-public-key" type would be defined as: typedef ssh-public-key-type { type binary; mandatory true; description "The binary public key data for this SSH key, as specified by RFC 4253, Section 6.6, i.e.: string certificate or public key format identifier byte[n] key/certificate data."; reference "RFC 4253: The Secure Shell (SSH) Transport Layer Protocol"; } Any concerns? Kent // author --Apple-Mail=_BBECC583-AEB4-4E6C-AD91-3AE43CC11107 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

The authors are looking for clear = direction for the next update to the draft(s).

=46rom the gist of the discussion, the punch list = appears to be:

- revert back = to using identities, as they were in the -08 revision.
- only = define base identities for what's needed immediately for TLS and SSH and = keystore key-encryption.
- define these base identities in = distinct YANG modules
- have each identity's description = statement indicate what the binary key data is encoded.

A bit separate from the above, but still in = mind:

  - specify that all TLS = public-keys are a DER-encoded SubjectPublicKeyInfo = structure
  - specify that all SSH public-keys are a = "ssh-public-key-type" type (see below)
  - specify that = all encrypted symmetric keys are a DER-encoded OneSymmetricKey = structure
  - specify that all encrypted asymmetric keys = are a DER-encoded OneAsymmetricKey structure

The "ssh-public-key" type would be defined = as:

    =  typedef ssh-public-key-type {
         type = binary;
         mandatory = true;
        =  description
           "The binary public = key data for this SSH key, as
          =   specified by RFC 4253, Section 6.6, i.e.:

              string =    certificate or public key format
      =                   = identifier
              byte[n] =   key/certificate data.";
        =  reference
           "RFC 4253: The = Secure Shell (SSH) Transport
          =             Layer = Protocol";
          }

Any concerns?

Kent // author


= --Apple-Mail=_BBECC583-AEB4-4E6C-AD91-3AE43CC11107-- From nobody Wed Sep 18 07:43:13 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D204120820 for ; Wed, 18 Sep 2019 07:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 XHdR_7Pw0BZd for ; Wed, 18 Sep 2019 07:43:10 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 16EBE12081E for ; Wed, 18 Sep 2019 07:43:10 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x8IEgQrK019653; Wed, 18 Sep 2019 15:43:08 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=qTx/s6b8vUfhP2AeQ31ksJO3yyYT8mUJb9IHGYlXVQE=; b=j1v4K+qXsR3U4bmIbPUtua9tkxaK8Z2aLr29DJP4NmofEmkT9ZwijQDCFGzNhg5svoCu Xtm3iUZdixDLilRMWtY+Wv50C9qKIG92DKJFdEjvDvPd3TX5RnMpduWsNmqWfarHKRd/ YhXEFSaOOA4JRmbO5D3iN0kCu9FXtdpYbr93Klsp89BHEguthUn5LZuAOcpRvLHpBfM4 SgjKto7qMDjZ0ak5rkNwGLmJo69LvQj2LKwXRKC90M6TAhmC6BlZlLx7kQZPXNAHvWws wwxIfJmuzvQ0PVOn8tDnN5I46U6euWAohB1lTU4rwaZmGrfrbL5VCk9aCxbm4yokrtrB 4A== Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2v37m3aykg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Sep 2019 15:43:08 +0100 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x8IEJUkG020322; Wed, 18 Sep 2019 10:43:07 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint8.akamai.com with ESMTP id 2v37kmf68s-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 18 Sep 2019 10:43:05 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 18 Sep 2019 10:42:36 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Wed, 18 Sep 2019 10:42:36 -0400 From: "Salz, Rich" To: Kent Watsen , "Rob Wilton (rwilton)" CC: "netconf@ietf.org" , Rifaat Shekh-Yusef Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxGVhFlbERW30moo9Q8WhnpJqcpkUCAgAU9agCAASLxgP//+5oAgABHL4D//+j+AIAARomA//+/BAAAKuwGgP//8LyAgABEJYCAABougP//w4kA Date: Wed, 18 Sep 2019 14:42:36 +0000 Message-ID: <2614C1E8-A015-4816-AA3B-F75D02F5701C@akamai.com> References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@email.amazonses.com> <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> In-Reply-To: <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.155] Content-Type: multipart/alternative; boundary="_000_2614C1E8A0154816AA3BF75D02F5701Cakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-18_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=988 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909180144 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-18_08:2019-09-18,2019-09-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 malwarescore=0 priorityscore=1501 impostorscore=0 mlxscore=0 suspectscore=0 adultscore=0 phishscore=0 lowpriorityscore=0 spamscore=0 clxscore=1015 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909180146 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 14:43:12 -0000 --_000_2614C1E8A0154816AA3BF75D02F5701Cakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TW92aW5nIFJ1c3MgYW5kIFNlYW4gdG8gQkNDOyB0aGV5IGNhbiBzdWJzY3JpYmUgdG8gdGhlIGxp c3QgaWYgdGhleSB3YW50IDopDQoNCldpbGwgY29tbWVudCBvbiB0aGUgc3BlY2lmaWNzIGxhdGVy LCBidXQ6DQoNCj4gIC0gc3BlY2lmeSB0aGF0IGFsbCBUTFMgcHVibGljLWtleXMgYXJlIGEgREVS LWVuY29kZWQgU3ViamVjdFB1YmxpY0tleUluZm8gc3RydWN0dXJlDQoNCk5vLCB0aGV5IHNob3Vs ZCBiZSBhbiBYNTA5IGNlcnRpZmljYXRlIG9iamVjdC4NCg0KUHJpdmF0ZSBrZXlzIGFuZCBzeW1t ZXRyaWMga2V5cyBjYW4gYmUgZW5jcnlwdGVkOyBpcyB0aGF0IGEgc2VwYXJhdGUga2V5dHlwZSBk ZXJpdmVkIGZyb20gdGhlaXIgYmFzZSBrZXkgdHlwZXM/DQo= --_000_2614C1E8A0154816AA3BF75D02F5701Cakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIj MDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+TW92aW5nIFJ1c3MgYW5kIFNlYW4gdG8gQkNDOyB0aGV5IGNhbiBz dWJzY3JpYmUgdG8gdGhlIGxpc3QgaWYgdGhleSB3YW50IDopPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPldpbGwgY29tbWVudCBvbiB0aGUgc3BlY2lmaWNzIGxhdGVyLCBidXQ6PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7IC0gc3BlY2lmeSB0aGF0IGFsbCBUTFMgcHVi bGljLWtleXMgYXJlIGEgREVSLWVuY29kZWQgU3ViamVjdFB1YmxpY0tleUluZm8gc3RydWN0dXJl PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vLCB0aGV5IHNob3VsZCBiZSBhbiBYNTA5IGNlcnRp ZmljYXRlIG9iamVjdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UHJp dmF0ZSBrZXlzIGFuZCBzeW1tZXRyaWMga2V5cyBjYW4gYmUgZW5jcnlwdGVkOyBpcyB0aGF0IGEg c2VwYXJhdGUga2V5dHlwZSBkZXJpdmVkIGZyb20gdGhlaXIgYmFzZSBrZXkgdHlwZXM/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2614C1E8A0154816AA3BF75D02F5701Cakamaicom_-- From nobody Wed Sep 18 08:37:31 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1431209A5 for ; Wed, 18 Sep 2019 08:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=IYYPYyzG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=I3qazOGi 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 LbxyeDc7TNjZ for ; Wed, 18 Sep 2019 08:37:25 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BBD0120A11 for ; Wed, 18 Sep 2019 08:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13137; q=dns/txt; s=iport; t=1568821038; x=1570030638; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nw6eoupWiMSYXjMSiPCvU2g8hXehm9G91Huz/8jfOe4=; b=IYYPYyzGrDMZNJBDfZ4IISQ9jfLISZP4x0u2slOsHZO8ViVqoxD8VoOj ARA/7QTu5aBhOFqEN2O8pKmqWGtN7E6ReeOSd9nef6Bk4nLuCXDBWTTgH 7wXwd/O9dN609nsEuTrxlLqu5towaJ7fWJ84G9y8rxvQb3Vv/c2yJp05u c=; IronPort-PHdr: =?us-ascii?q?9a23=3Aj5TA1BRK/S12g65izGwsrG4a8dpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBdfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjYlHcBeU1lN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAAD3TYJd/5pdJa1dCRoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVMFAQEBAQsBgRUvKScDbVYgBAsqCodfA4RShiWCXIlmiTC?= =?us-ascii?q?EXYEugSQDVAkBAQEMAQEtAgEBhD8CgwMjNAkOAgMJAQEEAQEBAgEFBG2FLQy?= =?us-ascii?q?FSgEBAQEDEhsTAQE3AQ8CAQgRBAEBLyERHQgCBA4FCBqDAYEdTQMdAQKlXQK?= =?us-ascii?q?BOIhhgiWCfQEBBYUKDQuCFwmBNAGKRYEmHRiBQD+BV4JMPoIaggAsgzuCJo8?= =?us-ascii?q?hhV2JIY4hQQqCIpEEhBuCNpI/hCyPSYhejnMCBAIEBQIOAQEFgVI4gVhwFTu?= =?us-ascii?q?CbFAQFIFOgScBAoJIilNzgSmOKgGBIgEB?= X-IronPort-AV: E=Sophos;i="5.64,521,1559520000"; d="scan'208,217";a="636125686" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Sep 2019 15:37:17 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x8IFbHlc015005 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 18 Sep 2019 15:37:17 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 18 Sep 2019 10:37:17 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 18 Sep 2019 10:37:16 -0500 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 18 Sep 2019 10:37:15 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d1/BHWyz8IqXKToUb+3mvA0PT3oHtgIeQcXeyweC9aAzXL34/ge1sBGmKpFJzAK+ziL1y6VQRrnG9l0iioPsGCzl6WipGRk1mF33F2xT75tRGfPplRKyaLzpJG32iMd4HQJ0n91kggCFrzjQ9sMI+y9TWQdfSP1sdJ6rzo/nHlDV2lhrvj/Hf7QTduNIIY4P+VcwISH0ynvhEm/wZr/y3ES0Ouvq/PngHeRLtToTwq09nOuwmHr5xEouID1xuzgMkJK0zjFb4mySUXT14Ju+1YG3ir+gjUKCjK9ZsOVMaWGNSxsyQPcWd+yPG0SDXOM77UvgJDph4SUFLFRNjRyuGw== 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=z+fmKRXxjbRMiAYHKFPt5k4eUA/9SQwM+vaQDrlsusU=; b=KsR9cmh0cG3h2Wn344RrQsjUsG98ud4ykRmupcM3In4ebQG8UJzo8n1n1mAqZKqSvLZIv7opOOfw4kMN/vtKK9FfJja+98WazjMefljSql4dPQi4SbPMa6nwVRuCZ6RKxEI/vuAj8YcZjrCAvBPuq3+RkvKDZmPVz+2Hhkzl5vCPcGLwH+PXH45UHUfNzgvr3yGhKlvdh2GzyGO9GiFWH/amRkuor7gOWvodOwg3vflSZJZNzDXjZ9tyQyeDuKT2WimJFPF5PqLO+BeyFcGVLu1a7jo0Jl5ZoFEcidw2yy03M1p50o+rv7EIzkATd6qF41o83BeccUigfzK9qe4YZg== 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=z+fmKRXxjbRMiAYHKFPt5k4eUA/9SQwM+vaQDrlsusU=; b=I3qazOGiaQ3ZMPLul+GSq5pz3kMdtUV7ipDrXeuFfNfGftcEUqckJ3bvmlMyO3nYKhos+m1Ltlt/fvx1nE9oNVqSk8uwqE+BKc3Fvdm23wqy/MdQg2P5fYTS3p0I0+RA0C12ELas5q8y98qoG0kl872ps6tq2iiwrYX54PlCKtk= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3838.namprd11.prod.outlook.com (20.178.252.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.17; Wed, 18 Sep 2019 15:37:14 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6%7]) with mapi id 15.20.2263.023; Wed, 18 Sep 2019 15:37:14 +0000 From: "Rob Wilton (rwilton)" To: Kent Watsen CC: "Salz, Rich" , Russ Housley , "netconf@ietf.org" , Sean Turner , "Rifaat Shekh-Yusef" Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxVu0aQE+n/K0iPwVgOy8FH/KcpQIdQgAVLFQCAARKfAIAATvkAgAABvxCAAC5vAIAAAggggAADhQCAAQHLcIAARlAAgAAAT1CAABr3gIAADR/A Date: Wed, 18 Sep 2019 15:37:14 +0000 Message-ID: References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@email.amazonses.com> <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> In-Reply-To: <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [173.38.220.61] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e8fd3185-1a58-4535-7fdd-08d73c4e1489 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB3838; x-ms-traffictypediagnostic: MN2PR11MB3838: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01644DCF4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(346002)(366004)(136003)(376002)(51444003)(189003)(199004)(102836004)(33656002)(14454004)(6436002)(66946007)(256004)(14444005)(81166006)(81156014)(8676002)(99286004)(6246003)(186003)(7736002)(86362001)(316002)(76176011)(66476007)(7696005)(66556008)(446003)(9326002)(26005)(11346002)(5660300002)(6116002)(71190400001)(25786009)(2906002)(478600001)(3846002)(55016002)(64756008)(6506007)(66446008)(790700001)(71200400001)(6306002)(54906003)(8936002)(66066001)(9686003)(53546011)(476003)(74316002)(52536014)(486006)(76116006)(54896002)(229853002)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3838; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 6NKS976yFMJ9xM6OVVqflv2msUuECZI3w98IeHOavo9iaXvAFTvEUeEYJklU3buQy+ZhbL/FwOTqYu0rWOvdCbXCcHinGntW04ECHp8c5dpHvS73hdIMvBu+XmerAd4OsLoRjQXGIYOTVxG0OlltXg+gRKTj1l80fSxrvg3LIH6rsQ6JoAja62MIQGQec5FtIOUrzpdzmfVADfVDWWM4ZReFu4SozotldQ+IS3+u0Xd7vEmOhxyv81E2zSu/UOaHqaIAM7D3SDmhE7Ke1SnOgcUGSZv29fdiMnH7DyLTrHxokakNwaeZxTnEdOvDJZpBQNcbPqkkjir+9y/CVgNs2XsywoLh2uWdfWu24cms3kmzqOfhET0ASQ7d5rNhGVpmBeKClB6rdTCMPyjg6/PMF7jnUDGE4x34iAVvWypAK4w= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB436617082A8308A7A8928DDFB58E0MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e8fd3185-1a58-4535-7fdd-08d73c4e1489 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2019 15:37:14.4146 (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: FMfGY/47t+oj4JlP03lN9V4lLOOm2FZLvcxK2XwhDGyZRKqlmJ6wA2stDoIragEXMy8EKKl5N8/eh/DTN8YKOg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3838 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.27, xch-aln-017.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 15:37:29 -0000 --_000_MN2PR11MB436617082A8308A7A8928DDFB58E0MN2PR11MB4366namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kent, From: Kent Watsen Sent: 18 September 2019 15:19 To: Rob Wilton (rwilton) Cc: Salz, Rich ; Russ Housley ; net= conf@ietf.org; Sean Turner ; Rifaat Shekh-Yusef Subject: Re: [netconf] crypto-types fallback strategy The authors are looking for clear direction for the next update to the draf= t(s). >From the gist of the discussion, the punch list appears to be: - revert back to using identities, as they were in the -08 revision. - only define base identities for what's needed immediately for TLS and SSH= and keystore key-encryption. - define these base identities in distinct YANG modules - have each identity's description statement indicate what the binary key d= ata is encoded. [RW] I think that this matches my view, except for "define these base identities= in distinct YANG modules". I don't feel particularly strongly about this,= but I was thinking that the base identities would still be defined in cryp= to-types.yang, which might help keep the import references simple. A bit separate from the above, but still in mind: - specify that all TLS public-keys are a DER-encoded SubjectPublicKeyInfo= structure - specify that all SSH public-keys are a "ssh-public-key-type" type (see = below) - specify that all encrypted symmetric keys are a DER-encoded OneSymmetri= cKey structure - specify that all encrypted asymmetric keys are a DER-encoded OneAsymmet= ricKey structure The "ssh-public-key" type would be defined as: typedef ssh-public-key-type { type binary; mandatory true; description "The binary public key data for this SSH key, as specified by RFC 4253, Section 6.6, i.e.: string certificate or public key format identifier byte[n] key/certificate data."; reference "RFC 4253: The Secure Shell (SSH) Transport Layer Protocol"; } Any concerns? [RW] I think that this sounds OK. Minor: Does the "string" in the description above mean "ASCII string" or "b= inary string", RFC 4251 seemingly uses both definitions? Is putting the encrypted keys into DER-encoded OneSymmetricKey obviously th= e right thing to do? Are there other choices? Thanks, Rob Kent // author --_000_MN2PR11MB436617082A8308A7A8928DDFB58E0MN2PR11MB4366namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kent,<= o:p>

&nbs= p;

From: Kent Watsen <kent+ietf@watsen= .net>
Sent: 18 September 2019 15:19
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: Salz, Rich <rsalz@akamai.com>; Russ Housley <housley@vi= gilsec.com>; netconf@ietf.org; Sean Turner <sean@sn3rd.com>; Rifaa= t Shekh-Yusef <rifaat.ietf@gmail.com>
Subject: Re: [netconf] crypto-types fallback strategy

 

 

The authors are looking= for clear direction for the next update to the draft(s).

 

From the gist of the di= scussion, the punch list appears to be:

 

- revert back to using = identities, as they were in the -08 revision.

- only define base iden= tities for what's needed immediately for TLS and SSH and keystore key-encry= ption.

- define these base ide= ntities in distinct YANG modules

- have each identity's = description statement indicate what the binary key data is encoded.

[RW]

I think t= hat this matches my view, except for “define these base identi= ties in distinct YANG modules= 221;.  I don’t feel particularly strongly about this, but I was thinking that the base identities would still be defined in cryp= to-types.yang, which might help keep the import references simple.

 

 

A bit separate from the= above, but still in mind:

 

  - specify that a= ll TLS public-keys are a DER-encoded SubjectPublicKeyInfo structure

  - specify that a= ll SSH public-keys are a "ssh-public-key-type" type (see below)

  - specify that a= ll encrypted symmetric keys are a DER-encoded OneSymmetricKey structure

  - specify that a= ll encrypted asymmetric keys are a DER-encoded OneAsymmetricKey structure

 

The "ssh-public-ke= y" type would be defined as:

 

     typedef ssh-public-ke= y-type {

         type binary;=

         mandatory tr= ue;

         description<= /span>

           "= ;The binary public key data for this SSH key, as

            spec= ified by RFC 4253, Section 6.6, i.e.:

 

            &nbs= p; string    certificate or public key format

            &nbs= p;           identifier

            &nbs= p; byte[n]   key/certificate data.";

         reference

           "= ;RFC 4253: The Secure Shell (SSH) Transport

            &nbs= p;         Layer Protocol";

          }

 

Any concerns?

[RW]

I think that this sounds OK.

 

Minor: Does the “string” in the descript= ion above mean “ASCII string” or “binary string”, R= FC 4251 seemingly uses both definitions?

 

Is putting the encrypted keys into DER-encoded OneSy= mmetricKey obviously the right thing to do?  Are there other choices?<= o:p>

 

Thanks,
Rob

 

 

Kent // author

 

 

--_000_MN2PR11MB436617082A8308A7A8928DDFB58E0MN2PR11MB4366namp_-- From nobody Wed Sep 18 09:37:13 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8BE120AC9 for ; Wed, 18 Sep 2019 09:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=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=jacobsuniversity.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 VxT0OtQMJJzb for ; Wed, 18 Sep 2019 09:37:02 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30055.outbound.protection.outlook.com [40.107.3.55]) (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 6614C120AEB for ; Wed, 18 Sep 2019 09:37:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QFc2rOQeGLO+wOZthkQ6tTKpV7aAc12tg2CPM0ghhrZDV0tgSmMWXLQKBNRQKg3Q0rKVdmSyqrj2IgrNsD3Tqg251i9zHQxyZUtbIb9dzGmyw5MIVEEh3V1nTcU6Ho8vdS2Zn9QgIutaYgQU4yJb20zyTAWyJqPOB4Sz1QjQvoDm4Io7/pmlrHbzBH2h2X3rgYj9PSDr8Iz90vGXvbyFP/26lACItaFYCcbDWboAGyxcEa8JntdzRzsNuxReo/LuxOwOJnSD41/eL4cXRxQ9p8dcaA+kP6dS6G2r2JDV0Fs/vV4dS98V4ZGMuQJfKwgZm0ENyc43uyI/OIjRp5QHZg== 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=JaSvi6tVEiaRR7TOiEq72GU866WGnav7cNGUff1i49c=; b=aKVtm2z4DOPan8u0+rt50HoKx3xSm0/RHZySEo4uxcU2XGhAts5J6njXSkl58gH2X0q8Ac/clV75olCcXZyWP6b9DWK75aRcLpGfNo3pEguBBwsPbYO5bIYnzLWh4cHbNk2Q+1ktpkY3j0fYB5DD6OBCEmfIvdN7np9tU8SvOeVJHDVeYEpGBpbU7ab1Dw/+CzDDMAMbLTo8cg9wviQlF/N7nHQsVUJhrahvZe6dx6oMCqJEP2SP55TQAzyw6diW+6O1xa1NSTtTmfsGfs1dmEHG8NGTh5/LHaIj8Z3+M347z24696RSkZx+5OcalGyoXZR2x3x1f9OhsNZf/cpEHQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JaSvi6tVEiaRR7TOiEq72GU866WGnav7cNGUff1i49c=; b=lZre9h4fZrHswiCKv7tHfKU/BeBAe5fNTAtjNtlQrf1N5DtqaZs99KpNOa4EViSRjC61J7fBDKPpbu4mcwPnzQVB1xMP7oq9uHVq0/jPougneyn87Ca79b4cTLgVfWaONruMZbkuz1JXwuotnFhydJQiSK2MC2KrINUXJmL84Yc= Received: from VI1P190MB0686.EURP190.PROD.OUTLOOK.COM (10.186.159.71) by VI1P190MB0622.EURP190.PROD.OUTLOOK.COM (10.186.159.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.17; Wed, 18 Sep 2019 16:36:59 +0000 Received: from VI1P190MB0686.EURP190.PROD.OUTLOOK.COM ([fe80::d48a:ffa3:4fff:141e]) by VI1P190MB0686.EURP190.PROD.OUTLOOK.COM ([fe80::d48a:ffa3:4fff:141e%2]) with mapi id 15.20.2263.023; Wed, 18 Sep 2019 16:36:59 +0000 From: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= To: "Rob Wilton (rwilton)" CC: Kent Watsen , Russ Housley , "netconf@ietf.org" , Sean Turner , Rifaat Shekh-Yusef Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVbjbxVhFlbERW30moo9Q8WhnpJqcxoiSA Date: Wed, 18 Sep 2019 16:36:59 +0000 Message-ID: <20190918163657.4pxh5jddxgrir5oh@anna.jacobs.jacobs-university.de> References: <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> In-Reply-To: Reply-To: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: AM0PR07CA0022.eurprd07.prod.outlook.com (2603:10a6:208:ac::35) To VI1P190MB0686.EURP190.PROD.OUTLOOK.COM (2603:10a6:800:12e::7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:638:709:5::7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a0f25064-6a54-4080-f00a-08d73c566d25 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600167)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:VI1P190MB0622; x-ms-traffictypediagnostic: VI1P190MB0622: x-ms-exchange-purlcount: 1 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01644DCF4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(136003)(346002)(39850400004)(396003)(199004)(189003)(51444003)(8936002)(2906002)(6246003)(6512007)(305945005)(7736002)(786003)(6306002)(486006)(316002)(446003)(54906003)(186003)(256004)(66446008)(64756008)(66556008)(66476007)(5660300002)(66946007)(102836004)(6916009)(45776006)(71200400001)(71190400001)(81166006)(46003)(86362001)(14454004)(6486002)(6116002)(76176011)(478600001)(52116002)(25786009)(3450700001)(386003)(6506007)(229853002)(476003)(99286004)(8676002)(4326008)(81156014)(11346002)(43066004)(6436002)(1076003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P190MB0622; H:VI1P190MB0686.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: TzS6niU+Dxnhh5q/vSHN4SIFxsQYZ9lrrbGiwFwln/Eq+jy+w23ygjOr4aihw4snTA33VDfDtiiY3xbAkCd22yOSo/qeeX70hgwdOMF1Ez3TjSmO3X4NsIzjm2rhSAY8MoV44B3tN6CpHqdtqTOyYJdWrwjx6OfzLGxxdyv7GpbRNrMHsY1xIR8QWd9GHMtdAbP49FUbhq2RBENSdJBusuEplm+XMrfvD7h1QyrLwik8yU2wm+rpC49Sj/LMNJvZjNZIxaPCIzuVYsR4WOBSfDBjZMdCtAbadWU+pYugILG5n5xrxkxiu5Ci5uGZqg5ydhSui8rp50zREwQJAArAN/lewtcxGbauY2pdAvQrKrZIz2OH/7mZeaDX2W25vzApSOPV1Fk8TO45zUFxo1+G4lrukw1/IbXEg8s5dngolbI= Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9B2B95E8C2773A4E966ADD38E5542461@EURP190.PROD.OUTLOOK.COM> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: a0f25064-6a54-4080-f00a-08d73c566d25 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2019 16:36:59.3552 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: oxdKJ3z7WgSuUjjvJqoio0HeP3DycQ0hiRT3CBwV0PrjpigvFuUaTK1m5bqJFqggup3wB2A/5PTb/2HIFT7j/qW7VCFB6Wb99arBgN7fEww= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P190MB0622 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 16:37:12 -0000 On Wed, Sep 18, 2019 at 03:37:14PM +0000, Rob Wilton (rwilton) wrote: > >From the gist of the discussion, the punch list appears to be: >=20 > - revert back to using identities, as they were in the -08 revision. > - only define base identities for what's needed immediately for TLS and S= SH and keystore key-encryption. > - define these base identities in distinct YANG modules > - have each identity's description statement indicate what the binary key= data is encoded. > [RW] > I think that this matches my view, except for "define these base identiti= es in distinct YANG modules". I don't feel particularly strongly about thi= s, but I was thinking that the base identities would still be defined in cr= ypto-types.yang, which might help keep the import references simple. I tend to agree that sometimes less modules is more. For me, the problem is likely more that I am not entirely sure what the proper base types would be, which may depend on what exactly they are used for. I guess I wait until I see the description text... =20 > A bit separate from the above, but still in mind: >=20 > - specify that all TLS public-keys are a DER-encoded SubjectPublicKeyIn= fo structure > - specify that all SSH public-keys are a "ssh-public-key-type" type (se= e below) > - specify that all encrypted symmetric keys are a DER-encoded OneSymmet= ricKey structure > - specify that all encrypted asymmetric keys are a DER-encoded OneAsymm= etricKey structure I would check what is commonly used in existing configuration interfaces. We are not inventing the wheel here. And whatever we define better is usable with existing implementations and tools. > The "ssh-public-key" type would be defined as: >=20 > typedef ssh-public-key-type { > type binary; > mandatory true; > description > "The binary public key data for this SSH key, as > specified by RFC 4253, Section 6.6, i.e.: >=20 > string certificate or public key format > identifier > byte[n] key/certificate data."; > reference > "RFC 4253: The Secure Shell (SSH) Transport > Layer Protocol"; > } The SSH implementations that I use have the binary key data rendered in ASCII. In fact, the whole key record is rendered in ASCII. I strongly suggest to use formats that are well established. /js=20 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Sep 18 09:46:26 2019 Return-Path: <0100016d45447f68-68073ae2-3f96-4c6d-846d-7c661c1cdb0c-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC60C1208E9 for ; Wed, 18 Sep 2019 09:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 rqQC026s6byA for ; Wed, 18 Sep 2019 09:46:21 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89030120121 for ; Wed, 18 Sep 2019 09:46:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568825180; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=Sr/hTwV72//C6WYtnS2XYyV6IrSZhzDNU979V/7pYO8=; b=HgHvzEpAmTbOQW3NxfUhBK9MSw7+6V1dgMgEBmLeitDcav5sVg5feZkU4w0s2nhR B6BEfDGWZYOpyH+m8Guq3okRllElammAKO01E+kmzVid/B9/vRs/ALX4lUrfqRDMdoW Lo4ScYNV9Orzxkljc/hRZvZOmPEFCmIB6bN8+sBM= From: Kent Watsen Message-ID: <0100016d45447f68-68073ae2-3f96-4c6d-846d-7c661c1cdb0c-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CF209721-1075-4E6C-A0EC-09C133AF69C6" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 18 Sep 2019 16:46:20 +0000 In-Reply-To: <2614C1E8-A015-4816-AA3B-F75D02F5701C@akamai.com> Cc: "Rob Wilton (rwilton)" , "netconf@ietf.org" , Rifaat Shekh-Yusef To: "Salz, Rich" References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@email.amazonses.com> <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <2614C1E8-A015-4816-AA3B-F75D02F5701C@akamai.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.18-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 16:46:25 -0000 --Apple-Mail=_CF209721-1075-4E6C-A0EC-09C133AF69C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Moving Russ and Sean to BCC; they can subscribe to the list if they = want :) Okay but, be aware that this thread is the culmination of me interacting = with Sean and Russ for a couple weeks... > > - specify that all TLS public-keys are a DER-encoded = SubjectPublicKeyInfo structure > =20 > No, they should be an X509 certificate object. There is a separate field for certificates, which is an X.509 = certificate. The desire to use SubjectPublicKeyInfo is per tests (2) and (4) = described here: = https://mailarchive.ietf.org/arch/msg/netconf/ysukDdbCA0a70heF1a_ldZNr4yE = . > Private keys and symmetric keys can be encrypted; is that a separate = keytype derived from their base key types? I don't understand the question. I think your tip-toeing on a concern = that a key should only be encrypted with a certain other key, if only = the ensure that the strength of the encrypting key is not less than the = key being encrypted. Is this what you mean? draft-ietf-netconf-keystore currently uses a YANG "leafref" for the = model to point to the other key in the keystore used to do the = encryption. The leafref has not constraints on its at the moment. Kent // contributor --Apple-Mail=_CF209721-1075-4E6C-A0EC-09C133AF69C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Moving Russ and Sean to = BCC; they can subscribe to the list if they want :)

Okay but, be aware that this thread is the = culmination of me interacting with Sean and Russ for a couple = weeks...


> = - specify that all TLS public-keys are a DER-encoded = SubjectPublicKeyInfo structure
 
No, they should be an X509 certificate = object.

There is a separate field for certificates, which = is an X.509 certificate.

The desire = to use SubjectPublicKeyInfo is per tests (2) and (4) described = here: https://mailarchive.ietf.org/arch/msg/netconf/ysukDdbCA0a70heF1= a_ldZNr4yE.



Private keys and symmetric keys = can be encrypted; is that a separate keytype derived from their base key = types?

I don't understand the question. =  I think your tip-toeing on a concern that a key should only be = encrypted with a certain other key, if only the ensure that the strength = of the encrypting key is not less than the key being encrypted.  Is = this what you mean?

draft-ietf-netconf-keystore currently uses a YANG = "leafref" for the model to point to the other key in the keystore used = to do the encryption.  The leafref has not constraints on its at = the moment.


Kent // contributor


= --Apple-Mail=_CF209721-1075-4E6C-A0EC-09C133AF69C6-- From nobody Wed Sep 18 09:58:36 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA4BA120916 for ; Wed, 18 Sep 2019 09:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 (2048-bit key) header.d=akamai.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 z83PRk0APlqm for ; Wed, 18 Sep 2019 09:58:33 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 F059912088F for ; Wed, 18 Sep 2019 09:58:32 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x8IGgtJw004438; Wed, 18 Sep 2019 17:58:30 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=NTsUK/7WYXUHMO7zBw1VLS0WewFb0QZfSvXT49N7asY=; b=EKU3gVL5CAQdZdz3z46R8vRI6eUI+r6YMdPSPwNF5cQjL+e8yA4NV5bPqh8nkE6PKKf1 gWOZ5RrttKZnjgkDWJZmkulMRp9Sz8lAu2FTlzJWHATvUi3VFfb2uuZ8cBuAvHXHo66m t8EJfYgzE06nLQTr5bx98dK7Sd+gEndcMdOSHQ40pq8zMbjgg07g1nfA/UMRDF+pzOPu hFh3ZfImLFf3XatnawZ84/1Ficx/zRI9CqF3XwLP86Mmz+tk51i4U0keXiA3z3xv7jky AJl0CW+JVkXrktn8UMN05RrTbltd8vYAkAILbbl499grGiVdadSQSwKY1z3juYjSFt1f Tg== Received: from prod-mail-ppoint7 (prod-mail-ppoint7.akamai.com [96.6.114.121] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2v37vwm6b8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Sep 2019 17:58:30 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x8IGnU8u017002; Wed, 18 Sep 2019 12:58:29 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint7.akamai.com with ESMTP id 2v37q3p5c6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 18 Sep 2019 12:58:28 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 18 Sep 2019 12:58:25 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Wed, 18 Sep 2019 12:58:25 -0400 From: "Salz, Rich" To: Kent Watsen CC: "Rob Wilton (rwilton)" , "netconf@ietf.org" , Rifaat Shekh-Yusef Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxGVhFlbERW30moo9Q8WhnpJqcpkUCAgAU9agCAASLxgP//+5oAgABHL4D//+j+AIAARomA//+/BAAAKuwGgP//8LyAgABEJYCAABougP//w4kAgABloAD//8BRAA== Date: Wed, 18 Sep 2019 16:58:25 +0000 Message-ID: <7AE47512-8974-4A8C-9756-699CAE220EF9@akamai.com> References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@email.amazonses.com> <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <2614C1E8-A015-4816-AA3B-F75D02F5701C@akamai.com> <0100016d45447f68-68073ae2-3f96-4c6d-846d-7c661c1cdb0c-000000@email.amazonses.com> In-Reply-To: <0100016d45447f68-68073ae2-3f96-4c6d-846d-7c661c1cdb0c-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.23] Content-Type: multipart/alternative; boundary="_000_7AE4751289744A8C9756699CAE220EF9akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-18_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=621 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909180157 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-18_09:2019-09-18,2019-09-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0 mlxlogscore=794 mlxscore=0 priorityscore=1501 impostorscore=0 spamscore=0 lowpriorityscore=0 phishscore=0 bulkscore=0 clxscore=1015 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909180157 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 16:58:35 -0000 --_000_7AE4751289744A8C9756699CAE220EF9akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCiAgKiAgIFRoZSBkZXNpcmUgdG8gdXNlIFN1YmplY3RQdWJsaWNLZXlJbmZvIGlzIHBlciB0 ZXN0cyAoMikgYW5kICg0KSBkZXNjcmliZWQgaGVyZTogaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRm Lm9yZy9hcmNoL21zZy9uZXRjb25mL3lzdWtEZGJDQTBhNzBoZUYxYV9sZFpOcjR5RTxodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX21haWxhcmNoaXZl LmlldGYub3JnX2FyY2hfbXNnX25ldGNvbmZfeXN1a0RkYkNBMGE3MGhlRjFhLTVGbGRaTnI0eUUm ZD1Ed01GQWcmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9NExNMEdiUjBoOUZ2eDg2RnRzS0kt dyZtPTJXakdBN0haQ2RnTzNQdU5JR2NTaGYyaXM3SlcwNkxDUWRiakhuWUZOczgmcz0yYTQ2N1Fl cGkzWm5PTWM2Ym9tWGpwM3lzVHNlRjBFVVh5dHVhaE5IWk53JmU9Pi4NCg0KVGhvc2UgZXhwZXJp bWVudHMgZG8gbm90IG1hdHRlci4gIFRMUyBzZW5kcyBYNTA5IGNlcnRpZmljYXRlcy4gIEkgYW0g bm90IGF3YXJlIG9mIGFueSBwcm90b2NvbCAoYW5kIEkgZG9u4oCZdCBrbm93IGFsbCBvZiB0aGVt LCBvZiBjb3Vyc2UpIHRoYXQgc2VuZHMgcmF3IHB1YmxpYyBrZXlzLiAgV2hhdCBwcm90b2NvbHMg YXJlIHlvdSB0aGlua2luZyBvZj8NCg0KSWYgeW91IHdhbnQgdG8gY29uZmlndXJlIGFuIEhUVFBT IHNlcnZlciB1c2luZyBuZXRjb25mL3lhbmcsIHlvdSB3aWxsIG5lZWQgdG8gZ2l2ZSB0aGF0IHNl cnZlciBYNTA5IGNlcnRpZmljYXRlcy4NCg0KDQo+IGRvbid0IHVuZGVyc3RhbmQgdGhlIHF1ZXN0 aW9uLiAgSSB0aGluayB5b3VyIHRpcC10b2Vpbmcgb24gYSBjb25jZXJuIHRoYXQgYSBrZXkgc2hv dWxkIG9ubHkgYmUgZW5jcnlwdGVkIHdpdGggYSBjZXJ0YWluIG90aGVyIGtleSwgaWYgb25seSB0 aGUgZW5zdXJlIHRoYXQgdGhlIHN0cmVuZ3RoIG9mIHRoZSBlbmNyeXB0aW5nIGtleSBpcyBub3Qg bGVzcyB0aGFuIHRoZSBrZXkgYmVpbmcgZW5jcnlwdGVkLiAgSXMgdGhpcyB3aGF0IHlvdSBtZWFu Pw0KDQpObywgSSB3YXMgYXNraW5nIGlmIOKAnGVuY3J5cHRlZCBwcml2YXRlIGtleeKAnSBpcyBh IHNlcGFyYXRlIHRoaW5nIGZyb20g4oCccGxhaW50ZXh0IHByaXZhdGUga2V5LuKAnQ0KDQo= --_000_7AE4751289744A8C9756699CAE220EF9akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <421F590C5FA0604388DF3182A307858D@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6 MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxl ZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNTAxMDQ2NjExOw0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyMDE0NzM2MjIyIDgwOTI5ODM5OCA2NzY5ODY5 MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2 NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIjsNCgltc28tYmlkaS1mb250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0IGwwOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJ e21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVs MSBsZm8xIj5UaGUgZGVzaXJlIHRvIHVzZSBTdWJqZWN0UHVibGljS2V5SW5mbyBpcyBwZXIgdGVz dHMgKDIpIGFuZCAoNCkgZGVzY3JpYmVkIGhlcmU6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19tYWlsYXJjaGl2ZS5pZXRm Lm9yZ19hcmNoX21zZ19uZXRjb25mX3lzdWtEZGJDQTBhNzBoZUYxYS01RmxkWk5yNHlFJmFtcDtk PUR3TUZBZyZhbXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJmFtcDtyPTRMTTBHYlIwaDlGdng4 NkZ0c0tJLXcmYW1wO209MldqR0E3SFpDZGdPM1B1TklHY1NoZjJpczdKVzA2TENRZGJqSG5ZRk5z OCZhbXA7cz0yYTQ2N1FlcGkzWm5PTWM2Ym9tWGpwM3lzVHNlRjBFVVh5dHVhaE5IWk53JmFtcDtl PSI+aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9uZXRjb25mL3lzdWtEZGJD QTBhNzBoZUYxYV9sZFpOcjR5RTwvYT4uPG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRob3NlIGV4cGVyaW1lbnRzIGRvIG5vdCBtYXR0ZXIuJm5ic3A7IFRMUyBz ZW5kcyBYNTA5IGNlcnRpZmljYXRlcy4mbmJzcDsgSSBhbSBub3QgYXdhcmUgb2YgYW55IHByb3Rv Y29sIChhbmQgSSBkb27igJl0IGtub3cgYWxsIG9mIHRoZW0sIG9mIGNvdXJzZSkgdGhhdCBzZW5k cyByYXcgcHVibGljIGtleXMuJm5ic3A7IFdoYXQgcHJvdG9jb2xzIGFyZSB5b3UgdGhpbmtpbmcg b2Y/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHlvdSB3YW50IHRvIGNvbmZpZ3VyZSBhbiBI VFRQUyBzZXJ2ZXIgdXNpbmcgbmV0Y29uZi95YW5nLCB5b3Ugd2lsbCBuZWVkIHRvIGdpdmUgdGhh dCBzZXJ2ZXIgWDUwOSBjZXJ0aWZpY2F0ZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jmd0OyBkb24ndCB1bmRlcnN0YW5kIHRoZSBxdWVzdGlvbi4gJm5ic3A7SSB0 aGluayB5b3VyIHRpcC10b2Vpbmcgb24gYSBjb25jZXJuIHRoYXQgYSBrZXkgc2hvdWxkIG9ubHkg YmUgZW5jcnlwdGVkIHdpdGggYSBjZXJ0YWluIG90aGVyIGtleSwgaWYgb25seSB0aGUgZW5zdXJl IHRoYXQgdGhlIHN0cmVuZ3RoIG9mIHRoZSBlbmNyeXB0aW5nIGtleSBpcyBub3QgbGVzcyB0aGFu IHRoZSBrZXkgYmVpbmcgZW5jcnlwdGVkLiAmbmJzcDtJcw0KIHRoaXMgd2hhdCB5b3UgbWVhbj88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm8sIEkgd2FzIGFza2luZyBp ZiDigJxlbmNyeXB0ZWQgcHJpdmF0ZSBrZXnigJ0gaXMgYSBzZXBhcmF0ZSB0aGluZyBmcm9tIOKA nHBsYWludGV4dCBwcml2YXRlIGtleS7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_7AE4751289744A8C9756699CAE220EF9akamaicom_-- From nobody Wed Sep 18 10:03:13 2019 Return-Path: <0100016d4553e645-9c5796b8-15da-4a51-b820-5ecef6575eff-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60DEF120AF9 for ; Wed, 18 Sep 2019 10:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 0xliqs0VYMX4 for ; Wed, 18 Sep 2019 10:03:11 -0700 (PDT) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E48C8120AF2 for ; Wed, 18 Sep 2019 10:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568826189; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Message-Id:References:To:Feedback-ID; bh=y091mJWRTDKUloELQQReqp+WS/uWuvRDfZe6zeXleWc=; b=leZGz/fd8ucL2ab/j3LSP/95YqV7fyRnj4ctgn62Ko00rINufWyERlyTCnaXuL5R 7jo0mumA0+LmU/G4kRu+7uzvsAuzD/Z5St5xNdkKVMSGfY28WKmP9e0jnI/5XVOKq8v I0Agz0RtYmLBMx96T6mKw+GQC4Za0dWtBhn+LSTk= Content-Type: multipart/alternative; boundary="Apple-Mail=_90920BF8-66F4-49CE-A2B2-3C19246CC770" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Kent Watsen In-Reply-To: Date: Wed, 18 Sep 2019 17:03:09 +0000 Cc: "Salz, Rich" , "netconf@ietf.org" , Rifaat Shekh-Yusef Message-ID: <0100016d4553e645-9c5796b8-15da-4a51-b820-5ecef6575eff-000000@email.amazonses.com> References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@email.amazonses.com> <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> To: "Rob Wilton (rwilton)" X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.18-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 17:03:12 -0000 --Apple-Mail=_90920BF8-66F4-49CE-A2B2-3C19246CC770 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [moving Russ and Sean to BCC, per Rich's action] > Minor: Does the =E2=80=9Cstring=E2=80=9D in the description above mean = =E2=80=9CASCII string=E2=80=9D or =E2=80=9Cbinary string=E2=80=9D, RFC = 4251 seemingly uses both definitions? I don't know, but this is the language found for the "key-data" leaf in = RFC 7317 (i.e., we've been living with this definition for awhile) > Is putting the encrypted keys into DER-encoded OneSymmetricKey = obviously the right thing to do? Are there other choices? Yes, if there was one thing that came out of my discussion with Russ and = Sean is that OneSymmetricKey and OneAsymmetricKey SHOULD be used for = encrypting key data. Anything else would be a BIG effort. =20 The real question is if we should also use the One*Key structures for = unencrypted keys, which could help some ways, but I think that it's = better to use the values provided by OpenSSL command line. This = approach pushes the complexity of using the One*Key structures to just = the "advanced" case of when encryption is needed and, besides, it would = primarily be for the NC/RC server to generate/parse; clients would = rarely encrypt a key themselves, the only case I can think of when they = might would be for the RMA workflow we discussed a few weeks back. Kent --Apple-Mail=_90920BF8-66F4-49CE-A2B2-3C19246CC770 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
[moving Russ and Sean to BCC, per Rich's action]



Minor: Does the = =E2=80=9Cstring=E2=80=9D in the description above mean =E2=80=9CASCII = string=E2=80=9D or =E2=80=9Cbinary string=E2=80=9D, RFC 4251 seemingly = uses both definitions?

I= don't know, but this is the language found for the "key-data" leaf = in RFC 7317 (i.e., we've been living with this definition for = awhile)


Is = putting the encrypted keys into DER-encoded OneSymmetricKey obviously = the right thing to do?  Are there other choices?



Yes, if there was one = thing that came out of my discussion with Russ and Sean is that = OneSymmetricKey and OneAsymmetricKey SHOULD be used for encrypting key = data.   Anything else would be a BIG effort. =   

The real question is if = we should also use the One*Key structures for unencrypted keys, which = could help some ways, but I think that it's better to use the values = provided by OpenSSL command line.  This approach pushes the = complexity of using the One*Key structures to just the "advanced" case = of when encryption is needed and, besides, it would primarily be for the = NC/RC server to generate/parse; clients would rarely encrypt a key = themselves, the only case I can think of when they might would be for = the RMA workflow we discussed a few weeks back.


Kent


= --Apple-Mail=_90920BF8-66F4-49CE-A2B2-3C19246CC770-- From nobody Wed Sep 18 10:12:30 2019 Return-Path: <0100016d455c6145-844c669e-8f31-4203-a827-7368d33cdee4-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D59120A1B for ; Wed, 18 Sep 2019 10:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 d0fGVM79dULb for ; Wed, 18 Sep 2019 10:12:27 -0700 (PDT) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF38B12088F for ; Wed, 18 Sep 2019 10:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568826745; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Message-Id:References:To:Feedback-ID; bh=JGl4Bpb1xb8ulVfc4XqZnCmbf6FR1gbtytSx3D9fVWc=; b=mXsFrwWHalKjMS1fu8zz1S3opJPpDJHfriOsdHZyByue8gkt1W7yWV8JWEmDVof7 SQ1GGxDtTJxS8qjauuz04nkGy7tvg/FKWoIo9BwoWQDBhKlLu1fH4ftyVvh5eWiMKXx Wxwm265ejrQK4lEGzs3vM/tBsECh63f39UG7kdhI= Content-Type: multipart/alternative; boundary="Apple-Mail=_09EB1161-443D-4F6E-ADF7-58268BB7904F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Kent Watsen In-Reply-To: <20190918163657.4pxh5jddxgrir5oh@anna.jacobs.jacobs-university.de> Date: Wed, 18 Sep 2019 17:12:25 +0000 Cc: "Rob Wilton (rwilton)" , "netconf@ietf.org" , Rifaat Shekh-Yusef Message-ID: <0100016d455c6145-844c669e-8f31-4203-a827-7368d33cdee4-000000@email.amazonses.com> References: <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <20190918163657.4pxh5jddxgrir5oh@anna.jacobs.jacobs-university.de> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.18-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 17:12:29 -0000 --Apple-Mail=_09EB1161-443D-4F6E-ADF7-58268BB7904F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [moving Russ and Sean to BCC, per Rich's action] > I tend to agree that sometimes less modules is more. For me, the > problem is likely more that I am not entirely sure what the proper > base types would be, which may depend on what exactly they are used > for. I guess I wait until I see the description text... Okay, we'll keep just the one YANG module. >> A bit separate from the above, but still in mind: >>=20 >> - specify that all TLS public-keys are a DER-encoded = SubjectPublicKeyInfo structure >> - specify that all SSH public-keys are a "ssh-public-key-type" type = (see below) >> - specify that all encrypted symmetric keys are a DER-encoded = OneSymmetricKey structure >> - specify that all encrypted asymmetric keys are a DER-encoded = OneAsymmetricKey structure >=20 > I would check what is commonly used in existing configuration > interfaces. We are not inventing the wheel here. And whatever we > define better is usable with existing implementations and tools. These are the native types used by OpenSSL and OpenSSH, what more = verification do we need? =20 Possibly we could discuss supporting PEM, in addition to DER, but I'd = image that, if PEM is supported at all, the presentation layer (Web UI, = CLI) would convert it to/from PEM as needed (i.e., the underlying model = only needs to support DER). > The SSH implementations that I use have the binary key data rendered > in ASCII. In fact, the whole key record is rendered in ASCII. I > strongly suggest to use formats that are well established. This is the "key-data" leaf from RFC 7317. Are you saying that it = should've been different? Regardless, should this be a presentation layer issue? Kent // contributor --Apple-Mail=_09EB1161-443D-4F6E-ADF7-58268BB7904F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii [moving Russ and Sean to BCC, per Rich's action]



I tend to agree that sometimes less modules is more. For me, = the
problem is likely more that I am not entirely sure = what the proper
base types would be, which may depend on = what exactly they are used
for. I guess I wait until I see = the description text...


Okay, we'll keep just = the one YANG module.



A bit = separate from the above, but still in mind:

=  - specify that all TLS public-keys are a DER-encoded = SubjectPublicKeyInfo structure
 - specify that all = SSH public-keys are a "ssh-public-key-type" type (see below)
 - specify that all encrypted symmetric keys are a = DER-encoded OneSymmetricKey structure
 - specify = that all encrypted asymmetric keys are a DER-encoded OneAsymmetricKey = structure

I would check what = is commonly used in existing configuration
interfaces. We = are not inventing the wheel here. And whatever we
define = better is usable with existing implementations and tools.

These = are the native types used by OpenSSL and OpenSSH, what more verification = do we need?   

Possibly we = could discuss supporting PEM, in addition to DER, but I'd image that, if = PEM is supported at all, the presentation layer (Web UI, CLI) would = convert it to/from PEM as needed (i.e., the underlying model only needs = to support DER).


The SSH = implementations that I use have the binary key data rendered
in ASCII. In fact, the whole key record is rendered in ASCII. = I
strongly suggest to use formats that are well = established.

This is the "key-data" leaf from RFC 7317. =  Are you saying that it should've been different?

Regardless, should this be a presentation layer = issue?

Kent // = contributor


= --Apple-Mail=_09EB1161-443D-4F6E-ADF7-58268BB7904F-- From nobody Wed Sep 18 10:16:41 2019 Return-Path: <0100016d456038a8-7eb604b5-235e-4fe2-b0a3-397a4a9a18f3-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E125A1209D0 for ; Wed, 18 Sep 2019 10:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 DZh5o86mH7QQ for ; Wed, 18 Sep 2019 10:16:38 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A2A712088F for ; Wed, 18 Sep 2019 10:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568826997; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=w5W+KH7vMeP9hyjbxXMKelB0g0vnuvtlym3tPkejwws=; b=XjCFphuUxS30Bw8Vb3xvCFqLlqK9amd8AuyRHf/C9JhXHHr8k6EXCGdDWMPZRdFj OE9x7ThLmlfXnOHCYPK/UTKoy6y+EVMN5RsHQFCcEozqnENr9/Nz676YMkX6G9YfC4T CDJL0aaazfv1YA2yPArBGZ0X8hbUrvwZ1v9EkhZI= From: Kent Watsen Message-ID: <0100016d456038a8-7eb604b5-235e-4fe2-b0a3-397a4a9a18f3-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_007FAB26-CB58-47AD-8783-4BC7A684ED6D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 18 Sep 2019 17:16:36 +0000 In-Reply-To: <7AE47512-8974-4A8C-9756-699CAE220EF9@akamai.com> Cc: "Rob Wilton (rwilton)" , "netconf@ietf.org" , Rifaat Shekh-Yusef To: "Salz, Rich" References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@email.amazonses.com> <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <2614C1E8-A015-4816-AA3B-F75D02F5701C@akamai.com> <0100016d45447f68-68073ae2-3f96-4c6d-846d-7c661c1cdb0c-000000@email.amazonses.com> <7AE47512-8974-4A8C-9756-699CAE220EF9@akamai.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.18-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 17:16:40 -0000 --Apple-Mail=_007FAB26-CB58-47AD-8783-4BC7A684ED6D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > The desire to use SubjectPublicKeyInfo is per tests (2) and (4) = described here: = https://mailarchive.ietf.org/arch/msg/netconf/ysukDdbCA0a70heF1a_ldZNr4yE = . > =20 > Those experiments do not matter. TLS sends X509 certificates. I am = not aware of any protocol (and I don=E2=80=99t know all of them, of = course) that sends raw public keys. What protocols are you thinking of? > =20 > If you want to configure an HTTPS server using netconf/yang, you will = need to give that server X509 certificates. The previous line in my response read: "There is a separate field for = certificates, which is an X.509 certificate." So, that need/desire is covered. Having the "public-key" field is not = needed for TLS. > No, I was asking if =E2=80=9Cencrypted private key=E2=80=9D is a = separate thing from =E2=80=9Cplaintext private key.=E2=80=9D =46rom a Keystore perspective, there are keys, and each key may either = be encrypted or not, but not both at the same time. Kent // contributor =20= --Apple-Mail=_007FAB26-CB58-47AD-8783-4BC7A684ED6D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

 
Those experiments do not matter.  = TLS sends X509 certificates.  I am not aware of any protocol (and I = don=E2=80=99t know all of them, of course) that sends raw public = keys.  What protocols are you thinking of?
 
If you = want to configure an HTTPS server using netconf/yang, you will need to = give that server X509 = certificates.


The previous line in my = response read: "There is a separate field for certificates, which is an = X.509 certificate."

So, that = need/desire is covered.  Having the "public-key" field is not = needed for TLS.



 No, I was asking if =E2=80=9Cencrypt= ed private key=E2=80=9D is a separate thing from =E2=80=9Cplaintext = private key.=E2=80=9D

=46rom a Keystore perspective, there are = keys, and each key may either be encrypted or not, but not both at the = same time.


Kent // contributor

 
= --Apple-Mail=_007FAB26-CB58-47AD-8783-4BC7A684ED6D-- From nobody Wed Sep 18 10:41:18 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8388D120B0A for ; Wed, 18 Sep 2019 10:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=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=jacobsuniversity.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 13iK75dlKCN6 for ; Wed, 18 Sep 2019 10:41:14 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130048.outbound.protection.outlook.com [40.107.13.48]) (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 54B74120AE1 for ; Wed, 18 Sep 2019 10:41:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SpCp/0RNESK1eWOKVyaRtXNOXFjq6t7EPl2b4tMf/ag29WV5rlR5Oq65iM97ouOftPT3d1+vftp7qyeKS5RcPvAiUAo0VIzAuPRlgtaBLKfjfseNY30R0HkGDLIGqU+sTk4+aB/9XlzAW2NmoDA/isYtxoRqXmhPGt2dK3bUiebPmh+DMqUD9USgp05ldSinlSVHt3SnDkWorQwTAarSYhhgn6OAiBpSMuzuO/a+TRcyQjUcCW/89juLdmLPOUkENgrAGtvQzCmsALZvL9cJYoJqQEW82qpsoOzO7ILyceNOarRihp0jNJ+uJG9TghGnlPgJWd5Rig/DuaZOrcv4Sw== 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=fq1PsYxYP/ehdmXf0gmiCKm5KfJe/oHuZobb0q0q8os=; b=jcpsk3BbkfjtNXELShtB0+vPuP0x6oj5gmAPxKJ0yb3Om1YZyIUq1tWPj6FndUMz4BJmP2BNPDvzAuODrWMYSKkBd5O79dLkRjpeeNKV8Hky/2VNB5iGCgU/Lg5KLFO/yTwT//e0bLcqKKhh9v+2ZV/qINMC+cacdi4Zr+HdZ8hiQ9UcIcA4CUg/jW6/ewsikakQ1p/yf6yFHqmt1sQ2ZM4Fn8czAmNMo/i9JEIkZqvQ9BgVHDt8PI4sajx3aPRuyKguMJ0z8Re7wE9P7KU0hmboDsywk52vjkI5W64w1CI+NP1QdnVYAMjrz3hcNKP2l49J3WwdDUA7Bif2XbGQOQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fq1PsYxYP/ehdmXf0gmiCKm5KfJe/oHuZobb0q0q8os=; b=dR1iey4xpJbOMlyI6W8BQ0H8smI8bVIz2K1cXyYm7X0mL4tHq+Tec20Do1AuPbvuVhKrr0ROLTcKsLfGiImGsDyDjUriihDT6MoKmze+vViwNoznniZ+4QC2SWS3D3k3tCWTpwFZLsc0dQB/09/+ss6Q0xXQ3A0wJO6yl0DxFqo= Received: from VI1P190MB0686.EURP190.PROD.OUTLOOK.COM (10.186.159.71) by VI1P190MB0285.EURP190.PROD.OUTLOOK.COM (10.165.197.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.15; Wed, 18 Sep 2019 17:41:09 +0000 Received: from VI1P190MB0686.EURP190.PROD.OUTLOOK.COM ([fe80::d48a:ffa3:4fff:141e]) by VI1P190MB0686.EURP190.PROD.OUTLOOK.COM ([fe80::d48a:ffa3:4fff:141e%2]) with mapi id 15.20.2263.023; Wed, 18 Sep 2019 17:41:09 +0000 From: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= To: Kent Watsen CC: "Rob Wilton (rwilton)" , "netconf@ietf.org" , Rifaat Shekh-Yusef Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVbjbxVhFlbERW30moo9Q8WhnpJqcxoiSAgAAJ6YCAAAgFgA== Date: Wed, 18 Sep 2019 17:41:08 +0000 Message-ID: <20190918174107.lqipsd2qal5x7eom@anna.jacobs.jacobs-university.de> References: <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <20190918163657.4pxh5jddxgrir5oh@anna.jacobs.jacobs-university.de> <0100016d455c6145-844c669e-8f31-4203-a827-7368d33cdee4-000000@email.amazonses.com> In-Reply-To: <0100016d455c6145-844c669e-8f31-4203-a827-7368d33cdee4-000000@email.amazonses.com> Reply-To: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: PR0P264CA0155.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1b::23) To VI1P190MB0686.EURP190.PROD.OUTLOOK.COM (2603:10a6:800:12e::7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:638:709:5::7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 853527d9-163b-4042-b745-08d73c5f63aa x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:VI1P190MB0285; x-ms-traffictypediagnostic: VI1P190MB0285: x-ms-exchange-purlcount: 1 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01644DCF4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(39850400004)(346002)(376002)(396003)(199004)(189003)(25786009)(478600001)(8676002)(6246003)(2906002)(99286004)(14454004)(6506007)(786003)(46003)(316002)(8936002)(486006)(7736002)(256004)(14444005)(305945005)(54906003)(476003)(71200400001)(81166006)(81156014)(71190400001)(11346002)(6116002)(446003)(6436002)(86362001)(186003)(6306002)(1076003)(386003)(5660300002)(43066004)(102836004)(3450700001)(45776006)(6512007)(229853002)(52116002)(6486002)(66946007)(66446008)(76176011)(66556008)(4326008)(66476007)(64756008); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P190MB0285; H:VI1P190MB0686.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 1g4LQYGKaFc3jQGy0L3RWJpyYq46WrUFcwq22bJN7jXbyTbV5GQAIKOGTJP3n2sk9e33rirzjazDQ35MLKn6eVEwUJMYvJA+ivJYd2k6k42/Rdle8bkmM8bZAjJIpvY3/HH1fK+Fx3Rbe5vJv4wrtI7DHZPmfP9VzHK/Ud+nxrawirt1bZTx5/o7WtW9bb4HsmzY1yl0SX3vUPnUadQl+hfx4YpNGTzCcuwv3SehkH071bIh1gdfQus5jT3fqCo9eMwNrkYqI7XjRaKUFjgV96rXF8KjvJAQzsfvUSLgEuxGCEzo8ElpWf3sk8d6zUcegPhsl47hS9r74Hie+sn6LvMGbpumImavlYhA9LLZx+Dt4WR6tNuGBFfwzRfHfCqPRSvzNDLfbKBrK+vl97B/y68Qx3iPzUYlnhpF4WFwXgc= Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 853527d9-163b-4042-b745-08d73c5f63aa X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2019 17:41:08.9127 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dbbZ2iasPBm5rtaP7eKxWOiYGJFhqD11xin1yhC9xbMVzqfSW469xpEReLNkVjvPoU61uo5ZbNH3UCWIoSx/iqZhoaXy6oXWHTa1uS0d8BA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P190MB0285 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 17:41:16 -0000 On Wed, Sep 18, 2019 at 05:12:25PM +0000, Kent Watsen wrote: > >=20 > > I would check what is commonly used in existing configuration > > interfaces. We are not inventing the wheel here. And whatever we > > define better is usable with existing implementations and tools. >=20 > These are the native types used by OpenSSL and OpenSSH, what more verific= ation do we need? =20 >=20 > Possibly we could discuss supporting PEM, in addition to DER, but I'd ima= ge that, if PEM is supported at all, the presentation layer (Web UI, CLI) w= ould convert it to/from PEM as needed (i.e., the underlying model only need= s to support DER). > On my Linux system, certs tend to be stoed in pem format, so I am biased. It seems some other applications like web browsers and server also tend to use pem format. But I am happy to be corrected since my experience with cert usage is limited. Yes, the application or presentation could convert between formats and solve all problems. One of the failures of SNMP was that SNMP required an application or presentation layer to be usable while CLIs did not require other tools. The idea that there is always software between the NC/RC server and whoever has to solve an automation problem has somehow failed in the past. I believe data models should be written to enable automation without requiring lots of additional tooling. And yes, there is a need to find a balance. =20 > > The SSH implementations that I use have the binary key data rendered > > in ASCII. In fact, the whole key record is rendered in ASCII. I > > strongly suggest to use formats that are well established. >=20 > This is the "key-data" leaf from RFC 7317. Are you saying that it should= 've been different? >=20 > Regardless, should this be a presentation layer issue? See above, if we start to require a presentation layer, we may repeat a failure. It might be useful to check who has implemented that part of RFC 7317 and how happy operators were with the format. I personally would not immediately know how to convert my openssh key in a binary format such that that I can use the YANG model. We should try to maximize usability and stay away from the idea that a presentation layer will be available to make things usable for people that have to script customized automation solutions. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Sep 18 12:02:58 2019 Return-Path: <0100016d45c185ab-6b73aeb6-b61a-4880-9ee6-a472a8c76f99-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172D2120128 for ; Wed, 18 Sep 2019 12:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 OSCnMj6IUF3e for ; Wed, 18 Sep 2019 12:02:55 -0700 (PDT) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A1B01200E6 for ; Wed, 18 Sep 2019 12:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568833373; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=84G48VwAz/+YBlTZ0B56UGv5I2ZA+yJ/HfDYZJHEPec=; b=lM6vWDFdpVvIt3Nv+sH/llCEFxnqOqItK8H4y5r92V6AkmhclFeGWACtGdQR5Sf2 SgsODCOvKKQ7biHPdLSPbeVZdoibUGHXCbwzeLYPt4oeSr1vfZcVa7fgTU8ZIwjUk8U cKwXNIQEPSo+a9kQhxG3nE9LoiKfyCtvk74MSx+E= From: Kent Watsen Message-ID: <0100016d45c185ab-6b73aeb6-b61a-4880-9ee6-a472a8c76f99-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_DE28597D-2FF7-4BD3-A4C9-3F3892BFD814" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 18 Sep 2019 19:02:53 +0000 In-Reply-To: <20190918174107.lqipsd2qal5x7eom@anna.jacobs.jacobs-university.de> Cc: "Rob Wilton (rwilton)" , "netconf@ietf.org" , Rifaat Shekh-Yusef To: Juergen Schoenwaelder References: <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <20190918163657.4pxh5jddxgrir5oh@anna.jacobs.jacobs-university.de> <0100016d455c6145-844c669e-8f31-4203-a827-7368d33cdee4-000000@email.amazonses.com> <20190918174107.lqipsd2qal5x7eom@anna.jacobs.jacobs-university.de> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.18-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 19:02:57 -0000 --Apple-Mail=_DE28597D-2FF7-4BD3-A4C9-3F3892BFD814 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On my Linux system, certs tend to be stoed in pem format, so I am > biased. It seems some other applications like web browsers and server > also tend to use pem format. But I am happy to be corrected since my > experience with cert usage is limited. >=20 > Yes, the application or presentation could convert between formats and > solve all problems. One of the failures of SNMP was that SNMP required > an application or presentation layer to be usable while CLIs did not > require other tools. The idea that there is always software between > the NC/RC server and whoever has to solve an automation problem has > somehow failed in the past. I believe data models should be written to > enable automation without requiring lots of additional tooling. And > yes, there is a need to find a balance. Use a union statement? The 'string' type for PEM and 'binary' for DER? >>> The SSH implementations that I use have the binary key data rendered >>> in ASCII. In fact, the whole key record is rendered in ASCII. I >>> strongly suggest to use formats that are well established. >>=20 >> This is the "key-data" leaf from RFC 7317. Are you saying that it = should've been different? >>=20 >> Regardless, should this be a presentation layer issue? >=20 > See above, if we start to require a presentation layer, we may repeat > a failure. It might be useful to check who has implemented that part > of RFC 7317 and how happy operators were with the format. I personally > would not immediately know how to convert my openssh key in a binary > format such that that I can use the YANG model. We should try to > maximize usability and stay away from the idea that a presentation > layer will be available to make things usable for people that have to > script customized automation solutions. Use a union for this too? string vs binary? One issue is that your file-format is most likely an OpenSSH-specific = format, which is likely duplicated by other SSH implementations. Is it = too much of an assumption to use that format as the defacto 'string' = format? Perhaps we should define a custom type (e.g., openssh-string) = to use instead of "string"? Kent // contributor --Apple-Mail=_DE28597D-2FF7-4BD3-A4C9-3F3892BFD814 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On my Linux system, certs tend to be stoed in pem format, so = I am
biased. It seems some other applications like web = browsers and server
also tend to use pem format. But I am = happy to be corrected since my
experience with cert usage = is limited.

Yes, the application or = presentation could convert between formats and
solve all = problems. One of the failures of SNMP was that SNMP required
an application or presentation layer to be usable while CLIs = did not
require other tools. The idea that there is always = software between
the NC/RC server and whoever has to solve = an automation problem has
somehow failed in the past. I = believe data models should be written to
enable automation = without requiring lots of additional tooling. And
yes, = there is a need to find a balance.


Use a union statement?  The 'string' type =  for PEM and 'binary' for DER?


The SSH implementations that I use have the binary key data = rendered
in ASCII. In fact, the whole key record is = rendered in ASCII. I
strongly suggest to use formats that = are well established.

This is = the "key-data" leaf from RFC 7317.  Are you saying that it = should've been different?

Regardless, = should this be a presentation layer issue?

See above, if we start to require a presentation layer, we = may repeat
a failure. It might be useful to check who has = implemented that part
of RFC 7317 and how happy operators = were with the format. I personally
would not immediately = know how to convert my openssh key in a binary
format such = that that I can use the YANG model. We should try to
maximize usability and stay away from the idea that a = presentation
layer will be available to make things usable = for people that have to
script customized automation = solutions.

Use a union for this too?  string vs = binary?

One issue is that your = file-format is most likely an OpenSSH-specific format, which is likely = duplicated by other SSH implementations.   Is it too much of an = assumption to use that format as the defacto 'string' format? =  Perhaps we should define a custom type (e.g., openssh-string) to = use instead of "string"?


Kent // contributor



= --Apple-Mail=_DE28597D-2FF7-4BD3-A4C9-3F3892BFD814-- From nobody Wed Sep 18 12:22:29 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99ECE1200B7 for ; Wed, 18 Sep 2019 12:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, SPF_NONE=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=jacobsuniversity.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 DG1abXEmeHTO for ; Wed, 18 Sep 2019 12:22:26 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60065.outbound.protection.outlook.com [40.107.6.65]) (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 ACDC1120086 for ; Wed, 18 Sep 2019 12:22:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X1g57OeRJxrPUUgK8t3jbZy0cw8cO+uDPzhlFyQETxNNMviA1rGPInHZUSxDI7Q329dphyZjm7WbuAMoY9aZ/40CFtN1tJrrFYqK+mz4iidOgBwh+P6kWAqCcO++8KsYqdojUbIHMDLshymE5KlV+Pa4u4gMfgXq32DwvMlnEyp86nc08J0v4zLWwvFlrD+eAoF2QlqGhmZ0ChYzlogYRVT1KtRz1mnFxbWC3/oGfckaAQ+JUpyD99GpeOQHD53dbJodJSDePyZ+aPw7KhB498cAzEmFvRCuDdV3cm9lWQwK2hFI6lcImVOUUKFyvm4HCjwaSK5qSelyMACAyK8wkA== 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=8lEvYnGaTKxx18UoiaZPMUsMqsnCMBzpLmpk18Pebqw=; b=WIkxecMaQjadCZnHsuZ1EmNlMzriUIWRGsF8D0TnyWMkAMUXriQGSFwR6i0Ynw+aG8r7JmLsfj+5mS0cEIgSADAj4GD72BnI4BxLZ1eLJJpuSorVsmr15po5dD01p6fSol2jZX3Ge/jl4wl7tctLIf523eRi8abLIJC6bju9MseWY99dPZf19H6PX6TG7vrlFyJ8U7LoFjimhXsUV3nTUf9+LxWnM0/uoL7lv8ctOY852j184V2QCyl+290ZI15Nzmh3j5aMCX5517Lv1uY0HjmcDC3W/bDakpiAKQSpF3eCPJG7MtpZYjVh82XA4ODvnG4hGrADx3mBC1P+sOLKWQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8lEvYnGaTKxx18UoiaZPMUsMqsnCMBzpLmpk18Pebqw=; b=Z7ibSBiiwia0JYSZq3FyhrTcEHx2VrLJwpZ3bidw1IhGln1D62FqCqdBWD7S8SmikuLw2ra8OvYEj2u1uY+Q/x+OcB/4Ch4pWTtPaEipmNY1ES+WqQIanHma1r6C63sF5ZBlDmVniJyDUgfhSQgHyUkC5C6kSyiDuEwjK/PEUKo= Received: from VI1P190MB0686.EURP190.PROD.OUTLOOK.COM (10.186.159.71) by VI1P190MB0158.EURP190.PROD.OUTLOOK.COM (10.172.15.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.18; Wed, 18 Sep 2019 19:22:23 +0000 Received: from VI1P190MB0686.EURP190.PROD.OUTLOOK.COM ([fe80::d48a:ffa3:4fff:141e]) by VI1P190MB0686.EURP190.PROD.OUTLOOK.COM ([fe80::d48a:ffa3:4fff:141e%2]) with mapi id 15.20.2263.023; Wed, 18 Sep 2019 19:22:23 +0000 From: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= To: Kent Watsen CC: "Rob Wilton (rwilton)" , "netconf@ietf.org" , Rifaat Shekh-Yusef Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVbjbxVhFlbERW30moo9Q8WhnpJqcxoiSAgAAJ6YCAAAgFgIAAFtiAgAAFcgA= Date: Wed, 18 Sep 2019 19:22:23 +0000 Message-ID: <20190918192222.gaxqofrozbaqdps5@anna.jacobs.jacobs-university.de> References: <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <20190918163657.4pxh5jddxgrir5oh@anna.jacobs.jacobs-university.de> <0100016d455c6145-844c669e-8f31-4203-a827-7368d33cdee4-000000@email.amazonses.com> <20190918174107.lqipsd2qal5x7eom@anna.jacobs.jacobs-university.de> <0100016d45c185ab-6b73aeb6-b61a-4880-9ee6-a472a8c76f99-000000@email.amazonses.com> In-Reply-To: <0100016d45c185ab-6b73aeb6-b61a-4880-9ee6-a472a8c76f99-000000@email.amazonses.com> Reply-To: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: AM4PR05CA0032.eurprd05.prod.outlook.com (2603:10a6:205::45) To VI1P190MB0686.EURP190.PROD.OUTLOOK.COM (2603:10a6:800:12e::7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:638:709:5::7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e3828903-16b7-4cf4-011f-08d73c6d885b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600167)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:VI1P190MB0158; x-ms-traffictypediagnostic: VI1P190MB0158: x-ms-exchange-purlcount: 1 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 01644DCF4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(39850400004)(136003)(396003)(376002)(199004)(189003)(305945005)(256004)(81156014)(8676002)(81166006)(8936002)(7736002)(71200400001)(71190400001)(486006)(786003)(316002)(1076003)(6116002)(6306002)(6512007)(4744005)(5660300002)(3450700001)(86362001)(2906002)(66946007)(11346002)(66476007)(66556008)(6486002)(6246003)(45776006)(66446008)(64756008)(4326008)(46003)(476003)(446003)(14454004)(102836004)(76176011)(6506007)(386003)(99286004)(6436002)(229853002)(43066004)(25786009)(478600001)(186003)(54906003)(52116002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P190MB0158; H:VI1P190MB0686.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: hKvWBeC/PPivk8KGYjL8gttDsEAOAAnZ89hIR9tZDInCR2NYLDOClbK3grn5HSGbkMdg4bPlOAsbfHxkb/J1pcWuj57frpD8AI+0YoXLjk7ihdftD/c2+0qbWKaMykZG4W2lFyIsKoaWWkEQH+PFsNqhlmoag5lT1FxlfIs0Dl8d2HQXSTyOonTmCs0mdbYwB7aycz5Udr3bEtQHQE1UYS0aSv5PLNcH18wqMuhvC+w24GOYcujgGSTcdMeY+wUhVC1VgQ/MCQbU3kFti03cTONXfa0zaSoCd+ZCESO4Z6/CYP/vzbfWAljgxamgRaAn9km+IIi7VACu/uIQUHuw5iyaoOhLpbJwM4cLuFp0QxVFxi17P4591DVIyJKXc8UYTjUuZb3aJbEb5zaozcyQyl5vvpPC15ZNve3BjsWjEOs= Content-Type: text/plain; charset="iso-8859-1" Content-ID: <84D2F1442D69FD438407AB9084B9B33A@EURP190.PROD.OUTLOOK.COM> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: e3828903-16b7-4cf4-011f-08d73c6d885b X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2019 19:22:23.5003 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TGOvZ2DWpz9Kf8AEBkBm6tVK3DQkaZscjXyBKrxuZPTXo66C26A+n+WPZIxr8YC57eGo4q/xva3eqOMaRdPzA3o+4MX/Hur8YKq+2YL5ItU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P190MB0158 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 19:22:28 -0000 On Wed, Sep 18, 2019 at 07:02:53PM +0000, Kent Watsen wrote: >=20 > One issue is that your file-format is most likely an OpenSSH-specific for= mat, which is likely duplicated by other SSH implementations. Is it too m= uch of an assumption to use that format as the defacto 'string' format? Pe= rhaps we should define a custom type (e.g., openssh-string) to use instead = of "string"? > What are the SSH implementations that do not understand that format? /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Sep 18 13:06:44 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C443E120953 for ; Wed, 18 Sep 2019 13:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 PDLwz6d1QaVS for ; Wed, 18 Sep 2019 13:06:41 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 310A1120086 for ; Wed, 18 Sep 2019 13:06:41 -0700 (PDT) Received: from localhost (h-46-233.A165.priv.bahnhof.se [46.59.46.233]) by mail.tail-f.com (Postfix) with ESMTPSA id 84E681AE047F; Wed, 18 Sep 2019 22:06:38 +0200 (CEST) Date: Wed, 18 Sep 2019 22:06:38 +0200 (CEST) Message-Id: <20190918.220638.1382892184185166890.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: rwilton@cisco.com, netconf@ietf.org, rifaat.ietf@gmail.com From: Martin Bjorklund In-Reply-To: <0100016d4553e645-9c5796b8-15da-4a51-b820-5ecef6575eff-000000@email.amazonses.com> References: <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <0100016d4553e645-9c5796b8-15da-4a51-b820-5ecef6575eff-000000@email.amazonses.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 20:06:43 -0000 S2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0PiB3cm90ZToNCj4gW21vdmluZyBSdXNz IGFuZCBTZWFuIHRvIEJDQywgcGVyIFJpY2gncyBhY3Rpb25dDQo+IA0KPiANCj4gDQo+ID4gTWlu b3I6IERvZXMgdGhlIOKAnHN0cmluZ+KAnSBpbiB0aGUgZGVzY3JpcHRpb24gYWJvdmUgbWVhbiDi gJxBU0NJSSBzdHJpbmfigJ0NCj4gPiBvciDigJxiaW5hcnkgc3RyaW5n4oCdLCBSRkMgNDI1MSBz ZWVtaW5nbHkgdXNlcyBib3RoIGRlZmluaXRpb25zPw0KPiANCj4gSSBkb24ndCBrbm93LCBidXQg dGhpcyBpcyB0aGUgbGFuZ3VhZ2UgZm91bmQgZm9yIHRoZSAia2V5LWRhdGEiIGxlYWYNCj4gaW4g UkZDIDczMTcgKGkuZS4sIHdlJ3ZlIGJlZW4gbGl2aW5nIHdpdGggdGhpcyBkZWZpbml0aW9uIGZv ciBhd2hpbGUpDQoNClNvIHRoZSBkZWZpbml0aW9uIGlzOg0KDQogICAgICAgICAgICAgbGVhZiBr ZXktZGF0YSB7DQogICAgICAgICAgICAgICB0eXBlIGJpbmFyeTsNCiAgICAgICAgICAgICAgIG1h bmRhdG9yeSB0cnVlOw0KICAgICAgICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICAg ICAgIlRoZSBiaW5hcnkgcHVibGljIGtleSBkYXRhIGZvciB0aGlzIFNTSCBrZXksIGFzDQogICAg ICAgICAgICAgICAgICBzcGVjaWZpZWQgYnkgUkZDIDQyNTMsIFNlY3Rpb24gNi42LCBpLmUuOg0K DQogICAgICAgICAgICAgICAgICAgIHN0cmluZyAgICBjZXJ0aWZpY2F0ZSBvciBwdWJsaWMga2V5 IGZvcm1hdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaWRlbnRpZmllcg0KICAgICAg ICAgICAgICAgICAgICBieXRlW25dICAga2V5L2NlcnRpZmljYXRlIGRhdGEuIjsNCg0KVGhlIHRl eHR1YWwgcmVwcmVzZW50YXRpb24gb2YgYSBiaW5hcnkgaW4gWUFORyBpcyBiYXNlNjQgZW5jb2Rl ZC4gIEFzDQppdCBoYXBwZW5zLCB0aGlzIGlzIGV4YWN0bHkgdGhlIHNhbWUgYXMgT3BlblNTSCB1 c2VzIGZvciBpdHMga2V5cy4gIFNvDQp0aGUgb3BlbiBzc2gga2V5IGNhbiBiZSBjb3B5L3Bhc3Rl ZCBpbnRvIHRoZSBOQy9SQyBYTUwvSlNPTi4NCg0KDQovbWFydGluDQoNCg0KDQoNCj4gDQo+IA0K PiA+IElzIHB1dHRpbmcgdGhlIGVuY3J5cHRlZCBrZXlzIGludG8gREVSLWVuY29kZWQgT25lU3lt bWV0cmljS2V5DQo+ID4gb2J2aW91c2x5IHRoZSByaWdodCB0aGluZyB0byBkbz8gIEFyZSB0aGVy ZSBvdGhlciBjaG9pY2VzPw0KPiANCj4gDQo+IFllcywgaWYgdGhlcmUgd2FzIG9uZSB0aGluZyB0 aGF0IGNhbWUgb3V0IG9mIG15IGRpc2N1c3Npb24gd2l0aCBSdXNzDQo+IGFuZCBTZWFuIGlzIHRo YXQgT25lU3ltbWV0cmljS2V5IGFuZCBPbmVBc3ltbWV0cmljS2V5IFNIT1VMRCBiZSB1c2VkDQo+ IGZvciBlbmNyeXB0aW5nIGtleSBkYXRhLiAgQW55dGhpbmcgZWxzZSB3b3VsZCBiZSBhIEJJRyBl ZmZvcnQuDQo+IA0KPiBUaGUgcmVhbCBxdWVzdGlvbiBpcyBpZiB3ZSBzaG91bGQgYWxzbyB1c2Ug dGhlIE9uZSpLZXkgc3RydWN0dXJlcyBmb3INCj4gdW5lbmNyeXB0ZWQga2V5cywgd2hpY2ggY291 bGQgaGVscCBzb21lIHdheXMsIGJ1dCBJIHRoaW5rIHRoYXQgaXQncw0KPiBiZXR0ZXIgdG8gdXNl IHRoZSB2YWx1ZXMgcHJvdmlkZWQgYnkgT3BlblNTTCBjb21tYW5kIGxpbmUuICBUaGlzDQo+IGFw cHJvYWNoIHB1c2hlcyB0aGUgY29tcGxleGl0eSBvZiB1c2luZyB0aGUgT25lKktleSBzdHJ1Y3R1 cmVzIHRvIGp1c3QNCj4gdGhlICJhZHZhbmNlZCIgY2FzZSBvZiB3aGVuIGVuY3J5cHRpb24gaXMg bmVlZGVkIGFuZCwgYmVzaWRlcywgaXQNCj4gd291bGQgcHJpbWFyaWx5IGJlIGZvciB0aGUgTkMv UkMgc2VydmVyIHRvIGdlbmVyYXRlL3BhcnNlOyBjbGllbnRzDQo+IHdvdWxkIHJhcmVseSBlbmNy eXB0IGEga2V5IHRoZW1zZWx2ZXMsIHRoZSBvbmx5IGNhc2UgSSBjYW4gdGhpbmsgb2YNCj4gd2hl biB0aGV5IG1pZ2h0IHdvdWxkIGJlIGZvciB0aGUgUk1BIHdvcmtmbG93IHdlIGRpc2N1c3NlZCBh IGZldyB3ZWVrcw0KPiBiYWNrLg0KPiANCj4gDQo+IEtlbnQNCj4gDQo+IA0K From nobody Wed Sep 18 13:29:37 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F53120046 for ; Wed, 18 Sep 2019 13:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=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=jacobsuniversity.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 ilo0dwcYHvQR for ; Wed, 18 Sep 2019 13:29:33 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70044.outbound.protection.outlook.com [40.107.7.44]) (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 5D598120086 for ; Wed, 18 Sep 2019 13:29:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U6VFVd+VaOT1RFEkLesH28DbBqlAOxAgIfc8bq6wUohVUR9slgI5uS+GXESFYEDlYt8rpGDLjU6T6ZULOacDzNjmdOz+1NlcHVpUF5VHFdMmF2e5M1tRCHrp+3jl5v7Dhrthg0tFa49ddzLLxNp+G62vUAV6x6tUNp+TKwtL2FA7seDGKLeXDVZRdHhUpNGyij1yfW+QjjEunscU6XBoFgoBPSlgvHsnJzh3v3uy0WUPjcv1U453YedHFGvBcnQb0EJnIOaX28vya1od2lU6h10WNCeMRG9zw+yHb2S0VJZwURoCmlklwZvgTjF2jYC/TFZQ65jWg74NUjth1pY1Rg== 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=2/SqD8w1nZyOSMfFRHptFAcBNsZLecVPndgKy7AOrik=; b=VvG9A7pQ+RfMUBDDnA+PBk2Hyh/PMEh4oGDToGF2HmH4gI5w02yMxAuYLZBDXHLqTuwHYvn3WIKLJthIkP7A0jp76RInqGyM5S9fcKemvMLPyY7JFOM1ivs+VVzeRHOZUGlNGtVf0aHQKrAGGV/5HT5cGDo2KbRLNor6nnfMe4xw5vRKjAob2/jNqAisGYNtXcWBOG3qke35NXuS8R/9jENgAWOI16XlZ0p+jdRVL+n20HIoWj863G5cc8ImmKHgDJG++UIeylv4gI13bvzc49ufMb99Z4cjL1njgwjxGXcCSGNzIug/b5mLmluufAfX/XBBdGOVeWeBItx0bnnS5Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2/SqD8w1nZyOSMfFRHptFAcBNsZLecVPndgKy7AOrik=; b=fmGE9dCxQkZu6DflLj8ib7aWm9wTFbGjbTXZHKjjCIXoDR8kohc5p6vqT1kvBdiyRBfZczRzb8lQ7s7jLq/DmJ/zC14DcnKtNyl7SKHRSdUMKjZVTTC1f9zxNV4UptcRzZsx41MzkNj3T9kBRb+NetknrFZapp6mSpdIoq5bAwQ= Received: from VI1P190MB0686.EURP190.PROD.OUTLOOK.COM (10.186.159.71) by VI1P190MB0496.EURP190.PROD.OUTLOOK.COM (10.165.198.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.26; Wed, 18 Sep 2019 20:29:30 +0000 Received: from VI1P190MB0686.EURP190.PROD.OUTLOOK.COM ([fe80::d48a:ffa3:4fff:141e]) by VI1P190MB0686.EURP190.PROD.OUTLOOK.COM ([fe80::d48a:ffa3:4fff:141e%2]) with mapi id 15.20.2263.023; Wed, 18 Sep 2019 20:29:30 +0000 From: =?utf-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= To: Martin Bjorklund CC: "kent+ietf@watsen.net" , "netconf@ietf.org" , "rifaat.ietf@gmail.com" Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVblyUVhFlbERW30moo9Q8WhnpJqcx4tAA Date: Wed, 18 Sep 2019 20:29:30 +0000 Message-ID: <20190918202928.mqxdsuh3by3c4usl@anna.jacobs.jacobs-university.de> References: <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <0100016d4553e645-9c5796b8-15da-4a51-b820-5ecef6575eff-000000@email.amazonses.com> <20190918.220638.1382892184185166890.mbj@tail-f.com> In-Reply-To: <20190918.220638.1382892184185166890.mbj@tail-f.com> Reply-To: =?utf-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: PR0P264CA0206.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1f::26) To VI1P190MB0686.EURP190.PROD.OUTLOOK.COM (2603:10a6:800:12e::7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:638:709:5::7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 03559881-1ed6-4127-3c20-08d73c76e882 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:VI1P190MB0496; x-ms-traffictypediagnostic: VI1P190MB0496: x-ms-exchange-purlcount: 1 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01644DCF4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39850400004)(376002)(136003)(396003)(366004)(189003)(199004)(316002)(6506007)(102836004)(6916009)(8676002)(486006)(14454004)(7736002)(86362001)(6512007)(81156014)(66946007)(66556008)(54906003)(6306002)(4326008)(81166006)(8936002)(786003)(6116002)(256004)(6246003)(66476007)(66446008)(2906002)(85182001)(85202003)(64756008)(46003)(43066004)(446003)(478600001)(476003)(99286004)(52116002)(71190400001)(3450700001)(76176011)(5660300002)(11346002)(71200400001)(25786009)(229853002)(305945005)(6436002)(386003)(6486002)(186003)(1076003)(777600001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P190MB0496; H:VI1P190MB0686.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: NT3LtDDag7Hc+IK331BLWgJ1LfNDbLe40Z3mecApMmHjEt/EcmAfjZ3sz0n4iZPGDpB8gF+Am+AQ3h0HRHwvL51dn13yL3Wfk8LNsAfn0AgeTlfkpXs3v4QurBqNKlPV/mWFt1b/EKlKoDHr5qI5dM2Sz9kSTz3QZcq0s9t+N+HX7HJic65UH6KQ8AeS2KH4Wif833ZEK6AVEbo/aCps2cdjJcFSKysZymA3jiYiwP3X1JNyo5xnw04OQQgaiJIlNZkt/5oh3K1GvUjF3HpNNS+e5wY5x9watdLpnamJo/TU9jwEBUrCYW9atB+qpU3kKrPzB8dEkF0lQ+Cc5cVe7weZn+YYp9kv2VMRyJ1+Ur5HNKvswS0lMbmYj4nPglqkarcvApa9X50jcu+x8mi4dNaRlwhCDTp95efnnT7RoSg= Content-Type: text/plain; charset="utf-8" Content-ID: <2FA6F8B5A136E04A9C37AE00BCEBB891@EURP190.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 03559881-1ed6-4127-3c20-08d73c76e882 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2019 20:29:30.2792 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: bggfJbWsQJcqrhgaMY6o+jruC4bHCtJ9zmC66HaHW5Ro1SBm1Jm1/vv2NQCOpdHYaN/M9NLayRitgp6rXFbd+Ade+DnFIZMwm7oquIn9gRg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P190MB0496 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 20:29:36 -0000 T24gV2VkLCBTZXAgMTgsIDIwMTkgYXQgMTA6MDY6MzhQTSArMDIwMCwgTWFydGluIEJqb3JrbHVu ZCB3cm90ZToNCj4gS2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0PiB3cm90ZToNCj4g PiBbbW92aW5nIFJ1c3MgYW5kIFNlYW4gdG8gQkNDLCBwZXIgUmljaCdzIGFjdGlvbl0NCj4gPiAN Cj4gPiANCj4gPiANCj4gPiA+IE1pbm9yOiBEb2VzIHRoZSDigJxzdHJpbmfigJ0gaW4gdGhlIGRl c2NyaXB0aW9uIGFib3ZlIG1lYW4g4oCcQVNDSUkgc3RyaW5n4oCdDQo+ID4gPiBvciDigJxiaW5h cnkgc3RyaW5n4oCdLCBSRkMgNDI1MSBzZWVtaW5nbHkgdXNlcyBib3RoIGRlZmluaXRpb25zPw0K PiA+IA0KPiA+IEkgZG9uJ3Qga25vdywgYnV0IHRoaXMgaXMgdGhlIGxhbmd1YWdlIGZvdW5kIGZv ciB0aGUgImtleS1kYXRhIiBsZWFmDQo+ID4gaW4gUkZDIDczMTcgKGkuZS4sIHdlJ3ZlIGJlZW4g bGl2aW5nIHdpdGggdGhpcyBkZWZpbml0aW9uIGZvciBhd2hpbGUpDQo+IA0KPiBTbyB0aGUgZGVm aW5pdGlvbiBpczoNCj4gDQo+ICAgICAgICAgICAgICBsZWFmIGtleS1kYXRhIHsNCj4gICAgICAg ICAgICAgICAgdHlwZSBiaW5hcnk7DQo+ICAgICAgICAgICAgICAgIG1hbmRhdG9yeSB0cnVlOw0K PiAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbg0KPiAgICAgICAgICAgICAgICAgICJUaGUgYmlu YXJ5IHB1YmxpYyBrZXkgZGF0YSBmb3IgdGhpcyBTU0gga2V5LCBhcw0KPiAgICAgICAgICAgICAg ICAgICBzcGVjaWZpZWQgYnkgUkZDIDQyNTMsIFNlY3Rpb24gNi42LCBpLmUuOg0KPiANCj4gICAg ICAgICAgICAgICAgICAgICBzdHJpbmcgICAgY2VydGlmaWNhdGUgb3IgcHVibGljIGtleSBmb3Jt YXQNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaWRlbnRpZmllcg0KPiAgICAgICAg ICAgICAgICAgICAgIGJ5dGVbbl0gICBrZXkvY2VydGlmaWNhdGUgZGF0YS4iOw0KPiANCj4gVGhl IHRleHR1YWwgcmVwcmVzZW50YXRpb24gb2YgYSBiaW5hcnkgaW4gWUFORyBpcyBiYXNlNjQgZW5j b2RlZC4gIEFzDQo+IGl0IGhhcHBlbnMsIHRoaXMgaXMgZXhhY3RseSB0aGUgc2FtZSBhcyBPcGVu U1NIIHVzZXMgZm9yIGl0cyBrZXlzLiAgU28NCj4gdGhlIG9wZW4gc3NoIGtleSBjYW4gYmUgY29w eS9wYXN0ZWQgaW50byB0aGUgTkMvUkMgWE1ML0pTT04uDQo+DQoNCk15IHB1YmxpYyBzc2gga2V5 cyB1c3VhbGx5IHN0YXJ0IGxpa2UgdGhpczoNCg0KICBzc2gtcnNhIEFBQUEuLi4NCg0KTG9va2lu ZyBhdCBSRkMgNDI1MSwgaXQgc2VlbXMgdG8gbWUgdGhhdCAnc3RyaW5nJyBpcyBlbmNvZGVkIHdp dGggYQ0KbGVuZ3RoIHByZWZpeCwgZm9sbG93ZWQgYnkgbiBieXRlcyBvZiBrZXkgZGF0YS4gVGhp cyBtZWFucyB0aGUgc3RhcnQNCmluIGhleCB3b3VsZCBiZSBzb21ldGhpbmcgbGlrZSB0aGlzOg0K DQogIDAwIDAwIDAwIDA3IDczIDczIDY4IDJkIDcyIDczIDYxDQoNCklmIEkgYmFzZTY0IGVuY29k ZSB0aGlzLCBJIHdvbid0IGdldCB3aGF0IEkgcXVvdGVkIGFib3ZlLg0KDQovanMNCg0KLS0gDQpK dWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBn R21iSA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3 NTkgQnJlbWVuIHwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0 cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0K From nobody Wed Sep 18 13:53:21 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC84120858 for ; Wed, 18 Sep 2019 13:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 7_4TQnRTDS4i for ; Wed, 18 Sep 2019 13:53:17 -0700 (PDT) Received: from mailout.easydns.com (mailout.easydns.com [64.68.202.10]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D5C5120112 for ; Wed, 18 Sep 2019 13:53:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easydns.com (Postfix) with ESMTP id 7CE0DA014A; Wed, 18 Sep 2019 20:53:16 +0000 (UTC) Received: from mailout.easydns.com ([127.0.0.1]) by localhost (emo13-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x48P8GJgrIjQ; Wed, 18 Sep 2019 20:53:16 +0000 (UTC) Received: from hedeland.org (81-228-157-209-no289.tbcn.telia.com [81.228.157.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout.easydns.com (Postfix) with ESMTPSA id 36858A00C8; Wed, 18 Sep 2019 20:53:11 +0000 (UTC) Received: from pluto.hedeland.org (pluto.hedeland.org [10.1.1.5]) by tellus.hedeland.org (8.15.2/8.15.2) with ESMTPS id x8IKr9UV009547 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 18 Sep 2019 22:53:09 +0200 (CEST) (envelope-from per@hedeland.org) To: =?UTF-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= Cc: Martin Bjorklund , "netconf@ietf.org" , "rifaat.ietf@gmail.com" References: <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <0100016d4553e645-9c5796b8-15da-4a51-b820-5ecef6575eff-000000@email.amazonses.com> <20190918.220638.1382892184185166890.mbj@tail-f.com> <20190918202928.mqxdsuh3by3c4usl@anna.jacobs.jacobs-university.de> From: Per Hedeland Message-ID: <7ec3f404-9070-b0f7-7673-10093437121e@hedeland.org> Date: Wed, 18 Sep 2019 22:53:09 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190918202928.mqxdsuh3by3c4usl@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 20:53:20 -0000 On 2019-09-18 22:29, Schönwälder, Jürgen wrote: > On Wed, Sep 18, 2019 at 10:06:38PM +0200, Martin Bjorklund wrote: >> Kent Watsen wrote: >>> [moving Russ and Sean to BCC, per Rich's action] >>> >>> >>> >>>> Minor: Does the string in the description above mean ASCII string >>>> or binary string, RFC 4251 seemingly uses both definitions? >>> >>> I don't know, but this is the language found for the "key-data" leaf >>> in RFC 7317 (i.e., we've been living with this definition for awhile) >> >> So the definition is: >> >> leaf key-data { >> type binary; >> mandatory true; >> description >> "The binary public key data for this SSH key, as >> specified by RFC 4253, Section 6.6, i.e.: >> >> string certificate or public key format >> identifier >> byte[n] key/certificate data."; >> >> The textual representation of a binary in YANG is base64 encoded. As >> it happens, this is exactly the same as OpenSSH uses for its keys. So >> the open ssh key can be copy/pasted into the NC/RC XML/JSON. >> > > My public ssh keys usually start like this: > > ssh-rsa AAAA... > > Looking at RFC 4251, it seems to me that 'string' is encoded with a > length prefix, followed by n bytes of key data. This means the start > in hex would be something like this: > > 00 00 00 07 73 73 68 2d 72 73 61 > > If I base64 encode this, I won't get what I quoted above. Are you sure? I don't have a handy base64 encoder for "space-separated octets represented as hex numbers", but going in the other direction with the initial part of my public ssh key (ssh-rsa), using the Linux 'base64' command and converting the result to "space-separated octets represented as hex numbers" gives: $ echo AAAAB3NzaC1yc2EA | base64 -d | od -t x1 0000000 00 00 00 07 73 73 68 2d 72 73 61 00 Seems to agree with what you have. --Per From nobody Wed Sep 18 14:20:00 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083C31200B7 for ; Wed, 18 Sep 2019 14:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=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=jacobsuniversity.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 bFQ7pGzzZBHO for ; Wed, 18 Sep 2019 14:19:56 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140088.outbound.protection.outlook.com [40.107.14.88]) (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 0D80F120046 for ; Wed, 18 Sep 2019 14:19:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Rmyb9/NSujpI3dB2ctmmRn5rLiBhv5vFRra6BQktRgzNismpb+jH9jdNYWscVo1oCgU7I0+oTIYzcNjbOtFx4ucxScW/bnRYYlT+j9jNni6oQMytXXVhsbKPgxgpU6QdOgjzRKFwDmf7CqUctJlaT1sWOT/pM5Dbkjry7VZ884xtEz1OF47znvxJf+HkjlyZCl4JwoKVPlDSeBvLzWUlwaiw724vTsAyzSM4tDy7/sSHvP2EvMli92Km4oGYmszFaOf6izXb0e9A05JwFIlvKdgIoF2sqwL1/oMw/JoIjAr9ODLmvrKzUBFiur+fI40Dj27MEc0i42reupZwdY1lxA== 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=V6FUZoNTu/+wGbA6eEjQFYqj0saQlwQsccxcKXx+73w=; b=Z/4bMT3fhZSudp9uZu+/jrNnf1nnOsOdLa2NoO0yQREC+MKcMnkU2tFwpwD6Kg+dP2Dp+N548A7tiFcgvKjHRPSRgbfLwCdm20s2Em9+KL1hS+P/j9KBXSviM0YUYAizApI1XlgIQRWyM5BrqA7I8qfu8nc5JXrNRZWvCAkqEBE5jpNpoUp4zVuVGnrrWVY8GHvTTFEga6WRc2RE2u1NztumRbURO2Oq63xOZal65wmTo/EJbJbL6Fylpgl+azgYUXWzTl/7ap7qstUfyWOaD7nrjTZKzodwTUYvVGvLt1ELnyqYnrnR9P67X6psKkQ/FYFi4ogYHu6E1vZLFIhUIw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=V6FUZoNTu/+wGbA6eEjQFYqj0saQlwQsccxcKXx+73w=; b=LlfJRqwDNEM8fv3sYujmsciL/LGkFPHC0Pj6qkhl2+E4OyK8OYDTV+j8nn5W++VJYdDA3IM2UrYPJEOoBWP3Pi5046ubBPkbYQXbwxp0pyZ15gMvGC3HpVRttxaJOYbtCCj6eIZWICQSK/vb7F+gZjB328jxjEtiUxYPZ1IIJjA= Received: from VI1P190MB0686.EURP190.PROD.OUTLOOK.COM (10.186.159.71) by VI1P190MB0317.EURP190.PROD.OUTLOOK.COM (10.165.197.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.26; Wed, 18 Sep 2019 21:19:53 +0000 Received: from VI1P190MB0686.EURP190.PROD.OUTLOOK.COM ([fe80::d48a:ffa3:4fff:141e]) by VI1P190MB0686.EURP190.PROD.OUTLOOK.COM ([fe80::d48a:ffa3:4fff:141e%2]) with mapi id 15.20.2263.023; Wed, 18 Sep 2019 21:19:53 +0000 From: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= To: Per Hedeland CC: Martin Bjorklund , "netconf@ietf.org" , "rifaat.ietf@gmail.com" Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVblyUVhFlbERW30moo9Q8WhnpJqcx4tAAgAAGnoCAAAd2gA== Date: Wed, 18 Sep 2019 21:19:52 +0000 Message-ID: <20190918211951.eznefdficdfjk6xz@anna.jacobs.jacobs-university.de> References: <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <0100016d4553e645-9c5796b8-15da-4a51-b820-5ecef6575eff-000000@email.amazonses.com> <20190918.220638.1382892184185166890.mbj@tail-f.com> <20190918202928.mqxdsuh3by3c4usl@anna.jacobs.jacobs-university.de> <7ec3f404-9070-b0f7-7673-10093437121e@hedeland.org> In-Reply-To: <7ec3f404-9070-b0f7-7673-10093437121e@hedeland.org> Reply-To: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: PR0P264CA0154.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1b::22) To VI1P190MB0686.EURP190.PROD.OUTLOOK.COM (2603:10a6:800:12e::7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:638:709:5::7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2e8b1e34-ecef-4ae1-fa61-08d73c7df229 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:VI1P190MB0317; x-ms-traffictypediagnostic: VI1P190MB0317: x-ms-exchange-purlcount: 1 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1728; x-forefront-prvs: 01644DCF4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39850400004)(366004)(136003)(396003)(189003)(199004)(102836004)(6506007)(305945005)(6916009)(46003)(3450700001)(256004)(7736002)(8676002)(486006)(54906003)(14454004)(6512007)(66946007)(45776006)(6306002)(6116002)(316002)(6246003)(8936002)(66556008)(81156014)(64756008)(81166006)(66476007)(2906002)(86362001)(786003)(66446008)(386003)(476003)(52116002)(446003)(76176011)(478600001)(229853002)(43066004)(1076003)(5660300002)(66574012)(11346002)(99286004)(25786009)(6486002)(4326008)(71190400001)(186003)(53546011)(6436002)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P190MB0317; H:VI1P190MB0686.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: HLw7P13GhK0SM0OMXqsq4YxSdRfi6xiv1HoOgG/xalFVbXfqPA5VO35Bx1WVBz8Fd6kHuiNNKjq9QOYHIjhC9jWNrbeVk+EYnjIdfXL9HZwl8ya1e2wJZQHqz3Nk4M6RYt4GRBGrMnikK19w2nQZI0UAT4QGfk7WnMX1NUkH21vaVXMASDOvXJvEtg/uS3d8dmIyao/zP5fPb9LQjdV0er1bxy4xNqmofV5UCyXSRVoeYD8K6QWGfeubx/rfjHWs1dAJF9u7AiuAbbosO4IauaTpfKMGOhPQcxPfbianvYG4zfEn/Ae29DrYPg/RTkMNc0k0xrbs2GD9Ph8fVmQM0nMHSHETWk5eSZVQBTnPnjWrLCCKDY0T8tYqP+bxjx07d1F0oQ8RBYP7SDmw5fun2xUPLwvvMc1yjb0b7agePWc= Content-Type: text/plain; charset="iso-8859-1" Content-ID: <53EE2E20ACE48F44A351DE6AC93CE58A@EURP190.PROD.OUTLOOK.COM> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 2e8b1e34-ecef-4ae1-fa61-08d73c7df229 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Sep 2019 21:19:52.9261 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NOSAkX0vHDD/3oy8qJgy3jhvFiKY+av/i+ADUGyUPE0QMMEiBywUQccJiGA64Jz2SPPkgHo5lo5vImlW4e4mqjjXPAIJHz7Wq56k8+1Wk1I= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P190MB0317 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 21:19:59 -0000 On Wed, Sep 18, 2019 at 10:53:09PM +0200, Per Hedeland wrote: > On 2019-09-18 22:29, Sch=F6nw=E4lder, J=FCrgen wrote: > > On Wed, Sep 18, 2019 at 10:06:38PM +0200, Martin Bjorklund wrote: > > > Kent Watsen wrote: > > > > [moving Russ and Sean to BCC, per Rich's action] > > > >=20 > > > >=20 > > > >=20 > > > > > Minor: Does the =1Cstring=1D in the description above mean =1CASC= II string=1D > > > > > or =1Cbinary string=1D, RFC 4251 seemingly uses both definitions? > > > >=20 > > > > I don't know, but this is the language found for the "key-data" lea= f > > > > in RFC 7317 (i.e., we've been living with this definition for awhil= e) > > >=20 > > > So the definition is: > > >=20 > > > leaf key-data { > > > type binary; > > > mandatory true; > > > description > > > "The binary public key data for this SSH key, as > > > specified by RFC 4253, Section 6.6, i.e.: > > >=20 > > > string certificate or public key format > > > identifier > > > byte[n] key/certificate data."; > > >=20 > > > The textual representation of a binary in YANG is base64 encoded. As > > > it happens, this is exactly the same as OpenSSH uses for its keys. S= o > > > the open ssh key can be copy/pasted into the NC/RC XML/JSON. > > >=20 > >=20 > > My public ssh keys usually start like this: > >=20 > > ssh-rsa AAAA... > >=20 > > Looking at RFC 4251, it seems to me that 'string' is encoded with a > > length prefix, followed by n bytes of key data. This means the start > > in hex would be something like this: > >=20 > > 00 00 00 07 73 73 68 2d 72 73 61 > >=20 > > If I base64 encode this, I won't get what I quoted above. >=20 > Are you sure? I don't have a handy base64 encoder for "space-separated > octets represented as hex numbers", but going in the other direction > with the initial part of my public ssh key (ssh-rsa), using the Linux > 'base64' command and converting the result to "space-separated octets > represented as hex numbers" gives: >=20 > $ echo AAAAB3NzaC1yc2EA | base64 -d | od -t x1 > 0000000 00 00 00 07 73 73 68 2d 72 73 61 00 >=20 > Seems to agree with what you have. > Aha. So the 'ssh-rsa ' part in my key file needs to be stripped as it is actually redundant (but still its there in my file). In the RFC 7317 YANG model, this string seems to go into the 'algorithm' leaf. All good and usable. (I wonder what happens if the two algorithm names do not match, time to run some experiments on my ssh implementation...) /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Sep 18 14:54:52 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3124D1200FE for ; Wed, 18 Sep 2019 14:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 BGDx-bdSDmIm for ; Wed, 18 Sep 2019 14:54:49 -0700 (PDT) Received: from mailout.easydns.com (mailout.easydns.com [64.68.202.10]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32AB01200F1 for ; Wed, 18 Sep 2019 14:54:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easydns.com (Postfix) with ESMTP id 7BA4DA6238; Wed, 18 Sep 2019 21:54:48 +0000 (UTC) Received: from mailout.easydns.com ([127.0.0.1]) by localhost (emo13-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFqvgX5f2S9q; Wed, 18 Sep 2019 21:54:48 +0000 (UTC) Received: from hedeland.org (81-228-157-209-no289.tbcn.telia.com [81.228.157.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout.easydns.com (Postfix) with ESMTPSA id 248F3A6134; Wed, 18 Sep 2019 21:54:43 +0000 (UTC) Received: from pluto.hedeland.org (pluto.hedeland.org [10.1.1.5]) by tellus.hedeland.org (8.15.2/8.15.2) with ESMTPS id x8ILsf6g010353 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 18 Sep 2019 23:54:41 +0200 (CEST) (envelope-from per@hedeland.org) To: =?UTF-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= Cc: Martin Bjorklund , "netconf@ietf.org" , "rifaat.ietf@gmail.com" References: <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <0100016d4553e645-9c5796b8-15da-4a51-b820-5ecef6575eff-000000@email.amazonses.com> <20190918.220638.1382892184185166890.mbj@tail-f.com> <20190918202928.mqxdsuh3by3c4usl@anna.jacobs.jacobs-university.de> <7ec3f404-9070-b0f7-7673-10093437121e@hedeland.org> <20190918211951.eznefdficdfjk6xz@anna.jacobs.jacobs-university.de> From: Per Hedeland Message-ID: Date: Wed, 18 Sep 2019 23:54:41 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190918211951.eznefdficdfjk6xz@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 21:54:51 -0000 On 2019-09-18 23:19, Schönwälder, Jürgen wrote: > On Wed, Sep 18, 2019 at 10:53:09PM +0200, Per Hedeland wrote: >> On 2019-09-18 22:29, Schönwälder, Jürgen wrote: >>> On Wed, Sep 18, 2019 at 10:06:38PM +0200, Martin Bjorklund wrote: >>>> Kent Watsen wrote: >>>>> [moving Russ and Sean to BCC, per Rich's action] >>>>> >>>>> >>>>> >>>>>> Minor: Does the string in the description above mean ASCII string >>>>>> or binary string, RFC 4251 seemingly uses both definitions? >>>>> >>>>> I don't know, but this is the language found for the "key-data" leaf >>>>> in RFC 7317 (i.e., we've been living with this definition for awhile) >>>> >>>> So the definition is: >>>> >>>> leaf key-data { >>>> type binary; >>>> mandatory true; >>>> description >>>> "The binary public key data for this SSH key, as >>>> specified by RFC 4253, Section 6.6, i.e.: >>>> >>>> string certificate or public key format >>>> identifier >>>> byte[n] key/certificate data."; >>>> >>>> The textual representation of a binary in YANG is base64 encoded. As >>>> it happens, this is exactly the same as OpenSSH uses for its keys. So >>>> the open ssh key can be copy/pasted into the NC/RC XML/JSON. >>>> >>> >>> My public ssh keys usually start like this: >>> >>> ssh-rsa AAAA... >>> >>> Looking at RFC 4251, it seems to me that 'string' is encoded with a >>> length prefix, followed by n bytes of key data. This means the start >>> in hex would be something like this: >>> >>> 00 00 00 07 73 73 68 2d 72 73 61 >>> >>> If I base64 encode this, I won't get what I quoted above. >> >> Are you sure? I don't have a handy base64 encoder for "space-separated >> octets represented as hex numbers", but going in the other direction >> with the initial part of my public ssh key (ssh-rsa), using the Linux >> 'base64' command and converting the result to "space-separated octets >> represented as hex numbers" gives: >> >> $ echo AAAAB3NzaC1yc2EA | base64 -d | od -t x1 >> 0000000 00 00 00 07 73 73 68 2d 72 73 61 00 >> >> Seems to agree with what you have. >> > > Aha. So the 'ssh-rsa ' part in my key file needs to be stripped as it > is actually redundant (but still its there in my file). Right, it's in mine too of course - I stripped it without thinking, but realized after posting that this might be the reason that your encoding didn't match. (There is also normally a trailing @ after the actual key.) > In the RFC > 7317 YANG model, this string seems to go into the 'algorithm' > leaf. All good and usable. Yes - and hopefully a server implementing it will reject 'key-data' input with the leading 'ssh-rsa ' (or any other "key type", which all seem to include one or more '-') - the '-' is not a valid base64 character (nor is space, but base64 decoders are often "liberal" with whitespace). > (I wonder what happens if the two algorithm names do not match, time > to run some experiments on my ssh implementation...) Ditto for a server implementing RFC 7317... --Per From nobody Thu Sep 19 03:44:15 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250FA1201E4 for ; Thu, 19 Sep 2019 03:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=jwpSZqUw; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BQuAMv12 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 vLJ_STiKDG7G for ; Thu, 19 Sep 2019 03:44:11 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71766120164 for ; Thu, 19 Sep 2019 03:44:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10267; q=dns/txt; s=iport; t=1568889851; x=1570099451; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kjOL6zo1UcAFkKWBqqyZ/rOlswJ4qbgYSUEBgh8UCi8=; b=jwpSZqUwjb5Nrwxup1Tdj5CchTfJ9xyxyj5UQ84yUTHlVLpbeB3QfgP4 ibGcP6ygqzlqp5ys6f2Mk3V3tOYPstfbcXteaszYjpDwBlFT2KKOczGtt M33oILQ8qSAlzpcEUtwl10ZugGGGApw14VpQvDbwhPc/hsPZnh7Iy3Cog g=; IronPort-PHdr: =?us-ascii?q?9a23=3AZja/Th36FIYlG3bwsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKHt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQE1L6KOLtaQQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAACEWoNd/4ENJK1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwQBAQEBAQsBgRUvUANtViAECyoKh18DhFKGKYJciWa?= =?us-ascii?q?JMIRdgS6BJANUCQEBAQwBAS0CAQGEPwKDAyM0CQ4CAwkBAQQBAQECAQUEbYU?= =?us-ascii?q?tDIVKAQEBBBIbEwEBNwEPAgEIEAEEAQEvIREdCAIEAQ0FCBqDAYEdTQMdAQK?= =?us-ascii?q?jEQKBOIhhgiWCfQEBBYUODQuCFwmBNAGKRYEmHRiBQD+BV4JMPoIagiwMgy+?= =?us-ascii?q?CJpUBl0hBCoIikQiEG5R3hCyOFooZjngCBAIEBQIOAQEFgVI4gVhwFYMnUBA?= =?us-ascii?q?UgU6DcopTc4EpjioBgSIBAQ?= X-IronPort-AV: E=Sophos;i="5.64,523,1559520000"; d="scan'208,217";a="627981812" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Sep 2019 10:44:10 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x8JAiAjm016521 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 19 Sep 2019 10:44:10 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 19 Sep 2019 05:44:09 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 19 Sep 2019 05:44:08 -0500 Received: from NAM01-SN1-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.1473.3 via Frontend Transport; Thu, 19 Sep 2019 06:44:08 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IvbDbjylZlCc7JKo9vbMxSV8tXHe/zHPiO7evEhTA1pvufMSZMLfGSDAfVPz8OXDb01u+0yP9hyfJmjHUhAmRv23Co1NSeb1rJELi66wqsFfrrbsC8ULO1o5VIshe6RGnrenFo7+hI41thL5gJ2cB4wITPlU+XIxR76726tmDqk+T4vBuVGEJVTc0B5hFtMfp22lnZJ4A/L4YNNvJht83PHP8T4cQiztcljVMWuKomxfqO/Z0Ro8vuEKZHup/kQ1FDPSJ6ydDjWDinD/ZtegafUkgyV61lAW+Zy4QsKlLryU6wL74uK/M0fbIV7bjqnPeB+CgqArtjXY2J0wJd0kGA== 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=gu4KZ1aSu7rY2zZWZzbsLgB9NUxps+qqCJX6Q0o8ZHg=; b=Safw7qBeaTWVC5BntJRJF4E06sQ5FPJWiG8mHUBXki0OvxcyBerIPlzd/Fl5EUk9oUSLA4RsKrxOeyoxDluy62igXs2zR18WYKyILIMHtvo1UroUZq430KAF2ujZtVY1TRumvOvETy6C2frF76bFhsr+ACHg+AWy+4SWEN+B76H3MfjqLJV8LKk+G9U4ITreFPVeCtWVaqdJOUqhA8uBdv7+0SXxeYMmvgqvsxBk3lML3WnlinNkrPcGoc5n8l6OwoxGI/4YQ9y9X+4/c0OjCWKuBxeqRQ+qfScXKA2wg1eN2uN2QIsBtIfY92dx5rpBZwpeIcszhm8+6GvaiBr7Wg== 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=gu4KZ1aSu7rY2zZWZzbsLgB9NUxps+qqCJX6Q0o8ZHg=; b=BQuAMv12aIOY5GXaD7eswTeHzgEAolyevxDBd4tqXZdR9xqVz8fXC9wcCs4HVIg66a0cX1LRVCyEzL9xc4RTI38PDA3yqdB6A7dCkYfJ4HGrEp0Zzl/sxnrL2Dh8xAD6xA9y3T4KUnfXh90aa+FO6yOufbfR8E+W0aLinNwjTeU= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB4285.namprd11.prod.outlook.com (52.135.39.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.22; Thu, 19 Sep 2019 10:44:06 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6%7]) with mapi id 15.20.2263.023; Thu, 19 Sep 2019 10:44:06 +0000 From: "Rob Wilton (rwilton)" To: Kent Watsen , Juergen Schoenwaelder CC: "netconf@ietf.org" , Rifaat Shekh-Yusef Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxVu0aQE+n/K0iPwVgOy8FH/KcpQIdQgAVLFQCAARKfAIAATvkAgAABvxCAAC5vAIAAAggggAADhQCAAQHLcIAARlAAgAAAT1CAABr3gIAADR/AgAAZbYCAAAnmgIABJX6g Date: Thu, 19 Sep 2019 10:44:06 +0000 Message-ID: References: <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <20190918163657.4pxh5jddxgrir5oh@anna.jacobs.jacobs-university.de> <0100016d455c6145-844c669e-8f31-4203-a827-7368d33cdee4-000000@email.amazonses.com> In-Reply-To: <0100016d455c6145-844c669e-8f31-4203-a827-7368d33cdee4-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [173.38.220.61] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b906c076-c624-438d-fd1b-08d73cee4bb4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB4285; x-ms-traffictypediagnostic: MN2PR11MB4285: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 016572D96D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(136003)(366004)(376002)(346002)(199004)(189003)(54896002)(6306002)(55016002)(9686003)(4326008)(229853002)(6246003)(86362001)(3846002)(6116002)(790700001)(71190400001)(71200400001)(25786009)(256004)(14444005)(74316002)(2906002)(6436002)(66066001)(478600001)(7736002)(52536014)(14454004)(81166006)(81156014)(8936002)(316002)(99286004)(5660300002)(7696005)(76176011)(6506007)(53546011)(186003)(26005)(102836004)(66946007)(486006)(476003)(446003)(11346002)(8676002)(66476007)(66446008)(64756008)(66556008)(33656002)(54906003)(76116006)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4285; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: pJWSfMlieFEJWFlbTXVwM3whcrQ0Ge8wVm9+7ih3Gm2CxQfsdbHMPicsqKrC/ZYdL+Av3hrV7plahARWEl7epeYyaaMT1ztXi916L09drhNpAQ3hshPuVqfbYMubVxjF9TWR8dZtxCfXw+kD9hKkG4kgXjhSCf7ProNgmuhsxTafxieMUYwQeU0Hdye4y07S3LBy5Dow2lDv2hy1RM1eZzYV2gpeCmsCPkjKiRhkr2+8Daeznd5/GRk3pkqgSY4sZ/da+50WG4IuJU5svynGoXpJkjBvTtkOumzF+obWtRKEWrOQjds3HubEqlFprMkXPqx9MZhY6bZW93luuYtCBI7muiuXWGaEiwuuydNral0u+jmDZM0FAxlWbEdsDy3d4H9xp06NSfMb3T4qierNywUwid6fCVJwOoFzTlolN7A= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366E914816F6C3D9515A31DB5890MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b906c076-c624-438d-fd1b-08d73cee4bb4 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Sep 2019 10:44:06.4491 (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: 3IelxVQHcGPVIxNokgGSHgMkMPQKMhJpVeR1a7NyVNZegTt5grgle5aYeeXCjervzd6MWabNInTpoRcDjHuvDg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4285 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.27, xch-rcd-017.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2019 10:44:14 -0000 --_000_MN2PR11MB4366E914816F6C3D9515A31DB5890MN2PR11MB4366namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Kent Watsen Sent: 18 September 2019 18:12 To: Juergen Schoenwaelder Cc: Rob Wilton (rwilton) ; netconf@ietf.org; Rifaat Shek= h-Yusef Subject: Re: [netconf] crypto-types fallback strategy [moving Russ and Sean to BCC, per Rich's action] I tend to agree that sometimes less modules is more. For me, the problem is likely more that I am not entirely sure what the proper base types would be, which may depend on what exactly they are used for. I guess I wait until I see the description text... Okay, we'll keep just the one YANG module. [RW] Do you mean one module for all the identities of just the base identities? Thanks, Rob A bit separate from the above, but still in mind: - specify that all TLS public-keys are a DER-encoded SubjectPublicKeyInfo = structure - specify that all SSH public-keys are a "ssh-public-key-type" type (see b= elow) - specify that all encrypted symmetric keys are a DER-encoded OneSymmetric= Key structure - specify that all encrypted asymmetric keys are a DER-encoded OneAsymmetr= icKey structure I would check what is commonly used in existing configuration interfaces. We are not inventing the wheel here. And whatever we define better is usable with existing implementations and tools. These are the native types used by OpenSSL and OpenSSH, what more verificat= ion do we need? Possibly we could discuss supporting PEM, in addition to DER, but I'd image= that, if PEM is supported at all, the presentation layer (Web UI, CLI) wou= ld convert it to/from PEM as needed (i.e., the underlying model only needs = to support DER). The SSH implementations that I use have the binary key data rendered in ASCII. In fact, the whole key record is rendered in ASCII. I strongly suggest to use formats that are well established. This is the "key-data" leaf from RFC 7317. Are you saying that it should'v= e been different? Regardless, should this be a presentation layer issue? Kent // contributor --_000_MN2PR11MB4366E914816F6C3D9515A31DB5890MN2PR11MB4366namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

&nbs= p;

&nbs= p;

From: Kent Watsen <kent+ietf@watsen= .net>
Sent: 18 September 2019 18:12
To: Juergen Schoenwaelder <J.Schoenwaelder@jacobs-university.de&g= t;
Cc: Rob Wilton (rwilton) <rwilton@cisco.com>; netconf@ietf.org= ; Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Subject: Re: [netconf] crypto-types fallback strategy

 

[moving Russ and Sean t= o BCC, per Rich's action]

 

 



I tend to agree that so= metimes less modules is more. For me, the
problem is likely more that I am not entirely sure what the proper
base types would be, which may depend on what exactly they are used
for. I guess I wait until I see the description text...

 

 

Okay, we'll keep just t= he one YANG module.

[RW]

Do you mean one module for all the identities = of just the base identities?

 

Thanks,

Rob

 

 

 



A bit separate from the= above, but still in mind:

 - specify that all TLS public-keys are a DER-encoded SubjectPublicKey= Info structure
 - specify that all SSH public-keys are a "ssh-public-key-type&qu= ot; type (see below)
 - specify that all encrypted symmetric keys are a DER-encoded OneSymm= etricKey structure
 - specify that all encrypted asymmetric keys are a DER-encoded OneAsy= mmetricKey structure


I would check what is commonly used in existing configuration
interfaces. We are not inventing the wheel here. And whatever we
define better is usable with existing implementations and tools.=

 

These are the native ty= pes used by OpenSSL and OpenSSH, what more verification do we need?  &= nbsp;

 

Possibly we could discu= ss supporting PEM, in addition to DER, but I'd image that, if PEM is suppor= ted at all, the presentation layer (Web UI, CLI) would convert it to/from P= EM as needed (i.e., the underlying model only needs to support DER).

 



The SSH implementations= that I use have the binary key data rendered
in ASCII. In fact, the whole key record is rendered in ASCII. I
strongly suggest to use formats that are well established.

 

This is the "key-d= ata" leaf from RFC 7317.  Are you saying that it should've been d= ifferent?

 

Regardless, should this= be a presentation layer issue?

 

Kent // contributor

 

 

--_000_MN2PR11MB4366E914816F6C3D9515A31DB5890MN2PR11MB4366namp_-- From nobody Thu Sep 19 03:45:53 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C840120803 for ; Thu, 19 Sep 2019 03:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=DZr6pTi0; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=x6xBPD/f 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 a1mD_DDx-d5X for ; Thu, 19 Sep 2019 03:45:49 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D7AA1201E4 for ; Thu, 19 Sep 2019 03:45:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11356; q=dns/txt; s=iport; t=1568889949; x=1570099549; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6M69MRI9s1AqYtTRMTsAI0jf+8158c97gcbg6wFQpnI=; b=DZr6pTi0sHFvMqB7fv71zEmFz3rSnNx7TyyXt9A3MPmkKeRANWpKJd8U fxxlYq5tGyrYLcjshd9xj50RyaqlyHyE/M5Y4NbXot4LsdnFbipF2qQqM PAL3hqz8H3HUM1Pt4pLDB6l4dOUl4tegYAAmMjGKpQGagd7vRyNPWDy8B 4=; IronPort-PHdr: =?us-ascii?q?9a23=3A+pvqaxLIPEZ8Iup6LtmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvad2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFfkLfr2aCoSF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAAClW4Nd/5hdJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwUBAQEBCwGBFS9QA21WIAQLKgqEGINHA4RShimCXIlmiTC?= =?us-ascii?q?EXYEugSQDVAkBAQEMAQEtAgEBhD8CF4JsIzQJDgIDCQEBBAEBAQIBBQRthS0?= =?us-ascii?q?MhUoBAQEEEhEKEwEBNwEPAgEIEQQBASsCAgIfER0IAgQOBQgagwGBHU0DHQE?= =?us-ascii?q?CowoCgTiIYXOBMoJ9AQEFhQ0NC4IXCYE0AYpFgSUBHRiBQD+BV4JMPoIaghQ?= =?us-ascii?q?YgwkygiaPWIUpl0hBCoIikQiEG5kjmC+OeAIEAgQFAg4BAQWBUjiBWHAVgyd?= =?us-ascii?q?QEBSBToNyilNzgSmOKgGBIgEB?= X-IronPort-AV: E=Sophos;i="5.64,523,1559520000"; d="scan'208,217";a="334900552" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Sep 2019 10:45:48 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x8JAjmMD025083 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 19 Sep 2019 10:45:48 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 19 Sep 2019 05:45:47 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 19 Sep 2019 06:45:47 -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.1473.3 via Frontend Transport; Thu, 19 Sep 2019 06:45:47 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ID+XsmBD8Cw5Lw6Pb8WraRdGFEiZdFeiAAiy4P0BZE5s9lLzYbkOIUpevmJk1uW/mLJRN4zwD9pr8yRpy092JVFm/mMxdm0rAR7yyeXpDhQu9DETOJZmZDzngNlXhL11XLPxZcEna+FVnsL8nYtrUOZ0uc3HRJP4Y8NeHPMEROnAmttPbhjW5Y8VuG5GpxomTqKV3SjSMtyH+PU2R4JI6vy3ajG+U1cNWW2XR4YNzm6AFzEZDTSaUW9oJwn4LkhzujCV3KevczG9wgwF679KhwtluWxxGgqpeBV1FCnISw39HCdlxrIQE9W3c+BNREYnFXYydNQlI8hHajR5wTdO3A== 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=6M69MRI9s1AqYtTRMTsAI0jf+8158c97gcbg6wFQpnI=; b=frIdVWBZ0Ct/Gj1c7My3eLZ781R5VAIfhivhmvTjr7TdtqiSdIlkjoC0BlQQQcdH7hrTqwTn99nkiCsoatRhEW2pmht2XgraZgvr1nWF1YPRe1BGZTCTkTqrwxuUOUlDlIQf2kv6Eu4Q2wGs3w2rd5e94h334Vm3opQ1cxjmxXG8OAy1N7dSvSsR2MZ08llliC1lEpUpV36o5ms12HCQjbZcDfBYcI2k4YJ0fKjXKavVfViGCGWHvW1rpNUhGF1RcjRhFmrrOyqe0+5tW/GS+lpDnB2dVu0dnMDt5QU2JEMEkcQHpZ0XqlIL/DKOU51xIE/02flYIMzYzBq8XKFuEA== 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=6M69MRI9s1AqYtTRMTsAI0jf+8158c97gcbg6wFQpnI=; b=x6xBPD/fjF/5SU+o1ywHSdogA6h/4EjT5m3FWfG+Iyk3JD6HMHPo+6f/Ux1ZS0UFfcg4wVnI9zp9SXBtJv8Q8fxCI7OAcKA4BeYG06PHaKGLsH86GIWDeJc99rxxooZ/bEYXUmLnKuZQu4dDq87YKvnAgoEsjZr9q1nJntGjuy8= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB4285.namprd11.prod.outlook.com (52.135.39.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.22; Thu, 19 Sep 2019 10:45:46 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::6db3:f4c:467b:30f6%7]) with mapi id 15.20.2263.023; Thu, 19 Sep 2019 10:45:46 +0000 From: "Rob Wilton (rwilton)" To: Kent Watsen CC: "Salz, Rich" , "netconf@ietf.org" , Rifaat Shekh-Yusef Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxVu0aQE+n/K0iPwVgOy8FH/KcpQIdQgAVLFQCAARKfAIAATvkAgAABvxCAAC5vAIAAAggggAADhQCAAQHLcIAARlAAgAAAT1CAABr3gIAADR/AgAAgvYCAAShzcA== Date: Thu, 19 Sep 2019 10:45:46 +0000 Message-ID: References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@email.amazonses.com> <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <0100016d4553e645-9c5796b8-15da-4a51-b820-5ecef6575eff-000000@email.amazonses.com> In-Reply-To: <0100016d4553e645-9c5796b8-15da-4a51-b820-5ecef6575eff-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [173.38.220.61] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3296071f-ad01-4524-7418-08d73cee8737 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB4285; x-ms-traffictypediagnostic: MN2PR11MB4285: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 016572D96D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(136003)(366004)(376002)(346002)(199004)(189003)(51444003)(54896002)(6306002)(55016002)(9686003)(4326008)(229853002)(6246003)(86362001)(3846002)(6116002)(790700001)(71190400001)(71200400001)(25786009)(256004)(74316002)(2906002)(6436002)(66066001)(478600001)(7736002)(52536014)(14454004)(81166006)(81156014)(8936002)(316002)(99286004)(5660300002)(7696005)(76176011)(6506007)(53546011)(186003)(26005)(102836004)(66946007)(486006)(476003)(446003)(11346002)(8676002)(66476007)(66446008)(64756008)(66556008)(33656002)(54906003)(76116006); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4285; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: a4AYIav/9bQhRybjaNg8mw5cp274njfleL0DbJG92hbpXn61y6JCE4BgdbiMGZz5hiCwK/NQJn41/PryuYD3bltbpM8eWNpJkjCfbGkM9ywRt7FYLyP/Rqykhu48adt1xzATqlLJQswD9pSJUBOeo8LxRKV3C71phF7BN9MWVxD7t0vxgLJyV5Z7shE92sX/dvx+XbSA6B/3pA3xGN1Kup3wWiefK6CsAnEe6VE4MDHy9X3ODkXfGfX8W09kNjeSXv4LoTChk8i8lZJGnh/daFYe2nAAmSasJP/T8k+iKii+Np3/yT+5m2eOwuSSU5NLdXYWtbkx7020Yoc2Jhq7HuDHeBKgIDYaDRU0FL80cpgYK5Q7PtMUdG52mH+QJ7WjoLRyxSn2vHvZ3yzYZ8JN4voNb+96FikIjbzwtxMq49M= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB43660652914A50BE1E7978F4B5890MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3296071f-ad01-4524-7418-08d73cee8737 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Sep 2019 10:45:46.3436 (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: AZKaUOSCjlwN/ioCKDIiPthOyt/kTeEwZQSu+0Jn1R1w0r4IzRORuKv8tkevrywiH28v5e66xB0C49EUQfxs5A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4285 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.24, xch-rcd-014.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2019 10:45:52 -0000 --_000_MN2PR11MB43660652914A50BE1E7978F4B5890MN2PR11MB4366namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkZyb206IEtlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldD4NClNlbnQ6IDE4IFNl cHRlbWJlciAyMDE5IDE4OjAzDQpUbzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lz Y28uY29tPg0KQ2M6IFNhbHosIFJpY2ggPHJzYWx6QGFrYW1haS5jb20+OyBuZXRjb25mQGlldGYu b3JnOyBSaWZhYXQgU2hla2gtWXVzZWYgPHJpZmFhdC5pZXRmQGdtYWlsLmNvbT4NClN1YmplY3Q6 IFJlOiBbbmV0Y29uZl0gY3J5cHRvLXR5cGVzIGZhbGxiYWNrIHN0cmF0ZWd5DQoNClttb3Zpbmcg UnVzcyBhbmQgU2VhbiB0byBCQ0MsIHBlciBSaWNoJ3MgYWN0aW9uXQ0KDQoNCg0KTWlub3I6IERv ZXMgdGhlIOKAnHN0cmluZ+KAnSBpbiB0aGUgZGVzY3JpcHRpb24gYWJvdmUgbWVhbiDigJxBU0NJ SSBzdHJpbmfigJ0gb3Ig4oCcYmluYXJ5IHN0cmluZ+KAnSwgUkZDIDQyNTEgc2VlbWluZ2x5IHVz ZXMgYm90aCBkZWZpbml0aW9ucz8NCg0KSSBkb24ndCBrbm93LCBidXQgdGhpcyBpcyB0aGUgbGFu Z3VhZ2UgZm91bmQgZm9yIHRoZSAia2V5LWRhdGEiIGxlYWYgaW4gUkZDIDczMTcgKGkuZS4sIHdl J3ZlIGJlZW4gbGl2aW5nIHdpdGggdGhpcyBkZWZpbml0aW9uIGZvciBhd2hpbGUpDQoNCg0KDQpJ cyBwdXR0aW5nIHRoZSBlbmNyeXB0ZWQga2V5cyBpbnRvIERFUi1lbmNvZGVkIE9uZVN5bW1ldHJp Y0tleSBvYnZpb3VzbHkgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvPyAgQXJlIHRoZXJlIG90aGVyIGNo b2ljZXM/DQoNCg0KWWVzLCBpZiB0aGVyZSB3YXMgb25lIHRoaW5nIHRoYXQgY2FtZSBvdXQgb2Yg bXkgZGlzY3Vzc2lvbiB3aXRoIFJ1c3MgYW5kIFNlYW4gaXMgdGhhdCBPbmVTeW1tZXRyaWNLZXkg YW5kIE9uZUFzeW1tZXRyaWNLZXkgU0hPVUxEIGJlIHVzZWQgZm9yIGVuY3J5cHRpbmcga2V5IGRh dGEuICAgQW55dGhpbmcgZWxzZSB3b3VsZCBiZSBhIEJJRyBlZmZvcnQuDQpbUlddDQpPSy4NCg0K VGhlIHJlYWwgcXVlc3Rpb24gaXMgaWYgd2Ugc2hvdWxkIGFsc28gdXNlIHRoZSBPbmUqS2V5IHN0 cnVjdHVyZXMgZm9yIHVuZW5jcnlwdGVkIGtleXMsIHdoaWNoIGNvdWxkIGhlbHAgc29tZSB3YXlz LCBidXQgSSB0aGluayB0aGF0IGl0J3MgYmV0dGVyIHRvIHVzZSB0aGUgdmFsdWVzIHByb3ZpZGVk IGJ5IE9wZW5TU0wgY29tbWFuZCBsaW5lLiAgVGhpcyBhcHByb2FjaCBwdXNoZXMgdGhlIGNvbXBs ZXhpdHkgb2YgdXNpbmcgdGhlIE9uZSpLZXkgc3RydWN0dXJlcyB0byBqdXN0IHRoZSAiYWR2YW5j ZWQiIGNhc2Ugb2Ygd2hlbiBlbmNyeXB0aW9uIGlzIG5lZWRlZCBhbmQsIGJlc2lkZXMsIGl0IHdv dWxkIHByaW1hcmlseSBiZSBmb3IgdGhlIE5DL1JDIHNlcnZlciB0byBnZW5lcmF0ZS9wYXJzZTsg Y2xpZW50cyB3b3VsZCByYXJlbHkgZW5jcnlwdCBhIGtleSB0aGVtc2VsdmVzLCB0aGUgb25seSBj YXNlIEkgY2FuIHRoaW5rIG9mIHdoZW4gdGhleSBtaWdodCB3b3VsZCBiZSBmb3IgdGhlIFJNQSB3 b3JrZmxvdyB3ZSBkaXNjdXNzZWQgYSBmZXcgd2Vla3MgYmFjay4NCg0KW1JXXQ0KSSB3b3VsZCBz dWdnZXN0IG9ubHkgdXNpbmcgdGhlIE9uZSpLZXkgc3RydWN0dXJlcyBmb3IgdGhlIGVuY3J5cHRl ZCBrZXkgZGF0YS4NCg0KVGhhbmtzLA0KUm9iDQoNCg0KS2VudA0KDQoNCg== --_000_MN2PR11MB43660652914A50BE1E7978F4B5890MN2PR11MB4366namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIj4gS2VudCBXYXRzZW4gJmx0O2tlbnQmIzQzO2lldGZAd2F0c2VuLm5ldCZndDsNCjxicj4N CjxiPlNlbnQ6PC9iPiAxOCBTZXB0ZW1iZXIgMjAxOSAxODowMzxicj4NCjxiPlRvOjwvYj4gUm9i IFdpbHRvbiAocndpbHRvbikgJmx0O3J3aWx0b25AY2lzY28uY29tJmd0Ozxicj4NCjxiPkNjOjwv Yj4gU2FseiwgUmljaCAmbHQ7cnNhbHpAYWthbWFpLmNvbSZndDs7IG5ldGNvbmZAaWV0Zi5vcmc7 IFJpZmFhdCBTaGVraC1ZdXNlZiAmbHQ7cmlmYWF0LmlldGZAZ21haWwuY29tJmd0Ozxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW25ldGNvbmZdIGNyeXB0by10eXBlcyBmYWxsYmFjayBzdHJhdGVn eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5bbW92 aW5nIFJ1c3MgYW5kIFNlYW4gdG8gQkNDLCBwZXIgUmljaCdzIGFjdGlvbl08bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+TWlub3I6IERv ZXMgdGhlIOKAnHN0cmluZ+KAnSBpbiB0aGUgZGVzY3JpcHRpb24gYWJvdmUgbWVhbiDigJxBU0NJ SSBzdHJpbmfigJ0gb3Ig4oCcYmluYXJ5IHN0cmluZ+KAnSwgUkZDIDQyNTEgc2VlbWluZ2x5IHVz ZXMgYm90aCBkZWZpbml0aW9ucz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkkgZG9uJ3Qga25v dywgYnV0IHRoaXMgaXMgdGhlIGxhbmd1YWdlIGZvdW5kIGZvciB0aGUgJnF1b3Q7a2V5LWRhdGEm cXVvdDsgbGVhZiBpbiZuYnNwO1JGQyA3MzE3IChpLmUuLCB3ZSd2ZSBiZWVuIGxpdmluZyB3aXRo IHRoaXMgZGVmaW5pdGlvbiBmb3IgYXdoaWxlKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCklz IHB1dHRpbmcgdGhlIGVuY3J5cHRlZCBrZXlzIGludG8gREVSLWVuY29kZWQgT25lU3ltbWV0cmlj S2V5IG9idmlvdXNseSB0aGUgcmlnaHQgdGhpbmcgdG8gZG8/Jm5ic3A7IEFyZSB0aGVyZSBvdGhl ciBjaG9pY2VzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij5ZZXMsIGlmIHRoZXJlIHdhcyBvbmUgdGhpbmcgdGhhdCBjYW1lIG91dCBvZiBteSBk aXNjdXNzaW9uIHdpdGggUnVzcyBhbmQgU2VhbiBpcyB0aGF0IE9uZVN5bW1ldHJpY0tleSBhbmQg T25lQXN5bW1ldHJpY0tleSBTSE9VTEQgYmUgdXNlZCBmb3IgZW5jcnlwdGluZyBrZXkgZGF0YS4g Jm5ic3A7IEFueXRoaW5nIGVsc2Ugd291bGQgYmUgYSBCSUcgZWZmb3J0LiAmbmJzcDsmbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPltSV10gPG86cD48L286 cD48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPk9LLjwvaT48L2I+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRoZSByZWFs IHF1ZXN0aW9uIGlzIGlmIHdlIHNob3VsZCBhbHNvIHVzZSB0aGUgT25lKktleSBzdHJ1Y3R1cmVz IGZvciB1bmVuY3J5cHRlZCBrZXlzLCB3aGljaCBjb3VsZCBoZWxwIHNvbWUgd2F5cywgYnV0IEkg dGhpbmsgdGhhdCBpdCdzIGJldHRlciB0byB1c2UgdGhlIHZhbHVlcyBwcm92aWRlZCBieSBPcGVu U1NMIGNvbW1hbmQgbGluZS4gJm5ic3A7VGhpcyBhcHByb2FjaA0KIHB1c2hlcyB0aGUgY29tcGxl eGl0eSBvZiB1c2luZyB0aGUgT25lKktleSBzdHJ1Y3R1cmVzIHRvIGp1c3QgdGhlICZxdW90O2Fk dmFuY2VkJnF1b3Q7IGNhc2Ugb2Ygd2hlbiBlbmNyeXB0aW9uIGlzIG5lZWRlZCBhbmQsIGJlc2lk ZXMsIGl0IHdvdWxkIHByaW1hcmlseSBiZSBmb3IgdGhlIE5DL1JDIHNlcnZlciB0byBnZW5lcmF0 ZS9wYXJzZTsgY2xpZW50cyB3b3VsZCByYXJlbHkgZW5jcnlwdCBhIGtleSB0aGVtc2VsdmVzLCB0 aGUgb25seSBjYXNlIEkgY2FuIHRoaW5rDQogb2Ygd2hlbiB0aGV5IG1pZ2h0IHdvdWxkIGJlIGZv ciB0aGUgUk1BIHdvcmtmbG93IHdlIGRpc2N1c3NlZCBhIGZldyB3ZWVrcyBiYWNrLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxp PltSV10gPG86cD48L286cD48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxp Pkkgd291bGQgc3VnZ2VzdCBvbmx5IHVzaW5nIHRoZSBPbmUqS2V5IHN0cnVjdHVyZXMgZm9yIHRo ZSBlbmNyeXB0ZWQga2V5IGRhdGEuPG86cD48L286cD48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxpPjxvOnA+Jm5ic3A7PC9vOnA+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48aT5UaGFua3MsPGJyPg0KUm9iPG86cD48L286cD48L2k+PC9iPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5LZW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_MN2PR11MB43660652914A50BE1E7978F4B5890MN2PR11MB4366namp_-- From nobody Thu Sep 19 03:54:04 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3479B1200B7 for ; Thu, 19 Sep 2019 03:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 8dB_o_BfYGiL for ; Thu, 19 Sep 2019 03:54:00 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 950A012006D for ; Thu, 19 Sep 2019 03:54:00 -0700 (PDT) Received: from localhost (h-46-233.A165.priv.bahnhof.se [46.59.46.233]) by mail.tail-f.com (Postfix) with ESMTPSA id 84E391AE0115; Thu, 19 Sep 2019 12:53:58 +0200 (CEST) Date: Thu, 19 Sep 2019 12:53:58 +0200 (CEST) Message-Id: <20190919.125358.892950440538953535.mbj@tail-f.com> To: J.Schoenwaelder@jacobs-university.de Cc: per@hedeland.org, netconf@ietf.org, rifaat.ietf@gmail.com From: Martin Bjorklund In-Reply-To: <20190918211951.eznefdficdfjk6xz@anna.jacobs.jacobs-university.de> References: <20190918202928.mqxdsuh3by3c4usl@anna.jacobs.jacobs-university.de> <7ec3f404-9070-b0f7-7673-10093437121e@hedeland.org> <20190918211951.eznefdficdfjk6xz@anna.jacobs.jacobs-university.de> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2019 10:54:03 -0000 Sch=F6nw=E4lder, J=FCrgen wrote:= > On Wed, Sep 18, 2019 at 10:53:09PM +0200, Per Hedeland wrote: > > On 2019-09-18 22:29, Sch=F6nw=E4lder, J=FCrgen wrote: > > > On Wed, Sep 18, 2019 at 10:06:38PM +0200, Martin Bjorklund wrote:= > > > > Kent Watsen wrote: > > > > > [moving Russ and Sean to BCC, per Rich's action] > > > > > = > > > > > = > > > > > = > > > > > > Minor: Does the =1Cstring=1D in the description above mean = =1CASCII string=1D > > > > > > or =1Cbinary string=1D, RFC 4251 seemingly uses both defini= tions? > > > > > = > > > > > I don't know, but this is the language found for the "key-dat= a" leaf > > > > > in RFC 7317 (i.e., we've been living with this definition for= awhile) > > > > = > > > > So the definition is: > > > > = > > > > leaf key-data { > > > > type binary; > > > > mandatory true; > > > > description > > > > "The binary public key data for this SSH key,= as > > > > specified by RFC 4253, Section 6.6, i.e.: > > > > = > > > > string certificate or public key format= > > > > identifier > > > > byte[n] key/certificate data."; > > > > = > > > > The textual representation of a binary in YANG is base64 encode= d. As > > > > it happens, this is exactly the same as OpenSSH uses for its ke= ys. So > > > > the open ssh key can be copy/pasted into the NC/RC XML/JSON. > > > > = > > > = > > > My public ssh keys usually start like this: > > > = > > > ssh-rsa AAAA... > > > = > > > Looking at RFC 4251, it seems to me that 'string' is encoded with= a > > > length prefix, followed by n bytes of key data. This means the st= art > > > in hex would be something like this: > > > = > > > 00 00 00 07 73 73 68 2d 72 73 61 > > > = > > > If I base64 encode this, I won't get what I quoted above. > > = > > Are you sure? I don't have a handy base64 encoder for "space-separa= ted > > octets represented as hex numbers", but going in the other directio= n > > with the initial part of my public ssh key (ssh-rsa), using the Lin= ux > > 'base64' command and converting the result to "space-separated octe= ts > > represented as hex numbers" gives: > > = > > $ echo AAAAB3NzaC1yc2EA | base64 -d | od -t x1 > > 0000000 00 00 00 07 73 73 68 2d 72 73 61 00 > > = > > Seems to agree with what you have. > > > = > Aha. So the 'ssh-rsa ' part in my key file needs to be stripped as it= > is actually redundant (but still its there in my file). In the RFC > 7317 YANG model, this string seems to go into the 'algorithm' > leaf. All good and usable. Here's a link to the discussion we had some five years ago: https://mailarchive.ietf.org/arch/msg/netmod/I5it0TXGL4sL00529qZmz6jCCP= s /martin > = > (I wonder what happens if the two algorithm names do not match, time > to run some experiments on my ssh implementation...) > = > /js > = > -- = > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > Fax: +49 421 200 3103 > = From nobody Thu Sep 19 06:35:28 2019 Return-Path: <0100016d49bc0dd7-0c8a6dba-4f08-4d3e-b74d-44f11577624f-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70825120074 for ; Thu, 19 Sep 2019 06:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 zGiYp0MZnD7x for ; Thu, 19 Sep 2019 06:35:26 -0700 (PDT) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0355E120025 for ; Thu, 19 Sep 2019 06:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568900124; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=kSbJtx0TO92PsTmJyfn8RLqUWe2gXEn+YIXZn+IQ+Zs=; b=YgkU7D5MBCV8pLI/b6Z2y/adckR57QTBmyzAybbh4B3AJHvsVXIYXhk/b50SA4Vv CqEahvakGqGems3b9m3bkaxTDgDR4RjaLtU2eQrnYRldY00QlQQ4VPMD0TcCELQ1pHM 6YnVYLAvb4cvGq+YPlojE9vrF/p5ZXgruXIyV+jA= From: Kent Watsen Message-ID: <0100016d49bc0dd7-0c8a6dba-4f08-4d3e-b74d-44f11577624f-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1A230203-85E7-4CAF-9C4E-349266117B78" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 19 Sep 2019 13:35:24 +0000 In-Reply-To: Cc: Juergen Schoenwaelder , "netconf@ietf.org" , Rifaat Shekh-Yusef To: "Rob Wilton (rwilton)" References: <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <20190918163657.4pxh5jddxgrir5oh@anna.jacobs.jacobs-university.de> <0100016d455c6145-844c669e-8f31-4203-a827-7368d33cdee4-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.19-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2019 13:35:27 -0000 --Apple-Mail=_1A230203-85E7-4CAF-9C4E-349266117B78 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > [RW]=20 > Do you mean one module for all the identities of just the base = identities? Do you have a preference? Recent comments suggest that less is more. = If there were one module, we could limit it to just the identity = hierarchies needed for our immediate needs, leaving it as a future = effort to add (and deprecate/remove) identities at any point in the = hierarchy. Kent // contributor --Apple-Mail=_1A230203-85E7-4CAF-9C4E-349266117B78 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
[RW] 
Do you mean one module for all the identities = of just the base = identities?


Do you have a = preference?   Recent comments suggest that less is more.   If = there were one module, we could limit it to just the identity = hierarchies needed for our immediate needs, leaving it as a future = effort to add (and deprecate/remove) identities at any point in the = hierarchy.

Kent // = contributor

= --Apple-Mail=_1A230203-85E7-4CAF-9C4E-349266117B78-- From nobody Thu Sep 19 06:36:31 2019 Return-Path: <0100016d49bd04c9-b588e39a-62a4-44db-9a2d-b69ee358f4a4-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4CB4120058 for ; Thu, 19 Sep 2019 06:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 8YnAdVyGes5y for ; Thu, 19 Sep 2019 06:36:28 -0700 (PDT) Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABF3A120025 for ; Thu, 19 Sep 2019 06:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568900187; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=B2chuwao8ROmc+BAZHktOt7ts9wkg3rJhj+K4kh1jac=; b=iUMHsMzo7THGePnQJjPdGIiKSi3jXyvJnt5MKjDto/epQ0syRfclK1tyyneaGJ2y HKrqRA+O9KOx+YB0K41kzp5xY5z8R3Pel97k0T3tqPFzB7yAg8rmP59UBos0Hj4VlNq Xcezex097KnALXZAIEYxWudpH+3KSb7nUHWcR/7E= From: Kent Watsen Message-ID: <0100016d49bd04c9-b588e39a-62a4-44db-9a2d-b69ee358f4a4-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B5D4F27F-312A-4B78-B6BB-A9383A38EC1B" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 19 Sep 2019 13:36:27 +0000 In-Reply-To: Cc: "Salz, Rich" , "netconf@ietf.org" , Rifaat Shekh-Yusef To: "Rob Wilton (rwilton)" References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@email.amazonses.com> <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <0100016d4553e645-9c5796b8-15da-4a51-b820-5ecef6575eff-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.19-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2019 13:36:30 -0000 --Apple-Mail=_B5D4F27F-312A-4B78-B6BB-A9383A38EC1B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > [RW] > I would suggest only using the One*Key structures for the encrypted = key data. Agreed. Okay. Kent // contributor --Apple-Mail=_B5D4F27F-312A-4B78-B6BB-A9383A38EC1B Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

[RW]

I would suggest only using the One*Key structures for the encrypted key data.


Agreed.  Okay.


Kent // contributor

--Apple-Mail=_B5D4F27F-312A-4B78-B6BB-A9383A38EC1B-- From nobody Thu Sep 19 07:04:11 2019 Return-Path: <0100016d49d65155-25a0cf04-fafc-44b0-a563-c10f958dfa73-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDF0120108 for ; Thu, 19 Sep 2019 07:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 l6ZGL5fHgaeh for ; Thu, 19 Sep 2019 07:04:07 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E90C6120047 for ; Thu, 19 Sep 2019 07:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568901845; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=gaTL3oIR5o+2n60bsv60wBAjuXMQYqLerN31JcbzUxg=; b=Ol+44tU0Mn95ZLGu2sJsVX+BKslsIxmPHaD48PrG3SLNfahgkho/y5FwX3W588Mm YsDEaulwKVwAJ7pZLKtfN3dBTGTPtwG0FJdWWt9vLX8fOB/8rrSRuKBHkWlEFy+MBHT dd1FQg/jGTJcD4uH/a0k0GX4Er4cVEMQ2iVCOWMU= From: Kent Watsen Message-ID: <0100016d49d65155-25a0cf04-fafc-44b0-a563-c10f958dfa73-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BEEBDD30-E869-4502-AC28-050755159537" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 19 Sep 2019 14:04:05 +0000 In-Reply-To: <20190919.125358.892950440538953535.mbj@tail-f.com> Cc: Juergen Schoenwaelder , "netconf@ietf.org" , rifaat.ietf@gmail.com To: Martin Bjorklund References: <20190918202928.mqxdsuh3by3c4usl@anna.jacobs.jacobs-university.de> <7ec3f404-9070-b0f7-7673-10093437121e@hedeland.org> <20190918211951.eznefdficdfjk6xz@anna.jacobs.jacobs-university.de> <20190919.125358.892950440538953535.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.19-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2019 14:04:10 -0000 --Apple-Mail=_BEEBDD30-E869-4502-AC28-050755159537 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Sep 19, 2019, at 6:53 AM, Martin Bjorklund wrote: >=20 > Here's a link to the discussion we had some five years ago: >=20 > = https://mailarchive.ietf.org/arch/msg/netmod/I5it0TXGL4sL00529qZmz6jCCPs = = So apropos. Yeah for email archives! I noticed a discrepancy between the file format described in RFC 4716 = and the one `ssh-keygen` produces by default. In order to get the = standard public key file format, I had to use the command `ssh-keygen -e = -m RFC4716 -f `. We can define a type for this: typedef rfc4716-string { type string; description "A string containing the contents of the file described by = RFC 4716"; reference "RFC 4716: The Secure Shell (SSH) Public Key File Format"; } And perhaps another for PEMs: typedef pem-string { type string; description "A string containing the PEM encoding of an ASN.1 = structure."; reference "TBD"; } And then put a union into the "public-key" leaf: leaf public-key { nacm:default-deny-write; type union { type rfc4716-string; type pem-string; type binary; } mandatory true; description "The value of the public key. The interpretation of this value = is defined by 'algorithm'. For example, algorithms using SSH specific identities always use 'rfc4716-string', where = algorithms using X.509 specific identities encode a SubjectPublicKeyInfo (RFC 5280) that may be a 'binary' (for DER encodings) or=20 'pem-string' (for PEM encodings)."; reference "RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) = Profile"; } And similar for the private key? AFAICT, that all are effectively strings doesn't matter. = Implementations can try to parse the options until something works. Thoughts? Kent // contributor --Apple-Mail=_BEEBDD30-E869-4502-AC28-050755159537 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Sep 19, 2019, at 6:53 AM, Martin Bjorklund <mbj@tail-f.com> = wrote:

Here's a link = to the discussion we had some five years ago:

https://mailarchive.ietf.org/arch/msg/netmod/I5it0TXGL4sL00529q= Zmz6jCCPs


So apropos.    Yeah for email = archives!

I noticed a discrepancy = between the file format described in RFC 4716 and the one `ssh-keygen` = produces by default.  In order to get the standard public key file = format, I had to use the command `ssh-keygen -e -m RFC4716 -f = <public-or-private-key-file>`.

We can define a type for = this:

typedef = rfc4716-string {
    type = string;
    = description
      "A string = containing the contents of the file described by RFC = 4716";
    reference
=       "RFC 4716: The Secure Shell (SSH) = Public Key File Format";
= }

And = perhaps another for PEMs:

typedef pem-string {
=     type string;
  =   description
      "A string = containing the PEM encoding of an ASN.1 structure.";
=     reference
  =     "TBD";
}

And then put a union into the = "public-key" leaf:

    leaf public-key {
      nacm:default-deny-write;
      type union {
      =     type rfc4716-string;
      =     type pem-string;
  =         type binary;
  =     }
    =   mandatory true;
    =   description
      =   "The value of the public key.  The interpretation = of this value is
         defined = by 'algorithm'.  For example, algorithms using SSH
         specific identities always = use 'rfc4716-string', where algorithms
  =        using X.509 specific identities encode a = SubjectPublicKeyInfo
        =  (RFC 5280) that may be a 'binary' (for DER encodings) = or 
        =  'pem-string' (for PEM encodings).";
  =     reference
      =   "RFC 5280: Internet X.509 Public Key = Infrastructure Certificate
      =                     =   and Certificate Revocation List (CRL) Profile";
    }


And similar for the = private key?

AFAICT, that all are effectively strings doesn't matter. =  Implementations can try to parse the options until something = works.


Thoughts?

Kent // contributor





= --Apple-Mail=_BEEBDD30-E869-4502-AC28-050755159537-- From nobody Mon Sep 23 00:53:04 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADF9120120 for ; Mon, 23 Sep 2019 00:53:02 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 yzcDpptyeIVO for ; Mon, 23 Sep 2019 00:53:01 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DDEB812011C for ; Mon, 23 Sep 2019 00:53:00 -0700 (PDT) Received: from localhost (h-46-233.A165.priv.bahnhof.se [46.59.46.233]) by mail.tail-f.com (Postfix) with ESMTPSA id 060791AE0115; Mon, 23 Sep 2019 09:52:59 +0200 (CEST) Date: Mon, 23 Sep 2019 09:52:58 +0200 (CEST) Message-Id: <20190923.095258.855042931469293827.mbj@tail-f.com> To: kent@watsen.net Cc: J.Schoenwaelder@jacobs-university.de, netconf@ietf.org, rifaat.ietf@gmail.com From: Martin Bjorklund In-Reply-To: <0100016d49d65155-25a0cf04-fafc-44b0-a563-c10f958dfa73-000000@email.amazonses.com> References: <20190918211951.eznefdficdfjk6xz@anna.jacobs.jacobs-university.de> <20190919.125358.892950440538953535.mbj@tail-f.com> <0100016d49d65155-25a0cf04-fafc-44b0-a563-c10f958dfa73-000000@email.amazonses.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 07:53:03 -0000 Hi, Kent Watsen wrote: > > > > On Sep 19, 2019, at 6:53 AM, Martin Bjorklund wrote: > > > > Here's a link to the discussion we had some five years ago: > > > > https://mailarchive.ietf.org/arch/msg/netmod/I5it0TXGL4sL00529qZmz6jCCPs > > > > > So apropos. Yeah for email archives! > > I noticed a discrepancy between the file format described in RFC 4716 > and the one `ssh-keygen` produces by default. In order to get the > standard public key file format, I had to use the command `ssh-keygen > -e -m RFC4716 -f `. > > We can define a type for this: > > typedef rfc4716-string { > type string; > description > "A string containing the contents of the file described by RFC > 4716"; > reference > "RFC 4716: The Secure Shell (SSH) Public Key File Format"; > } > > And perhaps another for PEMs: > > typedef pem-string { > type string; > description > "A string containing the PEM encoding of an ASN.1 structure."; > reference > "TBD"; > } > > And then put a union into the "public-key" leaf: > > leaf public-key { > nacm:default-deny-write; > type union { > type rfc4716-string; > type pem-string; > type binary; > } > mandatory true; > description > "The value of the public key. The interpretation of this value is > defined by 'algorithm'. For example, algorithms using SSH > specific identities always use 'rfc4716-string', where algorithms > using X.509 specific identities encode a SubjectPublicKeyInfo > (RFC 5280) that may be a 'binary' (for DER encodings) or > 'pem-string' (for PEM encodings)."; > reference > "RFC 5280: Internet X.509 Public Key Infrastructure Certificate > and Certificate Revocation List (CRL) Profile"; > } > > > And similar for the private key? > > AFAICT, that all are effectively strings doesn't matter. > Implementations can try to parse the options until something works. > > > Thoughts? What's wrong with the definition we use in RFC 7317? /martin From nobody Mon Sep 23 06:22:07 2019 Return-Path: <0100016d5e49265c-c375f668-0c9b-4d9e-9c9b-935aee915254-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F8712084C for ; Mon, 23 Sep 2019 06:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 NJC3Xqdxb8Cn for ; Mon, 23 Sep 2019 06:21:57 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D91120849 for ; Mon, 23 Sep 2019 06:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1569244915; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=3GotfzC4J59prOUoOZrgCzsjbhLS9G3fo8Bhc89Wd6w=; b=VEkr4fsevtHjZ+myJk5hh9bduPmlxMEYqmRaiLya1UbowPKvaAGhq3BqOHx4P4gW zswQkOuyXp9gIvnl4Q3C6Go4W3Y5P6nLd1eUJrWh21rWU9X+5uKlzPCLkkjTR9ezD59 NZa7A5H5+bSqUlElzrfdRK6bOCk0us4c3af+OKRo= From: Kent Watsen Message-ID: <0100016d5e49265c-c375f668-0c9b-4d9e-9c9b-935aee915254-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0E4EA67C-9F48-4640-A23F-D3D1A878666E" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 23 Sep 2019 13:21:55 +0000 In-Reply-To: <20190923.095258.855042931469293827.mbj@tail-f.com> Cc: Juergen Schoenwaelder , "netconf@ietf.org" , rifaat.ietf@gmail.com To: Martin Bjorklund References: <20190918211951.eznefdficdfjk6xz@anna.jacobs.jacobs-university.de> <20190919.125358.892950440538953535.mbj@tail-f.com> <0100016d49d65155-25a0cf04-fafc-44b0-a563-c10f958dfa73-000000@email.amazonses.com> <20190923.095258.855042931469293827.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.23-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 13:22:05 -0000 --Apple-Mail=_0E4EA67C-9F48-4640-A23F-D3D1A878666E Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > What's wrong with the definition we use in RFC 7317? Because Juergen said he wanted to copy/patse the file contents? Kent --Apple-Mail=_0E4EA67C-9F48-4640-A23F-D3D1A878666E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

What's wrong with the definition we use in RFC 7317?


Because Juergen said he wanted to copy/patse the file contents?

Kent

--Apple-Mail=_0E4EA67C-9F48-4640-A23F-D3D1A878666E-- From nobody Mon Sep 23 06:34:58 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048AC12081F for ; Mon, 23 Sep 2019 06:34:57 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 5frF5ed_KqFy for ; Mon, 23 Sep 2019 06:34:55 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA931200CD for ; Mon, 23 Sep 2019 06:34:55 -0700 (PDT) Received: from localhost (h-46-233.A165.priv.bahnhof.se [46.59.46.233]) by mail.tail-f.com (Postfix) with ESMTPSA id C87F21AE0115; Mon, 23 Sep 2019 15:34:53 +0200 (CEST) Date: Mon, 23 Sep 2019 15:34:53 +0200 (CEST) Message-Id: <20190923.153453.1773368477086878954.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: J.Schoenwaelder@jacobs-university.de, netconf@ietf.org, rifaat.ietf@gmail.com From: Martin Bjorklund In-Reply-To: <0100016d5e49265c-c375f668-0c9b-4d9e-9c9b-935aee915254-000000@email.amazonses.com> References: <0100016d49d65155-25a0cf04-fafc-44b0-a563-c10f958dfa73-000000@email.amazonses.com> <20190923.095258.855042931469293827.mbj@tail-f.com> <0100016d5e49265c-c375f668-0c9b-4d9e-9c9b-935aee915254-000000@email.amazonses.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 13:34:57 -0000 Kent Watsen wrote: > > > > What's wrong with the definition we use in RFC 7317? > > > Because Juergen said he wanted to copy/patse the file contents? He can; by copying the key-part (b64 encoded). /martin From nobody Mon Sep 23 06:50:39 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18341200E5 for ; Mon, 23 Sep 2019 06:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.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 qngmLlYkVhvc for ; Mon, 23 Sep 2019 06:50:35 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140041.outbound.protection.outlook.com [40.107.14.41]) (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 CBEAA1200C1 for ; Mon, 23 Sep 2019 06:50:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V6zDcHE9m/soCXRFT97SJn+FzK4+Oys61aTCet/L9soNADEOCg2ljRrY8i353AjOcMstNRMGXuC6iTSWPcHjb3Ydc4zIBTmuokoWLuuODNPuY7FxQgSyAM35Pc7vn3Yj2ME16mtfuzFu4dateo1iMItJiyTlI6Y3/OohD/v8uygM3Gm/qEbWs0hgT/gOwX3pQtNP4tDIjxjbm047KemMBBpQpx473BJ8CLreX3JKJTow4YGg2vQh0HLJrNujxiujWpzywuYSReC5FEtP6g+LOaFL0kkMIh/fp0oWEU8sE5TrKMltD+49uHSOBIfrdrNDUTzhklMRw+SSbh6gNETQog== 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=8PJiyJfrwmwKT9UcVuEvHAPQmUVY6pBNGOzn3QSzNZo=; b=mcG3jobSiXqlJDQpi3BOiwUmBrYpdyfWZCMAAh3vmwGc19slyrKtWWX13q0vZ59x9pN8owkrLCXOclR1IGVYEWrBhKy3dxuyx06+dWtuF2vgSJ4praHHDjWimj1naGG00y0w3jELLDo2s8v0QUh2MGHkgCkxV9gazOjJ6gimV9TF3YplgbnA/JcD26lfRNQX2uhR2tiOuXlPgjzuaPEtTzedKKhtD+ulx4su3uIvQ8xFM66UztHnxl/c/NUIesMQjHGXNz1kZ6+3Fx7Q4mgL3li9gFhhGpBxXi2CLgXMhh10aMk1wWYm/rTIh2GJicGnA2WW7XcgIJJdzfc+Pd6Mew== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8PJiyJfrwmwKT9UcVuEvHAPQmUVY6pBNGOzn3QSzNZo=; b=P5Rm//3zBtyVEKl20hn/5XakFMVwMh6M7h6g/vhpM1OMP4jzi05Qktwvzq8T6kab1abIloyRTd4tRjCo5YJcI9vah+JHIldNoXX12s0VBtVvNqHq0sdpv7IL9GSHW7GPRTu0BSLAgynZPttaoK+XFWp06cEsQaLuRbp59vqmRsI= Received: from VI1P190MB0686.EURP190.PROD.OUTLOOK.COM (10.186.159.71) by VI1P190MB0047.EURP190.PROD.OUTLOOK.COM (10.172.15.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.23; Mon, 23 Sep 2019 13:50:32 +0000 Received: from VI1P190MB0686.EURP190.PROD.OUTLOOK.COM ([fe80::e061:7f73:a47f:2ad4]) by VI1P190MB0686.EURP190.PROD.OUTLOOK.COM ([fe80::e061:7f73:a47f:2ad4%2]) with mapi id 15.20.2284.023; Mon, 23 Sep 2019 13:50:32 +0000 From: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= To: Martin Bjorklund CC: "kent+ietf@watsen.net" , "netconf@ietf.org" , "rifaat.ietf@gmail.com" Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVchOxZtcKPgjwnUCrL/6qf5piyKc5R5OA Date: Mon, 23 Sep 2019 13:50:32 +0000 Message-ID: <20190923135031.3xhnmr6yfx2slxhw@anna.jacobs.jacobs-university.de> References: <0100016d49d65155-25a0cf04-fafc-44b0-a563-c10f958dfa73-000000@email.amazonses.com> <20190923.095258.855042931469293827.mbj@tail-f.com> <0100016d5e49265c-c375f668-0c9b-4d9e-9c9b-935aee915254-000000@email.amazonses.com> <20190923.153453.1773368477086878954.mbj@tail-f.com> In-Reply-To: <20190923.153453.1773368477086878954.mbj@tail-f.com> Reply-To: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: AM4PR05CA0036.eurprd05.prod.outlook.com (2603:10a6:205::49) To VI1P190MB0686.EURP190.PROD.OUTLOOK.COM (2603:10a6:800:12e::7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:638:709:5::7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ff6754b6-7f51-45ac-a0d9-08d7402d0060 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600167)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:VI1P190MB0047; x-ms-traffictypediagnostic: VI1P190MB0047: x-ms-exchange-purlcount: 1 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0169092318 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(376002)(396003)(366004)(39850400004)(189003)(199004)(86362001)(446003)(476003)(6512007)(6306002)(99286004)(6486002)(11346002)(486006)(6246003)(25786009)(256004)(52116002)(76176011)(8676002)(81156014)(305945005)(6916009)(71200400001)(6506007)(102836004)(81166006)(7736002)(8936002)(386003)(71190400001)(46003)(4326008)(6436002)(186003)(3450700001)(6116002)(5660300002)(43066004)(4744005)(66946007)(66556008)(478600001)(64756008)(66446008)(2906002)(66476007)(14454004)(45776006)(54906003)(786003)(316002)(229853002)(1076003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P190MB0047; H:VI1P190MB0686.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: MwDQZl7fRaAQzgPsb5TVVvH0Fj+KPNwrVvMWhqzJSneQ9YZTNeLFvWnW3akqM84S0q2jZMobwYMYm+FayzFoM2zO/xH/8yov1+1ukVhILwgeLvXqRJ3Cp3/RY7EvT/eB59lq7VPYizk6Y80N/FNvIChLqFeOITVAKB/K7kA1quTTzSDMGj7PdLAB3SrdxhYpg3odVr24+/0aujuQ71QFBAxDDySIB3QJMlx3fuGjiNQCzSYYgxG8HLt0EbIFcZrN27mxKI+ADTyL6cnn3ayF5AZjYPGa5jkcKJ5Kqj7v2lP5eEn7x6MFreLpJQbt1cDFI1jM5frvjCnHeInZ/pil5eEmmYOuVh5jXlmoS2sijFCnj98vgDsyKLqYpbny3PhzC8HPet1PKb5I0h8W8spyESSnsycKgKGixnk4LZTp5TA= Content-Type: text/plain; charset="iso-8859-1" Content-ID: <324EF7FA4A7CAB4D8526D104C569BF4F@EURP190.PROD.OUTLOOK.COM> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: ff6754b6-7f51-45ac-a0d9-08d7402d0060 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2019 13:50:32.1534 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: GGZ+gsDYkC8jeOHNdOpePMPQttnkKA8erb6eW+yRTs3DR3xKsTZTV7nxllG+Mj01/apILLHz+4BOIFuQScWq9R5zDwCZRRXre0RNVcRFXLk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P190MB0047 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 13:50:38 -0000 On Mon, Sep 23, 2019 at 03:34:53PM +0200, Martin Bjorklund wrote: > Kent Watsen wrote: > >=20 > >=20 > > > What's wrong with the definition we use in RFC 7317? > >=20 > >=20 > > Because Juergen said he wanted to copy/patse the file contents? >=20 > He can; by copying the key-part (b64 encoded). > Yes. It took me a bit of time to figure this out from the description statement. An explanation of example might have helped me... /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Sep 23 15:26:36 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2709F120836 for ; Mon, 23 Sep 2019 15:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 soG7ON_2qVky for ; Mon, 23 Sep 2019 15:26:23 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02on0623.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe05::623]) (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 C88F612004C for ; Mon, 23 Sep 2019 15:26:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L8g8lRkjKaeTCu1ce4dDseYcgiE+m8d9BtE+wCSLAP7f/m9nMlHvtDUES73HNAgVS/PsAMbwdSy2cONh6vH6A1cbM4PX5fDv9LUaddCNteKSDY38ekrgmZGMCx5RADk6TqKmslV10Ci2HS0ZkVU6IMBfMGMw+vi+FW5hzuLwC8zmPFGRhPDTFlEVMlHa2/VTG+fWlC4WQzF6FSnutahvYx1Pd2tMfHoEGqPu1tjnUNEC4yKNODnt6Wv28mC/ItCWkIaH0aSh3HEGRzSufDWdbpfzUR+GX25uvHyMd7X2TFbwn5ocrnC94ZkjCJQfNVbX7MfHBHSKL3MQkV3vPnYWfQ== 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=VuXjQ4S4URrZ7SXZzLdhbeNl600P5Bys8DBWoPnroGo=; b=JopFGbrWYNiNu3XH0tuPLuT3ErSoSg77kaB6R736R6yFe7uemilYSZf55uJDwqI+mM5ufCzxD2mQVwski0YdDLbyOFum0q8LMPOD945B7kQOcz9fku9Lw82jUoS8f/JOaUQrUeuqphbWw1Yg8G471bgQOq1j+ZuNN2n2SidIFZwjm84jkHanAgcL5sTwJ6b7vvN4PIxAV8gvAxi4hAbABUvacHrp5JpUeoVd7CNMzU5egGzWaLBRtOWaez6qPdtVtfwOkbMiIJbn2fY9CA4zUUr/X9koqBEZ3XOC7vgRQNZjyk2Hon8AS7rmAbdUhq8g3gAEWVbpPg3BkTH5tBNVtg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VuXjQ4S4URrZ7SXZzLdhbeNl600P5Bys8DBWoPnroGo=; b=CsGUVjS1t+ER64SlcHNHOUUxfPI9KIu/m8SzIRR1c74cIbU5ebz2GvD64Km/OgRQQIaNnN3H0f9a+7DaXAKF4RqIX+DGvB2I8pP4riP1smr7ASe3IQ2j+sa2C4hpB4RskXZDX2g9odHacTAlGVfR+D4sIm6LnWsQPJV7xUbaTuM= Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com (10.169.137.153) by VI1PR0701MB2400.eurprd07.prod.outlook.com (10.168.138.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.13; Mon, 23 Sep 2019 22:26:20 +0000 Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com ([fe80::f44b:854c:51cf:c69f]) by VI1PR0701MB2286.eurprd07.prod.outlook.com ([fe80::f44b:854c:51cf:c69f%7]) with mapi id 15.20.2305.013; Mon, 23 Sep 2019 22:26:20 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: "netconf@ietf.org" Thread-Topic: HTTPS notifications (draft-ietf-netconf-https-notif) Thread-Index: AdVyXY/fdU3HloeGTTOWCxwrTn1HQw== Date: Mon, 23 Sep 2019 22:26:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-originating-ip: [80.98.34.204] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5cbff449-be41-435b-ee23-08d740750f19 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(49563074)(7193020); SRVR:VI1PR0701MB2400; x-ms-traffictypediagnostic: VI1PR0701MB2400: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-forefront-prvs: 0169092318 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39860400002)(396003)(376002)(136003)(366004)(189003)(199004)(9686003)(14454004)(26005)(55016002)(52536014)(45776006)(7110500001)(5660300002)(2351001)(74316002)(8676002)(8936002)(3846002)(86362001)(6916009)(7736002)(6116002)(2420400007)(186003)(15650500001)(790700001)(25786009)(102836004)(478600001)(66476007)(66446008)(64756008)(6436002)(4744005)(66556008)(6506007)(14444005)(66616009)(256004)(66066001)(1730700003)(316002)(81156014)(2906002)(9326002)(81166006)(6306002)(99286004)(7696005)(71200400001)(66946007)(476003)(2501003)(71190400001)(486006)(33656002)(99936001)(5640700003)(76116006)(54896002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2400; H:VI1PR0701MB2286.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: dFcVdJZ4t+Op6n7ISH2oYxiKyOVdRIFPGu9C2212MbIwqwP4h5s5nC5rCre10NZulIawp8Af4pHuTzVvozQVO2xxKp0L6tVhkgdfU+bwCCL+49LQ6AHmu7+chUHP0L/mQsMilWoemLRoiRuJ+e6wCfQUngOE8JVef9g3ta6Hs5dVd6nae2Yq+Ri0WvaTliuTmW4qBSRNGUNyDhyik+9iqMXS6WtNdxcUlLXpGo+2Y1PhufvGFfvOHPt/StzTMCvyiVkicEsMqlKG7Lj08GUbVReIiH5aGIY+qvgKA1QTYmxZ6C21h7RdU72s4AZOSK16GNMvxSuBhGnP+usOMOpSIpHchBAd4tlYoOv0eKsjbwGHdBNsbIKZK13rDHx6FA2iIIqFub1pRYzU3g+Bg2pmj9ouonhFpS2pzvHI5uJ1y0E= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0153_01D5726E.AF0950D0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5cbff449-be41-435b-ee23-08d740750f19 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2019 22:26:20.3274 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: XfzPD72AtCZX39T6EmBzc+tuRBl2w1zd4S44fF/MtLF63jQ2NdhkmOf5GAlKGJSFE7TA1iQtgspNb6jvv+ZuMYq9knoZWKpc/i4qys488XM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2400 Archived-At: Subject: [netconf] HTTPS notifications (draft-ietf-netconf-https-notif) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 22:26:34 -0000 ------=_NextPart_000_0153_01D5726E.AF0950D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0154_01D5726E.AF0950D0" ------=_NextPart_001_0154_01D5726E.AF0950D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, The draft should discuss how long the HTTPS connection is held open for the next notification. Or is it open/closed for each notification? The draft should include a sequence diagram showing the message flow something like: Server Client <------- establish TCP <------- establish SSH (or TLS) <------- establish Netconf session <------- configure subscription over Netconf <-------- <-------- tear down Netconf/SSH/TCP Later ------> establish TCP ------> establish TLS ------> Send HTTPS POST message with YANG defined notification <-----Send OK The last 2 or 4 steps repeat until the subscription is removed by another Regards Balazs -- Balazs Lengyel Senior Specialist Ericsson Hungary Ltd. Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com ------=_NextPart_001_0154_01D5726E.AF0950D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

The draft = should discuss how long the HTTPS connection is held open for the next = notification. Or is it open/closed for each = notification?

 

The draft should include a sequence diagram showing = the message flow something like:

Server  =             &= nbsp;          Client

<------- establish = TCP

<------- establish SSH (or = TLS)

<------- establish Netconf = session

<------- = <edit-config>   configure subscription over = Netconf

<-------- = <close-session>

<-------- = tear down Netconf/SSH/TCP

 

Later

 

------> = establish TCP

------> establish = TLS

------> Send HTTPS POST = message with YANG defined notification

<-----Send OK

 

The last 2 = or 4 steps repeat until the subscription is removed by another = <edit-config>

 

 

Regards = Balazs

 

--

Balazs = Lengyel=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Senior = Specialist=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 Ericsson Hungary Ltd.

Mobile: = +36-70-330-7909=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 email: = Balazs.Lengyel@ericsson.com

 

------=_NextPart_001_0154_01D5726E.AF0950D0-- ------=_NextPart_000_0153_01D5726E.AF0950D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVbjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF/zCCA+egAwIBAgIR AOm+1xFswMzmixU1jNT/MSEwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMB4XDTE3MTAw OTE1MjQ1OFoXDTIwMTAwOTE1MjQ1N1owajERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD0Jh bMOhenMgTGVuZ3llbDEqMCgGCSqGSIb3DQEJARYbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t MQ8wDQYDVQQFEwZFVEhCTEwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUUtnneUfH i428YPkvW+AsCNeKCCKq72SzUZpBggijy+oLVO0cgTXXHygrZ+KT8TbyEkPwuHi+V4TQxWAyMhGa nWZHWZXe9ghEZrJDJbCzFMHOqR+wEDnI1vM3sfQQ68iSsWQLd9opnb2/ihiJlt9up75VRpyj5lea bvzxOLQimJgZiXaZzsPPT2nROyytKxOsE5KbfT3mNof3bMG1bggZtGGA1GBJchwdFJwQKIShfPVm 1CdulvJV1hPVecxttMJNPzSfSfryb/b64QnR5yc/pSx8SxD0h0rnNT73Al3Af2iRghdXN4omDKZY OcdK/sE5HTmLTFuWoZAnL/RntOK9AgMBAAGjggHBMIIBvTBIBgNVHR8EQTA/MD2gO6A5hjdodHRw Oi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggr BgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYI KwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNlcjAmBgNVHREEHzAdgRtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBSkJw2vbyMFmf9tY1urk9NeYfiMgTAfBgNVHSMEGDAWgBQcexmel5x2rCA92Nzj kWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAD1RCVf5Df2uCXwPveXz LBGIjsz3k2la5UUlioC+i4Ms6vGstqXIX7K24+Wc41npi+G5xFhvkAkmuTP/j29F5xJJuJcy3OcL 0br02vKe2WJJnlivB+X9plPg0kMUBS0lLq7kHPUrO/BLeIIFRuaky05eZlTnGNcLbn5VpZdjX4Ic XZV78qpZI3L67Po1UgHzOTiWolc75jrKOx3UOw98fWRrgJPBUIeqDeD1NDfF7PlM4Cqlad062o6L lM9wfAnoLzz0z04dPXtJkOcTiZgOLdPoKIm7LR1wZ9c6mYw4sgtoVAs16Y2cCPBxqWpsW+9ZCcDK PPZzeBezCKyicpDJbTqCVMILd3j38HWUPWFuVITZNgANzHW1CpgqmiLIAADiznCCtudTE+fcB3O9 duuu/yuEME17LMy1GYMKXs1QCXmTq2hrqTJQ2AA2TsWZtoxl3ViqJgNBWjnQiMwdCl5Dural2jZP /iU6MmiauUNYn9YW/ViUluoBBdaUHMpnP/7kM0Wk8j3Wzhcggx+Biml2gCopMaK1EJYjQH/2J95N GEkSdZfVzFUmwV3yMd4mOhIaxW0SEq9b1eWICZ/BAcVBpSyU0sE1gpnBO5wLxj+IpSdiGlS4jc37 qCr/39xdv1Unu93glCmHq0xgX54N8EsyMBPC3+zSSu1qhCbU7VJWIz2aMIIGwjCCBKqgAwIBAgIQ U7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEf MB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcx MjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy 3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt 8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6j RrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFl hFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/2 0aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCY rEqHMRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuT LUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMd ay0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqd GTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMB AAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVz dC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9j cmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpec dqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5 s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90 BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRy pF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86 IWst821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QD Xnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7 C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbN QUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbH XSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i 6Ds5j0Qpj5aQMYIDBTCCAwECAQEwXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MAkGBSsOAwIaBQCgggF+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTE5MDkyMzIyMjYxOFowIwYJKoZIhvcNAQkEMRYEFJPoJSs1PgAVKaii/84Mbd/xRfW8MEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQB6HtNNhP4GhE4mkJJWYfA9Mw7r+E0aZkwmjlgBQdlPpdxk0ZT11OkF KivlULswC4JqI8Yf0ahnQxXhHkNm6YSwPpJy4YMXs23C3S8oBFNjTcPBc9iBeg49ecKBat0ZI2Iz 9+NKs0dtr/dN0zLj88hWzdQfnLmd3FQ6TLKM894TAns2bwUImNRUX0E7Ulg3rvnrsPpGVHT/4wdc X8P2I8pREgFnDorAygT6PQ7UKQbNet40MRxozL8IrtPthUONE9IpLpZ0NRO520uD/X3FBgDphdL3 PFHDXcCtt+AF6G3Wlpnz39gmbqUAMOtUtiX70UJUePcOQFgYgABnz4XjM2j2AAAAAAAA ------=_NextPart_000_0153_01D5726E.AF0950D0-- From nobody Mon Sep 23 17:28:31 2019 Return-Path: <0100016d60ab5732-3db5a046-a7b1-4386-b507-977cfa0cd25b-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFAE120099 for ; Mon, 23 Sep 2019 17:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 nZLMAmU1LhAO for ; Mon, 23 Sep 2019 17:28:26 -0700 (PDT) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54CEF120045 for ; Mon, 23 Sep 2019 17:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1569284904; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=njTbGIcLTp9yVlHu+cQ4oZxW3QUJpBzBualq2YecL68=; b=UlpaMMI8dLz900P9Bd5Qnp1UjCw+t8wUo8kv6igO7rw9uk9Q5Qa0ZQIcOiVh2tyt EJK0BxqxgNeXInKQlYxd1cZw/kTNIj+Zx5hAmh6m2LhMQpoiP+4JB13eNA1QRaOvLb3 SY8b3RZ231uEyNtePtLuCCCYRwRus6SyH8RNVdqI= From: Kent Watsen Message-ID: <0100016d60ab5732-3db5a046-a7b1-4386-b507-977cfa0cd25b-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C86BCCD0-8A2A-438C-88C2-662A27FE160F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 24 Sep 2019 00:28:24 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: =?utf-8?Q?Bal=C3=A1zs_Lengyel?= References: X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.24-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] HTTPS notifications (draft-ietf-netconf-https-notif) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 00:28:29 -0000 --Apple-Mail=_C86BCCD0-8A2A-438C-88C2-662A27FE160F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Balazs, > The draft should discuss how long the HTTPS connection is held open = for the next notification. Or is it open/closed for each notification? Should it? Perhaps it should say "Implementations must determine how = long the HTTPS connection is held open for subsequent notifications, or = if it is open/closed for each notification." > The draft should include a sequence diagram showing the message flow = something like: > Server Client > <------- establish TCP > <------- establish SSH (or TLS) > <------- establish Netconf session > <------- configure subscription over Netconf > <-------- > <-------- tear down Netconf/SSH/TCP I don't think the draft needs to include this diagram, as it's standard = NETCONF. > Later > =20 > ------> establish TCP > ------> establish TLS > ------> Send HTTPS POST message with YANG defined notification > <-----Send OK > =20 > The last 2 or 4 steps repeat until the subscription is removed by = another =20 Assuming the TLS session is help open, it might look like this? > ------> establish TCP > ------> establish TLS > ------> Send HTTPS POST message with YANG defined notification > <-----Send 204 (No Content) > ------> Send HTTPS POST message with YANG defined notification > <-----Send 204 (No Content) > ------> Send HTTPS POST message with YANG defined notification > <-----Send 204 (No Content) =46rom the email I sent Martin on Sep 9th, each POST MAY contain more = than one notification: POST /some/path HTTP/1.1 Host: my-receiver.my-domain.com Content-Type: application/yang-data+xml 2019-03-22T12:35:00Z /my-foobar-module"> ... 2019-03-22T12:35:00Z /my-foobar-module"> ... 2019-03-22T12:35:00Z /my-foobar-module"> ... With response: HTTP/1.1 204 No Content Date: Thu, 26 Jan 2017 20:56:30 GMT Server: my-receiver.my-domain.com = Kent // co-author --Apple-Mail=_C86BCCD0-8A2A-438C-88C2-662A27FE160F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Hi Balazs,


The = draft should discuss how long the HTTPS connection is held open for the = next notification. Or is it open/closed for each = notification?

Should it?  Perhaps it should say = "Implementations must determine how long the HTTPS connection is = held open for subsequent notifications, or if it is open/closed for = each notification."


 The = draft should include a sequence diagram showing the message flow = something like:
Server  =             &n= bsp;          Client
<-------= establish TCP
<------- establish SSH (or TLS)
<-------= establish Netconf session
<------- = <edit-config>   configure subscription over Netconf
<-------- <close-session>
<-------- tear down = Netconf/SSH/TCP

I = don't think the draft needs to include this diagram, as it's standard = NETCONF.


Later
 
------> establish TCP
------> = establish TLS
------> Send HTTPS POST message with YANG defined = notification
<-----Send OK
 
The last 2 or 4 steps repeat until the = subscription is removed by another <edit-config> 


Assuming the TLS = session is help open, it might look like this?

------> establish TCP
------> establish TLS
------> = Send HTTPS POST message with YANG defined notification
<-----Send 204 (No Content)
------> Send = HTTPS POST message with YANG defined notification
<-----Send 204 (No Content)
------> Send HTTPS POST message with YANG defined = notification
<-----Send 204 (No Content)


=46rom the email I sent = Martin on Sep 9th, each POST MAY contain more than one = notification:


    = POST /some/path HTTP/1.1
    Host: my-receiver.my-domain.com
    = Content-Type: application/yang-data+xml

    = <notification
    =   xmlns=3D"urn:ietf:params:xml:ns:netconf:notification:1.0">
      = <eventTime>2019-03-22T12:35:00Z</eventTime>
      <foo xmlns=3D"https://example.com/my-foobar-module">
        ...
      </foo>
    = </notification>

 =   <notification
      = xmlns=3D"urn:ietf:params:xml:ns:netconf:notification:1.0">
      = <eventTime>2019-03-22T12:35:00Z</eventTime>
      <bar xmlns=3D"https://example.com/my-foobar-module">
        ...
    =   </bar>
    = </notification>

    = <notification
      = xmlns=3D"urn:ietf:params:xml:ns:netconf:notification:1.0">
      = <eventTime>2019-03-22T12:35:00Z</eventTime>
      <baz xmlns=3D"https://example.com/my-foobar-module">
        ...
    =   </baz>
    </notification>


With = response:

      = HTTP/1.1 204 No Content
      Date: = Thu, 26 Jan 2017 20:56:30 GMT
      = Server: my-receiver.my-domain.com



Kent // = co-author


= --Apple-Mail=_C86BCCD0-8A2A-438C-88C2-662A27FE160F-- From nobody Mon Sep 23 23:46:28 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E755612010C for ; Mon, 23 Sep 2019 23:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 NGQHrc-X7lmW for ; Mon, 23 Sep 2019 23:46:25 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D335712001E for ; Mon, 23 Sep 2019 23:46:24 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id EED2F1AE018A; Tue, 24 Sep 2019 08:46:22 +0200 (CEST) Date: Tue, 24 Sep 2019 08:45:58 +0200 (CEST) Message-Id: <20190924.084558.420273240258823379.mbj@tail-f.com> To: kent@watsen.net Cc: balazs.lengyel=40ericsson.com@dmarc.ietf.org, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <0100016d60ab5732-3db5a046-a7b1-4386-b507-977cfa0cd25b-000000@email.amazonses.com> References: <0100016d60ab5732-3db5a046-a7b1-4386-b507-977cfa0cd25b-000000@email.amazonses.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] HTTPS notifications (draft-ietf-netconf-https-notif) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 06:46:27 -0000 Hi, Kent Watsen wrote: > > Hi Balazs, > > > > The draft should discuss how long the HTTPS connection is held open > > for the next notification. Or is it open/closed for each notification? > > Should it? Perhaps it should say "Implementations must determine how > long the HTTPS connection is held open for subsequent notifications, > or if it is open/closed for each notification." This is somewhat dependent on how notifs are streamed, see below. > > The draft should include a sequence diagram showing the message flow > > something like: > > Server Client > > <------- establish TCP > > <------- establish SSH (or TLS) > > <------- establish Netconf session > > <------- configure subscription over Netconf > > <-------- > > <-------- tear down Netconf/SSH/TCP > > I don't think the draft needs to include this diagram, as it's > standard NETCONF. +1 > > Later > > > > ------> establish TCP > > ------> establish TLS > > ------> Send HTTPS POST message with YANG defined notification > > <-----Send OK > > > > The last 2 or 4 steps repeat until the subscription is removed by > > another > > > Assuming the TLS session is help open, it might look like this? > > > ------> establish TCP > > ------> establish TLS > > ------> Send HTTPS POST message with YANG defined notification > > <-----Send 204 (No Content) > > ------> Send HTTPS POST message with YANG defined notification > > <-----Send 204 (No Content) > > > ------> Send HTTPS POST message with YANG defined notification > > <-----Send 204 (No Content) > > > > From the email I sent Martin on Sep 9th, each POST MAY contain more > than one notification: ... to which I replied: I'm not so sure about the streaming though. Perhaps pipelining is the right mechanism. For "bulk" sending, the "bundled-message" defined in draft-ietf-netconf-notification-messages seems right. To clarify: if the client just sends a stream of notifs it becomes a variant of SSE. The server doesn't know when the stream will end, and thus cannot simply close the session. You probably want to indicate end-of-message somehow (like in SSE). And the content type in the example below cannot be "application/yang-data+xml", since it is not a valid XML instance document; you'd have to invent a new media type to indicate the streaming. I think we should stick to simple HTTP where each notif is POSTed, as in your diagaram above. With HTTP pipelining you can do: ------> establish TCP ------> establish TLS ------> Send HTTPS POST message with YANG defined notification 1 ------> Send HTTPS POST message with YANG defined notification 2 <-----Send 204 (No Content) for 1 <-----Send 204 (No Content) for 2 ------> Send HTTPS POST message with YANG defined notification 3 <-----Send 204 (No Content) for 3 If the server wants to send multiple notifs at once, it can use "bundled-message". /martin > > POST /some/path HTTP/1.1 > Host: my-receiver.my-domain.com > Content-Type: application/yang-data+xml > > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > 2019-03-22T12:35:00Z > > ... > > > > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > 2019-03-22T12:35:00Z > > ... > > > > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > 2019-03-22T12:35:00Z > > ... > > > > > With response: > > HTTP/1.1 204 No Content > Date: Thu, 26 Jan 2017 20:56:30 GMT > Server: my-receiver.my-domain.com > > > Kent // co-author > > From nobody Tue Sep 24 01:50:13 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD63C120120 for ; Tue, 24 Sep 2019 01:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 DlP8aJbcb6vN for ; Tue, 24 Sep 2019 01:50:09 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130123.outbound.protection.outlook.com [40.107.13.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 606121201A3 for ; Tue, 24 Sep 2019 01:50:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O2kQh9D8JdW6Ij4V7RFsejgR69ProuVZxfUUHEueQaZLVqT+56Q4ByyhH73z9tPPnliHgiuCZzuhlV9A2Rie540sSu11t07+UJg/L7/HtU+43+Swavk+fToBVcdkSvIvRwmFowO5OzovmahccGttP44hLtLa9KQEFWVGRsbTWmBeu7EdocerQMc7xFNzzumAAk+mDXImnamVoRtHM9VQ9a8vfr69i8y1K20XTs0ipzI7Mc32UeqVfCLSFoI4LGHLECu+2k0wyDSH0Yy7a2Wvso+2svfQuDpqmLED08RY0sdvKePPOAQySxPtoHWNRF+OnCLgmUY7OVXrRD1wXfhLoQ== 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=ZxN1gNdmoJzWL8VYkf0PNb54AhAg4plTK57sdmmJKeY=; b=kxi3HKicbEvgq3Hh2cOdVlse/4bMEacBn2U3tBO+szbjVxdRfuD/dAs39lFuG/XuV7ZzAsRGmGZ5wVM3OjcFbgknEvYAeI/mIrb50QPK8qYnKOeXvRfV0vwUBExWLO3WCv5+ODzpSxPOuaqrRkEk/FcSkM8r7Lf415vh4IGKJKvQKn0h3dI8W2EkeX9sOlcY1qxBm5tp8DZ9NgNFcv7fnFjSzbay5oFRDSligye5M6SM9hjZUsnpg0fhpxafVrQeNVjiq8JNmlWXmJJ6tst/bTWuTHoCxxZwwxUWmkTcTjyfZY4JQjlChBN3xn/0MX2p58LzwvhEJR5fS/wb7iYkTw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZxN1gNdmoJzWL8VYkf0PNb54AhAg4plTK57sdmmJKeY=; b=IEMUUaVBfnhVy6f5xI76AwixmUvtG/VVQ00MtBOPVYHSA5NHUzBuwYYZyPeHBc3qJzntiDPBwkYrfZZskTdou+1ghk83LLC3VEdjcvvIrt/BfNXK0rU8AgEnTWbFA2dFc/OZ95sTtsd/zsNERD2Xv8vAWQfc0GRVgI+pvKyMvVQ= Received: from AM6PR07MB5944.eurprd07.prod.outlook.com (20.178.91.205) by AM6PR07MB5076.eurprd07.prod.outlook.com (20.177.119.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.13; Tue, 24 Sep 2019 08:50:06 +0000 Received: from AM6PR07MB5944.eurprd07.prod.outlook.com ([fe80::c01e:2ff4:7649:142]) by AM6PR07MB5944.eurprd07.prod.outlook.com ([fe80::c01e:2ff4:7649:142%7]) with mapi id 15.20.2284.023; Tue, 24 Sep 2019 08:50:06 +0000 From: tom petch To: =?iso-8859-1?Q?J=FCrgen?= , "Rob Wilton (rwilton)" CC: "netconf@ietf.org" Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVcrUQ0Ns6WykVUk6hpO31wncbaw== Date: Tue, 24 Sep 2019 08:50:06 +0000 Message-ID: <034101d572b4$cf1901e0$4001a8c0@gateway.2wire.net> References: <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <20190918163657.4pxh5jddxgrir5oh@anna.jacobs.jacobs-university.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0201.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9e::21) To AM6PR07MB5944.eurprd07.prod.outlook.com (2603:10a6:20b:90::13) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.211.103] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 590f797e-3f99-4a37-ab25-08d740cc32a8 x-ms-traffictypediagnostic: AM6PR07MB5076: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0170DAF08C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(346002)(366004)(396003)(376002)(199004)(189003)(51444003)(13464003)(6116002)(62236002)(478600001)(44716002)(486006)(1556002)(9686003)(6306002)(316002)(186003)(66066001)(386003)(6506007)(76176011)(81816011)(81686011)(52116002)(66446008)(8676002)(81156014)(5660300002)(229853002)(99286004)(71190400001)(71200400001)(6512007)(110136005)(4720700003)(64756008)(6486002)(6436002)(446003)(61296003)(14496001)(305945005)(25786009)(8936002)(476003)(66556008)(66946007)(7736002)(66476007)(81166006)(44736005)(102836004)(966005)(14454004)(256004)(14444005)(66574012)(6246003)(50226002)(3846002)(26005)(86362001)(2906002)(4326008)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR07MB5076; H:AM6PR07MB5944.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Z+K8bBeim0OFGcJX7W6CseOyzTfQEHFpUFIo3hwnQTdXOaYVgHEvcqM1GvjPmA7Je2CB90FoKtQGHAGyA4naQIXGi1BfvfUpLarrhLqbyv9ld798kCcV6XYtv/sQfJydL5oUdkJ52RgQretyg7/n68lYokSsCk9luDmsVVDfg+DLMmRe4va0yxrufCnRcLu1BRmWHvR15saMykQOr52I4shE/wb0xmfud7wZdkTyPjNTwPqGiS1c8BPjQAlc2S4SU0OzGyY/h2sGz5azCnz0u1fvlfO4fXtPdWd3PK4WtLgHC9kmB0OOOXVTVEs6k9opau9E34tH4E4xNnsjnItKD09tr43FuS5iIFZbkGlqvOy9dZasauztuhAGjcVKWegNqUBrOOn8YKfoJ5K0JkzieTL8XREjCrZHtoSNTs9OOUgtIS0pfShGwaY8dn5RO22OKa2xv6GHwhzB1B+oGFnAAQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 590f797e-3f99-4a37-ab25-08d740cc32a8 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2019 08:50:06.5584 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: aSWLgRxHWS78N5Tk88ee9FW4jWCLWWFIHw2PKMhzgAWmZeEFBquE5Y+uBrDM0dxDqiWEFRA4yelfebZ/GJKXCg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5076 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 08:50:12 -0000 Going back a bit, since this is a more generic comment, I get a different, simpler perspective in draft-jholland-taps-api-yang which has me wondering just how complicated this needs to be for it to be useful in other WGs. The I-D defines identity security-algorithm {description "Base identity for security algorithms." identity cipher-suite { base security-algorithm;description "Base identity for security cipher suites."; identity signature-algorithm {base security-algorithm; description "Base identity for security signature algorithms."; identity ed25519 {base signature-algorithm; identity TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 { base cipher-suite; and grouping security-credentials { leaf identity { type string; leaf trust-ca { type string; leaf algorithm { type identityref {base security-algorithm; leaf pre-shared-key { type string; leaf private-key { type string; leaf private-key-callback-handle {type string; leaf public-key {type string; (No SSH but that does not surprise me:-) Again a more general comment, the IETF often starts simple and adds lots later, which sometimes goes wrong because no allowance was made for slotting in extras, but an approach which, I think, more often leads to successful adoption. Thus will TAPS consider using draft-ietf-netconf-crypto-types or will they RYO? Tom Petch ----- Original Message ----- From: ; "J=FCrgen" To: "Rob Wilton (rwilton)" Cc: "Russ Housley" ; ; "Sean Turner" ; "Rifaat Shekh-Yusef" Sent: Wednesday, September 18, 2019 5:36 PM > On Wed, Sep 18, 2019 at 03:37:14PM +0000, Rob Wilton (rwilton) wrote: > > >From the gist of the discussion, the punch list appears to be: > > > > - revert back to using identities, as they were in the -08 revision. > > - only define base identities for what's needed immediately for TLS and SSH and keystore key-encryption. > > - define these base identities in distinct YANG modules > > - have each identity's description statement indicate what the binary key data is encoded. > > [RW] > > I think that this matches my view, except for "define these base identities in distinct YANG modules". I don't feel particularly strongly about this, but I was thinking that the base identities would still be defined in crypto-types.yang, which might help keep the import references simple. > > I tend to agree that sometimes less modules is more. For me, the > problem is likely more that I am not entirely sure what the proper > base types would be, which may depend on what exactly they are used > for. I guess I wait until I see the description text... > > > A bit separate from the above, but still in mind: > > > > - specify that all TLS public-keys are a DER-encoded SubjectPublicKeyInfo structure > > - specify that all SSH public-keys are a "ssh-public-key-type" type (see below) > > - specify that all encrypted symmetric keys are a DER-encoded OneSymmetricKey structure > > - specify that all encrypted asymmetric keys are a DER-encoded OneAsymmetricKey structure > > I would check what is commonly used in existing configuration > interfaces. We are not inventing the wheel here. And whatever we > define better is usable with existing implementations and tools. > > > The "ssh-public-key" type would be defined as: > > > > typedef ssh-public-key-type { > > type binary; > > mandatory true; > > description > > "The binary public key data for this SSH key, as > > specified by RFC 4253, Section 6.6, i.e.: > > > > string certificate or public key format > > identifier > > byte[n] key/certificate data."; > > reference > > "RFC 4253: The Secure Shell (SSH) Transport > > Layer Protocol"; > > } > > The SSH implementations that I use have the binary key data rendered > in ASCII. In fact, the whole key record is rendered in ASCII. I > strongly suggest to use formats that are well established. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Sep 24 05:15:51 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72FB812022A for ; Tue, 24 Sep 2019 05:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 awT4EUI3yojW for ; Tue, 24 Sep 2019 05:15:43 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 15FD71201EF for ; Tue, 24 Sep 2019 05:15:42 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x8OC7Dxr010303; Tue, 24 Sep 2019 13:15:37 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=cJcADm3VH46e42XmXDGxWevGpzjQj0SM2MnpkJforaI=; b=D+pETmYM/Ek/xzAi6ojJjQrHblNjlrn26lSulI5LY3m5fSfBEZPtcc3gd4LJjfFe71yg R8ufCw04xLSYUBZv8TMsgI7faBayCs7mgPrzro/GZVL0UrAbAex+icFOMRC9ClR+sFNv P+N2gn5PpEhzBehHn3refXNVPsGkGqUPMm45II7utUfW6IK3/4afIID/d8K6Rturo6sM zJqTSPx7gRo9CIovm6QqwKroxa09Nimd/pD1le98d36eZbknx8wm4tvI3RkbInB7B7o/ CCOa6BtghomwdGBBhVt2ylewueaoZ1zDnxg3pZB1yRzx+l+O7rIN8wh79lSH7+OF5l7u 8g== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2v73qdkh5x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Sep 2019 13:15:36 +0100 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x8OC39jr023790; Tue, 24 Sep 2019 08:15:35 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint6.akamai.com with ESMTP id 2v73vph1q0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 24 Sep 2019 08:15:35 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Sep 2019 08:15:34 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Tue, 24 Sep 2019 08:15:34 -0400 From: "Salz, Rich" To: tom petch , =?utf-8?B?SsO8cmdlbg==?= , "Rob Wilton (rwilton)" CC: "netconf@ietf.org" Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxGVhFlbERW30moo9Q8WhnpJqc60c8A Date: Tue, 24 Sep 2019 12:15:34 +0000 Message-ID: References: <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <20190918163657.4pxh5jddxgrir5oh@anna.jacobs.jacobs-university.de> <034101d572b4$cf1901e0$4001a8c0@gateway.2wire.net> In-Reply-To: <034101d572b4$cf1901e0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.220] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-24_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909240123 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-09-24_05:2019-09-23,2019-09-24 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxlogscore=999 clxscore=1011 phishscore=0 malwarescore=0 suspectscore=0 adultscore=0 priorityscore=1501 mlxscore=0 impostorscore=0 bulkscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909240124 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 12:15:46 -0000 PiBHb2luZyBiYWNrIGEgYml0LCBzaW5jZSB0aGlzIGlzIGEgbW9yZSBnZW5lcmljIGNvbW1lbnQs IEkgZ2V0IGEgZGlmZmVyZW50LCBzaW1wbGVyIHBlcnNwZWN0aXZlIGluDQpkcmFmdC1qaG9sbGFu ZC10YXBzLWFwaS15YW5nIHdoaWNoIGhhcyBtZSB3b25kZXJpbmcganVzdCBob3cgY29tcGxpY2F0 ZWQgdGhpcyBuZWVkcyB0byBiZSBmb3IgaXQgdG8gYmUgdXNlZnVsIGluIG90aGVyIFdHcy4NCg0K SSBsaWtlIEpha2UncyBhcHByb2FjaC4gIEJ1dCBJIGRvbid0IGtub3cgd2hhdCB5b3VyICJ0aGlz IiByZWZlcnMgdG8gLS0gdGhlIGNyeXB0by10eXBlcyBvciB0aGUgVEFQUyBkcmFmdD8NCg0KPiAg ICBUaHVzIHdpbGwgVEFQUyBjb25zaWRlciB1c2luZyBkcmFmdC1pZXRmLW5ldGNvbmYtY3J5cHRv LXR5cGVzIG9yIHdpbGwgdGhleSBSWU8/DQogIA0KUGVyaGFwcyB0aGUgVEFQUyBXRyBzaG91bGQg YmUgYXNrZWQgOikgIEpha2UncyBhIGNvbGxlYWd1ZSwgSSd2ZSBwaW5nZWQgaGltLg0KDQo= From nobody Tue Sep 24 06:45:45 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1914120026 for ; Tue, 24 Sep 2019 06:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=jKY13sf5; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=z1btXEuk 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 JUvFbIG2hGN4 for ; Tue, 24 Sep 2019 06:45:42 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD7F6120804 for ; Tue, 24 Sep 2019 06:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9479; q=dns/txt; s=iport; t=1569332742; x=1570542342; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Y7X3ct2s5VOiX+kP1Z4KQlEPu8DTMRlmsvYQzaeVptU=; b=jKY13sf5j6eBu5TXGbBA4I35AeuZF7xjmWpADtWoA8tlDr8Pcluc32M9 jABRPpZJUNFj3Q+4FQmzPPTSgaDGX73lQUKGRCXsjS+lr9SXzLWcqzVeg t2lZnj+tN8jC91cL056eciFMFRTbMRKsNv0jpFC4qArsafHZXklnlr+Gk U=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3AFRGo8RJPnXrA4lts4NmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeCtad2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXEDlK//2Ryc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAACuHYpd/4wNJK1lGgEBAQEBAgE?= =?us-ascii?q?BAQEMAgEBAQGBVQMBAQEBCwGBSlADbVYgBAsqCodfA4p1glyXdIEuFIEQA1Q?= =?us-ascii?q?CBwEBAQkDAQEYCwoCAQGDekUCgyEjNgcOAgMJAQEEAQEBAgEFBG2FLQyFSgE?= =?us-ascii?q?BAQMBAQEQFRkBASwJAgEPAgEIDgYRIQIlCyUCBAENBQgGFIMBgR1NAw4PAQI?= =?us-ascii?q?MolUCgTiIYYFyM4J9AQEFhRIYghAHCYE0AYFQijgYgUA/gVeCTD6CYQEBgS4?= =?us-ascii?q?BEgEJGBUJHoJ/giaWBpcKCoIig0GCLoEWjiCZJY4agxiCPII/kQICBAIEBQI?= =?us-ascii?q?OAQEFgVkDLmdxcBU7gmwJRxAUgU6DcoRLSYU/c4EpiSgHCBeBCwGBIgEB?= X-IronPort-AV: E=Sophos;i="5.64,544,1559520000"; d="p7s'?scan'208";a="548741475" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Sep 2019 13:45:25 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x8ODjPIk013707 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 Sep 2019 13:45:25 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Sep 2019 08:45:24 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Sep 2019 09:45:24 -0400 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 24 Sep 2019 08:45:24 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OcHX28jt1mM+rujivQa0Kc43mVSfvgdM3n/0bmmkS/mV4wt0gIX+VNdi/G6u3Zrr1e99Hh4LhEbCkaIhnkTzPZfyc8Yw7Gco80zcBSSRUb4ztJfBWy4g+awO3cpRHivftpofX54CiIS1mIiIHBCaasqx1vN5GRdaOBf/X1t2XdPwzRUJqi4GtBR+JCX5thCUpPf4R5IU1dRnWYPiSP7vINV1VcEX1oGEMknRt0t+UWj/32EM/k2m74fA6qnm9N5T9oBxWM4aYv/G+P6xErMSMhTOYYdnxMDrAY4IS2oH6Ma+ODIcROsEAC9afPX/x47MsM1U/xtrfsHDGKDEOvNvng== 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=z13Ro9wuYV8v11d6QYofxReNRLfPRhPBwikqlO3e0HU=; b=ZqItjVYacJdCu+Zpx8ToFWxvZf23/Da9GIZbVfOCw5CbxOthk4LxvoL2fUPAD223tj00QbtIY8gHNuOyC5xWk2/maGC+wc6OQq0KSTd5cUVQOqqIvhX1tOlc+KF1GI5Gkh5soFFanXCKbMy+4C8JVpke0y/In9TcF8wS1OLVhr31H9cspifJ3cGDHKcprblHNB58PLKX7vEHFs4rCwF2w5FUoGuAzN5WEH0GytMKC3ZOFTkfmdcbpEsLXkrJrt7I4oeLK2mPtLUVPoLBS7rwd2yQ3qw5YTsWYkHg37x/5Bs7x4ODvMNGKPtYiu/7tF3cQEh1A8BuKk1CCnM7ZUMx3Q== 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=z13Ro9wuYV8v11d6QYofxReNRLfPRhPBwikqlO3e0HU=; b=z1btXEukWQKzHa6iFN6Fco/zm2iBwpF+KoqSTfGjW46X2WWpf4FyzIT2hh3vF8adwy++vndfLwawpjJPUb8qLlDsFReErjDzn1OUgGEf8Z/2CGH17SH4joiLUDm3ol2zZztB3fgIET7wwpLu0Av80ygKVFyLa5q0HwxZDLVqUkQ= Received: from BN7PR11MB2627.namprd11.prod.outlook.com (52.135.255.31) by BN7PR11MB2785.namprd11.prod.outlook.com (52.135.254.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.20; Tue, 24 Sep 2019 13:45:22 +0000 Received: from BN7PR11MB2627.namprd11.prod.outlook.com ([fe80::61c6:4b6d:cf6c:f095]) by BN7PR11MB2627.namprd11.prod.outlook.com ([fe80::61c6:4b6d:cf6c:f095%3]) with mapi id 15.20.2284.023; Tue, 24 Sep 2019 13:45:22 +0000 From: "Eric Voit (evoit)" To: Martin Bjorklund , "kent@watsen.net" CC: "balazs.lengyel=40ericsson.com@dmarc.ietf.org" , "netconf@ietf.org" Thread-Topic: [netconf] HTTPS notifications (draft-ietf-netconf-https-notif) Thread-Index: AQHVcm8M1F2iC/feQE6yftH94OJ7Eac6YpMAgABf18A= Date: Tue, 24 Sep 2019 13:45:22 +0000 Message-ID: References: <0100016d60ab5732-3db5a046-a7b1-4386-b507-977cfa0cd25b-000000@email.amazonses.com> <20190924.084558.420273240258823379.mbj@tail-f.com> In-Reply-To: <20190924.084558.420273240258823379.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=evoit@cisco.com; x-originating-ip: [173.38.117.75] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cbf9d175-2d44-43bf-f664-08d740f57288 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600167)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:BN7PR11MB2785; x-ms-traffictypediagnostic: BN7PR11MB2785: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0170DAF08C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(366004)(346002)(136003)(396003)(199004)(189003)(71190400001)(71200400001)(229853002)(76116006)(8936002)(25786009)(3846002)(316002)(99936001)(110136005)(54906003)(6116002)(2906002)(86362001)(446003)(11346002)(5660300002)(476003)(66616009)(66476007)(74316002)(486006)(66946007)(66556008)(7736002)(305945005)(64756008)(66446008)(6506007)(81166006)(81156014)(102836004)(6246003)(52536014)(6436002)(33656002)(15650500001)(14454004)(7696005)(2501003)(2420400007)(4326008)(8676002)(76176011)(99286004)(7110500001)(966005)(256004)(14444005)(6306002)(9686003)(186003)(55016002)(66066001)(478600001)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2785; H:BN7PR11MB2627.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: nPzK0iyyACs+Uo2Fgf0SUQvrEY8vGyUrZ8sT6/SmkRDjo5FYwDR1JtoHd3mAQbYbaUBaMu7NytaY3lxwiQGv3ui/yluT0/qiFLbCiFdS45sVXd195u/DAIzmMJLoZ6DuAHX1LmykfxhmIe7MT7bUfCOOYItvJkdbiwbsLjFNgdgN55tubRFCx5Zovx5ljZ8Pdixd0A+EDBeVUAzqG6OErXbDs4OmYlsXQp20lqZ+3lDCgFFLawf2i1/+zJkIzQydmywbux/mSKopWwKsIjdf2ZM3b7Cim3Ms7ZvducSWgpECg1wHcpeZJAxVYkbY0fUEmwhXDo4cpGop04bfFadTx7gNZXdOy4MpfpMv+IsTp6CUOTmvYHYKr1cmFM7M1BZmqkT1EjP57dYql3V66Z6EsLmla+UEJYVN2535R97xFA0= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_011D_01D572BC.C44B1250" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cbf9d175-2d44-43bf-f664-08d740f57288 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2019 13:45:22.6889 (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: 0aMMNAZvJfKhN4S0sIK8x0vxUXwNSRJRzziTVRObtP10Ax8L+Mt2UAuXrHltwx3N X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2785 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [netconf] HTTPS notifications (draft-ietf-netconf-https-notif) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 13:45:44 -0000 ------=_NextPart_000_011D_01D572BC.C44B1250 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > > From the email I sent Martin on Sep 9th, each POST MAY contain more > > than one notification: > > .... to which I replied: > > I'm not so sure about the streaming though. > Perhaps pipelining is the right mechanism. For "bulk" sending, the > "bundled-message" defined in draft-ietf-netconf-notification-messages > seems right. > > To clarify: if the client just sends a stream of notifs it becomes a variant of > SSE. The server doesn't know when the stream will end, and thus cannot > simply close the session. You probably want to indicate end-of-message > somehow (like in SSE). And the content type in the example below cannot > be "application/yang-data+xml", since it is not a valid XML instance > document; you'd have to invent a new media type to indicate the streaming. > > I think we should stick to simple HTTP where each notif is POSTed, as in your > diagaram above. With HTTP pipelining you can do: > > ------> establish TCP > ------> establish TLS > ------> Send HTTPS POST message with YANG defined notification 1 Send > ------> HTTPS POST message with YANG defined notification 2 > <-----Send 204 (No Content) for 1 > <-----Send 204 (No Content) for 2 > > ------> Send HTTPS POST message with YANG defined notification 3 > <-----Send 204 (No Content) for 3 > > > If the server wants to send multiple notifs at once, it can use "bundled- > message". This seems a reasonable approach. draft-ietf-netconf-notification-messages has several advantages: (1) can push multiple YANG notifications at once (2) can include the subscription-id in notifications when subscribing to a stream. (Right now including an explicit subscription-id is only available when subscribing to a datastore.) (3) includes methods to discover lost/dropped notifications Two things which would need to be worked: (1) discovering receiver support for bundled notifications. (As some form of understanding/verifying configured receiver support over HTTP is already needed, this is a topic which perhaps can be merged into that.) (2) Completion of draft-ietf-netmod-yang-data-ext Eric > /martin > > > > > > POST /some/path HTTP/1.1 > > Host: my-receiver.my-domain.com domain.com/> > > Content-Type: application/yang-data+xml > > > > > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > > 2019-03-22T12:35:00Z > > > > ... > > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > > 2019-03-22T12:35:00Z > > > > ... > > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > > 2019-03-22T12:35:00Z > > > > ... > > > > > > > > > > With response: > > > > HTTP/1.1 204 No Content > > Date: Thu, 26 Jan 2017 20:56:30 GMT > > Server: my-receiver.my-domain.com > > > > > > > > Kent // co-author > > > > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_000_011D_01D572BC.C44B1250 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwOTI0MTM0NTE0WjAjBgkqhkiG 9w0BCQQxFgQUCmLnw7kbo6eYUg3kDaDVqZvQUjUwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQB+ope4ZnN1PFx6bCPUOg3fZYmxmKMEhTPdrWHaQNG5sBaGZmAkPsmur5/vEdn9Tnrc kbONn1nJWbHydIXS7BgW3rbfHPBxljlVMG/HLfqvMqO/uHo/0/voNKbomyuz//7/DtOT7vLxL3RY iLTl9QiBu5fgjKPIwu5LLomC6rF+Jz4JwgPHTWerCJvchBC3kGTp+sfWe0pZezY10TF7hy0Z3a8k 6qF3IPw1O2S3Tq5zpS3OPea3I3ZEGFdfVoyR/hvIh5jDeALkKPkI6ftA/L89sm5WfmJbklB+Mor5 iiv8iZnuUM+uwHAA+vAUUB7N6PtIP/VI8NRznBkWpAxCGV/qAAAAAAAA ------=_NextPart_000_011D_01D572BC.C44B1250-- From nobody Tue Sep 24 06:56:15 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A34412081E for ; Tue, 24 Sep 2019 06:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 i8G1dlefEra7 for ; Tue, 24 Sep 2019 06:56:11 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3B35212080C for ; Tue, 24 Sep 2019 06:56:11 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 7CEA81AE018A; Tue, 24 Sep 2019 15:56:09 +0200 (CEST) Date: Tue, 24 Sep 2019 15:55:45 +0200 (CEST) Message-Id: <20190924.155545.1143100128662277152.mbj@tail-f.com> To: evoit@cisco.com Cc: kent@watsen.net, balazs.lengyel=40ericsson.com@dmarc.ietf.org, netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <0100016d60ab5732-3db5a046-a7b1-4386-b507-977cfa0cd25b-000000@email.amazonses.com> <20190924.084558.420273240258823379.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] HTTPS notifications (draft-ietf-netconf-https-notif) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 13:56:14 -0000 "Eric Voit (evoit)" wrote: > > > > > From the email I sent Martin on Sep 9th, each POST MAY contain more > > > than one notification: > > > > .... to which I replied: > > > > I'm not so sure about the streaming though. > > Perhaps pipelining is the right mechanism. For "bulk" sending, the > > "bundled-message" defined in draft-ietf-netconf-notification-messages > > seems right. > > > > To clarify: if the client just sends a stream of notifs it becomes a > variant of > > SSE. The server doesn't know when the stream will end, and thus cannot > > simply close the session. You probably want to indicate end-of-message > > somehow (like in SSE). And the content type in the example below cannot > > be "application/yang-data+xml", since it is not a valid XML instance > > document; you'd have to invent a new media type to indicate the streaming. > > > > I think we should stick to simple HTTP where each notif is POSTed, as in > your > > diagaram above. With HTTP pipelining you can do: > > > > ------> establish TCP > > ------> establish TLS > > ------> Send HTTPS POST message with YANG defined notification 1 Send > > ------> HTTPS POST message with YANG defined notification 2 > > <-----Send 204 (No Content) for 1 > > <-----Send 204 (No Content) for 2 > > > > ------> Send HTTPS POST message with YANG defined notification 3 > > <-----Send 204 (No Content) for 3 > > > > > > If the server wants to send multiple notifs at once, it can use "bundled- > > message". > > This seems a reasonable approach. draft-ietf-netconf-notification-messages > has several advantages: > (1) can push multiple YANG notifications at once > (2) can include the subscription-id in notifications when subscribing to a > stream. (Right now including an explicit subscription-id is only available > when subscribing to a datastore.) > (3) includes methods to discover lost/dropped notifications > > Two things which would need to be worked: > (1) discovering receiver support for bundled notifications. (As some form > of understanding/verifying configured receiver support over HTTP is already > needed, this is a topic which perhaps can be merged into that.) This can be configured or auto-detected. For auto-detection, perhaps we can use HTTP OPTIONS with the server returning a special body or header to indicate capabilities such as this one? > (2) Completion of draft-ietf-netmod-yang-data-ext Yes! IMO it is ready for WGLC; I'll ping the chairs again. /martin > > Eric > > > /martin > > > > > > > > > > POST /some/path HTTP/1.1 > > > Host: my-receiver.my-domain.com > domain.com/> > > > Content-Type: application/yang-data+xml > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > > > 2019-03-22T12:35:00Z > > > > > > ... > > > > > > > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > > > 2019-03-22T12:35:00Z > > > > > > ... > > > > > > > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > > > 2019-03-22T12:35:00Z > > > > > > ... > > > > > > > > > > > > > > > With response: > > > > > > HTTP/1.1 204 No Content > > > Date: Thu, 26 Jan 2017 20:56:30 GMT > > > Server: my-receiver.my-domain.com > > > > > > > > > > > > Kent // co-author > > > > > > > > > > _______________________________________________ > > netconf mailing list > > netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Sep 24 07:57:51 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601691200CE for ; Tue, 24 Sep 2019 07:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=WQs9xzf1; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=LeNOxp9N 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 WNzEdUhR8N5l for ; Tue, 24 Sep 2019 07:57:44 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D9C612001A for ; Tue, 24 Sep 2019 07:57:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10828; q=dns/txt; s=iport; t=1569337064; x=1570546664; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=29knUyP39ijmbATqGmv1TrCt7U+o6rCvunGO6Og+a04=; b=WQs9xzf1heIFTQaO1Pr3eX6FJNoPfSvRwFfdwQzMJtADhzNuNUkiJvZU 1JEsoibmjz9sA70rByQdtAgoYiIT4UIYH3zuX2ZOxFkHE61Xgb9T2GR3N UpLm1ApOp2QDVwTvDdVFkjNHql2T9/MTBdS3/3qL2ze3Pcxl+RUJcmHcT o=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3AyWrS4BFdPMAiOe5+BR0uOJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4w3A3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+efP0aC0mNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeAADJLYpd/5NdJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQwBAQEBAQGBVgEBAQEBAQsBgUpQA21WIAQLKgqHXwOKdoJcl3SBQoE?= =?us-ascii?q?QA1QCBwEBAQkDAQEYCwoCAQGDekUCgyEjNwYOAgMJAQEEAQEBAgEFBG2FLQy?= =?us-ascii?q?FSgEBAQMBAQEQFRkBASwJAgEECwIBCA4GAQMNIQIlCyUCBAENBQgGFIMBgR1?= =?us-ascii?q?NAw4PAQIMolYCgTiIYYFyM4J9AQEFhQ0YghAHCYE0AYFQijgYgUA/gRFGgkw?= =?us-ascii?q?+gmEBAYEuARIBCRgVCR6Cf4ImlgaXCgqCIoNBgi6BFo4gmSWOGoMYgjyCP5E?= =?us-ascii?q?CAgQCBAUCDgEBBYFoImdxcBU7gmwJRxAUgU6DcoRLSYU/c4EpiTeBIgGBIgE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.64,544,1559520000"; d="p7s'?scan'208";a="636310619" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Sep 2019 14:57:43 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x8OEvhVs009713 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 Sep 2019 14:57:43 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Sep 2019 09:57:42 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Sep 2019 09:57:40 -0500 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 24 Sep 2019 09:57:40 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mDyWBMiicZamp29eXPAAR5gUYpVsd61IGHxxAMikkmR05AIi0J5jgPn72258VMQzhLNXZUMF6GUafX4Gca19bOACZLIeYpIoK0+t/FKU3sSInQuBvBr5h15fKn8deX7LzmpR6mhqkoMYy3+ICb4ZtG8VW9LSVnF1lthgB/UF/wS2xV3AhApftdTq/KafEoIaz71BugMgUPYIOajOr6ksB1AN5j8QtCGbxkQmxfpL784cMyzfeyjDQ1VYPGioJfdp7GL+UWsPXHmX4ZdZ/viIvEHTy1NhOY+DRDg+GnNx5GwvOfCSTxXKE04tZfhAZfRdTtFLwwcPDe4o3joOkSLFQA== 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=OSdCst9yBnkfXAyy811tSvGFZIx1xHQaYVlyOYCkwN8=; b=QLbv2S9QBeE8qLiF/wgBZOoxMerznsc6EIdgpP4Sc5QG2klFsmhfdW0N2UrUI6CZEo/OIC0D5ZNQMSRQcr1Jt+6zxzKw4ylLuvD/jInw2AJJ1YGAU8spIeaVE94bE3Ejm496Jetwrvx38GZVgciEGnuUtgq4/ylec7wySNIqw6mgv3n0UHAxXHUQ9LdcuEYTTCEmBttxC0J4M2kE1J6VS1rKV8hHutijpSvKiA44XwEq90YZcYZLkhR7y37bGhaYRj0Gk7xtokdGoVrIA8rOUZuMAS7BE596HCvWeybei6M0csyIyGQTyry5KmNwKjibF2swqfDRRP2ajJ1bP/HFkQ== 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=OSdCst9yBnkfXAyy811tSvGFZIx1xHQaYVlyOYCkwN8=; b=LeNOxp9Nm24bXmnxdOxF7Yn2K9mJyDie9qO2o0oYQDbB3fkG1I4rcXyv7wj3NoUddt1pBS28fjBrVI9p+wijvD8oF3lJs0XYGStJy//98HEBjLrMd/kwTcP29c4CR0kjv34t+jEC5OWS3IonzlSbc64Cce9VPNzs6MlIQQPaMOA= Received: from BN7PR11MB2627.namprd11.prod.outlook.com (52.135.255.31) by BN7PR11MB2593.namprd11.prod.outlook.com (52.135.253.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.25; Tue, 24 Sep 2019 14:57:37 +0000 Received: from BN7PR11MB2627.namprd11.prod.outlook.com ([fe80::61c6:4b6d:cf6c:f095]) by BN7PR11MB2627.namprd11.prod.outlook.com ([fe80::61c6:4b6d:cf6c:f095%3]) with mapi id 15.20.2284.023; Tue, 24 Sep 2019 14:57:37 +0000 From: "Eric Voit (evoit)" To: Martin Bjorklund , Mahesh Jethanandani , "kent@watsen.net" CC: "netconf@ietf.org" Thread-Topic: [netconf] HTTPS notifications (draft-ietf-netconf-https-notif) Thread-Index: AQHVcm8M1F2iC/feQE6yftH94OJ7Eac6YpMAgABf18CAABg9gIAACLaA Date: Tue, 24 Sep 2019 14:57:37 +0000 Message-ID: References: <0100016d60ab5732-3db5a046-a7b1-4386-b507-977cfa0cd25b-000000@email.amazonses.com> <20190924.084558.420273240258823379.mbj@tail-f.com> <20190924.155545.1143100128662277152.mbj@tail-f.com> In-Reply-To: <20190924.155545.1143100128662277152.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=evoit@cisco.com; x-originating-ip: [173.38.117.75] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cb211a2d-b7bf-44c7-256a-08d740ff8a05 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(49563074)(7193020); SRVR:BN7PR11MB2593; x-ms-traffictypediagnostic: BN7PR11MB2593: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0170DAF08C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(346002)(39860400002)(136003)(396003)(199004)(189003)(33656002)(7110500001)(55016002)(14454004)(5660300002)(86362001)(7736002)(6306002)(9686003)(6246003)(4326008)(305945005)(478600001)(52536014)(66066001)(966005)(25786009)(486006)(99936001)(8676002)(81156014)(74316002)(8936002)(81166006)(14444005)(256004)(186003)(2906002)(476003)(26005)(76176011)(446003)(71200400001)(6116002)(102836004)(3846002)(71190400001)(15650500001)(2501003)(6506007)(2420400007)(6436002)(99286004)(76116006)(66476007)(110136005)(11346002)(66946007)(66556008)(316002)(66446008)(64756008)(229853002)(7696005)(66616009); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2593; H:BN7PR11MB2627.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: /JP5Qm0AgERBv3hIvE5JZljMbA3Lfy8ZA8F5OBOtl0hE91Myz0FmJW1hDwbYAed/eoT1KNiv2i6UUVTjJOE6ukzL6LlYHru5dBSjWnvxW9Wtq+g3Wct1juv9YHPHrQwzWdAQlGWQyg6CbKpd+H9oFnyYh3BYf5Br1PgC2r46HGWvPww1XVwYwkpsftBxcAMkc5dRj57jeDtKe3NK95g9blJeGiuybeiLCDmeTMrfJDjo9K7QLk5p4J0s8Zxh+iOyXGC3ss0XjihbvkQAXk1qozEhl+BsE4qCESkD2HAszX5DXpujZgPEUZzY1lRuybM+L4O0mOGjty+r5gpVZhfF+tD+RgOhfDhPZjR6MNH4Oyt2GbU2ZcknK1lSlsY1MnXFAVZ6jpd3vvxtAfap1JvD4Tv/mg5B1owK+bKpZBO2Uus= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0145_01D572C6.2CACF080" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cb211a2d-b7bf-44c7-256a-08d740ff8a05 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2019 14:57:37.2265 (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: 8S3EJgrIFyqo8Dv208iW/GPeBDarbafW0BPHjGrAIA4gnVmLQQVmxhzlhZK3orAB X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2593 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.24, xch-rcd-014.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [netconf] HTTPS notifications (draft-ietf-netconf-https-notif) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 14:57:48 -0000 ------=_NextPart_000_0145_01D572C6.2CACF080 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > From: Martin Bjorklund, September 24, 2019 9:56 AM > > "Eric Voit (evoit)" wrote: > > > > > > > > From the email I sent Martin on Sep 9th, each POST MAY contain > > > > more than one notification: > > > > > > .... to which I replied: > > > > > > I'm not so sure about the streaming though. > > > Perhaps pipelining is the right mechanism. For "bulk" sending, the > > > "bundled-message" defined in draft-ietf-netconf-notification-messages > > > seems right. > > > > > > To clarify: if the client just sends a stream of notifs it becomes a > > variant of > > > SSE. The server doesn't know when the stream will end, and thus > > > cannot simply close the session. You probably want to indicate > > > end-of-message somehow (like in SSE). And the content type in the > > > example below cannot be "application/yang-data+xml", since it is not > > > a valid XML instance document; you'd have to invent a new media type > to indicate the streaming. > > > > > > I think we should stick to simple HTTP where each notif is POSTed, > > > as in > > your > > > diagaram above. With HTTP pipelining you can do: > > > > > > ------> establish TCP > > > ------> establish TLS > > > ------> Send HTTPS POST message with YANG defined notification 1 > > > ------> Send HTTPS POST message with YANG defined notification 2 > > > <-----Send 204 (No Content) for 1 > > > <-----Send 204 (No Content) for 2 > > > > > > ------> Send HTTPS POST message with YANG defined notification 3 > > > <-----Send 204 (No Content) for 3 > > > > > > > > > If the server wants to send multiple notifs at once, it can use > > > "bundled- message". > > > > This seems a reasonable approach. > > draft-ietf-netconf-notification-messages > > has several advantages: > > (1) can push multiple YANG notifications at once > > (2) can include the subscription-id in notifications when subscribing > > to a stream. (Right now including an explicit subscription-id is only > > available when subscribing to a datastore.) > > (3) includes methods to discover lost/dropped notifications > > > > Two things which would need to be worked: > > (1) discovering receiver support for bundled notifications. (As some > > form of understanding/verifying configured receiver support over HTTP > > is already needed, this is a topic which perhaps can be merged into > > that.) > > This can be configured or auto-detected. For auto-detection, perhaps we > can use HTTP OPTIONS with the server returning a special body or header to > indicate capabilities such as this one? The method previously proposed for HTTP configured subscriptions was an "OK" to the POST of a . The "OK" had to be received prior to sending YANG notifications. If the authors want to build upon this, I could see HTTP OPTIONS as a way to provide receiver capabilities. Some discussion about what capabilities would be advertisable as options would be worthwhile. Also worth discussion would be any intersections with NETCONF/RESTCONF capabilities discovery/exchange. Eric > > (2) Completion of draft-ietf-netmod-yang-data-ext > > Yes! IMO it is ready for WGLC; I'll ping the chairs again. > > > /martin > > > > > > > Eric > > > > > /martin > > > > > > > > > > > > > > POST /some/path HTTP/1.1 > > > > Host: my-receiver.my-domain.com > > domain.com/> > > > > Content-Type: application/yang-data+xml > > > > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > > > > 2019-03-22T12:35:00Z > > > > > > > > ... > > > > > > > > > > > > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > > > > 2019-03-22T12:35:00Z > > > > > > > > ... > > > > > > > > > > > > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > > > > 2019-03-22T12:35:00Z > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > With response: > > > > > > > > HTTP/1.1 204 No Content > > > > Date: Thu, 26 Jan 2017 20:56:30 GMT > > > > Server: my-receiver.my-domain.com > > > > > > > > > > > > > > > > Kent // co-author > > > > > > > > > > > > > > _______________________________________________ > > > netconf mailing list > > > netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf ------=_NextPart_000_0145_01D572C6.2CACF080 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwOTI0MTQ1MjM1WjAjBgkqhkiG 9w0BCQQxFgQU/Su/ugdtsxn7gWSKc6GfHQCj8GkwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQAbXwhytpxbqLYLEGVzCT3Kh/0jHB6jSf38WWtMCAAPrESBu0fJGYelMDBK0xWde6CO 7y8t4CaYZV8+mYXKPSNVgo8v23x63z8hzoiOBq54rAEf0UlXtQEjDBfeQUGo6XiktT8NrrNPJgFd Yx2nri4YtXAFI6lU77v6e5O3ok1IcVgo6sWc0Mg/78x84j43drqCM6UCidQ9MkQsPEA83nWJCqNV cKk6Li1zICHHpJ+EH8pxrX6o8N9WuK5T78NFFVuQYlJX2oQ6dmoggzW5Hq/qh6BdEUKUQZ2DC5jb qB2dUhv757J3FkKNShNyLuxX3lWD3WEib+yv3njImMsSRL79AAAAAAAA ------=_NextPart_000_0145_01D572C6.2CACF080-- From nobody Tue Sep 24 09:48:29 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C28120133 for ; Tue, 24 Sep 2019 09:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 uDMI2HTGvZDB for ; Tue, 24 Sep 2019 09:48:24 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD3012013C for ; Tue, 24 Sep 2019 09:48:15 -0700 (PDT) Received: from localhost (h-46-233.A165.priv.bahnhof.se [46.59.46.233]) by mail.tail-f.com (Postfix) with ESMTPSA id 288561AE018A; Tue, 24 Sep 2019 18:48:14 +0200 (CEST) Date: Tue, 24 Sep 2019 18:48:14 +0200 (CEST) Message-Id: <20190924.184814.1432116348522595319.mbj@tail-f.com> To: evoit@cisco.com Cc: mjethanandani@gmail.com, kent@watsen.net, netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <20190924.155545.1143100128662277152.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] HTTPS notifications (draft-ietf-netconf-https-notif) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 16:48:27 -0000 "Eric Voit (evoit)" wrote: > > From: Martin Bjorklund, September 24, 2019 9:56 AM > > > > "Eric Voit (evoit)" wrote: > > > > > > > > > > > From the email I sent Martin on Sep 9th, each POST MAY contain > > > > > more than one notification: > > > > > > > > .... to which I replied: > > > > > > > > I'm not so sure about the streaming though. > > > > Perhaps pipelining is the right mechanism. For "bulk" sending, the > > > > "bundled-message" defined in > draft-ietf-netconf-notification-messages > > > > seems right. > > > > > > > > To clarify: if the client just sends a stream of notifs it becomes a > > > variant of > > > > SSE. The server doesn't know when the stream will end, and thus > > > > cannot simply close the session. You probably want to indicate > > > > end-of-message somehow (like in SSE). And the content type in the > > > > example below cannot be "application/yang-data+xml", since it is not > > > > a valid XML instance document; you'd have to invent a new media type > > to indicate the streaming. > > > > > > > > I think we should stick to simple HTTP where each notif is POSTed, > > > > as in > > > your > > > > diagaram above. With HTTP pipelining you can do: > > > > > > > > ------> establish TCP > > > > ------> establish TLS > > > > ------> Send HTTPS POST message with YANG defined notification 1 > > > > ------> Send HTTPS POST message with YANG defined notification 2 > > > > <-----Send 204 (No Content) for 1 > > > > <-----Send 204 (No Content) for 2 > > > > > > > > ------> Send HTTPS POST message with YANG defined notification 3 > > > > <-----Send 204 (No Content) for 3 > > > > > > > > > > > > If the server wants to send multiple notifs at once, it can use > > > > "bundled- message". > > > > > > This seems a reasonable approach. > > > draft-ietf-netconf-notification-messages > > > has several advantages: > > > (1) can push multiple YANG notifications at once > > > (2) can include the subscription-id in notifications when subscribing > > > to a stream. (Right now including an explicit subscription-id is only > > > available when subscribing to a datastore.) > > > (3) includes methods to discover lost/dropped notifications > > > > > > Two things which would need to be worked: > > > (1) discovering receiver support for bundled notifications. (As some > > > form of understanding/verifying configured receiver support over HTTP > > > is already needed, this is a topic which perhaps can be merged into > > > that.) > > > > This can be configured or auto-detected. For auto-detection, perhaps we > > can use HTTP OPTIONS with the server returning a special body or header to > > indicate capabilities such as this one? > > The method previously proposed for HTTP configured subscriptions was an "OK" > to the POST of a . The "OK" had to be received prior > to sending YANG notifications. If the authors want to build upon > this This is now a WG document, so it should be discussed in the WG. > , I > could see HTTP OPTIONS as a way to provide receiver capabilities. Or perhaps simply do a GET to the same URI as you POST to, and in return get a sx:structure with the capabilities of the server. > Some > discussion about what capabilities would be advertisable as options would be > worthwhile. Yes. > Also worth discussion would be any intersections with > NETCONF/RESTCONF capabilities discovery/exchange. Sure. But this is a new protocol, with a new (limited, hopefully) set of capabilities. /martin > > Eric > > > > (2) Completion of draft-ietf-netmod-yang-data-ext > > > > Yes! IMO it is ready for WGLC; I'll ping the chairs again. > > > > > > /martin > > > > > > > > > > > > Eric > > > > > > > /martin > > > > > > > > > > > > > > > > > > POST /some/path HTTP/1.1 > > > > > Host: my-receiver.my-domain.com > > > domain.com/> > > > > > Content-Type: application/yang-data+xml > > > > > > > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > > > > > 2019-03-22T12:35:00Z > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > > > > > 2019-03-22T12:35:00Z > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > > > > > 2019-03-22T12:35:00Z > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > > > > > > > > With response: > > > > > > > > > > HTTP/1.1 204 No Content > > > > > Date: Thu, 26 Jan 2017 20:56:30 GMT > > > > > Server: my-receiver.my-domain.com > > > > > > > > > > > > > > > > > > > > Kent // co-author > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > netconf mailing list > > > > netconf@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Sep 24 10:50:22 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEF3120874 for ; Tue, 24 Sep 2019 10:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.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 jY1JCb7jNUxZ for ; Tue, 24 Sep 2019 10:50:19 -0700 (PDT) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EC6112084B for ; Tue, 24 Sep 2019 10:50:19 -0700 (PDT) Received: by mail-oi1-x232.google.com with SMTP id o205so2421887oib.12 for ; Tue, 24 Sep 2019 10:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=6pRZX5bqRyBx4YdKrHC/9ENQWN2/ZsYp+c3wAm//G3A=; b=HYKXxtK3kME8YtZC6F2fDzXM8TJczs/lMnDMshAV9yi/PF6Hqt0H6zY9CDKxDsg8Mk uELta061fgboF1VycdLkpVx+FOMBlYcP+wiiPDY1d1FsobQSGglCM72UUVBkOnou4UQM QehtxtlnVa61A3+nVAxqumQhKl8qUo1OeyVt6fNAgee/rxi9AZnCO0CX1cLgItaLZwMp yOEjSWQ0yXLerYAa+5LKRl7lmjqOnwAcYXoYPUn9cQrCWbWBD1Pviun4yqf0clhSw/ef NiVxXyZyc0kHrZhPW3lWUG9Pi8fDQh2Vmu8SGOqfsg3TCguB3I/mSzpd/rroDagqyF5T IQWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=6pRZX5bqRyBx4YdKrHC/9ENQWN2/ZsYp+c3wAm//G3A=; b=GxwkUr2ULvUj13u3dlbVtAW2WRgBmpwFo126vfEUlmvOL8GEkcXy+4w9eCKyfSvnm/ FOkFkyDH2dkBh+9fLC3Ye/UTApIuv4r18RCi2FPjAVPYLy38W3jRVTD3tymjs1qzPGmJ a+B7zRyMyRmv8V8exG79+vHZJ51y0MFlA3fZY85bn/jNSYpV82M8pjPYa5aQp9JHk0nG xYYPrv9hLkrgRRCSunrueklYerK7cXc4FBv4AxCfAme72E30lrGSUxO3mJ4Bshu7rtwe +XZIWTwA7gf0wLYKZCCeo8IoalZDpWSsS3lfnCugZ5BXgA/05qLZfs4fHD5TZNs3En4w 8f7w== X-Gm-Message-State: APjAAAUoNFHhwgQuIjrHUQOQPVokE2EPUXbUpGabGE/u12KMC5BHED6k oh0cnTYjuFC5JJ3rS5PjW46RmM18yYM= X-Google-Smtp-Source: APXvYqw4Bh69SHbDiNNVoewVzPfqHdf7Us/0JHPUkDIGtQGH8sC89q4ovV+fz7NM4a+RYIBkabvZmQ== X-Received: by 2002:aca:d408:: with SMTP id l8mr1177041oig.113.1569347418479; Tue, 24 Sep 2019 10:50:18 -0700 (PDT) Received: from [100.170.247.251] ([172.56.7.80]) by smtp.gmail.com with ESMTPSA id 91sm794524otn.36.2019.09.24.10.50.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Sep 2019 10:50:17 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-9C389CD5-EBD6-441A-BA91-7C7E1177B336 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) X-Apple-Base-Url: x-msg://39/ X-Universally-Unique-Identifier: 78A4C0CB-970B-433E-8174-EDA3995F84EE X-Apple-Mail-Remote-Attachments: YES From: Mahesh Jethanandani X-Mailer: iPhone Mail (16F203) In-Reply-To: X-Apple-Windows-Friendly: 1 Date: Tue, 24 Sep 2019 19:50:14 +0200 Content-Transfer-Encoding: 7bit X-Apple-Mail-Signature: Message-Id: <4F49DF08-B7FC-4EBD-9D6B-7BC329E50334@gmail.com> References: To: Netconf Archived-At: Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 17:50:22 -0000 --Apple-Mail-9C389CD5-EBD6-441A-BA91-7C7E1177B336 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable We were supposed to have closed on the WGLC today. However, between the docu= ment becoming a WG item and it going into LC, we have not received too many c= omments on the draft. As such, we are extending the LC by another week. Plea= se review the draft and provide any comments you might have. Mahesh & Kent (as co-chairs) > On Sep 10, 2019, at 3:39 PM, Mahesh Jethanandani = wrote: >=20 > Authors have published -04 version of the draft, which addresses comments t= hey received in IETF 105. If you provided comments please check to make sure= your comments have been addressed. At this point, the authors believe that t= he document is ready for WGLC. >=20 > This therefore starts a two week LC, ending on September 24th. Please prov= ide any technical comments you might have on the document. If you believe th= e document is not ready for LC, please state your reasons. >=20 > We will issue a IPR poll separately.=20 >=20 > Mahesh & Kent (as co-chairs) --Apple-Mail-9C389CD5-EBD6-441A-BA91-7C7E1177B336 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
We were supposed to have closed on the WGLC today. However, betwee= n the document becoming a WG item and it going into LC, we have not received= too many comments on the draft. As such, we are extending the LC by another= week. Please review the draft and provide any comments you might have.
=
Mahesh & Kent (as co-chairs)


On Sep 10, 2019, at 3:39 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:

Authors have published -04 version o= f the draft, which addresses comments they received in IETF 105. If you prov= ided comments please check to make sure your comments have been addressed. A= t this point, the authors believe that the document is ready for WGLC.

This therefore starts a two w= eek LC, ending on September 24th. Please provide any technical comments you m= ight have on the document. If you believe the document is not ready for LC, p= lease state your reasons.

We will issue a IPR poll separately. 

Mahesh & Kent (as co-chairs)




= --Apple-Mail-9C389CD5-EBD6-441A-BA91-7C7E1177B336-- From nobody Tue Sep 24 13:02:16 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D0F1208F2 for ; Tue, 24 Sep 2019 13:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 (2048-bit key) header.d=akamai.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 9bAoARNofM3Q for ; Tue, 24 Sep 2019 13:02:12 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 A852E120110 for ; Tue, 24 Sep 2019 13:02:10 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8OJrX5f030411 for ; Tue, 24 Sep 2019 21:02:04 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Ytb+3t/O1L1Hyc2mh5Gw7Z2BAdYFKTpbckxlbOulFBA=; b=mEKiIuataZ9qO06wXya7VAAi4OVMc255QUq4UAdqdovsUiZ7IWTgJvqkNU/HuKuXSCMt kFowdqK3JKBdyLnTbo+dhUiPl/qoq7beWZRLygdAO5mGJAO47iNK5oSB2NFrDMhPLy3J r4RDGVhxTUuIouEB5j5nztMjprbL8i0gNmddP5z3tjODem2G2mgG2qeFEQty3U0oaHh5 XPhl2uqa+epFau1Xvl6Igjm1NWegc0+JqktswfiJTOImm3afjBx8r1wSH6kwwq6ki86q r/j33qZCoG4FkuHqLrTSv9wN4NA/J8Mf7GeNZo8+a9YjFx6NSsx4x9lGhl+j4IpnS0wU iA== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2v73q9mjb5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 24 Sep 2019 21:02:03 +0100 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x8OK22Oq026942 for ; Tue, 24 Sep 2019 16:02:03 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint6.akamai.com with ESMTP id 2v73vphr9e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 24 Sep 2019 16:02:02 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Sep 2019 16:02:02 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Tue, 24 Sep 2019 16:02:01 -0400 From: "Salz, Rich" To: "Holland, Jake" CC: "netconf@ietf.org" Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxGVhFlbERW30moo9Q8WhnpJqc7VCKA Date: Tue, 24 Sep 2019 20:02:01 +0000 Message-ID: References: <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <20190918163657.4pxh5jddxgrir5oh@anna.jacobs.jacobs-university.de> <034101d572b4$cf1901e0$4001a8c0@gateway.2wire.net> In-Reply-To: <034101d572b4$cf1901e0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.220] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-24_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909240164 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-09-24_07:2019-09-23,2019-09-24 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxlogscore=999 clxscore=1015 priorityscore=1501 lowpriorityscore=0 adultscore=0 spamscore=0 impostorscore=0 bulkscore=0 mlxscore=0 malwarescore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909240164 Archived-At: Subject: [netconf] FW: crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 20:02:15 -0000 SmFrZSwNCg0KQXMgdGhlIGF1dGhvciBvZiB0aGUgZHJhZnQgcmVmZXJlbmNlZCBiZWxvdywgZG8g eW91IGNhcmUgdG8gY29tbWVudD8NCg0KVGhlIGNyeXB0by10eXBlcyBkb2N1bWVudCBpbiB0aGUg bmV0Y29uZiBXRyBpcyB1bmRlcmdvaW5nIHNvbWUgcHJldHR5IGRyYXN0aWMgc3VyZ2VyeS4NCg0K DQrvu79PbiA5LzI0LzE5LCA0OjUwIEFNLCAidG9tIHBldGNoIiA8aWV0ZmNAYnRjb25uZWN0LmNv bT4gd3JvdGU6DQoNCiAgICBHb2luZyBiYWNrIGEgYml0LCBzaW5jZSB0aGlzIGlzIGEgbW9yZSBn ZW5lcmljIGNvbW1lbnQsIEkgZ2V0IGENCiAgICBkaWZmZXJlbnQsIHNpbXBsZXIgcGVyc3BlY3Rp dmUgaW4NCiAgICBkcmFmdC1qaG9sbGFuZC10YXBzLWFwaS15YW5nDQogICAgd2hpY2ggaGFzIG1l IHdvbmRlcmluZyBqdXN0IGhvdyBjb21wbGljYXRlZCB0aGlzIG5lZWRzIHRvIGJlIGZvciBpdCB0 bw0KICAgIGJlIHVzZWZ1bCBpbiBvdGhlciBXR3MuDQogICAgDQogICAgVGhlIEktRCBkZWZpbmVz DQogICAgICBpZGVudGl0eSBzZWN1cml0eS1hbGdvcml0aG0ge2Rlc2NyaXB0aW9uICJCYXNlIGlk ZW50aXR5IGZvciBzZWN1cml0eQ0KICAgIGFsZ29yaXRobXMuIg0KICAgICAgaWRlbnRpdHkgY2lw aGVyLXN1aXRlIHsgYmFzZSBzZWN1cml0eS1hbGdvcml0aG07ZGVzY3JpcHRpb24gIkJhc2UNCiAg ICBpZGVudGl0eSBmb3Igc2VjdXJpdHkgY2lwaGVyIHN1aXRlcy4iOw0KICAgICAgaWRlbnRpdHkg c2lnbmF0dXJlLWFsZ29yaXRobSB7YmFzZSBzZWN1cml0eS1hbGdvcml0aG07DQogICAgZGVzY3Jp cHRpb24gIkJhc2UgaWRlbnRpdHkgZm9yIHNlY3VyaXR5IHNpZ25hdHVyZSBhbGdvcml0aG1zLiI7 DQogICAgICBpZGVudGl0eSBlZDI1NTE5IHtiYXNlIHNpZ25hdHVyZS1hbGdvcml0aG07DQogICAg ICBpZGVudGl0eSBUTFNfRUNESEVfRUNEU0FfV0lUSF9DSEFDSEEyMF9QT0xZMTMwNV9TSEEyNTYg ew0KICAgICAgICBiYXNlIGNpcGhlci1zdWl0ZTsNCiAgICANCiAgICBhbmQNCiAgICANCiAgICAg IGdyb3VwaW5nIHNlY3VyaXR5LWNyZWRlbnRpYWxzIHsNCiAgICAgICAgbGVhZiBpZGVudGl0eSB7 IHR5cGUgc3RyaW5nOw0KICAgICAgICBsZWFmIHRydXN0LWNhIHsgdHlwZSBzdHJpbmc7DQogICAg ICAgIGxlYWYgYWxnb3JpdGhtIHsgdHlwZSBpZGVudGl0eXJlZiB7YmFzZSBzZWN1cml0eS1hbGdv cml0aG07DQogICAgICAgIGxlYWYgcHJlLXNoYXJlZC1rZXkgeyB0eXBlIHN0cmluZzsNCiAgICAg ICAgbGVhZiBwcml2YXRlLWtleSB7IHR5cGUgc3RyaW5nOw0KICAgICAgICBsZWFmIHByaXZhdGUt a2V5LWNhbGxiYWNrLWhhbmRsZSB7dHlwZSBzdHJpbmc7DQogICAgICAgIGxlYWYgcHVibGljLWtl eSB7dHlwZSBzdHJpbmc7DQogICAgDQogICAgKE5vIFNTSCBidXQgdGhhdCBkb2VzIG5vdCBzdXJw cmlzZSBtZTotKQ0KICAgIA0KICAgIEFnYWluIGEgbW9yZSBnZW5lcmFsIGNvbW1lbnQsIHRoZSBJ RVRGIG9mdGVuIHN0YXJ0cyBzaW1wbGUgYW5kIGFkZHMgbG90cw0KICAgIGxhdGVyLCB3aGljaCBz b21ldGltZXMgZ29lcyB3cm9uZyBiZWNhdXNlIG5vIGFsbG93YW5jZSB3YXMgbWFkZSBmb3INCiAg ICBzbG90dGluZyBpbiBleHRyYXMsIGJ1dCBhbiBhcHByb2FjaCB3aGljaCwgSSB0aGluaywgbW9y ZSBvZnRlbiBsZWFkcyB0bw0KICAgIHN1Y2Nlc3NmdWwgYWRvcHRpb24uDQogICAgDQogICAgVGh1 cyB3aWxsIFRBUFMgY29uc2lkZXIgdXNpbmcNCiAgICBkcmFmdC1pZXRmLW5ldGNvbmYtY3J5cHRv LXR5cGVzDQogICAgb3Igd2lsbCB0aGV5IFJZTz8NCiAgICANCiAgICBUb20gUGV0Y2gNCiAgICAN CiAgICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQogICAgRnJvbTogPFNjaMO2bnfDpGxk ZXI+OyAiSsO8cmdlbiIgPEouU2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4NCiAg ICBUbzogIlJvYiBXaWx0b24gKHJ3aWx0b24pIiA8cndpbHRvbkBjaXNjby5jb20+DQogICAgQ2M6 ICJSdXNzIEhvdXNsZXkiIDxob3VzbGV5QHZpZ2lsc2VjLmNvbT47IDxuZXRjb25mQGlldGYub3Jn PjsgIlNlYW4NCiAgICBUdXJuZXIiIDxzZWFuQHNuM3JkLmNvbT47ICJSaWZhYXQgU2hla2gtWXVz ZWYiIDxyaWZhYXQuaWV0ZkBnbWFpbC5jb20+DQogICAgU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1i ZXIgMTgsIDIwMTkgNTozNiBQTQ0KICAgIA0KICAgID4gT24gV2VkLCBTZXAgMTgsIDIwMTkgYXQg MDM6Mzc6MTRQTSArMDAwMCwgUm9iIFdpbHRvbiAocndpbHRvbikgd3JvdGU6DQogICAgPiA+ID5G cm9tIHRoZSBnaXN0IG9mIHRoZSBkaXNjdXNzaW9uLCB0aGUgcHVuY2ggbGlzdCBhcHBlYXJzIHRv IGJlOg0KICAgID4gPg0KICAgID4gPiAtIHJldmVydCBiYWNrIHRvIHVzaW5nIGlkZW50aXRpZXMs IGFzIHRoZXkgd2VyZSBpbiB0aGUgLTA4IHJldmlzaW9uLg0KICAgID4gPiAtIG9ubHkgZGVmaW5l IGJhc2UgaWRlbnRpdGllcyBmb3Igd2hhdCdzIG5lZWRlZCBpbW1lZGlhdGVseSBmb3IgVExTDQog ICAgYW5kIFNTSCBhbmQga2V5c3RvcmUga2V5LWVuY3J5cHRpb24uDQogICAgPiA+IC0gZGVmaW5l IHRoZXNlIGJhc2UgaWRlbnRpdGllcyBpbiBkaXN0aW5jdCBZQU5HIG1vZHVsZXMNCiAgICA+ID4g LSBoYXZlIGVhY2ggaWRlbnRpdHkncyBkZXNjcmlwdGlvbiBzdGF0ZW1lbnQgaW5kaWNhdGUgd2hh dCB0aGUNCiAgICBiaW5hcnkga2V5IGRhdGEgaXMgZW5jb2RlZC4NCiAgICA+ID4gW1JXXQ0KICAg ID4gPiBJIHRoaW5rIHRoYXQgdGhpcyBtYXRjaGVzIG15IHZpZXcsIGV4Y2VwdCBmb3IgImRlZmlu ZSB0aGVzZSBiYXNlDQogICAgaWRlbnRpdGllcyBpbiBkaXN0aW5jdCBZQU5HIG1vZHVsZXMiLiAg SSBkb24ndCBmZWVsIHBhcnRpY3VsYXJseQ0KICAgIHN0cm9uZ2x5IGFib3V0IHRoaXMsIGJ1dCBJ IHdhcyB0aGlua2luZyB0aGF0IHRoZSBiYXNlIGlkZW50aXRpZXMgd291bGQNCiAgICBzdGlsbCBi ZSBkZWZpbmVkIGluIGNyeXB0by10eXBlcy55YW5nLCB3aGljaCBtaWdodCBoZWxwIGtlZXAgdGhl IGltcG9ydA0KICAgIHJlZmVyZW5jZXMgc2ltcGxlLg0KICAgID4NCiAgICA+IEkgdGVuZCB0byBh Z3JlZSB0aGF0IHNvbWV0aW1lcyBsZXNzIG1vZHVsZXMgaXMgbW9yZS4gRm9yIG1lLCB0aGUNCiAg ICA+IHByb2JsZW0gaXMgbGlrZWx5IG1vcmUgdGhhdCBJIGFtIG5vdCBlbnRpcmVseSBzdXJlIHdo YXQgdGhlIHByb3Blcg0KICAgID4gYmFzZSB0eXBlcyB3b3VsZCBiZSwgd2hpY2ggbWF5IGRlcGVu ZCBvbiB3aGF0IGV4YWN0bHkgdGhleSBhcmUgdXNlZA0KICAgID4gZm9yLiBJIGd1ZXNzIEkgd2Fp dCB1bnRpbCBJIHNlZSB0aGUgZGVzY3JpcHRpb24gdGV4dC4uLg0KICAgID4NCiAgICA+ID4gQSBi aXQgc2VwYXJhdGUgZnJvbSB0aGUgYWJvdmUsIGJ1dCBzdGlsbCBpbiBtaW5kOg0KICAgID4gPg0K ICAgID4gPiAgIC0gc3BlY2lmeSB0aGF0IGFsbCBUTFMgcHVibGljLWtleXMgYXJlIGEgREVSLWVu Y29kZWQNCiAgICBTdWJqZWN0UHVibGljS2V5SW5mbyBzdHJ1Y3R1cmUNCiAgICA+ID4gICAtIHNw ZWNpZnkgdGhhdCBhbGwgU1NIIHB1YmxpYy1rZXlzIGFyZSBhICJzc2gtcHVibGljLWtleS10eXBl Ig0KICAgIHR5cGUgKHNlZSBiZWxvdykNCiAgICA+ID4gICAtIHNwZWNpZnkgdGhhdCBhbGwgZW5j cnlwdGVkIHN5bW1ldHJpYyBrZXlzIGFyZSBhIERFUi1lbmNvZGVkDQogICAgT25lU3ltbWV0cmlj S2V5IHN0cnVjdHVyZQ0KICAgID4gPiAgIC0gc3BlY2lmeSB0aGF0IGFsbCBlbmNyeXB0ZWQgYXN5 bW1ldHJpYyBrZXlzIGFyZSBhIERFUi1lbmNvZGVkDQogICAgT25lQXN5bW1ldHJpY0tleSBzdHJ1 Y3R1cmUNCiAgICA+DQogICAgPiBJIHdvdWxkIGNoZWNrIHdoYXQgaXMgY29tbW9ubHkgdXNlZCBp biBleGlzdGluZyBjb25maWd1cmF0aW9uDQogICAgPiBpbnRlcmZhY2VzLiBXZSBhcmUgbm90IGlu dmVudGluZyB0aGUgd2hlZWwgaGVyZS4gQW5kIHdoYXRldmVyIHdlDQogICAgPiBkZWZpbmUgYmV0 dGVyIGlzIHVzYWJsZSB3aXRoIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBhbmQgdG9vbHMuDQog ICAgPg0KICAgID4gPiBUaGUgInNzaC1wdWJsaWMta2V5IiB0eXBlIHdvdWxkIGJlIGRlZmluZWQg YXM6DQogICAgPiA+DQogICAgPiA+ICAgICAgdHlwZWRlZiBzc2gtcHVibGljLWtleS10eXBlIHsN CiAgICA+ID4gICAgICAgICAgdHlwZSBiaW5hcnk7DQogICAgPiA+ICAgICAgICAgIG1hbmRhdG9y eSB0cnVlOw0KICAgID4gPiAgICAgICAgICBkZXNjcmlwdGlvbg0KICAgID4gPiAgICAgICAgICAg ICJUaGUgYmluYXJ5IHB1YmxpYyBrZXkgZGF0YSBmb3IgdGhpcyBTU0gga2V5LCBhcw0KICAgID4g PiAgICAgICAgICAgICBzcGVjaWZpZWQgYnkgUkZDIDQyNTMsIFNlY3Rpb24gNi42LCBpLmUuOg0K ICAgID4gPg0KICAgID4gPiAgICAgICAgICAgICAgIHN0cmluZyAgICBjZXJ0aWZpY2F0ZSBvciBw dWJsaWMga2V5IGZvcm1hdA0KICAgID4gPiAgICAgICAgICAgICAgICAgICAgICAgICBpZGVudGlm aWVyDQogICAgPiA+ICAgICAgICAgICAgICAgYnl0ZVtuXSAgIGtleS9jZXJ0aWZpY2F0ZSBkYXRh LiI7DQogICAgPiA+ICAgICAgICAgIHJlZmVyZW5jZQ0KICAgID4gPiAgICAgICAgICAgICJSRkMg NDI1MzogVGhlIFNlY3VyZSBTaGVsbCAoU1NIKSBUcmFuc3BvcnQNCiAgICA+ID4gICAgICAgICAg ICAgICAgICAgICAgIExheWVyIFByb3RvY29sIjsNCiAgICA+ID4gICAgICAgICAgIH0NCiAgICA+ DQogICAgPiBUaGUgU1NIIGltcGxlbWVudGF0aW9ucyB0aGF0IEkgdXNlIGhhdmUgdGhlIGJpbmFy eSBrZXkgZGF0YSByZW5kZXJlZA0KICAgID4gaW4gQVNDSUkuIEluIGZhY3QsIHRoZSB3aG9sZSBr ZXkgcmVjb3JkIGlzIHJlbmRlcmVkIGluIEFTQ0lJLiBJDQogICAgPiBzdHJvbmdseSBzdWdnZXN0 IHRvIHVzZSBmb3JtYXRzIHRoYXQgYXJlIHdlbGwgZXN0YWJsaXNoZWQuDQogICAgPg0KICAgID4g L2pzDQogICAgPg0KICAgID4gLS0NCiAgICA+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAg ICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQogICAgPiBQaG9uZTogKzQ5IDQyMSAy MDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQog ICAgPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMt dW5pdmVyc2l0eS5kZS8+DQogICAgPg0KICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCiAgICA+IG5ldGNvbmYgbWFpbGluZyBsaXN0DQogICAgPiBu ZXRjb25mQGlldGYub3JnDQogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldGNvbmYNCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KICAgIG5ldGNvbmYgbWFpbGluZyBsaXN0DQogICAgbmV0Y29uZkBpZXRm Lm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0K ICAgIA0KDQo= From nobody Tue Sep 24 13:39:24 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B0412094D; Tue, 24 Sep 2019 13:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 (2048-bit key) header.d=akamai.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 Vs6cEVggxuB1; Tue, 24 Sep 2019 13:39:19 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 2AB50120983; Tue, 24 Sep 2019 13:38:36 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8OKQWP1007455; Tue, 24 Sep 2019 21:38:35 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=JQqKUw8KtzlLSzYfTHxZ6AyGItcnRIjI3vc/UbyUYgQ=; b=bSdFa7WMVOCsZQOnPSqleJnQTcNO9uuut/JfaxCUqVfDBIk+fafcAK0c4m5infQKG/bP 83mgkmZoPJh4LJDc944gOIVW2srgWloylZlMTeeXIzT0Favb/yrLX6rsi7URXeo7hcVq wa7wTWnsDrKF1/2U8CQpKssD5Kz+DNSufKpQ4GlAoEGak50QhYIKN/UaBGUjqQxGcBpq 88fGiWm5vlqg7vRY/xdNgoGLxy4sIrd68PtN5++Yb8rW3ObczSPCLXiqwKGHr/kCdLJF X47U5EmWfbmqDtxkor4KbEv5WWZ4Dcd/Io/42h+BESOjceRdqwEUMAahQjS3ZH/lBXgO 9Q== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2v73qb5drw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 24 Sep 2019 21:38:35 +0100 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x8OKXCh3024331; Tue, 24 Sep 2019 13:38:34 -0700 Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint5.akamai.com with ESMTP id 2v73vp29sh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 24 Sep 2019 13:38:34 -0700 Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.27.104) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Sep 2019 15:38:33 -0500 Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.6.134]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.6.134]) with mapi id 15.00.1473.005; Tue, 24 Sep 2019 15:38:32 -0500 From: "Holland, Jake" To: "Salz, Rich" CC: "netconf@ietf.org" , "taps@ietf.org" Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxGVhFlbERW30moo9Q8WhnpJqc7VCKA///orIA= Date: Tue, 24 Sep 2019 20:38:31 +0000 Message-ID: <3F71FEE6-3679-4482-B210-6585A15E0BA7@akamai.com> References: <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <20190918163657.4pxh5jddxgrir5oh@anna.jacobs.jacobs-university.de> <034101d572b4$cf1901e0$4001a8c0@gateway.2wire.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.114.140] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-24_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909240167 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-09-24_07:2019-09-23,2019-09-24 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 phishscore=0 mlxscore=0 adultscore=0 mlxlogscore=999 impostorscore=0 lowpriorityscore=0 malwarescore=0 spamscore=0 clxscore=1011 bulkscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909240167 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 20:39:23 -0000 KCt0YXBzKQ0KSGksDQoNClRoYW5rcyBmb3IgdGFraW5nIGEgbG9vayBhdCB0aGF0IG1vZGVsLCBU b20uICBJJ2xsIGdpdmUganVzdCBhDQpsaXR0bGUgYmFja2dyb3VuZDoNCg0KVGhlIGN1cnJlbnQg dGFwcy1hcGkgc3RydWN0dXJlIHdhcyBkcml2ZW4gYmFzaWNhbGx5IGJ5IGFuIGF0dGVtcHQgdG8N CnN1cHBvcnQgdGhlIGV4YW1wbGVzIGdpdmVuIGluIHRoZSB0YXBzLWludGVyZmFjZSBkcmFmdCwg Zm9yIGluc3RhbmNlDQppbiBzZWN0aW9uIDUuMy4xOg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtdGFwcy1pbnRlcmZhY2UtMDQjc2VjdGlvbi01LjMuMQ0KDQpJIGRpZG4n dCBkbyBtdWNoIChvciBhbnk/IGRvbid0IHJlY2FsbC4uLikgb2YgYSBzZWFyY2ggZm9yIGNyeXB0 bw0KbW9kZWxzIGJlZm9yZSB0aHJvd2luZyB0b2dldGhlciB0aGUgZWFybHkgaWV0Zi10YXBzLWFw aS55YW5nIGRyYWZ0cywNCmluY2x1ZGluZyB0aGUgc2VjdXJpdHkgY29uZmlnIHN0dWZmLiAgSSBt b3N0bHkgd29ya2VkIG9mZiB0aGUgQVBJDQpleGFtcGxlcywgd2l0aCBpbnRlbnQgdG8gbG9vayBm b3IgYSBtb3JlIHNlcmlvdXMgYW5zd2VyIGxhdGVyIGFzDQp3ZSB0cnkgdG8gaW50ZWdyYXRlIHRo ZSBzZWN1cmUgY29ubmVjdGlvbiBzdXBwb3J0IGludG8gYSByZWZlcmVuY2UNCmltcGxlbWVudGF0 aW9uIG9yIDIuDQoNCldoYXQncyB0aGVyZSBub3cgaGFzbid0IGJlZW4gdGhyb3VnaCBhbnkga2lu ZCBvZiBzZWN1cml0eSByZXZpZXcsIGFuZA0KSSdkIGNoYXJhY3Rlcml6ZSBpdCBhcyBhIHBsYWNl aG9sZGVyLCBhdCB0aGUgbW9tZW50LiAgKFRoZSB0YXBzIHVzZSBvZg0KeWFuZyBpcyBzdGlsbCBy ZWxhdGl2ZWx5IGltbWF0dXJlLikNCg0KSSdkIGJlIHZlcnkgZ3JhdGVmdWwgZm9yIGEgZ3JvdXBp bmcgb3Igb2JqZWN0IG9mIHNvbWUga2luZCB0aGF0IEkNCmNvdWxkIHB1bGwgaW4gYnkgaW1wb3J0 IGZyb20gYW5vdGhlciBtb2R1bGUsIGFuZCB3b3VsZCBzdXBwb3J0DQp1c2luZyBpdCBpbiB0YXBz LWFwaS15YW5nIGlmIHdlIGNhbiB1c2UgaXQgdG8gZG8gd2hhdCB3ZSBuZWVkICh3aGljaA0KaXMg dG8gY29uZmlndXJlIGNvbm5lY3Rpb24gZW5kcG9pbnRzIHRvIGFsbG93IHNlY3VyZWQgY29ubmVj dGlvbnMsDQpmb3IgZWl0aGVyIGNsaWVudCBvciBzZXJ2ZXIgZW5kcG9pbnRzKS4gIEkgdGhpbmsg dGhhdCB3b3VsZCBtYWtlIGZvcg0KYSB2ZXJ5IGhlbHBmdWwgaW1wcm92ZW1lbnQuDQoNClBhcnQg b2YgdGhlIHBvaW50IG9mIHVzaW5nIHlhbmcgaW4gdGFwcyB3YXMgdG8gYmUgYWJsZSB0byBiZXR0 ZXIgZXhwbG9pdA0KeWFuZyB3b3JrIGZyb20gb3RoZXIgd2dzLCBhbmQgdGhpcyB3b3VsZCBiZSBh biBleGNlbGxlbnQgb3Bwb3J0dW5pdHkgdG8NCnB1dCB0aGF0IGludG8gcHJhY3RpY2UsIEkgdGhp bmsuICBTbyBJIHdvdWxkIGJlIHZlcnkgZGVsaWdodGVkIHRvIGltcG9ydA0KYSBtb2RlbCB0aGF0 IGRvZXMgdGhpcyByaWdodC4NCg0KQmVzdCwNCkpha2UNCg0K77u/T24gMjAxOS0wOS0yNCwgMTM6 MDIsICJTYWx6LCBSaWNoIiA8cnNhbHpAYWthbWFpLmNvbT4gd3JvdGU6DQoNCkpha2UsDQoNCkFz IHRoZSBhdXRob3Igb2YgdGhlIGRyYWZ0IHJlZmVyZW5jZWQgYmVsb3csIGRvIHlvdSBjYXJlIHRv IGNvbW1lbnQ/DQoNClRoZSBjcnlwdG8tdHlwZXMgZG9jdW1lbnQgaW4gdGhlIG5ldGNvbmYgV0cg aXMgdW5kZXJnb2luZyBzb21lIHByZXR0eSBkcmFzdGljIHN1cmdlcnkuDQoNCg0KT24gOS8yNC8x OSwgNDo1MCBBTSwgInRvbSBwZXRjaCIgPGlldGZjQGJ0Y29ubmVjdC5jb20+IHdyb3RlOg0KDQog ICAgR29pbmcgYmFjayBhIGJpdCwgc2luY2UgdGhpcyBpcyBhIG1vcmUgZ2VuZXJpYyBjb21tZW50 LCBJIGdldCBhDQogICAgZGlmZmVyZW50LCBzaW1wbGVyIHBlcnNwZWN0aXZlIGluDQogICAgZHJh ZnQtamhvbGxhbmQtdGFwcy1hcGkteWFuZw0KICAgIHdoaWNoIGhhcyBtZSB3b25kZXJpbmcganVz dCBob3cgY29tcGxpY2F0ZWQgdGhpcyBuZWVkcyB0byBiZSBmb3IgaXQgdG8NCiAgICBiZSB1c2Vm dWwgaW4gb3RoZXIgV0dzLg0KICAgIA0KICAgIFRoZSBJLUQgZGVmaW5lcw0KICAgICAgaWRlbnRp dHkgc2VjdXJpdHktYWxnb3JpdGhtIHtkZXNjcmlwdGlvbiAiQmFzZSBpZGVudGl0eSBmb3Igc2Vj dXJpdHkNCiAgICBhbGdvcml0aG1zLiINCiAgICAgIGlkZW50aXR5IGNpcGhlci1zdWl0ZSB7IGJh c2Ugc2VjdXJpdHktYWxnb3JpdGhtO2Rlc2NyaXB0aW9uICJCYXNlDQogICAgaWRlbnRpdHkgZm9y IHNlY3VyaXR5IGNpcGhlciBzdWl0ZXMuIjsNCiAgICAgIGlkZW50aXR5IHNpZ25hdHVyZS1hbGdv cml0aG0ge2Jhc2Ugc2VjdXJpdHktYWxnb3JpdGhtOw0KICAgIGRlc2NyaXB0aW9uICJCYXNlIGlk ZW50aXR5IGZvciBzZWN1cml0eSBzaWduYXR1cmUgYWxnb3JpdGhtcy4iOw0KICAgICAgaWRlbnRp dHkgZWQyNTUxOSB7YmFzZSBzaWduYXR1cmUtYWxnb3JpdGhtOw0KICAgICAgaWRlbnRpdHkgVExT X0VDREhFX0VDRFNBX1dJVEhfQ0hBQ0hBMjBfUE9MWTEzMDVfU0hBMjU2IHsNCiAgICAgICAgYmFz ZSBjaXBoZXItc3VpdGU7DQogICAgDQogICAgYW5kDQogICAgDQogICAgICBncm91cGluZyBzZWN1 cml0eS1jcmVkZW50aWFscyB7DQogICAgICAgIGxlYWYgaWRlbnRpdHkgeyB0eXBlIHN0cmluZzsN CiAgICAgICAgbGVhZiB0cnVzdC1jYSB7IHR5cGUgc3RyaW5nOw0KICAgICAgICBsZWFmIGFsZ29y aXRobSB7IHR5cGUgaWRlbnRpdHlyZWYge2Jhc2Ugc2VjdXJpdHktYWxnb3JpdGhtOw0KICAgICAg ICBsZWFmIHByZS1zaGFyZWQta2V5IHsgdHlwZSBzdHJpbmc7DQogICAgICAgIGxlYWYgcHJpdmF0 ZS1rZXkgeyB0eXBlIHN0cmluZzsNCiAgICAgICAgbGVhZiBwcml2YXRlLWtleS1jYWxsYmFjay1o YW5kbGUge3R5cGUgc3RyaW5nOw0KICAgICAgICBsZWFmIHB1YmxpYy1rZXkge3R5cGUgc3RyaW5n Ow0KICAgIA0KICAgIChObyBTU0ggYnV0IHRoYXQgZG9lcyBub3Qgc3VycHJpc2UgbWU6LSkNCiAg ICANCiAgICBBZ2FpbiBhIG1vcmUgZ2VuZXJhbCBjb21tZW50LCB0aGUgSUVURiBvZnRlbiBzdGFy dHMgc2ltcGxlIGFuZCBhZGRzIGxvdHMNCiAgICBsYXRlciwgd2hpY2ggc29tZXRpbWVzIGdvZXMg d3JvbmcgYmVjYXVzZSBubyBhbGxvd2FuY2Ugd2FzIG1hZGUgZm9yDQogICAgc2xvdHRpbmcgaW4g ZXh0cmFzLCBidXQgYW4gYXBwcm9hY2ggd2hpY2gsIEkgdGhpbmssIG1vcmUgb2Z0ZW4gbGVhZHMg dG8NCiAgICBzdWNjZXNzZnVsIGFkb3B0aW9uLg0KICAgIA0KICAgIFRodXMgd2lsbCBUQVBTIGNv bnNpZGVyIHVzaW5nDQogICAgZHJhZnQtaWV0Zi1uZXRjb25mLWNyeXB0by10eXBlcw0KICAgIG9y IHdpbGwgdGhleSBSWU8/DQogICAgDQogICAgVG9tIFBldGNoDQogICAgDQogICAgLS0tLS0gT3Jp Z2luYWwgTWVzc2FnZSAtLS0tLQ0KICAgIEZyb206IDxTY2jDtm53w6RsZGVyPjsgIkrDvHJnZW4i IDxKLlNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+DQogICAgVG86ICJSb2IgV2ls dG9uIChyd2lsdG9uKSIgPHJ3aWx0b25AY2lzY28uY29tPg0KICAgIENjOiAiUnVzcyBIb3VzbGV5 IiA8aG91c2xleUB2aWdpbHNlYy5jb20+OyA8bmV0Y29uZkBpZXRmLm9yZz47ICJTZWFuDQogICAg VHVybmVyIiA8c2VhbkBzbjNyZC5jb20+OyAiUmlmYWF0IFNoZWtoLVl1c2VmIiA8cmlmYWF0Lmll dGZAZ21haWwuY29tPg0KICAgIFNlbnQ6IFdlZG5lc2RheSwgU2VwdGVtYmVyIDE4LCAyMDE5IDU6 MzYgUE0NCiAgICANCiAgICA+IE9uIFdlZCwgU2VwIDE4LCAyMDE5IGF0IDAzOjM3OjE0UE0gKzAw MDAsIFJvYiBXaWx0b24gKHJ3aWx0b24pIHdyb3RlOg0KICAgID4gPiA+RnJvbSB0aGUgZ2lzdCBv ZiB0aGUgZGlzY3Vzc2lvbiwgdGhlIHB1bmNoIGxpc3QgYXBwZWFycyB0byBiZToNCiAgICA+ID4N CiAgICA+ID4gLSByZXZlcnQgYmFjayB0byB1c2luZyBpZGVudGl0aWVzLCBhcyB0aGV5IHdlcmUg aW4gdGhlIC0wOCByZXZpc2lvbi4NCiAgICA+ID4gLSBvbmx5IGRlZmluZSBiYXNlIGlkZW50aXRp ZXMgZm9yIHdoYXQncyBuZWVkZWQgaW1tZWRpYXRlbHkgZm9yIFRMUw0KICAgIGFuZCBTU0ggYW5k IGtleXN0b3JlIGtleS1lbmNyeXB0aW9uLg0KICAgID4gPiAtIGRlZmluZSB0aGVzZSBiYXNlIGlk ZW50aXRpZXMgaW4gZGlzdGluY3QgWUFORyBtb2R1bGVzDQogICAgPiA+IC0gaGF2ZSBlYWNoIGlk ZW50aXR5J3MgZGVzY3JpcHRpb24gc3RhdGVtZW50IGluZGljYXRlIHdoYXQgdGhlDQogICAgYmlu YXJ5IGtleSBkYXRhIGlzIGVuY29kZWQuDQogICAgPiA+IFtSV10NCiAgICA+ID4gSSB0aGluayB0 aGF0IHRoaXMgbWF0Y2hlcyBteSB2aWV3LCBleGNlcHQgZm9yICJkZWZpbmUgdGhlc2UgYmFzZQ0K ICAgIGlkZW50aXRpZXMgaW4gZGlzdGluY3QgWUFORyBtb2R1bGVzIi4gIEkgZG9uJ3QgZmVlbCBw YXJ0aWN1bGFybHkNCiAgICBzdHJvbmdseSBhYm91dCB0aGlzLCBidXQgSSB3YXMgdGhpbmtpbmcg dGhhdCB0aGUgYmFzZSBpZGVudGl0aWVzIHdvdWxkDQogICAgc3RpbGwgYmUgZGVmaW5lZCBpbiBj cnlwdG8tdHlwZXMueWFuZywgd2hpY2ggbWlnaHQgaGVscCBrZWVwIHRoZSBpbXBvcnQNCiAgICBy ZWZlcmVuY2VzIHNpbXBsZS4NCiAgICA+DQogICAgPiBJIHRlbmQgdG8gYWdyZWUgdGhhdCBzb21l dGltZXMgbGVzcyBtb2R1bGVzIGlzIG1vcmUuIEZvciBtZSwgdGhlDQogICAgPiBwcm9ibGVtIGlz IGxpa2VseSBtb3JlIHRoYXQgSSBhbSBub3QgZW50aXJlbHkgc3VyZSB3aGF0IHRoZSBwcm9wZXIN CiAgICA+IGJhc2UgdHlwZXMgd291bGQgYmUsIHdoaWNoIG1heSBkZXBlbmQgb24gd2hhdCBleGFj dGx5IHRoZXkgYXJlIHVzZWQNCiAgICA+IGZvci4gSSBndWVzcyBJIHdhaXQgdW50aWwgSSBzZWUg dGhlIGRlc2NyaXB0aW9uIHRleHQuLi4NCiAgICA+DQogICAgPiA+IEEgYml0IHNlcGFyYXRlIGZy b20gdGhlIGFib3ZlLCBidXQgc3RpbGwgaW4gbWluZDoNCiAgICA+ID4NCiAgICA+ID4gICAtIHNw ZWNpZnkgdGhhdCBhbGwgVExTIHB1YmxpYy1rZXlzIGFyZSBhIERFUi1lbmNvZGVkDQogICAgU3Vi amVjdFB1YmxpY0tleUluZm8gc3RydWN0dXJlDQogICAgPiA+ICAgLSBzcGVjaWZ5IHRoYXQgYWxs IFNTSCBwdWJsaWMta2V5cyBhcmUgYSAic3NoLXB1YmxpYy1rZXktdHlwZSINCiAgICB0eXBlIChz ZWUgYmVsb3cpDQogICAgPiA+ICAgLSBzcGVjaWZ5IHRoYXQgYWxsIGVuY3J5cHRlZCBzeW1tZXRy aWMga2V5cyBhcmUgYSBERVItZW5jb2RlZA0KICAgIE9uZVN5bW1ldHJpY0tleSBzdHJ1Y3R1cmUN CiAgICA+ID4gICAtIHNwZWNpZnkgdGhhdCBhbGwgZW5jcnlwdGVkIGFzeW1tZXRyaWMga2V5cyBh cmUgYSBERVItZW5jb2RlZA0KICAgIE9uZUFzeW1tZXRyaWNLZXkgc3RydWN0dXJlDQogICAgPg0K ICAgID4gSSB3b3VsZCBjaGVjayB3aGF0IGlzIGNvbW1vbmx5IHVzZWQgaW4gZXhpc3RpbmcgY29u ZmlndXJhdGlvbg0KICAgID4gaW50ZXJmYWNlcy4gV2UgYXJlIG5vdCBpbnZlbnRpbmcgdGhlIHdo ZWVsIGhlcmUuIEFuZCB3aGF0ZXZlciB3ZQ0KICAgID4gZGVmaW5lIGJldHRlciBpcyB1c2FibGUg d2l0aCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgYW5kIHRvb2xzLg0KICAgID4NCiAgICA+ID4g VGhlICJzc2gtcHVibGljLWtleSIgdHlwZSB3b3VsZCBiZSBkZWZpbmVkIGFzOg0KICAgID4gPg0K ICAgID4gPiAgICAgIHR5cGVkZWYgc3NoLXB1YmxpYy1rZXktdHlwZSB7DQogICAgPiA+ICAgICAg ICAgIHR5cGUgYmluYXJ5Ow0KICAgID4gPiAgICAgICAgICBtYW5kYXRvcnkgdHJ1ZTsNCiAgICA+ ID4gICAgICAgICAgZGVzY3JpcHRpb24NCiAgICA+ID4gICAgICAgICAgICAiVGhlIGJpbmFyeSBw dWJsaWMga2V5IGRhdGEgZm9yIHRoaXMgU1NIIGtleSwgYXMNCiAgICA+ID4gICAgICAgICAgICAg c3BlY2lmaWVkIGJ5IFJGQyA0MjUzLCBTZWN0aW9uIDYuNiwgaS5lLjoNCiAgICA+ID4NCiAgICA+ ID4gICAgICAgICAgICAgICBzdHJpbmcgICAgY2VydGlmaWNhdGUgb3IgcHVibGljIGtleSBmb3Jt YXQNCiAgICA+ID4gICAgICAgICAgICAgICAgICAgICAgICAgaWRlbnRpZmllcg0KICAgID4gPiAg ICAgICAgICAgICAgIGJ5dGVbbl0gICBrZXkvY2VydGlmaWNhdGUgZGF0YS4iOw0KICAgID4gPiAg ICAgICAgICByZWZlcmVuY2UNCiAgICA+ID4gICAgICAgICAgICAiUkZDIDQyNTM6IFRoZSBTZWN1 cmUgU2hlbGwgKFNTSCkgVHJhbnNwb3J0DQogICAgPiA+ICAgICAgICAgICAgICAgICAgICAgICBM YXllciBQcm90b2NvbCI7DQogICAgPiA+ICAgICAgICAgICB9DQogICAgPg0KICAgID4gVGhlIFNT SCBpbXBsZW1lbnRhdGlvbnMgdGhhdCBJIHVzZSBoYXZlIHRoZSBiaW5hcnkga2V5IGRhdGEgcmVu ZGVyZWQNCiAgICA+IGluIEFTQ0lJLiBJbiBmYWN0LCB0aGUgd2hvbGUga2V5IHJlY29yZCBpcyBy ZW5kZXJlZCBpbiBBU0NJSS4gSQ0KICAgID4gc3Ryb25nbHkgc3VnZ2VzdCB0byB1c2UgZm9ybWF0 cyB0aGF0IGFyZSB3ZWxsIGVzdGFibGlzaGVkLg0KICAgID4NCiAgICA+IC9qcw0KICAgID4NCiAg ICA+IC0tDQogICAgPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2 ZXJzaXR5IEJyZW1lbiBnR21iSA0KICAgID4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAg ICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KICAgID4gRmF4OiAgICs0 OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUv Pg0KICAgID4NCiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQogICAgPiBuZXRjb25mIG1haWxpbmcgbGlzdA0KICAgID4gbmV0Y29uZkBpZXRmLm9y Zw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQog ICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CiAgICBuZXRjb25mIG1haWxpbmcgbGlzdA0KICAgIG5ldGNvbmZAaWV0Zi5vcmcNCiAgICBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCiAgICANCg0KDQo= From nobody Tue Sep 24 14:14:58 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5FCA1200DB for ; Tue, 24 Sep 2019 14:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=fcAHNZ/4; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=vdhfbuNo 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 S4LsJ2rDIjfN for ; Tue, 24 Sep 2019 14:14:53 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F438120071 for ; Tue, 24 Sep 2019 14:14:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20919; q=dns/txt; s=iport; t=1569359693; x=1570569293; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=glpQ0WR5s7xqGkM1kQ/xAtU4k2OFXb5mP450xGdj8PM=; b=fcAHNZ/4gVRweoR1R4qve/q1NerEXEhgrM4GU68/7A9K8l1mFYDxmXON nUu6+hwG/AGhbsevg55gTTxsG27YkxGK4/abmIRKk4gX+JuZg73X2xgHj 5X+noeRLQbitg2TB5KAe74q89ISuhtBMuPegiScGGDrM16tdsSLXJj6vz k=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3A0kSBqhQs72BhxdVxPDYc80zSetpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESUDdfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOiEkG8VefFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAADyhYpd/49dJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQwBAQEBAQGBUwQBAQEBAQsBgRsvUANtViAECyoKhBiDRwOEUoYmgly?= =?us-ascii?q?HRIIjiTCEXYEugSQDVAIHAQEBCQMBASUIAgEBhD8CgyEjNAkOAgMJAQEEAQE?= =?us-ascii?q?BAgEFBG2FLQyFSgEBAQQSEQoTAQE1AgEPAgEIDgMEAQEoAwICAh8RFAkIAgQ?= =?us-ascii?q?BDQUIBhSDAYEdTQMdAQIMoyMCgTiIYXOBMoJ9AQEFgQcBLwKDWQ0LghAHAwa?= =?us-ascii?q?BNAGBUIo5GIFAP4ERRoJMPoFURkcBAQOBSBgrCYJVMoImjHEzgjaGLJYcLUE?= =?us-ascii?q?KgiKDQYIugRaKBIQcgjaHS41IgVyOGogTggiLIYNZAgQCBAUCDgEBBYFSOIF?= =?us-ascii?q?YcBWDJ1AQFIFOg3KFFIUIATZzgSmJJgeBKgGBIgEB?= X-IronPort-AV: E=Sophos;i="5.64,545,1559520000"; d="p7s'?scan'208,217";a="331989723" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Sep 2019 21:14:52 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x8OLEqxU021690 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 24 Sep 2019 21:14:52 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Sep 2019 16:14:51 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 24 Sep 2019 16:14:50 -0500 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 24 Sep 2019 16:14:50 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mSFSb7AzbVu/W9EwpZZnSpR+3RXSf5JO0xLaT8Gnpqgn0cJouKZGC13kMnuicrJfeHo42gB/+YwfO2+AFMAILaQ7XMGnPtu9KSzFESKED/OQ1DomZswp8+AuffFQmupB+zNdiBOS6DadZL6tYxNFaKVeGFYIl2m9R9mguXJS+5kScOzmI4WKnnbKPivALwoO0fmuOjyvI2WkkaN1+qJTRNOPpjggCQF+mjGPA1i1HcA650DyQDXltM4e2MYQuoDQ/QlY8593cacZlYiDU+Qao3P7w9CTCF8u2+QllnE3Dva1UrlurVZr0KCxnC4752r/xd8aQ/m4vs+ZLsX3mwAzPg== 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=BvU/z1PAPev04WpaYvtFhFZ0hoRvi+OghZkay5S5ulo=; b=mjkBBEbiylCFQimg+ZmeKPSLXG8jA8wxYXvI4xGesFlGM4KGxmx6FEbAJtnjx5IONw3KjnPAjmVpWZkX7mEmZd1qfHPkokA2TbsbBs7UHb9o/MvnS/MEYM9W9xftWc6hmj01bV0atkaDqs5jfI+NGVvAEKyZ+JatyRlQAKlDgx4ZRJhzz3yurMHOdQJW0dQT+DcqueAVPEDQRy2RVLwuht/1Y8ZSHqLO9Hanw6r/CGg7Q8yRzIoi0gcCdFhDbhTGvySdntFL4Rm4+Vjap7xLImSk1j12pBCfGNIPw0UkZ142TH50KYXQ1JlUItq4Dkdk6PAMLdTCkqqEoI/t+Tz2Iw== 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=BvU/z1PAPev04WpaYvtFhFZ0hoRvi+OghZkay5S5ulo=; b=vdhfbuNo7SLzyY6hi23B0kgEKzMASAVntWgiU3rVCmKCH4Luz0Rjr2/wJTX2/r81KcETI1wgSlWrz0TvqGiUa+78Y24apsUVa416ABX4a3c1ahPghpF/PuyreWuzcS35tUjSMrPQ316UnmNQbJoe/RjvvTAsf3VQudke7IYcb0U= Received: from BN7PR11MB2627.namprd11.prod.outlook.com (52.135.255.31) by BN7PR11MB2770.namprd11.prod.outlook.com (52.135.246.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.18; Tue, 24 Sep 2019 21:14:49 +0000 Received: from BN7PR11MB2627.namprd11.prod.outlook.com ([fe80::61c6:4b6d:cf6c:f095]) by BN7PR11MB2627.namprd11.prod.outlook.com ([fe80::61c6:4b6d:cf6c:f095%3]) with mapi id 15.20.2284.023; Tue, 24 Sep 2019 21:14:49 +0000 From: "Eric Voit (evoit)" To: Mahesh Jethanandani , "Balazs Lengyel (balazs.lengyel@ericsson.com)" , Alexander Clemm , "Benoit Claise (bclaise)" CC: Netconf Thread-Topic: [netconf] WGLC for draft-ietf-netconf-notification-capabilities Thread-Index: AQHVcwCXe43vmPblgUW74U2qSpt2bac7U+ng Date: Tue, 24 Sep 2019 21:14:49 +0000 Message-ID: References: <4F49DF08-B7FC-4EBD-9D6B-7BC329E50334@gmail.com> In-Reply-To: <4F49DF08-B7FC-4EBD-9D6B-7BC329E50334@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=evoit@cisco.com; x-originating-ip: [173.38.117.75] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 98d21785-eaed-4ce2-7698-08d741343bb7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600167)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:BN7PR11MB2770; x-ms-traffictypediagnostic: BN7PR11MB2770: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0170DAF08C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(376002)(346002)(39860400002)(366004)(189003)(199004)(4326008)(790700001)(6116002)(3846002)(7736002)(66616009)(2906002)(66556008)(76116006)(66476007)(74316002)(478600001)(66066001)(256004)(99286004)(52536014)(7696005)(14454004)(14444005)(5660300002)(446003)(26005)(486006)(476003)(11346002)(102836004)(6506007)(76176011)(186003)(53546011)(25786009)(15650500001)(99936001)(71190400001)(71200400001)(66946007)(2420400007)(81166006)(64756008)(8676002)(81156014)(8936002)(33656002)(6436002)(236005)(86362001)(9686003)(229853002)(55016002)(606006)(6306002)(54896002)(7110500001)(6246003)(110136005)(66446008)(316002)(6636002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2770; H:BN7PR11MB2627.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: aBeZikhAQzbZ+uDl/I1EmIGDKBGUYFddUFOv3AEDnPipJ2uwT3zH5r88+tg646G2wlMVTNjZvftGxLMS5sYO8wMwMapCmoLyTQ0KRjjcdzcOiUjfVttbKsGykB6zyzR3flPntmQL6vrpJT28gS4Yo1X1Mr+s/3c5Zvc30jdiMEET31L1GfWHm7ZwkL/fvxQqsYJ+1Ycl9ql36C4LgSX6vlYDJ0XzYvB6Qi1NXxJKDsZqi9iLiPk75ZUtiIkPP4VPdnhtLSiSsUfnzx16ogmU2gtx1+KUznONUuWOvcSHZIXVw97jFNV5RQ4QjRuH6AysTbWTeJQrPftgJYat122nN+IQcrLN5hg4lhIL46qxZmqBxti+FDAuRxeZ498//WdMKighM6H+vJE1JyezjpBSFYCYEregeVql1zMz4jvBB6g= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01E3_01D572FB.8FB15920" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 98d21785-eaed-4ce2-7698-08d741343bb7 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Sep 2019 21:14:49.0379 (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: uT/5rFGB3+q8Ynjs6sr9MPBRTVEE8k+ungTvpcNdgXTijrDSZ1CoT1lEOggXnDRA X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2770 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.22, xch-rcd-012.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 21:14:57 -0000 ------=_NextPart_000_01E3_01D572FB.8FB15920 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01E4_01D572FB.8FB15920" ------=_NextPart_001_01E4_01D572FB.8FB15920 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Here are some comments... Section 1: Terminology YANG-Push is the RFC-8641 term rather than Yang-Push. Both variants are used in this document On-change Notification Capability: Is this different from support for RFC-8641 feature "on-change"? If they are the same, it might be possible to remove the term. Especially as this term is used inconsistently. Implementation-time information is used twice in the document, but without the dash Run-time information is used once. And the definition refers to the availability of information over network management protocols. Is it worth differentiating the term via a linkage to run-time state objects? Section 2 Paragraph 4: instead of " meaningless (e.g., a temperature gauge changing 0.1 degrees)", how about "irrelevant to the receiver (e.g., a temperature gauge change of 0.1 degrees within a predetermined and acceptable range)"? Paragraph 6: instead of "not available early in some document" how about " not documented in a way available to the NMS designer". Also // from, is/ from is Bullet #1 under Run time information: not sure what is meant by "it does not care which data nodes send notification, it will just handle what is available.". Should reword. Bullet #3: might want to reword: " implementation time capability information about the capabilities" Section 3 Paragraph 2, bullet 2: Instead of "amount of notifications the server can send out", do you mean "the minimum periodicity of updates which a server can send out for an object" Paragraph 2, bullets 3 & 4: I don't think these should be indented as bullets are they are more about proper behavior of a correctly populated model. Paragraph 3, bullets 2: why isn't SHALL instead MUST? Also, shouldn't this point out that both NETCONF and RESTCONF MUST be supported if on-change is advertised, and this draft is supported? YANG Model I am not sure why "server" is preferable to "publisher". The initial YANG-Push draft moved to "Publisher" because it is possible for the client-server roles to be reversed for some transport protocols. For example, the recent HTTP notif draft might have the receiver fill the HTTP server role. I believe it cleaner to revert to the "publisher" terminology. I do like the tiered structure of specific and generic values. There are lots of good parallels to other YANG work. Section 4 I suspect that you will need to do a security analysis per YANG object. This has been done the other YANG push family. I suspect that manipulating the reporting intervals could have some security implications. E.g., a hacker could push up the damping period or periodic interval to a level where the information they are changing then becomes invisible to a monitoring system. Thanks, Eric From: netconf On Behalf Of Mahesh Jethanandani Sent: Tuesday, September 24, 2019 1:50 PM To: Netconf Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities We were supposed to have closed on the WGLC today. However, between the document becoming a WG item and it going into LC, we have not received too many comments on the draft. As such, we are extending the LC by another week. Please review the draft and provide any comments you might have. Mahesh & Kent (as co-chairs) On Sep 10, 2019, at 3:39 PM, Mahesh Jethanandani > wrote: Authors have published -04 version of the draft, which addresses comments they received in IETF 105. If you provided comments please check to make sure your comments have been addressed. At this point, the authors believe that the document is ready for WGLC. This therefore starts a two week LC, ending on September 24th. Please provide any technical comments you might have on the document. If you believe the document is not ready for LC, please state your reasons. We will issue a IPR poll separately. Mahesh & Kent (as co-chairs) ------=_NextPart_001_01E4_01D572FB.8FB15920 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Here are = some comments...

 

Section 1: Terminology

 

YANG-Push is the RFC-8641 term rather than = Yang-Push.=C2=A0=C2=A0 Both variants are used in this = document

 

On-change Notification Capability: Is this = different from support for RFC-8641 feature "on-change"?=C2=A0 = If they are the same, it might be possible to remove the term.=C2=A0 = Especially as this term is used inconsistently.

 

Implementation-time information is used twice in = the document, but without the dash

 

Run-time information is used once.=C2=A0 And the = definition refers to the availability of information over network = management protocols.=C2=A0 Is it worth differentiating the term via a = linkage to run-time state objects?

 

 

 

Section 2

 

Paragraph 4: instead of " meaningless (e.g., a = temperature gauge changing 0.1 degrees)", how about = "irrelevant to the receiver (e.g., a temperature gauge change of = 0.1 degrees within a predetermined and acceptable = range)"?

 

Paragraph 6:=C2=A0 instead of "not available = early in some document"=C2=A0 how about " not documented in a = way available to the NMS designer".=C2=A0 Also // from, is/ from = is

 

Bullet #1 under Run time information: not sure what = is meant by "it does not care which data nodes send notification, = it will just handle what is available.".=C2=A0 Should = reword.

 

Bullet #3: might want to reword: " = implementation time capability information about the = capabilities"

 

 

 

Section 3

 

Paragraph 2, bullet 2: Instead of = =C2=A0"amount of notifications the server can send out", do = you mean "the minimum periodicity of updates which a server can = send out for an object"

 

Paragraph 2, bullets 3 & 4: I don't think these = should be indented as bullets are they are more about proper behavior of = a correctly populated model.

 

Paragraph 3, bullets 2: why isn't SHALL instead = MUST?=C2=A0=C2=A0 Also, shouldn't this point out that both NETCONF and = RESTCONF MUST be supported if on-change is advertised, and this draft is = supported?

 

 

 

YANG = Model

 

I am not sure why "server" is preferable = to "publisher".=C2=A0 The initial YANG-Push draft moved to = "Publisher" because it is possible for the client-server roles = to be reversed for some transport protocols.=C2=A0 For example, the = recent HTTP notif draft might have the receiver fill the HTTP server = role.=C2=A0=C2=A0 I believe it cleaner to revert to the = "publisher" terminology.

 

I do = like the tiered structure of specific and generic values.=C2=A0 There = are lots of good parallels to other YANG work.

 

 

Section 4

 

I = suspect that you will need to do a security analysis per YANG = object.=C2=A0=C2=A0 This has been done the other YANG push = family.

 

I suspect that manipulating the reporting intervals = could have some security implications.=C2=A0=C2=A0 E.g., a hacker could = push up the damping period or periodic interval to a level where the = information they are changing then becomes invisible to a monitoring = system.

 

Thanks,

Eric =

 

 

From: = netconf <netconf-bounces@ietf.org> On Behalf Of Mahesh = Jethanandani
Sent: Tuesday, September 24, 2019 1:50 = PM
To: Netconf <netconf@ietf.org>
Subject: Re: = [netconf] WGLC for = draft-ietf-netconf-notification-capabilities

 

We = were supposed to have closed on the WGLC today. However, between the = document becoming a WG item and it going into LC, we have not received = too many comments on the draft. As such, we are extending the LC by = another week. Please review the draft and provide any comments you might = have.

 

Mahesh & Kent (as co-chairs)

 



On Sep 10, 2019, at 3:39 PM, Mahesh Jethanandani = <mjethanandani@gmail.com> = wrote:

 

Authors have published -04 version of the draft, which addresses comments = they received in IETF 105. If you provided comments please check to make = sure your comments have been addressed. At this point, the authors = believe that the document is ready for WGLC.

 

This therefore starts a two week LC, ending on = September 24th. Please provide any technical comments you might have on = the document. If you believe the document is not ready for LC, please = state your reasons.

 

We will issue a IPR poll = separately. 

 

Mahesh & Kent (as = co-chairs)

 

 

 

 

------=_NextPart_001_01E4_01D572FB.8FB15920-- ------=_NextPart_000_01E3_01D572FB.8FB15920 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwOTI0MjExNDQ1WjAjBgkqhkiG 9w0BCQQxFgQU+1DgPqxDm40rl/JGkBqRvuINZU4wSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQBvoIZv5efJuCoLSFRfz2NiEiqoVQ4mrP/HHDSQQbA9WzMfUYdpD9zZH7id7vGCg8Z/ IVYy0rHqitjDVdh5WJMqdqgY2udPTBLXz78gzhSh+SP1znIThkxFnpc2UnbIVSatQpRGHj7fdrnD wiU/ytIDP/Vw1hZBeTEqmkv8ky2izoBGwrzm+miAqh1xDZWaDP5lIkrmyRbQ/z/jlFkPwqQgIiJp MbCQih/skPqLtv151gwPMMGls8Ge6QUW+KHt+TATuL/afoVRiE7kNLlPoL2+6uaNBb8pLYY69JJQ zutUk3lKCu4QewehAw8RbfUZq1aatWiAvLCTXx7cZy/Ltbw5AAAAAAAA ------=_NextPart_000_01E3_01D572FB.8FB15920-- From nobody Tue Sep 24 23:36:52 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFE21208FF; Tue, 24 Sep 2019 23:36:50 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 fFMfhqj6UF1v; Tue, 24 Sep 2019 23:36:47 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B2691120934; Tue, 24 Sep 2019 23:36:47 -0700 (PDT) Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id D68301AE0115; Wed, 25 Sep 2019 08:36:44 +0200 (CEST) Date: Wed, 25 Sep 2019 08:36:20 +0200 (CEST) Message-Id: <20190925.083620.220579291789643978.mbj@tail-f.com> To: jholland@akamai.com Cc: rsalz@akamai.com, netconf@ietf.org, taps@ietf.org From: Martin Bjorklund In-Reply-To: <3F71FEE6-3679-4482-B210-6585A15E0BA7@akamai.com> References: <034101d572b4$cf1901e0$4001a8c0@gateway.2wire.net> <3F71FEE6-3679-4482-B210-6585A15E0BA7@akamai.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2019 06:36:51 -0000 SGksDQoNCkp1c3QgYSBxdWljayBjb21tZW50IG9uIHRoZSB1c2FnZSBvZiBZQU5HIGluIHRoaXMg ZG9jdW1lbnQuICBTaW5jZSBpdA0KZG9lc24ndCBkZWZpbmUgY29uZmlndXJhdGlvbiBkYXRhIHRv IGJlIHVzZWQgb3ZlciBhIG1hbmFnZW1lbnQNCnByb3RvY29sIGxpa2UgTkVUQ09ORiBvciBSRVNU Q09ORiwgeW91IG1heSB3YW50IHRvIGhhdmUgYSBsb29rIGF0DQpodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy1kYXRhLWV4dCwgd2hpY2gNCmludHJvZHVj ZXMgYSBZQU5HIGV4dGVuc3Rpb24gc3RhdGVtZW50IHRvIGRlZmluZSAic3RydWN0dXJlcyIgKHdp dGggbm8NCnByZWRlZmluZWQgc2VtYW50aWNzKSwgYW5kIHJlcGxhY2UgeW91cjoNCg0KICBjb250 YWluZXIgcHJlY29ubmVjdGlvbiB7IC4uLiB9DQoNCndpdGg6DQoNCiAgc3g6c3RydWN0dXJlIHBy ZWNvbm5lY3Rpb24geyAuLi4gfQ0KDQoNCg0KL21hcnRpbg0KDQoNCg0KIkhvbGxhbmQsIEpha2Ui IDxqaG9sbGFuZEBha2FtYWkuY29tPiB3cm90ZToNCj4gKCt0YXBzKQ0KPiBIaSwNCj4gDQo+IFRo YW5rcyBmb3IgdGFraW5nIGEgbG9vayBhdCB0aGF0IG1vZGVsLCBUb20uICBJJ2xsIGdpdmUganVz dCBhDQo+IGxpdHRsZSBiYWNrZ3JvdW5kOg0KPiANCj4gVGhlIGN1cnJlbnQgdGFwcy1hcGkgc3Ry dWN0dXJlIHdhcyBkcml2ZW4gYmFzaWNhbGx5IGJ5IGFuIGF0dGVtcHQgdG8NCj4gc3VwcG9ydCB0 aGUgZXhhbXBsZXMgZ2l2ZW4gaW4gdGhlIHRhcHMtaW50ZXJmYWNlIGRyYWZ0LCBmb3IgaW5zdGFu Y2UNCj4gaW4gc2VjdGlvbiA1LjMuMToNCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtdGFwcy1pbnRlcmZhY2UtMDQjc2VjdGlvbi01LjMuMQ0KPiANCj4gSSBkaWRuJ3Qg ZG8gbXVjaCAob3IgYW55PyBkb24ndCByZWNhbGwuLi4pIG9mIGEgc2VhcmNoIGZvciBjcnlwdG8N Cj4gbW9kZWxzIGJlZm9yZSB0aHJvd2luZyB0b2dldGhlciB0aGUgZWFybHkgaWV0Zi10YXBzLWFw aS55YW5nIGRyYWZ0cywNCj4gaW5jbHVkaW5nIHRoZSBzZWN1cml0eSBjb25maWcgc3R1ZmYuICBJ IG1vc3RseSB3b3JrZWQgb2ZmIHRoZSBBUEkNCj4gZXhhbXBsZXMsIHdpdGggaW50ZW50IHRvIGxv b2sgZm9yIGEgbW9yZSBzZXJpb3VzIGFuc3dlciBsYXRlciBhcw0KPiB3ZSB0cnkgdG8gaW50ZWdy YXRlIHRoZSBzZWN1cmUgY29ubmVjdGlvbiBzdXBwb3J0IGludG8gYSByZWZlcmVuY2UNCj4gaW1w bGVtZW50YXRpb24gb3IgMi4NCj4gDQo+IFdoYXQncyB0aGVyZSBub3cgaGFzbid0IGJlZW4gdGhy b3VnaCBhbnkga2luZCBvZiBzZWN1cml0eSByZXZpZXcsIGFuZA0KPiBJJ2QgY2hhcmFjdGVyaXpl IGl0IGFzIGEgcGxhY2Vob2xkZXIsIGF0IHRoZSBtb21lbnQuICAoVGhlIHRhcHMgdXNlIG9mDQo+ IHlhbmcgaXMgc3RpbGwgcmVsYXRpdmVseSBpbW1hdHVyZS4pDQo+IA0KPiBJJ2QgYmUgdmVyeSBn cmF0ZWZ1bCBmb3IgYSBncm91cGluZyBvciBvYmplY3Qgb2Ygc29tZSBraW5kIHRoYXQgSQ0KPiBj b3VsZCBwdWxsIGluIGJ5IGltcG9ydCBmcm9tIGFub3RoZXIgbW9kdWxlLCBhbmQgd291bGQgc3Vw cG9ydA0KPiB1c2luZyBpdCBpbiB0YXBzLWFwaS15YW5nIGlmIHdlIGNhbiB1c2UgaXQgdG8gZG8g d2hhdCB3ZSBuZWVkICh3aGljaA0KPiBpcyB0byBjb25maWd1cmUgY29ubmVjdGlvbiBlbmRwb2lu dHMgdG8gYWxsb3cgc2VjdXJlZCBjb25uZWN0aW9ucywNCj4gZm9yIGVpdGhlciBjbGllbnQgb3Ig c2VydmVyIGVuZHBvaW50cykuICBJIHRoaW5rIHRoYXQgd291bGQgbWFrZSBmb3INCj4gYSB2ZXJ5 IGhlbHBmdWwgaW1wcm92ZW1lbnQuDQo+IA0KPiBQYXJ0IG9mIHRoZSBwb2ludCBvZiB1c2luZyB5 YW5nIGluIHRhcHMgd2FzIHRvIGJlIGFibGUgdG8gYmV0dGVyIGV4cGxvaXQNCj4geWFuZyB3b3Jr IGZyb20gb3RoZXIgd2dzLCBhbmQgdGhpcyB3b3VsZCBiZSBhbiBleGNlbGxlbnQgb3Bwb3J0dW5p dHkgdG8NCj4gcHV0IHRoYXQgaW50byBwcmFjdGljZSwgSSB0aGluay4gIFNvIEkgd291bGQgYmUg dmVyeSBkZWxpZ2h0ZWQgdG8gaW1wb3J0DQo+IGEgbW9kZWwgdGhhdCBkb2VzIHRoaXMgcmlnaHQu DQo+IA0KPiBCZXN0LA0KPiBKYWtlDQo+IA0KPiDvu79PbiAyMDE5LTA5LTI0LCAxMzowMiwgIlNh bHosIFJpY2giIDxyc2FsekBha2FtYWkuY29tPiB3cm90ZToNCj4gDQo+IEpha2UsDQo+IA0KPiBB cyB0aGUgYXV0aG9yIG9mIHRoZSBkcmFmdCByZWZlcmVuY2VkIGJlbG93LCBkbyB5b3UgY2FyZSB0 byBjb21tZW50Pw0KPiANCj4gVGhlIGNyeXB0by10eXBlcyBkb2N1bWVudCBpbiB0aGUgbmV0Y29u ZiBXRyBpcyB1bmRlcmdvaW5nIHNvbWUgcHJldHR5IGRyYXN0aWMgc3VyZ2VyeS4NCj4gDQo+IA0K PiBPbiA5LzI0LzE5LCA0OjUwIEFNLCAidG9tIHBldGNoIiA8aWV0ZmNAYnRjb25uZWN0LmNvbT4g d3JvdGU6DQo+IA0KPiAgICAgR29pbmcgYmFjayBhIGJpdCwgc2luY2UgdGhpcyBpcyBhIG1vcmUg Z2VuZXJpYyBjb21tZW50LCBJIGdldCBhDQo+ICAgICBkaWZmZXJlbnQsIHNpbXBsZXIgcGVyc3Bl Y3RpdmUgaW4NCj4gICAgIGRyYWZ0LWpob2xsYW5kLXRhcHMtYXBpLXlhbmcNCj4gICAgIHdoaWNo IGhhcyBtZSB3b25kZXJpbmcganVzdCBob3cgY29tcGxpY2F0ZWQgdGhpcyBuZWVkcyB0byBiZSBm b3IgaXQgdG8NCj4gICAgIGJlIHVzZWZ1bCBpbiBvdGhlciBXR3MuDQo+ICAgICANCj4gICAgIFRo ZSBJLUQgZGVmaW5lcw0KPiAgICAgICBpZGVudGl0eSBzZWN1cml0eS1hbGdvcml0aG0ge2Rlc2Ny aXB0aW9uICJCYXNlIGlkZW50aXR5IGZvciBzZWN1cml0eQ0KPiAgICAgYWxnb3JpdGhtcy4iDQo+ ICAgICAgIGlkZW50aXR5IGNpcGhlci1zdWl0ZSB7IGJhc2Ugc2VjdXJpdHktYWxnb3JpdGhtO2Rl c2NyaXB0aW9uICJCYXNlDQo+ICAgICBpZGVudGl0eSBmb3Igc2VjdXJpdHkgY2lwaGVyIHN1aXRl cy4iOw0KPiAgICAgICBpZGVudGl0eSBzaWduYXR1cmUtYWxnb3JpdGhtIHtiYXNlIHNlY3VyaXR5 LWFsZ29yaXRobTsNCj4gICAgIGRlc2NyaXB0aW9uICJCYXNlIGlkZW50aXR5IGZvciBzZWN1cml0 eSBzaWduYXR1cmUgYWxnb3JpdGhtcy4iOw0KPiAgICAgICBpZGVudGl0eSBlZDI1NTE5IHtiYXNl IHNpZ25hdHVyZS1hbGdvcml0aG07DQo+ICAgICAgIGlkZW50aXR5IFRMU19FQ0RIRV9FQ0RTQV9X SVRIX0NIQUNIQTIwX1BPTFkxMzA1X1NIQTI1NiB7DQo+ICAgICAgICAgYmFzZSBjaXBoZXItc3Vp dGU7DQo+ICAgICANCj4gICAgIGFuZA0KPiAgICAgDQo+ICAgICAgIGdyb3VwaW5nIHNlY3VyaXR5 LWNyZWRlbnRpYWxzIHsNCj4gICAgICAgICBsZWFmIGlkZW50aXR5IHsgdHlwZSBzdHJpbmc7DQo+ ICAgICAgICAgbGVhZiB0cnVzdC1jYSB7IHR5cGUgc3RyaW5nOw0KPiAgICAgICAgIGxlYWYgYWxn b3JpdGhtIHsgdHlwZSBpZGVudGl0eXJlZiB7YmFzZSBzZWN1cml0eS1hbGdvcml0aG07DQo+ICAg ICAgICAgbGVhZiBwcmUtc2hhcmVkLWtleSB7IHR5cGUgc3RyaW5nOw0KPiAgICAgICAgIGxlYWYg cHJpdmF0ZS1rZXkgeyB0eXBlIHN0cmluZzsNCj4gICAgICAgICBsZWFmIHByaXZhdGUta2V5LWNh bGxiYWNrLWhhbmRsZSB7dHlwZSBzdHJpbmc7DQo+ICAgICAgICAgbGVhZiBwdWJsaWMta2V5IHt0 eXBlIHN0cmluZzsNCj4gICAgIA0KPiAgICAgKE5vIFNTSCBidXQgdGhhdCBkb2VzIG5vdCBzdXJw cmlzZSBtZTotKQ0KPiAgICAgDQo+ICAgICBBZ2FpbiBhIG1vcmUgZ2VuZXJhbCBjb21tZW50LCB0 aGUgSUVURiBvZnRlbiBzdGFydHMgc2ltcGxlIGFuZCBhZGRzIGxvdHMNCj4gICAgIGxhdGVyLCB3 aGljaCBzb21ldGltZXMgZ29lcyB3cm9uZyBiZWNhdXNlIG5vIGFsbG93YW5jZSB3YXMgbWFkZSBm b3INCj4gICAgIHNsb3R0aW5nIGluIGV4dHJhcywgYnV0IGFuIGFwcHJvYWNoIHdoaWNoLCBJIHRo aW5rLCBtb3JlIG9mdGVuIGxlYWRzIHRvDQo+ICAgICBzdWNjZXNzZnVsIGFkb3B0aW9uLg0KPiAg ICAgDQo+ICAgICBUaHVzIHdpbGwgVEFQUyBjb25zaWRlciB1c2luZw0KPiAgICAgZHJhZnQtaWV0 Zi1uZXRjb25mLWNyeXB0by10eXBlcw0KPiAgICAgb3Igd2lsbCB0aGV5IFJZTz8NCj4gICAgIA0K PiAgICAgVG9tIFBldGNoDQo+ICAgICANCj4gICAgIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS0NCj4gICAgIEZyb206IDxTY2jDtm53w6RsZGVyPjsgIkrDvHJnZW4iIDxKLlNjaG9lbndhZWxk ZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+DQo+ICAgICBUbzogIlJvYiBXaWx0b24gKHJ3aWx0b24p IiA8cndpbHRvbkBjaXNjby5jb20+DQo+ICAgICBDYzogIlJ1c3MgSG91c2xleSIgPGhvdXNsZXlA dmlnaWxzZWMuY29tPjsgPG5ldGNvbmZAaWV0Zi5vcmc+OyAiU2Vhbg0KPiAgICAgVHVybmVyIiA8 c2VhbkBzbjNyZC5jb20+OyAiUmlmYWF0IFNoZWtoLVl1c2VmIiA8cmlmYWF0LmlldGZAZ21haWwu Y29tPg0KPiAgICAgU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTgsIDIwMTkgNTozNiBQTQ0K PiAgICAgDQo+ICAgICA+IE9uIFdlZCwgU2VwIDE4LCAyMDE5IGF0IDAzOjM3OjE0UE0gKzAwMDAs IFJvYiBXaWx0b24gKHJ3aWx0b24pIHdyb3RlOg0KPiAgICAgPiA+ID5Gcm9tIHRoZSBnaXN0IG9m IHRoZSBkaXNjdXNzaW9uLCB0aGUgcHVuY2ggbGlzdCBhcHBlYXJzIHRvIGJlOg0KPiAgICAgPiA+ DQo+ICAgICA+ID4gLSByZXZlcnQgYmFjayB0byB1c2luZyBpZGVudGl0aWVzLCBhcyB0aGV5IHdl cmUgaW4gdGhlIC0wOCByZXZpc2lvbi4NCj4gICAgID4gPiAtIG9ubHkgZGVmaW5lIGJhc2UgaWRl bnRpdGllcyBmb3Igd2hhdCdzIG5lZWRlZCBpbW1lZGlhdGVseSBmb3IgVExTDQo+ICAgICBhbmQg U1NIIGFuZCBrZXlzdG9yZSBrZXktZW5jcnlwdGlvbi4NCj4gICAgID4gPiAtIGRlZmluZSB0aGVz ZSBiYXNlIGlkZW50aXRpZXMgaW4gZGlzdGluY3QgWUFORyBtb2R1bGVzDQo+ICAgICA+ID4gLSBo YXZlIGVhY2ggaWRlbnRpdHkncyBkZXNjcmlwdGlvbiBzdGF0ZW1lbnQgaW5kaWNhdGUgd2hhdCB0 aGUNCj4gICAgIGJpbmFyeSBrZXkgZGF0YSBpcyBlbmNvZGVkLg0KPiAgICAgPiA+IFtSV10NCj4g ICAgID4gPiBJIHRoaW5rIHRoYXQgdGhpcyBtYXRjaGVzIG15IHZpZXcsIGV4Y2VwdCBmb3IgImRl ZmluZSB0aGVzZSBiYXNlDQo+ICAgICBpZGVudGl0aWVzIGluIGRpc3RpbmN0IFlBTkcgbW9kdWxl cyIuICBJIGRvbid0IGZlZWwgcGFydGljdWxhcmx5DQo+ICAgICBzdHJvbmdseSBhYm91dCB0aGlz LCBidXQgSSB3YXMgdGhpbmtpbmcgdGhhdCB0aGUgYmFzZSBpZGVudGl0aWVzIHdvdWxkDQo+ICAg ICBzdGlsbCBiZSBkZWZpbmVkIGluIGNyeXB0by10eXBlcy55YW5nLCB3aGljaCBtaWdodCBoZWxw IGtlZXAgdGhlIGltcG9ydA0KPiAgICAgcmVmZXJlbmNlcyBzaW1wbGUuDQo+ICAgICA+DQo+ICAg ICA+IEkgdGVuZCB0byBhZ3JlZSB0aGF0IHNvbWV0aW1lcyBsZXNzIG1vZHVsZXMgaXMgbW9yZS4g Rm9yIG1lLCB0aGUNCj4gICAgID4gcHJvYmxlbSBpcyBsaWtlbHkgbW9yZSB0aGF0IEkgYW0gbm90 IGVudGlyZWx5IHN1cmUgd2hhdCB0aGUgcHJvcGVyDQo+ICAgICA+IGJhc2UgdHlwZXMgd291bGQg YmUsIHdoaWNoIG1heSBkZXBlbmQgb24gd2hhdCBleGFjdGx5IHRoZXkgYXJlIHVzZWQNCj4gICAg ID4gZm9yLiBJIGd1ZXNzIEkgd2FpdCB1bnRpbCBJIHNlZSB0aGUgZGVzY3JpcHRpb24gdGV4dC4u Lg0KPiAgICAgPg0KPiAgICAgPiA+IEEgYml0IHNlcGFyYXRlIGZyb20gdGhlIGFib3ZlLCBidXQg c3RpbGwgaW4gbWluZDoNCj4gICAgID4gPg0KPiAgICAgPiA+ICAgLSBzcGVjaWZ5IHRoYXQgYWxs IFRMUyBwdWJsaWMta2V5cyBhcmUgYSBERVItZW5jb2RlZA0KPiAgICAgU3ViamVjdFB1YmxpY0tl eUluZm8gc3RydWN0dXJlDQo+ICAgICA+ID4gICAtIHNwZWNpZnkgdGhhdCBhbGwgU1NIIHB1Ymxp Yy1rZXlzIGFyZSBhICJzc2gtcHVibGljLWtleS10eXBlIg0KPiAgICAgdHlwZSAoc2VlIGJlbG93 KQ0KPiAgICAgPiA+ICAgLSBzcGVjaWZ5IHRoYXQgYWxsIGVuY3J5cHRlZCBzeW1tZXRyaWMga2V5 cyBhcmUgYSBERVItZW5jb2RlZA0KPiAgICAgT25lU3ltbWV0cmljS2V5IHN0cnVjdHVyZQ0KPiAg ICAgPiA+ICAgLSBzcGVjaWZ5IHRoYXQgYWxsIGVuY3J5cHRlZCBhc3ltbWV0cmljIGtleXMgYXJl IGEgREVSLWVuY29kZWQNCj4gICAgIE9uZUFzeW1tZXRyaWNLZXkgc3RydWN0dXJlDQo+ICAgICA+ DQo+ICAgICA+IEkgd291bGQgY2hlY2sgd2hhdCBpcyBjb21tb25seSB1c2VkIGluIGV4aXN0aW5n IGNvbmZpZ3VyYXRpb24NCj4gICAgID4gaW50ZXJmYWNlcy4gV2UgYXJlIG5vdCBpbnZlbnRpbmcg dGhlIHdoZWVsIGhlcmUuIEFuZCB3aGF0ZXZlciB3ZQ0KPiAgICAgPiBkZWZpbmUgYmV0dGVyIGlz IHVzYWJsZSB3aXRoIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBhbmQgdG9vbHMuDQo+ICAgICA+ DQo+ICAgICA+ID4gVGhlICJzc2gtcHVibGljLWtleSIgdHlwZSB3b3VsZCBiZSBkZWZpbmVkIGFz Og0KPiAgICAgPiA+DQo+ICAgICA+ID4gICAgICB0eXBlZGVmIHNzaC1wdWJsaWMta2V5LXR5cGUg ew0KPiAgICAgPiA+ICAgICAgICAgIHR5cGUgYmluYXJ5Ow0KPiAgICAgPiA+ICAgICAgICAgIG1h bmRhdG9yeSB0cnVlOw0KPiAgICAgPiA+ICAgICAgICAgIGRlc2NyaXB0aW9uDQo+ICAgICA+ID4g ICAgICAgICAgICAiVGhlIGJpbmFyeSBwdWJsaWMga2V5IGRhdGEgZm9yIHRoaXMgU1NIIGtleSwg YXMNCj4gICAgID4gPiAgICAgICAgICAgICBzcGVjaWZpZWQgYnkgUkZDIDQyNTMsIFNlY3Rpb24g Ni42LCBpLmUuOg0KPiAgICAgPiA+DQo+ICAgICA+ID4gICAgICAgICAgICAgICBzdHJpbmcgICAg Y2VydGlmaWNhdGUgb3IgcHVibGljIGtleSBmb3JtYXQNCj4gICAgID4gPiAgICAgICAgICAgICAg ICAgICAgICAgICBpZGVudGlmaWVyDQo+ICAgICA+ID4gICAgICAgICAgICAgICBieXRlW25dICAg a2V5L2NlcnRpZmljYXRlIGRhdGEuIjsNCj4gICAgID4gPiAgICAgICAgICByZWZlcmVuY2UNCj4g ICAgID4gPiAgICAgICAgICAgICJSRkMgNDI1MzogVGhlIFNlY3VyZSBTaGVsbCAoU1NIKSBUcmFu c3BvcnQNCj4gICAgID4gPiAgICAgICAgICAgICAgICAgICAgICAgTGF5ZXIgUHJvdG9jb2wiOw0K PiAgICAgPiA+ICAgICAgICAgICB9DQo+ICAgICA+DQo+ICAgICA+IFRoZSBTU0ggaW1wbGVtZW50 YXRpb25zIHRoYXQgSSB1c2UgaGF2ZSB0aGUgYmluYXJ5IGtleSBkYXRhIHJlbmRlcmVkDQo+ICAg ICA+IGluIEFTQ0lJLiBJbiBmYWN0LCB0aGUgd2hvbGUga2V5IHJlY29yZCBpcyByZW5kZXJlZCBp biBBU0NJSS4gSQ0KPiAgICAgPiBzdHJvbmdseSBzdWdnZXN0IHRvIHVzZSBmb3JtYXRzIHRoYXQg YXJlIHdlbGwgZXN0YWJsaXNoZWQuDQo+ICAgICA+DQo+ICAgICA+IC9qcw0KPiAgICAgPg0KPiAg ICAgPiAtLQ0KPiAgICAgPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBV bml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiAgICAgPiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAg ICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQo+ICAgICA+IEZh eDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8vd3d3LmphY29icy11bml2ZXJz aXR5LmRlLz4NCj4gICAgID4NCj4gICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gICAgID4gbmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gICAgID4g bmV0Y29uZkBpZXRmLm9yZw0KPiAgICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldGNvbmYNCj4gICAgIA0KPiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gICAgIG5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ICAgICBu ZXRjb25mQGlldGYub3JnDQo+ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldGNvbmYNCj4gICAgIA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IG5ldGNvbmYgbWFpbGluZyBsaXN0DQo+IG5ldGNvbmZA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25m DQo= From nobody Wed Sep 25 07:56:14 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32681207FD for ; Wed, 25 Sep 2019 07:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_MIME_MALF=0.01] autolearn=ham autolearn_force=no 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 IsjkQcjjSBL2 for ; Wed, 25 Sep 2019 07:55:58 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 AFBF7120818 for ; Wed, 25 Sep 2019 07:55:57 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 6D9BF3E035D127FBB894 for ; Wed, 25 Sep 2019 15:55:55 +0100 (IST) Received: from lhreml705-chm.china.huawei.com (10.201.108.54) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 25 Sep 2019 15:55:55 +0100 Received: from lhreml705-chm.china.huawei.com (10.201.108.54) by lhreml705-chm.china.huawei.com (10.201.108.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Wed, 25 Sep 2019 15:55:54 +0100 Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml705-chm.china.huawei.com (10.201.108.54) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Wed, 25 Sep 2019 15:55:54 +0100 Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.185]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0439.000; Wed, 25 Sep 2019 22:55:49 +0800 From: Qin Wu To: netconf Thread-Topic: [netmod] CRUD operations on Leaf-list in RFC8040 Thread-Index: AQHVc7FRR8GsWGiAI0e0h5xov+X9IQ== Date: Wed, 25 Sep 2019 14:55:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/mixed; boundary="_004_B8F9A780D330094D99AF023C5877DABAA9323036dggeml511mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netconf] FW: [netmod] CRUD operations on Leaf-list in RFC8040 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2019 14:56:13 -0000 --_004_B8F9A780D330094D99AF023C5877DABAA9323036dggeml511mbschi_ Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA9323036dggeml511mbschi_" --_000_B8F9A780D330094D99AF023C5877DABAA9323036dggeml511mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQpTZW5kIHRvIG5ldGNvbmYgZm9yIGRpc2N1c3Npb24gaW4gdGhlIHJpZ2h0IHBsYWNlLHRoYW5r IEp1cmdlbiBmb3Iga2luZGx5IHJlbWluZGVyLg0KDQoNCreivP7Iy6O6IFFpbiBXdTxiaWxsLnd1 QGh1YXdlaS5jb208bWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbT4+DQrK1bz+yMujuiBuZXRtb2Q8 bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0Ks63LzaO6IFplbmdqdWFu PGFubmV0dGUuemVuZ0BodWF3ZWkuY29tPG1haWx0bzphbm5ldHRlLnplbmdAaHVhd2VpLmNvbT4+ DQrW98zio7ogW25ldG1vZF0gQ1JVRCBvcGVyYXRpb25zIG9uIExlYWYtbGlzdCBpbiBSRkM4MDQw DQrKsbzko7ogMjAxOS0wOS0yNSAxOTo1NToxMg0KDQpIaSwgQWxsOg0KRHVyaW5nIGltcGxlbWVu dGluZyBSRkM4MDQwLCB3ZSBmYWNlIGEgZmV3IHByb2JsZW1zIHJlbGF0ZWQgdG8gbGVhZi1saXN0 IHVzYWdlLg0KSSBhbSB3b25kZXJpbmcgaG93IGRvIHdlIGNyZWF0ZSBtdWx0aXBsZSBpbnN0YW5j ZSBvZiBsZWFmLWxpc3QgZGF0YSByZXNvdXJjZT8NClN1cHBvc2Ugd2UgaGF2ZSBleGFtcGxlLWZv by55YW5nIG1vZGVsIGFzIGZvbGxvd3M6DQpleGFtcGxlLXRvcC55YW5nDQoNCiAgIGNvbnRhaW5l ciB0b3Agew0KICAgIGxpc3QgbGlzdDEgew0KICAgICAgICBrZXkgImtleTEga2V5MiBrZXkzIjsN CiAgICAgICAgIC4uLg0KICAgICAgICAgbGlzdCBsaXN0MiB7DQogICAgICAgICAgICAga2V5ICJr ZXk0IGtleTUiOw0KICAgICAgICAgICAgIC4uLg0KICAgICAgICAgICAgIGxlYWYgWCB7IHR5cGUg c3RyaW5nOyB9DQogICAgICAgICB9DQogICAgIH0NCiAgICAgbGVhZi1saXN0IFkgew0KICAgICAg IHR5cGUgdWludDMyOw0KICAgICB9DQp9DQpUbyBjcmVhdGUgYSBuZXcgIlkiIHJlc291cmNlIHdp dGhpbiB0aGUgInRvcCIgcmVzb3VyY2UsIGNhbiB3ZSBtYWtlDQp0aGUgY2xpZW50IHNlbmQgdGhl IGZvbGxvd2luZyByZXF1ZXN0Og0KUE9TVCAvcmVzdGNvbmYvZGF0YS9leGFtcGxlLXRvcDp0b3Ag SFRUUC8xLjENCkhvc3Q6IGV4YW1wbGUuY29tDQpDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3lh bmctZGF0YStqc29uDQoNCnsNCiAgImV4YW1wbGUtdG9wOlkiIDogW3ZhbHVlMSx2YWx1ZTJdDQp9 DQoNCnJlc3BvbnNlo7oNCkhUVFAvMS4xIDIwMSBDcmVhdGVkDQpEYXRlOiBUaHUsIDI2IEphbiAy MDE3IDIwOjU2OjMwIEdNVA0KU2VydmVyOiBleGFtcGxlLXNlcnZlcg0KTG9jYXRpb246IGh0dHBz Oi8vZXhhbXBsZS5jb20vcmVzdGNvbmYvZGF0YS9leGFtcGxlLXRvcDp0b3AvWT12YWx1ZTEmdmFs dWUyDQpMYXN0LU1vZGlmaWVkOiBUaHUsIDI2IEphbiAyMDE3IDIwOjU2OjMwIEdNVA0KRVRhZzog ImIzODMwZjIzYTRjIg0KDQpBbHNvIEkgZG9uoa90IHVuZGVyc3RhbmQgd2h5IHdlIGFkZCBsaW1p dGF0aW9uIHRvIFBVVCBtZXRob2QgYW5kIHBsYWluIHBhdGNoIG1ldGhvZCBvbiBsZWFmLWxpc3Qg YW5kIGRvbqGvdCBhbGxvdw0KVGhlIHZhbHVlIG9mIGxlYWYtbGlzdCBpbnN0YW5jZSB0byBiZSBj aGFuZ2VkIGJ5IHRoZXNlIHR3byBtZXRob2RzDQpzZWUgc2VjdGlvbiA0LjUgYW5kIHNlY3Rpb24g NC42LjENCqGwDQo0LjUuICBQVVQNCiAgIElmIHRoZSB0YXJnZXQgcmVzb3VyY2UgcmVwcmVzZW50 cyBhIFlBTkcgbGVhZi1saXN0LCB0aGVuIHRoZSBQVVQNCiAgIG1ldGhvZCBNVVNUIE5PVCBjaGFu Z2UgdGhlIHZhbHVlIG9mIHRoZSBsZWFmLWxpc3QgaW5zdGFuY2UuDQo0LjYuMS4uICBQbGFpbiBQ YXRjaA0KICAgSWYgdGhlIHRhcmdldCByZXNvdXJjZSByZXByZXNlbnRzIGEgWUFORyBsZWFmLWxp c3QsIHRoZW4gdGhlIFBBVENIDQogICBtZXRob2QgTVVTVCBOT1QgY2hhbmdlIHRoZSB2YWx1ZSBv ZiB0aGUgbGVhZi1saXN0IGluc3RhbmNlLg0KobANClN1cHBvc2UgSSB3YW50IHRvIGRlbGV0ZSBh bGwgbGVhZi1saXN0IGluc3RhbmNlIHZhbHVlcyBhc3NvY2lhdGVkIHdpdGggbGVhZi1saXN0ICJZ IiwNCkNhbiBJIHNlbmQgdGhlIGZvbGxvd2luZyByZXF1ZXN0Og0KREVMRVRFIC9yZXN0Y29uZi9k YXRhL2V4YW1wbGUtdG9wOnRvcC9ZICBIVFRQLzEuMQ0KSG9zdDogZXhhbXBsZS5jb20NCg0KUXVv dGVkIHNlY3Rpb24gNC43Og0KobANCjQuNy4gIERFTEVURQ0KICAgSWYgdGhlIHRhcmdldCByZXNv dXJjZSByZXByZXNlbnRzIGEgY29uZmlndXJhdGlvbiBsZWFmLWxpc3Qgb3IgbGlzdA0KICAgZGF0 YSBub2RlLCB0aGVuIGl0IE1VU1QgcmVwcmVzZW50IGEgc2luZ2xlIFlBTkcgbGVhZi1saXN0IG9y IGxpc3QNCiAgIGluc3RhbmNlLiAgVGhlIHNlcnZlciBNVVNUIE5PVCB1c2UgdGhlIERFTEVURSBt ZXRob2QgdG8gZGVsZXRlIG1vcmUNCiAgIHRoYW4gb25lIHN1Y2ggaW5zdGFuY2UuDQqhsQ0KSXQg c2VlbXMgb2J2aW91cyB0aGF0IERFTEVURSBtZXRob2QgY2FuIG5vdCBkZWxldGUgbW9yZSB0aGFu IG9uZSBpbnN0YW5jZXMuIEJ1dCBJIGRvbqGvdCBrbm93IHdoeT8NCg0KDQpBbHNvIEkgZG9uoa90 IGtub3cgd2UgYWRkIGNvbnN0cmFpbnQgb24gWE1MIGVuY29kaW5nIGluIHRoZSBHZXQgcmVxdWVz dCwgb25seSBhbGxvdyBvbmUgc2luZ2xlIGVsZW1lbnQgYmUNCnJldHVybmVkIGZvciBYTUwgZW5j b2RpbmcsIHNlZSBzZWN0aW9uIDQuMyBvZiBSRkM4MDQwIGFzIGZvbGxvd3M6DQqhsA0KNC4zLiAg R0VUDQogICBJZiBhIHJldHJpZXZhbCByZXF1ZXN0IGZvciBhIGRhdGEgcmVzb3VyY2UgcmVwcmVz ZW50aW5nIGEgWUFORw0KICAgbGVhZi1saXN0IG9yIGxpc3Qgb2JqZWN0IGlkZW50aWZpZXMgbW9y ZSB0aGFuIG9uZSBpbnN0YW5jZSBhbmQgWE1MDQogICBlbmNvZGluZyBpcyB1c2VkIGluIHRoZSBy ZXNwb25zZSwgdGhlbiBhbiBlcnJvciByZXNwb25zZSBjb250YWluaW5nIGENCiAgICI0MDAgQmFk IFJlcXVlc3QiIHN0YXR1cy1saW5lIE1VU1QgYmUgcmV0dXJuZWQgYnkgdGhlIHNlcnZlci4NCqGw DQpTdXBwb3NlIEkgd2FudCB0byByZXRyaWV2ZS9kZWxldGUvbW9kaWZ5IG11bHRpcGxlIGxlYWYt bGlzdCBpbnN0YW5jZSBkYXRhIHJlc291cmNlLCBjYW4gSSB3cmFwIGxlYWYtbGlzdCAiWSIgd2l0 aGluIGNvbnRhaW5lciAidG9wIiwNCmNyZWF0ZS9kZWxldGUvbW9kaWZ5IGNvbnRhaW5lciAidG9w IiBkYXRhIHJlc291cmNlPw0KobANCkNvbW1lbnRzPw0KDQotUWluDQoNCg== --_000_B8F9A780D330094D99AF023C5877DABAA9323036dggeml511mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Send to netconf for discussion in the right place,thank Jurgen for kindly r= eminder.


=B7=A2=BC=FE=C8=CB=A3=BA Qin Wu<bill.wu@huawei.com>
=CA=D5=BC=FE=C8=CB=A3=BA netmod<netmod@ietf.org>
=B3=AD=CB=CD=A3=BA Zengjuan<annette.zeng@huawei.com>
=D6=F7=CC=E2=A3=BA [netmod] CRUD operations on Leaf-list in RFC= 8040
=CA=B1=BC=E4=A3=BA 2019-09-25 19:55:12

Hi, = All:

Duri= ng implementing RFC8040, we face a few problems related to leaf-list usage.=

I am= wondering how do we create multiple instance of leaf-list data resource?

Supp= ose we have example-foo.yang model as follows:

exam= ple-top.yang

&nbs= p;

&nbs= p;  container top {

&nbs= p;   list list1 {

&nbs= p;       key "key1 key2 key3";

&nbs= p;        ...

&nbs= p;        list list2 {

&nbs= p;            key &q= uot;key4 key5";

&nbs= p;            ...

&nbs= p;            leaf X= { type string; }

&nbs= p;        }

&nbs= p;    }

&nbs= p;    leaf-list Y {

&nbs= p;      type uint32;

&nbs= p;    }

}

To c= reate a new "Y" resource within the "top" resource, can= we make

the = client send the following request:

POST= /restconf/data/example-top:top HTTP/1.1

Host= : example.com

Cont= ent-Type: application/yang-data+json

&nbs= p;

{

&nbs= p; "example-top:Y" : [value1,value2]

}

&nbs= p;

resp= onse=A3= =BA

HTTP= /1.1 201 Created

Date= : Thu, 26 Jan 2017 20:56:30 GMT

Serv= er: example-server

Loca= tion: https://example.com/restconf/data/example-top:top/Y=3Dvalue1&valu= e2

Last= -Modified: Thu, 26 Jan 2017 20:56:30 GMT

ETag= : "b3830f23a4c"

 

Also= I don=A1=AFt understand why we add limitation to PUT method and plain patc= h method on leaf-list and don=A1=AFt allow

The = value of leaf-list instance to be changed by these two methods

see = section 4.5 and section 4.6.1

=A1= =B0

4.5.=   PUT

&nbs= p;  If the target resource represents a YANG leaf-list, then the PUT

&nbs= p;  method MUST NOT change the value of the leaf-list instance.=

4.6.= 1..  Plain Patch

&nbs= p;  If the target resource represents a YANG leaf-list, then the PATCH=

&nbs= p;  method MUST NOT change the value of the leaf-list instance.=

=A1= =B0

Supp= ose I want to delete all leaf-list instance values associated with leaf-lis= t "Y",

Can = I send the following request:

DELE= TE /restconf/data/example-top:top/Y  HTTP/1.1

Host= : example.com

&nbs= p;

Quot= ed section 4.7:

=A1= =B0

4.7.=   DELETE 

&nbs= p;  If the target resource represents a configuration leaf-list o= r list

&nbs= p;  data node, then it MUST represent a single YANG leaf-list or list<= /span>

&nbs= p;  instance.  The server MUST NOT use the DELETE method to delet= e more

&nbs= p;  than one such instance.

=A1= =B1

It s= eems obvious that DELETE method can not delete more than one instances. But= I don=A1=AFt know why?

&nbs= p;

Also I don=A1=AFt=
 know we add constraint on XML encoding in the Get request, only allow one =
single element be

retu= rned for XML encoding, see section 4.3 of RFC8040 as follows:

=A1= =B0

4.3.=   GET

&nbs= p;  If a retrieval request for a data resource representing a YANG

&nbs= p;  leaf-list or list object identifies more than one instance and XML=

&nbs= p;  encoding is used in the response, then an error response containin= g a

&nbs= p;  "400 Bad Request" status-line MUST be returned by the se= rver.

=A1= =B0

Supp= ose I want to retrieve/delete/modify multiple leaf-list instance data resou= rce, can I wrap leaf-list "Y" within container "top",

crea= te/delete/modify container "top" data resource?

=A1= =B0

Comm= ents?

&nbs= p;

-Qin=

&nbs= p;

--_000_B8F9A780D330094D99AF023C5877DABAA9323036dggeml511mbschi_-- --_004_B8F9A780D330094D99AF023C5877DABAA9323036dggeml511mbschi_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=133; creation-date="Wed, 25 Sep 2019 11:55:12 GMT"; modification-date="Wed, 25 Sep 2019 11:55:12 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBt YWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2QNCg== --_004_B8F9A780D330094D99AF023C5877DABAA9323036dggeml511mbschi_-- From nobody Wed Sep 25 08:01:29 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4AB31200C7 for ; Wed, 25 Sep 2019 08:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_MIME_MALF=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 8XBf92Mb6c5v for ; Wed, 25 Sep 2019 08:01:20 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2A8120026 for ; Wed, 25 Sep 2019 08:01:20 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id y127so4494147lfc.0 for ; Wed, 25 Sep 2019 08:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3PBDJF9+r4uZ6Rzv+uD9chYC8DPAZaXne21r0mZeHP8=; b=VwTEfUmeviJB1BhadWfJzR0bm9kT2vS6LvDt7ogrckYYdu/x+YZZLDkB9YWy1rkbqJ r9Hg2jtd6e6QB1lyqQXdWkvBgT2virSR797LAZDS4EKxBzsaW3nqJmkrdSOgAfS8EC70 aE2Q9izDXV7XzBQvOv+lliZ8slahpEoqhqfr3r/O2slzt3nwR2plK97r2W/dPbzI4f3r N1FBRUDRQvdLKclDvY1+uQEig/mXyBZj0qAPdWGqaEc4cHjInSiVVk+TpndSmn6lIqAe Xka/TOsCY9RMo5ZR2AcsUJPvssA+cg2vOMNciBGGWqV7DINQwH/RXLcyMVaLSDyxZVMj YUkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3PBDJF9+r4uZ6Rzv+uD9chYC8DPAZaXne21r0mZeHP8=; b=RTKVALy4S6C75fyKJKWlc1fZ7d/PfPCD4AqcO0eAzoLPWEdnCAXkLQuczXxfhx5nk+ qZy94T+2btF9RJNLTDwiVJ1gvM8krC+rFOreHwVEETJu+xIHkw5dLun6Lyzo6oZEGhFC nLhgecQRbbRWrvgZgS6htnDbu7GK4gV+NdbRSlqBfFiYvkeU6LVUosR35DmIfs8ZvpKd qBhFByWQqaGO3Mpj3wP3ItMm2d542lAVFEXJv/psG8JMWC8H7XbYe26UYRNc1w6R3E9O ODrBHogKePzKFKlePZ0bdgL/KJ/0kAjMK79pXnxTMbwnZtca5BHboFEEiehABHZR7Igr 3rLQ== X-Gm-Message-State: APjAAAUHV6wATul2gjG3UKMrL+g9BHuxllQc+Ap7pJQ8i8DR1EvjijF5 /7sub+p3Jv9T0g0n2XL/kD4wDEHeIycLCsBpjFDnLA== X-Google-Smtp-Source: APXvYqz2p96HWB0U+U3K4cWZgyBOmILrQpHqjSCMb8jD3ilpsFs6Sj+in4HsISBtDnccgA0yXl8eGX60Mox/XQEIFrY= X-Received: by 2002:ac2:554e:: with SMTP id l14mr6916765lfk.32.1569423678367; Wed, 25 Sep 2019 08:01:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Wed, 25 Sep 2019 08:01:07 -0700 Message-ID: To: Qin Wu Cc: netconf Content-Type: multipart/alternative; boundary="000000000000da06a0059361ece7" Archived-At: Subject: Re: [netconf] FW: [netmod] CRUD operations on Leaf-list in RFC8040 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2019 15:01:24 -0000 --000000000000da06a0059361ece7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, The RESTCONF target resource has to be one resource. The WG added YANG Patch (RFC 8072) to do more complex editing operations. Andy On Wed, Sep 25, 2019 at 7:57 AM Qin Wu wrote: > > Send to netconf for discussion in the right place,thank Jurgen for kindly > reminder. > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A *Qin Wu > *=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A *netmod > *=E6=8A=84=E9=80=81=EF=BC=9A *Zengjuan > *=E4=B8=BB=E9=A2=98=EF=BC=9A *[netmod] CRUD operations on Leaf-list in RF= C8040 > *=E6=97=B6=E9=97=B4=EF=BC=9A *2019-09-25 19:55:12 > > Hi, All: > > During implementing RFC8040, we face a few problems related to leaf-list > usage. > > I am wondering how do we create multiple instance of leaf-list data > resource? > > Suppose we have example-foo.yang model as follows: > > example-top.yang > > > > container top { > > list list1 { > > key "key1 key2 key3"; > > ... > > list list2 { > > key "key4 key5"; > > ... > > leaf X { type string; } > > } > > } > > leaf-list Y { > > type uint32; > > } > > } > > To create a new "Y" resource within the "top" resource, can we make > > the client send the following request: > > POST /restconf/data/example-top:top HTTP/1.1 > > Host: example.com > > Content-Type: application/yang-data+json > > > > { > > "example-top:Y" : [value1,value2] > > } > > > > response=EF=BC=9A > > HTTP/1.1 201 Created > > Date: Thu, 26 Jan 2017 20:56:30 GMT > > Server: example-server > > Location: > https://example.com/restconf/data/example-top:top/Y=3Dvalue1&value2 > > Last-Modified: Thu, 26 Jan 2017 20:56:30 GMT > > ETag: "b3830f23a4c" > > > > Also I don=E2=80=99t understand why we add limitation to PUT method and p= lain > patch method on leaf-list and don=E2=80=99t allow > > The value of leaf-list instance to be changed by these two methods > > see section 4.5 and section 4.6.1 > > =E2=80=9C > > 4.5. PUT > > If the target resource represents a YANG leaf-list, then the PUT > > method MUST NOT change the value of the leaf-list instance. > > 4.6.1.. Plain Patch > > If the target resource represents a YANG leaf-list, then the PATCH > > method MUST NOT change the value of the leaf-list instance. > > =E2=80=9C > > Suppose I want to delete all leaf-list instance values associated with > leaf-list "Y", > > Can I send the following request: > > DELETE /restconf/data/example-top:top/Y HTTP/1.1 > > Host: example.com > > > > Quoted section 4.7: > > =E2=80=9C > > 4.7. DELETE > > If the target resource represents a configuration leaf-list or list > > data node, then it MUST represent a single YANG leaf-list or list > > instance. The server MUST NOT use the DELETE method to delete more > > than one such instance. > > =E2=80=9D > > It seems obvious that DELETE method can not delete more than one > instances. But I don=E2=80=99t know why? > > > > Also I don=E2=80=99t know we add constraint on XML encoding in the Get re= quest, only allow one single element be > > returned for XML encoding, see section 4.3 of RFC8040 as follows: > > =E2=80=9C > > 4.3. GET > > If a retrieval request for a data resource representing a YANG > > leaf-list or list object identifies more than one instance and XML > > encoding is used in the response, then an error response containing a > > "400 Bad Request" status-line MUST be returned by the server. > > =E2=80=9C > > Suppose I want to retrieve/delete/modify multiple leaf-list instance data > resource, can I wrap leaf-list "Y" within container "top", > > create/delete/modify container "top" data resource? > > =E2=80=9C > > Comments? > > > > -Qin > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000da06a0059361ece7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

The RESTCONF target resource has to= be one resource.
The WG added YANG Patch (RFC 8072) to do more c= omplex editing operations.

Andy


On Wed, Sep 25, 2019 at 7:57 AM Qin Wu <bill.wu@huawei.com> wrote:

Send to netconf for discussion in the right place,thank Jurgen for kindly r= eminder.


=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Qin Wu<bill.wu@huawei.com>
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A netmod<netmod@ietf.org>
=E6=8A=84=E9=80=81=EF=BC=9A Zengjuan<annette.zeng@huawei.com>
=E4=B8=BB=E9=A2=98=EF=BC=9A [netmod] CRUD operations on Leaf-li= st in RFC8040
=E6=97=B6=E9=97=B4=EF=BC=9A 2019-09-25 19:55:12

H= i, All:

D= uring implementing RFC8040, we face a few problems related to leaf-list usa= ge.

I= am wondering how do we create multiple instance of leaf-list data resource= ?

S= uppose we have example-foo.yang model as follows:

e= xample-top.yang

= =C2=A0

= =C2=A0=C2=A0 container top {

= =C2=A0=C2=A0=C2=A0 list list1 {

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 key "key1 key2 key3";<= /span>

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ...

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 list list2 {

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ke= y "key4 key5";

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ..= .

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 le= af X { type string; }

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }

= =C2=A0=C2=A0=C2=A0=C2=A0 }

= =C2=A0=C2=A0=C2=A0=C2=A0 leaf-list Y {

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type uint32;

= =C2=A0=C2=A0=C2=A0=C2=A0 }

}=

T= o create a new "Y" resource within the "top" resource, = can we make

t= he client send the following request:

P= OST /restconf/data/example-top:top HTTP/1.1

H= ost: example.com

C= ontent-Type: application/yang-data+json

= =C2=A0

{=

= =C2=A0 "example-top:Y" : [value1,value2]

}=

= =C2=A0

r= esponse=EF=BC=9A

H= TTP/1.1 201 Created

D= ate: Thu, 26 Jan 2017 20:56:30 GMT

S= erver: example-server

L= ocation: https://example.com/restconf/data/examp= le-top:top/Y=3Dvalue1&value2

L= ast-Modified: Thu, 26 Jan 2017 20:56:30 GMT

E= Tag: "b3830f23a4c"

=C2=A0

A= lso I don=E2=80=99t understand why we add limitation to PUT method and plai= n patch method on leaf-list and don=E2=80=99t allow

T= he value of leaf-list instance to be changed by these two methods

s= ee section 4.5 and section 4.6.1

= =E2=80=9C

4= .5.=C2=A0 PUT

= =C2=A0=C2=A0 If the target resource represents a YANG leaf-list, then the P= UT

= =C2=A0=C2=A0 method MUST NOT change the value of the leaf-list instance.

4= .6.1..=C2=A0 Plain Patch

= =C2=A0=C2=A0 If the target resource represents a YANG leaf-list, then the P= ATCH

= =C2=A0=C2=A0 method MUST NOT change the value of the leaf-list instance.

= =E2=80=9C

S= uppose I want to delete all leaf-list instance values associated with leaf-= list "Y",

C= an I send the following request:

D= ELETE /restconf/data/example-top:top/Y=C2=A0 HTTP/1.1

H= ost: example.com

= =C2=A0

Q= uoted section 4.7:

= =E2=80=9C

4= .7.=C2=A0 DELETE=C2=A0

= =C2=A0=C2=A0=C2=A0If the target resource represents a configuration leaf-li= st or list

= =C2=A0=C2=A0 data node, then it MUST represent a single YANG leaf-list or l= ist

= =C2=A0=C2=A0 instance.=C2=A0 The server MUST NOT use the DELETE method to d= elete more

= =C2=A0=C2=A0 than one such instance.

= =E2=80=9D

I= t seems obvious that DELETE method can not delete more than one instances. = But I don=E2=80=99t know why?

= =C2=A0

Also I don=E2=80=99t kno=
w we add constraint on XML encoding in the Get request, only allow one sing=
le element be

r= eturned for XML encoding, see section 4.3 of RFC8040 as follows:

= =E2=80=9C

4= .3.=C2=A0 GET

= =C2=A0=C2=A0 If a retrieval request for a data resource representing a YANG=

= =C2=A0=C2=A0 leaf-list or list object identifies more than one instance and= XML

= =C2=A0=C2=A0 encoding is used in the response, then an error response conta= ining a

= =C2=A0=C2=A0 "400 Bad Request" status-line MUST be returned by th= e server.

= =E2=80=9C

S= uppose I want to retrieve/delete/modify multiple leaf-list instance data re= source, can I wrap leaf-list "Y" within container "top"= ,

c= reate/delete/modify container "top" data resource?

= =E2=80=9C

C= omments?

= =C2=A0

-= Qin

= =C2=A0

_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000da06a0059361ece7-- From nobody Wed Sep 25 18:27:29 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97221120131 for ; Wed, 25 Sep 2019 18:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_MIME_MALF=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 OcPZv--QIe8v for ; Wed, 25 Sep 2019 18:27:23 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 E190A120088 for ; Wed, 25 Sep 2019 18:27:22 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id A2993E7B47BF6A3F63EC for ; Thu, 26 Sep 2019 02:27:16 +0100 (IST) Received: from lhreml722-chm.china.huawei.com (10.201.108.73) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 26 Sep 2019 02:27:15 +0100 Received: from lhreml722-chm.china.huawei.com (10.201.108.73) by lhreml722-chm.china.huawei.com (10.201.108.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 26 Sep 2019 02:27:16 +0100 Received: from DGGEML406-HUB.china.huawei.com (10.3.17.50) by lhreml722-chm.china.huawei.com (10.201.108.73) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Thu, 26 Sep 2019 02:27:15 +0100 Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.185]) by dggeml406-hub.china.huawei.com ([10.3.17.50]) with mapi id 14.03.0439.000; Thu, 26 Sep 2019 09:27:00 +0800 From: Qin Wu To: Andy Bierman CC: netconf Thread-Topic: [netconf] FW: [netmod] CRUD operations on Leaf-list in RFC8040 Thread-Index: AdV0B+HZ9iWcMAYYRQa4/ijv7YCCIw== Date: Thu, 26 Sep 2019 01:26:59 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.31.203] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAA9323418dggeml511mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netconf] FW: [netmod] CRUD operations on Leaf-list in RFC8040 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2019 01:27:27 -0000 --_000_B8F9A780D330094D99AF023C5877DABAA9323418dggeml511mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5keToNCkl0IGlzIG5vdCBjbGVhciB0byBtZSBob3cgWUFORyBQYXRjaCBvcGVyYXRpb24gb24g bGVhZi1saXN0IGlzIGRpZmZlcmVudCBmcm9tIHdoYXQgUkZDODA0MCBpcyBkb2luZy4NClNpbWls YXIgdG8gUkZDODA0MCwgWUFORyBleGFtcGxlIGRlc2NyaWJlZCBpbiBSRkM4MDcyIGFwcGVuZGl4 IGlzIHVzaW5nICJleGFtcGxlLWp1a2Vib3giIFlBTkcgbW9kdWxlDQpXaXRoICJhcnRpc3QiIGxp c3QsICJhbGJ1bSIgbGlzdCwgInNvbmciIGxpc3QsICJwbGF5bGlzdCIgbGlzdCBpbnN0ZWFkIG9m IGFueSBsZWFmLWxpc3Qgbm9kZQ0KDQpDYW4geW91IHByb3ZpZGUgYW4gWUFORyBwYXRjaCBleGFt cGxlIHdoaWNoIGFsbG93cyBDUlVEIG9wZXJhdGlvbnMgb24gbXVsdGlwbGUgbGVhZi1saXN0IGlu c3RhbmNlcz8NCg0KQnkgcmVhZGluZyBTZWN0aW9uIDQuMyBvZiBSRkM4MDQwDQrigJwNCk1vcmUg dGhhbiBvbmUgZWxlbWVudCBNVVNUIE5PVCBiZQ0KICAgcmV0dXJuZWQgZm9yIFhNTCBlbmNvZGlu Zy4gIElmIG11bHRpcGxlIGVsZW1lbnRzIGFyZSBzZW50IGluIGEgSlNPTg0KICAgbWVzc2FnZS1i b2R5LCB0aGVuIHRoZXkgTVVTVCBiZSBzZW50IGFzIGEgSlNPTiBhcnJheS4NCuKAnQ0KSXQgbG9v a3MgdG8gbWUgWE1MIGVuY29kaW5nIHJlc3RyaWN0cyBvbmx5IG9uZSBlbGVtZW50IG9yIGxlYWYt bGlzdCBpbnN0YW5jZSBjYW4gYmUgcmV0dXJuZWQgYnV0IEpTT04gZW5jb2RpbmcgaGFzIG5vIHN1 Y2ggbGltaXRhdGlvbi4NCkkgYW0gd29uZGVyaW5nIHdoZXRoZXIgWUFORyBwYXRjaCBpbiBSRkM4 MDcyIGhhcyBzaW1pbGFyIGlzc3VlIHdoZW4gd2Ugc2VsZWN0IGJldHdlZW4gWE1MIGVuY29kaW5n IGFuZCBKU09OIGVuY29kaW5nLg0KDQotUWluDQrlj5Hku7bkuro6IEFuZHkgQmllcm1hbiBbbWFp bHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0NCuWPkemAgeaXtumXtDogMjAxOeW5tDnmnIgyNeaXpSAy MzowMQ0K5pS25Lu25Lq6OiBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT4NCuaKhOmAgTogbmV0 Y29uZiA8bmV0Y29uZkBpZXRmLm9yZz4NCuS4u+mimDogUmU6IFtuZXRjb25mXSBGVzogW25ldG1v ZF0gQ1JVRCBvcGVyYXRpb25zIG9uIExlYWYtbGlzdCBpbiBSRkM4MDQwDQoNCkhpLA0KDQpUaGUg UkVTVENPTkYgdGFyZ2V0IHJlc291cmNlIGhhcyB0byBiZSBvbmUgcmVzb3VyY2UuDQpUaGUgV0cg YWRkZWQgWUFORyBQYXRjaCAoUkZDIDgwNzIpIHRvIGRvIG1vcmUgY29tcGxleCBlZGl0aW5nIG9w ZXJhdGlvbnMuDQoNCkFuZHkNCg0KDQpPbiBXZWQsIFNlcCAyNSwgMjAxOSBhdCA3OjU3IEFNIFFp biBXdSA8YmlsbC53dUBodWF3ZWkuY29tPG1haWx0bzpiaWxsLnd1QGh1YXdlaS5jb20+PiB3cm90 ZToNCg0KU2VuZCB0byBuZXRjb25mIGZvciBkaXNjdXNzaW9uIGluIHRoZSByaWdodCBwbGFjZSx0 aGFuayBKdXJnZW4gZm9yIGtpbmRseSByZW1pbmRlci4NCg0K5Y+R5Lu25Lq677yaIFFpbiBXdTxi aWxsLnd1QGh1YXdlaS5jb208bWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbT4+DQrmlLbku7bkurrv vJogbmV0bW9kPG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPj4NCuaKhOmA ge+8miBaZW5nanVhbjxhbm5ldHRlLnplbmdAaHVhd2VpLmNvbTxtYWlsdG86YW5uZXR0ZS56ZW5n QGh1YXdlaS5jb20+Pg0K5Li76aKY77yaIFtuZXRtb2RdIENSVUQgb3BlcmF0aW9ucyBvbiBMZWFm LWxpc3QgaW4gUkZDODA0MA0K5pe26Ze077yaIDIwMTktMDktMjUgMTk6NTU6MTINCg0KSGksIEFs bDoNCkR1cmluZyBpbXBsZW1lbnRpbmcgUkZDODA0MCwgd2UgZmFjZSBhIGZldyBwcm9ibGVtcyBy ZWxhdGVkIHRvIGxlYWYtbGlzdCB1c2FnZS4NCkkgYW0gd29uZGVyaW5nIGhvdyBkbyB3ZSBjcmVh dGUgbXVsdGlwbGUgaW5zdGFuY2Ugb2YgbGVhZi1saXN0IGRhdGEgcmVzb3VyY2U/DQpTdXBwb3Nl IHdlIGhhdmUgZXhhbXBsZS1mb28ueWFuZyBtb2RlbCBhcyBmb2xsb3dzOg0KZXhhbXBsZS10b3Au eWFuZw0KDQogICBjb250YWluZXIgdG9wIHsNCiAgICBsaXN0IGxpc3QxIHsNCiAgICAgICAga2V5 ICJrZXkxIGtleTIga2V5MyI7DQogICAgICAgICAuLi4NCiAgICAgICAgIGxpc3QgbGlzdDIgew0K ICAgICAgICAgICAgIGtleSAia2V5NCBrZXk1IjsNCiAgICAgICAgICAgICAuLi4NCiAgICAgICAg ICAgICBsZWFmIFggeyB0eXBlIHN0cmluZzsgfQ0KICAgICAgICAgfQ0KICAgICB9DQogICAgIGxl YWYtbGlzdCBZIHsNCiAgICAgICB0eXBlIHVpbnQzMjsNCiAgICAgfQ0KfQ0KVG8gY3JlYXRlIGEg bmV3ICJZIiByZXNvdXJjZSB3aXRoaW4gdGhlICJ0b3AiIHJlc291cmNlLCBjYW4gd2UgbWFrZQ0K dGhlIGNsaWVudCBzZW5kIHRoZSBmb2xsb3dpbmcgcmVxdWVzdDoNClBPU1QgL3Jlc3Rjb25mL2Rh dGEvZXhhbXBsZS10b3A6dG9wIEhUVFAvMS4xDQpIb3N0OiBleGFtcGxlLmNvbTxodHRwOi8vZXhh bXBsZS5jb20+DQpDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3lhbmctZGF0YStqc29uDQoNCnsN CiAgImV4YW1wbGUtdG9wOlkiIDogW3ZhbHVlMSx2YWx1ZTJdDQp9DQoNCnJlc3BvbnNl77yaDQpI VFRQLzEuMSAyMDEgQ3JlYXRlZA0KRGF0ZTogVGh1LCAyNiBKYW4gMjAxNyAyMDo1NjozMCBHTVQN ClNlcnZlcjogZXhhbXBsZS1zZXJ2ZXINCkxvY2F0aW9uOiBodHRwczovL2V4YW1wbGUuY29tL3Jl c3Rjb25mL2RhdGEvZXhhbXBsZS10b3A6dG9wL1k9dmFsdWUxJnZhbHVlMg0KTGFzdC1Nb2RpZmll ZDogVGh1LCAyNiBKYW4gMjAxNyAyMDo1NjozMCBHTVQNCkVUYWc6ICJiMzgzMGYyM2E0YyINCg0K QWxzbyBJIGRvbuKAmXQgdW5kZXJzdGFuZCB3aHkgd2UgYWRkIGxpbWl0YXRpb24gdG8gUFVUIG1l dGhvZCBhbmQgcGxhaW4gcGF0Y2ggbWV0aG9kIG9uIGxlYWYtbGlzdCBhbmQgZG9u4oCZdCBhbGxv dw0KVGhlIHZhbHVlIG9mIGxlYWYtbGlzdCBpbnN0YW5jZSB0byBiZSBjaGFuZ2VkIGJ5IHRoZXNl IHR3byBtZXRob2RzDQpzZWUgc2VjdGlvbiA0LjUgYW5kIHNlY3Rpb24gNC42LjENCuKAnA0KNC41 LiAgUFVUDQogICBJZiB0aGUgdGFyZ2V0IHJlc291cmNlIHJlcHJlc2VudHMgYSBZQU5HIGxlYWYt bGlzdCwgdGhlbiB0aGUgUFVUDQogICBtZXRob2QgTVVTVCBOT1QgY2hhbmdlIHRoZSB2YWx1ZSBv ZiB0aGUgbGVhZi1saXN0IGluc3RhbmNlLg0KNC42LjEuLiAgUGxhaW4gUGF0Y2gNCiAgIElmIHRo ZSB0YXJnZXQgcmVzb3VyY2UgcmVwcmVzZW50cyBhIFlBTkcgbGVhZi1saXN0LCB0aGVuIHRoZSBQ QVRDSA0KICAgbWV0aG9kIE1VU1QgTk9UIGNoYW5nZSB0aGUgdmFsdWUgb2YgdGhlIGxlYWYtbGlz dCBpbnN0YW5jZS4NCuKAnA0KU3VwcG9zZSBJIHdhbnQgdG8gZGVsZXRlIGFsbCBsZWFmLWxpc3Qg aW5zdGFuY2UgdmFsdWVzIGFzc29jaWF0ZWQgd2l0aCBsZWFmLWxpc3QgIlkiLA0KQ2FuIEkgc2Vu ZCB0aGUgZm9sbG93aW5nIHJlcXVlc3Q6DQpERUxFVEUgL3Jlc3Rjb25mL2RhdGEvZXhhbXBsZS10 b3A6dG9wL1kgIEhUVFAvMS4xDQpIb3N0OiBleGFtcGxlLmNvbTxodHRwOi8vZXhhbXBsZS5jb20+ DQoNClF1b3RlZCBzZWN0aW9uIDQuNzoNCuKAnA0KNC43LiAgREVMRVRFDQogICBJZiB0aGUgdGFy Z2V0IHJlc291cmNlIHJlcHJlc2VudHMgYSBjb25maWd1cmF0aW9uIGxlYWYtbGlzdCBvciBsaXN0 DQogICBkYXRhIG5vZGUsIHRoZW4gaXQgTVVTVCByZXByZXNlbnQgYSBzaW5nbGUgWUFORyBsZWFm LWxpc3Qgb3IgbGlzdA0KICAgaW5zdGFuY2UuICBUaGUgc2VydmVyIE1VU1QgTk9UIHVzZSB0aGUg REVMRVRFIG1ldGhvZCB0byBkZWxldGUgbW9yZQ0KICAgdGhhbiBvbmUgc3VjaCBpbnN0YW5jZS4N CuKAnQ0KSXQgc2VlbXMgb2J2aW91cyB0aGF0IERFTEVURSBtZXRob2QgY2FuIG5vdCBkZWxldGUg bW9yZSB0aGFuIG9uZSBpbnN0YW5jZXMuIEJ1dCBJIGRvbuKAmXQga25vdyB3aHk/DQoNCg0KQWxz byBJIGRvbuKAmXQga25vdyB3ZSBhZGQgY29uc3RyYWludCBvbiBYTUwgZW5jb2RpbmcgaW4gdGhl IEdldCByZXF1ZXN0LCBvbmx5IGFsbG93IG9uZSBzaW5nbGUgZWxlbWVudCBiZQ0KcmV0dXJuZWQg Zm9yIFhNTCBlbmNvZGluZywgc2VlIHNlY3Rpb24gNC4zIG9mIFJGQzgwNDAgYXMgZm9sbG93czoN CuKAnA0KNC4zLiAgR0VUDQogICBJZiBhIHJldHJpZXZhbCByZXF1ZXN0IGZvciBhIGRhdGEgcmVz b3VyY2UgcmVwcmVzZW50aW5nIGEgWUFORw0KICAgbGVhZi1saXN0IG9yIGxpc3Qgb2JqZWN0IGlk ZW50aWZpZXMgbW9yZSB0aGFuIG9uZSBpbnN0YW5jZSBhbmQgWE1MDQogICBlbmNvZGluZyBpcyB1 c2VkIGluIHRoZSByZXNwb25zZSwgdGhlbiBhbiBlcnJvciByZXNwb25zZSBjb250YWluaW5nIGEN CiAgICI0MDAgQmFkIFJlcXVlc3QiIHN0YXR1cy1saW5lIE1VU1QgYmUgcmV0dXJuZWQgYnkgdGhl IHNlcnZlci4NCuKAnA0KU3VwcG9zZSBJIHdhbnQgdG8gcmV0cmlldmUvZGVsZXRlL21vZGlmeSBt dWx0aXBsZSBsZWFmLWxpc3QgaW5zdGFuY2UgZGF0YSByZXNvdXJjZSwgY2FuIEkgd3JhcCBsZWFm LWxpc3QgIlkiIHdpdGhpbiBjb250YWluZXIgInRvcCIsDQpjcmVhdGUvZGVsZXRlL21vZGlmeSBj b250YWluZXIgInRvcCIgZGF0YSByZXNvdXJjZT8NCuKAnA0KQ29tbWVudHM/DQoNCi1RaW4NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldGNvbmYg bWFpbGluZyBsaXN0DQpuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo= --_000_B8F9A780D330094D99AF023C5877DABAA9323418dggeml511mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTsN CglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMgMiAyIDQgMiAyIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAg MyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseTrlrovkvZM7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTo rr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIOmihOiuvuagvOW8jyI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04i IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+QW5keTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkl0IGlzIG5vdCBj bGVhciB0byBtZSBob3cgWUFORyBQYXRjaCBvcGVyYXRpb24gb24gbGVhZi1saXN0IGlzIGRpZmZl cmVudCBmcm9tIHdoYXQgUkZDODA0MCBpcyBkb2luZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlNpbWlsYXIgdG8gUkZDODA0MCwgWUFORyBleGFtcGxlIGRlc2NyaWJlZCBpbiBSRkM4 MDcyIGFwcGVuZGl4IGlzIHVzaW5nICZxdW90O2V4YW1wbGUtanVrZWJveCZxdW90OyBZQU5HIG1v ZHVsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2l0aCAmcXVvdDthcnRpc3QmcXVv dDsgbGlzdCwgJnF1b3Q7YWxidW0mcXVvdDsgbGlzdCwgJnF1b3Q7c29uZyZxdW90OyBsaXN0LCAm cXVvdDtwbGF5bGlzdCZxdW90OyBsaXN0IGluc3RlYWQgb2YgYW55IGxlYWYtbGlzdCBub2RlPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkNhbiB5b3UgcHJvdmlkZSBhbiBZQU5HIHBhdGNoIGV4YW1wbGUgd2hpY2ggYWxs b3dzIENSVUQgb3BlcmF0aW9ucyBvbiBtdWx0aXBsZSBsZWFmLWxpc3QgaW5zdGFuY2VzPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5CeSByZWFkaW5nIFNlY3Rpb24gNC4zIG9mIFJGQzgwNDA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPuKAnDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDoxOC4wcHQ7cGFnZS1icmVhay1iZWZvcmU6YWx3YXlz Ij48c3BhbiBsYW5nPSJFTiI+TW9yZSB0aGFuIG9uZSBlbGVtZW50IE1VU1QgTk9UIGJlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWst YmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iPiZuYnNwOyZuYnNwOyByZXR1cm5lZCBmb3Ig WE1MIGVuY29kaW5nLiZuYnNwOyBJZiBtdWx0aXBsZSBlbGVtZW50cyBhcmUgc2VudCBpbiBhIEpT T048bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTiI+Jm5ic3A7Jm5ic3A7IG1lc3NhZ2UtYm9keSwgdGhlbiB0aGV5IE1VU1QgYmUgc2VudCBh cyBhIEpTT04gYXJyYXkuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj7igJ08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkl0IGxvb2tzIHRvIG1lIFhNTCBlbmNvZGluZyByZXN0cmljdHMg b25seSBvbmUgZWxlbWVudCBvciBsZWFmLWxpc3QgaW5zdGFuY2UgY2FuIGJlIHJldHVybmVkIGJ1 dCBKU09OIGVuY29kaW5nIGhhcyBubyBzdWNoIGxpbWl0YXRpb24uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5JIGFtIHdvbmRlcmluZyB3aGV0aGVyIFlBTkcgcGF0Y2ggaW4gUkZDODA3 MiBoYXMgc2ltaWxhciBpc3N1ZSB3aGVuIHdlIHNlbGVjdCBiZXR3ZWVuIFhNTCBlbmNvZGluZyBh bmQgSlNPTiBlbmNvZGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LVFpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7lj5Hku7bkuro8 c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVv dDssc2Fucy1zZXJpZiI+IEFuZHkgQmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0N Cjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5Y+R6YCB5pe26Ze0PHNwYW4g bGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNh bnMtc2VyaWYiPiAyMDE5PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7lubQ8c3BhbiBsYW5n PSJFTi1VUyI+OTwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+MjU8L3NwYW4+5pelPHNwYW4g bGFuZz0iRU4tVVMiPg0KIDIzOjAxPGJyPg0KPC9zcGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9 IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFFpbiBXdSAmbHQ7YmlsbC53 dUBodWF3ZWkuY29tJmd0Ozxicj4NCjwvc3Bhbj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+ Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBuZXRjb25mICZsdDtuZXRjb25mQGlldGYu b3JnJmd0Ozxicj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBSZTogW25ldGNvbmZdIEZXOiBbbmV0bW9kXSBDUlVEIG9w ZXJhdGlvbnMgb24gTGVhZi1saXN0IGluIFJGQzgwNDA8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhl IFJFU1RDT05GIHRhcmdldCByZXNvdXJjZSBoYXMgdG8gYmUgb25lIHJlc291cmNlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5UaGUgV0cgYWRkZWQgWUFORyBQYXRjaCAoUkZDIDgwNzIpIHRvIGRvIG1v cmUgY29tcGxleCBlZGl0aW5nIG9wZXJhdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BbmR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gV2VkLCBT ZXAgMjUsIDIwMTkgYXQgNzo1NyBBTSBRaW4gV3UgJmx0OzxhIGhyZWY9Im1haWx0bzpiaWxsLnd1 QGh1YXdlaS5jb20iPmJpbGwud3VAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PGJy Pg0KU2VuZCB0byBuZXRjb25mIGZvciBkaXNjdXNzaW9uIGluIHRoZSByaWdodCBwbGFjZSx0aGFu ayBKdXJnZW4gZm9yIGtpbmRseSByZW1pbmRlci48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjYuMHB0IDBjbSAwY20gMGNtIiBuYW1lPSJBbnlPZmZpY2Ut QmFja2dyb3VuZC1JbWFnZSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+5Y+R5Lu2 5Lq677yaIDwvYj48c3BhbiBsYW5nPSJFTi1VUyI+UWluIFd1Jmx0OzxhIGhyZWY9Im1haWx0bzpi aWxsLnd1QGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5iaWxsLnd1QGh1YXdlaS5jb208L2E+ Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPuaUtuS7tuS6uu+8miA8L2I+PHNwYW4gbGFuZz0iRU4tVVMiPm5ldG1vZCZsdDs8 YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9kQGll dGYub3JnPC9hPiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj7mioTpgIHvvJogPC9iPjxzcGFuIGxhbmc9IkVOLVVTIj5aZW5n anVhbiZsdDs8YSBocmVmPSJtYWlsdG86YW5uZXR0ZS56ZW5nQGh1YXdlaS5jb20iIHRhcmdldD0i X2JsYW5rIj5hbm5ldHRlLnplbmdAaHVhd2VpLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+5Li76aKY77yaIDwv Yj48c3BhbiBsYW5nPSJFTi1VUyI+W25ldG1vZF0gQ1JVRCBvcGVyYXRpb25zIG9uIExlYWYtbGlz dCBpbiBSRkM4MDQwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+5pe26Ze077yaIDwvYj48c3BhbiBsYW5nPSJFTi1VUyI+MjAxOS0w OS0yNSAxOTo1NToxMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YnJlYWstYmVmb3Jl OnBhZ2UiPg0KPHNwYW4gbGFuZz0iRU4iPkhpLCBBbGw6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YnJlYWstYmVm b3JlOnBhZ2UiPg0KPHNwYW4gbGFuZz0iRU4iPkR1cmluZyBpbXBsZW1lbnRpbmcgUkZDODA0MCwg d2UgZmFjZSBhIGZldyBwcm9ibGVtcyByZWxhdGVkIHRvIGxlYWYtbGlzdCB1c2FnZS48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzticmVhay1iZWZvcmU6cGFnZSI+DQo8c3BhbiBsYW5nPSJFTiI+SSBhbSB3b25kZXJp bmcgaG93IGRvIHdlIGNyZWF0ZSBtdWx0aXBsZSBpbnN0YW5jZSBvZiBsZWFmLWxpc3QgZGF0YSBy ZXNvdXJjZT88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzticmVhay1iZWZvcmU6cGFnZSI+DQo8c3BhbiBsYW5nPSJF TiI+U3VwcG9zZSB3ZSBoYXZlIGV4YW1wbGUtZm9vLnlhbmcgbW9kZWwgYXMgZm9sbG93czo8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzticmVhay1iZWZvcmU6cGFnZSI+DQo8c3BhbiBsYW5nPSJFTiI+ZXhhbXBsZS10 b3AueWFuZzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO2JyZWFrLWJlZm9yZTpwYWdlIj4NCjxzcGFuIGxhbmc9IkVO Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzticmVhay1iZWZvcmU6cGFnZSI+DQo8c3BhbiBsYW5nPSJF TiI+Jm5ic3A7Jm5ic3A7IGNvbnRhaW5lciB0b3Agezwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JyZWFrLWJlZm9y ZTpwYWdlIj4NCjxzcGFuIGxhbmc9IkVOIj4mbmJzcDsmbmJzcDsmbmJzcDsgbGlzdCBsaXN0MSB7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87YnJlYWstYmVmb3JlOnBhZ2UiPg0KPHNwYW4gbGFuZz0iRU4iPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBrZXkgJnF1b3Q7a2V5MSBrZXky IGtleTMmcXVvdDs7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YnJlYWstYmVmb3JlOnBhZ2UiPg0KPHNwYW4gbGFu Zz0iRU4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAu Li48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzticmVhay1iZWZvcmU6cGFnZSI+DQo8c3BhbiBsYW5nPSJFTiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxpc3QgbGlzdDIg ezwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO2JyZWFrLWJlZm9yZTpwYWdlIj4NCjxzcGFuIGxhbmc9IkVOIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsga2V5ICZxdW90O2tleTQga2V5NSZxdW90Ozs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzticmVh ay1iZWZvcmU6cGFnZSI+DQo8c3BhbiBsYW5nPSJFTiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4uLjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO2JyZWFrLWJlZm9yZTpwYWdlIj4NCjxzcGFuIGxhbmc9IkVOIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgbGVhZiBYIHsgdHlwZSBzdHJpbmc7IH08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzticmVhay1iZWZvcmU6 cGFnZSI+DQo8c3BhbiBsYW5nPSJFTiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzticmVhay1iZWZvcmU6cGFnZSI+DQo8c3Bh biBsYW5nPSJFTiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzticmVh ay1iZWZvcmU6cGFnZSI+DQo8c3BhbiBsYW5nPSJFTiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGxlYWYtbGlzdCBZIHs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzticmVhay1iZWZvcmU6cGFnZSI+DQo8c3BhbiBs YW5nPSJFTiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgdWludDMy Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO2JyZWFrLWJlZm9yZTpwYWdlIj4NCjxzcGFuIGxhbmc9IkVOIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JyZWFrLWJlZm9yZTpwYWdlIj4N CjxzcGFuIGxhbmc9IkVOIj59PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YnJlYWstYmVmb3JlOnBhZ2UiPg0KPHNw YW4gbGFuZz0iRU4iPlRvIGNyZWF0ZSBhIG5ldyAmcXVvdDtZJnF1b3Q7IHJlc291cmNlIHdpdGhp biB0aGUgJnF1b3Q7dG9wJnF1b3Q7IHJlc291cmNlLCBjYW4gd2UgbWFrZTwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O2JyZWFrLWJlZm9yZTpwYWdlIj4NCjxzcGFuIGxhbmc9IkVOIj50aGUgY2xpZW50IHNlbmQgdGhl IGZvbGxvd2luZyByZXF1ZXN0Ojwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JyZWFrLWJlZm9yZTpwYWdlIj4NCjxz cGFuIGxhbmc9IkVOIj5QT1NUIC9yZXN0Y29uZi9kYXRhL2V4YW1wbGUtdG9wOnRvcCBIVFRQLzEu MTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO2JyZWFrLWJlZm9yZTpwYWdlIj4NCjxzcGFuIGxhbmc9IkVOIj5Ib3N0 OiA8YSBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5leGFtcGxlLmNv bTwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzticmVhay1iZWZvcmU6cGFnZSI+DQo8c3BhbiBsYW5nPSJFTiI+ Q29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi95YW5nLWRhdGEmIzQzO2pzb248L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzticmVhay1iZWZvcmU6cGFnZSI+DQo8c3BhbiBsYW5nPSJFTiI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87YnJlYWstYmVmb3JlOnBhZ2UiPg0KPHNwYW4gbGFuZz0iRU4iPns8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzti cmVhay1iZWZvcmU6cGFnZSI+DQo8c3BhbiBsYW5nPSJFTiI+Jm5ic3A7ICZxdW90O2V4YW1wbGUt dG9wOlkmcXVvdDsgOiBbdmFsdWUxLHZhbHVlMl08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzticmVhay1iZWZvcmU6 cGFnZSI+DQo8c3BhbiBsYW5nPSJFTiI+fTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JyZWFrLWJlZm9yZTpwYWdl Ij4NCjxzcGFuIGxhbmc9IkVOIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzticmVhay1iZWZvcmU6cGFn ZSI+DQo8c3BhbiBsYW5nPSJFTiI+cmVzcG9uc2U8L3NwYW4+77yaPHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzticmVhay1iZWZv cmU6cGFnZSI+DQo8c3BhbiBsYW5nPSJFTiI+SFRUUC8xLjEgMjAxIENyZWF0ZWQ8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzticmVhay1iZWZvcmU6cGFnZSI+DQo8c3BhbiBsYW5nPSJFTiI+RGF0ZTogVGh1LCAyNiBK YW4gMjAxNyAyMDo1NjozMCBHTVQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzticmVhay1iZWZvcmU6cGFnZSI+DQo8 c3BhbiBsYW5nPSJFTiI+U2VydmVyOiBleGFtcGxlLXNlcnZlcjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JyZWFr LWJlZm9yZTpwYWdlIj4NCjxzcGFuIGxhbmc9IkVOIj5Mb2NhdGlvbjogPGEgaHJlZj0iaHR0cHM6 Ly9leGFtcGxlLmNvbS9yZXN0Y29uZi9kYXRhL2V4YW1wbGUtdG9wOnRvcC9ZPXZhbHVlMSZhbXA7 dmFsdWUyIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2V4YW1wbGUuY29tL3Jlc3Rjb25mL2Rh dGEvZXhhbXBsZS10b3A6dG9wL1k9dmFsdWUxJmFtcDt2YWx1ZTI8L2E+PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 YnJlYWstYmVmb3JlOnBhZ2UiPg0KPHNwYW4gbGFuZz0iRU4iPkxhc3QtTW9kaWZpZWQ6IFRodSwg MjYgSmFuIDIwMTcgMjA6NTY6MzAgR01UPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YnJlYWstYmVmb3JlOnBhZ2Ui Pg0KPHNwYW4gbGFuZz0iRU4iPkVUYWc6ICZxdW90O2IzODMwZjIzYTRjJnF1b3Q7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzticmVhay1iZWZvcmU6 cGFnZSI+DQo8c3BhbiBsYW5nPSJFTiI+QWxzbyBJIGRvbjwvc3Bhbj7igJk8c3BhbiBsYW5nPSJF TiI+dCB1bmRlcnN0YW5kIHdoeSB3ZSBhZGQgbGltaXRhdGlvbiB0byBQVVQgbWV0aG9kIGFuZCBw bGFpbiBwYXRjaCBtZXRob2Qgb24gbGVhZi1saXN0IGFuZCBkb248L3NwYW4+4oCZPHNwYW4gbGFu Zz0iRU4iPnQgYWxsb3c8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzticmVhay1iZWZvcmU6cGFnZSI+DQo8c3BhbiBs YW5nPSJFTiI+VGhlIHZhbHVlIG9mIGxlYWYtbGlzdCBpbnN0YW5jZSB0byBiZSBjaGFuZ2VkIGJ5 IHRoZXNlIHR3byBtZXRob2RzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YnJlYWstYmVmb3JlOnBhZ2UiPg0KPHNw YW4gbGFuZz0iRU4iPnNlZSBzZWN0aW9uIDQuNSBhbmQgc2VjdGlvbiA0LjYuMTwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO2JyZWFrLWJlZm9yZTpwYWdlIj4NCuKAnDxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YnJlYWstYmVmb3JlOnBhZ2UiPg0K PHNwYW4gbGFuZz0iRU4iPjQuNS4mbmJzcDsgUFVUPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YnJlYWstYmVmb3Jl OnBhZ2UiPg0KPHNwYW4gbGFuZz0iRU4iPiZuYnNwOyZuYnNwOyBJZiB0aGUgdGFyZ2V0IHJlc291 cmNlIHJlcHJlc2VudHMgYSBZQU5HIGxlYWYtbGlzdCwgdGhlbiB0aGUgUFVUPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87YnJlYWstYmVmb3JlOnBhZ2UiPg0KPHNwYW4gbGFuZz0iRU4iPiZuYnNwOyZuYnNwOyBtZXRo b2QgTVVTVCBOT1QgY2hhbmdlIHRoZSB2YWx1ZSBvZiB0aGUgbGVhZi1saXN0IGluc3RhbmNlLjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO2JyZWFrLWJlZm9yZTpwYWdlIj4NCjxzcGFuIGxhbmc9IkVOIj40LjYuMS4u Jm5ic3A7IFBsYWluIFBhdGNoPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YnJlYWstYmVmb3JlOnBhZ2UiPg0KPHNw YW4gbGFuZz0iRU4iPiZuYnNwOyZuYnNwOyBJZiB0aGUgdGFyZ2V0IHJlc291cmNlIHJlcHJlc2Vu dHMgYSBZQU5HIGxlYWYtbGlzdCwgdGhlbiB0aGUgUEFUQ0g8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzticmVhay1i ZWZvcmU6cGFnZSI+DQo8c3BhbiBsYW5nPSJFTiI+Jm5ic3A7Jm5ic3A7IG1ldGhvZCBNVVNUIE5P VCBjaGFuZ2UgdGhlIHZhbHVlIG9mIHRoZSBsZWFmLWxpc3QgaW5zdGFuY2UuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87YnJlYWstYmVmb3JlOnBhZ2UiPg0K4oCcPHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzticmVhay1iZWZvcmU6cGFnZSI+DQo8 c3BhbiBsYW5nPSJFTiI+U3VwcG9zZSBJIHdhbnQgdG8gZGVsZXRlIGFsbCBsZWFmLWxpc3QgaW5z dGFuY2UgdmFsdWVzIGFzc29jaWF0ZWQgd2l0aCBsZWFmLWxpc3QgJnF1b3Q7WSZxdW90Oyw8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzticmVhay1iZWZvcmU6cGFnZSI+DQo8c3BhbiBsYW5nPSJFTiI+Q2FuIEkgc2Vu ZCB0aGUgZm9sbG93aW5nIHJlcXVlc3Q6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YnJlYWstYmVmb3JlOnBhZ2Ui Pg0KPHNwYW4gbGFuZz0iRU4iPkRFTEVURSAvcmVzdGNvbmYvZGF0YS9leGFtcGxlLXRvcDp0b3Av WSZuYnNwOyBIVFRQLzEuMTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JyZWFrLWJlZm9yZTpwYWdlIj4NCjxzcGFu IGxhbmc9IkVOIj5Ib3N0OiA8YSBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20iIHRhcmdldD0iX2Js YW5rIj5leGFtcGxlLmNvbTwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzticmVhay1iZWZvcmU6cGFnZSI+DQo8 c3BhbiBsYW5nPSJFTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YnJlYWstYmVmb3JlOnBhZ2UiPg0K PHNwYW4gbGFuZz0iRU4iPlF1b3RlZCBzZWN0aW9uIDQuNzo8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzticmVhay1i ZWZvcmU6cGFnZSI+DQrigJw8c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JyZWFrLWJlZm9yZTpwYWdlIj4NCjxzcGFuIGxhbmc9 IkVOIj40LjcuJm5ic3A7IERFTEVURSZuYnNwOyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzticmVhay1iZWZvcmU6 cGFnZSI+DQo8c3BhbiBsYW5nPSJFTiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7SWYgdGhlIHRhcmdldCBy ZXNvdXJjZSByZXByZXNlbnRzIGEgY29uZmlndXJhdGlvbiBsZWFmLWxpc3Qgb3IgbGlzdDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO2JyZWFrLWJlZm9yZTpwYWdlIj4NCjxzcGFuIGxhbmc9IkVOIj4mbmJzcDsmbmJz cDsgZGF0YSBub2RlLCB0aGVuIGl0IE1VU1QgcmVwcmVzZW50IGEgc2luZ2xlIFlBTkcgbGVhZi1s aXN0IG9yIGxpc3Q8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzticmVhay1iZWZvcmU6cGFnZSI+DQo8c3BhbiBsYW5n PSJFTiI+Jm5ic3A7Jm5ic3A7IGluc3RhbmNlLiZuYnNwOyBUaGUgc2VydmVyIE1VU1QgTk9UIHVz ZSB0aGUgREVMRVRFIG1ldGhvZCB0byBkZWxldGUgbW9yZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JyZWFrLWJl Zm9yZTpwYWdlIj4NCjxzcGFuIGxhbmc9IkVOIj4mbmJzcDsmbmJzcDsgdGhhbiBvbmUgc3VjaCBp bnN0YW5jZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzticmVhay1iZWZvcmU6cGFnZSI+DQrigJ08c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2Jy ZWFrLWJlZm9yZTpwYWdlIj4NCjxzcGFuIGxhbmc9IkVOIj5JdCBzZWVtcyBvYnZpb3VzIHRoYXQg REVMRVRFIG1ldGhvZCBjYW4gbm90IGRlbGV0ZSBtb3JlIHRoYW4gb25lIGluc3RhbmNlcy4gQnV0 IEkgZG9uPC9zcGFuPuKAmTxzcGFuIGxhbmc9IkVOIj50IGtub3cgd2h5Pzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O2JyZWFrLWJlZm9yZTpwYWdlIj4NCjxzcGFuIGxhbmc9IkVOIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmUgc3R5bGU9ImJyZWFrLWJl Zm9yZTpwYWdlIj48c3BhbiBsYW5nPSJFTiI+QWxzbyBJIGRvbjwvc3Bhbj7igJk8c3BhbiBsYW5n PSJFTiI+dCBrbm93IHdlIGFkZCBjb25zdHJhaW50IG9uIFhNTCBlbmNvZGluZyBpbiB0aGUgR2V0 IHJlcXVlc3QsIG9ubHkgYWxsb3cgb25lIHNpbmdsZSBlbGVtZW50IGJlPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzticmVhay1iZWZvcmU6cGFnZSI+DQo8c3BhbiBsYW5nPSJFTiI+cmV0dXJuZWQgZm9yIFhNTCBl bmNvZGluZywgc2VlIHNlY3Rpb24gNC4zIG9mIFJGQzgwNDAgYXMgZm9sbG93czo8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzticmVhay1iZWZvcmU6cGFnZSI+DQrigJw8c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JyZWFrLWJlZm9yZTpwYWdlIj4N CjxzcGFuIGxhbmc9IkVOIj40LjMuJm5ic3A7IEdFVDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JyZWFrLWJlZm9y ZTpwYWdlIj4NCjxzcGFuIGxhbmc9IkVOIj4mbmJzcDsmbmJzcDsgSWYgYSByZXRyaWV2YWwgcmVx dWVzdCBmb3IgYSBkYXRhIHJlc291cmNlIHJlcHJlc2VudGluZyBhIFlBTkc8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzticmVhay1iZWZvcmU6cGFnZSI+DQo8c3BhbiBsYW5nPSJFTiI+Jm5ic3A7Jm5ic3A7IGxlYWYt bGlzdCBvciBsaXN0IG9iamVjdCBpZGVudGlmaWVzIG1vcmUgdGhhbiBvbmUgaW5zdGFuY2UgYW5k IFhNTDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO2JyZWFrLWJlZm9yZTpwYWdlIj4NCjxzcGFuIGxhbmc9IkVOIj4m bmJzcDsmbmJzcDsgZW5jb2RpbmcgaXMgdXNlZCBpbiB0aGUgcmVzcG9uc2UsIHRoZW4gYW4gZXJy b3IgcmVzcG9uc2UgY29udGFpbmluZyBhPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YnJlYWstYmVmb3JlOnBhZ2Ui Pg0KPHNwYW4gbGFuZz0iRU4iPiZuYnNwOyZuYnNwOyAmcXVvdDs0MDAgQmFkIFJlcXVlc3QmcXVv dDsgc3RhdHVzLWxpbmUgTVVTVCBiZSByZXR1cm5lZCBieSB0aGUgc2VydmVyLjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO2JyZWFrLWJlZm9yZTpwYWdlIj4NCuKAnDxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YnJlYWstYmVmb3JlOnBhZ2UiPg0K PHNwYW4gbGFuZz0iRU4iPlN1cHBvc2UgSSB3YW50IHRvIHJldHJpZXZlL2RlbGV0ZS9tb2RpZnkg bXVsdGlwbGUgbGVhZi1saXN0IGluc3RhbmNlIGRhdGEgcmVzb3VyY2UsIGNhbiBJIHdyYXAgbGVh Zi1saXN0ICZxdW90O1kmcXVvdDsgd2l0aGluIGNvbnRhaW5lciAmcXVvdDt0b3AmcXVvdDssPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87YnJlYWstYmVmb3JlOnBhZ2UiPg0KPHNwYW4gbGFuZz0iRU4iPmNyZWF0ZS9k ZWxldGUvbW9kaWZ5IGNvbnRhaW5lciAmcXVvdDt0b3AmcXVvdDsgZGF0YSByZXNvdXJjZT88L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzticmVhay1iZWZvcmU6cGFnZSI+DQrigJw8c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JyZWFrLWJlZm9yZTpw YWdlIj4NCjxzcGFuIGxhbmc9IkVOIj5Db21tZW50cz88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzticmVhay1iZWZv cmU6cGFnZSI+DQo8c3BhbiBsYW5nPSJFTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87YnJlYWstYmVm b3JlOnBhZ2UiPg0KPHNwYW4gbGFuZz0iRU4iPi1RaW48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzticmVhay1iZWZv cmU6cGFnZSI+DQo8c3BhbiBsYW5nPSJFTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpuZXRjb25mIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0Y29uZkBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldGNvbmYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B8F9A780D330094D99AF023C5877DABAA9323418dggeml511mbschi_-- From nobody Wed Sep 25 20:58:53 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCDA120271 for ; Wed, 25 Sep 2019 20:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_MIME_MALF=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 GPWBJQWNIRH7 for ; Wed, 25 Sep 2019 20:58:48 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9733A120170 for ; Wed, 25 Sep 2019 20:58:47 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id t8so554043lfc.13 for ; Wed, 25 Sep 2019 20:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2UZ9Enhg+VDgO9vvuKrd5cqQEt+UkV8j3+CHT/AoZog=; b=DxInh9BbSyBMY0sNvIqDS6Dn5fqBy+N6MQMa5+eVwgXPwU3pR6GI9fOo66ipuxs/SZ QbOqLKo7wxiW4TPWT0JCcMdLH1TtI3y6raO3ALGXWCP5aKN7l6FGCoCBJd7bT3xiSPE/ S+U176lGBlc4B5jANbT3kNWkJhU8xlDx9cBm4Xc2M6rwFh0pqJZ8SkC8cIVAOihyAUhd +thPB/s+PcsizmKaaYM0AlH8G/+GQjYlKfxI9jmh5WPOUvddLhYdIG2h97PR6AOO2ihJ BOGqWwSzOgfheWF5J4WhE+DauGve1A8R6HIhPRcm63UsjlA76UP+8XToqV4IqwwQ77zM K5fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2UZ9Enhg+VDgO9vvuKrd5cqQEt+UkV8j3+CHT/AoZog=; b=XO4zeUAuePWSkzzUtzcMc/MRJ44WaqVazfMxn4fNqJhpb27yrGL0FnfNQRiBq2nK9a 9NLecfF2HsJw0wjYCesvbMCYGzo/ZkyejVIaXONxYdRivufLMTnFLEfYnZ64z1mf2Oi0 +Ok5nydN0xEPEjfcZkQbW5wQk3CqEipCSMtOxf8q3HKhCvugrhDTupFg8SbjunZRUy8u PVu6Pw9sXcP8cB0ZiD5xxM/t6n1s0B4N+PggAieHoiKtVI7SeNR4Vt9k1HD0utzXmQI6 sqxOjxO1lTu2mQEnuVZH5nc1hCndNs0kmJ9kTdyUKA+it2tBioaBCw9SNBvtRHQR1I9K pLBA== X-Gm-Message-State: APjAAAVIDTKlk1ahFYGcxD5nWROZpUw8fWQZE0ZZYzQnOO88aAFVw7X6 KFVkmmrSz/boSdw3BjpCu8OFfpveoBsrZxTVLUSihnn1 X-Google-Smtp-Source: APXvYqyn1hvQPUq0fNLSW/PhC9RpsW+1LL9Qmp9+MPXMR6kWK/fsOMF5vmmldAazd0THPaCDWqkhOdZgxbIc/BG81ok= X-Received: by 2002:ac2:554e:: with SMTP id l14mr840532lfk.32.1569470325701; Wed, 25 Sep 2019 20:58:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Wed, 25 Sep 2019 20:58:34 -0700 Message-ID: To: Qin Wu Cc: netconf Content-Type: multipart/alternative; boundary="0000000000004009b705936cc976" Archived-At: Subject: Re: [netconf] FW: [netmod] CRUD operations on Leaf-list in RFC8040 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2019 03:58:51 -0000 --0000000000004009b705936cc976 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 25, 2019 at 6:27 PM Qin Wu wrote: > Andy: > > It is not clear to me how YANG Patch operation on leaf-list is different > from what RFC8040 is doing. > > Similar to RFC8040, YANG example described in RFC8072 appendix is using > "example-jukebox" YANG module > > With "artist" list, "album" list, "song" list, "playlist" list instead of > any leaf-list node > > > > Can you provide an YANG patch example which allows CRUD operations on > multiple leaf-list instances? > > > no (I don't have time) but you would have an "edit" list entry for each leaf-list instance Andy > By reading Section 4.3 of RFC8040 > > =E2=80=9C > > More than one element MUST NOT be > > returned for XML encoding. If multiple elements are sent in a JSON > > message-body, then they MUST be sent as a JSON array. > > =E2=80=9D > > It looks to me XML encoding restricts only one element or leaf-list > instance can be returned but JSON encoding has no such limitation. > > I am wondering whether YANG patch in RFC8072 has similar issue when we > select between XML encoding and JSON encoding. > > > > -Qin > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Andy Bierman [mailto:andy@yumaworks.com] > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2019=E5=B9=B49=E6=9C=8825=E6=97= =A5 23:01 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* Qin Wu > *=E6=8A=84=E9=80=81:* netconf > *=E4=B8=BB=E9=A2=98:* Re: [netconf] FW: [netmod] CRUD operations on Leaf-= list in RFC8040 > > > > Hi, > > > > The RESTCONF target resource has to be one resource. > > The WG added YANG Patch (RFC 8072) to do more complex editing operations. > > > > Andy > > > > > > On Wed, Sep 25, 2019 at 7:57 AM Qin Wu wrote: > > > Send to netconf for discussion in the right place,thank Jurgen for kindly > reminder. > > *=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A *Qin Wu > > *=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A *netmod > > *=E6=8A=84=E9=80=81=EF=BC=9A *Zengjuan > > *=E4=B8=BB=E9=A2=98=EF=BC=9A *[netmod] CRUD operations on Leaf-list in RF= C8040 > > *=E6=97=B6=E9=97=B4=EF=BC=9A *2019-09-25 19:55:12 > > > > Hi, All: > > During implementing RFC8040, we face a few problems related to leaf-list > usage. > > I am wondering how do we create multiple instance of leaf-list data > resource? > > Suppose we have example-foo.yang model as follows: > > example-top.yang > > > > container top { > > list list1 { > > key "key1 key2 key3"; > > ... > > list list2 { > > key "key4 key5"; > > ... > > leaf X { type string; } > > } > > } > > leaf-list Y { > > type uint32; > > } > > } > > To create a new "Y" resource within the "top" resource, can we make > > the client send the following request: > > POST /restconf/data/example-top:top HTTP/1.1 > > Host: example.com > > Content-Type: application/yang-data+json > > > > { > > "example-top:Y" : [value1,value2] > > } > > > > response=EF=BC=9A > > HTTP/1.1 201 Created > > Date: Thu, 26 Jan 2017 20:56:30 GMT > > Server: example-server > > Location: > https://example.com/restconf/data/example-top:top/Y=3Dvalue1&value2 > > Last-Modified: Thu, 26 Jan 2017 20:56:30 GMT > > ETag: "b3830f23a4c" > > > > Also I don=E2=80=99t understand why we add limitation to PUT method and p= lain > patch method on leaf-list and don=E2=80=99t allow > > The value of leaf-list instance to be changed by these two methods > > see section 4.5 and section 4.6.1 > > =E2=80=9C > > 4.5. PUT > > If the target resource represents a YANG leaf-list, then the PUT > > method MUST NOT change the value of the leaf-list instance. > > 4.6.1.. Plain Patch > > If the target resource represents a YANG leaf-list, then the PATCH > > method MUST NOT change the value of the leaf-list instance. > > =E2=80=9C > > Suppose I want to delete all leaf-list instance values associated with > leaf-list "Y", > > Can I send the following request: > > DELETE /restconf/data/example-top:top/Y HTTP/1.1 > > Host: example.com > > > > Quoted section 4.7: > > =E2=80=9C > > 4.7. DELETE > > If the target resource represents a configuration leaf-list or list > > data node, then it MUST represent a single YANG leaf-list or list > > instance. The server MUST NOT use the DELETE method to delete more > > than one such instance. > > =E2=80=9D > > It seems obvious that DELETE method can not delete more than one > instances. But I don=E2=80=99t know why? > > > > Also I don=E2=80=99t know we add constraint on XML encoding in the Get re= quest, only allow one single element be > > returned for XML encoding, see section 4.3 of RFC8040 as follows: > > =E2=80=9C > > 4.3. GET > > If a retrieval request for a data resource representing a YANG > > leaf-list or list object identifies more than one instance and XML > > encoding is used in the response, then an error response containing a > > "400 Bad Request" status-line MUST be returned by the server. > > =E2=80=9C > > Suppose I want to retrieve/delete/modify multiple leaf-list instance data > resource, can I wrap leaf-list "Y" within container "top", > > create/delete/modify container "top" data resource? > > =E2=80=9C > > Comments? > > > > -Qin > > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --0000000000004009b705936cc976 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Sep 25, 2019 at 6:27 PM Qin W= u <bill.wu@huawei.com> wrot= e:

Andy:<= /p>

It is not clear to me how Y= ANG Patch operation on leaf-list is different from what RFC8040 is doing.

Similar to RFC8040, YANG ex= ample described in RFC8072 appendix is using "example-jukebox" YA= NG module

With "artist" lis= t, "album" list, "song" list, "playlist" list= instead of any leaf-list node

=C2=A0=

Can you provide an YANG pat= ch example which allows CRUD operations on multiple leaf-list instances?=

=C2=A0


no (I don't have time) but yo= u would have an "edit" list entry for each leaf-list instance

Andy
=C2=A0

<= u>

By reading Section 4.3 of R= FC8040

=E2=80=9C

More than one element MUST NOT be

=C2=A0= =C2=A0 returned for XML encoding.=C2=A0 If multiple elements are sent in a = JSON

=C2=A0=C2=A0 message-body, then th= ey MUST be sent as a JSON array.<= /u>

=E2=80=9D

It looks to me XML encoding= restricts only one element or leaf-list instance can be returned but JSON = encoding has no such limitation.

I am wondering whether YANG= patch in RFC8072 has similar issue when we select between XML encoding and= JSON encoding.

=C2=A0=

-Qin

=E5=8F=91=E4=BB=B6=E4=BA=BA: Andy Bie= rman [mailto:andy@y= umaworks.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B49=E6=9C=8825=E6=97=A5 23:01
=E6=94=B6=E4=BB=B6=E4=BA=BA: Qin Wu <bill.wu@huawei.com>
=E6=8A=84=E9=80=81: netconf <n= etconf@ietf.org>
=E4=B8=BB=E9=A2=98: Re: [netconf] FW: [netmod] CRUD operations on Leaf-list in RFC8040<= u>

=C2=A0

Hi,

=C2=A0

The RESTCONF target resource ha= s to be one resource.

The WG added YANG Patch (RFC 80= 72) to do more complex editing operations.

=C2=A0

Andy

=C2=A0

=C2=A0

On Wed, Sep 25, 2019 at 7:57 AM= Qin Wu <bill.wu= @huawei.com> wrote:


Send to netconf for discussion in the right place,thank Jurgen for kindly r= eminder.

=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Qin Wu<bill.wu@huawei.com>

=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A netmod<netmod@ietf.org>

=E6=8A=84=E9=80=81=EF=BC=9A Zengjuan<annette.zeng@huawei.com>

=E4=B8=BB=E9=A2=98=EF=BC=9A [netmod] CRUD operations on Leaf-list in RFC8040

=E6=97=B6=E9=97=B4=EF=BC=9A 2019-09-25 19:55:12

=C2=A0

Hi, All:=

During implementing RFC8040, we face a few problems relat= ed to leaf-list usage.

I am wondering how do we create multiple instance of leaf= -list data resource?

Suppose we have example-foo.yang model as follows:=

example-top.yang

=C2=A0

=C2=A0=C2=A0 container top {<= u>

=C2=A0=C2=A0=C2=A0 list list1 {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 key "key1= key2 key3";

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ...

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 list lis= t2 {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 key "key4 key5";

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 ...

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 leaf X { type string; }<= u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }=

=C2=A0=C2=A0=C2=A0=C2=A0 }=

=C2=A0=C2=A0=C2=A0=C2=A0 leaf-list Y {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type uint32;<= span lang=3D"EN-US">

=C2=A0=C2=A0=C2=A0=C2=A0 }=

}

To create a new "Y" resource within the "t= op" resource, can we make

the client send the following request:

POST /restconf/data/example-top:top HTTP/1.1

Host: ex= ample.com

Content-Type: application/yang-data+json

=C2=A0

{

=C2=A0 "example-top:Y" : [value1,value2]=

}

=C2=A0

response=EF=BC=9A

HTTP/1.1 201 Created

Date: Thu, 26 Jan 2017 20:56:30 GMT

Server: example-server=

Location: https://example.com/restconf/data/example-top:top/Y=3Dvalue1&value2=

Last-Modified: Thu, 26 Jan 2017 20:56:30 GMT

ETag: "b3830f23a4c"=

=C2=A0=

Also I don=E2=80=99t understand = why we add limitation to PUT method and plain patch method on leaf-list and= don=E2=80=99t allow

The value of leaf-list instance to be changed by these tw= o methods

see section 4.5 and section 4.6.1

=E2=80=9C

4.5.=C2=A0 PUT<= /span>

=C2=A0=C2=A0 If the target resource represents a YANG lea= f-list, then the PUT

=C2=A0=C2=A0 method MUST NOT change the value of the leaf= -list instance.

4.6.1..=C2=A0 Plain Patch<= /u>

=C2=A0=C2=A0 If the target resource represents a YANG lea= f-list, then the PATCH

=C2=A0=C2=A0 method MUST NOT change the value of the leaf= -list instance.

=E2=80=9C

Suppose I want to delete all leaf-list instance values as= sociated with leaf-list "Y",

Can I send the following request:

DELETE /restconf/data/example-top:top/Y=C2=A0 HTTP/1.1

Host: ex= ample.com

=C2=A0

Quoted section 4.7:=

=E2=80=9C

4.7.=C2=A0 DELETE=C2=A0

=C2=A0=C2=A0=C2=A0If the target resource represents a con= figuration leaf-list or list

=C2=A0=C2=A0 data node, then it MUST represent a single Y= ANG leaf-list or list

=C2=A0=C2=A0 instance.=C2=A0 The server MUST NOT use the = DELETE method to delete more

=C2=A0=C2=A0 than one such instance.

=E2=80=9D

It seems obvious that DELETE method can not delete more t= han one instances. But I don=E2=80=99t know why?

=C2=A0 

Also I don=E2=80=
=99t know we add constraint on XML encoding in the Get re=
quest, only allow one single element be<=
u>

returned for XML encoding, see section 4.3 of RFC8040 as = follows:

=E2=80=9C

4.3.=C2=A0 GET<= /span>

=C2=A0=C2=A0 If a retrieval request for a data resource r= epresenting a YANG

=C2=A0=C2=A0 leaf-list or list object identifies more tha= n one instance and XML

=C2=A0=C2=A0 encoding is used in the response, then an er= ror response containing a<= /p>

=C2=A0=C2=A0 "400 Bad Request" status-line MUST= be returned by the server.

=E2=80=9C

Suppose I want to retrieve/delete/modify multiple leaf-li= st instance data resource, can I wrap leaf-list "Y" within contai= ner "top",

create/delete/modify container "top" data resou= rce?

=E2=80=9C

Comments?

=C2=A0

-Qin

=C2=A0

_______________________________= ________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf

--0000000000004009b705936cc976-- From nobody Thu Sep 26 02:04:26 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEE4120844 for ; Thu, 26 Sep 2019 02:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=ericsson.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 ErlmNue9-hJw for ; Thu, 26 Sep 2019 02:04:22 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on060c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::60c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6461120843 for ; Thu, 26 Sep 2019 02:04:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WyRmaC8I8MAq/1282jEavHIkjyFQ0CByr0sD7w1/GekNPrKQrH1BkS9idXMeJpC1R+McoVqpK7J09DBHVOW3XVHo2lDDkNDAch/f35qn+pxdcxaFD7YrRp3uywGx+/c/LDOaKqmEIs4BJHoTP7lY4YZzBwBGgK17b6SKfxOxzNq2ANG5ZY9sAqBa0VY306dtk6nvN8xLtAfZdWHgyKxkS3hiLVuc48opRIvYRpEwgXspJtq/wumQDec0MjHUp+bQUhuMhbHRx4v1k8AP5AlwYvN5PsFvIds1JYKg4ajSKb8WA5XW/MWyMDGfh0/R+euLKuTBRYapwbx+5WTAX3EkCg== 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=t1pUq8L0C+z71X6WuLF//ZxZvrdt/Fh8w+IS3pwmBjk=; b=QnbrfZjzi3ZiVdKjnTnMWgZLwYFBSsni7Xd04d8TbeVREt/hZkp6Jo+N0HIsbjUeSQ7FGpTl2APYzaDxlc2VRJwWN+Bsp5dVZeESVDmCW3rskvuf3Ib+FcBvlqPKhNYMCkcFhCQ1JWKqbwLq3bcFVy0LO647iWhyP6axeW4saPtR5OaZ9o3SkfZ4pEN4bIc31e2pzjtgcCfXRFHehFkiTvmIiEGtu4GQAVoVjQPMROgT8tXEgQwF3HD5e+nmz2wbAOCNa2hqfuCVegOUFzbhekuN9JTL5s6B0aBC2z1hQ2Nayb+2a2PpDTCFqZOK4p5VHZm4wcljscIcShPSGgfQhQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t1pUq8L0C+z71X6WuLF//ZxZvrdt/Fh8w+IS3pwmBjk=; b=HJ4N9ZK5+RiH1dRW4fwHv2kYXn7U4wuwhYB/PvuDTx96ABcEiO5JmiQLy5rLBuZnvezg7ldksQT3CX522bfb0AVfvSDNilnD1AvHz3p+2kxptlB7L9xzyoiQvxwihNfQRP4SY7wSvfdE3vXk0A13wQqGzv5B/kCh3208uKHlM24= Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com (10.169.137.153) by VI1PR0701MB2591.eurprd07.prod.outlook.com (10.173.85.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.15; Thu, 26 Sep 2019 09:04:19 +0000 Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com ([fe80::f44b:854c:51cf:c69f]) by VI1PR0701MB2286.eurprd07.prod.outlook.com ([fe80::f44b:854c:51cf:c69f%7]) with mapi id 15.20.2305.017; Thu, 26 Sep 2019 09:04:19 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: Martin Bjorklund , "evoit@cisco.com" CC: "kent@watsen.net" , "netconf@ietf.org" Thread-Topic: [netconf] HTTPS notifications (draft-ietf-netconf-https-notif) Thread-Index: AdVyXY/fdU3HloeGTTOWCxwrTn1HQwAEWnoAAA0vtgAADqW6AAAAXNaAAFoxXVA= Date: Thu, 26 Sep 2019 09:04:19 +0000 Message-ID: References: <0100016d60ab5732-3db5a046-a7b1-4386-b507-977cfa0cd25b-000000@email.amazonses.com> <20190924.084558.420273240258823379.mbj@tail-f.com> <20190924.155545.1143100128662277152.mbj@tail-f.com> In-Reply-To: <20190924.155545.1143100128662277152.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aa8695bd-eb2a-42ab-1eba-08d7426083ec x-ms-traffictypediagnostic: VI1PR0701MB2591: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0172F0EF77 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(39860400002)(396003)(346002)(366004)(13464003)(199004)(189003)(14454004)(26005)(256004)(71190400001)(6246003)(7736002)(2501003)(5660300002)(6506007)(3846002)(53546011)(102836004)(186003)(99286004)(71200400001)(478600001)(7696005)(86362001)(45776006)(76176011)(6116002)(2906002)(9686003)(81156014)(55016002)(486006)(99936001)(14444005)(54906003)(15650500001)(11346002)(33656002)(66574012)(66066001)(25786009)(8676002)(110136005)(66446008)(81166006)(316002)(4326008)(229853002)(52536014)(66946007)(476003)(446003)(66616009)(66556008)(64756008)(74316002)(66476007)(76116006)(6436002)(305945005)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2591; H:VI1PR0701MB2286.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zN/ZjCTRZUtgX3CGmeeXryuw5PV2yBxiAeSgYo7SpwLDV1R2vxSqGXke8EZHLhR6xCvsbqMvVhToYKlBYMqHKuLPBDhZSESM1Ij/H6NjRaNvhWrMlkfz7I3AJeETCfzzeFtgMO/BEfHLTygulunRoBavE7rGbhfN8Ki+HUQN0eWwqDUFGcaNKxglDCxeTw1rWescC6Wkpcd0lIE5W3kLMi5A1+R6V6AQHhDUvg+NFJh3+TtoqCXxpvaQY3Su4yurZhLDBZF/eOEaMhqh5UT46vcjsOgmOuKTiEYVoYJUKD8so2/eTATYQ/CFIVBK/PmT9lIbXzqNRS+Nwz5pui2qgbqzYiGDEF+ZkzyJCGYV7/0eyVSKeX017tw7K5zQM9q7KJYdaUPOAWfEYDXNPha4mymgcznjTA2CvqThClo2Q0o= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_03D1_01D5745A.23FC3EB0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: aa8695bd-eb2a-42ab-1eba-08d7426083ec X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2019 09:04:19.3238 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8eWQDw3zgY/Kxh+6FtXkYQG+etFQysvaTLagbycdthd3vptT2X/4AvmvPhKAOZFJi751NqeKNyQtek5Z8MZTdgUeh2qbCZa+n2+YnWtJP/8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2591 Archived-At: Subject: Re: [netconf] HTTPS notifications (draft-ietf-netconf-https-notif) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2019 09:04:25 -0000 ------=_NextPart_000_03D1_01D5745A.23FC3EB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Martin Bjorklund =20 Sent: 2019. szeptember 24., kedd 15:56 To: evoit@cisco.com Cc: kent@watsen.net; Bal=E1zs Lengyel ; netconf@ietf.org Subject: Re: [netconf] HTTPS notifications = (draft-ietf-netconf-https-notif) "Eric Voit (evoit)" wrote: >=20 >=20 > > > From the email I sent Martin on Sep 9th, each POST MAY contain=20 > > > more than one notification: > >=20 > > .... to which I replied: > >=20 > > I'm not so sure about the streaming though. > > Perhaps pipelining is the right mechanism. For "bulk" sending, = the > > "bundled-message" defined in = draft-ietf-netconf-notification-messages > > seems right. > >=20 > > To clarify: if the client just sends a stream of notifs it becomes a > variant of > > SSE. The server doesn't know when the stream will end, and thus=20 > > cannot simply close the session. You probably want to indicate=20 > > end-of-message somehow (like in SSE). And the content type in the=20 > > example below cannot be "application/yang-data+xml", since it is not = > > a valid XML instance document; you'd have to invent a new media type = to indicate the streaming. > >=20 > > I think we should stick to simple HTTP where each notif is POSTed,=20 > > as in > your > > diagaram above. With HTTP pipelining you can do: > >=20 > > ------> establish TCP > > ------> establish TLS > > ------> Send HTTPS POST message with YANG defined notification 1=20 > > ------> Send HTTPS POST message with YANG defined notification 2 > > <-----Send 204 (No Content) for 1 > > <-----Send 204 (No Content) for 2 > >=20 > > ------> Send HTTPS POST message with YANG defined notification 3 > > <-----Send 204 (No Content) for 3 > >=20 > >=20 > > If the server wants to send multiple notifs at once, it can use=20 > > "bundled- message". >=20 > This seems a reasonable approach.=20 > draft-ietf-netconf-notification-messages > has several advantages: > (1) can push multiple YANG notifications at once > (2) can include the subscription-id in notifications when subscribing=20 > to a stream. (Right now including an explicit subscription-id is only = > available when subscribing to a datastore.) > (3) includes methods to discover lost/dropped notifications >=20 > Two things which would need to be worked: > (1) discovering receiver support for bundled notifications. (As some=20 > form of understanding/verifying configured receiver support over HTTP=20 > is already needed, this is a topic which perhaps can be merged into=20 > that.) This can be configured or auto-detected. For auto-detection, perhaps we = can use HTTP OPTIONS with the server returning a special body or header to indicate capabilities such as this one? > (2) Completion of draft-ietf-netmod-yang-data-ext Yes! IMO it is ready for WGLC; I'll ping the chairs again. /martin BALAZS: IMHO autodetection is much better then configuration. However we should try to avoid extra message roundtrips to do autodetection, so = IMHO either - cache receiver capabilities for subscriptions, so autodetection is = needed only once - send bundled notifications immediately and fallback to simple notifications if needed based on any error messages received=20 Regards Balazs ------=_NextPart_000_03D1_01D5745A.23FC3EB0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVbjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF/zCCA+egAwIBAgIR AOm+1xFswMzmixU1jNT/MSEwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMB4XDTE3MTAw OTE1MjQ1OFoXDTIwMTAwOTE1MjQ1N1owajERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD0Jh bMOhenMgTGVuZ3llbDEqMCgGCSqGSIb3DQEJARYbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t MQ8wDQYDVQQFEwZFVEhCTEwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUUtnneUfH i428YPkvW+AsCNeKCCKq72SzUZpBggijy+oLVO0cgTXXHygrZ+KT8TbyEkPwuHi+V4TQxWAyMhGa nWZHWZXe9ghEZrJDJbCzFMHOqR+wEDnI1vM3sfQQ68iSsWQLd9opnb2/ihiJlt9up75VRpyj5lea bvzxOLQimJgZiXaZzsPPT2nROyytKxOsE5KbfT3mNof3bMG1bggZtGGA1GBJchwdFJwQKIShfPVm 1CdulvJV1hPVecxttMJNPzSfSfryb/b64QnR5yc/pSx8SxD0h0rnNT73Al3Af2iRghdXN4omDKZY OcdK/sE5HTmLTFuWoZAnL/RntOK9AgMBAAGjggHBMIIBvTBIBgNVHR8EQTA/MD2gO6A5hjdodHRw Oi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggr BgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYI KwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNlcjAmBgNVHREEHzAdgRtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBSkJw2vbyMFmf9tY1urk9NeYfiMgTAfBgNVHSMEGDAWgBQcexmel5x2rCA92Nzj kWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAD1RCVf5Df2uCXwPveXz LBGIjsz3k2la5UUlioC+i4Ms6vGstqXIX7K24+Wc41npi+G5xFhvkAkmuTP/j29F5xJJuJcy3OcL 0br02vKe2WJJnlivB+X9plPg0kMUBS0lLq7kHPUrO/BLeIIFRuaky05eZlTnGNcLbn5VpZdjX4Ic XZV78qpZI3L67Po1UgHzOTiWolc75jrKOx3UOw98fWRrgJPBUIeqDeD1NDfF7PlM4Cqlad062o6L lM9wfAnoLzz0z04dPXtJkOcTiZgOLdPoKIm7LR1wZ9c6mYw4sgtoVAs16Y2cCPBxqWpsW+9ZCcDK PPZzeBezCKyicpDJbTqCVMILd3j38HWUPWFuVITZNgANzHW1CpgqmiLIAADiznCCtudTE+fcB3O9 duuu/yuEME17LMy1GYMKXs1QCXmTq2hrqTJQ2AA2TsWZtoxl3ViqJgNBWjnQiMwdCl5Dural2jZP /iU6MmiauUNYn9YW/ViUluoBBdaUHMpnP/7kM0Wk8j3Wzhcggx+Biml2gCopMaK1EJYjQH/2J95N GEkSdZfVzFUmwV3yMd4mOhIaxW0SEq9b1eWICZ/BAcVBpSyU0sE1gpnBO5wLxj+IpSdiGlS4jc37 qCr/39xdv1Unu93glCmHq0xgX54N8EsyMBPC3+zSSu1qhCbU7VJWIz2aMIIGwjCCBKqgAwIBAgIQ U7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEf MB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcx MjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy 3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt 8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6j RrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFl hFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/2 0aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCY rEqHMRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuT LUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMd ay0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqd GTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMB AAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVz dC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9j cmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpec dqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5 s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90 BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRy pF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86 IWst821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QD Xnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7 C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbN QUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbH XSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i 6Ds5j0Qpj5aQMYIDBTCCAwECAQEwXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MAkGBSsOAwIaBQCgggF+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTE5MDkyNjA5MDQxN1owIwYJKoZIhvcNAQkEMRYEFCj9gWXHo+bEb5V+SnfmoNfta+SqMEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQCMYnLj6Bw7YilU65itjuS7iWxmvMp2PXFVhPPFFO/2AA6VErAgwvQV J1C072tIDu+mJv0c0mFCtOj3e+dV9TlruxWvGOtmY2/IX4v0jViMvcneo/DS1sWkh8DzY1H9saN1 oHjc9puoIETdLtBCj1fg3hNdbdMEZnvcRQZNsuAcWRukKWep3fNjg+2yIufCxfuR59ilZX9uvR6p LjXFFg3WtBA/j+bZ3UZDV1spA3G99RomBVb9Y5blsF5r7mWd1lzycQa1YjJcqTOOXaWvR0J9LT1B gCFZ3UwP3E81eIF8wDA6TdKpkQushSSn4TufGRlJ2quri05Fy5jd2Gz3b5BRAAAAAAAA ------=_NextPart_000_03D1_01D5745A.23FC3EB0-- From nobody Fri Sep 27 04:00:58 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5410F12083D; Fri, 27 Sep 2019 04:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.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 CO2AtZB2qRTO; Fri, 27 Sep 2019 04:00:37 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20106.outbound.protection.outlook.com [40.107.2.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E68A120848; Fri, 27 Sep 2019 04:00:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eOxaUSoBMQvOQtvc/WV24NPW/v2I/ywTjEYGWj5UpZ1UeJWw6BETOnso22oR/WWQ9IJgVSTsbbKBaOSjYriXIgY8kGTaXxNiHooLidTl5suNMtrSfHbGLDZfYOLOGrxkLHLi0ynxhxiaGFrdOtav7jDh5KPBkxh4Ro/kFXOGcqznu+LAA17oWbm4FdGuu+urOduoX3MTgzSNWL8b5lZ6sRAHH2B6j6tvKZkDFKdQSypo84xdeWRzIUmVMyk0TS99/sDRklL3X8z39yxR6HUlQGGV0gFx1WYKCMgZhmLvAwAQW9VQvPShrOVLdP5EnyyHUndDKVoMZO0rG9wBemvRoA== 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=8RWZEdGRp66ZrTnvGCG/m9ZFoFbzBQIIJoHBvB5gRKM=; b=i0lqAQgYPpVcdWyy/0eWW0f1MhfRcKtbYF/Zt8Z8srX66aaZTk3XVyUAxFr3G9G+3rfmzuKiqDSNVSqF/cgeOnNS44E6PqklGc08joEsNgGhaY+9oOtmTCEFphqqPQ+Vln57HEfJ9syb6ngJALJUw/4kcth1tWGYmfY4QvO1+KhsUGbS457MDvuLbsS+2mqDXuBFAPGZIfTTKARgQI08wj5atzlpjgFcywBVkD+0VrVpIZ7guiHgFQPf9rELwH2xUeDD+IlbgmxnZzgLYZ9JhG1/qvm2kWdtJwA7CBb2DCTm17uy5nydcOZm/jUPOxOOdwcG1bn7peTVHXXqfxQFAw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8RWZEdGRp66ZrTnvGCG/m9ZFoFbzBQIIJoHBvB5gRKM=; b=PsDbAldC6opyszVDG79vhR9sMEsRa6Z1s01Xe/98iEw3UBwU1fxu53pZRYatU68SoYnDjVtl2zwcqifeLECdXnyb6dHQStCT80g+hWq0akGcP5WHlRPUjXy69mwo7JV1UcsNcbJNuZMt70AeWenFViUB/DD6Ew7XIjr6lMwYxoE= Received: from AM0PR07MB5716.eurprd07.prod.outlook.com (20.178.115.216) by AM0PR07MB5362.eurprd07.prod.outlook.com (20.178.23.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.13; Fri, 27 Sep 2019 11:00:32 +0000 Received: from AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::fc43:ed41:fb5:b5e3]) by AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::fc43:ed41:fb5:b5e3%3]) with mapi id 15.20.2305.017; Fri, 27 Sep 2019 11:00:32 +0000 From: tom petch To: "Holland, Jake" , "Salz, Rich" CC: "netconf@ietf.org" , "taps@ietf.org" Thread-Topic: [Taps] [netconf] crypto-types fallback strategy Thread-Index: AQHVdSLIiIMcLXKzwkKSh5zqgsfzeQ== Date: Fri, 27 Sep 2019 11:00:32 +0000 Message-ID: <01e501d57522$842edfe0$4001a8c0@gateway.2wire.net> References: <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <20190918163657.4pxh5jddxgrir5oh@anna.jacobs.jacobs-university.de> <034101d572b4$cf1901e0$4001a8c0@gateway.2wire.net> <3F71FEE6-3679-4482-B210-6585A15E0BA7@akamai.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0102.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:c::18) To AM0PR07MB5716.eurprd07.prod.outlook.com (2603:10a6:208:11e::24) authentication-results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.211.103] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f7ecedee-b479-48c5-fe58-08d74339ea75 x-ms-traffictypediagnostic: AM0PR07MB5362: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0173C6D4D5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(346002)(366004)(396003)(136003)(199004)(189003)(51444003)(13464003)(64756008)(3846002)(6486002)(966005)(61296003)(6436002)(186003)(44736005)(14454004)(110136005)(81166006)(81156014)(229853002)(476003)(50226002)(316002)(54906003)(4326008)(14496001)(2906002)(305945005)(486006)(446003)(8676002)(14444005)(256004)(76176011)(99286004)(81686011)(53546011)(6506007)(386003)(25786009)(62236002)(26005)(44716002)(66574012)(8936002)(66556008)(6116002)(86362001)(478600001)(7736002)(81816011)(102836004)(6306002)(52116002)(5660300002)(6512007)(9686003)(66476007)(66446008)(71200400001)(66066001)(1556002)(66946007)(71190400001)(4720700003)(6246003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB5362; H:AM0PR07MB5716.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RIQAeWOuDL492lh3WYxjGVMx/7Q/GQvCVWTQpCgbm5PTxHoyKv55qXRRv+Khl2DtZr+rSY8mX47di34bMmlskrYOwuiW1Q67XP3e0gGmeOh4aDOTTff4/PPSpeXtPvkQGp8JRwb+dCj975f5qWJxVTDkeADjLXe/ggULyfIAZkljkUsWR5+PI0Tyrj94YNKb4f5VRK3NKR9FpW6K3RprQgpogv/+AJDzmIX5mw91UO4YpsnQ2Da9PzCbVF6GrDDYOwJWfC9j3OWgB1fkBNy0OJnAOQBN2i9G+vOvjata59rtuEENzOMONRmHLK7c3hQ5U/zQnb9jA9CWK220ifDP/vTw+atvY0wvIwCQRpCDqHYO/Se/m4iWMGFq7sliIMJtUYF++bNrGo20NULaRr7rM+4qRFGQvOhC/2w2cVTfEAJmlJHE8Vu3QROU5qbx2c9f3uJdCdvY4A7fUn+NeV1Oxw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: f7ecedee-b479-48c5-fe58-08d74339ea75 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2019 11:00:32.4361 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vmgJbR6KL9f3UTqsHn615Vmwh1yQv+PQVqn7NYrTZCSx2gh61u3G11edD1FO8bgN1os/8xYqRITDWXFm2GWWjQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5362 Archived-At: Subject: Re: [netconf] [Taps] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2019 11:00:48 -0000 LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIkhvbGxhbmQsIEpha2UiIDxqaG9s bGFuZEBha2FtYWkuY29tPg0KVG86ICJTYWx6LCBSaWNoIiA8cnNhbHpAYWthbWFpLmNvbT4NCkNj OiA8bmV0Y29uZkBpZXRmLm9yZz47IDx0YXBzQGlldGYub3JnPg0KU2VudDogVHVlc2RheSwgU2Vw dGVtYmVyIDI0LCAyMDE5IDk6MzggUE0NCg0KPiAoK3RhcHMpDQo+IEhpLA0KPg0KPiBUaGFua3Mg Zm9yIHRha2luZyBhIGxvb2sgYXQgdGhhdCBtb2RlbCwgVG9tLiAgSSdsbCBnaXZlIGp1c3QgYQ0K PiBsaXR0bGUgYmFja2dyb3VuZDoNCj4NCj4gVGhlIGN1cnJlbnQgdGFwcy1hcGkgc3RydWN0dXJl IHdhcyBkcml2ZW4gYmFzaWNhbGx5IGJ5IGFuIGF0dGVtcHQgdG8NCj4gc3VwcG9ydCB0aGUgZXhh bXBsZXMgZ2l2ZW4gaW4gdGhlIHRhcHMtaW50ZXJmYWNlIGRyYWZ0LCBmb3IgaW5zdGFuY2UNCj4g aW4gc2VjdGlvbiA1LjMuMToNCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtdGFwcy1pbnRlcmZhY2UtMDQjc2VjdGlvbi01LjMuMQ0KPg0KPiBJIGRpZG4ndCBkbyBtdWNo IChvciBhbnk/IGRvbid0IHJlY2FsbC4uLikgb2YgYSBzZWFyY2ggZm9yIGNyeXB0bw0KPiBtb2Rl bHMgYmVmb3JlIHRocm93aW5nIHRvZ2V0aGVyIHRoZSBlYXJseSBpZXRmLXRhcHMtYXBpLnlhbmcg ZHJhZnRzLA0KPiBpbmNsdWRpbmcgdGhlIHNlY3VyaXR5IGNvbmZpZyBzdHVmZi4gIEkgbW9zdGx5 IHdvcmtlZCBvZmYgdGhlIEFQSQ0KPiBleGFtcGxlcywgd2l0aCBpbnRlbnQgdG8gbG9vayBmb3Ig YSBtb3JlIHNlcmlvdXMgYW5zd2VyIGxhdGVyIGFzDQo+IHdlIHRyeSB0byBpbnRlZ3JhdGUgdGhl IHNlY3VyZSBjb25uZWN0aW9uIHN1cHBvcnQgaW50byBhIHJlZmVyZW5jZQ0KPiBpbXBsZW1lbnRh dGlvbiBvciAyLg0KPg0KPiBXaGF0J3MgdGhlcmUgbm93IGhhc24ndCBiZWVuIHRocm91Z2ggYW55 IGtpbmQgb2Ygc2VjdXJpdHkgcmV2aWV3LCBhbmQNCj4gSSdkIGNoYXJhY3Rlcml6ZSBpdCBhcyBh IHBsYWNlaG9sZGVyLCBhdCB0aGUgbW9tZW50LiAgKFRoZSB0YXBzIHVzZSBvZg0KPiB5YW5nIGlz IHN0aWxsIHJlbGF0aXZlbHkgaW1tYXR1cmUuKQ0KPg0KPiBJJ2QgYmUgdmVyeSBncmF0ZWZ1bCBm b3IgYSBncm91cGluZyBvciBvYmplY3Qgb2Ygc29tZSBraW5kIHRoYXQgSQ0KPiBjb3VsZCBwdWxs IGluIGJ5IGltcG9ydCBmcm9tIGFub3RoZXIgbW9kdWxlLCBhbmQgd291bGQgc3VwcG9ydA0KPiB1 c2luZyBpdCBpbiB0YXBzLWFwaS15YW5nIGlmIHdlIGNhbiB1c2UgaXQgdG8gZG8gd2hhdCB3ZSBu ZWVkICh3aGljaA0KPiBpcyB0byBjb25maWd1cmUgY29ubmVjdGlvbiBlbmRwb2ludHMgdG8gYWxs b3cgc2VjdXJlZCBjb25uZWN0aW9ucywNCj4gZm9yIGVpdGhlciBjbGllbnQgb3Igc2VydmVyIGVu ZHBvaW50cykuICBJIHRoaW5rIHRoYXQgd291bGQgbWFrZSBmb3INCj4gYSB2ZXJ5IGhlbHBmdWwg aW1wcm92ZW1lbnQuDQo+DQo+IFBhcnQgb2YgdGhlIHBvaW50IG9mIHVzaW5nIHlhbmcgaW4gdGFw cyB3YXMgdG8gYmUgYWJsZSB0byBiZXR0ZXINCmV4cGxvaXQNCj4geWFuZyB3b3JrIGZyb20gb3Ro ZXIgd2dzLCBhbmQgdGhpcyB3b3VsZCBiZSBhbiBleGNlbGxlbnQgb3Bwb3J0dW5pdHkNCnRvDQo+ IHB1dCB0aGF0IGludG8gcHJhY3RpY2UsIEkgdGhpbmsuICBTbyBJIHdvdWxkIGJlIHZlcnkgZGVs aWdodGVkIHRvDQppbXBvcnQNCj4gYSBtb2RlbCB0aGF0IGRvZXMgdGhpcyByaWdodC4NCg0KSmFr ZSwNCg0KWWVzISAgUGFydCBvZiB0aGUgcmVtaXQgb2YgdGhlIE5FVENPTkYgYW5kIE5FVE1PRCBX RyAgaXMgdG8gcHJvZHVjZSBZQU5HDQptb2R1bGVzIGZvciBnZW5lcmFsIHVzZSBieSBvdGhlciBX RyBhbmQNCmRyYWZ0LWlldGYtbmV0Y29uZi1jcnlwdG8tdHlwZXMNCmlzIHBhcnQgb2YgdGhhdC4g IFRoZSBORVRDT05GICpjbGllbnQtc2VydmVyKiBtb2R1bGVzIHdvdWxkIGJlIGFub3RoZXINCmV4 YW1wbGUNCg0KQ3J5cHRvIGhhcyBkaWZmZXJlbnQgb2JqZWN0IGNsYXNzZXMgLSBoYXNoLCBNQUMs IEtFWCwgZW5jcnlwdCwNCnNpZ25hdHVyZSAtIHdpdGggcGxlbnR5IG9mIG9wdGlvbnMgZm9yIG1v c3Qgb2YgdGhlc2UuICBZQU5HIGxhY2tzIGENCnN1YnNldCBmZWF0dXJlIGZvciBzYXlpbmcgdGhp cyBpcyB0aGUgTVRJIHN1YnNldCBhbmQgaGVyZSBhcmUgb3RoZXJzIGZvcg0KeW91IHRvIGNvbnNp ZGVyOyB1bmxlc3MgeW91IGRpdmlkZSB0aGUgc3BhY2UgdXAgd2l0aCBiYXNlIFlBTkcgbW9kdWxl cw0KYW5kIGF1Z21lbnRhdGlvbnMgdGhlcmV0bywgYW4gb3B0aW9uIHdoaWNoIGhhcyBiZWVuIGRp c2N1c3NlZCBvbiB0aGUNCk5FVENPTkYgbGlzdCBhbmQgbm90IGZvdW5kIGZhdm91ci4NCg0KQW5k IHRoZW4geW91IGhhdmUgU1NIIGFuZCBUTFMgd2hpY2ggdGFrZSByYWRpY2FsbHkgZGlmZmVyZW50 IGFwcHJvYWNoZXMsDQp3aXRoIFRMUyBoYXZpbmcgY2lwaGVyc3VpdGVzIGFuZCBUTFMgaXRzZWxm IGNoYW5naW5nIHdoYXQgaXQgdXNlcyB3aXRoIGENCmNoYW5nZSBvZiB2ZXJzaW9uLg0KDQpTbyBp cyBhIGxpc3Qgb2YgZXZlcnl0aGluZyBwb3NzaWJsZSwgaW4gYSB0cmVlIG9yIG1lc2ggc3RydWN0 dXJlIG9mIFlBTkcNCmlkZW50aXR5IGdvaW5nIHRvIGJlIHVzZWZ1bCB0byBvdGhlciBXRz8NCg0K WW91ciBJLUQgY2F1Z2h0IG15IGV5ZSBhbmQgc2VlbWVkIHRvIGJlIGEgZGlmZmVyZW50IGFwcHJv YWNoIGJhc2VkIG9uDQp0aGlzIGlzIHdoYXQgbW9zdCBpbXBsZW1lbnRhdGlvbnMgb2YgVExTIDEu MiB3aWxsIG5lZWQsIGFuZCBsaW1pdGluZyBpdA0KdG8gdGhhdDsgYSBkaWZmZXJlbnQgYXBwcm9h Y2ggdG8NCmRyYWZ0LWlldGYtbmV0Y29uZi1jcnlwdG8tdHlwZXMNCndoaWNoIG1hZGUgbWUgd29u ZGVyIGlmIHRoZSBsYXR0ZXIgd291bGQgYmUgb2YgYW55IHVzZSB0byB5b3U7IGFuZCBpZg0Kbm90 LCBpZiBhbnl0aGluZyB3b3VsZC4NCg0KVG9tIFBldGNoDQoNCj4gQmVzdCwNCj4gSmFrZQ0KPg0K PiDvu79PbiAyMDE5LTA5LTI0LCAxMzowMiwgIlNhbHosIFJpY2giIDxyc2FsekBha2FtYWkuY29t PiB3cm90ZToNCj4NCj4gSmFrZSwNCj4NCj4gQXMgdGhlIGF1dGhvciBvZiB0aGUgZHJhZnQgcmVm ZXJlbmNlZCBiZWxvdywgZG8geW91IGNhcmUgdG8gY29tbWVudD8NCj4NCj4gVGhlIGNyeXB0by10 eXBlcyBkb2N1bWVudCBpbiB0aGUgbmV0Y29uZiBXRyBpcyB1bmRlcmdvaW5nIHNvbWUgcHJldHR5 DQpkcmFzdGljIHN1cmdlcnkuDQo+DQo+DQo+IE9uIDkvMjQvMTksIDQ6NTAgQU0sICJ0b20gcGV0 Y2giIDxpZXRmY0BidGNvbm5lY3QuY29tPiB3cm90ZToNCj4NCj4gICAgIEdvaW5nIGJhY2sgYSBi aXQsIHNpbmNlIHRoaXMgaXMgYSBtb3JlIGdlbmVyaWMgY29tbWVudCwgSSBnZXQgYQ0KPiAgICAg ZGlmZmVyZW50LCBzaW1wbGVyIHBlcnNwZWN0aXZlIGluDQo+ICAgICBkcmFmdC1qaG9sbGFuZC10 YXBzLWFwaS15YW5nDQo+ICAgICB3aGljaCBoYXMgbWUgd29uZGVyaW5nIGp1c3QgaG93IGNvbXBs aWNhdGVkIHRoaXMgbmVlZHMgdG8gYmUgZm9yDQppdCB0bw0KPiAgICAgYmUgdXNlZnVsIGluIG90 aGVyIFdHcy4NCj4NCj4gICAgIFRoZSBJLUQgZGVmaW5lcw0KPiAgICAgICBpZGVudGl0eSBzZWN1 cml0eS1hbGdvcml0aG0ge2Rlc2NyaXB0aW9uICJCYXNlIGlkZW50aXR5IGZvcg0Kc2VjdXJpdHkN Cj4gICAgIGFsZ29yaXRobXMuIg0KPiAgICAgICBpZGVudGl0eSBjaXBoZXItc3VpdGUgeyBiYXNl IHNlY3VyaXR5LWFsZ29yaXRobTtkZXNjcmlwdGlvbg0KIkJhc2UNCj4gICAgIGlkZW50aXR5IGZv ciBzZWN1cml0eSBjaXBoZXIgc3VpdGVzLiI7DQo+ICAgICAgIGlkZW50aXR5IHNpZ25hdHVyZS1h bGdvcml0aG0ge2Jhc2Ugc2VjdXJpdHktYWxnb3JpdGhtOw0KPiAgICAgZGVzY3JpcHRpb24gIkJh c2UgaWRlbnRpdHkgZm9yIHNlY3VyaXR5IHNpZ25hdHVyZSBhbGdvcml0aG1zLiI7DQo+ICAgICAg IGlkZW50aXR5IGVkMjU1MTkge2Jhc2Ugc2lnbmF0dXJlLWFsZ29yaXRobTsNCj4gICAgICAgaWRl bnRpdHkgVExTX0VDREhFX0VDRFNBX1dJVEhfQ0hBQ0hBMjBfUE9MWTEzMDVfU0hBMjU2IHsNCj4g ICAgICAgICBiYXNlIGNpcGhlci1zdWl0ZTsNCj4NCj4gICAgIGFuZA0KPg0KPiAgICAgICBncm91 cGluZyBzZWN1cml0eS1jcmVkZW50aWFscyB7DQo+ICAgICAgICAgbGVhZiBpZGVudGl0eSB7IHR5 cGUgc3RyaW5nOw0KPiAgICAgICAgIGxlYWYgdHJ1c3QtY2EgeyB0eXBlIHN0cmluZzsNCj4gICAg ICAgICBsZWFmIGFsZ29yaXRobSB7IHR5cGUgaWRlbnRpdHlyZWYge2Jhc2Ugc2VjdXJpdHktYWxn b3JpdGhtOw0KPiAgICAgICAgIGxlYWYgcHJlLXNoYXJlZC1rZXkgeyB0eXBlIHN0cmluZzsNCj4g ICAgICAgICBsZWFmIHByaXZhdGUta2V5IHsgdHlwZSBzdHJpbmc7DQo+ICAgICAgICAgbGVhZiBw cml2YXRlLWtleS1jYWxsYmFjay1oYW5kbGUge3R5cGUgc3RyaW5nOw0KPiAgICAgICAgIGxlYWYg cHVibGljLWtleSB7dHlwZSBzdHJpbmc7DQo+DQo+ICAgICAoTm8gU1NIIGJ1dCB0aGF0IGRvZXMg bm90IHN1cnByaXNlIG1lOi0pDQo+DQo+ICAgICBBZ2FpbiBhIG1vcmUgZ2VuZXJhbCBjb21tZW50 LCB0aGUgSUVURiBvZnRlbiBzdGFydHMgc2ltcGxlIGFuZA0KYWRkcyBsb3RzDQo+ICAgICBsYXRl ciwgd2hpY2ggc29tZXRpbWVzIGdvZXMgd3JvbmcgYmVjYXVzZSBubyBhbGxvd2FuY2Ugd2FzIG1h ZGUNCmZvcg0KPiAgICAgc2xvdHRpbmcgaW4gZXh0cmFzLCBidXQgYW4gYXBwcm9hY2ggd2hpY2gs IEkgdGhpbmssIG1vcmUgb2Z0ZW4NCmxlYWRzIHRvDQo+ICAgICBzdWNjZXNzZnVsIGFkb3B0aW9u Lg0KPg0KPiAgICAgVGh1cyB3aWxsIFRBUFMgY29uc2lkZXIgdXNpbmcNCj4gICAgIGRyYWZ0LWll dGYtbmV0Y29uZi1jcnlwdG8tdHlwZXMNCj4gICAgIG9yIHdpbGwgdGhleSBSWU8/DQo+DQo+ICAg ICBUb20gUGV0Y2gNCj4NCj4gICAgIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gICAg IEZyb206IDxTY2jDtm53w6RsZGVyPjsgIkrDvHJnZW4iDQo8Si5TY2hvZW53YWVsZGVyQGphY29i cy11bml2ZXJzaXR5LmRlPg0KPiAgICAgVG86ICJSb2IgV2lsdG9uIChyd2lsdG9uKSIgPHJ3aWx0 b25AY2lzY28uY29tPg0KPiAgICAgQ2M6ICJSdXNzIEhvdXNsZXkiIDxob3VzbGV5QHZpZ2lsc2Vj LmNvbT47IDxuZXRjb25mQGlldGYub3JnPjsNCiJTZWFuDQo+ICAgICBUdXJuZXIiIDxzZWFuQHNu M3JkLmNvbT47ICJSaWZhYXQgU2hla2gtWXVzZWYiDQo8cmlmYWF0LmlldGZAZ21haWwuY29tPg0K PiAgICAgU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTgsIDIwMTkgNTozNiBQTQ0KPg0KPiAg ICAgPiBPbiBXZWQsIFNlcCAxOCwgMjAxOSBhdCAwMzozNzoxNFBNICswMDAwLCBSb2IgV2lsdG9u IChyd2lsdG9uKQ0Kd3JvdGU6DQo+ICAgICA+ID4gPkZyb20gdGhlIGdpc3Qgb2YgdGhlIGRpc2N1 c3Npb24sIHRoZSBwdW5jaCBsaXN0IGFwcGVhcnMgdG8NCmJlOg0KPiAgICAgPiA+DQo+ICAgICA+ ID4gLSByZXZlcnQgYmFjayB0byB1c2luZyBpZGVudGl0aWVzLCBhcyB0aGV5IHdlcmUgaW4gdGhl IC0wOA0KcmV2aXNpb24uDQo+ICAgICA+ID4gLSBvbmx5IGRlZmluZSBiYXNlIGlkZW50aXRpZXMg Zm9yIHdoYXQncyBuZWVkZWQgaW1tZWRpYXRlbHkNCmZvciBUTFMNCj4gICAgIGFuZCBTU0ggYW5k IGtleXN0b3JlIGtleS1lbmNyeXB0aW9uLg0KPiAgICAgPiA+IC0gZGVmaW5lIHRoZXNlIGJhc2Ug aWRlbnRpdGllcyBpbiBkaXN0aW5jdCBZQU5HIG1vZHVsZXMNCj4gICAgID4gPiAtIGhhdmUgZWFj aCBpZGVudGl0eSdzIGRlc2NyaXB0aW9uIHN0YXRlbWVudCBpbmRpY2F0ZSB3aGF0IHRoZQ0KPiAg ICAgYmluYXJ5IGtleSBkYXRhIGlzIGVuY29kZWQuDQo+ICAgICA+ID4gW1JXXQ0KPiAgICAgPiA+ IEkgdGhpbmsgdGhhdCB0aGlzIG1hdGNoZXMgbXkgdmlldywgZXhjZXB0IGZvciAiZGVmaW5lIHRo ZXNlDQpiYXNlDQo+ICAgICBpZGVudGl0aWVzIGluIGRpc3RpbmN0IFlBTkcgbW9kdWxlcyIuICBJ IGRvbid0IGZlZWwgcGFydGljdWxhcmx5DQo+ICAgICBzdHJvbmdseSBhYm91dCB0aGlzLCBidXQg SSB3YXMgdGhpbmtpbmcgdGhhdCB0aGUgYmFzZSBpZGVudGl0aWVzDQp3b3VsZA0KPiAgICAgc3Rp bGwgYmUgZGVmaW5lZCBpbiBjcnlwdG8tdHlwZXMueWFuZywgd2hpY2ggbWlnaHQgaGVscCBrZWVw IHRoZQ0KaW1wb3J0DQo+ICAgICByZWZlcmVuY2VzIHNpbXBsZS4NCj4gICAgID4NCj4gICAgID4g SSB0ZW5kIHRvIGFncmVlIHRoYXQgc29tZXRpbWVzIGxlc3MgbW9kdWxlcyBpcyBtb3JlLiBGb3Ig bWUsIHRoZQ0KPiAgICAgPiBwcm9ibGVtIGlzIGxpa2VseSBtb3JlIHRoYXQgSSBhbSBub3QgZW50 aXJlbHkgc3VyZSB3aGF0IHRoZQ0KcHJvcGVyDQo+ICAgICA+IGJhc2UgdHlwZXMgd291bGQgYmUs IHdoaWNoIG1heSBkZXBlbmQgb24gd2hhdCBleGFjdGx5IHRoZXkgYXJlDQp1c2VkDQo+ICAgICA+ IGZvci4gSSBndWVzcyBJIHdhaXQgdW50aWwgSSBzZWUgdGhlIGRlc2NyaXB0aW9uIHRleHQuLi4N Cj4gICAgID4NCj4gICAgID4gPiBBIGJpdCBzZXBhcmF0ZSBmcm9tIHRoZSBhYm92ZSwgYnV0IHN0 aWxsIGluIG1pbmQ6DQo+ICAgICA+ID4NCj4gICAgID4gPiAgIC0gc3BlY2lmeSB0aGF0IGFsbCBU TFMgcHVibGljLWtleXMgYXJlIGEgREVSLWVuY29kZWQNCj4gICAgIFN1YmplY3RQdWJsaWNLZXlJ bmZvIHN0cnVjdHVyZQ0KPiAgICAgPiA+ICAgLSBzcGVjaWZ5IHRoYXQgYWxsIFNTSCBwdWJsaWMt a2V5cyBhcmUgYQ0KInNzaC1wdWJsaWMta2V5LXR5cGUiDQo+ICAgICB0eXBlIChzZWUgYmVsb3cp DQo+ICAgICA+ID4gICAtIHNwZWNpZnkgdGhhdCBhbGwgZW5jcnlwdGVkIHN5bW1ldHJpYyBrZXlz IGFyZSBhDQpERVItZW5jb2RlZA0KPiAgICAgT25lU3ltbWV0cmljS2V5IHN0cnVjdHVyZQ0KPiAg ICAgPiA+ICAgLSBzcGVjaWZ5IHRoYXQgYWxsIGVuY3J5cHRlZCBhc3ltbWV0cmljIGtleXMgYXJl IGENCkRFUi1lbmNvZGVkDQo+ICAgICBPbmVBc3ltbWV0cmljS2V5IHN0cnVjdHVyZQ0KPiAgICAg Pg0KPiAgICAgPiBJIHdvdWxkIGNoZWNrIHdoYXQgaXMgY29tbW9ubHkgdXNlZCBpbiBleGlzdGlu ZyBjb25maWd1cmF0aW9uDQo+ICAgICA+IGludGVyZmFjZXMuIFdlIGFyZSBub3QgaW52ZW50aW5n IHRoZSB3aGVlbCBoZXJlLiBBbmQgd2hhdGV2ZXIgd2UNCj4gICAgID4gZGVmaW5lIGJldHRlciBp cyB1c2FibGUgd2l0aCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgYW5kIHRvb2xzLg0KPiAgICAg Pg0KPiAgICAgPiA+IFRoZSAic3NoLXB1YmxpYy1rZXkiIHR5cGUgd291bGQgYmUgZGVmaW5lZCBh czoNCj4gICAgID4gPg0KPiAgICAgPiA+ICAgICAgdHlwZWRlZiBzc2gtcHVibGljLWtleS10eXBl IHsNCj4gICAgID4gPiAgICAgICAgICB0eXBlIGJpbmFyeTsNCj4gICAgID4gPiAgICAgICAgICBt YW5kYXRvcnkgdHJ1ZTsNCj4gICAgID4gPiAgICAgICAgICBkZXNjcmlwdGlvbg0KPiAgICAgPiA+ ICAgICAgICAgICAgIlRoZSBiaW5hcnkgcHVibGljIGtleSBkYXRhIGZvciB0aGlzIFNTSCBrZXks IGFzDQo+ICAgICA+ID4gICAgICAgICAgICAgc3BlY2lmaWVkIGJ5IFJGQyA0MjUzLCBTZWN0aW9u IDYuNiwgaS5lLjoNCj4gICAgID4gPg0KPiAgICAgPiA+ICAgICAgICAgICAgICAgc3RyaW5nICAg IGNlcnRpZmljYXRlIG9yIHB1YmxpYyBrZXkgZm9ybWF0DQo+ICAgICA+ID4gICAgICAgICAgICAg ICAgICAgICAgICAgaWRlbnRpZmllcg0KPiAgICAgPiA+ICAgICAgICAgICAgICAgYnl0ZVtuXSAg IGtleS9jZXJ0aWZpY2F0ZSBkYXRhLiI7DQo+ICAgICA+ID4gICAgICAgICAgcmVmZXJlbmNlDQo+ ICAgICA+ID4gICAgICAgICAgICAiUkZDIDQyNTM6IFRoZSBTZWN1cmUgU2hlbGwgKFNTSCkgVHJh bnNwb3J0DQo+ICAgICA+ID4gICAgICAgICAgICAgICAgICAgICAgIExheWVyIFByb3RvY29sIjsN Cj4gICAgID4gPiAgICAgICAgICAgfQ0KPiAgICAgPg0KPiAgICAgPiBUaGUgU1NIIGltcGxlbWVu dGF0aW9ucyB0aGF0IEkgdXNlIGhhdmUgdGhlIGJpbmFyeSBrZXkgZGF0YQ0KcmVuZGVyZWQNCj4g ICAgID4gaW4gQVNDSUkuIEluIGZhY3QsIHRoZSB3aG9sZSBrZXkgcmVjb3JkIGlzIHJlbmRlcmVk IGluIEFTQ0lJLiBJDQo+ICAgICA+IHN0cm9uZ2x5IHN1Z2dlc3QgdG8gdXNlIGZvcm1hdHMgdGhh dCBhcmUgd2VsbCBlc3RhYmxpc2hlZC4NCj4gICAgID4NCj4gICAgID4gL2pzDQo+ICAgICA+DQo+ ICAgICA+IC0tDQo+ICAgICA+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2Jz IFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+ICAgICA+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3 ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8DQpHZXJtYW55DQo+ICAgICA+ IEZheDogICArNDkgNDIxIDIwMCAzMTAzDQo8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHku ZGUvPg0KPiAgICAgPg0KPiAgICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiAgICAgPiBuZXRjb25mIG1haWxpbmcgbGlzdA0KPiAgICAgPiBuZXRj b25mQGlldGYub3JnDQo+ICAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0Y29uZg0KPg0KPiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gICAgIG5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ICAgICBuZXRjb25mQGll dGYub3JnDQo+ICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNv bmYNCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gVGFwcyBtYWlsaW5nIGxpc3QNCj4gVGFwc0BpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RhcHMNCj4NCg0K From nobody Fri Sep 27 05:47:49 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650E5120128 for ; Fri, 27 Sep 2019 05:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=ericsson.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 wwhDk6sT7NLs for ; Fri, 27 Sep 2019 05:47:44 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60045.outbound.protection.outlook.com [40.107.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8C8D12001E for ; Fri, 27 Sep 2019 05:47:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QK/7lOY9X40KxgrvxuWmK5QEUM+opm2+LGAMeFiC4izxIs7D1cNjWNh7xwlY/HjKBb92OL/U07do8WOwuqMOdPZdLv4PclYHUW1VmXkgnJGyLrnFM6wCgdnlp/+RZ6uaSAqkQMgEiOdUQnfpL3sw145qQ4VJZkJoIDniTeMEhpY+Jz3bNCy7frmbcDAqO6RR8WEtXG4FwAgo3kSOkpunSMl1n84VUErrJY8MNUuXqqydsqA7pk7v7ERSNzNu+g/a4Z+3Ewk0X66WlaalnBwHTNI+gm/KsRE+pKyXl6xRmmY9tkc2TYwog3c2YqbmjVrzCl07h6IHOuADNd13NlD5qA== 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=TvGxOCWMMQjtivMJnjN+G3KR5fT4ylDSjHT3l466/Xw=; b=PjCJtdWrHk60Zsn0f2OvWnj9xkeN00ZwpROXor40ljU7dobu2yKqW6XoyIn+m9qFZrY7PIc/Y0mJDcsd2KotCYGmoPfeXkFjHUqOzM35gAb4VZsGFccTz2jAqXxbk9Z0897ZJTVSUmP+Th88ilzgRkEOqzvQ0HwU/QgxdkW0j9peR8yNATUCCu2qRfm3hX4WX1S2gvg/FIl2Id+Ld9vh2OkHEBVuj+M1hzjqNKnSfH+0wI7Lf/lw+eXSAkXQWzvVvSymy/jE1QSDloHDdRxaQsSFgSWNO9G2MOtM4MH5h/D+BDuuMDnKXYyLF08sr52oUQdLnLubmeHgKvkYA2jFyA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TvGxOCWMMQjtivMJnjN+G3KR5fT4ylDSjHT3l466/Xw=; b=PJOqowOtxXClEFB1HW8gpVQpEFBbIYwj8grCSLJgFxd2vmRuPGOBO7EI7p+6qBZ1A8IRkM1wrqE7F3X+AKbBbJy3J14SurMAg7+0zYStAwEK4aQJxKLRKaq4NMtufN5je2uAkld6Ou7NKzfrfNcusVDjGDJjQpJXTrR1QEMU4wE= Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com (10.169.137.153) by VI1PR0701MB2750.eurprd07.prod.outlook.com (10.173.79.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2327.9; Fri, 27 Sep 2019 12:47:40 +0000 Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com ([fe80::f44b:854c:51cf:c69f]) by VI1PR0701MB2286.eurprd07.prod.outlook.com ([fe80::f44b:854c:51cf:c69f%7]) with mapi id 15.20.2305.017; Fri, 27 Sep 2019 12:47:40 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: "Eric Voit (evoit)" , Mahesh Jethanandani , Alexander Clemm , "Benoit Claise (bclaise)" CC: Netconf Thread-Topic: [netconf] WGLC for draft-ietf-netconf-notification-capabilities Thread-Index: AQHVaCiq/P3ytjAdYEi7Gp+LSYgUDqc7MLcAgAA5KYCAA/LsEA== Date: Fri, 27 Sep 2019 12:47:40 +0000 Message-ID: References: <4F49DF08-B7FC-4EBD-9D6B-7BC329E50334@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 12df3307-dbec-4fb1-a749-08d74348e222 x-ms-traffictypediagnostic: VI1PR0701MB2750: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0173C6D4D5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(346002)(376002)(396003)(39860400002)(51914003)(189003)(199004)(3846002)(6506007)(64756008)(110136005)(66066001)(85202003)(33656002)(790700001)(7110500001)(6116002)(8676002)(66574012)(81156014)(6436002)(6306002)(54896002)(9686003)(55016002)(2420400007)(15650500001)(316002)(6246003)(81166006)(4326008)(229853002)(26005)(99936001)(508600001)(14454004)(256004)(236005)(2906002)(86362001)(85182001)(14444005)(606006)(71200400001)(186003)(7696005)(99286004)(71190400001)(76116006)(66946007)(446003)(25786009)(76176011)(476003)(8936002)(74316002)(11346002)(486006)(7736002)(52536014)(66616009)(53546011)(66446008)(66556008)(66476007)(5660300002)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2750; H:VI1PR0701MB2286.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FgjLwP856mpkZ1WhOTAXmgSwsWIn0j0o1ogko6rmhuV/p2vxFRQL5jU9R7Tw0RNy97thbbCMtQfvk8z0hPaR8QIz01TVHzJj7wMZ9EVq8Ks5+7CTJzc4j49BF9f2wiaO1fluhIUZXE2NQQjFHeVuMX01empoSnN7YyGb/XwV4+7pBugW9Kr/xMId6jPU/enxUOMwFL5lCB/fkbAEkZGrKfucVqwp4WkJ2IpLOLbj+O+vjYBEwfll9lqPAhkZI3DwmG1AGpi143H5WZ6T8ob7fCTk7d6znCCQM0YGL9Hy5NH2c30mGWxEhD2htaixTrKg6Q+parcXLl+USE/7d3RtELUPQ85HtV5ROiT4pQ5elLjJoK3q1AxBteyPzcTev7GkKkmWJihFxxt3fapuY5nnmcw1Kw8LntvDBFwV9opDmMw= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_04B6_01D57542.81D66360" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 12df3307-dbec-4fb1-a749-08d74348e222 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2019 12:47:40.4403 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4no6wRDIN/Yk1y8g2rMc+QbyQTG/Rqms22QDoTjNQ7jXWOIdBRlKziYr/1Dl20taMQQOcN2DsGLMIbO5K6mY1LeXKIvEybPjDUzb2UB+yb8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2750 Archived-At: Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2019 12:47:47 -0000 ------=_NextPart_000_04B6_01D57542.81D66360 Content-Type: multipart/alternative; boundary="----=_NextPart_001_04B7_01D57542.81D66360" ------=_NextPart_001_04B7_01D57542.81D66360 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks for the comments. See answers below.=20 I hope the group will be ok with using the term publisher instead of = server. IMHO it is clearer as the client server relationship can be = reversed e.g. for https notification transport. Balazs =20 From: Eric Voit (evoit) =20 Sent: 2019. szeptember 24., kedd 23:15 To: Mahesh Jethanandani ; Bal=C3=A1zs Lengyel = ; Alexander Clemm ; = Benoit Claise (bclaise) Cc: Netconf Subject: RE: [netconf] WGLC for = draft-ietf-netconf-notification-capabilities =20 Here are some comments... =20 Section 1: Terminology =20 YANG-Push is the RFC-8641 term rather than Yang-Push. Both variants = are used in this document BALAZS: OK. Updated references to RFC and the capitalization to = YANG-Push =20 On-change Notification Capability: Is this different from support for = RFC-8641 feature "on-change"? If they are the same, it might be = possible to remove the term. Especially as this term is used = inconsistently. BALAZS: In RFC 8641 on-change is not defined as a capability. It is used = for many more things (e.g. On-change subscription, trigger condition, = type of push updates, a feature.) In this draft the on change capability = is just the servers capability to send on-change notification globally, = for a specific datastore or a specific data node. Description will be = reworded. Implementation-time information is used twice in the document, but = without the dash BALAZS: OK. I corrected the missing dashes. After this the term is used = 5 times. =20 Run-time information is used once. And the definition refers to the = availability of information over network management protocols. Is it = worth differentiating the term via a linkage to run-time state objects? BALAZS: Sorry but in my count the term appears 9 times. IMHO the duality = that the same information is available both during implementation and = run-time is an important point, so I would like to keep the term. Which = protocol is used to get the info is not crucial. It could be the CLI. I = put Netconf/Restconf there because someone asked for it. =20 =20 =20 Section 2 =20 Paragraph 4: instead of " meaningless (e.g., a temperature gauge = changing 0.1 degrees)", how about "irrelevant to the receiver (e.g., a = temperature gauge change of 0.1 degrees within a predetermined and = acceptable range)"? BALAZS: OK, updated =20 Paragraph 6: instead of "not available early in some document" how = about " not documented in a way available to the NMS designer". Also // = from, is/ from is BALAZS: OK, updated.=20 =20 Bullet #1 under Run time information: not sure what is meant by "it does = not care which data nodes send notification, it will just handle what is = available.". Should reword. BALAZS: OK, reworded. =20 Bullet #3: might want to reword: " implementation time capability = information about the capabilities" BALAZS: OK, updated =20 =20 =20 Section 3 =20 Paragraph 2, bullet 2: Instead of "amount of notifications the server = can send out", do you mean "the minimum periodicity of updates which a = server can send out for an object" BALAZS: That too, but also the max-objects-per-update. I was told not to = repeat information in the main text and in the YANG module, so I tried = to find a wording that covers both. Also its not always the minimum = times. Some servers support a specific set of times, not a anything = over a minimum. =20 Paragraph 2, bullets 3 & 4: I don't think these should be indented as = bullets are they are more about proper behavior of a correctly populated = model. BALAZS: I don=E2=80=99t really understand this comment. Please explain. =20 Paragraph 3, bullets 2: why isn't SHALL instead MUST? Also, shouldn't = this point out that both NETCONF and RESTCONF MUST be supported if = on-change is advertised, and this draft is supported? BALAZS: As I understand RFC 2119 MUST and SHALL both mean the same, but = I will change to MUST. No I do not want to mandate implementing both = Netconf AND Restconf. IMO a server with just Netconf would work just = fine; or maybe I misunderstand your comment? =20 =20 =20 YANG Model =20 I am not sure why "server" is preferable to "publisher". The initial = YANG-Push draft moved to "Publisher" because it is possible for the = client-server roles to be reversed for some transport protocols. For = example, the recent HTTP notif draft might have the receiver fill the = HTTP server role. I believe it cleaner to revert to the "publisher" = terminology. BALAZS: OK. I agree. Actually had that problem when explaining the HTTPS = notification transport in my company. I will start using the term = =E2=80=9Cpublisher=E2=80=9D. =20 I do like the tiered structure of specific and generic values. There = are lots of good parallels to other YANG work. =20 =20 Section 4 =20 I suspect that you will need to do a security analysis per YANG object. = This has been done the other YANG push family. BALAZS: The full module is readOnly and not sensitive or private in any = manner. The security text for the readOnly parts of YangPush is the = exact same text: not very informative, but gives you the illusion of = security awareness. =20 I suspect that manipulating the reporting intervals could have some = security implications. E.g., a hacker could push up the damping period = or periodic interval to a level where the information they are changing = then becomes invisible to a monitoring system. BALAZS: The full YAM is read-only so manipulating the data is not a = concern. =20 Thanks,=20 Eric=20 =20 =20 From: netconf > On Behalf Of Mahesh Jethanandani Sent: Tuesday, September 24, 2019 1:50 PM To: Netconf > Subject: Re: [netconf] WGLC for = draft-ietf-netconf-notification-capabilities =20 We were supposed to have closed on the WGLC today. However, between the = document becoming a WG item and it going into LC, we have not received = too many comments on the draft. As such, we are extending the LC by = another week. Please review the draft and provide any comments you might = have. =20 Mahesh & Kent (as co-chairs) =20 =20 On Sep 10, 2019, at 3:39 PM, Mahesh Jethanandani = > wrote: =20 Authors have published -04 = version of the draft, which addresses comments they received in = IETF 105. If you provided comments please check to make sure your = comments have been addressed. At this point, the authors believe that = the document is ready for WGLC. =20 This therefore starts a two week LC, ending on September 24th. Please = provide any technical comments you might have on the document. If you = believe the document is not ready for LC, please state your reasons. =20 We will issue a IPR poll separately.=20 =20 Mahesh & Kent (as co-chairs) =20 =20 =20 =20 ------=_NextPart_001_04B7_01D57542.81D66360 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Thanks for = the comments. See answers below. =

I hope the group will be ok with using the term = publisher instead of server. IMHO it is clearer as the client server = relationship can be reversed e.g. for https notification = transport.

Balazs

 

From: Eric Voit (evoit) = <evoit@cisco.com>
Sent: 2019. szeptember 24., kedd = 23:15
To: Mahesh Jethanandani <mjethanandani@gmail.com>; = Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>; Alexander Clemm = <ludwig@clemm.org>; Benoit Claise (bclaise) = <bclaise@cisco.com>
Cc: Netconf = <netconf@ietf.org>
Subject: RE: [netconf] WGLC for = draft-ietf-netconf-notification-capabilities

 

Here are = some comments...

 

Section 1: Terminology

 

YANG-Push is the RFC-8641 term rather than = Yang-Push.   Both variants are used in this = document

BALAZS: OK. Updated references to RFC and the = capitalization to YANG-Push

 

On-change Notification Capability: Is this = different from support for RFC-8641 feature "on-change"?  = If they are the same, it might be possible to remove the term.  = Especially as this term is used inconsistently.

BALAZS: In RFC 8641 = on-change is not defined as a capability. It is used for many more = things (e.g. On-change subscription, =C2=A0trigger condition, = type of push updates, a feature.) In this draft the on change capability = is just the servers capability to send on-change notification globally, = for a specific datastore or a specific data node. Description will be = reworded.

=

Implementation-time information = is used twice in the document, but without the dash

BALAZS: OK. I = corrected the missing dashes. After this the term is used 5 = times.

 

Run-time information is used once.  And the = definition refers to the availability of information over network = management protocols.  Is it worth differentiating the term via a = linkage to run-time state objects?

BALAZS: Sorry but in = my count the term appears 9 times. IMHO the duality that the same = information is available both during implementation and run-time is an = important point, so I would like to keep the term.=C2=A0 Which protocol = is used to get the info is not crucial. It could be the CLI. I put = Netconf/Restconf there because someone asked for = it.

 

 

 

Section 2

 

Paragraph 4: instead of " meaningless (e.g., a = temperature gauge changing 0.1 degrees)", how about = "irrelevant to the receiver (e.g., a temperature gauge change of = 0.1 degrees within a predetermined and acceptable = range)"?

BALAZS: OK, updated

 

Paragraph 6:  instead of "not available = early in some document"  how about " not documented in a = way available to the NMS designer".  Also // from, is/ from = is

BALAZS: OK, updated.

 

Bullet = #1 under Run time information: not sure what is meant by "it does = not care which data nodes send notification, it will just handle what is = available.".  Should reword.

BALAZS: OK, = reworded.

 

Bullet = #3: might want to reword: " implementation time capability = information about the capabilities"

BALAZS: OK, = updated

 

 

 

Section 3

 

Paragraph 2, bullet 2: Instead of =  "amount of notifications the server can send out", do = you mean "the minimum periodicity of updates which a server can = send out for an object"

BALAZS: That too, but also the = max-objects-per-update. I was told not to repeat information in the main = text and in the YANG module, so I tried to find a wording that covers = both. Also=C2=A0 its not always the minimum times. Some servers support = =C2=A0a specific set of times, not a anything over a = minimum.

 

Paragraph 2, bullets 3 & 4: I don't think these = should be indented as bullets are they are more about proper behavior of = a correctly populated model.

BALAZS: I don=E2=80=99t really understand this = comment.=C2=A0 Please explain.

 

Paragraph 3, bullets 2: why isn't SHALL instead = MUST?   Also, shouldn't this point out that both NETCONF and = RESTCONF MUST be supported if on-change is advertised, and this draft is = supported?

BALAZS: As I understand RFC 2119 MUST and SHALL = both mean the same, but I will change to MUST. No I do not want to = mandate implementing both Netconf AND Restconf. IMO a server with just = Netconf would work just fine; or maybe I misunderstand your = comment?

 

 

 

YANG = Model

 

I am not sure why "server" is preferable = to "publisher".  The initial YANG-Push draft moved to = "Publisher" because it is possible for the client-server roles = to be reversed for some transport protocols.  For example, the = recent HTTP notif draft might have the receiver fill the HTTP server = role.   I believe it cleaner to revert to the = "publisher" terminology.

BALAZS: OK. I agree. = Actually had that problem when explaining the HTTPS notification = transport in my company. I will start using the term = =E2=80=9Cpublisher=E2=80=9D.

 

I do = like the tiered structure of specific and generic values.  There = are lots of good parallels to other YANG work.

 

 

Section 4

 

I = suspect that you will need to do a security analysis per YANG = object.   This has been done the other YANG push = family.

BALAZS: The full module is readOnly and not = sensitive or private in any manner.=C2=A0 The security text for the = readOnly parts of YangPush is the exact same text: not very informative, = but gives you the illusion of security = awareness.

 

I = suspect that manipulating the reporting intervals could have some = security implications.   E.g., a hacker could push up the = damping period or periodic interval to a level where the information = they are changing then becomes invisible to a monitoring = system.

BALAZS: The full YAM is read-only so = manipulating the data is not a concern.

 

Thanks,

Eric =

 

 

From: = netconf <netconf-bounces@ietf.org>= On Behalf Of Mahesh Jethanandani
Sent: Tuesday, = September 24, 2019 1:50 PM
To: Netconf <netconf@ietf.org>
Subject:<= /b> Re: [netconf] WGLC for = draft-ietf-netconf-notification-capabilities

 

We = were supposed to have closed on the WGLC today. However, between the = document becoming a WG item and it going into LC, we have not received = too many comments on the draft. As such, we are extending the LC by = another week. Please review the draft and provide any comments you might = have.

 

Mahesh & Kent (as co-chairs)

 

 

On Sep 10, 2019, at 3:39 PM, Mahesh Jethanandani = <mjethanandani@gmail.com> = wrote:

 

Authors have published -04 version of the draft, which addresses comments = they received in IETF 105. If you provided comments please check to make = sure your comments have been addressed. At this point, the authors = believe that the document is ready for WGLC.

 

This therefore starts a two week LC, ending on = September 24th. Please provide any technical comments you might have on = the document. If you believe the document is not ready for LC, please = state your reasons.

 

We will issue a IPR poll = separately. 

 

Mahesh & Kent (as = co-chairs)

 

 

 

 

------=_NextPart_001_04B7_01D57542.81D66360-- ------=_NextPart_000_04B6_01D57542.81D66360 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVbjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF/zCCA+egAwIBAgIR AOm+1xFswMzmixU1jNT/MSEwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMB4XDTE3MTAw OTE1MjQ1OFoXDTIwMTAwOTE1MjQ1N1owajERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD0Jh bMOhenMgTGVuZ3llbDEqMCgGCSqGSIb3DQEJARYbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t MQ8wDQYDVQQFEwZFVEhCTEwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUUtnneUfH i428YPkvW+AsCNeKCCKq72SzUZpBggijy+oLVO0cgTXXHygrZ+KT8TbyEkPwuHi+V4TQxWAyMhGa nWZHWZXe9ghEZrJDJbCzFMHOqR+wEDnI1vM3sfQQ68iSsWQLd9opnb2/ihiJlt9up75VRpyj5lea bvzxOLQimJgZiXaZzsPPT2nROyytKxOsE5KbfT3mNof3bMG1bggZtGGA1GBJchwdFJwQKIShfPVm 1CdulvJV1hPVecxttMJNPzSfSfryb/b64QnR5yc/pSx8SxD0h0rnNT73Al3Af2iRghdXN4omDKZY OcdK/sE5HTmLTFuWoZAnL/RntOK9AgMBAAGjggHBMIIBvTBIBgNVHR8EQTA/MD2gO6A5hjdodHRw Oi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggr BgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYI KwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNlcjAmBgNVHREEHzAdgRtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBSkJw2vbyMFmf9tY1urk9NeYfiMgTAfBgNVHSMEGDAWgBQcexmel5x2rCA92Nzj kWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAD1RCVf5Df2uCXwPveXz LBGIjsz3k2la5UUlioC+i4Ms6vGstqXIX7K24+Wc41npi+G5xFhvkAkmuTP/j29F5xJJuJcy3OcL 0br02vKe2WJJnlivB+X9plPg0kMUBS0lLq7kHPUrO/BLeIIFRuaky05eZlTnGNcLbn5VpZdjX4Ic XZV78qpZI3L67Po1UgHzOTiWolc75jrKOx3UOw98fWRrgJPBUIeqDeD1NDfF7PlM4Cqlad062o6L lM9wfAnoLzz0z04dPXtJkOcTiZgOLdPoKIm7LR1wZ9c6mYw4sgtoVAs16Y2cCPBxqWpsW+9ZCcDK PPZzeBezCKyicpDJbTqCVMILd3j38HWUPWFuVITZNgANzHW1CpgqmiLIAADiznCCtudTE+fcB3O9 duuu/yuEME17LMy1GYMKXs1QCXmTq2hrqTJQ2AA2TsWZtoxl3ViqJgNBWjnQiMwdCl5Dural2jZP /iU6MmiauUNYn9YW/ViUluoBBdaUHMpnP/7kM0Wk8j3Wzhcggx+Biml2gCopMaK1EJYjQH/2J95N GEkSdZfVzFUmwV3yMd4mOhIaxW0SEq9b1eWICZ/BAcVBpSyU0sE1gpnBO5wLxj+IpSdiGlS4jc37 qCr/39xdv1Unu93glCmHq0xgX54N8EsyMBPC3+zSSu1qhCbU7VJWIz2aMIIGwjCCBKqgAwIBAgIQ U7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEf MB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcx MjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy 3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt 8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6j RrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFl hFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/2 0aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCY rEqHMRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuT LUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMd ay0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqd GTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMB AAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVz dC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9j cmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpec dqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5 s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90 BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRy pF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86 IWst821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QD Xnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7 C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbN QUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbH XSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i 6Ds5j0Qpj5aQMYIDBTCCAwECAQEwXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MAkGBSsOAwIaBQCgggF+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTE5MDkyNzEyNDczOFowIwYJKoZIhvcNAQkEMRYEFLvijYcE//JqCRR140dIQFS0t10aMEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQA+VkO5Bp8jyRrwU/Kf6Vzf//ukjjdHu7GqcfA440IJ0TBvBKIJMwK/ 6U9xEYQ9EhfskoIQBLt6Kgd/8CITAbJB2wpuQM2FK6ADv7P4aeNpe31kSN2DrigOWgDFsqD4fn3H NFaO4q0TjOk/x5OWC3pgduimHInL8tTfQeeKDn02Ndzd0my2rxK7MmzvJDWLqNxeUrfpSqVRQfYB SNxn7snRV4PkeLrEqTkW2LnbKqFD+yg7SszvRn9aFKjczhG5S8J6tsjdQmnIDvjLm7OObxsBtEsO iwa/FjJ9A37DcmsO1MgMMrdSlDb9o7gyRoVw6DlUB3y/Qgg4eKZgz9/d1A9tAAAAAAAA ------=_NextPart_000_04B6_01D57542.81D66360-- From nobody Fri Sep 27 07:35:35 2019 Return-Path: <0100016d7325f06e-00613ab7-413c-4d97-972c-858cf4886b65-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55AEC12010C for ; Fri, 27 Sep 2019 07:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 TEHVwfHBv1QD for ; Fri, 27 Sep 2019 07:35:31 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2D2E1200C4 for ; Fri, 27 Sep 2019 07:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1569594929; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=h4DuHNIhoa5iuEySIqjsSfpSyxmDHw5B8z67w/cv+PI=; b=Qq9xgIlI72dzL0Fn5ZCQxMgfnQDxi5tSeUQL7uSLORLQS9hlyli3xG4m/30B4x/M I/ukmIwrHeZOT1Vo5vUCit3gBCkamwXC961BCLf+/qhwNamezBVYC0cvR/loEv1NEl6 RrFEjUohGwqZ32AiR15B9TYsIhsbCQjkJHt1clxQ= From: Kent Watsen Message-ID: <0100016d7325f06e-00613ab7-413c-4d97-972c-858cf4886b65-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D543F5E4-CD06-4117-A859-F3E4B994B336" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 27 Sep 2019 14:35:29 +0000 In-Reply-To: Cc: Juergen Schoenwaelder , "netconf@ietf.org" , Rifaat Shekh-Yusef , Wang Haiguang , Frank Xialiang To: "Rob Wilton (rwilton)" References: <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <20190918163657.4pxh5jddxgrir5oh@anna.jacobs.jacobs-university.de> <0100016d455c6145-844c669e-8f31-4203-a827-7368d33cdee4-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.27-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2019 14:35:34 -0000 --Apple-Mail=_D543F5E4-CD06-4117-A859-F3E4B994B336 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [cc-ing my co-authors, as they're beginning to convert crypto-types back = to identities again] Rob et. al., > I tend to agree that sometimes less modules is more. For me, the > problem is likely more that I am not entirely sure what the proper > base types would be, which may depend on what exactly they are used > for. I guess I wait until I see the description text... > =20 > Okay, we'll keep just the one YANG module. > [RW] > Do you mean one module for all the identities of just the base = identities? >=20 Dunno. =20 Identities provide the desirable benefit of hierarchy and extensibility, = but they come with the weight of the module needing to be implemented = (not just imported) in order for the identity to be defined. This is = how YANG works; it would've been better if, e.g., identities could be = defined by "implemented" via YANG-library... The thing with crypto algorithms, the algorithms a server supports is a = matter of importance, e.g., because the algorithm isn't approved for use = on the network. The ability to configure algorithms supported is not = currently present in the ssh-client-server and tls-client-server drafts, = as I was hoping it could be added later as a -bis extension or an = update, but perhaps it should be, in order to drive this problem, to = ensure a proper crypto-types solution. Working within the current YANG construct, one possible solution would = be to define every algorithm identity in its own module, thus enabling = servers maximum flexibility to describe which are supported. The = ostensible negative is that doing so would produce many modules. While = not a computer problem, it could become onerous. Another idea is to not use identities either (in addition to = enumerations), but instead define a data model that preserves the = extensibility of identities without needing to implement modules. For = instance, instead of assuming the "algorithm" field is an 'identityref', = perhaps a "leafref" is used. ietf-crypto-types.yang snippet: // protocol accesible nodes (note: config false) list algorithms { config false; key name; leaf name { type string; description "The name of a collection of algorithms. = Suitable values are defined in the TBD IANA registry..."; } list algorithm { key name; leaf name { type string; description "The name of an algorithm. Suitable values = are defined in the TBD IANA registry..."; } } } =20 grouping public-key { leaf algorithm-type { type leafref { path "/ct:algorithms/ct:name"; require-instance false; } must '../algorithm'; } leaf algorithm { type leafref { path "/ct:algorithms[ct:name =3D = current()/../algorithm-type]/ct:algorithm/ct:name"; require-instance false; } must '../algorithm-type'; } } PROs: - allows a server to advertise (in ) which algorithms it = supports without any need to implement a module, other than = crypto-types. - supports extensibility via IANA registries. Sequence: RFC updates = registry --> server supports --> client configures to use. - "require-instance false" enables YANG-based config validations to = succeed w/o presence config false data. CONs: - only one level of hierarchy (would more every be needed?) - "require-instance false" enables YANG-based config validations to = succeed even when misconfigured (though commit should fail). Thoughts? Kent // contributor --Apple-Mail=_D543F5E4-CD06-4117-A859-F3E4B994B336 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
[cc-ing my co-authors, as they're beginning to convert = crypto-types back to identities again]


Rob et. al.,

I tend to agree that sometimes less modules = is more. For me, the
problem is likely more that I am not entirely sure what the proper
base types would be, which may depend on what exactly they are used
for. I guess I wait until I see the description text...

 

Okay, = we'll keep just the one YANG module.

[RW]

Do you mean one module for all the identities of just the = base identities?



Dunno.   

Identities provide the desirable benefit of = hierarchy and extensibility, but they come with the weight of the module = needing to be implemented (not just imported) in order for the identity = to be defined.  This is how YANG works; it would've been better if, = e.g., identities could be defined by "implemented" via = YANG-library...

The thing with = crypto algorithms, the algorithms a server supports is a matter of = importance, e.g., because the algorithm isn't approved for use on the = network.  The ability to configure algorithms supported is not = currently present in the ssh-client-server and tls-client-server drafts, = as I was hoping it could be added later as a -bis extension or an = update, but perhaps it should be, in order to drive this problem, to = ensure a proper crypto-types solution.

Working within the current YANG construct, one = possible solution would be to define every algorithm identity in its own = module, thus enabling servers maximum flexibility to describe which are = supported.  The ostensible negative is that doing so would produce = many modules.  While not a computer problem, it could become = onerous.

Another idea is to = not use identities either (in addition to enumerations), but instead = define a data model that preserves the extensibility of identities = without needing to implement modules.  For instance, instead of = assuming the "algorithm" field is an 'identityref', perhaps a "leafref" = is used.


ietf-crypto-types.yang snippet:

// protocol accesible nodes =  (note: config false)
list algorithms {
  = config false;
  key name;
  = leaf name {
    type = string;
    description "The = name of a collection of algorithms.  Suitable values are defined in = the TBD IANA registry...";
  }
  = list algorithm {
    key = name;
=     leaf name {
      type = string;
      description = "The name of an algorithm.   Suitable values are defined in = the TBD IANA registry...";
    }
  = }
= }    

grouping = public-key {
          leaf = algorithm-type {
  =   type leafref {
  =     path "/ct:algorithms/ct:name";
  =     require-instance false;
  =   }
  =   must '../algorithm';
      =     }
  leaf algorithm = {
=       type leafref {
  =       path "/ct:algorithms[ct:name =3D = current()/../algorithm-type]/ct:algorithm/ct:name";
  =       require-instance false;
  =     }
  =   must '../algorithm-type';
  = }
= }


PROs:
  - allows a server to = advertise (in <operational>) which algorithms it supports without = any need to implement a module, other than = crypto-types.
  - supports extensibility via IANA = registries.  Sequence:  RFC updates registry --> server = supports --> client configures to use.
  - = "require-instance false" enables YANG-based config validations to = succeed w/o presence config false data.

CONs:
  - only one level of = hierarchy (would more every be needed?)
  - = "require-instance false" enables YANG-based config validations to = succeed even when misconfigured (though commit should = fail).


Thoughts?

Kent = // contributor






= --Apple-Mail=_D543F5E4-CD06-4117-A859-F3E4B994B336-- From nobody Fri Sep 27 07:45:02 2019 Return-Path: <0100016d732e9ea8-d24bf4bc-503b-4487-819e-bb2b9ac20661-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89BD312011B for ; Fri, 27 Sep 2019 07:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 9MJ40CQDlwfC for ; Fri, 27 Sep 2019 07:44:59 -0700 (PDT) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A06712010C for ; Fri, 27 Sep 2019 07:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1569595498; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=wfl34TWkKmJYYHpjbP74HG4gMZ4iFEG9RHaLLEPM5+g=; b=a4LllpP2czu0IAUEM/xhgbEeTH3Cq1JKSJlwfGu/MIH3mQjSZz+N1P+6bJNYsFsu 5EfS0Bw5JhVKDq62LwHjMErAOnKLBzvGNeB1dauo++KVB851uFXnh2BySeOJqUO8g3w 5dcMnFRN/8YpqIINQN5HmZ2gE3Xpm6IzWk58xiRQ= From: Kent Watsen Message-ID: <0100016d732e9ea8-d24bf4bc-503b-4487-819e-bb2b9ac20661-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5871CA03-ECE1-4BB0-90FF-C6A532E5AF7A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 27 Sep 2019 14:44:58 +0000 In-Reply-To: <0100016d7325f06e-00613ab7-413c-4d97-972c-858cf4886b65-000000@email.amazonses.com> Cc: Wang Haiguang , Frank Xialiang To: "netconf@ietf.org" , Rifaat Shekh-Yusef , "Salz, Rich" References: <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <20190918163657.4pxh5jddxgrir5oh@anna.jacobs.jacobs-university.de> <0100016d455c6145-844c669e-8f31-4203-a827-7368d33cdee4-000000@email.amazonses.com> <0100016d7325f06e-00613ab7-413c-4d97-972c-858cf4886b65-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.27-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2019 14:45:02 -0000 --Apple-Mail=_5871CA03-ECE1-4BB0-90FF-C6A532E5AF7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Here is the COSE registry that Henk suggested us looking at in Montreal: https://www.iana.org/assignments/cose/cose.xhtml = It seems more a reference to how the issue has been approached before, = then something that crypto-types would consume normatively, but perhaps = others feel differently? Kent // contributor --Apple-Mail=_5871CA03-ECE1-4BB0-90FF-C6A532E5AF7A Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

Here is the COSE registry that Henk suggested us looking at in Montreal:


It seems more a reference to how the issue has been approached before, then something that crypto-types would consume normatively, but perhaps others feel differently?

Kent // contributor


--Apple-Mail=_5871CA03-ECE1-4BB0-90FF-C6A532E5AF7A-- From nobody Fri Sep 27 08:09:09 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710FE12086D for ; Fri, 27 Sep 2019 08:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 F6OBqWEAQFq8 for ; Fri, 27 Sep 2019 08:09:04 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id AEDFC12086E for ; Fri, 27 Sep 2019 08:09:04 -0700 (PDT) Received: from localhost (h-46-233.A165.priv.bahnhof.se [46.59.46.233]) by mail.tail-f.com (Postfix) with ESMTPSA id 458D21AE0115; Fri, 27 Sep 2019 17:09:02 +0200 (CEST) Date: Fri, 27 Sep 2019 17:09:02 +0200 (CEST) Message-Id: <20190927.170902.142773301948727896.mbj@tail-f.com> To: kent+ietf@watsen.net Cc: rwilton@cisco.com, wang.haiguang.shieldlab@huawei.com, netconf@ietf.org, rifaat.ietf@gmail.com From: Martin Bjorklund In-Reply-To: <0100016d7325f06e-00613ab7-413c-4d97-972c-858cf4886b65-000000@email.amazonses.com> References: <0100016d455c6145-844c669e-8f31-4203-a827-7368d33cdee4-000000@email.amazonses.com> <0100016d7325f06e-00613ab7-413c-4d97-972c-858cf4886b65-000000@email.amazonses.com> X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2019 15:09:08 -0000 Hi, Kent Watsen wrote: > [cc-ing my co-authors, as they're beginning to convert crypto-types > back to identities again] > > > Rob et. al., > > > I tend to agree that sometimes less modules is more. For me, the > > problem is likely more that I am not entirely sure what the proper > > base types would be, which may depend on what exactly they are used > > for. I guess I wait until I see the description text... > > > > Okay, we'll keep just the one YANG module. > > [RW] > > Do you mean one module for all the identities of just the base > > identities? > > > > Dunno. > > Identities provide the desirable benefit of hierarchy and > extensibility, but they come with the weight of the module needing to > be implemented (not just imported) in order for the identity to be > defined. This is how YANG works; it would've been better if, e.g., > identities could be defined by "implemented" via YANG-library... Yes, but it only matters if the server implements some data node of type identityref with the base that these identities are derived from. While I agree that it would be good to find a solution to the "advertise identities supported"-problem, I don't think it is importang enough for us to find some clever little workaround... So I think a single module wih the identities will work. Or perhaps one for tls and one for ssh. > The thing with crypto algorithms, the algorithms a server supports is > a matter of importance, e.g., because the algorithm isn't approved for > use on the network. The ability to configure algorithms supported is > not currently present in the ssh-client-server and tls-client-server > drafts, as I was hoping it could be added later as a -bis extension or > an update, but perhaps it should be, in order to drive this problem, > to ensure a proper crypto-types solution. > > Working within the current YANG construct, one possible solution would > be to define every algorithm identity in its own module, thus enabling > servers maximum flexibility to describe which are supported. The > ostensible negative is that doing so would produce many modules. > While not a computer problem, it could become onerous. > > Another idea is to not use identities either (in addition to > enumerations), but instead define a data model that preserves the > extensibility of identities without needing to implement modules. For > instance, instead of assuming the "algorithm" field is an > 'identityref', perhaps a "leafref" is used. > > > ietf-crypto-types.yang snippet: > > // protocol accesible nodes (note: config false) > list algorithms { > config false; > key name; > leaf name { > type string; > description "The name of a collection of algorithms. Suitable > values are defined in the TBD IANA registry..."; > } > list algorithm { > key name; > leaf name { > type string; > description "The name of an algorithm. Suitable values are > defined in the TBD IANA registry..."; > } > } > } > > grouping public-key { > leaf algorithm-type { > type leafref { > path "/ct:algorithms/ct:name"; > require-instance false; > } > must '../algorithm'; > } > leaf algorithm { > type leafref { > path "/ct:algorithms[ct:name = > current()/../algorithm-type]/ct:algorithm/ct:name"; > require-instance false; > } > must '../algorithm-type'; > } > } > > > PROs: > - allows a server to advertise (in ) which algorithms it > supports without any need to implement a module, other than > crypto-types. > - supports extensibility via IANA registries. Sequence: RFC updates > registry --> server supports --> client configures to use. > - "require-instance false" enables YANG-based config validations to > succeed w/o presence config false data. > > CONs: > - only one level of hierarchy (would more every be needed?) > - "require-instance false" enables YANG-based config validations to > succeed even when misconfigured (though commit should fail). The last CON here is essentially the same as you get with identities. I think we should stick to identities, and describe that it is ok for a server to reject config for an identity representing an algorithm that the server doesn't implement (even though it "supports" (understands) the identity itself). /martin From nobody Fri Sep 27 08:54:07 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4DC8120933 for ; Fri, 27 Sep 2019 08:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=BZ5hJwv2; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=JJtqKCKq 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 boRlzuTbbJHU for ; Fri, 27 Sep 2019 08:53:58 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7BCA120956 for ; Fri, 27 Sep 2019 08:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6330; q=dns/txt; s=iport; t=1569599637; x=1570809237; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+0FNnJAd/7Jc4Yq7U4GziFa1d8H085ajH7Ghz09Zf6Q=; b=BZ5hJwv21HX2uYJZtyZ8Uy9WY3uRzy1fnZHcmPIvK3MMFqN0+MpQkgWQ D+uKG8tphh7zsGDUmtmIRf8aDAsz3+glYT2+Fso3IGhVV7p6GKQy5KLto xTHeqya4/SbvwIs5CkCtr+9VGK5JtO6YldntLCDgz4wgiCUtO5ZjqWnSR 0=; IronPort-PHdr: =?us-ascii?q?9a23=3ApPpxqh0c5bhhnYYSsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKHt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQE1L6KOLtaQQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuAAAdL45d/4YNJK1dCRoBAQEBAQI?= =?us-ascii?q?BAQEBDAIBAQEBgWeBS1ADgUMgBAsqh2kDilaCXIlnjg+CUgNUCQEBAQwBAS0?= =?us-ascii?q?CAQGEQAKDNyM4EwIDCQEBBAEBAQIBBQRthS0MhUsBAQEDARIVEwYBATcBBAc?= =?us-ascii?q?EAgEIDgMEAQEBHhAhER0IAgQBDQUIEweEawMODwECo0gCgTiIYYF0M4J9AQE?= =?us-ascii?q?FhRQNC4IXCYE0ikuBQxiBQD+BEUaBTn4+ghqCABQYgzuCJpUulyxBCoIijBm?= =?us-ascii?q?EcIQdgjeWfY4hgT2IZI59AgQCBAUCDgEBBYFpIYFYcBU7gmxQEBSBToNyilN?= =?us-ascii?q?0AYEoi0srgicBAQ?= X-IronPort-AV: E=Sophos;i="5.64,556,1559520000"; d="scan'208";a="635182962" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Sep 2019 15:53:56 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x8RFruTM024459 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 27 Sep 2019 15:53:56 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 27 Sep 2019 10:53:56 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 27 Sep 2019 11:53:52 -0400 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 27 Sep 2019 10:53:52 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XKa+7joeWnqHeTl11s/1TlQvFa4QEex+5Rqvuqf3l5NNtsIsVarKLgFyIqmHGFanUIz+tq2hAv8v08XK7IbvCu4lnHi2POJM1rW9Yvld0Rjilbd54GnbwTm66UC4QRCIqxTswFN16Sk/nL5bAHjwvmmSOLkil7aLXJmr0mk77z+908yOxHUSATEtN4Y9x41u5ccJIWKHr5GdA9TToD1sCfXtYNFyqz0wygWP8B8j7aKi5j575HjSP1mQAm2h92RPmydr9KRYC0xzkHsNWDulVWV0eNoTZ7C8ckDCcm4a4WKMbrgqAcXYk1yZjH91fkZluxCdHrZKmqvHD53I75L/zA== 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=en/dPDK/3nAC3fMT4ZjjdrFCuWwxCwvG1GjHd6Eelzc=; b=IBlFHpJxxd7N+zfauOQrwIFRAFXCZSVqY3AEs1VXhmAxKIgJ2+aAAuulDnz6lSW9mcvkwdlzooOOMik8S9OBn5bN7lqDkwB/wHIZMbQlt/GDPPw3ozgh8qW4N11VNEGdw40cRbpHs8a/irKeVY1DUxQpduB/yX0gMtVmqYT9YWdWKP0sIboo1Qu5Fu47+QV3AwhP0QUctTSX7bPvYHBS3XO6LMgsbl7xL0dud1+6cF3SIUiZtkjujLZPm4si/qLo0Z8fVKuEhF8cCP55aL5JMzcvnSPtQPmQZvKk6dncSA/EPHPNo4s7PJvUXF63/lluRmScqUJ3rcns86hJwWiotA== 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=en/dPDK/3nAC3fMT4ZjjdrFCuWwxCwvG1GjHd6Eelzc=; b=JJtqKCKqXYoNTB38V4z9EjLu/to2X6Twd0RLDupwiei3D0105xpYCGkA7Q50Fm5vBwmjNC6XIlZzQNzbjluHNwApaKbpNcRo5tdfOGT2SXqzzoQdO4rdMPVdnkLw7at7oXDCiOSvHpvfVVjAHUj4vvO1SQLiWpoqbC/DcuShbDo= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3807.namprd11.prod.outlook.com (20.178.252.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.17; Fri, 27 Sep 2019 15:53:51 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::cca:41bd:b0bb:c549]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::cca:41bd:b0bb:c549%2]) with mapi id 15.20.2305.017; Fri, 27 Sep 2019 15:53:51 +0000 From: "Rob Wilton (rwilton)" To: Martin Bjorklund , "kent+ietf@watsen.net" CC: "wang.haiguang.shieldlab@huawei.com" , "netconf@ietf.org" , "rifaat.ietf@gmail.com" Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxVu0aQE+n/K0iPwVgOy8FH/KcpQIdQgAVLFQCAARKfAIAATvkAgAABvxCAAC5vAIAAAggggAADhQCAAQHLcIAARlAAgAAAT1CAABr3gIAADR/AgAAZbYCAAAnmgIABJX6ggAzTpYCAAAlgAIAACfMg Date: Fri, 27 Sep 2019 15:53:51 +0000 Message-ID: References: <0100016d455c6145-844c669e-8f31-4203-a827-7368d33cdee4-000000@email.amazonses.com> <0100016d7325f06e-00613ab7-413c-4d97-972c-858cf4886b65-000000@email.amazonses.com> <20190927.170902.142773301948727896.mbj@tail-f.com> In-Reply-To: <20190927.170902.142773301948727896.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [2001:420:c0c0:1005::bf] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: efac8c2c-75da-4e0d-b68a-08d74362e461 x-ms-traffictypediagnostic: MN2PR11MB3807: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0173C6D4D5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(136003)(366004)(346002)(396003)(13464003)(51444003)(189003)(199004)(6436002)(9686003)(55016002)(6116002)(5660300002)(6246003)(229853002)(110136005)(81166006)(14454004)(8936002)(316002)(54906003)(81156014)(4326008)(33656002)(14444005)(52536014)(256004)(478600001)(25786009)(446003)(11346002)(2906002)(486006)(476003)(186003)(102836004)(8676002)(66476007)(46003)(53546011)(74316002)(305945005)(6506007)(7736002)(64756008)(66946007)(99286004)(76176011)(66446008)(86362001)(7696005)(71200400001)(71190400001)(76116006)(66556008); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3807; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: muXujghg8PDgmfGiDjBuOuYyF+LyyGSciD7vRS1G+xHbEmIcmaT6p9CZ1yACfsKdlQPXGzYnCoLgX2su7EanbEmphysm8Y4MZbxkrQucRPic5AUyT18EBS4m0+BcZAGAB03E6QBp7rzbXia8lbI4Az0Pxl6Jd+HFuCiiB+vbstO9vRCWi4e8dRbBdmpXbfqaJF28s0+HCaSQH1lgcC9II3g7duBvPzz4CJCVbuWvZJAVTWtuIwzYLcrFgfSLKX2T0PEakTeeQswNUiNmSsn/Y4emaIEDK4K1ukqfGsbtp/rTJVGWNxMIiFyxQuw9dW2PP33hAeTDf8KIVNxFyokAJeaDWVvFt6UXmUSj7dukpC0i/5UtvRY6v+tYcl6f6AX4NtbFUUUYXI4pLpDTWGnrwf4n6AJaDNziHfT6lZgaZR0= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: efac8c2c-75da-4e0d-b68a-08d74362e461 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2019 15:53:51.2590 (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: TjVkvhfw1L8BFGWEd3+3KSjE1dybXrIGeYgWGxqCUBOdjw5veZ/1/o4J3aUczAkUIQcwDcsjL3PREwAVJUtBlg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3807 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.25, xch-rcd-015.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2019 15:54:06 -0000 I basically agree with what Martin is saying. Either one YANG module containing all of the crypto identities, or a few YA= NG modules as previously suggested. If advertising the specific identities is important, then a per identity if= -feature could be used, although I'm not entirely sure that one feature per= identity is really a great option either, but I think that this would be b= etter than one per module. Or, we could do an augmentation to YANG library with a leaf-list of the cry= pto identities that are supported by the server. This is sort of equivalen= t to a feature per identity solution without polluting the feature list wit= h lots of features. Something along these lines could even be extended if = it is likely that a given identity might only be supported by some of the p= rotocols. E.g. a separate list for NETCONF supported crypto identities vs = RESTCONF supported crypto identities, etc. But I also think that this is just another instance of the generic capabili= ties issue, and really it would be good to a have a solution where the capa= bilities are available offline as well as from the device. Thanks, Rob > -----Original Message----- > From: Martin Bjorklund > Sent: 27 September 2019 16:09 > To: kent+ietf@watsen.net > Cc: Rob Wilton (rwilton) ; > wang.haiguang.shieldlab@huawei.com; netconf@ietf.org; > rifaat.ietf@gmail.com > Subject: Re: [netconf] crypto-types fallback strategy >=20 > Hi, >=20 > Kent Watsen wrote: > > [cc-ing my co-authors, as they're beginning to convert crypto-types > > back to identities again] > > > > > > Rob et. al., > > > > > I tend to agree that sometimes less modules is more. For me, the > > > problem is likely more that I am not entirely sure what the proper > > > base types would be, which may depend on what exactly they are used > > > for. I guess I wait until I see the description text... > > > > > > Okay, we'll keep just the one YANG module. > > > [RW] > > > Do you mean one module for all the identities of just the base > > > identities? > > > > > > > Dunno. > > > > Identities provide the desirable benefit of hierarchy and > > extensibility, but they come with the weight of the module needing to > > be implemented (not just imported) in order for the identity to be > > defined. This is how YANG works; it would've been better if, e.g., > > identities could be defined by "implemented" via YANG-library... >=20 > Yes, but it only matters if the server implements some data node of type > identityref with the base that these identities are derived from. >=20 > While I agree that it would be good to find a solution to the "advertise > identities supported"-problem, I don't think it is importang enough for u= s > to find some clever little workaround... >=20 > So I think a single module wih the identities will work. Or perhaps one > for tls and one for ssh. >=20 > > The thing with crypto algorithms, the algorithms a server supports is > > a matter of importance, e.g., because the algorithm isn't approved for > > use on the network. The ability to configure algorithms supported is > > not currently present in the ssh-client-server and tls-client-server > > drafts, as I was hoping it could be added later as a -bis extension or > > an update, but perhaps it should be, in order to drive this problem, > > to ensure a proper crypto-types solution. > > > > Working within the current YANG construct, one possible solution would > > be to define every algorithm identity in its own module, thus enabling > > servers maximum flexibility to describe which are supported. The > > ostensible negative is that doing so would produce many modules. > > While not a computer problem, it could become onerous. > > > > Another idea is to not use identities either (in addition to > > enumerations), but instead define a data model that preserves the > > extensibility of identities without needing to implement modules. For > > instance, instead of assuming the "algorithm" field is an > > 'identityref', perhaps a "leafref" is used. > > > > > > ietf-crypto-types.yang snippet: > > > > // protocol accesible nodes (note: config false) > > list algorithms { > > config false; > > key name; > > leaf name { > > type string; > > description "The name of a collection of algorithms. Suitable > > values are defined in the TBD IANA registry..."; > > } > > list algorithm { > > key name; > > leaf name { > > type string; > > description "The name of an algorithm. Suitable values are > > defined in the TBD IANA registry..."; > > } > > } > > } > > > > grouping public-key { > > leaf algorithm-type { > > type leafref { > > path "/ct:algorithms/ct:name"; > > require-instance false; > > } > > must '../algorithm'; > > } > > leaf algorithm { > > type leafref { > > path "/ct:algorithms[ct:name =3D > > current()/../algorithm-type]/ct:algorithm/ct:name"; > > require-instance false; > > } > > must '../algorithm-type'; > > } > > } > > > > > > PROs: > > - allows a server to advertise (in ) which algorithms it > > supports without any need to implement a module, other than > > crypto-types. > > - supports extensibility via IANA registries. Sequence: RFC updates > > registry --> server supports --> client configures to use. > > - "require-instance false" enables YANG-based config validations to > > succeed w/o presence config false data. > > > > CONs: > > - only one level of hierarchy (would more every be needed?) > > - "require-instance false" enables YANG-based config validations to > > succeed even when misconfigured (though commit should fail). >=20 > The last CON here is essentially the same as you get with identities. > I think we should stick to identities, and describe that it is ok for a > server to reject config for an identity representing an algorithm that th= e > server doesn't implement (even though it "supports" > (understands) the identity itself). >=20 >=20 > /martin From nobody Fri Sep 27 09:35:39 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9362312098D for ; Fri, 27 Sep 2019 09:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 16UMELITRxAn for ; Fri, 27 Sep 2019 09:35:36 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 0E752120979 for ; Fri, 27 Sep 2019 09:35:35 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x8RGYJ2S026824; Fri, 27 Sep 2019 17:35:28 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=MKhxZPbtpao1YWhsFWypXnnA9hzz1Lf8+JO2cc6JEU8=; b=D57ejv5VRIF9iDBH1V7YIJBq9M904qWjVNyHzFe/AZ8E000n/oLNWBkgd8HN5Vm8ZuI/ W0q8lN/10skLDsCXnec7GJAYFhDuHjqYVm+j+5eYT2UtKg/k/8RdwhLfZtvQsK0bqBr+ WCEjuVTfgV4ZKFng9WLGPV9GJHP7GzIxFf55QMtmw+285uT07yf7zQyTZELJqNRfU8/P UhctQVX4eP3F2T7n4Wpq1GobSS4d59eh6+qTzhPXInEYdE9LkIXBjLXX8Q+SL5lBygxQ OLQMmwrBtsO1RGHGpbXsLzVbqNuO9sVW87pyiDRVGJJqVJVXbYZH4gpmJKX6J0n5vRJU Zw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2v73qamqry-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 Sep 2019 17:35:28 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x8RGXSjJ025729; Fri, 27 Sep 2019 12:35:26 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2v73vq578f-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 27 Sep 2019 12:35:26 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 27 Sep 2019 12:35:25 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Fri, 27 Sep 2019 12:35:25 -0400 From: "Salz, Rich" To: "Rob Wilton (rwilton)" , Martin Bjorklund , "kent+ietf@watsen.net" CC: "wang.haiguang.shieldlab@huawei.com" , "netconf@ietf.org" , "rifaat.ietf@gmail.com" Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVaNxGVhFlbERW30moo9Q8WhnpJqcpkUCAgAU9agCAASLxgP//+5oAgABHL4D//+j+AIAARomA//+/BAAAKuwGgP//8LyAgABEJYCAABougIAAFdoAgAAQsoCAAAnmgIABJdcAgAzTTICAAAlgAIAADIWA///IjgA= Date: Fri, 27 Sep 2019 16:35:24 +0000 Message-ID: <762B873F-B44E-4086-9994-E58B66649BCE@akamai.com> References: <0100016d455c6145-844c669e-8f31-4203-a827-7368d33cdee4-000000@email.amazonses.com> <0100016d7325f06e-00613ab7-413c-4d97-972c-858cf4886b65-000000@email.amazonses.com> <20190927.170902.142773301948727896.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.26] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-27_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=775 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909270145 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-09-27_08:2019-09-25,2019-09-27 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0 clxscore=1011 spamscore=0 lowpriorityscore=0 suspectscore=0 malwarescore=0 mlxscore=0 priorityscore=1501 impostorscore=0 mlxlogscore=754 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909270145 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2019 16:35:38 -0000 PiAgICBFaXRoZXIgb25lIFlBTkcgbW9kdWxlIGNvbnRhaW5pbmcgYWxsIG9mIHRoZSBjcnlwdG8g aWRlbnRpdGllcw0KDQpJIGRpc2xpa2UgdGhpcyBhcHByb2FjaCBmb3IgYSBjb3VwbGUgb2YgcmVh c29uczoNCgktIEl0IG1pZ2h0IGJlIGhhcmQgdG8gIGdldCBnb29kIHNlY3VyaXR5IHJldmlld3Mg b2YgYW4gb21uaWJ1cyBkb2N1bWVudCBhcyBvcHBvc2VkIHRvIHNob3J0IGRvY3MgdGhhdCBuZWVk IGRpZmZlcmVudCBhdWRpZW5jZXMNCgktIE5vdCBhbGwgY3J5cHRvIG9iamVjdHMgd2lsbCBhZHZh bmNlLCBvciBiZSBhdHRhY2tlZCwgaW4gbG9ja3N0ZXA7IGJlaW5nIGFibGUgdG8gcmV2aXNlIHRo ZSBvbmUgc2hvcnQgWUFORyBkb2N1bWVudCB3aWxsIG1ha2UgdXBkYXRlcyBlYXNpZXIuDQoNCiAN Cg0K From nobody Fri Sep 27 10:46:32 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B7912098F for ; Fri, 27 Sep 2019 10:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=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=jacobsuniversity.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 2Yi_0MYvwLpi for ; Fri, 27 Sep 2019 10:46:28 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on0617.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::617]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 162721208BC for ; Fri, 27 Sep 2019 10:46:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j74/VyEWdqf2bYteTb/JGV8bPMlzXutNv5XxUX3qtHlEhKCIXsw1MUA8z802ouiRUdQZyNBHh0OyswJHhoNcPXYQnxwKA1BcpcP5hv8DQialif/i37LEnxjBaHtBZnhA6V5btkQ6ryz5rn7MKONFYmCwLhOGYw7lJGq/D5aJQ4NJ/QA5rtVeLK0XtYTQiQMPvXHWqQhn8y80wmBlYjNMQbRJLzOK9P9PZ+eCqKsH6nRiI9T/lnBWLh5zZ4qlSeMoXzhYpZHZAW3I04NbqQ2YF2aA+ssvKwaVxezw1Rk1EO6rwJOSTXM0sQ6rqTxjkF1x3enhH5lGhaU2CX7sYpX+GA== 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=eILrnrrWBHIUXOA/CudrCurszP0UoRkjNEScv6U/oJI=; b=cem6PERCx4BHbBdTEvvGH9ilqmUBYz24S/kuWievqwVCXIM/3LbyxtvGqncf9FXEcc2yaGJhDmBVATJQeb3+Xdi3FcV5+qnh+bzw4C/xnl0VpsWUmn6+0xwzVTCbiRL2zKJlXy6e21ViLcYSF+4QWp42keuwrBLfpdpe1g0K0HF6SgDdR3CqVCsYSFNc3wAz+Kkus0QbFswl7WsqN3jsaNhA+BKMHDkPn+RMwTKOUwlm8aaPHUnwzIhjY885jwmMTgLnPHNfZrEe7hODjSdBSCkOr7NSUP7exAzZJsXDApTWn7RdVrP6+60XEwvXQMQ+7m+qTYTdKq3HhYK49fBE/A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eILrnrrWBHIUXOA/CudrCurszP0UoRkjNEScv6U/oJI=; b=Xp5Y5yUObTnqUd+97tUjls2K0isHr7//sUBEhQaPfbUq9TiJ6xN/M2R0WBb4+6OEVY4LEtTjtVD89JljbQZ6hHhbIxQXiWrwp1Pb6WotBA7DDbzAnh+H2T0xLpajBLl2Mn63KRdTP6g1gnXTYgkL6h6U+bJfrvPwKAEZ2C6kOGI= Received: from VI1P190MB0686.EURP190.PROD.OUTLOOK.COM (10.186.159.71) by VI1P190MB0448.EURP190.PROD.OUTLOOK.COM (10.165.198.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.20; Fri, 27 Sep 2019 17:46:24 +0000 Received: from VI1P190MB0686.EURP190.PROD.OUTLOOK.COM ([fe80::e061:7f73:a47f:2ad4]) by VI1P190MB0686.EURP190.PROD.OUTLOOK.COM ([fe80::e061:7f73:a47f:2ad4%2]) with mapi id 15.20.2305.017; Fri, 27 Sep 2019 17:46:24 +0000 From: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= To: "Rob Wilton (rwilton)" CC: Martin Bjorklund , "kent+ietf@watsen.net" , "wang.haiguang.shieldlab@huawei.com" , "netconf@ietf.org" , "rifaat.ietf@gmail.com" Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVbjbxVhFlbERW30moo9Q8WhnpJqcxoiSAgA4DFOiAAAlXAIAADIaAgAAfcYA= Date: Fri, 27 Sep 2019 17:46:24 +0000 Message-ID: <20190927174623.jhvpudof6yfs2m4k@anna.jacobs.jacobs-university.de> References: <0100016d455c6145-844c669e-8f31-4203-a827-7368d33cdee4-000000@email.amazonses.com> <0100016d7325f06e-00613ab7-413c-4d97-972c-858cf4886b65-000000@email.amazonses.com> <20190927.170902.142773301948727896.mbj@tail-f.com> In-Reply-To: Reply-To: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: PR0P264CA0068.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1d::32) To VI1P190MB0686.EURP190.PROD.OUTLOOK.COM (2603:10a6:800:12e::7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:638:709:5::7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 69febf2c-cdaf-49b6-9b55-08d743729d89 x-ms-traffictypediagnostic: VI1P190MB0448: x-ms-exchange-purlcount: 1 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0173C6D4D5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(346002)(39850400004)(136003)(396003)(51444003)(189003)(199004)(46003)(25786009)(7736002)(5660300002)(14444005)(8936002)(6916009)(6506007)(478600001)(305945005)(8676002)(43066004)(52116002)(4744005)(81166006)(81156014)(54906003)(99286004)(71200400001)(71190400001)(14454004)(76176011)(45776006)(64756008)(66556008)(66476007)(66446008)(1076003)(786003)(66946007)(6306002)(186003)(386003)(6512007)(6116002)(316002)(86362001)(6436002)(11346002)(229853002)(6246003)(446003)(476003)(3450700001)(256004)(4326008)(102836004)(2906002)(486006)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P190MB0448; H:VI1P190MB0686.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3KRtu2QNMuJDcJ6x0bHdchG8R+eaQzlElfziLL1QUc7SLiWgOSy/i1/zH0YF3PUXPc/3vjXdP2XCjslpz/7i+AHop4VWozWsNjLOnCZ4XiY2s76sKfehybXr33EcMv1jC6+vSQN2n7LiN39xaY8OIdCgvwjEt8qbbPc8gjq3tlaizmjfga9FeTAdr3kXZd2RO+ZHR3veHciG7q2PYv4kkmsjC4Ep1ttR9m5pw39yVUwnJl6MpnmbG+RZWTqyAiJEvBbkURbfQeJp+1qGBszDEYAJ9sXyfmIe5nJn8jXURAs20eJN/FqgvnwUW67ZJDo5zT7WYOWlLmMbp4DGoJIPqAyId4SwkIcZEEwQ5f+mPRnuQP9ltusdSeGbuFpp93KWMw9K6cxcs3OrxwklA16eImwQt90m9GplRtUrKh0hYeUPE77v5QZbPK7WBxmSQEM0+GoYQ8+iCoUFGkRyGK0FzQ== Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2F13AD93DC5450499D273494EE22D6D4@EURP190.PROD.OUTLOOK.COM> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 69febf2c-cdaf-49b6-9b55-08d743729d89 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2019 17:46:24.6359 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tV+elEsDA/GdQL9QqNHCU3Hmw2vIt7ohNp3B7xqbwwMcWsNqW8fxYcGEemsrXsWJW75KZyCva2XCltLlc4HnaRkSQJyP9bakeaowdFXmTZE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P190MB0448 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2019 17:46:31 -0000 On Fri, Sep 27, 2019 at 03:53:51PM +0000, Rob Wilton (rwilton) wrote: > I basically agree with what Martin is saying. So do I. > Either one YANG module containing all of the crypto identities, or a few = YANG modules as previously suggested. It may make sense to split by security protocol. > If advertising the specific identities is important, then a per identity = if-feature could be used, although I'm not entirely sure that one feature p= er identity is really a great option either, but I think that this would be= better than one per module. Why not instead have a config false list of algorithms supported? Once we have solved this problem generically, this list may get deprecated. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Sep 27 12:57:09 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA99A120A8E for ; Fri, 27 Sep 2019 12:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=YlWjbyY1; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=WvdgS7C3 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 lfS3r-H4pIC3 for ; Fri, 27 Sep 2019 12:56:58 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61421120A8C for ; Fri, 27 Sep 2019 12:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27459; q=dns/txt; s=iport; t=1569614218; x=1570823818; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WXWundfsWlWkauPRGzxyQz9xrREGHVtUPwyucvhPCmw=; b=YlWjbyY14FrnPqF7hkxXSXRcnWn+dulmtf0NfCCxKZb/kMiAYHi89Q6L AYikj4NLABCFrLyMPwIAlcUvUzCRsmcDIOIueSViNeVry3rDUX7AAYY4h pCfQZ8YrAlzLyPlrcmTG1s3pWR6Zqnz8/0i0mZokiYK+OwwllcqRZYqaj E=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3AzdCWBBVMoRahWzMXG2j0/wPK7b/V8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSANWJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtank3AsNDSHdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAACXaI5d/5tdJa1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQwBAQEBAQGBZ4EcL1ADbVYgBAsqCoQYg0cDileCXIlnjg+CUgNUAgc?= =?us-ascii?q?BAQEJAwEBJQgCAQGEQAKDNyM4EwIDCQEBBAEBAQIBBQRthS0MhUsBAQEBAxI?= =?us-ascii?q?RChMBATAFAgEPAgEIEQQBAQ4aAwICAh8RFAkIAgQBDQUIBhSDAYEdTQMdAQI?= =?us-ascii?q?MozYCgTiIYXWBMoJ9AQEFgTgCg1gNC4IQBwMGgTSBU4o7GIFAP4ERRoJMPoI?= =?us-ascii?q?aRwEBA4FIGAwfCQICglEygiaNJ4I2nH1BCoIig0GCLoEWigSEHYI3h0yEKok?= =?us-ascii?q?ogV+OIYE9hlqCCoskg1kCBAIEBQIOAQEFgWkhgVhwFYMnUBAUgU4MF4NPhRS?= =?us-ascii?q?FP3SBKYx5AYEiAQE?= X-IronPort-AV: E=Sophos;i="5.64,556,1559520000"; d="p7s'?scan'208,217";a="340473300" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Sep 2019 19:56:57 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x8RJuuZa022623 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 27 Sep 2019 19:56:56 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 27 Sep 2019 14:56:56 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 27 Sep 2019 15:41:54 -0400 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 27 Sep 2019 15:41:53 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fzm0xmB7HGXuvph50BwV+g29SBf+Hv3qxG+hLrlNKwwnV5J1ZT4fx8Rkos/zOYDmG4Xgrffb2qIOwSTEdoOWk+FmrAWp6J9ejWZ8bCf0913Z1FOvpfEhaQITaDuiWxkETTn3lZvTgpQRuEIOzVNWMr8RbOADLi9ikkYnj6b2mTcBCC4kQ94zWMifeyjPE921Wj3Wx+vP6akPn9J+sv5QWaTCj/+9ZUQwztlWm0SRsVrdrDLeeGByzg/PJzhaCncgUVfgNcMSUPjiTGjt2NE3kElY6bAe0I9nYW+5h4opr5aKZlHJinzMwdemxYjn/VS3q5YuDr4biVEH/T/gsbmnaQ== 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=bQhnm16K85p4WdZUFQOwD0jWSkYEvus+LAS4zWQrliY=; b=iHb/LjUv9BQQDNbYNNJakN7C9J0IeLJjBL2HI6XG6P+iIk+Uhd3VH4rmO8vuLM1Y2do4C1XdI8jiK2wm5+KBARkzzYZ8S/gEsFH8n4QsjNqJzEqUSqvttkUzHL/JKhSieJbBg7OYoYlbuDWwPn6Pj6WLrPjqkhpKRd8r0jXWMlihDyL0Rt4+YL2aLmDaS76gELFsZ87zCBdYwVhfcZVPaR0nbBowlEmGKpraDeUdcHhT3az/iA9AUQ5A35glV38K5SfWAKJE9kld5EUku3S+mqDOQnBq5xqbf4gOyXg21CA8kxqe/fW/eJiS8AKUEG47gO0GmgWJA1kw/O782vRFMA== 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=bQhnm16K85p4WdZUFQOwD0jWSkYEvus+LAS4zWQrliY=; b=WvdgS7C3QsEnAY1ihBG2BoDs413l3Yvk2k8WqGMOo70m8o7wOhsvW/ewHoZNUvT0fCRHfVqMrKw/C9RuL0Z49cnO+W2JUU9V+kbUwhIQd1xec0RtRVzEDACaF0FahoXRdYTJdqrDO75yQ4J44DGc7v6V5FDJnMUbFFFbzfOcFyU= Received: from BN7PR11MB2627.namprd11.prod.outlook.com (52.135.255.31) by BN7PR11MB2548.namprd11.prod.outlook.com (52.135.254.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.17; Fri, 27 Sep 2019 19:41:52 +0000 Received: from BN7PR11MB2627.namprd11.prod.outlook.com ([fe80::61c6:4b6d:cf6c:f095]) by BN7PR11MB2627.namprd11.prod.outlook.com ([fe80::61c6:4b6d:cf6c:f095%3]) with mapi id 15.20.2284.028; Fri, 27 Sep 2019 19:41:52 +0000 From: "Eric Voit (evoit)" To: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , "Mahesh Jethanandani" , Alexander Clemm , "Benoit Claise (bclaise)" CC: Netconf Thread-Topic: [netconf] WGLC for draft-ietf-netconf-notification-capabilities Thread-Index: AQHVcwCXe43vmPblgUW74U2qSpt2bac7U+nggAQplACAAGtwIA== Date: Fri, 27 Sep 2019 19:41:52 +0000 Message-ID: References: <4F49DF08-B7FC-4EBD-9D6B-7BC329E50334@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=evoit@cisco.com; x-originating-ip: [173.38.117.65] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4861fb66-5bf6-4a07-e0d6-08d74382beec x-ms-traffictypediagnostic: BN7PR11MB2548: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0173C6D4D5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(376002)(346002)(366004)(39860400002)(189003)(199004)(51914003)(6116002)(7736002)(2906002)(33656002)(6436002)(55016002)(11346002)(6246003)(9686003)(476003)(446003)(478600001)(6506007)(81166006)(81156014)(53546011)(8676002)(102836004)(52536014)(7696005)(99286004)(8936002)(9326002)(99936001)(54896002)(26005)(5660300002)(25786009)(6306002)(236005)(66574012)(229853002)(186003)(71200400001)(15650500001)(76176011)(2420400007)(4326008)(256004)(316002)(71190400001)(606006)(66066001)(14454004)(14444005)(66556008)(7110500001)(86362001)(66446008)(6636002)(64756008)(76116006)(74316002)(110136005)(3846002)(66616009)(66946007)(66476007)(790700001)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2548; H:BN7PR11MB2627.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RnMzK01hdP6H6+3lKcYDbStOIPV8bTwDLwdBM6jloVJHj+Zvh++O10+wkvJ8o1Ce8C+o4R5zOk7sJ/hgWw5Q8V2tV7usLoPKMZd0G92ncAhQY4jo2/Df7FLla6Aao0ya/mwhRnmAnxHsll0g69563s7jtZ0/PFduS8u2sNIHIM6N6Lmlk/4J9ITjZZdSSzT+mdFeQZvBRIIRqGdtx8C9sNdDYQamKaoktHBpN+pDjG1i7qU+Tx/ibLb2JnOehVI2lDu9OGTABXe5p0ETmgMoy0y7BTTa+b5A5nXmmfZMR3HXIjPglPU0s7ndPvTSuFgkncGaHaCLewhqUgZHlzPH+F/NGPnQJqPSRSj6B/BXPO7VtKvnWc9KNQ8LE2xCcvOfAYr5vzFe67Vk5AAV4+2ffqBex3NCTIEVNVaPsI5EATk= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0428_01D5754A.132B1D40" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4861fb66-5bf6-4a07-e0d6-08d74382beec X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2019 19:41:52.3389 (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: eXPe+cg56BWHJ/tDFBL3nZY5O1niwzbUP7BaksVzlZ/DSMUVqHwKc6XR10ije6fZ X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2548 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2019 19:57:07 -0000 ------=_NextPart_000_0428_01D5754A.132B1D40 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0429_01D5754A.132B1D40" ------=_NextPart_001_0429_01D5754A.132B1D40 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Balazs, =20 Some more thoughts in-line. I cut out those I think closed. =20 From: Bal=C3=A1zs Lengyel =20 Sent: Friday, September 27, 2019 8:48 AM To: Eric Voit (evoit) ; Mahesh Jethanandani = ; Alexander Clemm ; Benoit = Claise (bclaise) Cc: Netconf Subject: RE: [netconf] WGLC for = draft-ietf-netconf-notification-capabilities =20 Thanks for the comments. See answers below.=20 I hope the group will be ok with using the term publisher instead of = server. IMHO it is clearer as the client server relationship can be = reversed e.g. for https notification transport. Balazs =20 From: Eric Voit (evoit) >=20 Sent: 2019. szeptember 24., kedd 23:15 To: Mahesh Jethanandani >; Bal=C3=A1zs Lengyel = >; = Alexander Clemm >; Benoit = Claise (bclaise) > Cc: Netconf > Subject: RE: [netconf] WGLC for = draft-ietf-netconf-notification-capabilities =20 Here are some comments... =20 On-change Notification Capability: Is this different from support for = RFC-8641 feature "on-change"? If they are the same, it might be = possible to remove the term. Especially as this term is used = inconsistently. BALAZS: In RFC 8641 on-change is not defined as a capability. It is used = for many more things (e.g. On-change subscription, trigger condition, = type of push updates, a feature.) In this draft the on change capability = is just the servers capability to send on-change notification globally, = for a specific datastore or a specific data node. Description will be = reworded. It will be good to see the reword. I still am not clear how = this different from the RFC-8641 feature "on-change", along with this = feature being associated with specific nodes. =20 =20 =20 Section 3 =20 Paragraph 2, bullet 2: Instead of "amount of notifications the server = can send out", do you mean "the minimum periodicity of updates which a = server can send out for an object" BALAZS: That too, but also the max-objects-per-update. I was told not to = repeat information in the main text and in the YANG module, so I tried = to find a wording that covers both. Also its not always the minimum = times. Some servers support a specific set of times, not a anything = over a minimum. Ok, so this bullet is a bucket of various types of information. = Which is fine with me. =20 =20 Paragraph 2, bullets 3 & 4: I don't think these should be indented as = bullets are they are more about proper behavior of a correctly populated = model. BALAZS: I don=E2=80=99t really understand this comment. Please explain. Looking at the text, bullets 3 is written to say how capabilities = value can be set (i.e., how) rather than that they can be set for = different levels (i.e., what). Getting consistency so that the bullets = are all 'how' or all 'what' items would help readability. =20 =20 =20 Paragraph 3, bullets 2: why isn't SHALL instead MUST? Also, shouldn't = this point out that both NETCONF and RESTCONF MUST be supported if = on-change is advertised, and this draft is supported? BALAZS: As I understand RFC 2119 MUST and SHALL both mean the same, but = I will change to MUST. No I do not want to mandate implementing both = Netconf AND Restconf. IMO a server with just Netconf would work just = fine; or maybe I misunderstand your comment? The second part of my comment was about ensuring that IF this = model was available, and the publisher supports both RFC-8640 & = draft-ietf-netconf-restconf-notif, then this specification MUST be able = to push changes over both NETCONF and RESTCONF. Thinking more, this = is actually a generic question which is likely already answered: how do = you know which models are supported for which transports. As = advertisement is by transport, I withdraw this question. =20 =20 =20 =20 Section 4 =20 I suspect that you will need to do a security analysis per YANG object. = This has been done the other YANG push family. BALAZS: The full module is readOnly and not sensitive or private in any = manner. The security text for the readOnly parts of YangPush is the = exact same text: not very informative, but gives you the illusion of = security awareness. You can ignore my comment. In doing RFC-8639, I needed to put in = read/write analysis for each object. And this did sometime include the = risks of internally setting values which were read-only from the model. = Perhaps this will not be required during later draft reviews in the = publication process. =20 I suspect that manipulating the reporting intervals could have some = security implications. E.g., a hacker could push up the damping period = or periodic interval to a level where the information they are changing = then becomes invisible to a monitoring system. BALAZS: The full YAM is read-only so manipulating the data is not a = concern. Per my previous point, if the IETF process says you don't need to = highlight such possibilities, then I am good. =20 =20 Thanks,=20 Eric=20 =20 =20 From: netconf > On Behalf Of Mahesh Jethanandani Sent: Tuesday, September 24, 2019 1:50 PM To: Netconf > Subject: Re: [netconf] WGLC for = draft-ietf-netconf-notification-capabilities =20 We were supposed to have closed on the WGLC today. However, between the = document becoming a WG item and it going into LC, we have not received = too many comments on the draft. As such, we are extending the LC by = another week. Please review the draft and provide any comments you might = have. =20 Mahesh & Kent (as co-chairs) =20 =20 On Sep 10, 2019, at 3:39 PM, Mahesh Jethanandani = > wrote: =20 Authors have published -04 = version of the draft, which addresses comments they received in = IETF 105. If you provided comments please check to make sure your = comments have been addressed. At this point, the authors believe that = the document is ready for WGLC. =20 This therefore starts a two week LC, ending on September 24th. Please = provide any technical comments you might have on the document. If you = believe the document is not ready for LC, please state your reasons. =20 We will issue a IPR poll separately.=20 =20 Mahesh & Kent (as co-chairs) =20 =20 =20 =20 ------=_NextPart_001_0429_01D5754A.132B1D40 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Balazs,

 

Some more thoughts in-line.=C2=A0=C2=A0 I cut out = those I think closed.

 

From: = Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>
Sent: = Friday, September 27, 2019 8:48 AM
To: Eric Voit (evoit) = <evoit@cisco.com>; Mahesh Jethanandani = <mjethanandani@gmail.com>; Alexander Clemm = <ludwig@clemm.org>; Benoit Claise (bclaise) = <bclaise@cisco.com>
Cc: Netconf = <netconf@ietf.org>
Subject: RE: [netconf] WGLC for = draft-ietf-netconf-notification-capabilities

 

Thanks for = the comments. See answers below. =

I hope the group will be ok with using the term = publisher instead of server. IMHO it is clearer as the client server = relationship can be reversed e.g. for https notification = transport.

Balazs

 

From: Eric Voit (evoit) <evoit@cisco.com>
Sent: = 2019. szeptember 24., kedd 23:15
To: Mahesh Jethanandani = <mjethanandani@gmail.com>; = Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>; Alexander Clemm <ludwig@clemm.org>; Benoit Claise = (bclaise) <bclaise@cisco.com>
Cc:= Netconf <netconf@ietf.org>
Subject:<= /b> RE: [netconf] WGLC for = draft-ietf-netconf-notification-capabilities

 

Here are = some comments...

 

On-change Notification Capability: Is this = different from support for RFC-8641 feature "on-change"?  = If they are the same, it might be possible to remove the term.  = Especially as this term is used inconsistently.

BALAZS: In RFC 8641 = on-change is not defined as a capability. It is used for many more = things (e.g. On-change subscription,  trigger condition, type of = push updates, a feature.) In this draft the on change capability is just = the servers capability to send on-change notification globally, for a = specific datastore or a specific data node. Description will be = reworded.

<Eric> It = will be good to see the reword.=C2=A0=C2=A0 I still am not clear how = this different from the RFC-8641 feature "on-change", along = with this feature being associated with specific nodes.=C2=A0 =

 

 

Section 3

 

Paragraph 2, bullet 2: Instead of =  "amount of notifications the server can send out", do = you mean "the minimum periodicity of updates which a server can = send out for an object"

BALAZS: That too, but also the = max-objects-per-update. I was told not to repeat information in the main = text and in the YANG module, so I tried to find a wording that covers = both. Also  its not always the minimum times. Some servers support =  a specific set of times, not a anything over a = minimum.

<Eric> Ok, = so this bullet is a bucket of various types of information.=C2=A0 Which = is fine with me.

 

 

Paragraph 2, bullets 3 & 4: I don't think these = should be indented as bullets are they are more about proper behavior of = a correctly populated model.

BALAZS: I don=E2=80=99t really understand this = comment.  Please explain.

<Eric> Looking at the text, bullets 3 is = written to say how capabilities value can be set (i.e., how) rather than = that they can be set for different levels (i.e., what).=C2=A0 Getting = consistency so that the bullets are all 'how' or all 'what' items would = help readability. =C2=A0

 

 

Paragraph 3, bullets 2: why isn't SHALL instead = MUST?   Also, shouldn't this point out that both NETCONF and = RESTCONF MUST be supported if on-change is advertised, and this draft is = supported?

BALAZS: As I understand RFC 2119 MUST and SHALL = both mean the same, but I will change to MUST. No I do not want to = mandate implementing both Netconf AND Restconf. IMO a server with just = Netconf would work just fine; or maybe I misunderstand your = comment?

<Eric> The = second part of my comment was about ensuring that IF this model was = available, and the publisher supports both RFC-8640 & = draft-ietf-netconf-restconf-notif, then this specification MUST be able = to push changes over both NETCONF and RESTCONF.=C2=A0=C2=A0=C2=A0 = Thinking more, this is actually a generic question which is likely = already answered: how do you know which models are supported for which = transports.=C2=A0=C2=A0 As advertisement is by transport, I withdraw = this question.=C2=A0

 

 

 

Section 4

 

I = suspect that you will need to do a security analysis per YANG = object.   This has been done the other YANG push = family.

BALAZS: The full module is readOnly and not = sensitive or private in any manner.  The security text for the = readOnly parts of YangPush is the exact same text: not very informative, = but gives you the illusion of security = awareness.

<Eric> You = can ignore my comment.=C2=A0 In doing RFC-8639, I needed to put in = read/write analysis for each object.=C2=A0 And this did sometime include = the risks of internally setting values which were read-only from the = model.=C2=A0 Perhaps this will not be required during later draft = reviews in the publication process.

 

I = suspect that manipulating the reporting intervals could have some = security implications.   E.g., a hacker could push up the = damping period or periodic interval to a level where the information = they are changing then becomes invisible to a monitoring = system.

BALAZS: The full YAM is read-only so = manipulating the data is not a concern.

<Eric> Per my previous point, if the IETF = process says you don't need to highlight such possibilities, then I am = good.

 

</Eric>

 

Thanks,

Eric =

 

 

From: = netconf <netconf-bounces@ietf.org>= On Behalf Of Mahesh Jethanandani
Sent: Tuesday, = September 24, 2019 1:50 PM
To: Netconf <netconf@ietf.org>
Subject:<= /b> Re: [netconf] WGLC for = draft-ietf-netconf-notification-capabilities

 

We = were supposed to have closed on the WGLC today. However, between the = document becoming a WG item and it going into LC, we have not received = too many comments on the draft. As such, we are extending the LC by = another week. Please review the draft and provide any comments you might = have.

 

Mahesh & Kent (as co-chairs)

 

 

On Sep 10, 2019, at 3:39 PM, Mahesh Jethanandani = <mjethanandani@gmail.com> = wrote:

 

Authors have published -04 version of the draft, which addresses comments = they received in IETF 105. If you provided comments please check to make = sure your comments have been addressed. At this point, the authors = believe that the document is ready for WGLC.

 

This therefore starts a two week LC, ending on = September 24th. Please provide any technical comments you might have on = the document. If you believe the document is not ready for LC, please = state your reasons.

 

We will issue a IPR poll = separately. 

 

Mahesh & Kent (as = co-chairs)

 

 

 

 

------=_NextPart_001_0429_01D5754A.132B1D40-- ------=_NextPart_000_0428_01D5754A.132B1D40 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMWTCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBJwwggOEoAMCAQICCgGGHkPWlB04 96IwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTE5MDYxNDEyMTIzNFoXDTIxMDYxMzEyMjIzNFowgZIxGjAYBgNVBAMTEUVyaWMg Vm9pdCAoZXZvaXQpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMw EQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHjAcBgkqhkiG9w0BCQEM D2V2b2l0QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAIAZHOvN3UgE S1WSqNst+IZ44ptBZ+BHmyDmrLdjDiSuB5huzYxbcUFiN8ocvyAUFPS0s495oI/wnNvfUlomi5KO yJMvOdComHEquPtofQIIMn2FhYOlMZEJj4eC1nWI7DpnTChuIVoRj6bTcZNlOjX/Gxk8wcFJh64M mV58sSvHftNDUKDBYOQUmGmCiieGKI+MrIuhpxdNJQuljC18Jj+hq3Y+E1tI9Z0MqdaBEAUF97+v Z/iRZE1YFAOv78XSYFRzb+/g42/GzWBUCKSQDfwACXh89JsSNoXoVvvM3rZvYzEuQhZvTyHqi9pp W+70bkbEF9M7cX1yTPDc1Yr6PfkCAwEAAaOCAVcwggFTMA4GA1UdDwEB/wQEAwIE8DAMBgNVHRMB Af8EAjAAMHoGCCsGAQUFBwEBBG4wbDA8BggrBgEFBQcwAoYwaHR0cDovL3d3dy5jaXNjby5jb20v c2VjdXJpdHkvcGtpL2NlcnRzL2NlY2EuY2VyMCwGCCsGAQUFBzABhiBodHRwOi8vcGtpY3ZzLmNp c2NvLmNvbS9wa2kvb2NzcDAfBgNVHSMEGDAWgBSflTa0jl3VS8MKwacpk0NRBv2JUTA6BgNVHR8E MzAxMC+gLaArhilodHRwOi8vY2lzY29jZXJ0cy5jaXNjby5jb20vZmlsZS9jZWNhLmNybDAaBgNV HREEEzARgQ9ldm9pdEBjaXNjby5jb20wHQYDVR0OBBYEFIDTgXbBj6x3IEXvxtrJTbJFjKDbMB8G A1UdJQQYMBYGCisGAQQBgjcKAwwGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAowdP8izTr +GtcksOcgtT7KFPnW2Pcz7vMei6CMnGC4pAU4LUtHKBHKBJdr05RkV5wSDSeXsCmUQcj7PgeXwzQ KbDA6D3/6gRGBkMLZJQvqRiAXi+1CfXpg7mUr2B7IFC4mnm0V7MpCg8TU3jLKMB4Gidqh4Tmure0 JEOD1AgOsAtxW+x2+hPm+HpGOv/wuxoEXK0uB8snFLRRyTQYGR5AtqLDJGvk6Ref3uHseaZYGD2f 1XK05BfTdsNnjBjPeVI6vmRSdTCLr/kTO2dQG6q+LisAl4rA+4iHEgky3LeWj4T+pLa1g9Gj02qG +gKA5g05T5NUsRlPSx6+YGbSxA+bMYIC8DCCAuwCAQEwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgG A1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwCQYFKw4DAhoFAKCCAYswGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwOTI3MTk0MTQ4WjAjBgkqhkiG 9w0BCQQxFgQUSQu/cwqz5mV780CqGisB6ijuUCwwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQBx/fNxDOywO352xMfS4dJqw8o1sOiyKIULEtSzkvU+DQOOXLlzLac5bUBVyIkFQiYo SFkj0qaQefkp+E8+WwhhAiZImjx87EJRjNmRIMjOtKtdGtrWpcI3JLZEKA7ERX0uHMFMGV0rnu7I EjWBkIp9LOIIWkGUBqqWwChCpOdpLeiQoiniy0w5nvkeK1Xl5S4X51w7rc0btLYEhSb5PLam2SLn /9040AOdWY6byXKbjJfBlSU+V+PxKSYSJcYGSwWzYtlr1uHNxVpJSQw+pCwUa5X2x6VVBvXqQfsH oKK0dUfQJGoONDPuA4MIgGqkK3OxhbUBkbGz5pwbZPXHlcYcAAAAAAAA ------=_NextPart_000_0428_01D5754A.132B1D40-- From nobody Fri Sep 27 17:26:27 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF7112004E for ; Fri, 27 Sep 2019 17:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.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 LkkXlGsTVzpr for ; Fri, 27 Sep 2019 17:26:23 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D58120026 for ; Fri, 27 Sep 2019 17:26:23 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id t14so4302620pgs.3 for ; Fri, 27 Sep 2019 17:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=aNGcyuM1K8zcVqtuQtSwdjNTBhl+noGMPcHgYPgFYSw=; b=uZ325KiurEPHszKZ0ghDc8zIo9dR5Iu+Tk0FU7aux/DVJM6X8fleyQsMLW2aU6s8L6 hczIniRCsAwu/OlSu8qa64f4SIZXXN1QOhQ5ndu+DMakrk8Yhyy76iQ2tqllI/EqkOMH +N7aZnIXbbo/4ZnSW2jZV3WSFlbUFaR899X0DtkncepYjmwGv+rqdg5u6OQgoO5IThgE nAY0/2WbSp9iQpX/KQNCGDavHfRBuTXVhdUAEPnywrn8+tguis9M6mxFVhnnhMDA4IiZ fSnlFbCgk69DpRiHZLqSeWLYRZPQNboI6TTJH4nE9u2w4jPFGa+yO6yPooiJVzk1jGeM Aiyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=aNGcyuM1K8zcVqtuQtSwdjNTBhl+noGMPcHgYPgFYSw=; b=b1C17PU3wtyJ48R4Z3wpexTWruR+YyYfoOuoJPY0b8yy53MfxIC3iPAyPD0Ntl/+aF kDylZh3mpctHdNBRH2xDBzTkkRCPVUuxqoBuYywd9/UdgcgIDEu8lAWkk+gtYp5YB8a6 p8FE++shOtga8uEdhdTUruMpBG4uoLJlukjIPX5ulPLdbPh8cjzThfyvxpcYOkFSYzMO 3xfZAmxI8Agj/biL20x43vl2JoOdQc7EOGqTYB0X5B7zsx3iZCsS0XxiburVKk02XR9a cgLHLEtBN/+6u6R3pa1DajX3QX70aYQCP57KHcvc/QZxGYxpuSLWs6CK5kUMFZ2kTbk3 MJsA== X-Gm-Message-State: APjAAAX87HOfsbk2Y69QQaw+sITRf8G81Qbj6Oee7mmESueFpbRRfayT kYo2ZPcWI2VUNJism69iz60= X-Google-Smtp-Source: APXvYqyPVRdnmaSpBtSWkDlozxqVGto7XJu6wO7cSZMmW5jlQVSWkfWU0j7sXyWItpSe34D+t/hvFg== X-Received: by 2002:a63:83c3:: with SMTP id h186mr12335889pge.317.1569630382872; Fri, 27 Sep 2019 17:26:22 -0700 (PDT) Received: from ?IPv6:2601:647:5600:5020:8966:a5ac:204d:e8de? ([2601:647:5600:5020:8966:a5ac:204d:e8de]) by smtp.gmail.com with ESMTPSA id i1sm4936973pfg.2.2019.09.27.17.26.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Sep 2019 17:26:20 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <96458AE1-80DC-444A-A281-A7A018F2F093@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E87C69A6-8BCA-4ADE-8FAD-724236CCEC8B" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 27 Sep 2019 17:26:19 -0700 In-Reply-To: Cc: wangzitao , Kent Watsen , Netconf To: =?utf-8?Q?Bal=C3=A1zs_Lengyel?= References: <85F77701-E157-4FAD-A97B-B22CA2A85E08@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [netconf] [Netconf] WG adoption poll for draft-lengyel-netconf-notification-capabilities-02 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2019 00:26:26 -0000 --Apple-Mail=_E87C69A6-8BCA-4ADE-8FAD-724236CCEC8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 + netconf mailing list. > On Sep 27, 2019, at 2:13 AM, Bal=C3=A1zs Lengyel = wrote: >=20 > Hello, > I have a vague recollection that we did discuss this. However some = comments: > - Minimum-dampening-period is now included in the notification = capabilities >=20 > - subscription-priority is not present in either rfc 8639 or = 8641. There are some QOS parameters an weighs but not = subscription-priority >=20 > excluded-change is not included. No one has asked for it during the = elapsed 14 months. IMHO is not a capability. It could have been a = feature in the original spec.=20 > Sorry for the late reply. > Regards Balazs > =20 > From: Mahesh Jethanandani =20 > Sent: 2019. szeptember 23., h=C3=A9tf=C5=91 19:24 > To: wangzitao > Cc: Bal=C3=A1zs Lengyel ; Kent Watsen = > Subject: Re: [Netconf] WG adoption poll for = draft-lengyel-netconf-notification-capabilities-02 > =20 > Hi Michael/Balazs, > =20 > Did you have a private exchange on this question? I do not see a = response on the netconf mailing list. >=20 >=20 > On Aug 8, 2018, at 7:24 PM, wangzitao > wrote: > =20 > Hi WG, > I have read this document and I support WG adoption of this draft. > =20 > Hi Balazs and Alex, > There are some comments. As my understanding, the = =E2=80=9Cietf-notification-capabilities=E2=80=9D model can be used to = present the server=E2=80=99s basic capabilities to indicate that whether = it can support on-change push. IMHO, there are some capabilities that = also need to be considered to present, for example: > - Whether the server supports =E2=80=9Cexcluded-change=E2=80=9D= ; > - Whether the server supports =E2=80=9Csubscription-priority=E2= =80=9D; > - Whether the server supports =E2=80=9Cdampening-period=E2=80=9D= , etc. >=20 > Best Regards! > -Michael > =20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: Netconf [mailto:netconf-bounces@ietf.org = ] =E4=BB=A3=E8=A1=A8 Mahesh = Jethanandani > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2018=E5=B9=B48=E6=9C=888=E6=97=A5 = 10:39 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Netconf > > =E4=B8=BB=E9=A2=98: [Netconf] WG adoption poll for = draft-lengyel-netconf-notification-capabilities-02 > =20 > In the NETCONF 102 WG meeting, authors presented the following = document, and asked for WG adoption. > =20 > = https://tools.ietf.org/html/draft-lengyel-netconf-notification-capabilitie= s-02 = > =20 > This starts an adoption poll for the above draft. Please indicate your = support or objection to the adoption poll. If objecting, please state = your reasons by responding on this thread. > =20 > Thanks. > =20 > Mahesh & Kent. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_E87C69A6-8BCA-4ADE-8FAD-724236CCEC8B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 + = netconf mailing list.

On Sep 27, 2019, at 2:13 AM, = Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com> wrote:

Hello,
I have a = vague recollection that we did discuss this. However some comments:

-         Minimum-dampening-period is now included in the notification = capabilities

-         subscrip= tion-priority is not present in either rfc 8639 or 8641. There are some = QOS parameters an weighs but not subscription-priority

  • excluded-change is not included. No = one has asked for it during the elapsed 14 months.  IMHO is not a = capability.  It could have been a feature in the original = spec. 
Sorry for = the late reply.
Regards Balazs
 
From: Mahesh Jethanandani <mjethanandani@gmail.com> 
Sent: 2019. szeptember 23., = h=C3=A9tf=C5=91 19:24
To: wangzitao <wangzitao@huawei.com>
Cc: Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>; Kent Watsen <kent+ietf@watsen.net>
Subject: Re: [Netconf] WG adoption = poll for draft-lengyel-netconf-notification-capabilities-02
 
Hi Michael/Balazs,
 
Did you have a private exchange on this question? I do not = see a response on the netconf mailing list.


On Aug 8, 2018, at 7:24 PM, wangzitao <wangzitao@huawei.com> = wrote:
 
Hi WG,
I have = read this document and I support WG adoption of this draft.
 
Hi Balazs and =
Alex,
There are some comments. As my understanding, the = =E2=80=9Cietf-notification-capabilities=E2=80=9D model can be used to = present the server=E2=80=99s basic capabilities to indicate that whether = it can support on-change push. IMHO, there are some capabilities that = also need to be considered to present, for example:
-          Whether the server supports = =E2=80=9Cexcluded-change=E2=80=9D;
-          Whether the server supports = =E2=80=9Csubscription-priority=E2=80=9D;

-          Whether the server supports = =E2=80=9Cdampening-period=E2=80=9D, etc.

Best = Regards!
-Michael
 
=E5=8F=91=E4=BB=B6=E4=BA=BA: Netconf [mailto:netconf-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Mahesh = Jethanandani
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2018=E5=B9=B48=E6=9C=888=E6=97=A5 10:39
=E6=94=B6=E4=BB=B6=E4=BA=BA: Netconf <netconf@ietf.org>
=E4=B8=BB=E9=A2=98: [Netconf] WG = adoption poll for = draft-lengyel-netconf-notification-capabilities-02
 
In the = NETCONF 102 WG meeting, authors presented the following document, and = asked for WG adoption.
 
https://tools.ietf.org/html/draft-lengyel-netconf-notification-= capabilities-02
 
This starts an adoption poll for the above draft. = Please indicate your support or objection to the adoption poll. If = objecting, please state your reasons by responding on this thread.
 
Thanks.
 
Mahesh = & = Kent.
<= /div>

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_E87C69A6-8BCA-4ADE-8FAD-724236CCEC8B-- From nobody Mon Sep 30 02:21:10 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91FF5120046 for ; Mon, 30 Sep 2019 02:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 NfhMnqDr0uTs for ; Mon, 30 Sep 2019 02:21:03 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on0631.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA69B12000F for ; Mon, 30 Sep 2019 02:21:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RKmm9xf+BgK3jNqpuAg1XKeYVUnXttssSUMv5tIAiem97y4IWxkOwUDUUcFXOXk5wKtGL5EPMSFxvXh/f9vRRI2ALCblGsKL5vWYicckef0N68EaONWSX9TtvamrXCyN+juYEWAJMLXpvQkYj/ZHYeo6sWssNoWswIj01cDj/ZNu34SJqAoMDXqLf7GFN35oGGBQXsOUA5TUJBs/03N9mPt7Rb/O+lwKhog9SMpwr8gnnz+UMfdQxP6h8oOOYR++ik861dswnRx/iX/3KXcH+sN3wz1/CPOgw1M34Kin0K5T3AMdaCAIIIOV4aXlgSOy9oJrQmbwC/lU5ChP8Q1I6A== 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=/LstRlnaUEPC0ZlRCdNr0Vn6ZgZ5G/AhT/xFpP+svnA=; b=T4j1sP+d5bRIUbLhm53Qgq8NENwF+CMnnVqVT/OOacPmX+yxbeI3s4Msapx+Y/H0xZUU3J8tbjHMkSlcgdUP/m8NPo2H/zKZs3LBgySVn+iWxFbdzpy/7zPLk+d4Ps99shaslRuPVJ6JlBtFuTMhVey+F1K9KPwNXICh1dXLtAbtHJu5p1S5zuZYRzE/XKCvPP45M3ktve/GQjEJFWMt5/sMzLD1lY0mlGIr1YDev/HDCscnG/bQMMlTfm5+EYY353SfBqJ2W9p0tOcjQBu3rZio85P8yYXaxNfZIMMAI9sI/R7rpW80IJBKaJgrPvwPsUKf0vKGhh6HURqyVzwMFg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/LstRlnaUEPC0ZlRCdNr0Vn6ZgZ5G/AhT/xFpP+svnA=; b=KtoJ6KE7xLy9yh9pc9qSn8PHngyLs4IyQlOemtsLJaND/G+D4aAz0cmHhYthC/bkXXdJ6Xv0g6xqFuWP0uqvxLtAkTvwD2PYqw7p+9Pqeo/qguEmKXAeshQTi6bwJCLeftCYxePj3l1duhm9IPWKJcP+0nowZ0+97PXmxjhcg4Q= Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com (10.169.137.153) by VI1PR0701MB2591.eurprd07.prod.outlook.com (10.173.85.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.15; Mon, 30 Sep 2019 09:21:00 +0000 Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com ([fe80::f44b:854c:51cf:c69f]) by VI1PR0701MB2286.eurprd07.prod.outlook.com ([fe80::f44b:854c:51cf:c69f%7]) with mapi id 15.20.2305.017; Mon, 30 Sep 2019 09:20:59 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: "Eric Voit (evoit)" , Mahesh Jethanandani , Alexander Clemm , "Benoit Claise (bclaise)" CC: Netconf Thread-Topic: [netconf] WGLC for draft-ietf-netconf-notification-capabilities Thread-Index: AQHVaCiq/P3ytjAdYEi7Gp+LSYgUDqc7MLcAgAA5KYCAA/LsEIAAqhsAgAP1+uA= Date: Mon, 30 Sep 2019 09:20:59 +0000 Message-ID: References: <4F49DF08-B7FC-4EBD-9D6B-7BC329E50334@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3f0a8561-8886-4950-e6bf-08d7458781ec x-ms-traffictypediagnostic: VI1PR0701MB2591: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 01762B0D64 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(136003)(396003)(366004)(39860400002)(51914003)(189003)(199004)(6306002)(99286004)(25786009)(86362001)(99936001)(76176011)(26005)(186003)(102836004)(71200400001)(71190400001)(7696005)(6436002)(316002)(11346002)(85182001)(229853002)(4326008)(7110500001)(53546011)(110136005)(6506007)(476003)(66066001)(5660300002)(606006)(9326002)(81156014)(446003)(236005)(486006)(478600001)(6246003)(85202003)(76116006)(3846002)(15650500001)(2420400007)(256004)(64756008)(66616009)(14444005)(66574012)(790700001)(7736002)(8676002)(66446008)(52536014)(6116002)(66946007)(81166006)(8936002)(33656002)(54896002)(14454004)(66556008)(55016002)(66476007)(74316002)(2906002)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2591; H:VI1PR0701MB2286.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 33WQe4pTQsx0Fw5WQp9gd8LkR9b/J8F/aVmCxMT0Z3n3ATG8qt9cLG4ADOYRYa8dzMpoub/zomXI4iu2pI0Wv8VPB1dVyQfs+EcAUYzf+wu7gmkC2sHGD5r8hi0WcxFfc6U/aMrrvX+xfOKQy2xQDybOzP0tiKzL8qjObknuPfHK4vp8vye2GkSx48ZiHByFM8WZV0D9WJLgo91ivFk8mrhCX/k7HlpHQCDbDXSy/5GGX5Tz4Qu1PgZcZ0LZsK07pSjKgpiSDX4GuTzrtbXX1olopcDeLwFa7Hq1ytAm5Cqq4OUpvmFgSIopbykZB9WxxdVJE/JM6Pk5d7k+UTnjB3TCK0ANlmTvHSHIpsqOjRG32A33DHJRNsvZnvjwu154jAq4PU8PmcQrfmYnrVyNLWe/xV4eSQoZyboLuRfXGhg= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_052A_01D57781.167328B0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3f0a8561-8886-4950-e6bf-08d7458781ec X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2019 09:20:59.6973 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PK6yDTpg6LJteAGir3kcs7J81sSULT8wkF0u1pZ+WmF4H1b7i9rJjJl8jUConT3lTHnWP7Gv8x+hH2rg9061FKp6C91AeeljvNMTw9ccSTQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2591 Archived-At: Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2019 09:21:09 -0000 ------=_NextPart_000_052A_01D57781.167328B0 Content-Type: multipart/mixed; boundary="----=_NextPart_001_052B_01D57781.167328B0" ------=_NextPart_001_052B_01D57781.167328B0 Content-Type: multipart/alternative; boundary="----=_NextPart_002_052C_01D57781.167328B0" ------=_NextPart_002_052C_01D57781.167328B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, Here is a preliminary next version (not submitted yet). See also below. Regards Balazs =20 From: Eric Voit (evoit) =20 Sent: 2019. szeptember 27., p=C3=A9ntek 21:42 To: Bal=C3=A1zs Lengyel ; Mahesh = Jethanandani ; Alexander Clemm = ; Benoit Claise (bclaise) Cc: Netconf Subject: RE: [netconf] WGLC for = draft-ietf-netconf-notification-capabilities =20 Hi Balazs, =20 Some more thoughts in-line. I cut out those I think closed. =20 From: Bal=C3=A1zs Lengyel >=20 Sent: Friday, September 27, 2019 8:48 AM To: Eric Voit (evoit) >; = Mahesh Jethanandani >; Alexander Clemm >; Benoit Claise (bclaise) > Cc: Netconf > Subject: RE: [netconf] WGLC for = draft-ietf-netconf-notification-capabilities =20 Thanks for the comments. See answers below.=20 I hope the group will be ok with using the term publisher instead of = server. IMHO it is clearer as the client server relationship can be = reversed e.g. for https notification transport. Balazs =20 From: Eric Voit (evoit) >=20 Sent: 2019. szeptember 24., kedd 23:15 To: Mahesh Jethanandani >; Bal=C3=A1zs Lengyel = >; = Alexander Clemm >; Benoit = Claise (bclaise) > Cc: Netconf > Subject: RE: [netconf] WGLC for = draft-ietf-netconf-notification-capabilities =20 Here are some comments... =20 On-change Notification Capability: Is this different from support for = RFC-8641 feature "on-change"? If they are the same, it might be = possible to remove the term. Especially as this term is used = inconsistently. BALAZS: In RFC 8641 on-change is not defined as a capability. It is used = for many more things (e.g. On-change subscription, trigger condition, = type of push updates, a feature.) In this draft the on change capability = is just the servers capability to send on-change notification globally, = for a specific datastore or a specific data node. Description will be = reworded. It will be good to see the reword. I still am not clear how = this different from the RFC-8641 feature "on-change", along with this = feature being associated with specific nodes. =20 BALAZS2:=20 On-change Notification Capability: The capability of the server to send on-change notifications for a specific datastore or a specific data node. =20 =20 Section 3 =20 Paragraph 2, bullet 2: Instead of "amount of notifications the server = can send out", do you mean "the minimum periodicity of updates which a = server can send out for an object" BALAZS: That too, but also the max-objects-per-update. I was told not to = repeat information in the main text and in the YANG module, so I tried = to find a wording that covers both. Also its not always the minimum = times. Some servers support a specific set of times, not a anything = over a minimum. Ok, so this bullet is a bucket of various types of information. = Which is fine with me. =20 =20 Paragraph 2, bullets 3 & 4: I don't think these should be indented as = bullets are they are more about proper behavior of a correctly populated = model. BALAZS: I don=E2=80=99t really understand this comment. Please explain. Looking at the text, bullets 3 is written to say how capabilities = value can be set (i.e., how) rather than that they can be set for = different levels (i.e., what). Getting consistency so that the bullets = are all 'how' or all 'what' items would help readability. =20 BALAZS2: OK, I get it. You are right, to be corrected. =20 =20 Paragraph 3, bullets 2: why isn't SHALL instead MUST? Also, shouldn't = this point out that both NETCONF and RESTCONF MUST be supported if = on-change is advertised, and this draft is supported? BALAZS: As I understand RFC 2119 MUST and SHALL both mean the same, but = I will change to MUST. No I do not want to mandate implementing both = Netconf AND Restconf. IMO a server with just Netconf would work just = fine; or maybe I misunderstand your comment? The second part of my comment was about ensuring that IF this = model was available, and the publisher supports both RFC-8640 & = draft-ietf-netconf-restconf-notif, then this specification MUST be able = to push changes over both NETCONF and RESTCONF. Thinking more, this = is actually a generic question which is likely already answered: how do = you know which models are supported for which transports. As = advertisement is by transport, I withdraw this question. =20 BALAZS2: Some implementations have a yang extension statement to specify = whether a model is visible on specific interfaces =20 Section 4 =20 I suspect that you will need to do a security analysis per YANG object. = This has been done the other YANG push family. BALAZS: The full module is readOnly and not sensitive or private in any = manner. The security text for the readOnly parts of YangPush is the = exact same text: not very informative, but gives you the illusion of = security awareness. You can ignore my comment. In doing RFC-8639, I needed to put in = read/write analysis for each object. And this did sometime include the = risks of internally setting values which were read-only from the model. = Perhaps this will not be required during later draft reviews in the = publication process. =20 I suspect that manipulating the reporting intervals could have some = security implications. E.g., a hacker could push up the damping period = or periodic interval to a level where the information they are changing = then becomes invisible to a monitoring system. BALAZS: The full YAM is read-only so manipulating the data is not a = concern. Per my previous point, if the IETF process says you don't need to = highlight such possibilities, then I am good. BALAZS2: In rfc8639 the text says for readOnly data nodes something like:=20 If access control is not properly configured, can expose system internals to those who should not have access to this information. That is true for any bit of data, so I do not understand what = information does it add. It does not hurt, so I will add the same = sentence to my draft. =20 If you have something else in mind please describe the attack method = that I should mention. =20 Thanks,=20 Eric=20 =20 =20 From: netconf > On Behalf Of Mahesh Jethanandani Sent: Tuesday, September 24, 2019 1:50 PM To: Netconf > Subject: Re: [netconf] WGLC for = draft-ietf-netconf-notification-capabilities =20 We were supposed to have closed on the WGLC today. However, between the = document becoming a WG item and it going into LC, we have not received = too many comments on the draft. As such, we are extending the LC by = another week. Please review the draft and provide any comments you might = have. =20 Mahesh & Kent (as co-chairs) =20 =20 On Sep 10, 2019, at 3:39 PM, Mahesh Jethanandani = > wrote: =20 Authors have published -04 = version of the draft, which addresses comments they received in = IETF 105. If you provided comments please check to make sure your = comments have been addressed. At this point, the authors believe that = the document is ready for WGLC. =20 This therefore starts a two week LC, ending on September 24th. Please = provide any technical comments you might have on the document. If you = believe the document is not ready for LC, please state your reasons. =20 We will issue a IPR poll separately.=20 =20 Mahesh & Kent (as co-chairs) =20 =20 =20 =20 ------=_NextPart_002_052C_01D57781.167328B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello,

Here is a = preliminary next version (not submitted yet). See also below.

Regards Balazs

 

From: Eric Voit (evoit) = <evoit@cisco.com>
Sent: 2019. szeptember 27., = p=C3=A9ntek 21:42
To: Bal=C3=A1zs Lengyel = <balazs.lengyel@ericsson.com>; Mahesh Jethanandani = <mjethanandani@gmail.com>; Alexander Clemm = <ludwig@clemm.org>; Benoit Claise (bclaise) = <bclaise@cisco.com>
Cc: Netconf = <netconf@ietf.org>
Subject: RE: [netconf] WGLC for = draft-ietf-netconf-notification-capabilities

 

Hi = Balazs,

 

Some more thoughts in-line.   I cut out = those I think closed.

 

From: = Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>
Sent: Friday, September 27, 2019 8:48 AM
To: = Eric Voit (evoit) <evoit@cisco.com>; Mahesh = Jethanandani <mjethanandani@gmail.com>; = Alexander Clemm <ludwig@clemm.org>; Benoit Claise = (bclaise) <bclaise@cisco.com>
Cc:= Netconf <netconf@ietf.org>
Subject:<= /b> RE: [netconf] WGLC for = draft-ietf-netconf-notification-capabilities

 

Thanks for = the comments. See answers below. =

I hope the group will be ok with using the term = publisher instead of server. IMHO it is clearer as the client server = relationship can be reversed e.g. for https notification = transport.

Balazs

 

From: Eric Voit (evoit) <evoit@cisco.com>
Sent: = 2019. szeptember 24., kedd 23:15
To: Mahesh Jethanandani = <mjethanandani@gmail.com>; = Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>; Alexander Clemm <ludwig@clemm.org>; Benoit Claise = (bclaise) <bclaise@cisco.com>
Cc:= Netconf <netconf@ietf.org>
Subject:<= /b> RE: [netconf] WGLC for = draft-ietf-netconf-notification-capabilities

 

Here are = some comments...

 

On-change Notification Capability: Is this = different from support for RFC-8641 feature "on-change"?  = If they are the same, it might be possible to remove the term.  = Especially as this term is used inconsistently.

BALAZS: In RFC 8641 = on-change is not defined as a capability. It is used for many more = things (e.g. On-change subscription,  trigger condition, type of = push updates, a feature.) In this draft the on change capability is just = the servers capability to send on-change notification globally, for a = specific datastore or a specific data node. Description will be = reworded.

<Eric> It = will be good to see the reword.   I still am not clear how = this different from the RFC-8641 feature "on-change", along = with this feature being associated with specific nodes.  =

BALAZS2:

On-change Notification Capability: The = capability of the server to

=C2=A0=C2=A0 = send on-change notifications for a specific datastore or a = specific

=C2=A0=C2=A0 data node.

 

 

Section 3

 

Paragraph 2, bullet 2: Instead of =  "amount of notifications the server can send out", do = you mean "the minimum periodicity of updates which a server can = send out for an object"

BALAZS: That too, but also the = max-objects-per-update. I was told not to repeat information in the main = text and in the YANG module, so I tried to find a wording that covers = both. Also  its not always the minimum times. Some servers support =  a specific set of times, not a anything over a = minimum.

<Eric> Ok, = so this bullet is a bucket of various types of information.  Which = is fine with me.

 

 

Paragraph 2, bullets 3 & 4: I don't think these = should be indented as bullets are they are more about proper behavior of = a correctly populated model.

BALAZS: I don=E2=80=99t really understand this = comment.  Please explain.

<Eric> Looking at the text, bullets 3 is = written to say how capabilities value can be set (i.e., how) rather than = that they can be set for different levels (i.e., what).  Getting = consistency so that the bullets are all 'how' or all 'what' items would = help readability.  

BALAZS2: OK, I get it. You are right, to be = corrected.

 

 

Paragraph 3, bullets 2: why isn't SHALL instead = MUST?   Also, shouldn't this point out that both NETCONF and = RESTCONF MUST be supported if on-change is advertised, and this draft is = supported?

BALAZS: As I understand RFC 2119 MUST and SHALL = both mean the same, but I will change to MUST. No I do not want to = mandate implementing both Netconf AND Restconf. IMO a server with just = Netconf would work just fine; or maybe I misunderstand your = comment?

<Eric> The = second part of my comment was about ensuring that IF this model was = available, and the publisher supports both RFC-8640 & = draft-ietf-netconf-restconf-notif, then this specification MUST be able = to push changes over both NETCONF and RESTCONF.    = Thinking more, this is actually a generic question which is likely = already answered: how do you know which models are supported for which = transports.   As advertisement is by transport, I withdraw = this question. 

BALAZS2: Some implementations have a yang = extension statement to specify whether =C2=A0a model is visible on = specific interfaces

 

Section 4

 

I = suspect that you will need to do a security analysis per YANG = object.   This has been done the other YANG push = family.

BALAZS: The full module is readOnly and not = sensitive or private in any manner.  The security text for the = readOnly parts of YangPush is the exact same text: not very informative, = but gives you the illusion of security = awareness.

<Eric> You = can ignore my comment.  In doing RFC-8639, I needed to put in = read/write analysis for each object.  And this did sometime include = the risks of internally setting values which were read-only from the = model.  Perhaps this will not be required during later draft = reviews in the publication process.

 

I = suspect that manipulating the reporting intervals could have some = security implications.   E.g., a hacker could push up the = damping period or periodic interval to a level where the information = they are changing then becomes invisible to a monitoring = system.

BALAZS: The full YAM is read-only so = manipulating the data is not a concern.

<Eric> Per my previous point, if the IETF = process says you don't need to highlight such possibilities, then I am = good.

BALAZS2:

In rfc8639 the text = says for readOnly data nodes something like:

If access control is not properly configured, = can expose

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 system = internals to those who should not have access to = this

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = information.

That is true for any bit of data, so I do not = understand what information does it add. It does not hurt, so I will add = the same sentence to my draft.

 

If you have something = else in mind please describe the attack method that I should = mention.

</Eric>

 

Thanks,

Eric =

 

 

From: = netconf <netconf-bounces@ietf.org>= On Behalf Of Mahesh Jethanandani
Sent: Tuesday, = September 24, 2019 1:50 PM
To: Netconf <netconf@ietf.org>
Subject:<= /b> Re: [netconf] WGLC for = draft-ietf-netconf-notification-capabilities

 

We = were supposed to have closed on the WGLC today. However, between the = document becoming a WG item and it going into LC, we have not received = too many comments on the draft. As such, we are extending the LC by = another week. Please review the draft and provide any comments you might = have.

 

Mahesh & Kent (as co-chairs)

 

 

On Sep 10, 2019, at 3:39 PM, Mahesh Jethanandani = <mjethanandani@gmail.com> = wrote:

 

Authors have published -04 version of the draft, which addresses comments = they received in IETF 105. If you provided comments please check to make = sure your comments have been addressed. At this point, the authors = believe that the document is ready for WGLC.

 

This therefore starts a two week LC, ending on = September 24th. Please provide any technical comments you might have on = the document. If you believe the document is not ready for LC, please = state your reasons.

 

We will issue a IPR poll = separately. 

 

Mahesh & Kent (as = co-chairs)

 

 

 

 

------=_NextPart_002_052C_01D57781.167328B0-- ------=_NextPart_001_052B_01D57781.167328B0 Content-Type: text/plain; name="draft-ietf-netconf-notification-capabilities-05b.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-netconf-notification-capabilities-05b.txt" =0A= =0A= =0A= =0A= NETCONF B. Lengyel=0A= Internet-Draft Ericsson=0A= Intended status: Standards Track A. Clemm=0A= Expires: April 2, 2020 Futurewei=0A= B. Claise=0A= Cisco Systems, Inc.=0A= September 30, 2019=0A= =0A= =0A= YANG-Push Notification Capabilities=0A= draft-ietf-netconf-notification-capabilities-04=0A= =0A= Abstract=0A= =0A= This document proposes a YANG module that allows a publisher to=0A= specify capabilities related to "Subscription to YANG Datastores"=0A= (YANG-Push). It proposes to use YANG Instance Data to document this=0A= information and make it already available at implementation-time, but=0A= also allow it to be reported at run-time.=0A= =0A= Status of This Memo=0A= =0A= This Internet-Draft is submitted in full conformance with the=0A= provisions of BCP 78 and BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF). Note that other groups may also distribute=0A= working documents as Internet-Drafts. The list of current Internet-=0A= Drafts is at https://datatracker.ietf.org/drafts/current/.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= This Internet-Draft will expire on April 2, 2020.=0A= =0A= Copyright Notice=0A= =0A= Copyright (c) 2019 IETF Trust and the persons identified as the=0A= document authors. All rights reserved.=0A= =0A= This document is subject to BCP 78 and the IETF Trust's Legal=0A= Provisions Relating to IETF Documents=0A= (https://trustee.ietf.org/license-info) in effect on the date of=0A= publication of this document. Please review these documents=0A= carefully, as they describe your rights and restrictions with respect=0A= to this document. Code Components extracted from this document must=0A= =0A= =0A= =0A= Lengyel, et al. Expires April 2, 2020 [Page 1]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities September 2019=0A= =0A= =0A= include Simplified BSD License text as described in Section 4.e of=0A= the Trust Legal Provisions and are provided without warranty as=0A= described in the Simplified BSD License.=0A= =0A= Table of Contents=0A= =0A= 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2=0A= 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 3. Notification Capability Model . . . . . . . . . . . . . . . . 5=0A= 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 6=0A= 3.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6=0A= 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12=0A= 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12=0A= 5.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 12=0A= 5.2. The YANG Module Names Registry . . . . . . . . . . . . . 12=0A= 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 13=0A= 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13=0A= 7.1. Normative References . . . . . . . . . . . . . . . . . . 13=0A= 7.2. Informative References . . . . . . . . . . . . . . . . . 14=0A= Appendix A. Instance data examples . . . . . . . . . . . . . . . 14=0A= Appendix B. Changes between revisions . . . . . . . . . . . . . 17=0A= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18=0A= =0A= 1. Terminology=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and=0A= "OPTIONAL" in this document are to be interpreted as described in BCP=0A= 14 [RFC2119] [RFC8174] when, and only when, they appear in all=0A= capitals, as shown here.=0A= =0A= The terms YANG-Push, On-change subscription and Periodic subscription=0A= are used as defined in [RFC8641]=0A= =0A= The terms Publisher and Receiver are used as defined in [RFC8639]=0A= =0A= On-change Notification Capability: The capability of the publisher to=0A= send on-change notifications for a specific datastore or a specific=0A= data node.=0A= =0A= The term Server is used as defined in [RFC8342]=0A= =0A= Implementation-time information: Information about the publisher's=0A= behavior that is made available during the implementation of the=0A= publisher, available from a source other then a running server=0A= implementing the publisher.=0A= =0A= =0A= =0A= =0A= =0A= Lengyel, et al. Expires April 2, 2020 [Page 2]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities September 2019=0A= =0A= =0A= Run-time information: Information about the publisher's behavior that=0A= is available from the running server (implementing the publisher) via=0A= management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040].=0A= =0A= 2. Introduction=0A= =0A= As defined in [RFC8641] a publisher may allow clients to subscribe to=0A= updates from a datastore and subsequently push such update=0A= notifications to the receiver. Notifications may be sent=0A= periodically or on-change (more or less immediately after each=0A= change).=0A= =0A= A publisher supporting YANG-Push has a number of capabilities defined=0A= in [RFC8641] that are often determined during the implementation of=0A= the publisher. These include:=0A= =0A= o Supported (reporting) periods for periodic subscriptions=0A= =0A= o Maximum number of objects that can be sent in an update=0A= =0A= If the optional on-change feature is supported, additionally:=0A= =0A= o Supported dampening periods for on-change subscriptions=0A= =0A= o The set of data nodes for which on-change notification is=0A= supported=0A= =0A= Publishers MAY have limitations in how many update notifications and=0A= how many datastore node updates they can send out in a certain time-=0A= period.=0A= =0A= In some cases, a publisher supporting on-change notifications will=0A= not be able to push updates for some object types on-change. Reasons=0A= for this might be that the value of the datastore node changes=0A= frequently (e.g. in-octets counter), that small object changes are=0A= frequent and irrelevant to the receiver (e.g., a temperature gauge=0A= changing 0.1 degrees within a predetermined and acceptable range), or=0A= that the implementation is not capable of on-change notification for=0A= a particular object. In those cases, it will be important for client=0A= applications to have a way to identify for which objects on-change=0A= notifications are supported and for which ones not.=0A= =0A= Faced with the reality that support for on-change notification does=0A= not mean that such notifications will be sent for any specific data=0A= node, client/management applications can not rely on the on-change=0A= functionality unless the client has some means to identify for which=0A= objects on-change notifications are supported. YANG models are meant=0A= to be used as an interface contract. Without identification of the=0A= =0A= =0A= =0A= Lengyel, et al. Expires April 2, 2020 [Page 3]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities September 2019=0A= =0A= =0A= data nodes actually supporting on-change, this contract would be=0A= incomplete.=0A= =0A= This document proposes a YANG module that allows a client to discover=0A= YANG-Push related capabilities both at implementation-time and run-=0A= time.=0A= =0A= Implementation-time information is needed by Network Management=0A= System (NMS) implementers. During NMS implementation for any=0A= functionality that depends on the notifications the information about=0A= on change notification capability is needed. If the information is=0A= not documented in a way available to the NMS designer, but only as=0A= instance data from the network node once it is deployed, the NMS=0A= implementation will be delayed, because it has to wait for the=0A= network node to be ready. In addition, the assumption that all NMS=0A= implementers will have a correctly configured network node available=0A= to retrieve data from is an expensive proposition and may not always=0A= hold. (An NMS may need to be able to handle many dozens of network=0A= node types.) Often a fully functional NMS is a requirement for=0A= introducing a new network node type into a network, so delaying NMS=0A= readiness effectively also delays the time at which a new network=0A= node type can be introduced into the network.=0A= =0A= Implementation-time information is needed by system integrators.=0A= When introducing a network node type into their network, operators=0A= often need to integrate the node type into their own management=0A= system. The NMS may have management functions that depend on on-=0A= change notifications. The network operator needs to plan his=0A= management practices and NMS implementation before he even decides to=0A= buy the specific network node type. Moreover the decision to buy the=0A= node type sometimes depends on these management possibilities.=0A= =0A= Run-time information is needed:=0A= =0A= o for any "purely model driven" client, e.g. a NETCONF-browser.=0A= Such clients depend on reading models, capabilities in run-time to=0A= support all the server's/publisher's available functionality.=0A= =0A= o in case the capability might change during run-time e.g. due to=0A= licensing, HW constraints etc.=0A= =0A= o to check that capability information provided early, already in=0A= implementation-time is indeed what the publisher implements (is=0A= the supplied documentation correct?)=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Lengyel, et al. Expires April 2, 2020 [Page 4]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities September 2019=0A= =0A= =0A= 3. Notification Capability Model=0A= =0A= It is a goal to provide Yang-Push notification capability information=0A= in a format that is:=0A= =0A= o vendor independent=0A= =0A= o formal=0A= =0A= o identical for implementation-time and run-time=0A= =0A= The YANG module ietf-notification-capabilities is defined to provide=0A= the information. It contains:=0A= =0A= o a set of capabilities related to the amount of notifications the=0A= publisher can send out=0A= =0A= o specification of which data nodes support on-change notifications.=0A= =0A= Capability values can be specified on publisher level, datastore=0A= level or on specific data nodes (and their contained sub-tree) of a=0A= specific datastore. Capability values on a smaller, more specific=0A= part of the publisher's data always override more generic values.=0A= =0A= On-change capability is not specified on a publisher level as=0A= different datastores usually have different on-change capabilities.=0A= On a datastore level on-change capability for configuration and state=0A= data can be specified separately.=0A= =0A= The information SHALL be provided in two ways both following the=0A= ietf-notification-capabilities module:=0A= =0A= o For the implementation-time use-case: It SHALL be provided by the=0A= implementer as YANG instance data file complying to=0A= [I-D.ietf-netmod-yang-instance-file-format]. The file SHALL be=0A= available already in implementation-time retrievable in a way that=0A= does not depend on a live network node. E.g. download from=0A= product Website.=0A= =0A= o For the run-time use-case: It MUST be available via NETCONF=0A= [RFC6241] or RESTCONF [RFC8040] from the live server during run-=0A= time. Implementations which support changing these capabilities=0A= at run-time SHOULD support on-change notifications about the=0A= datastore-subscription-capabilities container.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Lengyel, et al. Expires April 2, 2020 [Page 5]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities September 2019=0A= =0A= =0A= 3.1. Tree Diagram=0A= =0A= The following tree diagram [RFC8340] provides an overview of the data=0A= model.=0A= =0A= module: ietf-notification-capabilities=0A= +--ro datastore-subscription-capabilities=0A= +--ro (update-period)?=0A= | +--:(minimum-update-period)=0A= | | +--ro minimum-update-period? uint32=0A= | +--:(supported-update-period)=0A= | +--ro supported-update-period* uint32=0A= +--ro max-objects-per-update? uint32=0A= +--ro minimum-dampening-period? uint32 {yp:on-change}?=0A= +--ro datastore-capabilities* [datastore]=0A= +--ro datastore union=0A= +--ro (update-period)?=0A= | +--:(minimum-update-period)=0A= | | +--ro minimum-update-period? uint32=0A= | +--:(supported-update-period)=0A= | +--ro supported-update-period* uint32=0A= +--ro max-objects-per-update? uint32=0A= +--ro minimum-dampening-period? uint32 {yp:on-change}?=0A= +--ro on-change-supported-for-config? boolean {yp:on-change}?=0A= +--ro on-change-supported-for-state? boolean {yp:on-change}?=0A= +--ro per-node-capabilities* [node-selector]=0A= +--ro node-selector nacm:node-instance-identifier=0A= +--ro (update-period)?=0A= | +--:(minimum-update-period)=0A= | | +--ro minimum-update-period? uint32=0A= | +--:(supported-update-period)=0A= | +--ro supported-update-period* uint32=0A= +--ro max-objects-per-update? uint32=0A= +--ro minimum-dampening-period? uint32 {yp:on-change}?=0A= +--ro on-change-supported boolean {yp:on-change}?=0A= =0A= 3.2. YANG Module=0A= =0A= file "ietf-notification-capabilities@2019-08-13.yang"=0A= =0A= module ietf-notification-capabilities {=0A= yang-version 1.1;=0A= namespace=0A= "urn:ietf:params:xml:ns:yang:ietf-notification-capabilities";=0A= prefix inc;=0A= =0A= import ietf-netconf-acm { prefix nacm; }=0A= import ietf-yang-push { prefix yp; }=0A= =0A= =0A= =0A= Lengyel, et al. Expires April 2, 2020 [Page 6]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities September 2019=0A= =0A= =0A= import ietf-yang-library {=0A= prefix yanglib;=0A= description=0A= "Requires revision 2019-01-04 or a revision derived from it.";=0A= }=0A= =0A= organization=0A= "IETF NETCONF (Network Configuration) Working Group";=0A= contact=0A= "WG Web: =0A= WG List: =0A= =0A= Editor: Balazs Lengyel=0A= ";=0A= description=0A= "This module specifies YANG-Push related publisher=0A= capabilities.=0A= =0A= The module contains=0A= - capabilities related to the amount of notifications the=0A= publisher can send out. (Note that for a specific subscription=0A= the publisher MAY still allow only longer periods or smaller=0A= updates depending on e.g. actual load conditions.)=0A= - specification of which data nodes support on-change=0A= notifications.=0A= =0A= Capability values on a=0A= smaller, more specific part of the publisher's data always override=0A= more generic values. The hierarchy of specifications from generic=0A= to more specific is:=0A= 1) top level values valid for all datastores=0A= 2) values for a specific datastore (including the special=0A= 'all' datastore identifier)=0A= 3) Value for a specific data node and its contained sub-tree=0A= in one of the datastores. Such capability values are inherited=0A= down the containment tree unless a more specific value is=0A= provided, as described in 4)=0A= 4) A contained, smaller, more specific sub-tree in a specific=0A= datastore (could be a single leaf)=0A= =0A= Any capability value MAY be absent if a more generic capability=0A= value is already provided or if the publisher is not capable of=0A= providing a value.=0A= =0A= The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',=0A= 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',=0A= 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document=0A= are to be interpreted as described in BCP 14 (RFC 2119)=0A= =0A= =0A= =0A= Lengyel, et al. Expires April 2, 2020 [Page 7]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities September 2019=0A= =0A= =0A= (RFC 8174) when, and only when, they appear in all=0A= capitals, as shown here.=0A= =0A= Copyright (c) 2019 IETF Trust and the persons identified as=0A= authors of the code. All rights reserved.=0A= =0A= Redistribution and use in source and binary forms, with or=0A= without modification, is permitted pursuant to, and subject=0A= to the license terms contained in, the Simplified BSD License=0A= set forth in Section 4.c of the IETF Trust's Legal Provisions=0A= Relating to IETF Documents=0A= (http://trustee.ietf.org/license-info).=0A= =0A= This version of this YANG module is part of RFC XXXX; see=0A= the RFC itself for full legal notices.";=0A= =0A= revision 2019-08-13 {=0A= description=0A= "Initial version";=0A= reference=0A= "RFC XXX: Yang-Push Notification Capabilities";=0A= }=0A= =0A= container datastore-subscription-capabilities {=0A= config false;=0A= description=0A= "YANG-Push related publisher capabilities";=0A= =0A= grouping datastore-subscription-throughput-capabilities {=0A= description "Capability values that affect the amount of=0A= notifications the publisher can send out.";=0A= =0A= choice update-period {=0A= description=0A= "Supported update-period values.";=0A= leaf minimum-update-period {=0A= type uint32;=0A= units "centiseconds";=0A= description=0A= "Minimum update period supported for a=0A= periodic subscription.";=0A= }=0A= =0A= leaf-list supported-update-period {=0A= type uint32;=0A= units "centiseconds";=0A= description "Supported update period values for a=0A= periodic subscription (used if only these specific=0A= =0A= =0A= =0A= Lengyel, et al. Expires April 2, 2020 [Page 8]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities September 2019=0A= =0A= =0A= values are supported).";=0A= }=0A= }=0A= =0A= leaf max-objects-per-update {=0A= type uint32 {=0A= range "1..max";=0A= }=0A= description=0A= "Maximum number of objects that can be sent=0A= in an update.";=0A= }=0A= =0A= leaf minimum-dampening-period {=0A= if-feature yp:on-change ;=0A= type uint32;=0A= units "centiseconds";=0A= description=0A= "The minimum dampening period supported for on-change=0A= subscriptions.";=0A= }=0A= }=0A= =0A= uses datastore-subscription-throughput-capabilities {=0A= description "Top level throughput capabilities.=0A= These values can be overridden by values provided per=0A= datastore or for individual data nodes in a datastore.";=0A= }=0A= =0A= list datastore-capabilities {=0A= key datastore ;=0A= description "Capabilities values per datastore.=0A= For non-NMDA servers/publishers the config=3Dfalse data is=0A= considered as if it was part of the running datastore.=0A= =0A= Indicates per datastore throughput capabilities.=0A= =0A= Indicates per datastore the data nodes for which the=0A= publisher is capable of sending on-change notifications.=0A= If a datastore implemented by the server/publisher is not=0A= specified in this list and there is no list element for=0A= 'all' datastores the datastore does not support any=0A= on-change notifications.=0A= =0A= On-change notifications SHALL be sent for a config=3Dtrue=0A= data node if one of the following is true:=0A= - if it is a top level data-node and is not specified in the=0A= per-node-capabilities list and on-change-supported-for-config=0A= =0A= =0A= =0A= Lengyel, et al. Expires April 2, 2020 [Page 9]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities September 2019=0A= =0A= =0A= is true; or=0A= - notifications are sent for its parent data node and it is=0A= not specified in the per-node-capabilities list; or=0A= - it is specified in the per-node-capabilities list and has=0A= an on-change-supported value true.=0A= =0A= On-change notifications SHALL be sent for a config=3Dfalse=0A= data node if one of the following is true:=0A= - if it is a top level data-node (a config=3Dfalse data node with=0A= a config=3Dtrue parent SHALL be treated as a top level data node)=0A= and is not specified in the per-node-capabilities list and=0A= on-change-supported-for-state is true; or=0A= - notifications are sent for its parent data node=0A= which is also config=3Dfalse and it is not specified in the=0A= per-node-capabilities list; or=0A= - it is specified in the per-node-capabilities list and has=0A= an on-change-supported value true";=0A= =0A= leaf datastore {=0A= type union {=0A= type leafref {=0A= path /yanglib:yang-library/yanglib:datastore/yanglib:name ;=0A= }=0A= type enumeration {=0A= enum all ;=0A= }=0A= }=0A= must '. !=3D "all" or count(..) =3D "1" ' {=0A= error-message=0A= "If 'all' is present individual datastores cannot be " +=0A= "specified.";=0A= }=0A= description "The datastore for which capabilities are defined.";=0A= }=0A= =0A= uses datastore-subscription-throughput-capabilities {=0A= description "Throughput capabilities for a datastore.=0A= These values will override top level values and can be=0A= overridden by values provided for individual data nodes=0A= in a datastore.";=0A= }=0A= =0A= leaf on-change-supported-for-config {=0A= if-feature yp:on-change ;=0A= type boolean;=0A= default "true";=0A= description=0A= "Specifies the default value for=0A= =0A= =0A= =0A= Lengyel, et al. Expires April 2, 2020 [Page 10]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities September 2019=0A= =0A= =0A= top level config=3Dtrue data nodes for the=0A= on-change-supported capability.";=0A= }=0A= =0A= leaf on-change-supported-for-state {=0A= if-feature yp:on-change ;=0A= type boolean;=0A= default "false";=0A= description=0A= "Specifies the default value for=0A= top level config=3Dfalse data nodes for the=0A= on-change-supported capability.";=0A= }=0A= =0A= list per-node-capabilities {=0A= key "node-selector";=0A= description=0A= "A list of data nodes that have either a throughput or=0A= on-change-notification capability specifically defined.=0A= =0A= Should be used only when specific data nodes support=0A= capabilities that are different from capabilities=0A= of their parent nodes or the default for the datastore.";=0A= =0A= leaf node-selector {=0A= type nacm:node-instance-identifier;=0A= description=0A= "Selects the data nodes for which=0A= a capability is specified.";=0A= }=0A= =0A= uses datastore-subscription-throughput-capabilities {=0A= description "Throughput capabilities for a specific data node.=0A= These values will override top level or datastore=0A= specific values.";=0A= }=0A= =0A= leaf on-change-supported {=0A= if-feature yp:on-change ;=0A= type boolean;=0A= mandatory true;=0A= description=0A= "Specifies whether the publisher is capable of=0A= sending on-change notifications for the selected=0A= data nodes.";=0A= }=0A= }=0A= }=0A= =0A= =0A= =0A= Lengyel, et al. Expires April 2, 2020 [Page 11]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities September 2019=0A= =0A= =0A= }=0A= }=0A= =0A= =0A= =0A= 4. Security Considerations=0A= =0A= The YANG module specified in this document defines a schema for data=0A= that is designed to be accessed via network management protocols such=0A= as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer=0A= is the secure transport layer, and the mandatory-to-implement secure=0A= transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer=0A= is HTTPS, and the mandatory-to-implement secure transport is TLS=0A= [RFC8446].=0A= =0A= The Network Configuration Access Control Model (NACM) [RFC8341]=0A= provides the means to restrict access for particular NETCONF or=0A= RESTCONF users to a preconfigured subset of all available NETCONF or=0A= RESTCONF protocol operations and content. If access control is not=0A= properly configured, it can expose system internals to those who=0A= should not have access to this information.=0A= =0A= The data in this module is not security sensitive.=0A= =0A= 5. IANA Considerations=0A= =0A= 5.1. The IETF XML Registry=0A= =0A= This document registers one URI in the IETF XML registry [RFC3688].=0A= Following the format in [RFC3688], the following registrations are=0A= requested:=0A= =0A= URI: urn:ietf:params:xml:ns:yang:ietf-notification-capabilities=0A= Registrant Contact: The NETCONF WG of the IETF.=0A= XML: N/A, the requested URI is an XML namespace.=0A= =0A= 5.2. The YANG Module Names Registry=0A= =0A= This document registers one YANG module in the YANG Module Names=0A= registry [RFC7950]. Following the format in [RFC7950], the the=0A= following registrations are requested:=0A= =0A= name: ietf-notification-capabilities=0A= namespace: urn:ietf:params:xml:ns:yang:ietf-notification-capabilities=0A= prefix: inc=0A= reference: RFC XXXX=0A= =0A= =0A= =0A= =0A= =0A= Lengyel, et al. Expires April 2, 2020 [Page 12]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities September 2019=0A= =0A= =0A= 6. Open Issues=0A= =0A= -=0A= =0A= 7. References=0A= =0A= 7.1. Normative References=0A= =0A= [I-D.ietf-netmod-yang-instance-file-format]=0A= Lengyel, B. and B. Claise, "YANG Instance Data File=0A= Format", draft-ietf-netmod-yang-instance-file-format-04=0A= (work in progress), August 2019.=0A= =0A= [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,=0A= and A. Bierman, Ed., "Network Configuration Protocol=0A= (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,=0A= .=0A= =0A= [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure=0A= Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,=0A= .=0A= =0A= [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",=0A= RFC 7950, DOI 10.17487/RFC7950, August 2016,=0A= .=0A= =0A= [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF=0A= Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,=0A= .=0A= =0A= [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,=0A= and R. Wilton, "Network Management Datastore Architecture=0A= (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,=0A= .=0A= =0A= [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol=0A= Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,=0A= .=0A= =0A= [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,=0A= E., and A. Tripathy, "Subscription to YANG Notifications",=0A= RFC 8639, DOI 10.17487/RFC8639, September 2019,=0A= .=0A= =0A= [RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications=0A= for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,=0A= September 2019, .=0A= =0A= =0A= =0A= =0A= Lengyel, et al. Expires April 2, 2020 [Page 13]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities September 2019=0A= =0A= =0A= 7.2. Informative References=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=0A= Requirement Levels", BCP 14, RFC 2119,=0A= DOI 10.17487/RFC2119, March 1997,=0A= .=0A= =0A= [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,=0A= DOI 10.17487/RFC3688, January 2004,=0A= .=0A= =0A= [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC=0A= 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,=0A= May 2017, .=0A= =0A= [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",=0A= BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,=0A= .=0A= =0A= Appendix A. Instance data examples=0A= =0A= The following example is instance-data describing the notification=0A= capabilities of a hypothetical "acme-switch". The switch implements=0A= the running, candidate and operational datastores. Every change can=0A= be reported on-change from running, nothing from candidate and all=0A= config=3Dfalse data from operational.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Lengyel, et al. Expires April 2, 2020 [Page 14]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities September 2019=0A= =0A= =0A= =0A= =0A= acme-switch-notification-capabilities=0A= ietf-notification-capabilities@2019-08-13.yang=0A= =0A= Notification capabilities of acme-switch.=0A= Acme-switch implements the running, candidate and operational=0A= datastores. Every change can be reported on-change from running,=0A= nothing from candidate and all config=3Dfalse data from operational.=0A= =0A= =0A= =0A= 500=0A= 2000=0A= 100=0A= =0A= =0A= running=0A= =0A= =0A= =0A= =0A= =0A= =0A= operational=0A= =0A= =0A= false=0A= =0A= =0A= true=0A= =0A= =0A= =0A= =0A= =0A= =0A= Figure 1: Notification Capabilities with default settings=0A= =0A= The following is the instance-data describing the notification=0A= capabilities of a hypothetical "acme-router". The router implements=0A= the running, and operational datastores. Every change can be=0A= reported on-change from running, but only config=3Dtrue nodes and some=0A= config=3Dfalse data from operational. Interface statistics are not=0A= =0A= =0A= =0A= Lengyel, et al. Expires April 2, 2020 [Page 15]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities September 2019=0A= =0A= =0A= reported on-change only 2 important counters. Datastore subscription=0A= capabilities are not reported on-change as they never change on the=0A= acme-router during run-time.=0A= =0A= =0A= =0A= acme-router-notification-capabilities=0A= ietf-notification-capabilities@2019-08-13.yang=0A= =0A= Defines the notification capabilities of an acme-router.=0A= The router only has running, and operational datastores.=0A= Every change can be reported on-change from running, but=0A= only config=3Dtrue nodes and some config=3Dfalse data from = operational.=0A= Statistics are not reported on-change only 2 important counters,=0A= for these a smaller dampening period is possible.=0A= =0A= =0A= =0A= 500=0A= 2000=0A= 100=0A= =0A= =0A= running=0A= =0A= =0A= =0A= =0A= operational=0A= =0A= =0A= true=0A= =0A= =0A= =0A= /inc:datastore-subscription-capabilities=0A= false=0A= =0A= =0A= =0A= /if:interfaces/if:interface/if:statistics=0A= false=0A= =0A= =0A= =0A= /if:interfaces/if:interface/if:statistics/if:in-octets=0A= =0A= =0A= =0A= Lengyel, et al. Expires April 2, 2020 [Page 16]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities September 2019=0A= =0A= =0A= =0A= 10=0A= true=0A= =0A= =0A= =0A= /if:interfaces/if:interface/if:statistics/if:out-octets=0A= =0A= true=0A= 10=0A= =0A= =0A= =0A= =0A= =0A= =0A= Figure 2: Notification Capabilities with data node specific settings=0A= =0A= Appendix B. Changes between revisions=0A= =0A= v04 - v05=0A= =0A= o Small correction, spelling, rewording=0A= =0A= o Replaced the term server with the term publisher where=0A= aprpropriate. The client-server relationship might be reversed=0A= for some notification transports e.g. https.=0A= =0A= v03 - v04=0A= =0A= o Clarified recommended support for on-change notifications about=0A= the datastore-subscription-capabilities.=0A= =0A= v02 - v03=0A= =0A= o Allow throughput related capabilities to be defined on top,=0A= datastore or data node level. Described that specific capability=0A= values always override generic ones.=0A= =0A= o Indicate that non-NMDA servers can also use this model.=0A= =0A= o Updated according to draft-ietf-netmod-yang-instance-file-=0A= format-04=0A= =0A= v01 - v02=0A= =0A= o Added instance data examples=0A= =0A= =0A= =0A= =0A= Lengyel, et al. Expires April 2, 2020 [Page 17]=0A= =0C=0A= Internet-Draft YANG-Push Notification Capabilities September 2019=0A= =0A= =0A= o On-change capability can be defined per datastore=0A= =0A= o Added "if-feature yp:on-change" where relevant=0A= =0A= o Unified units used=0A= =0A= v00 - v01=0A= =0A= o Add more capabilities: minimum period, supported period max-number=0A= of objects, min dampening period, dampening supported=0A= =0A= Authors' Addresses=0A= =0A= Balazs Lengyel=0A= Ericsson=0A= Magyar Tudosok korutja 11=0A= 1117 Budapest=0A= Hungary=0A= =0A= Email: balazs.lengyel@ericsson.com=0A= =0A= =0A= Alexander Clemm=0A= Futurewei=0A= 2330 Central Expressway=0A= Santa Clara, CA 95050=0A= USA=0A= =0A= Email: ludwig@clemm.org=0A= =0A= =0A= Benoit Claise=0A= Cisco Systems, Inc.=0A= De Kleetlaan 6a b1=0A= 1831 Diegem=0A= Belgium=0A= =0A= Email: bclaise@cisco.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Lengyel, et al. Expires April 2, 2020 [Page 18]=0A= ------=_NextPart_001_052B_01D57781.167328B0-- ------=_NextPart_000_052A_01D57781.167328B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVbjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIF/zCCA+egAwIBAgIR AOm+1xFswMzmixU1jNT/MSEwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoM CEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMB4XDTE3MTAw OTE1MjQ1OFoXDTIwMTAwOTE1MjQ1N1owajERMA8GA1UECgwIRXJpY3Nzb24xGDAWBgNVBAMMD0Jh bMOhenMgTGVuZ3llbDEqMCgGCSqGSIb3DQEJARYbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t MQ8wDQYDVQQFEwZFVEhCTEwwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUUtnneUfH i428YPkvW+AsCNeKCCKq72SzUZpBggijy+oLVO0cgTXXHygrZ+KT8TbyEkPwuHi+V4TQxWAyMhGa nWZHWZXe9ghEZrJDJbCzFMHOqR+wEDnI1vM3sfQQ68iSsWQLd9opnb2/ihiJlt9up75VRpyj5lea bvzxOLQimJgZiXaZzsPPT2nROyytKxOsE5KbfT3mNof3bMG1bggZtGGA1GBJchwdFJwQKIShfPVm 1CdulvJV1hPVecxttMJNPzSfSfryb/b64QnR5yc/pSx8SxD0h0rnNT73Al3Af2iRghdXN4omDKZY OcdK/sE5HTmLTFuWoZAnL/RntOK9AgMBAAGjggHBMIIBvTBIBgNVHR8EQTA/MD2gO6A5hjdodHRw Oi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggr BgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYI KwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNlcjAmBgNVHREEHzAdgRtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20wVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5 LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBSkJw2vbyMFmf9tY1urk9NeYfiMgTAfBgNVHSMEGDAWgBQcexmel5x2rCA92Nzj kWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAD1RCVf5Df2uCXwPveXz LBGIjsz3k2la5UUlioC+i4Ms6vGstqXIX7K24+Wc41npi+G5xFhvkAkmuTP/j29F5xJJuJcy3OcL 0br02vKe2WJJnlivB+X9plPg0kMUBS0lLq7kHPUrO/BLeIIFRuaky05eZlTnGNcLbn5VpZdjX4Ic XZV78qpZI3L67Po1UgHzOTiWolc75jrKOx3UOw98fWRrgJPBUIeqDeD1NDfF7PlM4Cqlad062o6L lM9wfAnoLzz0z04dPXtJkOcTiZgOLdPoKIm7LR1wZ9c6mYw4sgtoVAs16Y2cCPBxqWpsW+9ZCcDK PPZzeBezCKyicpDJbTqCVMILd3j38HWUPWFuVITZNgANzHW1CpgqmiLIAADiznCCtudTE+fcB3O9 duuu/yuEME17LMy1GYMKXs1QCXmTq2hrqTJQ2AA2TsWZtoxl3ViqJgNBWjnQiMwdCl5Dural2jZP /iU6MmiauUNYn9YW/ViUluoBBdaUHMpnP/7kM0Wk8j3Wzhcggx+Biml2gCopMaK1EJYjQH/2J95N GEkSdZfVzFUmwV3yMd4mOhIaxW0SEq9b1eWICZ/BAcVBpSyU0sE1gpnBO5wLxj+IpSdiGlS4jc37 qCr/39xdv1Unu93glCmHq0xgX54N8EsyMBPC3+zSSu1qhCbU7VJWIz2aMIIGwjCCBKqgAwIBAgIQ U7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0BAQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEf MB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcx MjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nz b24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy 3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5DtjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt 8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6j RrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1NwkTepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFl hFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJkwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/2 0aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCY rEqHMRaojI/VStloQgW76E76zQ2byw5QxrhOUbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuT LUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMd ay0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP05tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqd GTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QLsgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMB AAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVz dC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9j cmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpec dqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PLFpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5 s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUbAL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90 BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRy pF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86 IWst821ww0wxsCpEfClIvF7fBw2QkbG/1PwuzAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QD Xnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7 C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbN QUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbH XSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i 6Ds5j0Qpj5aQMYIDBTCCAwECAQEwXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MAkGBSsOAwIaBQCgggF+MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTE5MDkzMDA5MjAzOFowIwYJKoZIhvcNAQkEMRYEFHZsSD5XUH8glSdhsNH/57f9vBOmMEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQC6Q7Htxd8QCc6EbaEXMjYojQbDuVS2KO63M8KsiagO66krxv1Bhx54 5ped3cRy6Ewz4F/pA/SmZELueiXQaBLyKzk4OCgxecKAl6MCMd48qSNF9IPOnnxfKjZw9VWMHp4A NdgvPbKC3JTLRY1EYx0Dc3uIUIK9JXjgZwaudd00fXNiJ3T0dq8EElHbgglY2Y++EBx6TDxH9Ly8 Ud1fFxmGzQB1YiY71TqTrQw6kovTNsSxVwkzQ6EUfbk/BTcRdNNsj1BoeWi/3CBx2MyDasaxXQTh l5BlyUQPzckICaEHZD5EvD6nt0bAT5V9c+ETcoS72+5YP5llZNYRxrvQt8pOAAAAAAAA ------=_NextPart_000_052A_01D57781.167328B0-- From nobody Mon Sep 30 07:44:56 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6689312008B for ; Mon, 30 Sep 2019 07:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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=jyoTCd1W; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=taLkkHjR 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 v_EAfkgLBTb4 for ; Mon, 30 Sep 2019 07:44:52 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ECF81200B9 for ; Mon, 30 Sep 2019 07:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28020; q=dns/txt; s=iport; t=1569854692; x=1571064292; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=atejsqRNxDlxctaiz/D6xxyrDZkYofCoPqUbBLf5eVg=; b=jyoTCd1WRKNcMF/AnjzgztlmW3vv5uP8wN5rvtZ8pUgj4HYGlIoAD6fb ApxCVzDaHoz7FZd0lTM2ZP3+gUVzFV4Jm7crPrasiCR9iJ0MXfSDOeoZR A4+NzyGPtXXoTevZkvrEEUHt05P4iXgpCFcoSaAVGk6DmHiuQ9FkDrF+d A=; IronPort-PHdr: =?us-ascii?q?9a23=3A2W3HGRNvmvk8Tg/2t7El6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjhM//ucys8NM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AjAAB5FJJd/4wNJK1cChsBAQEBAwE?= =?us-ascii?q?BAQwDAQEBgVMGAQEBCwGBGy8kLANtViAECyqEIoNHA4RShgdNgg9+iGmOD4E?= =?us-ascii?q?uFIEQA1QJAQEBDAEBJQgCAQGBTIJ0AheDLCM0CQ4CAwkBAQQBAQECAQUEbYU?= =?us-ascii?q?tDIVLAQEBAQMSEQoTAQE1Aw8CAQYCDgMEAQEOEwcDAgICHxEUCQgCBAESCBq?= =?us-ascii?q?DAYEdTQMdAQIMkWqQYQKBOIhhdYEygn0BAQWBOAKDSA0LghcDBoE0AYpigSs?= =?us-ascii?q?YgUA/gRFGgU5JNT6CGkcBAQOBMwUOAhgrCYJXMoImjS+CNoUtl1BBCoIihwW?= =?us-ascii?q?KBIQdgjeHTo1SgV+OIYE9hluCCo59AgQCBAUCDgEBBYFSOSqBLnAVgydQEBS?= =?us-ascii?q?BT4NzhRSFP3SBKY0mASQHgicBAQ?= X-IronPort-AV: E=Sophos;i="5.64,567,1559520000"; d="scan'208,217";a="418772938" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Sep 2019 14:44:51 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x8UEip2i014430 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 30 Sep 2019 14:44:51 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 30 Sep 2019 09:44:50 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 30 Sep 2019 09:44:49 -0500 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 30 Sep 2019 10:44:49 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=miOm3LKgWm34TnH7TN9plB4PWxXGjfT+epd2QH6Dm68B7r7ehGaISb8DAgG6Ng/j/04ZCM4V7kFiQorXHYf3YEArdDPbAp5uJJoVez+IjXJlosP2JzOs3xmRlfcroD1C0k27ODFEaX8xFSfgHExOs1omIYzVRBCmvuS8IJbF+doqfAsXoFay3GRbRbUYmHj7HsXjkA664F6SdND/Tn1UIhpooYsiCC7iYmxSJ8xeSmcT97PyOxG+zk1SVwOHf9AmBlicc8NFtws67Ix1v5z6z0W4WYX5eWdiGpVwsWkQrmXVKvbV4ZKT7UzcRY7Q635UTrKh8PSL7m8Lgexjwc4FGw== 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=atejsqRNxDlxctaiz/D6xxyrDZkYofCoPqUbBLf5eVg=; b=P30iA4U4UEEjV2b5wzXS9GK09QMhlLoy0eRyE5AqfP0O4Q9lSx8Xp9ddjxpJvMi6BfHQeywd+/CGR8oxNiJR0mpK6E+9N285xxtgLQPVeHLpLOC2gT9dSnbpMDnPwB1s0o8nmEMDujN5zanmtpHIuAKCSqpAO+KwYUNtmS/b0gByei27VNQZCqTTxvO/L+g1rqPzxsBGOMv5S99fFolsQRcoPKu9AVd1ArH1te2jSNs7aJ/2S53hJpaXvHD5lemvw8v5h50SkhINvEnASBylCSzbybn1ZSOzh5NFfOW8V7j7dtOJAhYqmUy9LdXrYiC5DgcNtB6vbAsFwaMD8cS8Wg== 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=atejsqRNxDlxctaiz/D6xxyrDZkYofCoPqUbBLf5eVg=; b=taLkkHjRx84ieJW4pxDZtfnRz0t3aVDpmXrqyI/Jtt4/bvN82xztMXZ2shO7ah/CMqXmwAvyCDCATkKvw0MVTb32WaEeT04ID2h2mrC2awcpL5D/RvoIHSQRhiKaxQPHzBiP550A7QtDocfUU/5wIhPY1pGfSFmDTT02LHfON9M= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3693.namprd11.prod.outlook.com (20.178.252.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.20; Mon, 30 Sep 2019 14:44:48 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::cca:41bd:b0bb:c549]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::cca:41bd:b0bb:c549%2]) with mapi id 15.20.2305.017; Mon, 30 Sep 2019 14:44:48 +0000 From: "Rob Wilton (rwilton)" To: Mahesh Jethanandani , Netconf , =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= Thread-Topic: [netconf] WGLC for draft-ietf-netconf-notification-capabilities Thread-Index: AQHVaCiuRGm9KKbjG02ELVvMwRO/n6c7MLcAgAkj1tA= Date: Mon, 30 Sep 2019 14:44:48 +0000 Message-ID: References: <4F49DF08-B7FC-4EBD-9D6B-7BC329E50334@gmail.com> In-Reply-To: <4F49DF08-B7FC-4EBD-9D6B-7BC329E50334@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [2001:420:c0c0:1005::147] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 492a0696-aa15-47ca-af40-08d745b4be27 x-ms-traffictypediagnostic: MN2PR11MB3693: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01762B0D64 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(366004)(39860400002)(376002)(396003)(189003)(199004)(51444003)(71200400001)(46003)(76176011)(6306002)(7110500001)(54896002)(236005)(55016002)(25786009)(6436002)(14454004)(71190400001)(15650500001)(2420400007)(6246003)(9686003)(66446008)(66476007)(476003)(64756008)(33656002)(66556008)(9326002)(606006)(14444005)(76116006)(81156014)(790700001)(81166006)(66946007)(8936002)(52536014)(256004)(186003)(6116002)(86362001)(229853002)(6506007)(11346002)(99286004)(110136005)(102836004)(5660300002)(7736002)(2906002)(316002)(446003)(486006)(7696005)(53546011)(478600001)(8676002)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3693; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /XlPYqbuNVfLJeBDqzEJY2tMRQXzM5r4aN+WQmunwARJjbmR1zE67B4W4RRYcHBiclEU/H0VerqwEOcOq7pVOY2kcDxS03CgZUEZVs7frlKayofrB3CHZHFZY31LCxzB5ENa2vAgM0ytk6GJ+2Fqgfj+DMOmMIfGwV8ZdJw2UFYAg3VmJ6Ia7qxfS8xN51RnKBxZxh3RCpFwWa3aVoPfNmARyLmOkN3sr/f2DFZvZyWEIf1/6n1M2PpbWgtmhpdTw14K/d7ddICNTLEinW91yQn02SC+Oy8WdbEop8MtRB3Ss6Bj/8pP65MUlz1i/jt43Ixhu+h+bXlS+17F0QoCMc6UyQa5abcrzIUzZquj8fDF6NVGOMHKN5jzNySTxbJrqSPA9SaAkpOd8w9ltfgNPIFLCPfxrkmaSyjKeRp3HjsEaztOSwf7emJmJmqRijammjOBwGiBfliHRPaAD7czqA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB43663B72FBA8D839E539A001B5820MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 492a0696-aa15-47ca-af40-08d745b4be27 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2019 14:44:48.2546 (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: r1aF7xw65/kA+I6ZcP3VVp4Jldis9CHPi0S3tYkD6xR5+glPr6wF3PvkyJQx5Lyt7KHPrJ76Qn7B4p7QX3w/tw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3693 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.21, xch-rcd-011.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2019 14:44:55 -0000 --_000_MN2PR11MB43663B72FBA8D839E539A001B5820MN2PR11MB4366namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgaGF2ZSByZXZpZXdlZCB2ZXJzaW9uIC0wNWIgb2YgdGhpcyBkb2N1bWVudC4NCg0K SSBhbSBzdXBwb3J0aXZlIG9mIHRoaXMgZG9jdW1lbnQsIGFuZCBpdHMgZ2VuZXJhbCBhcHByb2Fj aCBvZiBtYWtpbmcgc3Vic2NyaXB0aW9uIGNhcGFiaWxpdHkgaW5mb3JtYXRpb24gYXZhaWxhYmxl IGJvdGggb25saW5lIGFuZCBvZmZsaW5lLiAgSSBiZWxpZXZlIHRoYXQgdGhpcyBpbmZvcm1hdGlv biBpcyB2YWx1YWJsZSB0byBtYWtpbmcgWUFORy1QdXNoIG1vcmUgdXNhYmxlLg0KDQpBIGZldyBj b21tZW50czoNCg0KICAxLiAgVGVybWlub2xvZ3kgYW5kIEludHJvZHVjdGlvbi4gIEkgd2FzbuKA mXQgc3VyZSB3aGV0aGVyIOKAnGltcGxlbWVudGF0aW9uLXRpbWUgaW5mb3JtYXRpb27igJ0gaXMg dGhlIGJlc3QgZGVzY3JpcHRpb24sIG9yIHdoZXRoZXIg4oCcb2ZmbGluZSBpbmZvcm1hdGlvbuKA nSB3b3VsZCBiZSBhIGJldHRlciBkZXNjcmlwdGlvbi4gICBJIGJlbGlldmUgdGhhdCB0aGUga2V5 IGlzIHRoYXQgdGhlIGluZm9ybWF0aW9uIGlzIGF2YWlsYWJsZSBvZmZsaW5lIHdpdGhvdXQgcmVx dWlyaW5nIGFjY2VzcyB0byBhbGwgdGhlIG5ldHdvcmsgZGV2aWNlcy4gIEFsdGhvdWdoIEkgY2Fu IHNlZSB0aGF0IHByb3ZpZGluZyB0aGlzIGluZm9ybWF0aW9uIGF0IGltcGxlbWVudGF0aW9uIHRp bWUgaXMgdXNlZnVsIGFuZCBzaG91bGQgYmUgUkVDT01NRU5ERUQsIEkgZG9u4oCZdCB0aGluayB0 aGF0IGl0IHNob3VsZCBiZSBhIE1VU1QvU0hBTEwgKGUuZy4gYXMgcGVyIHNlY3Rpb24gMykuDQog IDIuICBBbm90aGVyIGJlbmVmaXQgb2YgaGF2aW5nIGluZm9ybWF0aW9uIGF2YWlsYWJsZSBvZmZs aW5lIGlzIHRoYXQgaWYgdGhlcmUgYXJlIGNsYXNzZXMgb2YgZGV2aWNlcyBydW5uaW5nIHRoZSBz YW1lIHNvZnR3YXJlIGFuZCBoYXJkd2FyZSB0aGVuIHRoZXkgc2hvdWxkIGFsbCBoYXZlIHRoZSBz YW1lIGNhcGFiaWxpdGllcyB3aXRob3V0IGhhdmluZyB0byBjaGVjayBlYWNoIGFuZCBldmVyeSBv bmUuICBUbyB0aGlzIGVuZCwgaXQgd291bGQgYmUgbmljZSBpZiB0aGVyZSB3YXMgc29tZSBzb3J0 IG9mIHNpbXBsZSBjaGVja3N1bSBtZWNoYW5pc20gdGhhdCBjb3VsZCBiZSB1c2VkIHRvIGVuc3Vy ZSB0aGF0IHRoZSBpbmZvcm1hdGlvbiBzdG9yZWQgaW4gdGhlIGluc3RhbmNlLWRhdGEgZmlsZSBl eGFjdGx5IG1hdGNoZXMgdGhlIGVxdWl2YWxlbnQgaW5mb3JtYXRpb24gcHJvdmlkZWQgYnkgdGhl IHNlcnZlci4gIFRoaXMgd291bGQgYWxsb3dzIE5NUyBpbXBsZW1lbnRhdGlvbnMgdG8gYmUgY29k ZWQgdG8gdGhlIGluc3RhbmNlLWRhdGEgZG9jdW1lbnQsIGFuZCB0aGVuIGp1c3QgdmFsaWRhdGUg dGhhdCB0aGUgY2hlY2tzdW1zIG1hdGNoIHRob3NlIHByb3ZpZGVkIGJ5IHRoZSBzZXJ2ZXIgd2l0 aG91dCBoYXZpbmcgdG8gZmV0Y2ggYW5kIGNoZWNrIHRoYXQgYSBwb3J0aW9uIG9mIHRoZSBkYXRh IHRyZWUgbWF0Y2hlcy4gIEFzIGEgc2lkZSBub3RlIOKAkyBZQU5HIHBhY2thZ2VzIGhhcyBhIHNp bWlsYXIgcmVxdWlyZW1lbnQuDQogIDMuICBTZWN0aW9uIDMsIGJ5IOKAnGZvcm1hbOKAnSwgZG8g eW91IG1lYW4g4oCcbWFjaGluZSByZWFkYWJsZeKAnT8gIE90aGVyd2lzZSBleHBhbmRpbmcgd2hh dCBpcyBtZWFudCBieSBmb3JtYWwgbWlnaHQgYmUgdXNlZnVsLg0KICA0LiAgU2VjdGlvbiAzLCBp bnN0ZWFkIG9mIOKAnGFtb3VudCBvZiBub3RpZmljYXRpb25z4oCdIHdvdWxkIOKAnHRocm91Z2hw dXQgb2Ygbm90aWZpY2F0aW9uIGRhdGHigJ0gYmUgYmV0dGVyPw0KDQpJbiB0ZXJtcyBvZiB0aGUg WUFORyBtb2RlbCwgSSB0aGluayB0aGF0IGl0IGlzIHBvc3NpYmxlIHRvIGRlc2lnbiB0aGlzIGlu IGEgc2xpZ2h0bHkgbW9yZSByZWd1bGFyIChhbmQgYXJndWFibHkgc2ltcGxlcikgd2F5Og0KDQog ICogICBSZW5hbWUg4oCcZGF0YXN0b3JlLXN1YnNjcmlwdGlvbi10aHJvdWdocHV0LWNhcGFiaWxp dGllcyBncm91cGluZ+KAnSB0byDigJxzdWJzY3JpcHRpb24tdGhyb3VnaHB1dC1jYXBhYmlsaXRp ZXPigJ0gKHNpbmNlIHRoZSBncm91cGluZyBpcyBhbHNvIHVzZWQgYXQgdGhlIHN1YnNjcmlwdGlv biBsZXZlbCkNCiAgKiAgIEFkZCDigJxvbi1jaGFuZ2Utc3VwcG9ydGVk4oCdIGxlYWYgdG8g4oCc c3Vic2NyaXB0aW9uLXRocm91Z2hwdXQtY2FwYWJpbGl0aWVz4oCdIGdyb3VwaW5nLCBidXQgY2hh bmdlIGl0cyB0eXBlIHRvIGFuIGVudW0gb2Yg4oCcYWxsLW5vZGVzLCBjb25maWctb25seSwgc3Rh dGUtb25seeKAnSDigJMgdGhpcyBjb3VsZCB0aGVuIHdvcmsgaW4gYSBmdWxseSBoaWVyYXJjaGlj YWwgd2F5LiAgKEkuZS4gdGhlIGV4aXN0aW5nIG9uLWNoYW5nZS1zdXBwb3J0ZWQtZm9yLWNvbmZp Zywgb24tY2hhbmdlLXN1cHBvcnRlZC1mb3Itc3RhdGUgLCBvbi1jaGFuZ2Utc3VwcG9ydGVkIGNv dWxkIGJlIHJlbW92ZWQpLg0KICAqICAgSW5zdGVhZCBvZiBoYXZpbmcgYSBzZXQgb2Yg4oCcZGF0 YXN0b3Jl4oCdIGxldmVsIHBhcmFtZXRlcnMsIGNvdWxkIHRoZXNlIGp1c3QgYmUgZXhwcmVzc2Vk IGFzIHRoZSBzZXQgb2YgcGFyYW1ldGVycyB0aGF0IGFwcGx5IHRvIOKAnC/igJ0gd2l0aGluIGEg ZGF0YXN0b3JlIChlLmcuIGFzIGRlc2NyaWJlZCBpbiBOQUNNIFlBTkcgbW9kdWxlIOKAnGxlYWYg cGF0aOKAnCk/ICBJLmUuIGdpdmVuIHRoYXQgeW91IHN1cHBvcnQgaGllcmFyY2hpY2FsIHBhdGhz IHdpdGhpbiBhIGRhdGFzdG9yZSwgaXQganVzdCBtZWFucyB0aGF0IHlvdSBuZWVkIHR3byBsZXZl bHMsIHBlciBkZXZpY2UgYW5kIHBlciBkYXRhc3RvcmUuDQogICogICBJZGVhbGx5LCBpdCB3b3Vs ZCBiZSBiZXR0ZXIgdG8gaGF2ZSBhIGRlcGVuZGVuY3kgb24gUkZDNjk5MS1iaXMgZm9yIG5vZGUt aW5zdGFuY2UtaWRlbnRpZnkgcmF0aGVyIHRoYW4gb24gTkFDTS4gIEFsdGhvdWdoIEkgZ3Vlc3Mg dGhhdCB5b3UgbWF5IG5vdCB3YW50IHRvIGRlbGF5IHRoaXMgUkZDLg0KICAqICAgQ3VycmVudGx5 IOKAnGxlYWYgb24tY2hhbmdlLXN1cHBvcnRlZOKAnSBpcyBtYXJrZWQgYXMgbWFuZGF0b3J5IHRy dWUsIGJ1dCBJ4oCZbSBub3Qgc3VyZSB3aHkgaXQgc2hvdWxkIGJlIHNvLg0KICAqICAgSXMg4oCc bWF4LW9iamVjdHMtcGVyLXVwZGF0ZeKAnSBvcHRpb25hbC4gIFdoYXQgaWYgdGhlIHNlcnZlciBk b2VzbuKAmXQgaGF2ZSBhbnkgaGFyZCBsaW1pdCAtIGNhbiB0aGV5IGp1c3Qgbm90IHJldHVybiBh IHZhbHVlIGhlcmU/ICBJZiBzbywgcGVyaGFwcyBhc3NpZ25pbmcgYSBkZWZhdWx0IHZhbHVlIG9m IHVpbnQzMl9tYXggbWlnaHQgbWFrZSBzZW5zZT8NCg0KSW4gdGhlIHNlY3VyaXR5IHNlY3Rpb24s IGFyZSB0aGVzZSBjYXBhYmlsaXRpZXMgc2Vuc2l0aXZlIGluZm9ybWF0aW9uPyAgRS5nLiBjb3Vs ZCBpdCBiZSB1c2VkIGJ5IGFuIGF0dGFja2VyIHRvIG1vcmUgZWZmZWN0aXZlbHkgRERPUyBhIHNl cnZlciAoYnkga25vd2luZyB3aGljaCBwYXRocyB0byB0YXJnZXQgc3VzYnNjcmlwdGlvbnMgdG93 YXJkcyk/DQoNClRoYW5rcywNClJvYg0KDQoNCkZyb206IG5ldGNvbmYgPG5ldGNvbmYtYm91bmNl c0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIE1haGVzaCBKZXRoYW5hbmRhbmkNClNlbnQ6IDI0IFNl cHRlbWJlciAyMDE5IDE4OjUwDQpUbzogTmV0Y29uZiA8bmV0Y29uZkBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbbmV0Y29uZl0gV0dMQyBmb3IgZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlv bi1jYXBhYmlsaXRpZXMNCg0KV2Ugd2VyZSBzdXBwb3NlZCB0byBoYXZlIGNsb3NlZCBvbiB0aGUg V0dMQyB0b2RheS4gSG93ZXZlciwgYmV0d2VlbiB0aGUgZG9jdW1lbnQgYmVjb21pbmcgYSBXRyBp dGVtIGFuZCBpdCBnb2luZyBpbnRvIExDLCB3ZSBoYXZlIG5vdCByZWNlaXZlZCB0b28gbWFueSBj b21tZW50cyBvbiB0aGUgZHJhZnQuIEFzIHN1Y2gsIHdlIGFyZSBleHRlbmRpbmcgdGhlIExDIGJ5 IGFub3RoZXIgd2Vlay4gUGxlYXNlIHJldmlldyB0aGUgZHJhZnQgYW5kIHByb3ZpZGUgYW55IGNv bW1lbnRzIHlvdSBtaWdodCBoYXZlLg0KDQpNYWhlc2ggJiBLZW50IChhcyBjby1jaGFpcnMpDQoN Cg0KDQpPbiBTZXAgMTAsIDIwMTksIGF0IDM6MzkgUE0sIE1haGVzaCBKZXRoYW5hbmRhbmkgPG1q ZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4+IHdy b3RlOg0KDQpBdXRob3JzIGhhdmUgcHVibGlzaGVkIC0wNDxodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMtMDQ+IHZl cnNpb24gb2YgdGhlIGRyYWZ0LCB3aGljaCBhZGRyZXNzZXMgY29tbWVudHMgdGhleSByZWNlaXZl ZCBpbiBJRVRGIDEwNS4gSWYgeW91IHByb3ZpZGVkIGNvbW1lbnRzIHBsZWFzZSBjaGVjayB0byBt YWtlIHN1cmUgeW91ciBjb21tZW50cyBoYXZlIGJlZW4gYWRkcmVzc2VkLiBBdCB0aGlzIHBvaW50 LCB0aGUgYXV0aG9ycyBiZWxpZXZlIHRoYXQgdGhlIGRvY3VtZW50IGlzIHJlYWR5IGZvciBXR0xD Lg0KDQpUaGlzIHRoZXJlZm9yZSBzdGFydHMgYSB0d28gd2VlayBMQywgZW5kaW5nIG9uIFNlcHRl bWJlciAyNHRoLiBQbGVhc2UgcHJvdmlkZSBhbnkgdGVjaG5pY2FsIGNvbW1lbnRzIHlvdSBtaWdo dCBoYXZlIG9uIHRoZSBkb2N1bWVudC4gSWYgeW91IGJlbGlldmUgdGhlIGRvY3VtZW50IGlzIG5v dCByZWFkeSBmb3IgTEMsIHBsZWFzZSBzdGF0ZSB5b3VyIHJlYXNvbnMuDQoNCldlIHdpbGwgaXNz dWUgYSBJUFIgcG9sbCBzZXBhcmF0ZWx5Lg0KDQpNYWhlc2ggJiBLZW50IChhcyBjby1jaGFpcnMp DQoNCg0KDQoNCg== --_000_MN2PR11MB43663B72FBA8D839E539A001B5820MN2PR11MB4366namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3Jh cGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHls ZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1h cmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6MTU1NDE0ODc3MjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6LTYwMDU1MDc3NiAxMzM0NzI1MDUwIDEzNDgwNzU1NSAxMzQ4MDc1NTcgMTM0 ODA3NTUzIDEzNDgwNzU1NSAxMzQ4MDc1NTcgMTM0ODA3NTUzIDEzNDgwNzU1NSAxMzQ4MDc1NTc7 fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMC41cHQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFz dC1mb250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6 NTYuNXB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6OTIuNXB0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgltYXJnaW4tbGVmdDoxMjguNXB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTY0LjVwdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIwMC41cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1h cmdpbi1sZWZ0OjIzNi41cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyNzIuNXB0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MzA4LjVwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxOTA2OTE1 NzM0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczozMzAz Mzc4OTggMTM0ODA3NTY3IDEzNDgwNzU3NyAxMzQ4MDc1NzkgMTM0ODA3NTY3IDEzNDgwNzU3NyAx MzQ4MDc1NzkgMTM0ODA3NTY3IDEzNDgwNzU3NyAxMzQ4MDc1Nzk7fQ0KQGxpc3QgbDE6bGV2ZWwx DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9 DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpy aWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0 LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0O30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4w cHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgaGF2ZSBy ZXZpZXdlZCB2ZXJzaW9uIC0wNWIgb2YgdGhpcyBkb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBhbSBzdXBwb3J0 aXZlIG9mIHRoaXMgZG9jdW1lbnQsIGFuZCBpdHMgZ2VuZXJhbCBhcHByb2FjaCBvZiBtYWtpbmcg c3Vic2NyaXB0aW9uIGNhcGFiaWxpdHkgaW5mb3JtYXRpb24gYXZhaWxhYmxlIGJvdGggb25saW5l IGFuZCBvZmZsaW5lLiZuYnNwOyBJIGJlbGlldmUgdGhhdCB0aGlzIGluZm9ybWF0aW9uIGlzIHZh bHVhYmxlIHRvIG1ha2luZw0KIFlBTkctUHVzaCBtb3JlIHVzYWJsZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QSBmZXcgY29t bWVudHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIg c3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRlcm1pbm9sb2d5IGFuZCBJbnRyb2R1Y3Rpb24uJm5i c3A7IEkgd2FzbuKAmXQgc3VyZSB3aGV0aGVyIOKAnGltcGxlbWVudGF0aW9uLXRpbWUgaW5mb3Jt YXRpb27igJ0gaXMgdGhlIGJlc3QgZGVzY3JpcHRpb24sIG9yIHdoZXRoZXIg4oCcb2ZmbGluZSBp bmZvcm1hdGlvbuKAnQ0KIHdvdWxkIGJlIGEgYmV0dGVyIGRlc2NyaXB0aW9uLiAmbmJzcDsmbmJz cDtJIGJlbGlldmUgdGhhdCB0aGUga2V5IGlzIHRoYXQgdGhlIGluZm9ybWF0aW9uIGlzIGF2YWls YWJsZSBvZmZsaW5lIHdpdGhvdXQgcmVxdWlyaW5nIGFjY2VzcyB0byBhbGwgdGhlIG5ldHdvcmsg ZGV2aWNlcy4gJm5ic3A7QWx0aG91Z2ggSSBjYW4gc2VlIHRoYXQgcHJvdmlkaW5nIHRoaXMgaW5m b3JtYXRpb24gYXQgaW1wbGVtZW50YXRpb24gdGltZSBpcyB1c2VmdWwgYW5kIHNob3VsZCBiZSBS RUNPTU1FTkRFRCwNCiBJIGRvbuKAmXQgdGhpbmsgdGhhdCBpdCBzaG91bGQgYmUgYSBNVVNUL1NI QUxMIChlLmcuIGFzIHBlciBzZWN0aW9uIDMpLiA8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDps MSBsZXZlbDEgbGZvMSI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5B bm90aGVyIGJlbmVmaXQgb2YgaGF2aW5nIGluZm9ybWF0aW9uIGF2YWlsYWJsZSBvZmZsaW5lIGlz IHRoYXQgaWYgdGhlcmUgYXJlIGNsYXNzZXMgb2YgZGV2aWNlcyBydW5uaW5nIHRoZSBzYW1lIHNv ZnR3YXJlIGFuZCBoYXJkd2FyZSB0aGVuDQogdGhleSBzaG91bGQgYWxsIGhhdmUgdGhlIHNhbWUg Y2FwYWJpbGl0aWVzIHdpdGhvdXQgaGF2aW5nIHRvIGNoZWNrIGVhY2ggYW5kIGV2ZXJ5IG9uZS4m bmJzcDsgVG8gdGhpcyBlbmQsIGl0IHdvdWxkIGJlIG5pY2UgaWYgdGhlcmUgd2FzIHNvbWUgc29y dCBvZiBzaW1wbGUgY2hlY2tzdW0gbWVjaGFuaXNtIHRoYXQgY291bGQgYmUgdXNlZCB0byBlbnN1 cmUgdGhhdCB0aGUgaW5mb3JtYXRpb24gc3RvcmVkIGluIHRoZSBpbnN0YW5jZS1kYXRhIGZpbGUg ZXhhY3RseQ0KIG1hdGNoZXMgdGhlIGVxdWl2YWxlbnQgaW5mb3JtYXRpb24gcHJvdmlkZWQgYnkg dGhlIHNlcnZlci4mbmJzcDsgVGhpcyB3b3VsZCBhbGxvd3MgTk1TIGltcGxlbWVudGF0aW9ucyB0 byBiZSBjb2RlZCB0byB0aGUgaW5zdGFuY2UtZGF0YSBkb2N1bWVudCwgYW5kIHRoZW4ganVzdCB2 YWxpZGF0ZSB0aGF0IHRoZSBjaGVja3N1bXMgbWF0Y2ggdGhvc2UgcHJvdmlkZWQgYnkgdGhlIHNl cnZlciB3aXRob3V0IGhhdmluZyB0byBmZXRjaCBhbmQgY2hlY2sgdGhhdA0KIGEgcG9ydGlvbiBv ZiB0aGUgZGF0YSB0cmVlIG1hdGNoZXMuJm5ic3A7IEFzIGEgc2lkZSBub3RlIOKAkyBZQU5HIHBh Y2thZ2VzIGhhcyBhIHNpbWlsYXIgcmVxdWlyZW1lbnQuPG86cD48L286cD48L3NwYW4+PC9saT48 bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxp c3Q6bDEgbGV2ZWwxIGxmbzEiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+U2VjdGlvbiAzLCBieSDigJxmb3JtYWzigJ0sIGRvIHlvdSBtZWFuIOKAnG1hY2hpbmUgcmVh ZGFibGXigJ0/Jm5ic3A7IE90aGVyd2lzZSBleHBhbmRpbmcgd2hhdCBpcyBtZWFudCBieSBmb3Jt YWwgbWlnaHQgYmUgdXNlZnVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwxIGxldmVsMSBs Zm8xIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlNlY3Rpb24gMywg aW5zdGVhZCBvZiDigJxhbW91bnQgb2Ygbm90aWZpY2F0aW9uc+KAnSB3b3VsZCDigJx0aHJvdWdo cHV0IG9mIG5vdGlmaWNhdGlvbiBkYXRh4oCdIGJlIGJldHRlcj8NCjxvOnA+PC9vOnA+PC9zcGFu PjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JbiB0 ZXJtcyBvZiB0aGUgWUFORyBtb2RlbCwgSSB0aGluayB0aGF0IGl0IGlzIHBvc3NpYmxlIHRvIGRl c2lnbiB0aGlzIGluIGEgc2xpZ2h0bHkgbW9yZSByZWd1bGFyIChhbmQgYXJndWFibHkgc2ltcGxl cikgd2F5OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowY20i IHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LTE1LjVwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlbmFtZSDigJxkYXRhc3RvcmUtc3Vic2NyaXB0aW9u LXRocm91Z2hwdXQtY2FwYWJpbGl0aWVzIGdyb3VwaW5n4oCdIHRvIOKAnHN1YnNjcmlwdGlvbi10 aHJvdWdocHV0LWNhcGFiaWxpdGllc+KAnSAoc2luY2UgdGhlIGdyb3VwaW5nIGlzIGFsc28gdXNl ZCBhdCB0aGUgc3Vic2NyaXB0aW9uIGxldmVsKTxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LTE1LjVwdDttc28tbGlz dDpsMCBsZXZlbDEgbGZvMiI+DQo8c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPkFkZCDigJxvbi1jaGFuZ2Utc3VwcG9ydGVk4oCdIGxlYWYgdG8g4oCcc3Vic2NyaXB0aW9u LXRocm91Z2hwdXQtY2FwYWJpbGl0aWVz4oCdIGdyb3VwaW5nLCBidXQgY2hhbmdlIGl0cyB0eXBl IHRvIGFuIGVudW0gb2Yg4oCcYWxsLW5vZGVzLCBjb25maWctb25seSwgc3RhdGUtb25seeKAnSDi gJMgdGhpcyBjb3VsZCB0aGVuIHdvcmsgaW4gYSBmdWxseSBoaWVyYXJjaGljYWwgd2F5LiZuYnNw OyAoSS5lLiB0aGUNCiBleGlzdGluZyBvbi1jaGFuZ2Utc3VwcG9ydGVkLWZvci1jb25maWcsIG9u LWNoYW5nZS1zdXBwb3J0ZWQtZm9yLXN0YXRlICwgb24tY2hhbmdlLXN1cHBvcnRlZCBjb3VsZCBi ZSByZW1vdmVkKS48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi0xNS41cHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIi Pg0KPHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JbnN0ZWFkIG9mIGhh dmluZyBhIHNldCBvZiDigJxkYXRhc3RvcmXigJ0gbGV2ZWwgcGFyYW1ldGVycywgY291bGQgdGhl c2UganVzdCBiZSBleHByZXNzZWQgYXMgdGhlIHNldCBvZiBwYXJhbWV0ZXJzIHRoYXQgYXBwbHkg dG8g4oCcL+KAnSB3aXRoaW4gYSBkYXRhc3RvcmUgKGUuZy4gYXMgZGVzY3JpYmVkIGluIE5BQ00g WUFORyBtb2R1bGUg4oCcPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+bGVhZg0KIHBh dGg8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj7igJwpPyZu YnNwOyBJLmUuIGdpdmVuIHRoYXQgeW91IHN1cHBvcnQgaGllcmFyY2hpY2FsIHBhdGhzIHdpdGhp biBhIGRhdGFzdG9yZSwgaXQganVzdCBtZWFucyB0aGF0IHlvdSBuZWVkIHR3byBsZXZlbHMsIHBl ciBkZXZpY2UgYW5kIHBlciBkYXRhc3RvcmUuPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDotMTUuNXB0O21zby1saXN0 OmwwIGxldmVsMSBsZm8yIj4NCjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+SWRlYWxseSwgaXQgd291bGQgYmUgYmV0dGVyIHRvIGhhdmUgYSBkZXBlbmRlbmN5IG9uIFJG QzY5OTEtYmlzIGZvciBub2RlLWluc3RhbmNlLWlkZW50aWZ5IHJhdGhlciB0aGFuIG9uIE5BQ00u Jm5ic3A7IEFsdGhvdWdoIEkgZ3Vlc3MgdGhhdCB5b3UgbWF5IG5vdCB3YW50IHRvIGRlbGF5IHRo aXMgUkZDLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LTE1LjVwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkN1cnJlbnRseSDigJxsZWFm IG9uLWNoYW5nZS1zdXBwb3J0ZWTigJ0gaXMgbWFya2VkIGFzIG1hbmRhdG9yeSB0cnVlLCBidXQg SeKAmW0gbm90IHN1cmUgd2h5IGl0IHNob3VsZCBiZSBzby48bzpwPjwvbzpwPjwvc3Bhbj48L2xp PjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi0xNS41cHQ7 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5JcyDigJxtYXgtb2JqZWN0cy1wZXItdXBkYXRl4oCdIG9wdGlvbmFsLiZuYnNw OyBXaGF0IGlmIHRoZSBzZXJ2ZXIgZG9lc27igJl0IGhhdmUgYW55IGhhcmQgbGltaXQgLSBjYW4g dGhleSBqdXN0IG5vdCByZXR1cm4gYSB2YWx1ZSBoZXJlPyZuYnNwOyBJZiBzbywgcGVyaGFwcyBh c3NpZ25pbmcgYSBkZWZhdWx0IHZhbHVlIG9mIHVpbnQzMl9tYXggbWlnaHQgbWFrZSBzZW5zZT88 bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+SW4gdGhlIHNlY3VyaXR5IHNlY3Rpb24sIGFyZSB0aGVzZSBjYXBhYmlsaXRp ZXMgc2Vuc2l0aXZlIGluZm9ybWF0aW9uPyZuYnNwOyBFLmcuIGNvdWxkIGl0IGJlIHVzZWQgYnkg YW4gYXR0YWNrZXIgdG8gbW9yZSBlZmZlY3RpdmVseSBERE9TIGEgc2VydmVyIChieSBrbm93aW5n IHdoaWNoIHBhdGhzIHRvIHRhcmdldCBzdXNic2NyaXB0aW9ucyB0b3dhcmRzKT88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhh bmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Um9iPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IG5ldGNvbmYgJmx0O25ldGNv bmYtYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+TWFoZXNoIEpldGhh bmFuZGFuaTxicj4NCjxiPlNlbnQ6PC9iPiAyNCBTZXB0ZW1iZXIgMjAxOSAxODo1MDxicj4NCjxi PlRvOjwvYj4gTmV0Y29uZiAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtuZXRjb25mXSBXR0xDIGZvciBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0 aW9uLWNhcGFiaWxpdGllczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5XZSB3ZXJlIHN1cHBvc2VkIHRvIGhhdmUgY2xvc2VkIG9uIHRoZSBXR0xD IHRvZGF5LiBIb3dldmVyLCBiZXR3ZWVuIHRoZSBkb2N1bWVudCBiZWNvbWluZyBhIFdHIGl0ZW0g YW5kIGl0IGdvaW5nIGludG8gTEMsIHdlIGhhdmUgbm90IHJlY2VpdmVkIHRvbyBtYW55IGNvbW1l bnRzIG9uIHRoZSBkcmFmdC4gQXMgc3VjaCwgd2UgYXJlIGV4dGVuZGluZyB0aGUgTEMgYnkgYW5v dGhlciB3ZWVrLiBQbGVhc2UgcmV2aWV3DQogdGhlIGRyYWZ0IGFuZCBwcm92aWRlIGFueSBjb21t ZW50cyB5b3UgbWlnaHQgaGF2ZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk1haGVzaCAmYW1wOyBLZW50IChhcyBjby1jaGFpcnMpPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTZXAgMTAsIDIwMTksIGF0IDM6MzkgUE0sIE1h aGVzaCBKZXRoYW5hbmRhbmkgJmx0OzxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWls LmNvbSI+bWpldGhhbmFuZGFuaUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF1dGhvcnMgaGF2ZSBwdWJsaXNoZWQm bmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRj b25mLW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMtMDQiPi0wNDwvYT4mbmJzcDt2ZXJzaW9uIG9m IHRoZSBkcmFmdCwgd2hpY2ggYWRkcmVzc2VzIGNvbW1lbnRzIHRoZXkgcmVjZWl2ZWQgaW4gSUVU RiAxMDUuIElmIHlvdSBwcm92aWRlZCBjb21tZW50cyBwbGVhc2UgY2hlY2sgdG8gbWFrZQ0KIHN1 cmUgeW91ciBjb21tZW50cyBoYXZlIGJlZW4gYWRkcmVzc2VkLiBBdCB0aGlzIHBvaW50LCB0aGUg YXV0aG9ycyBiZWxpZXZlIHRoYXQgdGhlIGRvY3VtZW50IGlzIHJlYWR5IGZvciBXR0xDLjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyB0aGVyZWZvcmUg c3RhcnRzIGEgdHdvIHdlZWsgTEMsIGVuZGluZyBvbiBTZXB0ZW1iZXIgMjR0aC4gUGxlYXNlIHBy b3ZpZGUgYW55IHRlY2huaWNhbCBjb21tZW50cyB5b3UgbWlnaHQgaGF2ZSBvbiB0aGUgZG9jdW1l bnQuIElmIHlvdSBiZWxpZXZlIHRoZSBkb2N1bWVudCBpcyBub3QgcmVhZHkgZm9yIExDLCBwbGVh c2Ugc3RhdGUgeW91ciByZWFzb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSB3aWxsIGlzc3VlIGEgSVBSIHBvbGwgc2VwYXJhdGVseS4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWFoZXNo ICZhbXA7IEtlbnQgKGFzIGNvLWNoYWlycyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MN2PR11MB43663B72FBA8D839E539A001B5820MN2PR11MB4366namp_-- From nobody Mon Sep 30 13:02:43 2019 Return-Path: <0100016d83c486c9-83aece79-684a-4999-b382-dd9c09f24c62-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C6A12012C for ; Mon, 30 Sep 2019 13:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 s99RSf5_yx-6 for ; Mon, 30 Sep 2019 13:02:39 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980BE12008C for ; Mon, 30 Sep 2019 13:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1569873758; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=DUNyQgIBYTSkYnl2UshnU+eXIfIXiSO/xuwR+ZxTWqU=; b=DiPMIWDePjf/1ghTLBDqblhFhy/NkevYBDw3uTEPYApvlf9RFgrQoxz6wnR/svWt NP+63pOYmM4frW4lv/zjc/YxcjB3U7ozLvNjxWPr8Q6DVdXDH/snQMVtAgVLwathAb/ dcPC+DTn+XM7u+kjJrvWpQr+PFX2d4SA0wCnRnsE= From: Kent Watsen Message-ID: <0100016d83c486c9-83aece79-684a-4999-b382-dd9c09f24c62-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C6AEA442-CB56-4F4E-8EBE-5CB504FF6F0F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 30 Sep 2019 20:02:38 +0000 In-Reply-To: Cc: "Eric Voit (evoit)" , Mahesh Jethanandani , Alexander Clemm , Benoit Claise , "netconf@ietf.org" To: =?utf-8?Q?Bal=C3=A1zs_Lengyel?= References: <4F49DF08-B7FC-4EBD-9D6B-7BC329E50334@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.09.30-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] WGLC for draft-ietf-netconf-notification-capabilities X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Sep 2019 20:02:41 -0000 --Apple-Mail=_C6AEA442-CB56-4F4E-8EBE-5CB504FF6F0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In reviewing the draft, I don't see where the file format is defined. = I understand the module defining a 'container' for protocol-accessible = nodes, but shouldn't it define an 'sx:structure' for the file format? I = suggest moving the contents of the "datastore-subscription-capabilities" = container to a 'grouping' and then have both the container and an = 'sx:structure' use that grouping. On the below: > I suspect that you will need to do a security analysis per YANG = object. This has been done the other YANG push family. > BALAZS: The full module is readOnly and not sensitive or private in = any manner. The security text for the readOnly parts of YangPush is the = exact same text: not very informative, but gives you the illusion of = security awareness. > =20 > I suspect that manipulating the reporting intervals could have some = security implications. E.g., a hacker could push up the damping period = or periodic interval to a level where the information they are changing = then becomes invisible to a monitoring system. > BALAZS: The full YAM is read-only so manipulating the data is not a = concern. The draft should say something like: 1. All protocol-accessible are read-only and cannot be modified. The = nature of the read-only data is not deemed to be sensitive in a way = necessitating access-control restrictions (e.g., NACM) beyond the client = being authenticated. 2. When a file format, the protection afforded by a mutually = authenticated transport protocol. Protection of the data must be = performed manually, so as to ensure that the data is neither seen nor = modified in transit. Reword as needed. Kent // contributor --Apple-Mail=_C6AEA442-CB56-4F4E-8EBE-5CB504FF6F0F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

In reviewing the draft, = I don't see where the file format is defined.    I understand = the module defining a 'container' for protocol-accessible nodes, but = shouldn't it define an 'sx:structure' for the file format?  I = suggest moving the contents of the "datastore-subscription-capabilities" = container to a 'grouping' and then have both the container and an = 'sx:structure' use that grouping.

On the below:

I suspect that you will need to do a = security analysis per YANG object.   This has been done the = other YANG push family.
BALAZS: The full module is readOnly and not sensitive or = private in any manner.  The security text for the readOnly parts of = YangPush is the exact same text: not very informative, but gives you the = illusion of security awareness.
 
I suspect that manipulating the = reporting intervals could have some security implications.   = E.g., a hacker could push up the damping period or periodic interval to = a level where the information they are changing then becomes invisible = to a monitoring system.
BALAZS: The full YAM is read-only so manipulating the data is = not a concern.


The draft should say = something like:

1. = All protocol-accessible are read-only and cannot be modified.  The = nature of the read-only data is not deemed to be sensitive in a way = necessitating access-control restrictions (e.g., NACM) beyond the client = being authenticated.

2. When a file format, the protection afforded by a mutually = authenticated transport protocol.  Protection of the data must be = performed manually, so as to ensure that the data is neither seen nor = modified in transit.

Reword as needed.


Kent= // contributor


= --Apple-Mail=_C6AEA442-CB56-4F4E-8EBE-5CB504FF6F0F-- From nobody Mon Sep 30 17:38:13 2019 Return-Path: <0100016d84c0c469-e57fd7aa-dcba-4079-9b37-22720f7a4500-000000@amazonses.watsen.net> X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719BC1200A1 for ; Mon, 30 Sep 2019 17:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 HbEZZBYjqHFl for ; Mon, 30 Sep 2019 17:38:10 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32315120077 for ; Mon, 30 Sep 2019 17:38:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1569890288; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=ask/BE/TZiI9g5gnH6GvXcxhZvmJEoif05t4snDmG/U=; b=hTUVA5qf/RTyWe9J8+gUvSbJkEbmUjftS94y49xDbgK8rxeKz3hU7qZQP31azNIg RTTsyZtphqIpTo1SGEjaizl96SxZU8N012Gn5OUkQwXZLVnJgY0E70e7ARg/uL/dSFq tGGpwAhXo4nmUS6FPQrhZmVCWWFuSKE31hMEAaMM= From: Kent Watsen Message-ID: <0100016d84c0c469-e57fd7aa-dcba-4079-9b37-22720f7a4500-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F25F3B44-DFA2-4A15-9E8A-5C34ADC4EF10" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 1 Oct 2019 00:38:08 +0000 In-Reply-To: <20190927174623.jhvpudof6yfs2m4k@anna.jacobs.jacobs-university.de> Cc: "Rob Wilton (rwilton)" , Martin Bjorklund , "wang.haiguang.shieldlab@huawei.com" , "netconf@ietf.org" , "rifaat.ietf@gmail.com" To: Juergen Schoenwaelder References: <0100016d455c6145-844c669e-8f31-4203-a827-7368d33cdee4-000000@email.amazonses.com> <0100016d7325f06e-00613ab7-413c-4d97-972c-858cf4886b65-000000@email.amazonses.com> <20190927.170902.142773301948727896.mbj@tail-f.com> <20190927174623.jhvpudof6yfs2m4k@anna.jacobs.jacobs-university.de> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.10.01-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 00:38:13 -0000 --Apple-Mail=_F25F3B44-DFA2-4A15-9E8A-5C34ADC4EF10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 27, 2019, at 1:46 PM, Sch=C3=B6nw=C3=A4lder, J=C3=BCrgen = wrote: >=20 > On Fri, Sep 27, 2019 at 03:53:51PM +0000, Rob Wilton (rwilton) wrote: >> I basically agree with what Martin is saying. >=20 > So do I. Hmmm... >> Either one YANG module containing all of the crypto identities, or a = few YANG modules as previously suggested. >=20 > It may make sense to split by security protocol. That would go some towards addressing Rich's concern. Presumably we = would have one module each for SSH and TLS algorithms. That said, to = Rich's concern, there is a constant churn with them. This churn = concerns two activities: the removal and addition of algorithms. Both = occur at protocol-version boundaries and, perhaps, other times as well. = This suggests to me that we could further refine the identities by = protocol version, something like this: In ietf-crypto-types: identity base-alg {} identity tls-alg { base "base-alg" } identity ssh-alg { base "base-alg" } In ietf-tls-1.1-types: identity tls-1.1-alg { base "ct:tls-alg" } In ietf-tls-1.2-types: identity tls-1.2-alg { base "ct:tls-alg" } etc. Updates only to the specific module would be needed. The updates would = only need to support new algorithms (not to remove support for legacy = algorithms), as a different mechanism can be used for a server to = advertise which algorithms it actually supports (on a more granular = level). One issue not addressed is defining the identities for the algorithms = used to encrypt other keys in the keystore. At least, neither SSH or = TLS are involved. However, both the keystore and TLS use "ASN.1" and = so, somehow, the keystore may be encrypting with "TLS" (really ASN.1) = keys already... (requires more analysis) >> If advertising the specific identities is important, then a per = identity if-feature could be used, although I'm not entirely sure that = one feature per identity is really a great option either, but I think = that this would be better than one per module. >=20 > Why not instead have a config false list of algorithms supported? Once > we have solved this problem generically, this list may get deprecated. I like this idea, but it means that ietf-crypto-types, where this config = false list would be defined, presumably, would then have protocol = accessible nodes and, to the point, may be odd for a "types" module to = define. Thoughts? - a "config false" list okay? Rich, does any of this line of thinking address your concern? - or = maybe you liked more my previous idea of using IANA registries? Kent // contributor --Apple-Mail=_F25F3B44-DFA2-4A15-9E8A-5C34ADC4EF10 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Sep 27, 2019, at 1:46 PM, Sch=C3=B6nw=C3=A4lder, J=C3=BCrgen= <J.Schoenwaelder@jacobs-university.de> wrote:

On = Fri, Sep 27, 2019 at 03:53:51PM +0000, Rob Wilton (rwilton) wrote:
I basically agree with = what Martin is saying.

So do = I.

Hmmm...


Either one YANG module = containing all of the crypto identities, or a few YANG modules as = previously suggested.

It may = make sense to split by security protocol.

That = would go some towards addressing Rich's concern.  Presumably we = would have one module each for SSH  and TLS algorithms.  That = said, to Rich's concern, there is a constant churn with them.  This = churn concerns two activities:  the removal and addition of = algorithms.  Both occur at protocol-version boundaries and, = perhaps, other times as well.  This suggests to me that we could = further refine the identities by protocol version, something like = this:

In = ietf-crypto-types:

    = identity base-alg {}
    identity tls-alg = { base "base-alg" }
    identity ssh-alg { base = "base-alg" }

In = ietf-tls-1.1-types:

    identity tls-1.1-alg { base "ct:tls-alg" = }
    <a bunch of tls-1.1 identities = here>

In = ietf-tls-1.2-types:

    identity tls-1.2-alg { base "ct:tls-alg" = }
    <a bunch of tls-1.2 identities = here>

etc.

Updates only to the specific module would be needed.   = The updates would only need to support new algorithms (not to remove = support for legacy algorithms), as a different mechanism can be used for = a server to advertise which algorithms it actually supports (on a more = granular level).

One issue not addressed is defining the identities for the = algorithms used to encrypt other keys in the keystore.   At least, = neither SSH or TLS are involved.  However, both the keystore and = TLS use "ASN.1" and so, somehow, the keystore may be encrypting with = "TLS" (really ASN.1) keys already... (requires more analysis)


If = advertising the specific identities is important, then a per identity = if-feature could be used, although I'm not entirely sure that one = feature per identity is really a great option either, but I think that = this would be better than one per module.

Why not instead have a config false list of algorithms = supported? Once
we have solved this problem generically, = this list may get deprecated.

I = like this idea, but it means that ietf-crypto-types, where this config = false list would be defined, presumably, would then have protocol = accessible nodes and, to the point, may be odd for a "types" module to = define.   Thoughts?  - a "config false" list = okay?


Rich, = does any of this line of thinking address your concern?  - or maybe = you liked more my previous idea of using IANA registries?

Kent // contributor



= --Apple-Mail=_F25F3B44-DFA2-4A15-9E8A-5C34ADC4EF10-- From nobody Mon Sep 30 23:41:04 2019 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA531200A1 for ; Mon, 30 Sep 2019 23:41:02 -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_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.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 apLF0ul_oCyK for ; Mon, 30 Sep 2019 23:40:59 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40062.outbound.protection.outlook.com [40.107.4.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72D99120044 for ; Mon, 30 Sep 2019 23:40:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OTDUFTc0oXu1MZ1h3iqFepIDyDa/ikw+0IQwjDsGqa9Pnu1BgZpIBxEP3QWhNI5OzcBCM83BZa/+pgsBsDeA8xgSqWBwNNZelRPvjV7YhBOpTQuPZeD/SZSg5M1ycng7EXr1Kr9Eo7Bt8nxeY5Sm2J97up5txacIFiot06X8pmQ1L8x8En4HTjvEr+VvXwNseQpp3OCflxbuZpcBsrm/JVZYyutPJ4CZuRP3Mmrytsfz+mOADRXqSqm5F+cwl4uA+TEsdAeAfNW26QRkea3yNU3JFl0m32d+hE+kr8rrRGJ9wKejBNYjshIpLunKR+WVM5MOfsmJScfITMJF2sXuIg== 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=fHFT5r9m0LCwO2StxKQpmVkFtwE0d4JHbXEmz4QeAHw=; b=TICWnnR53pmfwYsZYuu5+Mtr/vTUt166QUQpuLjoDWIQTLfsk4hxFCyMFJJ4oE3l9rFfn1NXXy4l2pJA82rx2du1Z1uyfnS4A4rm13vaqdA+ynZyfBDyFA3rLSk5w4nG2XibD3Q3I3dt3RfyC03s3X/Rq3GeNtdj1g2F/uYP8i9sZNQ9FYkZIAfRw8OtLY6AMOrtgw6kVxA7ngm+CZYeDKSFNiQ+oYRW2H4zL3/O1cwLd+5e+bjKY2OQrzC1WcJXMnDnLT+RVmHALP2rP4XWBdsTy7MqOPYNdmcArzFfIFqYwADjGTT8swNTwUtuP+FOaDekIMUJqYFdpRe/9bX1LA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fHFT5r9m0LCwO2StxKQpmVkFtwE0d4JHbXEmz4QeAHw=; b=F0reEGzgOScbfhMYZtE/FU+9R0407QAd5VslscS5Zgbbl5BrN4qQJzy+u1xQY2ow4K3TK2ulm0bDKleOrE63epsPBocKaoFlSfF/gxoKrNSbePFz/TO8E/FMwjg25KDPXG4VqJ4dnZ/AiC/HE0AQkBKKqaRSGlSABop9pUP/vto= Received: from VI1P190MB0686.EURP190.PROD.OUTLOOK.COM (10.186.159.71) by VI1P190MB0110.EURP190.PROD.OUTLOOK.COM (10.172.80.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.20; Tue, 1 Oct 2019 06:40:55 +0000 Received: from VI1P190MB0686.EURP190.PROD.OUTLOOK.COM ([fe80::e061:7f73:a47f:2ad4]) by VI1P190MB0686.EURP190.PROD.OUTLOOK.COM ([fe80::e061:7f73:a47f:2ad4%2]) with mapi id 15.20.2305.017; Tue, 1 Oct 2019 06:40:55 +0000 From: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= To: Kent Watsen CC: "Rob Wilton (rwilton)" , Martin Bjorklund , "wang.haiguang.shieldlab@huawei.com" , "netconf@ietf.org" , "rifaat.ietf@gmail.com" Thread-Topic: [netconf] crypto-types fallback strategy Thread-Index: AQHVbjbxVhFlbERW30moo9Q8WhnpJqcxoiSAgA4DFOiAAAlXAIAADIaAgAAfcYCABSoJAIAAZVsA Date: Tue, 1 Oct 2019 06:40:55 +0000 Message-ID: <20191001064054.2g4ujuoy7lsbgjm2@anna.jacobs.jacobs-university.de> References: <0100016d455c6145-844c669e-8f31-4203-a827-7368d33cdee4-000000@email.amazonses.com> <0100016d7325f06e-00613ab7-413c-4d97-972c-858cf4886b65-000000@email.amazonses.com> <20190927.170902.142773301948727896.mbj@tail-f.com> <20190927174623.jhvpudof6yfs2m4k@anna.jacobs.jacobs-university.de> <0100016d84c0c469-e57fd7aa-dcba-4079-9b37-22720f7a4500-000000@email.amazonses.com> In-Reply-To: <0100016d84c0c469-e57fd7aa-dcba-4079-9b37-22720f7a4500-000000@email.amazonses.com> Reply-To: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: MR2P264CA0088.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:32::28) To VI1P190MB0686.EURP190.PROD.OUTLOOK.COM (2603:10a6:800:12e::7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:638:709:5::7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 52000013-846e-41df-ca71-08d7463a4fab x-ms-traffictypediagnostic: VI1P190MB0110: x-ms-exchange-purlcount: 1 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 0177904E6B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39850400004)(136003)(396003)(366004)(376002)(199004)(189003)(51444003)(186003)(2906002)(8936002)(43066004)(45776006)(25786009)(4326008)(6116002)(86362001)(3450700001)(7736002)(305945005)(81166006)(8676002)(81156014)(5660300002)(786003)(316002)(6486002)(229853002)(11346002)(446003)(46003)(66946007)(64756008)(256004)(478600001)(66476007)(66556008)(1076003)(6246003)(476003)(486006)(54906003)(52116002)(386003)(99286004)(102836004)(14444005)(6506007)(6512007)(6306002)(71190400001)(6436002)(14454004)(76176011)(71200400001)(66446008); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P190MB0110; H:VI1P190MB0686.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fZpcKO+33eRZYl5zMe8PPR/ZduwWEWxtOOLrphNZnQP6I56yRWRDofCa4RWnl4ld+n6Esx+BB3nsSJkIXFQmkdgsf9mjGHjPEKMZRO2EDQwTv9ClYIBt3K+tsUtMIZK+spOCZTTjUo3fRQXW6LVhvNDQ3a3m8JblwPwgt9hxAhxfVLoRZjXQadMdk9EP02fm8EUWIQ9VlHyzs2bo6TVZ52ruRM+Xq+BySxgk51RvvtIMENFMenUVS8L2tKPRQuTWRaIc3hEgNGK/s+Kg7P8LQDLM7Mi8FAfQUdzFtrE2ls4mRygfuGJeneAzf40oh/uL4+E/UvKaJnCy40eUSucG3+fF2bv5R50h5QpSG0OgYTv2O+SweSKfjsjiKEuqWPDgqwTMq/WWSIIW1BmKApLiDktnVBJAr5r0EFmDGhZ7pDangxYo1BgPC4PNK84ZfRnAnPQAvrE+FysOGVT5e7mEMQ== Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 52000013-846e-41df-ca71-08d7463a4fab X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2019 06:40:55.7382 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: kAl97MFBgD90pPZQZbao/QpAvb79pENT3k40rJGvIHiOLZMZ4TfP8jnZEr+wmtsVQR0BpZtOotJX7rjuesOan9AQmzSzSuGtkb/ObsAYMT4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P190MB0110 Archived-At: Subject: Re: [netconf] crypto-types fallback strategy X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 06:41:03 -0000 On Tue, Oct 01, 2019 at 12:38:08AM +0000, Kent Watsen wrote: > >=20 > > It may make sense to split by security protocol. >=20 > That would go some towards addressing Rich's concern. Presumably we woul= d have one module each for SSH and TLS algorithms. That said, to Rich's c= oncern, there is a constant churn with them. This churn concerns two activ= ities: the removal and addition of algorithms. Both occur at protocol-ver= sion boundaries and, perhaps, other times as well. This suggests to me tha= t we could further refine the identities by protocol version, something lik= e this: >=20 > In ietf-crypto-types: >=20 > identity base-alg {} > identity tls-alg { base "base-alg" } > identity ssh-alg { base "base-alg" } >=20 > In ietf-tls-1.1-types: >=20 > identity tls-1.1-alg { base "ct:tls-alg" } > >=20 > In ietf-tls-1.2-types: >=20 > identity tls-1.2-alg { base "ct:tls-alg" } > >=20 > etc. >=20 > Updates only to the specific module would be needed. The updates would = only need to support new algorithms (not to remove support for legacy algor= ithms), as a different mechanism can be used for a server to advertise whic= h algorithms it actually supports (on a more granular level). I do not know whether this helps solving a problem or creates other problems as side effects. I think we have a) a set of named algorithms that is changing over time b) a set of algorithms that are "blessed" for use a certain protocol version (and the set may change over time) c) a set of algorithms supported by a protocol implementation (may change with over time as well, i.e., with firmware updates) d) a set of algorithms configured to be used by a protocol implementation (this is really what we want to get at) Perhaps it is best to use identities for a) and to expose the other sets via data leafs. I am not even sure exposing b) is required since b) is input to the protocol implementer and a client can (only) configure what is implemented anyway. I think c) could be exposed as config false data and d) is then config true data. > >> If advertising the specific identities is important, then a per identi= ty if-feature could be used, although I'm not entirely sure that one featur= e per identity is really a great option either, but I think that this would= be better than one per module. > >=20 > > Why not instead have a config false list of algorithms supported? Once > > we have solved this problem generically, this list may get deprecated. >=20 > I like this idea, but it means that ietf-crypto-types, where this config = false list would be defined, presumably, would then have protocol accessibl= e nodes and, to the point, may be odd for a "types" module to define. Tho= ughts? - a "config false" list okay? > Such a config false list should go where the protocol specifics are defined. And it likely has to be protocol version specific for implementations that do support multiple versions of a security protocol. I am generally not a fan of overloading names (or concepts in general). A YANG identity simply gives a name to something and a module simply puts a collection of named definitions into a common namespace. We should stay away from associating additional semantics with how an identity is named or how a module is named. If additional information is needed, model that additional information as data. =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