From nobody Mon May 4 09:26:33 2020 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 93FE13A0C45 for ; Mon, 4 May 2020 09:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=cesnet.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 eGBOR_FNA1uj for ; Mon, 4 May 2020 09:26:29 -0700 (PDT) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee:34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A10513A0C30 for ; Mon, 4 May 2020 09:26:16 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 999) id 42FDF60178; Mon, 4 May 2020 18:26:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1588609572; bh=L99y6LcM3PigZug+HSwEE1Wtu2ntuzKwmF0IE/W7BU8=; h=To:Date:Subject:From; b=cP66ZsAd0gcqpDiZn7k7D4dN83f4DVKAt3UMQId4wIPLPtkZW6inYf0AjODA+9gdQ MqKvlscOXB8KWt48dicGSSjZzceiAY0n/8VC1Il2Vr99uQeHUQWW3L2TBPtZ7Fu9cH VxkvS/rQzDFU8q24a0Xk7JOVXmu4EoJeKpK4upfI= Content-Type: text/plain; charset="utf-8" To: "netconf" User-Agent: SOGoMail 2.3.23 MIME-Version: 1.0 Date: Mon, 04 May 2020 18:26:12 +0200 Message-ID: <55da-5eb04200-55-78b364@140138202> X-Forward: 84.42.161.20 From: =?utf-8?q?Michal_Va=C5=A1ko?= Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [netconf] ietf-netconf-server and ietf-netconf-client keepalives 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, 04 May 2020 16:26:32 -0000 Hi, in the current YANG modules in the drafts, there are 3 types of keepali= ves defined for both a server and a client. They are SSH, TLS, and TCP = keepalives and can be configured separately for each connection (endpoi= nt). While I understand what TCP keepalive is as it is a feature with exact = definition, I am not that positive for SSH nor TLS. I can only assume t= he keepalive mechanisms from a Call Home [1] server are used. I would a= ppreciate if the modules define the specifics of all these keepalives b= ecause otherwise interoperability cannot be guaranteed. Also, the relat= ion to the Call Home RFC itself should probably be mentioned somewhere.= Meaning the answers to questions such as whether SHOULD each RESTCONF/= NETCONF server use SSH/TLS keepalive even when a TCP keepalive is enabl= ed. I am also not sure about the need for all 3 types of keepalives, ne= eding to specify them for each connection , or allowing to support 2 ki= nds simultaneously, but that is just my opinion. Thanks for any feedback. It is also possible I may have missed somethin= g/am wrong and I am sorry in that case. Regards, Michal [1] https://tools.ietf.org/html/rfc8071#page-8 From radulkar@cisco.com Sun May 3 21:59:28 2020 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 701A33A0C14 for ; Sun, 3 May 2020 21:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.597 X-Spam-Level: X-Spam-Status: No, score=-14.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=MxTPNYnl; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0MvH9aaN 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 G70u6oUbxgn5 for ; Sun, 3 May 2020 21:59:26 -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 B01863A0C12 for ; Sun, 3 May 2020 21:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8435; q=dns/txt; s=iport; t=1588568366; x=1589777966; h=from:to:subject:date:message-id:mime-version; bh=aDmth1VGaQID2x2fQYvwNs0RFSGN8qG0oLTcLOWd3+Q=; b=MxTPNYnl1FUJHAme+nOc5S0s8xQTfpMSKUHaamM3IpV3/KYLcIMOFPIt qGFgzcF0C4uIzc6Zyy0ZGqsAY+D317SGqDELe51lQWimcOgPeIxbpAApJ /L6IIlvd+YGoswe9nukNQ3dBuQgNB0ikp72o+WbquNkZrO0mxEYFEmZrG M=; X-IronPort-AV: E=Sophos;i="5.73,350,1583193600"; d="scan'208,217";a="756033064" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 May 2020 04:59:01 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 0444x1jZ030689 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 4 May 2020 04:59:01 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 3 May 2020 23:59:00 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 4 May 2020 00:59:00 -0400 Received: from NAM10-DM6-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.1497.2 via Frontend Transport; Sun, 3 May 2020 23:58:59 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lPWfrw8Q/bX77jo9gags6i+2cjnGC/e00qSGUyzirW5laAfSQ2oX/xnhd76u00MQJPS0A7w8m6ubVWU85cOEcW4BTd7olo606IM2KX9PP850IjPu1Lz/Y2/xdcxMn4+mkq5t/zAorxUBoFUtcD7zHO3TidlsNC6NtG7wN4LMtGjmgbYiPqugoEr0lLek1IGG3QrDT5EPogvYcTVoVdDMaqTrPgAlWPacmy15fbsiEP+SRoG3n7FHX5zEyNNZPZlsnntm90t04Jwk+6GxCxIbjZzNTvBSXwRiq7TIPO8XzdyqIKKShFwfchAj4x6Bw1x80yJvSyT5fiyo8RSXjxCIuA== 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=aDmth1VGaQID2x2fQYvwNs0RFSGN8qG0oLTcLOWd3+Q=; b=NVr2xbdxWZHEOYNYZ5gz2CbNsrGZdSe0+KydUIM14FiZ3EdJt5EAwNUEAFNBG5yH1lro2hOeY6Q3PPfkxd4DtT/hi4g8448w5MWdmpfJhV2H6X1tWhZ2a1qvplppZ143XMQkla07UV608Azez1wk+JCzr51fSfzDcaUMOeueztL1OSvCfbxUNe3PT5WPGkEjwivmFDza3W72lcqhfGQFH6zIcWCh9hirp8zpAaDU2CsVtcjhtrAV1BrVgngmM+U7wD/Z91/Lwuy1Lu4oGkwFNReQ7rdVEog+xZMRFRNPPM7XQEJvH7LMn5T+o4XJqkTvDAcRgnQcdoK0SAD2TEVeiQ== 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=aDmth1VGaQID2x2fQYvwNs0RFSGN8qG0oLTcLOWd3+Q=; b=0MvH9aaNCJILsZI7MeGeYVs7YTu6nXLD0B4TP6K20uQB3aFOu3MgALihcDtlrS5hCQgENX/hqDcFD4yobxavPxPxeJr79+3xxfBduZahIw79Dhj1EqybQAhwJvO0N0uizsgzi0j0PtDvSaGQM/DchKts/zvQ8muDIesnITJibeo= Received: from DM6PR11MB3130.namprd11.prod.outlook.com (2603:10b6:5:67::20) by DM6PR11MB2682.namprd11.prod.outlook.com (2603:10b6:5:c3::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20; Mon, 4 May 2020 04:58:59 +0000 Received: from DM6PR11MB3130.namprd11.prod.outlook.com ([fe80::a952:9799:513a:b06d]) by DM6PR11MB3130.namprd11.prod.outlook.com ([fe80::a952:9799:513a:b06d%7]) with mapi id 15.20.2958.029; Mon, 4 May 2020 04:58:59 +0000 From: "Rakesh Adulkar (radulkar)" To: "netconf@ietf.org" Thread-Topic: Using Netconf in Segment Routing for Database exchange and Path request/reply Thread-Index: AQHWIdC4crbtsKnZz06G234GiPt3WA== Date: Mon, 4 May 2020 04:58:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20042808 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [171.76.107.151] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f5612342-724d-4596-a59c-08d7efe7db46 x-ms-traffictypediagnostic: DM6PR11MB2682: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03932714EB x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MXno6K0n14+9k/Hzz1+61/hEBzK4GQsfq10GA43OmiFDW81me1HRTyaoGsjgYPRNwyfgah2o4n03I/UfkcxApoQ37xq5KZxF8nOwf5eiVYdEc2v7nWU3DbCg640vyky0UvCNf93oqISOVVDwkV6gMAtE92lh2bDwRKE+CCjj2s+uAAp35Fvn7kSvEYnHvLMf/BmAlUTF5dGFHs+dyDAKajIgTHXIWpr+x+79uk1PlbXoz+jTagx/cjcswFVZS2ECU8uuN+lomP1WXW118e7jvkQtpsxI/fpwLuYusK6uW3dH0tD1j4CCFyy0wDXG9z6ejYu26gTcHtfh1DESDBQ6NKAJxd81k4ivNJ4J6pjiwPY/MODy7cOSFgjNFuU+OubZ8JH+uDNkhYHx3XaLhizjlPXGtPEuW2mo4IvWWg7JNVAql9WQj+U5hOUNEAP2UWK2Bgk98dPuoZqI0qBiHhNgtvorCdGNXIfgD04VbPv+ZnZi4JjXpbR7tqz+IO+oXORC x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3130.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(39860400002)(366004)(346002)(376002)(2906002)(86362001)(316002)(6512007)(9686003)(478600001)(5660300002)(66476007)(6916009)(66556008)(66946007)(64756008)(76116006)(91956017)(33656002)(6486002)(36756003)(9326002)(26005)(8676002)(186003)(71200400001)(66446008)(6506007)(8936002)(130980200001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: VUJ9RZgYJyx6k6qVTmo77mWwuT5cESM+CRpcX8QuCZsk8tb6+Cfkk1LiwJT8/xcX4D8ha7oOmN6PnCXZ9O82zdbl+AaPBAu9ljIjIWXqhRbNJviuHGIDAqZC/DEPuoN3y4w+UCsp8p+CyJp3593qqwrQzxDgXpzUafN9hkYLo9d8g9eu3HE7j867LhiA8a1FLnAgJm+rSNiame7zomaPvgf5jPXHsPRadZwrpbmoJOgz1TghKlsYKwUd2SU4FKowPa1yTPZGNENwbiSjgpx6GIoYJWjoFPBwcxPUyzoc4lHm1QVU8fwra8cEEgjWB+Jmhydp6VeYtrUXksVcSp+Y0GJiST2TLNhj/Tq8yWomewBNohPibAcuL4goeSrzg1JzizP5USOASOymv4HzKgh1JmSiMyqPKgwlyHLeyBxv9qT3d6pz91Jnrj1WCK76tzgxR5uZ6fh52F3A9Njh9mlIVEzGxMqKT+WKTgGyIJP31j8PM+uEl4okskgena2MicOZWA9BYNScrgK3mEQ+k0lnJ1laB0VPcSVUQzN4ozRwzHk77Ax3/85Pw19+mXywwk1JkUBJmBQvDf9EZCy2HICa1iwNt/8j4Sg0sXEj4LIFxddSytPX6ZqNSIro8ihcVPozbXchRQxNIeXiqS0PAyrzOcTECWi6flDz8VP7TglmTqzFUW32obYAoSVkDDaWmVLMBbfVpwaLyVjhX6FqUV4FOkaXIwqLJHHioSeXXgXcoY+4hKXUtqpVrnpV915jY0wtGifzxJMlG58bxMpAi/+AB1UTqHn7Jwrfhg+CGL3XsMI= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BD96D98088184F29A1CE12FD6DD3821Ccontosocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f5612342-724d-4596-a59c-08d7efe7db46 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2020 04:58:59.0499 (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: KMjWBNfFPS9EIGisSYTrUGnwV5/M0nbwHgxwK7XRZLfjahUDrgNSmw7qfo+4v8iVlVs+LOAnpF8kc6BZYNPz+Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2682 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: X-Mailman-Approved-At: Mon, 04 May 2020 14:02:44 -0700 Subject: [netconf] Using Netconf in Segment Routing for Database exchange and Path request/reply 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, 04 May 2020 05:02:01 -0000 --_000_BD96D98088184F29A1CE12FD6DD3821Ccontosocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGVhbSwNCg0KSG9wZSB5b3UgYXJlIGRvaW5nIHdlbGwuDQoNCkkgaGF2ZSBiZWxvdyBpZGVh LCBhcyBvZmYgbm93IEkgYW0gbm90IHN1cmUgaWYgaXQgd2lsbCB3b3JrIG9yIG5vdC4NCkluIGN1 cnJlbnQgU2VnbWVudCBSb3V0aW5nIGltcGxlbWVudGF0aW9uIHdlIGFyZSB1c2luZyBCR1AtTFMg dG8gZXhjaGFuZ2UgZGF0YWJhc2UgYW5kIFBDRVAgZm9yIHBhdGggcmVxdWVzdC9yZXBseSBiZXR3 ZWVuIFBFL1AgZGV2aWNlcyBhbmQgU1IgY29udHJvbGxlci4gSSBhbSBqdXN0IHRoaW5raW5nIHRo YXQgY2FuIHdlIHVzZSBOZXRjb25mIHRvIGV4Y2hhbmdlIGRhdGFiYXNlIGFuZCBhbHNvIHBhdGgg cmVxdWVzdCBhbmQgcmVwbHkgcHJvdG9jb2wgYmV0d2VlbiBQRS9QIGRldmljZXMgYW5kIFNSIGNv bnRyb2xsZXI/DQpJIFVuZGVyc3RhbmQgdGhhdCB0aGUgc29sZSBwdXJwb3NlIG9mIG5ldGNvbmYg aXMgdG8gbWFuYWdlIHRoZSBuZXR3b3JrIGRldmljZXMgd2l0aCBzcGVjaWZpYyB1c2UgY2FzZXMg dG8gaW5zdGFsbCwgbWFuaXB1bGF0ZSwgYW5kIGRlbGV0ZSB0aGUgY29uZmlndXJhdGlvbiBvZiBu ZXR3b3JrIGRldmljZXMuIEl04oCZcyBub3QgbWVhbnQgdG8gY2FycnkgSUdQIGFuZCBURS1yZWxh dGVkIHN0dWZmLCBub3IgY2FuIGl0IHJlYWN0IHRvIG5ldHdvcmsgdG9wb2xvZ3kgY2hhbmdlcy4g RWFjaCBwcm90b2NvbCBpcyB0aGVyZSBmb3IgaXRzIHJlYXNvbnMsIGFuZCBJTUhPIG5ldGNvbmYg aXMgbm90IGludGVuZGVkIHRvIHJlcGxhY2UgQkdQLUxTIGFuZCBQQ0VQLCBhbmQgZXZlbiBpZiBp dCBkb2VzLCB0aGVyZSBuZWVkcyB0byBiZSB2YXJpb3VzIGRldmVsb3BtZW50IG9uIHRoZSBuZXRj b25mIHNpZGUuDQoNClNvIEkgd2FudGVkIHRvIGtub3cgaWYgdGhlcmUgaXMgYW55IGRldmVsb3Bt ZW50IGluIE5ldGNvbmYgaXMgZ29pbmcgaW4gdGhpcyBkaXJlY3Rpb24/IElmIHllcywgdGhhbiBJ IHdvdWxkIGxpa2UgdG8gc2hhcmUgbXkgdGhvdWdodHMgb24gaXQuDQoNClRoYW5rcyAmIFJlZ2Fy ZHMsDQotLQ0KUmFrZXNoIEFkdWxrYXINClRlY2huaWNhbCBDb25zdWx0aW5nIEVuZ2luZWVyIOKA kyBDdXN0b21lciBEZWxpdmVyeSB8IENpc2NvIFRBQw0KDQo= --_000_BD96D98088184F29A1CE12FD6DD3821Ccontosocom_ 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 YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCnNwYW4uRW1haWxT dHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUlO IiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tR0IiPkhpIFRlYW0sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5Ib3BlIHlv dSBhcmUgZG9pbmcgd2VsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPkkgaGF2ZSBiZWxvdyBpZGVh LCBhcyBvZmYgbm93IEkgYW0gbm90IHN1cmUgaWYgaXQgd2lsbCB3b3JrIG9yIG5vdC4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5JbiBjdXJyZW50IFNlZ21lbnQgUm91dGlu ZyBpbXBsZW1lbnRhdGlvbiB3ZSBhcmUgdXNpbmcgQkdQLUxTIHRvIGV4Y2hhbmdlIGRhdGFiYXNl IGFuZCBQQ0VQIGZvciBwYXRoIHJlcXVlc3QvcmVwbHkgYmV0d2VlbiBQRS9QIGRldmljZXMgYW5k DQogU1IgY29udHJvbGxlci4gSSBhbSBqdXN0IHRoaW5raW5nIHRoYXQgY2FuIHdlIHVzZSBOZXRj b25mIHRvIGV4Y2hhbmdlIGRhdGFiYXNlIGFuZCBhbHNvIHBhdGggcmVxdWVzdCBhbmQgcmVwbHkg cHJvdG9jb2wgYmV0d2VlbiBQRS9QIGRldmljZXMgYW5kIFNSIGNvbnRyb2xsZXI/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPkkgVW5kZXJzdGFuZCB0aGF0IHRoZSBzb2xlIHB1 cnBvc2Ugb2YgbmV0Y29uZiBpcyB0byBtYW5hZ2UgdGhlIG5ldHdvcmsgZGV2aWNlcyB3aXRoIHNw ZWNpZmljIHVzZSBjYXNlcyB0byBpbnN0YWxsLCBtYW5pcHVsYXRlLCBhbmQgZGVsZXRlIHRoZQ0K IGNvbmZpZ3VyYXRpb24gb2YgbmV0d29yayBkZXZpY2VzLiBJdOKAmXMgbm90IG1lYW50IHRvIGNh cnJ5IElHUCBhbmQgVEUtcmVsYXRlZCBzdHVmZiwgbm9yIGNhbiBpdCByZWFjdCB0byBuZXR3b3Jr IHRvcG9sb2d5IGNoYW5nZXMuIEVhY2ggcHJvdG9jb2wgaXMgdGhlcmUgZm9yIGl0cyByZWFzb25z LCBhbmQgSU1ITyBuZXRjb25mIGlzIG5vdCBpbnRlbmRlZCB0byByZXBsYWNlIEJHUC1MUyBhbmQg UENFUCwgYW5kIGV2ZW4gaWYgaXQgZG9lcywgdGhlcmUNCiBuZWVkcyB0byBiZSB2YXJpb3VzIGRl dmVsb3BtZW50IG9uIHRoZSBuZXRjb25mIHNpZGUuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdC Ij5TbyBJIHdhbnRlZCB0byBrbm93IGlmIHRoZXJlIGlzIGFueSBkZXZlbG9wbWVudCBpbiBOZXRj b25mIGlzIGdvaW5nIGluIHRoaXMgZGlyZWN0aW9uPyBJZiB5ZXMsIHRoYW4gSSB3b3VsZCBsaWtl IHRvIHNoYXJlIG15IHRob3VnaHRzIG9uIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPlRoYW5rcyAmYW1w OyBSZWdhcmRzLDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj4tLTwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+UmFrZXNo IEFkdWxrYXI8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLUdCIj5UZWNobmljYWwgQ29uc3VsdGluZyBFbmdpbmVlciDigJMgQ3VzdG9tZXIgRGVsaXZl cnkgfCBDaXNjbyBUQUM8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BD96D98088184F29A1CE12FD6DD3821Ccontosocom_-- From nobody Mon May 4 14:23:49 2020 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 A47F43A10AB for ; Mon, 4 May 2020 14:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 xTupA4t-ZfzM for ; Mon, 4 May 2020 14:23:45 -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 222803A10B9 for ; Mon, 4 May 2020 14:23:45 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id n11so2576pgl.9 for ; Mon, 04 May 2020 14:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version; bh=G3DlfDoKXCtj1tLirIg0o1RFG36X8xkXjm5k7GKB2I4=; b=kOvW79pFcZwrLCHe61TGGKNFeua2tgAL0wCix6yLnke6uTbsBm34/RbHYxg4Gyi37z e0n/fdphczxFcp2Oahq510Coqn9FCM23E/LI4O1dLalf9ZaRb8mSG+HmB0yOFwRLNqsh 9ZueQhAGMUB3SlaSw9oLrkDJ8wOfzpY00zKtlHSs5AesDwSmrO+PLb8ELCRYk3lfeXZV OSAooYEzLyAhwCkRHay79uNsIFunvCkWblkrQSOj4hJ7Ptz8flXl9H/fYi9gcxkF0Rm0 JKYsxhQ6gH1k/SmzSvhgdfr79bMpDEvu6jssF39wc/4wIEUEM5qNnvLoB07niF7EytEv zgZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version; bh=G3DlfDoKXCtj1tLirIg0o1RFG36X8xkXjm5k7GKB2I4=; b=UoEyHk4mcjFtptHCLiOVdPBxinNnaGIu4jggPXSPZnVvLwsUJqGV9IDTf1ePeJoI2i vrQaN0+xA3ls9gqv3StCqTnvTfJolebkpCEnRbiYpsPtydmlyM2SuMImI6nBQ05Pxj+D euJ+oAaqm6u/AavuJoAR7ky0BjNODPuWVVXxzomSQUHe7LLOyST59HaYC15FZ3g4jlRe uy1jpAaWUDIvqN+/a3eSxpWDBsbgbCxcXARhNon7ApQ4ZfWITJMBRNX3ImS7W/rE6ODV UoybBVenLsnP4WW4qxqPiguuodCoUKaTrVZYBUEFyw5jqh+p55D1M889/QBJncdCiUJj ZMag== X-Gm-Message-State: AGi0PuYjVGWwFKaZh/XkzvOlppxPd+cXvWe4p/XRNN4wU7PAm3VJ4X2h uKWG6G9GPicK/3Tnnp+YAhB3/gtb X-Google-Smtp-Source: APiQypLRb3/KCuyurlUIv2byTTAPD1g7SPT9x+XC3n+GswiaxD10sJKscwWKcaFUD4xaLI3pRvbzSQ== X-Received: by 2002:a63:2485:: with SMTP id k127mr190606pgk.159.1588627424204; Mon, 04 May 2020 14:23:44 -0700 (PDT) Received: from [192.168.1.5] (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id a142sm28474pfa.6.2020.05.04.14.23.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 May 2020 14:23:43 -0700 (PDT) Date: Mon, 4 May 2020 14:23:30 -0700 From: Jeff Tantsura To: "=?utf-8?Q?netconf=40ietf.org?=" , "Rakesh Adulkar (radulkar)" Message-ID: <0217af62-62a7-4cd4-958f-c21e4b7cf8dd@Spark> In-Reply-To: References: X-Readdle-Message-ID: 0217af62-62a7-4cd4-958f-c21e4b7cf8dd@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5eb087de_15b5af5c_2480" Archived-At: Subject: Re: [netconf] Using Netconf in Segment Routing for Database exchange and Path request/reply 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, 04 May 2020 21:23:47 -0000 --5eb087de_15b5af5c_2480 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Rakesh, You have mostly answered your question in its second part. Leaving aside that this is a bad idea - PCEP communication state is ephemeral, and as such, Restconf would have= been a better candidate. - there are already implementations streaming LSDB content over gNMI Cheers, Jeff On May 4, 2020, 2:02 PM -0700, Rakesh Adulkar (radulkar) , wrote: > Hi Team, > > Hope you are doing well. > > I have below idea, as off now I am not sure if it will work or not. > In current Segment Routing implementation we are using BGP-LS to exchan= ge database and PCEP for path request/reply between PE/P devices and SR c= ontroller. I am just thinking that can we use Netconf to exchange databas= e and also path request and reply protocol between PE/P devices and SR co= ntroller=3F > I Understand that the sole purpose of netconf is to manage the network = devices with specific use cases to install, manipulate, and delete the co= nfiguration of network devices. It=E2=80=99s not meant to carry IGP and T= E-related stuff, nor can it react to network topology changes. Each proto= col is there for its reasons, and IMHO netconf is not intended to replace= BGP-LS and PCEP, and even if it does, there needs to be various developm= ent on the netconf side. > > So I wanted to know if there is any development in Netconf is going in = this direction=3F If yes, than I would like to share my thoughts on it. > > Thanks & Regards, > -- > Rakesh Adulkar > Technical Consulting Engineer =E2=80=93 Customer Delivery =7C Cisco TAC= > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > netconf mailing list > netconf=40ietf.org > https://www.ietf.org/mailman/listinfo/netconf --5eb087de_15b5af5c_2480 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Rakesh,

You have mostly answered your question in its second part.
Leaving aside that this is a bad idea
- PCEP communication state is ephemeral, and as such, Restconf would have= been a better candidate.
- there are already implementations streaming LSDB content over gNMI

Cheers,
Jeff
On May 4, 2020, 2:02 PM -0700, Rake= sh Adulkar (radulkar) <radulkar=3D40cisco.com=40dmarc.ietf.org>, wr= ote:

Hi Team= ,

&=23160= ;

Hope yo= u are doing well.

&=23160= ;

I have = below idea, as off now I am not sure if it will work or not.

In curr= ent Segment Routing implementation we are using BGP-LS to exchange databa= se and PCEP for path request/reply between PE/P devices and SR controller= . I am just thinking that can we use Netconf to exchange database and als= o path request and reply protocol between PE/P devices and SR controller=3F=

I Under= stand that the sole purpose of netconf is to manage the network devices w= ith specific use cases to install, manipulate, and delete the configurati= on of network devices. It=E2=80=99s not meant to carry IGP and TE-related= stuff, nor can it react to network topology changes. Each protocol is th= ere for its reasons, and IMHO netconf is not intended to replace BGP-LS a= nd PCEP, and even if it does, there needs to be various development on th= e netconf side.&=23160;

&=23160= ;

So I wa= nted to know if there is any development in Netconf is going in this dire= ction=3F If yes, than I would like to share my thoughts on it.

=

&=23160;

Thanks = & Regards,

--

Rakesh Adulkar

Technical Consulting Engineer =E2=80=93= Customer Delivery =7C Cisco TAC

&=23160;

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
netconf mailing list
netconf=40ietf.org
https://www.ietf.org/mailman/listinfo/netconf
--5eb087de_15b5af5c_2480-- From nobody Tue May 5 11:11:20 2020 Return-Path: <01000171e608e34e-31c7a78a-ba53-4d94-b9b4-642b4948081b-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 A07153A0B80 for ; Tue, 5 May 2020 11:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 69OW81BBvmgM for ; Tue, 5 May 2020 11:11:16 -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 BE07A3A0B7F for ; Tue, 5 May 2020 11:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1588702274; h=From:Content-Type:Mime-Version:Subject:Message-Id:References:To:Date:Feedback-ID; bh=r5hdvnSY6nSfaQhOJtWwwpvUYDW/EAV3rIBSMfhzhH0=; b=ISsCLP4SyM43b3GAf19ZncskylBGyCQF3tUZX8nqu/rr2QYly0BYagQEzjymENKH K9KMaSmPo2FwyENwlKLKNf4MQIIEyAU3wCw1pYPkMkK43bmCpBK9Mx8yTQlSrxoTLfh oEgACrwF7IjEi/HVhdBIChXP1yaZlOK0mHkrc0XI= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_70DBBDE4-759A-44FA-8C39-CBF1F589973F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-ID: <01000171e608e34e-31c7a78a-ba53-4d94-b9b4-642b4948081b-000000@email.amazonses.com> References: To: "netconf@ietf.org" Date: Tue, 5 May 2020 18:11:14 +0000 X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.05.05-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] Fwd: Reminder: Survey on planning for possible online IETF meetings 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, 05 May 2020 18:11:18 -0000 --Apple-Mail=_70DBBDE4-759A-44FA-8C39-CBF1F589973F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii NETCONF WG, Please fill out this survey. Thanks! > Begin forwarded message: >=20 > From: Alissa Cooper > Subject: Fwd: Reminder: Survey on planning for possible online IETF = meetings > Date: May 5, 2020 at 7:48:03 AM EDT > To: IETF WG Chairs >=20 > Please circulate this to your working group lists. The survey data = will be very important as we plan future IETF meetings. >=20 > Thanks, > Alissa >=20 >> Begin forwarded message: >>=20 >> From: IETF Executive Director > >> Subject: Reminder: Survey on planning for possible online IETF = meetings >> Date: May 4, 2020 at 3:03:35 AM EDT >> To: "IETF Announcement List" > >> Reply-To: ietf108planning@ietf.org >>=20 >> This is a reminder that we need the IETF community to help us plan = for the possibility that one or more upcoming IETF meetings in 2020 and = possibly 2021 may not be able to go ahead in person. You can help us = with this by filling out the following survey:=20 >>=20 >> https://www.surveymonkey.com/r/5328FFJ = >>=20 >> So far we have 114 responses and we would ideally like 500 or more. >>=20 >> The survey contains the following pages and will take 15-20 minutes = to complete: >>=20 >> 1. Welcome >> 2. Online IETF 107 and the subsequent virtual interims >> 3. Replacing a cancelled in-person meeting >> 4. Online meeting format and timezone >> 5. Replicating humming >> 6. Replicating the hallway environment >> 7. Fees >> 8. Thanks and anything else >>=20 >> We run the survey in anonymous mode which means that we only see data = that you explicitly provide. >>=20 >> Thank you in advance for your help. >>=20 >> --=20 >> Alissa Cooper, IETF Chair >> Jay Daley, IETF Executive Director >> Colin Perkins, IRTF Chair >>=20 >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >=20 --Apple-Mail=_70DBBDE4-759A-44FA-8C39-CBF1F589973F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii NETCONF WG,

Please fill out this survey.

Thanks!


Begin = forwarded message:

From: = Alissa Cooper <alissa@cooperw.in>
Subject: = Fwd: Reminder: = Survey on planning for possible online IETF meetings
Date: = May 5, 2020 at 7:48:03 AM = EDT
To: = IETF WG Chairs <wgchairs@ietf.org>

Please circulate this = to your working group lists. The survey data will be very important as = we plan future IETF meetings.

Thanks,
Alissa

Begin forwarded message:

From: IETF Executive Director <exec-director@ietf.org>
Subject: Reminder: Survey on planning for possible online IETF = meetings
Date: May 4, 2020 at 3:03:35 AM EDT
To: "IETF Announcement List" <ietf-announce@ietf.org>
Reply-To: ietf108planning@ietf.org

This is a reminder that we = need the IETF community to help us plan for the possibility that one or = more upcoming IETF meetings in 2020 and possibly 2021 may not be able to = go ahead in person.  You can help us with this by filling out the = following survey:

https://www.surveymonkey.com/r/5328FFJ

So far we have 114 responses and we would ideally like 500 or = more.

The survey contains the following = pages and will take 15-20 minutes to complete:

1. Welcome
2. Online IETF 107 and the = subsequent virtual interims
3. Replacing a cancelled = in-person meeting
4. Online meeting format and timezone
5. Replicating humming
6. Replicating the = hallway environment
7. Fees
8. Thanks and = anything else

We run the survey in = anonymous mode which means that we only see data that you explicitly = provide.

Thank you in advance for your = help.

--
Alissa Cooper, IETF = Chair
Jay Daley, IETF Executive Director
Colin= Perkins, IRTF Chair

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


= --Apple-Mail=_70DBBDE4-759A-44FA-8C39-CBF1F589973F-- From nobody Tue May 5 16:22:13 2020 Return-Path: <01000171e72582c2-2f87f408-9cd4-4970-af66-d309f57a49df-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 BAE8D3A0C39 for ; Tue, 5 May 2020 16:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 ZsP0yOy2thjp for ; Tue, 5 May 2020 16:22:09 -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 E2EFA3A0C1E for ; Tue, 5 May 2020 16:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1588720927; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=DcCmL57DbQcADIS3VFFItL7TFNhEeru3KxUVHqgWDGI=; b=Q6djPdR4ZoBClfA98sLK1mI+rq9i9sJE7Jopll99s4rRbllahL71AcprFSuNQPlf 7NQp6eRn1333Ck6q1mNn2bnKMs9yfLUIB2h5Nw55gIJSGqYhMM5EKf5rp1T6jn19I3u ZEtmskhFr1KXQ8QSdB5Fd3vqGkxUKNFEDMiMPnkk= From: Kent Watsen Message-ID: <01000171e72582c2-2f87f408-9cd4-4970-af66-d309f57a49df-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_32BBF60F-CF4E-45A0-BE9B-306FFD03B4B7" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 5 May 2020 23:22:07 +0000 In-Reply-To: <55da-5eb04200-55-78b364@140138202> Cc: "netconf@ietf.org" To: =?utf-8?Q?Michal_Va=C5=A1ko?= References: <55da-5eb04200-55-78b364@140138202> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.05.05-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] ietf-netconf-server and ietf-netconf-client keepalives 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, 05 May 2020 23:22:11 -0000 --Apple-Mail=_32BBF60F-CF4E-45A0-BE9B-306FFD03B4B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Michal, > On May 4, 2020, at 12:26 PM, Michal Va=C5=A1ko = wrote: >=20 > Hi, > in the current YANG modules in the drafts, there are 3 types of = keepalives defined for both a server and a client. They are SSH, TLS, = and TCP keepalives and can be configured separately for each connection = (endpoint). >=20 > While I understand what TCP keepalive is as it is a feature with exact = definition, I am not that positive for SSH nor TLS. I can only assume = the keepalive mechanisms from a Call Home [1] server are used. I would = appreciate if the modules define the specifics of all these keepalives = because otherwise interoperability cannot be guaranteed. Good suggestion. Indeed, they would be the same as in RFC 8071 > Also, the relation to the Call Home RFC itself should probably be = mentioned somewhere. draft-ietf-netconf-netconf-client-server currently has 11 references to = RFC 8071...not enough, or do you mean that the keepalive description = should say something like "consistent with RFC 8071, ..."?=20 > Meaning the answers to questions such as whether SHOULD each = RESTCONF/NETCONF server use SSH/TLS keepalive even when a TCP keepalive = is enabled. I am also not sure about the need for all 3 types of = keepalives, needing to specify them for each connection , or allowing to = support 2 kinds simultaneously, but that is just my opinion. Keepalives were heavily discussed with the TSV Area a couple years ago. = The general takeaway was that keepalives SHOULD be defined for every = protocol, and that applications SHOULD use as many as makes sense, as = each tests a different thing and with varying levels of security. > Thanks for any feedback. It is also possible I may have missed = something/am wrong and I am sorry in that case. >=20 > Regards, > Michal >=20 > [1] https://tools.ietf.org/html/rfc8071#page-8 >=20 Kent // contributor --Apple-Mail=_32BBF60F-CF4E-45A0-BE9B-306FFD03B4B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Michal,


On May 4, 2020, at 12:26 PM, = Michal Va=C5=A1ko <mvasko@cesnet.cz> wrote:

Hi,in the current YANG modules in the drafts, there are 3 types = of keepalives defined for both a server and a client. They are SSH, TLS, = and TCP keepalives and can be configured separately for each connection = (endpoint).

While I understand what TCP = keepalive is as it is a feature with exact definition, I am not that = positive for SSH nor TLS. I can only assume the keepalive mechanisms = from a Call Home [1] server are used. I would appreciate if the modules = define the specifics of all these keepalives because otherwise = interoperability cannot be guaranteed.

Good suggestion.  Indeed, they would be the = same as in RFC 8071


Also, the relation to the Call Home RFC itself should = probably be mentioned somewhere.

draft-ietf-netconf-netconf-client-server currently = has 11 references to RFC 8071...not enough, or do you mean that the = keepalive description should say something like "consistent with RFC = 8071, ..."? 


Meaning the answers to questions such as whether SHOULD each = RESTCONF/NETCONF server use SSH/TLS keepalive even when a TCP keepalive = is enabled. I am also not sure about the need for all 3 types of = keepalives, needing to specify them for each connection , or allowing to = support 2 kinds simultaneously, but that is just my opinion.

Keepalives were heavily discussed with the TSV = Area a couple years ago.  The general takeaway was that keepalives = SHOULD be defined for every protocol, and that applications SHOULD use = as many as makes sense, as each tests a different thing and with varying = levels of security.


Thanks for any feedback. It is also possible I may have = missed something/am wrong and I am sorry in that case.

Regards,
Michal

[1] https://tools.ietf.org/html/rfc8071#page-8



Kent // = contributor



= --Apple-Mail=_32BBF60F-CF4E-45A0-BE9B-306FFD03B4B7-- From nobody Tue May 5 18:48:23 2020 Return-Path: <01000171e7ab5453-7199ade0-ec62-4f6c-837e-5132fb5a4e78-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 4612E3A0CD6 for ; Tue, 5 May 2020 18:48:21 -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_MSPIKE_H2=-0.001, 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 f-zAY0y9X1_y for ; Tue, 5 May 2020 18:48:18 -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 B10543A0CD7 for ; Tue, 5 May 2020 18:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1588729697; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=BqS3Drc1sAwmYEEw+kS14VmbFDSBkooMEdNSUTcihbk=; b=Kh/QmFc7WF0GblpnGPd/tYUVmdC1WKzycqdm1UGxdC4WygYNo8yCTF2HSyTI1mlo aaB4Dlcy/5DsIJ/hfZKnI3LS8TodN2ViLXZrcPVzNlshA5At5deu0VgeqSEsCAH0so8 5x/O6CsYAy3q2cRQi4YOw0WssCBkKzqGbB3CXjiA= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_8D8CFB5F-FD07-4CF2-826E-3105C2832881" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 6 May 2020 01:48:17 +0000 References: <5CE2095E-7117-4092-B356-A5C4FF490D10@gmail.com> <01000171bc405640-6e173d84-f921-4f6f-929a-6431410051c8-000000@email.amazonses.com> To: "netconf@ietf.org" In-Reply-To: Message-ID: <01000171e7ab5453-7199ade0-ec62-4f6c-837e-5132fb5a4e78-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.05.06-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Virtual hum for the question on "https-notif" 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: Wed, 06 May 2020 01:48:21 -0000 --Apple-Mail=_8D8CFB5F-FD07-4CF2-826E-3105C2832881 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This email closes the virtual hum on the for the question on the = "https-notif=E2=80=9D draft. As reported before, 70% picked "Let the market decide=E2=80=9D, with the = remaining 30% all picking "Publisher MUST implement JSON encoding=E2=80=9D= . Rob raises a good point about the language in RFC 8639, but the results = of the poll reveal a contradiction. How can we =E2=80=9Clet the market = decide=E2=80=9D if a default MUST be picked? The chairs are questioning how vetted that text in RFC 8639 is, noting = that RESTCONF also doesn=E2=80=99t pick a default. We wonder if the = text in RFC 8639 should be softened. For instance: OLD: A specification for a transport MUST identify any encodings that are supported. If a configured subscription's transport allows different encodings, the specification MUST identify the default encoding. NEW: A specification for a transport MUST identify any encodings that are supported. If a configured subscription's transport allows different encodings, the specification MUST identify the default encoding, or provide a mechanism whereby supported encodings can be discovered. At least, it seems that the intent of the draft is to handle the case = for when the =E2=80=9Cencoding=E2=80=9D leaf is not configured (since = it=E2=80=99s =E2=80=9Cmandatory false=E2=80=9D), more so than force = interoperability, but there are other ways to determine an encoding in = such circumstances, and thus maybe the text is overly proscriptive? The NETCONF Chairs > On Apr 27, 2020, at 11:48 AM, Rob Wilton (rwilton) = wrote: >=20 > At least the hum seems to have narrowed it down to two choices = (assuming sufficient voices). > =20 > But I can see interop benefit in defining at least one encoding that = clients know will be supported by the server. > =20 > Hence, I wonder if anyone wouldn=E2=80=99t be able to live with: > =20 > =E2=80=9CThe default encoding is JSON. Publishers MUST support JSON = encoding=E2=80=9D > =20 > * or a slight variant (that I don=E2=80=99t like so much) would be to = soften the MUST to a SHOULD, with the expectation that servers that = don=E2=80=99t support JSON would reject the configuration unless the = clients had specified an alternative supported encoding. > =20 > Rob > [As a contributor] > =20 > =20 > From: Kent Watsen =20 > Sent: 27 April 2020 16:28 > To: Rob Wilton (rwilton) > Cc: Mahesh Jethanandani ; netconf@ietf.org > Subject: Re: [netconf] Virtual hum for the question on "https-notif" = draft > =20 > =20 >=20 >=20 > On Apr 27, 2020, at 8:08 AM, Rob Wilton (rwilton) = > wrote: > =20 > [As an individual contributor] > =20 > Changing my stance somewhat from the NETCONF meeting =E2=80=A6 > =20 > After looking into the details a bit more, section 7 of rfc8639 = states: > =20 > A specification for a transport MUST identify any encodings that = are >=20 > supported. If a configured subscription's transport allows = different >=20 > encodings, the specification MUST identify the default encoding. >=20 > =20 > Does this imply that the http-notif draft either must state a default = encoding (or otherwise update rfc8639)? > =20 > It seems that way...at least when https-notif is being used for RFC = 8639 (it doesn=E2=80=99t have to be). > =20 > Looking at the hum-results so far, 70% picked "Let the market = decide=E2=80=9D (with the remaining 30% all picking "Publisher MUST = implement JSON encoding=E2=80=9D).=20 > =20 > In light of the RFC 8639 text quoted above, we might question the = validity of the hum=E2=80=A6or, given the strong preference from the = hum, we might question the validity of that constraint in RFC 8639. If = questioning RFC 8639, a better question to ask might be why the = configurable =E2=80=9Cencoding=E2=80=9D leaf isn=E2=80=99t mandatory = (also eliminating this issue and seemingly cleaner)? >=20 > If so, my thinking is to make the default encoding JSON, because it is = easier to generate than XML, and easier to convert into CBOR. Clients = don=E2=80=99t have to support JSON if they know that the publisher = supports a different encoding that they do support. > =20 > If we had to pick one, JSON is more agreeable than XML. Picking JSON = would likely also be the kiss-of-death for XML, as once support for JSON = has been coded, it=E2=80=99s unlikely XML support would be coded (like = how XPath-filters are rarely implemented due to subtree-filters having = to implemented). Picking JSON would NOT be the kiss-of-death for CBOR = (or some other binary encoding) as *binary* offers real value in space = and time consumption. > =20 > =20 > Kent // contributor > =20 >=20 >=20 > =20 > I=E2=80=99ve also filled in the virtual hum. > =20 > Regards, > Rob > =20 > =20 > =20 > From: netconf > On Behalf Of Mahesh Jethanandani > Sent: 21 April 2020 01:48 > To: Netconf > > Subject: [netconf] Virtual hum for the question on "https-notif" draft > =20 >=20 > At the 107 NETCONF virtual meeting, the authors posed the question of = mandatory encoding for draft-ietf-netconf-https-notif = draft to = the WG. This virtual hum in the form of a survey is being presented to = record the response from the WG.=20 > =20 > Please respond by selecting one of the options in the survey page. > =20 > https://www.surveymonkey.com/r/68W3DX3 = > =20 > The relevant slide that was used for discussion was this. In addition = to the options discussed here, Rob suggested that the WG could defer to = the market to decide. > =20 > Thanks > =20 > Mahesh & Kent (as co-chairs) > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf = > =20 --Apple-Mail=_8D8CFB5F-FD07-4CF2-826E-3105C2832881 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This = email closes the virtual hum on the for the question on the = "https-notif=E2=80=9D draft.

As reported before, 70% picked "Let the market decide=E2=80=9D,= with the remaining 30% all picking "Publisher MUST implement = JSON encoding=E2=80=9D.

Rob raises a good point about the = language in RFC 8639, but the results of the poll reveal a = contradiction.  How can we =E2=80=9Clet the market decide=E2=80=9D = if a default MUST be picked?

The chairs are questioning how vetted = that text in RFC 8639 is, noting that RESTCONF also doesn=E2=80=99t pick = a default.  We wonder if the text in RFC 8639 should be softened. =  For instance:

  OLD:

 =  A specification for a transport MUST identify any encodings that = are
   supported.  If a configured = subscription's transport allows different
  =  encodings, the specification MUST identify the default = encoding.

  NEW:

   A specification for a transport = MUST identify any encodings that are
  =  supported.  If a configured subscription's transport allows = different
   encodings, the specification = MUST identify the default encoding, or
   provide a = mechanism whereby supported encodings can be discovered.

At = least, it seems that the intent of the draft is to handle the case for = when the =E2=80=9Cencoding=E2=80=9D leaf is not configured (since it=E2=80= =99s =E2=80=9Cmandatory false=E2=80=9D), more so than force = interoperability, but there are other ways to determine an encoding in = such circumstances, and thus maybe the text is overly = proscriptive?


The NETCONF = Chairs




On Apr = 27, 2020, at 11:48 AM, Rob Wilton (rwilton) <rwilton@cisco.com> = wrote:

At least the hum seems = to have narrowed it down to two choices (assuming sufficient = voices).

 

But I can see interop = benefit in defining at least one encoding that clients know will be = supported by the server.

 

Hence, I wonder if anyone wouldn=E2=80=99t be able to live = with:

 

  =E2=80=9CThe = default encoding is JSON.  Publishers MUST support JSON = encoding=E2=80=9D

 

* or a slight variant (that I don=E2=80=99t like so much) = would be to soften the MUST to a SHOULD, with the expectation that = servers that don=E2=80=99t support JSON would reject the configuration = unless the clients had specified an alternative supported encoding.

 

Rob

[As a contributor]

 

 

From:= Kent Watsen <kent+ietf@watsen.net>
Sent: 27 April 2020 16:28
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: Mahesh Jethanandani <mjethanandani@gmail.com>; netconf@ietf.org
Subject: Re: [netconf] Virtual hum for the question on = "https-notif" draft

 

 



On Apr 27, 2020, at 8:08 AM, Rob = Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org> wrote:

 

[As an individual = contributor]

 

Changing my stance somewhat from = the NETCONF meeting =E2=80=A6

 

After looking into the details a = bit more, section 7 of rfc8639 states:

 

   A specification for a transport MUST identify = any encodings that are

   supported.  If a configured subscription's = transport allows different

   encodings, the specification MUST identify the = default encoding.

 

Does this imply that the = http-notif draft either must state a default encoding (or otherwise = update rfc8639)?

 

It seems that way...at least when = https-notif is being used for RFC 8639 (it doesn=E2=80=99t have to = be).

 

Looking at the hum-results so = far, 70% picked "Let the market decide=E2=80=9D (with the remaining 30% = all picking "Publisher MUST implement JSON encoding=E2=80=9D). 

 

In light of the RFC 8639 text = quoted above, we might question the validity of the hum=E2=80=A6or, = given the strong preference from the hum, we might question the validity = of that constraint in RFC 8639.  If questioning RFC 8639, a better = question to ask might be why the configurable =E2=80=9Cencoding=E2=80=9D leaf = isn=E2=80=99t mandatory (also eliminating this issue and seemingly = cleaner)?

If so, my thinking is to make the = default encoding JSON, because it is easier to generate than XML, and = easier to convert into CBOR.  Clients don=E2=80=99t have to support = JSON if they know that the publisher supports a different encoding that they do support.

 

If we had to pick one, JSON is = more agreeable than XML.  Picking JSON would likely also be the = kiss-of-death for XML, as once support for JSON has been coded, it=E2=80=99= s unlikely XML support would be coded (like how XPath-filters are rarely = implemented due to subtree-filters having to implemented).  Picking JSON would = NOT be the kiss-of-death for CBOR (or some other binary encoding) as = *binary* offers real value in space and time consumption.

 

 

Kent // contributor

 



 

I=E2=80=99ve also filled in the = virtual hum.

 

Regards,
Rob

 

 

 

From: netconf <netconf-bounces@ietf.org> On Behalf Of Mahesh = Jethanandani
Sent: 21 April 2020 01:48
To: Netconf <netconf@ietf.org>
Subject: [netconf] Virtual hum for = the question on "https-notif" draft

 


At the 107 NETCONF virtual meeting, the authors posed the question of = mandatory encoding for draft-ietf-netconf-https-notif draft to the = WG. This virtual hum in the form of a survey is being presented to record the response = from the WG. 

 

Please respond by selecting one = of the options in the survey page.

 

https://www.surveymonkey.com/r/68W3DX3

 

The relevant slide that was used = for discussion was this. In addition to the options discussed here, Rob = suggested that the WG could defer to the market to decide.

 

Thanks

 

Mahesh & Kent (as = co-chairs)

_______________________________________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

 


= --Apple-Mail=_8D8CFB5F-FD07-4CF2-826E-3105C2832881-- From nobody Tue May 5 23:34:02 2020 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 77A3E3A05E2 for ; Tue, 5 May 2020 23:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=cesnet.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 KmnAo8yareQf for ; Tue, 5 May 2020 23:33:57 -0700 (PDT) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [78.128.211.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 927EB3A05AA for ; Tue, 5 May 2020 23:33:57 -0700 (PDT) Received: by kalendar.cesnet.cz (Postfix, from userid 999) id 2E4F660195; Wed, 6 May 2020 08:33:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1588746835; bh=XGktx5eRcwrF+Eyq0hwQV6Y4YBXLjp+RmtpsT52oUz4=; h=In-Reply-To:From:Date:Cc:To:Subject; b=T27e+MzwWB9SLEU0ZoOnFWdWbI8wNa/2QuuFahpywbZbQlj6PA+zwj8dM5QwhT5Gh OA4FHUUbeTHCDYc87zixIUV0LYPdekeFcPAyRt1hgQUe7lcHEH4sl7a+kX6fZ9Lg1m ZXKHonQkOYtlrNtGguGqsN9yA7GRybnou7g+tZN0= Content-Type: text/plain; charset="utf-8" In-Reply-To: <01000171e72582c2-2f87f408-9cd4-4970-af66-d309f57a49df-000000@email.amazonses.com> From: =?utf-8?q?Michal_Va=C5=A1ko?= X-Forward: 84.42.161.20 Date: Wed, 06 May 2020 08:33:55 +0200 Cc: =?utf-8?q?netconf=40ietf=2Eorg?= To: "Kent Watsen" MIME-Version: 1.0 Message-ID: <17c7-5eb25a80-25-3fe0c5c0@97757408> User-Agent: SOGoMail 2.3.23 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] =?utf-8?b?Pz09P3V0Zi04P3E/ICBpZXRmLW5ldGNvbmYtc2VydmVy?= =?utf-8?q?_and_ietf-netconf-client_keepalives?= 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, 06 May 2020 06:34:01 -0000 Hi Kent, thanks for the response and as long as you add the definition of SSH/TL= S keepalive I will have no more comments, as it seems the rest was disc= ussed and intentionally specified the way it is. Regards, Michal On Wednesday, May 6, 2020 01:22 CEST, Kent Watsen wro= te: > Hi Michal, > > > > On May 4, 2020, at 12:26 PM, Michal Va=C5=A1ko w= rote: > > > > Hi, > > in the current YANG modules in the drafts, there are 3 types of kee= palives defined for both a server and a client. They are SSH, TLS, and = TCP keepalives and can be configured separately for each connection (en= dpoint). > > > > While I understand what TCP keepalive is as it is a feature with ex= act definition, I am not that positive for SSH nor TLS. I can only assu= me the keepalive mechanisms from a Call Home [1] server are used. I wou= ld appreciate if the modules define the specifics of all these keepaliv= es because otherwise interoperability cannot be guaranteed. > > Good suggestion. Indeed, they would be the same as in RFC 8071 > > > > Also, the relation to the Call Home RFC itself should probably be m= entioned somewhere. > > draft-ietf-netconf-netconf-client-server currently has 11 references = to RFC 8071...not enough, or do you mean that the keepalive description= should say something like "consistent with RFC 8071, ..."? > > > > Meaning the answers to questions such as whether SHOULD each RESTCO= NF/NETCONF server use SSH/TLS keepalive even when a TCP keepalive is en= abled. I am also not sure about the need for all 3 types of keepalives,= needing to specify them for each connection , or allowing to support 2= kinds simultaneously, but that is just my opinion. > > Keepalives were heavily discussed with the TSV Area a couple years ag= o. The general takeaway was that keepalives SHOULD be defined for ever= y protocol, and that applications SHOULD use as many as makes sense, as= each tests a different thing and with varying levels of security. > > > > Thanks for any feedback. It is also possible I may have missed some= thing/am wrong and I am sorry in that case. > > > > Regards, > > Michal > > > > [1] https://tools.ietf.org/html/rfc8071#page-8 > > > > > Kent // contributor > > > From nobody Wed May 6 02:41:25 2020 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 0ACED3A07BB for ; Wed, 6 May 2020 02:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 99A4VwoO9hov for ; Wed, 6 May 2020 02:41:21 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80083.outbound.protection.outlook.com [40.107.8.83]) (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 AB0A83A07A5 for ; Wed, 6 May 2020 02:41:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U7UXzEVueTRQPuH+U9qs6AeNzcuMFIm+3hA9gQw5NhIqh/arpbJBQC8EA9QiUSF+hbb6wjqCadvbLukHFvDrF1xJy4gB3U+Ck4R9s0BRzTFiRrBfqsL4JGbXNb4mZHKIt05f5By/KFNrgFWDVDtXPiugfhO99hw+hLJ7IRZcCtkKDTpebquj1WDzNZvOrzDVVxa85KiaIMdsDNW38OpTn9fLBYTb3FJ8e8X+SVWoCTEecdNjqGooXfBx9lqb/THvZ+XTM3wFeMI1onIdMtzw7lriF2DG5ZnjKzmKGew2P/64sson4gs6MkWZ+HtXHjA4nEtiJVfLe8qVHyMjxqyZpw== 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=CvDPvzmtRFXKF01H8tzqGdDUGS6r+NYuHG7rO/eInoQ=; b=NyfDidgVAdaJTnghm5w5oR8IylzZ43HRpkqnG/tOYXDPSMQWbqS9r7Vi7+33iWHDR5LczVMrWpgTgUr5a0sUjtifA9WNbO9j5E/htvbtBIffTY730QCDHlDABLRzZ9n7ezfw47zrZd5WyyEHKgZCR5wB1GvLmWPZbBGJWjRf5yC3iPoV5YBtYbTzkhVY4QyyU/I0G3z/vj0tWHHGWl3v6Nop1ylw96qnxV0zpsvksKT1wlyR8h7hzJxjgTH/5QdbudTT46SPeU0GxQo+nxCIItMdn4lqk/H73i+30IveRQK9TtfEQMHvw77kKIc5dTvQLIzprl69ebZqLuYUDe+0Sg== 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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CvDPvzmtRFXKF01H8tzqGdDUGS6r+NYuHG7rO/eInoQ=; b=E/LUTpK5IwFslp/gNAuL8xBWe7/OHN+Bah7+bTRGcWpGNebQMv2XvPyF8E4B3ZI+DKM9+Ln8vFdRayI546nw9HQ4griDwHDfvhgyDSS7t5N+spTWLLarXQZB/XxSYCt/SH8e8NXp/2vmHJqs3FLGNMsbihnTNFudJiUW/ZAE/mI= Received: from AM0PR07MB4004.eurprd07.prod.outlook.com (2603:10a6:208:47::12) by AM0PR07MB5969.eurprd07.prod.outlook.com (2603:10a6:208:10f::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.18; Wed, 6 May 2020 09:41:18 +0000 Received: from AM0PR07MB4004.eurprd07.prod.outlook.com ([fe80::9462:5522:7e24:40e4]) by AM0PR07MB4004.eurprd07.prod.outlook.com ([fe80::9462:5522:7e24:40e4%6]) with mapi id 15.20.2979.024; Wed, 6 May 2020 09:41:18 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: "netconf@ietf.org" Thread-Topic: Identity of an OAM user behind ONAP or NMS Thread-Index: AdYjiM7lh+mF6H/UQMO8tt+YGRtHRw== Date: Wed, 6 May 2020 09:41:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [80.98.254.17] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4c026546-6202-4f9c-005a-08d7f1a1a0bf x-ms-traffictypediagnostic: AM0PR07MB5969: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 03950F25EC x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 644GYTTChrc1ILMOIgJ71XhXT7kbI9jtMyX55PttAtwzH1eP7LMcTM0ZgEqcgBxD6pSyMPAXSawRWugTkA9pMoiPBnrMIdfPjBnMq+Y8OPgqdnFFy1kNziirevP6YFHYQc9Y9w+3wemRRsqgkxwawMKOQhVQpI/98LRHx7edL6X8lFlUiAIs34/8iJ8NCro/MhuGEsUZv0bJzx9WIGjjRzx9hACghjoni5eaX0acQMaFPu9hXtLuxlws6Y/YAv8RhNNrUb2PBvPTUq3pGDi9zOwUDWZJ57rvjtWp2NEcIMVf6d7H0/h95wVMtUIXaw1UnmPsz0Vq2OO2Vo5/FKZiALdb3GlU0hTngoIsk4y/oDaoo7ftCDqlv9LmYmf0LL0S9zgNWG5DV6uswRaUSQztPBlKkwGPqkXzGoh6Tv2YDUQPE2RLBqVNeXfyjoEBcGeR2zjYGwPw1+9MqomA4tMeCVAQsk/svJRG1saVBge/nqJ1y5D4ytJznMXu41RH8kzaw5xqg7IX8/gSZCC5hF+jRQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB4004.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(346002)(136003)(39860400002)(396003)(376002)(33430700001)(86362001)(2906002)(8676002)(9326002)(52536014)(316002)(33656002)(8936002)(71200400001)(6506007)(26005)(186003)(6916009)(5660300002)(4744005)(7696005)(76116006)(66946007)(66616009)(66556008)(9686003)(64756008)(33440700001)(66446008)(478600001)(55016002)(66476007)(99936003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 2xkk5AIg0sx4uS15f+idstVdYP+JAQMPu55SMZzrResDe9UbcwvKjmKuX53frjd0VeZSBGn30/rMaKAd3Ilo4ZXt9TTNya9d3x0Xpm+ECxMJGmu6dnVg/LvT67ynfT98pe/9sPBhLZDkZso75MVBSDpJoS63yHVGu3ewVYGDmWfVoJyzMfaRDyA2vHml/z5ngbFoMBKmptkaVJMz42hRWpbbOE8IWd6IDG1PmGAbRnRhMf4kEL0uJdow4Pt16ujl7z6z5LSCNZ9WyHBYJ2YLBLhfbzW5nsKixBZBL3zp6DI3+bgD5+geeA60vLJzfhVHOfsUTyUl2NDu8ynlR1ycEXlBLTBwOtcByWQuHDhHx7VTZwJvtUcTLeVsj3myrMFM4bbSjWoBiBCZQ7MafrWR63BjyrTZd4IP3IyEoHlEHqFl46YCuvMT8N3vLynHgigUGGchyZ5EmjKwrVJ6AqHJB91T6MHVJB5fEnpecoiowFDq0lr2KEq2Wwf92EptZlwRjfFAlNEoxZDId87Og70JvHt4fDuc6RDEe/P4FCO78sDTHJUKnjI1VKU4eHlYmRglMlZqJXs24VxWRoxOqe/kk21UkRPtT8n5dUhHlYGtW3dxwyqVEfUi1WBxr5e581yn7Al1tg21iWmf3rVdNeUifTLsRwMvOJ34GFsIgqcWu/C1Eh+vmOMgI4mW4+dEISQjs+xMPhG7uTzx+ahxrkXtglXfCcyUX06EGLDRT7nLvM0WIqKFs7Ga+aAmEXsEQAMNo5pQ+thFyGw/pVSrR0eyQwQDQFVo4/ELKVDJVDY9zn4= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00FF_01D6239B.40BFE830" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4c026546-6202-4f9c-005a-08d7f1a1a0bf X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2020 09:41:18.4735 (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: gSCwC0fo2X6B6n+7387gQhOlLX0gZoydLS4Yd8AmsTAQ+/p9m2O/6krvkxhX5dl+bbJKdIgKBmsVeQzOL/x7KvzYV842L+ID4i2mqzkuxa4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5969 Archived-At: Subject: [netconf] Identity of an OAM user behind ONAP or NMS 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, 06 May 2020 09:41:23 -0000 ------=_NextPart_000_00FF_01D6239B.40BFE830 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0100_01D6239B.40BFE830" ------=_NextPart_001_0100_01D6239B.40BFE830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, We have systems where the Netconf client is actually a bigger management system like ONAP or a Network Management system (NMS). These systems have their own user management and access control with potentially many dozens of OAM users that can handle thousands of nodes. We do not want create and maintain these dozens of users in thousands of nodes. The idea is to have a single NMS user that has superuser rights and leave the access control to the NMS. However, this presents a problem: The Netconf server does not have the effective user identity who ordered the action in NMS. Still it would be good to include this effective userId in the audit trail logs on the Netconf server. IS there some standard way to send such a second effective-user-id to the Netconf server? Would there be interest for defining such a mechanism? Regards Balazs -- Balazs Lengyel Senior Specialist Ericsson Hungary Ltd. Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com ------=_NextPart_001_0100_01D6239B.40BFE830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

We have = systems where the Netconf client is actually a bigger management system = like ONAP or a Network Management system (NMS). These systems have their = own user management and access control with potentially many dozens of = OAM users that can handle thousands of nodes. We do not want create and = maintain these dozens of users in thousands of nodes. The idea is to = have a single NMS user that has superuser rights and leave the access = control to the NMS.

However, this = presents a problem: The Netconf server does not have the effective user = identity who ordered the action in NMS. Still it would be good to = include this effective userId in the audit trail logs on the Netconf = server.

 

IS there some standard way to send such a second = effective-user-id to the Netconf server? Would there be interest for = defining such a mechanism?

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_0100_01D6239B.40BFE830-- ------=_NextPart_000_00FF_01D6239B.40BFE830 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 DTIwMDUwNjA5NDExNlowIwYJKoZIhvcNAQkEMRYEFBuz5+SfQZ/gwTcKQzGNiwXashQLMEMGCSqG SIb3DQEJDzE2MDQwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG BSsOAwIaMGsGCSsGAQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8x ITBtBgsqhkiG9w0BCRACCzFeoFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUw IwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITAN BgkqhkiG9w0BAQEFAASCAQA/HuoOJetghSeT2N5bWCzRXTpwpYxaK+UbLDpNB3AOY0VMRm7K7Ap0 QjDPGNqonpWQ1C1nSe1cHhU3y16XpVDilTaBx41lKmge1dbw1AatEbVcc+D6Znf2xZmGPxAEWUsM YmTZyUZwHZ6h39T/5TQVMmXpbEOprA0/ySwFmkBeEZZT53waaajgPS2dkHd+3Siqw3+QttVd/R81 tNXqo6Y670J+TCXBRlHFQyqqerapLv3TncnEnqBC+1uNTrjhmpEeXze0vGzB1TAWuc11+z477FbH NRisM3jWfiPoNU44vLP3Tl8V4g2a31bmzsvsFe+SVCZxQwPMwubKGZhvxkFxAAAAAAAA ------=_NextPart_000_00FF_01D6239B.40BFE830-- From nobody Wed May 6 03:12:20 2020 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 CDE1C3A08AF for ; Wed, 6 May 2020 03:12:18 -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, HTML_MESSAGE=0.001, 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 h14V8jEkv-S8 for ; Wed, 6 May 2020 03:12:17 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9E63A08AC for ; Wed, 6 May 2020 03:12:17 -0700 (PDT) Received: from [192.168.1.121] (213-67-237-150-no99.tbcn.telia.com [213.67.237.150]) by mail.tail-f.com (Postfix) with ESMTPSA id E411D1AE0290; Wed, 6 May 2020 12:12:15 +0200 (CEST) From: Jan Lindblad Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2B1DC335-F32E-4C03-B84C-DBB96F645F78" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 6 May 2020 12:12:15 +0200 In-Reply-To: Cc: "netconf@ietf.org" To: =?utf-8?Q?Bal=C3=A1zs_Lengyel?= References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [netconf] Identity of an OAM user behind ONAP or NMS 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, 06 May 2020 10:12:19 -0000 --Apple-Mail=_2B1DC335-F32E-4C03-B84C-DBB96F645F78 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Bal=C3=A1sz, > Hello, > We have systems where the Netconf client is actually a bigger = management system like ONAP or a Network Management system (NMS). These = systems have their own user management and access control with = potentially many dozens of OAM users that can handle thousands of nodes. = We do not want create and maintain these dozens of users in thousands of = nodes. The idea is to have a single NMS user that has superuser rights = and leave the access control to the NMS. > However, this presents a problem: The Netconf server does not have the = effective user identity who ordered the action in NMS. Still it would be = good to include this effective userId in the audit trail logs on the = Netconf server. > =20 > IS there some standard way to send such a second effective-user-id to = the Netconf server? Would there be interest for defining such a = mechanism? This is one of the areas where operators' choices vary greatly, in my = experience. The most common basic approach, as far as I have seen, is to = actually use the real user id towards devices. If nothing else, so for = auditing purposes. In order not to have to store user credentials on = thousands of nodes, which as you say would be a problem, remote = authentication protocols like Radius, LDAP or TACACS+ are configured on = the nodes. Best Regards, /jan --Apple-Mail=_2B1DC335-F32E-4C03-B84C-DBB96F645F78 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Bal=C3=A1sz,

Hello,
We have = systems where the Netconf client is actually a bigger management system = like ONAP or a Network Management system (NMS). These systems have their = own user management and access control with potentially many dozens of = OAM users that can handle thousands of nodes. We do not want create and = maintain these dozens of users in thousands of nodes. The idea is to = have a single NMS user that has superuser rights and leave the access = control to the NMS.
However, this presents a problem: The Netconf server does not = have the effective user identity who ordered the action in NMS. Still it = would be good to include this effective userId in the audit trail logs = on the Netconf server.
 
IS there some standard way to send such a second = effective-user-id to the Netconf server? Would there be interest for = defining such a mechanism?

This is one of the areas where operators' choices = vary greatly, in my experience. The most common basic approach, as far = as I have seen, is to actually use the real user id towards devices. If = nothing else, so for auditing purposes. In order not to have to store = user credentials on thousands of nodes, which as you say would be a = problem, remote authentication protocols like Radius, LDAP or TACACS+ = are configured on the nodes.

Best = Regards,
/jan

= --Apple-Mail=_2B1DC335-F32E-4C03-B84C-DBB96F645F78-- From nobody Wed May 6 08:38:31 2020 Return-Path: <01000171eaa35a8f-47fb4c11-764e-4412-a8b3-d6d0a71a3a29-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 F07043A0AD1 for ; Wed, 6 May 2020 08:38: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_MSPIKE_H2=-0.001, 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 V7wk4PPLOqZZ for ; Wed, 6 May 2020 08:38: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 B32A63A0B3B for ; Wed, 6 May 2020 08:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1588779506; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=YizOq5p44F1PYZhfNWrz8wjrzDseSxdMniqnXG29/9E=; b=ZbA0USXQSj1s3R/ek0x03hrusY/zmtIXqLgSQFjWjzasChnkLw/QVFHjhflRTPjN ABjOeZJNEX33ctYa0TgsL7GVW2b5jxscziw2Rk3uHWlcLA0PdLN+GYYFFYSdNc3anzm 177AVNW+7cNcuGYfjO8BbWHOo1GIuL8L1l+99ouY= From: Kent Watsen Message-ID: <01000171eaa35a8f-47fb4c11-764e-4412-a8b3-d6d0a71a3a29-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E3DE9EFA-7CD2-4BE5-AF30-D9DE4FEB8650" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 6 May 2020 15:38:26 +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: 2020.05.06-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Identity of an OAM user behind ONAP or NMS 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, 06 May 2020 15:38:30 -0000 --Apple-Mail=_E3DE9EFA-7CD2-4BE5-AF30-D9DE4FEB8650 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Balazs, > We have systems where the Netconf client is actually a bigger = management system like ONAP or a Network Management system (NMS). These = systems have their own user management and access control with = potentially many dozens of OAM users that can handle thousands of nodes. = We do not want create and maintain these dozens of users in thousands of = nodes. The idea is to have a single NMS user that has superuser rights = and leave the access control to the NMS. This is what I=E2=80=99ve seen mostly: assuming NMS is the master, all = AAA happens there. > However, this presents a problem: The Netconf server does not have the = effective user identity who ordered the action in NMS. At first I thought you were going to say this is an issue because the = server can=E2=80=99t implement access control, but it seems it=E2=80=99s = more to do with attributing the userid in the audit trail logs... > Still it would be good to include this effective userId in the audit = trail logs on the Netconf server. Assuming the only goal is to correlate the server-generated audit logs, = techniques I=E2=80=99ve seen used include: 1) temporal correlation: i.e., assume the audit logs generated by a = server in some window of time immediately after a configuration update = are related to that update event, and hence attributed to the NMS user. = PROs: no device modification required. CONs: assumes non-overlapping = and somewhat infrequent updates. 2) opaque correlation: if the device supports either a) accepting an = opaque value in the request or b) generating an UID that it returns in = the RPC-reply that, in other case, it outputs in downstream audit logs. = This value can be used by the NMS to correlate audit-logs to the = NMS-update, from which the NMS-user can be determined. PROs: = deterministic. CONs: requires device support. 3) use remote-auth protocols, mentioned by Jan Lindblad. PROs: also = supports out-of-band updates. CONs: requires greater network = infrastructure access from all the servers. > IS there some standard way to send such a second effective-user-id to = the Netconf server? Would there be interest for defining such a = mechanism? If solely interested in audit-logs generated when is updated, = then it is effectively always a synchronous update. But from the = opstate-reqs days, it would be good to know when an update is *applied* = (see requirement 2B in draft-ietf-netmod-opstate-reqs-04 = ). Of = course, this consideration is additionally complex in cases, e.g., when = a line-card is plugged in. Nonetheless, for cases where the device knows that the RPC will be = processed asynchronously, it might be good to return in the RPC-reply a = handle (UID) that can be used in subsequent requests and/or returned in = audit-logs for offline correlation. An I-D along these lines might be = generally useful. Kent // contributor --Apple-Mail=_E3DE9EFA-7CD2-4BE5-AF30-D9DE4FEB8650 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Balazs,

We have = systems where the Netconf client is actually a bigger management system = like ONAP or a Network Management system (NMS). These systems have their = own user management and access control with potentially many dozens of = OAM users that can handle thousands of nodes. We do not want create and = maintain these dozens of users in thousands of nodes. The idea is to = have a single NMS user that has superuser rights and leave the access = control to the NMS.

This is what I=E2=80=99ve seen mostly: assuming = NMS is the master, all AAA happens there.


However, = this presents a problem: The Netconf server does not have the effective = user identity who ordered the action in NMS. =

At first I = thought you were going to say this is an issue because the server = can=E2=80=99t implement access control, but it seems it=E2=80=99s more = to do with attributing the userid in the audit trail = logs...


Still it would be good to = include this effective userId in the audit trail logs on the Netconf = server.

Assuming the = only goal is to correlate the server-generated audit logs, techniques = I=E2=80=99ve seen used include:

1) = temporal correlation:  i.e., assume the audit logs generated by a = server in some window of time immediately after a configuration update = are related to that update event, and hence attributed to the NMS user. =  PROs: no device modification required.  CONs: assumes = non-overlapping and somewhat infrequent updates.

2) opaque correlation: if the device supports = either a) accepting an opaque value in the request or b) generating an = UID that it  returns in the RPC-reply that, in other case, it = outputs in downstream audit logs.  This value can be used by the = NMS to correlate audit-logs to the NMS-update, from which the NMS-user = can be determined.  PROs: deterministic.  CONs: requires = device support.

3) use remote-auth = protocols, mentioned by Jan Lindblad.   PROs: also supports = out-of-band updates.  CONs: requires greater network infrastructure = access from all the servers.


IS there = some standard way to send such a second effective-user-id to the Netconf = server? Would there be interest for defining such a = mechanism?

If = solely interested in audit-logs generated when <intended> is = updated, then it is effectively always a synchronous update. But from = the opstate-reqs days, it would be good to know when an update is = *applied* (see requirement 2B in draft-ietf-netmod-opstate-reqs-04).  Of course, this = consideration is additionally complex in cases, e.g., when a line-card = is plugged in.

Nonetheless, for = cases where the device knows that the RPC will be processed = asynchronously, it might be good to return in the RPC-reply a handle = (UID) that can be used in subsequent requests and/or returned in = audit-logs for offline correlation.  An I-D along these lines might = be generally useful.


Kent // contributor



= --Apple-Mail=_E3DE9EFA-7CD2-4BE5-AF30-D9DE4FEB8650-- From nobody Wed May 6 08:58:36 2020 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 55F463A0B93 for ; Wed, 6 May 2020 08:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=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 Tttb2J7UPfk2 for ; Wed, 6 May 2020 08:58:29 -0700 (PDT) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (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 2C8333A0871 for ; Wed, 6 May 2020 08:58:29 -0700 (PDT) Received: by mail-yb1-xb31.google.com with SMTP id o8so105228ybc.11 for ; Wed, 06 May 2020 08:58:28 -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=JH2DPdoGonK1an+mltBAmT/TurSLqzL5t+NOVgAY5DA=; b=wAkgabM6GSNXlp4lb3obqR1Sei6CwL92I07SncPPuptvboqf/7yvYZw/2iD/jr83PJ 0Z0vVAqZyBSBx01+cMK9PEUDjzWWtDvqQDrFCs+G+XsmXRVhRQxKBImartqzZQD0dWUn PSKYg6H+HP1nqT9RmbVdlhL0ktkFmfsSYyomXYZzdfKwyPKpASovVYWHEhr3Tgj7kGKH Y3+HxrsCQHadNw/FEitp9jI3xVVVQ6PiImg1OjIHrqdrpdwoxlFsPwLFOYBGu+vQ0vpA 8r4JuLLswcSs5zo4vqvfkTf6KIrMePkTVOmIM4u6p3wE2gfH8FbAAzGncBBBxQDxhN/8 Km1w== 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=JH2DPdoGonK1an+mltBAmT/TurSLqzL5t+NOVgAY5DA=; b=B1HpwYHyS7o6MYzz1g/c9CbfTvI6uVTYNR3DXHfdtIonjL14idPz0y+WdoByQn9aeP VrcYGKYmbtMKcznPX8XhWJMxsfHA77JSPUlZ0dbjoqTlleDUfFywVTXClHkWKD74PMei /cukP4n+XqEpuRosXzuSQSRTZXiG2i8l7Yn3izqu1LCetAeGbdz2FuUle5J19U6biisM G6OxD2WJMpv8Oc0EbG8NJJnths7V83XkwMCgHls6dyHOl452s6qEORLEGFbt/6BWRztJ twQzSY/cjMqDLzwUPxDI3b/y5YqEmbIRqvZH+kmBsRpXHcKftT//aEr3LP3kF0ZBMfO2 xbRw== X-Gm-Message-State: AGi0PubDDlGffF5mSGnrHzzAYOIII5m7IFhxioJ0Oh704Sk6+t1nDyez gGp4rCE+SNPAYtGI05NeQtba8KpTeqZn2HCBILUBd4Z1 X-Google-Smtp-Source: APiQypIGSe3ypYlRb5jkQOmkBRltuJCCP9hy+SovlqAQhBGUPuSkX5MQABINHkfGMWZrwV9UTNTORkb+N+PPPdZ3Gis= X-Received: by 2002:a5b:cd0:: with SMTP id e16mr13803682ybr.107.1588780708009; Wed, 06 May 2020 08:58:28 -0700 (PDT) MIME-Version: 1.0 References: <01000171eaa35a8f-47fb4c11-764e-4412-a8b3-d6d0a71a3a29-000000@email.amazonses.com> In-Reply-To: <01000171eaa35a8f-47fb4c11-764e-4412-a8b3-d6d0a71a3a29-000000@email.amazonses.com> From: Andy Bierman Date: Wed, 6 May 2020 08:58:17 -0700 Message-ID: To: Kent Watsen Cc: =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ba307b05a4fcd571" Archived-At: Subject: Re: [netconf] Identity of an OAM user behind ONAP or NMS 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, 06 May 2020 15:58:34 -0000 --000000000000ba307b05a4fcd571 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 6, 2020 at 8:38 AM Kent Watsen wrote: > Hi Balazs, > > We have systems where the Netconf client is actually a bigger management > system like ONAP or a Network Management system (NMS). These systems have > their own user management and access control with potentially many dozens > of OAM users that can handle thousands of nodes. We do not want create an= d > maintain these dozens of users in thousands of nodes. The idea is to have= a > single NMS user that has superuser rights and leave the access control to > the NMS. > > > This is what I=E2=80=99ve seen mostly: assuming NMS is the master, all AA= A happens > there. > > > However, this presents a problem: The Netconf server does not have the > effective user identity who ordered the action in NMS. > > > At first I thought you were going to say this is an issue because the > server can=E2=80=99t implement access control, but it seems it=E2=80=99s = more to do with > attributing the userid in the audit trail logs... > > > Still it would be good to include this effective userId in the audit trai= l > logs on the Netconf server. > > > Assuming the only goal is to correlate the server-generated audit logs, > techniques I=E2=80=99ve seen used include: > > 1) temporal correlation: i.e., assume the audit logs generated by a > server in some window of time immediately after a configuration update ar= e > related to that update event, and hence attributed to the NMS user. PROs= : > no device modification required. CONs: assumes non-overlapping and > somewhat infrequent updates. > > 2) opaque correlation: if the device supports either a) accepting an > opaque value in the request or b) generating an UID that it returns in t= he > RPC-reply that, in other case, it outputs in downstream audit logs. This > value can be used by the NMS to correlate audit-logs to the NMS-update, > from which the NMS-user can be determined. PROs: deterministic. CONs: > requires device support. > > 3) use remote-auth protocols, mentioned by Jan Lindblad. PROs: also > supports out-of-band updates. CONs: requires greater network > infrastructure access from all the servers. > > > IS there some standard way to send such a second effective-user-id to the > Netconf server? Would there be interest for defining such a mechanism? > > > If solely interested in audit-logs generated when is updated, > then it is effectively always a synchronous update. But from the > opstate-reqs days, it would be good to know when an update is *applied* > (see requirement 2B in draft-ietf-netmod-opstate-reqs-04 > ). Of > course, this consideration is additionally complex in cases, e.g., when a > line-card is plugged in. > > Nonetheless, for cases where the device knows that the RPC will be > processed asynchronously, it might be good to return in the RPC-reply a > handle (UID) that can be used in subsequent requests and/or returned in > audit-logs for offline correlation. An I-D along these lines might be > generally useful. > > There is another (low-tech) solution possible -- add a "comment" leaf to the commit and edit-config operations and add the comment to the audit-log entry for the datastore update. > Kent // contributor > > > > Andy > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000ba307b05a4fcd571 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, May 6, 2020 at 8:38 AM Kent W= atsen <kent@watsen.net> wrote:=
Hi Balazs,

We have systems where the Netco= nf client is actually a bigger management system like ONAP or a Network Man= agement system (NMS). These systems have their own user management and acce= ss control with potentially many dozens of OAM users that can handle thousa= nds of nodes. We do not want create and maintain these dozens of users in t= housands of nodes. The idea is to have a single NMS user that has superuser= rights and leave the access control to the NMS.

This is what I=E2=80=99ve seen mostly: assuming NMS is th= e master, all AAA happens there.


Howe= ver, this presents a problem: The Netconf server does not have the effectiv= e user identity who ordered the action in NMS.

At first I thought you were going to say this is an issue = because the server can=E2=80=99t implement access control, but it seems it= =E2=80=99s more to do with attributing the userid in the audit trail logs..= .


Still it would be good to include this effective userId in the audi= t trail logs on the Netconf server.

= Assuming the only goal is to correlate the server-generated audit logs, tec= hniques I=E2=80=99ve seen used include:

1) tempora= l correlation: =C2=A0i.e., assume the audit logs generated by a server in s= ome window of time immediately after a configuration update are related to = that update event, and hence attributed to the NMS user.=C2=A0 PROs: no dev= ice modification required.=C2=A0 CONs: assumes non-overlapping and somewhat= infrequent updates.

2) opaque correlation: if the= device supports either a) accepting an opaque value in the request or b) g= enerating an UID that it =C2=A0returns in the RPC-reply that, in other case= , it outputs in downstream audit logs.=C2=A0 This value can be used by the = NMS to correlate audit-logs to the NMS-update, from which the NMS-user can = be determined.=C2=A0 PROs: deterministic.=C2=A0 CONs: requires device suppo= rt.

3) use remote-auth protocols, mentioned by Jan= Lindblad. =C2=A0 PROs: also supports out-of-band updates.=C2=A0 CONs: requ= ires greater network infrastructure access from all the servers.
=

IS there some standard way to send such a se= cond effective-user-id to the Netconf server? Would there be interest for d= efining such a mechanism?

If so= lely interested in audit-logs generated when <intended> is updated, t= hen it is effectively always a synchronous update. But from the opstate-req= s days, it would be good to know when an update is *applied* (see requireme= nt 2B in=C2=A0draft-ietf-netmod-opstate-reqs-04).=C2= =A0 Of course, this consideration is additionally complex in cases, e.g., w= hen a line-card is plugged in.

Nonetheless, for ca= ses where the device knows that the RPC will be processed asynchronously, i= t might be good to return in the RPC-reply a handle (UID) that can be used = in subsequent requests and/or returned in audit-logs for offline correlatio= n.=C2=A0 An I-D along these lines might be generally useful.

=

There is another (= low-tech) solution possible -- add a "comment" leaf to the commit= and edit-config operations
and add the comment to the audit-log = entry for the datastore update.=C2=A0



Kent // contributor=





Andy
=C2=A0
=
_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000ba307b05a4fcd571-- From nobody Thu May 7 00:18:12 2020 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 DBA313A08D4 for ; Thu, 7 May 2020 00:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 FUqTPZ5mlGLx for ; Thu, 7 May 2020 00:17:43 -0700 (PDT) Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) (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 CE03E3A0982 for ; Thu, 7 May 2020 00:17:42 -0700 (PDT) Received: by mail-lj1-x242.google.com with SMTP id e25so5153092ljg.5 for ; Thu, 07 May 2020 00:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=/2e72nvfRBBYHPPJQsQrzCobCLh7OpVTU5VDi3Wj9+U=; b=nrXSLuVU7SrKG5sS7fLyN+GIUMal7ms/smqfDs6l8QVlC6Ew8EjXoYhAcSQfJOUdl+ DNpRUuz6HasEbgqlPunXHua9F/LG9hx59VQlSAWhRCm2CJTuhOmWLxpY+/xpp2RUNPE7 YhpaklPdiNPNvecMjWTxYmP28k6mmhEp+R8NILqlegVASeAlvg/ijje42dIBloxOF2G8 UJ3GK2E3QtFh0cX4KqR8gc4w8vqeNMpEhn8E1kudnf+Ty0Hg16osVgwj+jFUKowt+AuU 8XJ+DChZ+euCDqvHrxzamslGv8rFPFxQhpYjXLDNjoPMQmmoztOxiSwVE6bq5WdXq3jT DPJw== 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=/2e72nvfRBBYHPPJQsQrzCobCLh7OpVTU5VDi3Wj9+U=; b=gewIjbhCUDAmmMoTG4N+OgP4PDz6J/XYUTIgxl9C9XvZRlDG0ykB2avxqQNaNx1q0S 4Uq+jrpkf439XmzHlbQ4aHc3CcF3zVpdQxYFc9absbTfsbZzH+a8DLxaSFHQDQmANaYj jghk+R9glamKpJ35eJa8EQNISeb2O7LJq6dQyOoAbJk8GIPVeJuLYQJAS6Yu9PkHvoNT eNR26XMnzotfGdrSFeq/GbNMIKwPjOwFOKfHF7MrNHRpkXH9wzHuIp56d9bCN5BwLZsW gaSPk35JtE0dn72Qu5UE4rEaQ0OcZlDwO3yiN/lTouiZgNSPMtQd/N3uvYdJ1bH7TbwN VhHg== X-Gm-Message-State: AGi0PubQ9IO6QI/QRvmhAYB6Y2uSYEpDAygdaV5KC9wOaPj+XD6S1G+r 5i0e61RXXybBFNPj7N4JELTkFp5z7+3B4850zklXL4T6 X-Google-Smtp-Source: APiQypIJg4TUj1WWopiQ3QuA+Bjr7M6F9LjkBesScol/SjGPbW9JaEo5vRsE/6z3+BUN155JTN7BVFL3n2F/lClHpRo= X-Received: by 2002:a2e:b891:: with SMTP id r17mr7532518ljp.34.1588835860598; Thu, 07 May 2020 00:17:40 -0700 (PDT) MIME-Version: 1.0 From: Henning Rogge Date: Thu, 7 May 2020 09:17:14 +0200 Message-ID: To: netconf@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [netconf] Question about RFC8040 data root node and depth example 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, 07 May 2020 07:17:46 -0000 Hi, while working myself through all the RFC8040 examples, two more questions came up. The first question is about the depth=3 example in B.3.2. If I understand the YANG file for the example correctly, both the "artist" and "song" entry are lists... why do they have a { } value in the example instead of a [ ] one? The second is about GET queries directly to the /data node, as it is done in example B.3.3. Is the server meant to "join" both the ietf-restconf, ietf-yang-library and the "user" datamodel into a larger one? This is interesting because the ietf-restconf yang model does not event implement any container, only a grouping that could be used by other models. Henning Rogge From nobody Thu May 7 02:46:10 2020 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 F05213A0B00 for ; Thu, 7 May 2020 02:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=l3YEeV+9; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=GlNz64Ra 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 PVq4cZ3BDdk1 for ; Thu, 7 May 2020 02:46:06 -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 4C8A23A0AF9 for ; Thu, 7 May 2020 02:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1446; q=dns/txt; s=iport; t=1588844766; x=1590054366; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=mTD4acjmq0ONNzZ4ZsgwkbYfGXT7qD+1sMbWKKtHk00=; b=l3YEeV+9BIHyTafumgjtI2Df3Avk7nk6lF9rw3DYsNC8QHBjxn0Or37X 875xEyMpjkzhSJccjgfI8ajDV292VNgbzTbhYiFL+qp8G+YVHk+NV76uC ahfIxivWlTOfo3vlEe9Xd+m3xYc0o4PwmCnS6hJjEA5Jg1akWBCX9NsOp Q=; IronPort-PHdr: =?us-ascii?q?9a23=3Aksy9IxJEbx5R0P19Z9mcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvKk/g1rAXIGd4PVB2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YkdQEcf6IVbVpy764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D?= =?us-ascii?q?=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B1DAAz2LNe/5BdJa1MGh4BAQsSDEC?= =?us-ascii?q?BPAuBVCkoBW5YLyoKh18Diy6CEYl5jjyBLoEkA1QLAQEBDAEBIwoCBAEBhEQ?= =?us-ascii?q?CggUkNQgOAgMBAQsBAQUBAQECAQUEbYVWDIVyAQEBAgESLgEBOAQLAgEIDjg?= =?us-ascii?q?hESUCBAESCBqCOUyCSwMOIAEOPKRqAoE5iGF0gTSDAAEBBYUlDQuCDgMGgTi?= =?us-ascii?q?CY4lhGoFBP4FUgh8uPoEEgRpJBBqBMRgCg0OCLZkNmH5KCoJIk0yEZ50gHY9?= =?us-ascii?q?6jBqRAgIEAgQFAg4BAQWBVAI1EYFFcBWDJFAYDZBCg3KFFIVCdAI1AgYIAQE?= =?us-ascii?q?DCXyQOgGBDwEB?= X-IronPort-AV: E=Sophos;i="5.73,363,1583193600"; d="scan'208";a="474734355" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 May 2020 09:46:05 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 0479k2QE007686 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 May 2020 09:46:05 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 7 May 2020 04:46:02 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 7 May 2020 04:46:01 -0500 Received: from NAM02-SN1-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.1497.2 via Frontend Transport; Thu, 7 May 2020 05:46:01 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L/v/lGAqqBkTQGO6X7s/CWcm6Eyxu+sWEssiai8iyI3PpR4LkT087AozIzsB0s5VSQQgLpKiO7dxJTEBv9q5yhuR7vdXoCs1ZHlvjB5VP3G0zZ0WZ9ERfCGLUwYSGqMpdmpCH1d99dAt/7uIEkRaMURzh3v4fXOeKXRaJ5si/D48n1U37KFBIrqzdWF0vRlN1P+AOTO9jc9zfXiDTwAxWyE7ZiyPr9vIuuSCjCG0XGcHALqbZ9IGSMHpC1CBrw60NiMrnHmJDOdA/ssLqrIrcGluFE7tecq3YsF6pCwEw3ZU8bBZ7dbWBt45xi/Wz96bT3ygmtBYuSnAsTk1yPLE5Q== 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=/MlF7dxESGm47DQ6qEG/UFYjagrcPdQ3Wb0iKBbsHqc=; b=O8SenZI0Xie7IMAljXkNXNaEo+AaeKgNXKd5H2vdw3Qc0i/8NPcuV0pD3sRxyD9LdBggYi4MigHtsS9MZchxf8EVSdsK8QFn7YeN0f7UfXJDUsRLj4dj5JuAOkLqN9Opilhow0LSDoCQ6tgXN7ssy5UPecklhO+IYU1J3EUYpQ2IFHRyACoGp1ZcW/pyBDL3lun+sKGndrWEADPMCbz4x5BVHf6O7WU2erC4hoHFjc1D9soBGDqGxbwbBIFB0ilgJ+a+2z1n+4mz1DK9Ut2rnHoz6ECVrZsg3V0M66fmKZmn+PpkJ+iUV55kchC6EtRT8uSAMXRCmK30xgxdRkCisw== 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=/MlF7dxESGm47DQ6qEG/UFYjagrcPdQ3Wb0iKBbsHqc=; b=GlNz64RaAfJ0GDbU+jY0GD+G6aoHE0I8bUZ5bqVKIM0P8FPXtJ+Acpe27QjcBFTSJH1NwM50QhsQ8YxCnvjm2Nsigd4ycAUeRzOl+mbl+vYFMfYfWtT5yH88S5GMbqsQINNxya3NFAog5ms9ORLv9tShtUlFmJ0Rpz+EBDRzF6M= Received: from DM6PR11MB3818.namprd11.prod.outlook.com (2603:10b6:5:145::22) by DM6PR11MB4361.namprd11.prod.outlook.com (2603:10b6:5:1df::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.26; Thu, 7 May 2020 09:46:00 +0000 Received: from DM6PR11MB3818.namprd11.prod.outlook.com ([fe80::597c:ff4:6845:c945]) by DM6PR11MB3818.namprd11.prod.outlook.com ([fe80::597c:ff4:6845:c945%3]) with mapi id 15.20.2979.028; Thu, 7 May 2020 09:46:00 +0000 From: "Per Andersson (perander)" To: Henning Rogge , "netconf@ietf.org" Thread-Topic: [netconf] Question about RFC8040 data root node and depth example Thread-Index: AQHWJD+yoUO+XWZSK0KzI7OByDeRIaicW8t6 Date: Thu, 7 May 2020 09:46:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.220.61] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 55dff76a-122b-4dfa-dc2f-08d7f26b737b x-ms-traffictypediagnostic: DM6PR11MB4361: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 03965EFC76 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: M0uwv+QQqzEY6T5a3tbLaoZE8lRHZ1cZ/igtOlUWYnf3J9IjlUQ5d+zgu++3aR2w7zYqn3SlLZjnPG1rfH9cejX5eIAtS3/v1sWKyhkqn3ox9bydpUJcT2txSIfAc4YGU//E9yIWvaDbRhk8BCypGUIPJ3fPcYcTtr6DsEyIv0nlAaph+tvPRELrM2rpMMsVXlmoLEEfHhxpL1oOI4AagawNWqO5wuXTh8U5H0PhgmTIIWbQV8A7JVge1Xvr2ZLk2Q097KFwVfHVuTJrWTbpIrCnoeff8zaNK/vYsjf39E02N1r5kzvW0cjXCAoBg+5ZM3zJJ0iW4dHecem18LQ38Qp9IeCnp7qEmmP2+COs33wbsK6Sh1h9qheWSKReBZLjWx22m1mMsBrejyigChIwFOXEq4UCAjGwkgG8Y8MyVdAKqml1RSzdeUrm1cBCd9Hwv3GM8btHgrnS9nVIgTtmR4ttOENuyTY4o7ElpLWN8xIIooVsaQd9dOINvGBMMkfvmgIrIvTjupNR/kkpm9jLSY8GUQBs3MGDE3Kloj3b4wXjZFBAFLg71k17CJ5ZqXu1hZ7uJ4sIFZCujdKe2Qsh2vP6RkgHAw5ct5Ie9LPljSk= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3818.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(136003)(39860400002)(346002)(376002)(33430700001)(76116006)(91956017)(16799955002)(71200400001)(186003)(26005)(8676002)(5660300002)(2906002)(8936002)(52536014)(66556008)(33440700001)(966005)(110136005)(66446008)(66946007)(9686003)(55016002)(86362001)(33656002)(83320400001)(83280400001)(478600001)(7696005)(6506007)(83310400001)(64756008)(316002)(83300400001)(66476007)(83290400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: lrUYZHHjN1nboMkOGWziE9Ima3MhXYSjouGsr46Ooz4wLt5P1g0FFipK386jNVln6aowDX4LtCynvV5PjwAeupOeumMogJVJJ0ulZTF3YmTB0t8y3RCyZlMyPEozXF+3rocE/VG6CjAHx3k6BmSA4NbJuFM3W11YZcZGVhDF6JATt7RlIZr3uUTghUJ+tFY5dBD0JiVcZNv+EpzDjhtmgPRoLgdOoxdFUvfrNP6IZdJBx3tRQLXogRhNqTZAB5RNkeR7cATxxImt217fURXiGkKLvGak9Co7oMct3JYGOJndXAGa65MpX0CfM6b4Yf9aZt6/0jJU+E8zJV2Y9gRz9QgVpnykI4BTcGmKWS2bvTJrdEqnNTPJrf9LAN4GzDeFWTtBKnvkSQb/d7MqyV6rA7lCAqB6KCFR/W4WSFYfOhnlUO+SIQer6njHV6dL7y+4l5Qf5pmvkYpSSpPTnFjP3JtE1tU2XC1eOnqG+yquapDtOc2a5qZEz8H+QuxEIQ3eOLPkEJiro3WZlQuZelEhQzmZyG2fkoxOCUFKeK+EjiVPom32BgspvavtphrBOegv8c27pYASO6sdAlNZblKM2B9oUGHcju+tFif6JALjaFjI9ZjUlia8Lax9UOH/psBXtEZpTtuVnCTqKaG1TYhDD1mxPbn+FRMxnKIN3vhxCJ6wxCpyxPQsB+B6rspIMqkqhDd+HoAatABKD3dxEMzAoTdgNbjTeg2eOA3898OvPpjGXq4201RrfJywUvLzFzsVlkpga1fqlcVFAb2mXab0+fq41gBd//DHJJoHww+q0uc= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 55dff76a-122b-4dfa-dc2f-08d7f26b737b X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2020 09:46:00.7944 (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: WS0u90kB8cF8ezlhE/bHypFtKh1lV/Hmt7e0NM0IOX40xbI1gFDoShT9LQ7DhUXQ/vtao/IsO++3kVGgBhSnsA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4361 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [netconf] Question about RFC8040 data root node and depth example 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, 07 May 2020 09:46:08 -0000 > Henning Rogge on Thursday, May 7, 2020 09:17:=0A= =0A= > The first question is about the depth=3D3 example in B.3.2. If I=0A= > understand the YANG file for the example correctly, both the "artist"=0A= > and "song" entry are lists... why do they have a { } value in the=0A= > example instead of a [ ] one?=0A= =0A= I would say this is an error in RFC 8040, there is no note about it=0A= in the Errata. [0]=0A= =0A= A similar issue is corrected in the Errata for the example in B.3.1.=0A= =0A= [0] https://www.rfc-editor.org/errata_search.php?rfc=3D8040=0A= =0A= =0A= > The second is about GET queries directly to the /data node, as it is=0A= > done in example B.3.3.=0A= >=0A= > Is the server meant to "join" both the ietf-restconf,=0A= > ietf-yang-library and the "user" datamodel into a larger one? This is=0A= > interesting because the ietf-restconf yang model does not event=0A= > implement any container, only a grouping that could be used by other=0A= > models.=0A= =0A= Under the unified datastore (i.e. {+restconf}/data node), all top level=0A= nodes would be found=0A= =0A= {=0A= "ietf-restconf:data": {=0A= "ietf-yang-library:yang-library": {},=0A= "example-jukebox:system": {},=0A= "example-jukebox:jukebox": {},=0A= "ietf-restconf-monitoring:restconf-state": {}=0A= }=0A= =0A= Note that example-jukebox have two top level nodes.=0A= =0A= =0A= --=0A= Per= From nobody Thu May 7 04:15:14 2020 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 1211C3A005F for ; Thu, 7 May 2020 04:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 QCY0f3UBY3Jt for ; Thu, 7 May 2020 04:15:09 -0700 (PDT) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (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 122333A005C for ; Thu, 7 May 2020 04:15:08 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id f18so5820190lja.13 for ; Thu, 07 May 2020 04:15:08 -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=SFcpMZGK/J+y0amfqEAeYiQAcHH5RsO2//JVw2Dbv4Q=; b=kDZ/XQ/QFt7MT7r/HD4XoryfNpTXR2t+MilIEmSOoVHz3MQKJzS5zwH2DkBZMvtJ0A HaSNjfRqs1SpTfvEfyvO1C4j7TRxmbsNA60ebNDrXpG7QXi7rxksYdBsdY8BWG6RUP0T sxxnpn0J5SxiIZbO3sr9KxowDlGEum+YJ4qZvcbN/lcAKuvWd++jAeRF336N439UJiKH 7NELwhrlt5TDIhCzBets+00RXSgEVrp21TVloc2oXntlO790zzmmrdTnKZ5bVl1xUzmi gc5GkMLz39tzgZn/VCEaARRfxyw8ZcckHpp+n9oxHnmMNAXi5DKvduzdMxLJmTQYO9D3 d5tA== 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=SFcpMZGK/J+y0amfqEAeYiQAcHH5RsO2//JVw2Dbv4Q=; b=fVLiPBrXAYzOvhdMWR1d/B8cxmSbx3Q/zgWnKptfD+p5RkZkKq7X5NU92sTTNfec9g UlidhfmqEPRMdbPNCUGJtHKRcds9AUCMKae2ARtyHE4a0+1Ph0ihbk3TZMEA5qyv5j0j HknhVb4rWjWmIirjYmH/af/BvP/ikD1JU+ezZ0gg9jplHk6nbhISSzezrJsS9UJFthnn N+6KP1pZnmzAclALgCFwQgTEyXllVSlaoY2GPWK95B5rZt6or81aRBT2X+lBkXgE10e3 dUMlzKG5W4SrjAUTT1sgBrwxexfPK9zjNyD4NApLp3K/hDYdPojPB95In8UrmYwlkTcT mRAA== X-Gm-Message-State: AGi0PuZa7pp8130nuFc0TOh8GdSM/2RoROlQa6WAaRHBQFJhwUmJU06R DjJy3If70uyl7d2meoDxFhxAdoeFgOTGHwadEJg= X-Google-Smtp-Source: APiQypJDCMsHVgJmHxpJ2LXZlWrQ6zmxq6sF44kVVizRGmDYmAFkTbfKvqH4iWJx9xB4lZdYJnqZ9EMHB/TD9a08QtQ= X-Received: by 2002:a2e:8693:: with SMTP id l19mr7922408lji.63.1588850106763; Thu, 07 May 2020 04:15:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Henning Rogge Date: Thu, 7 May 2020 13:14:40 +0200 Message-ID: To: "Per Andersson (perander)" Cc: "netconf@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [netconf] Question about RFC8040 data root node and depth example 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, 07 May 2020 11:15:11 -0000 On Thu, May 7, 2020 at 11:46 AM Per Andersson (perander) wrote: > I would say this is an error in RFC 8040, there is no note about it > in the Errata. [0] ok. > > The second is about GET queries directly to the /data node, as it is > > done in example B.3.3. > > > > Is the server meant to "join" both the ietf-restconf, > > ietf-yang-library and the "user" datamodel into a larger one? This is > > interesting because the ietf-restconf yang model does not event > > implement any container, only a grouping that could be used by other > > models. > > Under the unified datastore (i.e. {+restconf}/data node), all top level > nodes would be found **sigh** I was worried to get this answer. My current implementation of the "yang data model" does load one library file... not a hierarchical series of libraries... This makes iterating over the "unified" datastore 'interesting', especially because of the depth/fields query parameter. > { > "ietf-restconf:data": { > "ietf-yang-library:yang-library": {}, > "example-jukebox:system": {}, > "example-jukebox:jukebox": {}, > "ietf-restconf-monitoring:restconf-state": {} > } In theory It should be possible to define the "data" YANG model and then import/augment everything from there, right? > Note that example-jukebox have two top level nodes. I assume this is just your example, not the "example-jukebox" in the RFC 8040, right? Henning From nobody Thu May 7 05:30:46 2020 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 609083A00E2 for ; Thu, 7 May 2020 05:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=XR0R9TwG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=urBxpY2O 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 kQQsOO0C-hYY for ; Thu, 7 May 2020 05:30:41 -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 A13733A00E0 for ; Thu, 7 May 2020 05:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2636; q=dns/txt; s=iport; t=1588854641; x=1590064241; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EHtLt2tUf8akn3rHfRuWzD4Amf9+cynXCJ3oKFOJaY4=; b=XR0R9TwGSLEOdFMUb411i24Hn3OuOCvNNBSAMB4RJKKKDkIqiNEI84vX ZPHgYAQ9cWp4GLYsh8rU4GQK5ZPyuSLLHwelLOhG6Jx6jHfQ5D9nEJEcQ Bc5qh30gGZ0A6ePZqIQVdHRHRE1CY5oFmt7yco/f+QbtRkF4tQEE0OKSe E=; IronPort-PHdr: =?us-ascii?q?9a23=3ADvRXNB+Mlr+oP/9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZRCN6vBkjVuPVoLeuLpIiOvT5qbnX2FIoZOMq2sLf5EEUR?= =?us-ascii?q?gZwd4XkAotDI/gawX7IffmYjZ8EJFEU1lorH6+OElRXs35Yg6arni79zVHHB?= =?us-ascii?q?L5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5LQ69qkPascxFjA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKCQBV/rNe/51dJa1mH2qDG1EFgUY?= =?us-ascii?q?vKgqHXwONQIl5jjyCUgNUCwEBAQwBAS0CBAEBhEQCggckOBMCAwEBCwEBBQE?= =?us-ascii?q?BAQIBBQRthVYMhXIBAQECARIuAQE3AQQLAgEIDjghESUCBA4FCBqFUAMOIAG?= =?us-ascii?q?lTAKBOYhhdIE0gwABAQWFKg0Lgg4JgTiCY4lhGoFBP4FUgh8uPoEEgRqCGBg?= =?us-ascii?q?Cg0OCLZkNmH5KCoJIk0yEZ50gHZwUkQICBAIEBQIOAQEFgWkigVZwFYMkUBg?= =?us-ascii?q?NlDSKVnQ3AgYIAQEDCXyQOgGBDwEB?= X-IronPort-AV: E=Sophos;i="5.73,363,1583193600"; d="scan'208";a="509169487" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 May 2020 12:30:39 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 047CUcZt025528 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 May 2020 12:30:39 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 7 May 2020 07:30:38 -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.1497.2; Thu, 7 May 2020 07:30:38 -0500 Received: from NAM12-MW2-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.1497.2 via Frontend Transport; Thu, 7 May 2020 07:30:37 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d8X5L5cTxPwVXGWAilzJE0qiYqZWK3qRGOBgq3IOLmQTqIx0BDm0rICqN1jALkm+7pXczbgYAd9fIZFMSkdoIdRoFfDo6/sl/mVVzBlKZNHozv1Wd9hBLNsn1NQsxUS/Oe3fgN8uZFcE0O/GWzIUsXC9GIntJOqyspnE828aDNx48j+RH8TxtdkHSNyuQWq/6XWUlDJX1duKu6Gl/zXI98JU9Na/HH0y07rqLzZVfW1QLHELfUzr6t6x5o1FgLx+GVtntL02MXK1waWpTw59PJl6hYBT8+TcKeOHKVV5+WFwHAiLS2hHt/cChz8D90BlUGMAa99nq4NG+kGMyH9vqQ== 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=eXG672Rddleg2mWmoGYxHbQzmHXXI00qKE0nmn2qZbk=; b=KOPh3Ryz22WZ4hTEkkNoqkxq9vk2Yll9mayKNyQXDzXPJGtUtb+3W4u2pasmU4gqC0Rs+USbEoOzPKej2Ht/XhvNpfihp6p/55Q9UITsM1jUPxhPPHi8mSynFGhu//vF3Zog6oTP+WrBOnPT7SMiTsoFxkuORbDQNxKB0rtrjleXfkcP15/4Q3pagsUETw0cZPEUFENXD5vjzLJtefd7v55a6DeKIvEkdklZl6zgvIKaeOHiq3jcnhtwtmUbp/2mO8KiVYPsMyXc9/tGPf9r1iYllMtaFVR56cQsdHrOGjXJplE/+IlkrkDhnYc6anCSPqBtI5ziOr0J69yrCOp6FA== 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=eXG672Rddleg2mWmoGYxHbQzmHXXI00qKE0nmn2qZbk=; b=urBxpY2OeSnIHj9waW168Bqno0swEF6dPPtirkDKY6I1M9kikX059tAxVftVdELJY+gfziM9YbLnfNsAGtCc7XdGQMW6bHyxx+J8GMUh0zbzYMoJKUQv6X+orajGZQ2xI0379wqA3L4IFRt90IIRqYw86kXa6RzzVLt2IeA8Pus= Received: from DM6PR11MB3818.namprd11.prod.outlook.com (2603:10b6:5:145::22) by DM6PR11MB2874.namprd11.prod.outlook.com (2603:10b6:5:c9::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.28; Thu, 7 May 2020 12:30:36 +0000 Received: from DM6PR11MB3818.namprd11.prod.outlook.com ([fe80::597c:ff4:6845:c945]) by DM6PR11MB3818.namprd11.prod.outlook.com ([fe80::597c:ff4:6845:c945%3]) with mapi id 15.20.2979.028; Thu, 7 May 2020 12:30:36 +0000 From: "Per Andersson (perander)" To: Henning Rogge CC: "netconf@ietf.org" Thread-Topic: [netconf] Question about RFC8040 data root node and depth example Thread-Index: AQHWJD+yoUO+XWZSK0KzI7OByDeRIaicW8t6gAAdHACAABAUqA== Date: Thu, 7 May 2020 12:30:36 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.220.61] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a6c22029-7092-4b23-9427-08d7f28271f1 x-ms-traffictypediagnostic: DM6PR11MB2874: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03965EFC76 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cuTEW8nhVT7ij5BMj8p1Xk7WBy5Qdh1yLuzAfGHE2SbyDBm5hzaZiQ9WTNnJgQGd9NKeWtoXeIjlH2G7ruo+h8V6rzv8kTCu20u59pbVM9kgKt3g4rkYEqM/JizdadD/DDdoEEELwlHlxmj3otgEjAIjOVv2VTHyeIf+q1qO3yM2SAolyRvgY1rF5lWkuQjspPenJynwuRTHm7F8EaMc099w/dhVRM+oI2e6M9OcAarkc9qwnENu2hWwsTQuSC1QBA1XbGxfBxoqXB56+JgcbxQj0oKTAh2AYDLL+saFeXe4sHoZjNyi+/6BFj45DAxYXrSi0ddp1BC7ZcfSQvX7fRoKnl7ASzNDr3hY9J+5DuScQfor8YwA0iHzeMIlH3c0Xu8eb+pWmXGRXsWU9kvWuz5eGPnCh5WJaoTydf55nOUXp69OxIOHU2RmKHiRnulWAPVw7aT8dmdIU3/Wv0SKkXVr0Z8OitBhPfK1o8sE2mV7tV0iRhi+5Gimgc9NHJlwYMZQvnhsI0HBg+SyoRNJrw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3818.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(396003)(136003)(39860400002)(376002)(346002)(33430700001)(33440700001)(4326008)(9686003)(55016002)(478600001)(5660300002)(8936002)(83300400001)(2906002)(76116006)(83280400001)(83320400001)(83290400001)(83310400001)(316002)(91956017)(66446008)(66946007)(66556008)(64756008)(66476007)(6916009)(7696005)(8676002)(26005)(6506007)(86362001)(52536014)(71200400001)(33656002)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: r0gVrLKgGCIGKfEIZwRuTc0H+ObTsxm8gk74U5qvQP7PKm/y1qNuzVQOIRrX3KkJOZk9Rx26dn+0mTKau+vvXfX+REpqqIucNbn1Ja9/DgZ3orh3sL14HNtlLZ73FOUuqc4p0jayoh74k+5Co8sKTCnqkuQs4YkTGTYLUTforNYLmVyS82pKLo9RAGPyyp5MRc7hMFkLAOXZpBs2RcpJo1qIO5hfw+sIOjyofp5WMk4L4ZnNBuVFIUzPbcefid3hg5OY+06lHZIBP3mX/th/lXXfCGVRKxGA52Iaqib+NYS0ee/aOOWX7PbmSwvh81dHZ5teHx5aFeBo9sUekZnxDiwx5cHBrfT9ZMNOmWNREzr++xLxzY//VXNKx0GSqw+N/Gh0LB3i2mR8NcVZp/EcEMhwApq2c7gIRJAPyFfbRnZLDtkLfUrE5t8o35vPXmOZMaM6Acp+pSHB3xi2Nql/FZoGy0rvfuMS1wP2//7a3FzJC3CExJK5dUdQ99BITg5UAdZj8NHm3VXcwLNMmueztT4jtFjA0mV4u/IMk49PurrUCwH7F5o1F9Vcmch49ea+oWydH5IZTGQyrwjYTdp0jvxhsZFYwMkDECEWel9U3NrtIOy45t/+bsQC7SUoxPRn/0crfS3MM+feuT9PxV4XFmXkiU0qnM+kX3qorwScJq0nvHExFRBjTCb67xUgphlY8LJy6jnI8zQHuT+EjBrNTPwCxiDHZ8/2QhoK4sdT6PTAohxto0rZl0GMGOXTtXvqdAaw4XHYC8M41P4PsAYfIqYkiveJ0gMVCh/3njqk1h8= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a6c22029-7092-4b23-9427-08d7f28271f1 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2020 12:30:36.5023 (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: cJBZyNKg0wFZxsAdkb59RoP40tsn7mAvHQR3bZA0vLn7lr2id/KUo/JCOnvg0bQM1eudiph2+sZjq+SBeMoWcQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2874 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [netconf] Question about RFC8040 data root node and depth example 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, 07 May 2020 12:30:44 -0000 > Henning Rogge on Thursday, May 7, 2020 13:14=0A= >=0A= >> Under the unified datastore (i.e. {+restconf}/data node), all top level= =0A= >> nodes would be found=0A= >=0A= > **sigh** I was worried to get this answer. My current implementation=0A= > of the "yang data model" does load one library file... not a=0A= > hierarchical series of libraries...=0A= >=0A= > This makes iterating over the "unified" datastore 'interesting',=0A= > especially because of the depth/fields query parameter.=0A= >=0A= >> {=0A= >> "ietf-restconf:data": {=0A= >> "ietf-yang-library:yang-library": {},=0A= >> "example-jukebox:system": {},=0A= >> "example-jukebox:jukebox": {},=0A= >> "ietf-restconf-monitoring:restconf-state": {}=0A= >> }=0A= >=0A= > In theory It should be possible to define the "data" YANG model and=0A= > then import/augment everything from there, right?=0A= =0A= The datastore resource "data" is not a model per say but a container=0A= which should be populated with loaded models' top nodes.=0A= =0A= Fom ietf-restconf.yang:=0A= =0A= container data { = =0A= description = =0A= "Container representing the datastore resource. = =0A= Represents the conceptual root of all state data = =0A= and configuration data supported by the server. = =0A= The child nodes of this container can be any data = =0A= resources that are defined as top-level data nodes = =0A= from the YANG modules advertised by the server in = =0A= the 'ietf-yang-library' module."; = =0A= }=0A= =0A= See also RFC 8040 Section 3.4. Datastore Resource.=0A= =0A= =0A= >> Note that example-jukebox have two top level nodes.=0A= >=0A= > I assume this is just your example, not the "example-jukebox" in the=0A= > RFC 8040, right?=0A= =0A= Yes, the example-jukebox.yang I referenced is probably from an earlier=0A= RFC 8040 draft. But the principle is the same.=0A= =0A= =0A= --=0A= Per= From nobody Thu May 7 05:41:32 2020 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 4C1F83A0404 for ; Thu, 7 May 2020 05:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 DAncGu7GXye4 for ; Thu, 7 May 2020 05:41:29 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 BF1F13A0400 for ; Thu, 7 May 2020 05:41:28 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id a4so4334751lfh.12 for ; Thu, 07 May 2020 05:41:28 -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=7aDjqBrdE34WOHMREuKOriWY+bS6Ai40pHawETjfb0A=; b=plowirqGy+77y+0Kg4BKh3IptXgxiySwYF7BMrRasEBoaLXBhMtGGp8GXG2ePdYH0t vwYPajrZOEsQpccCqz8budEwTG90ebI7alfdL3pBVhIYVwLmsW/Dhp31ARXGBr5CNSuT ajcbsjhS4BD1lui6IT1c9VsLX1Ejf4BUoVQc44WSIWt0BmNmlkWjaiNt7FKN1gVxqiSR n07Ue1e3f5ZmUBuus8AGofP45KHZobkzqVAtSnSxr+/Iw3PIzkmNEdvML3qimk+osPyI BYNC+aAwIW3vjqOBJ55waqd4xvNNDDtw5ja9wo4DRSaACaueifLvaeeb3vCvmcXVtnmH +uTw== 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=7aDjqBrdE34WOHMREuKOriWY+bS6Ai40pHawETjfb0A=; b=FYZws8L9jmzTN4zUo8YGQVg2iJjW9LP/xPH29fyAK/9p7G5zDZty4w+DDLj4hKi2cm YwfHwZ1Xkn3d9A/J/P5ObQn4HRU9LY4MnTeOZwgzgFNh0AtuxK1tZg4H7USLad6CPguK CtsCzJUjLzFTfJq21LE8h/xl9oBTIR4AgYrjGm/+m1zPigqJxXD71mFx93BgTPHb49wb 4Tcc6LFelUvWW6TRshsO8MdJEyOOptO5r6UZpkrWt/gF4XXFpxDhfH3R1twHl9eSeO7K tJDJUWG+1eRyomPqV7EY/NKPOtx010W6cORnzFvoOxgbSGiVVRgMHz/Gg+TnZoeR1diL KenA== X-Gm-Message-State: AGi0Puau33/OEaCQXgGXJ3++hhYKoB8Ze9QqUqOkct1J9YpILL2AyF58 Jj3vEc73lBmznmcSH9VNcNT7R31AXX2PN/6G3I0= X-Google-Smtp-Source: APiQypL504YjA7oBIQjNlzZoozEXzlrtUAJgGQnueQN5sGsc4YoTJkfJneRM8wyrBemj9DCEbHUDS7A+AJ8Gtgqlrd4= X-Received: by 2002:a19:cc92:: with SMTP id c140mr8702300lfg.34.1588855286893; Thu, 07 May 2020 05:41:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Henning Rogge Date: Thu, 7 May 2020 14:41:00 +0200 Message-ID: To: "Per Andersson (perander)" Cc: "netconf@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [netconf] Question about RFC8040 data root node and depth example 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, 07 May 2020 12:41:31 -0000 On Thu, May 7, 2020 at 2:30 PM Per Andersson (perander) wrote: > > In theory It should be possible to define the "data" YANG model and > > then import/augment everything from there, right? > > The datastore resource "data" is not a model per say but a container > which should be populated with loaded models' top nodes. Yes, but because of query modifiers like depth/fields it is necessary to have a common filtering system that starts at the base datastore resource. A GET query easily can contain data from multiple models. It is more of an implementation problem, nothing wrong with the specification. At the moment my code just use different hooks in the REST server to deal with each Yang model (modules-state, restconf-state, userdata, ect.). Henning From nobody Thu May 7 10:29:18 2020 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 607833A0AA0 for ; Thu, 7 May 2020 10:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=SunYmFz3; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=PRYyINj4 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 dCp35Emj2JqS for ; Thu, 7 May 2020 10:29:14 -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 BDC3E3A00D9 for ; Thu, 7 May 2020 10:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31494; q=dns/txt; s=iport; t=1588872553; x=1590082153; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AEJ5fd85Hpq5Gr1R76//ncVshho7ecGitW+j5u5zFeM=; b=SunYmFz3jpAKLkr4mzWAhxHLMCwcOttC/Ol3rBdHEhLO4vh90JisHNOy H8Qtf9ULD+cK0cCgbcvycY4IJZD0BDvQG4BOuqXOQN6ssquYTcUoJJuXM C9kTBN0m/7xn6Y6I/HJxqa8MJh2f7tTH8KgiHF+e+9ZKSNGf8rQMEooz+ o=; X-Files: smime.p7s : 3975 IronPort-PHdr: =?us-ascii?q?9a23=3AFkTLKBT5Ce76ayra/jDbXCL8ANpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBNuJ9PtYkOfQ9abtRT9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7Nq2Gp4DhUHB?= =?us-ascii?q?jjZkJ5I+3vEdvUiMK6n+m555zUZVBOgzywKbN/JRm7t0PfrM4T1IBjMa02jB?= =?us-ascii?q?DOpyhF?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CDAACdRLRe/4wNJK1cChwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBgXQGAQELAYEkL1EFbistLyoKhBmDRgONQYl5jjyBLhSBEAN?= =?us-ascii?q?UBAcBAQEJAwEBGAEKCgIEAQGDf0UCggckNQgOAgMBAQsBAQUBAQECAQUEbYV?= =?us-ascii?q?WDIVxAQEBAQMBARAGCwoTAQEsCwEPAgEIEQQBAQ4TBwMCAgIfBgsUCQgCBA4?= =?us-ascii?q?FCAYUgwWBfk0DHw8BDqU3AoE5iGF2gTKDAAEBBYEyAQMCg3MNC4IHBwMGgTg?= =?us-ascii?q?BgVKBEIlhGoFBP4ERQ4IfLj6CHkkBAQIBgS0BBwsBCRorCYJcM4ItjjAOgwu?= =?us-ascii?q?gQkoKgkiEFIJLgTmLNIRngluIYZFkjxwMgkeHfIJGkQICBAIEBQIOAQEFgVM?= =?us-ascii?q?BN2ZwcBU7gmlQGA2QQoNyhRSFQnQCNQIGAQcBAQMJfJA6AYEPAQE?= X-IronPort-AV: E=Sophos;i="5.73,364,1583193600"; d="p7s'?scan'208,217";a="474931178" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 May 2020 17:29:12 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 047HTChO032761 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 May 2020 17:29:12 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 7 May 2020 12:29:12 -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.1497.2; Thu, 7 May 2020 12:29:11 -0500 Received: from NAM10-DM6-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.1497.2 via Frontend Transport; Thu, 7 May 2020 12:29:11 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DNITYA8Gw06M3/Yqd/qH1Sx0tZAH4O2y0BJpZvqNWjB0mOpggT6olyLDWLE4wxEO25v/FUNXypEZjqZcnUnGFTy+RcYxZMswQxg7gx9E8POiGsisHs4PZwpQ0Z8yVLQfGTR098nQuHLnqi7onAGxHSOyShAHpvZfkpSn4yskkfmrcvpItx7HqgaEOa52TYF6QTM4OVEmZZq6CU/7tmB5dhaCoJeRY98lmmI8IzUcYHX/GzU1alxR0yqGascXZqURl7kCX3o7SowbnytJkHoKUr2VJI/59dViC3ewSU5rToh23nRswDYwoBfFR6zvyBsPQ84+RVODhGU7H5G6Kd407A== 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=YUL73ZA1my7jPr4wVlqgnhXBo4UNeUo1ORAt0xfssAY=; b=NqYgHkt7IOQZP9r8VqwThEBS1EnWSEbtGBmc98n4pzcH6xP3DZ/d85if1A7IrnrC7Rd40M8oq0XWKZFaTQE5SeMmpQesVbdy5xCSUHYldXhg0euyRptqmvJwu4xxHyvwvzGBiJEL2sQeVHdzBnUccaoG77kAliTVZuruVauaIGmTtxL2m5ylyHp10PaKlFnpVMbfsBONYRQVfT+erJrDikZtbDbqjQ0EOZkNzbLIT8cpUgZgXNzxJjSSk0vGiq9gZpljLC+Dj+mv1JNwKTFg0I7raKYuIgljKuJM3lxnLmROajDW16wB4/lQfkaMmprWRiZRaYQHLYZDrUwhCpF0fA== 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=YUL73ZA1my7jPr4wVlqgnhXBo4UNeUo1ORAt0xfssAY=; b=PRYyINj4bXPpQTWj9YnLxqIcY+PrdSE9zLiyUxEXKgP3bLvtVgry2nBwfqEkkIjTBk6d/LPHfB0VfQn8aK9bQwA0dPEUOtltIATqp+22lK53DE+OeqfAC4ocdzz7QdwEON1ChCmx8Fbqj1LRwrs5POLJ4VJjGLNse8IgaKyB3SA= Received: from BL0PR11MB3122.namprd11.prod.outlook.com (2603:10b6:208:75::32) by BL0PR11MB2945.namprd11.prod.outlook.com (2603:10b6:208:32::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.19; Thu, 7 May 2020 17:29:10 +0000 Received: from BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::20ac:d8b4:4a4f:4290]) by BL0PR11MB3122.namprd11.prod.outlook.com ([fe80::20ac:d8b4:4a4f:4290%7]) with mapi id 15.20.2958.034; Thu, 7 May 2020 17:29:10 +0000 From: "Eric Voit (evoit)" To: Kent Watsen CC: "netconf@ietf.org" Thread-Topic: [netconf] Virtual hum for the question on "https-notif" draft Thread-Index: AQHWI0hpYHZAcDWdCEuo9DDiKKJ84Kic4tbg Date: Thu, 7 May 2020 17:29:10 +0000 Message-ID: References: <5CE2095E-7117-4092-B356-A5C4FF490D10@gmail.com> <01000171bc405640-6e173d84-f921-4f6f-929a-6431410051c8-000000@email.amazonses.com> <01000171e7ab5453-7199ade0-ec62-4f6c-837e-5132fb5a4e78-000000@email.amazonses.com> In-Reply-To: <01000171e7ab5453-7199ade0-ec62-4f6c-837e-5132fb5a4e78-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.87] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6a61a440-2cc6-4f88-e26f-08d7f2ac2771 x-ms-traffictypediagnostic: BL0PR11MB2945: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 03965EFC76 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qgvw8yJIv15KmwRYg0psLpAChecoYK9t8q2zLXg3tMFj/hi3EeLqRJ9sCjTxyybic0p1b8GdP9yuOnsPBWTPq9aJ4JB7mApUfHqpk/MaovZJ0xzlB3wAUrQFCBcJ2NMS//Ap+IUqfdimkfkA+caqZlnCPNTYZT18gtJRVPwx0yRO5a1GmUP4xDlzfQZaZVAAedT2QivsTXwEdh5Uq+vjGvn7++pV5l+DGc1lg5T7VuFxo6a5bPfWbfEa9YjCFHMEPkuwaiYSJVS996/B7lwh4Vh1pzvy6eyhMQxZjgTIrXBHEMwJrXsWX4jDlA3mZpy1kf3cfjBFBeppGvd9er3G9DTBTCiB414kcuiLGb1A+EsYQxkx8yzrGmXyakmLiShuwKiygx++PUiM99NZ0gZa6wqPacduz5MXwDP5MHYMJOx+u4AE3Tnc8xcT6jVtke0OIJjyf8/YA4mAx1oE/ggs9Bsxz8aThNPHuCdGuPMr5odLQuzTGAucica0YpU5fIoRMifQb9qKxez1WCMQkm/rcTDHxVkHdc2KjL+NucztqNHLhDZ4IXYLYmU02bGZ8vgfXGdHP8kbNN1Ax7lstD/wvNRq8OmGl7SOnOPzV7yr82g= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3122.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(346002)(376002)(396003)(136003)(33430700001)(316002)(33440700001)(966005)(8936002)(83310400001)(33656002)(83300400001)(83290400001)(478600001)(4326008)(83320400001)(83280400001)(7696005)(55016002)(9686003)(52536014)(71200400001)(8676002)(86362001)(99936003)(76116006)(66616009)(64756008)(66556008)(66946007)(186003)(2906002)(66476007)(53546011)(166002)(6506007)(26005)(66446008)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: +X35+zX4a2c7McFi2jHXaSifIo2HuLTcz7qz27CjrmCb3xTESCjtsQmXX2ec9whJaP/KB9Szs6/apKv/wV1oZ8TJr7CuptzcePwVca/p3Vgc5+dX4tiOieW/W4dstprdo4yx7yGvAkTcUt32ViyFfw4m+WldafKb34tPusIUEtmoUpJwE7SJFi8KO4dpMuMiTHvhGSscSw6BIu4UcbjpW+WUgyC9y+vbQeJ99TPzW9c452wWx9JdRRakNabaUOxBXqCo2z3li2SLa1HDGyo8rKtGH+X7yLeOkVQ+Jpu4RJCn3FrLmwPrv+wUGktMCKM2EpleSpgRIzZKx31JAS3ekdM/8NmSczDTroQlf5g4+GP88kv4vmaWEaDh5Oo80RoJxS9yxCVDZ1CsmH0UcGsyPLFuW48WQiB2Eejh7SgNCKCIwFhd1M8Je84xMlKcW5vPx7INJsqqmihAYADPEHtsNh15N9wAJ3DekmyiN3+RfxwJPX6DNx1OIphc0tYXHMBn8DFzxRdsPKJxDilDMh8YjddP1M9BY1Agu0K0ZPDJRX1rMxWYQSJ0LyRBWePz55rWvfiaqzyfrvoPW7prMevabQXwrmn3FkLJ7P1/q6ezIDWCFNJXAFxEKTFp/0eqggudhabwGBcdSZ2D9KjZqTYVROYtpefdezrVMGPfGW8982+S48wIktotypI9hHekdkzJvF78pWWq6BDDOCnglJWVNX38q8oAQQpHwys1ktHi6buGeh12bLL1nQ3E5j+oFBpVTKdZi/QCPSE9rPGec1hINBgZIeM9gWSA16r62QEtTbE= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0299_01D62473.79CB3D90" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6a61a440-2cc6-4f88-e26f-08d7f2ac2771 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2020 17:29:10.4527 (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: ggybGtNBUB2dCpgnzkKu+3v8ZGtq+vTosHsjE5USMX5ad2dXrZmF3z0m6kNMbVdM X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB2945 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [netconf] Virtual hum for the question on "https-notif" 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: Thu, 07 May 2020 17:29:17 -0000 ------=_NextPart_000_0299_01D62473.79CB3D90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_029A_01D62473.79CB3D90" ------=_NextPart_001_029A_01D62473.79CB3D90 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Kent Watsen, May 5, 2020 9:48 PM This email closes the virtual hum on the for the question on the = "https-notif=E2=80=9D draft. =20 As reported before, 70% picked "Let the market decide=E2=80=9D, with the = remaining 30% all picking "Publisher MUST implement JSON = encoding=E2=80=9D. =20 Rob raises a good point about the language in RFC 8639, but the results = of the poll reveal a contradiction. How can we =E2=80=9Clet the market = decide=E2=80=9D if a default MUST be picked? =20 The chairs are questioning how vetted that text in RFC 8639 is, noting = that RESTCONF also doesn=E2=80=99t pick a default. We wonder if the = text in RFC 8639 should be softened. For instance: =20 OLD: A specification for a transport MUST identify any encodings that are supported. If a configured subscription's transport allows different encodings, the specification MUST identify the default encoding. NEW: A specification for a transport MUST identify any encodings that are supported. If a configured subscription's transport allows different encodings, the specification MUST identify the default encoding, or provide a mechanism whereby supported encodings can be discovered. =20 At least, it seems that the intent of the draft is to handle the case = for when the =E2=80=9Cencoding=E2=80=9D leaf is not configured (since = it=E2=80=99s =E2=80=9Cmandatory false=E2=80=9D), more so than force = interoperability, but there are other ways to determine an encoding in = such circumstances, and thus maybe the text is overly proscriptive? =20 I have no problem with the proposed text. =20 Eric =20 =20 =20 The NETCONF Chairs =20 =20 =20 On Apr 27, 2020, at 11:48 AM, Rob Wilton (rwilton) > wrote: =20 At least the hum seems to have narrowed it down to two choices (assuming = sufficient voices). =20 But I can see interop benefit in defining at least one encoding that = clients know will be supported by the server. =20 Hence, I wonder if anyone wouldn=E2=80=99t be able to live with: =20 =E2=80=9CThe default encoding is JSON. Publishers MUST support JSON = encoding=E2=80=9D =20 * or a slight variant (that I don=E2=80=99t like so much) would be to = soften the MUST to a SHOULD, with the expectation that servers that = don=E2=80=99t support JSON would reject the configuration unless the = clients had specified an alternative supported encoding. =20 Rob [As a contributor] =20 =20 From: Kent Watsen >=20 Sent: 27 April 2020 16:28 To: Rob Wilton (rwilton) > Cc: Mahesh Jethanandani >; netconf@ietf.org = =20 Subject: Re: [netconf] Virtual hum for the question on "https-notif" = draft =20 =20 On Apr 27, 2020, at 8:08 AM, Rob Wilton (rwilton) = > wrote: =20 [As an individual contributor] =20 Changing my stance somewhat from the NETCONF meeting =E2=80=A6 =20 After looking into the details a bit more, section 7 of rfc8639 states: =20 A specification for a transport MUST identify any encodings that are supported. If a configured subscription's transport allows different encodings, the specification MUST identify the default encoding. =20 Does this imply that the http-notif draft either must state a default = encoding (or otherwise update rfc8639)? =20 It seems that way...at least when https-notif is being used for RFC 8639 = (it doesn=E2=80=99t have to be). =20 Looking at the hum-results so far, 70% picked "Let the market = decide=E2=80=9D (with the remaining 30% all picking "Publisher MUST = implement JSON encoding=E2=80=9D).=20 =20 In light of the RFC 8639 text quoted above, we might question the = validity of the hum=E2=80=A6or, given the strong preference from the = hum, we might question the validity of that constraint in RFC 8639. If = questioning RFC 8639, a better question to ask might be why the = configurable =E2=80=9Cencoding=E2=80=9D leaf isn=E2=80=99t mandatory = (also eliminating this issue and seemingly cleaner)? If so, my thinking is to make the default encoding JSON, because it is = easier to generate than XML, and easier to convert into CBOR. Clients = don=E2=80=99t have to support JSON if they know that the publisher = supports a different encoding that they do support. =20 If we had to pick one, JSON is more agreeable than XML. Picking JSON = would likely also be the kiss-of-death for XML, as once support for JSON = has been coded, it=E2=80=99s unlikely XML support would be coded (like = how XPath-filters are rarely implemented due to subtree-filters having = to implemented). Picking JSON would NOT be the kiss-of-death for CBOR = (or some other binary encoding) as *binary* offers real value in space = and time consumption. =20 =20 Kent // contributor =20 =20 I=E2=80=99ve also filled in the virtual hum. =20 Regards, Rob =20 =20 =20 From: netconf < = netconf-bounces@ietf.org> On Behalf Of Mahesh Jethanandani Sent: 21 April 2020 01:48 To: Netconf < netconf@ietf.org> Subject: [netconf] Virtual hum for the question on "https-notif" draft =20 At the 107 NETCONF virtual meeting, the authors posed the question of = mandatory encoding for = = draft-ietf-netconf-https-notif draft to the WG. This virtual hum in the = form of a survey is being presented to record the response from the WG.=20 =20 Please respond by selecting one of the options in the survey page. =20 = https://www.surveymonkey.com/r/68W3DX3 =20 The relevant slide that was used for discussion was this. In addition to = the options discussed here, Rob suggested that the WG could defer to the = market to decide. =20 Thanks =20 Mahesh & Kent (as co-chairs) _______________________________________________ netconf mailing list netconf@ietf.org = https://www.ietf.org/mailman/listinfo/netconf =20 =20 ------=_NextPart_001_029A_01D62473.79CB3D90 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Kent = Watsen, May 5, 2020 9:48 PM

This email = closes the virtual hum on the for the question on the = "https-notif=E2=80=9D draft.

 

As reported before, 70% picked "Let the market = decide=E2=80=9D, with the remaining 30% all picking "Publisher MUST = implement JSON encoding=E2=80=9D.

 

Rob raises a good point about the language in RFC = 8639, but the results of the poll reveal a contradiction.  How can = we =E2=80=9Clet the market decide=E2=80=9D if a default MUST be = picked?

 

The chairs are questioning how vetted that text in RFC = 8639 is, noting that RESTCONF also doesn=E2=80=99t pick a default. =  We wonder if the text in RFC 8639 should be softened.  For = instance:

 

  OLD:

   A specification for a transport MUST = identify any encodings that are

   supported.  If a configured = subscription's transport allows different

   encodings, the specification MUST = identify the default encoding.


  NEW:

   A specification for a transport MUST = identify any encodings that are

   supported.  If a configured = subscription's transport allows different

   encodings, the specification MUST = identify the default encoding, or

   provide a = mechanism whereby supported encodings can be = discovered.

 

At least, it seems that the intent of the draft is to = handle the case for when the =E2=80=9Cencoding=E2=80=9D leaf is not = configured (since it=E2=80=99s =E2=80=9Cmandatory false=E2=80=9D), more = so than force interoperability, but there are other ways to determine an = encoding in such circumstances, and thus maybe the text is overly = proscriptive?

 

<eric> I have no = problem with the proposed text.

 

Eric

 

 

 

The NETCONF Chairs

 

 

 



On Apr 27, 2020, at 11:48 AM, Rob Wilton (rwilton) = <rwilton@cisco.com> = wrote:

 

At least the hum seems to have = narrowed it down to two choices (assuming sufficient = voices).

 

But I can see interop benefit in defining at least one = encoding that clients know will be supported by the = server.

 

Hence, I wonder if anyone wouldn=E2=80=99t be able to live = with:

 

  =E2=80=9CThe default encoding is JSON.  = Publishers MUST support JSON encoding=E2=80=9D

 

* or a slight variant (that I = don=E2=80=99t like so much) would be to soften the MUST to a SHOULD, = with the expectation that servers that don=E2=80=99t support JSON would = reject the configuration unless the clients had specified an alternative = supported encoding.

 

Rob

[As a contributor]

 

 

From: Kent = Watsen <kent+ietf@watsen.net> =
Sent: 27 April 2020 16:28
To: Rob Wilton (rwilton) = <rwilton@cisco.com>
Cc:= Mahesh Jethanandani <mjethanandani@gmail.com>; = netconf@ietf.org
Subject: = Re: [netconf] Virtual hum for the question on "https-notif" = draft

 

 




On Apr 27, 2020, at 8:08 AM, Rob = Wilton (rwilton) <rwilton=3D40cisco.co= m@dmarc.ietf.org> wrote:

 

[As an individual = contributor]

 

Changing my stance somewhat from = the NETCONF meeting =E2=80=A6

 

After looking into the details a = bit more, section 7 of rfc8639 = states:

 

   A specification for a transport MUST = identify any encodings that are

   supported.  If a configured = subscription's transport allows different

   encodings, the specification MUST = identify the default encoding.

 

Does this imply that the http-notif = draft either must state a default encoding (or otherwise update = rfc8639)?

 

It seems that way...at least when = https-notif is being used for RFC 8639 (it doesn=E2=80=99t have to = be).

 

Looking at the hum-results so far, = 70% picked "Let the market decide=E2=80=9D (with the remaining 30% = all picking "Publisher MUST implement JSON = encoding=E2=80=9D). 

 

In light of the RFC 8639 text = quoted above, we might question the validity of the hum=E2=80=A6or, = given the strong preference from the hum, we might question the validity = of that constraint in RFC 8639.  If questioning RFC 8639, a better = question to ask might be why the configurable =E2=80=9Cencoding=E2=80=9D = leaf isn=E2=80=99t mandatory (also eliminating this issue and seemingly = cleaner)?


If so, my thinking is to make the = default encoding JSON, because it is easier to generate than XML, and = easier to convert into CBOR.  Clients don=E2=80=99t have to support = JSON if they know that the publisher supports a different encoding that = they do support.

 

If we had to pick one, JSON is more = agreeable than XML.  Picking JSON would likely also be the = kiss-of-death for XML, as once support for JSON has been coded, = it=E2=80=99s unlikely XML support would be coded (like how XPath-filters = are rarely implemented due to subtree-filters having to implemented). =  Picking JSON would NOT be the kiss-of-death for CBOR (or some = other binary encoding) as *binary* offers real value in space and time = consumption.

 

 

Kent // = contributor

 




 

I=E2=80=99ve also filled in the = virtual hum.

 

Regards,
Rob

 

 

 

From: netconf <netconf-bounces@ietf.org> On Behalf Of Mahesh = Jethanandani
Sent: 21 April 2020 = 01:48
To: Netconf <netconf@ietf.org>
Subject:=  [netconf] Virtual hum = for the question on "https-notif" draft

 


At the 107 NETCONF virtual = meeting, the authors posed the question of mandatory encoding = for draft-ietf-netconf-https-notif dra= ft to the WG. This virtual hum in the form of a survey is being = presented to record the response from the WG. 

 

Please respond by selecting one of = the options in the survey = page.

 

 

The relevant slide that was used = for discussion was this. In addition to the options discussed here, Rob = suggested that the WG could defer to the market to = decide.

 

Thanks

 

Mahesh & Kent (as = co-chairs)

___________= ____________________________________
netconf mailing = list
netconf@ietf.org
= https://www.ietf.org/mailman/listinfo/netconf

 

<= /div>

 

------=_NextPart_001_029A_01D62473.79CB3D90-- ------=_NextPart_000_0299_01D62473.79CB3D90 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 hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjAwNTA3MTcyOTAzWjAjBgkqhkiG 9w0BCQQxFgQUc+qItWoicCwtC0iTLTiz/TkHIbkwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQK EwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0ECCgGGHkPWlB0496IwSwYLKoZIhvcN AQkQAgsxPKA6MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIK AYYeQ9aUHTj3ojCBkwYJKoZIhvcNAQkPMYGFMIGCMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG9w0B AQEFAASCAQA/aEGAuWmrgpJvuJ1aAdn+zMN270FdhCDN6Pw0qJeks+pKJu30xIsjT4VfWMZLJEIc JZyhMF+xbHQIpBhkt3hU1NvPXNc2aOP2gIX9t0vKkMJnhKEUM1/Q6hXuPLuaC0+bIm8VNzoKTRD7 4hp3DJ4WhCE7ujerRZ4/GYbOXV86N+9XHbQe7EFuMCDoc1hToiug8Au+yS8meM9iVwwrpZ6v31+0 PBLCB1hDAysPFnIWm4hrq99qPzSHEPvn4jpZmqaY97r/v66bi9dXdc7ROc4o1kmyv4hy0AW97FDK 6OlDajKPFE2xWzt1Y6viElNTs5Qr39zr9YnqTJay1UKS0FyyAAAAAAAA ------=_NextPart_000_0299_01D62473.79CB3D90-- From nobody Thu May 7 13:33:44 2020 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 9ADEB3A0D6A for ; Thu, 7 May 2020 13:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 HozW2o78hgQT for ; Thu, 7 May 2020 13:33:40 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 8247E3A0AD3 for ; Thu, 7 May 2020 13:33:40 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id x2so3573768pfx.7 for ; Thu, 07 May 2020 13:33:40 -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=2Wj19ZnmOaCbKB/uMtHCvF5iWV2cNm17yaDA/CY2mFY=; b=t/+X1YsI32LHuZyuVMFSoF7nXb92Xf/CZ1At8WpYQ06YQGe1wRGBSTWnC0BdwnW5tE OrJfuiPiPJp8aRLRoxruvWXjAwTTxYqeMT+tT2/rmbrG0svVKR098Zteg5n/K+H7/Zhj vu4f3Q6COFGmcpuDGMU9hiuOT+6O+zVek/u+x0KfAQbLzYtp6iOv59l7kiI9esSCQz9z dHJphosdJdBBVkGYmulcCvPGZ1gND8WGmyhrXoXYj7BaHUvN/bdVzCv9m2IbZ+2DJVxA VA54sYAGK6lL9hINo4/cVdSsE/8FwaV7unQV+7i6ZIMK7RhKLc+YHsiPmpKbtYlmDUE7 iFGQ== 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=2Wj19ZnmOaCbKB/uMtHCvF5iWV2cNm17yaDA/CY2mFY=; b=eY3Sl1S2L74zHHB0cOyJOlyNg/3SB8TbBpiEL7BGEIhVpC9wcTAs+/Xfv25fMIbmOo n+uhWzC/GbHrtH37phOd2jzT3ld560SaRTG5RJbZtwJIWty+MbnLxl02Quc0ZE2EfuRh /VwTfnKOoUqh7iLHGZxcr7c/CiDinad4lTGsOgrZS7k5sqLiCV8+l0sHIJHyyV+gwhIW c8Ib5TJMQZItpXK4+QGl/pmhauBtvarnttFjAL3Q+mzW+DL10Hg71rHYJKoneAlqtofj P1kM7arDbGyqOYfdTJhrAzOWY2bPp894BT28pguO1uGZqGVwJuHxiLbfCScHClGYrsyY DXvA== X-Gm-Message-State: AGi0Pua2JR0fZndJC49Dwljcy4siRd0qyhc4Ps0s5/PIUeWQn64zUmVW SxFPXRrathgNS0UlZrt0s+4= X-Google-Smtp-Source: APiQypKPoJhJp49GxpRI6EXorjoiAmMkXZx7UBKnWXjB45INkEFjGqnGYzy43PTzohPpDQTs3i3QyQ== X-Received: by 2002:a62:7912:: with SMTP id u18mr14654003pfc.239.1588883619863; Thu, 07 May 2020 13:33:39 -0700 (PDT) Received: from ?IPv6:2601:647:5600:5020:a895:d5d1:9dfb:ae2a? ([2601:647:5600:5020:a895:d5d1:9dfb:ae2a]) by smtp.gmail.com with ESMTPSA id b73sm5773504pfb.52.2020.05.07.13.33.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 May 2020 13:33:38 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <9C6D0A8A-2BD4-4578-8CB3-6969078CE10A@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A7059CE0-1EAF-483A-B1BE-82066CB55531" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) Date: Thu, 7 May 2020 13:33:34 -0700 In-Reply-To: Cc: =?utf-8?Q?Martin_Bj=C3=B6rklund?= , netconf@ietf.org To: Henning Rogge References: <20200414.222236.518728457229433184.id@4668.se> X-Mailer: Apple Mail (2.3445.9.5) Archived-At: Subject: Re: [netconf] Trouble with RFC 8040 (Restconf) fields Query Parameter 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, 07 May 2020 20:33:43 -0000 --Apple-Mail=_A7059CE0-1EAF-483A-B1BE-82066CB55531 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Henning, > On Apr 20, 2020, at 3:44 AM, Henning Rogge wrote: >=20 > are there any set of test-cases the IETF used for interoperability = tests? While not IETF blessed, ODL ran into multiple issues with the fields = query parameter, and documented in this = Jira report. = Documented in there are some of the test cases that might interest you = to run. There were other test cases run in this = and this = report also that = should be of interest. Cheers. Mahesh Jethanandani (as contributor) mjethanandani@gmail.com --Apple-Mail=_A7059CE0-1EAF-483A-B1BE-82066CB55531 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Henning,

On Apr 20, 2020, at 3:44 AM, Henning Rogge = <hrogge@gmail.com> wrote:

are there any set of test-cases = the IETF used for interoperability tests?

While not IETF blessed, ODL ran into multiple = issues with the fields query parameter, and documented in this Jira report. Documented in there are some of = the test cases that might interest you to run. There were other test = cases run in this and this report also that should be of = interest.

Cheers.

Mahesh Jethanandani (as contributor)



= --Apple-Mail=_A7059CE0-1EAF-483A-B1BE-82066CB55531-- From nobody Thu May 7 13:58:54 2020 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 2B83B3A0B25 for ; Thu, 7 May 2020 13:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=DL3XW5sC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=e+u6n33S 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 gO0QFQ7dotU5 for ; Thu, 7 May 2020 13:58:51 -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 0AC2B3A0A69 for ; Thu, 7 May 2020 13:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2780; q=dns/txt; s=iport; t=1588885131; x=1590094731; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=rYfOyG7VwQvVDdmS9Xhp6V7pkp5btYH+GI0GKVkNYBQ=; b=DL3XW5sC/wjG65yixnXLiT9r+ITyPuStSVBH0A5iqbR5jxRauz7DC6uG Jnxsdt6WFRmTohENavVDkf0oyUbEHGT4LNEGdO68I0k6+OrUHdnNEt1xS blNDgwt/ew6PIIzga+DqGgsYXdyAt50trlm4OuWonCRul5/hVherSNUJI g=; IronPort-PHdr: =?us-ascii?q?9a23=3AI7TsbhDgs/WRsaZAdZdMUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw01g3IUJnVrfVehLmev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtUFdrwIVrIrS764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D?= =?us-ascii?q?=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CVCwBldrRe/40NJK1mHgEBCxIMQIE?= =?us-ascii?q?8C4FUUQVvWC8rCoQag0YDizGaSIEugSQDVAsBAQEMAQEjCgIEAQGEXYFwJDQ?= =?us-ascii?q?JDgIDAQELAQEFAQEBAgEFBG2FVgELhgoREQwBATgRASICJgIEMBUSBDWDBAG?= =?us-ascii?q?CSwMuAQMLpScCgTmIYXaBMoMAAQEFgkmCYxiCDgMGgQ4qgmOCSQ6HChqBQT+?= =?us-ascii?q?BOByDC4EEgWMBAQIBgUqDKjOCLY5KBIJ9hkKKSZANCoJJBIcfdZAKHZ00ix+?= =?us-ascii?q?EfYlXk1ECBAIEBQIOAQEFgVI5gVZwFWUBgj5QGA2QQhiDWoUUhUJ0AjUCBgE?= =?us-ascii?q?HAQEDCXyQDQGBDwEB?= X-IronPort-AV: E=Sophos;i="5.73,365,1583193600"; d="scan'208";a="491342356" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 May 2020 20:58:42 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 047Kwghu007922 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 7 May 2020 20:58:42 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 7 May 2020 15:58:42 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 7 May 2020 15:58:41 -0500 Received: from NAM10-MW2-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.1497.2 via Frontend Transport; Thu, 7 May 2020 15:58:41 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B31Rdi8/SwjHFolVNC7vVC+ZDLA3UqCf1IpteVYRlQF4tXRXWTvTDPSZz3E+7Y7szKabEV0YzltsJbrOOf2H3wuVjcE76OfnT3TsygnHhGyepa/u3y/pzcpMkb6lzXbc+E+tialcs509mLv+Q2FatadgGS+6x1XilQjqRugd7/MC387ILWeW7RsoHQUaeAs4hqoWmBt6d+idZdG/F3CRR+EYlcQ4g2gLLq8XUrwr8G9CHTvJ3L3elpAGKtVPcnmE+B+9B+uA+BrOJV0eh8hRA/2v3QUFhh87f51I+qvWkOmF9QUgEs4Q3IAu4WAHi3FtzPKngXEciPbeRJyy/WY7Yg== 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=rYfOyG7VwQvVDdmS9Xhp6V7pkp5btYH+GI0GKVkNYBQ=; b=R+MrBRLj/DJHJCoS8wdKZGm1MeIi96hyZiKDtN89Si847aEm1JQl6XTdjiz93ZLX4BJNBt5+AXQArc7+LVtUmgcpUvWgbFfLv0ND4kycbXW0qqSAymn56b4TjzP4UkLCjMKEE3KHB71goPr6h37JZVijELaTu7MWi5W71/ZQNxMuuBbcnucT0uo1D0H7E/ScvUc41M8/VVKkyAoEefxte3BvWY3W7TyGnQUhdRP7Gmw7jeU6PoCgzvJKiF9XyeT22lhCAsO1VP7i9y1jIFOcZWJ/1yffEFZgiBxdGxSp2PEJCIXgtmy+Y+QJv+ig31repWHBQ+BrSJvU4QKtkPcVLQ== 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=rYfOyG7VwQvVDdmS9Xhp6V7pkp5btYH+GI0GKVkNYBQ=; b=e+u6n33SU3YRNJMS+3CtxxfaLTyqXGsIvgFIo+i0wXAa0ZNGhMaMYWi/mOLFbdNPk/aSQQeOub5MKbS2v/rgmyO2uHpvHeFPtyFsoeLNSjkKT7LTTflXa4fritaby/lXeuYkciYRYg4mvVTqBbPNRSq+IPpSkVaxgALVcxGsFVE= Received: from SN6PR11MB2622.namprd11.prod.outlook.com (2603:10b6:805:57::31) by SN6PR11MB2559.namprd11.prod.outlook.com (2603:10b6:805:57::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20; Thu, 7 May 2020 20:58:40 +0000 Received: from SN6PR11MB2622.namprd11.prod.outlook.com ([fe80::ec4f:5d21:5d27:7c2a]) by SN6PR11MB2622.namprd11.prod.outlook.com ([fe80::ec4f:5d21:5d27:7c2a%7]) with mapi id 15.20.2958.034; Thu, 7 May 2020 20:58:40 +0000 From: "Jeffrey Ladouceur (jladouce)" To: "netconf@ietf.org" Thread-Topic: Question about RFC 6242 : netconf over ssh Thread-Index: AQHWJLJJ55sx7YpD4UCJKbsIO07H1A== Date: Thu, 7 May 2020 20:58:40 +0000 Message-ID: <71AEFEF1-BAC4-48EF-A591-7E8A85D421A0@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [87.101.49.80] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e9a109b0-e202-4c27-e0c5-08d7f2c96bc3 x-ms-traffictypediagnostic: SN6PR11MB2559: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03965EFC76 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LoepqsO+dvx4/XCUMa9MJKUuAYXrIDYKwoizE4zJ7kv7iEQE5Ip8kLSY7jsnIQusF8m0EbgsxB4J9yxKYQJQg9sSvSDhYX15L2UV/8dpkFrxlUTOTFge6UOf+G9DN0Y6IPaOIYxb3eWxVFVkiCxieGSWt2Meyj8ftWRaPVkh49x2gBlJ/7glAlTb8e51DVrSaX9SUVsPUoGmOGHdIAsZCQWV52lM325XjLeK6z/Xb6XXmVeyju/W6GPgRhZH0KC74Zm6qnxmc/saoH8KOxTpSG41qi5qEGlxqTYL0+Aot68wPVfjPtNPvLF4CU9+wdi71wx/DDlKRn+nz6r+BOTl4gIBxl1tf3AJqAfHDI/EbCrg2s+tQQLVh+tZRgTm1vlb0GmeH3+eEWYmcQBOA9j+sA1z2jlnMJw93JTZWwo8aHQDq3w3U4kNPVj7GYhY3HG1ORZIkAYrSmc/CYR4QfXZS4sogMgp/oOoBdzHUZdPDjpz2NnWR6kRhxWeL1EAHwJlCaV5aVpZiJ1uT0DBFAR6EtLU0uEBo8FaEjwsitYQcVAgpmBGO/umBQy/RUxeUIr7HIxLk+v4JTTdN0mogTzCZzpAoioROwlRaO/a+BU5KZQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR11MB2622.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(376002)(366004)(39860400002)(346002)(33430700001)(6512007)(5660300002)(71200400001)(316002)(66556008)(76116006)(64756008)(91956017)(66446008)(66946007)(66476007)(83300400001)(36756003)(2906002)(83320400001)(83280400001)(83310400001)(83290400001)(26005)(186003)(478600001)(2616005)(966005)(33440700001)(8936002)(86362001)(33656002)(6486002)(6506007)(8676002)(6916009); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: PXYBDVOp0kapqjF7M2k2yynIRXyTbznmVlIk8oM6gA9ssCoviWn0cxWu7Bz1K/gxasS6gHQmqNq31K1cZCUU/O0oEstGzpe/HiTqTOIbFlKcBfSL8VFtkJ9wIG9HUeAe96hxfGO5LYeZTY7iVTfcLKpZIyr8P3iCQ/sPZpc8EjwgA5tYi11aHkkS1DxT6oQ868fJc2jCXqC3ZsDKyxmxfDDbvmHTp9hnkn7vWlSGaZXpqhBkCxpU267etMchM+1Qiq50+/TiKb/Up63Ftlpg8YOrhJvMnVd2mUxy7ncP7B53z1cgr6Gb4Z7+7+E+v0G0l7LUo091rMDXXOKvEnyZH5hq97wflBOhTp37d5IUOsWQI7XbDZxfcBYaFhTKEwE8B1Du5lxmz60Iu9s1qde313uj+yMUkVYIzuYsVJ6l6qy7CSP0TIVuhF/NIj0YmPW6wA8mS0ZAnllQt5+R+AscnsLSFc41TnqbxNTCruAMM8FmSMR+vS4Pk8qIZ1rkNXf6AH8nPrR6RgTDrsfRwenE7Ao2nTQ/o9EMFT1WrHGL2zu+ydKt8jQ0D67uz+KXRzYuh21hqS8LtraMLAX77JPfs3DR/y555QJSn0sxGvOOHPwxPSVSMtJI1FKkXb8KBlraUXPaNNEUlqrJOIk+6vX4cZNMENK91tcerW31ElvNdZknWWwdq5h7lV6K+Zo/VxKQXulbwiBH4gF9U90nZY+Yqnrk3AMNeWWSEUmL9UgSxcOxH62v5COEXbxQYufHMQuigiSXjasMrb7W61xU0fGlHe6b/BIHeUx4q6Tn0haQcOU= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <9A18471D758F2B46BC97F11EBCD67B2E@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e9a109b0-e202-4c27-e0c5-08d7f2c96bc3 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2020 20:58:40.5202 (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: c+eSC98mq3KqOG/V7O4hmAiZVeBlB6PoM7rQBxQRJM6RhgapK+A/A0lcERlgvA+NZCSoNE54GeI6523Ly5q+3g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2559 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: [netconf] Question about RFC 6242 : netconf over ssh 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, 07 May 2020 20:58:53 -0000 SGVsbG8sDQoNCkkgd291bGQgbGlrZSBzb21lIGlucHV0IG9uIGEgdGhlIGZvbGxvd2luZyB1c2Ut Y2FzZSBhbmQgcG9zc2libGUgYWNjZXB0YWJsZSBvdXRjb21lcy4gDQoNClN1bW1hcnk6DQoNClJG QyA2MjQyIGRvZXNuJ3QgZXhwbGljaXRseSBpbmRpY2F0ZSBhbnkgbG93ZXIgbGV2ZWwgbWVzc2Fn aW5nIGluIFJGQyA0MjU0IHdoaWNoIGNvdWxkICJicmVhayIgdGhlIG5ldGNvbmYgbWVzc2FnaW5n IGJldHdlZW4gY2xpZW50IGFuZCBzZXJ2ZXIuDQpTcGVjaWZpY2FsbHksIHRoZSBjbGllbnQgY2Fu IHNlbmQgYSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDI1NCNzZWN0aW9uLTYuICJw dHktcmVxIiBqdXN0IHByaW9yIHRvIGludm9raW5nIHRoZSAibmV0Y29uZiIgc3NoIHN1YnN5c3Rl bS4NCkhhdmluZyBhIHBzZXVkby10ZXJtaW5hbCBkZXZpY2UgaW4gYmV0d2VlbiB0aGUgY2xpZW50 LXNlcnZlciBjb3VsZCByZXN1bHQgaW4gdGhlIGJyZWFrYWdlIG9mIHRoZSBtZXNzYWdpbmcgYmVp bmcgY2xpZW50L3NlcnZlci4gDQoNClJGQyA2MjQyIHN0YXRlczoNCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM2MjQyI3NlY3Rpb24tMyAoU3RhcnRpbmcgTkVDT05GIG92ZXIgU1NIKQ0K DQoxLiBPbmNlIHRoZSB1c2VyIGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBhdXRoZW50aWNhdGVkLCB0 aGUgU1NIIGNsaWVudCB3aWxsIGludm9rZSB0aGUgInNzaC1jb25uZWN0aW9uIiBzZXJ2aWNlLCBh bHNvIGtub3duIGFzIHRoZSBTU0ggY29ubmVjdGlvbiBwcm90b2NvbC4NCjIuIEFmdGVyIHRoZSBz c2gtY29ubmVjdGlvbiBzZXJ2aWNlIGlzIGVzdGFibGlzaGVkLCB0aGUgU1NIIGNsaWVudCB3aWxs IG9wZW4gYSBjaGFubmVsIG9mIHR5cGUgInNlc3Npb24iLCB3aGljaCB3aWxsIHJlc3VsdCBpbiBh biBTU0jCoHNlc3Npb24uDQozLiBPbmNlIHRoZSBTU0ggc2Vzc2lvbiBoYXMgYmVlbiBlc3RhYmxp c2hlZCwgdGhlIE5FVENPTkYgY2xpZW50IHdpbGzCoGludm9rZSBORVRDT05GIGFzIGFuIFNTSCBz dWJzeXN0ZW0gY2FsbGVkICJuZXRjb25mIi4NCjQuIFJ1bm5pbmcgTkVUQ09ORiBhcyBhbiBTU0gg c3Vic3lzdGVtIGF2b2lkcyB0aGUgbmVlZCBmb3IgdGhlwqBzY3JpcHQgdG8gcmVjb2duaXplIHNo ZWxsIHByb21wdHMgb3Igc2tpcCBvdmVyIGV4dHJhbmVvdXPCoGluZm9ybWF0aW9uLCBzdWNoIGFz IGEgc3lzdGVtIG1lc3NhZ2UgdGhhdCBpcyBzZW50IGF0IHNoZWxsIHN0YXJ0LXVwLg0KDQpJZiBJ IHdlcmUgdG8gdHJhbnNsYXRlIHRoZXNlIHN0ZXBzIGludG8gdGhlIGNvcnJlc3BvbmRpbmcgUkZD IDQyNTQgbWVzc2FnZXMuDQrCoA0KU3RlcCAoMikgdHJhbnNsYXRlcyB0bzoNCmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM0MjU0I3NlY3Rpb24tNi4xIChPcGVuaW5nIGEgU2Vzc2lvbikg LCB1cG9uIHdoaWNoIGEgc2Vzc2lvbiBoYXMgYmVlbiBlc3RhYmxpc2hlZA0KwqANClN0ZXAgKDMp LCB0aGlzIHRyYW5zbGF0ZXMgdG8gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQyNTQj c2VjdGlvbi02LjUgKFN0YXJ0aW5nIGEgU2hlbGwgb3IgYSBDb21tYW5kKSwgYnV0IHNwZWNpZmlj YWxseSB0aGUgInN1YnN5c3RlbSIgdmFyaWFudC4NCldpdGggYSBzdHJpbmcgb2Yg4oCcc3Vic3lz dGVt4oCdIGFuZCDigJxzdWJzeXN0ZW0gbmFtZeKAnSBzZXQgdG8gbmV0Y29uZi4NCg0KUXVlc3Rp b246DQoxLSBEb2VzICBSRkMgNjI0MiBpbXBseSB0aGF0IGl0IGV4cGVjdHMgZGlyZWN0IGNsaWVu dC9zZXJ2ZXIgY29ubmVjdGlvbiB3aXRob3V0IGFueSBpbnRlcmZlcmVuY2UgZnJvbSBhIHB0eSBk ZXZpY2UgPyBUaGUgdGV4dCBpbiBpdGVtICg0KSBhcHBlYXJzIHRvIG1lIHRvIGltcGx5IHRoaXMu DQoNCkZyb20gd2hhdCBJIGNhbiB0ZWxsLCB0aGUgdXNhZ2Ugb2YgdGhpcyBwdHkgcGF0dGVybiBp cyB3aGVuIGEgY2xpZW50IHdhbnRzIG5ldGNvbmYgb3ZlciB0dHkuDQoNClRoYW5rIHlvdSBmb3Ig YW55IGZlZWRiYWNrLg0KDQpSZWdhcmRzLA0KSmVmZg0KDQo= From nobody Thu May 7 22:19:24 2020 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 9E20C3A0366 for ; Thu, 7 May 2020 22:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 aAXNCPbuQC8U for ; Thu, 7 May 2020 22:19:20 -0700 (PDT) Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (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 DB5CF3A0365 for ; Thu, 7 May 2020 22:19:19 -0700 (PDT) Received: by mail-lj1-x243.google.com with SMTP id w20so345258ljj.0 for ; Thu, 07 May 2020 22:19:19 -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:content-transfer-encoding; bh=pTV1MNu3829IQDPpj2mhaAvHXQ4az/pf5d78QCDzrdc=; b=QezQ4SkgwA7eRUXKSCd9BL3tU43gRZEqfEbgQsxZ/CW9TUHOddEK31+V0GwTvYv1t8 C6yw12rVgQzshzo28NuPE9gNT0h1fTVdK1yz4UmuEE/ObMkvJqKK7sNzxxGF5hmhjl6Q mrPIVfO0L3KvfynDHOW2sUs7eUPj/9Ya5J4ZnDOGRQZitCEkkQMSgB5XqmKYQNvipzAS rYiKj8QsuDb903oKBrpuU06UN+piL+FSpyv2aFtpFa3TJB1hzknumeOfe5wnrBUfswnI 2PXJh3O4tHFhHlxE61AoJMeZzOCBSpm9evC3HyPYVUYGEYMgSoxjMbpRxup/Z3bGFqCG RInA== 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:content-transfer-encoding; bh=pTV1MNu3829IQDPpj2mhaAvHXQ4az/pf5d78QCDzrdc=; b=nvFQsiLQt0hPZo2v5l/piC8rYU3jSLAc51dQYL2GBfwR4q398oI3JLMBlnoDEIHfTd l5nEqlJ5b2Jwxh6VTiA8bxpHQ7s0LhxDWCxUPC/X5yt888YUbPiVhT9smrhd7Xy7o8sW ZD4BEPhOE5o/r7yxCpPVjPOiPj8eqKJZ3JCoklmkrXKqhkL4YSJkzGTPkmqxys+wzN7L LcWA1NOICaIy7R68WbYDHlwhFTnBvu2dt2trBALXrRGRTHdYRQJ8D9VfIDtwBZfKb4Ba 1Q+a+d408IUctCQ2l+/gamuIhFP85hK0yDXArtJWDTqOvFMA9pR7R6VdBpIW7xv3ctIA zdJQ== X-Gm-Message-State: AOAM530G2yP0Ho6zas59PrxT4owJCLvfKHH+jgSovSwJn7x/kdEb7Hzx GZuldv0Pm+L7gyb8TyJCu1KbIaerdy74dP8lQGk= X-Google-Smtp-Source: ABdhPJyknZSQpMWM0tkIX+Deblf8Joz+RYqeoYCYIRa+wjnM2S0RuMNNtIXBnGCRKR+sABghe+uRAxIrwZSK5sJBb8I= X-Received: by 2002:a2e:8693:: with SMTP id l19mr446887lji.63.1588915158109; Thu, 07 May 2020 22:19:18 -0700 (PDT) MIME-Version: 1.0 References: <20200414.222236.518728457229433184.id@4668.se> <9C6D0A8A-2BD4-4578-8CB3-6969078CE10A@gmail.com> In-Reply-To: <9C6D0A8A-2BD4-4578-8CB3-6969078CE10A@gmail.com> From: Henning Rogge Date: Fri, 8 May 2020 07:18:52 +0200 Message-ID: To: Mahesh Jethanandani Cc: =?UTF-8?Q?Martin_Bj=C3=B6rklund?= , netconf@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] Trouble with RFC 8040 (Restconf) fields Query Parameter 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, 08 May 2020 05:19:22 -0000 On Thu, May 7, 2020 at 10:33 PM Mahesh Jethanandani wrote: > > Hi Henning, > While not IETF blessed, ODL ran into multiple issues with the fields quer= y parameter, and documented in this Jira report. Documented in there are so= me of the test cases that might interest you to run. There were other test = cases run in this and this report also that should be of interest. Thank you very much for these links... hmm, when reading through them I noticed something... is fields=3Duuid;actual-equipment(manufactured-thing(equipment-type);structure= ) even valid? According to the RFC8040 4.8.3. the bracket part of the expression can only nest in the last of the fields... 'path ; fields-expr', but not 'fields-expr ; path" What do you think ? I guess this was don to prevent a whole tree of field subexpressions... the ABNF does only seem to support a "line" of them. Henning Rogge From nobody Fri May 8 03:25:00 2020 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 E4A403A09B0 for ; Fri, 8 May 2020 03:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 uWlNjOwccjKI for ; Fri, 8 May 2020 03:24:44 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 744163A09AF for ; Fri, 8 May 2020 03:24:43 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id j3so1103956ljg.8 for ; Fri, 08 May 2020 03:24:41 -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:content-transfer-encoding; bh=qiEqKfAQ31/V5oMB/eTu0GNiJWjvIkFDic0jm97mlGc=; b=QTvZh7CdXVpmmOAe2ptNbZfm8T3z7pph7xkOVd8/d2xEP1t5wU/rYv3opC1b/QJW8d cxi9axKz4mNAC7lErUxMxTINyT5CY1P6ZWa/7xP3NrN2Ov4zS0+y7qIK1/pQhpyTs3eg v01N/jUTsw1bXCEJtCnLZ5keLSl91IeCWfCkZ4CD2pY6B3pP9cNy8ej1XGri58Oo2U69 L2OfNosuXvK/yYWLIM3d5vwjiGaHsNvqDoxsj2jVIn4JuSmSxhOfyhsK4xZ8eWZQRJqi y55DAdu/D2Wjh2V0tm5AvAWGRYERqRUTgILpzrfXL3q9RFdgwBoZWmFsUKt2i+H0u8O7 2IFg== 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:content-transfer-encoding; bh=qiEqKfAQ31/V5oMB/eTu0GNiJWjvIkFDic0jm97mlGc=; b=AUDmtBR0ILrTtugwP5z34Gn6H3xX9m3ySvqOZx1YBfw2V5FutAEDVAnwVvVj1AwS96 l1crFSV3sWuCyEToaOm2Zyga5pIm8bn45R4zPrRU4uJwmUmMGW1Pach4XI1R+YtJMmI2 NtrHgsBrF6pmW4qVfSxb4lyJdqqNkfCJHp0LSipChIyy0679aSsUCvl0jZ6kEQ+ve+0o 2gmCPxv0n1169jwbHhNMMqIf1JsiE9KGNjFI68t/NBBYq616hxO3EW1kb9JhWoKWAa3n c9LGPf6qjn6ZbI63CRe4vrrFqFEeD83EybTpc+lmfOylRPlb7DavRINJmOhhLPYT/9YJ znuA== X-Gm-Message-State: AOAM533hV4DjxiXaZg1uS1T+LrN7GBGlijemQantmmC7A1YeuuqXmcyv ullEf7ihI28205EpxtM/B4NL2B63a6k8lki1sqA+/5YieX4= X-Google-Smtp-Source: ABdhPJy3Kr02CDvYOrAKZLddpQ3d54fjW/jIyoOQ4UpaSdgD70dwFIisBeKZvqGMd3wM4DNv2n/WonsQhl9vBvNFSTQ= X-Received: by 2002:a2e:9cc1:: with SMTP id g1mr1227852ljj.261.1588933479368; Fri, 08 May 2020 03:24:39 -0700 (PDT) MIME-Version: 1.0 References: <20200414.222236.518728457229433184.id@4668.se> <9C6D0A8A-2BD4-4578-8CB3-6969078CE10A@gmail.com> In-Reply-To: <9C6D0A8A-2BD4-4578-8CB3-6969078CE10A@gmail.com> From: Henning Rogge Date: Fri, 8 May 2020 12:24:13 +0200 Message-ID: To: Mahesh Jethanandani Cc: =?UTF-8?Q?Martin_Bj=C3=B6rklund?= , netconf@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] Trouble with RFC 8040 (Restconf) fields Query Parameter 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, 08 May 2020 10:24:55 -0000 Hi, I finally got the okay to push my testcases to a public repository... both the description and the filenames are still a little bit rough and could use some work, but this is what I am working with at the moment. https://github.com/fkie/ietf-restconf-testcases Henning Rogge On Thu, May 7, 2020 at 10:33 PM Mahesh Jethanandani wrote: > > Hi Henning, > > On Apr 20, 2020, at 3:44 AM, Henning Rogge wrote: > > are there any set of test-cases the IETF used for interoperability tests? > > > While not IETF blessed, ODL ran into multiple issues with the fields quer= y parameter, and documented in this Jira report. Documented in there are so= me of the test cases that might interest you to run. There were other test = cases run in this and this report also that should be of interest. > > Cheers. > > Mahesh Jethanandani (as contributor) > mjethanandani@gmail.com > > > From nobody Fri May 8 06:11:53 2020 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 C44163A0AAE for ; Fri, 8 May 2020 06:11:50 -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 (2048-bit key) header.d=hubler-us.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 ov0jDuvtdTlU for ; Fri, 8 May 2020 06:11:48 -0700 (PDT) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 AEB4E3A0A78 for ; Fri, 8 May 2020 06:11:48 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id n11so1340078ilj.4 for ; Fri, 08 May 2020 06:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hubler-us.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oJEyT2R1nCOV7UUI1TXBPS2YkSLLnhD+NyUIuuIdN6A=; b=wBtezeQMIHnBnUmJH9a/9zdmv9snZROEG1j17bHiZeX/vLSamgyGEYqQtBeYPs33Tg X+izFcYRmheTdXZnVVLuDURR5kbx1XvnPP8EZlFNNYxgdNiW+3hud89uC4JP7aowhldB HsuSSGvBukXR5pLIt9xrXnFMO7V5MxoYxK+HN9aSQ91WvhMzzM2OjMHK7H8WfTozzP6M zLy/fSk57d6lRlziEB0uGLFz/1kU6FJgIcKrMp9DKt2cT5S1B5wYBMciynKjLd03LFm0 Cgz+EAjenNujRxiPJ7twSlAPqFvE64cmpDSzm1WttSd2UuyXF/Awo9VYyoQx07FyFJei WmsQ== 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=oJEyT2R1nCOV7UUI1TXBPS2YkSLLnhD+NyUIuuIdN6A=; b=B3Rv8UWXDmD1swmgAw2YBlclJo6kFPqPMj1Hc09/qwr9H4/72TRX2mkkkIBVFNy2x/ D45FQ+yNx8x+LCFBmx90Q2HBQ16bWgWbq9FGHOjk9yQ2vItKWl5goUg+67kHKEqDiUBw d8HaObV8woZrDM2hjolrLo1fh9kuKH37qiPAjs8lNB92yr+MRDF9+vDU4J57lLujN5tt PDUD4iiUJ+0Pr9VxKh1GU77ifgvFAvOUD6dzEAumK07rUaaa33M4labErHvTHxagxk5s eSE1ViBGzZqk14x0/XoVSbtpqJ/4mhxNwdhfIHzHubvdEAK8GzeOC+luqFbfSOQUD7xG CINg== X-Gm-Message-State: AGi0Pub+dIxU5jl9fTbo3sKwdgkPx7Ci7QxxRguREIRUfc4RztO9Ed/d sN6hOj9wNabd49+WuNBVyqtwmHVyWK8= X-Google-Smtp-Source: APiQypKISI/zsjbHu+Ef2kuNBVIqbjfXbMYazjqOUvksmqqom9GoAafYgtGJhtrF6BdnhhXJfB1rFg== X-Received: by 2002:a92:bf0b:: with SMTP id z11mr2701698ilh.207.1588943507525; Fri, 08 May 2020 06:11:47 -0700 (PDT) Received: from mail-il1-f179.google.com (mail-il1-f179.google.com. [209.85.166.179]) by smtp.gmail.com with ESMTPSA id l13sm683770ioc.11.2020.05.08.06.11.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 May 2020 06:11:46 -0700 (PDT) Received: by mail-il1-f179.google.com with SMTP id w6so1351642ilg.1 for ; Fri, 08 May 2020 06:11:46 -0700 (PDT) X-Received: by 2002:a92:b710:: with SMTP id k16mr2662321ili.270.1588943506432; Fri, 08 May 2020 06:11:46 -0700 (PDT) MIME-Version: 1.0 References: <20200414.222236.518728457229433184.id@4668.se> <9C6D0A8A-2BD4-4578-8CB3-6969078CE10A@gmail.com> In-Reply-To: From: Douglas Hubler Date: Fri, 8 May 2020 09:11:35 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Henning Rogge Cc: Mahesh Jethanandani , Netconf Content-Type: multipart/alternative; boundary="00000000000044eab305a522bdc5" Archived-At: Subject: Re: [netconf] Trouble with RFC 8040 (Restconf) fields Query Parameter 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, 08 May 2020 13:11:51 -0000 --00000000000044eab305a522bdc5 Content-Type: text/plain; charset="UTF-8" I've been very interested in restconf test cases and glad to see some activity here. So is the idea restconf server implementations stand up a server that loads each config/state one-by-one then a utility will also read in same test cases, exercise queries and assert the expected results? I'd definitely like to hear more about how you're using this currently and if you have a working model. Thanks for sharing. On Fri, May 8, 2020 at 6:25 AM Henning Rogge wrote: > Hi, > > I finally got the okay to push my testcases to a public repository... > both the description and the filenames are still a little bit rough > and could use some work, but this is what I am working with at the > moment. > > https://github.com/fkie/ietf-restconf-testcases > > Henning Rogge > > On Thu, May 7, 2020 at 10:33 PM Mahesh Jethanandani > wrote: > > > > Hi Henning, > > > > On Apr 20, 2020, at 3:44 AM, Henning Rogge wrote: > > > > are there any set of test-cases the IETF used for interoperability tests? > > > > > > While not IETF blessed, ODL ran into multiple issues with the fields > query parameter, and documented in this Jira report. Documented in there > are some of the test cases that might interest you to run. There were other > test cases run in this and this report also that should be of interest. > > > > Cheers. > > > > Mahesh Jethanandani (as contributor) > > mjethanandani@gmail.com > > > > > > > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --00000000000044eab305a522bdc5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've been very interested in restconf test cases = and glad to see some activity here.

So is the idea rest= conf server implementations stand up a server that loads each config/state = one-by-one then a utility will also read in same test cases, exercise queri= es and assert the expected results?=C2=A0 =C2=A0

I'd= definitely like to hear more about how you're using this currently and= if you have a working=C2=A0model.

Thanks for shar= ing.


On Fri, May 8, 2020 at 6:25 AM Henning Rogge = <hrogge@gmail.com> wrote:
=
Hi,

I finally got the okay to push my testcases to a public repository...
both the description and the filenames are still a little bit rough
and could use some work, but this is what I am working with at the
moment.

https://github.com/fkie/ietf-restconf-testcases
Henning Rogge

On Thu, May 7, 2020 at 10:33 PM Mahesh Jethanandani
<mjethanand= ani@gmail.com> wrote:
>
> Hi Henning,
>
> On Apr 20, 2020, at 3:44 AM, Henning Rogge <hrogge@gmail.com> wrote:
>
> are there any set of test-cases the IETF used for interoperability tes= ts?
>
>
> While not IETF blessed, ODL ran into multiple issues with the fields q= uery parameter, and documented in this Jira report. Documented in there are= some of the test cases that might interest you to run. There were other te= st cases run in this and this report also that should be of interest.
>
> Cheers.
>
> Mahesh Jethanandani (as contributor)
> mjethanan= dani@gmail.com
>
>
>

_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--00000000000044eab305a522bdc5-- From nobody Fri May 8 06:59:46 2020 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 B68BB3A0ADE for ; Fri, 8 May 2020 06:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 GLujlEGkqte7 for ; Fri, 8 May 2020 06:59:42 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 22FE03A0927 for ; Fri, 8 May 2020 06:59:42 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id t2so1497008lfc.3 for ; Fri, 08 May 2020 06:59:41 -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=d3pF0cEMa1VKgLwJXrE4OlZVPsx2Vmw0gF99F/Knft4=; b=OoYv6PBvqh2WfvkAIjuwKTUKclSAuMvgGUdZrXv46Zxpl3NUhhrb6cIR+Anuf56/zM CREFgVBnfKtofeoFMPpKLKTBhBvKFCpyhwkMppFSuWjSxCZqz2El0YpcpUhfJgIQLoPw EDOc8Ik3GNH+MRgzyUMoUkk7UQzd/zFxRcoDdMsloSRmQEbS1M+ujsqZER0lhz2NtFms o3nDeVfp7jU3n2Jd9JY6eE2VWJssMiOYq7OoVLRVkzrMK4q104g5Yb6VZ/EqvcI42Kwb 6217I7V8uWPxgjIkMvSBdlizbjCdQGM1h74dBiPKjxhZpse64fcVLqXLd2GcOHnrdbw5 a89A== 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=d3pF0cEMa1VKgLwJXrE4OlZVPsx2Vmw0gF99F/Knft4=; b=erfdDJh35wtz/siQLhYlQI3moGd9HtfGq7uAvB+NY4o4FASD4KGMfVWwVvLHg4UM4r lWtPA6UdLzb4+3XSto7izUTdik10E3TD/bEC4nwwnDgZv46VMzyZsedH3RSe1gp0HcbL aBfNIZeUqcTYmQk9LV6czzYB84cvhoAaQ1A9eIHTK14WRfkgq3BWR44VJgI3kKkJAKes DJS4oISJjI2vU2Y8/ZJBoWLE41tiexNn4tC+VGk/rur2f/WKDNnp/Ip5w8y+RUgTM5OI w1H8/LVrBrQfW1eOmZKkVoIKbOCfLsJ5v3oKYZ/q25u6juEjxEnowqyMYCB8RJMglaqQ ryXA== X-Gm-Message-State: AOAM530br4YCldWVdq60x5fMjF9LL6bLUQHj+nRefVeLryOpUzbN8CB3 csLrGYH2NUfubMjtjnMhQSoPEjdrp+Cx07omPH4= X-Google-Smtp-Source: ABdhPJyH/nXqeKuJbmS2ZRJ/NpgSR767svCO6p2ystBykKnsJfA1ubQTHR0jyY1opnXyxaYQNcwuH1C71tgb16ZMIWc= X-Received: by 2002:ac2:58d0:: with SMTP id u16mr1981252lfo.114.1588946380094; Fri, 08 May 2020 06:59:40 -0700 (PDT) MIME-Version: 1.0 References: <20200414.222236.518728457229433184.id@4668.se> <9C6D0A8A-2BD4-4578-8CB3-6969078CE10A@gmail.com> In-Reply-To: From: Henning Rogge Date: Fri, 8 May 2020 15:59:13 +0200 Message-ID: To: Douglas Hubler Cc: Mahesh Jethanandani , Netconf Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [netconf] Trouble with RFC 8040 (Restconf) fields Query Parameter 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, 08 May 2020 13:59:44 -0000 On Fri, May 8, 2020 at 3:11 PM Douglas Hubler wrote: > > I've been very interested in restconf test cases and glad to see some activity here. > > So is the idea restconf server implementations stand up a server that loads each config/state one-by-one then a utility will also read in same test cases, exercise queries and assert the expected results? Yes. > I'd definitely like to hear more about how you're using this currently and if you have a working model. I use python with two threads... one thread starts the server and loads the "before" state into the datamodel. The other one waits 100ms, sends the HTTP request, parses the answer, check the answers body and headers and then checks the (possibly) changed internal state of the server. Both before and after uses the standard Restconf JSON encoding. After this the server thread is stopped and the client closes the connection. This is iterated for each test. At the moment the "/restconf" part of the URL is hardcoded... I will definitely change this when I switch to the "unified data store". I think I also have some tests where "before.json" and "after.json" are the same, so I could replace them with a single "state.json" file (easier to read). The trickiest part was to write a compare function for the servers response body and for the final server state (and setup and teardown of the second thread ^^). My tests use "pytest", so no special things involved. I am currently trying to get permission to share the code of the server under LGPLv3, same licence as the yangson library I use. I have also written a couple of extensions for the yangson library (e.g. XML input/output support), but I am trying to get them pulled into the upstream implementation. In theory the "write initial state" and "read final state" could be done with Restconf HTTP commands, but I would like to keep each test using only a single HTTP request. Henning Rogge From nobody Fri May 8 07:55:13 2020 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 CC89A3A086B for ; Fri, 8 May 2020 07:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 yMUfPQpf71p5 for ; Fri, 8 May 2020 07:55:01 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2102.outbound.protection.outlook.com [40.107.21.102]) (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 B3C633A0B6A for ; Fri, 8 May 2020 07:55:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Uq8+aWVe0NTrUjJT9tJTlErzHpeN4lMAPBvzYl+YJgsIUemrmZg10bV2GSRrYcmKG28qtr0l8500Q+PhDhWkbVwHtUHXXYmHklLyWOfqqovDoB6veV7Km5j2Uli/BNB7z4NhUKHJmaI341K1aK3/DkGJc/DTr+UynpjCp0cP+ZPPEx2HhrLZJ1GbScbgWLbEG5gc6vmN/f0FRMIGYGVf6GToIEUTvFs3IFoqvF9fRB51FUOGKlpS8cnZWqqU+Wge8q2sLWexYS4AKzBTsFvWf3I/Sq0zkgO6e52Pbc4myHJEdd04hnXJ83ZlBx+BC/3EJctT3dqtEGerVIqYPn1WDw== 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=HFOq9AX9hQS2KjScWWp44V9JBmba24h2vHy5BCc8oQg=; b=a3848LYgILAl5Vsk10Jz4L7dClVamXD5xaPdiE71RrrCvINyQTwz1MMt1ppviUrPIV0rL/6p/5UZL6ttB0FqYYl2wZk3lk0InDTbvaxfKY0/p7Qyqy3uWUtU3wsGLulTnmx6COob7xFvb11LkWC5H41qayG98eslBWAfb1vdFxOYg2d5qt44q9HrApiglpdsz7zu8x4VGxgS4QF1qXII9j1zXUA9m3/Sc94hCDsX7ok/ELfotiZGJMrmno8a2d6o2EJHZJKA164CaY/xd6gvNW86RypGUdx7LT6UhoNa0Xay0USOflvvIzTeqNiMnuV26LNms2497EoL3hHvXST4yQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HFOq9AX9hQS2KjScWWp44V9JBmba24h2vHy5BCc8oQg=; b=SQ1lTfERX6KlciXd1uYYkCO26Hwf2Y31ibAa0vEqnGwZwWWyyi0EZQsogFbrw22tTcmMY/UDT9WOYOgJ/xYmeAImsWxIpw1YfIvcek9ICCwBLqT720PIVHs4U46Xpjh1Uu9sjpxKn11jPfYqD1f1Ka6dF0Dt5jmKKNkwFNz9j6Y= Received: from AM0PR07MB4547.eurprd07.prod.outlook.com (2603:10a6:208:73::13) by AM0PR07MB4420.eurprd07.prod.outlook.com (2603:10a6:208:b9::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.23; Fri, 8 May 2020 14:54:57 +0000 Received: from AM0PR07MB4547.eurprd07.prod.outlook.com ([fe80::e8a3:c3:735:383f]) by AM0PR07MB4547.eurprd07.prod.outlook.com ([fe80::e8a3:c3:735:383f%5]) with mapi id 15.20.2979.028; Fri, 8 May 2020 14:54:57 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: "netconf@ietf.org" Thread-Topic: Question related to ietf-netconf-with-defaults Thread-Index: AdYlQ1uOZrBhhp89RjO4s3/1vCvkdAABTalA Date: Fri, 8 May 2020 14:54:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [2a02:1811:e41e:3400:596b:b7ab:d629:c524] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6c4d2d81-e9ba-4391-bd89-08d7f35fc6cb x-ms-traffictypediagnostic: AM0PR07MB4420: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 039735BC4E x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dUzqOr2ADxow0CLQoBsSzqItWG8OE23WYRKc4scYL4/mHgGxF+weK/m1dliAc1WYeN6JFRDNK/oh+hHnA2iuzG/O/tT7X+5qXYP+SIHQun1iWn2wshUl5QXvln6FTBoiyMGMrYGQopMCtRY2Un8LyxXfbNZDK+cFoGF9rgLWA1TlIf5P0dDArUHKXP5NapIHJfxwzkRCn42DqmaeGN9h5h/tKkemsw1toE6OBVI1s+UWYzUtpmaK/ZNzU3IzbCH4jT9CBV+PoOXvxgx1k/kPz67OH4JaU0y/j88SuVvQUyeUxzxpsJcK/EeuRtaU31lb5M8ZAtIwtTnO0c7cmjPmFowLzM/mg1BOBb5liotYieJ2rgdh90QOWQBtf9tb9gjmx446aSLmjt0hODoswYR9O+WGxkN5U8tVGTHGNKjILstisWgRdpdsLSsdtv8tWOKpT5Fvi4K+yM4QyBhuEOO2kJBSQFgVs/sCGe3IeLuHBPUjvhGJVK2ydsq9F+D3TsVCQTD2wTQQp0i6kabanZg+IIHCtAiGJxTuVwAzebxbmqV/AfGvWdVHwObxZ/qRw7CIiBL7BhU641Keos0EPn+94mIajPjFPrqz+1Jxda8qiLE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB4547.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(346002)(366004)(136003)(376002)(33430700001)(66556008)(64756008)(66446008)(71200400001)(478600001)(7696005)(186003)(52536014)(6506007)(8936002)(166002)(2906002)(76116006)(33440700001)(5660300002)(6916009)(8676002)(316002)(66946007)(86362001)(66476007)(55016002)(9686003)(33656002)(2940100002)(83280400001)(83310400001)(83320400001)(83300400001)(83290400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 2XioL3Au3pb3Osityd0zrjhDwIJ8h4dprfleDNpxFVaQJR3fwVWQX4srlUXewIttnss0ElsAGlpi0UD66FajU+3BrFqL1MJcFjIjBgN/XAs5iFNlB1eDorEEAabsqNtaCVRuOZ5SMc1hZCIsS+Ozjjut7sgODXm3UF3rG8reZtIF6Iy/56CDiAzciHhbNsO7yyWQACgGvNuDzOJzk6cXSGo4SerON0WNE4Pd+kfcglnAxFP69BrZblFPg9Tc69rDIQwo7xb7b4a9eEbDOwcrt2fM271IiQJONoIJMsHPpKaOMukBIHXECXD79QDlChjbmwft2VyopfCs6CKVt2w/K7DHnHtDcK7+LN5+LvGi5q5lU/nI/731/gJOeQcSQ0eGedwKyTBnRSruu/iMsZPhpuxzuUt2Di9EEIR7U99eXMoLfnFS+z2PlkAgEzeO7yvfe3KVkWyf//9XPvJoUPdFKjoMXqyRpQTe0+KDQ4QiOvK9gEHNBSQ+aMxKQGbsa46XwV8u/7l+6StcXD0US76oSiQnZscwL/RD/RZud/C0n8PzNPLQc0zL6geyeY2hQcu8 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR07MB4547FFCD1BF0DEEA2C55D0D294A20AM0PR07MB4547eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6c4d2d81-e9ba-4391-bd89-08d7f35fc6cb X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2020 14:54:57.7669 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5Sx7mJZGWLbzN0HlKh1L6y9S9tBNarTY9LkKDuF5GcYWV0iHv4/2DpdPgwp0kRxa4dyAmdVTbsAsTA/asxWzeA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4420 Archived-At: Subject: [netconf] Question related to ietf-netconf-with-defaults 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, 08 May 2020 14:55:09 -0000 --_000_AM0PR07MB4547FFCD1BF0DEEA2C55D0D294A20AM0PR07MB4547eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have a question related to the with-defaults capability and the how a NC = server should be dealing with schema-defaults. 1. Assume the following model: module leaf-has-default { yang-version 1.1; namespace "http://www.example.com/lhd"; prefix lhd; container contains-leafs { leaf num-value { type uint32; default 1; } leaf string-value { type string; default "bla"; } } } 1. The server does not support ietf-netconf-with-defaults Using an RPC we configure the node 'string-value' to "bla" (which coincides= with the schema-default). But the optional 'num-value' has been defined w= ith a schema-default. I'm assuming that the server will return the value 1= in case it receives a get-config request, correct? 1. Now assume that the model is changed so that the schema-default of nu= m-value is changed to 5 and the schema-default is changed to "blabla" and t= he server is restarted with this new module (or does an in-service upgrade) My assumption is that the server now: * returns 5 for the node 'num-value' (new schema-default and node was n= ot configured explicitly) * but still returns 'bla' for the node 'string-value' (as this node was= configured explicitly but happened to be configured to the schema-default0= to the same get-config request. Is that understanding correct? I'm not looking at this topic from the view-point whether this is good YANG= -practice but from the viewpoint of what must be expected from a NC server = implementation. Best regards, Bart --_000_AM0PR07MB4547FFCD1BF0DEEA2C55D0D294A20AM0PR07MB4547eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have a question related to th= e with-defaults capability and the how a NC server should be dealing with s= chema-defaults.

 

  1. Assume the following model:

    2.  

    module leaf-has-default {<= /o:p>

      yang-version 1.1;

      namespace "http://www.example.com/lhd";<= /o:p>

      prefix lhd;

     

      container contains-leafs= {

        leaf num-val= ue {

          = type uint32;

          = default 1;

        }=

        leaf string-= value {

          = type string;

          = default “bla”;

        }=

      }

    }

     

    1. The server does not support ietf-netconf-with-defaults=

     

    Using an RPC we configure the n= ode ‘string-value’ to “bla” (which coincides with t= he schema-default).  But the optional ‘num-value’ has been= defined with a schema-default.  I’m assuming that the server wi= ll return the value 1 in case it receives a get-config request, correct?

     

    1. Now assume that the model is changed so that the schem= a-default of num-value is changed to 5 and the schema-default is changed to= “blabla” and the server is restarted with this new module (or = does an in-service upgrade)

     

    My assumption is that the serve= r now:

    • returns 5 for the node ‘num-value’ (= new schema-default and node was not configured explicitly)
    • but still returns ‘bla’ for th= e node ‘string-value’ (as this node was configured explicitly b= ut happened to be configured to the schema-default0 to the same get-config request.

     

    Is that understanding correct?<= o:p>

     

    I’m not looking at this t= opic from the view-point whether this is good YANG-practice but from the vi= ewpoint of what must be expected from a NC server implementation.

     

    Best regards, Bart

--_000_AM0PR07MB4547FFCD1BF0DEEA2C55D0D294A20AM0PR07MB4547eurp_-- From nobody Fri May 8 08:27:25 2020 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 90D5F3A0ADA; Fri, 8 May 2020 08:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 uvzQyMI06ngX; Fri, 8 May 2020 08:26:42 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2117.outbound.protection.outlook.com [40.107.20.117]) (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 E8D4E3A0410; Fri, 8 May 2020 08:26:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=COtBACVP1FgxS2RAe4kUmMmbln4sqfu3lZze5mkaYIsN55bQN5vBBx84jKb0LSsuGVlUE4lAMx6c5bSPBQbZX0W3HEuLl/dMBB1f+tawR7EceFSAShTpGwuPtLKELe8wmUn8pUbY271tGycoXpiO2qWDYxJryQdHJsHZMJPqj/QQgUK5RgMByI4ONVKQlYiF2IZtJg2+2RmCHUI2PQVcCk3FbB+jYwFjutjLUBcUeEty6bjWF+lnRxt8x6dq3FavacGgxBnT8KocXpJkdNS4gcRIrHIyBF0XQH7uDtAaUiM4Wz1v5ZFzRtzkiXMwFXxRRfT1EXqhjGcehdShebNGYw== 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=WqHwe7LuyzhT3cf+6xNtS8ofX2dePSxLeMizCcyocVM=; b=G1LvjEEPWbtevoEVpIjPmL7mnD6j48jQpEIg8uEte4Qq7VHX2p3gJtlYVm08gzT2bVpyZgzvo6KCtVy3ojiWnwwKGY+25nK8nzPLKOUWgRNC0ZAPOz5QfUbVyJpBBNXwtf2Rn6me2nYxcNRDUMigoXckCKkXoC3UeIQ+u37TzEgCp0gLAV7FjjqFa/Y/6e9/d8xRSHVNn33wDcrc37HmDoc9XtW7kF4jLmMPSUrhI8A7u7fjA3L7Oci+VDWu9cwXQ2lhJyCzhG048RbA2v+RsriS0ujPJNmi/mf34PEwERcWF4D1BdbHsfpQfpK/HDmzcIin5a2Q4xAK1al3rPAHPg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WqHwe7LuyzhT3cf+6xNtS8ofX2dePSxLeMizCcyocVM=; b=PhVrNR2ZM7ann0pei9H/NyDaKYdC+uhijXucKbScEFnwwx49Fe5NLvfxLQZ1NVUEYYCYcbcZJNBEEIYNh/j9SNSGUCMkhPA+TMbifdMEg4d6UrnKfXRDnPWTkYVTLmVtos3p6GN1tsnd0YQXUZEuY9aSBVQfcaaToaj1X5/RfMA= Received: from AM0PR07MB4547.eurprd07.prod.outlook.com (2603:10a6:208:73::13) by AM0PR07MB5315.eurprd07.prod.outlook.com (2603:10a6:208:f2::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.18; Fri, 8 May 2020 15:26:38 +0000 Received: from AM0PR07MB4547.eurprd07.prod.outlook.com ([fe80::e8a3:c3:735:383f]) by AM0PR07MB4547.eurprd07.prod.outlook.com ([fe80::e8a3:c3:735:383f%5]) with mapi id 15.20.2979.028; Fri, 8 May 2020 15:26:38 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: "netconf@ietf.org" , "netmod@ietf.org" Thread-Topic: Question related to ietf-netconf-with-defaults Thread-Index: AdYlQ1uOZrBhhp89RjO4s3/1vCvkdAABTalAAAEX07A= Date: Fri, 8 May 2020 15:26:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-originating-ip: [2a02:1811:e41e:3400:596b:b7ab:d629:c524] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a1016830-f4e4-40b7-3df2-08d7f36433da x-ms-traffictypediagnostic: AM0PR07MB5315: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 039735BC4E x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eKwHHH9Sfl3mJcCVfWl3DsF1yX67mgiT3jjCqvSJ2GYhm2VtAwx9ixE9R3S1eds+dol9qiPYdOOIH+IeptqXS/LtdgMgd6daiyaR7GDldg+ddQUUO2zB3rIlKwwdfF++fsQlRmEqa2vfaJqTdJ1bY76qM/p49sWIVwlwD7fMC2aiTKmDq6oTEM9M5wm69hYGTejQYhID6YAlX8ckc9rrizceibs3+iyNtmex9ouiLNWKWX6zf3wU6sUg9FOk7aY1xJMv9VlQbcr6guLRBZtWOmdiAVLEAmHa/zAy6uCejj9Kgffl2VYbWoyVz8LMS0EQztpbORNG0q9loYq6rLEQ5VS9RTUPpv8zLK6J9ToijLKF/Gdp2EXPhJPwcUKfCM62WmTroG3pqRmcYBRgiKsp2+3lJQBzwRpSDZ31TPt5E9q17FgO2LKYa1PqMfV44NAwj2wGpB8hbjTh0vSK+TWu86wy6gQCZwQthUyDKlbcH6jRi4X/LjcmNGjEOQeQoIxur+Ns8WzVYB+6fvHWN93UcC6mrLot5TjI99faO0Cqek/0Z2gwHbzQ6Q6A/n4dIW1QdOPGXp2kUaKkXH504gLxWxdzq+BXCK6Rg/4cwZuRHGQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB4547.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(376002)(346002)(39860400002)(396003)(33430700001)(76116006)(8676002)(7696005)(53546011)(86362001)(33440700001)(52536014)(316002)(66476007)(110136005)(83290400001)(186003)(83300400001)(71200400001)(166002)(66556008)(83280400001)(83310400001)(450100002)(83320400001)(66446008)(2940100002)(8936002)(6506007)(55016002)(33656002)(478600001)(2906002)(66946007)(9686003)(5660300002)(64756008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: gBqpQ3BvKh2GUvZ4fFtS0ACCWtFtYEwdn7xjNbBoldCtK2CzIxMsCimN4KYlAwGE7D1OjCJI5sa9I8i96ugYFsd7lsNRwrH1rs72sw8mVzgQv4uvAbiooPwzuJqkuc2GbeRTnpGygoGKjdOX06RUL7+ku80GloGROTndJrA+Iw4qUcr1IZpbVnWfdf7QMW9VNhF4p2cJPqGxl+djJtGJttHgCrW/fhD90fMTxxDaroTFEn9japgyeQGjJa7QEyu3oJWYadHPqemYhk/8TEzCHMbK5ZsqY6qTdj7i7UXUezPoaTpQ/Ri7L6B9emDqFFMayGd8cWkjgEzmgaDEdhqJIuEvmKKvEyXV84S3BL60jcVrb2GMJ9NJE+a29xX8i+OnhYO9HxDNP+IIItG5PZMCnFOpvYiVu6Z+9DEUmvHIarVXDf0kwGQuA2v4wxQQySaU7XdKivSZcYEqmHrpOHeS1rlWYj7oyRxl9ODSXSUcEqxmIpra9zloAtnEqm1MibBVfJ0AiW/v2T4yO/EcIBp+SMFTC4l+k2EByl4I9z5FMhtoT15JE6YfYsv4FZW6qca0 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR07MB4547599E2676EAB2E681711E94A20AM0PR07MB4547eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: a1016830-f4e4-40b7-3df2-08d7f36433da X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2020 15:26:38.6795 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: XpklBM17mF/GuS7cLSxaty6n+Nb2RG9gotse0NCamJ46LZbTahbcokFAk/FZEy5iCug0buN24WZJw23xoEX6/g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5315 Archived-At: Subject: Re: [netconf] Question related to ietf-netconf-with-defaults 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, 08 May 2020 15:26:48 -0000 --_000_AM0PR07MB4547599E2676EAB2E681711E94A20AM0PR07MB4547eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Seems that I better address this subject to ietf-netmode. Sorry for the trouble. Regards, Bart From: netconf On Behalf Of Bogaert, Bart (Nokia = - BE/Antwerp) Sent: Friday, May 8, 2020 4:55 PM To: netconf@ietf.org Subject: [netconf] Question related to ietf-netconf-with-defaults Hi, I have a question related to the with-defaults capability and the how a NC = server should be dealing with schema-defaults. 1. Assume the following model: module leaf-has-default { yang-version 1.1; namespace "http://www.example.com/lhd"; prefix lhd; container contains-leafs { leaf num-value { type uint32; default 1; } leaf string-value { type string; default "bla"; } } } 1. The server does not support ietf-netconf-with-defaults Using an RPC we configure the node 'string-value' to "bla" (which coincides= with the schema-default). But the optional 'num-value' has been defined w= ith a schema-default. I'm assuming that the server will return the value 1= in case it receives a get-config request, correct? 1. Now assume that the model is changed so that the schema-default of nu= m-value is changed to 5 and the schema-default is changed to "blabla" and t= he server is restarted with this new module (or does an in-service upgrade) My assumption is that the server now: * returns 5 for the node 'num-value' (new schema-default and node was n= ot configured explicitly) * but still returns 'bla' for the node 'string-value' (as this node was= configured explicitly but happened to be configured to the schema-default0= to the same get-config request. Is that understanding correct? I'm not looking at this topic from the view-point whether this is good YANG= -practice but from the viewpoint of what must be expected from a NC server = implementation. Best regards, Bart --_000_AM0PR07MB4547599E2676EAB2E681711E94A20AM0PR07MB4547eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Seems that I better address thi= s subject to ietf-netmode.

 

Sorry for the trouble.

 

Regards, Bart=

 

From: netconf <netconf-bounces@ietf.org> On Behalf Of Bogaert, Bart (Nokia - BE/Antwerp)
Sent: Friday, May 8, 2020 4:55 PM
To: netconf@ietf.org
Subject: [netconf] Question related to ietf-netconf-with-defaults

 

Hi,

 

I have a question related to th= e with-defaults capability and the how a NC server should be dealing with s= chema-defaults.

 

  1. Assume the following model:

    2.  

    module leaf-has-default {<= /o:p>

      yang-version 1.1;

      namespace "http://www.example.com/lhd";<= /o:p>

      prefix lhd;

     

      container contains-leafs= {

        leaf num-val= ue {

          = type uint32;

          = default 1;

        }=

        leaf string-= value {

          = type string;

          = default “bla”;

        }=

      }

    }

     

    1. The server does not support ietf-netconf-with-defaults=

     

    Using an RPC we configure the n= ode ‘string-value’ to “bla” (which coincides with t= he schema-default).  But the optional ‘num-value’ has been= defined with a schema-default.  I’m assuming that the server wi= ll return the value 1 in case it receives a get-config request, correct?

     

    1. Now assume that the model is changed so that the schem= a-default of num-value is changed to 5 and the schema-default is changed to= “blabla” and the server is restarted with this new module (or = does an in-service upgrade)

     

    My assumption is that the serve= r now:

    • returns 5 for the node ‘num-value’ (= new schema-default and node was not configured explicitly)
    • but still returns ‘bla’ for th= e node ‘string-value’ (as this node was configured explicitly b= ut happened to be configured to the schema-default0 to the same get-config request.

     

    Is that understanding correct?<= o:p>

     

    I’m not looking at this t= opic from the view-point whether this is good YANG-practice but from the vi= ewpoint of what must be expected from a NC server implementation.

     

    Best regards, Bart

--_000_AM0PR07MB4547599E2676EAB2E681711E94A20AM0PR07MB4547eurp_-- From nobody Fri May 8 11:07:51 2020 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 902203A0F97 for ; Fri, 8 May 2020 11:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 98Vt1WeUzjvF for ; Fri, 8 May 2020 11:07:46 -0700 (PDT) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 B0AEB3A0F94 for ; Fri, 8 May 2020 11:07:46 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id j21so1214255pgb.7 for ; Fri, 08 May 2020 11:07:46 -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=t7JK2qG2o93FK5pF19712jLtcDDVENO5YbpCS7J91eo=; b=SlaBCXYyXIstR9KDgPQPo1LyryDYFngpKvXQPtkwvuFodoSVnBwhuuhV5u/jY8bp02 LjSiZofH17xhsJKztyMEjzvaIjknJ6PJJyvQEnJXiEAaX4o2qXHpfUn6K2KcQ8DrwXro Kqo1sRcNxJUx3kPIksS+Zu0xIxnJ7PbjaETLpePXjKbNrBnZaSyX3NGmhm2mGD4xRneR jGX1/J9PovL28j6flvjb2GrLpd0iQq6IpTL1/O7rOiABv1kYZj9oXbobcRkkuwnJkIC0 VgK/52CdpzNldtsvB+HVYi804bvj4fe1Cn3laaD7Czmzvv61rSHK6t2lv/6c8rDsAUPo AO6w== 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=t7JK2qG2o93FK5pF19712jLtcDDVENO5YbpCS7J91eo=; b=anvLV0iMZFP21WJ4n40Z00WCsPCA6oPJa9bpvq0acvH5nrrOc/zjg70pyBfmKSFh96 gIysQjUEXpPyWnYeFPcc4BG6EhX9Fk943olbCdzIqlEgBuyI+eaPJrDPMxmFwTjyTNVU gH0eGmJhP9jFR4UhpRJsMFkPH66NgVPld9qrJFDrnpKMeY8IqpqF/Qfx9A3Ta82gn+xL 3ANuLEpTYYSqyKM8E1D7hMTlHleCKhvCVQVvaEKLCF1algGtibCwJY9/G6cKaIcKuECy kmgj4OTZHaJtKWRTjeRQFsU/xc9WVz//k/JuJU8iWPhhE2hxVReUITl8/jXc/o1hb3vX xqlg== X-Gm-Message-State: AGi0PubrTA8yEzPPg0p3CgwTzrWAO9nmaSOM7LaOS6Tk+vETChdMWJBU DD7oPbkPCsKmCr79vgd3Z/kbWcSBZw0dWQ== X-Google-Smtp-Source: APiQypLCqS8fIQg5bAtYrWsvTCwq4VuS4MdXm94h/8Jw6h2ESV3/rkUTtr7xfkDNyjJYKjVucQm4Sg== X-Received: by 2002:a65:6208:: with SMTP id d8mr3085435pgv.225.1588961265996; Fri, 08 May 2020 11:07:45 -0700 (PDT) Received: from [192.168.1.175] (c-73-93-49-153.hsd1.ca.comcast.net. [73.93.49.153]) by smtp.gmail.com with ESMTPSA id w125sm1805350pgw.22.2020.05.08.11.07.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 May 2020 11:07:44 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <20BA9136-0FC6-4CAC-BF59-89FC16DB583E@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_AC5CB6D1-048A-49D9-B62D-7315550DBAA5" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) Date: Fri, 8 May 2020 11:07:35 -0700 In-Reply-To: Cc: =?utf-8?Q?Martin_Bj=C3=B6rklund?= , netconf@ietf.org To: Henning Rogge References: <20200414.222236.518728457229433184.id@4668.se> <9C6D0A8A-2BD4-4578-8CB3-6969078CE10A@gmail.com> X-Mailer: Apple Mail (2.3445.9.5) Archived-At: Subject: Re: [netconf] Trouble with RFC 8040 (Restconf) fields Query Parameter 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, 08 May 2020 18:07:49 -0000 --Apple-Mail=_AC5CB6D1-048A-49D9-B62D-7315550DBAA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Henning, > On May 7, 2020, at 10:18 PM, Henning Rogge wrote: >=20 > On Thu, May 7, 2020 at 10:33 PM Mahesh Jethanandani > wrote: >>=20 >> Hi Henning, >> While not IETF blessed, ODL ran into multiple issues with the fields = query parameter, and documented in this Jira report. Documented in there = are some of the test cases that might interest you to run. There were = other test cases run in this and this report also that should be of = interest. >=20 > Thank you very much for these links... >=20 > hmm, when reading through them I noticed something... is > = fields=3Duuid;actual-equipment(manufactured-thing(equipment-type);structur= e) > even valid? >=20 > According to the RFC8040 4.8.3. the bracket part of the expression can > only nest in the last of the fields... >=20 > 'path ; fields-expr', but not 'fields-expr ; path=E2=80=9D I will let one of the authors comment on what the intent was. >=20 > What do you think ? I guess this was don to prevent a whole tree of > field subexpressions... the ABNF does only seem to support a "line" of > them. The implementation in ODL does not care what order the query is placed = in. Even if the bracket part of the query is placed in the last field, = when it builds up the hash index for the search, the bracketed parts can = appear anywhere based on how it gets hashed. Cheers. >=20 > Henning Rogge Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_AC5CB6D1-048A-49D9-B62D-7315550DBAA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Henning,

On May 7, 2020, at 10:18 PM, Henning Rogge = <hrogge@gmail.com> wrote:

On = Thu, May 7, 2020 at 10:33 PM Mahesh Jethanandani
<mjethanandani@gmail.com> wrote:

Hi = Henning,
While not IETF blessed, ODL ran into multiple = issues with the fields query parameter, and documented in this Jira = report. Documented in there are some of the test cases that might = interest you to run. There were other test cases run in this and this = report also that should be of interest.

Thank you very much for these links...

hmm, when reading through them I noticed something... is
fields=3Duuid;actual-equipment(manufactured-thing(equipment-typ= e);structure)
even valid?

According to the RFC8040 4.8.3. the bracket part of the = expression can
only nest in the last of the fields...

'path ; fields-expr', but not 'fields-expr ; = path=E2=80=9D

I will = let one of the authors comment on what the intent was.


What do you think ? I guess this was don to = prevent a whole tree of
field subexpressions... the ABNF = does only seem to support a "line" of
them.

The = implementation in ODL does not care what order the query is placed in. = Even if the bracket part of the query is placed in the last field, when = it builds up the hash index for the search, the bracketed parts can = appear anywhere based on how it gets hashed.

Cheers.


Henning Rogge

Mahesh Jethanandani



= --Apple-Mail=_AC5CB6D1-048A-49D9-B62D-7315550DBAA5-- From nobody Fri May 8 11:38:24 2020 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 4423A3A11D5 for ; Fri, 8 May 2020 11:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 cq4YtjzyDDYe for ; Fri, 8 May 2020 11:38:17 -0700 (PDT) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (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 D815D3A0944 for ; Fri, 8 May 2020 11:38:16 -0700 (PDT) Received: by mail-lj1-x244.google.com with SMTP id e25so2715686ljg.5 for ; Fri, 08 May 2020 11:38:16 -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:content-transfer-encoding; bh=Hqwk6zHWGqlA8Xc/bjj1LdigNt7jMvdnIssDUXRn9zY=; b=N5Im0Nlu7vOuZCkw73YsEnDFtFzd/NuFO+Rmb4eBOz5csgH2CdvT25ylecRC6bG5ka GkcWLvT5RudXnRuyIg7in0btlVnkCObKrZzzlmVX9ZItHJ3iOGnvF1Uf/hZvj7psJ1cr FuADMCgyj7HR4EE+pKUzSRYDTpH4LHYVJneErIAy8bOFpB4lgrzC1xzo7qrJ3Z8lvQ9y +FuWra4vEuxOVTp3MyMfY4FR+0BzQ7Tw/p8qrzP90uwqJ0tKWwV74kmQguwer5uUlMW6 zzpdEKVqRzg/twlbA70H5KbNdQy6Eqh3Tu9/o9vU2hn9GkeY8c+JbF3KvDASC784VBLP Mu9A== 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:content-transfer-encoding; bh=Hqwk6zHWGqlA8Xc/bjj1LdigNt7jMvdnIssDUXRn9zY=; b=dRekz3EDbRygEfrdWMzEL3Tx2DsP8ehy09F+2XW7hVAQ2rhVgyrSaBj+okn72FRFTd ocrUOV5u8MLgwyn9sSnHq/4q1mlrgDwZUQipoBimI/L7iLzWsw2/Xwolu6jGVVJXgA/F rvFghTlWbaU6VSxj7TZ3JYebDib8yHcPsFxnjXfuNnA8KhTHk0BJzrGEQKthnVX0yYYP /R9B1AqKa2NV/6IIy7N6Oyp7zt/QWVmJr3mG0xzU58shwCxRd2HNl2B6MTqqHnRQ7vJU fA3kJnSoRXKrj+iQXFIuuvkXnEvOXiJxEHpODARBzpY3anIKUm5ghmZlEs8DnoFJ7Cy2 2oDQ== X-Gm-Message-State: AOAM530ah7C29SMIsT1tY9pMIFHv3XlBvDYrtQgUgzisuC0LgEe91d1v hCnegj63UMuu8dsEY3yuoFIQ20x6sLoVKukEaFo= X-Google-Smtp-Source: ABdhPJzq57HFQRe22/2jMz+czVPYG0q1Sryzm6DI0na8LrEw0gKWPTnXNmnWQWWU4agvXbZeZlY4m3wXb7kiZESv/gg= X-Received: by 2002:a2e:8658:: with SMTP id i24mr2417824ljj.287.1588963095157; Fri, 08 May 2020 11:38:15 -0700 (PDT) MIME-Version: 1.0 References: <20200414.222236.518728457229433184.id@4668.se> <9C6D0A8A-2BD4-4578-8CB3-6969078CE10A@gmail.com> <20BA9136-0FC6-4CAC-BF59-89FC16DB583E@gmail.com> In-Reply-To: <20BA9136-0FC6-4CAC-BF59-89FC16DB583E@gmail.com> From: Henning Rogge Date: Fri, 8 May 2020 20:37:48 +0200 Message-ID: To: Mahesh Jethanandani Cc: =?UTF-8?Q?Martin_Bj=C3=B6rklund?= , Netconf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] Trouble with RFC 8040 (Restconf) fields Query Parameter 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, 08 May 2020 18:38:22 -0000 On Fri, May 8, 2020 at 8:07 PM Mahesh Jethanandani wrote: > The implementation in ODL does not care what order the query is placed in= . Even if the bracket part of the query is placed in the last field, when i= t builds up the hash index for the search, the bracketed parts can appear a= nywhere based on how it gets hashed. Not sure about my implementation, I have to look at the code... but I think all test cases should be within the specification, because an implementation might have found a reason to care about it. Henning From nobody Fri May 8 11:49:14 2020 Return-Path: <01000171f59ea8ae-a7319ea3-12ca-4857-9b43-3f89ef6ec35c-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 BB5AB3A0AB0 for ; Fri, 8 May 2020 11:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 H8pOTj6nBVEA for ; Fri, 8 May 2020 11:49:10 -0700 (PDT) Received: from a48-95.smtp-out.amazonses.com (a48-95.smtp-out.amazonses.com [54.240.48.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A46FA3A0A24 for ; Fri, 8 May 2020 11:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1588963748; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=4yDgHRGkijjzA6ZKc37+HrBAClJX9VhYYVKvW+p1GdE=; b=YYyrbP7KVLZyJ7bRe+civQbTJNp7ZhHUeWwyf/EO22ow87D7W3UMMvtabZq3dDHV 7nNdHm3oW+DMs7PHXHwjW20n50Ch5BeYFzLojUcD5HDiI8SaLkscjvT0rFCNzP0FEV5 KfezVy8qDs3CS6pm9/zJDU5BOHW8L9rFrGso8o6Q= From: Kent Watsen Message-ID: <01000171f59ea8ae-a7319ea3-12ca-4857-9b43-3f89ef6ec35c-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_805555EF-88A5-4D1F-98E3-E0E539202499" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 8 May 2020 18:49:08 +0000 In-Reply-To: <20BA9136-0FC6-4CAC-BF59-89FC16DB583E@gmail.com> Cc: "netconf@ietf.org" To: Henning Rogge , Mahesh Jethanandani References: <20200414.222236.518728457229433184.id@4668.se> <9C6D0A8A-2BD4-4578-8CB3-6969078CE10A@gmail.com> <20BA9136-0FC6-4CAC-BF59-89FC16DB583E@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.05.08-54.240.48.95 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Trouble with RFC 8040 (Restconf) fields Query Parameter 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, 08 May 2020 18:49:12 -0000 --Apple-Mail=_805555EF-88A5-4D1F-98E3-E0E539202499 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Henning, >> hmm, when reading through them I noticed something... is >> = fields=3Duuid;actual-equipment(manufactured-thing(equipment-type);structur= e) >> even valid? >>=20 >> According to the RFC8040 4.8.3. the bracket part of the expression = can >> only nest in the last of the fields... >>=20 >> 'path ; fields-expr', but not 'fields-expr ; path=E2=80=9D >=20 > I will let one of the authors comment on what the intent was. This is likely an errata in just the ABNF. Supporting this view, note that fields=3Dgenre;year =3D=3D = fields=3Dyear;genre (i.e., order doesn't matter) >> What do you think ? I guess this was don to prevent a whole tree of >> field subexpressions... the ABNF does only seem to support a "line" = of >> them. >=20 > The implementation in ODL does not care what order the query is placed = in. Even if the bracket part of the query is placed in the last field, = when it builds up the hash index for the search, the bracketed parts can = appear anywhere based on how it gets hashed. A reasonable application of Postel's principle. Kent // as a co-author and quasi-instigator of the sub-select syntax= --Apple-Mail=_805555EF-88A5-4D1F-98E3-E0E539202499 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Henning,

hmm, when reading through them I noticed something... is
fields=3Duuid;actual-equipment(manufactured-thing(equipment-typ= e);structure)
even valid?

According to the RFC8040 4.8.3. the bracket part of the = expression can
only nest in the last of the fields...

'path ; fields-expr', but not 'fields-expr ; = path=E2=80=9D

I will let one of the authors comment on what the = intent was.

This is likely an errata in just the = ABNF.

Supporting this view, note = that fields=3Dgenre;year =3D=3D fields=3Dyear;genre (i.e., order = doesn't matter)


What do you think ? I guess = this was don to prevent a whole tree of
field = subexpressions... the ABNF does only seem to support a "line" of
them.

The implementation in ODL does not care = what order the query is placed in. Even if the bracket part of the query = is placed in the last field, when it builds up the hash index for the = search, the bracketed parts can appear anywhere based on how it gets = hashed.

A reasonable = application of Postel's principle.

Kent // as a co-author and quasi-instigator of = the sub-select syntax
= --Apple-Mail=_805555EF-88A5-4D1F-98E3-E0E539202499-- From nobody Fri May 8 12:25:19 2020 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 91AA43A0DF9 for ; Fri, 8 May 2020 12:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Y4IL13Nf5BFF for ; Fri, 8 May 2020 12:25:15 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 60A9C3A0DFB for ; Fri, 8 May 2020 12:25:15 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id a21so2846675ljj.11 for ; Fri, 08 May 2020 12:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=oGyiY+zZ7Vu603sBAkz1Ls3x094vTENVLy04FGB/iZ4=; b=mD2crQhak7P4pRg8Fz46IU8qdo5Bn6beR4I5dlUnCvzjSIYZhS5Qx7fVXSWmHdubCV F/FbgbavDTuQQKm/+HQ9ijyc8qM7wUQgGSHkp6YgeeORqALNVPO+/stAGzfiwzkCSafq nScSWYUQ6tVZvqKcmatzkm1QdNQjcVsINBb0XYejJYoJWPiqKuEyXkggHYC3nv0ZaSKo oGU3mom63OzjA1dmP5yNKSOFoTbxg1f8zteh4CTxHmlG/CMKYO9sd8cI/YOxrYu2RybN nLRNOe6QdxzJKLT9W665QOqAFZoIrJSztURxHVHI/dE8GNoOaSkVCphXKuFMiL3V/3Wd WevQ== 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=oGyiY+zZ7Vu603sBAkz1Ls3x094vTENVLy04FGB/iZ4=; b=LPYzekUnFa1YCp4cTyQRioeU3WTAJkUYOvoxdhCHSj+EulwYr5dPwByRlqBIfVbIhA vLH9mXyjncIpJagWUGQWikDW1ka3266k8pY2dWGPGsyxMaUvUTmiUQZNMbbvxPPRaHP0 m18iN8trSQ1yfeLigDE3Z5bVUsiZQTIiKA9SX8QYevINaxssgeDCFZvK0ekINWEh5Cyu gT68LTtJVODvI/ZzG6iH3XLw1BKntsdlorVX6NCYzsadKy2iCssu6IavU7aG5yY7556r DsJDRKG20/ccERRR6fUiBuuFya4W6BNSs9LhEaE5FT1ZIXgCJn7bjz6KN75ERO1OwoJH YWIQ== X-Gm-Message-State: AOAM530kMxAZJEFdJYIDZf6cRk03SrmIEdSS3lSypqOca9E1edO0cQpJ LOfr/VQ+edkyrLXCV5hgLeit3ah0ZKf6ShuHBvVvfRuz2jg0QA== X-Google-Smtp-Source: ABdhPJwHcc/bREyg2oGwLzZtF25f2q/iJqK3vhWpmzytHrIT9F0NUxQvcGcbY8TlmQlCjW8AiAtoojzGBGj64ZCs+ZQ= X-Received: by 2002:a2e:8693:: with SMTP id l19mr2655788lji.63.1588965913323; Fri, 08 May 2020 12:25:13 -0700 (PDT) MIME-Version: 1.0 From: Mahesh Jethanandani Date: Fri, 8 May 2020 12:25:02 -0700 Message-ID: To: Netconf Content-Type: multipart/alternative; boundary="000000000000d2ed1e05a527f4ca" Archived-At: Subject: [netconf] Virtual hum on the question of keygen 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, 08 May 2020 19:25:18 -0000 --000000000000d2ed1e05a527f4ca Content-Type: text/plain; charset="UTF-8" [Sorry if this e-mail appears multiple times. I seem to be having issues with Google's SMTP server] This e-mail closes the virtual hum on the question of keygen as it relates to draft-ietf-netconf-crypto-types. The poll was a weighed average poll, with folks asked to order their preferences. The overall results of the poll did not indicate a clear consensus. The tie was between keeping keygen and support at SSH/TLS layer, and not supporting keygen at this time, with the latter having a slight preference. What was interesting about the poll was an overwhelming support for not supporting keygen at this time as the first preference, with the 2nd option more evenly weighed between first and second preference. As explained before not supporting keygen at this time does not preclude it from being added later on. The WG has indicated a desire to get this work done soon, which may be why the 3rd option may be carrying more support. At this point with no clear consensus, I am going to make it authors decision. Thanks. Mahesh Jethanandani (as co-chair) mjethanandani@gmail.com --000000000000d2ed1e05a527f4ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[Sorry if this e-mail appears multiple times. I seem to be= having issues with Google's SMTP server]

This e-mail closes th= e virtual hum on the question of keygen as it relates to draft-ietf-netconf= -crypto-types.

The p= oll was a weighed average poll, with folks asked to order their preferences= . The overall results of the poll did not indicate a clear consensus. The t= ie was between keeping keygen and support at SSH/TLS layer, and not support= ing keygen at this time, with the latter having a slight preference. What w= as interesting about the poll was an overwhelming support for not supportin= g keygen at this time as the first preference, with the 2nd option more eve= nly weighed between first and second preference.

As explained before not supporting keygen at t= his time does not preclude it from being added later on. The WG has indicat= ed a desire to get this work done soon, which may be why the 3rd option may= be carrying more support.
=C2=A0
At this p= oint with no clear consensus, I am going to make it authors decision.
=

Thanks.
Mahesh Jetha= nandani (as co-chair)
mjethanandani@gmail.com
--000000000000d2ed1e05a527f4ca-- From nobody Fri May 8 12:51:11 2020 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 6CCB23A0F48 for ; Fri, 8 May 2020 12:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Bihlm9kne0Ab for ; Fri, 8 May 2020 12:50:58 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2127.outbound.protection.outlook.com [40.107.237.127]) (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 5D3DC3A0F06 for ; Fri, 8 May 2020 12:50:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ePGMNVM+iVtftI3y7tQUGZ707q02zLKs9XDSA3vp20HHvWGv2SdcoouCf7+uKTXs1rcUlxR84TTKSwCgt7M6S/cw4A5b1TS3MbtDQbrHt8Mz0gjGQDfIDb2k7dWhms8RCZZjy+rEUeY+40IQddM+1db/wIWDpHiF9ovlesU/cjr9c7C5XF3ivtxfMkrmTGWkpruTXji21YrHHiQCcu2kBi4nxaEtYCiPqmEzr/kFgYkgup+H6qW1AdmcZvRJdwSYm42e3jvKSeviZjmogoLGT2TLeXtKmHYY1DQQGAMvJK/4C+rIwyQvpZApS74OHd+PKE6Mz5r1NAzVqwl5k9tSoA== 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=jCxy8PyDFNRtplShmRara3lpp0pwZqWHUcuRpsyzWDs=; b=GKAQQbG3VTVQQs8TrIpbyX64CSFkn3Kr75SYqlyh/WUADSBlqrFIzforKNGYPySgZsdqkTRXXxSajyPbJWvqTtVoxZt2bl4nKLyG8ZFaXoK5zIFR7rubYchFZVMAxFSuykUuxH1LJAj47M78M9QU6PN4RyA5YTyLr/xCpVSRIc7cIDdSdf/dtbICNlinZ0w4uxGqYX8jfW5NME5GEtOP+kZtn9Dl/59JIXH84XJUnJBwUfzMaGcAkcng4iBLWUBAVrymZXcvxXkBrx0JkTjPVZ3QA/ooAnYjLLOqm+rlgTb69c1JpHafrEtoeuIgFhdqI+yQii9eS6gwa3VDpUAv7w== 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=jCxy8PyDFNRtplShmRara3lpp0pwZqWHUcuRpsyzWDs=; b=F1EUJXKR1niPkNF2L7FF5ToLNGXSa2pNGpr3SaXpwquGljgq+3FKBYUc9kRhztLUumzhF9cGiNiC+vTc3UFqZmiQVB3nht1SPNFNdFaK7BYdSsjqBKNBYqRS83iam8/JT6iGWoO9nVqceinukdBmQv1SUvpT+O/T4dV55kXqHdM= Received: from BY5PR13MB3793.namprd13.prod.outlook.com (2603:10b6:a03:226::15) by BY5PR13MB3285.namprd13.prod.outlook.com (2603:10b6:a03:190::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.16; Fri, 8 May 2020 19:50:49 +0000 Received: from BY5PR13MB3793.namprd13.prod.outlook.com ([fe80::dce5:a4c0:a980:4867]) by BY5PR13MB3793.namprd13.prod.outlook.com ([fe80::dce5:a4c0:a980:4867%9]) with mapi id 15.20.2979.025; Fri, 8 May 2020 19:50:49 +0000 From: Alexander Clemm To: "Eric Voit (evoit)" , Kent Watsen CC: "netconf@ietf.org" Thread-Topic: [netconf] Virtual hum for the question on "https-notif" draft Thread-Index: AQHWF3aZpbslnY0xcka+pz+/87preKiM6hkAgAA3xoCAAAWoAIANOl6AgAKZNwCAAbm1EA== Date: Fri, 8 May 2020 19:50:49 +0000 Message-ID: References: <5CE2095E-7117-4092-B356-A5C4FF490D10@gmail.com> <01000171bc405640-6e173d84-f921-4f6f-929a-6431410051c8-000000@email.amazonses.com> <01000171e7ab5453-7199ade0-ec62-4f6c-837e-5132fb5a4e78-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: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=futurewei.com; x-originating-ip: [73.189.160.186] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bc777505-ae5c-4bfd-f999-08d7f3891b82 x-ms-traffictypediagnostic: BY5PR13MB3285: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 039735BC4E x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: X+V/L5P5m44KVBpx/LxMUUS+sHYLnD1bEuUGdorLZ/4EpnNrQz0Eskb5hhSVJtjfEQ8baKtzBS09Hj3HES7nrOqSOkHK5r0Wv1g7cHRFtaboRT1tvEtb1PUl1oHZ0lV35IJtA6xnYWJ/+dIwo5grHEIueJ4TLOPhobaWti4nI6XQIpK/W0fI7WaTMH5l4NmMNyW23AocKBzS3mdBiwD93L4YsoT0Jtngnfv+CtxwiXKlYetVZXN3G7yFpnCj3mO5C4ZFNR0rscGaDXgoI1bNP3Oc0inD4BQ1KV5gWwaAKgvuuj4vKxzU2qTSrCDQyf918YaXS+iG2xfPDJDuyQ746S/f8DIXQAQ4XZ2o+pzlK8kImF1E2g2TZsTcSfQTvGi6IIezpo4cYhmooISUgZl4vyW5G3BzDGhycE9bE8iRJxxAv9mC7Xu+KGfeKBN2juhOuepqfNpyLRsD80ylNkTCHv3CUhNo/a8HrEI/JDflm8VqM9NeYvufCwcj+6S1MBdwh6gELI4Cjs/x/c2BkVRzjGhueotB8Pa8YAnN24goqYuMGUnRMpWo2bN9oDXhb85ZO7DgC4UMxt4D8/NdtcjkuUqbWQ5eE3pkDi+e8fVSspM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB3793.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(136003)(366004)(396003)(39840400004)(376002)(33430700001)(66556008)(186003)(86362001)(33440700001)(55016002)(7696005)(52536014)(83310400001)(83320400001)(83300400001)(5660300002)(53546011)(6506007)(66946007)(316002)(66476007)(66446008)(76116006)(2906002)(64756008)(4326008)(110136005)(33656002)(26005)(9686003)(8676002)(8936002)(71200400001)(966005)(478600001)(166002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: or//QGtNq5T9rW7cm1VhIcex438rEQZ6u76ozb9hsh974qFrqQilESdZFlv4A36+IBHT9KfllrRwMd+mGUkPbWEiWFgmmwgKztEBS8IJSXDHihKinlcK+nmjmg1pNULqrRnE3SR8Gu57PShhxacBkYGnwEXTA/9Pw0lGAtXUlfCs3gLMtYZrpT1IgRo/2u3++S3UI3ZlRry30r6kCXXfCSB8p86oPybrwy/Qxt/FKSiZ83+HsQcviPQD6vFXnIUbYm4K0x7A57dgt7odUAGBOjCl344tDeVKqIkncyCtqE+NBiH04tLENJPhuCvOGUufhfoon184GkT37HPIQuaBWzLn+6vQOrepxGeEXMqddkbx9aQDiQrAC+YbSu98FkfLCuvVFj47tFiViyhVVM3+iuxs5J+697gtOhDRMKNI/r8PtVOguRo6bL76F3fQ6r/6qRLLc7MP4TVY8PXk8aDOOgyyH8FWSbNFIkbcH9J9nAJ0GXqbiBcVGj8mLLBttcqq x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR13MB37938D3846C6F21BF595CAD1DBA20BY5PR13MB3793namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-Network-Message-Id: bc777505-ae5c-4bfd-f999-08d7f3891b82 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2020 19:50:49.2049 (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: cgQdJZin79HYuIgg1F2z0d1ApdBltJQ1ieV+KEZRcEj6rDExLQJ0AA5Ktdieh+2VY6lyUZbgk49rT52fPY4rxA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3285 Archived-At: Subject: Re: [netconf] Virtual hum for the question on "https-notif" 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: Fri, 08 May 2020 19:51:08 -0000 --_000_BY5PR13MB37938D3846C6F21BF595CAD1DBA20BY5PR13MB3793namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBmaW5lIHdpdGggdGhlIHByb3Bvc2VkIHRleHQgYWxzby4NCi0tLSBBbGV4DQoNCkZyb206 IG5ldGNvbmYgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEVyaWMgVm9p dCAoZXZvaXQpDQpTZW50OiBUaHVyc2RheSwgTWF5IDA3LCAyMDIwIDEwOjI5IEFNDQpUbzogS2Vu dCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0Pg0KQ2M6IG5ldGNvbmZAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbbmV0Y29uZl0gVmlydHVhbCBodW0gZm9yIHRoZSBxdWVzdGlvbiBvbiAiaHR0 cHMtbm90aWYiIGRyYWZ0DQoNCktlbnQgV2F0c2VuLCBNYXkgNSwgMjAyMCA5OjQ4IFBNDQpUaGlz IGVtYWlsIGNsb3NlcyB0aGUgdmlydHVhbCBodW0gb24gdGhlIGZvciB0aGUgcXVlc3Rpb24gb24g dGhlICJodHRwcy1ub3RpZuKAnSBkcmFmdC4NCg0KQXMgcmVwb3J0ZWQgYmVmb3JlLCA3MCUgcGlj a2VkICJMZXQgdGhlIG1hcmtldCBkZWNpZGXigJ0sIHdpdGggdGhlIHJlbWFpbmluZyAzMCUgYWxs IHBpY2tpbmcgIlB1Ymxpc2hlciBNVVNUIGltcGxlbWVudCBKU09OIGVuY29kaW5n4oCdLg0KDQpS b2IgcmFpc2VzIGEgZ29vZCBwb2ludCBhYm91dCB0aGUgbGFuZ3VhZ2UgaW4gUkZDIDg2MzksIGJ1 dCB0aGUgcmVzdWx0cyBvZiB0aGUgcG9sbCByZXZlYWwgYSBjb250cmFkaWN0aW9uLiAgSG93IGNh biB3ZSDigJxsZXQgdGhlIG1hcmtldCBkZWNpZGXigJ0gaWYgYSBkZWZhdWx0IE1VU1QgYmUgcGlj a2VkPw0KDQpUaGUgY2hhaXJzIGFyZSBxdWVzdGlvbmluZyBob3cgdmV0dGVkIHRoYXQgdGV4dCBp biBSRkMgODYzOSBpcywgbm90aW5nIHRoYXQgUkVTVENPTkYgYWxzbyBkb2VzbuKAmXQgcGljayBh IGRlZmF1bHQuICBXZSB3b25kZXIgaWYgdGhlIHRleHQgaW4gUkZDIDg2Mzkgc2hvdWxkIGJlIHNv ZnRlbmVkLiAgRm9yIGluc3RhbmNlOg0KDQogIE9MRDoNCiAgIEEgc3BlY2lmaWNhdGlvbiBmb3Ig YSB0cmFuc3BvcnQgTVVTVCBpZGVudGlmeSBhbnkgZW5jb2RpbmdzIHRoYXQgYXJlDQogICBzdXBw b3J0ZWQuICBJZiBhIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uJ3MgdHJhbnNwb3J0IGFsbG93cyBk aWZmZXJlbnQNCiAgIGVuY29kaW5ncywgdGhlIHNwZWNpZmljYXRpb24gTVVTVCBpZGVudGlmeSB0 aGUgZGVmYXVsdCBlbmNvZGluZy4NCg0KICBORVc6DQogICBBIHNwZWNpZmljYXRpb24gZm9yIGEg dHJhbnNwb3J0IE1VU1QgaWRlbnRpZnkgYW55IGVuY29kaW5ncyB0aGF0IGFyZQ0KICAgc3VwcG9y dGVkLiAgSWYgYSBjb25maWd1cmVkIHN1YnNjcmlwdGlvbidzIHRyYW5zcG9ydCBhbGxvd3MgZGlm ZmVyZW50DQogICBlbmNvZGluZ3MsIHRoZSBzcGVjaWZpY2F0aW9uIE1VU1QgaWRlbnRpZnkgdGhl IGRlZmF1bHQgZW5jb2RpbmcsIG9yDQogICBwcm92aWRlIGEgbWVjaGFuaXNtIHdoZXJlYnkgc3Vw cG9ydGVkIGVuY29kaW5ncyBjYW4gYmUgZGlzY292ZXJlZC4NCg0KQXQgbGVhc3QsIGl0IHNlZW1z IHRoYXQgdGhlIGludGVudCBvZiB0aGUgZHJhZnQgaXMgdG8gaGFuZGxlIHRoZSBjYXNlIGZvciB3 aGVuIHRoZSDigJxlbmNvZGluZ+KAnSBsZWFmIGlzIG5vdCBjb25maWd1cmVkIChzaW5jZSBpdOKA mXMg4oCcbWFuZGF0b3J5IGZhbHNl4oCdKSwgbW9yZSBzbyB0aGFuIGZvcmNlIGludGVyb3BlcmFi aWxpdHksIGJ1dCB0aGVyZSBhcmUgb3RoZXIgd2F5cyB0byBkZXRlcm1pbmUgYW4gZW5jb2Rpbmcg aW4gc3VjaCBjaXJjdW1zdGFuY2VzLCBhbmQgdGh1cyBtYXliZSB0aGUgdGV4dCBpcyBvdmVybHkg cHJvc2NyaXB0aXZlPw0KDQo8ZXJpYz4gSSBoYXZlIG5vIHByb2JsZW0gd2l0aCB0aGUgcHJvcG9z ZWQgdGV4dC4NCg0KRXJpYw0KDQoNCg0KVGhlIE5FVENPTkYgQ2hhaXJzDQoNCg0KDQoNCk9uIEFw ciAyNywgMjAyMCwgYXQgMTE6NDggQU0sIFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNp c2NvLmNvbTxtYWlsdG86cndpbHRvbkBjaXNjby5jb20+PiB3cm90ZToNCg0KQXQgbGVhc3QgdGhl IGh1bSBzZWVtcyB0byBoYXZlIG5hcnJvd2VkIGl0IGRvd24gdG8gdHdvIGNob2ljZXMgKGFzc3Vt aW5nIHN1ZmZpY2llbnQgdm9pY2VzKS4NCg0KQnV0IEkgY2FuIHNlZSBpbnRlcm9wIGJlbmVmaXQg aW4gZGVmaW5pbmcgYXQgbGVhc3Qgb25lIGVuY29kaW5nIHRoYXQgY2xpZW50cyBrbm93IHdpbGwg YmUgc3VwcG9ydGVkIGJ5IHRoZSBzZXJ2ZXIuDQoNCkhlbmNlLCBJIHdvbmRlciBpZiBhbnlvbmUg d291bGRu4oCZdCBiZSBhYmxlIHRvIGxpdmUgd2l0aDoNCg0KICDigJxUaGUgZGVmYXVsdCBlbmNv ZGluZyBpcyBKU09OLiAgUHVibGlzaGVycyBNVVNUIHN1cHBvcnQgSlNPTiBlbmNvZGluZ+KAnQ0K DQoqIG9yIGEgc2xpZ2h0IHZhcmlhbnQgKHRoYXQgSSBkb27igJl0IGxpa2Ugc28gbXVjaCkgd291 bGQgYmUgdG8gc29mdGVuIHRoZSBNVVNUIHRvIGEgU0hPVUxELCB3aXRoIHRoZSBleHBlY3RhdGlv biB0aGF0IHNlcnZlcnMgdGhhdCBkb27igJl0IHN1cHBvcnQgSlNPTiB3b3VsZCByZWplY3QgdGhl IGNvbmZpZ3VyYXRpb24gdW5sZXNzIHRoZSBjbGllbnRzIGhhZCBzcGVjaWZpZWQgYW4gYWx0ZXJu YXRpdmUgc3VwcG9ydGVkIGVuY29kaW5nLg0KDQpSb2INCltBcyBhIGNvbnRyaWJ1dG9yXQ0KDQoN CkZyb206IEtlbnQgV2F0c2VuIDxrZW50K2lldGZAd2F0c2VuLm5ldDxtYWlsdG86a2VudCtpZXRm QHdhdHNlbi5uZXQ+Pg0KU2VudDogMjcgQXByaWwgMjAyMCAxNjoyOA0KVG86IFJvYiBXaWx0b24g KHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbTxtYWlsdG86cndpbHRvbkBjaXNjby5jb20+Pg0K Q2M6IE1haGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzpt amV0aGFuYW5kYW5pQGdtYWlsLmNvbT4+OyBuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25m QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtuZXRjb25mXSBWaXJ0dWFsIGh1bSBmb3IgdGhlIHF1 ZXN0aW9uIG9uICJodHRwcy1ub3RpZiIgZHJhZnQNCg0KDQoNCg0KT24gQXByIDI3LCAyMDIwLCBh dCA4OjA4IEFNLCBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbj00MGNpc2NvLmNvbUBkbWFy Yy5pZXRmLm9yZzxtYWlsdG86cndpbHRvbj00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdy b3RlOg0KDQpbQXMgYW4gaW5kaXZpZHVhbCBjb250cmlidXRvcl0NCg0KQ2hhbmdpbmcgbXkgc3Rh bmNlIHNvbWV3aGF0IGZyb20gdGhlIE5FVENPTkYgbWVldGluZyDigKYNCg0KQWZ0ZXIgbG9va2lu ZyBpbnRvIHRoZSBkZXRhaWxzIGEgYml0IG1vcmUsIHNlY3Rpb24gNyBvZiByZmM4NjM5IHN0YXRl czoNCg0KICAgQSBzcGVjaWZpY2F0aW9uIGZvciBhIHRyYW5zcG9ydCBNVVNUIGlkZW50aWZ5IGFu eSBlbmNvZGluZ3MgdGhhdCBhcmUNCiAgIHN1cHBvcnRlZC4gIElmIGEgY29uZmlndXJlZCBzdWJz Y3JpcHRpb24ncyB0cmFuc3BvcnQgYWxsb3dzIGRpZmZlcmVudA0KICAgZW5jb2RpbmdzLCB0aGUg c3BlY2lmaWNhdGlvbiBNVVNUIGlkZW50aWZ5IHRoZSBkZWZhdWx0IGVuY29kaW5nLg0KDQpEb2Vz IHRoaXMgaW1wbHkgdGhhdCB0aGUgaHR0cC1ub3RpZiBkcmFmdCBlaXRoZXIgbXVzdCBzdGF0ZSBh IGRlZmF1bHQgZW5jb2RpbmcgKG9yIG90aGVyd2lzZSB1cGRhdGUgcmZjODYzOSk/DQoNCkl0IHNl ZW1zIHRoYXQgd2F5Li4uYXQgbGVhc3Qgd2hlbiBodHRwcy1ub3RpZiBpcyBiZWluZyB1c2VkIGZv ciBSRkMgODYzOSAoaXQgZG9lc27igJl0IGhhdmUgdG8gYmUpLg0KDQpMb29raW5nIGF0IHRoZSBo dW0tcmVzdWx0cyBzbyBmYXIsIDcwJSBwaWNrZWQgIkxldCB0aGUgbWFya2V0IGRlY2lkZeKAnSAo d2l0aCB0aGUgcmVtYWluaW5nIDMwJSBhbGwgcGlja2luZyAiUHVibGlzaGVyIE1VU1QgaW1wbGVt ZW50IEpTT04gZW5jb2RpbmfigJ0pLg0KDQpJbiBsaWdodCBvZiB0aGUgUkZDIDg2MzkgdGV4dCBx dW90ZWQgYWJvdmUsIHdlIG1pZ2h0IHF1ZXN0aW9uIHRoZSB2YWxpZGl0eSBvZiB0aGUgaHVt4oCm b3IsIGdpdmVuIHRoZSBzdHJvbmcgcHJlZmVyZW5jZSBmcm9tIHRoZSBodW0sIHdlIG1pZ2h0IHF1 ZXN0aW9uIHRoZSB2YWxpZGl0eSBvZiB0aGF0IGNvbnN0cmFpbnQgaW4gUkZDIDg2MzkuICBJZiBx dWVzdGlvbmluZyBSRkMgODYzOSwgYSBiZXR0ZXIgcXVlc3Rpb24gdG8gYXNrIG1pZ2h0IGJlIHdo eSB0aGUgY29uZmlndXJhYmxlIOKAnGVuY29kaW5n4oCdIGxlYWYgaXNu4oCZdCBtYW5kYXRvcnkg KGFsc28gZWxpbWluYXRpbmcgdGhpcyBpc3N1ZSBhbmQgc2VlbWluZ2x5IGNsZWFuZXIpPw0KDQpJ ZiBzbywgbXkgdGhpbmtpbmcgaXMgdG8gbWFrZSB0aGUgZGVmYXVsdCBlbmNvZGluZyBKU09OLCBi ZWNhdXNlIGl0IGlzIGVhc2llciB0byBnZW5lcmF0ZSB0aGFuIFhNTCwgYW5kIGVhc2llciB0byBj b252ZXJ0IGludG8gQ0JPUi4gIENsaWVudHMgZG9u4oCZdCBoYXZlIHRvIHN1cHBvcnQgSlNPTiBp ZiB0aGV5IGtub3cgdGhhdCB0aGUgcHVibGlzaGVyIHN1cHBvcnRzIGEgZGlmZmVyZW50IGVuY29k aW5nIHRoYXQgdGhleSBkbyBzdXBwb3J0Lg0KDQpJZiB3ZSBoYWQgdG8gcGljayBvbmUsIEpTT04g aXMgbW9yZSBhZ3JlZWFibGUgdGhhbiBYTUwuICBQaWNraW5nIEpTT04gd291bGQgbGlrZWx5IGFs c28gYmUgdGhlIGtpc3Mtb2YtZGVhdGggZm9yIFhNTCwgYXMgb25jZSBzdXBwb3J0IGZvciBKU09O IGhhcyBiZWVuIGNvZGVkLCBpdOKAmXMgdW5saWtlbHkgWE1MIHN1cHBvcnQgd291bGQgYmUgY29k ZWQgKGxpa2UgaG93IFhQYXRoLWZpbHRlcnMgYXJlIHJhcmVseSBpbXBsZW1lbnRlZCBkdWUgdG8g c3VidHJlZS1maWx0ZXJzIGhhdmluZyB0byBpbXBsZW1lbnRlZCkuICBQaWNraW5nIEpTT04gd291 bGQgTk9UIGJlIHRoZSBraXNzLW9mLWRlYXRoIGZvciBDQk9SIChvciBzb21lIG90aGVyIGJpbmFy eSBlbmNvZGluZykgYXMgKmJpbmFyeSogb2ZmZXJzIHJlYWwgdmFsdWUgaW4gc3BhY2UgYW5kIHRp bWUgY29uc3VtcHRpb24uDQoNCg0KS2VudCAvLyBjb250cmlidXRvcg0KDQoNCg0KDQpJ4oCZdmUg YWxzbyBmaWxsZWQgaW4gdGhlIHZpcnR1YWwgaHVtLg0KDQpSZWdhcmRzLA0KUm9iDQoNCg0KDQpG cm9tOiBuZXRjb25mIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmYtYm91 bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBNYWhlc2ggSmV0aGFuYW5kYW5pDQpTZW50OiAy MSBBcHJpbCAyMDIwIDAxOjQ4DQpUbzogTmV0Y29uZiA8bmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86 bmV0Y29uZkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbbmV0Y29uZl0gVmlydHVhbCBodW0gZm9yIHRo ZSBxdWVzdGlvbiBvbiAiaHR0cHMtbm90aWYiIGRyYWZ0DQoNCg0KQXQgdGhlIDEwNyBORVRDT05G IHZpcnR1YWwgbWVldGluZywgdGhlIGF1dGhvcnMgcG9zZWQgdGhlIHF1ZXN0aW9uIG9mIG1hbmRh dG9yeSBlbmNvZGluZyBmb3IgZHJhZnQtaWV0Zi1uZXRjb25mLWh0dHBzLW5vdGlmPGh0dHBzOi8v bmFtMTEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUy RnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZi0w MiZkYXRhPTAyJTdDMDElN0NhbGV4JTQwZnV0dXJld2VpLmNvbSU3QzQ5NjUzNTc0ZWMxODQ1ODkw MmNkMDhkN2YyYWMyZmU3JTdDMGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMlN0MxJTdD MCU3QzYzNzI0NDY5MzY2ODIwODMwMCZzZGF0YT1FMyUyRjhmcGhjb0c2QmtLczJJdCUyQm91V3R1 cVN6eThDbTdjcUJ1ZkVPTmFwRSUzRCZyZXNlcnZlZD0wPiBkcmFmdCB0byB0aGUgV0cuIFRoaXMg dmlydHVhbCBodW0gaW4gdGhlIGZvcm0gb2YgYSBzdXJ2ZXkgaXMgYmVpbmcgcHJlc2VudGVkIHRv IHJlY29yZCB0aGUgcmVzcG9uc2UgZnJvbSB0aGUgV0cuDQoNClBsZWFzZSByZXNwb25kIGJ5IHNl bGVjdGluZyBvbmUgb2YgdGhlIG9wdGlvbnMgaW4gdGhlIHN1cnZleSBwYWdlLg0KDQpodHRwczov L3d3dy5zdXJ2ZXltb25rZXkuY29tL3IvNjhXM0RYMzxodHRwczovL25hbTExLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuc3VydmV5bW9ua2V5 LmNvbSUyRnIlMkY2OFczRFgzJmRhdGE9MDIlN0MwMSU3Q2FsZXglNDBmdXR1cmV3ZWkuY29tJTdD NDk2NTM1NzRlYzE4NDU4OTAyY2QwOGQ3ZjJhYzJmZTclN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNh MWQ1NTkxZmVkYyU3QzElN0MwJTdDNjM3MjQ0NjkzNjY4MjE4Mjk0JnNkYXRhPXBOJTJGMUtaZkJv dUVUZTdGMzJhNWxYa2lDWkxoN1NYdTJNMGVDQkpkZHVDYyUzRCZyZXNlcnZlZD0wPg0KDQpUaGUg cmVsZXZhbnQgc2xpZGUgdGhhdCB3YXMgdXNlZCBmb3IgZGlzY3Vzc2lvbiB3YXMgdGhpcy4gSW4g YWRkaXRpb24gdG8gdGhlIG9wdGlvbnMgZGlzY3Vzc2VkIGhlcmUsIFJvYiBzdWdnZXN0ZWQgdGhh dCB0aGUgV0cgY291bGQgZGVmZXIgdG8gdGhlIG1hcmtldCB0byBkZWNpZGUuDQoNClRoYW5rcw0K DQpNYWhlc2ggJiBLZW50IChhcyBjby1jaGFpcnMpDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KbmV0Y29uZiBtYWlsaW5nIGxpc3QNCm5ldGNvbmZAaWV0 Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmY8aHR0cHM6Ly9uYW0xMS5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxp c3RpbmZvJTJGbmV0Y29uZiZkYXRhPTAyJTdDMDElN0NhbGV4JTQwZnV0dXJld2VpLmNvbSU3QzQ5 NjUzNTc0ZWMxODQ1ODkwMmNkMDhkN2YyYWMyZmU3JTdDMGZlZThmZjJhM2IyNDAxODljNzUzYTFk NTU5MWZlZGMlN0MxJTdDMCU3QzYzNzI0NDY5MzY2ODIxODI5NCZzZGF0YT1oSjVyWEpZMGswakJw aHRpYXBrbVlqZWUyNHRNTkVmTTFJdkhLb1RuWXQwJTNEJnJlc2VydmVkPTA+DQoNCg0K --_000_BY5PR13MB37938D3846C6F21BF595CAD1DBA20BY5PR13MB3793namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVk LXNwYWNlO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIGZpbmUgd2l0aCB0aGUgcHJvcG9zZWQgdGV4dCBhbHNv LiZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLSBBbGV4PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IG5ldGNvbmYgJmx0O25ldGNvbmYt Ym91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mDQo8L2I+RXJpYyBWb2l0IChldm9p dCk8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1heSAwNywgMjAyMCAxMDoyOSBBTTxicj4N CjxiPlRvOjwvYj4gS2VudCBXYXRzZW4gJmx0O2tlbnQmIzQzO2lldGZAd2F0c2VuLm5ldCZndDs8 YnI+DQo8Yj5DYzo8L2I+IG5ldGNvbmZAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtuZXRjb25mXSBWaXJ0dWFsIGh1bSBmb3IgdGhlIHF1ZXN0aW9uIG9uICZxdW90O2h0dHBzLW5v dGlmJnF1b3Q7IGRyYWZ0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPktlbnQgV2F0c2VuLCBNYXkgNSwgMjAyMCA5OjQ4 IFBNPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGVtYWlsIGNsb3Nl cyB0aGUgdmlydHVhbCBodW0gb24gdGhlJm5ic3A7Zm9yIHRoZSBxdWVzdGlvbiBvbiB0aGUgJnF1 b3Q7aHR0cHMtbm90aWbigJ0gZHJhZnQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BcyByZXBvcnRlZCBiZWZvcmUsIDcwJSBwaWNrZWQgJnF1b3Q7TGV0IHRo ZSBtYXJrZXQgZGVjaWRl4oCdLCB3aXRoIHRoZSByZW1haW5pbmcgMzAlIGFsbCBwaWNraW5nICZx dW90O1B1Ymxpc2hlciBNVVNUIGltcGxlbWVudCBKU09OJm5ic3A7ZW5jb2RpbmfigJ0uPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJvYiByYWlz ZXMgYSBnb29kIHBvaW50IGFib3V0IHRoZSBsYW5ndWFnZSBpbiBSRkMgODYzOSwgYnV0IHRoZSBy ZXN1bHRzIG9mIHRoZSBwb2xsIHJldmVhbCBhIGNvbnRyYWRpY3Rpb24uICZuYnNwO0hvdyBjYW4g d2Ug4oCcbGV0IHRoZSBtYXJrZXQgZGVjaWRl4oCdIGlmIGEgZGVmYXVsdCBNVVNUIGJlIHBpY2tl ZD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlIGNoYWlycyBhcmUgcXVlc3Rpb25pbmcgaG93IHZldHRlZCB0aGF0IHRleHQgaW4gUkZDIDg2 MzkgaXMsIG5vdGluZyB0aGF0IFJFU1RDT05GIGFsc28gZG9lc27igJl0IHBpY2sgYSBkZWZhdWx0 LiAmbmJzcDtXZSB3b25kZXIgaWYgdGhlIHRleHQgaW4gUkZDIDg2Mzkgc2hvdWxkIGJlIHNvZnRl bmVkLiAmbmJzcDtGb3IgaW5zdGFuY2U6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7 IE9MRDo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg Jm5ic3A7QSBzcGVjaWZpY2F0aW9uIGZvciBhIHRyYW5zcG9ydCBNVVNUIGlkZW50aWZ5IGFueSBl bmNvZGluZ3MgdGhhdCBhcmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtzdXBwb3J0ZWQuICZuYnNwO0lmIGEgY29uZmlndXJl ZCBzdWJzY3JpcHRpb24ncyB0cmFuc3BvcnQgYWxsb3dzIGRpZmZlcmVudDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2VuY29k aW5ncywgdGhlIHNwZWNpZmljYXRpb24gTVVTVCBpZGVudGlmeSB0aGUgZGVmYXVsdCBlbmNvZGlu Zy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQombmJzcDsgTkVXOjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtBIHNwZWNpZmljYXRpb24gZm9y IGEgdHJhbnNwb3J0IE1VU1QgaWRlbnRpZnkgYW55IGVuY29kaW5ncyB0aGF0IGFyZTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw O3N1cHBvcnRlZC4gJm5ic3A7SWYgYSBjb25maWd1cmVkIHN1YnNjcmlwdGlvbidzIHRyYW5zcG9y dCBhbGxvd3MgZGlmZmVyZW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ZW5jb2RpbmdzLCB0aGUgc3BlY2lmaWNhdGlvbiBN VVNUIGlkZW50aWZ5IHRoZSBkZWZhdWx0IGVuY29kaW5nLCBvcjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZu YnNwOyAmbmJzcDtwcm92aWRlIGEgbWVjaGFuaXNtIHdoZXJlYnkgc3VwcG9ydGVkIGVuY29kaW5n cyBjYW4gYmUgZGlzY292ZXJlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QXQgbGVhc3QsIGl0IHNlZW1zIHRoYXQgdGhlIGludGVudCBvZiB0 aGUgZHJhZnQgaXMgdG8gaGFuZGxlIHRoZSBjYXNlIGZvciB3aGVuIHRoZSDigJxlbmNvZGluZ+KA nSBsZWFmIGlzIG5vdCBjb25maWd1cmVkIChzaW5jZSBpdOKAmXMg4oCcbWFuZGF0b3J5IGZhbHNl 4oCdKSwgbW9yZSBzbyB0aGFuIGZvcmNlIGludGVyb3BlcmFiaWxpdHksIGJ1dCB0aGVyZSBhcmUg b3RoZXIgd2F5cyB0byBkZXRlcm1pbmUgYW4gZW5jb2RpbmcNCiBpbiBzdWNoIGNpcmN1bXN0YW5j ZXMsIGFuZCB0aHVzIG1heWJlIHRoZSB0ZXh0IGlzIG92ZXJseSBwcm9zY3JpcHRpdmU/PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzQ0NzJD NCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiM0NDcyQzQiPiZsdDtlcmljJmd0OyBJIGhhdmUgbm8gcHJvYmxlbSB3 aXRoIHRoZSBwcm9wb3NlZCB0ZXh0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojNDQ3MkM0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzQ0NzJD NCI+RXJpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoZSBORVRDT05GIENoYWlyczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gQXByIDI3LCAy MDIwLCBhdCAxMTo0OCBBTSwgUm9iIFdpbHRvbiAocndpbHRvbikgJmx0OzxhIGhyZWY9Im1haWx0 bzpyd2lsdG9uQGNpc2NvLmNvbSI+cndpbHRvbkBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIj5BdCBsZWFzdCB0aGUgaHVtIHNlZW1zIHRvIGhhdmUgbmFycm93ZWQgaXQgZG93biB0byB0 d28gY2hvaWNlcyAoYXNzdW1pbmcgc3VmZmljaWVudCB2b2ljZXMpLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiI+QnV0IEkgY2FuIHNlZSBpbnRlcm9wIGJlbmVmaXQgaW4gZGVmaW5pbmcgYXQgbGVhc3Qgb25l IGVuY29kaW5nIHRoYXQgY2xpZW50cyBrbm93IHdpbGwgYmUgc3VwcG9ydGVkIGJ5IHRoZSBzZXJ2 ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5IZW5jZSwgSSB3b25kZXIgaWYgYW55b25lIHdvdWxkbuKA mXQgYmUgYWJsZSB0byBsaXZlIHdpdGg6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDsg4oCcVGhl IGRlZmF1bHQgZW5jb2RpbmcgaXMgSlNPTi4mbmJzcDsgUHVibGlzaGVycyBNVVNUIHN1cHBvcnQg SlNPTiBlbmNvZGluZ+KAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+KiBvciBhIHNsaWdodCB2YXJpYW50 ICh0aGF0IEkgZG9u4oCZdCBsaWtlIHNvIG11Y2gpIHdvdWxkIGJlIHRvIHNvZnRlbiB0aGUgTVVT VCB0byBhIFNIT1VMRCwgd2l0aCB0aGUgZXhwZWN0YXRpb24gdGhhdCBzZXJ2ZXJzIHRoYXQgZG9u 4oCZdCBzdXBwb3J0IEpTT04gd291bGQgcmVqZWN0IHRoZSBjb25maWd1cmF0aW9uIHVubGVzcyB0 aGUgY2xpZW50cyBoYWQgc3BlY2lmaWVkIGFuIGFsdGVybmF0aXZlDQogc3VwcG9ydGVkIGVuY29k aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Um9iPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPltBcyBhIGNvbnRyaWJ1dG9yXTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gS2VudCBXYXRzZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpr ZW50JiM0MztpZXRmQHdhdHNlbi5uZXQiPmtlbnQmIzQzO2lldGZAd2F0c2VuLm5ldDwvYT4mZ3Q7 DQo8YnI+DQo8Yj5TZW50OjwvYj4gMjcgQXByaWwgMjAyMCAxNjoyODxicj4NCjxiPlRvOjwvYj4g Um9iIFdpbHRvbiAocndpbHRvbikgJmx0OzxhIGhyZWY9Im1haWx0bzpyd2lsdG9uQGNpc2NvLmNv bSI+cndpbHRvbkBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gTWFoZXNoIEpldGhh bmFuZGFuaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIj5tamV0 aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0 Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0 Y29uZl0gVmlydHVhbCBodW0gZm9yIHRoZSBxdWVzdGlvbiBvbiAmcXVvdDtodHRwcy1ub3RpZiZx dW90OyBkcmFmdDxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1HQiI+ PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPk9uIEFwciAyNywgMjAyMCwgYXQgODowOCBBTSwg Um9iIFdpbHRvbiAocndpbHRvbikgJmx0OzxhIGhyZWY9Im1haWx0bzpyd2lsdG9uPTQwY2lzY28u Y29tQGRtYXJjLmlldGYub3JnIj5yd2lsdG9uPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+W0Fz IGFuIGluZGl2aWR1YWwgY29udHJpYnV0b3JdPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIj5DaGFuZ2luZyBteSBzdGFuY2Ugc29tZXdoYXQgZnJvbSB0aGUg TkVUQ09ORiBtZWV0aW5nIOKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiI+QWZ0ZXIgbG9va2luZyBpbnRvIHRoZSBkZXRhaWxzIGEgYml0IG1vcmUsIHNl Y3Rpb24gNyBvZiByZmM4NjM5IHN0YXRlczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjguMHB0IDguMHB0IDguMHB0IDguMHB0O2JhY2tncm91bmQtcG9z aXRpb246aW5pdGlhbCBpbml0aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3Jv dW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0KPHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgQSBzcGVjaWZpY2F0aW9uIGZvciBhIHRyYW5zcG9y dCBNVVNUIGlkZW50aWZ5IGFueSBlbmNvZGluZ3MgdGhhdCBhcmU8L3NwYW4+PHNwYW4gbGFuZz0i RU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFr LWFsbDtiYWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVh dDppbml0aWFsIGluaXRpYWwiPg0KPHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgc3VwcG9ydGVkLiZuYnNwOyBJZiBhIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9u J3MgdHJhbnNwb3J0IGFsbG93cyBkaWZmZXJlbnQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtiYWNr Z3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFs IGluaXRpYWwiPg0KPHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsgZW5jb2RpbmdzLCB0aGUgc3BlY2lmaWNhdGlvbiBNVVNUIGlkZW50aWZ5IHRoZSBkZWZhdWx0 IGVuY29kaW5nLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5Eb2VzIHRoaXMgaW1wbHkgdGhhdCB0aGUgaHR0 cC1ub3RpZiBkcmFmdCBlaXRoZXIgbXVzdCBzdGF0ZSBhIGRlZmF1bHQgZW5jb2RpbmcgKG9yIG90 aGVyd2lzZSB1cGRhdGUgcmZjODYzOSk/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPkl0IHNlZW1zIHRoYXQgd2F5 Li4uYXQgbGVhc3Qgd2hlbiBodHRwcy1ub3RpZiBpcyBiZWluZyB1c2VkIGZvciBSRkMgODYzOSAo aXQgZG9lc27igJl0IGhhdmUgdG8gYmUpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiI+TG9va2luZyBhdCB0aGUgaHVtLXJlc3VsdHMgc28gZmFyLCA3MCUg cGlja2VkICZxdW90O0xldCB0aGUgbWFya2V0IGRlY2lkZeKAnSAod2l0aCB0aGUgcmVtYWluaW5n IDMwJSBhbGwgcGlja2luZyAmcXVvdDtQdWJsaXNoZXIgTVVTVCBpbXBsZW1lbnQgSlNPTiBlbmNv ZGluZ+KAnSkuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tR0IiPkluIGxpZ2h0IG9mIHRoZSBSRkMg ODYzOSB0ZXh0IHF1b3RlZCBhYm92ZSwgd2UgbWlnaHQgcXVlc3Rpb24gdGhlIHZhbGlkaXR5IG9m IHRoZSBodW3igKZvciwgZ2l2ZW4gdGhlIHN0cm9uZyBwcmVmZXJlbmNlIGZyb20gdGhlIGh1bSwg d2UgbWlnaHQgcXVlc3Rpb24gdGhlIHZhbGlkaXR5IG9mIHRoYXQgY29uc3RyYWludCBpbiBSRkMN CiA4NjM5LiAmbmJzcDtJZiBxdWVzdGlvbmluZyBSRkMgODYzOSwgYSBiZXR0ZXIgcXVlc3Rpb24g dG8gYXNrIG1pZ2h0IGJlIHdoeSB0aGUgY29uZmlndXJhYmxlIOKAnGVuY29kaW5n4oCdIGxlYWYg aXNu4oCZdCBtYW5kYXRvcnkgKGFsc28gZWxpbWluYXRpbmcgdGhpcyBpc3N1ZSBhbmQgc2VlbWlu Z2x5IGNsZWFuZXIpPzxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5J ZiBzbywgbXkgdGhpbmtpbmcgaXMgdG8gbWFrZSB0aGUgZGVmYXVsdCBlbmNvZGluZyBKU09OLCBi ZWNhdXNlIGl0IGlzIGVhc2llciB0byBnZW5lcmF0ZSB0aGFuIFhNTCwgYW5kIGVhc2llciB0byBj b252ZXJ0IGludG8gQ0JPUi4mbmJzcDsgQ2xpZW50cyBkb27igJl0IGhhdmUgdG8gc3VwcG9ydCBK U09OIGlmIHRoZXkga25vdyB0aGF0IHRoZSBwdWJsaXNoZXIgc3VwcG9ydHMgYSBkaWZmZXJlbnQN CiBlbmNvZGluZyB0aGF0IHRoZXkgZG8gc3VwcG9ydC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPklm IHdlIGhhZCB0byBwaWNrIG9uZSwgSlNPTiBpcyBtb3JlIGFncmVlYWJsZSB0aGFuIFhNTC4gJm5i c3A7UGlja2luZyBKU09OIHdvdWxkIGxpa2VseSBhbHNvIGJlIHRoZSBraXNzLW9mLWRlYXRoIGZv ciBYTUwsIGFzIG9uY2Ugc3VwcG9ydCBmb3IgSlNPTiBoYXMgYmVlbiBjb2RlZCwgaXTigJlzIHVu bGlrZWx5IFhNTCBzdXBwb3J0IHdvdWxkIGJlIGNvZGVkIChsaWtlIGhvdyBYUGF0aC1maWx0ZXJz DQogYXJlIHJhcmVseSBpbXBsZW1lbnRlZCBkdWUgdG8gc3VidHJlZS1maWx0ZXJzIGhhdmluZyB0 byBpbXBsZW1lbnRlZCkuICZuYnNwO1BpY2tpbmcgSlNPTiB3b3VsZCBOT1QgYmUgdGhlIGtpc3Mt b2YtZGVhdGggZm9yIENCT1IgKG9yIHNvbWUgb3RoZXIgYmluYXJ5IGVuY29kaW5nKSBhcyAqYmlu YXJ5KiBvZmZlcnMgcmVhbCB2YWx1ZSBpbiBzcGFjZSBhbmQgdGltZSBjb25zdW1wdGlvbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPktlbnQgLy8gY29udHJpYnV0b3I8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUdC Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIj5J4oCZdmUgYWxzbyBmaWxsZWQgaW4gdGhlIHZpcnR1YWwgaHVtLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+UmVnYXJkcyw8YnI+DQpSb2I8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5uZXRjb25mICZsdDs8YSBocmVmPSJt YWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5uZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGI+T24gQmVoYWxmIE9mPHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5NYWhlc2gNCiBKZXRo YW5hbmRhbmk8YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+MjEgQXByaWwgMjAyMCAwMTo0ODxicj4NCjxiPlRvOjwvYj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TmV0Y29uZiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJw bGUiPm5ldGNvbmZAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+W25ldGNvbmZd IFZpcnR1YWwgaHVtIGZvciB0aGUgcXVlc3Rpb24gb24gJnF1b3Q7aHR0cHMtbm90aWYmcXVvdDsg ZHJhZnQ8c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48YnI+DQpBdCB0 aGUgMTA3IE5FVENPTkYgdmlydHVhbCBtZWV0aW5nLCB0aGUgYXV0aG9ycyBwb3NlZCB0aGUgcXVl c3Rpb24gb2YgbWFuZGF0b3J5IGVuY29kaW5nIGZvciZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbmFt MTEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRv b2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtbmV0Y29uZi1odHRwcy1ub3RpZi0wMiZh bXA7ZGF0YT0wMiU3QzAxJTdDYWxleCU0MGZ1dHVyZXdlaS5jb20lN0M0OTY1MzU3NGVjMTg0NTg5 MDJjZDA4ZDdmMmFjMmZlNyU3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1OTFmZWRjJTdDMSU3 QzAlN0M2MzcyNDQ2OTM2NjgyMDgzMDAmYW1wO3NkYXRhPUUzJTJGOGZwaGNvRzZCa0tzMkl0JTJC b3VXdHVxU3p5OENtN2NxQnVmRU9OYXBFJTNEJmFtcDtyZXNlcnZlZD0wIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5kcmFmdC1pZXRmLW5ldGNvbmYtaHR0cHMtbm90aWY8L3NwYW4+PC9hPiZu YnNwO2RyYWZ0DQogdG8gdGhlIFdHLiBUaGlzIHZpcnR1YWwgaHVtIGluIHRoZSBmb3JtIG9mIGEg c3VydmV5IGlzIGJlaW5nIHByZXNlbnRlZCB0byByZWNvcmQgdGhlIHJlc3BvbnNlIGZyb20gdGhl IFdHLjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIj5QbGVhc2UgcmVzcG9uZCBieSBzZWxlY3Rpbmcgb25lIG9mIHRoZSBvcHRpb25z IGluIHRoZSBzdXJ2ZXkgcGFnZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48YSBocmVm PSJodHRwczovL25hbTExLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cHMlM0ElMkYlMkZ3d3cuc3VydmV5bW9ua2V5LmNvbSUyRnIlMkY2OFczRFgzJmFtcDtkYXRhPTAy JTdDMDElN0NhbGV4JTQwZnV0dXJld2VpLmNvbSU3QzQ5NjUzNTc0ZWMxODQ1ODkwMmNkMDhkN2Yy YWMyZmU3JTdDMGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMlN0MxJTdDMCU3QzYzNzI0 NDY5MzY2ODIxODI5NCZhbXA7c2RhdGE9cE4lMkYxS1pmQm91RVRlN0YzMmE1bFhraUNaTGg3U1h1 Mk0wZUNCSmRkdUNjJTNEJmFtcDtyZXNlcnZlZD0wIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5odHRwczovL3d3dy5zdXJ2ZXltb25rZXkuY29tL3IvNjhXM0RYMzwvc3Bhbj48L2E+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPlRoZSByZWxldmFudCBzbGlkZSB0aGF0IHdhcyB1c2Vk IGZvciBkaXNjdXNzaW9uIHdhcyB0aGlzLiBJbiBhZGRpdGlvbiB0byB0aGUgb3B0aW9ucyBkaXNj dXNzZWQgaGVyZSwgUm9iIHN1Z2dlc3RlZCB0aGF0IHRoZSBXRyBjb3VsZCBkZWZlciB0byB0aGUg bWFya2V0IHRvIGRlY2lkZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+TWFoZXNoICZhbXA7IEtl bnQgKGFzIGNvLWNoYWlycyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCm5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxzcGFuIGxh bmc9IkVOLUdCIj48YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6cHVycGxlIj5uZXRjb25mQGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4t R0IiPjxhIGhyZWY9Imh0dHBzOi8vbmFtMTEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j b20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUy Rm5ldGNvbmYmYW1wO2RhdGE9MDIlN0MwMSU3Q2FsZXglNDBmdXR1cmV3ZWkuY29tJTdDNDk2NTM1 NzRlYzE4NDU4OTAyY2QwOGQ3ZjJhYzJmZTclN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkx ZmVkYyU3QzElN0MwJTdDNjM3MjQ0NjkzNjY4MjE4Mjk0JmFtcDtzZGF0YT1oSjVyWEpZMGswakJw aHRpYXBrbVlqZWUyNHRNTkVmTTFJdkhLb1RuWXQwJTNEJmFtcDtyZXNlcnZlZD0wIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0Y29uZjwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_BY5PR13MB37938D3846C6F21BF595CAD1DBA20BY5PR13MB3793namp_-- From nobody Fri May 8 14:18:13 2020 Return-Path: <01000171f6271301-69bb22bd-aede-4256-bcce-2ac425acf523-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 9A22E3A0F33 for ; Fri, 8 May 2020 14:18:11 -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_MSPIKE_H2=-0.001, 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 0yUw4B7Cna_8 for ; Fri, 8 May 2020 14:18:09 -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 9D5EF3A0F31 for ; Fri, 8 May 2020 14:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1588972688; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=+WchjLbaoaI9l+Ol1i7ySM+EEqcxCCXKjG34OgB9b30=; b=ZWYaUDCnsA1Vb3SIdJTaoa1M+keyCIL/XPYZKfTH0wc0ZiEPXEYuIV3bOjlAQsHT PAnTo5PS4H7dsM5ZAjBabOnFOOqOIyPIBwovLt8aHtpWyTgrdRXN2hxnCd/sc/OL1Zq hl3z2G2qzc4gh/s6CV4NG0m3b9RnKHtn7RBjO9SQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Kent Watsen In-Reply-To: Date: Fri, 8 May 2020 21:18:08 +0000 Cc: "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <01000171f6271301-69bb22bd-aede-4256-bcce-2ac425acf523-000000@email.amazonses.com> References: To: Mahesh Jethanandani X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.05.08-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Virtual hum on the question of keygen 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, 08 May 2020 21:18:12 -0000 > On May 8, 2020, at 3:25 PM, Mahesh Jethanandani = wrote: >=20 > [Sorry if this e-mail appears multiple times. I seem to be having = issues with Google's SMTP server] >=20 > This e-mail closes the virtual hum on the question of keygen as it = relates to draft-ietf-netconf-crypto-types. >=20 > The poll was a weighed average poll, with folks asked to order their = preferences.. The overall results of the poll did not indicate a clear = consensus. The tie was between keeping keygen and support at SSH/TLS = layer, and not supporting keygen at this time, with the latter having a = slight preference. What was interesting about the poll was an = overwhelming support for not supporting keygen at this time as the first = preference, with the 2nd option more evenly weighed between first and = second preference. >=20 > As explained before not supporting keygen at this time does not = preclude it from being added later on. The WG has indicated a desire to = get this work done soon, which may be why the 3rd option may be carrying = more support. > =20 > At this point with no clear consensus, I am going to make it authors = decision. As author, primarily interested in reducing my = personal/self-funded/ongoing involvement in this sprawling effort, and = partially believing that others (upon realizing the important keygen) = will pick it and (upon attracting greater buy-in/involvement from key = stakeholders than I've been able to manage) produce a better and more = meaningful result, I therefore choose to proceed with Option 3 (i.e., to = NOT support keygen at this time). Kent // as author > Thanks. >=20 > Mahesh Jethanandani (as co-chair) > mjethanandani@gmail.com > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Sat May 9 00:37:12 2020 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 A7E6B3A08AF for ; Sat, 9 May 2020 00:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 mUe3NAxXvXXJ for ; Sat, 9 May 2020 00:37:07 -0700 (PDT) Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) (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 149C93A07FD for ; Sat, 9 May 2020 00:37:06 -0700 (PDT) Received: by mail-lf1-x143.google.com with SMTP id s9so3254133lfp.1 for ; Sat, 09 May 2020 00:37:06 -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:content-transfer-encoding; bh=aUUjFDkvW7duXuxjZLVYZblk97DkB8mVu/WwyOIMUiw=; b=Olor7sny3B3HPXXyZ2NGENjOENKBrIKw6YWNmDbGkqCHvrIGkMtp/zl4qdFZd1CTTJ GkoIIe41EfFc3En32z2Qeb6DwXRYaKuZNLmFGJKJN5y42wdDn9htPIKCTthbMhYnqyK0 f+B/0FP0u2Q8wIKHT87IszT6zJR9Qk0xsz27fFKzh6Ox6D0gMg/5dDFa7F4b9xiIaxCn Ws3Dlff+mWGqJ9pDz5iKPktav9MJOyPkewAHufJtuSZw1Xtq9a1e8Icc9BHUT2hRENGq zGl2imi32VKB66gBpXwFOU9txw9FsznFX38vSpn66hWQbOVKEPoReFUKRTS4w7vnIWTY Nn4Q== 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:content-transfer-encoding; bh=aUUjFDkvW7duXuxjZLVYZblk97DkB8mVu/WwyOIMUiw=; b=QjLd4zn/xtv1j5WbmVz1W82sEmG0Xd4icAjjOZtXcX/vVsxbTEhY7zGu0pWTxPIo8f cMNIfNWdnGOOSqlK7AryQoojcgGkcFe9LCTyq2HoKgosVP7yq58h7jScN3EqoKye0nRl rbJwqUvEnVKcdOGxQAoNvyoGj/Sct/jOvKEFlp6xYDjlD/5zl6gjHa2VxtFnDirrFhEf tBsJPb2u8+GqwyExEcod6mRLdiySeX9bENRooyrVLkGOUsFqcBmFuo4ilwbffS7KQwkh Uk/itfqZbZQNSt1FrMgFmuwRWGkWaYME/QNRm3gtJBfqA7smFX23yea5lJQtdo/d7Us1 WHJQ== X-Gm-Message-State: AOAM533kmziEUG8DY2RHoWMsWayvhubW8zpxXuwFhGq63wMeBtziOzdW Gyi87UPhKxJsRRSEG8pySLTRRr9WMi2xfaS6TdQ= X-Google-Smtp-Source: ABdhPJw6gQWrZ7dvFNMH72KgjwxR4MZFZGL+3Epz9NiU4ga3JCXZoEpSZ0NMpNfomx1F2ySh25u0bOwaY+A2hS+WYzI= X-Received: by 2002:a19:cc92:: with SMTP id c140mr4331213lfg.34.1589009825112; Sat, 09 May 2020 00:37:05 -0700 (PDT) MIME-Version: 1.0 References: <20200414.222236.518728457229433184.id@4668.se> <9C6D0A8A-2BD4-4578-8CB3-6969078CE10A@gmail.com> <20BA9136-0FC6-4CAC-BF59-89FC16DB583E@gmail.com> <01000171f59ea8ae-a7319ea3-12ca-4857-9b43-3f89ef6ec35c-000000@email.amazonses.com> In-Reply-To: <01000171f59ea8ae-a7319ea3-12ca-4857-9b43-3f89ef6ec35c-000000@email.amazonses.com> From: Henning Rogge Date: Sat, 9 May 2020 09:36:38 +0200 Message-ID: To: Kent Watsen Cc: Mahesh Jethanandani , "netconf@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] Trouble with RFC 8040 (Restconf) fields Query Parameter 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, 09 May 2020 07:37:10 -0000 On Fri, May 8, 2020 at 8:49 PM Kent Watsen wrote: > This is likely an errata in just the ABNF. > > Supporting this view, note that fields=3Dgenre;year =3D=3D fields=3Dyear;= genre (i.e., order doesn't matter) Good to know... does it make sense to transform this (and maybe the example error) into a formal errata? > > The implementation in ODL does not care what order the query is placed = in. Even if the bracket part of the query is placed in the last field, when= it builds up the hash index for the search, the bracketed parts can appear= anywhere based on how it gets hashed. > > A reasonable application of Postel's principle. Henning Rogge From nobody Tue May 12 03:58:31 2020 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 3BD4C3A0D7B for ; Tue, 12 May 2020 03:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 huMBEk8v9J0j for ; Tue, 12 May 2020 03:58:27 -0700 (PDT) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (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 956F83A0D7A for ; Tue, 12 May 2020 03:58:27 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id w10so2371454ljo.0 for ; Tue, 12 May 2020 03:58:27 -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:content-transfer-encoding; bh=j6g3DwBdKvtDmHVRT6IutC3XDvR3WJiusKq7SMnkps8=; b=JHv/Y1O4a6lRadZQs7y8t8UKlhUfBdK1Hf09nM0fYhIbCgZTE2noftg7FxIXs75tpY 3cZHxeyYI9EqwwEhsCpXWP6TDcEGnnvt4ypxs6OCio0nE7BMl+bImPTxzM7OG7dNVmyi rvdsG+XdWeUlVueF5XKepb46JRGMW+xqonHFyQLJ60gESDa/BB0IUFMQjPuh0cXqHe5+ b620PtjUVV3VFlTHnWsQmxFCMRmyEGPbGE0dqZJvjyiHJjLznlutrcfZpN1CoZVE5sFN f2Rj0eGejzOuZxeBeRqQd3wssxu0yYz6YujsHlI/lZcc7X6lPMynCAs9CVhQ2hlDbTjE GonA== 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:content-transfer-encoding; bh=j6g3DwBdKvtDmHVRT6IutC3XDvR3WJiusKq7SMnkps8=; b=AJjkxSehGCtFioypAvw/OfAIkNJDFQvTezZE98krLndKpudB8Uo8RfpbhrZ8GSSGn+ /bHN6Si+OcFNL4af7OB9epNatCNYTrCV5CnuJCxbzFjEgsic1W+cXRkImUJcoLLcqY3B Hu/NcPzamLfOgihuDBrxeFWi7PC0aCDqp2HiXwP4MGiuqWiBwh+1h5M1HEeKapqyBTiQ IEW4uUyR0oVY/IEJGF7xe5TLoS+rkyao6xmCbCAM4AKwF4QkjfmSgHjGl1UgK74xi+nR 3S7PIswvaCPR+P78kThL96AdzpccZjzr5NnDm3U//ZMYJv/vTgiYo0U58IPZAjPsTDB/ Z26A== X-Gm-Message-State: AOAM533reytBIGtBcP+zwK/Sx/9YZtbRerUTyHpynNkO6+iWr37MIdQs GkcBTlhdEQqtGKuYWQMCkE44FbfjeeF3N8fcaDw= X-Google-Smtp-Source: ABdhPJwdidUp2NXaViR+CoCw7E2gbYJ62aQf969APZNO526LKI2LzWIpQdJwzI8UgcDbUAWuzdqtIWY0moWt4jZXAv4= X-Received: by 2002:a2e:9cc1:: with SMTP id g1mr13476636ljj.261.1589281105550; Tue, 12 May 2020 03:58:25 -0700 (PDT) MIME-Version: 1.0 References: <20200414.222236.518728457229433184.id@4668.se> <9C6D0A8A-2BD4-4578-8CB3-6969078CE10A@gmail.com> <20BA9136-0FC6-4CAC-BF59-89FC16DB583E@gmail.com> <01000171f59ea8ae-a7319ea3-12ca-4857-9b43-3f89ef6ec35c-000000@email.amazonses.com> In-Reply-To: From: Henning Rogge Date: Tue, 12 May 2020 12:57:59 +0200 Message-ID: To: Kent Watsen Cc: Mahesh Jethanandani , "netconf@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netconf] Trouble with RFC 8040 (Restconf) fields Query Parameter 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, 12 May 2020 10:58:29 -0000 Hi, hopefully last question about the field operator. I finally managed to switch me datamodel to a "unified model" that includes everything beginning from the "/restconf" path. I noticed the following parts: * "fields" and "depth" query can be combined * "depth" default is unlimited * "fields" can be done on the "/restconf/data" level * a query to "/restconf/data" does NOT result in unlimited depth... does this mean "depth" is always 2 for /restconf/data queries (but not on sub-paths)? what is about a GET to "/restconf" ? is the "depth" default still 2 for "/restconf/data" if there is a "field" query operator? Henning On Sat, May 9, 2020 at 9:36 AM Henning Rogge wrote: > > On Fri, May 8, 2020 at 8:49 PM Kent Watsen wrote: > > This is likely an errata in just the ABNF. > > > > Supporting this view, note that fields=3Dgenre;year =3D=3D fields=3Dyea= r;genre (i.e., order doesn't matter) > > Good to know... does it make sense to transform this (and maybe the > example error) into a formal errata? > > > > The implementation in ODL does not care what order the query is place= d in. Even if the bracket part of the query is placed in the last field, wh= en it builds up the hash index for the search, the bracketed parts can appe= ar anywhere based on how it gets hashed. > > > > A reasonable application of Postel's principle. > > Henning Rogge From nobody Tue May 12 04:47:04 2020 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 7D1713A003B for ; Tue, 12 May 2020 04:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=TfM0vqHE; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=GZ6Jy9pO 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 MkbREnOcLKkv for ; Tue, 12 May 2020 04:47:00 -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 717D53A003C for ; Tue, 12 May 2020 04:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1389; q=dns/txt; s=iport; t=1589284020; x=1590493620; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=g93QlipyUhFPucbBXkcfxrsR4TGScEoJ76WeLayOXYY=; b=TfM0vqHEB5nHV2nrqISb6jv81BX/A4LvSl+wg5eLlHCS9cXBXA5ECRaH wYJHad5KVRAWKHUvuGPKuShNTWeJJhkQ8+0efBJWVsrNlF1Vs9puSGmDQ TvUA4yatw9ApTBPhz/z4rU2i/Yy07jFfcvD3ioqUY68Dav13QiGj5E8wa 0=; IronPort-PHdr: =?us-ascii?q?9a23=3A0KGQhBLFP3iDYHs+eNmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvKk/g1rAXIGd4PVB2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YkdQEcf6IVbVpy764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D?= =?us-ascii?q?=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CHBQDgi7pe/4MNJK1mHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUeBVFEFgUcvLIdqA41DiXqOPYJSA1QLAQEBDAEBLQIEAQG?= =?us-ascii?q?ERAKCBSQ4EwIDAQELAQEFAQEBAgEFBG2FVgyFcgEBAQIBEi4BATcBBAsCAQg?= =?us-ascii?q?OOCERJQIEAQ0FCBqFUAMOIAGkXgKBOYhhdIE0gwEBAQWFNg0Lgg4JgTiCY4l?= =?us-ascii?q?hGoFBP4FUgk0+gQSBGoIwAoNFgi2ZGpkLSgqCSpNWhG+dOpAdjCGRCQIEAgQ?= =?us-ascii?q?FAg4BAQWBaSKBVnAVgyRQGA2QQINyilZ0NwIGCAEBAwl8jgcBAQ?= X-IronPort-AV: E=Sophos;i="5.73,383,1583193600"; d="scan'208";a="757604022" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 May 2020 11:46:59 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 04CBkwW0022117 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 May 2020 11:46:59 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 12 May 2020 06:46:58 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 12 May 2020 06:46:57 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 12 May 2020 07:46:57 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=M/c5sSqsGmtyOZ6a8SLNaRkhV5pFQhXK6/n8SgHr93QTjJv4JqKc5ey1uh9MsJk4shqAfTEoV0frvaqbkTsfhgOPp2UEi0yz5tkiNH9rCqznZdRCZr4gJWL9dMdoSBtYA1/spPZaeQIOInukUE4zfNmS1ZSIRa81uxUNZZqms/jDIyL19Xfy/o/9lzFwgOxrKKc9pE7XPAjM9Z37V2TdMEqks13zetT8Sr2hBSLgGUslHhIrQkIgFIjZ4dmjXSWGKhsJ5E68egQ/pLZAm0cuKgsfyKjPJh6frCGE5bjUTxFwRHyqEQ9lx0TMyRKz+odxgp4z2/hztfvtf5oyu6+6DA== 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=RvIdU76ceVCXSeNmOVp7uBfm2xRa39an5kuh2oyUA7I=; b=AD/GcUXHHjoii/CZ6Cv30wTZ1UQwmZKcq5j3EP4hSqMQ05gNp0+KDd/uwKg7rgGlGnCySgVCJq0hcRRV3ftvGwebXShwlvfdWUkWVadekhjtsEYPZkUjt/RKPw4y0OTlmyt7Z9IHw/q28xKBQxg4I6GdPLneE27IrwPDPXs5l8SWtig9qG3Bj0WOUQ51Jfqxb3KWHbv9IUJXgMv1M+MUv/opyDUbiAbxIqanaod4ceiwsD+Q3mGnsWkelGLjYrUT47619pfdYfGuvwa0db96qLZLQmXB7pFhsbXfNyg2uoRSTCNrNxxwtCOL0An5bdLiG0WxAXTT3hJpSUFxSjok2g== 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=RvIdU76ceVCXSeNmOVp7uBfm2xRa39an5kuh2oyUA7I=; b=GZ6Jy9pOMc6kWsHOf3UBoiXGajU0uaBqU4B7rG91RHJjmlNEamlVmFWT0X3H6/YqS40m0iRhR65NeSFR/S1abNJDsGRXnlbaXe8pru97Q5LE8V77nvTOIPaB2BzameUrYW963OJMW/7cee3Ac9fxZrs42Yqsc2LGvCEo1k1sYRI= Received: from DM6PR11MB3818.namprd11.prod.outlook.com (2603:10b6:5:145::22) by DM6PR11MB4532.namprd11.prod.outlook.com (2603:10b6:5:2aa::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.34; Tue, 12 May 2020 11:46:56 +0000 Received: from DM6PR11MB3818.namprd11.prod.outlook.com ([fe80::597c:ff4:6845:c945]) by DM6PR11MB3818.namprd11.prod.outlook.com ([fe80::597c:ff4:6845:c945%3]) with mapi id 15.20.2979.033; Tue, 12 May 2020 11:46:56 +0000 From: "Per Andersson (perander)" To: Henning Rogge , Kent Watsen CC: "netconf@ietf.org" Thread-Topic: [netconf] Trouble with RFC 8040 (Restconf) fields Query Parameter Thread-Index: AQHWCOkLjYi46hri8EmuiXSe2Ms4zah0dzQAgASr2QCACMyVgIAbXBoAgACSxACAANbHgIAAC5wAgADWcACABO9AgIAACAQ8 Date: Tue, 12 May 2020 11:46:56 +0000 Message-ID: References: <20200414.222236.518728457229433184.id@4668.se> <9C6D0A8A-2BD4-4578-8CB3-6969078CE10A@gmail.com> <20BA9136-0FC6-4CAC-BF59-89FC16DB583E@gmail.com> <01000171f59ea8ae-a7319ea3-12ca-4857-9b43-3f89ef6ec35c-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: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c0:1004::3a8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 511d06f7-cbec-4234-bdb5-08d7f66a2c37 x-ms-traffictypediagnostic: DM6PR11MB4532: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0401647B7F x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kmXO7KAa0nqbDh7Q8MIk1S3rHxV62yrhW73fFG05ZLZyl6V4juWoSSM04ON21NQ46+OA06kWGytWPUBb1IMwqXnLofM8eLxMFx34OesmDBMhDc9vYICJUMG9pjgPOr6bUqqg6Fi9uozyEuaLgL98YVOyuF4Xr15YFBTmU3Me0VULVorvCa8kzNhZ2KFN5TBSSFmIS9knMSAxwckkdWqqS4sZQZr+lVDOrnnXQonoUg7h1j0i+ttONUVOXwDPDrQR6izhtzklR7Y+qLcc+u8vK3ELHgZtwKL4o9NV8i6PNR5fEAlqPU8AlkoLxgcbq/eVWPrVpD0P3/ly1Dz2lf+VgCf60HTJaBn5xbe5slE46WBTs1OAEUroZOv3GhI4awHMeLq3XxIkI+6gGzgMSHmE14QLhePCuoASunRgmWSG2KH+Tj2VmqK+gAcU63Elv8sqnv9JpEkqbdE4YG7Vkbo823ZfdTjNF3Dyz9VtAMumq12VkVA5ifx3sxkFmAhmwSdmhby8dJA1bKZKoqRU+GEC4w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3818.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(39860400002)(396003)(136003)(366004)(33430700001)(316002)(8936002)(86362001)(4326008)(6506007)(91956017)(66946007)(8676002)(64756008)(66556008)(66476007)(66446008)(76116006)(478600001)(186003)(33656002)(33440700001)(52536014)(2906002)(71200400001)(5660300002)(7696005)(9686003)(110136005)(55016002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: DDHG/Y7SD7XMqE8hvuSzQS4+vn0YNWsgcxIEg//tC+z6f0G0y8alv+CFXwbhViEvGia1jD6ifsOcitsE9qNTRVjAp126aJWIaN5Ru/wNzjgdWVKS/SWEnCCFCIPNJltGhfLjJvxA+l5qP+Kki8zWKPvLj/Mt+5OTOfWHkFM7NOBH3bAUXZEeGsFGSWNxMXN0DuXYaozrDjQ0fhUhV5ZQqpY2g53a6fHzBY3hWQMlQPDmTxe2rLQAKr4FbjSWsAZ4kDJ7JT/ifq97DtlyUrT9877HahdPEKP33dzIplB0DZQVVH/YB32FoKe8GFu3z47XbIzokkgqxO6u89bOujFxqgsnpLZLnJG1qroTobVvocC/VHYXk4sSotWWzggDnlbpCExlQpw2iXJAb1dWqrw/AP5ZeHega6qujWENiejXxTNlGbryvvFwJW49AeA1A2pl+Jotia9gjhPifOAiJLrBH6WlvC0NTyoKK6Ny+gazIrp4cwGJ/TDBzHoiF+E3x1aC0QixXuWZNbIK4mbVs+4t+A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 511d06f7-cbec-4234-bdb5-08d7f66a2c37 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2020 11:46:56.3772 (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: QszYQkDF0BcxFDRLXXb/WG54SxhZ61fiQYV1kB+iF5V4qQn2zWvvB/WXd+n61JzSzyCMqjUN6rKRib3FxPGOSA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4532 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [netconf] Trouble with RFC 8040 (Restconf) fields Query Parameter 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, 12 May 2020 11:47:02 -0000 Henning Rogge on Tuesday, May 12, 2020 12:57:=0A= > I noticed the following parts:=0A= > * "fields" and "depth" query can be combined=0A= > * "depth" default is unlimited=0A= > * "fields" can be done on the "/restconf/data" level=0A= > * a query to "/restconf/data" does NOT result in unlimited depth...=0A= =0A= The depth default would still be unbounded if not set explicitly.=0A= =0A= =0A= > does this mean "depth" is always 2 for /restconf/data queries (but not=0A= > on sub-paths)?=0A= > what is about a GET to "/restconf" ?=0A= =0A= >From RFC 8040=0A= =0A= The requested data node has a depth level of "1".=0A= =0A= So, a request towards /restconf/data would yield depth level 1=0A= on /restconf/data, /restconf/data/node would be depth level 2,=0A= and so on.=0A= =0A= If the request would be towards /restconf/data/node instead,=0A= /restconf/data/node would be depth level 1.=0A= =0A= =0A= > is the "depth" default still 2 for "/restconf/data" if there is a=0A= > "field" query operator?=0A= =0A= If depth and fields are combined, nodes that would be selected=0A= in fields (and all ancestor nodes) would have a depth value of 1.=0A= I.e. the path to the selected node is included even if depth is=0A= lower than the nodes included in fields. Otherwise the depth=0A= query parameter is obeyed.=0A= =0A= =0A= --=0A= Per= From nobody Tue May 12 05:16:02 2020 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 31D6E3A07D5 for ; Tue, 12 May 2020 05:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 SPzSO_fXv-kG for ; Tue, 12 May 2020 05:16:01 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 C7D053A07C3 for ; Tue, 12 May 2020 05:16:00 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id h26so10364216lfg.6 for ; Tue, 12 May 2020 05:16:00 -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=GuoqOa4edJMSy9MBUJ1b7HWmyOJoPMptxXpJXxjhluM=; b=k3nB573Z8j804eqwW+0KSah3IKse5ucfIQ3BGmwXA8Y7UAJegYAZ/ORvHQQXFRqfJ8 z/rjtwUhswfj6N5mEycYavYT1r6SfAJpB9QnsvuiINeBwUpbtnumMs1L7024bAPhcgVA QUezGrwIek1HBQj5b41I7l8KUVIjtdhKGCO9bwlWON2NUrS5JypvqpikRfJOMNg1TF6L VGYFGWaOeGYeT7Hr86+d8VM24WrK8V9zfOqu163OCZSYWBAqL+EkNhW8018anBzSHfTB Jgv9UECZqwlcF4XqnkT7A7sXluhRJsX44KEGON/7k/jLKbc4/LETBEMWlTTJC7e8F7aX V8UQ== 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=GuoqOa4edJMSy9MBUJ1b7HWmyOJoPMptxXpJXxjhluM=; b=KcDcXbuZ0LBcO9vHZyrbN6aNpZnEa05OFgOaTNFuAZJQ/gBURwbLetKh9NFkazwOQV O2sIKbQB2qrDuxIgYH6xOYG3lZDD8Wv9B+yjDaOGPWHkD9kMeQnMi61r2Lld7K6+abOT BsOgTPCBbH6g5vQb9BCF7ysLv1iwVUwHzG4JwUE8uqM/znsJnWdpAIa8JeM+SGsXYe3k ao5jQY/Dw1orLdWyFg2JKvWoe6tqM0qjPXFr2M4ZalapdaRmpoPZB3qeWEg8BccHwN19 GmocJFNBbkz2l2eUTNfosqJIFajdrVCKGmsD9ohYfnOqQcqn900hZRL2g/iVqlylFlkY HkGw== X-Gm-Message-State: AOAM531AXyBvy7dcPG8BKi6aCee+a0sRnTV+H4IF0VbD/QigE5QAJHag cNe/fv5UqCRmd9MzsEq1fGNU/uA2dMJqEtHwnlM= X-Google-Smtp-Source: ABdhPJzUWQLi196U/PT/kiP5h7n2BWebPs51+SZkwuxLDRNsSIa7Rt1Ed9HiXE7M7jaomB0AgdAGi1HA4KKcr0+D+9g= X-Received: by 2002:a19:8d3:: with SMTP id 202mr14353061lfi.201.1589285758716; Tue, 12 May 2020 05:15:58 -0700 (PDT) MIME-Version: 1.0 References: <20200414.222236.518728457229433184.id@4668.se> <9C6D0A8A-2BD4-4578-8CB3-6969078CE10A@gmail.com> <20BA9136-0FC6-4CAC-BF59-89FC16DB583E@gmail.com> <01000171f59ea8ae-a7319ea3-12ca-4857-9b43-3f89ef6ec35c-000000@email.amazonses.com> In-Reply-To: From: Henning Rogge Date: Tue, 12 May 2020 14:15:32 +0200 Message-ID: To: "Per Andersson (perander)" Cc: Kent Watsen , "netconf@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [netconf] Trouble with RFC 8040 (Restconf) fields Query Parameter 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, 12 May 2020 12:16:02 -0000 On Tue, May 12, 2020 at 1:46 PM Per Andersson (perander) wrote: > > Henning Rogge on Tuesday, May 12, 2020 12:57: > > I noticed the following parts: > > * "fields" and "depth" query can be combined > > * "depth" default is unlimited > > * "fields" can be done on the "/restconf/data" level > > * a query to "/restconf/data" does NOT result in unlimited depth... > > The depth default would still be unbounded if not set explicitly. the second/third in Example B.1.2 suggest otherwise... Client request something from "/restconf" and only gets a tree "1 deep" (node itself plus direct children), which would be an equivalent of "?depth=2"... > > does this mean "depth" is always 2 for /restconf/data queries (but not > > on sub-paths)? > > what is about a GET to "/restconf" ? > > From RFC 8040 > > The requested data node has a depth level of "1". > > So, a request towards /restconf/data would yield depth level 1 > on /restconf/data, /restconf/data/node would be depth level 2, > and so on. Yes... "?depth=2" gives you the node itself and the direct children. > If the request would be towards /restconf/data/node instead, > /restconf/data/node would be depth level 1. > > > is the "depth" default still 2 for "/restconf/data" if there is a > > "field" query operator? > > If depth and fields are combined, nodes that would be selected > in fields (and all ancestor nodes) would have a depth value of 1. > I.e. the path to the selected node is included even if depth is > lower than the nodes included in fields. Otherwise the depth > query parameter is obeyed. Does the counting just begin when the explicit selected fields end or does it directly jump to the depth measured from the root node? Henning Rogge From nobody Tue May 12 12:53:25 2020 Return-Path: <010001720a72cd87-57dc4f05-1079-470c-b1eb-d84e548c7ca6-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 E51C43A0AAD for ; Tue, 12 May 2020 12:53:17 -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_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 FRkjl8EuV348 for ; Tue, 12 May 2020 12:53:16 -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 ABBFD3A0A8D for ; Tue, 12 May 2020 12:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1589313195; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=Cg9XRKhDAtIrANo9BgMG/GqQl665j4R2Fr9hyrbC1LY=; b=KBHBQCvGzQkhvdEBs90x76Io/LVu4mYeznR3bLw6Hdi+ri+Cw3lkqwQauTAjWHke qmD+9BFmf7PrOZQRvD4Ke9Xzohl2E3J784ORUSYlBlzQLQTgXfkTOoOn6VLYtMGTE4+ ahiYAma3UjULaaijoSlE3VFkwQ6mPtK4eykv+RRU= From: Kent Watsen Message-ID: <010001720a72cd87-57dc4f05-1079-470c-b1eb-d84e548c7ca6-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9A6B9930-F07C-4630-B977-5634977014E9" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 12 May 2020 19:53:15 +0000 In-Reply-To: Cc: "Per Andersson (perander)" , "netconf@ietf.org" To: Henning Rogge References: <20200414.222236.518728457229433184.id@4668.se> <9C6D0A8A-2BD4-4578-8CB3-6969078CE10A@gmail.com> <20BA9136-0FC6-4CAC-BF59-89FC16DB583E@gmail.com> <01000171f59ea8ae-a7319ea3-12ca-4857-9b43-3f89ef6ec35c-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.05.12-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Trouble with RFC 8040 (Restconf) fields Query Parameter 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, 12 May 2020 19:53:23 -0000 --Apple-Mail=_9A6B9930-F07C-4630-B977-5634977014E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Henning, > Does the counting just begin when the explicit selected fields end or > does it directly jump to the depth measured from the root node? It's measured from the target resource. Think of "fields" as like a SQL "WHERE" clause and "depth" as a post-op = on the result. Note that certain combinations of depth and fields can = lead to all the selected fields being trimmed out of the response. That = is a valid user-error scenario. > Henning Rogge Kent // contributor --Apple-Mail=_9A6B9930-F07C-4630-B977-5634977014E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Henning,

Does the = counting just begin when the explicit selected fields end or
does it directly jump to the depth measured from the root = node?

It's measured from the target = resource.

Think of "fields" as like = a SQL "WHERE" clause and "depth" as a post-op on the result.   Note = that certain combinations of depth and fields can lead to all the = selected fields being trimmed out of the response.  That is a valid = user-error scenario.


Henning Rogge

Kent // contributor

= --Apple-Mail=_9A6B9930-F07C-4630-B977-5634977014E9-- From nobody Tue May 12 14:16:44 2020 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 68BA93A0BE8 for ; Tue, 12 May 2020 14:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=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 CRR03LbPQYwQ for ; Tue, 12 May 2020 14:16:42 -0700 (PDT) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 D52783A0BEC for ; Tue, 12 May 2020 14:16:41 -0700 (PDT) Received: by mail-yb1-xb34.google.com with SMTP id o8so7699860ybc.11 for ; Tue, 12 May 2020 14:16:41 -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=zsw/Ej1bGI931N/XQ1ki1volV6wATHOFJCBSQsEU3+k=; b=RR8udfvKrpVO1r0Ds4vXgdsoLWmy3LfNv2Hvm2x/G/OcPPNHtXMPrOmbIpmrsGCDds +rKlwRjsGrXG6AF+tbSfRvP5EflzgZV6jUci6mvFc74Ne2T9wnRkmeNlm5ncImubTMvB DwQDqiBP/nyXGgJ5rNRF1QIBB5y6pYFc+kFHXBKNTKm7oNeO/PYhFzYfjVDeHitkvI4K PgZBALheLC9qwM5gnIgBZimNZuTM21KUddsEJBfqXUtF2AJMXpEU7CBp4Qz6wSJACE4p 5d7btoAdR/cqBK+a/LKCvs6ATLo66667lDPtaID4QpFFMNm7nJJemudvhOHd/DbRiRZL 5wDw== 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=zsw/Ej1bGI931N/XQ1ki1volV6wATHOFJCBSQsEU3+k=; b=hadZairbZ6FbetNKzi4QK9K0nXQByeOeMoo3TE++zvGg3Co5/nxxk3kRLp/kFKk2es XI9/B+e34m9vT7Yd5PZLHpVybtTeVvJHQ/GkZ7LUuHbLztggrKJFpdKI7FzrsO4XijB8 Tpr/VTDsGkIP+Gj4/166MVPqekK5gYpEtcsfIj5d01rvZaaUk890jGPHgImZkGfuHLv6 Na0Zfi+IRoOr6rRN8qYr6a3VVu1x8NP5VKPBtxcvSQZ8xQHqpCKuJbHPbXltMV1PzgO/ P6bOfXG26e0p4gui1my7LpGGZpHbF2F4Wl/tq1GQTKWN+/kjMUInF7ljIkk8a3EoahLr NK1A== X-Gm-Message-State: AGi0PuYnykj4VPILoHNak/1e5Sw5Cvhzfx0DjhVLnyCDL72u0JNfNOAu G9kAHbMz2NUhUO/1//8yTBK0Fj27GvcIyQrcFwSxYg== X-Google-Smtp-Source: APiQypK6mxHDnMHPSIphqBooEh3+1BjA/Vq0Eu5BE3uFuSnX+UCF+C7raJPL4gUcHakzcIKpbfF47vu5J78CZyWx2v8= X-Received: by 2002:a25:787:: with SMTP id 129mr36403335ybh.359.1589318200802; Tue, 12 May 2020 14:16:40 -0700 (PDT) MIME-Version: 1.0 References: <20200414.222236.518728457229433184.id@4668.se> <9C6D0A8A-2BD4-4578-8CB3-6969078CE10A@gmail.com> <20BA9136-0FC6-4CAC-BF59-89FC16DB583E@gmail.com> <01000171f59ea8ae-a7319ea3-12ca-4857-9b43-3f89ef6ec35c-000000@email.amazonses.com> <010001720a72cd87-57dc4f05-1079-470c-b1eb-d84e548c7ca6-000000@email.amazonses.com> In-Reply-To: <010001720a72cd87-57dc4f05-1079-470c-b1eb-d84e548c7ca6-000000@email.amazonses.com> From: Andy Bierman Date: Tue, 12 May 2020 14:16:29 -0700 Message-ID: To: Kent Watsen Cc: Henning Rogge , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cb51a205a579fa67" Archived-At: Subject: Re: [netconf] Trouble with RFC 8040 (Restconf) fields Query Parameter 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, 12 May 2020 21:16:43 -0000 --000000000000cb51a205a579fa67 Content-Type: text/plain; charset="UTF-8" On Tue, May 12, 2020 at 12:53 PM Kent Watsen wrote: > Hi Henning, > > Does the counting just begin when the explicit selected fields end or > does it directly jump to the depth measured from the root node? > > > It's measured from the target resource. > > Think of "fields" as like a SQL "WHERE" clause and "depth" as a post-op on > the result. Note that certain combinations of depth and fields can lead > to all the selected fields being trimmed out of the response. That is a > valid user-error scenario. > > The fields nodes are supposed to be included in depth=1 https://tools.ietf.org/html/rfc8040#section-4.8.2 The requested data node has a depth level of "1". If the "fields" parameter (Section 4.8.3 ) is used to select descendant data nodes, then these nodes and all of their ancestor nodes have a "depth" value of "1". (This has the effect of including the nodes specified by the fields, even if the "depth" value is less than the actual depth level of the specified fields.) Any other child node has a "depth" value that is 1 greater than its parent. > > Henning Rogge > > > Kent // contributor > Andy > > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --000000000000cb51a205a579fa67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, May 12, 2020 at 12:53 PM Kent= Watsen <kent+ietf@watsen.net<= /a>> wrote:
<= div style=3D"overflow-wrap: break-word;">
Hi Henning,

Does the counting just begin when the expl= icit selected fields end or
does it directly jump to the depth measured = from the root node?





https://tools.ietf.org/html/rfc8040#section-4.8.2

   The requested data node has a depth level of "1".  If the &quo=
t;fields"
   parameter (Section 4.8.3) is used to select descendant data nodes,
   then these nodes and all of their ancestor nodes have a "depth"=
; value
   of "1".  (This has the effect of including the nodes specified=
 by the
   fields, even if the "depth" value is less than the actual dept=
h level
   of the specified fields.)  Any other child node has a "depth" =
value=C2=A0
= =C2=A0 =C2=A0 =C2=A0 that is 1 greater than its parent.
=C2=A0
=

Henning Rogge

=
Kent // contributor


Andy

=C2=A0
_______________________________________________
netconf mailing list
netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf
--000000000000cb51a205a579fa67-- From nobody Wed May 13 15:13:10 2020 Return-Path: <010001721019329c-2f818f0f-e2d7-48aa-b513-d4380e88b830-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 877693A00C0 for ; Wed, 13 May 2020 15:13:09 -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_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 5htP1pgJCg7v for ; Wed, 13 May 2020 15:13:08 -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 E8EE73A00B2 for ; Wed, 13 May 2020 15:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1589407986; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=4oHw+kaPtJT7uQKY1i+5BuK/jTFtU/EtxT/jJRqyyio=; b=R324Rr0bGpjZ9QWF4hE2zPRWIAVbr1PVVT9oOFAxqsOPY0PqcYSvX4Ayf7L3Xtp3 0c9QXzq9WFR0P/7VZacgAl0p8cq/ng/8EhLKW/YRf9sd5lVGpgjL7arRw1oT7Mt+QEO DAoFv2VnWynCGZntWTWf313rBhxA6DW7KB8y6PEg= From: Kent Watsen Message-ID: <010001721019329c-2f818f0f-e2d7-48aa-b513-d4380e88b830-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2CF63314-3E02-4CAD-881A-977A6EFD2DAD" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 13 May 2020 22:13:06 +0000 In-Reply-To: Cc: "netconf@ietf.org" To: "Rob Wilton (rwilton)" References: <0100017199cd7580-240a83ae-9934-4af3-a0e3-3b063286059f-000000@email.amazonses.com> <20200421063956.fgczjrjhh6ppjhnp@anna.jacobs.jacobs-university.de> <010001719d195262-4f097864-625d-437f-8e15-a79c4498342e-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.05.13-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Virtual "hum" for the "key generation" issue discussed at virtual meeting 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, 13 May 2020 22:13:10 -0000 --Apple-Mail=_2CF63314-3E02-4CAD-881A-977A6EFD2DAD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Rob, Before makeing the edits to conform to Option #3 (remove =E2=80=9Ckeygen=E2= =80=9D), I wanted to follow-up on a comment you made before: > One question I have, is whether the crypto-types could still define = identities for the base algorithms.=20 I know that it=E2=80=99s not what you had in mind, but one possible = half-step is as follows... In ietf-crypto-types.yang, define two base identities:=20 identity symmetric-algorithm { description "Base identity for symmetric algorithms."; } identity asymmetric-algorithm { description "Base identity for asymmetric algorithms."; } And then, wherever there is an =E2=80=9Calgorithm=E2=80=9D node, change = its definition as follows: OLD: leaf algorithm { type isa:symmetric-algorithm-type; mandatory true; description "The symmetric key=E2=80=99s algorithm."; } NEW: leaf algorithm { type identityref { base symmetric-algorithm; } mandatory false; description "The symmetric key=E2=80=99s algorithm."; } That the node would be =E2=80=9Cmandatory false=E2=80=9D is not a big = deal as the node=E2=80=99s existence in the configuration model serves a = very passive role, just relaying anecdotal information. Truly, the = only place where the node MUST be set is in the keygen RPCs (e.g., = generate-asymmetric-key). These RPCs would be defined later, and of = course would set the =E2=80=9Calgorithm" input node to =E2=80=9Cmandatory = true=E2=80=9D, where it=E2=80=99s needed. PROs: - enable apps to create proprietary identities that work with the = standard model - maintain placeholders to where the all the =E2=80=9Calgorithm=E2=80=9D= nodes are locations - negate needing to augment-in the =E2=80=9Calgorithm=E2=80=9D nodes = later CONs: - will likely lead to confusion as there is no way to set a correct = value until someone defines the concrete identities. Thoughts? Kent // contributor --Apple-Mail=_2CF63314-3E02-4CAD-881A-977A6EFD2DAD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Rob,

Before makeing = the edits to conform to Option #3 (remove =E2=80=9Ckeygen=E2=80=9D), I = wanted to follow-up on a comment you made before:

One = question I have, is whether the crypto-types could still define = identities for the base = algorithms. 

I know that it=E2=80=99s not what you had in mind, = but one possible half-step is as follows...

In ietf-crypto-types.yang, define two base = identities: 

    =  identity symmetric-algorithm {
  =       description "Base identity for symmetric = algorithms.";
      }

    =   identity asymmetric-algorithm {
 =       description "Base identity for = asymmetric algorithms.";
      }


And then, = wherever there is an =E2=80=9Calgorithm=E2=80=9D node, change its = definition as follows:

OLD:

  =   leaf algorithm {
    =   type isa:symmetric-algorithm-type;
  =     mandatory true;
    =   description
      =   "The symmetric key=E2=80=99s algorithm.";
 =   }


NEW:

  =   leaf algorithm {
    =   type identityref {
      =   base symmetric-algorithm;
      = }
      mandatory false;
      description
  =       "The symmetric key=E2=80=99s algorithm.";
    }

That the node would be =E2=80=9Cmandatory false=E2=80= =9D is not a big deal as the node=E2=80=99s existence in the = configuration model serves a very passive role, just relaying anecdotal = information.   Truly, the only place where the node MUST be set is = in the keygen RPCs (e.g., generate-asymmetric-key).  These RPCs = would be defined later, and of course would set the =E2=80=9Calgorithm" = input node to =E2=80=9Cmandatory true=E2=80=9D, where it=E2=80=99s = needed.


PROs:
   - enable apps to = create proprietary identities that work with the standard = model
   - maintain placeholders to where the all = the =E2=80=9Calgorithm=E2=80=9D nodes are = locations
   - negate needing to augment-in the = =E2=80=9Calgorithm=E2=80=9D nodes later

CONs:
  =  - will likely lead to confusion as there is no way to set a = correct value until
     someone = defines the concrete identities.


Thoughts?

Kent // contributor




= --Apple-Mail=_2CF63314-3E02-4CAD-881A-977A6EFD2DAD-- From nobody Thu May 14 04:45:58 2020 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 9C9B33A0977 for ; Thu, 14 May 2020 04:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=kNcOErgZ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=xfIqRoOt 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 dMLj7m3PyxO8 for ; Thu, 14 May 2020 04:45:53 -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 3DF773A0975 for ; Thu, 14 May 2020 04:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21578; q=dns/txt; s=iport; t=1589456753; x=1590666353; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LGgwqt34F0PILBJiMLV2Mjt3gWViWMYerc36aUXexvc=; b=kNcOErgZ0RvTty86WHZLlB22tkK84OM7xexAxmyQE7FgMslQdedP8F4/ BtFGg0JbWQ3cvV5qGruitscb8PeZw7rO97oLQomgHQwkN3AAYa3PjOw5m J6cL7LmU864BadSlQv/8apNHi1lKq0yfpDN2Cb6ZVVswI6LdNZbMkMVPX I=; IronPort-PHdr: =?us-ascii?q?9a23=3A7Zevehysha4iWJnXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWBt+pkkETEW8Pd5u4Xw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoLkFJA8v4IVvfvi764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D?= =?us-ascii?q?=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJCAAiLr1e/4UNJK1dCR0BAQEBCQE?= =?us-ascii?q?SAQUFAYIHgSUvUQdvWC8sCoQbg0YDjT2TVIRjglIDVAsBAQEMAQEtAgQBAYR?= =?us-ascii?q?EAheBfiQ4EwIDAQELAQEFAQEBAgEFBG2FKgYmDIVxAQEBAQMSEQoTAQE3AQ8?= =?us-ascii?q?CAQgRBAEBKwICAjAdCAIEDgUIEweDBYF+TQMuAaZaAoE5iGF2gTKDAQEBBYV?= =?us-ascii?q?FGIIOCYE4gmOIG4FEGoFBP4ERQ4JNPoQiLoMSM4ItkVqGIZsHCoJNmFGdSa1?= =?us-ascii?q?kAgQCBAUCDgEBBYFpIoFWcBWDJFAYDY4ughI4gzqKVnQ3AgYBBwEBAwl8jTg?= =?us-ascii?q?BgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.73,391,1583193600"; d="scan'208,217";a="759758509" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 May 2020 11:45:51 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 04EBjpRR012505 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 May 2020 11:45:51 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 14 May 2020 06:45:51 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 14 May 2020 07:45:50 -0400 Received: from NAM10-DM6-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.1497.2 via Frontend Transport; Thu, 14 May 2020 06:45:50 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Lnn0JMuWgN3KIM77YclUpWN28W+Hw2mz8hZEcn3WDv9gkexhg8+nToI2qVELoXQxN5FTqKdpD/7Us91cs2RV8zf4t5INUxjM5ke6A4NO3MlLG/Hk2GD1veHccQ8h3Cjpox8dATT1bCmqRZKFrZKKqbFj0RTpPF55KGj6PyysoUBuaFmbDhaAyFjeBbdz46GT9jeGqLm6wiyN5FB/wOahqZoooix5iGUHYXyNBJLzYsIzqO5Etty/Z6XgM1t6mqPcJPXArbZtrBcCTlqgVABRMoPjHYQqTAUl2+B5rctBr5qUMN3rqrgWubwgqp3S0F9zEp9bOwkWfqADEBxuIpP1Qg== 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=LGgwqt34F0PILBJiMLV2Mjt3gWViWMYerc36aUXexvc=; b=WuTAdqyeJ+G52vrP+5y87csnFig1q3dQgi4kqRXs49uCMSHaMs2PLPFZlR9uJ1z6lLJyn7HQH3RimCHx80zWrJ7anE73YailgCsLqtccs57OHz63ZI7dHCS9/i6cCpyF80MyhY30oB+ZvhhBXK9IPIFUklHFVs7zPW64hG9ZokjI3ctt/sKx2WZO8d57zh1KH+UoZDz8CxbS7eXh5juoF5NEUXDkEMq/H2+lyf4a2ZHXGnU3NUR2xFyrvbxHReacG8kztR9xeabSxEtwYS6OBBXlkZS5228uCstgtX6nJPMvYDM85ARGBaa7iJaK71kJu7oA8OP0bqQ61at97ncvPA== 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=LGgwqt34F0PILBJiMLV2Mjt3gWViWMYerc36aUXexvc=; b=xfIqRoOtFjysQk+AmDHuFRppXmZWPb8XB+Hln0I2NQ6e1p8/qsJxW0MHGMykzTZnwdaZhKN12JsSK/3S7uhwiqXhRv5SgCkKsR0+o1n8XnCGAmjgdlAKYQuW4KG62uw6brsLyTxZZljm/594wHRaPS+5+TSHq9VxB/OBDKYgi3k= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB3854.namprd11.prod.outlook.com (2603:10b6:208:f0::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.29; Thu, 14 May 2020 11:45:49 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3:2164:a8e2:33b3]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::3:2164:a8e2:33b3%5]) with mapi id 15.20.2979.033; Thu, 14 May 2020 11:45:49 +0000 From: "Rob Wilton (rwilton)" To: Kent Watsen CC: "netconf@ietf.org" , "Salz, Rich" Thread-Topic: [netconf] Virtual "hum" for the "key generation" issue discussed at virtual meeting Thread-Index: AQHWF2bXrSECauZ+fUyn7wWuc6EbxKiDIIkAgAB/rQCACXJewIAZpfgAgADGKaA= Date: Thu, 14 May 2020 11:45:49 +0000 Message-ID: References: <0100017199cd7580-240a83ae-9934-4af3-a0e3-3b063286059f-000000@email.amazonses.com> <20200421063956.fgczjrjhh6ppjhnp@anna.jacobs.jacobs-university.de> <010001719d195262-4f097864-625d-437f-8e15-a79c4498342e-000000@email.amazonses.com> <010001721019329c-2f818f0f-e2d7-48aa-b513-d4380e88b830-000000@email.amazonses.com> In-Reply-To: <010001721019329c-2f818f0f-e2d7-48aa-b513-d4380e88b830-000000@email.amazonses.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=cisco.com; x-originating-ip: [64.103.40.19] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8dc429dc-c9d4-440a-6c36-08d7f7fc5942 x-ms-traffictypediagnostic: MN2PR11MB3854: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 040359335D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: uAXl1HEXd+VzATJnlI6pMfrO0OJdrmzwZAsWfp2VVSp1xxkJdwSnzXQSvTaB/z8os19nlA50bbb1qL++y+C394BrXIQAOdWW2l+ddfJ68Dcr/y5OP1HJ9ov1zN5YLVPwF7vp18/axam1QROv6x0D/ylnmsPKfNwIocHnnDkw+G+onL1JayGbQJ4d8QrxVh2ptdjV1fhN1Qd+4cl8kVpNHcmVNSGBzonKyimPBcmmRXqiPz9asLQlQqbD4SJBRnR4QEJjFCr8qNNcqHxQ28LN4rmnJis8/Cw84OAXZ6ayNUfq/1sH2InDmusvnZegBOIj2QLw9EwXWUkVWETrebRZdbWGCrh6fjbpo+nByDSNP6wks7Pj0OJEaDLESBHO76LxJRpC2BOdBMbobft1VPLQCgr7PsTot+jojbmgyvxiFBxbFcssVwmUHe1nFQ2Auk+c x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(376002)(396003)(346002)(366004)(8936002)(53546011)(64756008)(316002)(5660300002)(7696005)(52536014)(66946007)(66446008)(66476007)(76116006)(8676002)(86362001)(66556008)(6506007)(33656002)(54906003)(2906002)(186003)(478600001)(55016002)(9326002)(9686003)(4326008)(26005)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: mrRulq+EOPQ7rcz4uchQrOUU9MMvtCT6NB4/dx3/1iFGSe6Ht1p6FXnlCAdQ5PTCMlBLdAvsLUf5mfT5j1z6XX71IURClJSKHw7HauM7j/jW/qS6U6KG8s9mRd6WksAUkNUR8N6kRNq2WOBjHQTt7YNfitBp/xtP/71ygAp6YfV+SOqCG50pAep6jeE5ubOSMFr1F6hQmU4H/nW2Jc4lrHrt1X9XHbXcBSSi2QtCHAWfHB22mKLjIZJuGkFIunXTKiePbCXTg8KQoiUtC70jl1ZILdaBcx9EoAz1Gc6YtqR4xcuPtryBI85HkHizzH1c6d0vJzM4+AQloEsFgQlBOTqohmf454yvrBoOJh+RMvx9awauxPrdLpO9aL0NHx8Zz2FMdfgZupUDt6dGVMFHpI+8fuvabhEXfZ4r+E66jICdoJSmJvGJrRX6u7z//SosvsDLRT4yiHV2kTjEJrmxf5LR7m4DGuMPARjTM7Doyf8= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366D2A91F5017A2EEA793C6B5BC0MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8dc429dc-c9d4-440a-6c36-08d7f7fc5942 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2020 11:45:49.5100 (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: tRaK3+ngY7gkooB0Tde6DT+2IPpvPOf2sVRr2ZLYpmqvHWP0+/GC0HqxTa/Bb/+3FnRxazdBT04HPk1wpP6VVQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3854 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [netconf] Virtual "hum" for the "key generation" issue discussed at virtual meeting 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, 14 May 2020 11:45:56 -0000 --_000_MN2PR11MB4366D2A91F5017A2EEA793C6B5BC0MN2PR11MB4366namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2VudCwNCg0KSeKAmW0gbm90IHN1cmUgdGhhdCBJIGhhdmUgc3VmZmljaWVudCBrbm93bGVk Z2UgdG8gcHJvcGVybHkgY29tbWVudCBvbiB0aGlzIHBvaW50OiDigJxlbmFibGUgYXBwcyB0byBj cmVhdGUgcHJvcHJpZXRhcnkgaWRlbnRpdGllcyB0aGF0IHdvcmsgd2l0aCB0aGUgc3RhbmRhcmQg bW9kZWzigJ0uDQoNCklmIGZlZWxzIHRvIG1lIHRoYXQgdGhlIHVsdGltYXRlIHNvbHV0aW9uIGhl cmUgaXMgdGhhdCB0aGUgaW5kaXZpZHVhbCBwcm90b2NvbHMgZGVmaW5lIHByb3RvY29sIHNwZWNp ZmljIGFsZ29yaXRobSBpZGVudGl0aWVzLiAgQnV0IGl0IGlzIHVuY2xlYXIgdG8gbWUgKGkpIHdo ZXRoZXIgaXQgaXMgaGVscGZ1bCBmb3IgdGhvc2UgcHJvdG9jb2wgc3BlY2lmaWMgYWxnb3JpdGht IGlkZW50aXRpZXMgdG8gZGVyaXZlIGZyb20gYSBiYXNlIGdlbmVyaWMgYWxnb3JpdGhtIGlkZW50 aXR5IG9yIG5vdCwgYW5kIChpaSkgd2hldGhlciBpdCBpcyBoZWxwZnVsIGZvciB0aG9zZSBhbGdv cml0aG0gc3BlY2lmaWMgaWRlbnRpdGllcyB0byBiZSBhYmxlIHRvIGluaGVyaXQgYSBiYXNlIGFs Z29yaXRobSBzcGVjaWZpYyBpZGVudGl0eS4NCg0KQXMgbW9yZSBjb25jcmV0ZSBleGFtcGxlczoN CihpKSBXb3VsZCBiZSBoZWxwZnVsIGZvciBhbiBzc2gg4oCccnNhNDA5NuKAnSBpZGVudGl0eSB0 byBkZXJpdmUgZnJvbSDigJxzc2gtYXN5bW1ldHJpYy1hbGdvcml0aG3igJ0gd2hpY2ggaXRzZWxm IGRlcml2ZXMgZnJvbSDigJxhc3ltbWV0cmljLWFsZ29yaXRobeKAnT8NCihpaSkgT3Igd291bGQg YmUgaGVscGZ1bCBmb3IgYW4gc3NoIOKAnHJzYTQwOTbigJ0gaWRlbnRpdHkgdG8gZGVyaXZlIGZy b20gYm90aCDigJxzc2gtYXN5bW1ldHJpYy1hbGdvcml0aG3igJ0gYW5kIGFsc28gYSBiYXNlIGN5 cHRvIOKAnHJzYTQwOTbigJ0gaWRlbnRpdHkgdGhhdCBkZXJpdmVzIGZyb20g4oCcYXN5bW1ldHJp Yy1hbGdvcml0aG3igJ0/DQooaWlpKSBPciBpcyBpdCBqdXN0IHN1ZmZpY2llbnQgdG8gaGF2ZSBh biBzc2gg4oCccnNhNDA5NuKAnSBpZGVudGl0eSBkZXJpdmUgZnJvbSBhIOKAnHNzaC1hc3ltbWV0 cmljLWFsZ29yaXRobeKAnSBiYXNlIGlkZW50aXR5Pw0KDQpJZiB0aGUgYW5zd2VyIGlzIChpaSkg dGhlbiBJIHRoaW5rIHRoYXQgdGhlcmUgaXMgYWxzbyBhIGZ1cnRoZXIgcXVlc3Rpb24gYXMgdG8g d2hldGhlciB0aGUgYmFzZSDigJxhc3ltbWV0cmljLWFsZ29yaXRobeKAnSBpZGVudGl0eSBzaG91 bGQgYmUgZGVmaW5lZCBpbiBjcnlwdG8tdHlwZXMueWFuZyBvciBpbiB0aGUgSUFOQSByZWdpc3Ry eSBkZWZpbmVkIFlBTkcgZmlsZSB0aGF0IGRlZmluZXMgdGhlIGJhc2UgaWRlbnRpdGllcz8NCg0K RXZlbiBpZiB3ZSBjYW4gZmlndXJlIG91dCB3aGF0IHRoZSBpZGVudGl0eSBoaWVyYXJjaHkgc2hv dWxkIGxvb2sgbGlrZSwgSeKAmW0gbm90IHN1cmUgd2hldGhlciBpdCBtYWtlcyBzZW5zZSB0byBz dGlsbCBkZWZpbmUgdGhlIOKAnGFsZ29yaXRobeKAnSBsZWFmIG5vZGVzIGluIHRoZSBncm91cGlu Z3MuICBJZiB0aGV5IGFyZSBvbmx5IHJlYWxseSB0cnVseSByZXF1aXJlZCBmb3IgdGhlIGtleSBn ZW5lcmF0aW9uIHJwY3MgdGhlbiBwZXJoYXBzIHRoZXkgYXJlIG5vdCByZXF1aXJlZCBpbiB0aGUg b3RoZXIgcGxhY2VzIGF0IGFsbC5lDQoNCkF0IHRoZSBtb21lbnQsICBJ4oCZbSBsZWFuaW5nIHRv d2FyZHMgbGVhdmluZyB0aGlzIG91dCwgYW5kIHNvbHZpbmcgdGhpcyBpbiB0aGUgZnV0dXJlLiAg SWYgd2UgZG9u4oCZdCBwdXQgYW55dGhpbmcgaW4sIHRoZW4gd2UgY2Fu4oCZdCBhY2NpZGVudGFs bHkgY29uc3RyYWluIGEgZnV0dXJlIHNvbHV0aW9uLg0KDQpSb2INCi8vIEFzIGFuIGluZGl2aWR1 YWwgY29udHJpYnV0b3INCg0KRnJvbTogS2VudCBXYXRzZW4gPGtlbnQraWV0ZkB3YXRzZW4ubmV0 Pg0KU2VudDogMTMgTWF5IDIwMjAgMjM6MTMNClRvOiBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndp bHRvbkBjaXNjby5jb20+DQpDYzogbmV0Y29uZkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRj b25mXSBWaXJ0dWFsICJodW0iIGZvciB0aGUgImtleSBnZW5lcmF0aW9uIiBpc3N1ZSBkaXNjdXNz ZWQgYXQgdmlydHVhbCBtZWV0aW5nDQoNCkhpIFJvYiwNCg0KQmVmb3JlIG1ha2VpbmcgdGhlIGVk aXRzIHRvIGNvbmZvcm0gdG8gT3B0aW9uICMzIChyZW1vdmUg4oCca2V5Z2Vu4oCdKSwgSSB3YW50 ZWQgdG8gZm9sbG93LXVwIG9uIGEgY29tbWVudCB5b3UgbWFkZSBiZWZvcmU6DQoNCg0KT25lIHF1 ZXN0aW9uIEkgaGF2ZSwgaXMgd2hldGhlciB0aGUgY3J5cHRvLXR5cGVzIGNvdWxkIHN0aWxsIGRl ZmluZSBpZGVudGl0aWVzIGZvciB0aGUgYmFzZSBhbGdvcml0aG1zLg0KDQpJIGtub3cgdGhhdCBp dOKAmXMgbm90IHdoYXQgeW91IGhhZCBpbiBtaW5kLCBidXQgb25lIHBvc3NpYmxlIGhhbGYtc3Rl cCBpcyBhcyBmb2xsb3dzLi4uDQoNCkluIGlldGYtY3J5cHRvLXR5cGVzLnlhbmcsIGRlZmluZSB0 d28gYmFzZSBpZGVudGl0aWVzOg0KDQogICAgIGlkZW50aXR5IHN5bW1ldHJpYy1hbGdvcml0aG0g ew0KICAgICAgICBkZXNjcmlwdGlvbiAiQmFzZSBpZGVudGl0eSBmb3Igc3ltbWV0cmljIGFsZ29y aXRobXMuIjsNCiAgICAgIH0NCg0KICAgICAgaWRlbnRpdHkgYXN5bW1ldHJpYy1hbGdvcml0aG0g ew0KICAgICAgICBkZXNjcmlwdGlvbiAiQmFzZSBpZGVudGl0eSBmb3IgYXN5bW1ldHJpYyBhbGdv cml0aG1zLiI7DQogICAgICB9DQoNCkFuZCB0aGVuLCB3aGVyZXZlciB0aGVyZSBpcyBhbiDigJxh bGdvcml0aG3igJ0gbm9kZSwgY2hhbmdlIGl0cyBkZWZpbml0aW9uIGFzIGZvbGxvd3M6DQoNCk9M RDoNCg0KICAgIGxlYWYgYWxnb3JpdGhtIHsNCiAgICAgIHR5cGUgaXNhOnN5bW1ldHJpYy1hbGdv cml0aG0tdHlwZTsNCiAgICAgIG1hbmRhdG9yeSB0cnVlOw0KICAgICAgZGVzY3JpcHRpb24NCiAg ICAgICAgIlRoZSBzeW1tZXRyaWMga2V54oCZcyBhbGdvcml0aG0uIjsNCiAgICB9DQoNCk5FVzoN Cg0KICAgIGxlYWYgYWxnb3JpdGhtIHsNCiAgICAgIHR5cGUgaWRlbnRpdHlyZWYgew0KICAgICAg ICBiYXNlIHN5bW1ldHJpYy1hbGdvcml0aG07DQogICAgICB9DQogICAgICBtYW5kYXRvcnkgZmFs c2U7DQogICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAiVGhlIHN5bW1ldHJpYyBrZXnigJlzIGFs Z29yaXRobS4iOw0KICAgIH0NCg0KVGhhdCB0aGUgbm9kZSB3b3VsZCBiZSDigJxtYW5kYXRvcnkg ZmFsc2XigJ0gaXMgbm90IGEgYmlnIGRlYWwgYXMgdGhlIG5vZGXigJlzIGV4aXN0ZW5jZSBpbiB0 aGUgY29uZmlndXJhdGlvbiBtb2RlbCBzZXJ2ZXMgYSB2ZXJ5IHBhc3NpdmUgcm9sZSwganVzdCBy ZWxheWluZyBhbmVjZG90YWwgaW5mb3JtYXRpb24uICAgVHJ1bHksIHRoZSBvbmx5IHBsYWNlIHdo ZXJlIHRoZSBub2RlIE1VU1QgYmUgc2V0IGlzIGluIHRoZSBrZXlnZW4gUlBDcyAoZS5nLiwgZ2Vu ZXJhdGUtYXN5bW1ldHJpYy1rZXkpLiAgVGhlc2UgUlBDcyB3b3VsZCBiZSBkZWZpbmVkIGxhdGVy LCBhbmQgb2YgY291cnNlIHdvdWxkIHNldCB0aGUg4oCcYWxnb3JpdGhtIiBpbnB1dCBub2RlIHRv IOKAnG1hbmRhdG9yeSB0cnVl4oCdLCB3aGVyZSBpdOKAmXMgbmVlZGVkLg0KDQoNClBST3M6DQog ICAtIGVuYWJsZSBhcHBzIHRvIGNyZWF0ZSBwcm9wcmlldGFyeSBpZGVudGl0aWVzIHRoYXQgd29y ayB3aXRoIHRoZSBzdGFuZGFyZCBtb2RlbA0KICAgLSBtYWludGFpbiBwbGFjZWhvbGRlcnMgdG8g d2hlcmUgdGhlIGFsbCB0aGUg4oCcYWxnb3JpdGht4oCdIG5vZGVzIGFyZSBsb2NhdGlvbnMNCiAg IC0gbmVnYXRlIG5lZWRpbmcgdG8gYXVnbWVudC1pbiB0aGUg4oCcYWxnb3JpdGht4oCdIG5vZGVz IGxhdGVyDQoNCkNPTnM6DQogICAtIHdpbGwgbGlrZWx5IGxlYWQgdG8gY29uZnVzaW9uIGFzIHRo ZXJlIGlzIG5vIHdheSB0byBzZXQgYSBjb3JyZWN0IHZhbHVlIHVudGlsDQogICAgIHNvbWVvbmUg ZGVmaW5lcyB0aGUgY29uY3JldGUgaWRlbnRpdGllcy4NCg0KDQpUaG91Z2h0cz8NCg0KS2VudCAv LyBjb250cmlidXRvcg0KDQoNCg0KDQo= --_000_MN2PR11MB4366D2A91F5017A2EEA793C6B5BC0MN2PR11MB4366namp_ 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 CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcy LjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRG NzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgS2VudCw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SeKA mW0gbm90IHN1cmUgdGhhdCBJIGhhdmUgc3VmZmljaWVudCBrbm93bGVkZ2UgdG8gcHJvcGVybHkg Y29tbWVudCBvbiB0aGlzIHBvaW50OiDigJw8L3NwYW4+ZW5hYmxlIGFwcHMgdG8gY3JlYXRlIHBy b3ByaWV0YXJ5IGlkZW50aXRpZXMgdGhhdCB3b3JrIHdpdGggdGhlIHN0YW5kYXJkIG1vZGVs4oCd LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPklmIGZlZWxzIHRvIG1lIHRoYXQgdGhlIHVsdGltYXRlIHNvbHV0aW9uIGhlcmUg aXMgdGhhdCB0aGUgaW5kaXZpZHVhbCBwcm90b2NvbHMgZGVmaW5lIHByb3RvY29sIHNwZWNpZmlj IGFsZ29yaXRobSBpZGVudGl0aWVzLiZuYnNwOyBCdXQgaXQgaXMgdW5jbGVhciB0byBtZSAoaSkg d2hldGhlciBpdCBpcyBoZWxwZnVsIGZvciB0aG9zZSBwcm90b2NvbA0KIHNwZWNpZmljIGFsZ29y aXRobSBpZGVudGl0aWVzIHRvIGRlcml2ZSBmcm9tIGEgYmFzZSBnZW5lcmljIGFsZ29yaXRobSBp ZGVudGl0eSBvciBub3QsIGFuZCAoaWkpIHdoZXRoZXIgaXQgaXMgaGVscGZ1bCBmb3IgdGhvc2Ug YWxnb3JpdGhtIHNwZWNpZmljIGlkZW50aXRpZXMgdG8gYmUgYWJsZSB0byBpbmhlcml0IGEgYmFz ZSBhbGdvcml0aG0gc3BlY2lmaWMgaWRlbnRpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkFzIG1vcmUgY29uY3JldGUgZXhh bXBsZXM6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPihpKSBXb3VsZCBiZSBoZWxwZnVs IGZvciBhbiBzc2gg4oCccnNhNDA5NuKAnSBpZGVudGl0eSB0byBkZXJpdmUgZnJvbSDigJxzc2gt YXN5bW1ldHJpYy1hbGdvcml0aG3igJ0gd2hpY2ggaXRzZWxmIGRlcml2ZXMgZnJvbSDigJxhc3lt bWV0cmljLWFsZ29yaXRobeKAnT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPihpaSkgT3Ig d291bGQgYmUgaGVscGZ1bCBmb3IgYW4gc3NoIOKAnHJzYTQwOTbigJ0gaWRlbnRpdHkgdG8gZGVy aXZlIGZyb20gYm90aCDigJxzc2gtYXN5bW1ldHJpYy1hbGdvcml0aG3igJ0gYW5kIGFsc28gYSBi YXNlIGN5cHRvIOKAnHJzYTQwOTbigJ0gaWRlbnRpdHkgdGhhdCBkZXJpdmVzIGZyb20g4oCcYXN5 bW1ldHJpYy1hbGdvcml0aG3igJ0/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4oaWlpKSBP ciBpcyBpdCBqdXN0IHN1ZmZpY2llbnQgdG8gaGF2ZSBhbiBzc2gg4oCccnNhNDA5NuKAnSBpZGVu dGl0eSBkZXJpdmUgZnJvbSBhIOKAnHNzaC1hc3ltbWV0cmljLWFsZ29yaXRobeKAnSBiYXNlIGlk ZW50aXR5PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5JZiB0aGUgYW5zd2VyIGlzIChpaSkgdGhlbiBJIHRoaW5rIHRoYXQgdGhl cmUgaXMgYWxzbyBhIGZ1cnRoZXIgcXVlc3Rpb24gYXMgdG8gd2hldGhlciB0aGUgYmFzZSDigJxh c3ltbWV0cmljLWFsZ29yaXRobeKAnSBpZGVudGl0eSBzaG91bGQgYmUgZGVmaW5lZCBpbiBjcnlw dG8tdHlwZXMueWFuZyBvciBpbiB0aGUgSUFOQSByZWdpc3RyeSBkZWZpbmVkDQogWUFORyBmaWxl IHRoYXQgZGVmaW5lcyB0aGUgYmFzZSBpZGVudGl0aWVzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5FdmVuIGlmIHdlIGNhbiBm aWd1cmUgb3V0IHdoYXQgdGhlIGlkZW50aXR5IGhpZXJhcmNoeSBzaG91bGQgbG9vayBsaWtlLCBJ 4oCZbSBub3Qgc3VyZSB3aGV0aGVyIGl0IG1ha2VzIHNlbnNlIHRvIHN0aWxsIGRlZmluZSB0aGUg 4oCcYWxnb3JpdGht4oCdIGxlYWYgbm9kZXMgaW4gdGhlIGdyb3VwaW5ncy4mbmJzcDsgSWYgdGhl eSBhcmUgb25seSByZWFsbHkgdHJ1bHkNCiByZXF1aXJlZCBmb3IgdGhlIGtleSBnZW5lcmF0aW9u IHJwY3MgdGhlbiBwZXJoYXBzIHRoZXkgYXJlIG5vdCByZXF1aXJlZCBpbiB0aGUgb3RoZXIgcGxh Y2VzIGF0IGFsbC5lPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkF0IHRoZSBtb21lbnQsICZuYnNwO0nigJltIGxlYW5pbmcgdG93 YXJkcyBsZWF2aW5nIHRoaXMgb3V0LCBhbmQgc29sdmluZyB0aGlzIGluIHRoZSBmdXR1cmUuJm5i c3A7IElmIHdlIGRvbuKAmXQgcHV0IGFueXRoaW5nIGluLCB0aGVuIHdlIGNhbuKAmXQgYWNjaWRl bnRhbGx5IGNvbnN0cmFpbiBhIGZ1dHVyZSBzb2x1dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Um9iPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj4vLyBBcyBhbiBpbmRpdmlkdWFsIGNvbnRyaWJ1dG9yPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IEtlbnQgV2F0c2Vu ICZsdDtrZW50JiM0MztpZXRmQHdhdHNlbi5uZXQmZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMTMg TWF5IDIwMjAgMjM6MTM8YnI+DQo8Yj5Ubzo8L2I+IFJvYiBXaWx0b24gKHJ3aWx0b24pICZsdDty d2lsdG9uQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IG5ldGNvbmZAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRjb25mXSBWaXJ0dWFsICZxdW90O2h1bSZxdW90OyBm b3IgdGhlICZxdW90O2tleSBnZW5lcmF0aW9uJnF1b3Q7IGlzc3VlIGRpc2N1c3NlZCBhdCB2aXJ0 dWFsIG1lZXRpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IaSBSb2IsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5C ZWZvcmUgbWFrZWluZyB0aGUgZWRpdHMgdG8gY29uZm9ybSB0byBPcHRpb24gIzMgKHJlbW92ZSDi gJxrZXlnZW7igJ0pLCBJIHdhbnRlZCB0byBmb2xsb3ctdXAgb24gYSBjb21tZW50IHlvdSBtYWRl IGJlZm9yZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T25lIHF1ZXN0aW9uIEkgaGF2ZSwgaXMgd2hldGhlciB0aGUgY3J5cHRvLXR5cGVz IGNvdWxkIHN0aWxsIGRlZmluZSBpZGVudGl0aWVzIGZvciB0aGUgYmFzZSBhbGdvcml0aG1zLiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIGtub3cgdGhhdCBpdOKAmXMgbm90IHdoYXQgeW91IGhhZCBpbiBt aW5kLCBidXQgb25lIHBvc3NpYmxlIGhhbGYtc3RlcCBpcyBhcyBmb2xsb3dzLi4uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIGlldGYtY3J5 cHRvLXR5cGVzLnlhbmcsIGRlZmluZSB0d28gYmFzZSBpZGVudGl0aWVzOiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOyAmbmJzcDsgJm5ic3A7aWRlbnRpdHkmbmJzcDtzeW1t ZXRyaWMtYWxnb3JpdGhtJm5ic3A7ezxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZu YnNwO2Rlc2NyaXB0aW9uJm5ic3A7JnF1b3Q7QmFzZSBpZGVudGl0eSBmb3Igc3ltbWV0cmljIGFs Z29yaXRobXMuJnF1b3Q7Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7fTxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7aWRlbnRpdHkmbmJzcDthc3ltbWV0cmljLWFs Z29yaXRobSZuYnNwO3s8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDtkZXNj cmlwdGlvbiZuYnNwOyZxdW90O0Jhc2UmbmJzcDtpZGVudGl0eSBmb3IgYXN5bW1ldHJpYyBhbGdv cml0aG1zLiZxdW90Ozs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwO308bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kIHRoZW4sIHdo ZXJldmVyIHRoZXJlIGlzIGFuIOKAnGFsZ29yaXRobeKAnSBub2RlLCBjaGFuZ2UgaXRzIGRlZmlu aXRpb24gYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T0xEOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOyAmbmJz cDsmbmJzcDtsZWFmJm5ic3A7YWxnb3JpdGhtJm5ic3A7ezxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7Jm5ic3A7dHlwZSZuYnNwO2lzYTpzeW1tZXRyaWMtYWxnb3JpdGhtLXR5cGU7PGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsmbmJzcDttYW5kYXRvcnkmbmJzcDt0cnVlOzxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7Jm5ic3A7ZGVzY3JpcHRpb248YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmbmJzcDsmcXVvdDtUaGUgc3ltbWV0cmljIGtleeKAmXMgYWxnb3JpdGhtLiZxdW90Ozs8 YnI+DQombmJzcDsgJm5ic3A7Jm5ic3A7fTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TkVXOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgbGVhZiZuYnNwO2FsZ29yaXRo bSZuYnNwO3s8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdHlwZSZuYnNwO2lkZW50aXR5cmVmJm5ic3A7ezxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDtiYXNlJm5ic3A7c3ltbWV0cmljLWFsZ29y aXRobTs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgfTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDttYW5kYXRvcnkmbmJzcDtmYWxz ZTs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwO2Rlc2NyaXB0aW9uPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7JnF1b3Q7VGhlIHN5bW1ldHJpYyBrZXnigJlzIGFs Z29yaXRobS4mcXVvdDs7PGJyPg0KJm5ic3A7ICZuYnNwOyZuYnNwO308bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgdGhlIG5vZGUgd291bGQgYmUg4oCc bWFuZGF0b3J5IGZhbHNl4oCdIGlzIG5vdCBhIGJpZyBkZWFsIGFzIHRoZSBub2Rl4oCZcyBleGlz dGVuY2UgaW4gdGhlIGNvbmZpZ3VyYXRpb24gbW9kZWwgc2VydmVzIGEgdmVyeSBwYXNzaXZlIHJv bGUsIGp1c3QgcmVsYXlpbmcgYW5lY2RvdGFsIGluZm9ybWF0aW9uLiAmbmJzcDsgVHJ1bHksIHRo ZSBvbmx5IHBsYWNlIHdoZXJlIHRoZSBub2RlIE1VU1QgYmUgc2V0IGlzIGluIHRoZQ0KIGtleWdl biBSUENzIChlLmcuLCBnZW5lcmF0ZS1hc3ltbWV0cmljLWtleSkuICZuYnNwO1RoZXNlIFJQQ3Mg d291bGQgYmUgZGVmaW5lZCBsYXRlciwgYW5kIG9mIGNvdXJzZSB3b3VsZCBzZXQgdGhlIOKAnGFs Z29yaXRobSZxdW90OyBpbnB1dCBub2RlIHRvIOKAnG1hbmRhdG9yeSB0cnVl4oCdLCB3aGVyZSBp dOKAmXMgbmVlZGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlBST3M6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7LSBlbmFibGUgYXBwcyB0byBjcmVhdGUgcHJvcHJp ZXRhcnkgaWRlbnRpdGllcyB0aGF0IHdvcmsgd2l0aCB0aGUgc3RhbmRhcmQgbW9kZWw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJz cDstIG1haW50YWluIHBsYWNlaG9sZGVycyB0byB3aGVyZSB0aGUgYWxsIHRoZSDigJxhbGdvcml0 aG3igJ0gbm9kZXMgYXJlIGxvY2F0aW9uczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDstIG5lZ2F0ZSBuZWVkaW5n IHRvIGF1Z21lbnQtaW4gdGhlIOKAnGFsZ29yaXRobeKAnSBub2RlcyBsYXRlcjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DT05zOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw Oy0gd2lsbCBsaWtlbHkgbGVhZCB0byBjb25mdXNpb24gYXMgdGhlcmUgaXMgbm8gd2F5IHRvIHNl dCBhIGNvcnJlY3QgdmFsdWUgdW50aWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7c29tZW9uZSBkZWZpbmVzIHRo ZSBjb25jcmV0ZSBpZGVudGl0aWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhvdWdodHM/PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPktlbnQgLy8gY29udHJpYnV0b3I8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MN2PR11MB4366D2A91F5017A2EEA793C6B5BC0MN2PR11MB4366namp_-- From nobody Thu May 14 10:14:37 2020 Return-Path: <01000172142e349b-b5a2b343-02d4-43d2-84d9-dd0e42c44cd9-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 E20D83A0C16 for ; Thu, 14 May 2020 10:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 4PaiJcW52Qwr for ; Thu, 14 May 2020 10:14:33 -0700 (PDT) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 554B23A0C15 for ; Thu, 14 May 2020 10:14:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1589476472; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=6YBHhpssQj1SAWbUlczDz8qyelZ3dgNntAzZh3BJSLM=; b=HVQQT/KwQBQ/bh68YeP+m26IsQwbxt598f1dl5zn7OruqFxUUnj36shr2FDIuSqJ 21pYbEe4REk43qyAUWRxQ5MgPYdAIfWPhyF9hvAzawX3Hb8KAjg1e2VcSNhO5AoR1w/ OehIhb0oWkOf5BQgadR5Wwp71E1yBcs1yA7707Js= From: Kent Watsen Message-ID: <01000172142e349b-b5a2b343-02d4-43d2-84d9-dd0e42c44cd9-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_106CD682-E94C-49A2-AD73-50E687377732" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 14 May 2020 17:14:32 +0000 In-Reply-To: Cc: "netconf@ietf.org" , "Salz, Rich" To: "Rob Wilton (rwilton)" References: <0100017199cd7580-240a83ae-9934-4af3-a0e3-3b063286059f-000000@email.amazonses.com> <20200421063956.fgczjrjhh6ppjhnp@anna.jacobs.jacobs-university.de> <010001719d195262-4f097864-625d-437f-8e15-a79c4498342e-000000@email.amazonses.com> <010001721019329c-2f818f0f-e2d7-48aa-b513-d4380e88b830-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.05.14-54.240.48.90 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Virtual "hum" for the "key generation" issue discussed at virtual meeting 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, 14 May 2020 17:14:36 -0000 --Apple-Mail=_106CD682-E94C-49A2-AD73-50E687377732 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Rob, > I=E2=80=99m not sure that I have sufficient knowledge to properly = comment on this point: =E2=80=9Cenable apps to create proprietary = identities that work with the standard model=E2=80=9D. > =20 > If feels to me that the ultimate solution here is that the individual = protocols define protocol specific algorithm identities. But it is = unclear to me (i) whether it is helpful for those protocol specific = algorithm identities to derive from a base generic algorithm identity or = not, and (ii) whether it is helpful for those algorithm specific = identities to be able to inherit a base algorithm specific identity. > =20 > As more concrete examples: > (i) Would be helpful for an ssh =E2=80=9Crsa4096=E2=80=9D identity to = derive from =E2=80=9Cssh-asymmetric-algorithm=E2=80=9D which itself = derives from =E2=80=9Casymmetric-algorithm=E2=80=9D? Assuming a future effort mimicked Option #2, then "yes=E2=80=9D, as = I=E2=80=99d expect an "ietf-ssh-common:generate-asymmetric-key=E2=80=9D = RPC to contain an =E2=80=9Cinput=E2=80=9D node that is an identityref to = the =E2=80=9Cssh-asymmetric-algorithm=E2=80=9D identity. > (ii) Or would be helpful for an ssh =E2=80=9Crsa4096=E2=80=9D identity = to derive from both =E2=80=9Cssh-asymmetric-algorithm=E2=80=9D and also = a base cypto =E2=80=9Crsa4096=E2=80=9D identity that derives from = =E2=80=9Casymmetric-algorithm=E2=80=9D? Assuming a future effort mimicked Option #1, then this might make sense. > (iii) Or is it just sufficient to have an ssh =E2=80=9Crsa4096=E2=80=9D = identity derive from a =E2=80=9Cssh-asymmetric-algorithm=E2=80=9D base = identity? Assuming the future effort mimics Option #2 again, this would NOT make = sense, as we=E2=80=99d want the protocol-independent base identity = (e.g., asymmetric-algorithm) so that a protocol-independent identityref = could exist in the "symmetric-key-grouping" and = =E2=80=9Casymmetric-key-pair-grouping=E2=80=9D groupings, which are use = by, e.g., Keystore, which is protocol-independent. > If the answer is (ii) then I think that there is also a further = question as to whether the base =E2=80=9Casymmetric-algorithm=E2=80=9D = identity should be defined in crypto-types.yang or in the IANA registry = defined YANG file that defines the base identities? I didn=E2=80=99t catch the first part, but gist is clear. I think that = defining the protocol-independent base identities in ietf-crypt-types is = safe or, rather not something I=E2=80=99d consider worthy of an IANA = registry. There are very few cryptographic algorithm types and rarely = is a new one defined. > Even if we can figure out what the identity hierarchy should look = like, I=E2=80=99m not sure whether it makes sense to still define the = =E2=80=9Calgorithm=E2=80=9D leaf nodes in the groupings. If they are = only really truly required for the key generation rpcs then perhaps they = are not required in the other places at all. TL;DR; It seems okay to drop the =E2=80=9Calgorithm=E2=80=9D node from = the "symmetric-key-grouping" and =E2=80=9Casymmetric-key-pair-grouping=E2=80= =9D groupings. The UI experience isn=E2=80=99t overly compromised, and = the security is the same. Think about this from a device administrator=E2=80=99s perspective using = CLI or a GUI interface looking at a screen presenting the contents of = the Keystore. If the UI logic is smart enough, almost in all cases, it = can extract a suitable algorithm identifier from the binary key = directly. That is, most of the "key formats=E2=80=9D embed an = identifier inside the binary structure. The only case where this is not = true is for symmetric keys that are configured using Octet Strings, = which are generally more common than using the OneSymmetricKey format. =20= The Octet String format is literally just a block a random bytes for the = symmetric key; the only metadata that can be extracted from an Octet = String is its length, but it is unknown if, e.g., a 24-byte octet string = is being used for AES-256 or ChaCha20-Poly1305. So, in this case, the = UI could only at best display the symmetric key=E2=80=99s length. That said, in general, all symmetric and asymmetric keys SHOULD be = encrypted by the public part of a =E2=80=9Chidden=E2=80=9D asymmetric = key (e.g., a built-in IDevID cert), in which case the encrypted keys = would HAVE to use the OneSymmetricKey and OneAsymmetricKey formats, = respectively=E2=80=A6and thus the UI experience could always be good. =20= In case this best practice is not followed (i.e.,the keys are NOT = encrypted), then the server would have to entirely rely on access = control (e.g., NACM) to protect the keys from accidental disclosure. = But that=E2=80=99s just the way it is, and how I imagine it is = implemented on most equipment out there. > At the moment, I=E2=80=99m leaning towards leaving this out, and = solving this in the future. If we don=E2=80=99t put anything in, then = we can=E2=80=99t accidentally constrain a future solution. Okay. > Rob > // As an individual contributor Kent // contributor --Apple-Mail=_106CD682-E94C-49A2-AD73-50E687377732 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Rob,


I=E2=80=99m not sure that I have sufficient knowledge to = properly comment on this point: =E2=80=9Cenable apps to create proprietary identities = that work with the standard model=E2=80=9D.
 
If feels to me that = the ultimate solution here is that the individual protocols define = protocol specific algorithm identities.  But it is unclear to me = (i) whether it is helpful for those protocol specific algorithm = identities to derive from a base generic algorithm identity or not, and = (ii) whether it is helpful for those algorithm specific identities to be = able to inherit a base algorithm specific identity.
 
As more concrete examples:
(i) Would be helpful for an ssh =E2=80=9Crsa4096=E2=80=9D = identity to derive from =E2=80=9Cssh-asymmetric-algorithm=E2=80=9D which = itself derives from = =E2=80=9Casymmetric-algorithm=E2=80=9D?

Assuming a future effort mimicked = Option #2, then "yes=E2=80=9D, as I=E2=80=99d expect an = "ietf-ssh-common:generate-asymmetric-key=E2=80=9D RPC to contain an = =E2=80=9Cinput=E2=80=9D node that is an identityref to the = =E2=80=9Cssh-asymmetric-algorithm=E2=80=9D identity.


(ii) Or would be helpful for an ssh =E2=80=9Crsa4096=E2=80=9D = identity to derive from both =E2=80=9Cssh-asymmetric-algorithm=E2=80=9D = and also a base cypto =E2=80=9Crsa4096=E2=80=9D identity that derives = from = =E2=80=9Casymmetric-algorithm=E2=80=9D?

Assuming a future effort mimicked = Option #1, then this might make sense.


(iii) Or is it just sufficient to have an ssh =E2=80=9Crsa4096=E2= =80=9D identity derive from a =E2=80=9Cssh-asymmetric-algorithm=E2=80=9D = base identity?

Assuming the future effort mimics Option #2 again, = this would NOT make sense, as we=E2=80=99d want the protocol-independent = base identity (e.g., asymmetric-algorithm) so that a = protocol-independent identityref could exist in the = "symmetric-key-grouping" and =E2=80=9Casymmetric-key-pair-grouping=E2=80=9D= groupings, which are use by, e.g., Keystore, which is = protocol-independent.


If the answer is (ii) then I think that = there is also a further question as to whether the base = =E2=80=9Casymmetric-algorithm=E2=80=9D identity should be defined in = crypto-types.yang or in the IANA registry defined YANG file that defines = the base identities?

I didn=E2=80=99t catch the first part, but gist is = clear.  I think that defining the protocol-independent base = identities in ietf-crypt-types is safe or, rather not something I=E2=80=99= d consider worthy of an IANA registry.  There are very few = cryptographic algorithm types and rarely is a new one = defined.


Even if we can figure out what the = identity hierarchy should look like, I=E2=80=99m not sure whether it = makes sense to still define the =E2=80=9Calgorithm=E2=80=9D leaf nodes = in the groupings.  If they are only really truly required for the = key generation rpcs then perhaps they are not required in the other = places at all.

TL;DR;   It seems okay to drop the = =E2=80=9Calgorithm=E2=80=9D node from the "symmetric-key-grouping" and = =E2=80=9Casymmetric-key-pair-grouping=E2=80=9D groupings.  The UI = experience isn=E2=80=99t overly compromised, and the security is the = same.

Think about = this from a device administrator=E2=80=99s perspective using CLI or a = GUI interface looking at a screen presenting the contents of the = Keystore.  If the UI logic is smart enough, almost in all cases, it = can extract a suitable algorithm identifier from the binary key = directly.  That is, most of the "key formats=E2=80=9D embed an = identifier inside the binary structure.  The only case where this = is not true is for symmetric keys that are configured using Octet = Strings, which are generally more common than using the OneSymmetricKey = format.  

The Octet String = format is literally just a block a random bytes for the symmetric key; = the only metadata that can be extracted from an Octet String is its = length, but it is unknown if, e.g., a 24-byte octet string is being used = for AES-256 or ChaCha20-Poly1305.  So, in this case, the UI = could only at best display the symmetric key=E2=80=99s length.

That said, in general, all = symmetric and asymmetric keys SHOULD be encrypted by the public = part of a =E2=80=9Chidden=E2=80=9D asymmetric key (e.g., a built-in = IDevID cert), in which case the encrypted keys would HAVE to use the = OneSymmetricKey and OneAsymmetricKey formats, respectively=E2=80=A6and = thus the UI experience could always be good.  

In case this best practice is not followed = (i.e.,the keys are NOT encrypted), then the server would have to = entirely rely on access control (e.g., NACM) to protect the keys from = accidental disclosure.  But that=E2=80=99s just the way it is, and = how I imagine it is implemented on most equipment out = there.


At the moment,  I=E2=80=99m leaning towards leaving this = out, and solving this in the future.  If we don=E2=80=99t put = anything in, then we can=E2=80=99t accidentally constrain a future = solution.

Okay.


Rob
// As an individual = contributor

Kent = // contributor



= --Apple-Mail=_106CD682-E94C-49A2-AD73-50E687377732-- From nobody Wed May 20 13:58:35 2020 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 EE4383A0746; Wed, 20 May 2020 13:58:23 -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: 7.0.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159000830389.7518.9321011403538913214@ietfa.amsl.com> Date: Wed, 20 May 2020 13:58:23 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-crypto-types-15.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, 20 May 2020 20:58:31 -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 : Common YANG Data Types for Cryptography Author : Kent Watsen Filename : draft-ietf-netconf-crypto-types-15.txt Pages : 38 Date : 2020-05-20 Abstract: This document presents a YANG 1.1 (RFC 7950) module defining identities, typedefs, and groupings useful to cryptographic applications. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "AAAA" --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2020-05-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix B. Change Log Note to Reviewers (To be removed by RFC Editor) This document presents a YANG module or modules that is/are part of a collection of drafts that work together to produce the ultimate goal of the NETCONF WG: to define configuration modules for NETCONF client and servers, and RESTCONF client and servers. The relationship between the various drafts in the collection is presented in the below diagram. crypto-types ^ ^ / \ / \ trust-anchors keystore ^ ^ ^ ^ | +---------+ | | | | | | | +------------+ | tcp-client-server | / | | ^ ^ ssh-client-server | | | | ^ tls-client-server | | | ^ ^ http-client-server | | | | | ^ | | | +-----+ +---------+ | | | | | | | | +-----------|--------|--------------+ | | | | | | | | +-----------+ | | | | | | | | | | | | | | | | | netconf-client-server restconf-client-server Full draft names and link to drafts: o draft-ietf-netconf-crypto-types (html [1]) o draft-ietf-netconf-trust-anchors (html [2]) o draft-ietf-netconf-keystore (html [3]) o draft-ietf-netconf-tcp-client-server (html [4]) o draft-ietf-netconf-ssh-client-server (html [5]) o draft-ietf-netconf-tls-client-server (html [6]) o draft-ietf-netconf-http-client-server (html [7]) o draft-ietf-netconf-netconf-client-server (html [8]) o draft-ietf-netconf-restconf-client-server (html [9]) The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-crypto-types/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-15 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-crypto-types-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-crypto-types-15 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 Wed May 20 14:02:51 2020 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 BB6E43A0029; Wed, 20 May 2020 14:02:48 -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: 7.0.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159000856868.7604.2794650927577489954@ietfa.amsl.com> Date: Wed, 20 May 2020 14:02:48 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-trust-anchors-10.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, 20 May 2020 21:02:49 -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 : A YANG Data Model for a Truststore Author : Kent Watsen Filename : draft-ietf-netconf-trust-anchors-10.txt Pages : 26 Date : 2020-05-20 Abstract: This document defines a YANG 1.1 data model for configuring globally- accessible bags of certificates and public keys that can be referenced by other data models for trust. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types o "BBBB" --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2020-05-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix A. Change Log Note to Reviewers (To be removed by RFC Editor) This document presents a YANG module or modules that is/are part of a collection of drafts that work together to produce the ultimate goal of the NETCONF WG: to define configuration modules for NETCONF client and servers, and RESTCONF client and servers. The relationship between the various drafts in the collection is presented in the below diagram. crypto-types ^ ^ / \ / \ trust-anchors keystore ^ ^ ^ ^ | +---------+ | | | | | | | +------------+ | tcp-client-server | / | | ^ ^ ssh-client-server | | | | ^ tls-client-server | | | ^ ^ http-client-server | | | | | ^ | | | +-----+ +---------+ | | | | | | | | +-----------|--------|--------------+ | | | | | | | | +-----------+ | | | | | | | | | | | | | | | | | netconf-client-server restconf-client-server Full draft names and link to drafts: o draft-ietf-netconf-crypto-types (html [1]) o draft-ietf-netconf-trust-anchors (html [2]) o draft-ietf-netconf-keystore (html [3]) o draft-ietf-netconf-tcp-client-server (html [4]) o draft-ietf-netconf-ssh-client-server (html [5]) o draft-ietf-netconf-tls-client-server (html [6]) o draft-ietf-netconf-http-client-server (html [7]) o draft-ietf-netconf-netconf-client-server (html [8]) o draft-ietf-netconf-restconf-client-server (html [9]) The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-trust-anchors/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-10 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-trust-anchors-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-trust-anchors-10 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 Wed May 20 14:03:50 2020 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 E25783A07AA; Wed, 20 May 2020 14:03:39 -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: 7.0.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159000861988.9523.12593648880240959103@ietfa.amsl.com> Date: Wed, 20 May 2020 14:03:39 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-keystore-17.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, 20 May 2020 21:03:46 -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 : A YANG Data Model for a Keystore Author : Kent Watsen Filename : draft-ietf-netconf-keystore-17.txt Pages : 42 Date : 2020-05-20 Abstract: This document defines a YANG 1.1 module called "ietf-keystore" that enables centralized configuration of both symmetric and asymmetric keys. The secret value for both key types may be encrypted. Asymmetric keys may be associated with certificates. Notifications are sent when certificates are about to expire. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types o "CCCC" --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2020-05-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix A. Change Log Note to Reviewers (To be removed by RFC Editor) This document presents a YANG module or modules that is/are part of a collection of drafts that work together to produce the ultimate goal of the NETCONF WG: to define configuration modules for NETCONF client and servers, and RESTCONF client and servers. The relationship between the various drafts in the collection is presented in the below diagram. crypto-types ^ ^ / \ / \ trust-anchors keystore ^ ^ ^ ^ | +---------+ | | | | | | | +------------+ | tcp-client-server | / | | ^ ^ ssh-client-server | | | | ^ tls-client-server | | | ^ ^ http-client-server | | | | | ^ | | | +-----+ +---------+ | | | | | | | | +-----------|--------|--------------+ | | | | | | | | +-----------+ | | | | | | | | | | | | | | | | | netconf-client-server restconf-client-server Full draft names and link to drafts: o draft-ietf-netconf-crypto-types (html [1]) o draft-ietf-netconf-trust-anchors (html [2]) o draft-ietf-netconf-keystore (html [3]) o draft-ietf-netconf-tcp-client-server (html [4]) o draft-ietf-netconf-ssh-client-server (html [5]) o draft-ietf-netconf-tls-client-server (html [6]) o draft-ietf-netconf-http-client-server (html [7]) o draft-ietf-netconf-netconf-client-server (html [8]) o draft-ietf-netconf-restconf-client-server (html [9]) The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-keystore/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-keystore-17 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-keystore-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-keystore-17 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 Wed May 20 14:05:31 2020 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 55FF43A0064; Wed, 20 May 2020 14:05:25 -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: 7.0.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159000872529.32380.2292793364276227749@ietfa.amsl.com> Date: Wed, 20 May 2020 14:05:25 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-tcp-client-server-05.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, 20 May 2020 21:05:26 -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 Groupings for TCP Clients and TCP Servers Authors : Kent Watsen Michael Scharf Filename : draft-ietf-netconf-tcp-client-server-05.txt Pages : 20 Date : 2020-05-20 Abstract: This document defines three YANG modules: the first defines a grouping for configuring a generic TCP client, the second defines a grouping for configuring a generic TCP server, and the third defines a grouping common to the TCP clients and TCP servers. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "DDDD" --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2020-05-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix A. Change Log Note to Reviewers (To be removed by RFC Editor) This document presents a YANG module or modules that is/are part of a collection of drafts that work together to produce the ultimate goal of the NETCONF WG: to define configuration modules for NETCONF client and servers, and RESTCONF client and servers. The relationship between the various drafts in the collection is presented in the below diagram. crypto-types ^ ^ / \ / \ trust-anchors keystore ^ ^ ^ ^ | +---------+ | | | | | | | +------------+ | tcp-client-server | / | | ^ ^ ssh-client-server | | | | ^ tls-client-server | | | ^ ^ http-client-server | | | | | ^ | | | +-----+ +---------+ | | | | | | | | +-----------|--------|--------------+ | | | | | | | | +-----------+ | | | | | | | | | | | | | | | | | netconf-client-server restconf-client-server Full draft names and link to drafts: o draft-ietf-netconf-crypto-types (html [1]) o draft-ietf-netconf-trust-anchors (html [2]) o draft-ietf-netconf-keystore (html [3]) o draft-ietf-netconf-tcp-client-server (html [4]) o draft-ietf-netconf-ssh-client-server (html [5]) o draft-ietf-netconf-tls-client-server (html [6]) o draft-ietf-netconf-http-client-server (html [7]) o draft-ietf-netconf-netconf-client-server (html [8]) o draft-ietf-netconf-restconf-client-server (html [9]) The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-tcp-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-05 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tcp-client-server-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-tcp-client-server-05 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 Wed May 20 14:06:27 2020 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 04A923A00B2; Wed, 20 May 2020 14:06:26 -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: 7.0.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159000878597.20730.1916805489208973980@ietfa.amsl.com> Date: Wed, 20 May 2020 14:06:26 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-ssh-client-server-19.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, 20 May 2020 21:06:26 -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 Groupings for SSH Clients and SSH Servers Authors : Kent Watsen Gary Wu Filename : draft-ietf-netconf-ssh-client-server-19.txt Pages : 55 Date : 2020-05-20 Abstract: This document defines three YANG modules: the first defines groupings for a generic SSH client, the second defines groupings for a generic SSH server, and the third defines common identities and groupings used by both the client and the server. It is intended that these groupings will be used by applications using the SSH protocol. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types o "BBBB" --> the assigned RFC value for draft-ietf-netconf-trust- anchors o "CCCC" --> the assigned RFC value for draft-ietf-netconf-keystore o "DDDD" --> the assigned RFC value for draft-ietf-netconf-tcp- client-server o "EEEE" --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2020-05-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix A. Change Log Note to Reviewers (To be removed by RFC Editor) This document presents a YANG module or modules that is/are part of a collection of drafts that work together to produce the ultimate goal of the NETCONF WG: to define configuration modules for NETCONF client and servers, and RESTCONF client and servers. The relationship between the various drafts in the collection is presented in the below diagram. crypto-types ^ ^ / \ / \ trust-anchors keystore ^ ^ ^ ^ | +---------+ | | | | | | | +------------+ | tcp-client-server | / | | ^ ^ ssh-client-server | | | | ^ tls-client-server | | | ^ ^ http-client-server | | | | | ^ | | | +-----+ +---------+ | | | | | | | | +-----------|--------|--------------+ | | | | | | | | +-----------+ | | | | | | | | | | | | | | | | | netconf-client-server restconf-client-server Full draft names and link to drafts: o draft-ietf-netconf-crypto-types (html [1]) o draft-ietf-netconf-trust-anchors (html [2]) o draft-ietf-netconf-keystore (html [3]) o draft-ietf-netconf-tcp-client-server (html [4]) o draft-ietf-netconf-ssh-client-server (html [5]) o draft-ietf-netconf-tls-client-server (html [6]) o draft-ietf-netconf-http-client-server (html [7]) o draft-ietf-netconf-netconf-client-server (html [8]) o draft-ietf-netconf-restconf-client-server (html [9]) The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-ssh-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-19 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-ssh-client-server-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-ssh-client-server-19 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 Wed May 20 14:08:06 2020 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 1D03E3A003D; Wed, 20 May 2020 14:08:04 -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: 7.0.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159000888398.7604.5737693138612053609@ietfa.amsl.com> Date: Wed, 20 May 2020 14:08:04 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-tls-client-server-19.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, 20 May 2020 21:08:04 -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 Groupings for TLS Clients and TLS Servers Authors : Kent Watsen Gary Wu Filename : draft-ietf-netconf-tls-client-server-19.txt Pages : 51 Date : 2020-05-20 Abstract: This document defines three YANG modules: the first defines groupings for a generic TLS client, the second defines groupings for a generic TLS server, and the third defines common identities and groupings used by both the client and the server. It is intended that these groupings will be used by applications using the TLS protocol. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types o "BBBB" --> the assigned RFC value for draft-ietf-netconf-trust- anchors o "CCCC" --> the assigned RFC value for draft-ietf-netconf-keystore o "DDDD" --> the assigned RFC value for draft-ietf-netconf-tcp- client-server o "FFFF" --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2020-05-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix A. Change Log Note to Reviewers (To be removed by RFC Editor) This document presents a YANG module or modules that is/are part of a collection of drafts that work together to produce the ultimate goal of the NETCONF WG: to define configuration modules for NETCONF client and servers, and RESTCONF client and servers. The relationship between the various drafts in the collection is presented in the below diagram. crypto-types ^ ^ / \ / \ trust-anchors keystore ^ ^ ^ ^ | +---------+ | | | | | | | +------------+ | tcp-client-server | / | | ^ ^ ssh-client-server | | | | ^ tls-client-server | | | ^ ^ http-client-server | | | | | ^ | | | +-----+ +---------+ | | | | | | | | +-----------|--------|--------------+ | | | | | | | | +-----------+ | | | | | | | | | | | | | | | | | netconf-client-server restconf-client-server Full draft names and link to drafts: o draft-ietf-netconf-crypto-types (html [1]) o draft-ietf-netconf-trust-anchors (html [2]) o draft-ietf-netconf-keystore (html [3]) o draft-ietf-netconf-tcp-client-server (html [4]) o draft-ietf-netconf-ssh-client-server (html [5]) o draft-ietf-netconf-tls-client-server (html [6]) o draft-ietf-netconf-http-client-server (html [7]) o draft-ietf-netconf-netconf-client-server (html [8]) o draft-ietf-netconf-restconf-client-server (html [9]) The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-tls-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-19 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tls-client-server-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-tls-client-server-19 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 Wed May 20 14:09:17 2020 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 B135D3A0064; Wed, 20 May 2020 14:09:11 -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: 7.0.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159000895168.24001.2023507517816037650@ietfa.amsl.com> Date: Wed, 20 May 2020 14:09:11 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-http-client-server-03.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, 20 May 2020 21:09:12 -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 Groupings for HTTP Clients and HTTP Servers Author : Kent Watsen Filename : draft-ietf-netconf-http-client-server-03.txt Pages : 19 Date : 2020-05-20 Abstract: This document defines two YANG modules: the first defines a minimal grouping for configuring an HTTP client, and the second defines a minimal grouping for configuring an HTTP server. It is intended that these groupings will be used to help define the configuration for simple HTTP-based protocols (not for complete web servers or browsers). Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements (note: not all may be present): o "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types o "BBBB" --> the assigned RFC value for draft-ietf-netconf-trust- anchors o "CCCC" --> the assigned RFC value for draft-ietf-netconf-keystore o "DDDD" --> the assigned RFC value for draft-ietf-netconf-tcp- client-server o "EEEE" --> the assigned RFC value for draft-ietf-netconf-ssh- client-server o "FFFF" --> the assigned RFC value for draft-ietf-netconf-tls- client-server o "GGGG" --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2020-05-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix A. Change Log Note to Reviewers (To be removed by RFC Editor) This document presents a YANG module or modules that is/are part of a collection of drafts that work together to produce the ultimate goal of the NETCONF WG: to define configuration modules for NETCONF client and servers, and RESTCONF client and servers. The relationship between the various drafts in the collection is presented in the below diagram. crypto-types ^ ^ / \ / \ trust-anchors keystore ^ ^ ^ ^ | +---------+ | | | | | | | +------------+ | tcp-client-server | / | | ^ ^ ssh-client-server | | | | ^ tls-client-server | | | ^ ^ http-client-server | | | | | ^ | | | +-----+ +---------+ | | | | | | | | +-----------|--------|--------------+ | | | | | | | | +-----------+ | | | | | | | | | | | | | | | | | netconf-client-server restconf-client-server Full draft names and link to drafts: o draft-ietf-netconf-crypto-types (html [1]) o draft-ietf-netconf-trust-anchors (html [2]) o draft-ietf-netconf-keystore (html [3]) o draft-ietf-netconf-tcp-client-server (html [4]) o draft-ietf-netconf-ssh-client-server (html [5]) o draft-ietf-netconf-tls-client-server (html [6]) o draft-ietf-netconf-http-client-server (html [7]) o draft-ietf-netconf-netconf-client-server (html [8]) o draft-ietf-netconf-restconf-client-server (html [9]) The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-http-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-03 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-http-client-server-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-http-client-server-03 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 Wed May 20 14:10:36 2020 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 BC91D3A005D; Wed, 20 May 2020 14:10:29 -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: 7.0.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159000902972.7644.12075242978539767660@ietfa.amsl.com> Date: Wed, 20 May 2020 14:10:29 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-netconf-client-server-19.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, 20 May 2020 21:10:30 -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 : NETCONF Client and Server Models Author : Kent Watsen Filename : draft-ietf-netconf-netconf-client-server-19.txt Pages : 98 Date : 2020-05-20 Abstract: This document defines two YANG modules, one module to configure a NETCONF client and the other module to configure a NETCONF server. Both modules support both the SSH and TLS transport protocols, and support both standard NETCONF and NETCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements (note: not all may be present): o "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types o "BBBB" --> the assigned RFC value for draft-ietf-netconf-trust- anchors o "CCCC" --> the assigned RFC value for draft-ietf-netconf-keystore o "DDDD" --> the assigned RFC value for draft-ietf-netconf-tcp- client-server o "EEEE" --> the assigned RFC value for draft-ietf-netconf-ssh- client-server o "FFFF" --> the assigned RFC value for draft-ietf-netconf-tls- client-server o "GGGG" --> the assigned RFC value for draft-ietf-netconf-http- client-server o "HHHH" --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2020-05-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix B. Change Log Note to Reviewers (To be removed by RFC Editor) This document presents a YANG module or modules that is/are part of a collection of drafts that work together to produce the ultimate goal of the NETCONF WG: to define configuration modules for NETCONF client and servers, and RESTCONF client and servers. The relationship between the various drafts in the collection is presented in the below diagram. crypto-types ^ ^ / \ / \ trust-anchors keystore ^ ^ ^ ^ | +---------+ | | | | | | | +------------+ | tcp-client-server | / | | ^ ^ ssh-client-server | | | | ^ tls-client-server | | | ^ ^ http-client-server | | | | | ^ | | | +-----+ +---------+ | | | | | | | | +-----------|--------|--------------+ | | | | | | | | +-----------+ | | | | | | | | | | | | | | | | | netconf-client-server restconf-client-server Full draft names and link to drafts: o draft-ietf-netconf-crypto-types (html [1]) o draft-ietf-netconf-trust-anchors (html [2]) o draft-ietf-netconf-keystore (html [3]) o draft-ietf-netconf-tcp-client-server (html [4]) o draft-ietf-netconf-ssh-client-server (html [5]) o draft-ietf-netconf-tls-client-server (html [6]) o draft-ietf-netconf-http-client-server (html [7]) o draft-ietf-netconf-netconf-client-server (html [8]) o draft-ietf-netconf-restconf-client-server (html [9]) The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-netconf-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-19 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-netconf-client-server-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-netconf-client-server-19 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 Wed May 20 14:11:33 2020 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 79C043A0063; Wed, 20 May 2020 14:11:28 -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: 7.0.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netconf@ietf.org Message-ID: <159000908846.7518.4424215065271178026@ietfa.amsl.com> Date: Wed, 20 May 2020 14:11:28 -0700 Archived-At: Subject: [netconf] I-D Action: draft-ietf-netconf-restconf-client-server-19.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, 20 May 2020 21:11:29 -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 : RESTCONF Client and Server Models Author : Kent Watsen Filename : draft-ietf-netconf-restconf-client-server-19.txt Pages : 93 Date : 2020-05-20 Abstract: This document defines two YANG modules, one module to configure a RESTCONF client and the other module to configure a RESTCONF server. Both modules support the TLS transport protocol with both standard RESTCONF and RESTCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements (note: not all may be present): o "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- types o "BBBB" --> the assigned RFC value for draft-ietf-netconf-trust- anchors o "CCCC" --> the assigned RFC value for draft-ietf-netconf-keystore o "DDDD" --> the assigned RFC value for draft-ietf-netconf-tcp- client-server o "EEEE" --> the assigned RFC value for draft-ietf-netconf-ssh- client-server o "FFFF" --> the assigned RFC value for draft-ietf-netconf-tls- client-server o "GGGG" --> the assigned RFC value for draft-ietf-netconf-http- client-server o "HHHH" --> the assigned RFC value for draft-ietf-netconf-netconf- client-server o "IIII" --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: o "2020-05-20" --> the publication date of this draft The following Appendix section is to be removed prior to publication: o Appendix B. Change Log Note to Reviewers (To be removed by RFC Editor) This document presents a YANG module or modules that is/are part of a collection of drafts that work together to produce the ultimate goal of the NETCONF WG: to define configuration modules for NETCONF client and servers, and RESTCONF client and servers. The relationship between the various drafts in the collection is presented in the below diagram. crypto-types ^ ^ / \ / \ trust-anchors keystore ^ ^ ^ ^ | +---------+ | | | | | | | +------------+ | tcp-client-server | / | | ^ ^ ssh-client-server | | | | ^ tls-client-server | | | ^ ^ http-client-server | | | | | ^ | | | +-----+ +---------+ | | | | | | | | +-----------|--------|--------------+ | | | | | | | | +-----------+ | | | | | | | | | | | | | | | | | netconf-client-server restconf-client-server Full draft names and link to drafts: o draft-ietf-netconf-crypto-types (html [1]) o draft-ietf-netconf-trust-anchors (html [2]) o draft-ietf-netconf-keystore (html [3]) o draft-ietf-netconf-tcp-client-server (html [4]) o draft-ietf-netconf-ssh-client-server (html [5]) o draft-ietf-netconf-tls-client-server (html [6]) o draft-ietf-netconf-http-client-server (html [7]) o draft-ietf-netconf-netconf-client-server (html [8]) o draft-ietf-netconf-restconf-client-server (html [9]) The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-19 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-restconf-client-server-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-client-server-19 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 Wed May 20 14:30:22 2020 Return-Path: <0100017233fe7ff7-8e22b4b1-aa03-4c8e-bf9d-fdbc7d3e41fd-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 A68DC3A00D5 for ; Wed, 20 May 2020 14:30:19 -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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 BeQCfqAy798q for ; Wed, 20 May 2020 14:30:18 -0700 (PDT) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCC1B3A00D2 for ; Wed, 20 May 2020 14:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1590010216; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=YFz17zzAFiiGJ34gTApGgdApbrj8WQPjEwKTWDDbl0Q=; b=Gxq9gkXpi71VCeBlTlOjBnVTIQGBQOxURoSeqfOeQg0YsUNqjJ9hNRtjhaEh/V4o v/P1VWpe+Fz+VJYJtSBY4vywJCurZ8NEBcYPb+cDKl7pajmswc4kqIHhwVh4o86M38Q AQS5lMvKdJCKX7imzgdMDwG6GiksIENMHcU6ScXw= From: Kent Watsen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-ID: <0100017233fe7ff7-8e22b4b1-aa03-4c8e-bf9d-fdbc7d3e41fd-000000@email.amazonses.com> Date: Wed, 20 May 2020 21:30:16 +0000 To: "netconf@ietf.org" X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.05.20-54.240.48.90 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: [netconf] Today's update to client-server drafts 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, 20 May 2020 21:30:20 -0000 The entire suite of drafts were updated today. The first three drafts are ready for WGLC. All of the other drafts are almost ready for WGLC. Below is the Change Log entry for each draft. K. For all drafts: o Added a "Note to Reviewers" note to first page. For crypto-types: o Removed the IANA-maintained registries for symmetric, asymmetric, and hash algorithms. o Removed the "generate-symmetric-key" and "generate-asymmetric-key" RPCs. o Removed the "algorithm" node in the various symmetric and asymmetric key groupings. o Added 'typedef csr' and 'feature certificate-signing-request- generation'. o Refined a usage of "end-entity-cert-grouping" to make the "cert" node mandatory true. For trust-anchors: o Removed "algorithm" node from examples. o Removed the no longer used statements supporting the old "ssh- public-key" and "raw-public-key" nodes. For keystore: o Removed augments to the "generate-symmetric-key" and "generate- asymmetric-key" groupings. o Removed "generate-symmetric-key" and "generate-asymmetric-key" examples. o Removed the "algorithm" nodes from remaining examples. o Renamed/updated the "Support for Built-in Keys" section. o Added new section "Encrypting Keys in Configuration". For tcp-client-server: o Removed commented out "grouping tcp-system-grouping" statement kept for reviewers. For ssh-client-server: o Updated the "keepalives" containers to address Michal Vasko's request to align with RFC 8071 o Removed algorithm-mapping tables from the "SSH Common Model" section o Removed 'algorithm' node from examples. o Added feature "client-identity-publickey" o Removed "choice auth-type", as auth-types aren't exclusive. o Renamed both "client-certs" and "server-certs" to "ee-certs" o Switch "must" to assert the public-key-format is "subject-public- key-info-format" when certificates are used. For tls-client-server: o Updated the "keepalives" containers in part to address Michal Vasko's request to align with RFC 8071 and in part to better = align to RFC 6520 o Removed algorithm-mapping tables from the "TLS Common Model" section o Removed the 'algorithm' node from the examples. o Renamed both "client-certs" and "server-certs" to "ee-certs" For http-client-server: o Removed "protocol-versions" from ietf-http-server based on HTTP WG feedback. o Slightly restructured the "proxy-server" definition in ietf-http- client. o Added http-client example show proxy server use. For netconf-client-server: o Updated examples to remove the 'algorithm' nodes. o Updated examples to reflect the new TLS keepalives structure. o Added keepalives to the tcp-client-parameters section in the netconf-server SSH-based call-home example. o Added a TLS-based call-home example to the netconf-client example. For restonf-client-server: o Updated examples to remove the 'algorithm' nodes. o Updated examples to reflect the new TLS keepalives structure. o Removed the 'protocol-versions' node from the restconf-server examples. From nobody Thu May 21 05:24:15 2020 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 928ED3A0C4C; Thu, 21 May 2020 05:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 8UKNvN_OnkLf; Thu, 21 May 2020 05:24:01 -0700 (PDT) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 716C93A0C5E; Thu, 21 May 2020 05:24:01 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id n11so6870836ilj.4; Thu, 21 May 2020 05:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=lvAwneA5+fJuA2DxRoC6V6T12mwwRmQVz5MYQ4IJg+c=; b=iGyB46BbFxMZSIgb7IcSNCUVSjC5LjLRHcXggBxcnJ5Jg+4YUwQKYHsnBIYOLDHe8R 72NAbY4YfMX75ThzeGchOF7MzJk7nM0rlWrx2u5mpYp6oQnVbbkYrdexP6dLPK0Spe5b AEVoRHte4P59IPguGLNUmurt9EkSi7Ub/pwRP7JXsmLxcrUshMi0hCtowyYTEIsOKnEg WtVgaLObmWKmDHZ3hmnfVwts0TJ1+MwR/SAYfcarAK3ZEl2bgBpiPxwnghS8LAapkyF1 kJga7Zf5dsDWz4RhshWMuAornp6MiCU+sCG4BcyvtkiKw+0lHughWjDXZTQ1dwfTl8EM 27Xw== 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=lvAwneA5+fJuA2DxRoC6V6T12mwwRmQVz5MYQ4IJg+c=; b=dtwDFDPimcaVv6a4TCI+kLf9Hapo9GFCKjhf/CgC749Ofv3j8ovR2rV1o+rfb/xqrT ThqpSZjb1pbjq9jxuSIGsuOPdUKjm+e9BX7Awr7Bb0wlh2zlh7ddlhQCMkzeDVreUV7X I9QzjZhzQSE8YDRwDBnjSz0OHMPfkksFzPkPq/pF/2dGX8UzeCxvVsfP8kAHYENm5Ai2 pz9p37k6qIli65fOYyHFpZToiY+qAM5w8jdAp0WaSOU2DfMvVNMdnLIOoiKhulzEsPON PNA84NZHzI5lBejhyJ+gDVyoZluHITDntvuCJvyLX09Z8AiA26jezA4gyBo0P8vqFL+D dGIA== X-Gm-Message-State: AOAM532tOb3KdEtKmoxC4FQhQZd11KEiVbG0Y+iYO3XWI1YoIqkmo96I gCFAzOW/ISDrCoUhgrPbRR3S5JCU5Xar0e8G61ENh3oE X-Google-Smtp-Source: ABdhPJxbt/NfTvxT0T2WHR2FE2CVOmGMut5H1LX3s5JYNr3CId2pkWIB7Hlb0Uw6IO/A4Y150EaLdTnH41qi0En3hNk= X-Received: by 2002:a92:584b:: with SMTP id m72mr8090973ilb.119.1590063840184; Thu, 21 May 2020 05:24:00 -0700 (PDT) MIME-Version: 1.0 From: Xufeng Liu Date: Thu, 21 May 2020 08:23:49 -0400 Message-ID: To: netconf , NETMOD WG Content-Type: multipart/alternative; boundary="0000000000005d4c0a05a627961e" Archived-At: Subject: [netconf] operation with "table join" capability 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, 21 May 2020 12:24:12 -0000 --0000000000005d4c0a05a627961e Content-Type: text/plain; charset="UTF-8" During the modeling discussion within TEAS WG, we encountered the dilemma between more compact (with less or no redundant information) YANG structure and less operations. We are wondering if it is reasonable to request NETCONF/YANG to support operations with "table join" capability that is equivalent to the SQL "JOIN" statement. The issue is reported as the last section in https://github.com/tsaad-dev/te/issues/98. The desired capability is: When a leafref or multiple leafrefs reference one or more objects specified in other parts of the schema, the operator can use a single operation to retrieve all attributes of the object containing the leafref and the attributes referenced by the leafref statement. Thanks, - Xufeng --0000000000005d4c0a05a627961e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
During the modeling discussion within TEAS WG, we enc= ountered the dilemma between more compact (with less or no redundant inform= ation) YANG structure and less <get-data> operations. We are wonderin= g if it is reasonable to request NETCONF/YANG to support <get-data> o= perations with "table join" capability that is equivalent to the = SQL "JOIN" statement.

The issue is repor= ted as the last section in https://github.com/tsaad-dev/te/issues/98.

The desired capability is:

When a leafref or mu= ltiple leafrefs reference one or more objects specified in other parts of t= he schema, the operator can use a single <get-data> operation to retr= ieve all attributes of the object containing the leafref and the attributes= referenced by the leafref statement.

Thanks,
- Xufeng

--0000000000005d4c0a05a627961e-- From nobody Thu May 21 06:36:30 2020 Return-Path: <010001723773049b-332a2a2d-cee5-4336-9e24-db1b42f83c7a-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 488BF3A0CB1; Thu, 21 May 2020 06:36:27 -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_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 8buQnbOXxaE7; Thu, 21 May 2020 06:36:26 -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 E1EFB3A0CAE; Thu, 21 May 2020 06:36:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1590068184; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Message-Id:References:To:Feedback-ID; bh=ZRlOK358QGvHfhATeBQ1vposzjU4eZuAr87Ojud5tiA=; b=V0vX8f8uanso8nAg1sZeHVAnh7NjSWlEE1PJbbqAonLlz1qyfrOREEX9qDUqDhZU Vv2oTGKHlC1AQ51Z+BeO1C7KCNbnU0TSFqYehwfIX1mnNpAayhKv5r3hGjBjNtSVWrH Nfnuvf39Rx8LuyL9P+EQN+ENnS2JTq9C25OP7KC0= Content-Type: multipart/alternative; boundary="Apple-Mail=_7783230F-8EAA-4721-8EB2-67B56FF6C902" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Kent Watsen In-Reply-To: Date: Thu, 21 May 2020 13:36:24 +0000 Cc: "netconf@ietf.org" Message-ID: <010001723773049b-332a2a2d-cee5-4336-9e24-db1b42f83c7a-000000@email.amazonses.com> References: To: Xufeng Liu X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.05.21-54.240.8.33 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] [netmod] operation with "table join" capability 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, 21 May 2020 13:36:27 -0000 --Apple-Mail=_7783230F-8EAA-4721-8EB2-67B56FF6C902 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [moving 'netmod' to BCC since this question has no modeling impact] > The desired capability is: >=20 > When a leafref or multiple leafrefs reference one or more objects = specified in other parts of the schema, the operator can use a single = operation to retrieve all attributes of the object containing = the leafref and the attributes referenced by the leafref statement. The motivation is clear. A solution would likely entail returning a multi-part response, perhaps = a single tree for NETCONF. Note that the resolutions may themselves = include leafrefs, a full-response may be N levels deep. =20 K. --Apple-Mail=_7783230F-8EAA-4721-8EB2-67B56FF6C902 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii [moving 'netmod' to BCC since this question has no modeling = impact]


The desired = capability is:

When a leafref or multiple leafrefs reference one or more = objects specified in other parts of the schema, the operator can use a = single <get-data> operation to retrieve all attributes of the = object containing the leafref and the attributes referenced by the = leafref statement.

The motivation is clear.

A solution would likely entail returning a multi-part = response, perhaps a single tree for NETCONF.   Note that the = resolutions may themselves include leafrefs, a full-response may be N = levels deep.   

K.

= --Apple-Mail=_7783230F-8EAA-4721-8EB2-67B56FF6C902-- From nobody Thu May 21 22:14:23 2020 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 2D84C3A0EB5 for ; Thu, 21 May 2020 22:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 tA8UzVFKpc5P for ; Thu, 21 May 2020 22:14:19 -0700 (PDT) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 C8AC53A0EAF for ; Thu, 21 May 2020 22:14:19 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id u5so4482772pgn.5 for ; Thu, 21 May 2020 22:14: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:cc :content-transfer-encoding:message-id:references:to; bh=9fgz+RhYrfvSew7ZZyZq4OVlWBEf9aeqhrSIS9645vE=; b=J++IBi1QgpairzyUbDq1ULdVV2+zCFWKZ8A73Ru7HEhG0V121fiJL9waFTZReDkMXp UvlgxJ2oNFQysZaAdmKom6tOluvbQX4/o2krUjx9A3xkB/winGlV9fwTLmGbRzwVElde pgf508/fi0Vrcuig6Y7j4o339kXYe6GI+dovVXqy7v5JWu6INgXs2eaX9r8nrkHVbbf+ uW/BQVUN4SaBjjUoF0gfSRfyBcbjDn601YHPokFhCxlPCCEw6/hTqv7MwkRQ2nsnKkqY 8MNHdv7K28kCo6uuEoxDO/KjTI+hVR27g6OPNXJNLo/atXk/j2T4Od1mYAuoDEwuFAoc kNng== 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:cc :content-transfer-encoding:message-id:references:to; bh=9fgz+RhYrfvSew7ZZyZq4OVlWBEf9aeqhrSIS9645vE=; b=A+P9zDm+Dk41Q9EqG88Q7Glby/BogJ4SYdvUtEWFSheZ256SNFFIXlBsrgCQsAoE63 yaYpw8qk/XEWaGZ8Lb5IJgMuyjfkxHUYWW7Zt+6K7FdXM64fu504G8HN+u139XD+ZVsf IPshkGLmGtzwxFsOvNLsvdRDYlpcV2QTJp/2cA3HPOoPYEcf9d+1s7eXOl/GNQ7xwzK7 NGSQ+jlb9e0XsBzvFvjt3en0jjhXLJDtZi6ICLuhcknedAaEPSreBzBtmAwvSARdu4+L B+UVHfLyNPZxIpRuwlEWsZChCX9GkZVY8TPu8eGwEJ8zoFfgijDf6cL3y8pHDASVgKUp AIGw== X-Gm-Message-State: AOAM531eyB7gOarKSo+fDs/hhm/dnKrB0h/YAoMvKCtelbClrx44xWVf cD6+kxooWeP6q8Bmdive0I4= X-Google-Smtp-Source: ABdhPJwzSTWobdjuvRWmxtEYYyADDtSwckoA80wmp4jWidyFx8GEJaydmliWvsiKLr6SE+9XvoO6Jg== X-Received: by 2002:a63:6747:: with SMTP id b68mr12200658pgc.142.1590124459139; Thu, 21 May 2020 22:14:19 -0700 (PDT) Received: from ?IPv6:2601:647:5600:5020:4166:baf0:1c22:47d9? ([2601:647:5600:5020:4166:baf0:1c22:47d9]) by smtp.gmail.com with ESMTPSA id m5sm98024pga.3.2020.05.21.22.14.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 May 2020 22:14:18 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) From: Mahesh Jethanandani In-Reply-To: <0100017233fe7ff7-8e22b4b1-aa03-4c8e-bf9d-fdbc7d3e41fd-000000@email.amazonses.com> Date: Thu, 21 May 2020 22:14:04 -0700 Cc: "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <85A8ECA9-8875-45FA-839B-50CE35F6C8BA@gmail.com> References: <0100017233fe7ff7-8e22b4b1-aa03-4c8e-bf9d-fdbc7d3e41fd-000000@email.amazonses.com> To: Kent Watsen X-Mailer: Apple Mail (2.3445.9.5) Archived-At: Subject: Re: [netconf] Today's update to client-server drafts 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, 22 May 2020 05:14:22 -0000 What would it take to get the remaining drafts into WGLC? > On May 20, 2020, at 2:30 PM, Kent Watsen wrote: >=20 >=20 > The entire suite of drafts were updated today. > The first three drafts are ready for WGLC. > All of the other drafts are almost ready for WGLC. > Below is the Change Log entry for each draft. >=20 > K. >=20 >=20 > For all drafts: >=20 > o Added a "Note to Reviewers" note to first page. >=20 >=20 > For crypto-types: >=20 > o Removed the IANA-maintained registries for symmetric, asymmetric, > and hash algorithms. >=20 > o Removed the "generate-symmetric-key" and = "generate-asymmetric-key" > RPCs. >=20 > o Removed the "algorithm" node in the various symmetric and > asymmetric key groupings. >=20 > o Added 'typedef csr' and 'feature certificate-signing-request- > generation'. >=20 > o Refined a usage of "end-entity-cert-grouping" to make the "cert" > node mandatory true. >=20 >=20 > For trust-anchors: >=20 > o Removed "algorithm" node from examples. >=20 > o Removed the no longer used statements supporting the old "ssh- > public-key" and "raw-public-key" nodes. >=20 >=20 > For keystore: >=20 > o Removed augments to the "generate-symmetric-key" and "generate- > asymmetric-key" groupings. >=20 > o Removed "generate-symmetric-key" and "generate-asymmetric-key" > examples. >=20 > o Removed the "algorithm" nodes from remaining examples. >=20 > o Renamed/updated the "Support for Built-in Keys" section. >=20 > o Added new section "Encrypting Keys in Configuration". >=20 >=20 > For tcp-client-server: >=20 > o Removed commented out "grouping tcp-system-grouping" statement > kept for reviewers. >=20 >=20 > For ssh-client-server: >=20 > o Updated the "keepalives" containers to address Michal Vasko's > request to align with RFC 8071 >=20 > o Removed algorithm-mapping tables from the "SSH Common Model" > section >=20 > o Removed 'algorithm' node from examples. >=20 > o Added feature "client-identity-publickey" >=20 > o Removed "choice auth-type", as auth-types aren't exclusive. >=20 > o Renamed both "client-certs" and "server-certs" to "ee-certs" >=20 > o Switch "must" to assert the public-key-format is "subject-public- > key-info-format" when certificates are used. >=20 >=20 > For tls-client-server: >=20 > o Updated the "keepalives" containers in part to address Michal > Vasko's request to align with RFC 8071 and in part to better = align to RFC 6520 >=20 > o Removed algorithm-mapping tables from the "TLS Common Model" > section >=20 > o Removed the 'algorithm' node from the examples. >=20 > o Renamed both "client-certs" and "server-certs" to "ee-certs" >=20 >=20 > For http-client-server: >=20 > o Removed "protocol-versions" from ietf-http-server based on HTTP = WG > feedback. >=20 > o Slightly restructured the "proxy-server" definition in ietf-http- > client. >=20 > o Added http-client example show proxy server use. >=20 >=20 > For netconf-client-server: >=20 > o Updated examples to remove the 'algorithm' nodes. >=20 > o Updated examples to reflect the new TLS keepalives structure. >=20 > o Added keepalives to the tcp-client-parameters section in the > netconf-server SSH-based call-home example. >=20 > o Added a TLS-based call-home example to the netconf-client = example. >=20 >=20 > For restonf-client-server: >=20 > o Updated examples to remove the 'algorithm' nodes. >=20 > o Updated examples to reflect the new TLS keepalives structure. >=20 > o Removed the 'protocol-versions' node from the restconf-server > examples. >=20 >=20 >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani (as co-chair) mjethanandani@gmail.com From nobody Fri May 22 09:41:02 2020 Return-Path: <010001723d42571a-3dfa9786-073a-4e34-917f-00cfe533f227-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 F09AE3A082F for ; Fri, 22 May 2020 09:40:59 -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, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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 m3Y9XK_oyqkC for ; Fri, 22 May 2020 09:40:59 -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 BB3C13A0B00 for ; Fri, 22 May 2020 09:40:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1590165657; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=1GrF7doXik7o6QkXyoeQXG6y5dV8Peia7IcqA64pMbU=; b=cEWztWm/XPeYyxa3hFapR42zt+3BPRYaelj+NyQy7m9rS1/x7JR8cPiweClxXUSp P4MbR6rLhc5ME6/BgfTDWYoZSQvt0hDKVqqoHFSxhiLeWW21AqcamMvuPnYn5R4mtb9 0MJQhtIiRRqGhKSx/ef8RSZoOORS+0THMMGhZ0z8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Kent Watsen In-Reply-To: <85A8ECA9-8875-45FA-839B-50CE35F6C8BA@gmail.com> Date: Fri, 22 May 2020 16:40:57 +0000 Cc: "netconf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <010001723d42571a-3dfa9786-073a-4e34-917f-00cfe533f227-000000@email.amazonses.com> References: <0100017233fe7ff7-8e22b4b1-aa03-4c8e-bf9d-fdbc7d3e41fd-000000@email.amazonses.com> <85A8ECA9-8875-45FA-839B-50CE35F6C8BA@gmail.com> To: Mahesh Jethanandani X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2020.05.22-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [netconf] Today's update to client-server drafts 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, 22 May 2020 16:41:00 -0000 Hi Mahesh, > What would it take to get the remaining drafts into WGLC? The pending activities are: - tcp-client-server:=20 - finalize proxy solution - ssh-client-server:=20 - discuss issues with the 'ssh-host-keys' node - tls-client-server:=20 - discuss issue with the 'ee-certs' node - discuss issue with the psk 'id' type - http-client-server: - finalize proxy solution - finalize security considerations We're currently 7 weeks out from the 108 draft cutoff, and 9 weeks out = from the conference itself. It would be nice to do something like this: - now: start 2-wk LC for ct/ts/ks - in 2wks: start 1-wk LC for tcp=20 - in 3wks: start 2-wk LC for ssh/tls - in 5wks: start 1-wk LC for http - in 6wks: start 2-wk LC for nc/rc - end all LC in 8wks. But that is only possible if (1) we're able to resolve all the pending = items while simultaneously doing LCs on the earlier drafts...or (2) = folks are willing to provide reviews on the drafts as they are, in part = helping to close the pending activities. Another option would be to (3) just do: - now: start 2-wk LC for ct+ts+ks - after resolving pending issue: start 2-wk LC for tcp - update all drafts based on the fallout of above reviews - present remaining open issues at 108=20 - update remaining drafts accordingly - resume the LCs shortly after 108 I prefer (2) or (3), as (1) puts too much work on me in a short period = of time, and I have a big deliverable coming up in my other life outside = the IETF. K.