From nobody Tue Jul 1 01:11:08 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859F91B27D8; Tue, 1 Jul 2014 01:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 Fkj1b-jMpc0V; Tue, 1 Jul 2014 01:11:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C761B27DD; Tue, 1 Jul 2014 01:10:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140701081056.11394.75518.idtracker@ietfa.amsl.com> Date: Tue, 01 Jul 2014 01:10:56 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/KYMgXKnM7qtjuLGkb1ZtllqWL70 Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 08:11:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) Authors : Kent Watsen Stephen Hanna Joe Marcus Clarke Mikael Abrahamsson Filename : draft-ietf-netconf-zerotouch-00.txt Pages : 29 Date : 2014-06-30 Abstract: This draft presents a technique for establishing a secure NETCONF connection between a newly deployed IP-based device, configured with just its factory default settings, and the new owner's Network Management System (NMS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-zerotouch-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 1 06:13:45 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012821A01F6 for ; Tue, 1 Jul 2014 06:13:41 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 nOlli7PLprdu for ; Tue, 1 Jul 2014 06:13:34 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 096651A01F3 for ; Tue, 1 Jul 2014 06:13:33 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.0.969.15; Tue, 1 Jul 2014 13:13:31 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.34]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.34]) with mapi id 15.00.0969.007; Tue, 1 Jul 2014 13:13:31 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-00.txt Thread-Index: AQHPlQQHUCZ3qL9hokqUPW/1uav6LpuK72gA Date: Tue, 1 Jul 2014 13:13:30 +0000 Message-ID: References: <20140701081056.11394.75518.idtracker@ietfa.amsl.com> In-Reply-To: <20140701081056.11394.75518.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [66.129.241.12] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02596AB7DA x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(24454002)(377454003)(189002)(199002)(51704005)(377424004)(479174003)(83322001)(19580405001)(19580395003)(101416001)(74662001)(85306003)(99396002)(77096002)(107046002)(106356001)(80022001)(85852003)(106116001)(2351001)(64706001)(81542001)(83072002)(20776003)(2656002)(66066001)(76482001)(87936001)(81342001)(86362001)(107886001)(92726001)(50986999)(36756003)(4396001)(105586002)(95666004)(99286002)(21056001)(83506001)(76176999)(54356999)(77982001)(46102001)(79102001)(74502001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Mvwuk63-Ru2Rahq23zUJJcKBbmg Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 13:13:41 -0000 All, This update takes into account all the comments received since the last update. Specifically: * Major structural update; the essence is the same. Most every section was rewritten to some degree. * Added a Use Cases section * Added diagrams for "Actors and Roles" and "NMS Precondition" sections, and greatly improved the "Device Boot Sequence" diagram * Removed support for physical presence or any ability for Configlets to not be signed. * Defined the ZeroTouch Information DHCP option * Added an ability for devices to also download images from Configuration Servers * Added an ability for Configlets to be encrypted * Now Configuration Servers only have to support HTTP/S - no other schemes possible * Posted as a WG document As of now, all the drafts reverse-ssh, netconf-server-model, and zerotouch have been updated and again represent a consistent set. It's best to read them in that order, as they build on top of each other that way. Please review before Toronto so we can have good discussion. Cheers, Kent On 7/1/14, 4:10 AM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Network Configuration Working Group of >the IETF. > > Title : Zero Touch Provisioning for NETCONF Call Home >(ZeroTouch) > Authors : Kent Watsen > Stephen Hanna > Joe Marcus Clarke > Mikael Abrahamsson > Filename : draft-ietf-netconf-zerotouch-00.txt > Pages : 29 > Date : 2014-06-30 > >Abstract: > This draft presents a technique for establishing a secure NETCONF > connection between a newly deployed IP-based device, configured with > just its factory default settings, and the new owner's Network > Management System (NMS). > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-netconf-zerotouch-00 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Jul 2 02:51:41 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90861B28E1; Wed, 2 Jul 2014 02:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.817 X-Spam-Level: X-Spam-Status: No, score=-2.817 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LONGWORDS=2.035, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 RWOQ30BCb4uc; Wed, 2 Jul 2014 02:51:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 876881B27E5; Wed, 2 Jul 2014 02:51:36 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJM38296; Wed, 02 Jul 2014 09:51:35 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 2 Jul 2014 10:51:34 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.24]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Wed, 2 Jul 2014 17:51:26 +0800 From: "Liubing (Leo)" To: Netconf , "netmod@ietf.org" Thread-Topic: Multiple instances configuration issues-//FW: New Version Notification for draft-liu-netconf-multi-instances-00.txt Thread-Index: AQHPldswcHtSPLODJEKU9E5gnW6XrQ== Date: Wed, 2 Jul 2014 09:51:26 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8ED5BF@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/pmYDuj1H30hAi8VLv9xG-aiOQ_M Cc: Zhengguangying , Yangang Subject: [Netconf] Multiple instances configuration issues-//FW: New Version Notification for draft-liu-netconf-multi-instances-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 09:51:39 -0000 SGkgYWxsIGluIE5ldGNvbmYgJiBOZXRtb2QsDQoNCkluIGxhc3QgTmV0Y29uZiBtZWV0aW5nIGlu IExvbmRvbiwgbXkgY29sbGVhZ3VlIEd1YW5neWluZyBaaGVuZyByYWlzZWQgYSBxdWVzdGlvbiBh dCB0aGUgbWlrZSBhYm91dCBob3cgdG8gZGlzdGluZ3Vpc2ggbXVsdGlwbGUgVlJGcyB3aGVuIHVz aW5nIE5FVENPTkYgdG8gY29uZmlndXJlIGEgZGV2aWNlLg0KQW5kIHRoZW4gaW4gdGhlIG1haWxp bmcgbGlzdCwgRGF2aWQgTGFtcGFydGVyIGxlZCBhIHZlcnkgZ29vZCBkaXNjdXNzaW9uIG9mIHRo ZSBwcm9ibGVtLiANCg0KQXMgZGlzY3Vzc2VkIGluIHRoZSBtYWlsaW5nIGxpc3QsIGl0IGlzIG5v dCBvbmx5IHJlZ2FyZGluZyB0byBWUkYsIHJhdGhlciwgaXQgaXMgcXVpdGUgYSBnZW5lcmFsIGlz c3VlLiANClNvIHdlIHdyb3RlIGEgZHJhZnQgdG8gdHJ5IHRvIG1ha2UgYSBjb21wcmVoZW5zaXZl IGRpc2N1c3Npb24gb2YgdGhlIGlzc3VlLiBUaGUgZHJhZnQgYW5hbHl6ZXMgdGhlIG1hbmFnZW1l bnQgcmVxdWlyZW1lbnRzIGZvciBtdWx0aXBsZSBpbnN0YW5jZXMgbGlrZSBWUkYsIGFuZCBwb2lu dGVkIG91dCBzb21lIGdhcHMgaW4gY3VycmVudCBORVRDT05GIHByb3RvY29sIGFuZCBZQU5HIG1v ZGVscy4gQXQgbGFzdCwgdGhlIGRyYWZ0IGJyaWVmbHkgZGlzY3VzcyBzb21lIHBvc3NpYmxlIHNv bHV0aW9ucyB0byBmaWxsIHRoZSBnYXBzLg0KDQpQbGVhc2UgcmV2aWV3IHRoZSBkcmFmdCBhbmQg Y29tbWVudC4NCk1hbnkgdGhhbmtzIQ0KDQpCZXN0IHJlZ2FyZHMsDQpCaW5nDQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMDIs IDIwMTQgNDo0OCBQTQ0KVG86IExpdWJpbmcgKExlbyk7IExpdWJpbmcgKExlbyk7IFlhbmdhbmc7 IFlhbmdhbmcNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGl1 LW5ldGNvbmYtbXVsdGktaW5zdGFuY2VzLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1saXUtbmV0Y29uZi1tdWx0aS1pbnN0YW5jZXMtMDAudHh0DQpoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEJpbmcgTGl1IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVw b3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWxpdS1uZXRjb25mLW11bHRpLWluc3RhbmNlcw0KUmV2 aXNpb246CTAwDQpUaXRsZToJCU11bHRpLUluc3RhbmNlcyBDb25maWd1cmF0aW9uIElzc3VlIGlu IE5FVENPTkYNCkRvY3VtZW50IGRhdGU6CTIwMTQtMDctMDINCkdyb3VwOgkJSW5kaXZpZHVhbCBT dWJtaXNzaW9uDQpQYWdlczoJCTEwDQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGl1LW5ldGNvbmYtbXVsdGktaW5zdGFuY2VzLTAwLnR4 dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWxpdS1uZXRjb25mLW11bHRpLWluc3RhbmNlcy8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saXUtbmV0Y29uZi1tdWx0aS1pbnN0YW5jZXMtMDANCg0K DQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgcHV0cyB0b2dldGhlciB0aGUgTkVUQ09ORiBp c3N1ZXMgb2YgY29uZmlndXJpbmcNCiAgIG11bHRpcGxlIGluc3RhbmNlcyBpbmNsdWRpbmcgY29u ZmlndXJpbmcgbXVsdGlwbGUgbmV0d29yayBlbGVtZW50DQogICBpbnN0YW5jZXMgYW5kIG11bHRp cGxlIHNlcnZpY2UgaW5zdGFuY2VzLiBUaGUgbWFpbiBwcm9ibGVtIGlzIGhvdyB0bw0KICAgY29u ZmlndXJlIHRoZSBtdWx0aXBsZSBpbnN0YW5jZXMgaW4gb25lIE5FVENPTkYgY2hhbm5lbC4NCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRh a2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Wed Jul 2 11:35:53 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9730E1B29F4 for ; Wed, 2 Jul 2014 11:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.057 X-Spam-Level: X-Spam-Status: No, score=0.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, LONGWORDS=2.035, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 VbsqYcCM_OGp for ; Wed, 2 Jul 2014 11:35:46 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 962571A03E1 for ; Wed, 2 Jul 2014 11:35:46 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id l6so10449305qcy.15 for ; Wed, 02 Jul 2014 11:35:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ECoFw332mhs8FXkQViVU/VWiA62zH6KW/MDa5aNzDOc=; b=ZyeYIl8gIYtas7ovjfm+/x15pIS73UtU13D0Du257NA74kAFs9HfAE2t9Xcuc89BjA XG8CJavKSpDm++jJ6X+CeinbkNLkU/INbMJZc0RqIltgtWb1uuB6o80yGR6Q0h+x9aOy M8qNvhKErsoJcqr778Ot51XBsLGWMord+aN9v3UauRE4DcKsxskPN9AvhJ/FPsv0sIZ1 utsyDdjLYZtUF5uRGDYXFrzJrd4GYGwKooIOkOEeAvzEzz9P4JXXYoJhN6m2rZfoa/Vh omW1d6rHwDGC/x3qYR99L/bhz1KcnzDEou8SYAPW3pMADHdrbESGjLLWOlNcBNfcJ1zY pLog== X-Gm-Message-State: ALoCoQkRGkcMFZyGGFFCTQ19owHe8DJy9/h/mJdzy0OdsMiQwfjoy7RkGyZE8pD3Ng0gBW7Aiq22 MIME-Version: 1.0 X-Received: by 10.224.20.10 with SMTP id d10mr85244944qab.16.1404326145638; Wed, 02 Jul 2014 11:35:45 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Wed, 2 Jul 2014 11:35:45 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8ED5BF@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8ED5BF@nkgeml506-mbx.china.huawei.com> Date: Wed, 2 Jul 2014 11:35:45 -0700 Message-ID: From: Andy Bierman To: "Liubing (Leo)" Content-Type: multipart/alternative; boundary=001a11c1c2ae0f6ab904fd3a29b9 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/V7tqcNW1ClWhOL-FLCoU2-6U3HA Cc: Zhengguangying , Netconf , "netmod@ietf.org" , Yangang Subject: Re: [Netconf] Multiple instances configuration issues-//FW: New Version Notification for draft-liu-netconf-multi-instances-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jul 2014 18:35:48 -0000 --001a11c1c2ae0f6ab904fd3a29b9 Content-Type: text/plain; charset=ISO-8859-1 Hi, I read your draft and it I can see use-cases for a context-ID. I prefer to think of named virtual hosts in Apache2, rather than SNMP contexts. I don't think your solution is fully specified, but it is a good start. I think the following solution could easily work, which is just a refinement of your solution in sec. 4.1. 1) define a 'server-id' XML attribute 2) define a NETCONF 'virtual-server' capability indicating the server supports the 'server-id' attribute 3) the server is already required to accept all attributes in the start tag and return them in the start tag. (So sending the server-id attribute is safe in all cases). 4) If the server supports the capability, then it must check for the server-id attribute in each and use the correct virtual server or else return an error if it is an unknown server-id. I don't really understand Gap-2 and Gap-3 so I am not addressing that. It looks like it might overlap the "YANG mount" draft (draft-clemm-netmod-mount-01). IMO that is a completely different problem -- configuration of a mid-level-manager. Andy On Wed, Jul 2, 2014 at 2:51 AM, Liubing (Leo) wrote: > Hi all in Netconf & Netmod, > > In last Netconf meeting in London, my colleague Guangying Zheng raised a > question at the mike about how to distinguish multiple VRFs when using > NETCONF to configure a device. > And then in the mailing list, David Lamparter led a very good discussion > of the problem. > > As discussed in the mailing list, it is not only regarding to VRF, rather, > it is quite a general issue. > So we wrote a draft to try to make a comprehensive discussion of the > issue. The draft analyzes the management requirements for multiple > instances like VRF, and pointed out some gaps in current NETCONF protocol > and YANG models. At last, the draft briefly discuss some possible solutions > to fill the gaps. > > Please review the draft and comment. > Many thanks! > > Best regards, > Bing > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, July 02, 2014 4:48 PM > To: Liubing (Leo); Liubing (Leo); Yangang; Yangang > Subject: New Version Notification for > draft-liu-netconf-multi-instances-00.txt > > > A new version of I-D, draft-liu-netconf-multi-instances-00.txt > has been successfully submitted by Bing Liu and posted to the IETF > repository. > > Name: draft-liu-netconf-multi-instances > Revision: 00 > Title: Multi-Instances Configuration Issue in NETCONF > Document date: 2014-07-02 > Group: Individual Submission > Pages: 10 > URL: > http://www.ietf.org/internet-drafts/draft-liu-netconf-multi-instances-00.txt > Status: > https://datatracker.ietf.org/doc/draft-liu-netconf-multi-instances/ > Htmlized: > http://tools.ietf.org/html/draft-liu-netconf-multi-instances-00 > > > Abstract: > This document puts together the NETCONF issues of configuring > multiple instances including configuring multiple network element > instances and multiple service instances. The main problem is how to > configure the multiple instances in one NETCONF channel. > > > > > 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. > > The IETF Secretariat > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11c1c2ae0f6ab904fd3a29b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I read your draft and it I can see = use-cases for a context-ID.
I prefer to think of named virtual ho= sts in Apache2, rather than
SNMP contexts.

I don't think your solution is fully specified, but it is a good start.=
I think the following solution could easily work, which is just = a
refinement of your solution in sec. 4.1.

=A01) define a 'server-id' XML attribute
<= div>=A02) define a NETCONF 'virtual-server' capability indicating t= he server supports the 'server-id' attribute
=A03) the se= rver is already required to accept all attributes in the <rpc> start = tag and return
=A0 =A0 =A0them in the <rpc-reply> start tag. (So sending the se= rver-id attribute is safe in all cases).
=A04) If the server supp= orts the capability, then it must check for the server-id attribute in each= <rpc>
=A0 =A0 =A0and use the correct virtual server or else return an error = if it is an unknown server-id.

I don't really = understand Gap-2 and Gap-3 so I am not addressing that. =A0It looks like
it might overlap the "YANG mount" draft (draft-clemm-netmod-mount= -01).
IMO that is a completely different problem -- configuration= of a mid-level-manager.


Andy





On Wed, Jul 2, 2014 at 2:51 AM, Liubin= g (Leo) <leo.liubing@huawei.com> wrote:
Hi all in Netconf & Netmod,

In last Netconf meeting in London, my colleague Guangying Zheng raised a qu= estion at the mike about how to distinguish multiple VRFs when using NETCON= F to configure a device.
And then in the mailing list, David Lamparter led a very good discussion of= the problem.

As discussed in the mailing list, it is not only regarding to VRF, rather, = it is quite a general issue.
So we wrote a draft to try to make a comprehensive discussion of the issue.= The draft analyzes the management requirements for multiple instances like= VRF, and pointed out some gaps in current NETCONF protocol and YANG models= . At last, the draft briefly discuss some possible solutions to fill the ga= ps.

Please review the draft and comment.
Many thanks!

Best regards,
Bing


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Wednesday, July 02, 2014 4:48 PM
To: Liubing (Leo); Liubing (Leo); Yangang; Yangang
Subject: New Version Notification for draft-liu-netconf-multi-instances-00.= txt


A new version of I-D, draft-liu-netconf-multi-instances-00.txt
has been successfully submitted by Bing Liu and posted to the IETF reposito= ry.

Name: =A0 =A0 =A0 =A0 =A0 draft-liu-netconf-multi-instances
Revision: =A0 =A0 =A0 00
Title: =A0 =A0 =A0 =A0 =A0Multi-Instances Configuration Issue in NETCONF Document date: =A02014-07-02
Group: =A0 =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0 =A0 =A010
URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf= .org/internet-drafts/draft-liu-netconf-multi-instances-00.txt
Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org= /doc/draft-liu-netconf-multi-instances/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-l= iu-netconf-multi-instances-00


Abstract:
=A0 =A0This document puts together the NETCONF issues of configuring
=A0 =A0multiple instances including configuring multiple network element =A0 =A0instances and multiple service instances. The main problem is how to=
=A0 =A0configure the multiple instances in one NETCONF channel.




Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

--001a11c1c2ae0f6ab904fd3a29b9-- From nobody Thu Jul 3 20:44:59 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C6D1A8BB7; Thu, 3 Jul 2014 20:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 XeqiRIfOdSbY; Thu, 3 Jul 2014 20:44:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6021B2A40; Thu, 3 Jul 2014 20:44:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704034452.25233.78381.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 20:44:52 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/jlDJsmD6_nO2WY9yMRumAM3icqA Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-restconf-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 03:44:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : RESTCONF Protocol Authors : Andy Bierman Martin Bjorklund Kent Watsen Rex Fernando Filename : draft-ietf-netconf-restconf-01.txt Pages : 92 Date : 2014-07-03 Abstract: This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-restconf-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-restconf-01 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 Thu Jul 3 20:47:27 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441D91B2BB2; Thu, 3 Jul 2014 20:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 1xo1oyzlPeDQ; Thu, 3 Jul 2014 20:47:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 321311B2BB3; Thu, 3 Jul 2014 20:47:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704034713.28580.81180.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 20:47:13 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/pNjUX09aJr1kn6pfqFCIf_YW0Aw Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-patch-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 03:47:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : YANG Patch Media Type Authors : Andy Bierman Martin Bjorklund Kent Watsen Rex Fernando Filename : draft-ietf-netconf-yang-patch-01.txt Pages : 30 Date : 2014-07-03 Abstract: This document describes a method for applying patches to NETCONF datastores using data defined with the YANG data modeling language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-patch/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-yang-patch-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-patch-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 05:44:03 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982FB1B28B4; Fri, 4 Jul 2014 05:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.816 X-Spam-Level: X-Spam-Status: No, score=-2.816 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LONGWORDS=2.035, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 Yn26XWVig9P0; Fri, 4 Jul 2014 05:43:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8055A1B28B5; Fri, 4 Jul 2014 05:43:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGU33172; Fri, 04 Jul 2014 12:43:50 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 4 Jul 2014 13:43:49 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.24]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 4 Jul 2014 20:43:38 +0800 From: "Liubing (Leo)" To: Andy Bierman Thread-Topic: [Netconf] Multiple instances configuration issues-//FW: New Version Notification for draft-liu-netconf-multi-instances-00.txt Thread-Index: AQHPldswcHtSPLODJEKU9E5gnW6XrZuMlwyAgAEfORA= Date: Fri, 4 Jul 2014 12:43:37 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8F0652@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8ED5BF@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8F0652nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/iGMH9adQu35Uh5XV-WyS8BrnWHA Cc: Zhengguangying , Netconf , "netmod@ietf.org" , Yangang Subject: Re: [Netconf] Multiple instances configuration issues-//FW: New Version Notification for draft-liu-netconf-multi-instances-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 12:43:59 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8F0652nkgeml506mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andy, Thanks for your comments. Please see replies inline. From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Thursday, July 03, 2014 2:36 AM To: Liubing (Leo) Cc: Netconf; netmod@ietf.org; Zhengguangying; Yanga= ng Subject: Re: [Netconf] Multiple instances configuration issues-//FW: New Ve= rsion Notification for draft-liu-netconf-multi-instances-00.txt Hi, I read your draft and it I can see use-cases for a context-ID. I prefer to think of named virtual hosts in Apache2, rather than SNMP contexts. [Bing] May I ask the specific reasons that you don't prefer SNMP context? We also had some concern that since context doesn't specify the content, it= may have problem on standardization. But we just thought it could be a fam= iliar concept to the network management people. I don't think your solution is fully specified, but it is a good start. [Bing] Yes, the solution part of the document is mostly a hint for further = discussion. At this stage, we'd like to hear more opinions on the problem/g= ap analysis part. I think the following solution could easily work, which is just a refinement of your solution in sec. 4.1. 1) define a 'server-id' XML attribute 2) define a NETCONF 'virtual-server' capability indicating the server supp= orts the 'server-id' attribute 3) the server is already required to accept all attributes in the st= art tag and return them in the start tag. (So sending the server-id attribute= is safe in all cases). 4) If the server supports the capability, then it must check for the serve= r-id attribute in each and use the correct virtual server or else return an error if it is an= unknown server-id. [Bing] We thought your proposal is also a good solution. If we go this way, then there might be a problem that is a single "server-i= d" sufficient to identify the targeted instance? Since LS and VS might co-e= xist in one device, thus one LS might contain multiple VSes. Then there com= es a hierarchy of the server-id. Maybe we need a comprehensive structure to= well express the hierarchical id? I don't really understand Gap-2 and Gap-3 so I am not addressing that. It = looks like it might overlap the "YANG mount" draft (draft-clemm-netmod-mount-01). IMO that is a completely different problem -- configuration of a mid-level-= manager. [Bing] Gap-2 and Gap-3 are indeed regarding to YANG rather than NETCONF. Le= t me explain them with some examples. Req-2/Gap-2: a YANG model itself needs to support multiple instances, for e= xample: - the routing model (draft-ietf-netmod-routing-cfg) clearly defines = "routing instance" to support VRF instances - the OSPF model (draft-yeung-netmod-ospf) defines "ospf:ospf-af [vr= f-name afi safi]" to support multiple OSPF engines (instances). Say, if an existing model doesn't support multiple instances, and in the fu= ture for some reason we need to manage them as multiple instances. How do w= e extend the existing model? Req-3a/Gap-3a: Configuring a service under another E.g., the above mentioned OSPF module is defined under the routing instance= (VRF) defined in routing model through augment: augment "/rt:routing/rt:routing-instance/rt:routing-protocols/" + "rt:routing-protocol" { list ospf-router { ... Then, we could configure the OSPF under the routing data model, there is no= problem/gap with this example. However, consider another example: if we're= going to write a new model, say, L3VPN, can we just re-use the whole routi= ng model also through augment? (Just to confirm, I'm not sure whether YANG = is able to do this or not. If YANG is already be able to do it, then maybe = we should remove the gap.) Req-3b/Gap-3b: a YANG model needs to be aware of the other's multiple insta= nces E.g., when the above mentioned OSPF model defines "ospf:ospf-af [vrf-name a= fi safi]" to support multiple OSPF engines (instances), it means the OSPF m= odel be aware of the VRF multiple instances, and there is an implication th= at the OSPF instance is binding to the VRF instance. This kind of awareness= /binding might face the scalability issue. Say, if something like VRF comes= out in the future, how does current OSPF model to support that new kind of= instance? For "YANG mount" draft, my personal understanding is that it is a container= to collect different modules in other location together in one place. Whil= e the above gaps are more regarding to relationships between different mode= ls. I think they have different scopes. Best regards, Bing On Wed, Jul 2, 2014 at 2:51 AM, Liubing (Leo) > wrote: Hi all in Netconf & Netmod, In last Netconf meeting in London, my colleague Guangying Zheng raised a qu= estion at the mike about how to distinguish multiple VRFs when using NETCON= F to configure a device. And then in the mailing list, David Lamparter led a very good discussion of= the problem. As discussed in the mailing list, it is not only regarding to VRF, rather, = it is quite a general issue. So we wrote a draft to try to make a comprehensive discussion of the issue.= The draft analyzes the management requirements for multiple instances like= VRF, and pointed out some gaps in current NETCONF protocol and YANG models= . At last, the draft briefly discuss some possible solutions to fill the ga= ps. Please review the draft and comment. Many thanks! Best regards, Bing -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Wednesday, July 02, 2014 4:48 PM To: Liubing (Leo); Liubing (Leo); Yangang; Yangang Subject: New Version Notification for draft-liu-netconf-multi-instances-00.= txt A new version of I-D, draft-liu-netconf-multi-instances-00.txt has been successfully submitted by Bing Liu and posted to the IETF reposito= ry. Name: draft-liu-netconf-multi-instances Revision: 00 Title: Multi-Instances Configuration Issue in NETCONF Document date: 2014-07-02 Group: Individual Submission Pages: 10 URL: http://www.ietf.org/internet-drafts/draft-liu-netconf-multi= -instances-00.txt Status: https://datatracker.ietf.org/doc/draft-liu-netconf-multi-in= stances/ Htmlized: http://tools.ietf.org/html/draft-liu-netconf-multi-instance= s-00 Abstract: This document puts together the NETCONF issues of configuring multiple instances including configuring multiple network element instances and multiple service instances. The main problem is how to configure the multiple instances in one NETCONF channel. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8F0652nkgeml506mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andy,

 = ;

Thanks for= your comments. Please see replies inline.

 = ;

From: Andy Bierman [m= ailto:andy@yumaworks.com]
Sent: Thursday, July 03, 2014 2:36 AM
To: Liubing (Leo)
Cc: Netconf; netmod@ietf.org;= Zhengguangying; Yangang
Subject: Re: [Netconf] Multiple instances configuration issues-//FW:= New Version Notification for draft-liu-netconf-multi-instances-00.txt=

 

Hi,

 

I read your draft and it I can = see use-cases for a context-ID.

I prefer to think of named virt= ual hosts in Apache2, rather than

SNMP contexts.

[Bing] May= I ask the specific reasons that you don’t prefer SNMP context?

We also ha= d some concern that since context doesn’t specify the content, it may= have problem on standardization. But we just thought it could be a familiar concept to the network management people.

 

I don't think your solution is = fully specified, but it is a good start.

[Bing] Yes= , the solution part of the document is mostly a hint for further discussion= . At this stage, we’d like to hear more opinions on the problem/gap analysis part.

 = ;

I think the following solution = could easily work, which is just a

refinement of your solution in = sec. 4.1.

 

 1) define a 'server-id' X= ML attribute

 2) define a NETCONF 'virt= ual-server' capability indicating the server supports the 'server-id' attri= bute

 3) the server is already = required to accept all attributes in the <rpc> start tag and return

     them in the= <rpc-reply> start tag. (So sending the server-id attribute is safe i= n all cases).

 4) If the server supports= the capability, then it must check for the server-id attribute in each <= ;rpc>

     and use the= correct virtual server or else return an error if it is an unknown server-= id.

 = ;

[Bing] We = thought your proposal is also a good solution.

If we go t= his way, then there might be a problem that is a single “server-id= 221; sufficient to identify the targeted instance? Since LS and VS might co-exist in one device, thus one LS might contain multiple VSes. Then ther= e comes a hierarchy of the server-id. Maybe we need a comprehensive structu= re to well express the hierarchical id?

 

I don't really understand Gap-2= and Gap-3 so I am not addressing that.  It looks like

it might overlap the "YANG= mount" draft (draft-clemm-netmod-mount-01).

IMO that is a completely differ= ent problem -- configuration of a mid-level-manager.

&n= bsp;

[Bing] Gap= -2 and Gap-3 are indeed regarding to YANG rather than NETCONF. Let me expla= in them with some examples.

 = ;

Req-2/Gap-= 2: a YANG model itself needs to support multiple instances, for example:

-th= e routing model (draft-ietf-netmod-routing-cfg) clearly defines “rout= ing instance” to support VRF instances

-th= e OSPF model (draft-yeung-netmod-ospf) defines “ospf:ospf-af [vrf-nam= e afi safi]” to support multiple OSPF engines (instances).=

Say, if an= existing model doesn’t support multiple instances, and in the future= for some reason we need to manage them as multiple instances. How do we extend the existing model?

 = ;

Req-3a/Gap= -3a: Configuring a service under another

E.g., the = above mentioned OSPF module is defined under the routing instance (VRF) def= ined in routing model through augment:  

augment "/rt:routing/rt:routing-instance/rt:routing-= protocols/"

         + &q= uot;rt:routing-protocol" {

 &nbs= p;   list ospf-router {

 &nbs= p;   ...

Then, we c= ould configure the OSPF under the routing data model, there is no problem/g= ap with this example. However, consider another example: if we’re going to write a new model, say, L3VPN, can we just re-use the= whole routing model also through augment? (Just to confirm, I’m not = sure whether YANG is able to do this or not. If YANG is already be able to = do it, then maybe we should remove the gap.)

 = ;

Req-3b/Gap= -3b: a YANG model needs to be aware of the other’s multiple instances=

E.g., when= the above mentioned OSPF model defines “ospf:ospf-af [vrf-name afi s= afi]” to support multiple OSPF engines (instances), it means the OSPF model be aware of the VRF multiple instances, and there is an implica= tion that the OSPF instance is binding to the VRF instance. This kind of aw= areness/binding might face the scalability issue. Say, if something like VR= F comes out in the future, how does current OSPF model to support that new kind of instance?

 = ;

For "= YANG mount" draft, my personal understanding is that it is a container= to collect different modules in other location together in one place. While the above gaps are more regarding to relationships between different= models. I think they have different scopes.

 = ;

Best regar= ds,

Bing<= /o:p>

 = ;

 = ;

 = ;

 

On Wed, Jul 2, 2014 at 2:51 AM,= Liubing (Leo) <leo.liubing@huawei.com> wrote:

Hi all in Netconf & Netmod,=

In last Netconf meeting in London, my colleague Guangying Zheng raised a qu= estion at the mike about how to distinguish multiple VRFs when using NETCON= F to configure a device.
And then in the mailing list, David Lamparter led a very good discussion of= the problem.

As discussed in the mailing list, it is not only regarding to VRF, rather, = it is quite a general issue.
So we wrote a draft to try to make a comprehensive discussion of the issue.= The draft analyzes the management requirements for multiple instances like= VRF, and pointed out some gaps in current NETCONF protocol and YANG models= . At last, the draft briefly discuss some possible solutions to fill the gaps.

Please review the draft and comment.
Many thanks!

Best regards,
Bing


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Wednesday, July 02, 2014 4:48 PM
To: Liubing (Leo); Liubing (Leo); Yangang; Yangang
Subject: New Version Notification for draft-liu-netconf-multi-instances-00.= txt


A new version of I-D, draft-liu-netconf-multi-instances-00.txt
has been successfully submitted by Bing Liu and posted to the IETF reposito= ry.

Name:           draft-liu-netconf-multi-instances<= br> Revision:       00
Title:          Multi-Instances Configuration Issu= e in NETCONF
Document date:  2014-07-02
Group:          Individual Submission
Pages:          10
URL:            http://www.ietf.org/internet-drafts/draft-liu-netconf-multi-instances-00= .txt
Status:         https://datatracker.ietf.org/doc/draft-liu-netconf-multi-instances/
Htmlized:       http://tools.ietf.org/html/draft-liu-netconf-multi-instances-00


Abstract:
   This document puts together the NETCONF issues of configuring<= br>    multiple instances including configuring multiple network elem= ent
   instances and multiple service instances. The main problem is = how to
   configure the multiple instances in one NETCONF channel.




Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

 

--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8F0652nkgeml506mbxchi_-- From nobody Fri Jul 4 08:47:27 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC70C1A0353 for ; Fri, 4 Jul 2014 08:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.057 X-Spam-Level: X-Spam-Status: No, score=0.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, LONGWORDS=2.035, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 r8mkPmVNuSQe for ; Fri, 4 Jul 2014 08:47:12 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6284A1A0180 for ; Fri, 4 Jul 2014 08:47:12 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id w8so1464774qac.36 for ; Fri, 04 Jul 2014 08:47:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yCOzqi6zIqi88Z/LAVQ0eSZyvWff7Fx3RH3+vTW9Km4=; b=icIL2Xa6ZKBIpopmdVH3obx+h0WVI4lDeoiODnSpzRF0pzRleGjJRp3cQ+W+30WMuH AtpXAis6gjyL0IvepgVWX9e8BsyQ88bReI4M1ejO0U1rlyEe4XV++QAVZyEqyEWrswha pvt1HBebxq8p/kh5L8KA1Zz0iK7sypJ/b5TGkZ+P8nAYOnZwODT0hRqSEnBcS857AwNi 7QXlDp3N/nxEsphFVsoV8lFb65VgjQDMGKcgV9HkNoZiQ5uzZ717isuP1cTb1liEU3/L 68jA8bangs85lZrsC/H0ueBdGShQgIpZAAi3jC95o4FX0OUU5SrJvYL8Uyn9mzezzprX y9zg== X-Gm-Message-State: ALoCoQmZhDsd9BplkeAEhl2s6iN8fENtgxXcF3nzNhpmDTxFM6qeXkr1fY+DgiNaFJqOYcH8ATz5 MIME-Version: 1.0 X-Received: by 10.140.101.115 with SMTP id t106mr18595588qge.91.1404488831329; Fri, 04 Jul 2014 08:47:11 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Fri, 4 Jul 2014 08:47:11 -0700 (PDT) In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D8F0652@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8ED5BF@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F0652@nkgeml506-mbx.china.huawei.com> Date: Fri, 4 Jul 2014 08:47:11 -0700 Message-ID: From: Andy Bierman To: "Liubing (Leo)" Content-Type: multipart/alternative; boundary=001a11c1721ee2011004fd60092c Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/LThrjI1-2FdzvY-upy0Q5kY15Jg Cc: Zhengguangying , Netconf , "netmod@ietf.org" , Yangang Subject: Re: [Netconf] Multiple instances configuration issues-//FW: New Version Notification for draft-liu-netconf-multi-instances-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 15:47:15 -0000 --001a11c1721ee2011004fd60092c Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 4, 2014 at 5:43 AM, Liubing (Leo) wrote: > Hi Andy, > > > > Thanks for your comments. Please see replies inline. > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com ] > *Sent:* Thursday, July 03, 2014 2:36 AM > *To:* Liubing (Leo) > *Cc:* Netconf; netmod@ietf.org; Zhengguangying; Yangang > *Subject:* Re: [Netconf] Multiple instances configuration issues-//FW: > New Version Notification for draft-liu-netconf-multi-instances-00.txt > > > > Hi, > > > > I read your draft and it I can see use-cases for a context-ID. > > I prefer to think of named virtual hosts in Apache2, rather than > > SNMP contexts. > > [Bing] May I ask the specific reasons that you don't prefer SNMP context? > > We also had some concern that since context doesn't specify the content, > it may have problem on standardization. But we just thought it could be a > familiar concept to the network management people. > > > I think SNMP Context has been misused. IMO it is better to have an explicit index in a data structure schema, rather than add an INDEX on the side using the context-ID. > I don't think your solution is fully specified, but it is a good start. > > [Bing] Yes, the solution part of the document is mostly a hint for further > discussion. At this stage, we'd like to hear more opinions on the > problem/gap analysis part. > > > > I think the following solution could easily work, which is just a > > refinement of your solution in sec. 4.1. > > > > 1) define a 'server-id' XML attribute > > 2) define a NETCONF 'virtual-server' capability indicating the server > supports the 'server-id' attribute > > 3) the server is already required to accept all attributes in the > start tag and return > > them in the start tag. (So sending the server-id > attribute is safe in all cases). > > 4) If the server supports the capability, then it must check for the > server-id attribute in each > > and use the correct virtual server or else return an error if it is > an unknown server-id. > > > > [Bing] We thought your proposal is also a good solution. > > If we go this way, then there might be a problem that is a single > "server-id" sufficient to identify the targeted instance? Since LS and VS > might co-exist in one device, thus one LS might contain multiple VSes. Then > there comes a hierarchy of the server-id. Maybe we need a comprehensive > structure to well express the hierarchical id? > > > But you had a single context-id. How is that any different? Named virtual hosts are useful in Apache2 because allocating an IP address to each WEB server is not always possible. Each virtual server is its own instance and content is independent across virtual servers. Each HTTP request is routed from the real server to the correct virtual server, based on the hostname in the URL. A hierarchy would have to be based on content, and in that case, a data modeling solution is needed, not nested virtual servers. > I don't really understand Gap-2 and Gap-3 so I am not addressing that. > It looks like > > it might overlap the "YANG mount" draft (draft-clemm-netmod-mount-01). > > IMO that is a completely different problem -- configuration of a > mid-level-manager. > > > > [Bing] Gap-2 and Gap-3 are indeed regarding to YANG rather than NETCONF. > Let me explain them with some examples. > > > > Req-2/Gap-2: a YANG model itself needs to support multiple instances, for > example: > > - the routing model (draft-ietf-netmod-routing-cfg) clearly > defines "routing instance" to support VRF instances > > - the OSPF model (draft-yeung-netmod-ospf) defines "ospf:ospf-af > [vrf-name afi safi]" to support multiple OSPF engines (instances). > > Say, if an existing model doesn't support multiple instances, and in the > future for some reason we need to manage them as multiple instances. How do > we extend the existing model? > Republish the model with the new key. > > > Req-3a/Gap-3a: Configuring a service under another > > E.g., the above mentioned OSPF module is defined under the routing > instance (VRF) defined in routing model through augment: > > augment "/rt:routing/rt:routing-instance/rt:routing-protocols/" > > + "rt:routing-protocol" { > > list ospf-router { > > ... > > Then, we could configure the OSPF under the routing data model, there is > no problem/gap with this example. However, consider another example: if > we're going to write a new model, say, L3VPN, can we just re-use the whole > routing model also through augment? (Just to confirm, I'm not sure whether > YANG is able to do this or not. If YANG is already be able to do it, then > maybe we should remove the gap.) > > > > Req-3b/Gap-3b: a YANG model needs to be aware of the other's multiple > instances > > E.g., when the above mentioned OSPF model defines "ospf:ospf-af [vrf-name > afi safi]" to support multiple OSPF engines (instances), it means the OSPF > model be aware of the VRF multiple instances, and there is an implication > that the OSPF instance is binding to the VRF instance. This kind of > awareness/binding might face the scalability issue. Say, if something like > VRF comes out in the future, how does current OSPF model to support that > new kind of instance? > > > > For "YANG mount" draft, my personal understanding is that it is a > container to collect different modules in other location together in one > place. While the above gaps are more regarding to relationships between > different models. I think they have different scopes. > > > > Best regards, > > Bing > > > > > Andy > > > > > On Wed, Jul 2, 2014 at 2:51 AM, Liubing (Leo) > wrote: > > Hi all in Netconf & Netmod, > > In last Netconf meeting in London, my colleague Guangying Zheng raised a > question at the mike about how to distinguish multiple VRFs when using > NETCONF to configure a device. > And then in the mailing list, David Lamparter led a very good discussion > of the problem. > > As discussed in the mailing list, it is not only regarding to VRF, rather, > it is quite a general issue. > So we wrote a draft to try to make a comprehensive discussion of the > issue. The draft analyzes the management requirements for multiple > instances like VRF, and pointed out some gaps in current NETCONF protocol > and YANG models. At last, the draft briefly discuss some possible solutions > to fill the gaps. > > Please review the draft and comment. > Many thanks! > > Best regards, > Bing > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, July 02, 2014 4:48 PM > To: Liubing (Leo); Liubing (Leo); Yangang; Yangang > Subject: New Version Notification for > draft-liu-netconf-multi-instances-00.txt > > > A new version of I-D, draft-liu-netconf-multi-instances-00.txt > has been successfully submitted by Bing Liu and posted to the IETF > repository. > > Name: draft-liu-netconf-multi-instances > Revision: 00 > Title: Multi-Instances Configuration Issue in NETCONF > Document date: 2014-07-02 > Group: Individual Submission > Pages: 10 > URL: > http://www.ietf.org/internet-drafts/draft-liu-netconf-multi-instances-00.txt > Status: > https://datatracker.ietf.org/doc/draft-liu-netconf-multi-instances/ > Htmlized: > http://tools.ietf.org/html/draft-liu-netconf-multi-instances-00 > > > Abstract: > This document puts together the NETCONF issues of configuring > multiple instances including configuring multiple network element > instances and multiple service instances. The main problem is how to > configure the multiple instances in one NETCONF channel. > > > > > 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. > > The IETF Secretariat > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > --001a11c1721ee2011004fd60092c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Jul 4, 2014 at 5:43 AM, Liubing (Leo) <= ;leo.liubing@hu= awei.com> wrote:

Hi Andy,

&nb= sp;

Thanks for= your comments. Please see replies inline.

&nb= sp;

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Thursday, July 03, 2014 2:36 AM
To: Liubing (Leo)
Cc: Netconf; ne= tmod@ietf.org; Zhengguangying; Yangang
Subject: Re: [Netconf] Multiple instances configuration issues-//FW:= New Version Notification for draft-liu-netconf-multi-instances-00.txt

 

Hi,

 

I read your draft and it I can = see use-cases for a context-ID.

I prefer to think of named virt= ual hosts in Apache2, rather than

SNMP contexts.

[Bing] May= I ask the specific reasons that you don’t prefer SNMP context?

We also ha= d some concern that since context doesn’t specify the content, it may= have problem on standardization. But we just thought it could be a familiar concept to the network management people.<= /p>

 

<= /div>


I th= ink SNMP Context has been misused.  IMO it is better to have an
<= div>explicit index in a data structure schema, rather than add an INDEX on = the side
using the context-ID.

 

I don't think your solution= is fully specified, but it is a good start.

[Bing] Yes= , the solution part of the document is mostly a hint for further discussion= . At this stage, we’d like to hear more opinions on the problem/gap analysis part.

&nb= sp;

I think the following solution = could easily work, which is just a

refinement of your solution in = sec. 4.1.

 

 1) define a 'server-i= d' XML attribute

 2) define a NETCONF '= virtual-server' capability indicating the server supports the 'serv= er-id' attribute

 3) the server is already = required to accept all attributes in the <rpc> start tag and return

     them in the= <rpc-reply> start tag. (So sending the server-id attribute is safe i= n all cases).

 4) If the server supports= the capability, then it must check for the server-id attribute in each <= ;rpc>

     and use the= correct virtual server or else return an error if it is an unknown server-= id.

&nb= sp;

[Bing] We = thought your proposal is also a good solution.

If we go t= his way, then there might be a problem that is a single “server-id&rd= quo; sufficient to identify the targeted instance? Since LS and VS might co-exist in one device, thus one LS might contain multiple VSes. Then ther= e comes a hierarchy of the server-id. Maybe we need a comprehensive structu= re to well express the hierarchical id?

 

<= /div>


But = you had a single context-id.  How is that any different?
Named virtual hosts are useful in Apache2 because allocating an IP address = to
each WEB server is not always possible.  Each virtual ser= ver is its own instance and
content is independent across virtual= servers.  Each HTTP request is routed from the
real server to the correct virtual server, based on the hostname in th= e URL.

A hierarchy would have to be based on conte= nt, and in that case,
a data modeling solution is needed, not nes= ted virtual servers.



 
<= div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4= .0pt">

I don't really understand G= ap-2 and Gap-3 so I am not addressing that.  It looks like

it might overlap the "YANG= mount" draft (draft-clemm-netmod-mount-01).

IMO that is a completely differ= ent problem -- configuration of a mid-level-manager.

=  

[Bing] Gap= -2 and Gap-3 are indeed regarding to YANG rather than NETCONF. Let me expla= in them with some examples.

&nb= sp;

Req-2/Gap-= 2: a YANG model itself needs to support multiple instances, for example:=

-      &nb= sp; the r= outing model (draft-ietf-netmod-routing-cfg) clearly defines “routing= instance” to support VRF instances

-      &nb= sp; the O= SPF model (draft-yeung-netmod-ospf) defines “ospf:ospf-af [vrf-name a= fi safi]” to support multiple OSPF engines (instances).=

Say, if an= existing model doesn’t support multiple instances, and in the future= for some reason we need to manage them as multiple instances. How do we extend the existing model?

<= /blockquote>

Republish the model with the new key.
=
 

&nb= sp;

Req-3a/Gap= -3a: Configuring a service under another

E.g., the = above mentioned OSPF module is defined under the routing instance (VRF) def= ined in routing model through augment:  

augment "/rt:routing/rt:routing-instance/rt:routing-= protocols/"

         + "= rt:routing-protocol" {

 &nbs= p;   list ospf-router {

 &nbs= p;   ...

Then, we c= ould configure the OSPF under the routing data model, there is no problem/g= ap with this example. However, consider another example: if we’re going to write a new model, say, L3VPN, can we just re-use the= whole routing model also through augment? (Just to confirm, I’m not = sure whether YANG is able to do this or not. If YANG is already be able to = do it, then maybe we should remove the gap.)

&nb= sp;

Req-3b/Gap= -3b: a YANG model needs to be aware of the other’s multiple instances=

E.g., when= the above mentioned OSPF model defines “ospf:ospf-af [vrf-name afi s= afi]” to support multiple OSPF engines (instances), it means the OSPF model be aware of the VRF multiple instances, and there is an implica= tion that the OSPF instance is binding to the VRF instance. This kind of aw= areness/binding might face the scalability issue. Say, if something like VR= F comes out in the future, how does current OSPF model to support that new kind of instance?

&nb= sp;

For "= YANG mount" draft, my personal understanding is that it is a container= to collect different modules in other location together in one place. While the above gaps are more regarding to relationships between different= models. I think they have different scopes.

&nb= sp;

Best regar= ds,

Bing

&nb= sp;

&nb= sp;


Andy
 

=

&nb= sp;

 

On Wed, Jul 2, 2014 at 2:51 AM,= Liubing (Leo) <leo.liubing@huawei.com> wrote:

Hi all in Netconf & Netmod,=

In last Netconf meeting in London, my colleague Guangying Zheng raised a qu= estion at the mike about how to distinguish multiple VRFs when using NETCON= F to configure a device.
And then in the mailing list, David Lamparter led a very good discussion of= the problem.

As discussed in the mailing list, it is not only regarding to VRF, rather, = it is quite a general issue.
So we wrote a draft to try to make a comprehensive discussion of the issue.= The draft analyzes the management requirements for multiple instances like= VRF, and pointed out some gaps in current NETCONF protocol and YANG models= . At last, the draft briefly discuss some possible solutions to fill the gaps.

Please review the draft and comment.
Many thanks!

Best regards,
Bing


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Wednesday, July 02, 2014 4:48 PM
To: Liubing (Leo); Liubing (Leo); Yangang; Yangang
Subject: New Version Notification for draft-liu-netconf-multi-instances-00.= txt


A new version of I-D, draft-liu-netconf-multi-instances-00.txt
has been successfully submitted by Bing Liu and posted to the IETF reposito= ry.

Name:           draft-liu-netconf-multi-instances<= br> Revision:       00
Title:          Multi-Instances Configuration Issu= e in NETCONF
Document date:  2014-07-02
Group:          Individual Submission
Pages:          10
URL:            http://www.ietf.org/internet-drafts/draft-liu-netconf-multi-instances-00= .txt
Status:         https://datatracker.ietf.org/doc/draft-liu-netconf-multi-instances/
Htmlized:       http://tools.ietf.org/html/draft-liu-netconf-multi-instances-00


Abstract:
   This document puts together the NETCONF issues of configuring<= br>    multiple instances including configuring multiple network elem= ent
   instances and multiple service instances. The main problem is = how to
   configure the multiple instances in one NETCONF channel.




Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

 


--001a11c1721ee2011004fd60092c-- From nobody Mon Jul 7 00:45:48 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBFE1B2793; Mon, 7 Jul 2014 00:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.816 X-Spam-Level: X-Spam-Status: No, score=-2.816 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LONGWORDS=2.035, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 9JLgVWlI4er0; Mon, 7 Jul 2014 00:45:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C48D51A8BB3; Mon, 7 Jul 2014 00:45:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJR87830; Mon, 07 Jul 2014 07:45:38 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 7 Jul 2014 08:45:00 +0100 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.24]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Mon, 7 Jul 2014 15:44:48 +0800 From: "Liubing (Leo)" To: Andy Bierman Thread-Topic: [Netconf] Multiple instances configuration issues-//FW: New Version Notification for draft-liu-netconf-multi-instances-00.txt Thread-Index: AQHPldswcHtSPLODJEKU9E5gnW6XrZuMlwyAgAEfORCAAdZYgIAEmsjA Date: Mon, 7 Jul 2014 07:44:48 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D8F12D1@nkgeml506-mbx.china.huawei.com> References: <8AE0F17B87264D4CAC7DE0AA6C406F453D8ED5BF@nkgeml506-mbx.china.huawei.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D8F0652@nkgeml506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.132] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8F12D1nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/-6vDWsHqaA97l38Ac1fhEEO87bQ Cc: Zhengguangying , Netconf , "netmod@ietf.org" , Yangang Subject: Re: [Netconf] Multiple instances configuration issues-//FW: New Version Notification for draft-liu-netconf-multi-instances-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 07:45:45 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8F12D1nkgeml506mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andy, Hi, I read your draft and it I can see use-cases for a context-ID. I prefer to think of named virtual hosts in Apache2, rather than SNMP contexts. [Bing] May I ask the specific reasons that you don't prefer SNMP context? We also had some concern that since context doesn't specify the content, it= may have problem on standardization. But we just thought it could be a fam= iliar concept to the network management people. I think SNMP Context has been misused. IMO it is better to have an explicit index in a data structure schema, rather than add an INDEX on the = side using the context-ID. [Bing] I see your point. An explicit data structure schema might be better = for standardization. We'll consider your approach at the solution discussio= n stage. I don't think your solution is fully specified, but it is a good start. [Bing] Yes, the solution part of the document is mostly a hint for further = discussion. At this stage, we'd like to hear more opinions on the problem/g= ap analysis part. I think the following solution could easily work, which is just a refinement of your solution in sec. 4.1. 1) define a 'server-id' XML attribute 2) define a NETCONF 'virtual-server' capability indicating the server supp= orts the 'server-id' attribute 3) the server is already required to accept all attributes in the st= art tag and return them in the start tag. (So sending the server-id attribute= is safe in all cases). 4) If the server supports the capability, then it must check for the serve= r-id attribute in each and use the correct virtual server or else return an error if it is an= unknown server-id. [Bing] We thought your proposal is also a good solution. If we go this way, then there might be a problem that is a single "server-i= d" sufficient to identify the targeted instance? Since LS and VS might co-e= xist in one device, thus one LS might contain multiple VSes. Then there com= es a hierarchy of the server-id. Maybe we need a comprehensive structure to= well express the hierarchical id? But you had a single context-id. How is that any different? [Bing] Context doesn't specify the content, so it could be coded to implici= tly express the hierarchical id. Nevertheless, I was not arguing context is better on this issue. I was just= thinking, if we follow the way of explicitly specifying the "server-id" at= tribute, then maybe the attribute itself needs to support hierarchy express= of the targeted instance. Named virtual hosts are useful in Apache2 because allocating an IP address = to each WEB server is not always possible. Each virtual server is its own ins= tance and content is independent across virtual servers. Each HTTP request is routed= from the real server to the correct virtual server, based on the hostname in the URL= . A hierarchy would have to be based on content, and in that case, a data modeling solution is needed, not nested virtual servers. [Bing] This is the HTTP Server case. Considering a complicated router, whi= ch is divided into several Logical Systems, and each Logical System contain= several Virtual Systems doing different routing tasks. Then a single hostn= ame is not sufficient enough to represent the VS, there needs to be a hiera= rchical expression such as "LS_name.VS_name". I don't really understand Gap-2 and Gap-3 so I am not addressing that. It = looks like it might overlap the "YANG mount" draft (draft-clemm-netmod-mount-01). IMO that is a completely different problem -- configuration of a mid-level-= manager. [Bing] Gap-2 and Gap-3 are indeed regarding to YANG rather than NETCONF. Le= t me explain them with some examples. Req-2/Gap-2: a YANG model itself needs to support multiple instances, for e= xample: - the routing model (draft-ietf-netmod-routing-cfg) clearly defines = "routing instance" to support VRF instances - the OSPF model (draft-yeung-netmod-ospf) defines "ospf:ospf-af [vr= f-name afi safi]" to support multiple OSPF engines (instances). Say, if an existing model doesn't support multiple instances, and in the fu= ture for some reason we need to manage them as multiple instances. How do w= e extend the existing model? Republish the model with the new key. [Bing] This is certainly an approach. We including this as a gap is to see whether there could be a more scalable= solution, such as Section 4.2 "Common Service Container". Best regards, Bing Req-3a/Gap-3a: Configuring a service under another E.g., the above mentioned OSPF module is defined under the routing instance= (VRF) defined in routing model through augment: augment "/rt:routing/rt:routing-instance/rt:routing-protocols/" + "rt:routing-protocol" { list ospf-router { ... Then, we could configure the OSPF under the routing data model, there is no= problem/gap with this example. However, consider another example: if we're= going to write a new model, say, L3VPN, can we just re-use the whole routi= ng model also through augment? (Just to confirm, I'm not sure whether YANG = is able to do this or not. If YANG is already be able to do it, then maybe = we should remove the gap.) Req-3b/Gap-3b: a YANG model needs to be aware of the other's multiple insta= nces E.g., when the above mentioned OSPF model defines "ospf:ospf-af [vrf-name a= fi safi]" to support multiple OSPF engines (instances), it means the OSPF m= odel be aware of the VRF multiple instances, and there is an implication th= at the OSPF instance is binding to the VRF instance. This kind of awareness= /binding might face the scalability issue. Say, if something like VRF comes= out in the future, how does current OSPF model to support that new kind of= instance? For "YANG mount" draft, my personal understanding is that it is a container= to collect different modules in other location together in one place. Whil= e the above gaps are more regarding to relationships between different mode= ls. I think they have different scopes. Best regards, Bing Andy On Wed, Jul 2, 2014 at 2:51 AM, Liubing (Leo) > wrote: Hi all in Netconf & Netmod, In last Netconf meeting in London, my colleague Guangying Zheng raised a qu= estion at the mike about how to distinguish multiple VRFs when using NETCON= F to configure a device. And then in the mailing list, David Lamparter led a very good discussion of= the problem. As discussed in the mailing list, it is not only regarding to VRF, rather, = it is quite a general issue. So we wrote a draft to try to make a comprehensive discussion of the issue.= The draft analyzes the management requirements for multiple instances like= VRF, and pointed out some gaps in current NETCONF protocol and YANG models= . At last, the draft briefly discuss some possible solutions to fill the ga= ps. Please review the draft and comment. Many thanks! Best regards, Bing -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Wednesday, July 02, 2014 4:48 PM To: Liubing (Leo); Liubing (Leo); Yangang; Yangang Subject: New Version Notification for draft-liu-netconf-multi-instances-00.= txt A new version of I-D, draft-liu-netconf-multi-instances-00.txt has been successfully submitted by Bing Liu and posted to the IETF reposito= ry. Name: draft-liu-netconf-multi-instances Revision: 00 Title: Multi-Instances Configuration Issue in NETCONF Document date: 2014-07-02 Group: Individual Submission Pages: 10 URL: http://www.ietf.org/internet-drafts/draft-liu-netconf-multi= -instances-00.txt Status: https://datatracker.ietf.org/doc/draft-liu-netconf-multi-in= stances/ Htmlized: http://tools.ietf.org/html/draft-liu-netconf-multi-instance= s-00 Abstract: This document puts together the NETCONF issues of configuring multiple instances including configuring multiple network element instances and multiple service instances. The main problem is how to configure the multiple instances in one NETCONF channel. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8F12D1nkgeml506mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andy,

 = ;

Hi,

 

I read your draft and it I can see use-cases = for a context-ID.

I prefer to think of named virtual hosts in A= pache2, rather than

SNMP contexts.

[Bing] May I ask the spe= cific reasons that you don’t prefer SNMP context?

We also had some concern= that since context doesn’t specify the content, it may have problem on standardization. But we just thought it could be a familiar con= cept to the network management people.

 

 

I think SNMP Context has been m= isused.  IMO it is better to have an

explicit index in a data struct= ure schema, rather than add an INDEX on the side

using the context-ID.

[Bing] = I see your point. An explicit data structure schema might be better for sta= ndardization. We’ll consider your approach at the solution discussion= stage.

 

I don't think your solution is fully specifie= d, but it is a good start.

[Bing] Yes, the solution= part of the document is mostly a hint for further discussion. At this stage, we’d like to hear more opinions on the problem/gap an= alysis part.

 

I think the following solution could easily w= ork, which is just a

refinement of your solution in sec. 4.1.=

 

 1) define a 'server-id' XML attribute

 2) define a NETCONF 'virtual-server' ca= pability indicating the server supports the 'server-id' attribute

 3) the server is already required to ac= cept all attributes in the <rpc> start tag and return

     them in the <rpc-reply= > start tag. (So sending the server-id attribute is safe in all cases).<= o:p>

 4) If the server supports the capabilit= y, then it must check for the server-id attribute in each <rpc><= /o:p>

     and use the correct virtu= al server or else return an error if it is an unknown server-id.=

 

[Bing] We thought your p= roposal is also a good solution.

If we go this way, then = there might be a problem that is a single “server-id” sufficien= t to identify the targeted instance? Since LS and VS might co-exist in one d= evice, thus one LS might contain multiple VSes. Then there comes a hierarch= y of the server-id. Maybe we need a comprehensive structure to well express= the hierarchical id?

 

 

 

But you had a single context-id= .  How is that any different?

[Bing] = Context doesn't specify the content, so it could be coded to implicitly exp= ress the hierarchical id.

Neverth= eless, I was not arguing context is better on this issue. I was just thinki= ng, if we follow the way of explicitly specifying the “server-id̶= 1; attribute, then maybe the attribute itself needs to support hierarchy express of the targeted instance.  

 

Named virtual hosts are useful = in Apache2 because allocating an IP address to

each WEB server is not always p= ossible.  Each virtual server is its own instance and

content is independent across v= irtual servers.  Each HTTP request is routed from the

real server to the correct virt= ual server, based on the hostname in the URL.

 

A hierarchy would have to be ba= sed on content, and in that case,

a data modeling solution is nee= ded, not nested virtual servers.

[Bing] = This is the HTTP Server case.  Considering a complicated router, which= is divided into several Logical Systems, and each Logical System contain s= everal Virtual Systems doing different routing tasks. Then a single hostname is not sufficient enough to represent the VS= , there needs to be a hierarchical expression such as “LS_name.VS_nam= e”.

 

 

 

I don't really understand Gap-2 and Gap-3 so = I am not addressing that.  It looks like

it might overlap the "YANG mount" d= raft (draft-clemm-netmod-mount-01).

IMO that is a completely different problem --= configuration of a mid-level-manager.

 

[Bing] Gap-2 and Gap-3 a= re indeed regarding to YANG rather than NETCONF. Let me explain them with some examples.

 

Req-2/Gap-2: a YANG mode= l itself needs to support multiple instances, for example:

-=  &= nbsp;      the routing model (draft-i= etf-netmod-routing-cfg) clearly defines “routing instance” to s= upport VRF instances

-=  &= nbsp;      the OSPF model (draft-yeun= g-netmod-ospf) defines “ospf:ospf-af [vrf-name afi safi]” to su= pport multiple OSPF engines (instances).

Say, if an existing mode= l doesn’t support multiple instances, and in the future for some reason we need to manage them as multiple instances. How do we extend= the existing model?

 

Republish the model with the ne= w key.

[Bing] = This is certainly an approach.

We incl= uding this as a gap is to see whether there could be a more scalable soluti= on, such as Section 4.2 “Common Service Container”.<= /span>

 = ;

Best re= gards,

Bing

 

Req-3a/Gap-3a: Configuri= ng a service under another

E.g., the above mentione= d OSPF module is defined under the routing instance (VRF) defined in routing model through augment:  <= /o:p>

augment "/rt:routing/rt:rout= ing-instance/rt:routing-protocols/"

     &nb= sp;   + "rt:routing-protocol" {

    = list ospf-router {

    = ...

Then, we could configure= the OSPF under the routing data model, there is no problem/gap with this example. However, consider another example: if we’re going= to write a new model, say, L3VPN, can we just re-use the whole routing mod= el also through augment? (Just to confirm, I’m not sure whether YANG = is able to do this or not. If YANG is already be able to do it, then maybe we should remove the gap.)

 

Req-3b/Gap-3b: a YANG mo= del needs to be aware of the other’s multiple instances

E.g., when the above men= tioned OSPF model defines “ospf:ospf-af [vrf-name afi safi]” to support multiple OSPF engines (instances), it means the OSPF model be a= ware of the VRF multiple instances, and there is an implication that the OS= PF instance is binding to the VRF instance. This kind of awareness/binding = might face the scalability issue. Say, if something like VRF comes out in the future, how does current OSPF = model to support that new kind of instance?

 

For "YANG mount&quo= t; draft, my personal understanding is that it is a container to collect different modules in other location together in one place. While the above= gaps are more regarding to relationships between different models. I think= they have different scopes.<= /p>

 

Best regards,

Bing

 

 

 

Andy

 

 

 

On Wed, Jul 2, 2014 at 2:51 AM, Liubing (Leo)= <leo.liubin= g@huawei.com> wrote:

Hi all in Netconf & Netmod,

In last Netconf meeting in London, my colleague Guangying Zheng raised a qu= estion at the mike about how to distinguish multiple VRFs when using NETCON= F to configure a device.
And then in the mailing list, David Lamparter led a very good discussion of= the problem.

As discussed in the mailing list, it is not only regarding to VRF, rather, = it is quite a general issue.
So we wrote a draft to try to make a comprehensive discussion of the issue.= The draft analyzes the management requirements for multiple instances like= VRF, and pointed out some gaps in current NETCONF protocol and YANG models= . At last, the draft briefly discuss some possible solutions to fill the gaps.

Please review the draft and comment.
Many thanks!

Best regards,
Bing


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Wednesday, July 02, 2014 4:48 PM
To: Liubing (Leo); Liubing (Leo); Yangang; Yangang
Subject: New Version Notification for draft-liu-netconf-multi-instances-00.= txt


A new version of I-D, draft-liu-netconf-multi-instances-00.txt
has been successfully submitted by Bing Liu and posted to the IETF reposito= ry.

Name:           draft-liu-netconf-multi-instances<= br> Revision:       00
Title:          Multi-Instances Configuration Issu= e in NETCONF
Document date:  2014-07-02
Group:          Individual Submission
Pages:          10
URL:            http://www.ietf.org/internet-drafts/draft-liu-netconf-multi-instances-00= .txt
Status:         https://datatracker.ietf.org/doc/draft-liu-netconf-multi-instances/
Htmlized:       http://tools.ietf.org/html/draft-liu-netconf-multi-instances-00


Abstract:
   This document puts together the NETCONF issues of configuring<= br>    multiple instances including configuring multiple network elem= ent
   instances and multiple service instances. The main problem is = how to
   configure the multiple instances in one NETCONF channel.




Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

 

 

--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D8F12D1nkgeml506mbxchi_-- From nobody Tue Jul 8 01:59:55 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658811B27A8 for ; Tue, 8 Jul 2014 01:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.551 X-Spam-Level: X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 00P-n7B4j2B4 for ; Tue, 8 Jul 2014 01:59:51 -0700 (PDT) Received: from mailgw12.technion.ac.il (mailgw12.technion.ac.il [132.68.225.12]) by ietfa.amsl.com (Postfix) with ESMTP id E8DC51B27A7 for ; Tue, 8 Jul 2014 01:59:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8BAGmyu1OERAEijGdsb2JhbABZg2Bagm+ofQEBBppDAYEXFg8BAQEnPIQDAQECAgEjFUEFCwsaAiYCAiwrBxKIOggNr1KUF4UmF4EshESJMgeCdzaBFgWKS5AqgUmQa4UfgWsE X-IPAS-Result: Ak8BAGmyu1OERAEijGdsb2JhbABZg2Bagm+ofQEBBppDAYEXFg8BAQEnPIQDAQECAgEjFUEFCwsaAiYCAiwrBxKIOggNr1KUF4UmF4EshESJMgeCdzaBFgWKS5AqgUmQa4UfgWsE X-IronPort-AV: E=Sophos;i="5.01,624,1400014800"; d="scan'208";a="114746240" Received: from webmail.technion.ac.il ([132.68.1.34]) by mailgw12.technion.ac.il with ESMTP; 08 Jul 2014 11:58:57 +0300 Received: by webmail.technion.ac.il (Postfix, from userid 48) id 9CF9B100160; Tue, 8 Jul 2014 11:58:55 +0300 (IDT) Received: from galiil.marvell.com (galiil.marvell.com [199.203.130.254]) by webmail.technion.ac.il (Horde Framework) with HTTP; Tue, 08 Jul 2014 11:58:55 +0300 Date: Tue, 08 Jul 2014 11:58:55 +0300 Message-ID: <20140708115855.Horde.rFgl4H0DArT_m_BHVYuy-A1@webmail.technion.ac.il> From: Tal Mizrahi To: netconf@ietf.org, mehmet.ersue@nsn.com, bertietf@bwijnen.net References: <20140626085221.Horde.gldxHIFgJCZsYtIR3JuSHg9@webmail.technion.ac.il> In-Reply-To: <20140626085221.Horde.gldxHIFgJCZsYtIR3JuSHg9@webmail.technion.ac.il> User-Agent: Internet Messaging Program (IMP) H5 (6.1.3) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/YYECSUFR5PJ5Edu8DWsIG5F9HFM Cc: moses@ee.technion.ac.il Subject: Re: [Netconf] Updated draft-mm-netconf-time-capability-02 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 08:59:54 -0000 Hi All, This draft has been around for about a year, and has significantly improved based on the comments we received. A couple of people have expressed their support, and others have raised some technical concerns. We believe we have addressed the lion's share of these concerns, and that the draft is ready to be adopted by the WG. We would like to encourage comments about the updated draft, which will allow us to see whether we have indeed addressed the concerns that have been previously raised. Comments will be welcome. Regards, Tal. Quoting Tal Mizrahi : > Hi, > > We have posted an updated draft. > http://tools.ietf.org/html/draft-mm-netconf-time-capability-02 > > Summary of the changes compared to the previous draft: > - We have added a YANG module that defines the time capability. > - Following the feedback we received, two significant features were > added: notifications and cancellation messages. > - Added a detailed discussion about near future scheduling vs. far > future scheduling. > - The current draft also includes a description of how the client > can check whether the server has a synchronized clock or not. > - Several typo fixes and phrasing improvements. > > Many thanks to those who reviewed and helped us improve the draft. > We believe this draft has significantly matured, and that it is > ready for WG adoption. > > Comments will be welcome. > Thanks, > Tal and Yoram. From nobody Tue Jul 8 06:24:53 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600651B283B for ; Tue, 8 Jul 2014 06:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 bF5d1Kgn_9HP for ; Tue, 8 Jul 2014 06:24:49 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF3501B283C for ; Tue, 8 Jul 2014 06:24:48 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s68DOliO031616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 8 Jul 2014 13:24:47 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s68DOkh2023059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 8 Jul 2014 15:24:47 +0200 Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 8 Jul 2014 15:24:46 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.136]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0181.006; Tue, 8 Jul 2014 15:24:46 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: netconf Thread-Topic: Draft NETCONF Session Agenda for IETF #90 Thread-Index: Ac+ar/wyx7lVW7Z3REOzSpmHTGSnxQ== Date: Tue, 8 Jul 2014 13:24:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.99] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F8392F7DDEMUMBX005nsnintr_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2245 X-purgate-ID: 151667::1404825887-000005B1-BF90FAB6/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Et-vHp7hxqdg32xOO7K3I2GWIJQ Subject: [Netconf] Draft NETCONF Session Agenda for IETF #90 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 13:24:51 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F8392F7DDEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, please find below the draft agenda for the NETCONF session at IETF #90. http://www.ietf.org/proceedings/90/agenda/agenda-90-netconf Regards, Mehmet --_000_E4DE949E6CE3E34993A2FF8AE79131F8392F7DDEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear NETCONF WG,
 
please find below the draft agenda for the NET= CONF session at IETF #90.
 
Regards,
Mehmet
 
&nbs= p;
&nbs= p;
 --_000_E4DE949E6CE3E34993A2FF8AE79131F8392F7DDEMUMBX005nsnintr_-- From nobody Wed Jul 9 02:01:04 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C261A0337 for ; Wed, 9 Jul 2014 02:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_44=0.6, RP_MATCHES_RCVD=-0.651] autolearn=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 q_9vHH8lYjzE for ; Wed, 9 Jul 2014 02:01:02 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF19B1A01DD for ; Wed, 9 Jul 2014 02:01:01 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7593F75A for ; Wed, 9 Jul 2014 11:01:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id jDYJAMFQNIE1 for ; Wed, 9 Jul 2014 11:00:48 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 9 Jul 2014 11:00:59 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B425A2002F for ; Wed, 9 Jul 2014 11:00:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2P9o8yfSxLd7; Wed, 9 Jul 2014 11:00:59 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B277520017; Wed, 9 Jul 2014 11:00:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BDEE12DD36AB; Wed, 9 Jul 2014 11:00:57 +0200 (CEST) Date: Wed, 9 Jul 2014 11:00:55 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20140709090055.GA86512@elstar.local> Mail-Followup-To: netconf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/wZ92FVOBJiWWTHw2ZTDEt9JyPjY Subject: [Netconf] netconf server listening endpoints X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 09:01:03 -0000 Hi, draft-ietf-netconf-server-model-01 uses this model for listening endpoints: +--rw listen +--rw ssh {ssh-listen}? | +--rw (one-or-many)? | +--:(one-port) | | +--rw port? inet:port-number | +--:(many-ports) | +--rw interface* [address] | +--rw address inet:host | +--rw port? inet:port-number +--rw tls {tls-listen}? +--rw (one-or-many)? +--:(one-port) | +--rw port? inet:port-number +--:(many-ports) +--rw interface* [address] +--rw address inet:host +--rw port? inet:port-number In other data models, we used a pattern that looks like this: +--rw listen* [name] +--rw name string +--rw (transport) +--:(ssh) {ssh-listen}? +--rw ssh +--rw address inet:ip-address +--rw port? inet:port-number +--:(tls) {tls-listen}? +--rw tls +--rw address inet:ip-address +--rw port? inet:port-number The main differences are: - There is no shortcut for configuring just a different port. In fact, the semantics of this in the I-D are not clear; if I set the port to 1234, does it mean I am listening on this port on all interfaces for all versions of IP supported? - Every configured transport endpoint gets keyed by an artificial key. This allows for extensions, e.g., to support VRFs, without having to replace the definition. The solution in the I-D also has the problem that I can't listen on multiple ports on the same IP address since the interface list is keyed by address. /js PS: The Tree Diagram text should explain the notation of features. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jul 9 02:11:55 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6741A0012 for ; Wed, 9 Jul 2014 02:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 ZV6Ktx4j8DVc for ; Wed, 9 Jul 2014 02:11:52 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F3F11A033A for ; Wed, 9 Jul 2014 02:11:52 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 49590F6A for ; Wed, 9 Jul 2014 11:11:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id vBVt7WyMXVhy for ; Wed, 9 Jul 2014 11:11:39 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 9 Jul 2014 11:11:50 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B645C2002C for ; Wed, 9 Jul 2014 11:11:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6-Dc-OIp_D3E; Wed, 9 Jul 2014 11:11:50 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B3C1C2002F; Wed, 9 Jul 2014 11:11:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 99EC22DD3707; Wed, 9 Jul 2014 11:11:49 +0200 (CEST) Date: Wed, 9 Jul 2014 11:11:49 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20140709091149.GA86588@elstar.local> Mail-Followup-To: netconf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/IKDNEHq2LRlDiQiIi8lRieF4pzg Subject: [Netconf] netconf server terminology X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 09:11:54 -0000 Hi, the document introduces the term 'application' in section 2. There is no clear definition provided but I think it is reasonably clear what is meant in section 2. The data model later on used the term 'network managers' which I tend to be believe is the same as 'application' in section 2. If this is correct, I would prefer to have just a single term that is used consistently throughout the document. Since RFC 6244 seems to use 'application' and 'client application', I think it makes sense to go with one of these terms and to get rid of 'network managers'. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jul 9 02:56:58 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDDE31A03DA for ; Wed, 9 Jul 2014 02:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_44=0.6, RP_MATCHES_RCVD=-0.651] autolearn=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 EfGp-ILxOuf5 for ; Wed, 9 Jul 2014 02:56:56 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B88AF1A03D9 for ; Wed, 9 Jul 2014 02:56:55 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8270A74D for ; Wed, 9 Jul 2014 11:56:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id O-BJRhDV9IZl for ; Wed, 9 Jul 2014 11:56:42 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 9 Jul 2014 11:56:53 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B2D2F20017 for ; Wed, 9 Jul 2014 11:56:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FJzTD1DUeRy8; Wed, 9 Jul 2014 11:56:53 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB3D82002C; Wed, 9 Jul 2014 11:56:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C97542DD37E7; Wed, 9 Jul 2014 11:56:51 +0200 (CEST) Date: Wed, 9 Jul 2014 11:56:51 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20140709095649.GB86588@elstar.local> Mail-Followup-To: netconf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/7eI2DV6aNqv40o9KvJMdy3tezrg Subject: [Netconf] netconf server outgoing endpoints X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 09:56:57 -0000 Hi, draft-ietf-netconf-server-model-01 uses this model for outgoing connections to NETCONF client applications: +--rw call-home +--rw network-managers +--rw network-manager* [name] +--rw name string +--rw description? string +--rw endpoints | +--rw endpoint* [address] | +--rw address inet:host | +--rw port? inet:port-number +--rw transport | +--rw ssh {ssh-call-home}? | | +--rw host-keys | | +--rw host-key* [name] | | +--rw name string | +--rw tls! {tls-call-home}? Again, I think there are potential issues due to the indexing and to support extensibility. An alternative solution may look like this: +--rw call-home +--rw application* [name] +--rw name string +--rw endpoints* [name] +--rw name string +--rw (transport) +--:(ssh) {ssh-call-home}? | +--rw ssh | +--rw address inet:ip-host | +--rw port? inet:port-number | +--rw host-key* [name] | +--rw name string +--:(tls) {tls-call-home}? +--rw tls +--rw address inet:ip-host +--rw port? inet:port-number The host-key I copied over from draft-ietf-netconf-server-model-01 but I am not sure it is well enough defined to allow for interoperable implementations. The relevant text is: list host-key { key name; min-elements 1; // requires 'ssh' element? ordered-by user; leaf name { type string; mandatory true; description "The name of a host key the device should advertise during the SSH key exchange."; } } Is it clear what a 'name of a host key' is up to the point that different implementations do exactly the same thing? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jul 9 03:07:50 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE761A03E4 for ; Wed, 9 Jul 2014 03:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 eELbQAktZ9P1 for ; Wed, 9 Jul 2014 03:07:44 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 336A11A03DE for ; Wed, 9 Jul 2014 03:07:44 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 85951753 for ; Wed, 9 Jul 2014 12:07:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id OxMzJs_ItAwq for ; Wed, 9 Jul 2014 12:07:30 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 9 Jul 2014 12:07:41 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E06E72002C for ; Wed, 9 Jul 2014 12:07:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3w1agw1nEhgT; Wed, 9 Jul 2014 12:07:41 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1DABD20017; Wed, 9 Jul 2014 12:07:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 028392DD381F; Wed, 9 Jul 2014 12:07:40 +0200 (CEST) Date: Wed, 9 Jul 2014 12:07:40 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20140709100740.GA86767@elstar.local> Mail-Followup-To: netconf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/9ZQVtXjanoOm47qgyYb1vnBcWVI Subject: [Netconf] netconf server cert/psk mapping X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 10:07:46 -0000 Hi, these mappings have been turned into augmentations of the system data model. I am not yet 100% convinced this is the way to go, at least it looks strange to have the mapping in the SNMP specific part for SNMP and kind of globally defined for NETCONF. I do not know how RESTCONF is going to address this issue. Is there a requirement that the name falling out of the mapping (e.g. extracted from the cert itself) must match a valid /system/authentication/user/name or does this create a completely orthogonal way of authenticating users to the system (note that this is system scope, not service scope). I am not sure system scope is the right thing here. Nits: - ietf-x509-cert-to-name is defined in I-D.ietf-netconf-snmp-cfg and not in I-D.ietf-netconf-rfc5539bis. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jul 9 18:55:53 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7499B1A01A0 for ; Wed, 9 Jul 2014 18:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 JaNfGyFwn7qN for ; Wed, 9 Jul 2014 18:55:48 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E891A0193 for ; Wed, 9 Jul 2014 18:55:48 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.0.980.8; Thu, 10 Jul 2014 01:55:46 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.73]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.73]) with mapi id 15.00.0980.000; Thu, 10 Jul 2014 01:55:46 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "netconf@ietf.org" Thread-Topic: [Netconf] netconf server terminology Thread-Index: AQHPm1XWyiotjXxEFkK/VTJCIqEzSpuYSmGA Date: Thu, 10 Jul 2014 01:55:45 +0000 Message-ID: References: <20140709091149.GA86588@elstar.local> In-Reply-To: <20140709091149.GA86588@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [66.129.241.17] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0268246AE7 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(479174003)(377454003)(24454002)(51704005)(64706001)(81342001)(20776003)(81542001)(46102001)(76176999)(107886001)(99396002)(66066001)(80022001)(50986999)(74662001)(74502001)(106116001)(77096002)(31966008)(54356999)(83506001)(36756003)(85306003)(86362001)(4396001)(92566001)(92726001)(19580405001)(76482001)(95666004)(85852003)(77982001)(19580395003)(15975445006)(99286002)(107046002)(106356001)(83322001)(15202345003)(87936001)(101416001)(105586002)(21056001)(79102001)(83072002)(2656002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <80E77F620801C848842A581B5EB44B23@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/VvdKeSw2PJom3A61UsMflcR69N8 Subject: Re: [Netconf] netconf server terminology X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 01:55:50 -0000 Fair enough, I cleaned up a lot of terminology already, but expected there would be a need for more. Thanks for your review. Kent On 7/9/14, 5:11 AM, "Juergen Schoenwaelder" wrote: >Hi, > >the document introduces the term 'application' in section 2. There is >no clear definition provided but I think it is reasonably clear what >is meant in section 2. The data model later on used the term 'network >managers' which I tend to be believe is the same as 'application' in >section 2. If this is correct, I would prefer to have just a single >term that is used consistently throughout the document. Since RFC 6244 >seems to use 'application' and 'client application', I think it makes >sense to go with one of these terms and to get rid of 'network >managers'. > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Jul 9 19:10:45 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0161A1A0403 for ; Wed, 9 Jul 2014 19:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 2Y6HcsWChjoh for ; Wed, 9 Jul 2014 19:10:41 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0184.outbound.protection.outlook.com [207.46.163.184]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4165B1A01D6 for ; Wed, 9 Jul 2014 19:10:41 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.0.980.8; Thu, 10 Jul 2014 02:10:39 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.73]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.73]) with mapi id 15.00.0980.000; Thu, 10 Jul 2014 02:10:38 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "netconf@ietf.org" Thread-Topic: [Netconf] netconf server listening endpoints Thread-Index: AQHPm1RUVAHQ0WPvJ0+8xBgkNhtQ8ZuYTowA Date: Thu, 10 Jul 2014 02:10:37 +0000 Message-ID: References: <20140709090055.GA86512@elstar.local> In-Reply-To: <20140709090055.GA86512@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [66.129.241.17] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0268246AE7 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(164054003)(377454003)(479174003)(24454002)(189002)(199002)(51704005)(50986999)(81342001)(31966008)(64706001)(2656002)(15202345003)(76176999)(74502001)(19580395003)(36756003)(66066001)(86362001)(81542001)(20776003)(87936001)(83322001)(19580405001)(80022001)(21056001)(107046002)(54356999)(106356001)(107886001)(46102001)(4396001)(15975445006)(79102001)(92726001)(76482001)(101416001)(83072002)(77982001)(99396002)(85852003)(105586002)(74662001)(106116001)(77096002)(92566001)(95666004)(85306003)(83506001)(99286002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <25BB1841F7A50B41BE563DDB98025966@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/GBUtlkK5sNkuBPprN1_BKSIrpvY Subject: Re: [Netconf] netconf server listening endpoints X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 02:10:43 -0000 The "one-or-many" was discussed during the meeting in London (I think Martin skeptically said it was interesting), but no follow-up discussion on list and thus it's still in the current version. BY way of explanation, let me throw out that I came up with this construct hoping to optimize what I perceived to be a common case of just needing to just configure a port value, while also needing to configure more than one specific interface/address. Perhaps its not common and worse, as you note below, the alternate choice doesn't support multiple ports on the same IP address (though why this would be needed I'm unsure). Lastly, I think you rightly point out that it bucks tradition - I didn't do this intentionally, I was just doing what I though made sense to me. That said, I wonder if there is any merit to discussing if we can do better. Especially in the area of enabling a service on more than one specific interface/address, something not supported at all by the current strategy? Thanks, Kent On 7/9/14, 5:00 AM, "Juergen Schoenwaelder" wrote: >Hi, > >draft-ietf-netconf-server-model-01 uses this model for listening >endpoints: > > +--rw listen > +--rw ssh {ssh-listen}? > | +--rw (one-or-many)? > | +--:(one-port) > | | +--rw port? inet:port-number > | +--:(many-ports) > | +--rw interface* [address] > | +--rw address inet:host > | +--rw port? inet:port-number > +--rw tls {tls-listen}? > +--rw (one-or-many)? > +--:(one-port) > | +--rw port? inet:port-number > +--:(many-ports) > +--rw interface* [address] > +--rw address inet:host > +--rw port? inet:port-number > >In other data models, we used a pattern that looks like this: > > +--rw listen* [name] > +--rw name string > +--rw (transport) > +--:(ssh) {ssh-listen}? > +--rw ssh > +--rw address inet:ip-address > +--rw port? inet:port-number > +--:(tls) {tls-listen}? > +--rw tls > +--rw address inet:ip-address > +--rw port? inet:port-number > >The main differences are: > > - There is no shortcut for configuring just a different port. In > fact, the semantics of this in the I-D are not clear; if I set the > port to 1234, does it mean I am listening on this port on all > interfaces for all versions of IP supported? > > - Every configured transport endpoint gets keyed by an artificial > key. This allows for extensions, e.g., to support VRFs, without > having to replace the definition. The solution in the I-D also has > the problem that I can't listen on multiple ports on the same IP > address since the interface list is keyed by address. > >/js > >PS: The Tree Diagram text should explain the notation of features. > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Jul 9 19:11:18 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD421A01D6 for ; Wed, 9 Jul 2014 19:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 j8F3xNSVOH8A for ; Wed, 9 Jul 2014 19:11:10 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC411A041D for ; Wed, 9 Jul 2014 19:11:10 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.0.974.11; Thu, 10 Jul 2014 02:11:09 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.73]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.73]) with mapi id 15.00.0980.000; Thu, 10 Jul 2014 02:11:08 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "netconf@ietf.org" Thread-Topic: [Netconf] netconf server cert/psk mapping Thread-Index: AQHPm12mkAYWpqsl7UCnV8/AL8BEUpuYSZ0A Date: Thu, 10 Jul 2014 02:11:08 +0000 Message-ID: References: <20140709100740.GA86767@elstar.local> In-Reply-To: <20140709100740.GA86767@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [66.129.241.17] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0268246AE7 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(24454002)(189002)(479174003)(199002)(164054003)(51704005)(107046002)(83506001)(105586002)(80022001)(31966008)(92566001)(4396001)(86362001)(15202345003)(81342001)(107886001)(66066001)(46102001)(2656002)(106116001)(101416001)(77096002)(50986999)(81542001)(36756003)(64706001)(85852003)(76482001)(54356999)(20776003)(99286002)(95666004)(74662001)(85306003)(99396002)(74502001)(92726001)(15975445006)(83072002)(87936001)(19580405001)(83322001)(77982001)(106356001)(79102001)(21056001)(19580395003)(76176999); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <5401A905AEC6544ABF433D8E2FE7BBFF@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/IlpY1Na8Mj47hGWqmNSh4omZfiQ Subject: Re: [Netconf] netconf server cert/psk mapping X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 02:11:16 -0000 Hi Juergen, I think you're referring to http://tools.ietf.org/html/draft-ietf-netconf-server-model-01#section-5 Defining it globally came about because of Radek's comments here: http://www.ietf.org/mail-archive/web/netconf/current/msg08836.html And the choice to use an augmentation made here: http://www.ietf.org/mail-archive/web/netmod/current/msg09828.html Does it still not seem right? Thanks, Kent On 7/9/14, 6:07 AM, "Juergen Schoenwaelder" wrote: >Hi, > >these mappings have been turned into augmentations of the system data >model. I am not yet 100% convinced this is the way to go, at least it >looks strange to have the mapping in the SNMP specific part for SNMP >and kind of globally defined for NETCONF. I do not know how RESTCONF >is going to address this issue. Is there a requirement that the name >falling out of the mapping (e.g. extracted from the cert itself) must >match a valid /system/authentication/user/name or does this create a >completely orthogonal way of authenticating users to the system (note >that this is system scope, not service scope). I am not sure system >scope is the right thing here. > >Nits: > > - ietf-x509-cert-to-name is defined in I-D.ietf-netconf-snmp-cfg and > not in I-D.ietf-netconf-rfc5539bis. > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Jul 9 19:38:05 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3D11A0240 for ; Wed, 9 Jul 2014 19:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 74adhc_Gh43u for ; Wed, 9 Jul 2014 19:37:59 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14A421A023E for ; Wed, 9 Jul 2014 19:37:58 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.0.980.8; Thu, 10 Jul 2014 02:37:51 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.73]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.73]) with mapi id 15.00.0980.000; Thu, 10 Jul 2014 02:37:51 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "netconf@ietf.org" Thread-Topic: [Netconf] netconf server outgoing endpoints Thread-Index: AQHPm1whROC7MovZy0O11gYhfCof1puYVhiA Date: Thu, 10 Jul 2014 02:37:50 +0000 Message-ID: References: <20140709095649.GB86588@elstar.local> In-Reply-To: <20140709095649.GB86588@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [66.129.241.17] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0268246AE7 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(377454003)(51704005)(479174003)(164054003)(24454002)(79102001)(76482001)(46102001)(74502001)(19580405001)(106116001)(36756003)(31966008)(77096002)(54356999)(99286002)(21056001)(74662001)(76176999)(83506001)(87936001)(83322001)(107046002)(19580395003)(77982001)(66066001)(2656002)(83072002)(101416001)(85306003)(92726001)(4396001)(20776003)(106356001)(80022001)(81542001)(95666004)(50986999)(86362001)(107886001)(64706001)(105586002)(92566001)(81342001)(85852003)(99396002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <8B964A65356FEB438DD04A767020C85D@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/4N-ucIzfqRM3TsrxImNAB_m9HjI Subject: Re: [Netconf] netconf server outgoing endpoints X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 02:38:03 -0000 Comments inline below: On 7/9/14, 5:56 AM, "Juergen Schoenwaelder" wrote: >Hi, > >draft-ietf-netconf-server-model-01 uses this model for outgoing >connections to NETCONF client applications: > > +--rw call-home > +--rw network-managers > +--rw network-manager* [name] > +--rw name string > +--rw description? string > +--rw endpoints > | +--rw endpoint* [address] > | +--rw address inet:host > | +--rw port? inet:port-number > +--rw transport > | +--rw ssh {ssh-call-home}? > | | +--rw host-keys > | | +--rw host-key* [name] > | | +--rw name string > | +--rw tls! {tls-call-home}? > >Again, I think there are potential issues due to the indexing and to >support extensibility. An alternative solution may look like this: > > +--rw call-home > +--rw application* [name] > +--rw name string > +--rw endpoints* [name] > +--rw name string > +--rw (transport) > +--:(ssh) {ssh-call-home}? > | +--rw ssh > | +--rw address inet:ip-host > | +--rw port? inet:port-number > | +--rw host-key* [name] > | +--rw name string > +--:(tls) {tls-call-home}? > +--rw tls > +--rw address inet:ip-host > +--rw port? inet:port-number The use-case here is that a NMS managing a device may have more than one address for availability reasons (e.g., clustering, disaster recovery, hierarchical geographic distribution, etc.). For that given application, the transport used would be identical for all its endpoints. The solution proposed above is more flexible, allowing the transport to be configured distinctly for each endpoint, but I can't see an NMS ever wanting to do that. Can anyone think of a reason, or should we do it just to be safe? > >The host-key I copied over from draft-ietf-netconf-server-model-01 but >I am not sure it is well enough defined to allow for interoperable >implementations. The relevant text is: > > list host-key { > key name; > min-elements 1; // requires 'ssh' element? > ordered-by user; > leaf name { > type string; > mandatory true; > description > "The name of a host key the device should > advertise during the SSH key exchange."; > } > } > >Is it clear what a 'name of a host key' is up to the point that >different implementations do exactly the same thing? This list of host-keys construct maps directly onto OpenSSH's sshd_config file's "HostKey" value. An example value would be ssh_hostkey.pem. The goal/assumption is that the host keys have been configured somewhere else. Perhaps we need to add configuring SSH host-keys to ietf-system via another (or same) augmentation similar to the ietf-system-tls-auth module, also defined in this draft? Thanks, Kent From nobody Thu Jul 10 05:13:40 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5665B1A0407 for ; Thu, 10 Jul 2014 05:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 6bJlJvUf1q-B for ; Thu, 10 Jul 2014 05:13:32 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92D61A037F for ; Thu, 10 Jul 2014 05:13:31 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5000A116D; Thu, 10 Jul 2014 14:13:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id gzC6aXTijhNh; Thu, 10 Jul 2014 14:13:12 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 10 Jul 2014 14:13:29 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A1CFB2002C; Thu, 10 Jul 2014 14:13:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id eSa2kvLXod8M; Thu, 10 Jul 2014 14:13:29 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6578E20017; Thu, 10 Jul 2014 14:13:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1BEB52DD4B9A; Thu, 10 Jul 2014 14:13:26 +0200 (CEST) Date: Thu, 10 Jul 2014 14:13:26 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20140710121326.GA90023@elstar.local> Mail-Followup-To: Kent Watsen , "netconf@ietf.org" References: <20140709090055.GA86512@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ikyT-rRsf_rJ6umGvINYA78t-B0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] netconf server listening endpoints X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 12:13:38 -0000 On Thu, Jul 10, 2014 at 02:10:37AM +0000, Kent Watsen wrote: > > The "one-or-many" was discussed during the meeting in London (I think > Martin skeptically said it was interesting), but no follow-up discussion > on list and thus it's still in the current version. > > BY way of explanation, let me throw out that I came up with this construct > hoping to optimize what I perceived to be a common case of just needing to > just configure a port value, while also needing to configure more than one > specific interface/address. Perhaps its not common and worse, as you note > below, the alternate choice doesn't support multiple ports on the same IP > address (though why this would be needed I'm unsure). Lastly, I think you > rightly point out that it bucks tradition - I didn't do this > intentionally, I was just doing what I though made sense to me. > > That said, I wonder if there is any merit to discussing if we can do > better. Especially in the area of enabling a service on more than one > specific interface/address, something not supported at all by the current > strategy? The 'listen' node in my proposal is a list and hence you can of course listen on more than one specific interface/address. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Jul 10 05:22:02 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2449F1B28B7 for ; Thu, 10 Jul 2014 05:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_44=0.6, RP_MATCHES_RCVD=-0.651] autolearn=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 24CNAQ7Tb3c4 for ; Thu, 10 Jul 2014 05:21:56 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D594C1B28C2 for ; Thu, 10 Jul 2014 05:21:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7A358F63; Thu, 10 Jul 2014 14:21:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id r_LVo1jCumbt; Thu, 10 Jul 2014 14:21:23 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 10 Jul 2014 14:21:40 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 836222002C; Thu, 10 Jul 2014 14:21:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qb1W9Cism_ho; Thu, 10 Jul 2014 14:21:39 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DAB2A20017; Thu, 10 Jul 2014 14:21:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DB5732DD4BD3; Thu, 10 Jul 2014 14:21:37 +0200 (CEST) Date: Thu, 10 Jul 2014 14:21:37 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20140710122135.GB90023@elstar.local> Mail-Followup-To: Kent Watsen , "netconf@ietf.org" References: <20140709095649.GB86588@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/XvGiNuUVvjp7q_Mv186zaywTyWQ Cc: "netconf@ietf.org" Subject: Re: [Netconf] netconf server outgoing endpoints X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 12:21:57 -0000 On Thu, Jul 10, 2014 at 02:37:50AM +0000, Kent Watsen wrote: > > Comments inline below: > > > > On 7/9/14, 5:56 AM, "Juergen Schoenwaelder" > wrote: > > >Hi, > > > >draft-ietf-netconf-server-model-01 uses this model for outgoing > >connections to NETCONF client applications: > > > > +--rw call-home > > +--rw network-managers > > +--rw network-manager* [name] > > +--rw name string > > +--rw description? string > > +--rw endpoints > > | +--rw endpoint* [address] > > | +--rw address inet:host > > | +--rw port? inet:port-number > > +--rw transport > > | +--rw ssh {ssh-call-home}? > > | | +--rw host-keys > > | | +--rw host-key* [name] > > | | +--rw name string > > | +--rw tls! {tls-call-home}? > > > >Again, I think there are potential issues due to the indexing and to > >support extensibility. An alternative solution may look like this: > > > > +--rw call-home > > +--rw application* [name] > > +--rw name string > > +--rw endpoints* [name] > > +--rw name string > > +--rw (transport) > > +--:(ssh) {ssh-call-home}? > > | +--rw ssh > > | +--rw address inet:ip-host > > | +--rw port? inet:port-number > > | +--rw host-key* [name] > > | +--rw name string > > +--:(tls) {tls-call-home}? > > +--rw tls > > +--rw address inet:ip-host > > +--rw port? inet:port-number > > > > The use-case here is that a NMS managing a device may have more than one > address for availability reasons (e.g., clustering, disaster recovery, > hierarchical geographic distribution, etc.). For that given application, > the transport used would be identical for all its endpoints. The solution > proposed above is more flexible, allowing the transport to be configured > distinctly for each endpoint, but I can't see an NMS ever wanting to do > that. Can anyone think of a reason, or should we do it just to be safe? > You can replicate the endpoints list into the ssh and tls containers if you want to prevent this. My main point is that the endpoint list should not be keyed by an address to allow for extensions (e.g. vrfs). > >The host-key I copied over from draft-ietf-netconf-server-model-01 but > >I am not sure it is well enough defined to allow for interoperable > >implementations. The relevant text is: > > > > list host-key { > > key name; > > min-elements 1; // requires 'ssh' element? > > ordered-by user; > > leaf name { > > type string; > > mandatory true; > > description > > "The name of a host key the device should > > advertise during the SSH key exchange."; > > } > > } > > > >Is it clear what a 'name of a host key' is up to the point that > >different implementations do exactly the same thing? > > > This list of host-keys construct maps directly onto OpenSSH's sshd_config > file's "HostKey" value. An example value would be > ssh_hostkey.pem. But we need to make this general and not implementation specific. My understanding of sshd_config's HostKey option is that it specifies where a key is stored. So that means you would not verify a key but only verify where some random key is stored. This is likely not what you want. I guess what you wanted is likely a fingerprint of a host key. It would be nice to be able to refer to something in the SSH specifications. > The goal/assumption is that the host keys > have been configured somewhere else. Perhaps we need to add configuring > SSH host-keys to ietf-system via another (or same) augmentation similar to > the ietf-system-tls-auth module, also defined in this draft? Well, in this case this makes this leaf a reference to something undefined. Not sure this is useful. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Jul 10 05:36:34 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4F01B28BF for ; Thu, 10 Jul 2014 05:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 1_CrG7rfOikV for ; Thu, 10 Jul 2014 05:36:30 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C057B1B28B7 for ; Thu, 10 Jul 2014 05:36:29 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8109E633; Thu, 10 Jul 2014 14:36:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id VHjJbArhR6Fq; Thu, 10 Jul 2014 14:36:10 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 10 Jul 2014 14:36:27 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1913D2002C; Thu, 10 Jul 2014 14:36:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Wf4Ltik3CJvf; Thu, 10 Jul 2014 14:36:26 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 02ED120017; Thu, 10 Jul 2014 14:36:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DE37A2DD4C17; Thu, 10 Jul 2014 14:36:25 +0200 (CEST) Date: Thu, 10 Jul 2014 14:36:25 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20140710123625.GC90023@elstar.local> Mail-Followup-To: Kent Watsen , "netconf@ietf.org" References: <20140709100740.GA86767@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/9JgCtcUO4SBQ-17nkwp7aKZoSEw Cc: "netconf@ietf.org" Subject: Re: [Netconf] netconf server cert/psk mapping X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jul 2014 12:36:31 -0000 On Thu, Jul 10, 2014 at 02:11:08AM +0000, Kent Watsen wrote: > > Hi Juergen, > > I think you're referring to > http://tools.ietf.org/html/draft-ietf-netconf-server-model-01#section-5 Yes. > Defining it globally came about because of Radek's comments here: > http://www.ietf.org/mail-archive/web/netconf/current/msg08836.html Yes, I have seen that exchange. > And the choice to use an augmentation made here: > http://www.ietf.org/mail-archive/web/netmod/current/msg09828.html > > Does it still not seem right? Yes, I likely have issues with this. My understanding of the /system/authentication/user list is that it essentially tells me something about user accounts on a system and how to manage the associated passwords and SSH keys with the goal to make typical SSH access work. And typical SSH access maps the incoming connection into a context of a local system user account. This makes sense since access to remote system accounts was the prime reason for creating SSH in the first place. When we talk about other services, then the notion of a service account is often detached from the notion of system accounts. Lets take SNMP as an example: The SNMP users usually only exist within the SNMP agent, they typically do not map to a local system user account. The same is true for many HTTP based services. To configure say a webdav share, you typically create a user with a password that purely exists in the webdav implementation and does typically not map to a local system user account. The difference between these approaches is not only significant from the implementation background but also from the point of the name spaces. In typical implementations, my SNMP user name space is distinct from my webdav user name space, which is again distinct from my local system user account name space. I guess one of the not clearly answered open questions is which model NC over TLS (and RESTCONF over TLS) should follow - the 'user name space is scoped to a service' model or the 'user name maps to a local system user account' model. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jul 14 05:38:25 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360461A03C7 for ; Mon, 14 Jul 2014 05:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.851 X-Spam-Level: X-Spam-Status: No, score=-9.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 614fzw9vcdUU for ; Mon, 14 Jul 2014 05:38:21 -0700 (PDT) Received: from bgl-iport-3.cisco.com (bgl-iport-3.cisco.com [72.163.197.27]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62E921A03C2 for ; Mon, 14 Jul 2014 05:38:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6844; q=dns/txt; s=iport; t=1405341501; x=1406551101; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=oJ7ubRSsIUMcnjl4xr/0zhyetZw8OE4OnQkStLtKuvQ=; b=VHqZY38pE4fZh85G/VEIbGQskrUithMOnyIRboePZkf1vwHJ9HjFLeq9 B5DFENMP/XhrSslKLz+TOYAzARaJeEwqdatl95hBUZd735O0eJ1GcYA9e /pzZr5KobzkmMPKEOC1GlRTAjh8TH7/djX8QdB3sIRf1hlGF6dpHunh78 M=; X-IronPort-AV: E=Sophos;i="5.01,658,1400025600"; d="scan'208,217";a="8239071" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-3.cisco.com with ESMTP; 14 Jul 2014 12:38:19 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by bgl-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6ECcGYl023518; Mon, 14 Jul 2014 12:38:16 GMT Message-ID: <53C3CF38.2070601@cisco.com> Date: Mon, 14 Jul 2014 14:38:16 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= , Randy Presuhn , "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" References: <30336078.1403297845090.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030604090600090606080104" Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Ua6zess4AMyD_RvwF4oLGDOKwMg Cc: "rob.enns@gmail.com" , "joelja@bogus.com" , "netconf@ietf.org" Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 12:38:23 -0000 This is a multi-part message in MIME format. --------------030604090600090606080104 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Let me try to bring some closure on this errata http://www.rfc-editor.org/errata_search.php?eid=3980 Before proceeding (I want to check with the IESG if this is allowed to introduce a new MUST sentence in an errata), I would like to 1. check that text below is the final proposal 2. understand if there is agreement in the WG. Do someone object this change? OLD: For each sibling set, the server determines which nodes are included (or potentially included) in the filter output, and which sibling subtrees are excluded (pruned) from the filter output. The server first determines which types of nodes are present in the sibling set and processes the nodes according to the rules for their type. If any nodes in the sibling set are selected, then the process is recursively applied to the sibling sets of each selected node. The algorithm continues until all sibling sets in all subtrees specified in the filter have been processed. NEW: For each sibling set, the server determines which nodes are included (or potentially included) in the filter output, and which sibling subtrees are excluded (pruned) from the filter output. The server first determines which types of nodes are present in the sibling set and processes the nodes according to the rules for their type. If any nodes in the sibling set are selected, then the process is recursively applied to the sibling sets of each selected node. The algorithm continues until all sibling sets in all subtrees specified in the filter have been processed. If any sibling nodes of a node are instance identifier components for a conceptual data structure (e.g., list key leaf), then they_MUST_be included in the filter output. Regards, Benoit > I agree that MUST would be better. But I don't think we can/should do thar change in an errata. > > On 20 juni 2014 13:57:24 PDT, Randy Presuhn wrote: >> Hi - >> >>> From: Benoit Claise >>> Sent: Jun 20, 2014 2:01 AM >> ... >>> Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) >>> >>> One last check (till mid next week) for everybody in the WG before I >>> apply this change below to the errata, and accept it. >> "SHOULD" is no better than "MAY" or "OPTIONAL" from an >> interoperability perspective. "MUST" would be much simpler >> for all concerned. >> >> Randy >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > > /martin > . > --------------030604090600090606080104 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
Dear all,

Let me try to bring some closure on this errata http://www.rfc-editor.org/errata_search.php?eid=3980
Before proceeding (I want to check with the IESG if this is allowed to introduce a new MUST sentence in an errata), I would like to
1. check that text below is the final proposal
2. understand if there is agreement in the WG. Do someone object this change?
OLD:
   For each sibling set, the server determines which nodes are included
   (or potentially included) in the filter output, and which sibling
   subtrees are excluded (pruned) from the filter output.  The server
   first determines which types of nodes are present in the sibling set
   and processes the nodes according to the rules for their type.  If
   any nodes in the sibling set are selected, then the process is
   recursively applied to the sibling sets of each selected node.  The
   algorithm continues until all sibling sets in all subtrees specified
   in the filter have been processed.

NEW:
   For each sibling set, the server determines which nodes are included
   (or potentially included) in the filter output, and which sibling
   subtrees are excluded (pruned) from the filter output.  The server
   first determines which types of nodes are present in the sibling set
   and processes the nodes according to the rules for their type.  If
   any nodes in the sibling set are selected, then the process is
   recursively applied to the sibling sets of each selected node.  The
   algorithm continues until all sibling sets in all subtrees specified
   in the filter have been processed. If any sibling nodes of a node 
   are instance identifier components for a conceptual data structure 
   (e.g., list key leaf), then they MUST be included in the filter output.
Regards, Benoit

I agree that MUST would be better. But I don't think we can/should do thar change in an errata. 

On 20 juni 2014 13:57:24 PDT, Randy Presuhn <randy_presuhn@mindspring.com> wrote:

Hi -


From: Benoit Claise <bclaise@cisco.com>
Sent: Jun 20, 2014 2:01 AM

...

Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980)

One last check (till mid next week) for everybody in the WG before I 
apply this change below to the errata, and accept it.

"SHOULD" is no better than "MAY" or "OPTIONAL" from an
interoperability perspective.  "MUST" would be much simpler
for all concerned.

Randy

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


/martin
.

--------------030604090600090606080104-- From nobody Mon Jul 14 17:58:31 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC971B27DA; Mon, 14 Jul 2014 17:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, USER_IN_WHITELIST=-100] autolearn=ham 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 hPre9yK9YyBI; Mon, 14 Jul 2014 17:58:25 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id D040B1B27EC; Mon, 14 Jul 2014 17:58:24 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 617E51246771; Tue, 15 Jul 2014 08:58:16 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 314687070C9; Tue, 15 Jul 2014 08:58:16 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s6F0wDWb093760; Tue, 15 Jul 2014 08:58:13 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) In-Reply-To: <53C3CF38.2070601@cisco.com> References: <30336078.1403297845090.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> <53C3CF38.2070601@cisco.com> To: Benoit Claise MIME-Version: 1.0 X-KeepSent: 31241F0D:E0F8C72E-48257D16:00054663; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Tue, 15 Jul 2014 08:58:14 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2014-07-15 08:58:12, Serialize complete at 2014-07-15 08:58:12 Content-Type: multipart/alternative; boundary="=_alternative 000554BD48257D16_=" X-MAIL: mse02.zte.com.cn s6F0wDWb093760 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/dREG-rEeGKMUnMh1XFyt230Kovs Cc: "rob.enns@gmail.com" , Randy Presuhn , "joelja@bogus.com" , Netconf , "netconf@ietf.org" Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 00:58:28 -0000 This is a multipart message in MIME format. --=_alternative 000554BD48257D16_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSBpbnN0YW5jZSBpZGVudGlmaWVyIE1VU1QgYmUgcHJlc2VudCBpbiBvdXRwdXQuDQov ZnJhbmsNCg0KDQoiTmV0Y29uZiIgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz4g5YaZ5LqOIDIw MTQtMDctMTQgMjA6Mzg6MTY6DQoNCj4gQmVub2l0IENsYWlzZSA8YmNsYWlzZUBjaXNjby5jb20+ IA0KPiDlj5Hku7bkuro6ICAiTmV0Y29uZiIgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz4NCj4g DQo+IDIwMTQtMDctMTQgMjA6MzgNCj4gDQo+IOaUtuS7tuS6ug0KPiANCj4gTWFydGluIEJqw7Zy a2x1bmQgPG1iakB0YWlsLWYuY29tPiwgUmFuZHkgUHJlc3VobiANCj4gPHJhbmR5X3ByZXN1aG5A bWluZHNwcmluZy5jb20+LCAiS2xlbWVudCBTZWtlcmEgLVggKGtzZWtlcmEgLSANCj4gUGFudGhl b24gVGVjaG5vbG9naWVzIFNSTyBhdCBDaXNjbykiIDxrc2VrZXJhQGNpc2NvLmNvbT4sIA0KPiAN Cj4g5oqE6YCBDQo+IA0KPiAicm9iLmVubnNAZ21haWwuY29tIiA8cm9iLmVubnNAZ21haWwuY29t PiwgImpvZWxqYUBib2d1cy5jb20iIA0KPiA8am9lbGphQGJvZ3VzLmNvbT4sICJuZXRjb25mQGll dGYub3JnIiA8bmV0Y29uZkBpZXRmLm9yZz4NCj4gDQo+IOS4u+mimA0KPiANCj4gUmU6IFtOZXRj b25mXSBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0gUkZDNjI0MSAoMzk4MCkNCj4gDQo+IERl YXIgYWxsLA0KPiANCj4gTGV0IG1lIHRyeSB0byBicmluZyBzb21lIGNsb3N1cmUgb24gdGhpcyBl cnJhdGEgaHR0cDovL3d3dy5yZmMtDQo+IGVkaXRvci5vcmcvZXJyYXRhX3NlYXJjaC5waHA/ZWlk PTM5ODANCj4gQmVmb3JlIHByb2NlZWRpbmcgKEkgd2FudCB0byBjaGVjayB3aXRoIHRoZSBJRVNH IGlmIHRoaXMgaXMgYWxsb3dlZCANCj4gdG8gaW50cm9kdWNlIGEgbmV3IE1VU1Qgc2VudGVuY2Ug aW4gYW4gZXJyYXRhKSwgSSB3b3VsZCBsaWtlIHRvDQo+IDEuIGNoZWNrIHRoYXQgdGV4dCBiZWxv dyBpcyB0aGUgZmluYWwgcHJvcG9zYWwNCj4gMi4gdW5kZXJzdGFuZCBpZiB0aGVyZSBpcyBhZ3Jl ZW1lbnQgaW4gdGhlIFdHLiBEbyBzb21lb25lIG9iamVjdCB0aGlzIA0KY2hhbmdlPw0KPiBPTEQ6 DQo+ICAgIEZvciBlYWNoIHNpYmxpbmcgc2V0LCB0aGUgc2VydmVyIGRldGVybWluZXMgd2hpY2gg bm9kZXMgYXJlIGluY2x1ZGVkDQo+ICAgIChvciBwb3RlbnRpYWxseSBpbmNsdWRlZCkgaW4gdGhl IGZpbHRlciBvdXRwdXQsIGFuZCB3aGljaCBzaWJsaW5nDQo+ICAgIHN1YnRyZWVzIGFyZSBleGNs dWRlZCAocHJ1bmVkKSBmcm9tIHRoZSBmaWx0ZXIgb3V0cHV0LiAgVGhlIHNlcnZlcg0KPiAgICBm aXJzdCBkZXRlcm1pbmVzIHdoaWNoIHR5cGVzIG9mIG5vZGVzIGFyZSBwcmVzZW50IGluIHRoZSBz aWJsaW5nIHNldA0KPiAgICBhbmQgcHJvY2Vzc2VzIHRoZSBub2RlcyBhY2NvcmRpbmcgdG8gdGhl IHJ1bGVzIGZvciB0aGVpciB0eXBlLiAgSWYNCj4gICAgYW55IG5vZGVzIGluIHRoZSBzaWJsaW5n IHNldCBhcmUgc2VsZWN0ZWQsIHRoZW4gdGhlIHByb2Nlc3MgaXMNCj4gICAgcmVjdXJzaXZlbHkg YXBwbGllZCB0byB0aGUgc2libGluZyBzZXRzIG9mIGVhY2ggc2VsZWN0ZWQgbm9kZS4gIFRoZQ0K PiAgICBhbGdvcml0aG0gY29udGludWVzIHVudGlsIGFsbCBzaWJsaW5nIHNldHMgaW4gYWxsIHN1 YnRyZWVzIHNwZWNpZmllZA0KPiAgICBpbiB0aGUgZmlsdGVyIGhhdmUgYmVlbiBwcm9jZXNzZWQu DQo+IA0KPiBORVc6DQo+ICAgIEZvciBlYWNoIHNpYmxpbmcgc2V0LCB0aGUgc2VydmVyIGRldGVy bWluZXMgd2hpY2ggbm9kZXMgYXJlIGluY2x1ZGVkDQo+ICAgIChvciBwb3RlbnRpYWxseSBpbmNs dWRlZCkgaW4gdGhlIGZpbHRlciBvdXRwdXQsIGFuZCB3aGljaCBzaWJsaW5nDQo+ICAgIHN1YnRy ZWVzIGFyZSBleGNsdWRlZCAocHJ1bmVkKSBmcm9tIHRoZSBmaWx0ZXIgb3V0cHV0LiAgVGhlIHNl cnZlcg0KPiAgICBmaXJzdCBkZXRlcm1pbmVzIHdoaWNoIHR5cGVzIG9mIG5vZGVzIGFyZSBwcmVz ZW50IGluIHRoZSBzaWJsaW5nIHNldA0KPiAgICBhbmQgcHJvY2Vzc2VzIHRoZSBub2RlcyBhY2Nv cmRpbmcgdG8gdGhlIHJ1bGVzIGZvciB0aGVpciB0eXBlLiAgSWYNCj4gICAgYW55IG5vZGVzIGlu IHRoZSBzaWJsaW5nIHNldCBhcmUgc2VsZWN0ZWQsIHRoZW4gdGhlIHByb2Nlc3MgaXMNCj4gICAg cmVjdXJzaXZlbHkgYXBwbGllZCB0byB0aGUgc2libGluZyBzZXRzIG9mIGVhY2ggc2VsZWN0ZWQg bm9kZS4gIFRoZQ0KPiAgICBhbGdvcml0aG0gY29udGludWVzIHVudGlsIGFsbCBzaWJsaW5nIHNl dHMgaW4gYWxsIHN1YnRyZWVzIHNwZWNpZmllZA0KPiAgICBpbiB0aGUgZmlsdGVyIGhhdmUgYmVl biBwcm9jZXNzZWQuIElmIGFueSBzaWJsaW5nIG5vZGVzIG9mIGEgbm9kZSANCj4gICAgYXJlIGlu c3RhbmNlIGlkZW50aWZpZXIgY29tcG9uZW50cyBmb3IgYSBjb25jZXB0dWFsIGRhdGEgc3RydWN0 dXJlIA0KPiAgICAoZS5nLiwgbGlzdCBrZXkgbGVhZiksIHRoZW4gdGhleSBNVVNUIGJlIGluY2x1 ZGVkIGluIHRoZSBmaWx0ZXIgDQpvdXRwdXQuDQo+IFJlZ2FyZHMsIEJlbm9pdA0KDQo+IEkgYWdy ZWUgdGhhdCBNVVNUIHdvdWxkIGJlIGJldHRlci4gQnV0IEkgZG9uJ3QgdGhpbmsgd2UgY2FuL3No b3VsZCANCj4gZG8gdGhhciBjaGFuZ2UgaW4gYW4gZXJyYXRhLiANCj4gDQo+IE9uIDIwIGp1bmkg MjAxNCAxMzo1NzoyNCBQRFQsIFJhbmR5IFByZXN1aG4gDQo8cmFuZHlfcHJlc3VobkBtaW5kc3By aW5nLmNvbT4NCj4gd3JvdGU6DQoNCj4gSGkgLQ0KPiANCg0KPiBGcm9tOiBCZW5vaXQgQ2xhaXNl IDxiY2xhaXNlQGNpc2NvLmNvbT4NCj4gU2VudDogSnVuIDIwLCAyMDE0IDI6MDEgQU0NCg0KPiAu Li4NCg0KPiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVk XSBSRkM2MjQxICgzOTgwKQ0KPiANCj4gT25lIGxhc3QgY2hlY2sgKHRpbGwgbWlkIG5leHQgd2Vl aykgZm9yIGV2ZXJ5Ym9keSBpbiB0aGUgV0cgYmVmb3JlIEkgDQo+IGFwcGx5IHRoaXMgY2hhbmdl IGJlbG93IHRvIHRoZSBlcnJhdGEsIGFuZCBhY2NlcHQgaXQuDQoNCj4gDQo+ICJTSE9VTEQiIGlz IG5vIGJldHRlciB0aGFuICJNQVkiIG9yICJPUFRJT05BTCIgZnJvbSBhbg0KPiBpbnRlcm9wZXJh YmlsaXR5IHBlcnNwZWN0aXZlLiAgIk1VU1QiIHdvdWxkIGJlIG11Y2ggc2ltcGxlcg0KPiBmb3Ig YWxsIGNvbmNlcm5lZC4NCj4gDQo+IFJhbmR5DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiBOZXRj b25mQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 Y29uZg0KDQo+IA0KPiANCj4gL21hcnRpbg0KPiAuDQo+IA0KDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ IE5ldGNvbmZAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRjb25mDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0 dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVu ZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFy ZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9u LCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMg aW1tZWRpYXRlbHkuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21p dHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRl bmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBh cmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlv biwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZv cm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVz IGltbWVkaWF0ZWx5Lg0K --=_alternative 000554BD48257D16_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgYWdyZWUgaW5zdGFuY2UgaWRlbnRpZmll ciBNVVNUIGJlIHByZXNlbnQNCmluIG91dHB1dC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPi9mcmFuazwvZm9udD4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZxdW90O05ldGNvbmYmcXVvdDsgJmx0O25ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyZn dDsNCuWGmeS6jiAyMDE0LTA3LTE0IDIwOjM4OjE2Ojxicj4NCjxicj4NCiZndDsgQmVub2l0IENs YWlzZSAmbHQ7YmNsYWlzZUBjaXNjby5jb20mZ3Q7IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyDlj5Hku7bkuro6ICZuYnNwOyZxdW90O05ldGNvbmYmcXVvdDsgJmx0O25l dGNvbmYtYm91bmNlc0BpZXRmLm9yZyZndDs8YnI+DQomZ3Q7IDwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyAyMDE0LTA3LTE0IDIwOjM4PC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg5pS25Lu25Lq6PC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgTWFydGluIEJqw7Zya2x1bmQgJmx0O21i akB0YWlsLWYuY29tJmd0OywgUmFuZHkgUHJlc3VobiA8YnI+DQomZ3Q7ICZsdDtyYW5keV9wcmVz dWhuQG1pbmRzcHJpbmcuY29tJmd0OywgJnF1b3Q7S2xlbWVudCBTZWtlcmEgLVggKGtzZWtlcmEN Ci0gPGJyPg0KJmd0OyBQYW50aGVvbiBUZWNobm9sb2dpZXMgU1JPIGF0IENpc2NvKSZxdW90OyAm bHQ7a3Nla2VyYUBjaXNjby5jb20mZ3Q7LA0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7IDxicj4NCiZndDsg5oqE6YCBPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7IDxicj4NCiZndDsgJnF1b3Q7cm9iLmVubnNAZ21haWwuY29tJnF1b3Q7ICZsdDty b2IuZW5uc0BnbWFpbC5jb20mZ3Q7LCAmcXVvdDtqb2VsamFAYm9ndXMuY29tJnF1b3Q7DQo8YnI+ DQomZ3Q7ICZsdDtqb2VsamFAYm9ndXMuY29tJmd0OywgJnF1b3Q7bmV0Y29uZkBpZXRmLm9yZyZx dW90OyAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgPGJyPg0KJmd0OyDkuLvpopg8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBSZTogW05ldGNvbmZdIFtUZWNobmljYWwgRXJyYXRhIFJl cG9ydGVkXSBSRkM2MjQxICgzOTgwKTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jmd0OyA8YnI+DQomZ3Q7IERlYXIgYWxsLDxicj4NCiZndDsgPGJyPg0KJmd0OyBMZXQgbWUgdHJ5 IHRvIGJyaW5nIHNvbWUgY2xvc3VyZSBvbiB0aGlzIGVycmF0YSA8L2ZvbnQ+PC90dD48YSBocmVm PSJodHRwOi8vd3d3LnJmYy0vIj48dHQ+PGZvbnQgc2l6ZT0yPmh0dHA6Ly93d3cucmZjLTwvZm9u dD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgZWRpdG9yLm9yZy9lcnJhdGFf c2VhcmNoLnBocD9laWQ9Mzk4MDxicj4NCiZndDsgQmVmb3JlIHByb2NlZWRpbmcgKEkgd2FudCB0 byBjaGVjayB3aXRoIHRoZSBJRVNHIGlmIHRoaXMgaXMgYWxsb3dlZA0KPGJyPg0KJmd0OyB0byBp bnRyb2R1Y2UgYSBuZXcgTVVTVCBzZW50ZW5jZSBpbiBhbiBlcnJhdGEpLCBJIHdvdWxkIGxpa2Ug dG88YnI+DQomZ3Q7IDEuIGNoZWNrIHRoYXQgdGV4dCBiZWxvdyBpcyB0aGUgZmluYWwgcHJvcG9z YWw8YnI+DQomZ3Q7IDIuIHVuZGVyc3RhbmQgaWYgdGhlcmUgaXMgYWdyZWVtZW50IGluIHRoZSBX Ry4gRG8gc29tZW9uZSBvYmplY3QgdGhpcw0KY2hhbmdlPzwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyBPTEQ6PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7Rm9yIGVhY2ggc2li bGluZyBzZXQsIHRoZSBzZXJ2ZXIgZGV0ZXJtaW5lcyB3aGljaCBub2Rlcw0KYXJlIGluY2x1ZGVk PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7KG9yIHBvdGVudGlhbGx5IGluY2x1ZGVkKSBpbiB0aGUg ZmlsdGVyIG91dHB1dCwgYW5kIHdoaWNoDQpzaWJsaW5nPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 c3VidHJlZXMgYXJlIGV4Y2x1ZGVkIChwcnVuZWQpIGZyb20gdGhlIGZpbHRlciBvdXRwdXQuDQom bmJzcDtUaGUgc2VydmVyPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7Zmlyc3QgZGV0ZXJtaW5lcyB3 aGljaCB0eXBlcyBvZiBub2RlcyBhcmUgcHJlc2VudCBpbg0KdGhlIHNpYmxpbmcgc2V0PGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7YW5kIHByb2Nlc3NlcyB0aGUgbm9kZXMgYWNjb3JkaW5nIHRvIHRo ZSBydWxlcyBmb3IgdGhlaXINCnR5cGUuICZuYnNwO0lmPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 YW55IG5vZGVzIGluIHRoZSBzaWJsaW5nIHNldCBhcmUgc2VsZWN0ZWQsIHRoZW4gdGhlIHByb2Nl c3MNCmlzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7cmVjdXJzaXZlbHkgYXBwbGllZCB0byB0aGUg c2libGluZyBzZXRzIG9mIGVhY2ggc2VsZWN0ZWQNCm5vZGUuICZuYnNwO1RoZTxicj4NCiZndDsg Jm5ic3A7ICZuYnNwO2FsZ29yaXRobSBjb250aW51ZXMgdW50aWwgYWxsIHNpYmxpbmcgc2V0cyBp biBhbGwgc3VidHJlZXMNCnNwZWNpZmllZDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2luIHRoZSBm aWx0ZXIgaGF2ZSBiZWVuIHByb2Nlc3NlZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgTkVXOjxicj4N CiZndDsgJm5ic3A7ICZuYnNwO0ZvciBlYWNoIHNpYmxpbmcgc2V0LCB0aGUgc2VydmVyIGRldGVy bWluZXMgd2hpY2ggbm9kZXMNCmFyZSBpbmNsdWRlZDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyhv ciBwb3RlbnRpYWxseSBpbmNsdWRlZCkgaW4gdGhlIGZpbHRlciBvdXRwdXQsIGFuZCB3aGljaA0K c2libGluZzxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3N1YnRyZWVzIGFyZSBleGNsdWRlZCAocHJ1 bmVkKSBmcm9tIHRoZSBmaWx0ZXIgb3V0cHV0Lg0KJm5ic3A7VGhlIHNlcnZlcjxicj4NCiZndDsg Jm5ic3A7ICZuYnNwO2ZpcnN0IGRldGVybWluZXMgd2hpY2ggdHlwZXMgb2Ygbm9kZXMgYXJlIHBy ZXNlbnQgaW4NCnRoZSBzaWJsaW5nIHNldDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2FuZCBwcm9j ZXNzZXMgdGhlIG5vZGVzIGFjY29yZGluZyB0byB0aGUgcnVsZXMgZm9yIHRoZWlyDQp0eXBlLiAm bmJzcDtJZjxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2FueSBub2RlcyBpbiB0aGUgc2libGluZyBz ZXQgYXJlIHNlbGVjdGVkLCB0aGVuIHRoZSBwcm9jZXNzDQppczxicj4NCiZndDsgJm5ic3A7ICZu YnNwO3JlY3Vyc2l2ZWx5IGFwcGxpZWQgdG8gdGhlIHNpYmxpbmcgc2V0cyBvZiBlYWNoIHNlbGVj dGVkDQpub2RlLiAmbmJzcDtUaGU8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDthbGdvcml0aG0gY29u dGludWVzIHVudGlsIGFsbCBzaWJsaW5nIHNldHMgaW4gYWxsIHN1YnRyZWVzDQpzcGVjaWZpZWQ8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtpbiB0aGUgZmlsdGVyIGhhdmUgYmVlbiBwcm9jZXNzZWQu IElmIGFueSBzaWJsaW5nIG5vZGVzDQpvZiBhIG5vZGUgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 YXJlIGluc3RhbmNlIGlkZW50aWZpZXIgY29tcG9uZW50cyBmb3IgYSBjb25jZXB0dWFsIGRhdGEN CnN0cnVjdHVyZSA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsoZS5nLiwgbGlzdCBrZXkgbGVhZiks IHRoZW4gdGhleSBNVVNUIGJlIGluY2x1ZGVkIGluDQp0aGUgZmlsdGVyIG91dHB1dC48L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgUmVnYXJkcywgQmVub2l0PGJyPg0KPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEkgYWdyZWUgdGhhdCBNVVNUIHdv dWxkIGJlIGJldHRlci4gQnV0IEkgZG9uJ3QNCnRoaW5rIHdlIGNhbi9zaG91bGQgPGJyPg0KJmd0 OyBkbyB0aGFyIGNoYW5nZSBpbiBhbiBlcnJhdGEuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiAy MCBqdW5pIDIwMTQgMTM6NTc6MjQgUERULCBSYW5keSBQcmVzdWhuICZsdDtyYW5keV9wcmVzdWhu QG1pbmRzcHJpbmcuY29tJmd0Ozxicj4NCiZndDsgd3JvdGU6PGJyPg0KPC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEhpIC08YnI+DQomZ3Q7IDxicj4NCjwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBGcm9tOiBCZW5vaXQgQ2xhaXNlICZsdDtiY2xh aXNlQGNpc2NvLmNvbSZndDs8YnI+DQomZ3Q7IFNlbnQ6IEp1biAyMCwgMjAxNCAyOjAxIEFNPGJy Pg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IC4uLjxicj4NCjwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBTdWJqZWN0OiBSZTogW05ldGNvbmZd IFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXQ0KUkZDNjI0MSAoMzk4MCk8YnI+DQomZ3Q7IDxi cj4NCiZndDsgT25lIGxhc3QgY2hlY2sgKHRpbGwgbWlkIG5leHQgd2VlaykgZm9yIGV2ZXJ5Ym9k eSBpbiB0aGUgV0cgYmVmb3JlDQpJIDxicj4NCiZndDsgYXBwbHkgdGhpcyBjaGFuZ2UgYmVsb3cg dG8gdGhlIGVycmF0YSwgYW5kIGFjY2VwdCBpdC48YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAmcXVvdDtTSE9VTEQmcXVvdDsgaXMgbm8gYmV0 dGVyIHRoYW4gJnF1b3Q7TUFZJnF1b3Q7IG9yICZxdW90O09QVElPTkFMJnF1b3Q7DQpmcm9tIGFu PGJyPg0KJmd0OyBpbnRlcm9wZXJhYmlsaXR5IHBlcnNwZWN0aXZlLiAmbmJzcDsmcXVvdDtNVVNU JnF1b3Q7IHdvdWxkIGJlIG11Y2gNCnNpbXBsZXI8YnI+DQomZ3Q7IGZvciBhbGwgY29uY2VybmVk Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBSYW5keTxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgTmV0Y29u ZiBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IE5ldGNvbmZAaWV0Zi5vcmc8YnI+DQomZ3Q7IDwvZm9u dD48L3R0PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRj b25mPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRjb25mPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAvbWFy dGluPGJyPg0KJmd0OyAuPGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7IE5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBOZXRjb25mQGll dGYub3JnPGJyPg0KJmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0Y29uZj48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQg c2l6ZT0yPjxicj4NCjwvZm9udD48L3R0Pg0KDQo8YnI+PHByZT48Zm9udCBjb2xvcj0iYmx1ZSI+ DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0 aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhl IGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGlu dGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0 aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg bWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5 Lg0KDQo8L2ZvbnQ+PC9wcmU+PGJyPg0KDQo8YnI+PHByZT48Zm9udCBjb2xvcj0iYmx1ZSI+DQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K WlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkg aXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4 Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVu ZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9u IG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFp bCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0K DQo8L2ZvbnQ+PC9wcmU+PGJyPg0K --=_alternative 000554BD48257D16_=-- From nobody Tue Jul 15 04:42:14 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C7A1B287B; Tue, 15 Jul 2014 04:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 R5rhmmSCQa4l; Tue, 15 Jul 2014 04:42:10 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E66C11B286F; Tue, 15 Jul 2014 04:42:08 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D9C3774D; Tue, 15 Jul 2014 13:42:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 3aUvbSaWgKPq; Tue, 15 Jul 2014 13:41:58 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 15 Jul 2014 13:42:05 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C41AA20017; Tue, 15 Jul 2014 13:42:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HhaMeSQBTy6Q; Tue, 15 Jul 2014 13:42:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9ED0E2002F; Tue, 15 Jul 2014 13:42:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7175C2DD8357; Tue, 15 Jul 2014 13:42:01 +0200 (CEST) Date: Tue, 15 Jul 2014 13:42:00 +0200 From: Juergen Schoenwaelder To: feng.chong33@zte.com.cn Message-ID: <20140715114200.GA398@elstar.local> Mail-Followup-To: feng.chong33@zte.com.cn, Benoit Claise , "rob.enns@gmail.com" , Randy Presuhn , "joelja@bogus.com" , Netconf , "netconf@ietf.org" References: <30336078.1403297845090.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> <53C3CF38.2070601@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/C81vspLU2w3rMKTD7c_HGSsBHdM Cc: "rob.enns@gmail.com" , "joelja@bogus.com" , Randy Presuhn , Netconf , "netconf@ietf.org" Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 11:42:12 -0000 But since the original spec did not say clearly such leafs must be included, I think the only safe bet for a client is to explicitely request key leafs in the filter - unless we are sure the _every_ implementation actually returns key leafs (and since nobody knows the number of implementations around, establishing this fact is hard). /js On Tue, Jul 15, 2014 at 08:58:14AM +0800, feng.chong33@zte.com.cn wrote: > I agree instance identifier MUST be present in output. > /frank > > > "Netconf" 写于 2014-07-14 20:38:16: > > > Benoit Claise > > å‘件人: "Netconf" > > > > 2014-07-14 20:38 > > > > 收件人 > > > > Martin Björklund , Randy Presuhn > > , "Klement Sekera -X (ksekera - > > Pantheon Technologies SRO at Cisco)" , > > > > æŠ„é€ > > > > "rob.enns@gmail.com" , "joelja@bogus.com" > > , "netconf@ietf.org" > > > > 主题 > > > > Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) > > > > Dear all, > > > > Let me try to bring some closure on this errata http://www.rfc- > > editor.org/errata_search.php?eid=3980 > > Before proceeding (I want to check with the IESG if this is allowed > > to introduce a new MUST sentence in an errata), I would like to > > 1. check that text below is the final proposal > > 2. understand if there is agreement in the WG. Do someone object this > change? > > OLD: > > For each sibling set, the server determines which nodes are included > > (or potentially included) in the filter output, and which sibling > > subtrees are excluded (pruned) from the filter output. The server > > first determines which types of nodes are present in the sibling set > > and processes the nodes according to the rules for their type. If > > any nodes in the sibling set are selected, then the process is > > recursively applied to the sibling sets of each selected node. The > > algorithm continues until all sibling sets in all subtrees specified > > in the filter have been processed. > > > > NEW: > > For each sibling set, the server determines which nodes are included > > (or potentially included) in the filter output, and which sibling > > subtrees are excluded (pruned) from the filter output. The server > > first determines which types of nodes are present in the sibling set > > and processes the nodes according to the rules for their type. If > > any nodes in the sibling set are selected, then the process is > > recursively applied to the sibling sets of each selected node. The > > algorithm continues until all sibling sets in all subtrees specified > > in the filter have been processed. If any sibling nodes of a node > > are instance identifier components for a conceptual data structure > > (e.g., list key leaf), then they MUST be included in the filter > output. > > Regards, Benoit > > > I agree that MUST would be better. But I don't think we can/should > > do thar change in an errata. > > > > On 20 juni 2014 13:57:24 PDT, Randy Presuhn > > > wrote: > > > Hi - > > > > > From: Benoit Claise > > Sent: Jun 20, 2014 2:01 AM > > > ... > > > Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) > > > > One last check (till mid next week) for everybody in the WG before I > > apply this change below to the errata, and accept it. > > > > > "SHOULD" is no better than "MAY" or "OPTIONAL" from an > > interoperability perspective. "MUST" would be much simpler > > for all concerned. > > > > Randy > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > /martin > > . > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Jul 15 05:41:51 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443F71B2883; Tue, 15 Jul 2014 05:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 Vs2926Z8NGIl; Tue, 15 Jul 2014 05:41:46 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3001B283A; Tue, 15 Jul 2014 05:41:46 -0700 (PDT) Received: from host-90-236-67-119.mobileonline.telia.com (host-90-236-67-119.mobileonline.telia.com [90.236.67.119]) by mail.tail-f.com (Postfix) with ESMTPSA id 5576D128046E; Tue, 15 Jul 2014 14:37:44 +0200 (CEST) User-Agent: K-9 Mail for Android In-Reply-To: <20140715114200.GA398@elstar.local> References: <30336078.1403297845090.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> <53C3CF38.2070601@cisco.com> <20140715114200.GA398@elstar.local> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: =?ISO-8859-1?Q?Martin_Bj=F6rklund?= Date: Tue, 15 Jul 2014 14:39:39 +0200 To: Juergen Schoenwaelder , feng.chong33@zte.com.cn Message-ID: <5f76f622-d93a-41e7-8115-2c4e11c2a245@email.android.com> Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/vN4ToCo4jTe5ELaFGiO6ZI8_C0A Cc: "rob.enns@gmail.com" , "joelja@bogus.com" , Randy Presuhn , "netconf@ietf.org" , Netconf Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 12:41:49 -0000 I agree with Juergen. Thus, I think the new text should use MAY instead of MUST. On 15 juli 2014 13:42:00 CEST, Juergen Schoenwaelder wrote: >But since the original spec did not say clearly such leafs must be >included, I think the only safe bet for a client is to explicitely >request key leafs in the filter - unless we are sure the _every_ >implementation actually returns key leafs (and since nobody knows the >number of implementations around, establishing this fact is hard). > >/js > >On Tue, Jul 15, 2014 at 08:58:14AM +0800, feng.chong33@zte.com.cn >wrote: >> I agree instance identifier MUST be present in output. >> /frank >> >> >> "Netconf" 写于 2014-07-14 20:38:16: >> >> > Benoit Claise >> > å‘件人: "Netconf" >> > >> > 2014-07-14 20:38 >> > >> > 收件人 >> > >> > Martin Björklund , Randy Presuhn >> > , "Klement Sekera -X (ksekera - >> > Pantheon Technologies SRO at Cisco)" , >> > >> > æŠ„é€ >> > >> > "rob.enns@gmail.com" , "joelja@bogus.com" >> > , "netconf@ietf.org" >> > >> > 主题 >> > >> > Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) >> > >> > Dear all, >> > >> > Let me try to bring some closure on this errata http://www.rfc- >> > editor.org/errata_search.php?eid=3980 >> > Before proceeding (I want to check with the IESG if this is allowed > >> > to introduce a new MUST sentence in an errata), I would like to >> > 1. check that text below is the final proposal >> > 2. understand if there is agreement in the WG. Do someone object >this >> change? >> > OLD: >> > For each sibling set, the server determines which nodes are >included >> > (or potentially included) in the filter output, and which >sibling >> > subtrees are excluded (pruned) from the filter output. The >server >> > first determines which types of nodes are present in the sibling >set >> > and processes the nodes according to the rules for their type. >If >> > any nodes in the sibling set are selected, then the process is >> > recursively applied to the sibling sets of each selected node. >The >> > algorithm continues until all sibling sets in all subtrees >specified >> > in the filter have been processed. >> > >> > NEW: >> > For each sibling set, the server determines which nodes are >included >> > (or potentially included) in the filter output, and which >sibling >> > subtrees are excluded (pruned) from the filter output. The >server >> > first determines which types of nodes are present in the sibling >set >> > and processes the nodes according to the rules for their type. >If >> > any nodes in the sibling set are selected, then the process is >> > recursively applied to the sibling sets of each selected node. >The >> > algorithm continues until all sibling sets in all subtrees >specified >> > in the filter have been processed. If any sibling nodes of a >node >> > are instance identifier components for a conceptual data >structure >> > (e.g., list key leaf), then they MUST be included in the filter >> output. >> > Regards, Benoit >> >> > I agree that MUST would be better. But I don't think we can/should >> > do thar change in an errata. >> > >> > On 20 juni 2014 13:57:24 PDT, Randy Presuhn >> >> > wrote: >> >> > Hi - >> > >> >> > From: Benoit Claise >> > Sent: Jun 20, 2014 2:01 AM >> >> > ... >> >> > Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) >> > >> > One last check (till mid next week) for everybody in the WG before >I >> > apply this change below to the errata, and accept it. >> >> > >> > "SHOULD" is no better than "MAY" or "OPTIONAL" from an >> > interoperability perspective. "MUST" would be much simpler >> > for all concerned. >> > >> > Randy >> > >> > _______________________________________________ >> > Netconf mailing list >> > Netconf@ietf.org >> > https://www.ietf.org/mailman/listinfo/netconf >> >> > >> > >> > /martin >> > . >> > >> >> > _______________________________________________ >> > Netconf mailing list >> > Netconf@ietf.org >> > https://www.ietf.org/mailman/listinfo/netconf >> >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this >mail (and any attachment transmitted herewith) is privileged and >confidential and is intended for the exclusive use of the addressee(s). >If you are not an intended recipient, any disclosure, reproduction, >distribution or other dissemination or use of the information contained >is strictly prohibited. If you have received this mail in error, >please delete it and notify us immediately. >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this >mail (and any attachment transmitted herewith) is privileged and >confidential and is intended for the exclusive use of the addressee(s). >If you are not an intended recipient, any disclosure, reproduction, >distribution or other dissemination or use of the information contained >is strictly prohibited. If you have received this mail in error, >please delete it and notify us immediately. > >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > > >-- >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf /martin From nobody Tue Jul 15 05:47:58 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0A21B2888; Tue, 15 Jul 2014 05:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] autolearn=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 ldjesbgBDKQu; Tue, 15 Jul 2014 05:47:54 -0700 (PDT) Received: from koko.ripe.net (koko.ripe.net [IPv6:2001:67c:2e8:11::c100:1348]) (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 4EC011B2886; Tue, 15 Jul 2014 05:47:54 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1X7293-0005Yp-3E; Tue, 15 Jul 2014 14:47:47 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest9.guestnet.ripe.net) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1X7292-00006x-Ua; Tue, 15 Jul 2014 14:47:45 +0200 Message-ID: <53C522F0.1030107@bwijnen.net> Date: Tue, 15 Jul 2014 14:47:44 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= , Juergen Schoenwaelder , feng.chong33@zte.com.cn References: <30336078.1403297845090.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> <53C3CF38.2070601@cisco.com> <20140715114200.GA398@elstar.local> <5f76f622-d93a-41e7-8115-2c4e11c2a245@email.android.com> In-Reply-To: <5f76f622-d93a-41e7-8115-2c4e11c2a245@email.android.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd413e8f560ad23be0581e2768a313e0b72 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ITyI9ZBUia56akuYQ7tykNZDBBk Cc: "rob.enns@gmail.com" , "joelja@bogus.com" , Randy Presuhn , "netconf@ietf.org" , Netconf Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 12:47:57 -0000 Or.... maybe use MAY and add that if the client wants to be sure that such leafs are returned, then the client better asks for those leaf explicitly in the filter. Bert On 15/07/14 14:39, Martin Björklund wrote: > I agree with Juergen. Thus, I think the new text should use MAY instead of MUST. > > On 15 juli 2014 13:42:00 CEST, Juergen Schoenwaelder wrote: >> But since the original spec did not say clearly such leafs must be >> included, I think the only safe bet for a client is to explicitely >> request key leafs in the filter - unless we are sure the _every_ >> implementation actually returns key leafs (and since nobody knows the >> number of implementations around, establishing this fact is hard). >> >> /js >> >> On Tue, Jul 15, 2014 at 08:58:14AM +0800, feng.chong33@zte.com.cn >> wrote: >>> I agree instance identifier MUST be present in output. >>> /frank >>> >>> >>> "Netconf" 写于 2014-07-14 20:38:16: >>> >>>> Benoit Claise >>>> å‘件人: "Netconf" >>>> >>>> 2014-07-14 20:38 >>>> >>>> 收件人 >>>> >>>> Martin Björklund , Randy Presuhn >>>> , "Klement Sekera -X (ksekera - >>>> Pantheon Technologies SRO at Cisco)" , >>>> >>>> æŠ„é€ >>>> >>>> "rob.enns@gmail.com" , "joelja@bogus.com" >>>> , "netconf@ietf.org" >>>> >>>> 主题 >>>> >>>> Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) >>>> >>>> Dear all, >>>> >>>> Let me try to bring some closure on this errata http://www.rfc- >>>> editor.org/errata_search.php?eid=3980 >>>> Before proceeding (I want to check with the IESG if this is allowed >> >>>> to introduce a new MUST sentence in an errata), I would like to >>>> 1. check that text below is the final proposal >>>> 2. understand if there is agreement in the WG. Do someone object >> this >>> change? >>>> OLD: >>>> For each sibling set, the server determines which nodes are >> included >>>> (or potentially included) in the filter output, and which >> sibling >>>> subtrees are excluded (pruned) from the filter output. The >> server >>>> first determines which types of nodes are present in the sibling >> set >>>> and processes the nodes according to the rules for their type. >> If >>>> any nodes in the sibling set are selected, then the process is >>>> recursively applied to the sibling sets of each selected node. >> The >>>> algorithm continues until all sibling sets in all subtrees >> specified >>>> in the filter have been processed. >>>> >>>> NEW: >>>> For each sibling set, the server determines which nodes are >> included >>>> (or potentially included) in the filter output, and which >> sibling >>>> subtrees are excluded (pruned) from the filter output. The >> server >>>> first determines which types of nodes are present in the sibling >> set >>>> and processes the nodes according to the rules for their type. >> If >>>> any nodes in the sibling set are selected, then the process is >>>> recursively applied to the sibling sets of each selected node. >> The >>>> algorithm continues until all sibling sets in all subtrees >> specified >>>> in the filter have been processed. If any sibling nodes of a >> node >>>> are instance identifier components for a conceptual data >> structure >>>> (e.g., list key leaf), then they MUST be included in the filter >>> output. >>>> Regards, Benoit >>> >>>> I agree that MUST would be better. But I don't think we can/should >>>> do thar change in an errata. >>>> >>>> On 20 juni 2014 13:57:24 PDT, Randy Presuhn >>> >>>> wrote: >>> >>>> Hi - >>>> >>> >>>> From: Benoit Claise >>>> Sent: Jun 20, 2014 2:01 AM >>> >>>> ... >>> >>>> Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) >>>> >>>> One last check (till mid next week) for everybody in the WG before >> I >>>> apply this change below to the errata, and accept it. >>> >>>> >>>> "SHOULD" is no better than "MAY" or "OPTIONAL" from an >>>> interoperability perspective. "MUST" would be much simpler >>>> for all concerned. >>>> >>>> Randy >>>> >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >>> >>>> >>>> >>>> /martin >>>> . >>>> >>> >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >>> >>> -------------------------------------------------------- >>> ZTE Information Security Notice: The information contained in this >> mail (and any attachment transmitted herewith) is privileged and >> confidential and is intended for the exclusive use of the addressee(s). >> If you are not an intended recipient, any disclosure, reproduction, >> distribution or other dissemination or use of the information contained >> is strictly prohibited. If you have received this mail in error, >> please delete it and notify us immediately. >>> -------------------------------------------------------- >>> ZTE Information Security Notice: The information contained in this >> mail (and any attachment transmitted herewith) is privileged and >> confidential and is intended for the exclusive use of the addressee(s). >> If you are not an intended recipient, any disclosure, reproduction, >> distribution or other dissemination or use of the information contained >> is strictly prohibited. If you have received this mail in error, >> please delete it and notify us immediately. >> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >> >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > > > /martin > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Tue Jul 15 06:51:29 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2051A0089 for ; Tue, 15 Jul 2014 06:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 bbQfAc-qSaiB for ; Tue, 15 Jul 2014 06:51:24 -0700 (PDT) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C5AC1A03CE for ; Tue, 15 Jul 2014 06:51:23 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id i50so2034861qgf.35 for ; Tue, 15 Jul 2014 06:51:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hIOZgHAmr4yykHKBaqRYsN2e+/Kh/82nTMUxFFa/fUo=; b=EnRaYNmnlP2Rlx90US/SSIBMdjC5m1ljRuhX0CYnaSa9gDMjavgKgssGAQ4yMaD5v1 kBcBozgryBvQkQwt+xsImavWiEZ8Mxm6qIGVEDYi9qm+nsOJkWiwuNK2IugO7wyMXbGh 8hnkruieCC8ro4BEtIYWWoo2tph5p3nVTy+Cim51TbFknx7hVmDHms2TSXnLySEgJXSx rZthX7VJ1Jo3PfIV68tPucx8AkOo+fOu+sfDsidqvbrXHXw24SuOprnfVneTlkh08me2 /d5/UfIrcdYqT4OVLfNBbqQpGR4lFF1Tz2h8Rb+TyXgrT0QezL1ItrqnZ66Gwlt7AgI5 uUlA== X-Gm-Message-State: ALoCoQmEeG1/Prp31FPgOvXojTXAxXMPeJC3o1Yv8SR+HtN31wT5O+O3ay0+ElRDWqFeiJkNtn6x MIME-Version: 1.0 X-Received: by 10.140.103.74 with SMTP id x68mr33147188qge.34.1405432282090; Tue, 15 Jul 2014 06:51:22 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Tue, 15 Jul 2014 06:51:21 -0700 (PDT) In-Reply-To: <53C522F0.1030107@bwijnen.net> References: <30336078.1403297845090.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> <53C3CF38.2070601@cisco.com> <20140715114200.GA398@elstar.local> <5f76f622-d93a-41e7-8115-2c4e11c2a245@email.android.com> <53C522F0.1030107@bwijnen.net> Date: Tue, 15 Jul 2014 06:51:21 -0700 Message-ID: From: Andy Bierman To: "Bert Wijnen (IETF)" Content-Type: multipart/alternative; boundary=001a1134eda8ee277604fe3bb33a Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/bY5cBdekv8zpHBqBDCJw-ajM1BU Cc: "rob.enns@gmail.com" , "joelja@bogus.com" , Randy Presuhn , Netconf , "netconf@ietf.org" Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 13:51:26 -0000 --001a1134eda8ee277604fe3bb33a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 15, 2014 at 5:47 AM, Bert Wijnen (IETF) wrote: > Or.... maybe use MAY and add that if the client wants to be sure that > such leafs are returned, then the client better asks for those leaf > explicitly > in the filter. > So what is the point of this errata? The client already MAY include whatever nodes it wants in the filter. IMO the new text adds no value and clarifies nothing. > Bert > > Andy > > On 15/07/14 14:39, Martin Bj=C3=B6rklund wrote: > >> I agree with Juergen. Thus, I think the new text should use MAY instead >> of MUST. >> >> On 15 juli 2014 13:42:00 CEST, Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de> wrote: >> >>> But since the original spec did not say clearly such leafs must be >>> included, I think the only safe bet for a client is to explicitely >>> request key leafs in the filter - unless we are sure the _every_ >>> implementation actually returns key leafs (and since nobody knows the >>> number of implementations around, establishing this fact is hard). >>> >>> /js >>> >>> On Tue, Jul 15, 2014 at 08:58:14AM +0800, feng.chong33@zte.com.cn >>> wrote: >>> >>>> I agree instance identifier MUST be present in output. >>>> /frank >>>> >>>> >>>> "Netconf" =E5=86=99=E4=BA=8E 2014-07-14 20:= 38:16: >>>> >>>> Benoit Claise >>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: "Netconf" >>>>> >>>>> 2014-07-14 20:38 >>>>> >>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA >>>>> >>>>> Martin Bj=C3=B6rklund , Randy Presuhn >>>>> , "Klement Sekera -X (ksekera - >>>>> Pantheon Technologies SRO at Cisco)" , >>>>> >>>>> =E6=8A=84=E9=80=81 >>>>> >>>>> "rob.enns@gmail.com" , "joelja@bogus.com" >>>>> , "netconf@ietf.org" >>>>> >>>>> =E4=B8=BB=E9=A2=98 >>>>> >>>>> Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) >>>>> >>>>> Dear all, >>>>> >>>>> Let me try to bring some closure on this errata http://www.rfc- >>>>> editor.org/errata_search.php?eid=3D3980 >>>>> Before proceeding (I want to check with the IESG if this is allowed >>>>> >>>> >>> to introduce a new MUST sentence in an errata), I would like to >>>>> 1. check that text below is the final proposal >>>>> 2. understand if there is agreement in the WG. Do someone object >>>>> >>>> this >>> >>>> change? >>>> >>>>> OLD: >>>>> For each sibling set, the server determines which nodes are >>>>> >>>> included >>> >>>> (or potentially included) in the filter output, and which >>>>> >>>> sibling >>> >>>> subtrees are excluded (pruned) from the filter output. The >>>>> >>>> server >>> >>>> first determines which types of nodes are present in the sibling >>>>> >>>> set >>> >>>> and processes the nodes according to the rules for their type. >>>>> >>>> If >>> >>>> any nodes in the sibling set are selected, then the process is >>>>> recursively applied to the sibling sets of each selected node. >>>>> >>>> The >>> >>>> algorithm continues until all sibling sets in all subtrees >>>>> >>>> specified >>> >>>> in the filter have been processed. >>>>> >>>>> NEW: >>>>> For each sibling set, the server determines which nodes are >>>>> >>>> included >>> >>>> (or potentially included) in the filter output, and which >>>>> >>>> sibling >>> >>>> subtrees are excluded (pruned) from the filter output. The >>>>> >>>> server >>> >>>> first determines which types of nodes are present in the sibling >>>>> >>>> set >>> >>>> and processes the nodes according to the rules for their type. >>>>> >>>> If >>> >>>> any nodes in the sibling set are selected, then the process is >>>>> recursively applied to the sibling sets of each selected node. >>>>> >>>> The >>> >>>> algorithm continues until all sibling sets in all subtrees >>>>> >>>> specified >>> >>>> in the filter have been processed. If any sibling nodes of a >>>>> >>>> node >>> >>>> are instance identifier components for a conceptual data >>>>> >>>> structure >>> >>>> (e.g., list key leaf), then they MUST be included in the filter >>>>> >>>> output. >>>> >>>>> Regards, Benoit >>>>> >>>> >>>> I agree that MUST would be better. But I don't think we can/should >>>>> do thar change in an errata. >>>>> >>>>> On 20 juni 2014 13:57:24 PDT, Randy Presuhn >>>>> >>>> >>>> >>>>> wrote: >>>>> >>>> >>>> Hi - >>>>> >>>>> >>>> From: Benoit Claise >>>>> Sent: Jun 20, 2014 2:01 AM >>>>> >>>> >>>> ... >>>>> >>>> >>>> Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) >>>>> >>>>> One last check (till mid next week) for everybody in the WG before >>>>> >>>> I >>> >>>> apply this change below to the errata, and accept it. >>>>> >>>> >>>> >>>>> "SHOULD" is no better than "MAY" or "OPTIONAL" from an >>>>> interoperability perspective. "MUST" would be much simpler >>>>> for all concerned. >>>>> >>>>> Randy >>>>> >>>>> _______________________________________________ >>>>> Netconf mailing list >>>>> Netconf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netconf >>>>> >>>> >>>> >>>>> >>>>> /martin >>>>> . >>>>> >>>>> >>>> _______________________________________________ >>>>> Netconf mailing list >>>>> Netconf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netconf >>>>> >>>> >>>> -------------------------------------------------------- >>>> ZTE Information Security Notice: The information contained in this >>>> >>> mail (and any attachment transmitted herewith) is privileged and >>> confidential and is intended for the exclusive use of the addressee(s). >>> If you are not an intended recipient, any disclosure, reproduction, >>> distribution or other dissemination or use of the information contained >>> is strictly prohibited. If you have received this mail in error, >>> please delete it and notify us immediately. >>> >>>> -------------------------------------------------------- >>>> ZTE Information Security Notice: The information contained in this >>>> >>> mail (and any attachment transmitted herewith) is privileged and >>> confidential and is intended for the exclusive use of the addressee(s). >>> If you are not an intended recipient, any disclosure, reproduction, >>> distribution or other dissemination or use of the information contained >>> is strictly prohibited. If you have received this mail in error, >>> please delete it and notify us immediately. >>> >>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >>>> >>> >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>> Fax: +49 421 200 3103 >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> >> >> >> /martin >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a1134eda8ee277604fe3bb33a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Jul 15, 2014 at 5:47 AM, Bert Wijnen (IETF) <bertietf@b= wijnen.net> wrote:
Or.... maybe use MAY and add that if the cli= ent wants to be sure that
such leafs are returned, then the client better asks for those leaf explici= tly
in the filter.

So what is the point of = this errata? =C2=A0The client already MAY include whatever
nodes = it wants in the filter. IMO the new text adds no value and clarifies nothin= g.



Bert


Andy
=C2=A0

On 15/07/14 14:39, Martin Bj=C3=B6rklund wrote:
I agree with Juergen. Thus, I think the new text should use MAY instead of = MUST.

On 15 juli 2014 13:42:00 CEST, Juergen Schoenwaelder <j.schoenwaelder@jac= obs-university.de> wrote:
But since the original spec did not say clearly such leafs must be
included, I think the only safe bet for a client is to explicitely
request key leafs in the filter - unless we are sure the _every_
implementation actually returns key leafs (and since nobody knows the
number of implementations around, establishing this fact is hard).

/js

On Tue, Jul 15, 2014 at 08:58:14AM +0800, feng.chong33@zte.com.cn
wrote:
I agree instance identifier MUST be present in output.
/frank


"Netconf" <netconf-bounces@ietf.org> =E5=86=99=E4=BA=8E 2014-07-14 = 20:38:16:

Benoit Claise <bc= laise@cisco.com>
=E5=8F=91=E4=BB=B6=E4=BA=BA: =C2=A0"Netconf" <netconf-bounces@ietf.org&= gt;

2014-07-14 20:38

=E6=94=B6=E4=BB=B6=E4=BA=BA

Martin Bj=C3=B6rklund <mbj@tail-f.com>, Randy Presuhn
<randy= _presuhn@mindspring.com>, "Klement Sekera -X (ksekera -<= br> Pantheon Technologies SRO at Cisco)" <ksekera@cisco.com>,

=E6=8A=84=E9=80=81

"rob.enns@gmai= l.com" <rob.enns@gmail.com>, "joelja@bogus.com"
<joelja@bogus.com<= /a>>, "netcon= f@ietf.org" <netconf@ietf.org>

=E4=B8=BB=E9=A2=98

Re: [Netconf] [Technical Errata Reported] RFC6241 (3980)

Dear all,

Let me try to bring some closure on this errata http://www.rfc-
editor.org/errata_search.php?eid=3D3980
Before proceeding (I want to check with the IESG if this is allowed

to introduce a new MUST sentence in an errata), I would like to
1. check that text below is the final proposal
2. understand if there is agreement in the WG. Do someone object
this
change?
OLD:
=C2=A0 =C2=A0 For each sibling set, the server determines which nodes are
included
=C2=A0 =C2=A0 (or potentially included) in the filter output, and which
sibling
=C2=A0 =C2=A0 subtrees are excluded (pruned) from the filter output. =C2=A0= The
server
=C2=A0 =C2=A0 first determines which types of nodes are present in the sibl= ing
set
=C2=A0 =C2=A0 and processes the nodes according to the rules for their type= .
If
=C2=A0 =C2=A0 any nodes in the sibling set are selected, then the process i= s
=C2=A0 =C2=A0 recursively applied to the sibling sets of each selected node= .
The
=C2=A0 =C2=A0 algorithm continues until all sibling sets in all subtrees
specified
=C2=A0 =C2=A0 in the filter have been processed.

NEW:
=C2=A0 =C2=A0 For each sibling set, the server determines which nodes are
included
=C2=A0 =C2=A0 (or potentially included) in the filter output, and which
sibling
=C2=A0 =C2=A0 subtrees are excluded (pruned) from the filter output. =C2=A0= The
server
=C2=A0 =C2=A0 first determines which types of nodes are present in the sibl= ing
set
=C2=A0 =C2=A0 and processes the nodes according to the rules for their type= .
If
=C2=A0 =C2=A0 any nodes in the sibling set are selected, then the process i= s
=C2=A0 =C2=A0 recursively applied to the sibling sets of each selected node= .
The
=C2=A0 =C2=A0 algorithm continues until all sibling sets in all subtrees
specified
=C2=A0 =C2=A0 in the filter have been processed. If any sibling nodes of a<= br>
node
=C2=A0 =C2=A0 are instance identifier components for a conceptual data
structure
=C2=A0 =C2=A0 (e.g., list key leaf), then they MUST be included in the filt= er
output.
Regards, Benoit

I agree that MUST would be better. But I don't think we can/should
do thar change in an errata.

On 20 juni 2014 13:57:24 PDT, Randy Presuhn
<randy= _presuhn@mindspring.com>
wrote:

Hi -


From: Benoit Claise <bclaise@cisco.com>
Sent: Jun 20, 2014 2:01 AM

...

Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980)

One last check (till mid next week) for everybody in the WG before
I
apply this change below to the errata, and accept it.


"SHOULD" is no better than "MAY" or "OPTIONAL"= ; from an
interoperability perspective. =C2=A0"MUST" would be much simpler<= br> for all concerned.

Randy

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



/martin
.


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

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this
mail (and any attachment transmitted herewith) is privileged and
confidential and is intended for the exclusive use of the addressee(s).
If you are not an intended recipient, any disclosure, reproduction,
distribution or other dissemination or use of the information contained
is strictly prohibited. =C2=A0If you have received this mail in error,
please delete it and notify us immediately.
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this
mail (and any attachment transmitted herewith) is privileged and
confidential and is intended for the exclusive use of the addressee(s).
If you are not an intended recipient, any disclosure, reproduction,
distribution or other dissemination or use of the information contained
is strictly prohibited. =C2=A0If you have received this mail in error,
please delete it and notify us immediately.

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


--
Juergen Schoenwaelder =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jacobs University = Bremen gGmbH
Phone: +49 421 200 3587 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Campus Ring 1, 28759 Br= emen, Germany
Fax: =C2=A0 +49 421 200 3103 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://www.jacobs-universi= ty.de/>

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


/martin

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


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

--001a1134eda8ee277604fe3bb33a-- From nobody Tue Jul 15 07:09:52 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D761B28B9; Tue, 15 Jul 2014 07:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 0f4WvKlrQTBo; Tue, 15 Jul 2014 07:09:40 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7F611A03F9; Tue, 15 Jul 2014 07:09:39 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 612196DD; Tue, 15 Jul 2014 16:09:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id HLE866EcDqnU; Tue, 15 Jul 2014 16:09:29 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 15 Jul 2014 16:09:37 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36FAF20017; Tue, 15 Jul 2014 16:09:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id yR2WXbC9VGrn; Tue, 15 Jul 2014 16:09:36 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DB6262002C; Tue, 15 Jul 2014 16:09:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 193712DD8506; Tue, 15 Jul 2014 16:09:33 +0200 (CEST) Date: Tue, 15 Jul 2014 16:09:33 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20140715140933.GA795@elstar.local> Mail-Followup-To: Andy Bierman , "Bert Wijnen (IETF)" , Martin =?iso-8859-1?Q?Bj=F6rklund?= , "feng.chong33@zte.com.cn" , "rob.enns@gmail.com" , "joelja@bogus.com" , Randy Presuhn , "netconf@ietf.org" , Netconf References: <30336078.1403297845090.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> <53C3CF38.2070601@cisco.com> <20140715114200.GA398@elstar.local> <5f76f622-d93a-41e7-8115-2c4e11c2a245@email.android.com> <53C522F0.1030107@bwijnen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/DUCL4d3lqSdRAAodkOmH1pgKAg4 Cc: "rob.enns@gmail.com" , "joelja@bogus.com" , Randy Presuhn , Netconf , "netconf@ietf.org" Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 14:09:42 -0000 On Tue, Jul 15, 2014 at 06:51:21AM -0700, Andy Bierman wrote: > On Tue, Jul 15, 2014 at 5:47 AM, Bert Wijnen (IETF) > wrote: > > > Or.... maybe use MAY and add that if the client wants to be sure that > > such leafs are returned, then the client better asks for those leaf > > explicitly > > in the filter. > > > > So what is the point of this errata? The client already MAY include > whatever > nodes it wants in the filter. IMO the new text adds no value and clarifies > nothing. > I think the goal was to _encourage_ servers to include key leafs while making it clear that doing so is not mandatory and hence (b) encourage clients to explicitely ask for key leafs. The current text says "MAY also be included" and RFC 2119 tells me that MAY means that "an item is truly optional". I think we would have loved this to be a MUST or at least a SHOULD. With the current MAY, the only safe bet is to ask explicitely for any 'instance identifying components'. This kind of stuff is typically material for an implementors guidelines document. But we do not have one and I doubt it is worth starting one for this particular issue. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Jul 15 07:17:18 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717CD1B287C; Tue, 15 Jul 2014 07:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 7zO7REkmx23Y; Tue, 15 Jul 2014 07:17:13 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (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 573C41A03FF; Tue, 15 Jul 2014 07:17:13 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1X73XU-0002YD-TR; Tue, 15 Jul 2014 16:17:06 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest9.guestnet.ripe.net) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1X73XU-0001xg-MF; Tue, 15 Jul 2014 16:17:04 +0200 Message-ID: <53C537E0.3090105@bwijnen.net> Date: Tue, 15 Jul 2014 16:17:04 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Andy Bierman References: <30336078.1403297845090.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> <53C3CF38.2070601@cisco.com> <20140715114200.GA398@elstar.local> <5f76f622-d93a-41e7-8115-2c4e11c2a245@email.android.com> <53C522F0.1030107@bwijnen.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4be29861a15272442f40381b5c588e165 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/onu2r9EdBJQbDl_f39fSEpEZAgY Cc: "rob.enns@gmail.com" , "joelja@bogus.com" , Randy Presuhn , Netconf , "netconf@ietf.org" Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 14:17:16 -0000 Well, I added text that explains that if a client wnts to be sure that it better asks for the leafs in its filter Bert On 15/07/14 15:51, Andy Bierman wrote: > > > > On Tue, Jul 15, 2014 at 5:47 AM, Bert Wijnen (IETF) > wrote: > > Or.... maybe use MAY and add that if the client wants to be sure that > such leafs are returned, then the client better asks for those leaf explicitly > in the filter. > > > So what is the point of this errata? The client already MAY include whatever > nodes it wants in the filter. IMO the new text adds no value and clarifies nothing. > > > > Bert > > > Andy > > > On 15/07/14 14:39, Martin Björklund wrote: > > I agree with Juergen. Thus, I think the new text should use MAY instead of MUST. > > On 15 juli 2014 13:42:00 CEST, Juergen Schoenwaelder > wrote: > > But since the original spec did not say clearly such leafs must be > included, I think the only safe bet for a client is to explicitely > request key leafs in the filter - unless we are sure the _every_ > implementation actually returns key leafs (and since nobody knows the > number of implementations around, establishing this fact is hard). > > /js > > On Tue, Jul 15, 2014 at 08:58:14AM +0800, feng.chong33@zte.com.cn > wrote: > > I agree instance identifier MUST be present in output. > /frank > > > "Netconf" > 写于 2014-07-14 20:38:16: > > Benoit Claise > > å‘件人: "Netconf" > > > 2014-07-14 20:38 > > 收件人 > > Martin Björklund >, Randy Presuhn > >__, "Klement Sekera -X (ksekera - > Pantheon Technologies SRO at Cisco)" >, > > æŠ„é€ > > "rob.enns@gmail.com " >, > "joelja@bogus.com " > >, "netconf@ietf.org " > > > 主题 > > Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) > > Dear all, > > Let me try to bring some closure on this errata http://www.rfc- > editor.org/errata_search.php?__eid=3980 > Before proceeding (I want to check with the IESG if this is allowed > > > to introduce a new MUST sentence in an errata), I would like to > 1. check that text below is the final proposal > 2. understand if there is agreement in the WG. Do someone object > > this > > change? > > OLD: > For each sibling set, the server determines which nodes are > > included > > (or potentially included) in the filter output, and which > > sibling > > subtrees are excluded (pruned) from the filter output. The > > server > > first determines which types of nodes are present in the sibling > > set > > and processes the nodes according to the rules for their type. > > If > > any nodes in the sibling set are selected, then the process is > recursively applied to the sibling sets of each selected node. > > The > > algorithm continues until all sibling sets in all subtrees > > specified > > in the filter have been processed. > > NEW: > For each sibling set, the server determines which nodes are > > included > > (or potentially included) in the filter output, and which > > sibling > > subtrees are excluded (pruned) from the filter output. The > > server > > first determines which types of nodes are present in the sibling > > set > > and processes the nodes according to the rules for their type. > > If > > any nodes in the sibling set are selected, then the process is > recursively applied to the sibling sets of each selected node. > > The > > algorithm continues until all sibling sets in all subtrees > > specified > > in the filter have been processed. If any sibling nodes of a > > node > > are instance identifier components for a conceptual data > > structure > > (e.g., list key leaf), then they MUST be included in the filter > > output. > > Regards, Benoit > > > I agree that MUST would be better. But I don't think we can/should > do thar change in an errata. > > On 20 juni 2014 13:57:24 PDT, Randy Presuhn > > > > > wrote: > > > Hi - > > > From: Benoit Claise > > Sent: Jun 20, 2014 2:01 AM > > > ... > > > Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) > > One last check (till mid next week) for everybody in the WG before > > I > > apply this change below to the errata, and accept it. > > > > "SHOULD" is no better than "MAY" or "OPTIONAL" from an > interoperability perspective. "MUST" would be much simpler > for all concerned. > > Randy > > _________________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/__listinfo/netconf > > > > > /martin > . > > > _________________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/__listinfo/netconf > > > ------------------------------__-------------------------- > ZTE Information Security Notice: The information contained in this > > mail (and any attachment transmitted herewith) is privileged and > confidential and is intended for the exclusive use of the addressee(s). > If you are not an intended recipient, any disclosure, reproduction, > distribution or other dissemination or use of the information contained > is strictly prohibited. If you have received this mail in error, > please delete it and notify us immediately. > > ------------------------------__-------------------------- > ZTE Information Security Notice: The information contained in this > > mail (and any attachment transmitted herewith) is privileged and > confidential and is intended for the exclusive use of the addressee(s). > If you are not an intended recipient, any disclosure, reproduction, > distribution or other dissemination or use of the information contained > is strictly prohibited. If you have received this mail in error, > please delete it and notify us immediately. > > _________________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/__listinfo/netconf > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > > _________________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/__listinfo/netconf > > > > /martin > > _________________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/__listinfo/netconf > > > _________________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/__listinfo/netconf > > From nobody Tue Jul 15 07:33:26 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658EE1B2883; Tue, 15 Jul 2014 07:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 1rVKO3OEmJGE; Tue, 15 Jul 2014 07:33:21 -0700 (PDT) Received: from p3plsmtpa12-07.prod.phx3.secureserver.net (p3plsmtpa12-07.prod.phx3.secureserver.net [68.178.252.236]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2C01B287F; Tue, 15 Jul 2014 07:33:21 -0700 (PDT) Received: from [192.168.2.3] ([50.179.41.78]) by p3plsmtpa12-07.prod.phx3.secureserver.net with id SeZK1o00M1hB5UJ01eZKHM; Tue, 15 Jul 2014 07:33:21 -0700 Message-ID: <53C53BAC.4040402@seguesoft.com> Date: Tue, 15 Jul 2014 09:33:16 -0500 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Andy Bierman , "Bert Wijnen (IETF)" , =?ISO-8859-1?Q?Martin_Bj=F6rklund?= , "feng.chong33@zte.com.cn" , "rob.enns@gmail.com" , "joelja@bogus.com" , Randy Presuhn , "netconf@ietf.org" , Netconf References: <30336078.1403297845090.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> <53C3CF38.2070601@cisco.com> <20140715114200.GA398@elstar.local> <5f76f622-d93a-41e7-8115-2c4e11c2a245@email.android.com> <53C522F0.1030107@bwijnen.net> <20140715140933.GA795@elstar.local> In-Reply-To: <20140715140933.GA795@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/DPZrby8jg5P5a5Hj4tOnws8lUyM Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 14:33:22 -0000 >> So what is the point of this errata? The client already MAY include >> whatever >> nodes it wants in the filter. IMO the new text adds no value and clarifies >> nothing. >> > I think the goal was to _encourage_ servers to include key leafs while > making it clear that doing so is not mandatory and hence (b) encourage > clients to explicitely ask for key leafs. > > The current text says "MAY also be included" and RFC 2119 tells me > that MAY means that "an item is truly optional". I think we would have > loved this to be a MUST or at least a SHOULD. With the current MAY, > the only safe bet is to ask explicitely for any 'instance identifying > components'. > > This kind of stuff is typically material for an implementors > guidelines document. But we do not have one and I doubt it is worth > starting one for this particular issue. While I understand Jurgen's point but isn't this an errata item? If it is then I think it needs to be a "MUST". Current implementations out there that do not return key leafs should fix the bug. Otherwise it should not be added as an errata here. --Xiang Li > > /js > -- -- Xiang Li, Seguesoft, Champaign, IL (217) 721-5341 From nobody Tue Jul 15 07:36:21 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2161B28C1 for ; Tue, 15 Jul 2014 07:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 1-KzUrYbCSQE for ; Tue, 15 Jul 2014 07:36:08 -0700 (PDT) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EFDE1B28D2 for ; Tue, 15 Jul 2014 07:35:26 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id m5so2474278qaj.21 for ; Tue, 15 Jul 2014 07:35:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ypZaoM6LXCmUw66lkRb237Lhh9SYEs4E04oxZkfSxko=; b=EFShqRNGBfExCC6EXRmHtpsf8y+ql0Kg7cMuZPQqyGxsHu5DIVNXi+GQjUGnG6Wg1i 2PDDyr3jSJcjujyZHysqCbm0W7jnu1EL//n0s9T1yWXANg4WJpXKBOqF0SZjxWp117L4 fODrUPTBcgN625/Uhe5vhsK05X8ASO8WzRV5eut7L9D8m3C9/ZG8C2Olt/PX/zEmnHVM yeY/28JBF8yrxAL2t9dp6cqASZRZPzECEwRRNU5SzsU6DfdNcU24B1m0JzskfV/KZ+32 cPIp4UJg/T+FKm7jAHSzUbbY6oQ+7lf8Muw4/dk1G0ivMNrwEh2oG3DxMUW1d4yyq18M TOxg== X-Gm-Message-State: ALoCoQkHe46dupmsgtRVNY2gGY4CC7V1zZfHIV+ue7RHndkfrIAk41Kgil2l6l1EdJMxQG7iulh6 MIME-Version: 1.0 X-Received: by 10.224.28.133 with SMTP id m5mr5734261qac.16.1405434925382; Tue, 15 Jul 2014 07:35:25 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Tue, 15 Jul 2014 07:35:25 -0700 (PDT) In-Reply-To: <53C537E0.3090105@bwijnen.net> References: <30336078.1403297845090.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> <53C3CF38.2070601@cisco.com> <20140715114200.GA398@elstar.local> <5f76f622-d93a-41e7-8115-2c4e11c2a245@email.android.com> <53C522F0.1030107@bwijnen.net> <53C537E0.3090105@bwijnen.net> Date: Tue, 15 Jul 2014 07:35:25 -0700 Message-ID: From: Andy Bierman To: "Bert Wijnen (IETF)" Content-Type: multipart/alternative; boundary=001a11c1db707b97dd04fe3c51aa Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Rvkdj-HGNotidnUakZm5terHqUk Cc: "rob.enns@gmail.com" , "joelja@bogus.com" , Randy Presuhn , Netconf , "netconf@ietf.org" Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 14:36:14 -0000 --001a11c1db707b97dd04fe3c51aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 15, 2014 at 7:17 AM, Bert Wijnen (IETF) wrote: > Well, I added text that explains that if a client wnts to be sure that it > better > asks for the leafs in its filter > The subtree filtering is much more useful if the server supplies missing keys. (I guess we agree on that). Consider a simple use-case: there are 10,000 interface entries and 1 of them is disabled. Which one? false If I add the leaf to the filter, I will get back 10,000 matches. If I don't, then all I get back is the filter I sent, confirming there is indeed 1 disabled interface. The only useful response is to include the leaf for the 1 entry that matched. It seems like SHOULD is more appropriate than MAY. It does not force old servers to be non-compliant like MUST. > Bert > Andy > > On 15/07/14 15:51, Andy Bierman wrote: > >> >> >> >> On Tue, Jul 15, 2014 at 5:47 AM, Bert Wijnen (IETF) > > wrote: >> >> Or.... maybe use MAY and add that if the client wants to be sure tha= t >> such leafs are returned, then the client better asks for those leaf >> explicitly >> in the filter. >> >> >> So what is the point of this errata? The client already MAY include >> whatever >> nodes it wants in the filter. IMO the new text adds no value and >> clarifies nothing. >> >> >> >> Bert >> >> >> Andy >> >> >> On 15/07/14 14:39, Martin Bj=C3=B6rklund wrote: >> >> I agree with Juergen. Thus, I think the new text should use MAY >> instead of MUST. >> >> On 15 juli 2014 13:42:00 CEST, Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-__university.de >> > wrote: >> >> But since the original spec did not say clearly such leafs >> must be >> included, I think the only safe bet for a client is to >> explicitely >> request key leafs in the filter - unless we are sure the >> _every_ >> implementation actually returns key leafs (and since nobody >> knows the >> number of implementations around, establishing this fact is >> hard). >> >> /js >> >> On Tue, Jul 15, 2014 at 08:58:14AM +0800, >> feng.chong33@zte.com.cn >> wrote: >> >> I agree instance identifier MUST be present in output. >> /frank >> >> >> "Netconf" > netconf-bounces@ietf.org>> =E5=86=99=E4=BA=8E 2014-07-14 20:38:16: >> >> Benoit Claise > bclaise@cisco.com>> >> =E5=8F=91=E4=BB=B6=E4=BA=BA: "Netconf" > netconf-bounces@ietf.org>> >> >> 2014-07-14 20:38 >> >> =E6=94=B6=E4=BB=B6=E4=BA=BA >> >> Martin Bj=C3=B6rklund > mbj@tail-f.com>>, Randy Presuhn >> > mindspring.com>>__, "Klement Sekera -X (ksekera - >> Pantheon Technologies SRO at Cisco)" < >> ksekera@cisco.com >, >> >> =E6=8A=84=E9=80=81 >> >> "rob.enns@gmail.com " < >> rob.enns@gmail.com >, >> "joelja@bogus.com " >> >, " >> netconf@ietf.org " > > >> >> =E4=B8=BB=E9=A2=98 >> >> Re: [Netconf] [Technical Errata Reported] RFC6241 >> (3980) >> >> Dear all, >> >> Let me try to bring some closure on this errata >> http://www.rfc- >> editor.org/errata_search.php?__eid=3D3980 < >> http://editor.org/errata_search.php?eid=3D3980> >> Before proceeding (I want to check with the IESG if >> this is allowed >> >> >> to introduce a new MUST sentence in an errata), I >> would like to >> 1. check that text below is the final proposal >> 2. understand if there is agreement in the WG. Do >> someone object >> >> this >> >> change? >> >> OLD: >> For each sibling set, the server determines >> which nodes are >> >> included >> >> (or potentially included) in the filter output, >> and which >> >> sibling >> >> subtrees are excluded (pruned) from the filter >> output. The >> >> server >> >> first determines which types of nodes are >> present in the sibling >> >> set >> >> and processes the nodes according to the rules >> for their type. >> >> If >> >> any nodes in the sibling set are selected, then >> the process is >> recursively applied to the sibling sets of each >> selected node. >> >> The >> >> algorithm continues until all sibling sets in >> all subtrees >> >> specified >> >> in the filter have been processed. >> >> NEW: >> For each sibling set, the server determines >> which nodes are >> >> included >> >> (or potentially included) in the filter output, >> and which >> >> sibling >> >> subtrees are excluded (pruned) from the filter >> output. The >> >> server >> >> first determines which types of nodes are >> present in the sibling >> >> set >> >> and processes the nodes according to the rules >> for their type. >> >> If >> >> any nodes in the sibling set are selected, then >> the process is >> recursively applied to the sibling sets of each >> selected node. >> >> The >> >> algorithm continues until all sibling sets in >> all subtrees >> >> specified >> >> in the filter have been processed. If any >> sibling nodes of a >> >> node >> >> are instance identifier components for a >> conceptual data >> >> structure >> >> (e.g., list key leaf), then they MUST be >> included in the filter >> >> output. >> >> Regards, Benoit >> >> >> I agree that MUST would be better. But I don't think >> we can/should >> do thar change in an errata. >> >> On 20 juni 2014 13:57:24 PDT, Randy Presuhn >> >> > mindspring.com>> >> >> wrote: >> >> >> Hi - >> >> >> From: Benoit Claise > bclaise@cisco.com>> >> Sent: Jun 20, 2014 2:01 AM >> >> >> ... >> >> >> Subject: Re: [Netconf] [Technical Errata Reported] >> RFC6241 (3980) >> >> One last check (till mid next week) for everybody in >> the WG before >> >> I >> >> apply this change below to the errata, and accept it= . >> >> >> >> "SHOULD" is no better than "MAY" or "OPTIONAL" from = an >> interoperability perspective. "MUST" would be much >> simpler >> for all concerned. >> >> Randy >> >> _________________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/__listinfo/netconf < >> https://www.ietf.org/mailman/listinfo/netconf> >> >> >> >> >> /martin >> . >> >> >> _________________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/__listinfo/netconf < >> https://www.ietf.org/mailman/listinfo/netconf> >> >> >> ------------------------------ >> __-------------------------- >> ZTE Information Security Notice: The information >> contained in this >> >> mail (and any attachment transmitted herewith) is privileged >> and >> confidential and is intended for the exclusive use of the >> addressee(s). >> If you are not an intended recipient, any disclosure, >> reproduction, >> distribution or other dissemination or use of the informatio= n >> contained >> is strictly prohibited. If you have received this mail in >> error, >> please delete it and notify us immediately. >> >> ------------------------------ >> __-------------------------- >> ZTE Information Security Notice: The information >> contained in this >> >> mail (and any attachment transmitted herewith) is privileged >> and >> confidential and is intended for the exclusive use of the >> addressee(s). >> If you are not an intended recipient, any disclosure, >> reproduction, >> distribution or other dissemination or use of the informatio= n >> contained >> is strictly prohibited. If you have received this mail in >> error, >> please delete it and notify us immediately. >> >> _________________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/__listinfo/netconf < >> https://www.ietf.org/mailman/listinfo/netconf> >> >> >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGm= bH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, >> Germany >> Fax: +49 421 200 3103 < >> http://www.jacobs-university.__de/ > >> >> _________________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/__listinfo/netconf < >> https://www.ietf.org/mailman/listinfo/netconf> >> >> >> >> /martin >> >> _________________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/__listinfo/netconf < >> https://www.ietf.org/mailman/listinfo/netconf> >> >> >> _________________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/__listinfo/netconf < >> https://www.ietf.org/mailman/listinfo/netconf> >> >> >> --001a11c1db707b97dd04fe3c51aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Jul 15, 2014 at 7:17 AM, Bert Wijnen (IETF) <bertietf@b= wijnen.net> wrote:
Well, I added text that explains that if a c= lient wnts to be sure that it better
asks for the leafs in its filter


The subtree filtering is much more useful if the server supplies m= issing keys.
(I guess we agree on that). =C2=A0Consider a simple = use-case: there are 10,000 interface
entries and 1 of them is disabled. =C2=A0Which one?

=C2=A0 =C2=A0<interfaces>
=C2=A0 =C2=A0 =C2=A0 <i= nterface>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<enabled>fal= se</enabled>
=C2=A0 =C2=A0 =C2=A0 </interface>
=C2=A0 =C2=A0</interfaces>

If I add the= <name> leaf to the filter, I will get back 10,000 matches.
If I don't, then all I get back is the filter I sent, confirming there= is indeed 1 disabled interface.
The only useful response is to include the <name> leaf for the 1= entry that matched.

It seems like SHOULD is more = appropriate than MAY. =C2=A0It does not force old servers to
be n= on-compliant like MUST.


Bert

Andy
=C2=A0

On 15/07/14 15:51, Andy Bierman wrote:



On Tue, Jul 15, 2014 at 5:47 AM, Bert Wijnen (IETF) <bertietf@bwijnen.net <mailto:= bertietf@bwijnen.= net>> wrote:

=C2=A0 =C2=A0 Or.... maybe use MAY and add that if the client wants to be s= ure that
=C2=A0 =C2=A0 such leafs are returned, then the client better asks for thos= e leaf explicitly
=C2=A0 =C2=A0 in the filter.


So what is the point of this errata? =C2=A0The client already MAY include w= hatever
nodes it wants in the filter. IMO the new text adds no value and clarifies = nothing.



=C2=A0 =C2=A0 Bert


Andy


=C2=A0 =C2=A0 On 15/07/14 14:39, Martin Bj=C3=B6rklund wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I agree with Juergen. Thus, I think the new tex= t should use MAY instead of MUST.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On 15 juli 2014 13:42:00 CEST, Juergen Schoenwa= elder <j.schoenwaelder@jacobs-__university.de
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:j.schoenwaelder@jacobs-univers= ity.de>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 But since the original spec did n= ot say clearly such leafs must be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 included, I think the only safe b= et for a client is to explicitely
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 request key leafs in the filter -= unless we are sure the _every_
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 implementation actually returns k= ey leafs (and since nobody knows the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 number of implementations around,= establishing this fact is hard).

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /js

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Tue, Jul 15, 2014 at 08:58:14A= M +0800, feng.= chong33@zte.com.cn <mailto:feng.chong33@zte.com.cn>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I agree instance id= entifier MUST be present in output.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /frank


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Netconf"= <netconf-= bounces@ietf.org <mailto:netconf-bounces@ietf.org>> =E5=86=99=E4= =BA=8E 2014-07-14 20:38:16:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Benoi= t Claise <bclaise= @cisco.com <mailto:bclaise@cisco.com>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E5= =8F=91=E4=BB=B6=E4=BA=BA: =C2=A0"Netconf" <netconf-bounces@ietf.org <= ;mailto:netco= nf-bounces@ietf.org>>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2014-= 07-14 20:38

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E6= =94=B6=E4=BB=B6=E4=BA=BA

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Marti= n Bj=C3=B6rklund <mb= j@tail-f.com <mailto:mbj@tail-f.com>>, Randy Presuhn
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<= a href=3D"mailto:randy_presuhn@mindspring.com" target=3D"_blank">randy_pres= uhn@mindspring.com <mailto:randy_presuhn@mindspring.com>>__,= "Klement Sekera -X (ksekera -
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Panth= eon Technologies SRO at Cisco)" <ksekera@cisco.com <mailto:ksekera@cisco.com>>,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E6= =8A=84=E9=80=81

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;rob.enns@gmail.com= <mailto:rob= .enns@gmail.com>" <rob.enns@gmail.com <mailto:rob.enns@gmail.com>>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;joelja@bogus.com= <mailto:joelja@bo= gus.com>"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<= a href=3D"mailto:joelja@bogus.com" target=3D"_blank">joelja@bogus.com &= lt;mailto:joelja@bogu= s.com>>, "netconf@ietf.org <mailto:netconf@ietf.org>" <netconf@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <m= ailto:netconf@ietf.or= g>>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =E4= =B8=BB=E9=A2=98

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Re: [= Netconf] [Technical Errata Reported] RFC6241 (3980)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Dear = all,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Let m= e try to bring some closure on this errata http://www.rfc-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 e= ditor.org/errata_search.php?__eid=3D3980 <http://editor.org= /errata_search.php?eid=3D3980>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Befor= e proceeding (I want to check with the IESG if this is allowed


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to in= troduce a new MUST sentence in an errata), I would like to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1. ch= eck that text below is the final proposal
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2. un= derstand if there is agreement in the WG. Do someone object

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 change?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OLD:<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0For each sibling set, the server determines which nodes ar= e

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 included

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0(or potentially included) in the filter output, and which<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sibling

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0subtrees are excluded (pruned) from the filter output. =C2= =A0The

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 server

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0first determines which types of nodes are present in the s= ibling

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 set

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0and processes the nodes according to the rules for their t= ype.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0any nodes in the sibling set are selected, then the proces= s is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0recursively applied to the sibling sets of each selected n= ode.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0algorithm continues until all sibling sets in all subtrees=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 specified

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0in the filter have been processed.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 NEW:<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0For each sibling set, the server determines which nodes ar= e

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 included

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0(or potentially included) in the filter output, and which<= br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sibling

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0subtrees are excluded (pruned) from the filter output. =C2= =A0The

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 server

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0first determines which types of nodes are present in the s= ibling

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 set

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0and processes the nodes according to the rules for their t= ype.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0any nodes in the sibling set are selected, then the proces= s is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0recursively applied to the sibling sets of each selected n= ode.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0algorithm continues until all sibling sets in all subtrees=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 specified

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0in the filter have been processed. If any sibling nodes of= a

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 node

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0are instance identifier components for a conceptual data
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 structure

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0(e.g., list key leaf), then they MUST be included in the f= ilter

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Regar= ds, Benoit


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I agr= ee that MUST would be better. But I don't think we can/should
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 do th= ar change in an errata.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On 20= juni 2014 13:57:24 PDT, Randy Presuhn

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <randy_presuhn@mindspring= .com <mailto:randy_presuhn@mindspring.com>>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 wrote= :


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi -<= br>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 From:= Benoit Claise <b= claise@cisco.com <mailto:bclaise@cisco.com>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sent:= Jun 20, 2014 2:01 AM


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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Subje= ct: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 One l= ast check (till mid next week) for everybody in the WG before

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 apply= this change below to the errata, and accept it.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;SHOULD" is no better than "MAY" or "OPTIONAL" fro= m an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inter= operability perspective. =C2=A0"MUST" would be much simpler
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for a= ll concerned.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Randy=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _____= ____________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Netco= nf mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Netconf@ietf.org <m= ailto:Netconf@ietf.or= g>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ht= tps://www.ietf.org/mailman/__listinfo/netconf <https://www.i= etf.org/mailman/listinfo/netconf>




=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /mart= in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _____= ____________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Netco= nf mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Netconf@ietf.org <m= ailto:Netconf@ietf.or= g>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ht= tps://www.ietf.org/mailman/__listinfo/netconf <https://www.i= etf.org/mailman/listinfo/netconf>


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -------------------= -----------__--------------------------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ZTE Information Sec= urity Notice: The information contained in this

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mail (and any attachment transmit= ted herewith) is privileged and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 confidential and is intended for = the exclusive use of the addressee(s).
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If you are not an intended recipi= ent, any disclosure, reproduction,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 distribution or other disseminati= on or use of the information contained
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is strictly prohibited. =C2=A0If = you have received this mail in error,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 please delete it and notify us im= mediately.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -------------------= -----------__--------------------------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ZTE Information Sec= urity Notice: The information contained in this

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mail (and any attachment transmit= ted herewith) is privileged and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 confidential and is intended for = the exclusive use of the addressee(s).
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If you are not an intended recipi= ent, any disclosure, reproduction,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 distribution or other disseminati= on or use of the information contained
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is strictly prohibited. =C2=A0If = you have received this mail in error,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 please delete it and notify us im= mediately.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________= ______________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Netconf mailing lis= t
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Netconf@ietf.org <mailto:Netconf@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf= .org/mailman/__listinfo/netconf <https://www.ietf.org/mailma= n/listinfo/netconf>



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Juergen Schoenwaelder =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Jacobs University Bremen gGmbH
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: +49 421 200 3587 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Campus Ring 1, 28759 Bremen, Germany
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Fax: =C2=A0 +49 421 200 3103 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 <http://www.jacobs-university.__de/ <http://www.jacobs-unive= rsity.de/>>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ______________________________= ___________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Netconf mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Netconf@ietf.org <mailto:Netconf@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/_= _listinfo/netconf <https://www.ietf.org/mailman/listi= nfo/netconf>



=C2=A0 =C2=A0 =C2=A0 =C2=A0 /martin

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ________________________________________= _________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Netconf mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Netconf@ietf.org <mailto:Netconf@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/__listin= fo/netconf <https://www.ietf.org/mailman/listinfo/netconf>


=C2=A0 =C2=A0 _________________________________________________
=C2=A0 =C2=A0 Netconf mailing list
=C2=A0 =C2=A0 Netconf= @ietf.org <mailto:Netconf@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/__listinfo/netconf= <https://www.ietf.org/mailman/listinfo/netconf>



--001a11c1db707b97dd04fe3c51aa-- From nobody Tue Jul 15 07:50:06 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3550F1B287F; Tue, 15 Jul 2014 07:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 TcVezXWusrVv; Tue, 15 Jul 2014 07:49:58 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B676A1B28C1; Tue, 15 Jul 2014 07:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17780; q=dns/txt; s=iport; t=1405435686; x=1406645286; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+S/iAOdtw4uYuNCmyhvE/zHC6grQnmdqpmA91puBcaA=; b=i1MXl7LEZuUcFoBefYYdu6itTh6d79dRBRXkpO+vqYSIpNLYdTd2G+TR 05GPjFwhgVrqLeI8VwVaa65iphmvqrfI3PM5HCqmsORnECf+oIhzOtEdz MDlyQQtJ7R/+UO6W4aV8oFqytuXAxS4eNf1fRhpz3cW4dXV09GFk0zgcj Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FALQ+xVOtJA2B/2dsb2JhbAA/FwODDlJXBIJyvnQKhnBTARlzFnWEAwEBAQQBAQEgEToLDgICAQYCEAEEAQEBAgIjAwICAhkGBgsUAQgIAgQOBYguAxENNpUGnCiRBQ2HCxcEgSiKcIECgVwBARwYCwsFBxGCZoFMBZkYg0uMPoYcg0RsgQw5 X-IronPort-AV: E=Sophos;i="5.01,665,1400025600"; d="scan'208";a="340163410" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP; 15 Jul 2014 14:48:05 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6FEm5QN015065 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Jul 2014 14:48:05 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.17]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Tue, 15 Jul 2014 09:48:05 -0500 From: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" To: "andy@yumaworks.com" Thread-Topic: [Netconf] [Technical Errata Reported] RFC6241 (3980) Thread-Index: AQHPjMpE1rSv56QPfUy4JxqVG/6IWpt7HU0AgCTd5wCAAM6/AIAAs94AgAAQG4CAAAJCAIAAEcaAgAAHMACAAAUggIAAA4kA Date: Tue, 15 Jul 2014 14:48:05 +0000 Message-ID: <1405435684.19255.2.camel@ksekera-fedora> References: <30336078.1403297845090.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> <53C3CF38.2070601@cisco.com> <20140715114200.GA398@elstar.local> <5f76f622-d93a-41e7-8115-2c4e11c2a245@email.android.com> <53C522F0.1030107@bwijnen.net> <53C537E0.3090105@bwijnen.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.83.180] Content-Type: text/plain; charset="utf-8" Content-ID: <364F0ACD3688F94EB30294A9670EF44C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/5O7FiCb48_sUWR0O5Aib9gwNwDQ Cc: "rob.enns@gmail.com" , "joelja@bogus.com" , "randy_presuhn@mindspring.com" , "netconf-bounces@ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 14:50:02 -0000 SGkgQW5keSwNCg0KanVzdCB0byBjbGFyaWZ5LCB5b3VyIGZpbHRlciB3b3VsZCBzZWxlY3Qgb25s eSB0aGUgb25lIGRpc2FibGVkDQppbnRlcmZhY2UgZXZlbiBpZiB5b3Ugc3BlY2lmaWVkIHRoZSA8 bmFtZT4gdGhlcmUuIEFsbCB0aGUgb3RoZXINCmluc3RhbmNlcyB3b3VsZCBiZSBkcm9wcGVkLCBz aW5jZSB0aGUgY29udGVudC1tYXRjaCBvbiA8ZW5hYmxlZD4gaXMNCmZhbHNlLg0KDQpLbGVtZW50 DQoNCk9uIFR1ZSwgMjAxNC0wNy0xNSBhdCAwNzozNSAtMDcwMCwgQW5keSBCaWVybWFuIHdyb3Rl Og0KPiBPbiBUdWUsIEp1bCAxNSwgMjAxNCBhdCA3OjE3IEFNLCBCZXJ0IFdpam5lbiAoSUVURikg PGJlcnRpZXRmQGJ3aWpuZW4ubmV0Pg0KPiB3cm90ZToNCj4gDQo+ID4gV2VsbCwgSSBhZGRlZCB0 ZXh0IHRoYXQgZXhwbGFpbnMgdGhhdCBpZiBhIGNsaWVudCB3bnRzIHRvIGJlIHN1cmUgdGhhdCBp dA0KPiA+IGJldHRlcg0KPiA+IGFza3MgZm9yIHRoZSBsZWFmcyBpbiBpdHMgZmlsdGVyDQo+ID4N Cj4gDQo+IA0KPiBUaGUgc3VidHJlZSBmaWx0ZXJpbmcgaXMgbXVjaCBtb3JlIHVzZWZ1bCBpZiB0 aGUgc2VydmVyIHN1cHBsaWVzIG1pc3NpbmcNCj4ga2V5cy4NCj4gKEkgZ3Vlc3Mgd2UgYWdyZWUg b24gdGhhdCkuICBDb25zaWRlciBhIHNpbXBsZSB1c2UtY2FzZTogdGhlcmUgYXJlIDEwLDAwMA0K PiBpbnRlcmZhY2UNCj4gZW50cmllcyBhbmQgMSBvZiB0aGVtIGlzIGRpc2FibGVkLiAgV2hpY2gg b25lPw0KPiANCj4gICAgPGludGVyZmFjZXM+DQo+ICAgICAgIDxpbnRlcmZhY2U+DQo+ICAgICAg ICAgIDxlbmFibGVkPmZhbHNlPC9lbmFibGVkPg0KPiAgICAgICA8L2ludGVyZmFjZT4NCj4gICAg PC9pbnRlcmZhY2VzPg0KPiANCj4gSWYgSSBhZGQgdGhlIDxuYW1lPiBsZWFmIHRvIHRoZSBmaWx0 ZXIsIEkgd2lsbCBnZXQgYmFjayAxMCwwMDAgbWF0Y2hlcy4NCj4gSWYgSSBkb24ndCwgdGhlbiBh bGwgSSBnZXQgYmFjayBpcyB0aGUgZmlsdGVyIEkgc2VudCwgY29uZmlybWluZyB0aGVyZSBpcw0K PiBpbmRlZWQgMSBkaXNhYmxlZCBpbnRlcmZhY2UuDQo+IFRoZSBvbmx5IHVzZWZ1bCByZXNwb25z ZSBpcyB0byBpbmNsdWRlIHRoZSA8bmFtZT4gbGVhZiBmb3IgdGhlIDEgZW50cnkgdGhhdA0KPiBt YXRjaGVkLg0KPiANCj4gSXQgc2VlbXMgbGlrZSBTSE9VTEQgaXMgbW9yZSBhcHByb3ByaWF0ZSB0 aGFuIE1BWS4gIEl0IGRvZXMgbm90IGZvcmNlIG9sZA0KPiBzZXJ2ZXJzIHRvDQo+IGJlIG5vbi1j b21wbGlhbnQgbGlrZSBNVVNULg0KPiANCj4gDQo+ID4gQmVydA0KPiA+DQo+IA0KPiBBbmR5DQo+ IA0KPiANCj4gPg0KPiA+IE9uIDE1LzA3LzE0IDE1OjUxLCBBbmR5IEJpZXJtYW4gd3JvdGU6DQo+ ID4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gT24gVHVlLCBKdWwgMTUsIDIwMTQgYXQgNTo0NyBB TSwgQmVydCBXaWpuZW4gKElFVEYpIDxiZXJ0aWV0ZkBid2lqbmVuLm5ldA0KPiA+PiA8bWFpbHRv OmJlcnRpZXRmQGJ3aWpuZW4ubmV0Pj4gd3JvdGU6DQo+ID4+DQo+ID4+ICAgICBPci4uLi4gbWF5 YmUgdXNlIE1BWSBhbmQgYWRkIHRoYXQgaWYgdGhlIGNsaWVudCB3YW50cyB0byBiZSBzdXJlIHRo YXQNCj4gPj4gICAgIHN1Y2ggbGVhZnMgYXJlIHJldHVybmVkLCB0aGVuIHRoZSBjbGllbnQgYmV0 dGVyIGFza3MgZm9yIHRob3NlIGxlYWYNCj4gPj4gZXhwbGljaXRseQ0KPiA+PiAgICAgaW4gdGhl IGZpbHRlci4NCj4gPj4NCj4gPj4NCj4gPj4gU28gd2hhdCBpcyB0aGUgcG9pbnQgb2YgdGhpcyBl cnJhdGE/ICBUaGUgY2xpZW50IGFscmVhZHkgTUFZIGluY2x1ZGUNCj4gPj4gd2hhdGV2ZXINCj4g Pj4gbm9kZXMgaXQgd2FudHMgaW4gdGhlIGZpbHRlci4gSU1PIHRoZSBuZXcgdGV4dCBhZGRzIG5v IHZhbHVlIGFuZA0KPiA+PiBjbGFyaWZpZXMgbm90aGluZy4NCj4gPj4NCj4gPj4NCj4gPj4NCj4g Pj4gICAgIEJlcnQNCj4gPj4NCj4gPj4NCj4gPj4gQW5keQ0KPiA+Pg0KPiA+Pg0KPiA+PiAgICAg T24gMTUvMDcvMTQgMTQ6MzksIE1hcnRpbiBCasO2cmtsdW5kIHdyb3RlOg0KPiA+Pg0KPiA+PiAg ICAgICAgIEkgYWdyZWUgd2l0aCBKdWVyZ2VuLiBUaHVzLCBJIHRoaW5rIHRoZSBuZXcgdGV4dCBz aG91bGQgdXNlIE1BWQ0KPiA+PiBpbnN0ZWFkIG9mIE1VU1QuDQo+ID4+DQo+ID4+ICAgICAgICAg T24gMTUganVsaSAyMDE0IDEzOjQyOjAwIENFU1QsIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8DQo+ ID4+IGouc2Nob2Vud2FlbGRlckBqYWNvYnMtX191bml2ZXJzaXR5LmRlDQo+ID4+ICAgICAgICAg PG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+PiB3cm90ZToNCj4g Pj4NCj4gPj4gICAgICAgICAgICAgQnV0IHNpbmNlIHRoZSBvcmlnaW5hbCBzcGVjIGRpZCBub3Qg c2F5IGNsZWFybHkgc3VjaCBsZWFmcw0KPiA+PiBtdXN0IGJlDQo+ID4+ICAgICAgICAgICAgIGlu Y2x1ZGVkLCBJIHRoaW5rIHRoZSBvbmx5IHNhZmUgYmV0IGZvciBhIGNsaWVudCBpcyB0bw0KPiA+ PiBleHBsaWNpdGVseQ0KPiA+PiAgICAgICAgICAgICByZXF1ZXN0IGtleSBsZWFmcyBpbiB0aGUg ZmlsdGVyIC0gdW5sZXNzIHdlIGFyZSBzdXJlIHRoZQ0KPiA+PiBfZXZlcnlfDQo+ID4+ICAgICAg ICAgICAgIGltcGxlbWVudGF0aW9uIGFjdHVhbGx5IHJldHVybnMga2V5IGxlYWZzIChhbmQgc2lu Y2Ugbm9ib2R5DQo+ID4+IGtub3dzIHRoZQ0KPiA+PiAgICAgICAgICAgICBudW1iZXIgb2YgaW1w bGVtZW50YXRpb25zIGFyb3VuZCwgZXN0YWJsaXNoaW5nIHRoaXMgZmFjdCBpcw0KPiA+PiBoYXJk KS4NCj4gPj4NCj4gPj4gICAgICAgICAgICAgL2pzDQo+ID4+DQo+ID4+ICAgICAgICAgICAgIE9u IFR1ZSwgSnVsIDE1LCAyMDE0IGF0IDA4OjU4OjE0QU0gKzA4MDAsDQo+ID4+IGZlbmcuY2hvbmcz M0B6dGUuY29tLmNuIDxtYWlsdG86ZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24+DQo+ID4+ICAgICAg ICAgICAgIHdyb3RlOg0KPiA+Pg0KPiA+PiAgICAgICAgICAgICAgICAgSSBhZ3JlZSBpbnN0YW5j ZSBpZGVudGlmaWVyIE1VU1QgYmUgcHJlc2VudCBpbiBvdXRwdXQuDQo+ID4+ICAgICAgICAgICAg ICAgICAvZnJhbmsNCj4gPj4NCj4gPj4NCj4gPj4gICAgICAgICAgICAgICAgICJOZXRjb25mIiA8 bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIDxtYWlsdG86DQo+ID4+IG5ldGNvbmYtYm91bmNlc0Bp ZXRmLm9yZz4+IOWGmeS6jiAyMDE0LTA3LTE0IDIwOjM4OjE2Og0KPiA+Pg0KPiA+PiAgICAgICAg ICAgICAgICAgICAgIEJlbm9pdCBDbGFpc2UgPGJjbGFpc2VAY2lzY28uY29tIDxtYWlsdG86DQo+ ID4+IGJjbGFpc2VAY2lzY28uY29tPj4NCj4gPj4gICAgICAgICAgICAgICAgICAgICDlj5Hku7bk uro6ICAiTmV0Y29uZiIgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyA8bWFpbHRvOg0KPiA+PiBu ZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc+Pg0KPiA+Pg0KPiA+PiAgICAgICAgICAgICAgICAgICAg IDIwMTQtMDctMTQgMjA6MzgNCj4gPj4NCj4gPj4gICAgICAgICAgICAgICAgICAgICDmlLbku7bk uroNCj4gPj4NCj4gPj4gICAgICAgICAgICAgICAgICAgICBNYXJ0aW4gQmrDtnJrbHVuZCA8bWJq QHRhaWwtZi5jb20gPG1haWx0bzoNCj4gPj4gbWJqQHRhaWwtZi5jb20+PiwgUmFuZHkgUHJlc3Vo bg0KPiA+PiAgICAgICAgICAgICAgICAgICAgIDxyYW5keV9wcmVzdWhuQG1pbmRzcHJpbmcuY29t IDxtYWlsdG86cmFuZHlfcHJlc3VobkANCj4gPj4gbWluZHNwcmluZy5jb20+Pl9fLCAiS2xlbWVu dCBTZWtlcmEgLVggKGtzZWtlcmEgLQ0KPiA+PiAgICAgICAgICAgICAgICAgICAgIFBhbnRoZW9u IFRlY2hub2xvZ2llcyBTUk8gYXQgQ2lzY28pIiA8DQo+ID4+IGtzZWtlcmFAY2lzY28uY29tIDxt YWlsdG86a3Nla2VyYUBjaXNjby5jb20+PiwNCj4gPj4NCj4gPj4gICAgICAgICAgICAgICAgICAg ICDmioTpgIENCj4gPj4NCj4gPj4gICAgICAgICAgICAgICAgICAgICAicm9iLmVubnNAZ21haWwu Y29tIDxtYWlsdG86cm9iLmVubnNAZ21haWwuY29tPiIgPA0KPiA+PiByb2IuZW5uc0BnbWFpbC5j b20gPG1haWx0bzpyb2IuZW5uc0BnbWFpbC5jb20+PiwNCj4gPj4gICAgICAgICAgICAgICAgICAg ICAiam9lbGphQGJvZ3VzLmNvbSA8bWFpbHRvOmpvZWxqYUBib2d1cy5jb20+Ig0KPiA+PiAgICAg ICAgICAgICAgICAgICAgIDxqb2VsamFAYm9ndXMuY29tIDxtYWlsdG86am9lbGphQGJvZ3VzLmNv bT4+LCAiDQo+ID4+IG5ldGNvbmZAaWV0Zi5vcmcgPG1haWx0bzpuZXRjb25mQGlldGYub3JnPiIg PG5ldGNvbmZAaWV0Zi5vcmcNCj4gPj4gICAgICAgICAgICAgICAgICAgICA8bWFpbHRvOm5ldGNv bmZAaWV0Zi5vcmc+Pg0KPiA+Pg0KPiA+PiAgICAgICAgICAgICAgICAgICAgIOS4u+mimA0KPiA+ Pg0KPiA+PiAgICAgICAgICAgICAgICAgICAgIFJlOiBbTmV0Y29uZl0gW1RlY2huaWNhbCBFcnJh dGEgUmVwb3J0ZWRdIFJGQzYyNDENCj4gPj4gKDM5ODApDQo+ID4+DQo+ID4+ICAgICAgICAgICAg ICAgICAgICAgRGVhciBhbGwsDQo+ID4+DQo+ID4+ICAgICAgICAgICAgICAgICAgICAgTGV0IG1l IHRyeSB0byBicmluZyBzb21lIGNsb3N1cmUgb24gdGhpcyBlcnJhdGENCj4gPj4gaHR0cDovL3d3 dy5yZmMtDQo+ID4+ICAgICAgICAgICAgICAgICAgICAgZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNo LnBocD9fX2VpZD0zOTgwIDwNCj4gPj4gaHR0cDovL2VkaXRvci5vcmcvZXJyYXRhX3NlYXJjaC5w aHA/ZWlkPTM5ODA+DQo+ID4+ICAgICAgICAgICAgICAgICAgICAgQmVmb3JlIHByb2NlZWRpbmcg KEkgd2FudCB0byBjaGVjayB3aXRoIHRoZSBJRVNHIGlmDQo+ID4+IHRoaXMgaXMgYWxsb3dlZA0K PiA+Pg0KPiA+Pg0KPiA+PiAgICAgICAgICAgICAgICAgICAgIHRvIGludHJvZHVjZSBhIG5ldyBN VVNUIHNlbnRlbmNlIGluIGFuIGVycmF0YSksIEkNCj4gPj4gd291bGQgbGlrZSB0bw0KPiA+PiAg ICAgICAgICAgICAgICAgICAgIDEuIGNoZWNrIHRoYXQgdGV4dCBiZWxvdyBpcyB0aGUgZmluYWwg cHJvcG9zYWwNCj4gPj4gICAgICAgICAgICAgICAgICAgICAyLiB1bmRlcnN0YW5kIGlmIHRoZXJl IGlzIGFncmVlbWVudCBpbiB0aGUgV0cuIERvDQo+ID4+IHNvbWVvbmUgb2JqZWN0DQo+ID4+DQo+ ID4+ICAgICAgICAgICAgIHRoaXMNCj4gPj4NCj4gPj4gICAgICAgICAgICAgICAgIGNoYW5nZT8N Cj4gPj4NCj4gPj4gICAgICAgICAgICAgICAgICAgICBPTEQ6DQo+ID4+ICAgICAgICAgICAgICAg ICAgICAgICAgICBGb3IgZWFjaCBzaWJsaW5nIHNldCwgdGhlIHNlcnZlciBkZXRlcm1pbmVzDQo+ ID4+IHdoaWNoIG5vZGVzIGFyZQ0KPiA+Pg0KPiA+PiAgICAgICAgICAgICBpbmNsdWRlZA0KPiA+ Pg0KPiA+PiAgICAgICAgICAgICAgICAgICAgICAgICAgKG9yIHBvdGVudGlhbGx5IGluY2x1ZGVk KSBpbiB0aGUgZmlsdGVyIG91dHB1dCwNCj4gPj4gYW5kIHdoaWNoDQo+ID4+DQo+ID4+ICAgICAg ICAgICAgIHNpYmxpbmcNCj4gPj4NCj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgIHN1YnRy ZWVzIGFyZSBleGNsdWRlZCAocHJ1bmVkKSBmcm9tIHRoZSBmaWx0ZXINCj4gPj4gb3V0cHV0LiAg VGhlDQo+ID4+DQo+ID4+ICAgICAgICAgICAgIHNlcnZlcg0KPiA+Pg0KPiA+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgZmlyc3QgZGV0ZXJtaW5lcyB3aGljaCB0eXBlcyBvZiBub2RlcyBhcmUN Cj4gPj4gcHJlc2VudCBpbiB0aGUgc2libGluZw0KPiA+Pg0KPiA+PiAgICAgICAgICAgICBzZXQN Cj4gPj4NCj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgIGFuZCBwcm9jZXNzZXMgdGhlIG5v ZGVzIGFjY29yZGluZyB0byB0aGUgcnVsZXMNCj4gPj4gZm9yIHRoZWlyIHR5cGUuDQo+ID4+DQo+ ID4+ICAgICAgICAgICAgIElmDQo+ID4+DQo+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICBh bnkgbm9kZXMgaW4gdGhlIHNpYmxpbmcgc2V0IGFyZSBzZWxlY3RlZCwgdGhlbg0KPiA+PiB0aGUg cHJvY2VzcyBpcw0KPiA+PiAgICAgICAgICAgICAgICAgICAgICAgICAgcmVjdXJzaXZlbHkgYXBw bGllZCB0byB0aGUgc2libGluZyBzZXRzIG9mIGVhY2gNCj4gPj4gc2VsZWN0ZWQgbm9kZS4NCj4g Pj4NCj4gPj4gICAgICAgICAgICAgVGhlDQo+ID4+DQo+ID4+ICAgICAgICAgICAgICAgICAgICAg ICAgICBhbGdvcml0aG0gY29udGludWVzIHVudGlsIGFsbCBzaWJsaW5nIHNldHMgaW4NCj4gPj4g YWxsIHN1YnRyZWVzDQo+ID4+DQo+ID4+ICAgICAgICAgICAgIHNwZWNpZmllZA0KPiA+Pg0KPiA+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgaW4gdGhlIGZpbHRlciBoYXZlIGJlZW4gcHJvY2Vz c2VkLg0KPiA+Pg0KPiA+PiAgICAgICAgICAgICAgICAgICAgIE5FVzoNCj4gPj4gICAgICAgICAg ICAgICAgICAgICAgICAgIEZvciBlYWNoIHNpYmxpbmcgc2V0LCB0aGUgc2VydmVyIGRldGVybWlu ZXMNCj4gPj4gd2hpY2ggbm9kZXMgYXJlDQo+ID4+DQo+ID4+ICAgICAgICAgICAgIGluY2x1ZGVk DQo+ID4+DQo+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAob3IgcG90ZW50aWFsbHkgaW5j bHVkZWQpIGluIHRoZSBmaWx0ZXIgb3V0cHV0LA0KPiA+PiBhbmQgd2hpY2gNCj4gPj4NCj4gPj4g ICAgICAgICAgICAgc2libGluZw0KPiA+Pg0KPiA+PiAgICAgICAgICAgICAgICAgICAgICAgICAg c3VidHJlZXMgYXJlIGV4Y2x1ZGVkIChwcnVuZWQpIGZyb20gdGhlIGZpbHRlcg0KPiA+PiBvdXRw dXQuICBUaGUNCj4gPj4NCj4gPj4gICAgICAgICAgICAgc2VydmVyDQo+ID4+DQo+ID4+ICAgICAg ICAgICAgICAgICAgICAgICAgICBmaXJzdCBkZXRlcm1pbmVzIHdoaWNoIHR5cGVzIG9mIG5vZGVz IGFyZQ0KPiA+PiBwcmVzZW50IGluIHRoZSBzaWJsaW5nDQo+ID4+DQo+ID4+ICAgICAgICAgICAg IHNldA0KPiA+Pg0KPiA+PiAgICAgICAgICAgICAgICAgICAgICAgICAgYW5kIHByb2Nlc3NlcyB0 aGUgbm9kZXMgYWNjb3JkaW5nIHRvIHRoZSBydWxlcw0KPiA+PiBmb3IgdGhlaXIgdHlwZS4NCj4g Pj4NCj4gPj4gICAgICAgICAgICAgSWYNCj4gPj4NCj4gPj4gICAgICAgICAgICAgICAgICAgICAg ICAgIGFueSBub2RlcyBpbiB0aGUgc2libGluZyBzZXQgYXJlIHNlbGVjdGVkLCB0aGVuDQo+ID4+ IHRoZSBwcm9jZXNzIGlzDQo+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICByZWN1cnNpdmVs eSBhcHBsaWVkIHRvIHRoZSBzaWJsaW5nIHNldHMgb2YgZWFjaA0KPiA+PiBzZWxlY3RlZCBub2Rl Lg0KPiA+Pg0KPiA+PiAgICAgICAgICAgICBUaGUNCj4gPj4NCj4gPj4gICAgICAgICAgICAgICAg ICAgICAgICAgIGFsZ29yaXRobSBjb250aW51ZXMgdW50aWwgYWxsIHNpYmxpbmcgc2V0cyBpbg0K PiA+PiBhbGwgc3VidHJlZXMNCj4gPj4NCj4gPj4gICAgICAgICAgICAgc3BlY2lmaWVkDQo+ID4+ DQo+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICBpbiB0aGUgZmlsdGVyIGhhdmUgYmVlbiBw cm9jZXNzZWQuIElmIGFueQ0KPiA+PiBzaWJsaW5nIG5vZGVzIG9mIGENCj4gPj4NCj4gPj4gICAg ICAgICAgICAgbm9kZQ0KPiA+Pg0KPiA+PiAgICAgICAgICAgICAgICAgICAgICAgICAgYXJlIGlu c3RhbmNlIGlkZW50aWZpZXIgY29tcG9uZW50cyBmb3IgYQ0KPiA+PiBjb25jZXB0dWFsIGRhdGEN Cj4gPj4NCj4gPj4gICAgICAgICAgICAgc3RydWN0dXJlDQo+ID4+DQo+ID4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAoZS5nLiwgbGlzdCBrZXkgbGVhZiksIHRoZW4gdGhleSBNVVNUIGJlDQo+ ID4+IGluY2x1ZGVkIGluIHRoZSBmaWx0ZXINCj4gPj4NCj4gPj4gICAgICAgICAgICAgICAgIG91 dHB1dC4NCj4gPj4NCj4gPj4gICAgICAgICAgICAgICAgICAgICBSZWdhcmRzLCBCZW5vaXQNCj4g Pj4NCj4gPj4NCj4gPj4gICAgICAgICAgICAgICAgICAgICBJIGFncmVlIHRoYXQgTVVTVCB3b3Vs ZCBiZSBiZXR0ZXIuIEJ1dCBJIGRvbid0IHRoaW5rDQo+ID4+IHdlIGNhbi9zaG91bGQNCj4gPj4g ICAgICAgICAgICAgICAgICAgICBkbyB0aGFyIGNoYW5nZSBpbiBhbiBlcnJhdGEuDQo+ID4+DQo+ ID4+ICAgICAgICAgICAgICAgICAgICAgT24gMjAganVuaSAyMDE0IDEzOjU3OjI0IFBEVCwgUmFu ZHkgUHJlc3Vobg0KPiA+Pg0KPiA+PiAgICAgICAgICAgICAgICAgPHJhbmR5X3ByZXN1aG5AbWlu ZHNwcmluZy5jb20gPG1haWx0bzpyYW5keV9wcmVzdWhuQA0KPiA+PiBtaW5kc3ByaW5nLmNvbT4+ DQo+ID4+DQo+ID4+ICAgICAgICAgICAgICAgICAgICAgd3JvdGU6DQo+ID4+DQo+ID4+DQo+ID4+ ICAgICAgICAgICAgICAgICAgICAgSGkgLQ0KPiA+Pg0KPiA+Pg0KPiA+PiAgICAgICAgICAgICAg ICAgICAgIEZyb206IEJlbm9pdCBDbGFpc2UgPGJjbGFpc2VAY2lzY28uY29tIDxtYWlsdG86DQo+ ID4+IGJjbGFpc2VAY2lzY28uY29tPj4NCj4gPj4gICAgICAgICAgICAgICAgICAgICBTZW50OiBK dW4gMjAsIDIwMTQgMjowMSBBTQ0KPiA+Pg0KPiA+Pg0KPiA+PiAgICAgICAgICAgICAgICAgICAg IC4uLg0KPiA+Pg0KPiA+Pg0KPiA+PiAgICAgICAgICAgICAgICAgICAgIFN1YmplY3Q6IFJlOiBb TmV0Y29uZl0gW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdDQo+ID4+IFJGQzYyNDEgKDM5ODAp DQo+ID4+DQo+ID4+ICAgICAgICAgICAgICAgICAgICAgT25lIGxhc3QgY2hlY2sgKHRpbGwgbWlk IG5leHQgd2VlaykgZm9yIGV2ZXJ5Ym9keSBpbg0KPiA+PiB0aGUgV0cgYmVmb3JlDQo+ID4+DQo+ ID4+ICAgICAgICAgICAgIEkNCj4gPj4NCj4gPj4gICAgICAgICAgICAgICAgICAgICBhcHBseSB0 aGlzIGNoYW5nZSBiZWxvdyB0byB0aGUgZXJyYXRhLCBhbmQgYWNjZXB0IGl0Lg0KPiA+Pg0KPiA+ Pg0KPiA+Pg0KPiA+PiAgICAgICAgICAgICAgICAgICAgICJTSE9VTEQiIGlzIG5vIGJldHRlciB0 aGFuICJNQVkiIG9yICJPUFRJT05BTCIgZnJvbSBhbg0KPiA+PiAgICAgICAgICAgICAgICAgICAg IGludGVyb3BlcmFiaWxpdHkgcGVyc3BlY3RpdmUuICAiTVVTVCIgd291bGQgYmUgbXVjaA0KPiA+ PiBzaW1wbGVyDQo+ID4+ICAgICAgICAgICAgICAgICAgICAgZm9yIGFsbCBjb25jZXJuZWQuDQo+ ID4+DQo+ID4+ICAgICAgICAgICAgICAgICAgICAgUmFuZHkNCj4gPj4NCj4gPj4gICAgICAgICAg ICAgICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4+ICAgICAgICAgICAgICAgICAgICAgTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPj4g ICAgICAgICAgICAgICAgICAgICBOZXRjb25mQGlldGYub3JnIDxtYWlsdG86TmV0Y29uZkBpZXRm Lm9yZz4NCj4gPj4gICAgICAgICAgICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL19fbGlzdGluZm8vbmV0Y29uZiA8DQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0Y29uZj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gICAgICAg ICAgICAgICAgICAgICAvbWFydGluDQo+ID4+ICAgICAgICAgICAgICAgICAgICAgLg0KPiA+Pg0K PiA+Pg0KPiA+PiAgICAgICAgICAgICAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gICAgICAgICAgICAgICAgICAgICBOZXRjb25m IG1haWxpbmcgbGlzdA0KPiA+PiAgICAgICAgICAgICAgICAgICAgIE5ldGNvbmZAaWV0Zi5vcmcg PG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KPiA+PiAgICAgICAgICAgICAgICAgICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vX19saXN0aW5mby9uZXRjb25mIDwNCj4gPj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPg0KPiA+Pg0KPiA+Pg0KPiA+ PiAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IF9f LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4gICAgICAgICAgICAgICAgIFpURSBJbmZv cm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbg0KPiA+PiBjb250YWluZWQg aW4gdGhpcw0KPiA+Pg0KPiA+PiAgICAgICAgICAgICBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQg dHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQNCj4gPj4gYW5kDQo+ID4+ICAgICAg ICAgICAgIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNl IG9mIHRoZQ0KPiA+PiBhZGRyZXNzZWUocykuDQo+ID4+ICAgICAgICAgICAgIElmIHlvdSBhcmUg bm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsDQo+ID4+IHJlcHJvZHVj dGlvbiwNCj4gPj4gICAgICAgICAgICAgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRp b24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbg0KPiA+PiBjb250YWluZWQNCj4gPj4gICAgICAg ICAgICAgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg bWFpbCBpbg0KPiA+PiBlcnJvciwNCj4gPj4gICAgICAgICAgICAgcGxlYXNlIGRlbGV0ZSBpdCBh bmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KPiA+Pg0KPiA+PiAgICAgICAgICAgICAgICAgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IF9fLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gPj4gICAgICAgICAgICAgICAgIFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3Rp Y2U6IFRoZSBpbmZvcm1hdGlvbg0KPiA+PiBjb250YWluZWQgaW4gdGhpcw0KPiA+Pg0KPiA+PiAg ICAgICAgICAgICBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgp IGlzIHByaXZpbGVnZWQNCj4gPj4gYW5kDQo+ID4+ICAgICAgICAgICAgIGNvbmZpZGVudGlhbCBh bmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZQ0KPiA+PiBhZGRyZXNz ZWUocykuDQo+ID4+ICAgICAgICAgICAgIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lw aWVudCwgYW55IGRpc2Nsb3N1cmUsDQo+ID4+IHJlcHJvZHVjdGlvbiwNCj4gPj4gICAgICAgICAg ICAgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZv cm1hdGlvbg0KPiA+PiBjb250YWluZWQNCj4gPj4gICAgICAgICAgICAgaXMgc3RyaWN0bHkgcHJv aGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbg0KPiA+PiBlcnJvciwN Cj4gPj4gICAgICAgICAgICAgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0 ZWx5Lg0KPiA+Pg0KPiA+PiAgICAgICAgICAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiAgICAgICAgICAgICAgICAgTmV0Y29uZiBt YWlsaW5nIGxpc3QNCj4gPj4gICAgICAgICAgICAgICAgIE5ldGNvbmZAaWV0Zi5vcmcgPG1haWx0 bzpOZXRjb25mQGlldGYub3JnPg0KPiA+PiAgICAgICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9fX2xpc3RpbmZvL25ldGNvbmYgPA0KPiA+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+ICAg ICAgICAgICAgIC0tDQo+ID4+ICAgICAgICAgICAgIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAg ICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+ID4+ICAgICAgICAgICAgIFBo b25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSwgMjg3NTkgQnJlbWVu LA0KPiA+PiBHZXJtYW55DQo+ID4+ICAgICAgICAgICAgIEZheDogICArNDkgNDIxIDIwMCAzMTAz ICAgICAgICAgPA0KPiA+PiBodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5Ll9fZGUvIDxodHRw Oi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4+DQo+ID4+DQo+ID4+ICAgICAgICAgICAgIF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gICAg ICAgICAgICAgTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPj4gICAgICAgICAgICAgTmV0Y29uZkBp ZXRmLm9yZyA8bWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmc+DQo+ID4+ICAgICAgICAgICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vX19saXN0aW5mby9uZXRjb25mIDwNCj4gPj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPg0KPiA+Pg0KPiA+Pg0KPiA+ Pg0KPiA+PiAgICAgICAgIC9tYXJ0aW4NCj4gPj4NCj4gPj4gICAgICAgICBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ICAgICAgICAgTmV0Y29u ZiBtYWlsaW5nIGxpc3QNCj4gPj4gICAgICAgICBOZXRjb25mQGlldGYub3JnIDxtYWlsdG86TmV0 Y29uZkBpZXRmLm9yZz4NCj4gPj4gICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L19fbGlzdGluZm8vbmV0Y29uZiA8DQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0Y29uZj4NCj4gPj4NCj4gPj4NCj4gPj4gICAgIF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gICAgIE5ldGNvbmYgbWFpbGlu ZyBsaXN0DQo+ID4+ICAgICBOZXRjb25mQGlldGYub3JnIDxtYWlsdG86TmV0Y29uZkBpZXRmLm9y Zz4NCj4gPj4gICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vX19saXN0aW5mby9uZXRj b25mIDwNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25m Pg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiBOZXRjb25mQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KDQo= From nobody Tue Jul 15 08:08:04 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B471B28BD for ; Tue, 15 Jul 2014 08:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 KtOJkiGGmyTI for ; Tue, 15 Jul 2014 08:07:39 -0700 (PDT) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E2321B28BB for ; Tue, 15 Jul 2014 08:07:34 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id q108so824604qgd.37 for ; Tue, 15 Jul 2014 08:07:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/3b10lckUcB0DSxABPaXIq5o+wfHdus+MVo4a/DPQME=; b=cjeifkYUjHldLBJxFOd67EMMVG6bEc9O7TcXAmLazDIVf4meQFhX4luJZNuD96pNeP KnZHCxdsGRukoqWGliuilWcsgXsE8c3ZIZnbM3ayitMHD8JhRtMlPKHFHy2XCkYYGhGf YNUCzkJHovuFp8IUM5qcAysTJi5ZpSmsY+2J4tO8bNoLMt5bF8lOqKc7naEE0bZZaXDd RKFpDrVghstpQ+bmsErLon0zzUgT3nrSxX6O+vvKKWID1Nn6Dg00KNQ5RR3dgQja88qv ztrpsUk0v8EcsMaImr2ZJxv+uSq60gkikctL6k6RmjkRIdZ9WyDInVfHK0LtNo6LMNoG kezQ== X-Gm-Message-State: ALoCoQmzxuLleOSpctNvjxbHV+cxuTFI25yx+6KnkQV8ZzTb+Auq27S1YPykErF06W51jpBikmdb MIME-Version: 1.0 X-Received: by 10.140.82.201 with SMTP id h67mr26310873qgd.94.1405436853542; Tue, 15 Jul 2014 08:07:33 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Tue, 15 Jul 2014 08:07:33 -0700 (PDT) In-Reply-To: <1405435684.19255.2.camel@ksekera-fedora> References: <30336078.1403297845090.JavaMail.root@mswamui-billy.atl.sa.earthlink.net> <53C3CF38.2070601@cisco.com> <20140715114200.GA398@elstar.local> <5f76f622-d93a-41e7-8115-2c4e11c2a245@email.android.com> <53C522F0.1030107@bwijnen.net> <53C537E0.3090105@bwijnen.net> <1405435684.19255.2.camel@ksekera-fedora> Date: Tue, 15 Jul 2014 08:07:33 -0700 Message-ID: From: Andy Bierman To: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" Content-Type: multipart/alternative; boundary=001a11c120bc68ffac04fe3cc419 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/gcAeZR6JeSF7BVaz4idlzZbvft8 Cc: "rob.enns@gmail.com" , "joelja@bogus.com" , "randy_presuhn@mindspring.com" , "netconf-bounces@ietf.org" , "netconf@ietf.org" Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3980) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 15:07:45 -0000 --001a11c120bc68ffac04fe3cc419 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 15, 2014 at 7:48 AM, Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco) wrote: > Hi Andy, > > just to clarify, your filter would select only the one disabled > interface even if you specified the there. All the other > instances would be dropped, since the content-match on is > false. > > you're right. been awhile since I implemented this section. I notice sec. 6.2.5 also has this text: o If any sibling nodes of the selection node are instance identifier components for a conceptual data structure (e.g., list key leaf), then they MAY also be included in the filter output. Andy > Klement > > On Tue, 2014-07-15 at 07:35 -0700, Andy Bierman wrote: > > On Tue, Jul 15, 2014 at 7:17 AM, Bert Wijnen (IETF) < > bertietf@bwijnen.net> > > wrote: > > > > > Well, I added text that explains that if a client wnts to be sure tha= t > it > > > better > > > asks for the leafs in its filter > > > > > > > > > The subtree filtering is much more useful if the server supplies missin= g > > keys. > > (I guess we agree on that). Consider a simple use-case: there are 10,0= 00 > > interface > > entries and 1 of them is disabled. Which one? > > > > > > > > false > > > > > > > > If I add the leaf to the filter, I will get back 10,000 matches. > > If I don't, then all I get back is the filter I sent, confirming there = is > > indeed 1 disabled interface. > > The only useful response is to include the leaf for the 1 entry > that > > matched. > > > > It seems like SHOULD is more appropriate than MAY. It does not force o= ld > > servers to > > be non-compliant like MUST. > > > > > > > Bert > > > > > > > Andy > > > > > > > > > > On 15/07/14 15:51, Andy Bierman wrote: > > > > > >> > > >> > > >> > > >> On Tue, Jul 15, 2014 at 5:47 AM, Bert Wijnen (IETF) < > bertietf@bwijnen.net > > >> > wrote: > > >> > > >> Or.... maybe use MAY and add that if the client wants to be sure > that > > >> such leafs are returned, then the client better asks for those > leaf > > >> explicitly > > >> in the filter. > > >> > > >> > > >> So what is the point of this errata? The client already MAY include > > >> whatever > > >> nodes it wants in the filter. IMO the new text adds no value and > > >> clarifies nothing. > > >> > > >> > > >> > > >> Bert > > >> > > >> > > >> Andy > > >> > > >> > > >> On 15/07/14 14:39, Martin Bj=C3=B6rklund wrote: > > >> > > >> I agree with Juergen. Thus, I think the new text should use > MAY > > >> instead of MUST. > > >> > > >> On 15 juli 2014 13:42:00 CEST, Juergen Schoenwaelder < > > >> j.schoenwaelder@jacobs-__university.de > > >> > wrote: > > >> > > >> But since the original spec did not say clearly such lea= fs > > >> must be > > >> included, I think the only safe bet for a client is to > > >> explicitely > > >> request key leafs in the filter - unless we are sure the > > >> _every_ > > >> implementation actually returns key leafs (and since > nobody > > >> knows the > > >> number of implementations around, establishing this fact > is > > >> hard). > > >> > > >> /js > > >> > > >> On Tue, Jul 15, 2014 at 08:58:14AM +0800, > > >> feng.chong33@zte.com.cn > > >> wrote: > > >> > > >> I agree instance identifier MUST be present in outpu= t. > > >> /frank > > >> > > >> > > >> "Netconf" > >> netconf-bounces@ietf.org>> =E5=86=99=E4=BA=8E 2014-07-14 20:38:16: > > >> > > >> Benoit Claise > >> bclaise@cisco.com>> > > >> =E5=8F=91=E4=BB=B6=E4=BA=BA: "Netconf" > >> netconf-bounces@ietf.org>> > > >> > > >> 2014-07-14 20:38 > > >> > > >> =E6=94=B6=E4=BB=B6=E4=BA=BA > > >> > > >> Martin Bj=C3=B6rklund > >> mbj@tail-f.com>>, Randy Presuhn > > >> randy_presuhn@ > > >> mindspring.com>>__, "Klement Sekera -X (ksekera - > > >> Pantheon Technologies SRO at Cisco)" < > > >> ksekera@cisco.com >, > > >> > > >> =E6=8A=84=E9=80=81 > > >> > > >> "rob.enns@gmail.com " > < > > >> rob.enns@gmail.com >, > > >> "joelja@bogus.com " > > >> >, " > > >> netconf@ietf.org " > >> > > > >> > > >> =E4=B8=BB=E9=A2=98 > > >> > > >> Re: [Netconf] [Technical Errata Reported] RFC624= 1 > > >> (3980) > > >> > > >> Dear all, > > >> > > >> Let me try to bring some closure on this errata > > >> http://www.rfc- > > >> editor.org/errata_search.php?__eid=3D3980 < > > >> http://editor.org/errata_search.php?eid=3D3980> > > >> Before proceeding (I want to check with the IESG > if > > >> this is allowed > > >> > > >> > > >> to introduce a new MUST sentence in an errata), = I > > >> would like to > > >> 1. check that text below is the final proposal > > >> 2. understand if there is agreement in the WG. D= o > > >> someone object > > >> > > >> this > > >> > > >> change? > > >> > > >> OLD: > > >> For each sibling set, the server determines > > >> which nodes are > > >> > > >> included > > >> > > >> (or potentially included) in the filter > output, > > >> and which > > >> > > >> sibling > > >> > > >> subtrees are excluded (pruned) from the > filter > > >> output. The > > >> > > >> server > > >> > > >> first determines which types of nodes are > > >> present in the sibling > > >> > > >> set > > >> > > >> and processes the nodes according to the > rules > > >> for their type. > > >> > > >> If > > >> > > >> any nodes in the sibling set are selected, > then > > >> the process is > > >> recursively applied to the sibling sets of > each > > >> selected node. > > >> > > >> The > > >> > > >> algorithm continues until all sibling sets = in > > >> all subtrees > > >> > > >> specified > > >> > > >> in the filter have been processed. > > >> > > >> NEW: > > >> For each sibling set, the server determines > > >> which nodes are > > >> > > >> included > > >> > > >> (or potentially included) in the filter > output, > > >> and which > > >> > > >> sibling > > >> > > >> subtrees are excluded (pruned) from the > filter > > >> output. The > > >> > > >> server > > >> > > >> first determines which types of nodes are > > >> present in the sibling > > >> > > >> set > > >> > > >> and processes the nodes according to the > rules > > >> for their type. > > >> > > >> If > > >> > > >> any nodes in the sibling set are selected, > then > > >> the process is > > >> recursively applied to the sibling sets of > each > > >> selected node. > > >> > > >> The > > >> > > >> algorithm continues until all sibling sets = in > > >> all subtrees > > >> > > >> specified > > >> > > >> in the filter have been processed. If any > > >> sibling nodes of a > > >> > > >> node > > >> > > >> are instance identifier components for a > > >> conceptual data > > >> > > >> structure > > >> > > >> (e.g., list key leaf), then they MUST be > > >> included in the filter > > >> > > >> output. > > >> > > >> Regards, Benoit > > >> > > >> > > >> I agree that MUST would be better. But I don't > think > > >> we can/should > > >> do thar change in an errata. > > >> > > >> On 20 juni 2014 13:57:24 PDT, Randy Presuhn > > >> > > >> > >> mindspring.com>> > > >> > > >> wrote: > > >> > > >> > > >> Hi - > > >> > > >> > > >> From: Benoit Claise > >> bclaise@cisco.com>> > > >> Sent: Jun 20, 2014 2:01 AM > > >> > > >> > > >> ... > > >> > > >> > > >> Subject: Re: [Netconf] [Technical Errata Reporte= d] > > >> RFC6241 (3980) > > >> > > >> One last check (till mid next week) for everybod= y > in > > >> the WG before > > >> > > >> I > > >> > > >> apply this change below to the errata, and accep= t > it. > > >> > > >> > > >> > > >> "SHOULD" is no better than "MAY" or "OPTIONAL" > from an > > >> interoperability perspective. "MUST" would be > much > > >> simpler > > >> for all concerned. > > >> > > >> Randy > > >> > > >> ________________________________________________= _ > > >> Netconf mailing list > > >> Netconf@ietf.org > > >> https://www.ietf.org/mailman/__listinfo/netconf = < > > >> https://www.ietf.org/mailman/listinfo/netconf> > > >> > > >> > > >> > > >> > > >> /martin > > >> . > > >> > > >> > > >> ________________________________________________= _ > > >> Netconf mailing list > > >> Netconf@ietf.org > > >> https://www.ietf.org/mailman/__listinfo/netconf = < > > >> https://www.ietf.org/mailman/listinfo/netconf> > > >> > > >> > > >> ------------------------------ > > >> __-------------------------- > > >> ZTE Information Security Notice: The information > > >> contained in this > > >> > > >> mail (and any attachment transmitted herewith) is > privileged > > >> and > > >> confidential and is intended for the exclusive use of th= e > > >> addressee(s). > > >> If you are not an intended recipient, any disclosure, > > >> reproduction, > > >> distribution or other dissemination or use of the > information > > >> contained > > >> is strictly prohibited. If you have received this mail = in > > >> error, > > >> please delete it and notify us immediately. > > >> > > >> ------------------------------ > > >> __-------------------------- > > >> ZTE Information Security Notice: The information > > >> contained in this > > >> > > >> mail (and any attachment transmitted herewith) is > privileged > > >> and > > >> confidential and is intended for the exclusive use of th= e > > >> addressee(s). > > >> If you are not an intended recipient, any disclosure, > > >> reproduction, > > >> distribution or other dissemination or use of the > information > > >> contained > > >> is strictly prohibited. If you have received this mail = in > > >> error, > > >> please delete it and notify us immediately. > > >> > > >> _________________________________________________ > > >> Netconf mailing list > > >> Netconf@ietf.org > > >> https://www.ietf.org/mailman/__listinfo/netconf < > > >> https://www.ietf.org/mailman/listinfo/netconf> > > >> > > >> > > >> > > >> -- > > >> Juergen Schoenwaelder Jacobs University Bremen > gGmbH > > >> Phone: +49 421 200 3587 Campus Ring 1, 28759 > Bremen, > > >> Germany > > >> Fax: +49 421 200 3103 < > > >> http://www.jacobs-university.__de/ >> > > >> > > >> _________________________________________________ > > >> Netconf mailing list > > >> Netconf@ietf.org > > >> https://www.ietf.org/mailman/__listinfo/netconf < > > >> https://www.ietf.org/mailman/listinfo/netconf> > > >> > > >> > > >> > > >> /martin > > >> > > >> _________________________________________________ > > >> Netconf mailing list > > >> Netconf@ietf.org > > >> https://www.ietf.org/mailman/__listinfo/netconf < > > >> https://www.ietf.org/mailman/listinfo/netconf> > > >> > > >> > > >> _________________________________________________ > > >> Netconf mailing list > > >> Netconf@ietf.org > > >> https://www.ietf.org/mailman/__listinfo/netconf < > > >> https://www.ietf.org/mailman/listinfo/netconf> > > >> > > >> > > >> > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > --001a11c120bc68ffac04fe3cc419 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Jul 15, 2014 at 7:48 AM, Klement Sekera -X (ksekera - Panth= eon Technologies SRO at Cisco) <ksekera@cisco.com> wrote:
Hi Andy,

just to clarify, your filter would select only the one disabled
interface even if you specified the <name> there. All the other
instances would be dropped, since the content-match on <enabled> is false.


you're right.

=
been awhile since I implemented this section.
I notice sec. = 6.2.5 also has this text:

   o  If any sibling nodes of the selection node are instance identifier
      components for a conceptual data structure (e.g., list key leaf),
      then they MAY also be included in the filter output.

Andy
=C2=A0
Klement

On Tue, 2014-07-15 at 07:35 -0700, Andy Bierman wrote:
> On Tue, Jul 15, 2014 at 7:17 AM, Bert Wijnen (IETF) <bertietf@bwijnen.net>
> wrote:
>
> > Well, I added text that explains that if a client wnts to be sure= that it
> > better
> > asks for the leafs in its filter
> >
>
>
> The subtree filtering is much more useful if the server supplies missi= ng
> keys.
> (I guess we agree on that). =C2=A0Consider a simple use-case: there ar= e 10,000
> interface
> entries and 1 of them is disabled. =C2=A0Which one?
>
> =C2=A0 =C2=A0<interfaces>
> =C2=A0 =C2=A0 =C2=A0 <interface>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<enabled>false</enabled>=
> =C2=A0 =C2=A0 =C2=A0 </interface>
> =C2=A0 =C2=A0</interfaces>
>
> If I add the <name> leaf to the filter, I will get back 10,000 m= atches.
> If I don't, then all I get back is the filter I sent, confirming t= here is
> indeed 1 disabled interface.
> The only useful response is to include the <name> leaf for the 1= entry that
> matched.
>
> It seems like SHOULD is more appropriate than MAY. =C2=A0It does not f= orce old
> servers to
> be non-compliant like MUST.
>
>
> > Bert
> >
>
> Andy
>
>
> >
> > On 15/07/14 15:51, Andy Bierman wrote:
> >
> >>
> >>
> >>
> >> On Tue, Jul 15, 2014 at 5:47 AM, Bert Wijnen (IETF) <bertietf@bwijnen.net
> >> <mailto:bertietf@b= wijnen.net>> wrote:
> >>
> >> =C2=A0 =C2=A0 Or.... maybe use MAY and add that if the client= wants to be sure that
> >> =C2=A0 =C2=A0 such leafs are returned, then the client better= asks for those leaf
> >> explicitly
> >> =C2=A0 =C2=A0 in the filter.
> >>
> >>
> >> So what is the point of this errata? =C2=A0The client already= MAY include
> >> whatever
> >> nodes it wants in the filter. IMO the new text adds no value = and
> >> clarifies nothing.
> >>
> >>
> >>
> >> =C2=A0 =C2=A0 Bert
> >>
> >>
> >> Andy
> >>
> >>
> >> =C2=A0 =C2=A0 On 15/07/14 14:39, Martin Bj=C3=B6rklund wrote:=
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 I agree with Juergen. Thus, I thi= nk the new text should use MAY
> >> instead of MUST.
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 On 15 juli 2014 13:42:00 CEST, Ju= ergen Schoenwaelder <
> >> j.s= choenwaelder@jacobs-__university.de
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:j.schoenwaelder@jacobs-university.de&= gt;> wrote:
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 But since the origi= nal spec did not say clearly such leafs
> >> must be
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 included, I think t= he only safe bet for a client is to
> >> explicitely
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 request key leafs i= n the filter - unless we are sure the
> >> _every_
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 implementation actu= ally returns key leafs (and since nobody
> >> knows the
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 number of implement= ations around, establishing this fact is
> >> hard).
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /js
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Tue, Jul 15, 201= 4 at 08:58:14AM +0800,
> >> feng.chong33@zte.c= om.cn <mailto:feng.chong3= 3@zte.com.cn>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 wrote:
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I agr= ee instance identifier MUST be present in output.
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /fran= k
> >>
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= ;Netconf" <netconf-boun= ces@ietf.org <mailto:
> >> netconf-bounces@i= etf.org>> =E5=86=99=E4=BA=8E 2014-07-14 20:38:16:
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Benoit Claise <bclaise@c= isco.com <mailto:
> >> bclaise@cisco.com>= ;>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =E5=8F=91=E4=BB=B6=E4=BA=BA: =C2=A0"Netconf" <netconf-bounces@ietf.org <mai= lto:
> >> netconf-bounces@i= etf.org>>
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 2014-07-14 20:38
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =E6=94=B6=E4=BB=B6=E4=BA=BA
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Martin Bj=C3=B6rklund <mbj@= tail-f.com <mailto:
> >> mbj@tail-f.com>>,= Randy Presuhn
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 <randy_presuh= n@mindspring.com <mailto:randy_pre= suhn@
> >> mindsprin= g.com>>__, "Klement Sekera -X (ksekera -
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Pantheon Technologies SRO at Cisco)" <
> >> ksekera@cisco.com &l= t;mailto:ksekera@cisco.com>>= ,
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =E6=8A=84=E9=80=81
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "rob.enns@gmail.com <mailto:rob.enns@gmail.com&= gt;" <
> >> rob.enns@gmail.com = <mailto:rob.enns@gmail.com>= >,
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "joelja@bogus.com &= lt;mailto:joelja@bogus.com>"= ;
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 <joelja@bogus.com <= ;mailto:joelja@bogus.com>>, &= quot;
> >> netconf@ietf.org <= mailto:netconf@ietf.org>" &= lt;netconf@ietf.org
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 <mailto:netconf@ietf.org<= /a>>>
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =E4=B8=BB=E9=A2=98
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Re: [Netconf] [Technical Errata Reported] RFC6241
> >> (3980)
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Dear all,
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Let me try to bring some closure on this errata
> >> http://www.rfc-=
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 editor.org/errata_search.php?__eid=3D3980 <
> >> http://editor.org/errata_search.php?eid=3D3980>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Before proceeding (I want to check with the IESG if
> >> this is allowed
> >>
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 to introduce a new MUST sentence in an errata), I
> >> would like to
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 1. check that text below is the final proposal
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 2. understand if there is agreement in the WG. Do
> >> someone object
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 chang= e?
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 OLD:
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For each sibling set, the server determines<= br> > >> which nodes are
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 included
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(or potentially included) in the filter outp= ut,
> >> and which
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sibling
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0subtrees are excluded (pruned) from the filt= er
> >> output. =C2=A0The
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 server
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0first determines which types of nodes are > >> present in the sibling
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 set
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and processes the nodes according to the rul= es
> >> for their type.
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0any nodes in the sibling set are selected, t= hen
> >> the process is
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0recursively applied to the sibling sets of e= ach
> >> selected node.
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm continues until all sibling sets i= n
> >> all subtrees
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 specified
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the filter have been processed.
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 NEW:
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For each sibling set, the server determines<= br> > >> which nodes are
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 included
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(or potentially included) in the filter outp= ut,
> >> and which
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sibling
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0subtrees are excluded (pruned) from the filt= er
> >> output. =C2=A0The
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 server
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0first determines which types of nodes are > >> present in the sibling
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 set
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and processes the nodes according to the rul= es
> >> for their type.
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0any nodes in the sibling set are selected, t= hen
> >> the process is
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0recursively applied to the sibling sets of e= ach
> >> selected node.
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm continues until all sibling sets i= n
> >> all subtrees
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 specified
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the filter have been processed. If any > >> sibling nodes of a
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 node
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0are instance identifier components for a
> >> conceptual data
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 structure
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(e.g., list key leaf), then they MUST be
> >> included in the filter
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 outpu= t.
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Regards, Benoit
> >>
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 I agree that MUST would be better. But I don't think
> >> we can/should
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 do thar change in an errata.
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 On 20 juni 2014 13:57:24 PDT, Randy Presuhn
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<= a href=3D"mailto:randy_presuhn@mindspring.com">randy_presuhn@mindspring.com= <mailto:randy_presuhn@
> >> mindsprin= g.com>>
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 wrote:
> >>
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Hi -
> >>
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 From: Benoit Claise <bcl= aise@cisco.com <mailto:
> >> bclaise@cisco.com>= ;>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Sent: Jun 20, 2014 2:01 AM
> >>
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ...
> >>
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Subject: Re: [Netconf] [Technical Errata Reported]
> >> RFC6241 (3980)
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 One last check (till mid next week) for everybody in
> >> the WG before
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 apply this change below to the errata, and accept it.
> >>
> >>
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "SHOULD" is no better than "MAY" or "OP= TIONAL" from an
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 interoperability perspective. =C2=A0"MUST" would be mu= ch
> >> simpler
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 for all concerned.
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Randy
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 _________________________________________________
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Netconf mailing list
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Netconf@ietf.org <mai= lto:Netconf@ietf.org>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 https://www.ietf.org/mailman/__listinfo/netconf <
> >> https://www.ietf.org/mailman/listinfo/netconf>
> >>
> >>
> >>
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 /martin
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 .
> >>
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 _________________________________________________
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Netconf mailing list
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Netconf@ietf.org <mai= lto:Netconf@ietf.org>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 https://www.ietf.org/mailman/__listinfo/netconf <
> >> https://www.ietf.org/mailman/listinfo/netconf>
> >>
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -----= -------------------------
> >> __--------------------------
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ZTE I= nformation Security Notice: The information
> >> contained in this
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mail (and any attac= hment transmitted herewith) is privileged
> >> and
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 confidential and is= intended for the exclusive use of the
> >> addressee(s).
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If you are not an i= ntended recipient, any disclosure,
> >> reproduction,
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 distribution or oth= er dissemination or use of the information
> >> contained
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is strictly prohibi= ted. =C2=A0If you have received this mail in
> >> error,
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 please delete it an= d notify us immediately.
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -----= -------------------------
> >> __--------------------------
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ZTE I= nformation Security Notice: The information
> >> contained in this
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mail (and any attac= hment transmitted herewith) is privileged
> >> and
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 confidential and is= intended for the exclusive use of the
> >> addressee(s).
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 If you are not an i= ntended recipient, any disclosure,
> >> reproduction,
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 distribution or oth= er dissemination or use of the information
> >> contained
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is strictly prohibi= ted. =C2=A0If you have received this mail in
> >> error,
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 please delete it an= d notify us immediately.
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _____= ____________________________________________
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Netco= nf mailing list
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Netconf@ietf.org <mailto:Netconf@ietf.org>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ht= tps://www.ietf.org/mailman/__listinfo/netconf <
> >> https://www.ietf.org/mailman/listinfo/netconf>
> >>
> >>
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Juergen Schoenwaeld= er =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jacobs University Bremen gGmbH
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: +49 421 200 = 3587 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Campus Ring 1, 28759 Bremen,
> >> Germany
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Fax: =C2=A0 +49 421= 200 3103 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <
> >> h= ttp://www.jacobs-university.__de/ <http://www.jacobs-university.de/>><= br> > >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ___________________= ______________________________
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Netconf mailing lis= t
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Netconf@ietf.org <mailto:Netconf@ietf.org>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf= .org/mailman/__listinfo/netconf <
> >> https://www.ietf.org/mailman/listinfo/netconf>
> >>
> >>
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 /martin
> >>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 _________________________________= ________________
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Netconf mailing list
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Netconf@ietf.org <mailto:Netc= onf@ietf.org>
> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/_= _listinfo/netconf <
> >> https://www.ietf.org/mailman/listinfo/netconf>
> >>
> >>
> >> =C2=A0 =C2=A0 _______________________________________________= __
> >> =C2=A0 =C2=A0 Netconf mailing list
> >> =C2=A0 =C2=A0 Netconf@iet= f.org <mailto:Netconf@ietf.org>
> >> =C2=A0 =C2=A0 https://www.ietf.org/mailman/__listinfo/netc= onf <
> >> https://www.ietf.org/mailman/listinfo/netconf>
> >>
> >>
> >>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


--001a11c120bc68ffac04fe3cc419-- From nobody Wed Jul 16 15:31:36 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1961A0379 for ; Wed, 16 Jul 2014 15:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 EXJnpNSy7r5u for ; Wed, 16 Jul 2014 15:31:33 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0242.outbound.protection.outlook.com [207.46.163.242]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D31D41A0378 for ; Wed, 16 Jul 2014 15:31:33 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.0.985.8; Wed, 16 Jul 2014 22:31:31 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) with mapi id 15.00.0985.008; Wed, 16 Jul 2014 22:31:31 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "netconf@ietf.org" Thread-Topic: [Netconf] netconf server listening endpoints Thread-Index: AQHPm1RUVAHQ0WPvJ0+8xBgkNhtQ8ZujEacA Date: Wed, 16 Jul 2014 22:31:30 +0000 Message-ID: References: <20140709090055.GA86512@elstar.local> In-Reply-To: <20140709090055.GA86512@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0274272F87 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(164054003)(95666004)(31966008)(99286002)(74662001)(101416001)(106116001)(36756003)(106356001)(105586002)(85852003)(81542001)(81342001)(74502001)(87936001)(92566001)(64706001)(83072002)(2656002)(92726001)(83322001)(46102001)(21056001)(77982001)(107046002)(107886001)(76482001)(79102001)(66066001)(20776003)(4396001)(86362001)(77096002)(76176999)(50986999)(83506001)(80022001)(54356999)(85306003)(99396002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/m7knmc4qND6UPgYCB3egevu6Hpc Subject: Re: [Netconf] netconf server listening endpoints X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 22:31:35 -0000 Hi Juergen, Just reviewing old mail and noticed this: > PS: The Tree Diagram text should explain the notation of features. The text describing tree diagram notation is in section 1.2, which does seem far removed from the sections depicting tree diagrams. What makes sense to me is to add a reference to section 1.2 from these sections - makes sense? Thanks, Kent From nobody Wed Jul 16 16:10:42 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 381051A013B for ; Wed, 16 Jul 2014 16:10:41 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 UEaBGCgeuI2g for ; Wed, 16 Jul 2014 16:10:39 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 279821A039A for ; Wed, 16 Jul 2014 16:10:32 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.0.985.8; Wed, 16 Jul 2014 23:10:29 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) with mapi id 15.00.0985.008; Wed, 16 Jul 2014 23:10:29 +0000 From: Kent Watsen To: Juergen Schoenwaelder Thread-Topic: [Netconf] netconf server cert/psk mapping Thread-Index: AQHPm12mkAYWpqsl7UCnV8/AL8BEUpuYSZ0AgAD2x4CACdwTAA== Date: Wed, 16 Jul 2014 23:10:28 +0000 Message-ID: References: <20140709100740.GA86767@elstar.local> <20140710123625.GC90023@elstar.local> In-Reply-To: <20140710123625.GC90023@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0274272F87 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(51704005)(479174003)(377454003)(24454002)(199002)(189002)(164054003)(551544002)(95666004)(31966008)(99286002)(74662001)(101416001)(106116001)(36756003)(106356001)(105586002)(85852003)(81542001)(81342001)(74502001)(87936001)(92566001)(64706001)(83072002)(2656002)(92726001)(83322001)(46102001)(21056001)(77982001)(15202345003)(107046002)(76482001)(79102001)(66066001)(20776003)(15975445006)(110136001)(86362001)(4396001)(77096002)(76176999)(50986999)(19580405001)(19580395003)(83506001)(80022001)(54356999)(99396002)(85306003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <5B712858B0EB764FB5B3EBBC2D8FC491@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/xR4xLa1lXfE2OtsJdLPW6QoZ0JI Cc: "netconf@ietf.org" Subject: Re: [Netconf] netconf server cert/psk mapping X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 23:10:41 -0000 The augmentation is made to /system/authentication (not /system/authentication/user). The maps are currently to username strings, with no assertion of them being related to the /system/authentication/user accounts. So this is a "service" account, as you put it, which seems right to me. Agreed? That said, if they are service account mappings, specifically for the NETCONF service, then we probably want it configured in ietf-netconf-server, not ietf-system as it is now. Agreed? Thanks, Kent On 7/10/14, 8:36 AM, "Juergen Schoenwaelder" wrote: >On Thu, Jul 10, 2014 at 02:11:08AM +0000, Kent Watsen wrote: >>=20 >> Hi Juergen, >>=20 >> I think you're referring to >> http://tools.ietf.org/html/draft-ietf-netconf-server-model-01#section-5 > >Yes. >=20 >> Defining it globally came about because of Radek's comments here: >> http://www.ietf.org/mail-archive/web/netconf/current/msg08836.html > >Yes, I have seen that exchange. > >> And the choice to use an augmentation made here: >> http://www.ietf.org/mail-archive/web/netmod/current/msg09828.html >>=20 >> Does it still not seem right? > >Yes, I likely have issues with this. My understanding of the >/system/authentication/user list is that it essentially tells me >something about user accounts on a system and how to manage the >associated passwords and SSH keys with the goal to make typical SSH >access work. And typical SSH access maps the incoming connection into >a context of a local system user account. This makes sense since >access to remote system accounts was the prime reason for creating SSH >in the first place. > >When we talk about other services, then the notion of a service >account is often detached from the notion of system accounts. Lets >take SNMP as an example: The SNMP users usually only exist within the >SNMP agent, they typically do not map to a local system user account. >The same is true for many HTTP based services. To configure say a >webdav share, you typically create a user with a password that purely >exists in the webdav implementation and does typically not map to a >local system user account. > >The difference between these approaches is not only significant from >the implementation background but also from the point of the name >spaces. In typical implementations, my SNMP user name space is >distinct from my webdav user name space, which is again distinct from >my local system user account name space. > >I guess one of the not clearly answered open questions is which model >NC over TLS (and RESTCONF over TLS) should follow - the 'user name >space is scoped to a service' model or the 'user name maps to a local >system user account' model. > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 From nobody Thu Jul 17 02:43:12 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004A01A033D for ; Thu, 17 Jul 2014 02:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=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 i5Y9Sh79pH8q for ; Thu, 17 Jul 2014 02:43:10 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F271A1A0322 for ; Thu, 17 Jul 2014 02:43:09 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4DF3C1259; Thu, 17 Jul 2014 11:43:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id qz-Ho5cHTkBT; Thu, 17 Jul 2014 11:42:51 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 17 Jul 2014 11:43:07 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C2EE02002C; Thu, 17 Jul 2014 11:43:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NO9MG_5p4AlN; Thu, 17 Jul 2014 11:43:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A9ACB20017; Thu, 17 Jul 2014 11:43:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4555D2DD956A; Thu, 17 Jul 2014 11:43:06 +0200 (CEST) Date: Thu, 17 Jul 2014 11:43:06 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20140717094305.GA4796@elstar.local> Mail-Followup-To: Kent Watsen , "netconf@ietf.org" References: <20140709090055.GA86512@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ei1fO4GY_BDVGgEtvo8bF2pIA5A Cc: "netconf@ietf.org" Subject: Re: [Netconf] netconf server listening endpoints X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 09:43:11 -0000 On Wed, Jul 16, 2014 at 10:31:30PM +0000, Kent Watsen wrote: > > Hi Juergen, > > > Just reviewing old mail and noticed this: > > > PS: The Tree Diagram text should explain the notation of features. > > > The text describing tree diagram notation is in section 1.2, which does > seem far removed from the sections depicting tree diagrams. What makes > sense to me is to add a reference to section 1.2 from these sections - > makes sense? Perhaps it helps but in any case, this does not resolve the issue that the feature notation (e.g., {ssh-call-home}?) is not defined in the text in section 1.2. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Jul 17 02:44:10 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC4A1A035D for ; Thu, 17 Jul 2014 02:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=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 yCgN_t08yTv6 for ; Thu, 17 Jul 2014 02:44:06 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C6E81A0322 for ; Thu, 17 Jul 2014 02:44:06 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EE23C1167; Thu, 17 Jul 2014 11:44:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id PWrBc6Lp6fxo; Thu, 17 Jul 2014 11:43:48 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 17 Jul 2014 11:44:04 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 724582002F; Thu, 17 Jul 2014 11:44:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ivx7w00vtCGU; Thu, 17 Jul 2014 11:44:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 95B542002C; Thu, 17 Jul 2014 11:44:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E22CA2DD9584; Thu, 17 Jul 2014 11:44:03 +0200 (CEST) Date: Thu, 17 Jul 2014 11:44:03 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20140717094403.GB4796@elstar.local> Mail-Followup-To: Kent Watsen , "netconf@ietf.org" References: <20140709100740.GA86767@elstar.local> <20140710123625.GC90023@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/5hQNvTWQNhSvI5OKcmw53_WmTYQ Cc: "netconf@ietf.org" Subject: Re: [Netconf] netconf server cert/psk mapping X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 09:44:07 -0000 On Wed, Jul 16, 2014 at 11:10:28PM +0000, Kent Watsen wrote: > > > > The augmentation is made to /system/authentication (not > /system/authentication/user). The maps are currently to username strings, > with no assertion of them being related to the /system/authentication/user > accounts. So this is a "service" account, as you put it, which seems > right to me. Agreed? no > That said, if they are service account mappings, specifically for the > NETCONF service, then we probably want it configured in > ietf-netconf-server, not ietf-system as it is now. Agreed? yes /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Jul 17 09:08:36 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E451A0301 for ; Thu, 17 Jul 2014 09:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 3BcDAqMQ0BEY for ; Thu, 17 Jul 2014 09:08:14 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0205.outbound.protection.outlook.com [207.46.163.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F1691B279C for ; Thu, 17 Jul 2014 09:08:14 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.0.985.8; Thu, 17 Jul 2014 16:08:11 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) with mapi id 15.00.0985.008; Thu, 17 Jul 2014 16:08:11 +0000 From: Kent Watsen To: Juergen Schoenwaelder Thread-Topic: [Netconf] netconf server cert/psk mapping Thread-Index: AQHPm12mkAYWpqsl7UCnV8/AL8BEUpuYSZ0AgAD2x4CACdwTAIAA9BaAgAAoQ4A= Date: Thu, 17 Jul 2014 16:08:11 +0000 Message-ID: References: <20140709100740.GA86767@elstar.local> <20140710123625.GC90023@elstar.local> <20140717094403.GB4796@elstar.local> In-Reply-To: <20140717094403.GB4796@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(24454002)(51704005)(479174003)(377454003)(199002)(189002)(83072002)(86362001)(85852003)(2656002)(85306003)(4396001)(31966008)(92566001)(92726001)(74662001)(36756003)(93886003)(74502001)(101416001)(83506001)(87936001)(105586002)(79102001)(110136001)(19580405001)(83322001)(95666004)(19580395003)(76482001)(46102001)(99286002)(106356001)(106116001)(81542001)(77096002)(54356999)(99396002)(66066001)(64706001)(107046002)(50986999)(21056001)(77982001)(81342001)(76176999)(20776003)(80022001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <07C3E9DF852B7440A6C9E837D4E2AB72@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/2i2IAsL52fw1pnemVo1Teh3j0QE Cc: "netconf@ietf.org" Subject: Re: [Netconf] netconf server cert/psk mapping X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 16:08:19 -0000 On 7/17/14, 5:44 AM, "Juergen Schoenwaelder" wrote: >On Wed, Jul 16, 2014 at 11:10:28PM +0000, Kent Watsen wrote: >>=20 >>=20 >>=20 >> The augmentation is made to /system/authentication (not >> /system/authentication/user). The maps are currently to username >>strings, >> with no assertion of them being related to the >>/system/authentication/user >> accounts. So this is a "service" account, as you put it, which seems >> right to me. Agreed? > >No No what? - you don't think they are service accounts? - please explain. From nobody Thu Jul 17 09:16:30 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C6B1A07AB for ; Thu, 17 Jul 2014 09:16: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 vaMAFmTd6puy for ; Thu, 17 Jul 2014 09:16:03 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 777221A0033 for ; Thu, 17 Jul 2014 09:16:03 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.0.985.8; Thu, 17 Jul 2014 16:16:01 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.27]) with mapi id 15.00.0985.008; Thu, 17 Jul 2014 16:16:01 +0000 From: Kent Watsen To: Juergen Schoenwaelder Thread-Topic: [Netconf] netconf server listening endpoints Thread-Index: AQHPm1RUVAHQ0WPvJ0+8xBgkNhtQ8ZujEacAgAD+tQCAACq2AA== Date: Thu, 17 Jul 2014 16:16:00 +0000 Message-ID: References: <20140709090055.GA86512@elstar.local> <20140717094305.GA4796@elstar.local> In-Reply-To: <20140717094305.GA4796@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(164054003)(86362001)(50986999)(4396001)(110136001)(20776003)(79102001)(66066001)(77096002)(85306003)(80022001)(99396002)(54356999)(76176999)(105586002)(83506001)(36756003)(106116001)(31966008)(99286002)(101416001)(74662001)(95666004)(64706001)(83322001)(77982001)(21056001)(81342001)(87936001)(83072002)(106356001)(2656002)(107046002)(76482001)(92726001)(81542001)(85852003)(92566001)(46102001)(74502001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/thACh7D4-lGdprKetyXhDIcJMhk Cc: "netconf@ietf.org" Subject: Re: [Netconf] netconf server listening endpoints X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 16:16:08 -0000 >Perhaps it helps but in any case, this does not resolve the issue that >the feature notation (e.g., {ssh-call-home}?) is not defined in the >text in section 1.2. I had copy/pasted this text out of another current draft, I'd assumed it was correct. Is there a definitive boilerplate that should be used? Looking at `pyang`, I get: $ pyang --tree-help Each node is printed as: is one of: + for current x for deprecated o for obsolete is one of: rw for configuration data ro for non-configuration data -x for rpcs -n for notifications is the name of the node () means that the node is a choice node :() means that the node is a case node If the node is augmented into the tree from another module, its name is printed as :. is one of: ? for an optional leaf or choice ! for a presence container * for a leaf-list or list [] for a list's keys is the name of the type for leafs and leaf-lists is the list of features this node depends on, printed within curly brackets and a question mark "{...}?" This seems OK to me. Alternatively, maybe we should formally define tree notation in a RFC?=20 Thanks, Kent From nobody Thu Jul 17 09:54:32 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C48B1A0181 for ; Thu, 17 Jul 2014 09:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 smTVEefgFXPr for ; Thu, 17 Jul 2014 09:53:59 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32FCF1A001E for ; Thu, 17 Jul 2014 09:53:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQMAAT/x1PGmAcV/2dsb2JhbABZgkcjJFJYA4VUpz0BAQEBAQEGgxyTF4dCAYEHFnaEBQEBAxIbXgEMCRVWJgEEGxqIIAEMnwKEXaFlF4V7iR+DZoEYBZxrhXGMb4NEgjE X-IronPort-AV: E=Sophos; i="5.01,679,1400040000"; d="scan'208,217"; a="74279171" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Jul 2014 12:53:58 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 17 Jul 2014 12:53:58 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Thu, 17 Jul 2014 18:53:56 +0200 From: "Romascanu, Dan (Dan)" To: "netconf@ietf.org" Thread-Topic: protocol proposals for LMAP Thread-Index: Ac+h37FIyCC2nnEdTRqifxN0s8VRcw== Date: Thu, 17 Jul 2014 16:53:55 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C845AD0@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C845AD0AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/mRhvzHCdDWK2YO_wgW1VYmPye1Q Subject: [Netconf] protocol proposals for LMAP X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 16:54:00 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C845AD0AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The LMAP working group http://datatracker.ietf.org/wg/lmap/charter/ has rec= ently submitted a use case document to the IESG and makes progress towards = the completion and submission of the LMAP framework and information model I= -Ds. It is now time to submit proposals for the LMAP protocols (the charter= talks about a Control Protocol and a Report Protocol). In the initial phas= es of the LMAP discussions NETCONF was mentioned as one of the candidates. = Does anybody plan to write an Internet-Draft to propose NETCONF (or maybe R= ESTCONF?) as a candidate protocol in LMAP? Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C845AD0AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The LMAP working group http://datatracker.ietf.org/wg/lmap/charter/ has recently submitted a u= se case document to the IESG and makes progress towards the completion and = submission of the LMAP framework and information model I-Ds. It is now time= to submit proposals for the LMAP protocols (the charter talks about a Control Protocol and a Report Protoco= l). In the initial phases of the LMAP discussions NETCONF was mentioned as = one of the candidates. Does anybody plan to write an Internet-Draft to prop= ose NETCONF (or maybe RESTCONF?) as a candidate protocol in LMAP?

 

Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C845AD0AZFFEXMB04globa_-- From nobody Thu Jul 17 11:56:08 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16871A000F for ; Thu, 17 Jul 2014 11:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=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 Kh3WTD0_a0sb for ; Thu, 17 Jul 2014 11:52:03 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447BA1A0002 for ; Thu, 17 Jul 2014 11:52:03 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D903F1281; Thu, 17 Jul 2014 20:52:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Vl2zqlCLPB0i; Thu, 17 Jul 2014 20:51:59 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 17 Jul 2014 20:52:00 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C853D2002C; Thu, 17 Jul 2014 20:52:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XFZYAOJdRZ3S; Thu, 17 Jul 2014 20:52:00 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F229B20017; Thu, 17 Jul 2014 20:51:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4A2A52DDB55D; Thu, 17 Jul 2014 20:51:58 +0200 (CEST) Date: Thu, 17 Jul 2014 20:51:57 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20140717185156.GC30594@elstar.local> Mail-Followup-To: Kent Watsen , "netconf@ietf.org" References: <20140709090055.GA86512@elstar.local> <20140717094305.GA4796@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/nIH36L13tSabi96qSuUf8irDbz0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] netconf server listening endpoints X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 18:52:04 -0000 On Thu, Jul 17, 2014 at 04:16:00PM +0000, Kent Watsen wrote: > > > > >Perhaps it helps but in any case, this does not resolve the issue that > >the feature notation (e.g., {ssh-call-home}?) is not defined in the > >text in section 1.2. > > > I had copy/pasted this text out of another current draft, I'd assumed it > was correct. It might be correct in that context (if the tree diagrams do not show features). > Is there a definitive boilerplate that should be used? Nope. > Looking at `pyang`, I get: But not good boilerplate. > This seems OK to me. Alternatively, maybe we should formally define > tree notation in a RFC? Not sure for 'formally' means but yes the boilerplate can be revised (and perhaps Andy can edit a common complete version of the boilerplate into the guidelines document). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Jul 17 11:56:22 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8811A0073 for ; Thu, 17 Jul 2014 11:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=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 ocgDoa2Ij0AN for ; Thu, 17 Jul 2014 11:53:51 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E8D31A000F for ; Thu, 17 Jul 2014 11:53:51 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EDC091281; Thu, 17 Jul 2014 20:53:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id A82G-PDjaaRQ; Thu, 17 Jul 2014 20:53:47 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 17 Jul 2014 20:53:48 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8DA992002C; Thu, 17 Jul 2014 20:53:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1zEveGt-QEY3; Thu, 17 Jul 2014 20:53:48 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C214420017; Thu, 17 Jul 2014 20:53:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A86C62DDB599; Thu, 17 Jul 2014 20:53:47 +0200 (CEST) Date: Thu, 17 Jul 2014 20:53:47 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20140717185347.GD30594@elstar.local> Mail-Followup-To: Kent Watsen , "netconf@ietf.org" References: <20140709100740.GA86767@elstar.local> <20140710123625.GC90023@elstar.local> <20140717094403.GB4796@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/GwIPCUxJuc5VgIzC8WaCEjobFuI Cc: "netconf@ietf.org" Subject: Re: [Netconf] netconf server cert/psk mapping X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 18:53:52 -0000 On Thu, Jul 17, 2014 at 04:08:11PM +0000, Kent Watsen wrote: > > > On 7/17/14, 5:44 AM, "Juergen Schoenwaelder" > wrote: > > >On Wed, Jul 16, 2014 at 11:10:28PM +0000, Kent Watsen wrote: > >> > >> > >> > >> The augmentation is made to /system/authentication (not > >> /system/authentication/user). The maps are currently to username > >>strings, > >> with no assertion of them being related to the > >>/system/authentication/user > >> accounts. So this is a "service" account, as you put it, which seems > >> right to me. Agreed? > > > >No > > No what? - you don't think they are service accounts? - please explain. > No to 'service accounts are under /syste/authentication with no other qualifier. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Jul 21 11:33:55 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DC91A0350 for ; Mon, 21 Jul 2014 11:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 HXxvdFXW67p9 for ; Mon, 21 Jul 2014 11:33:52 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD8D1A006C for ; Mon, 21 Jul 2014 11:33:51 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id f12so5541292qad.31 for ; Mon, 21 Jul 2014 11:33:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=pKgQYFrwaQn9ognhpB3a5pqTVdMMTrF77J8gec3Uxcc=; b=H0J6tEzw2LrqjFD4XAnGfhAO2qbW2hx0ximb1Q9BvC5x7jZD4um8gabaf8EyiSxS9J HTApGeBPJi/1VCL5dLnjjhwuLVFP89X7QiyV2xz6/HpY+EG9GAwAAmzo4rlk2qJUD1QU pMeRxaJQKHKoVqshSVb/uxnI2Xq5rmbAv0dgKFv6SG9hBLgPL8WszDzS+t8zsn/crhtD mWJaRje651mowxD92jf27/vgg4iia2Oq3PLWrK6SueviCoZnuo/WMmQKcLZ+0WRW2Jea Gvxxi4YtXWVSZ5ESr4IPZcE3rdvgswUWA+Jbvok7r9YxrTVsT1mlZLJxZoMBDys05f7W FD4A== X-Gm-Message-State: ALoCoQlaiGsasWUgQeaagE8zXb+1J9HfwpTmU0eXAu4s/Y94gZ+66sxh+C9tGHs/VRfpKoP2F/AT MIME-Version: 1.0 X-Received: by 10.140.94.138 with SMTP id g10mr41417391qge.90.1405967630321; Mon, 21 Jul 2014 11:33:50 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Mon, 21 Jul 2014 11:33:50 -0700 (PDT) Date: Mon, 21 Jul 2014 11:33:50 -0700 Message-ID: From: Andy Bierman To: Netconf , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a113a4eda2c4e6104feb85949 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/bUsrBxArCdKK0L-8Tjqy4QN5AQ8 Subject: [Netconf] NETCONF/YANG tutorial for SNMP Developers X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 18:33:53 -0000 --001a113a4eda2c4e6104feb85949 Content-Type: text/plain; charset=ISO-8859-1 FYI, There is a new NETCONF tutorial available online in case people want to learn more about NETCONF/YANG. It assumes a little SNMP knowledge but should be readable even if you don't know about SNMP or SMIv2. http://dld.netconfcentral.org/doc/ncorg_netconf_yang_tutorial.pdf Andy --001a113a4eda2c4e6104feb85949 Content-Type: text/html; charset=ISO-8859-1
FYI,

There is a new NETCONF tutorial available online in case
people want to learn more about NETCONF/YANG.
It assumes a little SNMP knowledge but should be readable
even if you don't know about SNMP or SMIv2.





Andy


--001a113a4eda2c4e6104feb85949-- From nobody Mon Jul 21 12:59:53 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262131A03E1; Mon, 21 Jul 2014 12:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 Vw1M3EAC6FNd; Mon, 21 Jul 2014 12:59:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 71EA11A03AA; Mon, 21 Jul 2014 12:59:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140721195948.11317.76822.idtracker@ietfa.amsl.com> Date: Mon, 21 Jul 2014 12:59:48 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/z4_05uI7lkDgzno0vtpc9Xkdigk Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 19:59:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF Call Home using SSH Author : Kent Watsen Filename : draft-ietf-netconf-reverse-ssh-06.txt Pages : 11 Date : 2014-07-21 Abstract: This document presents a technique for a NETCONF server to request that a NETCONF client initiates a SSH connection to the NETCONF server, a technique referred to as 'call home'. Call home is needed to support deployments where the NETCONF client is otherwise unable to initiate a SSH connection to the NETCONF server directly. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-reverse-ssh/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-reverse-ssh-06 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 Mon Jul 21 13:16:24 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DB01A0263 for ; Mon, 21 Jul 2014 13:16:23 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 X-4-g51ltvWw for ; Mon, 21 Jul 2014 13:16:22 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F9C1A0328 for ; Mon, 21 Jul 2014 13:16:21 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.0.990.7; Mon, 21 Jul 2014 20:16:19 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.190]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.190]) with mapi id 15.00.0990.007; Mon, 21 Jul 2014 20:16:18 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-06.txt Thread-Index: AQHPpR5ZxUeC2NkKRkWfGoFEggCQPJuqs/SA Date: Mon, 21 Jul 2014 20:16:18 +0000 Message-ID: References: <20140721195948.11317.76822.idtracker@ietfa.amsl.com> In-Reply-To: <20140721195948.11317.76822.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0279B3DD0D x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(479174003)(377454003)(24454002)(164054003)(51704005)(40224003)(199002)(377424004)(189002)(21056001)(76176999)(83072002)(107886001)(92726001)(92566001)(54356999)(4396001)(105586002)(36756003)(106356001)(79102001)(2656002)(95666004)(85852003)(87936001)(107046002)(2351001)(110136001)(106116001)(50986999)(101416001)(81542001)(86362001)(31966008)(74502001)(81342001)(80022001)(15202345003)(77982001)(85306003)(74662001)(66066001)(64706001)(20776003)(83322001)(99396002)(76482001)(19580395003)(83506001)(46102001)(15975445006)(77096002)(19580405001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/R-4h9Z0s4X_1mrp-jvg3xAisKHU Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-06.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 20:16:23 -0000 I discussed posting this last-minute update with the NETCONF chairs before. It's not a big change, the diffs show best, but the changes include: * Changed title to "NETCONF Call Home using SSH" [This sounds better, esp. when considering other transports] * Changed "MUST" to "SHOULD" in the Applicability Statement. [this addresses Andy and Benoit's comments from London] * Revised the Abstract and Introduction to better explain what the document regards. [now better targets use-case being addressed] * Added a "Draft Naming" section explaining why, despite its name, reversing SSH is nowhere in the text [this section can be deleted when/if draft promoted to RFC] * Added PGP keys as another kind of SSH host key encoding identity and signed by a trust anchor. [to underscore that X.509 isn't the only solution avail] * Revised the Device Considerations section to more clearly explain why a device configuration data model is out of scope, and hence an Informative reference. * Clarified Security Considerations section on use of serial numbers. Thanks, Kent On 7/21/14, 3:59 PM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Network Configuration Working Group of >the IETF. > > Title : NETCONF Call Home using SSH > Author : Kent Watsen > Filename : draft-ietf-netconf-reverse-ssh-06.txt > Pages : 11 > Date : 2014-07-21 > >Abstract: > This document presents a technique for a NETCONF server to request > that a NETCONF client initiates a SSH connection to the NETCONF > server, a technique referred to as 'call home'. Call home is needed > to support deployments where the NETCONF client is otherwise unable > to initiate a SSH connection to the NETCONF server directly. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-netconf-reverse-ssh/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh-06 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-reverse-ssh-06 > > >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/ > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Jul 22 10:42:30 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7541B2AFC for ; Tue, 22 Jul 2014 10:42:29 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 JUqiO3798OFg for ; Tue, 22 Jul 2014 10:42:27 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0C21A01B0 for ; Tue, 22 Jul 2014 10:42:26 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.0.990.7; Tue, 22 Jul 2014 17:42:24 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.190]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.190]) with mapi id 15.00.0990.007; Tue, 22 Jul 2014 17:42:23 +0000 From: Kent Watsen To: Mark Nottingham Thread-Topic: [Netconf] RESTCONF and draft-ietf-appsawg-uri-get-off-my-lawn-04 (on the IESG telechat this week) Thread-Index: AQHPbjTesrzdWmo2rkmRPyjc5i2Otps9kRSAgAAaUoCAAO5HgIAARg6AgAIsroCAAHbbgIBrBdYA Date: Tue, 22 Jul 2014 17:42:23 +0000 Message-ID: References: <53714FEC.2030709@cisco.com> <53743F8F.2050308@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02801ACE41 x-forefront-antispam-report: SFV:NSPM; SFS:(52604005)(377454003)(16813002)(189002)(199002)(24454002)(43784003)(17383004)(164054003)(85852003)(54356999)(92566001)(99396002)(21056001)(105586002)(77982001)(83072002)(76176999)(81342001)(107046002)(74502001)(74662001)(79102001)(76482001)(93886003)(83506001)(81542001)(101416001)(95666004)(92726001)(106356001)(50986999)(99286002)(77096002)(19617315012)(110136001)(86362001)(19580405001)(15975445006)(80022001)(85306003)(19580395003)(83322001)(66066001)(20776003)(36756003)(64706001)(87936001)(106116001)(31966008)(16236675004)(4396001)(2656002)(46102001)(15202345003)(166863002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_CFF419367AFEFkwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/G0Z5UpBJJF0yxxUtrElrTGgH0U4 Cc: NETCONF Subject: Re: [Netconf] RESTCONF and draft-ietf-appsawg-uri-get-off-my-lawn-04 (on the IESG telechat this week) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 17:42:29 -0000 --_000_CFF419367AFEFkwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mark, Thank you for meeting with Andy, Bert, and myself yesterday. We're happy = that you support our use of /.well-known/host-meta as described here: http:= //tools.ietf.org/html/draft-ietf-netconf-restconf-01#section-3.2. Thank = you also for suggesting the draft advise clients to cache the result using = standard HTTP caching, we'll be sure to update the accordingly. Thanks again, Kent From: Kent Watsen > Date: Thursday, May 15, 2014 at 11:21 AM To: Benoit Claise >, Andy Bierm= an > Cc: Mark Nottingham >, 'Barry Leiba' >, NetConf > Subject: Re: [Netconf] RESTCONF and draft-ietf-appsawg-uri-get-off-my-lawn-= 04 (on the IESG telechat this week) Hi Mark, thanks for looking in on this! Currently RESTCONF hardcodes the top-level URL path "/restconf", which isn'= t in line with your BCP. Our thoughts are to put in text like that below= . Looking at rfc6570, I don't see how URI templates would help here. Can = you suggest a better way? - or were you thinking that we could use URI Tem= plates to define the structure of the RESTCONF API's URLs? Thanks, Kent =3D=3D=3D=3D=3DSTART=3D=3D=3D=3D=3D RESTCONF Path Resolution In line the best practices defined by "get-off-my-lawn", RESTCONF enables deployments to specify where the RESTCONF API is located. When first connecting to a RESTCONF server, a RESTCONF client MUST determine the root of the RESTCONF API. The client discovers this by getting the ".well-known/host-meta" resource [RFC6415] as follows: Request ------- GET /.well-known/host-meta users HTTP/1.1 Host: example.com Accept: application/xrd+xml Response -------- HTTP/1.1 200 OK Content-Type: application/xrd+xml Content-Length: nnn Once discovering the RESTCONF API root, the client MUST prepend it to any access to a RESTCONF resource. For instance, using the "/api/restco= nf" path discovered above, the client can now determine the version of RESTCONF protocol as follows: Request ------- GET /api/restconf/version HTTP/1.1 Host: example.com Accept: application/yang.api+json Response -------- HTTP/1.1 200 OK Date: Mon, 23 Apr 2012 17:01:00 GMT Server: example-server Cache-Control: no-cache Pragma: no-cache Last-Modified: Sun, 22 Apr 2012 01:00:14 GMT Content-Type: application/yang.api+json { "version": "1.0" } =3D=3D=3D=3D=3D STOP =3D=3D=3D=3D=3D From: Benoit Claise > Date: Thursday, May 15, 2014 at 12:16 AM To: Andy Bierman >, Kent Wats= en > Cc: NetConf >, 'Barry Leiba' >, Mark Nottingham > Subject: Re: [Netconf] RESTCONF and draft-ietf-appsawg-uri-get-off-my-lawn-= 04 (on the IESG telechat this week) Dear all, Discussing this issue with Barry: Yes, .well-known is a possible solution for netconf/restconf. Another poss= ibility is URI templates. The get-off-my-lawn document talks about both. = For restconf, Mark Nottingham could help advise which would be a better opt= ion for them. Regards, Benoit On Tue, May 13, 2014 at 11:53 AM, Kent Watsen > wrote: Andy writes: I think RESTCONF violates sec 2.3 wrt/ structure within the URI path. I agree with Andy that RESTCONF violates section 2.3. I also think that we= can remove that violation by supporting "well-known" URIs. Notice that th= e 2nd paragraph in section 2.3 says "The only exception to this requirement= is registered 'well-known' URIs, as specified by [RFC5785]." My reading = is, if we use a "well-known" URI, then our subtree can defined sub-structur= e per RESTCONF convention. We discussed using well-known URIs before. Appendix B.3. in the RESTCONF = draft ("Open Issues") regards ".well-known usage". This issue was closed w= ith the resolution "not needed in RESTCONF". We may need to revisit that = decision now. I agree we need to support .well-known to conform to this BCP. Thanks, Kent Andy --_000_CFF419367AFEFkwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Mark,

Thank you for meeting with Andy, Bert, and myself yesterday.   We= 're happy that you support our use of /.well-known/host-meta as described h= ere: http://tools.ietf.org/html/draft-ietf-netconf-restconf-01#= section-3.2.    Thank you also for suggesting the draft advise clients to cac= he the result using standard HTTP caching, we'll be sure to update the acco= rdingly.

Thanks again,
Kent


From: Kent Watsen <kwatsen@juniper.net>
Date: Thursday, May 15, 2014 at 11:= 21 AM
To: Benoit Claise <bclaise@cisco.com>, Andy Bierman <andy@yumaworks.com>
Cc: Mark Nottingham <mnot@mnot.net>, 'Barry Leiba' <barryleiba@computer.org>, NetConf <= ;netconf@ietf.org>
Subject: Re: [Netconf] RESTCONF and= draft-ietf-appsawg-uri-get-off-my-lawn-04 (on the IESG telechat this week)=


Hi Mark, thanks for looking in on this!

Currently RESTCONF hardcodes the top-level URL path "/restconf", = which isn't in line with your BCP.    Our thoughts are to put in = text like that below.  Looking at rfc6570, I don't see how URI templat= es would help here.  Can you suggest a better way?  - or were you thinking that we could use URI Templates to define the structure = of the RESTCONF API's URLs?

Thanks,
Kent

=3D=3D=3D=3D=3DSTART=3D=3D=3D=3D=3D

RESTCONF Path Resolution

   In line the best practices defined by "get-off-my-lawn&qu= ot;, RESTCONF
   enables deployments to specify where the RESTCONF API is locat= ed.
   When first connecting to a RESTCONF server, a RESTCONF cl= ient MUST
   determine the root of the RESTCONF API.  The client disco= vers this
   by getting the ".well-known/host-meta" resource [RFC= 6415] as follows:

       Request
       -------
       GET /.wel= l-known/host-meta users HTTP/1.1
       Host: exa= mple.com
       Accept: a= pplication/xrd+xml

       Response<= /font>
       --------<= /font>
       HTTP/1.1 = 200 OK
       Content-T= ype: application/xrd+xml
       Content-L= ength: nnn

          &= nbsp;<Link rel=3D'restconf' href=3D'/api/restconf'/>
       </XRD&= gt;


   Once discovering the RE= STCONF API root, the client MUST prepend it to
   any access to a RESTCON= F resource.  For instance, using the "/api/restconf"<= /div>
   path discovered above, = the client can now determine the version of 
   RESTCONF protocol as fo= llows:

       Request
       -------
       GET /api/= restconf/version  HTTP/1.1
       Host: exa= mple.com
       Accept: a= pplication/yang.api+json

       Response<= /font>
       --------<= /font>
       HTTP/1.1 = 200 OK
       Date: Mon= , 23 Apr 2012 17:01:00 GMT
       Server: e= xample-server
       Cache-Con= trol: no-cache
       Pragma: n= o-cache
       Last-Modi= fied: Sun, 22 Apr 2012 01:00:14 GMT
       Content-T= ype: application/yang.api+json

       { "v= ersion": "1.0" }


=3D=3D=3D=3D=3D STOP =3D=3D=3D=3D=3D



From: Benoit Claise <bclaise@cisco.com>
Date: Thursday, May 15, 2014 at 12:= 16 AM
To: Andy Bierman <andy@yumaworks.com>, Kent Watsen <kwatsen@juniper.net>
Cc: NetConf <netconf@ietf.org>, 'Barry Leiba' <barryleiba@computer.org>, Mark Nottingh= am <mnot@mnot.net>
Subject: Re: [Netconf] RESTCONF and= draft-ietf-appsawg-uri-get-off-my-lawn-04 (on the IESG telechat this week)=

Dear all,

Discussing this issue with Barry:
Yes, .well-known is a possible solution for netconf/restconf. &= nbsp;Another possibility is URI templates.  The get-off-my-lawn docume= nt talks about both.  For restconf, Mark Nottingham could help advise = which would be a better option for them.
Regards, Benoit


On Tue, May 13, 2014 at 11:53 AM, Kent Watsen <kwatsen@juniper.net> wrote:

Andy writes:
I think RESTCONF violates sec 2.3 wrt/ structure within the URI path.<= /div>
<snip/>

I agree with Andy that RESTCONF violates section 2.3.  I also thi= nk that we can remove that violation by supporting "well-known" U= RIs.  Notice that the 2nd paragraph in section 2.3 says "The only= exception to this requirement is registered 'well-known' URIs, as specified by [RFC5785]."   My reading is, if we use a &= quot;well-known" URI, then our subtree can defined sub-structure per R= ESTCONF convention.

We discussed using well-known URIs before.   Appendix B.3. in the= RESTCONF draft ("Open Issues") regards ".well-known usage&q= uot;.  This issue was closed with the resolution "not needed in R= ESTCONF".   We may need to revisit that decision now.


I agree we need to support .well-known to conform to this BCP.
 
Thanks,
Kent


Andy


--_000_CFF419367AFEFkwatsenjunipernet_-- From nobody Tue Jul 22 11:52:08 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1BC81B2BC5; Tue, 22 Jul 2014 11:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 vyTvOtAUiIZu; Tue, 22 Jul 2014 11:52:03 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE3021A034F; Tue, 22 Jul 2014 11:52:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcGAPGxzlPGmAcV/2dsb2JhbABVA4JHIyRSVwSCdKt1AQEBAQEHl3MBChgBCYdFARl6FnaEAwEBAQEDAQEBDxEKQQsQAgEIDQQDAQEBCxYBBgMCAgIfBgsUBwEBBQMCBAENBQgGFIgMAxEBDJ4oikeQEg2GahMEhXuGIYECgUsRAR8WCgEQBgERgmc2gRgFjkWDfYFFhRwBiUOGV4Ycg0ZsgQw5 X-IronPort-AV: E=Sophos;i="5.01,711,1400040000"; d="txt'?scan'208,217";a="75092925" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Jul 2014 14:52:00 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 22 Jul 2014 14:51:56 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Tue, 22 Jul 2014 20:51:55 +0200 From: "Romascanu, Dan (Dan)" To: "opsawg@ietf.org" , "netconf@ietf.org" Thread-Topic: [ieee-ietf-coord] Liaison from IEEE 802.1 - Deterministic Networking Thread-Index: AQHPpcAEs3WTsuh1fkOm4WBZZ56LlZuscC2A Date: Tue, 22 Jul 2014 18:51:55 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C84E752@AZ-FFEXMB04.global.avaya.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/mixed; boundary="_004_9904FB1B0159DA42B0B887B7FA8119CA5C84E752AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/wU5mGCkdgc25FWGEA22PGT9Y9cw Cc: "Norman Finn \(nfinn\) \(nfinn@cisco.com\)" Subject: [Netconf] FW: [ieee-ietf-coord] Liaison from IEEE 802.1 - Deterministic Networking X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 18:52:06 -0000 --_004_9904FB1B0159DA42B0B887B7FA8119CA5C84E752AZFFEXMB04globa_ Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C84E752AZFFEXMB04globa_" --_000_9904FB1B0159DA42B0B887B7FA8119CA5C84E752AZFFEXMB04globa_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9yd2FyZGluZyB0byBmb2xrcyBpbiBORVRDT05GIGFuZCB0aGUgT1BTIGFyZWEuDQoNClJlZ2Fy ZHMsDQoNCkRhbg0KDQoNCkZyb206IGllZWUtaWV0Zi1jb29yZCBbbWFpbHRvOmllZWUtaWV0Zi1j b29yZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTm9ybWFuIEZpbm4gKG5maW5uKQ0K U2VudDogVHVlc2RheSwgSnVseSAyMiwgMjAxNCA2OjE3IFBNDQpUbzogR2xlbm4gUGFyc29uczsg aWVlZS1pZXRmLWNvb3JkQGlldGYub3JnOyBSaWNoYXJkIEJhcm5lczsgQWxpc3NhIENvb3Blcjsg QWxpYSBBdGxhczsgQWRyaWFuIEZhcnJlbDsgSnVsaWVuIE1ldXJpYzsgSlAgVmFzc2V1cjsgQWx2 YXJvIFJldGFuYSAoYXJldGFuYSk7IEplZmYgVGFudHN1cmE7IEJyaWFuIEhhYmVybWFuOyB0ZWQu bGVtb25Abm9taW51bS5jb207IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCk7IHdhdHRleW5lQGVl Y3MuYmVya2VsZXkuZWR1OyBLYXJlbiBPJ0Rvbm9naHVlOyBZYWFrb3YgU3RlaW47IFNwZW5jZXIg RGF3a2luczsgbWxzLmlldGZAZ21haWwuY29tOyBEYXZpZCBCbGFjazsgR29ycnkgRmFpcmh1cnN0 OyBKYW1lcyBQb2xrIChqbXBvbGspOyBCZW5vaXQgQ2xhaXNlIChiY2xhaXNlKTsgSm9lbCBKYWVn Z2xpOyBNZWhtZXQgRXJzdWU7IEJlcnQgV2lqbmVuDQpDYzogc3RhdGVtZW50c0BpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtpZWVlLWlldGYtY29vcmRdIExpYWlzb24gZnJvbSBJRUVFIDgwMi4xIC0g RGV0ZXJtaW5pc3RpYyBOZXR3b3JraW5nDQoNCkkgb3JnYW5pemVkIHRoaXMgbWVldGluZyAocmVx dWVzdGVkIHRoZSByb29tLCBldGMuKSAgVGhlcmUgd2lsbCBiZSBhIDwgMjAtc2xpZGUgaW50cm9k dWN0aW9uLCB0aGVuIGEgZnJlZS1mb3ItYWxsIGRpc2N1c3Npb24uICBJIGFwcHJlY2lhdGUgdGhh dCB0aGlzIGlzIGEgcmVxdWVzdCBmb3IgYSB0aW1lIGNvbW1pdG1lbnQgZnJvbSBzb21lIHZlcnkg YnVzeSBwZW9wbGUuICBJbiB0aGF0IHZlaW4sIHRoZSBpbnZpdGVlcyBzaG91bGQgZmVlbCBmcmVl IHRvIGRlbGVnYXRlIHRoZWlyIGF0dGVuZGFuY2UgdG8gcGFydGllcyB3aG8gbWF5IGhhdmUgYSBw YXJ0aWN1bGFyIGludGVyZXN0Lg0KDQpJ4oCZbSBhdHRlbmRpbmcgbWVldGluZ3MgYWxsIHdlZWsu ICBGZWVsIGZyZWUgdG8gdHh0IG1lIGF0IDEtOTI1LTk4MC02NDMwIHdpdGggcXVlc3Rpb25zIG9y IGNvbXBsYWludHMuICBFbWFpbCBtYXkgd29yaywgYWxzby4NCg0K4oCUIE5vcm0gRmlubg0KDQpG cm9tOiBHbGVubiBQYXJzb25zIDxnbGVubi5wYXJzb25zQGVyaWNzc29uLmNvbTxtYWlsdG86Z2xl bm4ucGFyc29uc0Blcmljc3Nvbi5jb20+Pg0KRGF0ZTogVHVlc2RheSwgSnVseSAyMiwgMjAxNCBh dCAwNDowNCBBTQ0KVG86ICJpZWVlLWlldGYtY29vcmRAaWV0Zi5vcmc8bWFpbHRvOmllZWUtaWV0 Zi1jb29yZEBpZXRmLm9yZz4iIDxpZWVlLWlldGYtY29vcmRAaWV0Zi5vcmc8bWFpbHRvOmllZWUt aWV0Zi1jb29yZEBpZXRmLm9yZz4+LCBSaWNoYXJkIEJhcm5lcyA8cmxiQGlwdi5zeDxtYWlsdG86 cmxiQGlwdi5zeD4+LCBBbGlzc2EgQ29vcGVyIDxhbGlzc2FAY29vcGVydy5pbjxtYWlsdG86YWxp c3NhQGNvb3BlcncuaW4+PiwgQWxpYSBBdGxhcyA8YWthdGxhc0BnbWFpbC5jb208bWFpbHRvOmFr YXRsYXNAZ21haWwuY29tPj4sIEFkcmlhbiBGYXJyZWwgPGFkcmlhbkBvbGRkb2cuY28udWs8bWFp bHRvOmFkcmlhbkBvbGRkb2cuY28udWs+PiwgSnVsaWVuIE1ldXJpYyA8anVsaWVuLm1ldXJpY0Bv cmFuZ2UuY29tPG1haWx0bzpqdWxpZW4ubWV1cmljQG9yYW5nZS5jb20+PiwgSlAgVmFzc2V1ciA8 anB2QGNpc2NvLmNvbTxtYWlsdG86anB2QGNpc2NvLmNvbT4+LCAiQWx2YXJvIFJldGFuYSAoYXJl dGFuYSkiIDxhcmV0YW5hQGNpc2NvLmNvbTxtYWlsdG86YXJldGFuYUBjaXNjby5jb20+PiwgSmVm ZiBUYW50c3VyYSA8amVmZi50YW50c3VyYUBlcmljc3Nvbi5jb208bWFpbHRvOmplZmYudGFudHN1 cmFAZXJpY3Nzb24uY29tPj4sIEJyaWFuIEhhYmVybWFuIDxicmlhbkBpbm5vdmF0aW9uc2xhYi5u ZXQ8bWFpbHRvOmJyaWFuQGlubm92YXRpb25zbGFiLm5ldD4+LCAidGVkLmxlbW9uQG5vbWludW0u Y29tPG1haWx0bzp0ZWQubGVtb25Abm9taW51bS5jb20+IiA8dGVkLmxlbW9uQG5vbWludW0uY29t PG1haWx0bzp0ZWQubGVtb25Abm9taW51bS5jb20+PiwgUGFzY2FsIFRodWJlcnQgPHB0aHViZXJ0 QGNpc2NvLmNvbTxtYWlsdG86cHRodWJlcnRAY2lzY28uY29tPj4sICJ3YXR0ZXluZUBlZWNzLmJl cmtlbGV5LmVkdTxtYWlsdG86d2F0dGV5bmVAZWVjcy5iZXJrZWxleS5lZHU+IiA8d2F0dGV5bmVA ZWVjcy5iZXJrZWxleS5lZHU8bWFpbHRvOndhdHRleW5lQGVlY3MuYmVya2VsZXkuZWR1Pj4sIEth cmVuIE8nRG9ub2dodWUgPG9kb25vZ2h1ZUBpc29jLm9yZzxtYWlsdG86b2Rvbm9naHVlQGlzb2Mu b3JnPj4sIFlhYWtvdiBTdGVpbiA8eWFha292X3NAcmFkLmNvbTxtYWlsdG86eWFha292X3NAcmFk LmNvbT4+LCBTcGVuY2VyIERhd2tpbnMgPHNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tPG1h aWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbT4+LCAibWxzLmlldGZAZ21haWwuY29t PG1haWx0bzptbHMuaWV0ZkBnbWFpbC5jb20+IiA8bWxzLmlldGZAZ21haWwuY29tPG1haWx0bzpt bHMuaWV0ZkBnbWFpbC5jb20+PiwgRGF2aWQgQmxhY2sgPGRhdmlkLmJsYWNrQGVtYy5jb208bWFp bHRvOmRhdmlkLmJsYWNrQGVtYy5jb20+PiwgR29ycnkgRmFpcmh1cnN0IDxnb3JyeUBlcmcuYWJk bi5hYy51azxtYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWs+PiwgIkphbWVzIFBvbGsgKGptcG9s aykiIDxqbXBvbGtAY2lzY28uY29tPG1haWx0bzpqbXBvbGtAY2lzY28uY29tPj4sICJCZW5vaXQg Q2xhaXNlIChiY2xhaXNlKSIgPGJjbGFpc2VAY2lzY28uY29tPG1haWx0bzpiY2xhaXNlQGNpc2Nv LmNvbT4+LCBKb2VsIEphZWdnbGkgPGpvZWxqYUBib2d1cy5jb208bWFpbHRvOmpvZWxqYUBib2d1 cy5jb20+PiwgTWVobWV0IEVyc3VlIDxtZWhtZXQuZXJzdWVAbnNuLmNvbTxtYWlsdG86bWVobWV0 LmVyc3VlQG5zbi5jb20+PiwgQmVydCBXaWpuZW4gPGJlcnRpZXRmQGJ3aWpuZW4ubmV0PG1haWx0 bzpiZXJ0aWV0ZkBid2lqbmVuLm5ldD4+DQpDYzogInN0YXRlbWVudHNAaWV0Zi5vcmc8bWFpbHRv OnN0YXRlbWVudHNAaWV0Zi5vcmc+IiA8c3RhdGVtZW50c0BpZXRmLm9yZzxtYWlsdG86c3RhdGVt ZW50c0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBbaWVlZS1pZXRmLWNvb3JkXSBMaWFpc29uIGZyb20g SUVFRSA4MDIuMSAtIERldGVybWluaXN0aWMgTmV0d29ya2luZw0KDQpUbzoNCg0KUmljaGFyZCBC YXJuZXMgPHJsYkBpcHYuc3g8bWFpbHRvOnJsYkBpcHYuc3g+PjsgQWxpc3NhIENvb3BlciA8YWxp c3NhQGNvb3BlcncuaW48bWFpbHRvOmFsaXNzYUBjb29wZXJ3LmluPj47DQpSZWFsLXRpbWUgQXBw bGljYXRpb25zIGFuZCBJbmZyYXN0cnVjdHVyZSBBcmVhIERpcmVjdG9ycw0KDQpBbGlhIEF0bGFz IDxha2F0bGFzQGdtYWlsLmNvbTxtYWlsdG86YWthdGxhc0BnbWFpbC5jb20+PjsgQWRyaWFuIEZh cnJlbCA8YWRyaWFuQG9sZGRvZy5jby51azxtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51az4+Ow0K Um91dGluZyBBcmVhIERpcmVjdG9ycw0KDQpKdWxpZW4gTWV1cmljIDxqdWxpZW4ubWV1cmljQG9y YW5nZS5jb208bWFpbHRvOmp1bGllbi5tZXVyaWNAb3JhbmdlLmNvbT4+OyBKUCBWYXNzZXVyIDxq cHZAY2lzY28uY29tPG1haWx0bzpqcHZAY2lzY28uY29tPj47DQpQYXRoIENvbnRyb2wgRWxlbWVu dCBXRyBjaGFpcnMNCg0KQWx2YXJvIFJldGFuYSAoYXJldGFuYSkgPGFyZXRhbmFAY2lzY28uY29t PG1haWx0bzphcmV0YW5hQGNpc2NvLmNvbT4+OyBKZWZmIFRhbnRzdXJhDQo8amVmZi50YW50c3Vy YUBlcmljc3Nvbi5jb208bWFpbHRvOmplZmYudGFudHN1cmFAZXJpY3Nzb24uY29tPj47IFJvdXRp bmcgQXJlYSBXRyBjaGFpcnMNCg0KQnJpYW4gSGFiZXJtYW4gPGJyaWFuQGlubm92YXRpb25zbGFi Lm5ldDxtYWlsdG86YnJpYW5AaW5ub3ZhdGlvbnNsYWIubmV0Pj47IFRlZCBMZW1vbg0KPHRlZC5s ZW1vbkBub21pbnVtLmNvbTxtYWlsdG86dGVkLmxlbW9uQG5vbWludW0uY29tPj47IEludGVybmV0 IEFyZWEgRGlyZWN0b3JzDQoNClBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgPHB0aHViZXJ0QGNp c2NvLmNvbTxtYWlsdG86cHRodWJlcnRAY2lzY28uY29tPj47IFRob21hcyBXYXR0ZXluZQ0KPHdh dHRleW5lQGVlY3MuYmVya2VsZXkuZWR1PG1haWx0bzp3YXR0ZXluZUBlZWNzLmJlcmtlbGV5LmVk dT4+OyBJUHY2IG92ZXIgVFNDSCBXRyBjaGFpcnMNCg0KUmF5IEJlbGxpcyA8cmF5LmJlbGxpc0Bu b21pbmV0Lm9yZy51azxtYWlsdG86cmF5LmJlbGxpc0Bub21pbmV0Lm9yZy51az4+OyBNYXJrIFRv d25zbGV5IDxtYXJrQHRvd25zbGV5Lm5ldDxtYWlsdG86bWFya0B0b3duc2xleS5uZXQ+PjsNCkhv bWUgTmV0d29ya2luZyBXRyBjaGFpcnMNCg0KS2FyZW4gTydEb25vZ2h1ZSA8b2Rvbm9naHVlQGlz b2Mub3JnPG1haWx0bzpvZG9ub2dodWVAaXNvYy5vcmc+PjsgWWFha292IFN0ZWluIDx5YWFrb3Zf c0ByYWQuY29tPG1haWx0bzp5YWFrb3Zfc0ByYWQuY29tPj47DQpUaWN0b2MgV0cgY2hhaXJzDQoN ClNwZW5jZXIgRGF3a2lucyA8c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnNw ZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tPj47IE1hcnRpbiBTdGllbWVybGluZw0KPG1scy5p ZXRmQGdtYWlsLmNvbTxtYWlsdG86bWxzLmlldGZAZ21haWwuY29tPj47IFRyYW5zcG9ydCBBcmVh IERpcmVjdG9ycw0KDQpEYXZpZCBCbGFjayA8ZGF2aWQuYmxhY2tAZW1jLmNvbTxtYWlsdG86ZGF2 aWQuYmxhY2tAZW1jLmNvbT4+OyBHb3JyeSBGYWlyaHVyc3QgPGdvcnJ5QGVyZy5hYmRuLmFjLnVr PG1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51az4+Ow0KSmFtZXMgUG9sayAoam1wb2xrKSA8am1w b2xrQGNpc2NvLmNvbTxtYWlsdG86am1wb2xrQGNpc2NvLmNvbT4+OyBUcmFuc3BvcnQgQXJlYSBX RyBjaGFpcnMNCg0KQmVub2l0IENsYWlzZSA8YmNsYWlzZUBjaXNjby5jb208bWFpbHRvOmJjbGFp c2VAY2lzY28uY29tPj47IEpvZWwgSmFlZ2dsaSA8am9lbGphQGJvZ3VzLmNvbTxtYWlsdG86am9l bGphQGJvZ3VzLmNvbT4+Ow0KT3BlcmF0aW9uIGFuZCBNYW5hZ2VtZW50IEFyZWEgRGlyZWN0b3Jz DQoNCk1laG1ldCBFcnN1ZSA8bWVobWV0LmVyc3VlQG5zbi5jb208bWFpbHRvOm1laG1ldC5lcnN1 ZUBuc24uY29tPj47IEJlcnQgV2lqbmVuIDxiZXJ0aWV0ZkBid2lqbmVuLm5ldDxtYWlsdG86YmVy dGlldGZAYndpam5lbi5uZXQ+Pg0KTmV0d29yayBDb25maWd1cmF0aW9uIFdHIGNoYWlycw0KDQpB dCA4OjAwIFBNIG9uIFdlZG5lc2RheSwgSnVseSAyMywgYXQgSUVURjkwIGluIFRvcm9udG8sIHRo ZXJlIHdpbGwgYmUgYQ0Kc2lkZSBtZWV0aW5nIChha2EgQmFyIEJPRiDigJQgc2VlIFJGQzY3NzEp IG9uIHRoZSBzdWJqZWN0IG9mIERldGVybWluaXN0aWMNCk5ldHdvcmtpbmcgaW4gdGhlIFF1ZWJl YyByb29tLiAgSUVFRSA4MDIuMSB3aXNoZXMgdG8gZW5jb3VyYWdlIHlvdXINCmNvb3BlcmF0aW9u IGFuZC9vciBwYXJ0aWNpcGF0aW9uLg0KDQpPdmVyIHRoZSBwYXN0IGZldyB5ZWFycywgdGhlIElF RUUgODAyIEF1ZGlvIFZpZGVvIEJyaWRnaW5nIFRhc2sgR3JvdXAgYW5kDQppdCBzdWNjZXNzb3Is IHRoZSBUaW1lLVNlbnNpdGl2ZSBOZXR3b3JraW5nIFRHLCBoYXZlIHJlbGVhc2VkIHN0YW5kYXJk cw0KdGhhdCBkZWZpbmU6DQoNCjEuIFByb3RvY29scyBmb3IgdGhlIHJlc2VydmF0aW9uLCBieSBl bmQgc3RhdGlvbnMsIG9mIExheWVyIDIgbmV0d29yaw0KcmVzb3VyY2VzIGZvciBjcml0aWNhbCBm bG93czsNCjIuIFNwZWNpZmljIGRhdGEgcGxhbmUgbWVjaGFuaXNtcyBmb3IgYSBMYXllciAyIG5l dHdvcmsgdG8gZ3VhcmFudGVlIDANCmNvbmdlc3Rpb24gbG9zcywgYW5kIGNvbnNlcXVlbnRseSwg YSBrbm93biBmaW5pdGUgZW5kLXRvLWVuZCBsYXRlbmN5LCBmb3INCnRob3NlIHJlc2VydmVkIGZs b3dzOyBhbmQNCjMuIFBsdWctYW5kLXBsYXkgZGlzdHJpYnV0aW9uIG9mIHRoZSBQcmVjaXNpb24g VGltZSBQcm90b2NvbCAoSUVFRSAxNTg4DQpQVFApIG92ZXIgYnJpZGdlZCwgcm91dGVkLCBvciBt aXhlZCBuZXR3b3Jrcy4NCg0KVGhlc2Ugc3RhbmRhcmRzIHdlcmUgb3JpZ2luYWxseSB0YXJnZXRl ZCBmb3IgdGhlIHRyYW5zcG9ydCBvZiByYXcgYXVkaW8NCmFuZCB2aWRlbyBzdHJlYW1zLiAgVGhl IHN1Y2Nlc3NmdWwgZGVwbG95bWVudCBvZiBtdWx0aS12ZW5kb3IgbmV0d29ya3MNCmVtcGxveWlu ZyB0aGVzZSBzdGFuZGFyZHMgaGFzIHRyaWdnZXJlZCBpbnRlcmVzdCBmcm9tIG5ldyBtYXJrZXQg c2VnbWVudHMsDQppbmNsdWRpbmcgaW5kdXN0cmlhbCwgdmVoaWN1bGFyLCBhbmQgb3RoZXIgcmVh bC10aW1lIHN5c3RlbXMuICBBcyBhDQpjb25zZXF1ZW5jZSwgdGhlIElFRUUgODAyLjEgVGltZS1T ZW5zaXRpdmUgTmV0d29ya2luZyBUYXNrIEdyb3VwIGhhcw0KbnVtYmVyIG9mIHByb2plY3RzIGlu IHByb2dyZXNzIHRvIGV4cGFuZCB0aGUgZmlyc3Qtcm91bmQgY2FwYWJpbGl0aWVzLg0KDQpUaGlz IHN1Y2Nlc3MgaGFzIGFsc28gbWFkZSBjbGVhciB0aGF0IHRoZSB1c2VycyBvZiB0aGVzZSBjYXBh YmlsaXRpZXMgaGF2ZQ0KbmV0d29ya2luZyBuZWVkcyB0aGF0IHRyYW5zY2VuZCB0aGUgbGltaXRh dGlvbnMgaW1wb3NlZCBieSBuZXR3b3JrcyB0aGF0DQpvcGVyYXRlIGF0IG9ubHkgTGF5ZXIgMi4g IFRoZSBmb2xsb3dpbmcgZWxlbWVudHMgYXJlIGVzc2VudGlhbCB0byBleHBhbmQNCnRoZSBjdXJy ZW50IFRpbWUtU2Vuc2l0aXZlIE5ldHdvcmtpbmcgVEfigJlzIHN0YW5kYXJkcyBpbnRvIOKAnERl dGVybWluaXN0aWMNCk5ldHdvcmtpbmfigJ06DQoNCkEuIERldGVybWluaXN0aWMgTmV0d29ya2lu ZyBoYXMgdG8gYmUgYSBRb1MgZmVhdHVyZSBvZiBzdGFuZGFyZCBuZXR3b3JrcywNCm5vdCBhIHNl dCBvZiBwb2ludCBmZWF0dXJlcyBhcm91bmQgd2hpY2ggb25lIGNvdWxkIHdyaXRlIGFuIEFwcGxp Y2F0aW9uLg0KQi4gVGhlIG5ldHdvcmtzIG9mIGludGVyZXN0IGNvbnRhaW4gYSBtaXh0dXJlIG9m IGJyaWRnZXMgYW5kIHJvdXRlcnMuICBUaGUNClFvUyBmZWF0dXJlcyBoYXZlIHRvIGJlIHN1cHBv cnRlZCByZWdhcmRsZXNzIG9mIExheWVyIDIgLyBMYXllciAzDQpib3VuZGFyaWVzLiAgVGhlIGNv bnRyb2wgcHJvdG9jb2xzIG11c3QgYmUgdmlzaWJsZSB0byBib3RoIHJvdXRlcnMgYW5kDQpicmlk Z2VzOyBldmVyeSBib3ggYWxvbmcgdGhlIHBhdGggbXVzdCByZXNlcnZlIHJlc291cmNlcy4NCkMu IFRoZSBob3N0IG1ha2luZyB0aGUgcmVzZXJ2YXRpb25zIG11c3Qgbm90IGNhcmUgd2hldGhlciB0 aGUgZmlyc3QgYm94IHRvDQp3aGljaCBpdCBpcyBjb25uZWN0ZWQgaXMgYSBicmlkZ2Ugb3IgYSBy b3V0ZXIsIG9yIHdoYXQgc3VpdGUgb2YgcHJvdG9jb2xzDQppcyB1c2VkIGJ5IHRoZSBuZXR3b3Jr IHRvIHN1cHBvcnQgaXRzIHJlc2VydmF0aW9ucy4NCg0KQSBudW1iZXIgb2YgbWVtYmVycyBvZiBJ RUVFIDgwMi4xIGJlbGlldmUgdGhhdCB0aGUgbW9kZWxzIGZvciBpbmZvcm1hdGlvbg0KcHJvcGFn YXRpb24gdXNlZCBieSB0aGUgUGF0aCBDb21wdXRhdGlvbiBFbGVtZW50LCBSU1ZQLCBSU1ZQLVRF LCBQQ0VQLA0KYW5kL29yIHNlZ21lbnQgcm91dGluZyBhcmUgYSBzdXBlcnNldCBvZiB0aGF0IHVz ZWQgYnkgdGhlIGV4aXN0aW5nIGFuZA0KcGxhbm5lZCB3b3JrIGJ5IHRoZSA4MDIuMSBUU04gV0cs IGFuZCBvZmZlciBhIG1vZGVsIGZvciBhIGNvbWJpbmVkIExheWVyIDINCi8gTGF5ZXIgMywgSUVF RSAvIElFVEYsIGVmZm9ydC4NCg0KV2UgaG9wZSB0aGF0IHRoZSBEZXRlcm1pbmlzdGljIE5ldHdv cmtpbmcgc2lkZSBtZWV0aW5nIGNhbiBiZSB1c2VkIGJ5IHRoZQ0KcGFydGljaXBhbnRzIHRvIHRl c3QgdGhlIHdhdGVycywgYW5kIHNlZSB3aGV0aGVyIHRoZXJlIGlzIGludGVyZXN0IGluDQp3b3Jr aW5nIG9uIHRoZSBhYm92ZSBwcm9ibGVtcy4NCg0KDQotLQ0KR2xlbm4gUGFyc29ucyAtIENoYWly LCBJRUVFIDgwMi4xDQpnbGVubi5wYXJzb25zQGVyaWNzc29uLmNvbTxtYWlsdG86Z2xlbm4ucGFy c29uc0Blcmljc3Nvbi5jb20+DQorMS02MTMtOTYzLTgxNDENCg0K --_000_9904FB1B0159DA42B0B887B7FA8119CA5C84E752AZFFEXMB04globa_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRl LCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0 IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkZvcndhcmRpbmcgdG8gZm9sa3MgaW4gTkVUQ09ORiBh bmQgdGhlIE9QUyBhcmVhLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+RGFuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBpZWVlLWlldGYtY29v cmQgW21haWx0bzppZWVlLWlldGYtY29vcmQtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+Tm9ybWFuIEZpbm4gKG5maW5uKTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBK dWx5IDIyLCAyMDE0IDY6MTcgUE08YnI+DQo8Yj5Ubzo8L2I+IEdsZW5uIFBhcnNvbnM7IGllZWUt aWV0Zi1jb29yZEBpZXRmLm9yZzsgUmljaGFyZCBCYXJuZXM7IEFsaXNzYSBDb29wZXI7IEFsaWEg QXRsYXM7IEFkcmlhbiBGYXJyZWw7IEp1bGllbiBNZXVyaWM7IEpQIFZhc3NldXI7IEFsdmFybyBS ZXRhbmEgKGFyZXRhbmEpOyBKZWZmIFRhbnRzdXJhOyBCcmlhbiBIYWJlcm1hbjsgdGVkLmxlbW9u QG5vbWludW0uY29tOyBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpOyB3YXR0ZXluZUBlZWNzLmJl cmtlbGV5LmVkdTsNCiBLYXJlbiBPJ0Rvbm9naHVlOyBZYWFrb3YgU3RlaW47IFNwZW5jZXIgRGF3 a2luczsgbWxzLmlldGZAZ21haWwuY29tOyBEYXZpZCBCbGFjazsgR29ycnkgRmFpcmh1cnN0OyBK YW1lcyBQb2xrIChqbXBvbGspOyBCZW5vaXQgQ2xhaXNlIChiY2xhaXNlKTsgSm9lbCBKYWVnZ2xp OyBNZWhtZXQgRXJzdWU7IEJlcnQgV2lqbmVuPGJyPg0KPGI+Q2M6PC9iPiBzdGF0ZW1lbnRzQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbaWVlZS1pZXRmLWNvb3JkXSBMaWFpc29u IGZyb20gSUVFRSA4MDIuMSAtIERldGVybWluaXN0aWMgTmV0d29ya2luZzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+SSBvcmdhbml6ZWQgdGhpcyBtZWV0aW5nIChyZXF1 ZXN0ZWQgdGhlIHJvb20sIGV0Yy4pICZuYnNwO1RoZXJlIHdpbGwgYmUgYSAmbHQ7IDIwLXNsaWRl IGludHJvZHVjdGlvbiwgdGhlbiBhIGZyZWUtZm9yLWFsbCBkaXNjdXNzaW9uLiAmbmJzcDtJIGFw cHJlY2lhdGUgdGhhdCB0aGlzIGlzIGEgcmVxdWVzdCBmb3IgYSB0aW1lIGNvbW1pdG1lbnQgZnJv bSBzb21lDQogdmVyeSBidXN5IHBlb3BsZS4gJm5ic3A7SW4gdGhhdCB2ZWluLCB0aGUgaW52aXRl ZXMgc2hvdWxkIGZlZWwgZnJlZSB0byBkZWxlZ2F0ZSB0aGVpciBhdHRlbmRhbmNlIHRvIHBhcnRp ZXMgd2hvIG1heSBoYXZlIGEgcGFydGljdWxhciBpbnRlcmVzdC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Y29sb3I6YmxhY2siPknigJltIGF0dGVuZGluZyBtZWV0aW5ncyBhbGwgd2Vlay4g Jm5ic3A7RmVlbCBmcmVlIHRvIHR4dCBtZSBhdCAxLTkyNS05ODAtNjQzMCB3aXRoIHF1ZXN0aW9u cyBvciBjb21wbGFpbnRzLiAmbmJzcDtFbWFpbCBtYXkgd29yaywgYWxzby48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPuKAlCBOb3JtIEZpbm48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5HbGVubiBQYXJzb25zICZsdDs8YSBocmVmPSJtYWlsdG86Z2xlbm4u cGFyc29uc0Blcmljc3Nvbi5jb20iPmdsZW5uLnBhcnNvbnNAZXJpY3Nzb24uY29tPC9hPiZndDs8 YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSwgSnVseSAyMiwgMjAxNCBhdCAwNDowNCBBTTxicj4N CjxiPlRvOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmllZWUtaWV0Zi1jb29yZEBpZXRmLm9y ZyI+aWVlZS1pZXRmLWNvb3JkQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv OmllZWUtaWV0Zi1jb29yZEBpZXRmLm9yZyI+aWVlZS1pZXRmLWNvb3JkQGlldGYub3JnPC9hPiZn dDssIFJpY2hhcmQgQmFybmVzICZsdDs8YSBocmVmPSJtYWlsdG86cmxiQGlwdi5zeCI+cmxiQGlw di5zeDwvYT4mZ3Q7LCBBbGlzc2EgQ29vcGVyICZsdDs8YSBocmVmPSJtYWlsdG86YWxpc3NhQGNv b3BlcncuaW4iPmFsaXNzYUBjb29wZXJ3LmluPC9hPiZndDssDQogQWxpYSBBdGxhcyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmFrYXRsYXNAZ21haWwuY29tIj5ha2F0bGFzQGdtYWlsLmNvbTwvYT4mZ3Q7 LCBBZHJpYW4gRmFycmVsICZsdDs8YSBocmVmPSJtYWlsdG86YWRyaWFuQG9sZGRvZy5jby51ayI+ YWRyaWFuQG9sZGRvZy5jby51azwvYT4mZ3Q7LCBKdWxpZW4gTWV1cmljICZsdDs8YSBocmVmPSJt YWlsdG86anVsaWVuLm1ldXJpY0BvcmFuZ2UuY29tIj5qdWxpZW4ubWV1cmljQG9yYW5nZS5jb208 L2E+Jmd0OywgSlAgVmFzc2V1ciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpwdkBjaXNjby5jb20iPmpw dkBjaXNjby5jb208L2E+Jmd0OywNCiAmcXVvdDtBbHZhcm8gUmV0YW5hIChhcmV0YW5hKSZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFyZXRhbmFAY2lzY28uY29tIj5hcmV0YW5hQGNpc2NvLmNv bTwvYT4mZ3Q7LCBKZWZmIFRhbnRzdXJhICZsdDs8YSBocmVmPSJtYWlsdG86amVmZi50YW50c3Vy YUBlcmljc3Nvbi5jb20iPmplZmYudGFudHN1cmFAZXJpY3Nzb24uY29tPC9hPiZndDssIEJyaWFu IEhhYmVybWFuICZsdDs8YSBocmVmPSJtYWlsdG86YnJpYW5AaW5ub3ZhdGlvbnNsYWIubmV0Ij5i cmlhbkBpbm5vdmF0aW9uc2xhYi5uZXQ8L2E+Jmd0OywNCiAmcXVvdDs8YSBocmVmPSJtYWlsdG86 dGVkLmxlbW9uQG5vbWludW0uY29tIj50ZWQubGVtb25Abm9taW51bS5jb208L2E+JnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86dGVkLmxlbW9uQG5vbWludW0uY29tIj50ZWQubGVtb25Abm9taW51 bS5jb208L2E+Jmd0OywgUGFzY2FsIFRodWJlcnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwdGh1YmVy dEBjaXNjby5jb20iPnB0aHViZXJ0QGNpc2NvLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJt YWlsdG86d2F0dGV5bmVAZWVjcy5iZXJrZWxleS5lZHUiPndhdHRleW5lQGVlY3MuYmVya2VsZXku ZWR1PC9hPiZxdW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86d2F0dGV5bmVAZWVjcy5iZXJrZWxl eS5lZHUiPndhdHRleW5lQGVlY3MuYmVya2VsZXkuZWR1PC9hPiZndDssIEthcmVuIE8nRG9ub2do dWUgJmx0OzxhIGhyZWY9Im1haWx0bzpvZG9ub2dodWVAaXNvYy5vcmciPm9kb25vZ2h1ZUBpc29j Lm9yZzwvYT4mZ3Q7LCBZYWFrb3YgU3RlaW4gJmx0OzxhIGhyZWY9Im1haWx0bzp5YWFrb3Zfc0By YWQuY29tIj55YWFrb3Zfc0ByYWQuY29tPC9hPiZndDssIFNwZW5jZXIgRGF3a2lucyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tIj5zcGVuY2VyZGF3a2lu cy5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7LA0KICZxdW90OzxhIGhyZWY9Im1haWx0bzptbHMuaWV0 ZkBnbWFpbC5jb20iPm1scy5pZXRmQGdtYWlsLmNvbTwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzptbHMuaWV0ZkBnbWFpbC5jb20iPm1scy5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7LCBEYXZp ZCBCbGFjayAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhdmlkLmJsYWNrQGVtYy5jb20iPmRhdmlkLmJs YWNrQGVtYy5jb208L2E+Jmd0OywgR29ycnkgRmFpcmh1cnN0ICZsdDs8YSBocmVmPSJtYWlsdG86 Z29ycnlAZXJnLmFiZG4uYWMudWsiPmdvcnJ5QGVyZy5hYmRuLmFjLnVrPC9hPiZndDssDQogJnF1 b3Q7SmFtZXMgUG9sayAoam1wb2xrKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptcG9sa0Bj aXNjby5jb20iPmptcG9sa0BjaXNjby5jb208L2E+Jmd0OywgJnF1b3Q7QmVub2l0IENsYWlzZSAo YmNsYWlzZSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2xhaXNlQGNpc2NvLmNvbSI+YmNs YWlzZUBjaXNjby5jb208L2E+Jmd0OywgSm9lbCBKYWVnZ2xpICZsdDs8YSBocmVmPSJtYWlsdG86 am9lbGphQGJvZ3VzLmNvbSI+am9lbGphQGJvZ3VzLmNvbTwvYT4mZ3Q7LCBNZWhtZXQgRXJzdWUg Jmx0OzxhIGhyZWY9Im1haWx0bzptZWhtZXQuZXJzdWVAbnNuLmNvbSI+bWVobWV0LmVyc3VlQG5z bi5jb208L2E+Jmd0OywNCiBCZXJ0IFdpam5lbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlcnRpZXRm QGJ3aWpuZW4ubmV0Ij5iZXJ0aWV0ZkBid2lqbmVuLm5ldDwvYT4mZ3Q7PGJyPg0KPGI+Q2M6IDwv Yj4mcXVvdDs8YSBocmVmPSJtYWlsdG86c3RhdGVtZW50c0BpZXRmLm9yZyI+c3RhdGVtZW50c0Bp ZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzdGF0ZW1lbnRzQGlldGYub3Jn Ij5zdGF0ZW1lbnRzQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W2llZWUt aWV0Zi1jb29yZF0gTGlhaXNvbiBmcm9tIElFRUUgODAyLjEgLSBEZXRlcm1pbmlzdGljIE5ldHdv cmtpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGNtIiBpZD0iTUFDX09VVExP T0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPlRvOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iY29sb3I6YmxhY2siPlJpY2hhcmQgQmFybmVzICZsdDs8YSBocmVmPSJtYWlsdG86 cmxiQGlwdi5zeCI+cmxiQGlwdi5zeDwvYT4mZ3Q7OyBBbGlzc2EgQ29vcGVyICZsdDs8YSBocmVm PSJtYWlsdG86YWxpc3NhQGNvb3BlcncuaW4iPmFsaXNzYUBjb29wZXJ3LmluPC9hPiZndDs7PGJy Pg0KUmVhbC10aW1lIEFwcGxpY2F0aW9ucyBhbmQgSW5mcmFzdHJ1Y3R1cmUgQXJlYSBEaXJlY3Rv cnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNr Ij5BbGlhIEF0bGFzICZsdDs8YSBocmVmPSJtYWlsdG86YWthdGxhc0BnbWFpbC5jb20iPmFrYXRs YXNAZ21haWwuY29tPC9hPiZndDs7IEFkcmlhbiBGYXJyZWwgJmx0OzxhIGhyZWY9Im1haWx0bzph ZHJpYW5Ab2xkZG9nLmNvLnVrIj5hZHJpYW5Ab2xkZG9nLmNvLnVrPC9hPiZndDs7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+Um91dGluZyBBcmVh IERpcmVjdG9yczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iY29sb3I6 YmxhY2siPkp1bGllbiBNZXVyaWMgJmx0OzxhIGhyZWY9Im1haWx0bzpqdWxpZW4ubWV1cmljQG9y YW5nZS5jb20iPmp1bGllbi5tZXVyaWNAb3JhbmdlLmNvbTwvYT4mZ3Q7OyBKUCBWYXNzZXVyICZs dDs8YSBocmVmPSJtYWlsdG86anB2QGNpc2NvLmNvbSI+anB2QGNpc2NvLmNvbTwvYT4mZ3Q7Ow0K PGJyPg0KUGF0aCA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+ Q29udHJvbCBFbGVtZW50IFdHIGNoYWlyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPkFsdmFybyBSZXRhbmEgKGFyZXRhbmEpICZsdDs8YSBo cmVmPSJtYWlsdG86YXJldGFuYUBjaXNjby5jb20iPmFyZXRhbmFAY2lzY28uY29tPC9hPiZndDs7 IEplZmYgVGFudHN1cmE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNv bG9yOmJsYWNrIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmplZmYudGFudHN1cmFAZXJpY3Nzb24uY29t Ij5qZWZmLnRhbnRzdXJhQGVyaWNzc29uLmNvbTwvYT4mZ3Q7OyBSb3V0aW5nIEFyZWEgV0cgY2hh aXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFj ayI+QnJpYW4gSGFiZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpicmlhbkBpbm5vdmF0aW9uc2xh Yi5uZXQiPmJyaWFuQGlubm92YXRpb25zbGFiLm5ldDwvYT4mZ3Q7OyBUZWQgTGVtb248bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbHQ7PGEgaHJl Zj0ibWFpbHRvOnRlZC5sZW1vbkBub21pbnVtLmNvbSI+dGVkLmxlbW9uQG5vbWludW0uY29tPC9h PiZndDs7IEludGVybmV0IEFyZWEgRGlyZWN0b3JzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+UGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSAm bHQ7PGEgaHJlZj0ibWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbSI+cHRodWJlcnRAY2lzY28uY29t PC9hPiZndDs7IFRob21hcyBXYXR0ZXluZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iY29sb3I6YmxhY2siPiZsdDs8YSBocmVmPSJtYWlsdG86d2F0dGV5bmVAZWVjcy5i ZXJrZWxleS5lZHUiPndhdHRleW5lQGVlY3MuYmVya2VsZXkuZWR1PC9hPiZndDs7IElQdjYgb3Zl ciBUU0NIIFdHIGNoYWlyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iY29sb3I6YmxhY2siPlJheSBCZWxsaXMgJmx0OzxhIGhyZWY9Im1haWx0bzpyYXkuYmVsbGlz QG5vbWluZXQub3JnLnVrIj5yYXkuYmVsbGlzQG5vbWluZXQub3JnLnVrPC9hPiZndDs7IE1hcmsg VG93bnNsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzptYXJrQHRvd25zbGV5Lm5ldCI+bWFya0B0b3du c2xleS5uZXQ8L2E+Jmd0Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9 ImNvbG9yOmJsYWNrIj5Ib21lIE5ldHdvcmtpbmcgV0cgY2hhaXJzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+S2FyZW4gTydEb25vZ2h1ZSAm bHQ7PGEgaHJlZj0ibWFpbHRvOm9kb25vZ2h1ZUBpc29jLm9yZyI+b2Rvbm9naHVlQGlzb2Mub3Jn PC9hPiZndDs7IFlhYWtvdiBTdGVpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlhYWtvdl9zQHJhZC5j b20iPnlhYWtvdl9zQHJhZC5jb208L2E+Jmd0Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJF Ti1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj5UaWN0b2MgV0cgY2hhaXJzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+U3BlbmNlciBEYXdraW5z ICZsdDs8YSBocmVmPSJtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20iPnNwZW5j ZXJkYXdraW5zLmlldGZAZ21haWwuY29tPC9hPiZndDs7IE1hcnRpbiBTdGllbWVybGluZzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPiZsdDs8YSBo cmVmPSJtYWlsdG86bWxzLmlldGZAZ21haWwuY29tIj5tbHMuaWV0ZkBnbWFpbC5jb208L2E+Jmd0 OzsgVHJhbnNwb3J0IEFyZWEgRGlyZWN0b3JzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+RGF2aWQgQmxhY2sgJmx0OzxhIGhyZWY9Im1haWx0 bzpkYXZpZC5ibGFja0BlbWMuY29tIj5kYXZpZC5ibGFja0BlbWMuY29tPC9hPiZndDs7IEdvcnJ5 IEZhaXJodXJzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVrIj5nb3Jy eUBlcmcuYWJkbi5hYy51azwvYT4mZ3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iY29sb3I6YmxhY2siPkphbWVzIFBvbGsgKGptcG9saykgJmx0OzxhIGhyZWY9Im1h aWx0bzpqbXBvbGtAY2lzY28uY29tIj5qbXBvbGtAY2lzY28uY29tPC9hPiZndDs7IFRyYW5zcG9y dCBBcmVhIFdHIGNoYWlyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i Y29sb3I6YmxhY2siPkJlbm9pdCBDbGFpc2UgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2xhaXNlQGNp c2NvLmNvbSI+YmNsYWlzZUBjaXNjby5jb208L2E+Jmd0OzsgSm9lbCBKYWVnZ2xpICZsdDs8YSBo cmVmPSJtYWlsdG86am9lbGphQGJvZ3VzLmNvbSI+am9lbGphQGJvZ3VzLmNvbTwvYT4mZ3Q7Ozwv c3Bhbj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj5PcGVyYXRpb24gYW5kIE1h bmFnZW1lbnQgQXJlYSBEaXJlY3RvcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImNvbG9yOmJsYWNrIj5NZWhtZXQgRXJzdWUgJmx0OzxhIGhyZWY9Im1haWx0bzpt ZWhtZXQuZXJzdWVAbnNuLmNvbSI+bWVobWV0LmVyc3VlQG5zbi5jb208L2E+Jmd0OzsgQmVydCBX aWpuZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpiZXJ0aWV0ZkBid2lqbmVuLm5ldCI+YmVydGlldGZA Yndpam5lbi5uZXQ8L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iY29sb3I6YmxhY2siPk5ldHdvcmsgQ29uZmlndXJhdGlvbiBXRyBjaGFpcnM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj5BdCA4OjAw IFBNIG9uIFdlZG5lc2RheSwgSnVseSAyMywgYXQgSUVURjkwIGluIFRvcm9udG8sIHRoZXJlIHdp bGwgYmUgYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPnNpZGUgbWVldGluZyAoYWthIEJhciBC T0Yg4oCUIHNlZSBSRkM2NzcxKSBvbiB0aGUgc3ViamVjdCBvZiBEZXRlcm1pbmlzdGljPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJjb2xvcjpibGFjayI+TmV0d29ya2luZyBpbiB0aGUgUXVlYmVjIHJvb20uJm5ic3A7 IElFRUUgODAyLjEgd2lzaGVzIHRvIGVuY291cmFnZSB5b3VyPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpi bGFjayI+Y29vcGVyYXRpb24gYW5kL29yIHBhcnRpY2lwYXRpb24uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+T3ZlciB0aGUgcGFzdCBm ZXcgeWVhcnMsIHRoZSBJRUVFIDgwMiBBdWRpbyBWaWRlbyBCcmlkZ2luZyBUYXNrIEdyb3VwIGFu ZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPml0IHN1Y2Nlc3NvciwgdGhlIFRpbWUtU2Vuc2l0 aXZlIE5ldHdvcmtpbmcgVEcsIGhhdmUgcmVsZWFzZWQgc3RhbmRhcmRzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJj b2xvcjpibGFjayI+dGhhdCBkZWZpbmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+MS4g UHJvdG9jb2xzIGZvciB0aGUgcmVzZXJ2YXRpb24sIGJ5IGVuZCBzdGF0aW9ucywgb2YgTGF5ZXIg MiBuZXR3b3JrPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpi bGFjayI+cmVzb3VyY2VzIGZvciBjcml0aWNhbCBmbG93czs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj4yLiBTcGVjaWZpYyBkYXRhIHBsYW5lIG1l Y2hhbmlzbXMgZm9yIGEgTGF5ZXIgMiBuZXR3b3JrIHRvIGd1YXJhbnRlZSAwPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+Y29uZ2VzdGlvbiBsb3Nz LCBhbmQgY29uc2VxdWVudGx5LCBhIGtub3duIGZpbml0ZSBlbmQtdG8tZW5kIGxhdGVuY3ksIGZv cjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPnRo b3NlIHJlc2VydmVkIGZsb3dzOyBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImNvbG9yOmJsYWNrIj4zLiBQbHVnLWFuZC1wbGF5IGRpc3RyaWJ1dGlvbiBvZiB0aGUg UHJlY2lzaW9uIFRpbWUgUHJvdG9jb2wgKElFRUUgMTU4ODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxh bmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPlBUUCkgb3ZlciBicmlkZ2VkLCByb3V0ZWQs IG9yIG1peGVkIG5ldHdvcmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZXNlIHN0YW5kYXJkcyB3ZXJlIG9yaWdpbmFsbHkgdGFy Z2V0ZWQgZm9yIHRoZSB0cmFuc3BvcnQgb2YgcmF3IGF1ZGlvPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpi bGFjayI+YW5kIHZpZGVvIHN0cmVhbXMuJm5ic3A7IFRoZSBzdWNjZXNzZnVsIGRlcGxveW1lbnQg b2YgbXVsdGktdmVuZG9yIG5ldHdvcmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+ZW1wbG95 aW5nIHRoZXNlIHN0YW5kYXJkcyBoYXMgdHJpZ2dlcmVkIGludGVyZXN0IGZyb20gbmV3IG1hcmtl dCBzZWdtZW50cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj5pbmNsdWRpbmcgaW5kdXN0cmlh bCwgdmVoaWN1bGFyLCBhbmQgb3RoZXIgcmVhbC10aW1lIHN5c3RlbXMuJm5ic3A7IEFzIGE8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImNvbG9yOmJsYWNrIj5jb25zZXF1ZW5jZSwgdGhlIElFRUUgODAyLjEgVGltZS1T ZW5zaXRpdmUgTmV0d29ya2luZyBUYXNrIEdyb3VwIGhhczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6Ymxh Y2siPm51bWJlciBvZiBwcm9qZWN0cyBpbiBwcm9ncmVzcyB0byBleHBhbmQgdGhlIGZpcnN0LXJv dW5kIGNhcGFiaWxpdGllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIg c3R5bGU9ImNvbG9yOmJsYWNrIj5UaGlzIHN1Y2Nlc3MgaGFzIGFsc28gbWFkZSBjbGVhciB0aGF0 IHRoZSB1c2VycyBvZiB0aGVzZSBjYXBhYmlsaXRpZXMgaGF2ZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6 YmxhY2siPm5ldHdvcmtpbmcgbmVlZHMgdGhhdCB0cmFuc2NlbmQgdGhlIGxpbWl0YXRpb25zIGlt cG9zZWQgYnkgbmV0d29ya3MgdGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPm9wZXJhdGUg YXQgb25seSBMYXllciAyLiZuYnNwOyBUaGUgZm9sbG93aW5nIGVsZW1lbnRzIGFyZSBlc3NlbnRp YWwgdG8gZXhwYW5kPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+dGhlIGN1cnJlbnQgVGltZS1T ZW5zaXRpdmUgTmV0d29ya2luZyBUR+KAmXMgc3RhbmRhcmRzIGludG8g4oCcRGV0ZXJtaW5pc3Rp YzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPk5ldHdvcmtpbmfigJ06PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJjb2xvcjpibGFjayI+QS4gRGV0ZXJtaW5pc3RpYyBOZXR3b3JraW5nIGhhcyB0byBiZSBhIFFv UyBmZWF0dXJlIG9mIHN0YW5kYXJkIG5ldHdvcmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPm5vdCBhIHNldCBvZiBwb2ludCBmZWF0dXJlcyBh cm91bmQgd2hpY2ggb25lIGNvdWxkIHdyaXRlIGFuIEFwcGxpY2F0aW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPkIuIFRoZSBuZXR3b3JrcyBv ZiBpbnRlcmVzdCBjb250YWluIGEgbWl4dHVyZSBvZiBicmlkZ2VzIGFuZCByb3V0ZXJzLiZuYnNw OyBUaGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNr Ij5Rb1MgZmVhdHVyZXMgaGF2ZSB0byBiZSBzdXBwb3J0ZWQgcmVnYXJkbGVzcyBvZiBMYXllciAy IC8gTGF5ZXIgMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6 YmxhY2siPmJvdW5kYXJpZXMuJm5ic3A7IFRoZSBjb250cm9sIHByb3RvY29scyBtdXN0IGJlIHZp c2libGUgdG8gYm90aCByb3V0ZXJzIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNB IiBzdHlsZT0iY29sb3I6YmxhY2siPmJyaWRnZXM7IGV2ZXJ5IGJveCBhbG9uZyB0aGUgcGF0aCBt dXN0IHJlc2VydmUgcmVzb3VyY2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iY29sb3I6YmxhY2siPkMuIFRoZSBob3N0IG1ha2luZyB0aGUgcmVzZXJ2YXRpb25zIG11 c3Qgbm90IGNhcmUgd2hldGhlciB0aGUgZmlyc3QgYm94IHRvPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4g bGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+d2hpY2ggaXQgaXMgY29ubmVjdGVkIGlz IGEgYnJpZGdlIG9yIGEgcm91dGVyLCBvciB3aGF0IHN1aXRlIG9mIHByb3RvY29sczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPmlzIHVzZWQgYnkg dGhlIG5ldHdvcmsgdG8gc3VwcG9ydCBpdHMgcmVzZXJ2YXRpb25zLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPkEgbnVtYmVyIG9mIG1l bWJlcnMgb2YgSUVFRSA4MDIuMSBiZWxpZXZlIHRoYXQgdGhlIG1vZGVscyBmb3IgaW5mb3JtYXRp b248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj5wcm9wYWdhdGlvbiB1c2VkIGJ5IHRoZSBQYXRo IENvbXB1dGF0aW9uIEVsZW1lbnQsIFJTVlAsIFJTVlAtVEUsIFBDRVAsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJj b2xvcjpibGFjayI+YW5kL29yIHNlZ21lbnQgcm91dGluZyBhcmUgYSBzdXBlcnNldCBvZiB0aGF0 IHVzZWQgYnkgdGhlIGV4aXN0aW5nIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPnBsYW5u ZWQgd29yayBieSB0aGUgODAyLjEgVFNOIFdHLCBhbmQgb2ZmZXIgYSBtb2RlbCBmb3IgYSBjb21i aW5lZCBMYXllciAyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+LyBMYXllciAzLCBJRUVFIC8g SUVURiwgZWZmb3J0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iY29sb3I6YmxhY2siPldlIGhvcGUgdGhhdCB0aGUgRGV0ZXJtaW5pc3RpYyBOZXR3b3JraW5n IHNpZGUgbWVldGluZyBjYW4gYmUgdXNlZCBieSB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNr Ij5wYXJ0aWNpcGFudHMgdG8gdGVzdCB0aGUgd2F0ZXJzLCBhbmQgc2VlIHdoZXRoZXIgdGhlcmUg aXMgaW50ZXJlc3QgaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj53b3JraW5nIG9uIHRoZSBh Ym92ZSBwcm9ibGVtcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImNvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUNBIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xv cjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1DQSI+LS08L3NwYW4+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjazttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1DQSI+R2xlbm4gUGFyc29ucyAtIENoYWlyLCBJRUVFIDgwMi4x PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iY29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tQ0EiPjxhIGhyZWY9Im1haWx0 bzpnbGVubi5wYXJzb25zQGVyaWNzc29uLmNvbSI+Z2xlbm4ucGFyc29uc0Blcmljc3Nvbi5jb208 L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iY29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tQ0EiPiYjNDM7MS02MTMt OTYzLTgxNDE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_9904FB1B0159DA42B0B887B7FA8119CA5C84E752AZFFEXMB04globa_-- --_004_9904FB1B0159DA42B0B887B7FA8119CA5C84E752AZFFEXMB04globa_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=160; creation-date="Tue, 22 Jul 2014 15:41:47 GMT"; modification-date="Tue, 22 Jul 2014 15:41:47 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmllZWUtaWV0 Zi1jb29yZCBtYWlsaW5nIGxpc3QNCmllZWUtaWV0Zi1jb29yZEBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZWVlLWlldGYtY29vcmQNCg== --_004_9904FB1B0159DA42B0B887B7FA8119CA5C84E752AZFFEXMB04globa_-- From nobody Tue Jul 22 15:49:30 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099EF1A07A1; Tue, 22 Jul 2014 15:49:29 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Dss34LfTw6fF; Tue, 22 Jul 2014 15:49:27 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675941A0646; Tue, 22 Jul 2014 15:49:27 -0700 (PDT) Received: from BN1PR05MB154.namprd05.prod.outlook.com (10.255.205.19) by BN1PR05MB059.namprd05.prod.outlook.com (10.255.202.149) with Microsoft SMTP Server (TLS) id 15.0.990.7; Tue, 22 Jul 2014 22:49:25 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB154.namprd05.prod.outlook.com (10.255.205.19) with Microsoft SMTP Server (TLS) id 15.0.990.7; Tue, 22 Jul 2014 22:49:25 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.39]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.39]) with mapi id 15.00.0995.014; Tue, 22 Jul 2014 22:49:25 +0000 From: Dean Bogdanovic To: "" , "netmod@ietf.org" Thread-Topic: i2rs requirements draft Thread-Index: AQHPpf8u0Mc/JKhi6k20vGS/ckMDww== Date: Tue, 22 Jul 2014 22:49:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02801ACE41 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(86362001)(93916002)(92726001)(110136001)(558084003)(101416001)(50226001)(87286001)(89996001)(88136002)(77156001)(92566001)(31966008)(36756003)(83322001)(107046002)(229853001)(85852003)(77982001)(106116001)(50986999)(95666004)(105586002)(77096002)(2656002)(62966002)(74502001)(104166001)(79102001)(57306001)(85306003)(76482001)(46102001)(20776003)(4396001)(81542001)(99286002)(64706001)(74662001)(83072002)(87936001)(81342001)(66066001)(106356001)(21056001)(33656002)(80022001)(99396002)(104396001)(491001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB154; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <4E30BB54711FA44186E81D1898995043@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/sdspTrDlqN6ocnbumf-ZNUtzcWY Cc: Jeff Haas Subject: [Netconf] i2rs requirements draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 22:49:29 -0000 Just to follow up from the meeting. I'm volunteering to write up i2rs requi= rements to NETCONF WG, essentially RESTCONF/NETCONF part. Would need a co a= uthor for the NETMOD WG part. Dean From nobody Wed Jul 23 04:00:03 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1AEF1A0453; Wed, 23 Jul 2014 03:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.001] autolearn=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 QRgU8qznzjCX; Wed, 23 Jul 2014 03:59:46 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCB861A0422; Wed, 23 Jul 2014 03:59:45 -0700 (PDT) Received: from [172.16.50.248] (unknown [206.47.221.210]) by mail.nic.cz (Postfix) with ESMTPSA id 9BA6214006C; Wed, 23 Jul 2014 12:59:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1406113184; bh=72ocPqDkoQfCUcRxQhoX08i+SIzKy13PRpMxC0c7RFg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ZJVEq0KtI9AxbmQRUysZq5A3aNTJlpDYNJv3QSMG7k9EjyjUjtWiuQio4UxCIrfoi 8wPNIswPc5wWOzsNOQdQnD3AAu7Ua8IQNaQSHYQaLNoY/wpyP1sfdukGlMCOIDWevb JVW1XzD55ykS7HQreI51QGanOeSwyPD1Zj0khrRY= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 23 Jul 2014 06:59:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <49778DBA-3D86-4DF6-A304-4EE94CF1DBB1@nic.cz> References: To: Dean Bogdanovic X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/8GPcTwsoYHtud-CCLHMucq34h1c Cc: Jeff Haas , Netconf , "netmod@ietf.org" Subject: Re: [Netconf] i2rs requirements draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 10:59:49 -0000 Hi Dean, I can do that. Lada On 22 Jul 2014, at 18:49, Dean Bogdanovic wrote: > Just to follow up from the meeting. I'm volunteering to write up i2rs = requirements to NETCONF WG, essentially RESTCONF/NETCONF part. Would = need a co author for the NETMOD WG part. >=20 > Dean >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Jul 23 07:27:44 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D7E1B27D4; Wed, 23 Jul 2014 07:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 0ZSW5k2kPjuF; Wed, 23 Jul 2014 07:27:39 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 95E1D1B27CA; Wed, 23 Jul 2014 07:27:39 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 5F2DDC1FA; Wed, 23 Jul 2014 10:27:39 -0400 (EDT) Date: Wed, 23 Jul 2014 10:27:39 -0400 From: Jeffrey Haas To: Ladislav Lhotka Message-ID: <20140723142739.GD4653@pfrc> References: <49778DBA-3D86-4DF6-A304-4EE94CF1DBB1@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49778DBA-3D86-4DF6-A304-4EE94CF1DBB1@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/J20y0AKtHcDZVAidl98RRBgiWkw Cc: Jeff Haas , "netmod@ietf.org" , Netconf Subject: Re: [Netconf] i2rs requirements draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 14:27:40 -0000 Thanks for the support! Ed and I will be in contact soon. -- Jeff On Wed, Jul 23, 2014 at 06:59:10AM -0400, Ladislav Lhotka wrote: > Hi Dean, > > I can do that. > > Lada > > On 22 Jul 2014, at 18:49, Dean Bogdanovic wrote: > > > Just to follow up from the meeting. I'm volunteering to write up i2rs requirements to NETCONF WG, essentially RESTCONF/NETCONF part. Would need a co author for the NETMOD WG part. > > > > Dean > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Jul 23 14:36:16 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A52DD1B2798 for ; Wed, 23 Jul 2014 14:36:15 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 zxP-58yeVRew for ; Wed, 23 Jul 2014 14:36:14 -0700 (PDT) Received: from epost.uninett.no (epost.uninett.no [IPv6:2001:700:1:8::180:100]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4AD1A0B00 for ; Wed, 23 Jul 2014 14:36:14 -0700 (PDT) Received: from [IPv6:2001:67c:370:152:14a7:d481:93bd:2028] (unknown [IPv6:2001:67c:370:152:14a7:d481:93bd:2028]) by epost.uninett.no (Postfix) with ESMTPSA id E776A33780F for ; Wed, 23 Jul 2014 23:36:12 +0200 (CEST) Message-ID: <53D02AC9.30206@uninett.no> Date: Wed, 23 Jul 2014 23:36:09 +0200 From: Arne Oslebo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: netconf@ietf.org References: <9904FB1B0159DA42B0B887B7FA8119CA5C845AD0@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C845AD0@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/rVSWqg6vrkkgARrZTf4NkVVfK_o Subject: Re: [Netconf] protocol proposals for LMAP X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 21:36:15 -0000 Hello, we think that RESTCONF and YANG are good candidates for the LMAP Control Protocol so I can start working on an Internet-Draft. Regards, Arne On 17. juli 2014 18:53, Romascanu, Dan (Dan) wrote: > > Hi, > > > > The LMAP working group http://datatracker.ietf.org/wg/lmap/charter/ > has recently submitted > a use case document to the IESG and makes progress towards the > completion and submission of the LMAP framework and information model > I-Ds. It is now time to submit proposals for the LMAP protocols (the > charter talks about a Control Protocol and a Report Protocol). In the > initial phases of the LMAP discussions NETCONF was mentioned as one of > the candidates. Does anybody plan to write an Internet-Draft to > propose NETCONF (or maybe RESTCONF?) as a candidate protocol in LMAP? > > > > Regards, > > > > Dan > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Jul 23 14:39:51 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1808C1B281C for ; Wed, 23 Jul 2014 14:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 t_Zqbas0-3SC for ; Wed, 23 Jul 2014 14:39:46 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 526711B280A for ; Wed, 23 Jul 2014 14:39:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQHAKoq0FPGmAcV/2dsb2JhbABZgmokUlcErzwBAQEBAQEGmTghCoZyUwGBCxZ2hAMBAQEBAwEBAQ8oNAsMBAIBCA0EBAEBAQoUCQcnCxQJCAIEAQ0FCBqIIAEMnhyiHBeFe4kfMQcGgyiBGAWcf4V0jHqDSGyBRQ X-IronPort-AV: E=Sophos;i="5.01,720,1400040000"; d="scan'208";a="66196905" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 23 Jul 2014 17:39:43 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 23 Jul 2014 17:39:30 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Wed, 23 Jul 2014 23:39:28 +0200 From: "Romascanu, Dan (Dan)" To: Arne Oslebo , "netconf@ietf.org" Thread-Topic: [Netconf] protocol proposals for LMAP Thread-Index: AQHPpr4kqwkG1h0V7Eq4Qead+GiUXJuuL1xg Date: Wed, 23 Jul 2014 21:39:28 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C8507BF@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA5C845AD0@AZ-FFEXMB04.global.avaya.com> <53D02AC9.30206@uninett.no> In-Reply-To: <53D02AC9.30206@uninett.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/c-Z9bX-n6Bv3bkvu00JjGiuyPqg Cc: "Weil, Jason" Subject: Re: [Netconf] protocol proposals for LMAP X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 21:39:48 -0000 If you are in Toronto - can you say a few words about this tomorrow in the = LMAP WG meeting?=20 Thanks and Regards, Dan > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Arne Oslebo > Sent: Thursday, July 24, 2014 12:36 AM > To: netconf@ietf.org > Subject: Re: [Netconf] protocol proposals for LMAP >=20 > Hello, >=20 > we think that RESTCONF and YANG are good candidates for the LMAP > Control Protocol so I can start working on an Internet-Draft. >=20 > Regards, > Arne >=20 > On 17. juli 2014 18:53, Romascanu, Dan (Dan) wrote: > > > > Hi, > > > > > > > > The LMAP working group http://datatracker.ietf.org/wg/lmap/charter/ > > has recently submitted > > a use case document to the IESG and makes progress towards the > > completion and submission of the LMAP framework and information model > > I-Ds. It is now time to submit proposals for the LMAP protocols (the > > charter talks about a Control Protocol and a Report Protocol). In the > > initial phases of the LMAP discussions NETCONF was mentioned as one of > > the candidates. Does anybody plan to write an Internet-Draft to > > propose NETCONF (or maybe RESTCONF?) as a candidate protocol in > LMAP? > > > > > > > > Regards, > > > > > > > > Dan > > > > > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Jul 23 14:52:22 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685351B28B2 for ; Wed, 23 Jul 2014 14:52:21 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 3tiQ1Vqw5zLz for ; Wed, 23 Jul 2014 14:52:20 -0700 (PDT) Received: from epost.uninett.no (epost.uninett.no [IPv6:2001:700:1:8::180:100]) by ietfa.amsl.com (Postfix) with ESMTP id BD1691B2833 for ; Wed, 23 Jul 2014 14:52:19 -0700 (PDT) Received: from [IPv6:2001:67c:370:152:14a7:d481:93bd:2028] (unknown [IPv6:2001:67c:370:152:14a7:d481:93bd:2028]) by epost.uninett.no (Postfix) with ESMTPSA id 47DF678AB8; Wed, 23 Jul 2014 23:52:18 +0200 (CEST) Message-ID: <53D02E90.4080507@uninett.no> Date: Wed, 23 Jul 2014 23:52:16 +0200 From: Arne Oslebo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" , "netconf@ietf.org" References: <9904FB1B0159DA42B0B887B7FA8119CA5C845AD0@AZ-FFEXMB04.global.avaya.com> <53D02AC9.30206@uninett.no> <9904FB1B0159DA42B0B887B7FA8119CA5C8507BF@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C8507BF@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/8v4IGfsjF317ZmaepGUn1itzda8 Cc: "Weil, Jason" Subject: Re: [Netconf] protocol proposals for LMAP X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 21:52:21 -0000 I'm in Toronto and will be attending the LMAP meeting tomorrow. So sure, I can say a few words about it. Regards, Arne On 23. juli 2014 23:39, Romascanu, Dan (Dan) wrote: > If you are in Toronto - can you say a few words about this tomorrow in the LMAP WG meeting? > > Thanks and Regards, > > Dan > > >> -----Original Message----- >> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Arne Oslebo >> Sent: Thursday, July 24, 2014 12:36 AM >> To: netconf@ietf.org >> Subject: Re: [Netconf] protocol proposals for LMAP >> >> Hello, >> >> we think that RESTCONF and YANG are good candidates for the LMAP >> Control Protocol so I can start working on an Internet-Draft. >> >> Regards, >> Arne >> >> On 17. juli 2014 18:53, Romascanu, Dan (Dan) wrote: >>> Hi, >>> >>> >>> >>> The LMAP working group http://datatracker.ietf.org/wg/lmap/charter/ >>> has recently submitted >>> a use case document to the IESG and makes progress towards the >>> completion and submission of the LMAP framework and information model >>> I-Ds. It is now time to submit proposals for the LMAP protocols (the >>> charter talks about a Control Protocol and a Report Protocol). In the >>> initial phases of the LMAP discussions NETCONF was mentioned as one of >>> the candidates. Does anybody plan to write an Internet-Draft to >>> propose NETCONF (or maybe RESTCONF?) as a candidate protocol in >> LMAP? >>> >>> >>> Regards, >>> >>> >>> >>> Dan >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Jul 23 15:07:23 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D141A03FC for ; Wed, 23 Jul 2014 15:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.001] autolearn=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 uvAvEW_7ui8N for ; Wed, 23 Jul 2014 15:07:16 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 646F81A0089 for ; Wed, 23 Jul 2014 15:07:16 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2ED281202; Thu, 24 Jul 2014 00:07:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id AkAbCyayZ82K; Thu, 24 Jul 2014 00:07:01 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 24 Jul 2014 00:07:14 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9FEF32002C; Thu, 24 Jul 2014 00:07:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id paPCC_eqPTqk; Thu, 24 Jul 2014 00:07:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C9BBF20017; Thu, 24 Jul 2014 00:07:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B84252DF7D7F; Thu, 24 Jul 2014 00:07:13 +0200 (CEST) Date: Thu, 24 Jul 2014 00:07:13 +0200 From: Juergen Schoenwaelder To: Arne Oslebo Message-ID: <20140723220713.GA42165@elstar.local> Mail-Followup-To: Arne Oslebo , netconf@ietf.org References: <9904FB1B0159DA42B0B887B7FA8119CA5C845AD0@AZ-FFEXMB04.global.avaya.com> <53D02AC9.30206@uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53D02AC9.30206@uninett.no> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ID0H9vVroDlz8ZUeCadWAZNZglM Cc: netconf@ietf.org Subject: Re: [Netconf] protocol proposals for LMAP X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 22:07:17 -0000 On Wed, Jul 23, 2014 at 11:36:09PM +0200, Arne Oslebo wrote: > Hello, > > we think that RESTCONF and YANG are good candidates for the LMAP Control > Protocol so I can start working on an Internet-Draft. > Arne, you may want to look at http://tools.ietf.org/html/draft-schoenw-lmap-netconf-00 since there are a few subtle points to sort out (I think). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Jul 23 16:01:18 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99B21B2A4F for ; Wed, 23 Jul 2014 16:01:16 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 PeXRxUqOAENe for ; Wed, 23 Jul 2014 16:01:15 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id F031E1B2A39 for ; Wed, 23 Jul 2014 16:01:14 -0700 (PDT) Received: from localhost (dhcp-a2a8.meeting.ietf.org [31.133.162.168]) by mail.tail-f.com (Postfix) with ESMTPSA id CA6D312809B7 for ; Thu, 24 Jul 2014 00:56:33 +0200 (CEST) Date: Wed, 23 Jul 2014 19:01:10 -0400 (EDT) Message-Id: <20140723.190110.325781546.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/gp_X2HcVSjYvrxLHBNAb2QeVAfI Subject: [Netconf] review of draft-ietf-netconf-zerotouch-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 23:01:17 -0000 Hi, I have reviewed draft-ietf-netconf-zerotouch-00 and here are my comments: o sec. 1.4 Vendors are the de facto Configuration Signer for the devices it manufactures, but may delegate that role to external Configuration Signers. What eactly do you mean with "de facto Configuration Signer" in this case? o sec. 1.4 Also mention boot images in your list and in the diagram. o sec. 2 This section describes the service interface a Configuration Server must implement as well as what's needed for transport security. s/must/MUST/ ? o sec 2.1 The term IDevID is used for the first time here. It would probably be a good idea to mention this term in a Terminology section. o sec 2.3 Therefore, it is RECOMMENDED for Configuration Servers to support transport-level encryption. Doesn't this contradict section 2.1 which says that https MUST be supported? Maybe you mean that it is RECOMMENDED that _devices_ use transport-level encryption? o sec 2.4 An expiration policy is needed to limit how long a Configuration Server needs to retain a configuration and, in turn, how many configurations it might need to retain at a given time. I do not understand this sentence. Why is the expiration policy needed? What does the number of configs it retains has to do with anything? o sec 3. Terminology: "Configuration Signer" vs. "Configlet Signer". o sec 4.2 The picture says "IDevID entity". What is this entity? o sec 4.2 Devices supporting ZeroTouch MUST be pre-provisioned with one or more URIs for Internet-based Configuration Servers. Why is this a MUST? (or why "one or more"?). It seems to me that the DHCP option could be used instead of manual pre-provisioning. Do you expect these config server URIs to be part of the normal config? See more below. o sec 4.2 confidentially and not available outside the DevID module What is "DevID module"? o sec 4.3 The test is: [if running config != factory default, boot normally] So if the user has done any local configuration, e.g. configured the Configuration Servers, it means that zerotouch won't be used? o sec 4.3 I think that the picture and text could use some numbering of the steps to make it easier to follow, i.e., number ot match the text with the diagram. o sec 4.3 You introduce the term GUID w/o explanation. o sec 4.3 However, since the Configlet configured the device to "call home," upon entering its normal operating mode, the device immediately begins trying to establish a call home connection, as specified by the Configlet. s/However, since the Configlet configured/ However, if the Configlet configured/ ? It seems to me this process can be used w/o call home as well. o sec 5.1 You have the list of expected device identifiers in immutable storage - that seems to indicate that it not possible to ever add a new device! o sec 6.1. s/preconfigure/configure/ ? o sec 6.2 Should this step also be in the diagram in 1.4? o sec 7.1. The second paragraph should probably be removed. o sec 7.2 The term "unique-identifier" is pretty generic. Should it simply be "device-identifier" instead? Also, here you are using "DevID". Did you mean "IDevID"? If not, you need to explain the difference. o sec 7.2 If the device finds that it is not running the correct version of software, it can pull the correct version from the Configuration Server. "can pull" - section 4.3 had "MUST". o sec 7.5 You define a "container configlet". With YANG version 1, I think it is better to follow the restconf example and define a grouping with this container: grouping configlet { container configlet { ... } } and explain that the grouping is not intended to be used. (side note: maybe we should have an explicit statement for this in YANG 1.1; it seems we have the need for it, since we use this hack already in several places) o sec 7.5, leaf unique-identifier This means that it is not possible to have a single configlet for all devices of a certain type. Is this necessary? o sec 7.5, leaf software-version "The device MUST must be running this version of software. The value for this field is device-specific, but it MUST be an exact match (e.g., 14.1R2.5)"; Why is this MUST be exact match? It seems inflexible to me. Since the field is vendor specific anyway, why not let the match algorithm be vendor specific as well? Also, should this really be mandatory? o sec 8.2 Remove the text about how a timestamp *could* be used? o signing / encrypting configlets I think you need to specify somewhere how the signature is inserted into the configlet XML document. Currently the only hint the reader get is from an example... Same for encryption, and in this case the example is also tbd. o sec A.1 This comment is related to the netconf-server data model. In this example teh configlet pushes a config with host keys, referred to by file name. How does the device get these keys? Editorial: ---------- o sec. 1.4 OLD: The device is preconfigured with a secure device identity, for Configuration Servers URIs, and certificates for Configuration Signers and Configuration Servers it trusts by default. NEW: The device is preconfigured with a secure device identity, Configuration Servers URIs, and certificates for Configuration Signers and Configuration Servers it trusts by default. o sec 2 s/The unique identifies/The unique identifier/ o sec 2.2 OLD: The Configuration server SHOULD to provide some user-facing interface to enable to the end-user to provide a Configlet and, optionally, an bootimage file. NEW: The Configuration server SHOULD provide some user-facing interface to enable the end-user to provide a Configlet and, optionally, a bootimage file. o sec 3.4 s/may prefer a this role be/may prefer that this role be/ o sec 4.3 s/MAY also try both the raw/MAY also try the raw/ o sec 5.1 s/either a SSH/either SSH/ o sec 7.5, leaf configuration OLD: support both the following standard data-models: NEW: support the following standard data-models: /martin From nobody Wed Jul 23 16:40:06 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FE61B2828; Wed, 23 Jul 2014 16:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 uOgwonDlYeb8; Wed, 23 Jul 2014 16:40:00 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 9B9561A02A2; Wed, 23 Jul 2014 16:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s6NNdoG4019765; Thu, 24 Jul 2014 01:39:50 +0200 (CEST) Received: from dhcp-9b7d.meeting.ietf.org (dhcp-9b7d.meeting.ietf.org [31.133.155.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8E39A324; Thu, 24 Jul 2014 01:39:48 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Carsten Bormann In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C84E752@AZ-FFEXMB04.global.avaya.com> Date: Wed, 23 Jul 2014 19:39:45 -0400 X-Mao-Original-Outgoing-Id: 427851585.788612-50a81dcd53bddb39de1bac54e9f35da5 Content-Transfer-Encoding: quoted-printable Message-Id: <172CF03E-D59E-45FE-B24B-C4DE7A8FCA86@tzi.org> References: <9904FB1B0159DA42B0B887B7FA8119CA5C84E752@AZ-FFEXMB04.global.avaya.com> To: "opsawg@ietf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/KYWxQo71PGJjpz8yO4SXBcBLcbQ Cc: "netconf@ietf.org" , "Norman Finn \(nfinn\) \(nfinn@cisco.com\)" Subject: Re: [Netconf] [OPSAWG] [ieee-ietf-coord] Liaison from IEEE 802.1 - Deterministic Networking X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 23:40:02 -0000 On 22 Jul 2014, at 14:51, Romascanu, Dan (Dan) = wrote: > < 20-slide introduction, =85 which apparently can be found here: = http://www.ieee802.org/1/files/public/docs2014/tsn-nfinn-Deterministic-Net= working-L2-L3-0714-v1.pdf Gr=FC=DFe, Carsten From nobody Thu Jul 24 12:16:11 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F2A1A002A for ; Thu, 24 Jul 2014 12:16:10 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 P_JjxfbyYoRA for ; Thu, 24 Jul 2014 12:16:09 -0700 (PDT) Received: from koko.ripe.net (koko.ripe.net [IPv6:2001:67c:2e8:11::c100:1348]) (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 E5C091A0467 for ; Thu, 24 Jul 2014 12:16:08 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XAOUo-0003lD-IU for netconf@ietf.org; Thu, 24 Jul 2014 21:16:07 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=dhcp-b7d9.meeting.ietf.org) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1XAOUo-00050f-BU for netconf@ietf.org; Thu, 24 Jul 2014 21:16:06 +0200 Message-ID: <53D15B74.7000404@ripe.net> Date: Thu, 24 Jul 2014 21:16:04 +0200 From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Netconf References: <53D01A8A.6030703@ripe.net> In-Reply-To: <53D01A8A.6030703@ripe.net> X-Forwarded-Message-Id: <53D01A8A.6030703@ripe.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885e3096357ee9d7f76442a0d9038731c492 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/XtXMhm1GbHvMqS0IOczgxhyGeYA Subject: [Netconf] Action by August 1st: WG call for consensus to have ONE netconf-callhome document X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 19:16:10 -0000 WG participants, during our IET90 session, Kent presented and we discussed reverse ssh this issue: Asymmetric document structure 5539bis vs RFC6242 + reverse-ssh -> 6242bis instead? Placement for generic content, Including: Section 3: "Benefits to Device Management” Section 5: "SSH Server Identification and Verification” Best if moved to a common “Call Home” draft A “6242bis” wouldn’t work after all… Proposal: Have a single “NETCONF Call Home” (draft-ietf-netconf-call-home) draft that is equally valid for all NETCONF transports rename this draft and move 5539bis content into it We did a hum in the room and there was overwhelming support to accept the proposal. No-one hummed against or abstained. So we're confirming this consensus on the WG mailing list. Please speak up by Friday August 1st if you disagree. Bert and Mehmet From nobody Thu Jul 24 13:31:50 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A8F1B27D7 for ; Thu, 24 Jul 2014 13:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 GSWX2rPoBvYF for ; Thu, 24 Jul 2014 13:31:40 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C30681B28BE for ; Thu, 24 Jul 2014 13:31:07 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s6OKV3SN025188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 24 Jul 2014 20:31:03 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s6OKV264012673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jul 2014 22:31:02 +0200 Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 24 Jul 2014 22:31:02 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.198]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0195.001; Thu, 24 Jul 2014 22:31:02 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: Benoit Claise , netconf Thread-Topic: Summary of the Netconf Session at IETF #90 Thread-Index: Ac+nfi4CvHqVn6y9RuG5uRU3Qc9oRw== Date: Thu, 24 Jul 2014 20:31:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.113] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81949B0F5DEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 12540 X-purgate-ID: 151667::1406233863-000005B1-B2937D92/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/0w9-4DvJ8TRYLeWN2G9E8pu8Xb0 Cc: Jeffrey Haas , ext Edward Crabbe Subject: [Netconf] Summary of the Netconf Session at IETF #90 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 20:31:47 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F81949B0F5DEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Benoit, NETCONF WG, below is a summary and action items from the NETCONF WG session on July 22,= 2014, Toronto Canada. - We had approx. 92(!!) participants in the 2 hour NETCONF session, - We reviewed the status of the WG, - We had a discussion on all 6 chartered documents. - Note takers were: Dan Romascanu and Lada Lhotka. Many thanks for voluntee= ring. Chartered items: 1. Reverse Secure Shell (Reverse SSH) - K. Watsen http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh Issues discussed. Some of the issues will be taken to the list. 2. NETCONF Over TLS update - RFC 5539bis - J. Schoenwaelder http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis Issues discussed. Some of the issues will be taken to the list. 3. A YANG Data Model for NETCONF Server Configuration - K. Watsen http://tools.ietf.org/html/draft-ietf-netconf-server Issues discussed. The proposal to provide a I-D draft-ietf-netconf-call-home has been discuss= ed. This draft would replace reverse-ssh and also clean up call home relate= d part in 5539bis. Humming showed that the WG is in favor of this I-D. Base= d on this the co-chairs sent a consensus call to the WG list. AI Co-chairs: Update charter if WG consensus is confirmed. 4. RESTCONF Protocol - A. Bierman http://tools.ietf.org/html/draft-ietf-netconf-restconf Issues discussed. Some of the issues will be taken to the list. 5. YANG Patch Media Type - A. Bierman http://tools.ietf.org/html/draft-ietf-netconf-yang-patch Issue discussed. 6. Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) - K. Watsen http://tools.ietf.org/html/draft-ietf-netconf-zerotouch Issues discussed. AI for the authors of the chartered items: Please provide an update for your draft by September 1st. Non-Chartered items: 1. I2RS Requirements on NETCONF - Jeff Haas I2RS WG will provide a draft describing the requirements on NETCONF. It has been proposed to start a discussion as early as possible to figure o= ut whether single requirements can be already addressed with available NETC= ONF protocol features. AI Jeff Haas: to get the I2RS WG (plus any volunteers) to do this. 2. A NETCONF Extension for Data Fragmentation - G. Zheng http://tools.ietf.org/html/draft-liu-netconf-fragmentation Humming showed that the WG sees the issues as a valid problem. It needs to = be discussed whether it can be addressed with a bis-draft. For the time bei= ng NETCONF charter will not be changed. Once active WG items are finalized = the draft can be re-discussed. 3. Multi-Instances Configuration Issue in NETCONF - G. Yan http://tools.ietf.org/html/draft-liu-netconf-multi-instances The presenter has been proposed that he should check with the I2RS WG as th= ey have similar issues to address. Regards, Mehmet & Bert --_000_E4DE949E6CE3E34993A2FF8AE79131F81949B0F5DEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Benoit, NETCONF WG,
&nbs= p;
below is a summary and action items from the NETCONF WG session on Jul= y 22, 2014, Toronto Canada.
 
- We had approx. 92(!!) participants in the 2 hour NETCONF session,
- We reviewed the status of the WG,
- We had a discussion on all 6 chartere= d documents.
- Note takers were: Dan Romascanu and Lada Lhotka. Many thanks for vol= unteering.
 
C= hartered items:
&= nbsp;
1= . Reverse Secure Shell (Reverse SSH) - K. Watsen
<= a href=3D"http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh">http:/= /tools.ietf.org/html/draft-ietf-netconf-reverse-ssh
I= ssues discussed. Some of the issues will be taken to the list.
&= nbsp;
2= . NETCONF Over TLS update - RFC 5539bis - J.  Schoenwaelder
<= a href=3D"http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis">http://= tools.ietf.org/html/draft-ietf-netconf-rfc5539bis
I= ssues discussed. Some of the issues will be taken to the list.
&= nbsp;
3= . A YANG Data Model for NETCONF Server Configuration - K. Watsen
<= a href=3D"http://tools.ietf.org/html/draft-ietf-netconf-server">http://tool= s.ietf.org/html/draft-ietf-netconf-server
I= ssues discussed.
&= nbsp;
T= he proposal to provide a I-D draft-ietf-netconf-call-home has been discusse= d. This draft would replace reverse-ssh and also clean up call home related= part in 5539bis. Humming showed that the WG is in favor of this I-D. Based on this the co-chairs sent a consensu= s call to the WG list.
A= I Co-chairs: Update charter if WG consensus is confirmed.
&= nbsp;
4= . RESTCONF Protocol - A. Bierman
<= a href=3D"http://tools.ietf.org/html/draft-ietf-netconf-restconf">http://to= ols.ietf.org/html/draft-ietf-netconf-restconf
I= ssues discussed. Some of the issues will be taken to the list.
&= nbsp;
5= . YANG Patch Media Type - A. Bierman
<= a href=3D"http://tools.ietf.org/html/draft-ietf-netconf-yang-patch">http://= tools.ietf.org/html/draft-ietf-netconf-yang-patch
I= ssue discussed.
&= nbsp;
6= . Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) - K. Watsen
<= a href=3D"http://tools.ietf.org/html/draft-ietf-netconf-zerotouch">http://t= ools.ietf.org/html/draft-ietf-netconf-zerotouch
I= ssues discussed.
&= nbsp;
A= I for the authors of the chartered items:
P= lease provide an update for your draft by September 1st.
&= nbsp;
N= on-Chartered items:
&= nbsp;
1= . I2RS Requirements on NETCONF - Jeff Haas
I= 2RS WG will provide a draft describing the requirements on NETCONF.<= /font>
I= t has been proposed to start a discussion as early as possible to figure ou= t whether single requirements can be already addressed with available NETCO= NF protocol features.
A= I Jeff Haas: to get the I2RS WG  (plus any volunteers) to do this.
&= nbsp;
2= . A NETCONF Extension for Data Fragmentation - G. Zheng
<= a href=3D"http://tools.ietf.org/html/draft-liu-netconf-fragmentation">http:= //tools.ietf.org/html/draft-liu-netconf-fragmentation
H= umming showed that the WG sees the issues as a valid problem. It needs to b= e discussed whether it can be addressed with a bis-draft. For the time bein= g NETCONF charter will not be changed. Once active WG items are finalized the draft can be re-discussed.
&= nbsp;
3= . Multi-Instances Configuration Issue in NETCONF - G. Yan
<= a href=3D"http://tools.ietf.org/html/draft-liu-netconf-multi-instances">htt= p://tools.ietf.org/html/draft-liu-netconf-multi-instances=
T= he presenter has been proposed that he should check with the I2RS WG as the= y have similar issues to address.
 
R= egards,
Mehmet & Bert
 
&nbs= p;
 --_000_E4DE949E6CE3E34993A2FF8AE79131F81949B0F5DEMUMBX005nsnin_-- From nobody Mon Jul 28 01:49:57 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2271B27D2 for ; Sun, 27 Jul 2014 18:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 anjQSfBh7yO4 for ; Sun, 27 Jul 2014 18:03:09 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6A411B27D0 for ; Sun, 27 Jul 2014 18:03:08 -0700 (PDT) Received: from [192.168.1.55] (unknown [118.209.32.55]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A465622E1FA; Sun, 27 Jul 2014 21:03:03 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Mark Nottingham In-Reply-To: Date: Mon, 28 Jul 2014 11:03:00 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53714FEC.2030709@cisco.com> <53743F8F.2050308@cisco.com> To: Kent Watsen X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/13IzLETRQA6aX7P_ZCB-Hl6dd1U X-Mailman-Approved-At: Mon, 28 Jul 2014 01:49:55 -0700 Cc: NETCONF Subject: Re: [Netconf] RESTCONF and draft-ietf-appsawg-uri-get-off-my-lawn-04 (on the IESG telechat this week) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 01:03:11 -0000 Hi Kent, This looks good. In a perfect world, the structure of URIs "under" the = restconf resource also would be dynamic, but this is good enough for = get-off-my-lawn purposes. Cheers, On 23 Jul 2014, at 3:42 am, Kent Watsen wrote: >=20 > Hi Mark, >=20 > Thank you for meeting with Andy, Bert, and myself yesterday. We're = happy that you support our use of /.well-known/host-meta as described = here: = http://tools.ietf.org/html/draft-ietf-netconf-restconf-01#section-3.2. = Thank you also for suggesting the draft advise clients to cache the = result using standard HTTP caching, we'll be sure to update the = accordingly. >=20 > Thanks again, > Kent >=20 >=20 > From: Kent Watsen > Date: Thursday, May 15, 2014 at 11:21 AM > To: Benoit Claise , Andy Bierman = > Cc: Mark Nottingham , 'Barry Leiba' = , NetConf > Subject: Re: [Netconf] RESTCONF and = draft-ietf-appsawg-uri-get-off-my-lawn-04 (on the IESG telechat this = week) >=20 >=20 > Hi Mark, thanks for looking in on this! >=20 > Currently RESTCONF hardcodes the top-level URL path "/restconf", which = isn't in line with your BCP. Our thoughts are to put in text like = that below. Looking at rfc6570, I don't see how URI templates would = help here. Can you suggest a better way? - or were you thinking that = we could use URI Templates to define the structure of the RESTCONF API's = URLs? >=20 > Thanks, > Kent >=20 > =3D=3D=3D=3D=3DSTART=3D=3D=3D=3D=3D >=20 > RESTCONF Path Resolution >=20 > In line the best practices defined by "get-off-my-lawn", RESTCONF > enables deployments to specify where the RESTCONF API is located. > When first connecting to a RESTCONF server, a RESTCONF client MUST > determine the root of the RESTCONF API. The client discovers this > by getting the ".well-known/host-meta" resource [RFC6415] as = follows: >=20 > Request > ------- > GET /.well-known/host-meta users HTTP/1.1 > Host: example.com > Accept: application/xrd+xml >=20 > Response > -------- > HTTP/1.1 200 OK > Content-Type: application/xrd+xml > Content-Length: nnn >=20 > > > >=20 >=20 > Once discovering the RESTCONF API root, the client MUST prepend it = to > any access to a RESTCONF resource. For instance, using the = "/api/restconf" > path discovered above, the client can now determine the version of=20= > RESTCONF protocol as follows: >=20 > Request > ------- > GET /api/restconf/version HTTP/1.1 > Host: example.com > Accept: application/yang.api+json >=20 > Response > -------- > HTTP/1.1 200 OK > Date: Mon, 23 Apr 2012 17:01:00 GMT > Server: example-server > Cache-Control: no-cache > Pragma: no-cache > Last-Modified: Sun, 22 Apr 2012 01:00:14 GMT > Content-Type: application/yang.api+json >=20 > { "version": "1.0" } >=20 >=20 > =3D=3D=3D=3D=3D STOP =3D=3D=3D=3D=3D >=20 >=20 >=20 > From: Benoit Claise > Date: Thursday, May 15, 2014 at 12:16 AM > To: Andy Bierman , Kent Watsen = > Cc: NetConf , 'Barry Leiba' = , Mark Nottingham > Subject: Re: [Netconf] RESTCONF and = draft-ietf-appsawg-uri-get-off-my-lawn-04 (on the IESG telechat this = week) >=20 > Dear all, >=20 > Discussing this issue with Barry: >> Yes, .well-known is a possible solution for netconf/restconf. = Another possibility is URI templates. The get-off-my-lawn document = talks about both. For restconf, Mark Nottingham could help advise which = would be a better option for them. > Regards, Benoit >>=20 >>=20 >> On Tue, May 13, 2014 at 11:53 AM, Kent Watsen = wrote: >>>=20 >>> Andy writes: >>>> I think RESTCONF violates sec 2.3 wrt/ structure within the URI = path. >>> >>>=20 >>> I agree with Andy that RESTCONF violates section 2.3. I also think = that we can remove that violation by supporting "well-known" URIs. = Notice that the 2nd paragraph in section 2.3 says "The only exception to = this requirement is registered 'well-known' URIs, as specified by = [RFC5785]." My reading is, if we use a "well-known" URI, then our = subtree can defined sub-structure per RESTCONF convention. >>>=20 >>> We discussed using well-known URIs before. Appendix B.3. in the = RESTCONF draft ("Open Issues") regards ".well-known usage". This issue = was closed with the resolution "not needed in RESTCONF". We may need = to revisit that decision now. >>>=20 >>=20 >> I agree we need to support .well-known to conform to this BCP. >> =20 >>> Thanks, >>> Kent >>>=20 >>=20 >> Andy >>=20 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Mon Jul 28 08:12:03 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C261A0303 for ; Mon, 28 Jul 2014 08:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 oMZ047DN8mxO for ; Mon, 28 Jul 2014 08:11:52 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D602A1A03C1 for ; Mon, 28 Jul 2014 08:11:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1972; q=dns/txt; s=iport; t=1406560310; x=1407769910; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=whEd34APD+HP0m5HSHJt+bd2M3FCZWAeorJVJGWVefE=; b=KRm/5Cwz8d37sEZZMBrWKOKvZG61Pg/FGgvDouiMmk2+r/ZtZ71f9nSG l2n9RxGmihejIHaFDYtOYloK1C7U0lPYXkne3OU0NI1EKluY1b7PN/eP6 tNtM93ZA8bhg0VTdrbFZSh1YyqAsY9Xk3wFPR+FsoT8e3hKEirAbtxLzP A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGFn1lOtJV2Z/2dsb2JhbABZgw6BLYJ00HF2FneECiMRVwEiAiYCBDAVEgSIVZd0jyiXBxeBLI08g2SBUQWwGINJgW9C X-IronPort-AV: E=Sophos;i="5.01,749,1400025600"; d="scan'208";a="343427626" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 28 Jul 2014 15:11:50 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6SFBomW025756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 28 Jul 2014 15:11:50 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.17]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Mon, 28 Jul 2014 10:11:50 -0500 From: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" To: "netconf@ietf.org" Thread-Topic: edit-config operation inconsistency Thread-Index: AQHPqnZB5nc9S5Cy80+vi7aEiv9A/w== Date: Mon, 28 Jul 2014 15:11:49 +0000 Message-ID: <1406560309.12287.21.camel@ksekera-fedora> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.220.188] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/z8rNLnrHyblqqajHcOCFtpdV7CM Subject: [Netconf] edit-config operation inconsistency X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 15:12:01 -0000 SGkgYWxsLA0KDQp3ZSBhcmUgY3VycmVudGx5IGRlYmF0aW5nIGFuIGlzc3VlIHdlIGZvdW5kIGFu ZCB3b3VsZCBsaWtlIHRvIGhhdmUgc29tZQ0KY2xhcmlmaWNhdGlvbi4gTmV0Y29uZiBSRkMgc2F5 cyB0aGF0IHRoZSBlZGl0LWNvbmZpZyBvcGVyYXRpb24gd2hpY2gNCmNvbnRhaW5zIG11bHRpcGxl IHN1Yi1vcGVyYXRpb25zIG9uIHRoZSBzYW1lIGRhdGEgaXMgdW5kZWZpbmVkLiANCg0Kc28gd2hl biBjb25zaWRlcmluZyB0aGlzIHJlcXVlc3Q6DQoNCjxlZGl0LWNvbmZpZz4NCjx0YXJnZXQ+PGNh bmRpZGF0ZS8+PC90YXJnZXQ+DQo8Y29uZmlnPg0KIDxjb250YWluZXIgb3BlcmF0aW9uPSJkZWxl dGUiPg0KICA8bGVhZiBvcGVyYXRpb249ImNyZWF0ZSIvPg0KIDwvY29udGFpbmVyPg0KPC9jb25m aWc+DQo8L2VkaXQtY29uZmlnPg0KDQp0aGUgb3V0Y29tZSBpcyB1bmRlZmluZWQsIHNpbmNlIHRo ZSBjbGllbnQgd2FudHMgZG8gZGVsZXRlIGNvbnRhaW5lcg0KPGNvbnRhaW5lcj4sIHdoaWxlIHNp bXVsdGFuZW91c2x5IGNyZWF0aW5nIDxsZWFmPiB3aGljaCBpcyBwYXJ0IG9mDQo8Y29udGFpbmVy Pi4NCg0KTm93LCB3aGVuIGNvbnNpZGVyaW5nIGEgc2ltcGxlIGxpc3QgZGVsZXRpb246DQoNCjxl ZGl0LWNvbmZpZz4NCjx0YXJnZXQ+PGNhbmRpZGF0ZS8+PC90YXJnZXQ+DQo8Y29uZmlnPg0KIDxs aXN0IG9wZXJhdGlvbj0iZGVsZXRlIj4NCiAgPGtleS1ub2RlPmtleS12YWx1ZTwva2V5LW5vZGU+ DQogPC9saXN0Pg0KPC9jb25maWc+DQo8L2VkaXQtY29uZmlnPg0KDQphbmQgcmlnb3JvdXNseSBy ZWFkaW5nIHRoZSBSRkMgcmVnYXJkaW5nIG9wZXJhdGlvbiBhbmQNCmRlZmF1bHQtb3BlcmF0aW9u LCB0aGUgb3BlcmF0aW9uIGF0dHJpYnV0ZSBmb3IgPGtleS1ub2RlPiBpcyAibWVyZ2UiLA0KdGh1 cywgdGVjaG5pY2FsbHksIHRoaXMgZWRpdC1jb25maWcgb3BlcmF0aW9uIG9wZXJhdGVzIG9uIHRo ZSA8a2V5LW5vZGU+DQp0d2ljZToNCg0KMS4pIGRlbGV0aW5nIHRoZSB2YWx1ZSB2aWEgZGVsZXRp b24gb2YgdGhlIGxpc3QgZW50aXR5IDxsaXN0Pg0KMi4pIG1lcmdpbmcgaW4gYSBuZXcgdmFsdWUg dmlhICJtZXJnZSIgb24gdGhlIDxrZXktbm9kZT4NCg0KDQpUaGUgUkZDIGhhcyA8ZGVmYXVsdC1v cGVyYXRpb24+bm9uZTwvZGVmYXVsdC1vcGVyYXRpb24+IGluIGFsbCBkZWxldGlvbg0KZXhhbXBs ZXMsIHdoaWNoIG1ha2VzIHVzIGJlbGlldmUgdGhhdCBpbmRlZWQgd2hlbiBwcm9jZXNzaW5nIHRo ZQ0KbWVudGlvbmVkIHJlcXVlc3QsIHRoZSA8a2V5LW5vZGU+J3Mgb3BlcmF0aW9uIHdvdWxkIGJl ICJtZXJnZSIgYW5kIHRodXMNCnRoZSBvcGVyYXRpb24gdW5kZWZpbmVkLg0KDQpJcyB0aGlzIGhv dyBpdCdzIHN1cHBvc2VkIHRvIGJlIG9yIGFyZSB3ZSByZWFkaW5nIGl0IHdyb25nPw0KDQpUaGFu a3MsDQpLbGVtZW50DQo= From nobody Mon Jul 28 08:22:49 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACBE1A02E6 for ; Mon, 28 Jul 2014 08:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 OOFda1qvWq9d for ; Mon, 28 Jul 2014 08:22:41 -0700 (PDT) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 151B31B28B5 for ; Mon, 28 Jul 2014 08:22:39 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id q107so8524448qgd.26 for ; Mon, 28 Jul 2014 08:22:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZESPvARdKy89lRj2EB3uA94Gu/HsbVYGYdosZfqkdpI=; b=f8Lr3/jd5PKFVNQXJcC+x8+5Ne0OGB5ZRj2ae9iFQ6QgdzKXz00di8G1SkY6aekRC/ J3O41fNc3EsYK01aj8w/jy+IqXs4ElKCRdNPea5fgToVXfIVQYX0N93A9J06SEwuu60i KmJL07tkgymcRoRV/z4iU5uweqIUoZs0+ojlzsATrwk/PMHtQzYoUCe1mMJwXqly/OIZ a53vJIlxDZV6dabO8BpAyQ8h4prGsRC8GHXAMYSxfzDl2q2I2R3MHIMqbzD2wKlVdpGy NG0R2D3GdhoKqITWrdLWrRzBLaaTSfCim05/LHxUjEy3oAxxQIA1DpnRJgYN8TFfn6CX 8ckA== X-Gm-Message-State: ALoCoQkAkJGutrcXfeuUA336KxeO99tgP7b6LiExcPLOzdmAzdXw26BMxvrffTiUk8I27A4KMG/n MIME-Version: 1.0 X-Received: by 10.224.126.66 with SMTP id b2mr59232423qas.99.1406560958157; Mon, 28 Jul 2014 08:22:38 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Mon, 28 Jul 2014 08:22:38 -0700 (PDT) In-Reply-To: <1406560309.12287.21.camel@ksekera-fedora> References: <1406560309.12287.21.camel@ksekera-fedora> Date: Mon, 28 Jul 2014 08:22:38 -0700 Message-ID: From: Andy Bierman To: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" Content-Type: multipart/alternative; boundary=001a11c2f98e442f6a04ff427e89 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/CutrVUiGknROf57yeali0n50T6k Cc: "netconf@ietf.org" Subject: Re: [Netconf] edit-config operation inconsistency X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 15:22:46 -0000 --001a11c2f98e442f6a04ff427e89 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 28, 2014 at 8:11 AM, Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco) wrote: > Hi all, > > we are currently debating an issue we found and would like to have some > clarification. Netconf RFC says that the edit-config operation which > contains multiple sub-operations on the same data is undefined. > > so when considering this request: > > > > > > > > > > > the outcome is undefined, since the client wants do delete container > , while simultaneously creating which is part of > . > > It is defined. Does the node /container exist in the target datastore? If yes, then the create operation on /container/leaf MUST fail. If no, then the delete operation on /container MUST fail. > Now, when considering a simple list deletion: > > > > > > key-value > > > > > and rigorously reading the RFC regarding operation and > default-operation, the operation attribute for is "merge", > thus, technically, this edit-config operation operates on the > twice: > The operation is inherited from its parent if no "nc:operation" attribute is specified. The keys need to be present to specify the list node to be deleted. > 1.) deleting the value via deletion of the list entity > 2.) merging in a new value via "merge" on the > > > The RFC has none in all deletion > examples, which makes us believe that indeed when processing the > mentioned request, the 's operation would be "merge" and thus > the operation undefined. > > Is this how it's supposed to be or are we reading it wrong? > > the latter > Thanks, > Klement > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11c2f98e442f6a04ff427e89 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jul 28, 2014 at 8:11 AM, Klement Sekera -X (ksekera - Panth= eon Technologies SRO at Cisco) <ksekera@cisco.com> wrote:
Hi all,

we are currently debating an issue we found and would like to have some
clarification. Netconf RFC says that the edit-config operation which
contains multiple sub-operations on the same data is undefined.

so when considering this request:

<edit-config>
<target><candidate/></target>
<config>
=A0<container operation=3D"delete">
=A0 <leaf operation=3D"create"/>
=A0</container>
</config>
</edit-config>

the outcome is undefined, since the client wants do delete container
<container>, while simultaneously creating <leaf> which is part= of
<container>.


It is defined.
Does the node= /container exist in the target datastore?
If yes, then the creat= e operation on /container/leaf MUST fail.
If no, then the delete = operation on /container MUST fail.

=A0
Now, when considering a simple list deletion:

<edit-config>
<target><candidate/></target>
<config>
=A0<list operation=3D"delete">
=A0 <key-node>key-value</key-node>
=A0</list>
</config>
</edit-config>

and rigorously reading the RFC regarding operation and
default-operation, the operation attribute for <key-node> is "me= rge",
thus, technically, this edit-config operation operates on the <key-node&= gt;
twice:

The operation is inherited from = its parent if no "nc:operation"
attribute is specified.= The keys need to be present to specify the list
node to be delet= ed.=A0



1.) deleting the value via deletion of the list entity <list>
2.) merging in a new value via "merge" on the <key-node>

The RFC has <default-operation>none</default-operation> in all = deletion
examples, which makes us believe that indeed when processing the
mentioned request, the <key-node>'s operation would be "merg= e" and thus
the operation undefined.

Is this how it's supposed to be or are we reading it wrong?


the latter
=A0
Thanks,
Klement
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--001a11c2f98e442f6a04ff427e89-- From nobody Mon Jul 28 08:31:54 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1FB1A0385 for ; Mon, 28 Jul 2014 08:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 eJ0iNgP82bpI for ; Mon, 28 Jul 2014 08:31:49 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C507A1B283D for ; Mon, 28 Jul 2014 08:31:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3576; q=dns/txt; s=iport; t=1406561510; x=1407771110; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HCtRwON8wJsUZySTYPuCI77lhH8Ettd5WTvQRW/fkKo=; b=iLs3lx78CvtvHlT2NkOt2vjOfDvu22puj1bv7Lsco07nzuaUErTaxmYd GfbdlQgJG9kmzmTjWJ+lm68Tuhvy1GNXcG30CpyyQqOZ8BVC0RdL4jQ/h yMqV6QiQHF8PZ0eXBz/Svp3BLOmQAfQPop+vDFoMKi0fwGd3jUdPRKr7k c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAGBs1lOtJV2d/2dsb2JhbABZgw5SVwSCdMkICoZyUwEZdhZ3hAQBAQQBAQEgEToLEAIBCBgCAiYCAgIlCxUQAgQOBYhCDacYlwcTBIEsjTwxMweCeYFRBbAYg0lsgQNC X-IronPort-AV: E=Sophos;i="5.01,749,1400025600"; d="scan'208";a="343362983" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 28 Jul 2014 15:31:48 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s6SFVmm5010073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jul 2014 15:31:48 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.17]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Mon, 28 Jul 2014 10:31:47 -0500 From: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" To: "andy@yumaworks.com" Thread-Topic: [Netconf] edit-config operation inconsistency Thread-Index: AQHPqnZB7zgA6VWc9UyRPcHJnzYLfZu17mwAgAACj4A= Date: Mon, 28 Jul 2014 15:31:47 +0000 Message-ID: <1406561507.12287.24.camel@ksekera-fedora> References: <1406560309.12287.21.camel@ksekera-fedora> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.220.188] Content-Type: text/plain; charset="utf-8" Content-ID: <9BD4C429F0D28A41AB0860628B79DA10@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/J5PaSnB2gMpdb9RCgA0m73XJHRQ Cc: "netconf@ietf.org" Subject: Re: [Netconf] edit-config operation inconsistency X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 15:31:52 -0000 T24gTW9uLCAyMDE0LTA3LTI4IGF0IDA4OjIyIC0wNzAwLCBBbmR5IEJpZXJtYW4gd3JvdGU6DQo+ IE9uIE1vbiwgSnVsIDI4LCAyMDE0IGF0IDg6MTEgQU0sIEtsZW1lbnQgU2VrZXJhIC1YIChrc2Vr ZXJhIC0gUGFudGhlb24NCj4gVGVjaG5vbG9naWVzIFNSTyBhdCBDaXNjbykgPGtzZWtlcmFAY2lz Y28uY29tPiB3cm90ZToNCj4gDQo+ID4gSGkgYWxsLA0KPiA+DQo+ID4gd2UgYXJlIGN1cnJlbnRs eSBkZWJhdGluZyBhbiBpc3N1ZSB3ZSBmb3VuZCBhbmQgd291bGQgbGlrZSB0byBoYXZlIHNvbWUN Cj4gPiBjbGFyaWZpY2F0aW9uLiBOZXRjb25mIFJGQyBzYXlzIHRoYXQgdGhlIGVkaXQtY29uZmln IG9wZXJhdGlvbiB3aGljaA0KPiA+IGNvbnRhaW5zIG11bHRpcGxlIHN1Yi1vcGVyYXRpb25zIG9u IHRoZSBzYW1lIGRhdGEgaXMgdW5kZWZpbmVkLg0KPiA+DQo+ID4gc28gd2hlbiBjb25zaWRlcmlu ZyB0aGlzIHJlcXVlc3Q6DQo+ID4NCj4gPiA8ZWRpdC1jb25maWc+DQo+ID4gPHRhcmdldD48Y2Fu ZGlkYXRlLz48L3RhcmdldD4NCj4gPiA8Y29uZmlnPg0KPiA+ICA8Y29udGFpbmVyIG9wZXJhdGlv bj0iZGVsZXRlIj4NCj4gPiAgIDxsZWFmIG9wZXJhdGlvbj0iY3JlYXRlIi8+DQo+ID4gIDwvY29u dGFpbmVyPg0KPiA+IDwvY29uZmlnPg0KPiA+IDwvZWRpdC1jb25maWc+DQo+ID4NCj4gPiB0aGUg b3V0Y29tZSBpcyB1bmRlZmluZWQsIHNpbmNlIHRoZSBjbGllbnQgd2FudHMgZG8gZGVsZXRlIGNv bnRhaW5lcg0KPiA+IDxjb250YWluZXI+LCB3aGlsZSBzaW11bHRhbmVvdXNseSBjcmVhdGluZyA8 bGVhZj4gd2hpY2ggaXMgcGFydCBvZg0KPiA+IDxjb250YWluZXI+Lg0KPiA+DQo+ID4NCj4gSXQg aXMgZGVmaW5lZC4NCj4gRG9lcyB0aGUgbm9kZSAvY29udGFpbmVyIGV4aXN0IGluIHRoZSB0YXJn ZXQgZGF0YXN0b3JlPw0KPiBJZiB5ZXMsIHRoZW4gdGhlIGNyZWF0ZSBvcGVyYXRpb24gb24gL2Nv bnRhaW5lci9sZWFmIE1VU1QgZmFpbC4NCj4gSWYgbm8sIHRoZW4gdGhlIGRlbGV0ZSBvcGVyYXRp b24gb24gL2NvbnRhaW5lciBNVVNUIGZhaWwuDQoNCndoYXQgaWYgL2NvbnRhaW5lciBleGlzdHMg YnV0IC9jb250YWluZXIvbGVhZiBkb2VzIG5vdD8gdGhpcyB3YXkgYm90aA0Kc3ViLW9wZXJhdGlv bnMgY291bGQgYmUgcGVyZm9ybWVkDQoNCj4gDQo+IA0KPiANCj4gPiBOb3csIHdoZW4gY29uc2lk ZXJpbmcgYSBzaW1wbGUgbGlzdCBkZWxldGlvbjoNCj4gPg0KPiA+IDxlZGl0LWNvbmZpZz4NCj4g PiA8dGFyZ2V0PjxjYW5kaWRhdGUvPjwvdGFyZ2V0Pg0KPiA+IDxjb25maWc+DQo+ID4gIDxsaXN0 IG9wZXJhdGlvbj0iZGVsZXRlIj4NCj4gPiAgIDxrZXktbm9kZT5rZXktdmFsdWU8L2tleS1ub2Rl Pg0KPiA+ICA8L2xpc3Q+DQo+ID4gPC9jb25maWc+DQo+ID4gPC9lZGl0LWNvbmZpZz4NCj4gPg0K PiA+IGFuZCByaWdvcm91c2x5IHJlYWRpbmcgdGhlIFJGQyByZWdhcmRpbmcgb3BlcmF0aW9uIGFu ZA0KPiA+IGRlZmF1bHQtb3BlcmF0aW9uLCB0aGUgb3BlcmF0aW9uIGF0dHJpYnV0ZSBmb3IgPGtl eS1ub2RlPiBpcyAibWVyZ2UiLA0KPiA+IHRodXMsIHRlY2huaWNhbGx5LCB0aGlzIGVkaXQtY29u ZmlnIG9wZXJhdGlvbiBvcGVyYXRlcyBvbiB0aGUgPGtleS1ub2RlPg0KPiA+IHR3aWNlOg0KPiA+ DQo+IA0KPiBUaGUgb3BlcmF0aW9uIGlzIGluaGVyaXRlZCBmcm9tIGl0cyBwYXJlbnQgaWYgbm8g Im5jOm9wZXJhdGlvbiINCj4gYXR0cmlidXRlIGlzIHNwZWNpZmllZC4gVGhlIGtleXMgbmVlZCB0 byBiZSBwcmVzZW50IHRvIHNwZWNpZnkgdGhlIGxpc3QNCj4gbm9kZSB0byBiZSBkZWxldGVkLg0K DQpjYW4geW91IHBvaW50IHRvIHRoZSBwYXJhZ3JhcGggaW4gbmV0Y29uZiBSRkMgd2hpY2ggc2F5 cyB0aGF0IHRoZQ0Kb3BlcmF0aW9uIGlzIGluaGVyaXRlZD8NCg0KPiANCj4gDQo+IA0KPiA+IDEu KSBkZWxldGluZyB0aGUgdmFsdWUgdmlhIGRlbGV0aW9uIG9mIHRoZSBsaXN0IGVudGl0eSA8bGlz dD4NCj4gPiAyLikgbWVyZ2luZyBpbiBhIG5ldyB2YWx1ZSB2aWEgIm1lcmdlIiBvbiB0aGUgPGtl eS1ub2RlPg0KPiA+DQo+ID4NCj4gPiBUaGUgUkZDIGhhcyA8ZGVmYXVsdC1vcGVyYXRpb24+bm9u ZTwvZGVmYXVsdC1vcGVyYXRpb24+IGluIGFsbCBkZWxldGlvbg0KPiA+IGV4YW1wbGVzLCB3aGlj aCBtYWtlcyB1cyBiZWxpZXZlIHRoYXQgaW5kZWVkIHdoZW4gcHJvY2Vzc2luZyB0aGUNCj4gPiBt ZW50aW9uZWQgcmVxdWVzdCwgdGhlIDxrZXktbm9kZT4ncyBvcGVyYXRpb24gd291bGQgYmUgIm1l cmdlIiBhbmQgdGh1cw0KPiA+IHRoZSBvcGVyYXRpb24gdW5kZWZpbmVkLg0KPiA+DQo+ID4gSXMg dGhpcyBob3cgaXQncyBzdXBwb3NlZCB0byBiZSBvciBhcmUgd2UgcmVhZGluZyBpdCB3cm9uZz8N Cj4gPg0KPiA+DQo+IHRoZSBsYXR0ZXINCj4gDQo+IA0KPiA+IFRoYW5rcywNCj4gPiBLbGVtZW50 DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+IE5ldGNvbmZAaWV0Zi5vcmcNCj4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gPg0KDQo= From nobody Mon Jul 28 08:43:19 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274D71B28D4 for ; Mon, 28 Jul 2014 08:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 liF7q3WHkzWK for ; Mon, 28 Jul 2014 08:43:10 -0700 (PDT) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2F0F1B28D7 for ; Mon, 28 Jul 2014 08:43:09 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id v10so8062867qac.12 for ; Mon, 28 Jul 2014 08:43:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kF5B1cNh9hCN0CbMYMO8h7JN03bi6kqki2BWSbSYme8=; b=UQg4ofK+5hN3YgEq382t759HdJyLBSyT7/v4QOF5U0whGl607nYHfqF11ngKQrn9lN P2R5SkmseKLL77kN2aw5NK9aISWQMwbIjfptfPXmseDWUJV8iPieChgNzPbGFRvhbEb6 OzIkwfcsENOTTbe853yKsSvmLV8oLbuc7eigCq6b08Xs7AQC+vd+UB+DzeGxOs5cKgCu /dOWVGCIbCwh5tiP8hmMlDJ2wbcYyIbOepYoMKjePtCW6ZI0JVBJdpSQa1NvEYKq8UCu 21K9imqRqpmWU/0DgVPhyZ1pYW7RaLETxRbGpzOyDvJoMok565wz7I2/scIUBC4V+TId s0DA== X-Gm-Message-State: ALoCoQn/y2n6acEyg8LLhnFaPqeikLGc1oRJY53uooOqgujPuZsHYT+EpgHJbzPslDEpqDZYAojr MIME-Version: 1.0 X-Received: by 10.140.94.197 with SMTP id g63mr5549345qge.90.1406562189184; Mon, 28 Jul 2014 08:43:09 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Mon, 28 Jul 2014 08:43:09 -0700 (PDT) In-Reply-To: <1406561507.12287.24.camel@ksekera-fedora> References: <1406560309.12287.21.camel@ksekera-fedora> <1406561507.12287.24.camel@ksekera-fedora> Date: Mon, 28 Jul 2014 08:43:09 -0700 Message-ID: From: Andy Bierman To: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" Content-Type: multipart/alternative; boundary=001a113a22baa456c504ff42c7d0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/a0_6Xq2b_KUCEmdJlTiI6TVANAw Cc: "netconf@ietf.org" Subject: Re: [Netconf] edit-config operation inconsistency X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 15:43:12 -0000 --001a113a22baa456c504ff42c7d0 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 28, 2014 at 8:31 AM, Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco) wrote: > On Mon, 2014-07-28 at 08:22 -0700, Andy Bierman wrote: > > On Mon, Jul 28, 2014 at 8:11 AM, Klement Sekera -X (ksekera - Pantheon > > Technologies SRO at Cisco) wrote: > > > > > Hi all, > > > > > > we are currently debating an issue we found and would like to have some > > > clarification. Netconf RFC says that the edit-config operation which > > > contains multiple sub-operations on the same data is undefined. > > > > > > so when considering this request: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the outcome is undefined, since the client wants do delete container > > > , while simultaneously creating which is part of > > > . > > > > > > > > It is defined. > > Does the node /container exist in the target datastore? > > If yes, then the create operation on /container/leaf MUST fail. > > If no, then the delete operation on /container MUST fail. > > what if /container exists but /container/leaf does not? this way both > sub-operations could be performed > not really. If implemented correctly then if the delete on /container succeeds, then all its descendants are also deleted. The result in the target datastore cannot possibly complete both a delete on an ancestor and create of a descendant in the same edit. Our server returns an error because it cannot honor both requests. > > > > > > > > > > Now, when considering a simple list deletion: > > > > > > > > > > > > > > > > > > key-value > > > > > > > > > > > > > > > and rigorously reading the RFC regarding operation and > > > default-operation, the operation attribute for is "merge", > > > thus, technically, this edit-config operation operates on the > > > > twice: > > > > > > > The operation is inherited from its parent if no "nc:operation" > > attribute is specified. The keys need to be present to specify the list > > node to be deleted. > > can you point to the paragraph in netconf RFC which says that the > operation is inherited? > > the delete operation on the /container node is for the container and all its descendants. That is how it is inherited. I should have said "effective" operation instead of "inherited". > > > > > > > > 1.) deleting the value via deletion of the list entity > > > 2.) merging in a new value via "merge" on the > > > > > > > > > The RFC has none in all deletion > > > examples, which makes us believe that indeed when processing the > > > mentioned request, the 's operation would be "merge" and thus > > > the operation undefined. > > > > > > Is this how it's supposed to be or are we reading it wrong? > > > > > > > > the latter > > > > > > > Thanks, > > > Klement > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > Andy --001a113a22baa456c504ff42c7d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jul 28, 2014 at 8:31 AM, Klement Sekera -X (ksekera - Panth= eon Technologies SRO at Cisco) <ksekera@cisco.com> wrote:
On Mon, 2014-07-28 at 08:22 -0700, Andy Bier= man wrote:
> On Mon, Jul 28, 2014 at 8:11 AM, Klement Sekera -X (ksekera - Pantheon=
> Technologies SRO at Cisco) <ks= ekera@cisco.com> wrote:
>
> > Hi all,
> >
> > we are currently debating an issue we found and would like to hav= e some
> > clarification. Netconf RFC says that the edit-config operation wh= ich
> > contains multiple sub-operations on the same data is undefined. > >
> > so when considering this request:
> >
> > <edit-config>
> > <target><candidate/></target>
> > <config>
> > =A0<container operation=3D"delete">
> > =A0 <leaf operation=3D"create"/>
> > =A0</container>
> > </config>
> > </edit-config>
> >
> > the outcome is undefined, since the client wants do delete contai= ner
> > <container>, while simultaneously creating <leaf> whi= ch is part of
> > <container>.
> >
> >
> It is defined.
> Does the node /container exist in the target datastore?
> If yes, then the create operation on /container/leaf MUST fail.
> If no, then the delete operation on /container MUST fail.

what if /container exists but /container/leaf does not? this way both
sub-operations could be performed


<= /div>
not really. If implemented correctly then if the delete on /conta= iner succeeds,
then all its descendants are also deleted. =A0The = result in the target datastore cannot
possibly complete both a delete on an ancestor and create of a descend= ant
in the same edit. Our server returns an error because it cann= ot honor
both requests.


=A0

>
>
>
> > Now, when considering a simple list deletion:
> >
> > <edit-config>
> > <target><candidate/></target>
> > <config>
> > =A0<list operation=3D"delete">
> > =A0 <key-node>key-value</key-node>
> > =A0</list>
> > </config>
> > </edit-config>
> >
> > and rigorously reading the RFC regarding operation and
> > default-operation, the operation attribute for <key-node> i= s "merge",
> > thus, technically, this edit-config operation operates on the <= ;key-node>
> > twice:
> >
>
> The operation is inherited from its parent if no "nc:operation&qu= ot;
> attribute is specified. The keys need to be present to specify the lis= t
> node to be deleted.

can you point to the paragraph in netconf RFC which says that the
operation is inherited?


the delete operation on the /container= node is for the container and all its
descendants. =A0That is ho= w it is inherited. I should have said "effective" operation
instead of "inherited".


<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> >
>
>
> > 1.) deleting the value via deletion of the list entity <list&g= t;
> > 2.) merging in a new value via "merge" on the <key-n= ode>
> >
> >
> > The RFC has <default-operation>none</default-operation&g= t; in all deletion
> > examples, which makes us believe that indeed when processing the<= br> > > mentioned request, the <key-node>'s operation would be = "merge" and thus
> > the operation undefined.
> >
> > Is this how it's supposed to be or are we reading it wrong? > >
> >
> the latter
>
>
> > Thanks,
> > Klement
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> >


Andy

--001a113a22baa456c504ff42c7d0-- From nobody Tue Jul 29 00:44:26 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1DC1A026A for ; Tue, 29 Jul 2014 00:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 yD_2HpPyQ3Hw for ; Tue, 29 Jul 2014 00:44:23 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFE6F1ADDB5 for ; Tue, 29 Jul 2014 00:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7034; q=dns/txt; s=iport; t=1406619863; x=1407829463; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/V+yHSM0Zv2vCmgTrxxTZcqux4ZuZk08bL88pp1dJGc=; b=cfgydb4bMfldU2KgkN/OAd0/y+FvmG53dAj7Plos1wTZ/dOB3aUZjO4R G7eMpO0EZZg9WotbMxXCSzw2Xvrig9RRt/zBCtVwL2Z3eAamfLGBVFNkX v3ZC5JDSCADXBbCPGN8FdyGlYZILk/LjdHKdd7XgYCaTwpvH5D7nswVhv U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAOxP11OtJA2I/2dsb2JhbABZgw5SVwSCdMhpCoZ4UwEZeRZ3hAQBAQQBAQEgEToLEAIBCBgCAiYCAgIlCxUQAgQOBYhCDadal1wTBIEsjTxkB4J5gVEFsBqDSWyBA0I X-IronPort-AV: E=Sophos;i="5.01,755,1400025600"; d="scan'208";a="343324252" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-1.cisco.com with ESMTP; 29 Jul 2014 07:44:22 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6T7iMjx009009 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jul 2014 07:44:22 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.17]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 29 Jul 2014 02:44:22 -0500 From: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" To: "andy@yumaworks.com" Thread-Topic: [Netconf] edit-config operation inconsistency Thread-Index: AQHPqnZB7zgA6VWc9UyRPcHJnzYLfZu17mwAgAACj4CAAAMtgIABDIyA Date: Tue, 29 Jul 2014 07:44:20 +0000 Message-ID: <1406619859.12287.31.camel@ksekera-fedora> References: <1406560309.12287.21.camel@ksekera-fedora> <1406561507.12287.24.camel@ksekera-fedora> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.221.176] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/VuJm3TYVWBiTwjtXirG8oAdzEAM Cc: "netconf@ietf.org" Subject: Re: [Netconf] edit-config operation inconsistency X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 07:44:25 -0000 T24gTW9uLCAyMDE0LTA3LTI4IGF0IDA4OjQzIC0wNzAwLCBBbmR5IEJpZXJtYW4gd3JvdGU6DQo+ IE9uIE1vbiwgSnVsIDI4LCAyMDE0IGF0IDg6MzEgQU0sIEtsZW1lbnQgU2VrZXJhIC1YIChrc2Vr ZXJhIC0gUGFudGhlb24NCj4gVGVjaG5vbG9naWVzIFNSTyBhdCBDaXNjbykgPGtzZWtlcmFAY2lz Y28uY29tPiB3cm90ZToNCj4gDQo+ID4gT24gTW9uLCAyMDE0LTA3LTI4IGF0IDA4OjIyIC0wNzAw LCBBbmR5IEJpZXJtYW4gd3JvdGU6DQo+ID4gPiBPbiBNb24sIEp1bCAyOCwgMjAxNCBhdCA4OjEx IEFNLCBLbGVtZW50IFNla2VyYSAtWCAoa3Nla2VyYSAtIFBhbnRoZW9uDQo+ID4gPiBUZWNobm9s b2dpZXMgU1JPIGF0IENpc2NvKSA8a3Nla2VyYUBjaXNjby5jb20+IHdyb3RlOg0KPiA+ID4NCj4g PiA+ID4gSGkgYWxsLA0KPiA+ID4gPg0KPiA+ID4gPiB3ZSBhcmUgY3VycmVudGx5IGRlYmF0aW5n IGFuIGlzc3VlIHdlIGZvdW5kIGFuZCB3b3VsZCBsaWtlIHRvIGhhdmUgc29tZQ0KPiA+ID4gPiBj bGFyaWZpY2F0aW9uLiBOZXRjb25mIFJGQyBzYXlzIHRoYXQgdGhlIGVkaXQtY29uZmlnIG9wZXJh dGlvbiB3aGljaA0KPiA+ID4gPiBjb250YWlucyBtdWx0aXBsZSBzdWItb3BlcmF0aW9ucyBvbiB0 aGUgc2FtZSBkYXRhIGlzIHVuZGVmaW5lZC4NCj4gPiA+ID4NCj4gPiA+ID4gc28gd2hlbiBjb25z aWRlcmluZyB0aGlzIHJlcXVlc3Q6DQo+ID4gPiA+DQo+ID4gPiA+IDxlZGl0LWNvbmZpZz4NCj4g PiA+ID4gPHRhcmdldD48Y2FuZGlkYXRlLz48L3RhcmdldD4NCj4gPiA+ID4gPGNvbmZpZz4NCj4g PiA+ID4gIDxjb250YWluZXIgb3BlcmF0aW9uPSJkZWxldGUiPg0KPiA+ID4gPiAgIDxsZWFmIG9w ZXJhdGlvbj0iY3JlYXRlIi8+DQo+ID4gPiA+ICA8L2NvbnRhaW5lcj4NCj4gPiA+ID4gPC9jb25m aWc+DQo+ID4gPiA+IDwvZWRpdC1jb25maWc+DQo+ID4gPiA+DQo+ID4gPiA+IHRoZSBvdXRjb21l IGlzIHVuZGVmaW5lZCwgc2luY2UgdGhlIGNsaWVudCB3YW50cyBkbyBkZWxldGUgY29udGFpbmVy DQo+ID4gPiA+IDxjb250YWluZXI+LCB3aGlsZSBzaW11bHRhbmVvdXNseSBjcmVhdGluZyA8bGVh Zj4gd2hpY2ggaXMgcGFydCBvZg0KPiA+ID4gPiA8Y29udGFpbmVyPi4NCj4gPiA+ID4NCj4gPiA+ ID4NCj4gPiA+IEl0IGlzIGRlZmluZWQuDQo+ID4gPiBEb2VzIHRoZSBub2RlIC9jb250YWluZXIg ZXhpc3QgaW4gdGhlIHRhcmdldCBkYXRhc3RvcmU/DQo+ID4gPiBJZiB5ZXMsIHRoZW4gdGhlIGNy ZWF0ZSBvcGVyYXRpb24gb24gL2NvbnRhaW5lci9sZWFmIE1VU1QgZmFpbC4NCj4gPiA+IElmIG5v LCB0aGVuIHRoZSBkZWxldGUgb3BlcmF0aW9uIG9uIC9jb250YWluZXIgTVVTVCBmYWlsLg0KPiA+ DQo+ID4gd2hhdCBpZiAvY29udGFpbmVyIGV4aXN0cyBidXQgL2NvbnRhaW5lci9sZWFmIGRvZXMg bm90PyB0aGlzIHdheSBib3RoDQo+ID4gc3ViLW9wZXJhdGlvbnMgY291bGQgYmUgcGVyZm9ybWVk DQo+ID4NCj4gDQo+IA0KPiBub3QgcmVhbGx5LiBJZiBpbXBsZW1lbnRlZCBjb3JyZWN0bHkgdGhl biBpZiB0aGUgZGVsZXRlIG9uIC9jb250YWluZXINCj4gc3VjY2VlZHMsDQo+IHRoZW4gYWxsIGl0 cyBkZXNjZW5kYW50cyBhcmUgYWxzbyBkZWxldGVkLiAgVGhlIHJlc3VsdCBpbiB0aGUgdGFyZ2V0 DQo+IGRhdGFzdG9yZSBjYW5ub3QNCj4gcG9zc2libHkgY29tcGxldGUgYm90aCBhIGRlbGV0ZSBv biBhbiBhbmNlc3RvciBhbmQgY3JlYXRlIG9mIGEgZGVzY2VuZGFudA0KPiBpbiB0aGUgc2FtZSBl ZGl0LiBPdXIgc2VydmVyIHJldHVybnMgYW4gZXJyb3IgYmVjYXVzZSBpdCBjYW5ub3QgaG9ub3IN Cj4gYm90aCByZXF1ZXN0cy4NCj4gDQoNCkkgYmVsaWV2ZSB0aGF0IHRoaXMgaXMgdGhlIHBhcnQg d2hlcmUgDQoNCiAgICAgIElmIHRoZSA8ZWRpdC1jb25maWc+IG9wZXJhdGlvbiBjb250YWlucyBt dWx0aXBsZSBzdWItb3BlcmF0aW9ucw0KICAgICAgdGhhdCBhcHBseSB0byB0aGUgc2FtZSBjb25j ZXB0dWFsIG5vZGUgaW4gdGhlIHVuZGVybHlpbmcgZGF0YQ0KICAgICAgbW9kZWwsIHRoZW4gdGhl IHJlc3VsdCBvZiB0aGUgb3BlcmF0aW9uIGlzIHVuZGVmaW5lZCAoaS5lLiwNCiAgICAgIG91dHNp ZGUgdGhlIHNjb3BlIG9mIHRoZSBORVRDT05GIHByb3RvY29sKS4NCg0KY29tZXMgaW50byBwbGF5 LiBFeGFjdGx5IGFzIHlvdSBzYXksIHRhcmdldCBkYXRhc3RvcmUgY2Fubm90IGNvbXBsZXRlDQpi b3RoIHRoZSBkZWxldGlvbiBhbmQgY3JlYXRpb24sIHNpbmNlIGJvdGggb3BlcmF0ZSBvbiB0aGUg c2FtZSBkYXRhIGJ1dA0KcnVsZSBlYWNoIG90aGVyIG91dC4NCg0KPiANCj4gDQo+IA0KPiA+DQo+ ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiA+IE5vdywgd2hlbiBjb25zaWRlcmluZyBhIHNpbXBs ZSBsaXN0IGRlbGV0aW9uOg0KPiA+ID4gPg0KPiA+ID4gPiA8ZWRpdC1jb25maWc+DQo+ID4gPiA+ IDx0YXJnZXQ+PGNhbmRpZGF0ZS8+PC90YXJnZXQ+DQo+ID4gPiA+IDxjb25maWc+DQo+ID4gPiA+ ICA8bGlzdCBvcGVyYXRpb249ImRlbGV0ZSI+DQo+ID4gPiA+ICAgPGtleS1ub2RlPmtleS12YWx1 ZTwva2V5LW5vZGU+DQo+ID4gPiA+ICA8L2xpc3Q+DQo+ID4gPiA+IDwvY29uZmlnPg0KPiA+ID4g PiA8L2VkaXQtY29uZmlnPg0KPiA+ID4gPg0KPiA+ID4gPiBhbmQgcmlnb3JvdXNseSByZWFkaW5n IHRoZSBSRkMgcmVnYXJkaW5nIG9wZXJhdGlvbiBhbmQNCj4gPiA+ID4gZGVmYXVsdC1vcGVyYXRp b24sIHRoZSBvcGVyYXRpb24gYXR0cmlidXRlIGZvciA8a2V5LW5vZGU+IGlzICJtZXJnZSIsDQo+ ID4gPiA+IHRodXMsIHRlY2huaWNhbGx5LCB0aGlzIGVkaXQtY29uZmlnIG9wZXJhdGlvbiBvcGVy YXRlcyBvbiB0aGUNCj4gPiA8a2V5LW5vZGU+DQo+ID4gPiA+IHR3aWNlOg0KPiA+ID4gPg0KPiA+ ID4NCj4gPiA+IFRoZSBvcGVyYXRpb24gaXMgaW5oZXJpdGVkIGZyb20gaXRzIHBhcmVudCBpZiBu byAibmM6b3BlcmF0aW9uIg0KPiA+ID4gYXR0cmlidXRlIGlzIHNwZWNpZmllZC4gVGhlIGtleXMg bmVlZCB0byBiZSBwcmVzZW50IHRvIHNwZWNpZnkgdGhlIGxpc3QNCj4gPiA+IG5vZGUgdG8gYmUg ZGVsZXRlZC4NCj4gPg0KPiA+IGNhbiB5b3UgcG9pbnQgdG8gdGhlIHBhcmFncmFwaCBpbiBuZXRj b25mIFJGQyB3aGljaCBzYXlzIHRoYXQgdGhlDQo+ID4gb3BlcmF0aW9uIGlzIGluaGVyaXRlZD8N Cj4gPg0KPiA+DQo+IHRoZSBkZWxldGUgb3BlcmF0aW9uIG9uIHRoZSAvY29udGFpbmVyIG5vZGUg aXMgZm9yIHRoZSBjb250YWluZXIgYW5kIGFsbCBpdHMNCj4gZGVzY2VuZGFudHMuICBUaGF0IGlz IGhvdyBpdCBpcyBpbmhlcml0ZWQuIEkgc2hvdWxkIGhhdmUgc2FpZCAiZWZmZWN0aXZlIg0KPiBv cGVyYXRpb24NCj4gaW5zdGVhZCBvZiAiaW5oZXJpdGVkIi4NCg0KICAgICAgb3BlcmF0aW9uOiAg RWxlbWVudHMgaW4gdGhlIDxjb25maWc+IHN1YnRyZWUgTUFZIGNvbnRhaW4gYW4NCiAgICAgICAg ICJvcGVyYXRpb24iIGF0dHJpYnV0ZSwgd2hpY2ggYmVsb25ncyB0byB0aGUgTkVUQ09ORiBuYW1l c3BhY2UNCiAgICAgICAgIGRlZmluZWQgaW4gU2VjdGlvbiAzLjEuICBUaGUgYXR0cmlidXRlIGlk ZW50aWZpZXMgdGhlIHBvaW50IGluDQogICAgICAgICB0aGUgY29uZmlndXJhdGlvbiB0byBwZXJm b3JtIHRoZSBvcGVyYXRpb24gYW5kIE1BWSBhcHBlYXIgb24NCiAgICAgICAgIG11bHRpcGxlIGVs ZW1lbnRzIHRocm91Z2hvdXQgdGhlIDxjb25maWc+IHN1YnRyZWUuDQoNCiAgICAgICAgIElmIHRo ZSAib3BlcmF0aW9uIiBhdHRyaWJ1dGUgaXMgbm90IHNwZWNpZmllZCwgdGhlDQogICAgICAgICBj b25maWd1cmF0aW9uIGlzIG1lcmdlZCBpbnRvIHRoZSBjb25maWd1cmF0aW9uIGRhdGFzdG9yZS4N Cg0KaW4gdGhpcyBjYXNlLCB0aGUgIm9wZXJhdGlvbiIgYXR0cmlidXRlIGZvciA8a2V5LW5vZGU+ IGlzIG5vdCBzcGVjaWZpZWQuDQpTbyB0aGUgcHJvdmlkZWQgZXhhbXBsZSByZXF1ZXN0IGlzIGVx dWl2YWxlbnQgdG8gdGhpcyByZXF1ZXN0Og0KDQo8bGlzdCBvcGVyYXRpb249ImRlbGV0ZSI+DQog PGtleS1ub2RlIG9wZXJhdGlvbj0ibWVyZ2UiPmtleS12YWx1ZTwva2V5LW5vZGU+DQo8L2xpc3Q+ DQoNCnNvIGJhc2ljYWxseSBpdCdzIHRoZSBzYW1lIGFzIGFib3ZlIC0gdGhlcmUgaXMgYSByZXF1 ZXN0IGRvIGRlbGV0ZQ0KPGxpc3Q+IHdoaWxlIGNyZWF0aW5nIGFuZC9vciBrZWVwaW5nIDxrZXkt bm9kZT4gYXJvdW5kIC0gYm90aCBjYW5ub3QgYmUNCmRvbmUuIEkgY2Fubm90IGZpbmQgYW55IGV4 Y2VwdGlvbiBpbiB0aGUgUkZDIGZvciBsaXN0L2tleS1ub2RlIGNvbWJvDQpjYXNlLg0KDQo+IA0K PiANCj4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiA+IDEuKSBkZWxldGluZyB0aGUgdmFsdWUgdmlh IGRlbGV0aW9uIG9mIHRoZSBsaXN0IGVudGl0eSA8bGlzdD4NCj4gPiA+ID4gMi4pIG1lcmdpbmcg aW4gYSBuZXcgdmFsdWUgdmlhICJtZXJnZSIgb24gdGhlIDxrZXktbm9kZT4NCj4gPiA+ID4NCj4g PiA+ID4NCj4gPiA+ID4gVGhlIFJGQyBoYXMgPGRlZmF1bHQtb3BlcmF0aW9uPm5vbmU8L2RlZmF1 bHQtb3BlcmF0aW9uPiBpbiBhbGwgZGVsZXRpb24NCj4gPiA+ID4gZXhhbXBsZXMsIHdoaWNoIG1h a2VzIHVzIGJlbGlldmUgdGhhdCBpbmRlZWQgd2hlbiBwcm9jZXNzaW5nIHRoZQ0KPiA+ID4gPiBt ZW50aW9uZWQgcmVxdWVzdCwgdGhlIDxrZXktbm9kZT4ncyBvcGVyYXRpb24gd291bGQgYmUgIm1l cmdlIiBhbmQgdGh1cw0KPiA+ID4gPiB0aGUgb3BlcmF0aW9uIHVuZGVmaW5lZC4NCj4gPiA+ID4N Cj4gPiA+ID4gSXMgdGhpcyBob3cgaXQncyBzdXBwb3NlZCB0byBiZSBvciBhcmUgd2UgcmVhZGlu ZyBpdCB3cm9uZz8NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+IHRoZSBsYXR0ZXINCj4gPiA+DQo+ ID4gPg0KPiA+ID4gPiBUaGFua3MsDQo+ID4gPiA+IEtsZW1lbnQNCj4gPiA+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gTmV0Y29uZiBt YWlsaW5nIGxpc3QNCj4gPiA+ID4gTmV0Y29uZkBpZXRmLm9yZw0KPiA+ID4gPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gPiA+ID4NCj4gPg0KPiA+DQo+ IEFuZHkNCg0K From nobody Tue Jul 29 05:18:04 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318561B2827 for ; Tue, 29 Jul 2014 05:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 NHXFM_7Uwrb0 for ; Tue, 29 Jul 2014 05:17:59 -0700 (PDT) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32CAF1B280F for ; Tue, 29 Jul 2014 05:17:59 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id j107so9996588qga.22 for ; Tue, 29 Jul 2014 05:17:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yS57ujaP2wd/ONYv6tBDlTPQCPq8KZegPH9yCs1e3Ng=; b=J2/Auys6mCrtYVXJ1EDcZ4q87W0vLmRqFYs3zRP4u2SEwBlmZIjB41v+Cl/eIvnd38 FmA2U+eDX1CW8+XIgeEQp7T9Mza9qetA+Qe/5LojWwMtWewKXeDEPAf23BzzHdl7GoFX wjHxMKtSziOi81N/rBQtosyTOj7TuFGvKmUXq6Tr7ryMglyZ9eRfCiFgfM/uMP9IN+6v G6bAMGwgGASK8dPBLTxKv4FaNAuiE99j1yeyNUk/xSn6wGgqzqwgJQNZO1d2L8OTeclW xzHuAEKdJ6UUpueTCvcYM92462tsJyBoFdu8m1WUqTQzX8LntkjKf6x/z8rFlXkUnvgq sasw== X-Gm-Message-State: ALoCoQl8YTBZ3QzgYBCJYqDqSfXjcT1ctk+xMNIdzkV8hpfPJZNPQqK+MmeqMJJTVjwxa0Qv6gN8 MIME-Version: 1.0 X-Received: by 10.140.80.74 with SMTP id b68mr2666862qgd.21.1406636277074; Tue, 29 Jul 2014 05:17:57 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Tue, 29 Jul 2014 05:17:56 -0700 (PDT) In-Reply-To: <1406619859.12287.31.camel@ksekera-fedora> References: <1406560309.12287.21.camel@ksekera-fedora> <1406561507.12287.24.camel@ksekera-fedora> <1406619859.12287.31.camel@ksekera-fedora> Date: Tue, 29 Jul 2014 05:17:56 -0700 Message-ID: From: Andy Bierman To: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" Content-Type: multipart/alternative; boundary=001a11c125109fa75a04ff5407a2 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/-poW6wO_xygMS5Ta3ajiyoRyuTo Cc: "netconf@ietf.org" Subject: Re: [Netconf] edit-config operation inconsistency X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 12:18:02 -0000 --001a11c125109fa75a04ff5407a2 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 29, 2014 at 12:44 AM, Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco) wrote: > On Mon, 2014-07-28 at 08:43 -0700, Andy Bierman wrote: > > On Mon, Jul 28, 2014 at 8:31 AM, Klement Sekera -X (ksekera - Pantheon > > Technologies SRO at Cisco) wrote: > > > > > On Mon, 2014-07-28 at 08:22 -0700, Andy Bierman wrote: > > > > On Mon, Jul 28, 2014 at 8:11 AM, Klement Sekera -X (ksekera - > Pantheon > > > > Technologies SRO at Cisco) wrote: > > > > > > > > > Hi all, > > > > > > > > > > we are currently debating an issue we found and would like to have > some > > > > > clarification. Netconf RFC says that the edit-config operation > which > > > > > contains multiple sub-operations on the same data is undefined. > > > > > > > > > > so when considering this request: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > the outcome is undefined, since the client wants do delete > container > > > > > , while simultaneously creating which is part of > > > > > . > > > > > > > > > > > > > > It is defined. > > > > Does the node /container exist in the target datastore? > > > > If yes, then the create operation on /container/leaf MUST fail. > > > > If no, then the delete operation on /container MUST fail. > > > > > > what if /container exists but /container/leaf does not? this way both > > > sub-operations could be performed > > > > > > > > > not really. If implemented correctly then if the delete on /container > > succeeds, > > then all its descendants are also deleted. The result in the target > > datastore cannot > > possibly complete both a delete on an ancestor and create of a descendant > > in the same edit. Our server returns an error because it cannot honor > > both requests. > > > > I believe that this is the part where > > If the operation contains multiple sub-operations > that apply to the same conceptual node in the underlying data > model, then the result of the operation is undefined (i.e., > outside the scope of the NETCONF protocol). > > comes into play. Exactly as you say, target datastore cannot complete > both the deletion and creation, since both operate on the same data but > rule each other out. > > > > > > > > > > > > > > > > > > > > > > > > > > > Now, when considering a simple list deletion: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > key-value > > > > > > > > > > > > > > > > > > > > > > > > > and rigorously reading the RFC regarding operation and > > > > > default-operation, the operation attribute for is > "merge", > > > > > thus, technically, this edit-config operation operates on the > > > > > > > > twice: > > > > > > > > > > > > > The operation is inherited from its parent if no "nc:operation" > > > > attribute is specified. The keys need to be present to specify the > list > > > > node to be deleted. > > > > > > can you point to the paragraph in netconf RFC which says that the > > > operation is inherited? > > > > > > > > the delete operation on the /container node is for the container and all > its > > descendants. That is how it is inherited. I should have said "effective" > > operation > > instead of "inherited". > > operation: Elements in the subtree MAY contain an > "operation" attribute, which belongs to the NETCONF namespace > defined in Section 3.1. The attribute identifies the point in > the configuration to perform the operation and MAY appear on > multiple elements throughout the subtree. > > If the "operation" attribute is not specified, the > configuration is merged into the configuration datastore. > > in this case, the "operation" attribute for is not specified. > So the provided example request is equivalent to this request: > > > key-value > > > so basically it's the same as above - there is a request do delete > while creating and/or keeping around - both cannot be > done. I cannot find any exception in the RFC for list/key-node combo > case. > > Perhaps 1 new sentence (After the 1 about no attribute=merge): If the operation attribute is not present for a key leaf node, and the edit operation for the parent node is "delete" or "remove", then the operation for the key leaf node is the same as its parent node. Andy > > > > > > > > > > > > > > > > > > > > 1.) deleting the value via deletion of the list entity > > > > > 2.) merging in a new value via "merge" on the > > > > > > > > > > > > > > > The RFC has none in all > deletion > > > > > examples, which makes us believe that indeed when processing the > > > > > mentioned request, the 's operation would be "merge" and > thus > > > > > the operation undefined. > > > > > > > > > > Is this how it's supposed to be or are we reading it wrong? > > > > > > > > > > > > > > the latter > > > > > > > > > > > > > Thanks, > > > > > Klement > > > > > _______________________________________________ > > > > > Netconf mailing list > > > > > Netconf@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > > > > > Andy > > --001a11c125109fa75a04ff5407a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Jul 29, 2014 at 12:44 AM, Klement Sekera -X (ksekera - Pant= heon Technologies SRO at Cisco) <ksekera@cisco.com> wrote:
On Mon, 2014-07-28 at 08:43 -0700, Andy Bier= man wrote:
> On Mon, Jul 28, 2014 at 8:31 AM, Klement Sekera -X (ksekera - Pantheon=
> Technologies SRO at Cisco) <ks= ekera@cisco.com> wrote:
>
> > On Mon, 2014-07-28 at 08:22 -0700, Andy Bierman wrote:
> > > On Mon, Jul 28, 2014 at 8:11 AM, Klement Sekera -X (ksekera = - Pantheon
> > > Technologies SRO at Cisco) <ksekera@cisco.com> wrote:
> > >
> > > > Hi all,
> > > >
> > > > we are currently debating an issue we found and would l= ike to have some
> > > > clarification. Netconf RFC says that the edit-config op= eration which
> > > > contains multiple sub-operations on the same data is un= defined.
> > > >
> > > > so when considering this request:
> > > >
> > > > <edit-config>
> > > > <target><candidate/></target>
> > > > <config>
> > > > =A0<container operation=3D"delete">
> > > > =A0 <leaf operation=3D"create"/>
> > > > =A0</container>
> > > > </config>
> > > > </edit-config>
> > > >
> > > > the outcome is undefined, since the client wants do del= ete container
> > > > <container>, while simultaneously creating <le= af> which is part of
> > > > <container>.
> > > >
> > > >
> > > It is defined.
> > > Does the node /container exist in the target datastore?
> > > If yes, then the create operation on /container/leaf MUST fa= il.
> > > If no, then the delete operation on /container MUST fail. > >
> > what if /container exists but /container/leaf does not? this way = both
> > sub-operations could be performed
> >
>
>
> not really. If implemented correctly then if the delete on /container<= br> > succeeds,
> then all its descendants are also deleted. =A0The result in the target=
> datastore cannot
> possibly complete both a delete on an ancestor and create of a descend= ant
> in the same edit. Our server returns an error because it cannot honor<= br> > both requests.
>

I believe that this is the part where

=A0 =A0 =A0 If the <edit-config> operation contains multiple sub-oper= ations
=A0 =A0 =A0 that apply to the same conceptual node in the underlying data =A0 =A0 =A0 model, then the result of the operation is undefined (i.e.,
=A0 =A0 =A0 outside the scope of the NETCONF protocol).

comes into play. Exactly as you say, target datastore cannot complete
both the deletion and creation, since both operate on the same data but
rule each other out.

>
>
>
> >
> > >
> > >
> > >
> > > > Now, when considering a simple list deletion:
> > > >
> > > > <edit-config>
> > > > <target><candidate/></target>
> > > > <config>
> > > > =A0<list operation=3D"delete">
> > > > =A0 <key-node>key-value</key-node>
> > > > =A0</list>
> > > > </config>
> > > > </edit-config>
> > > >
> > > > and rigorously reading the RFC regarding operation and<= br> > > > > default-operation, the operation attribute for <key-= node> is "merge",
> > > > thus, technically, this edit-config operation operates = on the
> > <key-node>
> > > > twice:
> > > >
> > >
> > > The operation is inherited from its parent if no "nc:op= eration"
> > > attribute is specified. The keys need to be present to speci= fy the list
> > > node to be deleted.
> >
> > can you point to the paragraph in netconf RFC which says that the=
> > operation is inherited?
> >
> >
> the delete operation on the /container node is for the container and a= ll its
> descendants. =A0That is how it is inherited. I should have said "= effective"
> operation
> instead of "inherited".

=A0 =A0 =A0 operation: =A0Elements in the <config> subtree MAY contai= n an
=A0 =A0 =A0 =A0 =A0"operation" attribute, which belongs to the NE= TCONF namespace
=A0 =A0 =A0 =A0 =A0defined in Section 3.1. =A0The attribute identifies the = point in
=A0 =A0 =A0 =A0 =A0the configuration to perform the operation and MAY appea= r on
=A0 =A0 =A0 =A0 =A0multiple elements throughout the <config> subtree.=

=A0 =A0 =A0 =A0 =A0If the "operation" attribute is not specified,= the
=A0 =A0 =A0 =A0 =A0configuration is merged into the configuration datastore= .

in this case, the "operation" attribute for <key-node> is n= ot specified.
So the provided example request is equivalent to this request:

<list operation=3D"delete">
=A0<key-node operation=3D"merge">key-value</key-node>=
</list>

so basically it's the same as above - there is a request do delete
<list> while creating and/or keeping <key-node> around - both c= annot be
done. I cannot find any exception in the RFC for list/key-node combo
case.


Perhaps 1 new sentence (After the 1 ab= out no attribute=3Dmerge):

=A0 If the operation at= tribute is not present for a key leaf node, and
=A0 the edit oper= ation for the parent node is "delete" or "remove",
=A0 then the operation for the key leaf node is the same as its parent= node.


Andy

=A0
>
>
> >
> > >
> > >
> > > > 1.) deleting the value via deletion of the list entity = <list>
> > > > 2.) merging in a new value via "merge" on the= <key-node>
> > > >
> > > >
> > > > The RFC has <default-operation>none</default-o= peration> in all deletion
> > > > examples, which makes us believe that indeed when proce= ssing the
> > > > mentioned request, the <key-node>'s operation= would be "merge" and thus
> > > > the operation undefined.
> > > >
> > > > Is this how it's supposed to be or are we reading i= t wrong?
> > > >
> > > >
> > > the latter
> > >
> > >
> > > > Thanks,
> > > > Klement
> > > > _______________________________________________
> > > > Netconf mailing list
> > > > Netconf@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netconf
> > > >
> >
> >
> Andy


--001a11c125109fa75a04ff5407a2-- From nobody Tue Jul 29 07:43:45 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D474E1B2910 for ; Tue, 29 Jul 2014 07:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 V80dm0d9H-lF for ; Tue, 29 Jul 2014 07:43:39 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A86C1B2909 for ; Tue, 29 Jul 2014 07:43:38 -0700 (PDT) X-AuditID: c1b4fb2d-f798a6d000000e9b-4c-53d7b3180772 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F7.7B.03739.813B7D35; Tue, 29 Jul 2014 16:43:36 +0200 (CEST) Received: from [159.107.198.99] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.174.1; Tue, 29 Jul 2014 16:43:35 +0200 Message-ID: <53D7B316.8020903@ericsson.com> Date: Tue, 29 Jul 2014 16:43:34 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Andy Bierman , "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" References: <1406560309.12287.21.camel@ksekera-fedora> <1406561507.12287.24.camel@ksekera-fedora> <1406619859.12287.31.camel@ksekera-fedora> In-Reply-To: Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUyM+Jvja7E5uvBBjOXCFs8ODKL3eLxu3Y2 i6mbbrM6MHtM+b2R1WPJkp9MHi39F1kCmKO4bFJSczLLUov07RK4Mi6t6WIqmF9X8WqtZAPj xaAuRk4OCQETiWvnOpggbDGJC/fWs3UxcnEICRxllHjUdQLKWcMo8W7zaVaQKl4BbYlvrW1s IDaLgKpET/NXdhCbTcBIYmr/eRYQW1QgSuLOpX6oekGJkzOfgMVFBOolvtz+xQxiMwtoSqz9 +xHMFhawkpj97TDUsttMEv8W7QRr4BQIlOhsuc0C0aArceH/FChbXmL72zlgzUICGhIPL/xl ncAoOAvJvllIWmYhaVnAyLyKUbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzCID275rbuDcfVr x0OMAhyMSjy8D45fCxZiTSwrrsw9xCjNwaIkzrvo3LxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xM HJxSDYzduZLrv8jYJzjssY5a571gw6lH9q13rmtNzK1Y8aX0uP3bH48sVeOX/D2+OFR568Yb ZhZZOw9/9q7RXnSWtTSjbZOl9X3ZlznOxss2fl/903LmLYaNaX+3+0SGCj7Ysfle9JvQ3i+6 0aaTvNRreFlqvv+XNF6fJhl5bOk59w8l82T+seasvsepxFKckWioxVxUnAgARpFy+kMCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/GOfLgZI8e4Yjnyjanbob_yfjxyI Cc: "netconf@ietf.org" Subject: Re: [Netconf] edit-config operation inconsistency X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 14:43:44 -0000 Hello,
I always tought the operation attribute is inherited.  Inherited in a sense that an XML element actually contains/includes all sub-elements under it. So creating/deleting/merging the element means creating/deleting/merging all its contents as well. So unless you later override this with more specific instructions for one of the contained elements it should be valid for the complete element with all its content.

If operation is not inheritable we have some interesting cases:
- your examples
- default operation=none and I want to create a sizeable subtree. I have to place the merge/create operation on every node. Don't like it, makes none-unusable except for delete/remove.
Lets say we have the following data model: 
routing
  +--static-routing
  |   +--route [routeId]            
  |        +--routeId 			ipprefix   
  |        +--path-to-destination 	[nexthop]
  |            +--nextHop 		ipAddress
  |            +--outgoingInterface   	string
               +--bfdActive		boolean
I want to create a static route with all its sub-elements but only if the static-routing presence container exists (static routing is allowed/enabled).
<default-operation>none</default-operation>
<config>
   <static-routing>  --- this will check that static routing exists.
      <route operation="create">  --this will create the interface
         <routeid>1.1.1.1/24</routeid>   -- I don't want to put operation=create on all further nodes 5 times or more depending on the number of paths
         <path-to-destination>
            <nextHop>1.1.1.5</nextHop>
            <outgoingInterface>eth0</outgoingInterface>
            <bfdActive>true</bfdActive>              
         </path-to-destination>
      </route>
   </static-routing>
</config>

 This was very nice and logical. I hope it still works.
regards Balazs

On 2014-07-29 14:17, Andy Bierman wrote:



On Tue, Jul 29, 2014 at 12:44 AM, Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco) <ksekera@cisco.com> wrote:
On Mon, 2014-07-28 at 08:43 -0700, Andy Bierman wrote:
> On Mon, Jul 28, 2014 at 8:31 AM, Klement Sekera -X (ksekera - Pantheon
> Technologies SRO at Cisco) <ksekera@cisco.com> wrote:
>
> > On Mon, 2014-07-28 at 08:22 -0700, Andy Bierman wrote:
> > > On Mon, Jul 28, 2014 at 8:11 AM, Klement Sekera -X (ksekera - Pantheon
> > > Technologies SRO at Cisco) <ksekera@cisco.com> wrote:
> > >
> > > > Hi all,
> > > >
> > > > we are currently debating an issue we found and would like to have some
> > > > clarification. Netconf RFC says that the edit-config operation which
> > > > contains multiple sub-operations on the same data is undefined.
> > > >
> > > > so when considering this request:
> > > >
> > > > <edit-config>
> > > > <target><candidate/></target>
> > > > <config>
> > > >  <container operation="delete">
> > > >   <leaf operation="create"/>
> > > >  </container>
> > > > </config>
> > > > </edit-config>
> > > >
> > > > the outcome is undefined, since the client wants do delete container
> > > > <container>, while simultaneously creating <leaf> which is part of
> > > > <container>.
> > > >
> > > >
> > > It is defined.
> > > Does the node /container exist in the target datastore?
> > > If yes, then the create operation on /container/leaf MUST fail.
> > > If no, then the delete operation on /container MUST fail.
> >
> > what if /container exists but /container/leaf does not? this way both
> > sub-operations could be performed
> >
>
>
> not really. If implemented correctly then if the delete on /container
> succeeds,
> then all its descendants are also deleted.  The result in the target
> datastore cannot
> possibly complete both a delete on an ancestor and create of a descendant
> in the same edit. Our server returns an error because it cannot honor
> both requests.
>

I believe that this is the part where

      If the <edit-config> operation contains multiple sub-operations
      that apply to the same conceptual node in the underlying data
      model, then the result of the operation is undefined (i.e.,
      outside the scope of the NETCONF protocol).

comes into play. Exactly as you say, target datastore cannot complete
both the deletion and creation, since both operate on the same data but
rule each other out.

>
>
>
> >
> > >
> > >
> > >
> > > > Now, when considering a simple list deletion:
> > > >
> > > > <edit-config>
> > > > <target><candidate/></target>
> > > > <config>
> > > >  <list operation="delete">
> > > >   <key-node>key-value</key-node>
> > > >  </list>
> > > > </config>
> > > > </edit-config>
> > > >
> > > > and rigorously reading the RFC regarding operation and
> > > > default-operation, the operation attribute for <key-node> is "merge",
> > > > thus, technically, this edit-config operation operates on the
> > <key-node>
> > > > twice:
> > > >
> > >
> > > The operation is inherited from its parent if no "nc:operation"
> > > attribute is specified. The keys need to be present to specify the list
> > > node to be deleted.
> >
> > can you point to the paragraph in netconf RFC which says that the
> > operation is inherited?
> >
> >
> the delete operation on the /container node is for the container and all its
> descendants.  That is how it is inherited. I should have said "effective"
> operation
> instead of "inherited".

      operation:  Elements in the <config> subtree MAY contain an
         "operation" attribute, which belongs to the NETCONF namespace
         defined in Section 3.1.  The attribute identifies the point in
         the configuration to perform the operation and MAY appear on
         multiple elements throughout the <config> subtree.

         If the "operation" attribute is not specified, the
         configuration is merged into the configuration datastore.

in this case, the "operation" attribute for <key-node> is not specified.
So the provided example request is equivalent to this request:

<list operation="delete">
 <key-node operation="merge">key-value</key-node>
</list>

so basically it's the same as above - there is a request do delete
<list> while creating and/or keeping <key-node> around - both cannot be
done. I cannot find any exception in the RFC for list/key-node combo
case.


Perhaps 1 new sentence (After the 1 about no attribute=merge):

  If the operation attribute is not present for a key leaf node, and
  the edit operation for the parent node is "delete" or "remove",
  then the operation for the key leaf node is the same as its parent node.


Andy

 
>
>
> >
> > >
> > >
> > > > 1.) deleting the value via deletion of the list entity <list>
> > > > 2.) merging in a new value via "merge" on the <key-node>
> > > >
> > > >
> > > > The RFC has <default-operation>none</default-operation> in all deletion
> > > > examples, which makes us believe that indeed when processing the
> > > > mentioned request, the <key-node>'s operation would be "merge" and thus
> > > > the operation undefined.
> > > >
> > > > Is this how it's supposed to be or are we reading it wrong?
> > > >
> > > >
> > > the latter
> > >
> > >
> > > > Thanks,
> > > > Klement
> > > > _______________________________________________
> > > > Netconf mailing list
> > > > Netconf@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netconf
> > > >
> >
> >
> Andy




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


-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Tue Jul 29 07:55:25 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F50E1B2951 for ; Tue, 29 Jul 2014 07:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 hNUQYr3WpBMW for ; Tue, 29 Jul 2014 07:55:21 -0700 (PDT) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0C81B294E for ; Tue, 29 Jul 2014 07:55:00 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id i50so10398288qgf.6 for ; Tue, 29 Jul 2014 07:54:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ouB46or5K/4rP1UCwZKcyLXjyEhAP3UlEx5RI7b1fPA=; b=ivhLEQ6IBtjUvUnlPECupsynC9X4wjda+RNy6ij1FRTPBKkE9uXXIew/N4EkCC3kVY lcA6moSyCg4Xh+eTO/UtCVcBNkcmB/ADEk4uFxt+UaPL10lng+YK/KEV9A0yfKvgb2SS YV8w6x1nPbjn4YOaq/4RY4TUPrnJ8yMaZrtObqeloPzW1cTPGxPiAcDcdjLINOfrc1sT SBTs9KbtvwL/TVmO8EMTN3vg7OCPhLHfiStmeeodyAlsi+SoNunVI4si5tV0EE/76RpK SO1zUsdCTBEIoWnEfrV/jQtTtMaL+S96IpRTSTT8JVdzU38VG+A2dCN4n6ukt8kve8zK 1euQ== X-Gm-Message-State: ALoCoQnqXIA984KmFBsVOfUbScxYyBpr5nUYaczTOGvphOygpivuyJAeuWQguSSFqEBKcLeDveAS MIME-Version: 1.0 X-Received: by 10.140.80.74 with SMTP id b68mr4063315qgd.21.1406645699555; Tue, 29 Jul 2014 07:54:59 -0700 (PDT) Received: by 10.140.104.48 with HTTP; Tue, 29 Jul 2014 07:54:59 -0700 (PDT) In-Reply-To: <53D7B316.8020903@ericsson.com> References: <1406560309.12287.21.camel@ksekera-fedora> <1406561507.12287.24.camel@ksekera-fedora> <1406619859.12287.31.camel@ksekera-fedora> <53D7B316.8020903@ericsson.com> Date: Tue, 29 Jul 2014 07:54:59 -0700 Message-ID: From: Andy Bierman To: Balazs Lengyel Content-Type: multipart/alternative; boundary=001a11c125103f978504ff563925 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/AMIJPekUrcB0m8O7hGXChHbupP0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] edit-config operation inconsistency X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 14:55:24 -0000 --001a11c125103f978504ff563925 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 29, 2014 at 7:43 AM, Balazs Lengyel wrote: > Hello, > I always tought the operation attribute is inherited. > This is how everybody implements it, and what we intended (pre-4741). Otherwise, would a "replace" operation for some arbitrary subtree require nc:operation="replace" in every replacement descendant node? Andy > Inherited in a sense that an XML element actually contains/includes all > sub-elements under it. So creating/deleting/merging the element means > creating/deleting/merging all its contents as well. So unless you later > override this with more specific instructions for one of the contained > elements it should be valid for the complete element with all its content. > > If operation is not inheritable we have some interesting cases: > - your examples > - default operation=none and I want to create a sizeable subtree. I have > to place the merge/create operation on every node. Don't like it, makes > none-unusable except for delete/remove. > Lets say we have the following data model: > > routing > +--static-routing > | +--route [routeId] > | +--routeId ipprefix > | +--path-to-destination [nexthop] > | +--nextHop ipAddress > | +--outgoingInterface string > +--bfdActive boolean > > I want to create a static route with all its sub-elements but only if the > static-routing presence container exists (static routing is > allowed/enabled). > none > > --- this will check that static routing exists. > --this will create the interface > 1.1.1.1/24 -- I don't want to put > operation=create on all further nodes 5 times or more depending on the > number of paths > > 1.1.1.5 > eth0 > true > > > > > > This was very nice and logical. I hope it still works. > regards Balazs > > On 2014-07-29 14:17, Andy Bierman wrote: > > > > > On Tue, Jul 29, 2014 at 12:44 AM, Klement Sekera -X (ksekera - Pantheon > Technologies SRO at Cisco) wrote: > >> On Mon, 2014-07-28 at 08:43 -0700, Andy Bierman wrote: >> > On Mon, Jul 28, 2014 at 8:31 AM, Klement Sekera -X (ksekera - Pantheon >> > Technologies SRO at Cisco) wrote: >> > >> > > On Mon, 2014-07-28 at 08:22 -0700, Andy Bierman wrote: >> > > > On Mon, Jul 28, 2014 at 8:11 AM, Klement Sekera -X (ksekera - >> Pantheon >> > > > Technologies SRO at Cisco) wrote: >> > > > >> > > > > Hi all, >> > > > > >> > > > > we are currently debating an issue we found and would like to >> have some >> > > > > clarification. Netconf RFC says that the edit-config operation >> which >> > > > > contains multiple sub-operations on the same data is undefined. >> > > > > >> > > > > so when considering this request: >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > the outcome is undefined, since the client wants do delete >> container >> > > > > , while simultaneously creating which is part of >> > > > > . >> > > > > >> > > > > >> > > > It is defined. >> > > > Does the node /container exist in the target datastore? >> > > > If yes, then the create operation on /container/leaf MUST fail. >> > > > If no, then the delete operation on /container MUST fail. >> > > >> > > what if /container exists but /container/leaf does not? this way both >> > > sub-operations could be performed >> > > >> > >> > >> > not really. If implemented correctly then if the delete on /container >> > succeeds, >> > then all its descendants are also deleted. The result in the target >> > datastore cannot >> > possibly complete both a delete on an ancestor and create of a >> descendant >> > in the same edit. Our server returns an error because it cannot honor >> > both requests. >> > >> >> I believe that this is the part where >> >> If the operation contains multiple sub-operations >> that apply to the same conceptual node in the underlying data >> model, then the result of the operation is undefined (i.e., >> outside the scope of the NETCONF protocol). >> >> comes into play. Exactly as you say, target datastore cannot complete >> both the deletion and creation, since both operate on the same data but >> rule each other out. >> >> > >> > >> > >> > > >> > > > >> > > > >> > > > >> > > > > Now, when considering a simple list deletion: >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > key-value >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > and rigorously reading the RFC regarding operation and >> > > > > default-operation, the operation attribute for is >> "merge", >> > > > > thus, technically, this edit-config operation operates on the >> > > >> > > > > twice: >> > > > > >> > > > >> > > > The operation is inherited from its parent if no "nc:operation" >> > > > attribute is specified. The keys need to be present to specify the >> list >> > > > node to be deleted. >> > > >> > > can you point to the paragraph in netconf RFC which says that the >> > > operation is inherited? >> > > >> > > >> > the delete operation on the /container node is for the container and >> all its >> > descendants. That is how it is inherited. I should have said >> "effective" >> > operation >> > instead of "inherited". >> >> operation: Elements in the subtree MAY contain an >> "operation" attribute, which belongs to the NETCONF namespace >> defined in Section 3.1. The attribute identifies the point in >> the configuration to perform the operation and MAY appear on >> multiple elements throughout the subtree. >> >> If the "operation" attribute is not specified, the >> configuration is merged into the configuration datastore. >> >> in this case, the "operation" attribute for is not specified. >> So the provided example request is equivalent to this request: >> >> >> key-value >> >> >> so basically it's the same as above - there is a request do delete >> while creating and/or keeping around - both cannot be >> done. I cannot find any exception in the RFC for list/key-node combo >> case. >> >> > Perhaps 1 new sentence (After the 1 about no attribute=merge): > > If the operation attribute is not present for a key leaf node, and > the edit operation for the parent node is "delete" or "remove", > then the operation for the key leaf node is the same as its parent node. > > > Andy > > > >> > >> > >> > > >> > > > >> > > > >> > > > > 1.) deleting the value via deletion of the list entity >> > > > > 2.) merging in a new value via "merge" on the >> > > > > >> > > > > >> > > > > The RFC has none in all >> deletion >> > > > > examples, which makes us believe that indeed when processing the >> > > > > mentioned request, the 's operation would be "merge" >> and thus >> > > > > the operation undefined. >> > > > > >> > > > > Is this how it's supposed to be or are we reading it wrong? >> > > > > >> > > > > >> > > > the latter >> > > > >> > > > >> > > > > Thanks, >> > > > > Klement >> > > > > _______________________________________________ >> > > > > Netconf mailing list >> > > > > Netconf@ietf.org >> > > > > https://www.ietf.org/mailman/listinfo/netconf >> > > > > >> > > >> > > >> > Andy >> >> > > > _______________________________________________ > Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 Tel: +36-1-437-7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > --001a11c125103f978504ff563925 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Jul 29, 2014 at 7:43 AM, Balazs Lengyel &= lt;balazs.= lengyel@ericsson.com> wrote:
=20 =20 =20
Hello,
I always tought the operation attribute is inherited.=A0

This is how everybody implements it, and what we in= tended (pre-4741).
Otherwise, would a "replace" operati= on for some arbitrary subtree
require nc:operation=3D"replace" in every replacement descen= dant node?


Andy





=A0
I= nherited in a sense that an XML element actually contains/includes all sub-elements under it. So creating/deleting/merging the element means creating/deleting/merging all its contents as well. So unless you later override this with more specific instructions for one of the contained elements it should be valid for the complete element with all its content.

If operation is not inheritable we have some interesting cases:
- your examples
- default operation=3Dnone and I want to create a sizeable subtree. I have to place the merge/create operation on every node. Don't like it, makes none-unusable except for delete/remove.
Lets say we have the following data model: 
routing
  +--static-routing
  |   +--route [routeId]           =20
  |        +--routeId 			ipprefix  =20
  |        +--path-to-destination 	[nexthop]
  |            +--nextHop 		ipAddress
  |            +--outgoingInterface   	string
=A0              +--bfdActive		boolean
I want to create a static route with all its sub-elements but only if the static-routing presence container exists (static routing is allowed/enabled).
<default-operation>none</default-operation>
<config>
=A0=A0 <static-routing>=A0 --- this will check that static routin= g exists.
=A0=A0=A0=A0=A0 <route operation=3D"create">=A0 --this = will create the interface
=A0=A0=A0=A0=A0=A0=A0=A0 <routeid>1.1.1.1/24</routeid>=A0=A0 -- I don't want to put operation=3Dcreate on all further nodes 5 times or more depending on the number of paths
=A0=A0=A0=A0=A0=A0=A0=A0 <path-to-destination>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <nextHop>1.1.1.5</nextHop>= ;
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <outgoingInterface>eth0</out= goingInterface>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <bfdActive>true</bfdActive&g= t;=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
=A0=A0=A0=A0=A0=A0=A0=A0 </path-to-destination>
=A0=A0=A0=A0=A0 </route>
=A0=A0 </static-routing>
</config>

=A0This was very nice and logical. I hope it still works.
regards Balazs

On 2014-07-29 14:17, Andy Bierman wrote:
=20



On Tue, Jul 29, 2014 at 12:44 AM, Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco) <ksekera@cisco.com> wrote:
On Mon, 2014-07-28 at 08:43 -0700, Andy Bierman wrote:
> On Mon, Jul 28, 2014 at 8:31 AM, Klement Sekera -X (ksekera - Pantheon
> Technologies SRO at Cisco) <ksekera@cisco.com> wrote:
>
> > On Mon, 2014-07-28 at 08:22 -0700, Andy Bierman wrote:
> > > On Mon, Jul 28, 2014 at 8:11 AM, Klement Sekera -X (ksekera - Pantheon
> > > Technologies SRO at Cisco) <ksekera@cisco.com> wrote:
> > >
> > > > Hi all,
> > > >
> > > > we are currently debating an issue we found and would like to have some
> > > > clarification. Netconf RFC says that the edit-config operation which
> > > > contains multiple sub-operations on the same data is undefined.
> > > >
> > > > so when considering this request:
> > > >
> > > > <edit-config>
> > > > <target><candidate/></target>
> > > > <config>
> > > > =A0<container operation=3D"delete= ">
> > > > =A0 <leaf operation=3D"create&quo= t;/>
> > > > =A0</container>
> > > > </config>
> > > > </edit-config>
> > > >
> > > > the outcome is undefined, since the client wants do delete container
> > > > <container>, while simultaneously creating <leaf> which is part of
> > > > <container>.
> > > >
> > > >
> > > It is defined.
> > > Does the node /container exist in the target datastore?
> > > If yes, then the create operation on /container/leaf MUST fail.
> > > If no, then the delete operation on /container MUST fail.
> >
> > what if /container exists but /container/leaf does not? this way both
> > sub-operations could be performed
> >
>
>
> not really. If implemented correctly then if the delete on /container
> succeeds,
> then all its descendants are also deleted. =A0The result in the target
> datastore cannot
> possibly complete both a delete on an ancestor and create of a descendant
> in the same edit. Our server returns an error because it cannot honor
> both requests.
>

I believe that this is the part where

=A0 =A0 =A0 If the <edit-config> operation contains multiple sub-operations
=A0 =A0 =A0 that apply to the same conceptual node in the underlying data
=A0 =A0 =A0 model, then the result of the operation is undefi= ned (i.e.,
=A0 =A0 =A0 outside the scope of the NETCONF protocol).

comes into play. Exactly as you say, target datastore cannot complete
both the deletion and creation, since both operate on the same data but
rule each other out.

>
>
>
> >
> > >
> > >
> > >
> > > > Now, when considering a simple list deletion:
> > > >
> > > > <edit-config>
> > > > <target><candidate/></target>
> > > > <config>
> > > > =A0<list operation=3D"delete"= ;>
> > > > =A0 <key-node>key-value</key-node>
> > > > =A0</list>
> > > > </config>
> > > > </edit-config>
> > > >
> > > > and rigorously reading the RFC regarding operation and
> > > > default-operation, the operation attribute for <key-node> is "merge",
> > > > thus, technically, this edit-config operation operates on the
> > <key-node>
> > > > twice:
> > > >
> > >
> > > The operation is inherited from its parent if no "nc:operation"
> > > attribute is specified. The keys need to be present to specify the list
> > > node to be deleted.
> >
> > can you point to the paragraph in netconf RFC which says that the
> > operation is inherited?
> >
> >
> the delete operation on the /container node is for the container and all its
> descendants. =A0That is how it is inherited. I should have said "effective"
> operation
> instead of "inherited".

=A0 =A0 =A0 operation: =A0Elements in the <config> subt= ree MAY contain an
=A0 =A0 =A0 =A0 =A0"operation" attribute, which bel= ongs to the NETCONF namespace
=A0 =A0 =A0 =A0 =A0defined in Section 3.1. =A0The attribute i= dentifies the point in
=A0 =A0 =A0 =A0 =A0the configuration to perform the operation= and MAY appear on
=A0 =A0 =A0 =A0 =A0multiple elements throughout the <confi= g> subtree.

=A0 =A0 =A0 =A0 =A0If the "operation" attribute is = not specified, the
=A0 =A0 =A0 =A0 =A0configuration is merged into the configura= tion datastore.

in this case, the "operation" attribute for <key-node> is not specified.
So the provided example request is equivalent to this request:

<list operation=3D"delete">
=A0<key-node operation=3D"merge">key-value</key-node> </list>

so basically it's the same as above - there is a request do delete
<list> while creating and/or keeping <key-node> around - both cannot be
done. I cannot find any exception in the RFC for list/key-node combo
case.


Perhaps 1 new sentence (After the 1 about no attribute=3Dmerge):

=A0 If the operation attribute is not present for a key leaf node, and
=A0 the edit operation for the parent node is "delete= " or "remove",
=A0 then the operation for the key leaf node is the same as its parent node.


Andy

=A0
>
>
> >
> > >
> > >
> > > > 1.) deleting the value via deletion of the list entity <list>
> > > > 2.) merging in a new value via "merg= e" on the <key-node>
> > > >
> > > >
> > > > The RFC has <default-operation>none</default-operation> in all deletion
> > > > examples, which makes us believe that indeed when processing the
> > > > mentioned request, the <key-node>'s operation would be "merge" a= nd thus
> > > > the operation undefined.
> > > >
> > > > Is this how it's supposed to be or ar= e we reading it wrong?
> > > >
> > > >
> > > the latter
> > >
> > >
> > > > Thanks,
> > > > Klement
> > > > _______________________________________________
> > > > Netconf mailing list
> > > > Netconf@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/ne= tconf
> > > >
> >
> >
> Andy




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


--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com=20

--001a11c125103f978504ff563925-- From nobody Tue Jul 29 08:03:08 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE161B283E for ; Tue, 29 Jul 2014 08:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 jsF6fZZFn-8S for ; Tue, 29 Jul 2014 08:03:02 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A63841A0307 for ; Tue, 29 Jul 2014 08:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13442; q=dns/txt; s=iport; t=1406646181; x=1407855781; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GlFTvzlv6+Zt4idKF2dCoEbwnC+f1MSi6PglsyH4JJE=; b=jEC2ET5d28723py0xn+fxvtkMU4Lw+SK+CkP1siktVXZov9Lra5w4dtT ZzPvyJncK/HkgjJshcFfKx2mtvcrDquh0yJcZJwDuaEoKeo5QXUwu7LsU 5wyM+PeuzswdSI46hc1D4aAHVkKj6pJ5udSdMYH97Fw58zL62ZYJNt7xM 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMFADe311OtJV2T/2dsb2JhbABZgw5SVwSCdMhuCoZ4UwEZdRZ3hAMBAQEDAQEBASAROgsQAgEIGAICJgICAiULFRACBA4FCYgxCA2nZpcsF4Esi2OBWQIRAR0YGweCeYFRBbAag0lsgQMJFyI X-IronPort-AV: E=Sophos;i="5.01,757,1400025600"; d="scan'208";a="343573524" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-2.cisco.com with ESMTP; 29 Jul 2014 15:03:00 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s6TF30Pm030501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jul 2014 15:03:00 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.17]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Tue, 29 Jul 2014 10:03:00 -0500 From: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" To: "andy@yumaworks.com" Thread-Topic: [Netconf] edit-config operation inconsistency Thread-Index: AQHPqnZB7zgA6VWc9UyRPcHJnzYLfZu17mwAgAACj4CAAAMtgIABDIyAgABMcgCAACixAIAAAzCAgAACOwA= Date: Tue, 29 Jul 2014 15:03:00 +0000 Message-ID: <1406646178.21825.6.camel@ksekera-fedora> References: <1406560309.12287.21.camel@ksekera-fedora> <1406561507.12287.24.camel@ksekera-fedora> <1406619859.12287.31.camel@ksekera-fedora> <53D7B316.8020903@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.221.176] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/dQexBSaSqkl0EpQ1rztAB8aZNAo Cc: "netconf@ietf.org" Subject: Re: [Netconf] edit-config operation inconsistency X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 15:03:07 -0000 T24gVHVlLCAyMDE0LTA3LTI5IGF0IDA3OjU0IC0wNzAwLCBBbmR5IEJpZXJtYW4gd3JvdGU6DQo+ IE9uIFR1ZSwgSnVsIDI5LCAyMDE0IGF0IDc6NDMgQU0sIEJhbGF6cyBMZW5neWVsIDxiYWxhenMu bGVuZ3llbEBlcmljc3Nvbi5jb20NCj4gPiB3cm90ZToNCj4gDQo+ID4gIEhlbGxvLA0KPiA+IEkg YWx3YXlzIHRvdWdodCB0aGUgb3BlcmF0aW9uIGF0dHJpYnV0ZSBpcyBpbmhlcml0ZWQuDQo+ID4N Cj4gDQo+IFRoaXMgaXMgaG93IGV2ZXJ5Ym9keSBpbXBsZW1lbnRzIGl0LCBhbmQgd2hhdCB3ZSBp bnRlbmRlZCAocHJlLTQ3NDEpLg0KPiBPdGhlcndpc2UsIHdvdWxkIGEgInJlcGxhY2UiIG9wZXJh dGlvbiBmb3Igc29tZSBhcmJpdHJhcnkgc3VidHJlZQ0KPiByZXF1aXJlIG5jOm9wZXJhdGlvbj0i cmVwbGFjZSIgaW4gZXZlcnkgcmVwbGFjZW1lbnQgZGVzY2VuZGFudCBub2RlPw0KPiANCj4gDQo+ IEFuZHkNCj4gDQoNCldlbGwgaWYgdGhlIGRlZmF1bHQtb3BlcmF0aW9uIGlzIHVuY2hhbmdlZCwg dGhlbg0KDQo8Y29udGFpbmVyIG9wZXJhdGlvbj0icmVwbGFjZSI+DQogPGxlYWYvPg0KPC9jb250 YWluZXI+DQoNCndvcmtzIHBlcmZlY3RseSBmaW5lIGlmIHRoZSBvcGVyYXRpb24gZm9yIDxsZWFm PiBpcyBhc3N1bWVkIHRvIGJlIGENCiJtZXJnZSIuIEZpcnN0LCB0aGUgc2VydmVyIHJlbW92ZXMg dGhlIGV4aXN0aW5nIDxjb250YWluZXI+LCByZXBsYWNlcyBpdA0Kd2l0aCBlbXB0eSBvbmUgYW5k IHRoZW4gbWVyZ2VzIHRoZSA8bGVhZj4gaW4uDQoNCkZyb20gdGhpcyBwb2ludCBvZiB2aWV3LCAi bWVyZ2UiIG9uIGNoaWxkIGlzIGNvbXBhdGlibGUgd2l0aCAiY3JlYXRlIiBvcg0KInJlcGxhY2Ui IG9uIHBhcmVudC4NCg0KSSBkb24ndCBzZWUgYW55IHNlbnRlbmNlIGluIHRoZSBSRkMgd2hpY2gg c2F5cyB0aGF0IHRoZSBvcGVyYXRpb24gaXMNCmluaGVyaXRlZC4NCg0KPiANCj4gDQo+IA0KPiAN Cj4gDQo+IA0KPiA+IEluaGVyaXRlZCBpbiBhIHNlbnNlIHRoYXQgYW4gWE1MIGVsZW1lbnQgYWN0 dWFsbHkgY29udGFpbnMvaW5jbHVkZXMgYWxsDQo+ID4gc3ViLWVsZW1lbnRzIHVuZGVyIGl0LiBT byBjcmVhdGluZy9kZWxldGluZy9tZXJnaW5nIHRoZSBlbGVtZW50IG1lYW5zDQo+ID4gY3JlYXRp bmcvZGVsZXRpbmcvbWVyZ2luZyBhbGwgaXRzIGNvbnRlbnRzIGFzIHdlbGwuIFNvIHVubGVzcyB5 b3UgbGF0ZXINCj4gPiBvdmVycmlkZSB0aGlzIHdpdGggbW9yZSBzcGVjaWZpYyBpbnN0cnVjdGlv bnMgZm9yIG9uZSBvZiB0aGUgY29udGFpbmVkDQo+ID4gZWxlbWVudHMgaXQgc2hvdWxkIGJlIHZh bGlkIGZvciB0aGUgY29tcGxldGUgZWxlbWVudCB3aXRoIGFsbCBpdHMgY29udGVudC4NCj4gPg0K PiA+IElmIG9wZXJhdGlvbiBpcyBub3QgaW5oZXJpdGFibGUgd2UgaGF2ZSBzb21lIGludGVyZXN0 aW5nIGNhc2VzOg0KPiA+IC0geW91ciBleGFtcGxlcw0KPiA+IC0gZGVmYXVsdCBvcGVyYXRpb249 bm9uZSBhbmQgSSB3YW50IHRvIGNyZWF0ZSBhIHNpemVhYmxlIHN1YnRyZWUuIEkgaGF2ZQ0KPiA+ IHRvIHBsYWNlIHRoZSBtZXJnZS9jcmVhdGUgb3BlcmF0aW9uIG9uIGV2ZXJ5IG5vZGUuIERvbid0 IGxpa2UgaXQsIG1ha2VzDQo+ID4gbm9uZS11bnVzYWJsZSBleGNlcHQgZm9yIGRlbGV0ZS9yZW1v dmUuDQo+ID4gTGV0cyBzYXkgd2UgaGF2ZSB0aGUgZm9sbG93aW5nIGRhdGEgbW9kZWw6DQo+ID4N Cj4gPiByb3V0aW5nDQo+ID4gICArLS1zdGF0aWMtcm91dGluZw0KPiA+ICAgfCAgICstLXJvdXRl IFtyb3V0ZUlkXQ0KPiA+ICAgfCAgICAgICAgKy0tcm91dGVJZCAJCQlpcHByZWZpeA0KPiA+ICAg fCAgICAgICAgKy0tcGF0aC10by1kZXN0aW5hdGlvbiAJW25leHRob3BdDQo+ID4gICB8ICAgICAg ICAgICAgKy0tbmV4dEhvcCAJCWlwQWRkcmVzcw0KPiA+ICAgfCAgICAgICAgICAgICstLW91dGdv aW5nSW50ZXJmYWNlICAgCXN0cmluZw0KPiA+ICAgICAgICAgICAgICAgICstLWJmZEFjdGl2ZQkJ Ym9vbGVhbg0KPiA+DQo+ID4gSSB3YW50IHRvIGNyZWF0ZSBhIHN0YXRpYyByb3V0ZSB3aXRoIGFs bCBpdHMgc3ViLWVsZW1lbnRzIGJ1dCBvbmx5IGlmIHRoZQ0KPiA+IHN0YXRpYy1yb3V0aW5nIHBy ZXNlbmNlIGNvbnRhaW5lciBleGlzdHMgKHN0YXRpYyByb3V0aW5nIGlzDQo+ID4gYWxsb3dlZC9l bmFibGVkKS4NCj4gPiA8ZGVmYXVsdC1vcGVyYXRpb24+bm9uZTwvZGVmYXVsdC1vcGVyYXRpb24+ DQo+ID4gPGNvbmZpZz4NCj4gPiAgICA8c3RhdGljLXJvdXRpbmc+ICAtLS0gdGhpcyB3aWxsIGNo ZWNrIHRoYXQgc3RhdGljIHJvdXRpbmcgZXhpc3RzLg0KPiA+ICAgICAgIDxyb3V0ZSBvcGVyYXRp b249ImNyZWF0ZSI+ICAtLXRoaXMgd2lsbCBjcmVhdGUgdGhlIGludGVyZmFjZQ0KPiA+ICAgICAg ICAgIDxyb3V0ZWlkPjEuMS4xLjEvMjQ8L3JvdXRlaWQ+ICAgLS0gSSBkb24ndCB3YW50IHRvIHB1 dA0KPiA+IG9wZXJhdGlvbj1jcmVhdGUgb24gYWxsIGZ1cnRoZXIgbm9kZXMgNSB0aW1lcyBvciBt b3JlIGRlcGVuZGluZyBvbiB0aGUNCj4gPiBudW1iZXIgb2YgcGF0aHMNCj4gPiAgICAgICAgICA8 cGF0aC10by1kZXN0aW5hdGlvbj4NCj4gPiAgICAgICAgICAgICA8bmV4dEhvcD4xLjEuMS41PC9u ZXh0SG9wPg0KPiA+ICAgICAgICAgICAgIDxvdXRnb2luZ0ludGVyZmFjZT5ldGgwPC9vdXRnb2lu Z0ludGVyZmFjZT4NCj4gPiAgICAgICAgICAgICA8YmZkQWN0aXZlPnRydWU8L2JmZEFjdGl2ZT4N Cj4gPiAgICAgICAgICA8L3BhdGgtdG8tZGVzdGluYXRpb24+DQo+ID4gICAgICAgPC9yb3V0ZT4N Cj4gPiAgICA8L3N0YXRpYy1yb3V0aW5nPg0KPiA+IDwvY29uZmlnPg0KPiA+DQo+ID4gIFRoaXMg d2FzIHZlcnkgbmljZSBhbmQgbG9naWNhbC4gSSBob3BlIGl0IHN0aWxsIHdvcmtzLg0KPiA+IHJl Z2FyZHMgQmFsYXpzDQo+ID4NCj4gPiBPbiAyMDE0LTA3LTI5IDE0OjE3LCBBbmR5IEJpZXJtYW4g d3JvdGU6DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBPbiBUdWUsIEp1bCAyOSwgMjAxNCBhdCAx Mjo0NCBBTSwgS2xlbWVudCBTZWtlcmEgLVggKGtzZWtlcmEgLSBQYW50aGVvbg0KPiA+IFRlY2hu b2xvZ2llcyBTUk8gYXQgQ2lzY28pIDxrc2VrZXJhQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4NCj4g Pj4gT24gTW9uLCAyMDE0LTA3LTI4IGF0IDA4OjQzIC0wNzAwLCBBbmR5IEJpZXJtYW4gd3JvdGU6 DQo+ID4+ID4gT24gTW9uLCBKdWwgMjgsIDIwMTQgYXQgODozMSBBTSwgS2xlbWVudCBTZWtlcmEg LVggKGtzZWtlcmEgLSBQYW50aGVvbg0KPiA+PiA+IFRlY2hub2xvZ2llcyBTUk8gYXQgQ2lzY28p IDxrc2VrZXJhQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4+ID4NCj4gPj4gPiA+IE9uIE1vbiwgMjAx NC0wNy0yOCBhdCAwODoyMiAtMDcwMCwgQW5keSBCaWVybWFuIHdyb3RlOg0KPiA+PiA+ID4gPiBP biBNb24sIEp1bCAyOCwgMjAxNCBhdCA4OjExIEFNLCBLbGVtZW50IFNla2VyYSAtWCAoa3Nla2Vy YSAtDQo+ID4+IFBhbnRoZW9uDQo+ID4+ID4gPiA+IFRlY2hub2xvZ2llcyBTUk8gYXQgQ2lzY28p IDxrc2VrZXJhQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4+ID4gPiA+DQo+ID4+ID4gPiA+ID4gSGkg YWxsLA0KPiA+PiA+ID4gPiA+DQo+ID4+ID4gPiA+ID4gd2UgYXJlIGN1cnJlbnRseSBkZWJhdGlu ZyBhbiBpc3N1ZSB3ZSBmb3VuZCBhbmQgd291bGQgbGlrZSB0bw0KPiA+PiBoYXZlIHNvbWUNCj4g Pj4gPiA+ID4gPiBjbGFyaWZpY2F0aW9uLiBOZXRjb25mIFJGQyBzYXlzIHRoYXQgdGhlIGVkaXQt Y29uZmlnIG9wZXJhdGlvbg0KPiA+PiB3aGljaA0KPiA+PiA+ID4gPiA+IGNvbnRhaW5zIG11bHRp cGxlIHN1Yi1vcGVyYXRpb25zIG9uIHRoZSBzYW1lIGRhdGEgaXMgdW5kZWZpbmVkLg0KPiA+PiA+ ID4gPiA+DQo+ID4+ID4gPiA+ID4gc28gd2hlbiBjb25zaWRlcmluZyB0aGlzIHJlcXVlc3Q6DQo+ ID4+ID4gPiA+ID4NCj4gPj4gPiA+ID4gPiA8ZWRpdC1jb25maWc+DQo+ID4+ID4gPiA+ID4gPHRh cmdldD48Y2FuZGlkYXRlLz48L3RhcmdldD4NCj4gPj4gPiA+ID4gPiA8Y29uZmlnPg0KPiA+PiA+ ID4gPiA+ICA8Y29udGFpbmVyIG9wZXJhdGlvbj0iZGVsZXRlIj4NCj4gPj4gPiA+ID4gPiAgIDxs ZWFmIG9wZXJhdGlvbj0iY3JlYXRlIi8+DQo+ID4+ID4gPiA+ID4gIDwvY29udGFpbmVyPg0KPiA+ PiA+ID4gPiA+IDwvY29uZmlnPg0KPiA+PiA+ID4gPiA+IDwvZWRpdC1jb25maWc+DQo+ID4+ID4g PiA+ID4NCj4gPj4gPiA+ID4gPiB0aGUgb3V0Y29tZSBpcyB1bmRlZmluZWQsIHNpbmNlIHRoZSBj bGllbnQgd2FudHMgZG8gZGVsZXRlDQo+ID4+IGNvbnRhaW5lcg0KPiA+PiA+ID4gPiA+IDxjb250 YWluZXI+LCB3aGlsZSBzaW11bHRhbmVvdXNseSBjcmVhdGluZyA8bGVhZj4gd2hpY2ggaXMgcGFy dCBvZg0KPiA+PiA+ID4gPiA+IDxjb250YWluZXI+Lg0KPiA+PiA+ID4gPiA+DQo+ID4+ID4gPiA+ ID4NCj4gPj4gPiA+ID4gSXQgaXMgZGVmaW5lZC4NCj4gPj4gPiA+ID4gRG9lcyB0aGUgbm9kZSAv Y29udGFpbmVyIGV4aXN0IGluIHRoZSB0YXJnZXQgZGF0YXN0b3JlPw0KPiA+PiA+ID4gPiBJZiB5 ZXMsIHRoZW4gdGhlIGNyZWF0ZSBvcGVyYXRpb24gb24gL2NvbnRhaW5lci9sZWFmIE1VU1QgZmFp bC4NCj4gPj4gPiA+ID4gSWYgbm8sIHRoZW4gdGhlIGRlbGV0ZSBvcGVyYXRpb24gb24gL2NvbnRh aW5lciBNVVNUIGZhaWwuDQo+ID4+ID4gPg0KPiA+PiA+ID4gd2hhdCBpZiAvY29udGFpbmVyIGV4 aXN0cyBidXQgL2NvbnRhaW5lci9sZWFmIGRvZXMgbm90PyB0aGlzIHdheSBib3RoDQo+ID4+ID4g PiBzdWItb3BlcmF0aW9ucyBjb3VsZCBiZSBwZXJmb3JtZWQNCj4gPj4gPiA+DQo+ID4+ID4NCj4g Pj4gPg0KPiA+PiA+IG5vdCByZWFsbHkuIElmIGltcGxlbWVudGVkIGNvcnJlY3RseSB0aGVuIGlm IHRoZSBkZWxldGUgb24gL2NvbnRhaW5lcg0KPiA+PiA+IHN1Y2NlZWRzLA0KPiA+PiA+IHRoZW4g YWxsIGl0cyBkZXNjZW5kYW50cyBhcmUgYWxzbyBkZWxldGVkLiAgVGhlIHJlc3VsdCBpbiB0aGUg dGFyZ2V0DQo+ID4+ID4gZGF0YXN0b3JlIGNhbm5vdA0KPiA+PiA+IHBvc3NpYmx5IGNvbXBsZXRl IGJvdGggYSBkZWxldGUgb24gYW4gYW5jZXN0b3IgYW5kIGNyZWF0ZSBvZiBhDQo+ID4+IGRlc2Nl bmRhbnQNCj4gPj4gPiBpbiB0aGUgc2FtZSBlZGl0LiBPdXIgc2VydmVyIHJldHVybnMgYW4gZXJy b3IgYmVjYXVzZSBpdCBjYW5ub3QgaG9ub3INCj4gPj4gPiBib3RoIHJlcXVlc3RzLg0KPiA+PiA+ DQo+ID4+DQo+ID4+IEkgYmVsaWV2ZSB0aGF0IHRoaXMgaXMgdGhlIHBhcnQgd2hlcmUNCj4gPj4N Cj4gPj4gICAgICAgSWYgdGhlIDxlZGl0LWNvbmZpZz4gb3BlcmF0aW9uIGNvbnRhaW5zIG11bHRp cGxlIHN1Yi1vcGVyYXRpb25zDQo+ID4+ICAgICAgIHRoYXQgYXBwbHkgdG8gdGhlIHNhbWUgY29u Y2VwdHVhbCBub2RlIGluIHRoZSB1bmRlcmx5aW5nIGRhdGENCj4gPj4gICAgICAgbW9kZWwsIHRo ZW4gdGhlIHJlc3VsdCBvZiB0aGUgb3BlcmF0aW9uIGlzIHVuZGVmaW5lZCAoaS5lLiwNCj4gPj4g ICAgICAgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhlIE5FVENPTkYgcHJvdG9jb2wpLg0KPiA+Pg0K PiA+PiBjb21lcyBpbnRvIHBsYXkuIEV4YWN0bHkgYXMgeW91IHNheSwgdGFyZ2V0IGRhdGFzdG9y ZSBjYW5ub3QgY29tcGxldGUNCj4gPj4gYm90aCB0aGUgZGVsZXRpb24gYW5kIGNyZWF0aW9uLCBz aW5jZSBib3RoIG9wZXJhdGUgb24gdGhlIHNhbWUgZGF0YSBidXQNCj4gPj4gcnVsZSBlYWNoIG90 aGVyIG91dC4NCj4gPj4NCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPiA+DQo+ID4+ID4g PiA+DQo+ID4+ID4gPiA+DQo+ID4+ID4gPiA+DQo+ID4+ID4gPiA+ID4gTm93LCB3aGVuIGNvbnNp ZGVyaW5nIGEgc2ltcGxlIGxpc3QgZGVsZXRpb246DQo+ID4+ID4gPiA+ID4NCj4gPj4gPiA+ID4g PiA8ZWRpdC1jb25maWc+DQo+ID4+ID4gPiA+ID4gPHRhcmdldD48Y2FuZGlkYXRlLz48L3Rhcmdl dD4NCj4gPj4gPiA+ID4gPiA8Y29uZmlnPg0KPiA+PiA+ID4gPiA+ICA8bGlzdCBvcGVyYXRpb249 ImRlbGV0ZSI+DQo+ID4+ID4gPiA+ID4gICA8a2V5LW5vZGU+a2V5LXZhbHVlPC9rZXktbm9kZT4N Cj4gPj4gPiA+ID4gPiAgPC9saXN0Pg0KPiA+PiA+ID4gPiA+IDwvY29uZmlnPg0KPiA+PiA+ID4g PiA+IDwvZWRpdC1jb25maWc+DQo+ID4+ID4gPiA+ID4NCj4gPj4gPiA+ID4gPiBhbmQgcmlnb3Jv dXNseSByZWFkaW5nIHRoZSBSRkMgcmVnYXJkaW5nIG9wZXJhdGlvbiBhbmQNCj4gPj4gPiA+ID4g PiBkZWZhdWx0LW9wZXJhdGlvbiwgdGhlIG9wZXJhdGlvbiBhdHRyaWJ1dGUgZm9yIDxrZXktbm9k ZT4gaXMNCj4gPj4gIm1lcmdlIiwNCj4gPj4gPiA+ID4gPiB0aHVzLCB0ZWNobmljYWxseSwgdGhp cyBlZGl0LWNvbmZpZyBvcGVyYXRpb24gb3BlcmF0ZXMgb24gdGhlDQo+ID4+ID4gPiA8a2V5LW5v ZGU+DQo+ID4+ID4gPiA+ID4gdHdpY2U6DQo+ID4+ID4gPiA+ID4NCj4gPj4gPiA+ID4NCj4gPj4g PiA+ID4gVGhlIG9wZXJhdGlvbiBpcyBpbmhlcml0ZWQgZnJvbSBpdHMgcGFyZW50IGlmIG5vICJu YzpvcGVyYXRpb24iDQo+ID4+ID4gPiA+IGF0dHJpYnV0ZSBpcyBzcGVjaWZpZWQuIFRoZSBrZXlz IG5lZWQgdG8gYmUgcHJlc2VudCB0byBzcGVjaWZ5IHRoZQ0KPiA+PiBsaXN0DQo+ID4+ID4gPiA+ IG5vZGUgdG8gYmUgZGVsZXRlZC4NCj4gPj4gPiA+DQo+ID4+ID4gPiBjYW4geW91IHBvaW50IHRv IHRoZSBwYXJhZ3JhcGggaW4gbmV0Y29uZiBSRkMgd2hpY2ggc2F5cyB0aGF0IHRoZQ0KPiA+PiA+ ID4gb3BlcmF0aW9uIGlzIGluaGVyaXRlZD8NCj4gPj4gPiA+DQo+ID4+ID4gPg0KPiA+PiA+IHRo ZSBkZWxldGUgb3BlcmF0aW9uIG9uIHRoZSAvY29udGFpbmVyIG5vZGUgaXMgZm9yIHRoZSBjb250 YWluZXIgYW5kDQo+ID4+IGFsbCBpdHMNCj4gPj4gPiBkZXNjZW5kYW50cy4gIFRoYXQgaXMgaG93 IGl0IGlzIGluaGVyaXRlZC4gSSBzaG91bGQgaGF2ZSBzYWlkDQo+ID4+ICJlZmZlY3RpdmUiDQo+ ID4+ID4gb3BlcmF0aW9uDQo+ID4+ID4gaW5zdGVhZCBvZiAiaW5oZXJpdGVkIi4NCj4gPj4NCj4g Pj4gICAgICAgb3BlcmF0aW9uOiAgRWxlbWVudHMgaW4gdGhlIDxjb25maWc+IHN1YnRyZWUgTUFZ IGNvbnRhaW4gYW4NCj4gPj4gICAgICAgICAgIm9wZXJhdGlvbiIgYXR0cmlidXRlLCB3aGljaCBi ZWxvbmdzIHRvIHRoZSBORVRDT05GIG5hbWVzcGFjZQ0KPiA+PiAgICAgICAgICBkZWZpbmVkIGlu IFNlY3Rpb24gMy4xLiAgVGhlIGF0dHJpYnV0ZSBpZGVudGlmaWVzIHRoZSBwb2ludCBpbg0KPiA+ PiAgICAgICAgICB0aGUgY29uZmlndXJhdGlvbiB0byBwZXJmb3JtIHRoZSBvcGVyYXRpb24gYW5k IE1BWSBhcHBlYXIgb24NCj4gPj4gICAgICAgICAgbXVsdGlwbGUgZWxlbWVudHMgdGhyb3VnaG91 dCB0aGUgPGNvbmZpZz4gc3VidHJlZS4NCj4gPj4NCj4gPj4gICAgICAgICAgSWYgdGhlICJvcGVy YXRpb24iIGF0dHJpYnV0ZSBpcyBub3Qgc3BlY2lmaWVkLCB0aGUNCj4gPj4gICAgICAgICAgY29u ZmlndXJhdGlvbiBpcyBtZXJnZWQgaW50byB0aGUgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUuDQo+ ID4+DQo+ID4+IGluIHRoaXMgY2FzZSwgdGhlICJvcGVyYXRpb24iIGF0dHJpYnV0ZSBmb3IgPGtl eS1ub2RlPiBpcyBub3Qgc3BlY2lmaWVkLg0KPiA+PiBTbyB0aGUgcHJvdmlkZWQgZXhhbXBsZSBy ZXF1ZXN0IGlzIGVxdWl2YWxlbnQgdG8gdGhpcyByZXF1ZXN0Og0KPiA+Pg0KPiA+PiA8bGlzdCBv cGVyYXRpb249ImRlbGV0ZSI+DQo+ID4+ICA8a2V5LW5vZGUgb3BlcmF0aW9uPSJtZXJnZSI+a2V5 LXZhbHVlPC9rZXktbm9kZT4NCj4gPj4gPC9saXN0Pg0KPiA+Pg0KPiA+PiBzbyBiYXNpY2FsbHkg aXQncyB0aGUgc2FtZSBhcyBhYm92ZSAtIHRoZXJlIGlzIGEgcmVxdWVzdCBkbyBkZWxldGUNCj4g Pj4gPGxpc3Q+IHdoaWxlIGNyZWF0aW5nIGFuZC9vciBrZWVwaW5nIDxrZXktbm9kZT4gYXJvdW5k IC0gYm90aCBjYW5ub3QgYmUNCj4gPj4gZG9uZS4gSSBjYW5ub3QgZmluZCBhbnkgZXhjZXB0aW9u IGluIHRoZSBSRkMgZm9yIGxpc3Qva2V5LW5vZGUgY29tYm8NCj4gPj4gY2FzZS4NCj4gPj4NCj4g Pj4NCj4gPiAgUGVyaGFwcyAxIG5ldyBzZW50ZW5jZSAoQWZ0ZXIgdGhlIDEgYWJvdXQgbm8gYXR0 cmlidXRlPW1lcmdlKToNCj4gPg0KPiA+ICAgIElmIHRoZSBvcGVyYXRpb24gYXR0cmlidXRlIGlz IG5vdCBwcmVzZW50IGZvciBhIGtleSBsZWFmIG5vZGUsIGFuZA0KPiA+ICAgdGhlIGVkaXQgb3Bl cmF0aW9uIGZvciB0aGUgcGFyZW50IG5vZGUgaXMgImRlbGV0ZSIgb3IgInJlbW92ZSIsDQo+ID4g ICB0aGVuIHRoZSBvcGVyYXRpb24gZm9yIHRoZSBrZXkgbGVhZiBub2RlIGlzIHRoZSBzYW1lIGFz IGl0cyBwYXJlbnQgbm9kZS4NCj4gPg0KPiA+DQo+ID4gIEFuZHkNCj4gPg0KPiA+DQo+ID4NCj4g Pj4gPg0KPiA+PiA+DQo+ID4+ID4gPg0KPiA+PiA+ID4gPg0KPiA+PiA+ID4gPg0KPiA+PiA+ID4g PiA+IDEuKSBkZWxldGluZyB0aGUgdmFsdWUgdmlhIGRlbGV0aW9uIG9mIHRoZSBsaXN0IGVudGl0 eSA8bGlzdD4NCj4gPj4gPiA+ID4gPiAyLikgbWVyZ2luZyBpbiBhIG5ldyB2YWx1ZSB2aWEgIm1l cmdlIiBvbiB0aGUgPGtleS1ub2RlPg0KPiA+PiA+ID4gPiA+DQo+ID4+ID4gPiA+ID4NCj4gPj4g PiA+ID4gPiBUaGUgUkZDIGhhcyA8ZGVmYXVsdC1vcGVyYXRpb24+bm9uZTwvZGVmYXVsdC1vcGVy YXRpb24+IGluIGFsbA0KPiA+PiBkZWxldGlvbg0KPiA+PiA+ID4gPiA+IGV4YW1wbGVzLCB3aGlj aCBtYWtlcyB1cyBiZWxpZXZlIHRoYXQgaW5kZWVkIHdoZW4gcHJvY2Vzc2luZyB0aGUNCj4gPj4g PiA+ID4gPiBtZW50aW9uZWQgcmVxdWVzdCwgdGhlIDxrZXktbm9kZT4ncyBvcGVyYXRpb24gd291 bGQgYmUgIm1lcmdlIg0KPiA+PiBhbmQgdGh1cw0KPiA+PiA+ID4gPiA+IHRoZSBvcGVyYXRpb24g dW5kZWZpbmVkLg0KPiA+PiA+ID4gPiA+DQo+ID4+ID4gPiA+ID4gSXMgdGhpcyBob3cgaXQncyBz dXBwb3NlZCB0byBiZSBvciBhcmUgd2UgcmVhZGluZyBpdCB3cm9uZz8NCj4gPj4gPiA+ID4gPg0K PiA+PiA+ID4gPiA+DQo+ID4+ID4gPiA+IHRoZSBsYXR0ZXINCj4gPj4gPiA+ID4NCj4gPj4gPiA+ ID4NCj4gPj4gPiA+ID4gPiBUaGFua3MsDQo+ID4+ID4gPiA+ID4gS2xlbWVudA0KPiA+PiA+ID4g PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ ID4gPiA+ID4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPj4gPiA+ID4gPiBOZXRjb25mQGlldGYu b3JnDQo+ID4+ID4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRjb25mDQo+ID4+ID4gPiA+ID4NCj4gPj4gPiA+DQo+ID4+ID4gPg0KPiA+PiA+IEFuZHkNCj4g Pj4NCj4gPj4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiBOZXRjb25mIG1haWxpbmcgbGlzdE5ldGNvbmZAaWV0Zi5vcmdo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gPg0KPiA+DQo+ ID4gLS0NCj4gPiBCYWxhenMgTGVuZ3llbCAgICAgICAgICAgICAgICAgICAgICAgRXJpY3Nzb24g SHVuZ2FyeSBMdGQuDQo+ID4gU2VuaW9yIFNwZWNpYWxpc3QNCj4gPiBFQ046IDgzMSA3MzIwICAg ICAgICAgICAgICAgICAgICAgICAgVGVsOiArMzYtMS00MzctNzMyMA0KPiA+IE1vYmlsZTogKzM2 LTcwLTMzMC03OTA5ICAgICAgICAgICAgICBlbWFpbDogQmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24u Y29tDQo+ID4NCj4gPg0KDQo= From nobody Tue Jul 29 08:41:37 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A741A02D0 for ; Tue, 29 Jul 2014 08:41:35 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 tcwhJ5p7Mjwh for ; Tue, 29 Jul 2014 08:41:24 -0700 (PDT) Received: from p3plsmtpa09-01.prod.phx3.secureserver.net (p3plsmtpa09-01.prod.phx3.secureserver.net [173.201.193.230]) by ietfa.amsl.com (Postfix) with ESMTP id 7A41E1B29D3 for ; Tue, 29 Jul 2014 08:38:21 -0700 (PDT) Received: from [192.168.2.3] ([50.179.41.78]) by p3plsmtpa09-01.prod.phx3.secureserver.net with id YFeG1o00E1hB5UJ01FeGu5; Tue, 29 Jul 2014 08:38:20 -0700 Message-ID: <53D7BFE2.9080003@seguesoft.com> Date: Tue, 29 Jul 2014 10:38:10 -0500 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: netconf@ietf.org References: <1406560309.12287.21.camel@ksekera-fedora> <1406561507.12287.24.camel@ksekera-fedora> <1406619859.12287.31.camel@ksekera-fedora> <53D7B316.8020903@ericsson.com> <1406646178.21825.6.camel@ksekera-fedora> In-Reply-To: <1406646178.21825.6.camel@ksekera-fedora> Content-Type: multipart/alternative; boundary="------------040902030607050600090008" Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/tYAbiEvb3xTMRRnQ9CQMXBgv3KA Subject: Re: [Netconf] edit-config operation inconsistency X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 15:41:35 -0000 This is a multi-part message in MIME format. --------------040902030607050600090008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/29/2014 10:03 AM, Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco) wrote: > On Tue, 2014-07-29 at 07:54 -0700, Andy Bierman wrote: >> On Tue, Jul 29, 2014 at 7:43 AM, Balazs Lengyel >> wrote: >>> Hello, >>> I always tought the operation attribute is inherited. >>> >> This is how everybody implements it, and what we intended (pre-4741). >> Otherwise, would a "replace" operation for some arbitrary subtree >> require nc:operation="replace" in every replacement descendant node? >> >> >> Andy >> > Well if the default-operation is unchanged, then > > > > > > works perfectly fine if the operation for is assumed to be a > "merge". First, the server removes the existing , replaces it > with empty one and then merges the in. > > From this point of view, "merge" on child is compatible with "create" or > "replace" on parent. > > I don't see any sentence in the RFC which says that the operation is > inherited. RFC6243 With-defaults Capability for NETCONF may help clarify wh "effective operation" means in an "edit-config": 4.5.2 . Operation ... If the 'default' attribute is present, then the effective operation for the target data node MUST be 'create', 'merge', or 'replace'. If not, then the server MUST return an response with an 'invalid-value' error-tag. For example, if 'create' is the effective operation, then the create request must be valid on its own (e.g., current data node MUST NOT exist). The procedure for determining the effective operation is defined in [RFC6241 ]. I*t is derived from the 'default-operation' parameter and/or any operation attributes that are present in the data node or any of its ancestor nodes, within the request.* In other words the "operation" attribute has a "scope", that is, it applies to the nested nodes, until is is redefined. This is logical too. --Xiang Li >> >> >> >> >> >>> Inherited in a sense that an XML element actually contains/includes all >>> sub-elements under it. So creating/deleting/merging the element means >>> creating/deleting/merging all its contents as well. So unless you later >>> override this with more specific instructions for one of the contained >>> elements it should be valid for the complete element with all its content. >>> >>> If operation is not inheritable we have some interesting cases: >>> - your examples >>> - default operation=none and I want to create a sizeable subtree. I have >>> to place the merge/create operation on every node. Don't like it, makes >>> none-unusable except for delete/remove. >>> Lets say we have the following data model: >>> >>> routing >>> +--static-routing >>> | +--route [routeId] >>> | +--routeId ipprefix >>> | +--path-to-destination [nexthop] >>> | +--nextHop ipAddress >>> | +--outgoingInterface string >>> +--bfdActive boolean >>> >>> I want to create a static route with all its sub-elements but only if the >>> static-routing presence container exists (static routing is >>> allowed/enabled). >>> none >>> >>> --- this will check that static routing exists. >>> --this will create the interface >>> 1.1.1.1/24 -- I don't want to put >>> operation=create on all further nodes 5 times or more depending on the >>> number of paths >>> >>> 1.1.1.5 >>> eth0 >>> true >>> >>> >>> >>> >>> >>> This was very nice and logical. I hope it still works. >>> regards Balazs >>> >>> On 2014-07-29 14:17, Andy Bierman wrote: >>> >>> >>> >>> >>> On Tue, Jul 29, 2014 at 12:44 AM, Klement Sekera -X (ksekera - Pantheon >>> Technologies SRO at Cisco) wrote: >>> >>>> On Mon, 2014-07-28 at 08:43 -0700, Andy Bierman wrote: >>>>> On Mon, Jul 28, 2014 at 8:31 AM, Klement Sekera -X (ksekera - Pantheon >>>>> Technologies SRO at Cisco) wrote: >>>>> >>>>>> On Mon, 2014-07-28 at 08:22 -0700, Andy Bierman wrote: >>>>>>> On Mon, Jul 28, 2014 at 8:11 AM, Klement Sekera -X (ksekera - >>>> Pantheon >>>>>>> Technologies SRO at Cisco) wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> we are currently debating an issue we found and would like to >>>> have some >>>>>>>> clarification. Netconf RFC says that the edit-config operation >>>> which >>>>>>>> contains multiple sub-operations on the same data is undefined. >>>>>>>> >>>>>>>> so when considering this request: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> the outcome is undefined, since the client wants do delete >>>> container >>>>>>>> , while simultaneously creating which is part of >>>>>>>> . >>>>>>>> >>>>>>>> >>>>>>> It is defined. >>>>>>> Does the node /container exist in the target datastore? >>>>>>> If yes, then the create operation on /container/leaf MUST fail. >>>>>>> If no, then the delete operation on /container MUST fail. >>>>>> what if /container exists but /container/leaf does not? this way both >>>>>> sub-operations could be performed >>>>>> >>>>> >>>>> not really. If implemented correctly then if the delete on /container >>>>> succeeds, >>>>> then all its descendants are also deleted. The result in the target >>>>> datastore cannot >>>>> possibly complete both a delete on an ancestor and create of a >>>> descendant >>>>> in the same edit. Our server returns an error because it cannot honor >>>>> both requests. >>>>> >>>> I believe that this is the part where >>>> >>>> If the operation contains multiple sub-operations >>>> that apply to the same conceptual node in the underlying data >>>> model, then the result of the operation is undefined (i.e., >>>> outside the scope of the NETCONF protocol). >>>> >>>> comes into play. Exactly as you say, target datastore cannot complete >>>> both the deletion and creation, since both operate on the same data but >>>> rule each other out. >>>> >>>>> >>>>> >>>>>>> >>>>>>> >>>>>>>> Now, when considering a simple list deletion: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> key-value >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> and rigorously reading the RFC regarding operation and >>>>>>>> default-operation, the operation attribute for is >>>> "merge", >>>>>>>> thus, technically, this edit-config operation operates on the >>>>>> >>>>>>>> twice: >>>>>>>> >>>>>>> The operation is inherited from its parent if no "nc:operation" >>>>>>> attribute is specified. The keys need to be present to specify the >>>> list >>>>>>> node to be deleted. >>>>>> can you point to the paragraph in netconf RFC which says that the >>>>>> operation is inherited? >>>>>> >>>>>> >>>>> the delete operation on the /container node is for the container and >>>> all its >>>>> descendants. That is how it is inherited. I should have said >>>> "effective" >>>>> operation >>>>> instead of "inherited". >>>> operation: Elements in the subtree MAY contain an >>>> "operation" attribute, which belongs to the NETCONF namespace >>>> defined in Section 3.1. The attribute identifies the point in >>>> the configuration to perform the operation and MAY appear on >>>> multiple elements throughout the subtree. >>>> >>>> If the "operation" attribute is not specified, the >>>> configuration is merged into the configuration datastore. >>>> >>>> in this case, the "operation" attribute for is not specified. >>>> So the provided example request is equivalent to this request: >>>> >>>> >>>> key-value >>>> >>>> >>>> so basically it's the same as above - there is a request do delete >>>> while creating and/or keeping around - both cannot be >>>> done. I cannot find any exception in the RFC for list/key-node combo >>>> case. >>>> >>>> >>> Perhaps 1 new sentence (After the 1 about no attribute=merge): >>> >>> If the operation attribute is not present for a key leaf node, and >>> the edit operation for the parent node is "delete" or "remove", >>> then the operation for the key leaf node is the same as its parent node. >>> >>> >>> Andy >>> >>> >>> >>>>> >>>>>>> >>>>>>>> 1.) deleting the value via deletion of the list entity >>>>>>>> 2.) merging in a new value via "merge" on the >>>>>>>> >>>>>>>> >>>>>>>> The RFC has none in all >>>> deletion >>>>>>>> examples, which makes us believe that indeed when processing the >>>>>>>> mentioned request, the 's operation would be "merge" >>>> and thus >>>>>>>> the operation undefined. >>>>>>>> >>>>>>>> Is this how it's supposed to be or are we reading it wrong? >>>>>>>> >>>>>>>> >>>>>>> the latter >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> Klement >>>>>>>> _______________________________________________ >>>>>>>> Netconf mailing list >>>>>>>> Netconf@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/netconf >>>>>>>> >>>>>> >>>>> Andy >>>> >>> >>> _______________________________________________ >>> Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf >>> >>> >>> -- >>> Balazs Lengyel Ericsson Hungary Ltd. >>> Senior Specialist >>> ECN: 831 7320 Tel: +36-1-437-7320 >>> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >>> >>> > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- -- Xiang Li, Seguesoft, Champaign, IL (217) 721-5341 --------------040902030607050600090008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 7/29/2014 10:03 AM, Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco) wrote:
On Tue, 2014-07-29 at 07:54 -0700, Andy Bierman wrote:

On Tue, Jul 29, 2014 at 7:43 AM, Balazs Lengyel <balazs.lengyel@ericsson.com

wrote:


        

          
 Hello,
I always tought the operation attribute is inherited.



        

        
This is how everybody implements it, and what we intended (pre-4741).
Otherwise, would a "replace" operation for some arbitrary subtree
require nc:operation="replace" in every replacement descendant node?


Andy



      

      
Well if the default-operation is unchanged, then

<container operation="replace">
 <leaf/>
</container>

works perfectly fine if the operation for <leaf> is assumed to be a
"merge". First, the server removes the existing <container>, replaces it
with empty one and then merges the <leaf> in.

>From this point of view, "merge" on child is compatible with "create" or
"replace" on parent.

I don't see any sentence in the RFC which says that the operation is
inherited.


    

    

    
RFC6243 
With-defaults Capability for NETCONF may help clarify wh "effective operation" means in an "edit-config":


    

    

    
4.5.2.  <edit-config> Operation
...


    
If the 'default' attribute is present, then the effective operation
   for the target data node MUST be 'create', 'merge', or 'replace'.  If
   not, then the server MUST return an <rpc-error> response with an
   'invalid-value' error-tag.  For example, if 'create' is the effective
   operation, then the create request must be valid on its own (e.g.,
   current data node MUST NOT exist).  The procedure for determining the
   effective operation is defined in [RFC6241].  It is derived from the
   'default-operation' parameter and/or any operation attributes that
   are present in the data node or any of its ancestor nodes, within the
   <edit-config> request.

In other words the "operation" attribute has a "scope", that is, it applies
to the nested nodes, until is is redefined. This is logical too.

--Xiang Li



    

    

      

      

        







        

          
Inherited in a sense that an XML element actually contains/includes all
sub-elements under it. So creating/deleting/merging the element means
creating/deleting/merging all its contents as well. So unless you later
override this with more specific instructions for one of the contained
elements it should be valid for the complete element with all its content.

If operation is not inheritable we have some interesting cases:
- your examples
- default operation=none and I want to create a sizeable subtree. I have
to place the merge/create operation on every node. Don't like it, makes
none-unusable except for delete/remove.
Lets say we have the following data model:

routing
  +--static-routing
  |   +--route [routeId]
  |        +--routeId 			ipprefix
  |        +--path-to-destination 	[nexthop]
  |            +--nextHop 		ipAddress
  |            +--outgoingInterface   	string
               +--bfdActive		boolean

I want to create a static route with all its sub-elements but only if the
static-routing presence container exists (static routing is
allowed/enabled).
<default-operation>none</default-operation>
<config>
   <static-routing>  --- this will check that static routing exists.
      <route operation="create">  --this will create the interface
         <routeid>1.1.1.1/24</routeid>   -- I don't want to put
operation=create on all further nodes 5 times or more depending on the
number of paths
         <path-to-destination>
            <nextHop>1.1.1.5</nextHop>
            <outgoingInterface>eth0</outgoingInterface>
            <bfdActive>true</bfdActive>
         </path-to-destination>
      </route>
   </static-routing>
</config>

 This was very nice and logical. I hope it still works.
regards Balazs

On 2014-07-29 14:17, Andy Bierman wrote:




On Tue, Jul 29, 2014 at 12:44 AM, Klement Sekera -X (ksekera - Pantheon
Technologies SRO at Cisco) <ksekera@cisco.com> wrote:



          

            
On Mon, 2014-07-28 at 08:43 -0700, Andy Bierman wrote:


            

              
On Mon, Jul 28, 2014 at 8:31 AM, Klement Sekera -X (ksekera - Pantheon
Technologies SRO at Cisco) <ksekera@cisco.com> wrote:



              

                
On Mon, 2014-07-28 at 08:22 -0700, Andy Bierman wrote:


                

                  
On Mon, Jul 28, 2014 at 8:11 AM, Klement Sekera -X (ksekera -


                

              

            

            
Pantheon


            

              

                

                  
Technologies SRO at Cisco) <ksekera@cisco.com> wrote:



                  

                    
Hi all,

we are currently debating an issue we found and would like to


                  

                

              

            

            
have some


            

              

                

                  

                    
clarification. Netconf RFC says that the edit-config operation


                  

                

              

            

            
which


            

              

                

                  

                    
contains multiple sub-operations on the same data is undefined.

so when considering this request:

<edit-config>
<target><candidate/></target>
<config>
 <container operation="delete">
  <leaf operation="create"/>
 </container>
</config>
</edit-config>

the outcome is undefined, since the client wants do delete


                  

                

              

            

            
container


            

              

                

                  

                    
<container>, while simultaneously creating <leaf> which is part of
<container>.




                  

                  
It is defined.
Does the node /container exist in the target datastore?
If yes, then the create operation on /container/leaf MUST fail.
If no, then the delete operation on /container MUST fail.


                

                
what if /container exists but /container/leaf does not? this way both
sub-operations could be performed



              

              

not really. If implemented correctly then if the delete on /container
succeeds,
then all its descendants are also deleted.  The result in the target
datastore cannot
possibly complete both a delete on an ancestor and create of a


            

            
descendant


            

              
in the same edit. Our server returns an error because it cannot honor
both requests.



            

            
I believe that this is the part where

      If the <edit-config> operation contains multiple sub-operations
      that apply to the same conceptual node in the underlying data
      model, then the result of the operation is undefined (i.e.,
      outside the scope of the NETCONF protocol).

comes into play. Exactly as you say, target datastore cannot complete
both the deletion and creation, since both operate on the same data but
rule each other out.



            

              




              

                

                

                  




                  

                    
Now, when considering a simple list deletion:

<edit-config>
<target><candidate/></target>
<config>
 <list operation="delete">
  <key-node>key-value</key-node>
 </list>
</config>
</edit-config>

and rigorously reading the RFC regarding operation and
default-operation, the operation attribute for <key-node> is


                  

                

              

            

            
"merge",


            

              

                

                  

                    
thus, technically, this edit-config operation operates on the


                  

                

                
<key-node>


                

                  

                    
twice:



                  

                  
The operation is inherited from its parent if no "nc:operation"
attribute is specified. The keys need to be present to specify the


                

              

            

            
list


            

              

                

                  
node to be deleted.


                

                
can you point to the paragraph in netconf RFC which says that the
operation is inherited?




              

              
the delete operation on the /container node is for the container and


            

            
all its


            

              
descendants.  That is how it is inherited. I should have said


            

            
"effective"


            

              
operation
instead of "inherited".


            

            
      operation:  Elements in the <config> subtree MAY contain an
         "operation" attribute, which belongs to the NETCONF namespace
         defined in Section 3.1.  The attribute identifies the point in
         the configuration to perform the operation and MAY appear on
         multiple elements throughout the <config> subtree.

         If the "operation" attribute is not specified, the
         configuration is merged into the configuration datastore.

in this case, the "operation" attribute for <key-node> is not specified.
So the provided example request is equivalent to this request:

<list operation="delete">
 <key-node operation="merge">key-value</key-node>
</list>

so basically it's the same as above - there is a request do delete
<list> while creating and/or keeping <key-node> around - both cannot be
done. I cannot find any exception in the RFC for list/key-node combo
case.




          

          
 Perhaps 1 new sentence (After the 1 about no attribute=merge):

   If the operation attribute is not present for a key leaf node, and
  the edit operation for the parent node is "delete" or "remove",
  then the operation for the key leaf node is the same as its parent node.


 Andy





          

            

              



              

                

                

                  



                  

                    
1.) deleting the value via deletion of the list entity <list>
2.) merging in a new value via "merge" on the <key-node>


The RFC has <default-operation>none</default-operation> in all


                  

                

              

            

            
deletion


            

              

                

                  

                    
examples, which makes us believe that indeed when processing the
mentioned request, the <key-node>'s operation would be "merge"


                  

                

              

            

            
and thus


            

              

                

                  

                    
the operation undefined.

Is this how it's supposed to be or are we reading it wrong?




                  

                  
the latter




                  

                    
Thanks,
Klement
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf



                  

                

                



              

              
Andy


            

            



          

          

_______________________________________________
Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf


--
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com




        

      

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


    

    

    
-- 
--
Xiang Li, 
Seguesoft, Champaign, IL
(217) 721-5341


  


--------------040902030607050600090008--


From nobody Tue Jul 29 09:01:48 2014
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9FA1B2867 for ; Tue, 29 Jul 2014 09:01:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 DxhBj0MDzc5e for ; Tue, 29 Jul 2014 09:01:41 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F3211B2863 for ; Tue, 29 Jul 2014 09:01:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16726; q=dns/txt; s=iport; t=1406649701; x=1407859301; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=VWDNcBxEvBYvH4X79J3VXxlCP/foOo+TxSwBhqjTb3w=; b=UjmPsM+g7sKk7v/LkmsGQSM0sBkRvACjAPMuGnTyQ/VdvlTj0XUGqSxZ hMrD43OK/gchEykMxyQDqFxAmzivGkeme4xYaptKW3CUFYw+ScEejAFo4 WQjvHcTNfOHoX94UQEQdzcqKTZ7L17dDapLOr2ilAoXyDAGhYaAPO0BoL U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkMFAA/F11OtJV2U/2dsb2JhbABZgw5SVwSCdMhuCoZ4UwEZdRZ3hAQBAQQBAQEgEToLEAIBCBgCAiYCAgIlCxUQAgQOBQmIOQ2nWpcrF4Esi2OBWQIRATUbB4J5gVEFlXaHKJJ8g0lsAQGBAQkXIg
X-IronPort-AV: E=Sophos;i="5.01,757,1400025600"; d="scan'208";a="64896540"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-7.cisco.com with ESMTP; 29 Jul 2014 16:01:40 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6TG1e3A002391 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jul 2014 16:01:40 GMT
Received: from xmb-rcd-x13.cisco.com ([169.254.3.17]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Tue, 29 Jul 2014 11:01:40 -0500
From: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" 
To: "xiangli@seguesoft.com" 
Thread-Topic: [Netconf] edit-config operation inconsistency
Thread-Index: AQHPqnZB7zgA6VWc9UyRPcHJnzYLfZu17mwAgAACj4CAAAMtgIABDIyAgABMcgCAACixAIAAAzCAgAACOwCAAAnWAIAABo2A
Date: Tue, 29 Jul 2014 16:01:38 +0000
Message-ID: <1406649697.21825.11.camel@ksekera-fedora>
References: <1406560309.12287.21.camel@ksekera-fedora>  <1406561507.12287.24.camel@ksekera-fedora>  <1406619859.12287.31.camel@ksekera-fedora>  <53D7B316.8020903@ericsson.com>  <1406646178.21825.6.camel@ksekera-fedora> <53D7BFE2.9080003@seguesoft.com>
In-Reply-To: <53D7BFE2.9080003@seguesoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.221.176]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/r-CoaVKenF7ISMNar_RJ70SPYLs
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] edit-config operation inconsistency
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Jul 2014 16:01:47 -0000

T24gVHVlLCAyMDE0LTA3LTI5IGF0IDEwOjM4IC0wNTAwLCBYaWFuZyBMaSB3cm90ZToNCj4gT24g
Ny8yOS8yMDE0IDEwOjAzIEFNLCBLbGVtZW50IFNla2VyYSAtWCAoa3Nla2VyYSAtIFBhbnRoZW9u
IA0KPiBUZWNobm9sb2dpZXMgU1JPIGF0IENpc2NvKSB3cm90ZToNCj4gPiBPbiBUdWUsIDIwMTQt
MDctMjkgYXQgMDc6NTQgLTA3MDAsIEFuZHkgQmllcm1hbiB3cm90ZToNCj4gPj4gT24gVHVlLCBK
dWwgMjksIDIwMTQgYXQgNzo0MyBBTSwgQmFsYXpzIExlbmd5ZWwgPGJhbGF6cy5sZW5neWVsQGVy
aWNzc29uLmNvbQ0KPiA+Pj4gd3JvdGU6DQo+ID4+PiAgIEhlbGxvLA0KPiA+Pj4gSSBhbHdheXMg
dG91Z2h0IHRoZSBvcGVyYXRpb24gYXR0cmlidXRlIGlzIGluaGVyaXRlZC4NCj4gPj4+DQo+ID4+
IFRoaXMgaXMgaG93IGV2ZXJ5Ym9keSBpbXBsZW1lbnRzIGl0LCBhbmQgd2hhdCB3ZSBpbnRlbmRl
ZCAocHJlLTQ3NDEpLg0KPiA+PiBPdGhlcndpc2UsIHdvdWxkIGEgInJlcGxhY2UiIG9wZXJhdGlv
biBmb3Igc29tZSBhcmJpdHJhcnkgc3VidHJlZQ0KPiA+PiByZXF1aXJlIG5jOm9wZXJhdGlvbj0i
cmVwbGFjZSIgaW4gZXZlcnkgcmVwbGFjZW1lbnQgZGVzY2VuZGFudCBub2RlPw0KPiA+Pg0KPiA+
Pg0KPiA+PiBBbmR5DQo+ID4+DQo+ID4gV2VsbCBpZiB0aGUgZGVmYXVsdC1vcGVyYXRpb24gaXMg
dW5jaGFuZ2VkLCB0aGVuDQo+ID4NCj4gPiA8Y29udGFpbmVyIG9wZXJhdGlvbj0icmVwbGFjZSI+
DQo+ID4gICA8bGVhZi8+DQo+ID4gPC9jb250YWluZXI+DQo+ID4NCj4gPiB3b3JrcyBwZXJmZWN0
bHkgZmluZSBpZiB0aGUgb3BlcmF0aW9uIGZvciA8bGVhZj4gaXMgYXNzdW1lZCB0byBiZSBhDQo+
ID4gIm1lcmdlIi4gRmlyc3QsIHRoZSBzZXJ2ZXIgcmVtb3ZlcyB0aGUgZXhpc3RpbmcgPGNvbnRh
aW5lcj4sIHJlcGxhY2VzIGl0DQo+ID4gd2l0aCBlbXB0eSBvbmUgYW5kIHRoZW4gbWVyZ2VzIHRo
ZSA8bGVhZj4gaW4uDQo+ID4NCj4gPiAgRnJvbSB0aGlzIHBvaW50IG9mIHZpZXcsICJtZXJnZSIg
b24gY2hpbGQgaXMgY29tcGF0aWJsZSB3aXRoICJjcmVhdGUiIG9yDQo+ID4gInJlcGxhY2UiIG9u
IHBhcmVudC4NCj4gPg0KPiA+IEkgZG9uJ3Qgc2VlIGFueSBzZW50ZW5jZSBpbiB0aGUgUkZDIHdo
aWNoIHNheXMgdGhhdCB0aGUgb3BlcmF0aW9uIGlzDQo+ID4gaW5oZXJpdGVkLg0KPiANCj4gUkZD
NjI0Mw0KPiANCj4gDQo+ICAgV2l0aC1kZWZhdWx0cyBDYXBhYmlsaXR5IGZvciBORVRDT05GIG1h
eSBoZWxwIGNsYXJpZnkgd2ggImVmZmVjdGl2ZQ0KPiAgIG9wZXJhdGlvbiIgbWVhbnMgaW4gYW4g
ImVkaXQtY29uZmlnIjoNCj4gDQo+IA0KPiANCj4gICAgICAgICA0LjUuMiA8aHR0cDovL3Rvb2xz
LmlldGYub3JnL2h0bWwvcmZjNjI0MyNzZWN0aW9uLTQuNS4yPi4NCj4gICAgICAgICA8ZWRpdC1j
b25maWc+IE9wZXJhdGlvbg0KPiANCj4gLi4uDQo+IA0KPiBJZiB0aGUgJ2RlZmF1bHQnIGF0dHJp
YnV0ZSBpcyBwcmVzZW50LCB0aGVuIHRoZSBlZmZlY3RpdmUgb3BlcmF0aW9uDQo+ICAgICBmb3Ig
dGhlIHRhcmdldCBkYXRhIG5vZGUgTVVTVCBiZSAnY3JlYXRlJywgJ21lcmdlJywgb3IgJ3JlcGxh
Y2UnLiAgSWYNCj4gICAgIG5vdCwgdGhlbiB0aGUgc2VydmVyIE1VU1QgcmV0dXJuIGFuIDxycGMt
ZXJyb3I+IHJlc3BvbnNlIHdpdGggYW4NCj4gICAgICdpbnZhbGlkLXZhbHVlJyBlcnJvci10YWcu
ICBGb3IgZXhhbXBsZSwgaWYgJ2NyZWF0ZScgaXMgdGhlIGVmZmVjdGl2ZQ0KPiAgICAgb3BlcmF0
aW9uLCB0aGVuIHRoZSBjcmVhdGUgcmVxdWVzdCBtdXN0IGJlIHZhbGlkIG9uIGl0cyBvd24gKGUu
Zy4sDQo+ICAgICBjdXJyZW50IGRhdGEgbm9kZSBNVVNUIE5PVCBleGlzdCkuICBUaGUgcHJvY2Vk
dXJlIGZvciBkZXRlcm1pbmluZyB0aGUNCj4gICAgIGVmZmVjdGl2ZSBvcGVyYXRpb24gaXMgZGVm
aW5lZCBpbiBbUkZDNjI0MSAgPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYyNDE+XS4g
IEkqdCBpcyBkZXJpdmVkIGZyb20gdGhlDQo+ICAgICAnZGVmYXVsdC1vcGVyYXRpb24nIHBhcmFt
ZXRlciBhbmQvb3IgYW55IG9wZXJhdGlvbiBhdHRyaWJ1dGVzIHRoYXQNCj4gICAgIGFyZSBwcmVz
ZW50IGluIHRoZSBkYXRhIG5vZGUgb3IgYW55IG9mIGl0cyBhbmNlc3RvciBub2Rlcywgd2l0aGlu
IHRoZQ0KPiAgICAgPGVkaXQtY29uZmlnPiByZXF1ZXN0LioNCj4gDQo+IEluIG90aGVyIHdvcmRz
IHRoZSAib3BlcmF0aW9uIiBhdHRyaWJ1dGUgaGFzIGEgInNjb3BlIiwgdGhhdCBpcywgaXQgYXBw
bGllcw0KPiB0byB0aGUgbmVzdGVkIG5vZGVzLCB1bnRpbCBpcyBpcyByZWRlZmluZWQuIFRoaXMg
aXMgbG9naWNhbCB0b28uDQoNCnNpZGUtbm90ZTogbm90IGV2ZXJ5IG5ldGNvbmYgc2VydmVyIG11
c3Qgc3VwcG9ydCB3aXRoLWRlZmF1bHRzDQpjYXBhYmlsaXR5DQoNCkl0IHNheXMgdGhhdCB0aGUg
b3BlcmF0aW9uIGlzIGRlcml2ZWQgZnJvbSBkZWZhdWx0LW9wZXJhdGlvbiBhbmQvb3IgYW55DQpv
cGVyYXRpb24gYXR0cmlidXRlcyBwcmVzZW50LiBOb3cgUkZDIDYyNDEgc2F5czoNCg0KICAgICAg
ZGVmYXVsdC1vcGVyYXRpb246ICBTZWxlY3RzIHRoZSBkZWZhdWx0IG9wZXJhdGlvbiAoYXMgZGVz
Y3JpYmVkIGluDQogICAgICAgICB0aGUgIm9wZXJhdGlvbiIgYXR0cmlidXRlKSBmb3IgdGhpcyA8
ZWRpdC1jb25maWc+IHJlcXVlc3QuICBUaGUNCiAgICAgICAgIGRlZmF1bHQgdmFsdWUgZm9yIHRo
ZSA8ZGVmYXVsdC1vcGVyYXRpb24+IHBhcmFtZXRlciBpcyAibWVyZ2UiLg0KDQpzbyB3aGVuZXZl
ciBhIG5vZGUgZG9lcyBub3QgaGF2ZSBhbiBvcGVyYXRpb24gYXR0cmlidXRlLCB0aGlzIGNsYXVz
ZQ0KZm9yY2VzIHRoZSBzZXJ2ZXIgdG8gb3BlcmF0ZSBhcyBpZiBpdCB3YXMgIm1lcmdlIiwgaWYg
bm90IHNldCB0byBvdGhlcg0KdmFsdWUuIEkgdGhpbmsgdGhpcyBpcyBwcmV2ZW50cyBhbnkgaW5o
ZXJpdGFuY2UgbG9naWMuDQoNCj4gDQo+IC0tWGlhbmcgTGkNCj4gDQo+IA0KPiA+Pg0KPiA+Pg0K
PiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pj4gSW5oZXJpdGVkIGluIGEgc2Vuc2UgdGhhdCBhbiBYTUwg
ZWxlbWVudCBhY3R1YWxseSBjb250YWlucy9pbmNsdWRlcyBhbGwNCj4gPj4+IHN1Yi1lbGVtZW50
cyB1bmRlciBpdC4gU28gY3JlYXRpbmcvZGVsZXRpbmcvbWVyZ2luZyB0aGUgZWxlbWVudCBtZWFu
cw0KPiA+Pj4gY3JlYXRpbmcvZGVsZXRpbmcvbWVyZ2luZyBhbGwgaXRzIGNvbnRlbnRzIGFzIHdl
bGwuIFNvIHVubGVzcyB5b3UgbGF0ZXINCj4gPj4+IG92ZXJyaWRlIHRoaXMgd2l0aCBtb3JlIHNw
ZWNpZmljIGluc3RydWN0aW9ucyBmb3Igb25lIG9mIHRoZSBjb250YWluZWQNCj4gPj4+IGVsZW1l
bnRzIGl0IHNob3VsZCBiZSB2YWxpZCBmb3IgdGhlIGNvbXBsZXRlIGVsZW1lbnQgd2l0aCBhbGwg
aXRzIGNvbnRlbnQuDQo+ID4+Pg0KPiA+Pj4gSWYgb3BlcmF0aW9uIGlzIG5vdCBpbmhlcml0YWJs
ZSB3ZSBoYXZlIHNvbWUgaW50ZXJlc3RpbmcgY2FzZXM6DQo+ID4+PiAtIHlvdXIgZXhhbXBsZXMN
Cj4gPj4+IC0gZGVmYXVsdCBvcGVyYXRpb249bm9uZSBhbmQgSSB3YW50IHRvIGNyZWF0ZSBhIHNp
emVhYmxlIHN1YnRyZWUuIEkgaGF2ZQ0KPiA+Pj4gdG8gcGxhY2UgdGhlIG1lcmdlL2NyZWF0ZSBv
cGVyYXRpb24gb24gZXZlcnkgbm9kZS4gRG9uJ3QgbGlrZSBpdCwgbWFrZXMNCj4gPj4+IG5vbmUt
dW51c2FibGUgZXhjZXB0IGZvciBkZWxldGUvcmVtb3ZlLg0KPiA+Pj4gTGV0cyBzYXkgd2UgaGF2
ZSB0aGUgZm9sbG93aW5nIGRhdGEgbW9kZWw6DQo+ID4+Pg0KPiA+Pj4gcm91dGluZw0KPiA+Pj4g
ICAgKy0tc3RhdGljLXJvdXRpbmcNCj4gPj4+ICAgIHwgICArLS1yb3V0ZSBbcm91dGVJZF0NCj4g
Pj4+ICAgIHwgICAgICAgICstLXJvdXRlSWQgCQkJaXBwcmVmaXgNCj4gPj4+ICAgIHwgICAgICAg
ICstLXBhdGgtdG8tZGVzdGluYXRpb24gCVtuZXh0aG9wXQ0KPiA+Pj4gICAgfCAgICAgICAgICAg
ICstLW5leHRIb3AgCQlpcEFkZHJlc3MNCj4gPj4+ICAgIHwgICAgICAgICAgICArLS1vdXRnb2lu
Z0ludGVyZmFjZSAgIAlzdHJpbmcNCj4gPj4+ICAgICAgICAgICAgICAgICArLS1iZmRBY3RpdmUJ
CWJvb2xlYW4NCj4gPj4+DQo+ID4+PiBJIHdhbnQgdG8gY3JlYXRlIGEgc3RhdGljIHJvdXRlIHdp
dGggYWxsIGl0cyBzdWItZWxlbWVudHMgYnV0IG9ubHkgaWYgdGhlDQo+ID4+PiBzdGF0aWMtcm91
dGluZyBwcmVzZW5jZSBjb250YWluZXIgZXhpc3RzIChzdGF0aWMgcm91dGluZyBpcw0KPiA+Pj4g
YWxsb3dlZC9lbmFibGVkKS4NCj4gPj4+IDxkZWZhdWx0LW9wZXJhdGlvbj5ub25lPC9kZWZhdWx0
LW9wZXJhdGlvbj4NCj4gPj4+IDxjb25maWc+DQo+ID4+PiAgICAgPHN0YXRpYy1yb3V0aW5nPiAg
LS0tIHRoaXMgd2lsbCBjaGVjayB0aGF0IHN0YXRpYyByb3V0aW5nIGV4aXN0cy4NCj4gPj4+ICAg
ICAgICA8cm91dGUgb3BlcmF0aW9uPSJjcmVhdGUiPiAgLS10aGlzIHdpbGwgY3JlYXRlIHRoZSBp
bnRlcmZhY2UNCj4gPj4+ICAgICAgICAgICA8cm91dGVpZD4xLjEuMS4xLzI0PC9yb3V0ZWlkPiAg
IC0tIEkgZG9uJ3Qgd2FudCB0byBwdXQNCj4gPj4+IG9wZXJhdGlvbj1jcmVhdGUgb24gYWxsIGZ1
cnRoZXIgbm9kZXMgNSB0aW1lcyBvciBtb3JlIGRlcGVuZGluZyBvbiB0aGUNCj4gPj4+IG51bWJl
ciBvZiBwYXRocw0KPiA+Pj4gICAgICAgICAgIDxwYXRoLXRvLWRlc3RpbmF0aW9uPg0KPiA+Pj4g
ICAgICAgICAgICAgIDxuZXh0SG9wPjEuMS4xLjU8L25leHRIb3A+DQo+ID4+PiAgICAgICAgICAg
ICAgPG91dGdvaW5nSW50ZXJmYWNlPmV0aDA8L291dGdvaW5nSW50ZXJmYWNlPg0KPiA+Pj4gICAg
ICAgICAgICAgIDxiZmRBY3RpdmU+dHJ1ZTwvYmZkQWN0aXZlPg0KPiA+Pj4gICAgICAgICAgIDwv
cGF0aC10by1kZXN0aW5hdGlvbj4NCj4gPj4+ICAgICAgICA8L3JvdXRlPg0KPiA+Pj4gICAgIDwv
c3RhdGljLXJvdXRpbmc+DQo+ID4+PiA8L2NvbmZpZz4NCj4gPj4+DQo+ID4+PiAgIFRoaXMgd2Fz
IHZlcnkgbmljZSBhbmQgbG9naWNhbC4gSSBob3BlIGl0IHN0aWxsIHdvcmtzLg0KPiA+Pj4gcmVn
YXJkcyBCYWxhenMNCj4gPj4+DQo+ID4+PiBPbiAyMDE0LTA3LTI5IDE0OjE3LCBBbmR5IEJpZXJt
YW4gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gT24gVHVlLCBKdWwg
MjksIDIwMTQgYXQgMTI6NDQgQU0sIEtsZW1lbnQgU2VrZXJhIC1YIChrc2VrZXJhIC0gUGFudGhl
b24NCj4gPj4+IFRlY2hub2xvZ2llcyBTUk8gYXQgQ2lzY28pIDxrc2VrZXJhQGNpc2NvLmNvbT4g
d3JvdGU6DQo+ID4+Pg0KPiA+Pj4+IE9uIE1vbiwgMjAxNC0wNy0yOCBhdCAwODo0MyAtMDcwMCwg
QW5keSBCaWVybWFuIHdyb3RlOg0KPiA+Pj4+PiBPbiBNb24sIEp1bCAyOCwgMjAxNCBhdCA4OjMx
IEFNLCBLbGVtZW50IFNla2VyYSAtWCAoa3Nla2VyYSAtIFBhbnRoZW9uDQo+ID4+Pj4+IFRlY2hu
b2xvZ2llcyBTUk8gYXQgQ2lzY28pIDxrc2VrZXJhQGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4+Pj4+
DQo+ID4+Pj4+PiBPbiBNb24sIDIwMTQtMDctMjggYXQgMDg6MjIgLTA3MDAsIEFuZHkgQmllcm1h
biB3cm90ZToNCj4gPj4+Pj4+PiBPbiBNb24sIEp1bCAyOCwgMjAxNCBhdCA4OjExIEFNLCBLbGVt
ZW50IFNla2VyYSAtWCAoa3Nla2VyYSAtDQo+ID4+Pj4gUGFudGhlb24NCj4gPj4+Pj4+PiBUZWNo
bm9sb2dpZXMgU1JPIGF0IENpc2NvKSA8a3Nla2VyYUBjaXNjby5jb20+IHdyb3RlOg0KPiA+Pj4+
Pj4+DQo+ID4+Pj4+Pj4+IEhpIGFsbCwNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gd2UgYXJlIGN1
cnJlbnRseSBkZWJhdGluZyBhbiBpc3N1ZSB3ZSBmb3VuZCBhbmQgd291bGQgbGlrZSB0bw0KPiA+
Pj4+IGhhdmUgc29tZQ0KPiA+Pj4+Pj4+PiBjbGFyaWZpY2F0aW9uLiBOZXRjb25mIFJGQyBzYXlz
IHRoYXQgdGhlIGVkaXQtY29uZmlnIG9wZXJhdGlvbg0KPiA+Pj4+IHdoaWNoDQo+ID4+Pj4+Pj4+
IGNvbnRhaW5zIG11bHRpcGxlIHN1Yi1vcGVyYXRpb25zIG9uIHRoZSBzYW1lIGRhdGEgaXMgdW5k
ZWZpbmVkLg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBzbyB3aGVuIGNvbnNpZGVyaW5nIHRoaXMg
cmVxdWVzdDoNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gPGVkaXQtY29uZmlnPg0KPiA+Pj4+Pj4+
PiA8dGFyZ2V0PjxjYW5kaWRhdGUvPjwvdGFyZ2V0Pg0KPiA+Pj4+Pj4+PiA8Y29uZmlnPg0KPiA+
Pj4+Pj4+PiAgIDxjb250YWluZXIgb3BlcmF0aW9uPSJkZWxldGUiPg0KPiA+Pj4+Pj4+PiAgICA8
bGVhZiBvcGVyYXRpb249ImNyZWF0ZSIvPg0KPiA+Pj4+Pj4+PiAgIDwvY29udGFpbmVyPg0KPiA+
Pj4+Pj4+PiA8L2NvbmZpZz4NCj4gPj4+Pj4+Pj4gPC9lZGl0LWNvbmZpZz4NCj4gPj4+Pj4+Pj4N
Cj4gPj4+Pj4+Pj4gdGhlIG91dGNvbWUgaXMgdW5kZWZpbmVkLCBzaW5jZSB0aGUgY2xpZW50IHdh
bnRzIGRvIGRlbGV0ZQ0KPiA+Pj4+IGNvbnRhaW5lcg0KPiA+Pj4+Pj4+PiA8Y29udGFpbmVyPiwg
d2hpbGUgc2ltdWx0YW5lb3VzbHkgY3JlYXRpbmcgPGxlYWY+IHdoaWNoIGlzIHBhcnQgb2YNCj4g
Pj4+Pj4+Pj4gPGNvbnRhaW5lcj4uDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4g
SXQgaXMgZGVmaW5lZC4NCj4gPj4+Pj4+PiBEb2VzIHRoZSBub2RlIC9jb250YWluZXIgZXhpc3Qg
aW4gdGhlIHRhcmdldCBkYXRhc3RvcmU/DQo+ID4+Pj4+Pj4gSWYgeWVzLCB0aGVuIHRoZSBjcmVh
dGUgb3BlcmF0aW9uIG9uIC9jb250YWluZXIvbGVhZiBNVVNUIGZhaWwuDQo+ID4+Pj4+Pj4gSWYg
bm8sIHRoZW4gdGhlIGRlbGV0ZSBvcGVyYXRpb24gb24gL2NvbnRhaW5lciBNVVNUIGZhaWwuDQo+
ID4+Pj4+PiB3aGF0IGlmIC9jb250YWluZXIgZXhpc3RzIGJ1dCAvY29udGFpbmVyL2xlYWYgZG9l
cyBub3Q/IHRoaXMgd2F5IGJvdGgNCj4gPj4+Pj4+IHN1Yi1vcGVyYXRpb25zIGNvdWxkIGJlIHBl
cmZvcm1lZA0KPiA+Pj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gbm90IHJlYWxseS4gSWYgaW1wbGVt
ZW50ZWQgY29ycmVjdGx5IHRoZW4gaWYgdGhlIGRlbGV0ZSBvbiAvY29udGFpbmVyDQo+ID4+Pj4+
IHN1Y2NlZWRzLA0KPiA+Pj4+PiB0aGVuIGFsbCBpdHMgZGVzY2VuZGFudHMgYXJlIGFsc28gZGVs
ZXRlZC4gIFRoZSByZXN1bHQgaW4gdGhlIHRhcmdldA0KPiA+Pj4+PiBkYXRhc3RvcmUgY2Fubm90
DQo+ID4+Pj4+IHBvc3NpYmx5IGNvbXBsZXRlIGJvdGggYSBkZWxldGUgb24gYW4gYW5jZXN0b3Ig
YW5kIGNyZWF0ZSBvZiBhDQo+ID4+Pj4gZGVzY2VuZGFudA0KPiA+Pj4+PiBpbiB0aGUgc2FtZSBl
ZGl0LiBPdXIgc2VydmVyIHJldHVybnMgYW4gZXJyb3IgYmVjYXVzZSBpdCBjYW5ub3QgaG9ub3IN
Cj4gPj4+Pj4gYm90aCByZXF1ZXN0cy4NCj4gPj4+Pj4NCj4gPj4+PiBJIGJlbGlldmUgdGhhdCB0
aGlzIGlzIHRoZSBwYXJ0IHdoZXJlDQo+ID4+Pj4NCj4gPj4+PiAgICAgICAgSWYgdGhlIDxlZGl0
LWNvbmZpZz4gb3BlcmF0aW9uIGNvbnRhaW5zIG11bHRpcGxlIHN1Yi1vcGVyYXRpb25zDQo+ID4+
Pj4gICAgICAgIHRoYXQgYXBwbHkgdG8gdGhlIHNhbWUgY29uY2VwdHVhbCBub2RlIGluIHRoZSB1
bmRlcmx5aW5nIGRhdGENCj4gPj4+PiAgICAgICAgbW9kZWwsIHRoZW4gdGhlIHJlc3VsdCBvZiB0
aGUgb3BlcmF0aW9uIGlzIHVuZGVmaW5lZCAoaS5lLiwNCj4gPj4+PiAgICAgICAgb3V0c2lkZSB0
aGUgc2NvcGUgb2YgdGhlIE5FVENPTkYgcHJvdG9jb2wpLg0KPiA+Pj4+DQo+ID4+Pj4gY29tZXMg
aW50byBwbGF5LiBFeGFjdGx5IGFzIHlvdSBzYXksIHRhcmdldCBkYXRhc3RvcmUgY2Fubm90IGNv
bXBsZXRlDQo+ID4+Pj4gYm90aCB0aGUgZGVsZXRpb24gYW5kIGNyZWF0aW9uLCBzaW5jZSBib3Ro
IG9wZXJhdGUgb24gdGhlIHNhbWUgZGF0YSBidXQNCj4gPj4+PiBydWxlIGVhY2ggb3RoZXIgb3V0
Lg0KPiA+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+
Pj4+PiBOb3csIHdoZW4gY29uc2lkZXJpbmcgYSBzaW1wbGUgbGlzdCBkZWxldGlvbjoNCj4gPj4+
Pj4+Pj4NCj4gPj4+Pj4+Pj4gPGVkaXQtY29uZmlnPg0KPiA+Pj4+Pj4+PiA8dGFyZ2V0PjxjYW5k
aWRhdGUvPjwvdGFyZ2V0Pg0KPiA+Pj4+Pj4+PiA8Y29uZmlnPg0KPiA+Pj4+Pj4+PiAgIDxsaXN0
IG9wZXJhdGlvbj0iZGVsZXRlIj4NCj4gPj4+Pj4+Pj4gICAgPGtleS1ub2RlPmtleS12YWx1ZTwv
a2V5LW5vZGU+DQo+ID4+Pj4+Pj4+ICAgPC9saXN0Pg0KPiA+Pj4+Pj4+PiA8L2NvbmZpZz4NCj4g
Pj4+Pj4+Pj4gPC9lZGl0LWNvbmZpZz4NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gYW5kIHJpZ29y
b3VzbHkgcmVhZGluZyB0aGUgUkZDIHJlZ2FyZGluZyBvcGVyYXRpb24gYW5kDQo+ID4+Pj4+Pj4+
IGRlZmF1bHQtb3BlcmF0aW9uLCB0aGUgb3BlcmF0aW9uIGF0dHJpYnV0ZSBmb3IgPGtleS1ub2Rl
PiBpcw0KPiA+Pj4+ICJtZXJnZSIsDQo+ID4+Pj4+Pj4+IHRodXMsIHRlY2huaWNhbGx5LCB0aGlz
IGVkaXQtY29uZmlnIG9wZXJhdGlvbiBvcGVyYXRlcyBvbiB0aGUNCj4gPj4+Pj4+IDxrZXktbm9k
ZT4NCj4gPj4+Pj4+Pj4gdHdpY2U6DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4gVGhlIG9wZXJhdGlv
biBpcyBpbmhlcml0ZWQgZnJvbSBpdHMgcGFyZW50IGlmIG5vICJuYzpvcGVyYXRpb24iDQo+ID4+
Pj4+Pj4gYXR0cmlidXRlIGlzIHNwZWNpZmllZC4gVGhlIGtleXMgbmVlZCB0byBiZSBwcmVzZW50
IHRvIHNwZWNpZnkgdGhlDQo+ID4+Pj4gbGlzdA0KPiA+Pj4+Pj4+IG5vZGUgdG8gYmUgZGVsZXRl
ZC4NCj4gPj4+Pj4+IGNhbiB5b3UgcG9pbnQgdG8gdGhlIHBhcmFncmFwaCBpbiBuZXRjb25mIFJG
QyB3aGljaCBzYXlzIHRoYXQgdGhlDQo+ID4+Pj4+PiBvcGVyYXRpb24gaXMgaW5oZXJpdGVkPw0K
PiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+IHRoZSBkZWxldGUgb3BlcmF0aW9uIG9uIHRoZSAv
Y29udGFpbmVyIG5vZGUgaXMgZm9yIHRoZSBjb250YWluZXIgYW5kDQo+ID4+Pj4gYWxsIGl0cw0K
PiA+Pj4+PiBkZXNjZW5kYW50cy4gIFRoYXQgaXMgaG93IGl0IGlzIGluaGVyaXRlZC4gSSBzaG91
bGQgaGF2ZSBzYWlkDQo+ID4+Pj4gImVmZmVjdGl2ZSINCj4gPj4+Pj4gb3BlcmF0aW9uDQo+ID4+
Pj4+IGluc3RlYWQgb2YgImluaGVyaXRlZCIuDQo+ID4+Pj4gICAgICAgIG9wZXJhdGlvbjogIEVs
ZW1lbnRzIGluIHRoZSA8Y29uZmlnPiBzdWJ0cmVlIE1BWSBjb250YWluIGFuDQo+ID4+Pj4gICAg
ICAgICAgICJvcGVyYXRpb24iIGF0dHJpYnV0ZSwgd2hpY2ggYmVsb25ncyB0byB0aGUgTkVUQ09O
RiBuYW1lc3BhY2UNCj4gPj4+PiAgICAgICAgICAgZGVmaW5lZCBpbiBTZWN0aW9uIDMuMS4gIFRo
ZSBhdHRyaWJ1dGUgaWRlbnRpZmllcyB0aGUgcG9pbnQgaW4NCj4gPj4+PiAgICAgICAgICAgdGhl
IGNvbmZpZ3VyYXRpb24gdG8gcGVyZm9ybSB0aGUgb3BlcmF0aW9uIGFuZCBNQVkgYXBwZWFyIG9u
DQo+ID4+Pj4gICAgICAgICAgIG11bHRpcGxlIGVsZW1lbnRzIHRocm91Z2hvdXQgdGhlIDxjb25m
aWc+IHN1YnRyZWUuDQo+ID4+Pj4NCj4gPj4+PiAgICAgICAgICAgSWYgdGhlICJvcGVyYXRpb24i
IGF0dHJpYnV0ZSBpcyBub3Qgc3BlY2lmaWVkLCB0aGUNCj4gPj4+PiAgICAgICAgICAgY29uZmln
dXJhdGlvbiBpcyBtZXJnZWQgaW50byB0aGUgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUuDQo+ID4+
Pj4NCj4gPj4+PiBpbiB0aGlzIGNhc2UsIHRoZSAib3BlcmF0aW9uIiBhdHRyaWJ1dGUgZm9yIDxr
ZXktbm9kZT4gaXMgbm90IHNwZWNpZmllZC4NCj4gPj4+PiBTbyB0aGUgcHJvdmlkZWQgZXhhbXBs
ZSByZXF1ZXN0IGlzIGVxdWl2YWxlbnQgdG8gdGhpcyByZXF1ZXN0Og0KPiA+Pj4+DQo+ID4+Pj4g
PGxpc3Qgb3BlcmF0aW9uPSJkZWxldGUiPg0KPiA+Pj4+ICAgPGtleS1ub2RlIG9wZXJhdGlvbj0i
bWVyZ2UiPmtleS12YWx1ZTwva2V5LW5vZGU+DQo+ID4+Pj4gPC9saXN0Pg0KPiA+Pj4+DQo+ID4+
Pj4gc28gYmFzaWNhbGx5IGl0J3MgdGhlIHNhbWUgYXMgYWJvdmUgLSB0aGVyZSBpcyBhIHJlcXVl
c3QgZG8gZGVsZXRlDQo+ID4+Pj4gPGxpc3Q+IHdoaWxlIGNyZWF0aW5nIGFuZC9vciBrZWVwaW5n
IDxrZXktbm9kZT4gYXJvdW5kIC0gYm90aCBjYW5ub3QgYmUNCj4gPj4+PiBkb25lLiBJIGNhbm5v
dCBmaW5kIGFueSBleGNlcHRpb24gaW4gdGhlIFJGQyBmb3IgbGlzdC9rZXktbm9kZSBjb21ibw0K
PiA+Pj4+IGNhc2UuDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4gICBQZXJoYXBzIDEgbmV3IHNlbnRl
bmNlIChBZnRlciB0aGUgMSBhYm91dCBubyBhdHRyaWJ1dGU9bWVyZ2UpOg0KPiA+Pj4NCj4gPj4+
ICAgICBJZiB0aGUgb3BlcmF0aW9uIGF0dHJpYnV0ZSBpcyBub3QgcHJlc2VudCBmb3IgYSBrZXkg
bGVhZiBub2RlLCBhbmQNCj4gPj4+ICAgIHRoZSBlZGl0IG9wZXJhdGlvbiBmb3IgdGhlIHBhcmVu
dCBub2RlIGlzICJkZWxldGUiIG9yICJyZW1vdmUiLA0KPiA+Pj4gICAgdGhlbiB0aGUgb3BlcmF0
aW9uIGZvciB0aGUga2V5IGxlYWYgbm9kZSBpcyB0aGUgc2FtZSBhcyBpdHMgcGFyZW50IG5vZGUu
DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ICAgQW5keQ0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4+
Pg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IDEuKSBkZWxldGluZyB0aGUgdmFsdWUgdmlhIGRlbGV0
aW9uIG9mIHRoZSBsaXN0IGVudGl0eSA8bGlzdD4NCj4gPj4+Pj4+Pj4gMi4pIG1lcmdpbmcgaW4g
YSBuZXcgdmFsdWUgdmlhICJtZXJnZSIgb24gdGhlIDxrZXktbm9kZT4NCj4gPj4+Pj4+Pj4NCj4g
Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gVGhlIFJGQyBoYXMgPGRlZmF1bHQtb3BlcmF0aW9uPm5vbmU8
L2RlZmF1bHQtb3BlcmF0aW9uPiBpbiBhbGwNCj4gPj4+PiBkZWxldGlvbg0KPiA+Pj4+Pj4+PiBl
eGFtcGxlcywgd2hpY2ggbWFrZXMgdXMgYmVsaWV2ZSB0aGF0IGluZGVlZCB3aGVuIHByb2Nlc3Np
bmcgdGhlDQo+ID4+Pj4+Pj4+IG1lbnRpb25lZCByZXF1ZXN0LCB0aGUgPGtleS1ub2RlPidzIG9w
ZXJhdGlvbiB3b3VsZCBiZSAibWVyZ2UiDQo+ID4+Pj4gYW5kIHRodXMNCj4gPj4+Pj4+Pj4gdGhl
IG9wZXJhdGlvbiB1bmRlZmluZWQuDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IElzIHRoaXMgaG93
IGl0J3Mgc3VwcG9zZWQgdG8gYmUgb3IgYXJlIHdlIHJlYWRpbmcgaXQgd3Jvbmc/DQo+ID4+Pj4+
Pj4+DQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4gdGhlIGxhdHRlcg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+
Pj4NCj4gPj4+Pj4+Pj4gVGhhbmtzLA0KPiA+Pj4+Pj4+PiBLbGVtZW50DQo+ID4+Pj4+Pj4+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pj4+Pj4+
IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4+Pj4+Pj4+IE5ldGNvbmZAaWV0Zi5vcmcNCj4gPj4+
Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo+ID4+
Pj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+PiBBbmR5DQo+ID4+Pj4NCj4gPj4+DQo+ID4+PiBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gTmV0Y29u
ZiBtYWlsaW5nIGxpc3ROZXRjb25mQGlldGYub3JnaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9uZXRjb25mDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IC0tDQo+ID4+PiBCYWxhenMg
TGVuZ3llbCAgICAgICAgICAgICAgICAgICAgICAgRXJpY3Nzb24gSHVuZ2FyeSBMdGQuDQo+ID4+
PiBTZW5pb3IgU3BlY2lhbGlzdA0KPiA+Pj4gRUNOOiA4MzEgNzMyMCAgICAgICAgICAgICAgICAg
ICAgICAgIFRlbDogKzM2LTEtNDM3LTczMjANCj4gPj4+IE1vYmlsZTogKzM2LTcwLTMzMC03OTA5
ICAgICAgICAgICAgICBlbWFpbDogQmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24uY29tDQo+ID4+Pg0K
PiA+Pj4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KPiA+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4gTmV0Y29uZkBpZXRmLm9yZw0KPiA+IGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KPiANCj4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTmV0Y29uZiBtYWls
aW5nIGxpc3QNCj4gTmV0Y29uZkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL25ldGNvbmYNCg0K


From nobody Tue Jul 29 09:11:15 2014
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4C21B2899 for ; Tue, 29 Jul 2014 09:11:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 PEHAazCzEIFp for ; Tue, 29 Jul 2014 09:11:07 -0700 (PDT)
Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1B2B1B2854 for ; Tue, 29 Jul 2014 09:11:07 -0700 (PDT)
Received: by mail-qg0-f46.google.com with SMTP id z60so10781182qgd.19 for ; Tue, 29 Jul 2014 09:11:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7cNZ1rT7j3m4zKXQ9G85WMx8L41MrLqJXjdlDLphuXk=; b=e8qf/pgOvLOq89+rXKwjt9PLcbd9XDEQ9m81h8kmDLZkPgZnAzU4qjzhY2TyncS0h5 6asrM39tbQGIK8ggdddmMmLUAT5qEeH3Q1dki6SMYH0Ykku94XEK1k1HbnKOBzyncMAf A8anKXD3+jjPckESlerI64s0484BAu/+2n7CNkRGF9s0BndybGHEtLHx8DlvNFZ5xRhE TZHXaVA9cxJrlllcRkJfTgmvGACHBNYSakCxDdduJEAOPSCyNJ9XzPkmnqzqTuZ+9/OZ QV7TNAXIyQJ6eB7gzCDOHpK4o3DqlZIllvuLTlqeeoNkbTGBcg6I2eJF2q7FULZbZX0N GZCQ==
X-Gm-Message-State: ALoCoQmYUZlals8SSFTMbQ5fiBm1FGWmublNhq7Rk458AHPcX0QASHDEPfrysLh9/YwgYkQyHtuP
MIME-Version: 1.0
X-Received: by 10.229.39.73 with SMTP id f9mr5021326qce.27.1406650265335; Tue, 29 Jul 2014 09:11:05 -0700 (PDT)
Received: by 10.140.104.48 with HTTP; Tue, 29 Jul 2014 09:11:05 -0700 (PDT)
In-Reply-To: <1406646178.21825.6.camel@ksekera-fedora>
References: <1406560309.12287.21.camel@ksekera-fedora>  <1406561507.12287.24.camel@ksekera-fedora>  <1406619859.12287.31.camel@ksekera-fedora>  <53D7B316.8020903@ericsson.com>  <1406646178.21825.6.camel@ksekera-fedora>
Date: Tue, 29 Jul 2014 09:11:05 -0700
Message-ID: 
From: Andy Bierman 
To: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" 
Content-Type: multipart/alternative; boundary=001a113309306389ee04ff574972
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/GJ2d4nuchBSGFMIwv-TkAVMTSPQ
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] edit-config operation inconsistency
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Jul 2014 16:11:12 -0000

--001a113309306389ee04ff574972
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jul 29, 2014 at 8:03 AM, Klement Sekera -X (ksekera - Pantheon
Technologies SRO at Cisco)  wrote:

> On Tue, 2014-07-29 at 07:54 -0700, Andy Bierman wrote:
> > On Tue, Jul 29, 2014 at 7:43 AM, Balazs Lengyel <
> balazs.lengyel@ericsson.com
> > > wrote:
> >
> > >  Hello,
> > > I always tought the operation attribute is inherited.
> > >
> >
> > This is how everybody implements it, and what we intended (pre-4741).
> > Otherwise, would a "replace" operation for some arbitrary subtree
> > require nc:operation="replace" in every replacement descendant node?
> >
> >
> > Andy
> >
>
> Well if the default-operation is unchanged, then
>
> 
>  
> 
>
> works perfectly fine if the operation for  is assumed to be a
> "merge". First, the server removes the existing , replaces it
> with empty one and then merges the  in.
>
> From this point of view, "merge" on child is compatible with "create" or
> "replace" on parent.
>
> I don't see any sentence in the RFC which says that the operation is
> inherited.
>
>

You don't see any text that specifies an implementation order for edits
within  or  operations.  This is intentionally
an implementation detail.


Andy

>
> >
> >
> >
> >
> >
> > > Inherited in a sense that an XML element actually contains/includes all
> > > sub-elements under it. So creating/deleting/merging the element means
> > > creating/deleting/merging all its contents as well. So unless you later
> > > override this with more specific instructions for one of the contained
> > > elements it should be valid for the complete element with all its
> content.
> > >
> > > If operation is not inheritable we have some interesting cases:
> > > - your examples
> > > - default operation=none and I want to create a sizeable subtree. I
> have
> > > to place the merge/create operation on every node. Don't like it, makes
> > > none-unusable except for delete/remove.
> > > Lets say we have the following data model:
> > >
> > > routing
> > >   +--static-routing
> > >   |   +--route [routeId]
> > >   |        +--routeId                       ipprefix
> > >   |        +--path-to-destination   [nexthop]
> > >   |            +--nextHop           ipAddress
> > >   |            +--outgoingInterface         string
> > >                +--bfdActive         boolean
> > >
> > > I want to create a static route with all its sub-elements but only if
> the
> > > static-routing presence container exists (static routing is
> > > allowed/enabled).
> > > none
> > > 
> > >      --- this will check that static routing exists.
> > >         --this will create the interface
> > >          1.1.1.1/24   -- I don't want to put
> > > operation=create on all further nodes 5 times or more depending on the
> > > number of paths
> > >          
> > >             1.1.1.5
> > >             eth0
> > >             true
> > >          
> > >       
> > >    
> > > 
> > >
> > >  This was very nice and logical. I hope it still works.
> > > regards Balazs
> > >
> > > On 2014-07-29 14:17, Andy Bierman wrote:
> > >
> > >
> > >
> > >
> > > On Tue, Jul 29, 2014 at 12:44 AM, Klement Sekera -X (ksekera - Pantheon
> > > Technologies SRO at Cisco)  wrote:
> > >
> > >> On Mon, 2014-07-28 at 08:43 -0700, Andy Bierman wrote:
> > >> > On Mon, Jul 28, 2014 at 8:31 AM, Klement Sekera -X (ksekera -
> Pantheon
> > >> > Technologies SRO at Cisco)  wrote:
> > >> >
> > >> > > On Mon, 2014-07-28 at 08:22 -0700, Andy Bierman wrote:
> > >> > > > On Mon, Jul 28, 2014 at 8:11 AM, Klement Sekera -X (ksekera -
> > >> Pantheon
> > >> > > > Technologies SRO at Cisco)  wrote:
> > >> > > >
> > >> > > > > Hi all,
> > >> > > > >
> > >> > > > > we are currently debating an issue we found and would like to
> > >> have some
> > >> > > > > clarification. Netconf RFC says that the edit-config operation
> > >> which
> > >> > > > > contains multiple sub-operations on the same data is
> undefined.
> > >> > > > >
> > >> > > > > so when considering this request:
> > >> > > > >
> > >> > > > > 
> > >> > > > > 
> > >> > > > > 
> > >> > > > >  
> > >> > > > >   
> > >> > > > >  
> > >> > > > > 
> > >> > > > > 
> > >> > > > >
> > >> > > > > the outcome is undefined, since the client wants do delete
> > >> container
> > >> > > > > , while simultaneously creating  which is
> part of
> > >> > > > > .
> > >> > > > >
> > >> > > > >
> > >> > > > It is defined.
> > >> > > > Does the node /container exist in the target datastore?
> > >> > > > If yes, then the create operation on /container/leaf MUST fail.
> > >> > > > If no, then the delete operation on /container MUST fail.
> > >> > >
> > >> > > what if /container exists but /container/leaf does not? this way
> both
> > >> > > sub-operations could be performed
> > >> > >
> > >> >
> > >> >
> > >> > not really. If implemented correctly then if the delete on
> /container
> > >> > succeeds,
> > >> > then all its descendants are also deleted.  The result in the target
> > >> > datastore cannot
> > >> > possibly complete both a delete on an ancestor and create of a
> > >> descendant
> > >> > in the same edit. Our server returns an error because it cannot
> honor
> > >> > both requests.
> > >> >
> > >>
> > >> I believe that this is the part where
> > >>
> > >>       If the  operation contains multiple sub-operations
> > >>       that apply to the same conceptual node in the underlying data
> > >>       model, then the result of the operation is undefined (i.e.,
> > >>       outside the scope of the NETCONF protocol).
> > >>
> > >> comes into play. Exactly as you say, target datastore cannot complete
> > >> both the deletion and creation, since both operate on the same data
> but
> > >> rule each other out.
> > >>
> > >> >
> > >> >
> > >> >
> > >> > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > > Now, when considering a simple list deletion:
> > >> > > > >
> > >> > > > > 
> > >> > > > > 
> > >> > > > > 
> > >> > > > >  
> > >> > > > >   key-value
> > >> > > > >  
> > >> > > > > 
> > >> > > > > 
> > >> > > > >
> > >> > > > > and rigorously reading the RFC regarding operation and
> > >> > > > > default-operation, the operation attribute for  is
> > >> "merge",
> > >> > > > > thus, technically, this edit-config operation operates on the
> > >> > > 
> > >> > > > > twice:
> > >> > > > >
> > >> > > >
> > >> > > > The operation is inherited from its parent if no "nc:operation"
> > >> > > > attribute is specified. The keys need to be present to specify
> the
> > >> list
> > >> > > > node to be deleted.
> > >> > >
> > >> > > can you point to the paragraph in netconf RFC which says that the
> > >> > > operation is inherited?
> > >> > >
> > >> > >
> > >> > the delete operation on the /container node is for the container and
> > >> all its
> > >> > descendants.  That is how it is inherited. I should have said
> > >> "effective"
> > >> > operation
> > >> > instead of "inherited".
> > >>
> > >>       operation:  Elements in the  subtree MAY contain an
> > >>          "operation" attribute, which belongs to the NETCONF namespace
> > >>          defined in Section 3.1.  The attribute identifies the point
> in
> > >>          the configuration to perform the operation and MAY appear on
> > >>          multiple elements throughout the  subtree.
> > >>
> > >>          If the "operation" attribute is not specified, the
> > >>          configuration is merged into the configuration datastore.
> > >>
> > >> in this case, the "operation" attribute for  is not
> specified.
> > >> So the provided example request is equivalent to this request:
> > >>
> > >> 
> > >>  key-value
> > >> 
> > >>
> > >> so basically it's the same as above - there is a request do delete
> > >>  while creating and/or keeping  around - both cannot
> be
> > >> done. I cannot find any exception in the RFC for list/key-node combo
> > >> case.
> > >>
> > >>
> > >  Perhaps 1 new sentence (After the 1 about no attribute=merge):
> > >
> > >    If the operation attribute is not present for a key leaf node, and
> > >   the edit operation for the parent node is "delete" or "remove",
> > >   then the operation for the key leaf node is the same as its parent
> node.
> > >
> > >
> > >  Andy
> > >
> > >
> > >
> > >> >
> > >> >
> > >> > >
> > >> > > >
> > >> > > >
> > >> > > > > 1.) deleting the value via deletion of the list entity 
> > >> > > > > 2.) merging in a new value via "merge" on the 
> > >> > > > >
> > >> > > > >
> > >> > > > > The RFC has none in all
> > >> deletion
> > >> > > > > examples, which makes us believe that indeed when processing
> the
> > >> > > > > mentioned request, the 's operation would be "merge"
> > >> and thus
> > >> > > > > the operation undefined.
> > >> > > > >
> > >> > > > > Is this how it's supposed to be or are we reading it wrong?
> > >> > > > >
> > >> > > > >
> > >> > > > the latter
> > >> > > >
> > >> > > >
> > >> > > > > Thanks,
> > >> > > > > Klement
> > >> > > > > _______________________________________________
> > >> > > > > Netconf mailing list
> > >> > > > > Netconf@ietf.org
> > >> > > > > https://www.ietf.org/mailman/listinfo/netconf
> > >> > > > >
> > >> > >
> > >> > >
> > >> > Andy
> > >>
> > >>
> > >
> > >
> > > _______________________________________________
> > > Netconf mailing listNetconf@ietf.orghttps://
> www.ietf.org/mailman/listinfo/netconf
> > >
> > >
> > > --
> > > Balazs Lengyel                       Ericsson Hungary Ltd.
> > > Senior Specialist
> > > ECN: 831 7320                        Tel: +36-1-437-7320
> > > Mobile: +36-70-330-7909              email:
> Balazs.Lengyel@ericsson.com
> > >
> > >
>
>

--001a113309306389ee04ff574972
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Tue, Jul 29, 2014 at 8:03 AM, Klement Sekera -X (ksekera - Panth=
eon Technologies SRO at Cisco) <ksekera@cisco.com> wrote:

On Tue, 2014-07-29 at 07:54 -0700, Andy Bier=
man wrote:

> On Tue, Jul 29, 2014 at 7:43 AM, Balazs Lengyel <balazs.lengyel@ericsson.com

> > wrote:

>

> > =A0Hello,

> > I always tought the operation attribute is inherited.

> >

>

> This is how everybody implements it, and what we intended (pre-4741).<=
br>
> Otherwise, would a "replace" operation for some arbitrary su=
btree

> require nc:operation=3D"replace" in every replacement descen=
dant node?

>

>

> Andy

>



Well if the default-operation is unchanged, then



<container operation=3D"replace">

=A0<leaf/>

</container>



works perfectly fine if the operation for <leaf> is assumed to be a
"merge". First, the server removes the existing <container>=
, replaces it

with empty one and then merges the <leaf> in.



>From this point of view, "merge" on child is compatible with &quo=
t;create" or

"replace" on parent.



I don't see any sentence in the RFC which says that the operation is
inherited.




You don't see any t=
ext that specifies an implementation order for edits
within <e=
dit-config> or <copy-config> operations. =A0This is intentionally<=
/div>

an implementation detail.


Andy=



>

>

>

>

>

>

> > Inherited in a sense that an XML element actually contains/includ=
es all

> > sub-elements under it. So creating/deleting/merging the element m=
eans

> > creating/deleting/merging all its contents as well. So unless you=
 later

> > override this with more specific instructions for one of the cont=
ained

> > elements it should be valid for the complete element with all its=
 content.

> >

> > If operation is not inheritable we have some interesting cases:
> > - your examples

> > - default operation=3Dnone and I want to create a sizeable subtre=
e. I have

> > to place the merge/create operation on every node. Don't like=
 it, makes

> > none-unusable except for delete/remove.

> > Lets say we have the following data model:

> >

> > routing

> > =A0 +--static-routing

> > =A0 | =A0 +--route [routeId]

> > =A0 | =A0 =A0 =A0 =A0+--routeId =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 ipprefix

> > =A0 | =A0 =A0 =A0 =A0+--path-to-destination =A0 [nexthop]

> > =A0 | =A0 =A0 =A0 =A0 =A0 =A0+--nextHop =A0 =A0 =A0 =A0 =A0 ipAdd=
ress

> > =A0 | =A0 =A0 =A0 =A0 =A0 =A0+--outgoingInterface =A0 =A0 =A0 =A0=
 string

> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0+--bfdActive =A0 =A0 =A0 =A0 boole=
an

> >

> > I want to create a static route with all its sub-elements but onl=
y if the

> > static-routing presence container exists (static routing is

> > allowed/enabled).

> > <default-operation>none</default-operation>

> > <config>

> > =A0 =A0<static-routing> =A0--- this will check that static =
routing exists.

> > =A0 =A0 =A0 <route operation=3D"create"> =A0--thi=
s will create the interface

> > =A0 =A0 =A0 =A0 =A0<routeid>1.1.1.1/24</routeid> =A0 -- I don't want to =
put

> > operation=3Dcreate on all further nodes 5 times or more depending=
 on the

> > number of paths

> > =A0 =A0 =A0 =A0 =A0<path-to-destination>

> > =A0 =A0 =A0 =A0 =A0 =A0 <nextHop>1.1.1.5</nextHop>
> > =A0 =A0 =A0 =A0 =A0 =A0 <outgoingInterface>eth0</outgoin=
gInterface>

> > =A0 =A0 =A0 =A0 =A0 =A0 <bfdActive>true</bfdActive>
> > =A0 =A0 =A0 =A0 =A0</path-to-destination>

> > =A0 =A0 =A0 </route>

> > =A0 =A0</static-routing>

> > </config>

> >

> > =A0This was very nice and logical. I hope it still works.

> > regards Balazs

> >

> > On 2014-07-29 14:17, Andy Bierman wrote:

> >

> >

> >

> >

> > On Tue, Jul 29, 2014 at 12:44 AM, Klement Sekera -X (ksekera - Pa=
ntheon

> > Technologies SRO at Cisco) <ksekera@cisco.com> wrote:

> >

> >> On Mon, 2014-07-28 at 08:43 -0700, Andy Bierman wrote:

> >> > On Mon, Jul 28, 2014 at 8:31 AM, Klement Sekera -X (ksek=
era - Pantheon

> >> > Technologies SRO at Cisco) <ksekera@cisco.com> wrote:

> >> >

> >> > > On Mon, 2014-07-28 at 08:22 -0700, Andy Bierman wro=
te:

> >> > > > On Mon, Jul 28, 2014 at 8:11 AM, Klement Seker=
a -X (ksekera -

> >> Pantheon

> >> > > > Technologies SRO at Cisco) <ksekera@cisco.com> wrote:

> >> > > >

> >> > > > > Hi all,

> >> > > > >

> >> > > > > we are currently debating an issue we fou=
nd and would like to

> >> have some

> >> > > > > clarification. Netconf RFC says that the =
edit-config operation

> >> which

> >> > > > > contains multiple sub-operations on the s=
ame data is undefined.

> >> > > > >

> >> > > > > so when considering this request:

> >> > > > >

> >> > > > > <edit-config>

> >> > > > > <target><candidate/></targ=
et>

> >> > > > > <config>

> >> > > > > =A0<container operation=3D"delete=
">

> >> > > > > =A0 <leaf operation=3D"create&quo=
t;/>

> >> > > > > =A0</container>

> >> > > > > </config>

> >> > > > > </edit-config>

> >> > > > >

> >> > > > > the outcome is undefined, since the clien=
t wants do delete

> >> container

> >> > > > > <container>, while simultaneously c=
reating <leaf> which is part of

> >> > > > > <container>.

> >> > > > >

> >> > > > >

> >> > > > It is defined.

> >> > > > Does the node /container exist in the target d=
atastore?

> >> > > > If yes, then the create operation on /containe=
r/leaf MUST fail.

> >> > > > If no, then the delete operation on /container=
 MUST fail.

> >> > >

> >> > > what if /container exists but /container/leaf does =
not? this way both

> >> > > sub-operations could be performed

> >> > >

> >> >

> >> >

> >> > not really. If implemented correctly then if the delete =
on /container

> >> > succeeds,

> >> > then all its descendants are also deleted. =A0The result=
 in the target

> >> > datastore cannot

> >> > possibly complete both a delete on an ancestor and creat=
e of a

> >> descendant

> >> > in the same edit. Our server returns an error because it=
 cannot honor

> >> > both requests.

> >> >

> >>

> >> I believe that this is the part where

> >>

> >> =A0 =A0 =A0 If the <edit-config> operation contains mul=
tiple sub-operations

> >> =A0 =A0 =A0 that apply to the same conceptual node in the und=
erlying data

> >> =A0 =A0 =A0 model, then the result of the operation is undefi=
ned (i.e.,

> >> =A0 =A0 =A0 outside the scope of the NETCONF protocol).

> >>

> >> comes into play. Exactly as you say, target datastore cannot =
complete

> >> both the deletion and creation, since both operate on the sam=
e data but

> >> rule each other out.

> >>

> >> >

> >> >

> >> >

> >> > >

> >> > > >

> >> > > >

> >> > > >

> >> > > > > Now, when considering a simple list delet=
ion:

> >> > > > >

> >> > > > > <edit-config>

> >> > > > > <target><candidate/></targ=
et>

> >> > > > > <config>

> >> > > > > =A0<list operation=3D"delete"=
;>

> >> > > > > =A0 <key-node>key-value</key-nod=
e>

> >> > > > > =A0</list>

> >> > > > > </config>

> >> > > > > </edit-config>

> >> > > > >

> >> > > > > and rigorously reading the RFC regarding =
operation and

> >> > > > > default-operation, the operation attribut=
e for <key-node> is

> >> "merge",

> >> > > > > thus, technically, this edit-config opera=
tion operates on the

> >> > > <key-node>

> >> > > > > twice:

> >> > > > >

> >> > > >

> >> > > > The operation is inherited from its parent if =
no "nc:operation"

> >> > > > attribute is specified. The keys need to be pr=
esent to specify the

> >> list

> >> > > > node to be deleted.

> >> > >

> >> > > can you point to the paragraph in netconf RFC which=
 says that the

> >> > > operation is inherited?

> >> > >

> >> > >

> >> > the delete operation on the /container node is for the c=
ontainer and

> >> all its

> >> > descendants. =A0That is how it is inherited. I should ha=
ve said

> >> "effective"

> >> > operation

> >> > instead of "inherited".

> >>

> >> =A0 =A0 =A0 operation: =A0Elements in the <config> subt=
ree MAY contain an

> >> =A0 =A0 =A0 =A0 =A0"operation" attribute, which bel=
ongs to the NETCONF namespace

> >> =A0 =A0 =A0 =A0 =A0defined in Section 3.1. =A0The attribute i=
dentifies the point in

> >> =A0 =A0 =A0 =A0 =A0the configuration to perform the operation=
 and MAY appear on

> >> =A0 =A0 =A0 =A0 =A0multiple elements throughout the <confi=
g> subtree.

> >>

> >> =A0 =A0 =A0 =A0 =A0If the "operation" attribute is =
not specified, the

> >> =A0 =A0 =A0 =A0 =A0configuration is merged into the configura=
tion datastore.

> >>

> >> in this case, the "operation" attribute for <key=
-node> is not specified.

> >> So the provided example request is equivalent to this request=
:

> >>

> >> <list operation=3D"delete">

> >> =A0<key-node operation=3D"merge">key-value<=
;/key-node>

> >> </list>

> >>

> >> so basically it's the same as above - there is a request =
do delete

> >> <list> while creating and/or keeping <key-node> a=
round - both cannot be

> >> done. I cannot find any exception in the RFC for list/key-nod=
e combo

> >> case.

> >>

> >>

> > =A0Perhaps 1 new sentence (After the 1 about no attribute=3Dmerge=
):

> >

> > =A0 =A0If the operation attribute is not present for a key leaf n=
ode, and

> > =A0 the edit operation for the parent node is "delete" =
or "remove",

> > =A0 then the operation for the key leaf node is the same as its p=
arent node.

> >

> >

> > =A0Andy

> >

> >

> >

> >> >

> >> >

> >> > >

> >> > > >

> >> > > >

> >> > > > > 1.) deleting the value via deletion of th=
e list entity <list>

> >> > > > > 2.) merging in a new value via "merg=
e" on the <key-node>

> >> > > > >

> >> > > > >

> >> > > > > The RFC has <default-operation>none=
</default-operation> in all

> >> deletion

> >> > > > > examples, which makes us believe that ind=
eed when processing the

> >> > > > > mentioned request, the <key-node>&#=
39;s operation would be "merge"

> >> and thus

> >> > > > > the operation undefined.

> >> > > > >

> >> > > > > Is this how it's supposed to be or ar=
e we reading it wrong?

> >> > > > >

> >> > > > >

> >> > > > the latter

> >> > > >

> >> > > >

> >> > > > > Thanks,

> >> > > > > Klement

> >> > > > > _________________________________________=
______

> >> > > > > Netconf mailing list

> >> > > > > Netco=
nf@ietf.org

> >> > > > > https://www.ietf.org/mailman/listinfo/ne=
tconf

> >> > > > >

> >> > >

> >> > >

> >> > Andy

> >>

> >>

> >

> >

> > _______________________________________________

> > Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/=
listinfo/netconf

> >

> >

> > --

> > Balazs Lengyel =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ericss=
on Hungary Ltd.

> > Senior Specialist

> > ECN: 831 7320 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Tel:=
 +36-1-437-7320

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

> >

> >







--001a113309306389ee04ff574972--


From nobody Tue Jul 29 09:16:12 2014
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267B41B287C for ; Tue, 29 Jul 2014 09:16:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 gKuIQ0oEh2D1 for ; Tue, 29 Jul 2014 09:16:07 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 446C81B2863 for ; Tue, 29 Jul 2014 09:16:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16086; q=dns/txt; s=iport; t=1406650567; x=1407860167; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=scuGx1b+8ws6bDtdEzJ4E4xWsUZyIrt2La6cxt2jEQo=; b=eNBlDGWoiTGPYNBQ8LwzVXpU36o8tJe7aLwOR4fxFGH3vdBeF66wNzCh cmDHXsqC7+xVBL8ErfuVdFaQBHp4edfgqaNbh8zALHBXLeVWkUiDHqPxf vtlQdXM568Wh9CdK4YkS7VJarEhkgkpRpDavFTu4dX/PnbE4XcdLy4beQ Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkMFAGzH11OtJV2R/2dsb2JhbABZgw5SVwSCdMhuCoZ4UwEZdRZ3hAMBAQEDAQEBASARFSULEAIBCBgCAiYCAgIlCxUQAgQOBQmIMQgNp1OXSheBLItjgVkCEQEdGBsHgnmBUQWXKphwg0lsgQMJFyI
X-IronPort-AV: E=Sophos;i="5.01,757,1400025600"; d="scan'208";a="64900188"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-7.cisco.com with ESMTP; 29 Jul 2014 16:16:06 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6TGG6EX004023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jul 2014 16:16:06 GMT
Received: from xmb-rcd-x13.cisco.com ([169.254.3.17]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Tue, 29 Jul 2014 11:16:06 -0500
From: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" 
To: "andy@yumaworks.com" 
Thread-Topic: [Netconf] edit-config operation inconsistency
Thread-Index: AQHPqnZB7zgA6VWc9UyRPcHJnzYLfZu17mwAgAACj4CAAAMtgIABDIyAgABMcgCAACixAIAAAzCAgAACOwCAABMJgIAAAWWA
Date: Tue, 29 Jul 2014 16:16:05 +0000
Message-ID: <1406650565.21825.13.camel@ksekera-fedora>
References: <1406560309.12287.21.camel@ksekera-fedora>  <1406561507.12287.24.camel@ksekera-fedora>  <1406619859.12287.31.camel@ksekera-fedora>  <53D7B316.8020903@ericsson.com>  <1406646178.21825.6.camel@ksekera-fedora> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.221.176]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/OfMf6cpQc9msDyP1nVs1WrMgc0o
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] edit-config operation inconsistency
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Jul 2014 16:16:10 -0000

T24gVHVlLCAyMDE0LTA3LTI5IGF0IDA5OjExIC0wNzAwLCBBbmR5IEJpZXJtYW4gd3JvdGU6DQo+
IE9uIFR1ZSwgSnVsIDI5LCAyMDE0IGF0IDg6MDMgQU0sIEtsZW1lbnQgU2VrZXJhIC1YIChrc2Vr
ZXJhIC0gUGFudGhlb24NCj4gVGVjaG5vbG9naWVzIFNSTyBhdCBDaXNjbykgPGtzZWtlcmFAY2lz
Y28uY29tPiB3cm90ZToNCj4gDQo+ID4gT24gVHVlLCAyMDE0LTA3LTI5IGF0IDA3OjU0IC0wNzAw
LCBBbmR5IEJpZXJtYW4gd3JvdGU6DQo+ID4gPiBPbiBUdWUsIEp1bCAyOSwgMjAxNCBhdCA3OjQz
IEFNLCBCYWxhenMgTGVuZ3llbCA8DQo+ID4gYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tDQo+
ID4gPiA+IHdyb3RlOg0KPiA+ID4NCj4gPiA+ID4gIEhlbGxvLA0KPiA+ID4gPiBJIGFsd2F5cyB0
b3VnaHQgdGhlIG9wZXJhdGlvbiBhdHRyaWJ1dGUgaXMgaW5oZXJpdGVkLg0KPiA+ID4gPg0KPiA+
ID4NCj4gPiA+IFRoaXMgaXMgaG93IGV2ZXJ5Ym9keSBpbXBsZW1lbnRzIGl0LCBhbmQgd2hhdCB3
ZSBpbnRlbmRlZCAocHJlLTQ3NDEpLg0KPiA+ID4gT3RoZXJ3aXNlLCB3b3VsZCBhICJyZXBsYWNl
IiBvcGVyYXRpb24gZm9yIHNvbWUgYXJiaXRyYXJ5IHN1YnRyZWUNCj4gPiA+IHJlcXVpcmUgbmM6
b3BlcmF0aW9uPSJyZXBsYWNlIiBpbiBldmVyeSByZXBsYWNlbWVudCBkZXNjZW5kYW50IG5vZGU/
DQo+ID4gPg0KPiA+ID4NCj4gPiA+IEFuZHkNCj4gPiA+DQo+ID4NCj4gPiBXZWxsIGlmIHRoZSBk
ZWZhdWx0LW9wZXJhdGlvbiBpcyB1bmNoYW5nZWQsIHRoZW4NCj4gPg0KPiA+IDxjb250YWluZXIg
b3BlcmF0aW9uPSJyZXBsYWNlIj4NCj4gPiAgPGxlYWYvPg0KPiA+IDwvY29udGFpbmVyPg0KPiA+
DQo+ID4gd29ya3MgcGVyZmVjdGx5IGZpbmUgaWYgdGhlIG9wZXJhdGlvbiBmb3IgPGxlYWY+IGlz
IGFzc3VtZWQgdG8gYmUgYQ0KPiA+ICJtZXJnZSIuIEZpcnN0LCB0aGUgc2VydmVyIHJlbW92ZXMg
dGhlIGV4aXN0aW5nIDxjb250YWluZXI+LCByZXBsYWNlcyBpdA0KPiA+IHdpdGggZW1wdHkgb25l
IGFuZCB0aGVuIG1lcmdlcyB0aGUgPGxlYWY+IGluLg0KPiA+DQo+ID4gRnJvbSB0aGlzIHBvaW50
IG9mIHZpZXcsICJtZXJnZSIgb24gY2hpbGQgaXMgY29tcGF0aWJsZSB3aXRoICJjcmVhdGUiIG9y
DQo+ID4gInJlcGxhY2UiIG9uIHBhcmVudC4NCj4gPg0KPiA+IEkgZG9uJ3Qgc2VlIGFueSBzZW50
ZW5jZSBpbiB0aGUgUkZDIHdoaWNoIHNheXMgdGhhdCB0aGUgb3BlcmF0aW9uIGlzDQo+ID4gaW5o
ZXJpdGVkLg0KPiA+DQo+ID4NCj4gDQo+IFlvdSBkb24ndCBzZWUgYW55IHRleHQgdGhhdCBzcGVj
aWZpZXMgYW4gaW1wbGVtZW50YXRpb24gb3JkZXIgZm9yIGVkaXRzDQo+IHdpdGhpbiA8ZWRpdC1j
b25maWc+IG9yIDxjb3B5LWNvbmZpZz4gb3BlcmF0aW9ucy4gIFRoaXMgaXMgaW50ZW50aW9uYWxs
eQ0KPiBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwuDQo+IA0KDQpXaGF0IEkgbWVhbnQgdG8gc2F5
IGlzIHRoYXQgdGhlIGxvZ2ljIHlvdSBkZXNjcmliZWQ6DQoNCiJPdGhlcndpc2UsIHdvdWxkIGEg
InJlcGxhY2UiIG9wZXJhdGlvbiBmb3Igc29tZSBhcmJpdHJhcnkgc3VidHJlZQ0KcmVxdWlyZSBu
YzpvcGVyYXRpb249InJlcGxhY2UiIGluIGV2ZXJ5IHJlcGxhY2VtZW50IGRlc2NlbmRhbnQgbm9k
ZT8iDQoNCmlzIG5vdCB0aGUgb25seSBwb3NzaWJsZS4gSXQgY2FuIGRvIHdpdGggZGVmYXVsdCAi
bWVyZ2UiIGlmIGltcGxlbWVudGVkDQp0aGUgd2F5IEkgZGVzY3JpYmVkLg0KDQo+IA0KPiBBbmR5
DQo+IA0KPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+ID4gSW5o
ZXJpdGVkIGluIGEgc2Vuc2UgdGhhdCBhbiBYTUwgZWxlbWVudCBhY3R1YWxseSBjb250YWlucy9p
bmNsdWRlcyBhbGwNCj4gPiA+ID4gc3ViLWVsZW1lbnRzIHVuZGVyIGl0LiBTbyBjcmVhdGluZy9k
ZWxldGluZy9tZXJnaW5nIHRoZSBlbGVtZW50IG1lYW5zDQo+ID4gPiA+IGNyZWF0aW5nL2RlbGV0
aW5nL21lcmdpbmcgYWxsIGl0cyBjb250ZW50cyBhcyB3ZWxsLiBTbyB1bmxlc3MgeW91IGxhdGVy
DQo+ID4gPiA+IG92ZXJyaWRlIHRoaXMgd2l0aCBtb3JlIHNwZWNpZmljIGluc3RydWN0aW9ucyBm
b3Igb25lIG9mIHRoZSBjb250YWluZWQNCj4gPiA+ID4gZWxlbWVudHMgaXQgc2hvdWxkIGJlIHZh
bGlkIGZvciB0aGUgY29tcGxldGUgZWxlbWVudCB3aXRoIGFsbCBpdHMNCj4gPiBjb250ZW50Lg0K
PiA+ID4gPg0KPiA+ID4gPiBJZiBvcGVyYXRpb24gaXMgbm90IGluaGVyaXRhYmxlIHdlIGhhdmUg
c29tZSBpbnRlcmVzdGluZyBjYXNlczoNCj4gPiA+ID4gLSB5b3VyIGV4YW1wbGVzDQo+ID4gPiA+
IC0gZGVmYXVsdCBvcGVyYXRpb249bm9uZSBhbmQgSSB3YW50IHRvIGNyZWF0ZSBhIHNpemVhYmxl
IHN1YnRyZWUuIEkNCj4gPiBoYXZlDQo+ID4gPiA+IHRvIHBsYWNlIHRoZSBtZXJnZS9jcmVhdGUg
b3BlcmF0aW9uIG9uIGV2ZXJ5IG5vZGUuIERvbid0IGxpa2UgaXQsIG1ha2VzDQo+ID4gPiA+IG5v
bmUtdW51c2FibGUgZXhjZXB0IGZvciBkZWxldGUvcmVtb3ZlLg0KPiA+ID4gPiBMZXRzIHNheSB3
ZSBoYXZlIHRoZSBmb2xsb3dpbmcgZGF0YSBtb2RlbDoNCj4gPiA+ID4NCj4gPiA+ID4gcm91dGlu
Zw0KPiA+ID4gPiAgICstLXN0YXRpYy1yb3V0aW5nDQo+ID4gPiA+ICAgfCAgICstLXJvdXRlIFty
b3V0ZUlkXQ0KPiA+ID4gPiAgIHwgICAgICAgICstLXJvdXRlSWQgICAgICAgICAgICAgICAgICAg
ICAgIGlwcHJlZml4DQo+ID4gPiA+ICAgfCAgICAgICAgKy0tcGF0aC10by1kZXN0aW5hdGlvbiAg
IFtuZXh0aG9wXQ0KPiA+ID4gPiAgIHwgICAgICAgICAgICArLS1uZXh0SG9wICAgICAgICAgICBp
cEFkZHJlc3MNCj4gPiA+ID4gICB8ICAgICAgICAgICAgKy0tb3V0Z29pbmdJbnRlcmZhY2UgICAg
ICAgICBzdHJpbmcNCj4gPiA+ID4gICAgICAgICAgICAgICAgKy0tYmZkQWN0aXZlICAgICAgICAg
Ym9vbGVhbg0KPiA+ID4gPg0KPiA+ID4gPiBJIHdhbnQgdG8gY3JlYXRlIGEgc3RhdGljIHJvdXRl
IHdpdGggYWxsIGl0cyBzdWItZWxlbWVudHMgYnV0IG9ubHkgaWYNCj4gPiB0aGUNCj4gPiA+ID4g
c3RhdGljLXJvdXRpbmcgcHJlc2VuY2UgY29udGFpbmVyIGV4aXN0cyAoc3RhdGljIHJvdXRpbmcg
aXMNCj4gPiA+ID4gYWxsb3dlZC9lbmFibGVkKS4NCj4gPiA+ID4gPGRlZmF1bHQtb3BlcmF0aW9u
Pm5vbmU8L2RlZmF1bHQtb3BlcmF0aW9uPg0KPiA+ID4gPiA8Y29uZmlnPg0KPiA+ID4gPiAgICA8
c3RhdGljLXJvdXRpbmc+ICAtLS0gdGhpcyB3aWxsIGNoZWNrIHRoYXQgc3RhdGljIHJvdXRpbmcg
ZXhpc3RzLg0KPiA+ID4gPiAgICAgICA8cm91dGUgb3BlcmF0aW9uPSJjcmVhdGUiPiAgLS10aGlz
IHdpbGwgY3JlYXRlIHRoZSBpbnRlcmZhY2UNCj4gPiA+ID4gICAgICAgICAgPHJvdXRlaWQ+MS4x
LjEuMS8yNDwvcm91dGVpZD4gICAtLSBJIGRvbid0IHdhbnQgdG8gcHV0DQo+ID4gPiA+IG9wZXJh
dGlvbj1jcmVhdGUgb24gYWxsIGZ1cnRoZXIgbm9kZXMgNSB0aW1lcyBvciBtb3JlIGRlcGVuZGlu
ZyBvbiB0aGUNCj4gPiA+ID4gbnVtYmVyIG9mIHBhdGhzDQo+ID4gPiA+ICAgICAgICAgIDxwYXRo
LXRvLWRlc3RpbmF0aW9uPg0KPiA+ID4gPiAgICAgICAgICAgICA8bmV4dEhvcD4xLjEuMS41PC9u
ZXh0SG9wPg0KPiA+ID4gPiAgICAgICAgICAgICA8b3V0Z29pbmdJbnRlcmZhY2U+ZXRoMDwvb3V0
Z29pbmdJbnRlcmZhY2U+DQo+ID4gPiA+ICAgICAgICAgICAgIDxiZmRBY3RpdmU+dHJ1ZTwvYmZk
QWN0aXZlPg0KPiA+ID4gPiAgICAgICAgICA8L3BhdGgtdG8tZGVzdGluYXRpb24+DQo+ID4gPiA+
ICAgICAgIDwvcm91dGU+DQo+ID4gPiA+ICAgIDwvc3RhdGljLXJvdXRpbmc+DQo+ID4gPiA+IDwv
Y29uZmlnPg0KPiA+ID4gPg0KPiA+ID4gPiAgVGhpcyB3YXMgdmVyeSBuaWNlIGFuZCBsb2dpY2Fs
LiBJIGhvcGUgaXQgc3RpbGwgd29ya3MuDQo+ID4gPiA+IHJlZ2FyZHMgQmFsYXpzDQo+ID4gPiA+
DQo+ID4gPiA+IE9uIDIwMTQtMDctMjkgMTQ6MTcsIEFuZHkgQmllcm1hbiB3cm90ZToNCj4gPiA+
ID4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gT24gVHVlLCBKdWwgMjksIDIw
MTQgYXQgMTI6NDQgQU0sIEtsZW1lbnQgU2VrZXJhIC1YIChrc2VrZXJhIC0gUGFudGhlb24NCj4g
PiA+ID4gVGVjaG5vbG9naWVzIFNSTyBhdCBDaXNjbykgPGtzZWtlcmFAY2lzY28uY29tPiB3cm90
ZToNCj4gPiA+ID4NCj4gPiA+ID4+IE9uIE1vbiwgMjAxNC0wNy0yOCBhdCAwODo0MyAtMDcwMCwg
QW5keSBCaWVybWFuIHdyb3RlOg0KPiA+ID4gPj4gPiBPbiBNb24sIEp1bCAyOCwgMjAxNCBhdCA4
OjMxIEFNLCBLbGVtZW50IFNla2VyYSAtWCAoa3Nla2VyYSAtDQo+ID4gUGFudGhlb24NCj4gPiA+
ID4+ID4gVGVjaG5vbG9naWVzIFNSTyBhdCBDaXNjbykgPGtzZWtlcmFAY2lzY28uY29tPiB3cm90
ZToNCj4gPiA+ID4+ID4NCj4gPiA+ID4+ID4gPiBPbiBNb24sIDIwMTQtMDctMjggYXQgMDg6MjIg
LTA3MDAsIEFuZHkgQmllcm1hbiB3cm90ZToNCj4gPiA+ID4+ID4gPiA+IE9uIE1vbiwgSnVsIDI4
LCAyMDE0IGF0IDg6MTEgQU0sIEtsZW1lbnQgU2VrZXJhIC1YIChrc2VrZXJhIC0NCj4gPiA+ID4+
IFBhbnRoZW9uDQo+ID4gPiA+PiA+ID4gPiBUZWNobm9sb2dpZXMgU1JPIGF0IENpc2NvKSA8a3Nl
a2VyYUBjaXNjby5jb20+IHdyb3RlOg0KPiA+ID4gPj4gPiA+ID4NCj4gPiA+ID4+ID4gPiA+ID4g
SGkgYWxsLA0KPiA+ID4gPj4gPiA+ID4gPg0KPiA+ID4gPj4gPiA+ID4gPiB3ZSBhcmUgY3VycmVu
dGx5IGRlYmF0aW5nIGFuIGlzc3VlIHdlIGZvdW5kIGFuZCB3b3VsZCBsaWtlIHRvDQo+ID4gPiA+
PiBoYXZlIHNvbWUNCj4gPiA+ID4+ID4gPiA+ID4gY2xhcmlmaWNhdGlvbi4gTmV0Y29uZiBSRkMg
c2F5cyB0aGF0IHRoZSBlZGl0LWNvbmZpZyBvcGVyYXRpb24NCj4gPiA+ID4+IHdoaWNoDQo+ID4g
PiA+PiA+ID4gPiA+IGNvbnRhaW5zIG11bHRpcGxlIHN1Yi1vcGVyYXRpb25zIG9uIHRoZSBzYW1l
IGRhdGEgaXMNCj4gPiB1bmRlZmluZWQuDQo+ID4gPiA+PiA+ID4gPiA+DQo+ID4gPiA+PiA+ID4g
PiA+IHNvIHdoZW4gY29uc2lkZXJpbmcgdGhpcyByZXF1ZXN0Og0KPiA+ID4gPj4gPiA+ID4gPg0K
PiA+ID4gPj4gPiA+ID4gPiA8ZWRpdC1jb25maWc+DQo+ID4gPiA+PiA+ID4gPiA+IDx0YXJnZXQ+
PGNhbmRpZGF0ZS8+PC90YXJnZXQ+DQo+ID4gPiA+PiA+ID4gPiA+IDxjb25maWc+DQo+ID4gPiA+
PiA+ID4gPiA+ICA8Y29udGFpbmVyIG9wZXJhdGlvbj0iZGVsZXRlIj4NCj4gPiA+ID4+ID4gPiA+
ID4gICA8bGVhZiBvcGVyYXRpb249ImNyZWF0ZSIvPg0KPiA+ID4gPj4gPiA+ID4gPiAgPC9jb250
YWluZXI+DQo+ID4gPiA+PiA+ID4gPiA+IDwvY29uZmlnPg0KPiA+ID4gPj4gPiA+ID4gPiA8L2Vk
aXQtY29uZmlnPg0KPiA+ID4gPj4gPiA+ID4gPg0KPiA+ID4gPj4gPiA+ID4gPiB0aGUgb3V0Y29t
ZSBpcyB1bmRlZmluZWQsIHNpbmNlIHRoZSBjbGllbnQgd2FudHMgZG8gZGVsZXRlDQo+ID4gPiA+
PiBjb250YWluZXINCj4gPiA+ID4+ID4gPiA+ID4gPGNvbnRhaW5lcj4sIHdoaWxlIHNpbXVsdGFu
ZW91c2x5IGNyZWF0aW5nIDxsZWFmPiB3aGljaCBpcw0KPiA+IHBhcnQgb2YNCj4gPiA+ID4+ID4g
PiA+ID4gPGNvbnRhaW5lcj4uDQo+ID4gPiA+PiA+ID4gPiA+DQo+ID4gPiA+PiA+ID4gPiA+DQo+
ID4gPiA+PiA+ID4gPiBJdCBpcyBkZWZpbmVkLg0KPiA+ID4gPj4gPiA+ID4gRG9lcyB0aGUgbm9k
ZSAvY29udGFpbmVyIGV4aXN0IGluIHRoZSB0YXJnZXQgZGF0YXN0b3JlPw0KPiA+ID4gPj4gPiA+
ID4gSWYgeWVzLCB0aGVuIHRoZSBjcmVhdGUgb3BlcmF0aW9uIG9uIC9jb250YWluZXIvbGVhZiBN
VVNUIGZhaWwuDQo+ID4gPiA+PiA+ID4gPiBJZiBubywgdGhlbiB0aGUgZGVsZXRlIG9wZXJhdGlv
biBvbiAvY29udGFpbmVyIE1VU1QgZmFpbC4NCj4gPiA+ID4+ID4gPg0KPiA+ID4gPj4gPiA+IHdo
YXQgaWYgL2NvbnRhaW5lciBleGlzdHMgYnV0IC9jb250YWluZXIvbGVhZiBkb2VzIG5vdD8gdGhp
cyB3YXkNCj4gPiBib3RoDQo+ID4gPiA+PiA+ID4gc3ViLW9wZXJhdGlvbnMgY291bGQgYmUgcGVy
Zm9ybWVkDQo+ID4gPiA+PiA+ID4NCj4gPiA+ID4+ID4NCj4gPiA+ID4+ID4NCj4gPiA+ID4+ID4g
bm90IHJlYWxseS4gSWYgaW1wbGVtZW50ZWQgY29ycmVjdGx5IHRoZW4gaWYgdGhlIGRlbGV0ZSBv
bg0KPiA+IC9jb250YWluZXINCj4gPiA+ID4+ID4gc3VjY2VlZHMsDQo+ID4gPiA+PiA+IHRoZW4g
YWxsIGl0cyBkZXNjZW5kYW50cyBhcmUgYWxzbyBkZWxldGVkLiAgVGhlIHJlc3VsdCBpbiB0aGUg
dGFyZ2V0DQo+ID4gPiA+PiA+IGRhdGFzdG9yZSBjYW5ub3QNCj4gPiA+ID4+ID4gcG9zc2libHkg
Y29tcGxldGUgYm90aCBhIGRlbGV0ZSBvbiBhbiBhbmNlc3RvciBhbmQgY3JlYXRlIG9mIGENCj4g
PiA+ID4+IGRlc2NlbmRhbnQNCj4gPiA+ID4+ID4gaW4gdGhlIHNhbWUgZWRpdC4gT3VyIHNlcnZl
ciByZXR1cm5zIGFuIGVycm9yIGJlY2F1c2UgaXQgY2Fubm90DQo+ID4gaG9ub3INCj4gPiA+ID4+
ID4gYm90aCByZXF1ZXN0cy4NCj4gPiA+ID4+ID4NCj4gPiA+ID4+DQo+ID4gPiA+PiBJIGJlbGll
dmUgdGhhdCB0aGlzIGlzIHRoZSBwYXJ0IHdoZXJlDQo+ID4gPiA+Pg0KPiA+ID4gPj4gICAgICAg
SWYgdGhlIDxlZGl0LWNvbmZpZz4gb3BlcmF0aW9uIGNvbnRhaW5zIG11bHRpcGxlIHN1Yi1vcGVy
YXRpb25zDQo+ID4gPiA+PiAgICAgICB0aGF0IGFwcGx5IHRvIHRoZSBzYW1lIGNvbmNlcHR1YWwg
bm9kZSBpbiB0aGUgdW5kZXJseWluZyBkYXRhDQo+ID4gPiA+PiAgICAgICBtb2RlbCwgdGhlbiB0
aGUgcmVzdWx0IG9mIHRoZSBvcGVyYXRpb24gaXMgdW5kZWZpbmVkIChpLmUuLA0KPiA+ID4gPj4g
ICAgICAgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhlIE5FVENPTkYgcHJvdG9jb2wpLg0KPiA+ID4g
Pj4NCj4gPiA+ID4+IGNvbWVzIGludG8gcGxheS4gRXhhY3RseSBhcyB5b3Ugc2F5LCB0YXJnZXQg
ZGF0YXN0b3JlIGNhbm5vdCBjb21wbGV0ZQ0KPiA+ID4gPj4gYm90aCB0aGUgZGVsZXRpb24gYW5k
IGNyZWF0aW9uLCBzaW5jZSBib3RoIG9wZXJhdGUgb24gdGhlIHNhbWUgZGF0YQ0KPiA+IGJ1dA0K
PiA+ID4gPj4gcnVsZSBlYWNoIG90aGVyIG91dC4NCj4gPiA+ID4+DQo+ID4gPiA+PiA+DQo+ID4g
PiA+PiA+DQo+ID4gPiA+PiA+DQo+ID4gPiA+PiA+ID4NCj4gPiA+ID4+ID4gPiA+DQo+ID4gPiA+
PiA+ID4gPg0KPiA+ID4gPj4gPiA+ID4NCj4gPiA+ID4+ID4gPiA+ID4gTm93LCB3aGVuIGNvbnNp
ZGVyaW5nIGEgc2ltcGxlIGxpc3QgZGVsZXRpb246DQo+ID4gPiA+PiA+ID4gPiA+DQo+ID4gPiA+
PiA+ID4gPiA+IDxlZGl0LWNvbmZpZz4NCj4gPiA+ID4+ID4gPiA+ID4gPHRhcmdldD48Y2FuZGlk
YXRlLz48L3RhcmdldD4NCj4gPiA+ID4+ID4gPiA+ID4gPGNvbmZpZz4NCj4gPiA+ID4+ID4gPiA+
ID4gIDxsaXN0IG9wZXJhdGlvbj0iZGVsZXRlIj4NCj4gPiA+ID4+ID4gPiA+ID4gICA8a2V5LW5v
ZGU+a2V5LXZhbHVlPC9rZXktbm9kZT4NCj4gPiA+ID4+ID4gPiA+ID4gIDwvbGlzdD4NCj4gPiA+
ID4+ID4gPiA+ID4gPC9jb25maWc+DQo+ID4gPiA+PiA+ID4gPiA+IDwvZWRpdC1jb25maWc+DQo+
ID4gPiA+PiA+ID4gPiA+DQo+ID4gPiA+PiA+ID4gPiA+IGFuZCByaWdvcm91c2x5IHJlYWRpbmcg
dGhlIFJGQyByZWdhcmRpbmcgb3BlcmF0aW9uIGFuZA0KPiA+ID4gPj4gPiA+ID4gPiBkZWZhdWx0
LW9wZXJhdGlvbiwgdGhlIG9wZXJhdGlvbiBhdHRyaWJ1dGUgZm9yIDxrZXktbm9kZT4gaXMNCj4g
PiA+ID4+ICJtZXJnZSIsDQo+ID4gPiA+PiA+ID4gPiA+IHRodXMsIHRlY2huaWNhbGx5LCB0aGlz
IGVkaXQtY29uZmlnIG9wZXJhdGlvbiBvcGVyYXRlcyBvbiB0aGUNCj4gPiA+ID4+ID4gPiA8a2V5
LW5vZGU+DQo+ID4gPiA+PiA+ID4gPiA+IHR3aWNlOg0KPiA+ID4gPj4gPiA+ID4gPg0KPiA+ID4g
Pj4gPiA+ID4NCj4gPiA+ID4+ID4gPiA+IFRoZSBvcGVyYXRpb24gaXMgaW5oZXJpdGVkIGZyb20g
aXRzIHBhcmVudCBpZiBubyAibmM6b3BlcmF0aW9uIg0KPiA+ID4gPj4gPiA+ID4gYXR0cmlidXRl
IGlzIHNwZWNpZmllZC4gVGhlIGtleXMgbmVlZCB0byBiZSBwcmVzZW50IHRvIHNwZWNpZnkNCj4g
PiB0aGUNCj4gPiA+ID4+IGxpc3QNCj4gPiA+ID4+ID4gPiA+IG5vZGUgdG8gYmUgZGVsZXRlZC4N
Cj4gPiA+ID4+ID4gPg0KPiA+ID4gPj4gPiA+IGNhbiB5b3UgcG9pbnQgdG8gdGhlIHBhcmFncmFw
aCBpbiBuZXRjb25mIFJGQyB3aGljaCBzYXlzIHRoYXQgdGhlDQo+ID4gPiA+PiA+ID4gb3BlcmF0
aW9uIGlzIGluaGVyaXRlZD8NCj4gPiA+ID4+ID4gPg0KPiA+ID4gPj4gPiA+DQo+ID4gPiA+PiA+
IHRoZSBkZWxldGUgb3BlcmF0aW9uIG9uIHRoZSAvY29udGFpbmVyIG5vZGUgaXMgZm9yIHRoZSBj
b250YWluZXIgYW5kDQo+ID4gPiA+PiBhbGwgaXRzDQo+ID4gPiA+PiA+IGRlc2NlbmRhbnRzLiAg
VGhhdCBpcyBob3cgaXQgaXMgaW5oZXJpdGVkLiBJIHNob3VsZCBoYXZlIHNhaWQNCj4gPiA+ID4+
ICJlZmZlY3RpdmUiDQo+ID4gPiA+PiA+IG9wZXJhdGlvbg0KPiA+ID4gPj4gPiBpbnN0ZWFkIG9m
ICJpbmhlcml0ZWQiLg0KPiA+ID4gPj4NCj4gPiA+ID4+ICAgICAgIG9wZXJhdGlvbjogIEVsZW1l
bnRzIGluIHRoZSA8Y29uZmlnPiBzdWJ0cmVlIE1BWSBjb250YWluIGFuDQo+ID4gPiA+PiAgICAg
ICAgICAib3BlcmF0aW9uIiBhdHRyaWJ1dGUsIHdoaWNoIGJlbG9uZ3MgdG8gdGhlIE5FVENPTkYg
bmFtZXNwYWNlDQo+ID4gPiA+PiAgICAgICAgICBkZWZpbmVkIGluIFNlY3Rpb24gMy4xLiAgVGhl
IGF0dHJpYnV0ZSBpZGVudGlmaWVzIHRoZSBwb2ludA0KPiA+IGluDQo+ID4gPiA+PiAgICAgICAg
ICB0aGUgY29uZmlndXJhdGlvbiB0byBwZXJmb3JtIHRoZSBvcGVyYXRpb24gYW5kIE1BWSBhcHBl
YXIgb24NCj4gPiA+ID4+ICAgICAgICAgIG11bHRpcGxlIGVsZW1lbnRzIHRocm91Z2hvdXQgdGhl
IDxjb25maWc+IHN1YnRyZWUuDQo+ID4gPiA+Pg0KPiA+ID4gPj4gICAgICAgICAgSWYgdGhlICJv
cGVyYXRpb24iIGF0dHJpYnV0ZSBpcyBub3Qgc3BlY2lmaWVkLCB0aGUNCj4gPiA+ID4+ICAgICAg
ICAgIGNvbmZpZ3VyYXRpb24gaXMgbWVyZ2VkIGludG8gdGhlIGNvbmZpZ3VyYXRpb24gZGF0YXN0
b3JlLg0KPiA+ID4gPj4NCj4gPiA+ID4+IGluIHRoaXMgY2FzZSwgdGhlICJvcGVyYXRpb24iIGF0
dHJpYnV0ZSBmb3IgPGtleS1ub2RlPiBpcyBub3QNCj4gPiBzcGVjaWZpZWQuDQo+ID4gPiA+PiBT
byB0aGUgcHJvdmlkZWQgZXhhbXBsZSByZXF1ZXN0IGlzIGVxdWl2YWxlbnQgdG8gdGhpcyByZXF1
ZXN0Og0KPiA+ID4gPj4NCj4gPiA+ID4+IDxsaXN0IG9wZXJhdGlvbj0iZGVsZXRlIj4NCj4gPiA+
ID4+ICA8a2V5LW5vZGUgb3BlcmF0aW9uPSJtZXJnZSI+a2V5LXZhbHVlPC9rZXktbm9kZT4NCj4g
PiA+ID4+IDwvbGlzdD4NCj4gPiA+ID4+DQo+ID4gPiA+PiBzbyBiYXNpY2FsbHkgaXQncyB0aGUg
c2FtZSBhcyBhYm92ZSAtIHRoZXJlIGlzIGEgcmVxdWVzdCBkbyBkZWxldGUNCj4gPiA+ID4+IDxs
aXN0PiB3aGlsZSBjcmVhdGluZyBhbmQvb3Iga2VlcGluZyA8a2V5LW5vZGU+IGFyb3VuZCAtIGJv
dGggY2Fubm90DQo+ID4gYmUNCj4gPiA+ID4+IGRvbmUuIEkgY2Fubm90IGZpbmQgYW55IGV4Y2Vw
dGlvbiBpbiB0aGUgUkZDIGZvciBsaXN0L2tleS1ub2RlIGNvbWJvDQo+ID4gPiA+PiBjYXNlLg0K
PiA+ID4gPj4NCj4gPiA+ID4+DQo+ID4gPiA+ICBQZXJoYXBzIDEgbmV3IHNlbnRlbmNlIChBZnRl
ciB0aGUgMSBhYm91dCBubyBhdHRyaWJ1dGU9bWVyZ2UpOg0KPiA+ID4gPg0KPiA+ID4gPiAgICBJ
ZiB0aGUgb3BlcmF0aW9uIGF0dHJpYnV0ZSBpcyBub3QgcHJlc2VudCBmb3IgYSBrZXkgbGVhZiBu
b2RlLCBhbmQNCj4gPiA+ID4gICB0aGUgZWRpdCBvcGVyYXRpb24gZm9yIHRoZSBwYXJlbnQgbm9k
ZSBpcyAiZGVsZXRlIiBvciAicmVtb3ZlIiwNCj4gPiA+ID4gICB0aGVuIHRoZSBvcGVyYXRpb24g
Zm9yIHRoZSBrZXkgbGVhZiBub2RlIGlzIHRoZSBzYW1lIGFzIGl0cyBwYXJlbnQNCj4gPiBub2Rl
Lg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiAgQW5keQ0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+
ID4gPg0KPiA+ID4gPj4gPg0KPiA+ID4gPj4gPg0KPiA+ID4gPj4gPiA+DQo+ID4gPiA+PiA+ID4g
Pg0KPiA+ID4gPj4gPiA+ID4NCj4gPiA+ID4+ID4gPiA+ID4gMS4pIGRlbGV0aW5nIHRoZSB2YWx1
ZSB2aWEgZGVsZXRpb24gb2YgdGhlIGxpc3QgZW50aXR5IDxsaXN0Pg0KPiA+ID4gPj4gPiA+ID4g
PiAyLikgbWVyZ2luZyBpbiBhIG5ldyB2YWx1ZSB2aWEgIm1lcmdlIiBvbiB0aGUgPGtleS1ub2Rl
Pg0KPiA+ID4gPj4gPiA+ID4gPg0KPiA+ID4gPj4gPiA+ID4gPg0KPiA+ID4gPj4gPiA+ID4gPiBU
aGUgUkZDIGhhcyA8ZGVmYXVsdC1vcGVyYXRpb24+bm9uZTwvZGVmYXVsdC1vcGVyYXRpb24+IGlu
IGFsbA0KPiA+ID4gPj4gZGVsZXRpb24NCj4gPiA+ID4+ID4gPiA+ID4gZXhhbXBsZXMsIHdoaWNo
IG1ha2VzIHVzIGJlbGlldmUgdGhhdCBpbmRlZWQgd2hlbiBwcm9jZXNzaW5nDQo+ID4gdGhlDQo+
ID4gPiA+PiA+ID4gPiA+IG1lbnRpb25lZCByZXF1ZXN0LCB0aGUgPGtleS1ub2RlPidzIG9wZXJh
dGlvbiB3b3VsZCBiZSAibWVyZ2UiDQo+ID4gPiA+PiBhbmQgdGh1cw0KPiA+ID4gPj4gPiA+ID4g
PiB0aGUgb3BlcmF0aW9uIHVuZGVmaW5lZC4NCj4gPiA+ID4+ID4gPiA+ID4NCj4gPiA+ID4+ID4g
PiA+ID4gSXMgdGhpcyBob3cgaXQncyBzdXBwb3NlZCB0byBiZSBvciBhcmUgd2UgcmVhZGluZyBp
dCB3cm9uZz8NCj4gPiA+ID4+ID4gPiA+ID4NCj4gPiA+ID4+ID4gPiA+ID4NCj4gPiA+ID4+ID4g
PiA+IHRoZSBsYXR0ZXINCj4gPiA+ID4+ID4gPiA+DQo+ID4gPiA+PiA+ID4gPg0KPiA+ID4gPj4g
PiA+ID4gPiBUaGFua3MsDQo+ID4gPiA+PiA+ID4gPiA+IEtsZW1lbnQNCj4gPiA+ID4+ID4gPiA+
ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+
ID4+ID4gPiA+ID4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gPiA+ID4+ID4gPiA+ID4gTmV0Y29u
ZkBpZXRmLm9yZw0KPiA+ID4gPj4gPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL25ldGNvbmYNCj4gPiA+ID4+ID4gPiA+ID4NCj4gPiA+ID4+ID4gPg0KPiA+ID4g
Pj4gPiA+DQo+ID4gPiA+PiA+IEFuZHkNCj4gPiA+ID4+DQo+ID4gPiA+Pg0KPiA+ID4gPg0KPiA+
ID4gPg0KPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KPiA+ID4gPiBOZXRjb25mIG1haWxpbmcgbGlzdE5ldGNvbmZAaWV0Zi5vcmdodHRwczov
Lw0KPiA+IHd3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gPiA+ID4NCj4g
PiA+ID4NCj4gPiA+ID4gLS0NCj4gPiA+ID4gQmFsYXpzIExlbmd5ZWwgICAgICAgICAgICAgICAg
ICAgICAgIEVyaWNzc29uIEh1bmdhcnkgTHRkLg0KPiA+ID4gPiBTZW5pb3IgU3BlY2lhbGlzdA0K
PiA+ID4gPiBFQ046IDgzMSA3MzIwICAgICAgICAgICAgICAgICAgICAgICAgVGVsOiArMzYtMS00
MzctNzMyMA0KPiA+ID4gPiBNb2JpbGU6ICszNi03MC0zMzAtNzkwOSAgICAgICAgICAgICAgZW1h
aWw6DQo+ID4gQmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24uY29tDQo+ID4gPiA+DQo+ID4gPiA+DQo+
ID4NCj4gPg0KDQo=


From nobody Tue Jul 29 09:41:50 2014
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7B31A040E for ; Tue, 29 Jul 2014 09:41:49 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 QR6ZYXT5ci6f for ; Tue, 29 Jul 2014 09:41:44 -0700 (PDT)
Received: from p3plsmtpa09-10.prod.phx3.secureserver.net (p3plsmtpa09-10.prod.phx3.secureserver.net [173.201.193.239]) by ietfa.amsl.com (Postfix) with ESMTP id 94DAA1B28DC for ; Tue, 29 Jul 2014 09:41:44 -0700 (PDT)
Received: from [192.168.2.3] ([50.179.41.78]) by p3plsmtpa09-10.prod.phx3.secureserver.net with  id YGhi1o00N1hB5UJ01Ghjsz; Tue, 29 Jul 2014 09:41:43 -0700
Message-ID: <53D7CEC0.4020300@seguesoft.com>
Date: Tue, 29 Jul 2014 11:41:36 -0500
From: Xiang Li 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" 
References: <1406560309.12287.21.camel@ksekera-fedora>	 	 <1406561507.12287.24.camel@ksekera-fedora>	 	 <1406619859.12287.31.camel@ksekera-fedora>	 	 <53D7B316.8020903@ericsson.com>	 	 <1406646178.21825.6.camel@ksekera-fedora> <53D7BFE2.9080003@seguesoft.com> <1406649697.21825.11.camel@ksekera-fedora>
In-Reply-To: <1406649697.21825.11.camel@ksekera-fedora>
Content-Type: multipart/alternative; boundary="------------020508090409060004020705"
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/HKrKqLzj1FjhBHhQd15CYvrp8WI
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] edit-config operation inconsistency
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Jul 2014 16:41:49 -0000

This is a multi-part message in MIME format.
--------------020508090409060004020705
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 7/29/2014 11:01 AM, Klement Sekera -X (ksekera - Pantheon 
Technologies SRO at Cisco) wrote:
> On Tue, 2014-07-29 at 10:38 -0500, Xiang Li wrote:
>> On 7/29/2014 10:03 AM, Klement Sekera -X (ksekera - Pantheon
>> Technologies SRO at Cisco) wrote:
>>> On Tue, 2014-07-29 at 07:54 -0700, Andy Bierman wrote:
>>>> On Tue, Jul 29, 2014 at 7:43 AM, Balazs Lengyel >>>> wrote:
>>>>>    Hello,
>>>>> I always tought the operation attribute is inherited.
>>>>>
>>>> This is how everybody implements it, and what we intended (pre-4741).
>>>> Otherwise, would a "replace" operation for some arbitrary subtree
>>>> require nc:operation="replace" in every replacement descendant node?
>>>>
>>>>
>>>> Andy
>>>>
>>> Well if the default-operation is unchanged, then
>>>
>>> 
>>>    
>>> 
>>>
>>> works perfectly fine if the operation for  is assumed to be a
>>> "merge". First, the server removes the existing , replaces it
>>> with empty one and then merges the  in.
>>>
>>>   From this point of view, "merge" on child is compatible with "create" or
>>> "replace" on parent.
>>>
>>> I don't see any sentence in the RFC which says that the operation is
>>> inherited.
>> RFC6243
>>
>>
>>    With-defaults Capability for NETCONF may help clarify wh "effective
>>    operation" means in an "edit-config":
>>
>>
>>
>>          4.5.2 .
>>           Operation
>>
>> ...
>>
>> If the 'default' attribute is present, then the effective operation
>>      for the target data node MUST be 'create', 'merge', or 'replace'.  If
>>      not, then the server MUST return an  response with an
>>      'invalid-value' error-tag.  For example, if 'create' is the effective
>>      operation, then the create request must be valid on its own (e.g.,
>>      current data node MUST NOT exist).  The procedure for determining the
>>      effective operation is defined in [RFC6241  ].  I*t is derived from the
>>      'default-operation' parameter and/or any operation attributes that
>>      are present in the data node or any of its ancestor nodes, within the
>>       request.*
>>
>> In other words the "operation" attribute has a "scope", that is, it applies
>> to the nested nodes, until is is redefined. This is logical too.
> side-note: not every netconf server must support with-defaults
> capability

The point is not about whether a sever supports " with-defaults 
capability". The paragraph
I quoted simply helps us see the  NETCONF protocol authors' intention.

>
> It says that the operation is derived from default-operation and/or any
> operation attributes present.

To be precise, RFC6243 says:

  It is derived from the 'default-operation' parameter and/or any operation attributes that
    are present in the data node or any of its ancestor nodes, within the
     request.

Notice the "ancestor nodes" wording.

**


> Now RFC 6241 says:
>
>        default-operation:  Selects the default operation (as described in
>           the "operation" attribute) for this  request.  The
>           default value for the  parameter is "merge".
>
> so whenever a node does not have an operation attribute, this clause
> forces the server to operate as if it was "merge", if not set to other
> value.

But if there is "operation" attribute specified in itself or any parent 
node then the effective
operation is not "merge" anymore.

>   I think this is prevents any inheritance logic.

I don't see why the sentence above prevents any inheritance.

RFC6241 says:

    operation:  Elements in the  subtree MAY contain an
          "operation" attribute, which belongs to the NETCONF namespace
          defined inSection 3.1  .  The attribute identifies the point in
          the configuration to perform the operation and MAY appear on
          multiple elements throughout the  subtree.


Notice the "point" wording used here. In other words "operation" identifies
a point (a subtree) where the config data should be applied. My understanding
is that it does not make sense if the "point" means the "element" here.

Perhaps it could be clearer if it were written as " the attribute identifies
the point and below in the configuration...".


--Xiang


>> --Xiang Li
>>
>>
>>>>
>>>>
>>>>
>>>>
>>>>> Inherited in a sense that an XML element actually contains/includes all
>>>>> sub-elements under it. So creating/deleting/merging the element means
>>>>> creating/deleting/merging all its contents as well. So unless you later
>>>>> override this with more specific instructions for one of the contained
>>>>> elements it should be valid for the complete element with all its content.
>>>>>
>>>>> If operation is not inheritable we have some interesting cases:
>>>>> - your examples
>>>>> - default operation=none and I want to create a sizeable subtree. I have
>>>>> to place the merge/create operation on every node. Don't like it, makes
>>>>> none-unusable except for delete/remove.
>>>>> Lets say we have the following data model:
>>>>>
>>>>> routing
>>>>>     +--static-routing
>>>>>     |   +--route [routeId]
>>>>>     |        +--routeId 			ipprefix
>>>>>     |        +--path-to-destination 	[nexthop]
>>>>>     |            +--nextHop 		ipAddress
>>>>>     |            +--outgoingInterface   	string
>>>>>                  +--bfdActive		boolean
>>>>>
>>>>> I want to create a static route with all its sub-elements but only if the
>>>>> static-routing presence container exists (static routing is
>>>>> allowed/enabled).
>>>>> none
>>>>> 
>>>>>        --- this will check that static routing exists.
>>>>>           --this will create the interface
>>>>>            1.1.1.1/24   -- I don't want to put
>>>>> operation=create on all further nodes 5 times or more depending on the
>>>>> number of paths
>>>>>            
>>>>>               1.1.1.5
>>>>>               eth0
>>>>>               true
>>>>>            
>>>>>         
>>>>>      
>>>>> 
>>>>>
>>>>>    This was very nice and logical. I hope it still works.
>>>>> regards Balazs
>>>>>
>>>>> On 2014-07-29 14:17, Andy Bierman wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jul 29, 2014 at 12:44 AM, Klement Sekera -X (ksekera - Pantheon
>>>>> Technologies SRO at Cisco)  wrote:
>>>>>
>>>>>> On Mon, 2014-07-28 at 08:43 -0700, Andy Bierman wrote:
>>>>>>> On Mon, Jul 28, 2014 at 8:31 AM, Klement Sekera -X (ksekera - Pantheon
>>>>>>> Technologies SRO at Cisco)  wrote:
>>>>>>>
>>>>>>>> On Mon, 2014-07-28 at 08:22 -0700, Andy Bierman wrote:
>>>>>>>>> On Mon, Jul 28, 2014 at 8:11 AM, Klement Sekera -X (ksekera -
>>>>>> Pantheon
>>>>>>>>> Technologies SRO at Cisco)  wrote:
>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> we are currently debating an issue we found and would like to
>>>>>> have some
>>>>>>>>>> clarification. Netconf RFC says that the edit-config operation
>>>>>> which
>>>>>>>>>> contains multiple sub-operations on the same data is undefined.
>>>>>>>>>>
>>>>>>>>>> so when considering this request:
>>>>>>>>>>
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>    
>>>>>>>>>>     
>>>>>>>>>>    
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>
>>>>>>>>>> the outcome is undefined, since the client wants do delete
>>>>>> container
>>>>>>>>>> , while simultaneously creating  which is part of
>>>>>>>>>> .
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> It is defined.
>>>>>>>>> Does the node /container exist in the target datastore?
>>>>>>>>> If yes, then the create operation on /container/leaf MUST fail.
>>>>>>>>> If no, then the delete operation on /container MUST fail.
>>>>>>>> what if /container exists but /container/leaf does not? this way both
>>>>>>>> sub-operations could be performed
>>>>>>>>
>>>>>>> not really. If implemented correctly then if the delete on /container
>>>>>>> succeeds,
>>>>>>> then all its descendants are also deleted.  The result in the target
>>>>>>> datastore cannot
>>>>>>> possibly complete both a delete on an ancestor and create of a
>>>>>> descendant
>>>>>>> in the same edit. Our server returns an error because it cannot honor
>>>>>>> both requests.
>>>>>>>
>>>>>> I believe that this is the part where
>>>>>>
>>>>>>         If the  operation contains multiple sub-operations
>>>>>>         that apply to the same conceptual node in the underlying data
>>>>>>         model, then the result of the operation is undefined (i.e.,
>>>>>>         outside the scope of the NETCONF protocol).
>>>>>>
>>>>>> comes into play. Exactly as you say, target datastore cannot complete
>>>>>> both the deletion and creation, since both operate on the same data but
>>>>>> rule each other out.
>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>>> Now, when considering a simple list deletion:
>>>>>>>>>>
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>    
>>>>>>>>>>     key-value
>>>>>>>>>>    
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>
>>>>>>>>>> and rigorously reading the RFC regarding operation and
>>>>>>>>>> default-operation, the operation attribute for  is
>>>>>> "merge",
>>>>>>>>>> thus, technically, this edit-config operation operates on the
>>>>>>>> 
>>>>>>>>>> twice:
>>>>>>>>>>
>>>>>>>>> The operation is inherited from its parent if no "nc:operation"
>>>>>>>>> attribute is specified. The keys need to be present to specify the
>>>>>> list
>>>>>>>>> node to be deleted.
>>>>>>>> can you point to the paragraph in netconf RFC which says that the
>>>>>>>> operation is inherited?
>>>>>>>>
>>>>>>>>
>>>>>>> the delete operation on the /container node is for the container and
>>>>>> all its
>>>>>>> descendants.  That is how it is inherited. I should have said
>>>>>> "effective"
>>>>>>> operation
>>>>>>> instead of "inherited".
>>>>>>         operation:  Elements in the  subtree MAY contain an
>>>>>>            "operation" attribute, which belongs to the NETCONF namespace
>>>>>>            defined in Section 3.1.  The attribute identifies the point in
>>>>>>            the configuration to perform the operation and MAY appear on
>>>>>>            multiple elements throughout the  subtree.
>>>>>>
>>>>>>            If the "operation" attribute is not specified, the
>>>>>>            configuration is merged into the configuration datastore.
>>>>>>
>>>>>> in this case, the "operation" attribute for  is not specified.
>>>>>> So the provided example request is equivalent to this request:
>>>>>>
>>>>>> 
>>>>>>    key-value
>>>>>> 
>>>>>>
>>>>>> so basically it's the same as above - there is a request do delete
>>>>>>  while creating and/or keeping  around - both cannot be
>>>>>> done. I cannot find any exception in the RFC for list/key-node combo
>>>>>> case.
>>>>>>
>>>>>>
>>>>>    Perhaps 1 new sentence (After the 1 about no attribute=merge):
>>>>>
>>>>>      If the operation attribute is not present for a key leaf node, and
>>>>>     the edit operation for the parent node is "delete" or "remove",
>>>>>     then the operation for the key leaf node is the same as its parent node.
>>>>>
>>>>>
>>>>>    Andy
>>>>>
>>>>>
>>>>>
>>>>>>>>>> 1.) deleting the value via deletion of the list entity 
>>>>>>>>>> 2.) merging in a new value via "merge" on the 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The RFC has none in all
>>>>>> deletion
>>>>>>>>>> examples, which makes us believe that indeed when processing the
>>>>>>>>>> mentioned request, the 's operation would be "merge"
>>>>>> and thus
>>>>>>>>>> the operation undefined.
>>>>>>>>>>
>>>>>>>>>> Is this how it's supposed to be or are we reading it wrong?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> the latter
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Klement
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Netconf mailing list
>>>>>>>>>> Netconf@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/netconf
>>>>>>>>>>
>>>>>>> Andy
>>>>> _______________________________________________
>>>>> Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf
>>>>>
>>>>>
>>>>> --
>>>>> Balazs Lengyel                       Ericsson Hungary Ltd.
>>>>> Senior Specialist
>>>>> ECN: 831 7320                        Tel: +36-1-437-7320
>>>>> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
>>>>>
>>>>>
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netconf
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf

-- 
--
Xiang Li,
Seguesoft, Champaign, IL
(217) 721-5341


--------------020508090409060004020705
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    
On 7/29/2014 11:01 AM, Klement Sekera
      -X (ksekera - Pantheon Technologies SRO at Cisco) wrote:

    

    

      
On Tue, 2014-07-29 at 10:38 -0500, Xiang Li wrote:


      

        
On 7/29/2014 10:03 AM, Klement Sekera -X (ksekera - Pantheon 
Technologies SRO at Cisco) wrote:


        

          
On Tue, 2014-07-29 at 07:54 -0700, Andy Bierman wrote:


          

            
On Tue, Jul 29, 2014 at 7:43 AM, Balazs Lengyel <balazs.lengyel@ericsson.com


            

              
wrote:
  Hello,
I always tought the operation attribute is inherited.



            

            
This is how everybody implements it, and what we intended (pre-4741).
Otherwise, would a "replace" operation for some arbitrary subtree
require nc:operation="replace" in every replacement descendant node?


Andy



          

          
Well if the default-operation is unchanged, then

<container operation="replace">
  <leaf/>
</container>

works perfectly fine if the operation for <leaf> is assumed to be a
"merge". First, the server removes the existing <container>, replaces it
with empty one and then merges the <leaf> in.

 From this point of view, "merge" on child is compatible with "create" or
"replace" on parent.

I don't see any sentence in the RFC which says that the operation is
inherited.


        

        
RFC6243


  With-defaults Capability for NETCONF may help clarify wh "effective
  operation" means in an "edit-config":



        4.5.2 <http://tools.ietf.org/html/rfc6243#section-4.5.2>.
        <edit-config> Operation

...

If the 'default' attribute is present, then the effective operation
    for the target data node MUST be 'create', 'merge', or 'replace'.  If
    not, then the server MUST return an <rpc-error> response with an
    'invalid-value' error-tag.  For example, if 'create' is the effective
    operation, then the create request must be valid on its own (e.g.,
    current data node MUST NOT exist).  The procedure for determining the
    effective operation is defined in [RFC6241  <http://tools.ietf.org/html/rfc6241>].  I*t is derived from the
    'default-operation' parameter and/or any operation attributes that
    are present in the data node or any of its ancestor nodes, within the
    <edit-config> request.*

In other words the "operation" attribute has a "scope", that is, it applies
to the nested nodes, until is is redefined. This is logical too.


      

      
side-note: not every netconf server must support with-defaults
capability

    

    

    The point is not about whether a sever supports " with-defaults
    capability". The paragraph

    I quoted simply helps us see the  NETCONF protocol authors'
    intention.

    

    

      

It says that the operation is derived from default-operation and/or any
operation attributes present. 

    

    

    To be precise, RFC6243 says:

    

    
 It is derived from the 'default-operation' parameter and/or any operation attributes that
   are present in the data node or any of its ancestor nodes, within the
   <edit-config> request.

Notice the "ancestor nodes" wording.



    

    

      
Now RFC 6241 says:

      default-operation:  Selects the default operation (as described in
         the "operation" attribute) for this <edit-config> request.  The
         default value for the <default-operation> parameter is "merge".

so whenever a node does not have an operation attribute, this clause
forces the server to operate as if it was "merge", if not set to other
value.

    

    

    But if there is "operation" attribute specified in itself or any
    parent node then the effective

    operation is not "merge" anymore.

    

    

      
 I think this is prevents any inheritance logic.


    

    

    I don't see why the sentence above prevents any inheritance. 

    

    RFC6241 says:

    

    
   operation:  Elements in the <config> subtree MAY contain an
         "operation" attribute, which belongs to the NETCONF namespace
         defined in Section 3.1.  The attribute identifies the point in
         the configuration to perform the operation and MAY appear on
         multiple elements throughout the <config> subtree.


Notice the "point" wording used here. In other words "operation" identifies
a point (a subtree) where the config data should be applied. My understanding
is that it does not make sense if the "point" means the "element" here. 

Perhaps it could be clearer if it were written as " the attribute identifies 
the point and below in the configuration...".


--Xiang


    

    

      

      

        
--Xiang Li




        

          

            






            

              
Inherited in a sense that an XML element actually contains/includes all
sub-elements under it. So creating/deleting/merging the element means
creating/deleting/merging all its contents as well. So unless you later
override this with more specific instructions for one of the contained
elements it should be valid for the complete element with all its content.

If operation is not inheritable we have some interesting cases:
- your examples
- default operation=none and I want to create a sizeable subtree. I have
to place the merge/create operation on every node. Don't like it, makes
none-unusable except for delete/remove.
Lets say we have the following data model:

routing
   +--static-routing
   |   +--route [routeId]
   |        +--routeId 			ipprefix
   |        +--path-to-destination 	[nexthop]
   |            +--nextHop 		ipAddress
   |            +--outgoingInterface   	string
                +--bfdActive		boolean

I want to create a static route with all its sub-elements but only if the
static-routing presence container exists (static routing is
allowed/enabled).
<default-operation>none</default-operation>
<config>
    <static-routing>  --- this will check that static routing exists.
       <route operation="create">  --this will create the interface
          <routeid>1.1.1.1/24</routeid>   -- I don't want to put
operation=create on all further nodes 5 times or more depending on the
number of paths
          <path-to-destination>
             <nextHop>1.1.1.5</nextHop>
             <outgoingInterface>eth0</outgoingInterface>
             <bfdActive>true</bfdActive>
          </path-to-destination>
       </route>
    </static-routing>
</config>

  This was very nice and logical. I hope it still works.
regards Balazs

On 2014-07-29 14:17, Andy Bierman wrote:




On Tue, Jul 29, 2014 at 12:44 AM, Klement Sekera -X (ksekera - Pantheon
Technologies SRO at Cisco) <ksekera@cisco.com> wrote:



              

                
On Mon, 2014-07-28 at 08:43 -0700, Andy Bierman wrote:


                

                  
On Mon, Jul 28, 2014 at 8:31 AM, Klement Sekera -X (ksekera - Pantheon
Technologies SRO at Cisco) <ksekera@cisco.com> wrote:



                  

                    
On Mon, 2014-07-28 at 08:22 -0700, Andy Bierman wrote:


                    

                      
On Mon, Jul 28, 2014 at 8:11 AM, Klement Sekera -X (ksekera -


                    

                  

                

                
Pantheon


                

                  

                    

                      
Technologies SRO at Cisco) <ksekera@cisco.com> wrote:



                      

                        
Hi all,

we are currently debating an issue we found and would like to


                      

                    

                  

                

                
have some


                

                  

                    

                      

                        
clarification. Netconf RFC says that the edit-config operation


                      

                    

                  

                

                
which


                

                  

                    

                      

                        
contains multiple sub-operations on the same data is undefined.

so when considering this request:

<edit-config>
<target><candidate/></target>
<config>
  <container operation="delete">
   <leaf operation="create"/>
  </container>
</config>
</edit-config>

the outcome is undefined, since the client wants do delete


                      

                    

                  

                

                
container


                

                  

                    

                      

                        
<container>, while simultaneously creating <leaf> which is part of
<container>.




                      

                      
It is defined.
Does the node /container exist in the target datastore?
If yes, then the create operation on /container/leaf MUST fail.
If no, then the delete operation on /container MUST fail.


                    

                    
what if /container exists but /container/leaf does not? this way both
sub-operations could be performed



                  

                  
not really. If implemented correctly then if the delete on /container
succeeds,
then all its descendants are also deleted.  The result in the target
datastore cannot
possibly complete both a delete on an ancestor and create of a


                

                
descendant


                

                  
in the same edit. Our server returns an error because it cannot honor
both requests.



                

                
I believe that this is the part where

       If the <edit-config> operation contains multiple sub-operations
       that apply to the same conceptual node in the underlying data
       model, then the result of the operation is undefined (i.e.,
       outside the scope of the NETCONF protocol).

comes into play. Exactly as you say, target datastore cannot complete
both the deletion and creation, since both operate on the same data but
rule each other out.



                

                  



                  

                    

                      



                      

                        
Now, when considering a simple list deletion:

<edit-config>
<target><candidate/></target>
<config>
  <list operation="delete">
   <key-node>key-value</key-node>
  </list>
</config>
</edit-config>

and rigorously reading the RFC regarding operation and
default-operation, the operation attribute for <key-node> is


                      

                    

                  

                

                
"merge",


                

                  

                    

                      

                        
thus, technically, this edit-config operation operates on the


                      

                    

                    
<key-node>


                    

                      

                        
twice:



                      

                      
The operation is inherited from its parent if no "nc:operation"
attribute is specified. The keys need to be present to specify the


                    

                  

                

                
list


                

                  

                    

                      
node to be deleted.


                    

                    
can you point to the paragraph in netconf RFC which says that the
operation is inherited?




                  

                  
the delete operation on the /container node is for the container and


                

                
all its


                

                  
descendants.  That is how it is inherited. I should have said


                

                
"effective"


                

                  
operation
instead of "inherited".


                

                
       operation:  Elements in the <config> subtree MAY contain an
          "operation" attribute, which belongs to the NETCONF namespace
          defined in Section 3.1.  The attribute identifies the point in
          the configuration to perform the operation and MAY appear on
          multiple elements throughout the <config> subtree.

          If the "operation" attribute is not specified, the
          configuration is merged into the configuration datastore.

in this case, the "operation" attribute for <key-node> is not specified.
So the provided example request is equivalent to this request:

<list operation="delete">
  <key-node operation="merge">key-value</key-node>
</list>

so basically it's the same as above - there is a request do delete
<list> while creating and/or keeping <key-node> around - both cannot be
done. I cannot find any exception in the RFC for list/key-node combo
case.




              

              
  Perhaps 1 new sentence (After the 1 about no attribute=merge):

    If the operation attribute is not present for a key leaf node, and
   the edit operation for the parent node is "delete" or "remove",
   then the operation for the key leaf node is the same as its parent node.


  Andy





              

                

                  

                  

                    

                      

                      

                        
1.) deleting the value via deletion of the list entity <list>
2.) merging in a new value via "merge" on the <key-node>


The RFC has <default-operation>none</default-operation> in all


                      

                    

                  

                

                
deletion


                

                  

                    

                      

                        
examples, which makes us believe that indeed when processing the
mentioned request, the <key-node>'s operation would be "merge"


                      

                    

                  

                

                
and thus


                

                  

                    

                      

                        
the operation undefined.

Is this how it's supposed to be or are we reading it wrong?




                      

                      
the latter




                      

                        
Thanks,
Klement
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf



                      

                    

                    

                  

                  
Andy


                

                

              

              
_______________________________________________
Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf


--
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com




            

          

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


        

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


      

      

    

    

    
-- 
--
Xiang Li, 
Seguesoft, Champaign, IL
(217) 721-5341


  


--------------020508090409060004020705--


From nobody Tue Jul 29 19:18:25 2014
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28121B2A55 for ; Tue, 29 Jul 2014 19:18:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 Vdwiqa9zPEb6 for ; Tue, 29 Jul 2014 19:18:20 -0700 (PDT)
Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 208991B2A4C for ; Tue, 29 Jul 2014 19:18:20 -0700 (PDT)
Received: by mail-qg0-f53.google.com with SMTP id q107so725471qgd.12 for ; Tue, 29 Jul 2014 19:18:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YF/3jjBiubIpmoK8lqW9byoQA/2x3nxLQYIWYdYCvx8=; b=C+TQMyWrEL+/X24qrHKw+t/0qxrdvIA7wDE5f0QF0DqQ4l2BaFRkOrafuanDeHasnY Cz1o/Wqk2UqZ8N6BBB6YK9B/zpBpf76tQugWHe1gNYldaq66lg5Zx2iNMEqFsJp9ygGZ CjgJ3bxa1rOPL+PzbqHD728yLw/fa41PijLkNfYBMW+C8kXXjgRKLoYDsdIO07Xu4xSL ruljOI6Oiq5iYSjcRJCQVnlzvSg4EG+hJSFIdqNq2AJVcJh1cAj+VCEMY/U0utM+vesw IFM7qBu9oaKuXiWa59UvxWQEwqT9mJa2gkJB4QtkY+r7vX5u+oCICGLwUQ34IOSpVZmE 2qGw==
X-Gm-Message-State: ALoCoQmXx+OhEehNpSTnCPS2f6B7FpAAkShkO54OHtobnax8/glJ+3tuqm8Ez76g2fohNZMQ6owB
MIME-Version: 1.0
X-Received: by 10.140.95.101 with SMTP id h92mr1334047qge.35.1406686699182; Tue, 29 Jul 2014 19:18:19 -0700 (PDT)
Received: by 10.140.104.48 with HTTP; Tue, 29 Jul 2014 19:18:19 -0700 (PDT)
In-Reply-To: <53D7CEC0.4020300@seguesoft.com>
References: <1406560309.12287.21.camel@ksekera-fedora>  <1406561507.12287.24.camel@ksekera-fedora>  <1406619859.12287.31.camel@ksekera-fedora>  <53D7B316.8020903@ericsson.com>  <1406646178.21825.6.camel@ksekera-fedora> <53D7BFE2.9080003@seguesoft.com> <1406649697.21825.11.camel@ksekera-fedora> <53D7CEC0.4020300@seguesoft.com>
Date: Tue, 29 Jul 2014 19:18:19 -0700
Message-ID: 
From: Andy Bierman 
To: Xiang Li 
Content-Type: multipart/alternative; boundary=001a11c15c5003f49804ff5fc5f6
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/-_-KCYy4CjH3OyIsXafME2dEYaM
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] edit-config operation inconsistency
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 02:18:25 -0000

--001a11c15c5003f49804ff5fc5f6
Content-Type: text/plain; charset=ISO-8859-1

Hi,


I know the intent was that the operation attribute was for the entire
sub-tree until explicitly
changed.

         If the "operation" attribute is not specified, the
         configuration is merged into the configuration datastore.


The preceding text on page 37 is incomplete.
Look further down on page 38 (default-operation parameter)

         default-operation:  Selects the default operation (as described in
         the "operation" attribute) for this  request.  The
         default value for the  parameter is "merge".


Obviously the text on page 37 is incomplete because the default-operation
overrides "merge".
It is very common to use default-operation="none" to make sure the target
resource already exists
when doing an update.

The text on page 37 needs to be updated somehow (as errata).
I don't think we agree on the text yet, but here is an attempt

RFC 6241, sec 7.2, para 6:

OLD:

         If the "operation" attribute is not specified, the
         configuration is merged into the configuration datastore.



NEW:

         If the "operation" attribute is not specified, then
         the operation applied to the parent data node of the configuration
         is used. If no parent data node is available, then the
'default-operation' value is used.

        Andy



On Tue, Jul 29, 2014 at 9:41 AM, Xiang Li  wrote:

>
> On 7/29/2014 11:01 AM, Klement Sekera -X (ksekera - Pantheon Technologies
> SRO at Cisco) wrote:
>
> On Tue, 2014-07-29 at 10:38 -0500, Xiang Li wrote:
>
>  On 7/29/2014 10:03 AM, Klement Sekera -X (ksekera - Pantheon
> Technologies SRO at Cisco) wrote:
>
>  On Tue, 2014-07-29 at 07:54 -0700, Andy Bierman wrote:
>
>  On Tue, Jul 29, 2014 at 7:43 AM, Balazs Lengyel 
>  wrote:
>   Hello,
> I always tought the operation attribute is inherited.
>
>
>  This is how everybody implements it, and what we intended (pre-4741).
> Otherwise, would a "replace" operation for some arbitrary subtree
> require nc:operation="replace" in every replacement descendant node?
>
>
> Andy
>
>
>  Well if the default-operation is unchanged, then
>
> 
>   
> 
>
> works perfectly fine if the operation for  is assumed to be a
> "merge". First, the server removes the existing , replaces it
> with empty one and then merges the  in.
>
>  From this point of view, "merge" on child is compatible with "create" or
> "replace" on parent.
>
> I don't see any sentence in the RFC which says that the operation is
> inherited.
>
>  RFC6243
>
>
>   With-defaults Capability for NETCONF may help clarify wh "effective
>   operation" means in an "edit-config":
>
>
>
>         4.5.2  .
>          Operation
>
> ...
>
> If the 'default' attribute is present, then the effective operation
>     for the target data node MUST be 'create', 'merge', or 'replace'.  If
>     not, then the server MUST return an  response with an
>     'invalid-value' error-tag.  For example, if 'create' is the effective
>     operation, then the create request must be valid on its own (e.g.,
>     current data node MUST NOT exist).  The procedure for determining the
>     effective operation is defined in [RFC6241   ].  I*t is derived from the
>     'default-operation' parameter and/or any operation attributes that
>     are present in the data node or any of its ancestor nodes, within the
>      request.*
>
> In other words the "operation" attribute has a "scope", that is, it applies
> to the nested nodes, until is is redefined. This is logical too.
>
>  side-note: not every netconf server must support with-defaults
> capability
>
>
> The point is not about whether a sever supports " with-defaults
> capability". The paragraph
> I quoted simply helps us see the  NETCONF protocol authors' intention.
>
>  It says that the operation is derived from default-operation and/or any
> operation attributes present.
>
>
> To be precise, RFC6243 says:
>
>  It is derived from the 'default-operation' parameter and/or any operation attributes that
>    are present in the data node or any of its ancestor nodes, within the
>     request.
>
> Notice the "ancestor nodes" wording.
>
>
>
>  Now RFC 6241 says:
>
>       default-operation:  Selects the default operation (as described in
>          the "operation" attribute) for this  request.  The
>          default value for the  parameter is "merge".
>
> so whenever a node does not have an operation attribute, this clause
> forces the server to operate as if it was "merge", if not set to other
> value.
>
>
> But if there is "operation" attribute specified in itself or any parent
> node then the effective
> operation is not "merge" anymore.
>
>   I think this is prevents any inheritance logic.
>
>
> I don't see why the sentence above prevents any inheritance.
>
> RFC6241 says:
>
>    operation:  Elements in the  subtree MAY contain an
>          "operation" attribute, which belongs to the NETCONF namespace
>          defined in Section 3.1 .  The attribute identifies the point in
>          the configuration to perform the operation and MAY appear on
>          multiple elements throughout the  subtree.
>
>
> Notice the "point" wording used here. In other words "operation" identifies
> a point (a subtree) where the config data should be applied. My understanding
> is that it does not make sense if the "point" means the "element" here.
>
> Perhaps it could be clearer if it were written as " the attribute identifies
> the point and below in the configuration...".
>
>

--Xiang
>
>
  --Xiang Li
>
>
>
>   Inherited in a sense that an XML element actually contains/includes all
> sub-elements under it. So creating/deleting/merging the element means
> creating/deleting/merging all its contents as well. So unless you later
> override this with more specific instructions for one of the contained
> elements it should be valid for the complete element with all its content.
>
> If operation is not inheritable we have some interesting cases:
> - your examples
> - default operation=none and I want to create a sizeable subtree. I have
> to place the merge/create operation on every node. Don't like it, makes
> none-unusable except for delete/remove.
> Lets say we have the following data model:
>
> routing
>    +--static-routing
>    |   +--route [routeId]
>    |        +--routeId 			ipprefix
>    |        +--path-to-destination 	[nexthop]
>    |            +--nextHop 		ipAddress
>    |            +--outgoingInterface   	string
>                 +--bfdActive		boolean
>
> I want to create a static route with all its sub-elements but only if the
> static-routing presence container exists (static routing is
> allowed/enabled).
> none
> 
>       --- this will check that static routing exists.
>          --this will create the interface
>           1.1.1.1/24   -- I don't want to put
> operation=create on all further nodes 5 times or more depending on the
> number of paths
>           
>              1.1.1.5
>              eth0
>              true
>           
>        
>     
> 
>
>   This was very nice and logical. I hope it still works.
> regards Balazs
>
> On 2014-07-29 14:17, Andy Bierman wrote:
>
>
>
>
> On Tue, Jul 29, 2014 at 12:44 AM, Klement Sekera -X (ksekera - Pantheon
> Technologies SRO at Cisco)   wrote:
>
>
>  On Mon, 2014-07-28 at 08:43 -0700, Andy Bierman wrote:
>
>  On Mon, Jul 28, 2014 at 8:31 AM, Klement Sekera -X (ksekera - Pantheon
> Technologies SRO at Cisco)   wrote:
>
>
>  On Mon, 2014-07-28 at 08:22 -0700, Andy Bierman wrote:
>
>  On Mon, Jul 28, 2014 at 8:11 AM, Klement Sekera -X (ksekera -
>
>   Pantheon
>
>   Technologies SRO at Cisco)   wrote:
>
>
>  Hi all,
>
> we are currently debating an issue we found and would like to
>
>   have some
>
>   clarification. Netconf RFC says that the edit-config operation
>
>   which
>
>   contains multiple sub-operations on the same data is undefined.
>
> so when considering this request:
>
> 
> 
> 
>   
>    
>   
> 
> 
>
> the outcome is undefined, since the client wants do delete
>
>   container
>
>   , while simultaneously creating  which is part of
> .
>
>
>
>  It is defined.
> Does the node /container exist in the target datastore?
> If yes, then the create operation on /container/leaf MUST fail.
> If no, then the delete operation on /container MUST fail.
>
>  what if /container exists but /container/leaf does not? this way both
> sub-operations could be performed
>
>
>  not really. If implemented correctly then if the delete on /container
> succeeds,
> then all its descendants are also deleted.  The result in the target
> datastore cannot
> possibly complete both a delete on an ancestor and create of a
>
>  descendant
>
>  in the same edit. Our server returns an error because it cannot honor
> both requests.
>
>
>  I believe that this is the part where
>
>        If the  operation contains multiple sub-operations
>        that apply to the same conceptual node in the underlying data
>        model, then the result of the operation is undefined (i.e.,
>        outside the scope of the NETCONF protocol).
>
> comes into play. Exactly as you say, target datastore cannot complete
> both the deletion and creation, since both operate on the same data but
> rule each other out.
>
>
>    Now, when considering a simple list deletion:
>
> 
> 
> 
>   
>    key-value
>   
> 
> 
>
> and rigorously reading the RFC regarding operation and
> default-operation, the operation attribute for  is
>
>   "merge",
>
>   thus, technically, this edit-config operation operates on the
>
>  
>
>  twice:
>
>
>  The operation is inherited from its parent if no "nc:operation"
> attribute is specified. The keys need to be present to specify the
>
>   list
>
>   node to be deleted.
>
>  can you point to the paragraph in netconf RFC which says that the
> operation is inherited?
>
>
>
>  the delete operation on the /container node is for the container and
>
>  all its
>
>  descendants.  That is how it is inherited. I should have said
>
>  "effective"
>
>  operation
> instead of "inherited".
>
>         operation:  Elements in the  subtree MAY contain an
>           "operation" attribute, which belongs to the NETCONF namespace
>           defined in Section 3.1.  The attribute identifies the point in
>           the configuration to perform the operation and MAY appear on
>           multiple elements throughout the  subtree.
>
>           If the "operation" attribute is not specified, the
>           configuration is merged into the configuration datastore.
>
> in this case, the "operation" attribute for  is not specified.
> So the provided example request is equivalent to this request:
>
> 
>   key-value
> 
>
> so basically it's the same as above - there is a request do delete
>  while creating and/or keeping  around - both cannot be
> done. I cannot find any exception in the RFC for list/key-node combo
> case.
>
>
>
>    Perhaps 1 new sentence (After the 1 about no attribute=merge):
>
>     If the operation attribute is not present for a key leaf node, and
>    the edit operation for the parent node is "delete" or "remove",
>    then the operation for the key leaf node is the same as its parent node.
>
>
>   Andy
>
>
>
>
>     1.) deleting the value via deletion of the list entity 
> 2.) merging in a new value via "merge" on the 
>
>
> The RFC has none in all
>
>   deletion
>
>   examples, which makes us believe that indeed when processing the
> mentioned request, the 's operation would be "merge"
>
>   and thus
>
>   the operation undefined.
>
> Is this how it's supposed to be or are we reading it wrong?
>
>
>
>  the latter
>
>
>
>  Thanks,
> Klement
> _______________________________________________
> Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf
>
>   Andy
>
>   _______________________________________________
> Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf
>
>
> --
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> ECN: 831 7320                        Tel: +36-1-437-7320
> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
>
>   _______________________________________________
> Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf
>
>  _______________________________________________
> Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf
>
>
> --
> --
> Xiang Li,
> Seguesoft, Champaign, IL
> (217) 721-5341
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>

--001a11c15c5003f49804ff5fc5f6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi,


I know the intent was that the operation attribute was for the ent=
ire sub-tree until explicitly


changed.

         If the "operation"=
 attribute is not specified, the
         configuration is merged into the configuration datastore.

The preceding text on page 37 is incomplete.
Look further down on page 38 (default-operation parameter)


         default-operation:  Selects the default operation (a=
s described in
         the "operation" attribute) for this <edit-config> =
request.  The
         default value for the <default-operation> parameter is "=
;merge".
=A0
Obviously the text on page 37 i=
s incomplete because the default-operation overrides "merge".


It is very common to use default-operation=3D"none" to=
 make sure the target resource already exists
when doing an updat=
e.

The text on page 37 needs to be updated somehow=
 (as errata).


I don't think we agree on the text yet, but here is an attempt

RFC 6241, sec 7.2, para 6:

O=
LD:

         If the "operation" attribute is not specified, the
         configuration is merged into the configuration datastore.


NEW:

        =
 If the "operation" attribute is not specified, then
         the operation applied to the parent data node of the configuration
         is used. If no parent data node is available, then the 'defaul=
t-operation' value is used.


 =
       
Andy



On Tue, Jul 29, 2014 at 9:41 AM, Xiang Li <xiangli=
@seguesoft.com> wrote:




 =20
   =20
 =20
  

    

    
On 7/29/2014 11:01 AM, Klement Sekera
      -X (ksekera - Pantheon Technologies SRO at Cisco) wrote:

    

    

      
On Tue, 2014-07-29 at 10:38 -0500, Xiang Li wrote:


      

        
On 7/29/2014 10:03 AM, Klement Sekera -X (ksekera - Pantheon=
=20
Technologies SRO at Cisco) wrote:


        

          
On Tue, 2014-07-29 at 07:54 -0700, Andy Bierman wrote:


          

            
On Tue, Jul 29, 2014 at 7:43 AM, Balazs Lengyel <balazs.lengyel@e=
ricsson.com


            

              
wrote:
  Hello,
I always tought the operation attribute is inherited.



            

            
This is how everybody implements it, and what we intended =
(pre-4741).
Otherwise, would a "replace" operation for some arbitrary subtree
require nc:operation=3D"replace" in every replacement descendant =
node?


Andy



          

          
Well if the default-operation is unchanged, then

<container operation=3D"replace">
  <leaf/>
</container>

works perfectly fine if the operation for <leaf> is assumed to be a
"merge". First, the server removes the existing <container>=
, replaces it
with empty one and then merges the <leaf> in.

 From this point of view, "merge" on child is compatible with &qu=
ot;create" or
"replace" on parent.

I don't see any sentence in the RFC which says that the operation is
inherited.


        

        
RFC6243


  With-defaults Capability for NETCONF may help clarify wh "effective
  operation" means in an "edit-config":



        4.5.2 <http://tools.ietf.org/html/rfc6243#section-4.5.2><=
/a>.
        <edit-config> Operation

...

If the 'default' attribute is present, then the effective operation
    for the target data node MUST be 'create', 'merge', or =
'replace'.  If
    not, then the server MUST return an <rpc-error> response with an
    'invalid-value' error-tag.  For example, if 'create' is=
 the effective
    operation, then the create request must be valid on its own (e.g.,
    current data node MUST NOT exist).  The procedure for determining the
    effective operation is defined in [RFC6241  <http://tools.ietf.org/html/rfc624=
1>].  I*t is derived from the
    'default-operation' parameter and/or any operation attributes t=
hat
    are present in the data node or any of its ancestor nodes, within the
    <edit-config> request.*

In other words the "operation" attribute has a "scope",=
 that is, it applies
to the nested nodes, until is is redefined. This is logical too.


      

      
side-note: not every netconf server must support with-defaults
capability

    

    

    The point is not about whether a sever supports " with-defaults
    capability". The paragraph

    I quoted simply helps us see the=A0 NETCONF protocol authors'
    intention.

    

    

      
It says that the operation is derived from default-operation and=
/or any
operation attributes present. 

    

    

    To be precise, RFC6243 says:

    

    
 It is derived from the 'default-operation' parameter and/or any op=
eration attributes that
   are present in the data node or any of its ancestor nodes, within the
   <edit-config> request.

Notice the "ancestor nodes" wording.



    

    

      
Now RFC 6241 says:

      default-operation:  Selects the default operation (as described in
         the "operation" attribute) for this <edit-config> =
request.  The
         default value for the <default-operation> parameter is "=
;merge".

so whenever a node does not have an operation attribute, this clause
forces the server to operate as if it was "merge", if not set to =
other
value.

    

    

    But if there is "operation" attribute specified in itself or =
any
    parent node then the effective

    operation is not "merge" anymore.

    

    

      
 I think this is prevents any inheritance logic.


    

    

    I don't see why the sentence above prevents any inheritance. 

    

    RFC6241 says:

    

    
   operation:  Elements in the <config> subtree MAY contain an
         "operation" attribute, which belongs to the NETCONF name=
space
         defined in Section 3.1.  The attribute identifies the point =
in
         the configuration to perform the operation and MAY appear on
         multiple elements throughout the <config> subtree.


Notice the "point" wording used here. In other words "operat=
ion" identifies
a point (a subtree) where the config data should be applied. My understandi=
ng
is that it does not make sense if the "point" means the "ele=
ment" here.=20

Perhaps it could be clearer if it were written as " the attribute iden=
tifies=20
the point and below in the configuration...".





--Xiang


    




    

      

      

        
--Xiang Li




        

          

            

            

              
Inherited in a sense that an XML element actually contai=
ns/includes all
sub-elements under it. So creating/deleting/merging the element means
creating/deleting/merging all its contents as well. So unless you later
override this with more specific instructions for one of the contained
elements it should be valid for the complete element with all its content.

If operation is not inheritable we have some interesting cases:
- your examples
- default operation=3Dnone and I want to create a sizeable subtree. I have
to place the merge/create operation on every node. Don't like it, makes
none-unusable except for delete/remove.
Lets say we have the following data model:

routing
   +--static-routing
   |   +--route [routeId]
   |        +--routeId 			ipprefix
   |        +--path-to-destination 	[nexthop]
   |            +--nextHop 		ipAddress
   |            +--outgoingInterface   	string
                +--bfdActive		boolean

I want to create a static route with all its sub-elements but only if the
static-routing presence container exists (static routing is
allowed/enabled).
<default-operation>none</default-operation>
<config>
    <static-routing>  --- this will check that static routing exists.
       <route operation=3D"create">  --this will create the=
 interface
          <routeid>1.=
1.1.1/24</routeid>   -- I don't want to put
operation=3Dcreate on all further nodes 5 times or more depending on the
number of paths
          <path-to-destination>
             <nextHop>1.1.1.5</nextHop>
             <outgoingInterface>eth0</outgoingInterface>
             <bfdActive>true</bfdActive>
          </path-to-destination>
       </route>
    </static-routing>
</config>

  This was very nice and logical. I hope it still works.
regards Balazs

On 2014-07-29 14:17, Andy Bierman wrote:




On Tue, Jul 29, 2014 at 12:44 AM, Klement Sekera -X (ksekera - Pantheon
Technologies SRO at Cisco) <ksekera@cisco.com> wrote:



              

                
On Mon, 2014-07-28 at 08:43 -0700, Andy Bierman wrote:


                

                  
On Mon, Jul 28, 2014 at 8:31 AM, Klement Sekera -X (=
ksekera - Pantheon
Technologies SRO at Cisco) <ksekera@cisco.com> wrote:



                  

                    
On Mon, 2014-07-28 at 08:22 -0700, Andy Bierman wr=
ote:


                    

                      
On Mon, Jul 28, 2014 at 8:11 AM, Klement Sekera =
-X (ksekera -


                    

                  

                

                
Pantheon


                

                  

                    

                      
Technologies SRO at Cisco) <ksekera@cisco.com> wrote:



                      

                        
Hi all,

we are currently debating an issue we found and would like to


                      

                    

                  

                

                
have some


                

                  

                    

                      

                        
clarification. Netconf RFC says that the edit-=
config operation


                      

                    

                  

                

                
which


                

                  

                    

                      

                        
contains multiple sub-operations on the same d=
ata is undefined.

so when considering this request:

<edit-config>
<target><candidate/></target>
<config>
  <container operation=3D"delete">
   <leaf operation=3D"create"/>
  </container>
</config>
</edit-config>

the outcome is undefined, since the client wants do delete


                      

                    

                  

                

                
container


                

                  

                    

                      

                        
<container>, while simultaneously creati=
ng <leaf> which is part of
<container>.




                      

                      
It is defined.
Does the node /container exist in the target datastore?
If yes, then the create operation on /container/leaf MUST fail.
If no, then the delete operation on /container MUST fail.


                    

                    
what if /container exists but /container/leaf does=
 not? this way both
sub-operations could be performed



                  

                  
not really. If implemented correctly then if the del=
ete on /container
succeeds,
then all its descendants are also deleted.  The result in the target
datastore cannot
possibly complete both a delete on an ancestor and create of a


                

                
descendant


                

                  
in the same edit. Our server returns an error becaus=
e it cannot honor
both requests.



                

                
I believe that this is the part where

       If the <edit-config> operation contains multiple sub-operation=
s
       that apply to the same conceptual node in the underlying data
       model, then the result of the operation is undefined (i.e.,
       outside the scope of the NETCONF protocol).

comes into play. Exactly as you say, target datastore cannot complete
both the deletion and creation, since both operate on the same data but
rule each other out.



                

                  

                  

                    

                      

                      

                        
Now, when considering a simple list deletion:

<edit-config>
<target><candidate/></target>
<config>
  <list operation=3D"delete">
   <key-node>key-value</key-node>
  </list>
</config>
</edit-config>

and rigorously reading the RFC regarding operation and
default-operation, the operation attribute for <key-node> is


                      

                    

                  

                

                
"merge",


                

                  

                    

                      

                        
thus, technically, this edit-config operation =
operates on the


                      

                    

                    
<key-node>


                    

                      

                        
twice:



                      

                      
The operation is inherited from its parent if no=
 "nc:operation"
attribute is specified. The keys need to be present to specify the


                    

                  

                

                
list


                

                  

                    

                      
node to be deleted.


                    

                    
can you point to the paragraph in netconf RFC whic=
h says that the
operation is inherited?




                  

                  
the delete operation on the /container node is for t=
he container and


                

                
all its


                

                  
descendants.  That is how it is inherited. I should =
have said


                

                
"effective"


                

                  
operation
instead of "inherited".


                

                
       operation:  Elements in the <config> subt=
ree MAY contain an
          "operation" attribute, which belongs to the NETCONF nam=
espace
          defined in Section 3.1.  The attribute identifies the point in
          the configuration to perform the operation and MAY appear on
          multiple elements throughout the <config> subtree.

          If the "operation" attribute is not specified, the
          configuration is merged into the configuration datastore.

in this case, the "operation" attribute for <key-node> is n=
ot specified.
So the provided example request is equivalent to this request:

<list operation=3D"delete">
  <key-node operation=3D"merge">key-value</key-node>
</list>

so basically it's the same as above - there is a request do delete
<list> while creating and/or keeping <key-node> around - both c=
annot be
done. I cannot find any exception in the RFC for list/key-node combo
case.




              

              
  Perhaps 1 new sentence (After the 1 about no attribute=
=3Dmerge):

    If the operation attribute is not present for a key leaf node, and
   the edit operation for the parent node is "delete" or "re=
move",
   then the operation for the key leaf node is the same as its parent node.


  Andy





              

                

                  

                  

                    

                      

                      

                        
1.) deleting the value via deletion of the lis=
t entity <list>
2.) merging in a new value via "merge" on the <key-node>


The RFC has <default-operation>none</default-operation> in all


                      

                    

                  

                

                
deletion


                

                  

                    

                      

                        
examples, which makes us believe that indeed w=
hen processing the
mentioned request, the <key-node>'s operation would be "merg=
e"


                      

                    

                  

                

                
and thus


                

                  

                    

                      

                        
the operation undefined.

Is this how it's supposed to be or are we reading it wrong?




                      

                      
the latter




                      

                        
Thanks,
Klement
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf



                      

                    

                    

                  

                  
Andy


                

                

              

              
_______________________________________________
Netconf mailing listNetconf@ietf.orghttps://www=
.ietf.org/mailman/listinfo/netconf


--
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com




            

          

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


        

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


      

      

    

    

    
--=20
--
Xiang Li,=20
Seguesoft, Champaign, IL
(217) 721-5341


  



_______________________________________________

Netconf mailing list

Netconf@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/netconf





--001a11c15c5003f49804ff5fc5f6--


From nobody Wed Jul 30 00:28:24 2014
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257821ABB2B for ; Wed, 30 Jul 2014 00:28:22 -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, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 4GPyqU3fOVPB for ; Wed, 30 Jul 2014 00:28:16 -0700 (PDT)
Received: from p3plsmtpa09-09.prod.phx3.secureserver.net (p3plsmtpa09-09.prod.phx3.secureserver.net [173.201.193.238]) by ietfa.amsl.com (Postfix) with ESMTP id CA6AB1B2973 for ; Wed, 30 Jul 2014 00:28:15 -0700 (PDT)
Received: from [192.168.2.3] ([50.179.41.78]) by p3plsmtpa09-09.prod.phx3.secureserver.net with  id YXUD1o0091hB5UJ01XUDxX; Wed, 30 Jul 2014 00:28:15 -0700
Message-ID: <53D89E87.6000203@seguesoft.com>
Date: Wed, 30 Jul 2014 02:28:07 -0500
From: Xiang Li 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Andy Bierman 
References: <1406560309.12287.21.camel@ksekera-fedora>		<1406561507.12287.24.camel@ksekera-fedora>		<1406619859.12287.31.camel@ksekera-fedora>		<53D7B316.8020903@ericsson.com>		<1406646178.21825.6.camel@ksekera-fedora>	<53D7BFE2.9080003@seguesoft.com>	<1406649697.21825.11.camel@ksekera-fedora>	<53D7CEC0.4020300@seguesoft.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050100060602090206060609"
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/RTi00goBwivAlYbvWuRvZt0oSSw
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] edit-config operation inconsistency
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 07:28:22 -0000

This is a multi-part message in MIME format.
--------------050100060602090206060609
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


> The text on page 37 needs to be updated somehow (as errata).
> I don't think we agree on the text yet, but here is an attempt
>
> RFC 6241, sec 7.2, para 6:
>
> OLD:
>
>           If the "operation" attribute is not specified, the
>           configuration is merged into the configuration datastore.
>
>
> NEW:
>
>           If the "operation" attribute is not specified, then
>           the operation applied to the parent data node of the configuration
>           is used.If no parent data node is available, then the 'default-operation'value is used.

Adding this as an erratum would help clarify issue but it isn't 
absolutely needed, IMO. My
understanding is that this  is how XML attribute is supposed to work.  
For example,  you
don't need to specify XML namespace attribute on each element. The way 
the "operation"
implicitly inherits from parent is exactly the same as child elements 
inherit  their "namespace"
  attributes their parent nodes.

--Xiang

>          
> Andy
>
>
>
> On Tue, Jul 29, 2014 at 9:41 AM, Xiang Li  > wrote:
>
>
>     On 7/29/2014 11:01 AM, Klement Sekera -X (ksekera - Pantheon
>     Technologies SRO at Cisco) wrote:
>>     On Tue, 2014-07-29 at 10:38 -0500, Xiang Li wrote:
>>>     On 7/29/2014 10:03 AM, Klement Sekera -X (ksekera - Pantheon
>>>     Technologies SRO at Cisco) wrote:
>>>>     On Tue, 2014-07-29 at 07:54 -0700, Andy Bierman wrote:
>>>>>     On Tue, Jul 29, 2014 at 7:43 AM, Balazs Lengyel 
>>>>>>     wrote:
>>>>>>        Hello,
>>>>>>     I always tought the operation attribute is inherited.
>>>>>>
>>>>>     This is how everybody implements it, and what we intended (pre-4741).
>>>>>     Otherwise, would a "replace" operation for some arbitrary subtree
>>>>>     require nc:operation="replace" in every replacement descendant node?
>>>>>
>>>>>
>>>>>     Andy
>>>>>
>>>>     Well if the default-operation is unchanged, then
>>>>
>>>>     
>>>>        
>>>>     
>>>>
>>>>     works perfectly fine if the operation for  is assumed to be a
>>>>     "merge". First, the server removes the existing , replaces it
>>>>     with empty one and then merges the  in.
>>>>
>>>>       From this point of view, "merge" on child is compatible with "create" or
>>>>     "replace" on parent.
>>>>
>>>>     I don't see any sentence in the RFC which says that the operation is
>>>>     inherited.
>>>     RFC6243
>>>
>>>
>>>        With-defaults Capability for NETCONF may help clarify wh "effective
>>>        operation" means in an "edit-config":
>>>
>>>
>>>
>>>              4.5.2  .
>>>               Operation
>>>
>>>     ...
>>>
>>>     If the 'default' attribute is present, then the effective operation
>>>          for the target data node MUST be 'create', 'merge', or 'replace'.  If
>>>          not, then the server MUST return an  response with an
>>>          'invalid-value' error-tag.  For example, if 'create' is the effective
>>>          operation, then the create request must be valid on its own (e.g.,
>>>          current data node MUST NOT exist).  The procedure for determining the
>>>          effective operation is defined in [RFC6241  ].  I*t is derived from the
>>>          'default-operation' parameter and/or any operation attributes that
>>>          are present in the data node or any of its ancestor nodes, within the
>>>           request.*
>>>
>>>     In other words the "operation" attribute has a "scope", that is, it applies
>>>     to the nested nodes, until is is redefined. This is logical too.
>>     side-note: not every netconf server must support with-defaults
>>     capability
>
>     The point is not about whether a sever supports " with-defaults
>     capability". The paragraph
>     I quoted simply helps us see the  NETCONF protocol authors' intention.
>
>>     It says that the operation is derived from default-operation and/or any
>>     operation attributes present.
>
>     To be precise, RFC6243 says:
>
>       It is derived from the 'default-operation' parameter and/or any operation attributes that
>         are present in the data node or any of its ancestor nodes, within the
>          request.
>
>     Notice the "ancestor nodes" wording.
>
>
>>     Now RFC 6241 says:
>>
>>            default-operation:  Selects the default operation (as described in
>>               the "operation" attribute) for this  request.  The
>>               default value for the  parameter is "merge".
>>
>>     so whenever a node does not have an operation attribute, this clause
>>     forces the server to operate as if it was "merge", if not set to other
>>     value.
>
>     But if there is "operation" attribute specified in itself or any
>     parent node then the effective
>     operation is not "merge" anymore.
>
>>       I think this is prevents any inheritance logic.
>
>     I don't see why the sentence above prevents any inheritance.
>
>     RFC6241 says:
>
>         operation:  Elements in the  subtree MAY contain an
>               "operation" attribute, which belongs to the NETCONF namespace
>               defined inSection 3.1  .  The attribute identifies the point in
>               the configuration to perform the operation and MAY appear on
>               multiple elements throughout the  subtree.
>
>
>     Notice the "point" wording used here. In other words "operation" identifies
>     a point (a subtree) where the config data should be applied. My understanding
>     is that it does not make sense if the "point" means the "element" here.
>
>     Perhaps it could be clearer if it were written as " the attribute identifies
>     the point and below in the configuration...".
>
>
>
>     --Xiang
>
>
>>>     --Xiang Li
>>>
>>>
>>>>>>     Inherited in a sense that an XML element actually contains/includes all
>>>>>>     sub-elements under it. So creating/deleting/merging the element means
>>>>>>     creating/deleting/merging all its contents as well. So unless you later
>>>>>>     override this with more specific instructions for one of the contained
>>>>>>     elements it should be valid for the complete element with all its content.
>>>>>>
>>>>>>     If operation is not inheritable we have some interesting cases:
>>>>>>     - your examples
>>>>>>     - default operation=none and I want to create a sizeable subtree. I have
>>>>>>     to place the merge/create operation on every node. Don't like it, makes
>>>>>>     none-unusable except for delete/remove.
>>>>>>     Lets say we have the following data model:
>>>>>>
>>>>>>     routing
>>>>>>         +--static-routing
>>>>>>         |   +--route [routeId]
>>>>>>         |        +--routeId 			ipprefix
>>>>>>         |        +--path-to-destination 	[nexthop]
>>>>>>         |            +--nextHop 		ipAddress
>>>>>>         |            +--outgoingInterface   	string
>>>>>>                      +--bfdActive		boolean
>>>>>>
>>>>>>     I want to create a static route with all its sub-elements but only if the
>>>>>>     static-routing presence container exists (static routing is
>>>>>>     allowed/enabled).
>>>>>>     none
>>>>>>     
>>>>>>            --- this will check that static routing exists.
>>>>>>               --this will create the interface
>>>>>>                1.1.1.1/24     -- I don't want to put
>>>>>>     operation=create on all further nodes 5 times or more depending on the
>>>>>>     number of paths
>>>>>>                
>>>>>>                   1.1.1.5
>>>>>>                   eth0
>>>>>>                   true
>>>>>>                
>>>>>>             
>>>>>>          
>>>>>>     
>>>>>>
>>>>>>        This was very nice and logical. I hope it still works.
>>>>>>     regards Balazs
>>>>>>
>>>>>>     On 2014-07-29 14:17, Andy Bierman wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>     On Tue, Jul 29, 2014 at 12:44 AM, Klement Sekera -X (ksekera - Pantheon
>>>>>>     Technologies SRO at Cisco)    wrote:
>>>>>>
>>>>>>>     On Mon, 2014-07-28 at 08:43 -0700, Andy Bierman wrote:
>>>>>>>>     On Mon, Jul 28, 2014 at 8:31 AM, Klement Sekera -X (ksekera - Pantheon
>>>>>>>>     Technologies SRO at Cisco)    wrote:
>>>>>>>>
>>>>>>>>>     On Mon, 2014-07-28 at 08:22 -0700, Andy Bierman wrote:
>>>>>>>>>>     On Mon, Jul 28, 2014 at 8:11 AM, Klement Sekera -X (ksekera -
>>>>>>>     Pantheon
>>>>>>>>>>     Technologies SRO at Cisco)    wrote:
>>>>>>>>>>
>>>>>>>>>>>     Hi all,
>>>>>>>>>>>
>>>>>>>>>>>     we are currently debating an issue we found and would like to
>>>>>>>     have some
>>>>>>>>>>>     clarification. Netconf RFC says that the edit-config operation
>>>>>>>     which
>>>>>>>>>>>     contains multiple sub-operations on the same data is undefined.
>>>>>>>>>>>
>>>>>>>>>>>     so when considering this request:
>>>>>>>>>>>
>>>>>>>>>>>     
>>>>>>>>>>>     
>>>>>>>>>>>     
>>>>>>>>>>>        
>>>>>>>>>>>         
>>>>>>>>>>>        
>>>>>>>>>>>     
>>>>>>>>>>>     
>>>>>>>>>>>
>>>>>>>>>>>     the outcome is undefined, since the client wants do delete
>>>>>>>     container
>>>>>>>>>>>     , while simultaneously creating  which is part of
>>>>>>>>>>>     .
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>     It is defined.
>>>>>>>>>>     Does the node /container exist in the target datastore?
>>>>>>>>>>     If yes, then the create operation on /container/leaf MUST fail.
>>>>>>>>>>     If no, then the delete operation on /container MUST fail.
>>>>>>>>>     what if /container exists but /container/leaf does not? this way both
>>>>>>>>>     sub-operations could be performed
>>>>>>>>>
>>>>>>>>     not really. If implemented correctly then if the delete on /container
>>>>>>>>     succeeds,
>>>>>>>>     then all its descendants are also deleted.  The result in the target
>>>>>>>>     datastore cannot
>>>>>>>>     possibly complete both a delete on an ancestor and create of a
>>>>>>>     descendant
>>>>>>>>     in the same edit. Our server returns an error because it cannot honor
>>>>>>>>     both requests.
>>>>>>>>
>>>>>>>     I believe that this is the part where
>>>>>>>
>>>>>>>             If the  operation contains multiple sub-operations
>>>>>>>             that apply to the same conceptual node in the underlying data
>>>>>>>             model, then the result of the operation is undefined (i.e.,
>>>>>>>             outside the scope of the NETCONF protocol).
>>>>>>>
>>>>>>>     comes into play. Exactly as you say, target datastore cannot complete
>>>>>>>     both the deletion and creation, since both operate on the same data but
>>>>>>>     rule each other out.
>>>>>>>
>>>>>>>>>>>     Now, when considering a simple list deletion:
>>>>>>>>>>>
>>>>>>>>>>>     
>>>>>>>>>>>     
>>>>>>>>>>>     
>>>>>>>>>>>        
>>>>>>>>>>>         key-value
>>>>>>>>>>>        
>>>>>>>>>>>     
>>>>>>>>>>>     
>>>>>>>>>>>
>>>>>>>>>>>     and rigorously reading the RFC regarding operation and
>>>>>>>>>>>     default-operation, the operation attribute for  is
>>>>>>>     "merge",
>>>>>>>>>>>     thus, technically, this edit-config operation operates on the
>>>>>>>>>     
>>>>>>>>>>>     twice:
>>>>>>>>>>>
>>>>>>>>>>     The operation is inherited from its parent if no "nc:operation"
>>>>>>>>>>     attribute is specified. The keys need to be present to specify the
>>>>>>>     list
>>>>>>>>>>     node to be deleted.
>>>>>>>>>     can you point to the paragraph in netconf RFC which says that the
>>>>>>>>>     operation is inherited?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>     the delete operation on the /container node is for the container and
>>>>>>>     all its
>>>>>>>>     descendants.  That is how it is inherited. I should have said
>>>>>>>     "effective"
>>>>>>>>     operation
>>>>>>>>     instead of "inherited".
>>>>>>>             operation:  Elements in the  subtree MAY contain an
>>>>>>>                "operation" attribute, which belongs to the NETCONF namespace
>>>>>>>                defined in Section 3.1.  The attribute identifies the point in
>>>>>>>                the configuration to perform the operation and MAY appear on
>>>>>>>                multiple elements throughout the  subtree.
>>>>>>>
>>>>>>>                If the "operation" attribute is not specified, the
>>>>>>>                configuration is merged into the configuration datastore.
>>>>>>>
>>>>>>>     in this case, the "operation" attribute for  is not specified.
>>>>>>>     So the provided example request is equivalent to this request:
>>>>>>>
>>>>>>>     
>>>>>>>        key-value
>>>>>>>     
>>>>>>>
>>>>>>>     so basically it's the same as above - there is a request do delete
>>>>>>>      while creating and/or keeping  around - both cannot be
>>>>>>>     done. I cannot find any exception in the RFC for list/key-node combo
>>>>>>>     case.
>>>>>>>
>>>>>>>
>>>>>>        Perhaps 1 new sentence (After the 1 about no attribute=merge):
>>>>>>
>>>>>>          If the operation attribute is not present for a key leaf node, and
>>>>>>         the edit operation for the parent node is "delete" or "remove",
>>>>>>         then the operation for the key leaf node is the same as its parent node.
>>>>>>
>>>>>>
>>>>>>        Andy
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>     1.) deleting the value via deletion of the list entity 
>>>>>>>>>>>     2.) merging in a new value via "merge" on the 
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>     The RFC has none in all
>>>>>>>     deletion
>>>>>>>>>>>     examples, which makes us believe that indeed when processing the
>>>>>>>>>>>     mentioned request, the 's operation would be "merge"
>>>>>>>     and thus
>>>>>>>>>>>     the operation undefined.
>>>>>>>>>>>
>>>>>>>>>>>     Is this how it's supposed to be or are we reading it wrong?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>     the latter
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>     Thanks,
>>>>>>>>>>>     Klement
>>>>>>>>>>>     _______________________________________________
>>>>>>>>>>>     Netconf mailing list
>>>>>>>>>>>     Netconf@ietf.org  
>>>>>>>>>>>     https://www.ietf.org/mailman/listinfo/netconf
>>>>>>>>>>>
>>>>>>>>     Andy
>>>>>>     _______________________________________________
>>>>>>     Netconf mailinglistNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf  
>>>>>>
>>>>>>
>>>>>>     --
>>>>>>     Balazs Lengyel                       Ericsson Hungary Ltd.
>>>>>>     Senior Specialist
>>>>>>     ECN: 831 7320                        Tel: +36-1-437-7320
>>>>>>     Mobile: +36-70-330-7909              email:Balazs.Lengyel@ericsson.com  
>>>>>>
>>>>>>
>>>>     _______________________________________________
>>>>     Netconf mailing list
>>>>     Netconf@ietf.org  
>>>>     https://www.ietf.org/mailman/listinfo/netconf
>>>     _______________________________________________
>>>     Netconf mailing list
>>>     Netconf@ietf.org  
>>>     https://www.ietf.org/mailman/listinfo/netconf
>
>     -- 
>     --
>     Xiang Li,
>     Seguesoft, Champaign, IL
>     (217) 721-5341
>
>
>     _______________________________________________
>     Netconf mailing list
>     Netconf@ietf.org 
>     https://www.ietf.org/mailman/listinfo/netconf
>
>

-- 
--
Xiang Li,
Seguesoft, Champaign, IL
(217) 721-5341


--------------050100060602090206060609
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    

      

        

          
The text on page 37 needs to be updated somehow (as
            errata).

          
I don't think we agree on the text yet, but here is an
            attempt

          


          

          
RFC 6241, sec 7.2, para 6:

          


          

          
OLD:

          


          

          

            
         If the "operation" attribute is not specified, the
         configuration is merged into the configuration datastore.

          

          


          

          


          

          
NEW:

          


          

          

            
         If the "operation" attribute is not specified, then
         the operation applied to the parent data node of the configuration
         is used. If no parent data node is available, then the 'default-operation' value is used.

          

        

      

    

    

    Adding this as an erratum would help clarify issue but it isn't
    absolutely needed, IMO. My 

    understanding is that this  is how XML attribute is supposed to
    work.  For example,  you 

    don't need to specify XML namespace attribute on each element. The
    way the "operation"

    implicitly inherits from parent is exactly the same as child
    elements inherit  their "namespace"

     attributes their parent nodes.

    

    --Xiang

    

    

      

        

          

            
        

          

          
Andy

          


          

          


          

          

          
On Tue, Jul 29, 2014 at 9:41 AM,
            Xiang Li <xiangli@seguesoft.com>
            wrote:

            

              
 

                
On 7/29/2014 11:01 AM, Klement Sekera -X (ksekera -
                  Pantheon Technologies SRO at Cisco) wrote:

                

                

                  
On Tue, 2014-07-29 at 10:38 -0500, Xiang Li wrote:


                  

                    
On 7/29/2014 10:03 AM, Klement Sekera -X (ksekera - Pantheon 
Technologies SRO at Cisco) wrote:


                    

                      
On Tue, 2014-07-29 at 07:54 -0700, Andy Bierman wrote:


                      

                        
On Tue, Jul 29, 2014 at 7:43 AM, Balazs Lengyel <balazs.lengyel@ericsson.com


                        

                          
wrote:
  Hello,
I always tought the operation attribute is inherited.



                        

                        
This is how everybody implements it, and what we intended (pre-4741).
Otherwise, would a "replace" operation for some arbitrary subtree
require nc:operation="replace" in every replacement descendant node?


Andy



                      

                      
Well if the default-operation is unchanged, then

<container operation="replace">
  <leaf/>
</container>

works perfectly fine if the operation for <leaf> is assumed to be a
"merge". First, the server removes the existing <container>, replaces it
with empty one and then merges the <leaf> in.

 From this point of view, "merge" on child is compatible with "create" or
"replace" on parent.

I don't see any sentence in the RFC which says that the operation is
inherited.


                    

                    
RFC6243


  With-defaults Capability for NETCONF may help clarify wh "effective
  operation" means in an "edit-config":



        4.5.2 <http://tools.ietf.org/html/rfc6243#section-4.5.2>.
        <edit-config> Operation

...

If the 'default' attribute is present, then the effective operation
    for the target data node MUST be 'create', 'merge', or 'replace'.  If
    not, then the server MUST return an <rpc-error> response with an
    'invalid-value' error-tag.  For example, if 'create' is the effective
    operation, then the create request must be valid on its own (e.g.,
    current data node MUST NOT exist).  The procedure for determining the
    effective operation is defined in [RFC6241  <http://tools.ietf.org/html/rfc6241>].  I*t is derived from the
    'default-operation' parameter and/or any operation attributes that
    are present in the data node or any of its ancestor nodes, within the
    <edit-config> request.*

In other words the "operation" attribute has a "scope", that is, it applies
to the nested nodes, until is is redefined. This is logical too.


                  

                  
side-note: not every netconf server must support with-defaults
capability

                

                

                The point is not about whether a sever supports "
                with-defaults capability". The paragraph

                I quoted simply helps us see the  NETCONF protocol
                authors' intention.

                

                

                  
It says that the operation is derived from default-operation and/or any
operation attributes present. 

                

                

                To be precise, RFC6243 says:

                

                
 It is derived from the 'default-operation' parameter and/or any operation attributes that
   are present in the data node or any of its ancestor nodes, within the
   <edit-config> request.

Notice the "ancestor nodes" wording.



                

                

                  
Now RFC 6241 says:

      default-operation:  Selects the default operation (as described in
         the "operation" attribute) for this <edit-config> request.  The
         default value for the <default-operation> parameter is "merge".

so whenever a node does not have an operation attribute, this clause
forces the server to operate as if it was "merge", if not set to other
value.

                

                

                But if there is "operation" attribute specified in
                itself or any parent node then the effective

                operation is not "merge" anymore.

                

                

                  
 I think this is prevents any inheritance logic.


                

                

                I don't see why the sentence above prevents any
                inheritance. 

                

                RFC6241 says:

                

                
   operation:  Elements in the <config> subtree MAY contain an
         "operation" attribute, which belongs to the NETCONF namespace
         defined in Section 3.1.  The attribute identifies the point in
         the configuration to perform the operation and MAY appear on
         multiple elements throughout the <config> subtree.


Notice the "point" wording used here. In other words "operation" identifies
a point (a subtree) where the config data should be applied. My understanding
is that it does not make sense if the "point" means the "element" here. 

Perhaps it could be clearer if it were written as " the attribute identifies 
the point and below in the configuration...".


              

            

            


            

            


            

            

              

                
--Xiang


              

            

            


            

            

              

                

                  

                    
--Xiang Li




                    

                      

                        

                          
Inherited in a sense that an XML element actually contains/includes all
sub-elements under it. So creating/deleting/merging the element means
creating/deleting/merging all its contents as well. So unless you later
override this with more specific instructions for one of the contained
elements it should be valid for the complete element with all its content.

If operation is not inheritable we have some interesting cases:
- your examples
- default operation=none and I want to create a sizeable subtree. I have
to place the merge/create operation on every node. Don't like it, makes
none-unusable except for delete/remove.
Lets say we have the following data model:

routing
   +--static-routing
   |   +--route [routeId]
   |        +--routeId 			ipprefix
   |        +--path-to-destination 	[nexthop]
   |            +--nextHop 		ipAddress
   |            +--outgoingInterface   	string
                +--bfdActive		boolean

I want to create a static route with all its sub-elements but only if the
static-routing presence container exists (static routing is
allowed/enabled).
<default-operation>none</default-operation>
<config>
    <static-routing>  --- this will check that static routing exists.
       <route operation="create">  --this will create the interface
          <routeid>1.1.1.1/24</routeid>   -- I don't want to put
operation=create on all further nodes 5 times or more depending on the
number of paths
          <path-to-destination>
             <nextHop>1.1.1.5</nextHop>
             <outgoingInterface>eth0</outgoingInterface>
             <bfdActive>true</bfdActive>
          </path-to-destination>
       </route>
    </static-routing>
</config>

  This was very nice and logical. I hope it still works.
regards Balazs

On 2014-07-29 14:17, Andy Bierman wrote:




On Tue, Jul 29, 2014 at 12:44 AM, Klement Sekera -X (ksekera - Pantheon
Technologies SRO at Cisco) <ksekera@cisco.com> wrote:



                          

                            
On Mon, 2014-07-28 at 08:43 -0700, Andy Bierman wrote:


                            

                              
On Mon, Jul 28, 2014 at 8:31 AM, Klement Sekera -X (ksekera - Pantheon
Technologies SRO at Cisco) <ksekera@cisco.com> wrote:



                              

                                
On Mon, 2014-07-28 at 08:22 -0700, Andy Bierman wrote:


                                

                                  
On Mon, Jul 28, 2014 at 8:11 AM, Klement Sekera -X (ksekera -


                                

                              

                            

                            
Pantheon


                            

                              

                                

                                  
Technologies SRO at Cisco) <ksekera@cisco.com> wrote:



                                  

                                    
Hi all,

we are currently debating an issue we found and would like to


                                  

                                

                              

                            

                            
have some


                            

                              

                                

                                  

                                    
clarification. Netconf RFC says that the edit-config operation


                                  

                                

                              

                            

                            
which


                            

                              

                                

                                  

                                    
contains multiple sub-operations on the same data is undefined.

so when considering this request:

<edit-config>
<target><candidate/></target>
<config>
  <container operation="delete">
   <leaf operation="create"/>
  </container>
</config>
</edit-config>

the outcome is undefined, since the client wants do delete


                                  

                                

                              

                            

                            
container


                            

                              

                                

                                  

                                    
<container>, while simultaneously creating <leaf> which is part of
<container>.




                                  

                                  
It is defined.
Does the node /container exist in the target datastore?
If yes, then the create operation on /container/leaf MUST fail.
If no, then the delete operation on /container MUST fail.


                                

                                
what if /container exists but /container/leaf does not? this way both
sub-operations could be performed



                              

                              
not really. If implemented correctly then if the delete on /container
succeeds,
then all its descendants are also deleted.  The result in the target
datastore cannot
possibly complete both a delete on an ancestor and create of a


                            

                            
descendant


                            

                              
in the same edit. Our server returns an error because it cannot honor
both requests.



                            

                            
I believe that this is the part where

       If the <edit-config> operation contains multiple sub-operations
       that apply to the same conceptual node in the underlying data
       model, then the result of the operation is undefined (i.e.,
       outside the scope of the NETCONF protocol).

comes into play. Exactly as you say, target datastore cannot complete
both the deletion and creation, since both operate on the same data but
rule each other out.



                            

                              

                                

                                  

                                    
Now, when considering a simple list deletion:

<edit-config>
<target><candidate/></target>
<config>
  <list operation="delete">
   <key-node>key-value</key-node>
  </list>
</config>
</edit-config>

and rigorously reading the RFC regarding operation and
default-operation, the operation attribute for <key-node> is


                                  

                                

                              

                            

                            
"merge",


                            

                              

                                

                                  

                                    
thus, technically, this edit-config operation operates on the


                                  

                                

                                
<key-node>


                                

                                  

                                    
twice:



                                  

                                  
The operation is inherited from its parent if no "nc:operation"
attribute is specified. The keys need to be present to specify the


                                

                              

                            

                            
list


                            

                              

                                

                                  
node to be deleted.


                                

                                
can you point to the paragraph in netconf RFC which says that the
operation is inherited?




                              

                              
the delete operation on the /container node is for the container and


                            

                            
all its


                            

                              
descendants.  That is how it is inherited. I should have said


                            

                            
"effective"


                            

                              
operation
instead of "inherited".


                            

                            
       operation:  Elements in the <config> subtree MAY contain an
          "operation" attribute, which belongs to the NETCONF namespace
          defined in Section 3.1.  The attribute identifies the point in
          the configuration to perform the operation and MAY appear on
          multiple elements throughout the <config> subtree.

          If the "operation" attribute is not specified, the
          configuration is merged into the configuration datastore.

in this case, the "operation" attribute for <key-node> is not specified.
So the provided example request is equivalent to this request:

<list operation="delete">
  <key-node operation="merge">key-value</key-node>
</list>

so basically it's the same as above - there is a request do delete
<list> while creating and/or keeping <key-node> around - both cannot be
done. I cannot find any exception in the RFC for list/key-node combo
case.




                          

                          
  Perhaps 1 new sentence (After the 1 about no attribute=merge):

    If the operation attribute is not present for a key leaf node, and
   the edit operation for the parent node is "delete" or "remove",
   then the operation for the key leaf node is the same as its parent node.


  Andy





                          

                            

                              

                                

                                  

                                    
1.) deleting the value via deletion of the list entity <list>
2.) merging in a new value via "merge" on the <key-node>


The RFC has <default-operation>none</default-operation> in all


                                  

                                

                              

                            

                            
deletion


                            

                              

                                

                                  

                                    
examples, which makes us believe that indeed when processing the
mentioned request, the <key-node>'s operation would be "merge"


                                  

                                

                              

                            

                            
and thus


                            

                              

                                

                                  

                                    
the operation undefined.

Is this how it's supposed to be or are we reading it wrong?




                                  

                                  
the latter




                                  

                                    
Thanks,
Klement
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf



                                  

                                

                              

                              
Andy


                            

                          

                          
_______________________________________________
Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf


--
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com




                        

                      

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


                    

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


                  

                   

                 

                    
-- 
--
Xiang Li, 
Seguesoft, Champaign, IL
(217) 721-5341


                  

              

              _______________________________________________

              Netconf mailing list

              Netconf@ietf.org

              https://www.ietf.org/mailman/listinfo/netconf

              

            

          

          

        

      

    

    

    
-- 
--
Xiang Li, 
Seguesoft, Champaign, IL
(217) 721-5341


  


--------------050100060602090206060609--


From nobody Wed Jul 30 01:59:39 2014
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7DD1B2A2A for ; Wed, 30 Jul 2014 01:59:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 UFXAM6fek1Yl for ; Wed, 30 Jul 2014 01:59:26 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AAA81A00C5 for ; Wed, 30 Jul 2014 01:59:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24566; q=dns/txt; s=iport; t=1406710766; x=1407920366; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9yjPj/GdYTIlSISTzaEVJr3fsBoUZIeQENeX734kL9Q=; b=gKP6BbhK6P7QL24SVIKlZH4YAFiPuE8pwKs0VnW0tGwQJGbDNsNvoxPS 3bgfFozj3n7dtJoh+cXgWRJpUBHUQR52k40zJ57Bwf6wLFy5zzferBRQ7 bv8LulrEYSS/eeGojQ5XDpjP8J5HVxwIU1xNLV/c+8wAR5np0g/i/cRVp I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkIFAGuz2FOtJV2R/2dsb2JhbABWA4MOUlcEgnSvepg1CoZ4UwEZKE0Wd4QDAQEBAwEBAQEgERcBIgsQAgEIEwUCAiMDAgICIwILFAEQAgQOBQmIMQgNqAqGCAGRYxeBLItjgVkCEQEdGAsQBxGCaIFRBZV+hyiMXIYig0lsAQGBAQkXIg
X-IronPort-AV: E=Sophos;i="5.01,763,1400025600"; d="scan'208";a="65109915"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-7.cisco.com with ESMTP; 30 Jul 2014 08:59:25 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6U8xPUH014236 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Jul 2014 08:59:25 GMT
Received: from xmb-rcd-x13.cisco.com ([169.254.3.17]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Wed, 30 Jul 2014 03:59:24 -0500
From: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" 
To: "xiangli@seguesoft.com" 
Thread-Topic: [Netconf] edit-config operation inconsistency
Thread-Index: AQHPqnZB7zgA6VWc9UyRPcHJnzYLfZu17mwAgAACj4CAAAMtgIABDIyAgABMcgCAACixAIAAAzCAgAACOwCAAAnWAIAABo2AgAALLACAAKEigIAAVo+AgAAZgIA=
Date: Wed, 30 Jul 2014 08:59:23 +0000
Message-ID: <1406710763.5771.1.camel@ksekera-fedora>
References: <1406560309.12287.21.camel@ksekera-fedora>  <1406561507.12287.24.camel@ksekera-fedora>  <1406619859.12287.31.camel@ksekera-fedora>  <53D7B316.8020903@ericsson.com>  <1406646178.21825.6.camel@ksekera-fedora>	<53D7BFE2.9080003@seguesoft.com> <1406649697.21825.11.camel@ksekera-fedora>	<53D7CEC0.4020300@seguesoft.com>  <53D89E87.6000203@seguesoft.com>
In-Reply-To: <53D89E87.6000203@seguesoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.195.252]
Content-Type: text/plain; charset="utf-8"
Content-ID: <118CF95B9674CE42AEAEE435754ACF0C@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/MJB_aWK4M94HRzCIOVK9BM9egxc
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] edit-config operation inconsistency
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 08:59:34 -0000

T24gV2VkLCAyMDE0LTA3LTMwIGF0IDAyOjI4IC0wNTAwLCBYaWFuZyBMaSB3cm90ZToNCj4gPiBU
aGUgdGV4dCBvbiBwYWdlIDM3IG5lZWRzIHRvIGJlIHVwZGF0ZWQgc29tZWhvdyAoYXMgZXJyYXRh
KS4NCj4gPiBJIGRvbid0IHRoaW5rIHdlIGFncmVlIG9uIHRoZSB0ZXh0IHlldCwgYnV0IGhlcmUg
aXMgYW4gYXR0ZW1wdA0KPiA+DQo+ID4gUkZDIDYyNDEsIHNlYyA3LjIsIHBhcmEgNjoNCj4gPg0K
PiA+IE9MRDoNCj4gPg0KPiA+ICAgICAgICAgICBJZiB0aGUgIm9wZXJhdGlvbiIgYXR0cmlidXRl
IGlzIG5vdCBzcGVjaWZpZWQsIHRoZQ0KPiA+ICAgICAgICAgICBjb25maWd1cmF0aW9uIGlzIG1l
cmdlZCBpbnRvIHRoZSBjb25maWd1cmF0aW9uIGRhdGFzdG9yZS4NCj4gPg0KPiA+DQo+ID4gTkVX
Og0KPiA+DQo+ID4gICAgICAgICAgIElmIHRoZSAib3BlcmF0aW9uIiBhdHRyaWJ1dGUgaXMgbm90
IHNwZWNpZmllZCwgdGhlbg0KPiA+ICAgICAgICAgICB0aGUgb3BlcmF0aW9uIGFwcGxpZWQgdG8g
dGhlIHBhcmVudCBkYXRhIG5vZGUgb2YgdGhlIGNvbmZpZ3VyYXRpb24NCj4gPiAgICAgICAgICAg
aXMgdXNlZC5JZiBubyBwYXJlbnQgZGF0YSBub2RlIGlzIGF2YWlsYWJsZSwgdGhlbiB0aGUgJ2Rl
ZmF1bHQtb3BlcmF0aW9uJ3ZhbHVlIGlzIHVzZWQuDQoNClRoaXMgd291bGQgY2xlYXIgdXAgYW55
IGNvbmZ1c2lvbi4NCg0KPiANCj4gQWRkaW5nIHRoaXMgYXMgYW4gZXJyYXR1bSB3b3VsZCBoZWxw
IGNsYXJpZnkgaXNzdWUgYnV0IGl0IGlzbid0IA0KPiBhYnNvbHV0ZWx5IG5lZWRlZCwgSU1PLiBN
eQ0KPiB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhpcyAgaXMgaG93IFhNTCBhdHRyaWJ1dGUgaXMg
c3VwcG9zZWQgdG8gd29yay4gIA0KPiBGb3IgZXhhbXBsZSwgIHlvdQ0KPiBkb24ndCBuZWVkIHRv
IHNwZWNpZnkgWE1MIG5hbWVzcGFjZSBhdHRyaWJ1dGUgb24gZWFjaCBlbGVtZW50LiBUaGUgd2F5
IA0KPiB0aGUgIm9wZXJhdGlvbiINCj4gaW1wbGljaXRseSBpbmhlcml0cyBmcm9tIHBhcmVudCBp
cyBleGFjdGx5IHRoZSBzYW1lIGFzIGNoaWxkIGVsZW1lbnRzIA0KPiBpbmhlcml0ICB0aGVpciAi
bmFtZXNwYWNlIg0KPiAgIGF0dHJpYnV0ZXMgdGhlaXIgcGFyZW50IG5vZGVzLg0KDQpJIHRoaW5r
IHRoYXQgeG1sIG5hbWVzcGFjZSBpcyBhIHNwZWNpYWwgY2FzZSBhbmQgdGhhdCB4bWwgYXR0cmli
dXRlcyBhcmUNCm5vdCBpbmhlcml0dGVkIGJ5IGRlZmF1bHQuDQoNCj4gDQo+IC0tWGlhbmcNCj4g
DQo+ID4gICAgICAgICAgDQo+ID4gQW5keQ0KPiA+DQo+ID4NCj4gPg0KPiA+IE9uIFR1ZSwgSnVs
IDI5LCAyMDE0IGF0IDk6NDEgQU0sIFhpYW5nIExpIDx4aWFuZ2xpQHNlZ3Vlc29mdC5jb20gDQo+
ID4gPG1haWx0bzp4aWFuZ2xpQHNlZ3Vlc29mdC5jb20+PiB3cm90ZToNCj4gPg0KPiA+DQo+ID4g
ICAgIE9uIDcvMjkvMjAxNCAxMTowMSBBTSwgS2xlbWVudCBTZWtlcmEgLVggKGtzZWtlcmEgLSBQ
YW50aGVvbg0KPiA+ICAgICBUZWNobm9sb2dpZXMgU1JPIGF0IENpc2NvKSB3cm90ZToNCj4gPj4g
ICAgIE9uIFR1ZSwgMjAxNC0wNy0yOSBhdCAxMDozOCAtMDUwMCwgWGlhbmcgTGkgd3JvdGU6DQo+
ID4+PiAgICAgT24gNy8yOS8yMDE0IDEwOjAzIEFNLCBLbGVtZW50IFNla2VyYSAtWCAoa3Nla2Vy
YSAtIFBhbnRoZW9uDQo+ID4+PiAgICAgVGVjaG5vbG9naWVzIFNSTyBhdCBDaXNjbykgd3JvdGU6
DQo+ID4+Pj4gICAgIE9uIFR1ZSwgMjAxNC0wNy0yOSBhdCAwNzo1NCAtMDcwMCwgQW5keSBCaWVy
bWFuIHdyb3RlOg0KPiA+Pj4+PiAgICAgT24gVHVlLCBKdWwgMjksIDIwMTQgYXQgNzo0MyBBTSwg
QmFsYXpzIExlbmd5ZWwgPGJhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbSAgPG1haWx0bzpiYWxh
enMubGVuZ3llbEBlcmljc3Nvbi5jb20+DQo+ID4+Pj4+PiAgICAgd3JvdGU6DQo+ID4+Pj4+PiAg
ICAgICAgSGVsbG8sDQo+ID4+Pj4+PiAgICAgSSBhbHdheXMgdG91Z2h0IHRoZSBvcGVyYXRpb24g
YXR0cmlidXRlIGlzIGluaGVyaXRlZC4NCj4gPj4+Pj4+DQo+ID4+Pj4+ICAgICBUaGlzIGlzIGhv
dyBldmVyeWJvZHkgaW1wbGVtZW50cyBpdCwgYW5kIHdoYXQgd2UgaW50ZW5kZWQgKHByZS00NzQx
KS4NCj4gPj4+Pj4gICAgIE90aGVyd2lzZSwgd291bGQgYSAicmVwbGFjZSIgb3BlcmF0aW9uIGZv
ciBzb21lIGFyYml0cmFyeSBzdWJ0cmVlDQo+ID4+Pj4+ICAgICByZXF1aXJlIG5jOm9wZXJhdGlv
bj0icmVwbGFjZSIgaW4gZXZlcnkgcmVwbGFjZW1lbnQgZGVzY2VuZGFudCBub2RlPw0KPiA+Pj4+
Pg0KPiA+Pj4+Pg0KPiA+Pj4+PiAgICAgQW5keQ0KPiA+Pj4+Pg0KPiA+Pj4+ICAgICBXZWxsIGlm
IHRoZSBkZWZhdWx0LW9wZXJhdGlvbiBpcyB1bmNoYW5nZWQsIHRoZW4NCj4gPj4+Pg0KPiA+Pj4+
ICAgICA8Y29udGFpbmVyIG9wZXJhdGlvbj0icmVwbGFjZSI+DQo+ID4+Pj4gICAgICAgIDxsZWFm
Lz4NCj4gPj4+PiAgICAgPC9jb250YWluZXI+DQo+ID4+Pj4NCj4gPj4+PiAgICAgd29ya3MgcGVy
ZmVjdGx5IGZpbmUgaWYgdGhlIG9wZXJhdGlvbiBmb3IgPGxlYWY+IGlzIGFzc3VtZWQgdG8gYmUg
YQ0KPiA+Pj4+ICAgICAibWVyZ2UiLiBGaXJzdCwgdGhlIHNlcnZlciByZW1vdmVzIHRoZSBleGlz
dGluZyA8Y29udGFpbmVyPiwgcmVwbGFjZXMgaXQNCj4gPj4+PiAgICAgd2l0aCBlbXB0eSBvbmUg
YW5kIHRoZW4gbWVyZ2VzIHRoZSA8bGVhZj4gaW4uDQo+ID4+Pj4NCj4gPj4+PiAgICAgICBGcm9t
IHRoaXMgcG9pbnQgb2YgdmlldywgIm1lcmdlIiBvbiBjaGlsZCBpcyBjb21wYXRpYmxlIHdpdGgg
ImNyZWF0ZSIgb3INCj4gPj4+PiAgICAgInJlcGxhY2UiIG9uIHBhcmVudC4NCj4gPj4+Pg0KPiA+
Pj4+ICAgICBJIGRvbid0IHNlZSBhbnkgc2VudGVuY2UgaW4gdGhlIFJGQyB3aGljaCBzYXlzIHRo
YXQgdGhlIG9wZXJhdGlvbiBpcw0KPiA+Pj4+ICAgICBpbmhlcml0ZWQuDQo+ID4+PiAgICAgUkZD
NjI0Mw0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAgICAgICAgV2l0aC1kZWZhdWx0cyBDYXBhYmlsaXR5
IGZvciBORVRDT05GIG1heSBoZWxwIGNsYXJpZnkgd2ggImVmZmVjdGl2ZQ0KPiA+Pj4gICAgICAg
IG9wZXJhdGlvbiIgbWVhbnMgaW4gYW4gImVkaXQtY29uZmlnIjoNCj4gPj4+DQo+ID4+Pg0KPiA+
Pj4NCj4gPj4+ICAgICAgICAgICAgICA0LjUuMjxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y
ZmM2MjQzI3NlY3Rpb24tNC41LjI+ICA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjI0
MyNzZWN0aW9uLTQuNS4yPi4NCj4gPj4+ICAgICAgICAgICAgICA8ZWRpdC1jb25maWc+IE9wZXJh
dGlvbg0KPiA+Pj4NCj4gPj4+ICAgICAuLi4NCj4gPj4+DQo+ID4+PiAgICAgSWYgdGhlICdkZWZh
dWx0JyBhdHRyaWJ1dGUgaXMgcHJlc2VudCwgdGhlbiB0aGUgZWZmZWN0aXZlIG9wZXJhdGlvbg0K
PiA+Pj4gICAgICAgICAgZm9yIHRoZSB0YXJnZXQgZGF0YSBub2RlIE1VU1QgYmUgJ2NyZWF0ZScs
ICdtZXJnZScsIG9yICdyZXBsYWNlJy4gIElmDQo+ID4+PiAgICAgICAgICBub3QsIHRoZW4gdGhl
IHNlcnZlciBNVVNUIHJldHVybiBhbiA8cnBjLWVycm9yPiByZXNwb25zZSB3aXRoIGFuDQo+ID4+
PiAgICAgICAgICAnaW52YWxpZC12YWx1ZScgZXJyb3ItdGFnLiAgRm9yIGV4YW1wbGUsIGlmICdj
cmVhdGUnIGlzIHRoZSBlZmZlY3RpdmUNCj4gPj4+ICAgICAgICAgIG9wZXJhdGlvbiwgdGhlbiB0
aGUgY3JlYXRlIHJlcXVlc3QgbXVzdCBiZSB2YWxpZCBvbiBpdHMgb3duIChlLmcuLA0KPiA+Pj4g
ICAgICAgICAgY3VycmVudCBkYXRhIG5vZGUgTVVTVCBOT1QgZXhpc3QpLiAgVGhlIHByb2NlZHVy
ZSBmb3IgZGV0ZXJtaW5pbmcgdGhlDQo+ID4+PiAgICAgICAgICBlZmZlY3RpdmUgb3BlcmF0aW9u
IGlzIGRlZmluZWQgaW4gW1JGQzYyNDE8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjI0
MT4gIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2MjQxPl0uICBJKnQgaXMgZGVyaXZl
ZCBmcm9tIHRoZQ0KPiA+Pj4gICAgICAgICAgJ2RlZmF1bHQtb3BlcmF0aW9uJyBwYXJhbWV0ZXIg
YW5kL29yIGFueSBvcGVyYXRpb24gYXR0cmlidXRlcyB0aGF0DQo+ID4+PiAgICAgICAgICBhcmUg
cHJlc2VudCBpbiB0aGUgZGF0YSBub2RlIG9yIGFueSBvZiBpdHMgYW5jZXN0b3Igbm9kZXMsIHdp
dGhpbiB0aGUNCj4gPj4+ICAgICAgICAgIDxlZGl0LWNvbmZpZz4gcmVxdWVzdC4qDQo+ID4+Pg0K
PiA+Pj4gICAgIEluIG90aGVyIHdvcmRzIHRoZSAib3BlcmF0aW9uIiBhdHRyaWJ1dGUgaGFzIGEg
InNjb3BlIiwgdGhhdCBpcywgaXQgYXBwbGllcw0KPiA+Pj4gICAgIHRvIHRoZSBuZXN0ZWQgbm9k
ZXMsIHVudGlsIGlzIGlzIHJlZGVmaW5lZC4gVGhpcyBpcyBsb2dpY2FsIHRvby4NCj4gPj4gICAg
IHNpZGUtbm90ZTogbm90IGV2ZXJ5IG5ldGNvbmYgc2VydmVyIG11c3Qgc3VwcG9ydCB3aXRoLWRl
ZmF1bHRzDQo+ID4+ICAgICBjYXBhYmlsaXR5DQo+ID4NCj4gPiAgICAgVGhlIHBvaW50IGlzIG5v
dCBhYm91dCB3aGV0aGVyIGEgc2V2ZXIgc3VwcG9ydHMgIiB3aXRoLWRlZmF1bHRzDQo+ID4gICAg
IGNhcGFiaWxpdHkiLiBUaGUgcGFyYWdyYXBoDQo+ID4gICAgIEkgcXVvdGVkIHNpbXBseSBoZWxw
cyB1cyBzZWUgdGhlICBORVRDT05GIHByb3RvY29sIGF1dGhvcnMnIGludGVudGlvbi4NCj4gPg0K
PiA+PiAgICAgSXQgc2F5cyB0aGF0IHRoZSBvcGVyYXRpb24gaXMgZGVyaXZlZCBmcm9tIGRlZmF1
bHQtb3BlcmF0aW9uIGFuZC9vciBhbnkNCj4gPj4gICAgIG9wZXJhdGlvbiBhdHRyaWJ1dGVzIHBy
ZXNlbnQuDQo+ID4NCj4gPiAgICAgVG8gYmUgcHJlY2lzZSwgUkZDNjI0MyBzYXlzOg0KPiA+DQo+
ID4gICAgICAgSXQgaXMgZGVyaXZlZCBmcm9tIHRoZSAnZGVmYXVsdC1vcGVyYXRpb24nIHBhcmFt
ZXRlciBhbmQvb3IgYW55IG9wZXJhdGlvbiBhdHRyaWJ1dGVzIHRoYXQNCj4gPiAgICAgICAgIGFy
ZSBwcmVzZW50IGluIHRoZSBkYXRhIG5vZGUgb3IgYW55IG9mIGl0cyBhbmNlc3RvciBub2Rlcywg
d2l0aGluIHRoZQ0KPiA+ICAgICAgICAgPGVkaXQtY29uZmlnPiByZXF1ZXN0Lg0KPiA+DQo+ID4g
ICAgIE5vdGljZSB0aGUgImFuY2VzdG9yIG5vZGVzIiB3b3JkaW5nLg0KPiA+DQo+ID4NCj4gPj4g
ICAgIE5vdyBSRkMgNjI0MSBzYXlzOg0KPiA+Pg0KPiA+PiAgICAgICAgICAgIGRlZmF1bHQtb3Bl
cmF0aW9uOiAgU2VsZWN0cyB0aGUgZGVmYXVsdCBvcGVyYXRpb24gKGFzIGRlc2NyaWJlZCBpbg0K
PiA+PiAgICAgICAgICAgICAgIHRoZSAib3BlcmF0aW9uIiBhdHRyaWJ1dGUpIGZvciB0aGlzIDxl
ZGl0LWNvbmZpZz4gcmVxdWVzdC4gIFRoZQ0KPiA+PiAgICAgICAgICAgICAgIGRlZmF1bHQgdmFs
dWUgZm9yIHRoZSA8ZGVmYXVsdC1vcGVyYXRpb24+IHBhcmFtZXRlciBpcyAibWVyZ2UiLg0KPiA+
Pg0KPiA+PiAgICAgc28gd2hlbmV2ZXIgYSBub2RlIGRvZXMgbm90IGhhdmUgYW4gb3BlcmF0aW9u
IGF0dHJpYnV0ZSwgdGhpcyBjbGF1c2UNCj4gPj4gICAgIGZvcmNlcyB0aGUgc2VydmVyIHRvIG9w
ZXJhdGUgYXMgaWYgaXQgd2FzICJtZXJnZSIsIGlmIG5vdCBzZXQgdG8gb3RoZXINCj4gPj4gICAg
IHZhbHVlLg0KPiA+DQo+ID4gICAgIEJ1dCBpZiB0aGVyZSBpcyAib3BlcmF0aW9uIiBhdHRyaWJ1
dGUgc3BlY2lmaWVkIGluIGl0c2VsZiBvciBhbnkNCj4gPiAgICAgcGFyZW50IG5vZGUgdGhlbiB0
aGUgZWZmZWN0aXZlDQo+ID4gICAgIG9wZXJhdGlvbiBpcyBub3QgIm1lcmdlIiBhbnltb3JlLg0K
PiA+DQo+ID4+ICAgICAgIEkgdGhpbmsgdGhpcyBpcyBwcmV2ZW50cyBhbnkgaW5oZXJpdGFuY2Ug
bG9naWMuDQo+ID4NCj4gPiAgICAgSSBkb24ndCBzZWUgd2h5IHRoZSBzZW50ZW5jZSBhYm92ZSBw
cmV2ZW50cyBhbnkgaW5oZXJpdGFuY2UuDQo+ID4NCj4gPiAgICAgUkZDNjI0MSBzYXlzOg0KPiA+
DQo+ID4gICAgICAgICBvcGVyYXRpb246ICBFbGVtZW50cyBpbiB0aGUgPGNvbmZpZz4gc3VidHJl
ZSBNQVkgY29udGFpbiBhbg0KPiA+ICAgICAgICAgICAgICAgIm9wZXJhdGlvbiIgYXR0cmlidXRl
LCB3aGljaCBiZWxvbmdzIHRvIHRoZSBORVRDT05GIG5hbWVzcGFjZQ0KPiA+ICAgICAgICAgICAg
ICAgZGVmaW5lZCBpblNlY3Rpb24gMy4xICA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj
NjI0MSNzZWN0aW9uLTMuMT4uICBUaGUgYXR0cmlidXRlIGlkZW50aWZpZXMgdGhlIHBvaW50IGlu
DQo+ID4gICAgICAgICAgICAgICB0aGUgY29uZmlndXJhdGlvbiB0byBwZXJmb3JtIHRoZSBvcGVy
YXRpb24gYW5kIE1BWSBhcHBlYXIgb24NCj4gPiAgICAgICAgICAgICAgIG11bHRpcGxlIGVsZW1l
bnRzIHRocm91Z2hvdXQgdGhlIDxjb25maWc+IHN1YnRyZWUuDQo+ID4NCj4gPg0KPiA+ICAgICBO
b3RpY2UgdGhlICJwb2ludCIgd29yZGluZyB1c2VkIGhlcmUuIEluIG90aGVyIHdvcmRzICJvcGVy
YXRpb24iIGlkZW50aWZpZXMNCj4gPiAgICAgYSBwb2ludCAoYSBzdWJ0cmVlKSB3aGVyZSB0aGUg
Y29uZmlnIGRhdGEgc2hvdWxkIGJlIGFwcGxpZWQuIE15IHVuZGVyc3RhbmRpbmcNCj4gPiAgICAg
aXMgdGhhdCBpdCBkb2VzIG5vdCBtYWtlIHNlbnNlIGlmIHRoZSAicG9pbnQiIG1lYW5zIHRoZSAi
ZWxlbWVudCIgaGVyZS4NCj4gPg0KPiA+ICAgICBQZXJoYXBzIGl0IGNvdWxkIGJlIGNsZWFyZXIg
aWYgaXQgd2VyZSB3cml0dGVuIGFzICIgdGhlIGF0dHJpYnV0ZSBpZGVudGlmaWVzDQo+ID4gICAg
IHRoZSBwb2ludCBhbmQgYmVsb3cgaW4gdGhlIGNvbmZpZ3VyYXRpb24uLi4iLg0KPiA+DQo+ID4N
Cj4gPg0KPiA+ICAgICAtLVhpYW5nDQo+ID4NCj4gPg0KPiA+Pj4gICAgIC0tWGlhbmcgTGkNCj4g
Pj4+DQo+ID4+Pg0KPiA+Pj4+Pj4gICAgIEluaGVyaXRlZCBpbiBhIHNlbnNlIHRoYXQgYW4gWE1M
IGVsZW1lbnQgYWN0dWFsbHkgY29udGFpbnMvaW5jbHVkZXMgYWxsDQo+ID4+Pj4+PiAgICAgc3Vi
LWVsZW1lbnRzIHVuZGVyIGl0LiBTbyBjcmVhdGluZy9kZWxldGluZy9tZXJnaW5nIHRoZSBlbGVt
ZW50IG1lYW5zDQo+ID4+Pj4+PiAgICAgY3JlYXRpbmcvZGVsZXRpbmcvbWVyZ2luZyBhbGwgaXRz
IGNvbnRlbnRzIGFzIHdlbGwuIFNvIHVubGVzcyB5b3UgbGF0ZXINCj4gPj4+Pj4+ICAgICBvdmVy
cmlkZSB0aGlzIHdpdGggbW9yZSBzcGVjaWZpYyBpbnN0cnVjdGlvbnMgZm9yIG9uZSBvZiB0aGUg
Y29udGFpbmVkDQo+ID4+Pj4+PiAgICAgZWxlbWVudHMgaXQgc2hvdWxkIGJlIHZhbGlkIGZvciB0
aGUgY29tcGxldGUgZWxlbWVudCB3aXRoIGFsbCBpdHMgY29udGVudC4NCj4gPj4+Pj4+DQo+ID4+
Pj4+PiAgICAgSWYgb3BlcmF0aW9uIGlzIG5vdCBpbmhlcml0YWJsZSB3ZSBoYXZlIHNvbWUgaW50
ZXJlc3RpbmcgY2FzZXM6DQo+ID4+Pj4+PiAgICAgLSB5b3VyIGV4YW1wbGVzDQo+ID4+Pj4+PiAg
ICAgLSBkZWZhdWx0IG9wZXJhdGlvbj1ub25lIGFuZCBJIHdhbnQgdG8gY3JlYXRlIGEgc2l6ZWFi
bGUgc3VidHJlZS4gSSBoYXZlDQo+ID4+Pj4+PiAgICAgdG8gcGxhY2UgdGhlIG1lcmdlL2NyZWF0
ZSBvcGVyYXRpb24gb24gZXZlcnkgbm9kZS4gRG9uJ3QgbGlrZSBpdCwgbWFrZXMNCj4gPj4+Pj4+
ICAgICBub25lLXVudXNhYmxlIGV4Y2VwdCBmb3IgZGVsZXRlL3JlbW92ZS4NCj4gPj4+Pj4+ICAg
ICBMZXRzIHNheSB3ZSBoYXZlIHRoZSBmb2xsb3dpbmcgZGF0YSBtb2RlbDoNCj4gPj4+Pj4+DQo+
ID4+Pj4+PiAgICAgcm91dGluZw0KPiA+Pj4+Pj4gICAgICAgICArLS1zdGF0aWMtcm91dGluZw0K
PiA+Pj4+Pj4gICAgICAgICB8ICAgKy0tcm91dGUgW3JvdXRlSWRdDQo+ID4+Pj4+PiAgICAgICAg
IHwgICAgICAgICstLXJvdXRlSWQgCQkJaXBwcmVmaXgNCj4gPj4+Pj4+ICAgICAgICAgfCAgICAg
ICAgKy0tcGF0aC10by1kZXN0aW5hdGlvbiAJW25leHRob3BdDQo+ID4+Pj4+PiAgICAgICAgIHwg
ICAgICAgICAgICArLS1uZXh0SG9wIAkJaXBBZGRyZXNzDQo+ID4+Pj4+PiAgICAgICAgIHwgICAg
ICAgICAgICArLS1vdXRnb2luZ0ludGVyZmFjZSAgIAlzdHJpbmcNCj4gPj4+Pj4+ICAgICAgICAg
ICAgICAgICAgICAgICstLWJmZEFjdGl2ZQkJYm9vbGVhbg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICAg
ICBJIHdhbnQgdG8gY3JlYXRlIGEgc3RhdGljIHJvdXRlIHdpdGggYWxsIGl0cyBzdWItZWxlbWVu
dHMgYnV0IG9ubHkgaWYgdGhlDQo+ID4+Pj4+PiAgICAgc3RhdGljLXJvdXRpbmcgcHJlc2VuY2Ug
Y29udGFpbmVyIGV4aXN0cyAoc3RhdGljIHJvdXRpbmcgaXMNCj4gPj4+Pj4+ICAgICBhbGxvd2Vk
L2VuYWJsZWQpLg0KPiA+Pj4+Pj4gICAgIDxkZWZhdWx0LW9wZXJhdGlvbj5ub25lPC9kZWZhdWx0
LW9wZXJhdGlvbj4NCj4gPj4+Pj4+ICAgICA8Y29uZmlnPg0KPiA+Pj4+Pj4gICAgICAgICAgPHN0
YXRpYy1yb3V0aW5nPiAgLS0tIHRoaXMgd2lsbCBjaGVjayB0aGF0IHN0YXRpYyByb3V0aW5nIGV4
aXN0cy4NCj4gPj4+Pj4+ICAgICAgICAgICAgIDxyb3V0ZSBvcGVyYXRpb249ImNyZWF0ZSI+ICAt
LXRoaXMgd2lsbCBjcmVhdGUgdGhlIGludGVyZmFjZQ0KPiA+Pj4+Pj4gICAgICAgICAgICAgICAg
PHJvdXRlaWQ+MS4xLjEuMS8yNCAgPGh0dHA6Ly8xLjEuMS4xLzI0Pjwvcm91dGVpZD4gICAtLSBJ
IGRvbid0IHdhbnQgdG8gcHV0DQo+ID4+Pj4+PiAgICAgb3BlcmF0aW9uPWNyZWF0ZSBvbiBhbGwg
ZnVydGhlciBub2RlcyA1IHRpbWVzIG9yIG1vcmUgZGVwZW5kaW5nIG9uIHRoZQ0KPiA+Pj4+Pj4g
ICAgIG51bWJlciBvZiBwYXRocw0KPiA+Pj4+Pj4gICAgICAgICAgICAgICAgPHBhdGgtdG8tZGVz
dGluYXRpb24+DQo+ID4+Pj4+PiAgICAgICAgICAgICAgICAgICA8bmV4dEhvcD4xLjEuMS41PC9u
ZXh0SG9wPg0KPiA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgPG91dGdvaW5nSW50ZXJmYWNlPmV0
aDA8L291dGdvaW5nSW50ZXJmYWNlPg0KPiA+Pj4+Pj4gICAgICAgICAgICAgICAgICAgPGJmZEFj
dGl2ZT50cnVlPC9iZmRBY3RpdmU+DQo+ID4+Pj4+PiAgICAgICAgICAgICAgICA8L3BhdGgtdG8t
ZGVzdGluYXRpb24+DQo+ID4+Pj4+PiAgICAgICAgICAgICA8L3JvdXRlPg0KPiA+Pj4+Pj4gICAg
ICAgICAgPC9zdGF0aWMtcm91dGluZz4NCj4gPj4+Pj4+ICAgICA8L2NvbmZpZz4NCj4gPj4+Pj4+
DQo+ID4+Pj4+PiAgICAgICAgVGhpcyB3YXMgdmVyeSBuaWNlIGFuZCBsb2dpY2FsLiBJIGhvcGUg
aXQgc3RpbGwgd29ya3MuDQo+ID4+Pj4+PiAgICAgcmVnYXJkcyBCYWxhenMNCj4gPj4+Pj4+DQo+
ID4+Pj4+PiAgICAgT24gMjAxNC0wNy0yOSAxNDoxNywgQW5keSBCaWVybWFuIHdyb3RlOg0KPiA+
Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ICAgICBPbiBUdWUs
IEp1bCAyOSwgMjAxNCBhdCAxMjo0NCBBTSwgS2xlbWVudCBTZWtlcmEgLVggKGtzZWtlcmEgLSBQ
YW50aGVvbg0KPiA+Pj4+Pj4gICAgIFRlY2hub2xvZ2llcyBTUk8gYXQgQ2lzY28pPGtzZWtlcmFA
Y2lzY28uY29tPiAgPG1haWx0bzprc2VrZXJhQGNpc2NvLmNvbT4gIHdyb3RlOg0KPiA+Pj4+Pj4N
Cj4gPj4+Pj4+PiAgICAgT24gTW9uLCAyMDE0LTA3LTI4IGF0IDA4OjQzIC0wNzAwLCBBbmR5IEJp
ZXJtYW4gd3JvdGU6DQo+ID4+Pj4+Pj4+ICAgICBPbiBNb24sIEp1bCAyOCwgMjAxNCBhdCA4OjMx
IEFNLCBLbGVtZW50IFNla2VyYSAtWCAoa3Nla2VyYSAtIFBhbnRoZW9uDQo+ID4+Pj4+Pj4+ICAg
ICBUZWNobm9sb2dpZXMgU1JPIGF0IENpc2NvKTxrc2VrZXJhQGNpc2NvLmNvbT4gIDxtYWlsdG86
a3Nla2VyYUBjaXNjby5jb20+ICB3cm90ZToNCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+ICAgICBP
biBNb24sIDIwMTQtMDctMjggYXQgMDg6MjIgLTA3MDAsIEFuZHkgQmllcm1hbiB3cm90ZToNCj4g
Pj4+Pj4+Pj4+PiAgICAgT24gTW9uLCBKdWwgMjgsIDIwMTQgYXQgODoxMSBBTSwgS2xlbWVudCBT
ZWtlcmEgLVggKGtzZWtlcmEgLQ0KPiA+Pj4+Pj4+ICAgICBQYW50aGVvbg0KPiA+Pj4+Pj4+Pj4+
ICAgICBUZWNobm9sb2dpZXMgU1JPIGF0IENpc2NvKTxrc2VrZXJhQGNpc2NvLmNvbT4gIDxtYWls
dG86a3Nla2VyYUBjaXNjby5jb20+ICB3cm90ZToNCj4gPj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+
PiAgICAgSGkgYWxsLA0KPiA+Pj4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiAgICAgd2UgYXJlIGN1
cnJlbnRseSBkZWJhdGluZyBhbiBpc3N1ZSB3ZSBmb3VuZCBhbmQgd291bGQgbGlrZSB0bw0KPiA+
Pj4+Pj4+ICAgICBoYXZlIHNvbWUNCj4gPj4+Pj4+Pj4+Pj4gICAgIGNsYXJpZmljYXRpb24uIE5l
dGNvbmYgUkZDIHNheXMgdGhhdCB0aGUgZWRpdC1jb25maWcgb3BlcmF0aW9uDQo+ID4+Pj4+Pj4g
ICAgIHdoaWNoDQo+ID4+Pj4+Pj4+Pj4+ICAgICBjb250YWlucyBtdWx0aXBsZSBzdWItb3BlcmF0
aW9ucyBvbiB0aGUgc2FtZSBkYXRhIGlzIHVuZGVmaW5lZC4NCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+
Pj4+Pj4+Pj4gICAgIHNvIHdoZW4gY29uc2lkZXJpbmcgdGhpcyByZXF1ZXN0Og0KPiA+Pj4+Pj4+
Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiAgICAgPGVkaXQtY29uZmlnPg0KPiA+Pj4+Pj4+Pj4+PiAgICAg
PHRhcmdldD48Y2FuZGlkYXRlLz48L3RhcmdldD4NCj4gPj4+Pj4+Pj4+Pj4gICAgIDxjb25maWc+
DQo+ID4+Pj4+Pj4+Pj4+ICAgICAgICA8Y29udGFpbmVyIG9wZXJhdGlvbj0iZGVsZXRlIj4NCj4g
Pj4+Pj4+Pj4+Pj4gICAgICAgICA8bGVhZiBvcGVyYXRpb249ImNyZWF0ZSIvPg0KPiA+Pj4+Pj4+
Pj4+PiAgICAgICAgPC9jb250YWluZXI+DQo+ID4+Pj4+Pj4+Pj4+ICAgICA8L2NvbmZpZz4NCj4g
Pj4+Pj4+Pj4+Pj4gICAgIDwvZWRpdC1jb25maWc+DQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+
Pj4+ICAgICB0aGUgb3V0Y29tZSBpcyB1bmRlZmluZWQsIHNpbmNlIHRoZSBjbGllbnQgd2FudHMg
ZG8gZGVsZXRlDQo+ID4+Pj4+Pj4gICAgIGNvbnRhaW5lcg0KPiA+Pj4+Pj4+Pj4+PiAgICAgPGNv
bnRhaW5lcj4sIHdoaWxlIHNpbXVsdGFuZW91c2x5IGNyZWF0aW5nIDxsZWFmPiB3aGljaCBpcyBw
YXJ0IG9mDQo+ID4+Pj4+Pj4+Pj4+ICAgICA8Y29udGFpbmVyPi4NCj4gPj4+Pj4+Pj4+Pj4NCj4g
Pj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+PiAgICAgSXQgaXMgZGVmaW5lZC4NCj4gPj4+Pj4+Pj4+
PiAgICAgRG9lcyB0aGUgbm9kZSAvY29udGFpbmVyIGV4aXN0IGluIHRoZSB0YXJnZXQgZGF0YXN0
b3JlPw0KPiA+Pj4+Pj4+Pj4+ICAgICBJZiB5ZXMsIHRoZW4gdGhlIGNyZWF0ZSBvcGVyYXRpb24g
b24gL2NvbnRhaW5lci9sZWFmIE1VU1QgZmFpbC4NCj4gPj4+Pj4+Pj4+PiAgICAgSWYgbm8sIHRo
ZW4gdGhlIGRlbGV0ZSBvcGVyYXRpb24gb24gL2NvbnRhaW5lciBNVVNUIGZhaWwuDQo+ID4+Pj4+
Pj4+PiAgICAgd2hhdCBpZiAvY29udGFpbmVyIGV4aXN0cyBidXQgL2NvbnRhaW5lci9sZWFmIGRv
ZXMgbm90PyB0aGlzIHdheSBib3RoDQo+ID4+Pj4+Pj4+PiAgICAgc3ViLW9wZXJhdGlvbnMgY291
bGQgYmUgcGVyZm9ybWVkDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiAgICAgbm90IHJlYWxseS4g
SWYgaW1wbGVtZW50ZWQgY29ycmVjdGx5IHRoZW4gaWYgdGhlIGRlbGV0ZSBvbiAvY29udGFpbmVy
DQo+ID4+Pj4+Pj4+ICAgICBzdWNjZWVkcywNCj4gPj4+Pj4+Pj4gICAgIHRoZW4gYWxsIGl0cyBk
ZXNjZW5kYW50cyBhcmUgYWxzbyBkZWxldGVkLiAgVGhlIHJlc3VsdCBpbiB0aGUgdGFyZ2V0DQo+
ID4+Pj4+Pj4+ICAgICBkYXRhc3RvcmUgY2Fubm90DQo+ID4+Pj4+Pj4+ICAgICBwb3NzaWJseSBj
b21wbGV0ZSBib3RoIGEgZGVsZXRlIG9uIGFuIGFuY2VzdG9yIGFuZCBjcmVhdGUgb2YgYQ0KPiA+
Pj4+Pj4+ICAgICBkZXNjZW5kYW50DQo+ID4+Pj4+Pj4+ICAgICBpbiB0aGUgc2FtZSBlZGl0LiBP
dXIgc2VydmVyIHJldHVybnMgYW4gZXJyb3IgYmVjYXVzZSBpdCBjYW5ub3QgaG9ub3INCj4gPj4+
Pj4+Pj4gICAgIGJvdGggcmVxdWVzdHMuDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4gICAgIEkgYmVs
aWV2ZSB0aGF0IHRoaXMgaXMgdGhlIHBhcnQgd2hlcmUNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+ICAg
ICAgICAgICAgIElmIHRoZSA8ZWRpdC1jb25maWc+IG9wZXJhdGlvbiBjb250YWlucyBtdWx0aXBs
ZSBzdWItb3BlcmF0aW9ucw0KPiA+Pj4+Pj4+ICAgICAgICAgICAgIHRoYXQgYXBwbHkgdG8gdGhl
IHNhbWUgY29uY2VwdHVhbCBub2RlIGluIHRoZSB1bmRlcmx5aW5nIGRhdGENCj4gPj4+Pj4+PiAg
ICAgICAgICAgICBtb2RlbCwgdGhlbiB0aGUgcmVzdWx0IG9mIHRoZSBvcGVyYXRpb24gaXMgdW5k
ZWZpbmVkIChpLmUuLA0KPiA+Pj4+Pj4+ICAgICAgICAgICAgIG91dHNpZGUgdGhlIHNjb3BlIG9m
IHRoZSBORVRDT05GIHByb3RvY29sKS4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+ICAgICBjb21lcyBp
bnRvIHBsYXkuIEV4YWN0bHkgYXMgeW91IHNheSwgdGFyZ2V0IGRhdGFzdG9yZSBjYW5ub3QgY29t
cGxldGUNCj4gPj4+Pj4+PiAgICAgYm90aCB0aGUgZGVsZXRpb24gYW5kIGNyZWF0aW9uLCBzaW5j
ZSBib3RoIG9wZXJhdGUgb24gdGhlIHNhbWUgZGF0YSBidXQNCj4gPj4+Pj4+PiAgICAgcnVsZSBl
YWNoIG90aGVyIG91dC4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+PiAgICAgTm93LCB3aGVuIGNv
bnNpZGVyaW5nIGEgc2ltcGxlIGxpc3QgZGVsZXRpb246DQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+
Pj4+Pj4+ICAgICA8ZWRpdC1jb25maWc+DQo+ID4+Pj4+Pj4+Pj4+ICAgICA8dGFyZ2V0PjxjYW5k
aWRhdGUvPjwvdGFyZ2V0Pg0KPiA+Pj4+Pj4+Pj4+PiAgICAgPGNvbmZpZz4NCj4gPj4+Pj4+Pj4+
Pj4gICAgICAgIDxsaXN0IG9wZXJhdGlvbj0iZGVsZXRlIj4NCj4gPj4+Pj4+Pj4+Pj4gICAgICAg
ICA8a2V5LW5vZGU+a2V5LXZhbHVlPC9rZXktbm9kZT4NCj4gPj4+Pj4+Pj4+Pj4gICAgICAgIDwv
bGlzdD4NCj4gPj4+Pj4+Pj4+Pj4gICAgIDwvY29uZmlnPg0KPiA+Pj4+Pj4+Pj4+PiAgICAgPC9l
ZGl0LWNvbmZpZz4NCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4gICAgIGFuZCByaWdvcm91
c2x5IHJlYWRpbmcgdGhlIFJGQyByZWdhcmRpbmcgb3BlcmF0aW9uIGFuZA0KPiA+Pj4+Pj4+Pj4+
PiAgICAgZGVmYXVsdC1vcGVyYXRpb24sIHRoZSBvcGVyYXRpb24gYXR0cmlidXRlIGZvciA8a2V5
LW5vZGU+IGlzDQo+ID4+Pj4+Pj4gICAgICJtZXJnZSIsDQo+ID4+Pj4+Pj4+Pj4+ICAgICB0aHVz
LCB0ZWNobmljYWxseSwgdGhpcyBlZGl0LWNvbmZpZyBvcGVyYXRpb24gb3BlcmF0ZXMgb24gdGhl
DQo+ID4+Pj4+Pj4+PiAgICAgPGtleS1ub2RlPg0KPiA+Pj4+Pj4+Pj4+PiAgICAgdHdpY2U6DQo+
ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4gICAgIFRoZSBvcGVyYXRpb24gaXMgaW5oZXJpdGVk
IGZyb20gaXRzIHBhcmVudCBpZiBubyAibmM6b3BlcmF0aW9uIg0KPiA+Pj4+Pj4+Pj4+ICAgICBh
dHRyaWJ1dGUgaXMgc3BlY2lmaWVkLiBUaGUga2V5cyBuZWVkIHRvIGJlIHByZXNlbnQgdG8gc3Bl
Y2lmeSB0aGUNCj4gPj4+Pj4+PiAgICAgbGlzdA0KPiA+Pj4+Pj4+Pj4+ICAgICBub2RlIHRvIGJl
IGRlbGV0ZWQuDQo+ID4+Pj4+Pj4+PiAgICAgY2FuIHlvdSBwb2ludCB0byB0aGUgcGFyYWdyYXBo
IGluIG5ldGNvbmYgUkZDIHdoaWNoIHNheXMgdGhhdCB0aGUNCj4gPj4+Pj4+Pj4+ICAgICBvcGVy
YXRpb24gaXMgaW5oZXJpdGVkPw0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+
ICAgICB0aGUgZGVsZXRlIG9wZXJhdGlvbiBvbiB0aGUgL2NvbnRhaW5lciBub2RlIGlzIGZvciB0
aGUgY29udGFpbmVyIGFuZA0KPiA+Pj4+Pj4+ICAgICBhbGwgaXRzDQo+ID4+Pj4+Pj4+ICAgICBk
ZXNjZW5kYW50cy4gIFRoYXQgaXMgaG93IGl0IGlzIGluaGVyaXRlZC4gSSBzaG91bGQgaGF2ZSBz
YWlkDQo+ID4+Pj4+Pj4gICAgICJlZmZlY3RpdmUiDQo+ID4+Pj4+Pj4+ICAgICBvcGVyYXRpb24N
Cj4gPj4+Pj4+Pj4gICAgIGluc3RlYWQgb2YgImluaGVyaXRlZCIuDQo+ID4+Pj4+Pj4gICAgICAg
ICAgICAgb3BlcmF0aW9uOiAgRWxlbWVudHMgaW4gdGhlIDxjb25maWc+IHN1YnRyZWUgTUFZIGNv
bnRhaW4gYW4NCj4gPj4+Pj4+PiAgICAgICAgICAgICAgICAib3BlcmF0aW9uIiBhdHRyaWJ1dGUs
IHdoaWNoIGJlbG9uZ3MgdG8gdGhlIE5FVENPTkYgbmFtZXNwYWNlDQo+ID4+Pj4+Pj4gICAgICAg
ICAgICAgICAgZGVmaW5lZCBpbiBTZWN0aW9uIDMuMS4gIFRoZSBhdHRyaWJ1dGUgaWRlbnRpZmll
cyB0aGUgcG9pbnQgaW4NCj4gPj4+Pj4+PiAgICAgICAgICAgICAgICB0aGUgY29uZmlndXJhdGlv
biB0byBwZXJmb3JtIHRoZSBvcGVyYXRpb24gYW5kIE1BWSBhcHBlYXIgb24NCj4gPj4+Pj4+PiAg
ICAgICAgICAgICAgICBtdWx0aXBsZSBlbGVtZW50cyB0aHJvdWdob3V0IHRoZSA8Y29uZmlnPiBz
dWJ0cmVlLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gICAgICAgICAgICAgICAgSWYgdGhlICJvcGVy
YXRpb24iIGF0dHJpYnV0ZSBpcyBub3Qgc3BlY2lmaWVkLCB0aGUNCj4gPj4+Pj4+PiAgICAgICAg
ICAgICAgICBjb25maWd1cmF0aW9uIGlzIG1lcmdlZCBpbnRvIHRoZSBjb25maWd1cmF0aW9uIGRh
dGFzdG9yZS4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+ICAgICBpbiB0aGlzIGNhc2UsIHRoZSAib3Bl
cmF0aW9uIiBhdHRyaWJ1dGUgZm9yIDxrZXktbm9kZT4gaXMgbm90IHNwZWNpZmllZC4NCj4gPj4+
Pj4+PiAgICAgU28gdGhlIHByb3ZpZGVkIGV4YW1wbGUgcmVxdWVzdCBpcyBlcXVpdmFsZW50IHRv
IHRoaXMgcmVxdWVzdDoNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+ICAgICA8bGlzdCBvcGVyYXRpb249
ImRlbGV0ZSI+DQo+ID4+Pj4+Pj4gICAgICAgIDxrZXktbm9kZSBvcGVyYXRpb249Im1lcmdlIj5r
ZXktdmFsdWU8L2tleS1ub2RlPg0KPiA+Pj4+Pj4+ICAgICA8L2xpc3Q+DQo+ID4+Pj4+Pj4NCj4g
Pj4+Pj4+PiAgICAgc28gYmFzaWNhbGx5IGl0J3MgdGhlIHNhbWUgYXMgYWJvdmUgLSB0aGVyZSBp
cyBhIHJlcXVlc3QgZG8gZGVsZXRlDQo+ID4+Pj4+Pj4gICAgIDxsaXN0PiB3aGlsZSBjcmVhdGlu
ZyBhbmQvb3Iga2VlcGluZyA8a2V5LW5vZGU+IGFyb3VuZCAtIGJvdGggY2Fubm90IGJlDQo+ID4+
Pj4+Pj4gICAgIGRvbmUuIEkgY2Fubm90IGZpbmQgYW55IGV4Y2VwdGlvbiBpbiB0aGUgUkZDIGZv
ciBsaXN0L2tleS1ub2RlIGNvbWJvDQo+ID4+Pj4+Pj4gICAgIGNhc2UuDQo+ID4+Pj4+Pj4NCj4g
Pj4+Pj4+Pg0KPiA+Pj4+Pj4gICAgICAgIFBlcmhhcHMgMSBuZXcgc2VudGVuY2UgKEFmdGVyIHRo
ZSAxIGFib3V0IG5vIGF0dHJpYnV0ZT1tZXJnZSk6DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gICAgICAg
ICAgSWYgdGhlIG9wZXJhdGlvbiBhdHRyaWJ1dGUgaXMgbm90IHByZXNlbnQgZm9yIGEga2V5IGxl
YWYgbm9kZSwgYW5kDQo+ID4+Pj4+PiAgICAgICAgIHRoZSBlZGl0IG9wZXJhdGlvbiBmb3IgdGhl
IHBhcmVudCBub2RlIGlzICJkZWxldGUiIG9yICJyZW1vdmUiLA0KPiA+Pj4+Pj4gICAgICAgICB0
aGVuIHRoZSBvcGVyYXRpb24gZm9yIHRoZSBrZXkgbGVhZiBub2RlIGlzIHRoZSBzYW1lIGFzIGl0
cyBwYXJlbnQgbm9kZS4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gICAgICAgIEFuZHkN
Cj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4gICAgIDEuKSBkZWxl
dGluZyB0aGUgdmFsdWUgdmlhIGRlbGV0aW9uIG9mIHRoZSBsaXN0IGVudGl0eSA8bGlzdD4NCj4g
Pj4+Pj4+Pj4+Pj4gICAgIDIuKSBtZXJnaW5nIGluIGEgbmV3IHZhbHVlIHZpYSAibWVyZ2UiIG9u
IHRoZSA8a2V5LW5vZGU+DQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+
Pj4+ICAgICBUaGUgUkZDIGhhcyA8ZGVmYXVsdC1vcGVyYXRpb24+bm9uZTwvZGVmYXVsdC1vcGVy
YXRpb24+IGluIGFsbA0KPiA+Pj4+Pj4+ICAgICBkZWxldGlvbg0KPiA+Pj4+Pj4+Pj4+PiAgICAg
ZXhhbXBsZXMsIHdoaWNoIG1ha2VzIHVzIGJlbGlldmUgdGhhdCBpbmRlZWQgd2hlbiBwcm9jZXNz
aW5nIHRoZQ0KPiA+Pj4+Pj4+Pj4+PiAgICAgbWVudGlvbmVkIHJlcXVlc3QsIHRoZSA8a2V5LW5v
ZGU+J3Mgb3BlcmF0aW9uIHdvdWxkIGJlICJtZXJnZSINCj4gPj4+Pj4+PiAgICAgYW5kIHRodXMN
Cj4gPj4+Pj4+Pj4+Pj4gICAgIHRoZSBvcGVyYXRpb24gdW5kZWZpbmVkLg0KPiA+Pj4+Pj4+Pj4+
Pg0KPiA+Pj4+Pj4+Pj4+PiAgICAgSXMgdGhpcyBob3cgaXQncyBzdXBwb3NlZCB0byBiZSBvciBh
cmUgd2UgcmVhZGluZyBpdCB3cm9uZz8NCj4gPj4+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+Pj4NCj4g
Pj4+Pj4+Pj4+PiAgICAgdGhlIGxhdHRlcg0KPiA+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pj4NCj4g
Pj4+Pj4+Pj4+Pj4gICAgIFRoYW5rcywNCj4gPj4+Pj4+Pj4+Pj4gICAgIEtsZW1lbnQNCj4gPj4+
Pj4+Pj4+Pj4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQo+ID4+Pj4+Pj4+Pj4+ICAgICBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+Pj4+Pj4+Pj4+
PiAgICAgTmV0Y29uZkBpZXRmLm9yZyAgPG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KPiA+Pj4+
Pj4+Pj4+PiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25m
DQo+ID4+Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ICAgICBBbmR5DQo+ID4+Pj4+PiAgICAgX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+Pj4+ICAgICBO
ZXRjb25mIG1haWxpbmdsaXN0TmV0Y29uZkBpZXRmLm9yZ2h0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vbmV0Y29uZiAgPG1haWx0bzpsaXN0TmV0Y29uZkBpZXRmLm9yZ2h0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZj4NCj4gPj4+Pj4+DQo+ID4+
Pj4+Pg0KPiA+Pj4+Pj4gICAgIC0tDQo+ID4+Pj4+PiAgICAgQmFsYXpzIExlbmd5ZWwgICAgICAg
ICAgICAgICAgICAgICAgIEVyaWNzc29uIEh1bmdhcnkgTHRkLg0KPiA+Pj4+Pj4gICAgIFNlbmlv
ciBTcGVjaWFsaXN0DQo+ID4+Pj4+PiAgICAgRUNOOiA4MzEgNzMyMCAgICAgICAgICAgICAgICAg
ICAgICAgIFRlbDogKzM2LTEtNDM3LTczMjANCj4gPj4+Pj4+ICAgICBNb2JpbGU6ICszNi03MC0z
MzAtNzkwOSAgICAgICAgICAgICAgZW1haWw6QmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24uY29tICA8
bWFpbHRvOkJhbGF6cy5MZW5neWVsQGVyaWNzc29uLmNvbT4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0K
PiA+Pj4+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KPiA+Pj4+ICAgICBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+Pj4+ICAgICBOZXRjb25mQGll
dGYub3JnICA8bWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmc+DQo+ID4+Pj4gICAgIGh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KPiA+Pj4gICAgIF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+PiAgICAgTmV0Y29uZiBt
YWlsaW5nIGxpc3QNCj4gPj4+ICAgICBOZXRjb25mQGlldGYub3JnICA8bWFpbHRvOk5ldGNvbmZA
aWV0Zi5vcmc+DQo+ID4+PiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9uZXRjb25mDQo+ID4NCj4gPiAgICAgLS0gDQo+ID4gICAgIC0tDQo+ID4gICAgIFhpYW5nIExp
LA0KPiA+ICAgICBTZWd1ZXNvZnQsIENoYW1wYWlnbiwgSUwNCj4gPiAgICAgKDIxNykgNzIxLTUz
NDENCj4gPg0KPiA+DQo+ID4gICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQo+ID4gICAgIE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4gICAgIE5ldGNv
bmZAaWV0Zi5vcmcgPG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KPiA+ICAgICBodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gPg0KPiA+DQo+IA0KDQo=


From bartosz.bak@amartus.com  Wed Jul 30 05:56:39 2014
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3155B1A0025 for ; Wed, 30 Jul 2014 05:56:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level: 
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
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 JF1CRipH0S0B for ; Wed, 30 Jul 2014 05:56:37 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0015.outbound.protection.outlook.com [213.199.154.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 393571A0020 for ; Wed, 30 Jul 2014 05:56:36 -0700 (PDT)
Received: from [192.168.12.52] (31.179.210.186) by AMXPR04MB087.eurprd04.prod.outlook.com (10.242.71.18) with Microsoft SMTP Server (TLS) id 15.0.995.14; Wed, 30 Jul 2014 12:56:34 +0000
Message-ID: <53D8EB81.2090407@amartus.com>
Date: Wed, 30 Jul 2014 14:56:33 +0200
From: =?UTF-8?B?QmFydG9zeiBCxIVr?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [31.179.210.186]
X-ClientProxiedBy: DBXPR04CA004.eurprd04.prod.outlook.com (10.255.191.152) To AMXPR04MB087.eurprd04.prod.outlook.com (10.242.71.18)
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:
X-Forefront-PRVS: 0288CD37D9
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6049001)(6009001)(189002)(199002)(53754006)(504964003)(42186005)(95666004)(54356999)(50986999)(77096002)(64126003)(107046002)(229853001)(101416001)(4396001)(50466002)(85182001)(87976001)(85202003)(23676002)(77982001)(15202345003)(107886001)(79102001)(2351001)(106356001)(99396002)(36756003)(20776003)(85852003)(83506001)(87266999)(66066001)(15975445006)(92566001)(80022001)(31966008)(19580395003)(47776003)(81542001)(83072002)(64706001)(74662001)(21056001)(81342001)(110136001)(74502001)(76482001)(92726001)(83322001)(65816999)(33656002)(102836001)(80316001)(46102001)(65956001)(85306003)(105586002)(86362001); DIR:OUT; SFP:; SCL:1; SRVR:AMXPR04MB087; H:[192.168.12.52]; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; 
X-OriginatorOrg: amartus.com
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/2uAr2fKECkYfuAErpS3KkSW4Q-Y
Subject: [Netconf] Entity tag (ETag) question
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 12:59:00 -0000

Hi all,
I'm working on a database-backed YANG datastore with RESTCONF API.
Currently I'm dealing with entity tag feature and I have a problem with 
spec interpretation in this area.
Let me explain my concerns on a below example:
Suppose I have the following model:

module leafrefs {
   namespace "http://com/example/A";
   prefix test;
   list A {
    leaf a-key {type string;}
    leaf a-property {type string;}
    key a-key;
    container Test {
        leaf test {type string;}
        leaf test2 {type string;}
        leaf test3 {type string;}
    }
    leaf
    list B {
      leaf b-key {type string;}
      leaf b-property {type string;}
      key b;
    }
   }
}

So my question is whether there should by only single ETag assigned to 
the whole data tree instance (to each "A" root element) and then each 
data modification to that tree, like :
a). modifying A.a-property,
b). Modifying container property A.Test.test
c). Adding new B  to the A.b list,
d). Patching existing A.B element.
e). removing existing A.B element.
changes the entity tag to the new unique value?

Or maybe system should maintain separate entity tags  for every A and B 
elements and patching existing A.B element should not change entity tag 
of the parent A element, instead given B child element should get new 
value of it's own Etag.

Thank you in advance for the answers
-- 
Regards,
Bartek


From nobody Wed Jul 30 06:53:20 2014
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421051A0061 for ; Wed, 30 Jul 2014 06:53:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level: 
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 KxjiDiecRWcQ for ; Wed, 30 Jul 2014 06:53:13 -0700 (PDT)
Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93841A0056 for ; Wed, 30 Jul 2014 06:53:12 -0700 (PDT)
Received: by mail-qg0-f42.google.com with SMTP id j5so1469591qga.1 for ; Wed, 30 Jul 2014 06:53:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9JiP2gFLqrakCSeSBSwly3WdeDe0x9Z+rRruygRND7U=; b=Q5jdiwTG7nJ9lPC+RgLkUJhHRO/Nvrz8XUB12WrpHnjEM/rXvAV0NqVkrKnW068kk1 PUaS+Lf5XR3vqTR8YiPJ1AJDuYPMcY1XD+8K1C4Eryf/JkGRLlkckm77Bcs7h/wrASj8 eZeB0FUW/XWs1yrTMSbFyrMuJgYPAYNqF1NSblphsqwqtZcbcYfJJl5Frgw+xsGlx8fx I56jE6VFnpKUn1C/pZ117Abm5WjH22eEnWopum85Wv21Ly6pnPeDRKUBJrkLsSgHrr33 iYXFsBkT2Bp8K3bee3XdtofMaTLN0HC0GBdgX10evf12hFy6h0XOKhWRShL6rhT3BCGJ LTJA==
X-Gm-Message-State: ALoCoQnIeSWSuAlIcGDGrA5cB6GX4467Xm3Tva3tnQe1wEiZ0P0hMXJRrHq8lO/pWFTWcZDkrNW3
MIME-Version: 1.0
X-Received: by 10.224.20.200 with SMTP id g8mr7096332qab.88.1406728392086; Wed, 30 Jul 2014 06:53:12 -0700 (PDT)
Received: by 10.140.104.48 with HTTP; Wed, 30 Jul 2014 06:53:12 -0700 (PDT)
In-Reply-To: <53D8EB81.2090407@amartus.com>
References: <53D8EB81.2090407@amartus.com>
Date: Wed, 30 Jul 2014 06:53:12 -0700
Message-ID: 
From: Andy Bierman 
To: =?UTF-8?B?QmFydG9zeiBCxIVr?= 
Content-Type: multipart/alternative; boundary=001a11c2a3b01b2c5304ff697a43
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/_xvKTbeN3moQdWypOpb07_C51sU
Cc: Netconf 
Subject: Re: [Netconf] Entity tag (ETag) question
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 13:53:14 -0000

--001a11c2a3b01b2c5304ff697a43
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

In our implementation, the server simply updates the changed node and
all its ancestors, including the  root.  The draft only requires
that the etag be maintained for the config root. Anything else is optional
and up to the developer.

Andy



On Wed, Jul 30, 2014 at 5:56 AM, Bartosz B=C4=85k 
wrote:

> Hi all,
> I'm working on a database-backed YANG datastore with RESTCONF API.
> Currently I'm dealing with entity tag feature and I have a problem with
> spec interpretation in this area.
> Let me explain my concerns on a below example:
> Suppose I have the following model:
>
> module leafrefs {
>   namespace "http://com/example/A";
>   prefix test;
>   list A {
>    leaf a-key {type string;}
>    leaf a-property {type string;}
>    key a-key;
>    container Test {
>        leaf test {type string;}
>        leaf test2 {type string;}
>        leaf test3 {type string;}
>    }
>    leaf
>    list B {
>      leaf b-key {type string;}
>      leaf b-property {type string;}
>      key b;
>    }
>   }
> }
>
> So my question is whether there should by only single ETag assigned to th=
e
> whole data tree instance (to each "A" root element) and then each data
> modification to that tree, like :
> a). modifying A.a-property,
> b). Modifying container property A.Test.test
> c). Adding new B  to the A.b list,
> d). Patching existing A.B element.
> e). removing existing A.B element.
> changes the entity tag to the new unique value?
>
> Or maybe system should maintain separate entity tags  for every A and B
> elements and patching existing A.B element should not change entity tag o=
f
> the parent A element, instead given B child element should get new value =
of
> it's own Etag.
>
> Thank you in advance for the answers
> --
> Regards,
> Bartek
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

--001a11c2a3b01b2c5304ff697a43
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

In our implementation, the server s=
imply updates the changed node and
all its ancestors, including t=
he <config> root. =C2=A0The draft only requires
that the et=
ag be maintained for the config root. Anything else is optional


and up to the developer.

Andy

<=
/div>


On =
Wed, Jul 30, 2014 at 5:56 AM, Bartosz B=C4=85k <bartosz.bak@amartus.=
com> wrote:


Hi all,

I'm working on a database-backed YANG datastore with RESTCONF API.

Currently I'm dealing with entity tag feature and I have a problem with=
 spec interpretation in this area.

Let me explain my concerns on a below example:

Suppose I have the following model:



module leafrefs {

=C2=A0 namespace "h=
ttp://com/example/A";

=C2=A0 prefix test;

=C2=A0 list A {

=C2=A0 =C2=A0leaf a-key {type string;}

=C2=A0 =C2=A0leaf a-property {type string;}

=C2=A0 =C2=A0key a-key;

=C2=A0 =C2=A0container Test {

=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf test {type string;}

=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf test2 {type string;}

=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf test3 {type string;}

=C2=A0 =C2=A0}

=C2=A0 =C2=A0leaf

=C2=A0 =C2=A0list B {

=C2=A0 =C2=A0 =C2=A0leaf b-key {type string;}

=C2=A0 =C2=A0 =C2=A0leaf b-property {type string;}

=C2=A0 =C2=A0 =C2=A0key b;

=C2=A0 =C2=A0}

=C2=A0 }

}



So my question is whether there should by only single ETag assigned to the =
whole data tree instance (to each "A" root element) and then each=
 data modification to that tree, like :

a). modifying A.a-property,

b). Modifying container property A.Test.test

c). Adding new B =C2=A0to the A.b list,

d). Patching existing A.B element.

e). removing existing A.B element.

changes the entity tag to the new unique value?



Or maybe system should maintain separate entity tags =C2=A0for every A and =
B elements and patching existing A.B element should not change entity tag o=
f the parent A element, instead given B child element should get new value =
of it's own Etag.




Thank you in advance for the answers

-- 

Regards,

Bartek



_______________________________________________

Netconf mailing list

Netconf@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/netconf





--001a11c2a3b01b2c5304ff697a43--


From nobody Wed Jul 30 07:58:46 2014
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8ED1A0173 for ; Wed, 30 Jul 2014 07:58:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.476
X-Spam-Level: 
X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 Ec9R_fvUJEgJ for ; Wed, 30 Jul 2014 07:58:33 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D77DB1A017A for ; Wed, 30 Jul 2014 07:58:32 -0700 (PDT)
X-AuditID: c1b4fb2d-f798a6d000000e9b-69-53d908166a6f
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id AD.1E.03739.61809D35; Wed, 30 Jul 2014 16:58:31 +0200 (CEST)
Received: from [159.107.209.124] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.174.1; Wed, 30 Jul 2014 16:58:29 +0200
Message-ID: <53D90815.3080905@ericsson.com>
Date: Wed, 30 Jul 2014 16:58:29 +0200
From: Balazs Lengyel 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Andy Bierman , Xiang Li 
References: <1406560309.12287.21.camel@ksekera-fedora>  <1406561507.12287.24.camel@ksekera-fedora>  <1406619859.12287.31.camel@ksekera-fedora>  <53D7B316.8020903@ericsson.com>  <1406646178.21825.6.camel@ksekera-fedora> <53D7BFE2.9080003@seguesoft.com> <1406649697.21825.11.camel@ksekera-fedora> <53D7CEC0.4020300@seguesoft.com> 
In-Reply-To: 
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM+Jvja44x81gg/utjBYPjsxit5i66Tar xbdNf5gdmD2WLPnJ5PFwSQeLR0v/RZYA5igum5TUnMyy1CJ9uwSujIdfT7AVHHzNWHFrx0vG BsbP0xm7GDk5JARMJM4fameFsMUkLtxbz9bFyMUhJHCUUeLzggYoZy2jxP/ZPWAdvALaEqeP HmAHsVkEVCVmbZ7FDGKzCRhJTO0/zwJiiwpESdy51M8KUS8ocXLmE7C4iIC7RGf3Z7B6ZgFN ibV/P4LZwgJWErO/HYZaNodV4sbPyWAJToFAiY39l6AadCUu/J/CAmHLS2x/OwcsLiSgIfHw wl/WCYyCs5Dsm4WkZRaSlgWMzKsYRYtTi4tz042M9VKLMpOLi/Pz9PJSSzYxAkP54JbfujsY V792PMQowMGoxMObIHkjWIg1say4MvcQozQHi5I476Jz84KFBNITS1KzU1MLUovii0pzUosP MTJxcEo1MLo3Pg9fuf3kvvPzROTbcosT0/6e6FjRGB8+W/Fr9ZR7bgrrj09lXzC1I2mGSlpf W2nSlBuzlvWcKFebMpfbtvDoCYUb8zw1RfU9/ifpvVd9zSk0mfet6ZUbj5IsrtulZ7ncqnBT On/09VuBLXPurX9b/I7Tv25DRCbDSc5XJuv3Gxv3pgY7CCixFGckGmoxFxUnAgAvif5ERgIA AA==
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Xn8nK9iHafWAAmBGZfcKDmNK0Ew
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] edit-config operation inconsistency
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 14:58:39 -0000


  
    
  
  
    I would vote for errata on RFC 6241 as Andy described.

    Even if the inheritance is IMHO the XML way and thus natural, the
    effect of the default operation is missing from the paragraph.

    Balazs

    

    
On 2014-07-30 04:18, Andy Bierman
      wrote:

    

    

      
      

        
Hi,

        


        

        


        

        

          
I know the intent was that the operation attribute was
            for the entire sub-tree until explicitly

          
changed.

          


          

          

            
         If the "operation" attribute is not specified, the
         configuration is merged into the configuration datastore.

          

          


          

          
The preceding text on page 37 is incomplete.

          
Look further down on page 38 (default-operation
            parameter)

          

            

          

          

            
         default-operation:  Selects the default operation (as described in
         the "operation" attribute) for this <edit-config> request.  The
         default value for the <default-operation> parameter is "merge".

          

          
 

          
Obviously the text on page 37 is incomplete because the
            default-operation overrides "merge".

          

          
It is very common to use default-operation="none" to make
            sure the target resource already exists

          
when doing an update.

          


          

          
The text on page 37 needs to be updated somehow (as
            errata).

          
I don't think we agree on the text yet, but here is an
            attempt

          


          

          
RFC 6241, sec 7.2, para 6:

          


          

          
OLD:

          


          

          

            
         If the "operation" attribute is not specified, the
         configuration is merged into the configuration datastore.

          

          


          

          


          

          
NEW:

          


          

          

            
         If the "operation" attribute is not specified, then
         the operation applied to the parent data node of the configuration
         is used. If no parent data node is available, then the 'default-operation' value is used.

            
        

          

          
Andy

          


          

          


          

          

          
On Tue, Jul 29, 2014 at 9:41 AM,
            Xiang Li <xiangli@seguesoft.com>
            wrote:

            

              
 

                
On 7/29/2014 11:01 AM, Klement Sekera -X (ksekera -
                  Pantheon Technologies SRO at Cisco) wrote:

                

                

                  
On Tue, 2014-07-29 at 10:38 -0500, Xiang Li wrote:


                  

                    
On 7/29/2014 10:03 AM, Klement Sekera -X (ksekera - Pantheon 
Technologies SRO at Cisco) wrote:


                    

                      
On Tue, 2014-07-29 at 07:54 -0700, Andy Bierman wrote:


                      

                        
On Tue, Jul 29, 2014 at 7:43 AM, Balazs Lengyel <balazs.lengyel@ericsson.com


                        

                          
wrote:
  Hello,
I always tought the operation attribute is inherited.



                        

                        
This is how everybody implements it, and what we intended (pre-4741).
Otherwise, would a "replace" operation for some arbitrary subtree
require nc:operation="replace" in every replacement descendant node?


Andy



                      

                      
Well if the default-operation is unchanged, then

<container operation="replace">
  <leaf/>
</container>

works perfectly fine if the operation for <leaf> is assumed to be a
"merge". First, the server removes the existing <container>, replaces it
with empty one and then merges the <leaf> in.

 From this point of view, "merge" on child is compatible with "create" or
"replace" on parent.

I don't see any sentence in the RFC which says that the operation is
inherited.


                    

                    
RFC6243


  With-defaults Capability for NETCONF may help clarify wh "effective
  operation" means in an "edit-config":



        4.5.2 <http://tools.ietf.org/html/rfc6243#section-4.5.2>.
        <edit-config> Operation

...

If the 'default' attribute is present, then the effective operation
    for the target data node MUST be 'create', 'merge', or 'replace'.  If
    not, then the server MUST return an <rpc-error> response with an
    'invalid-value' error-tag.  For example, if 'create' is the effective
    operation, then the create request must be valid on its own (e.g.,
    current data node MUST NOT exist).  The procedure for determining the
    effective operation is defined in [RFC6241  <http://tools.ietf.org/html/rfc6241>].  I*t is derived from the
    'default-operation' parameter and/or any operation attributes that
    are present in the data node or any of its ancestor nodes, within the
    <edit-config> request.*

In other words the "operation" attribute has a "scope", that is, it applies
to the nested nodes, until is is redefined. This is logical too.


                  

                  
side-note: not every netconf server must support with-defaults
capability

                

                

                The point is not about whether a sever supports "
                with-defaults capability". The paragraph

                I quoted simply helps us see the  NETCONF protocol
                authors' intention.

                

                

                  
It says that the operation is derived from default-operation and/or any
operation attributes present. 

                

                

                To be precise, RFC6243 says:

                

                
 It is derived from the 'default-operation' parameter and/or any operation attributes that
   are present in the data node or any of its ancestor nodes, within the
   <edit-config> request.

Notice the "ancestor nodes" wording.



                

                

                  
Now RFC 6241 says:

      default-operation:  Selects the default operation (as described in
         the "operation" attribute) for this <edit-config> request.  The
         default value for the <default-operation> parameter is "merge".

so whenever a node does not have an operation attribute, this clause
forces the server to operate as if it was "merge", if not set to other
value.

                

                

                But if there is "operation" attribute specified in
                itself or any parent node then the effective

                operation is not "merge" anymore.

                

                

                  
 I think this is prevents any inheritance logic.


                

                

                I don't see why the sentence above prevents any
                inheritance. 

                

                RFC6241 says:

                

                
   operation:  Elements in the <config> subtree MAY contain an
         "operation" attribute, which belongs to the NETCONF namespace
         defined in Section 3.1.  The attribute identifies the point in
         the configuration to perform the operation and MAY appear on
         multiple elements throughout the <config> subtree.


Notice the "point" wording used here. In other words "operation" identifies
a point (a subtree) where the config data should be applied. My understanding
is that it does not make sense if the "point" means the "element" here. 

Perhaps it could be clearer if it were written as " the attribute identifies 
the point and below in the configuration...".


              

            

            


            

            


            

            

              

                
--Xiang


              

            

            


            

            

              

                

                  

                    
--Xiang Li




                    

                      

                        

                          
Inherited in a sense that an XML element actually contains/includes all
sub-elements under it. So creating/deleting/merging the element means
creating/deleting/merging all its contents as well. So unless you later
override this with more specific instructions for one of the contained
elements it should be valid for the complete element with all its content.

If operation is not inheritable we have some interesting cases:
- your examples
- default operation=none and I want to create a sizeable subtree. I have
to place the merge/create operation on every node. Don't like it, makes
none-unusable except for delete/remove.
Lets say we have the following data model:

routing
   +--static-routing
   |   +--route [routeId]
   |        +--routeId 			ipprefix
   |        +--path-to-destination 	[nexthop]
   |            +--nextHop 		ipAddress
   |            +--outgoingInterface   	string
                +--bfdActive		boolean

I want to create a static route with all its sub-elements but only if the
static-routing presence container exists (static routing is
allowed/enabled).
<default-operation>none</default-operation>
<config>
    <static-routing>  --- this will check that static routing exists.
       <route operation="create">  --this will create the interface
          <routeid>1.1.1.1/24</routeid>   -- I don't want to put
operation=create on all further nodes 5 times or more depending on the
number of paths
          <path-to-destination>
             <nextHop>1.1.1.5</nextHop>
             <outgoingInterface>eth0</outgoingInterface>
             <bfdActive>true</bfdActive>
          </path-to-destination>
       </route>
    </static-routing>
</config>

  This was very nice and logical. I hope it still works.
regards Balazs

On 2014-07-29 14:17, Andy Bierman wrote:




On Tue, Jul 29, 2014 at 12:44 AM, Klement Sekera -X (ksekera - Pantheon
Technologies SRO at Cisco) <ksekera@cisco.com> wrote:



                          

                            
On Mon, 2014-07-28 at 08:43 -0700, Andy Bierman wrote:


                            

                              
On Mon, Jul 28, 2014 at 8:31 AM, Klement Sekera -X (ksekera - Pantheon
Technologies SRO at Cisco) <ksekera@cisco.com> wrote:



                              

                                
On Mon, 2014-07-28 at 08:22 -0700, Andy Bierman wrote:


                                

                                  
On Mon, Jul 28, 2014 at 8:11 AM, Klement Sekera -X (ksekera -


                                

                              

                            

                            
Pantheon


                            

                              

                                

                                  
Technologies SRO at Cisco) <ksekera@cisco.com> wrote:



                                  

                                    
Hi all,

we are currently debating an issue we found and would like to


                                  

                                

                              

                            

                            
have some


                            

                              

                                

                                  

                                    
clarification. Netconf RFC says that the edit-config operation


                                  

                                

                              

                            

                            
which


                            

                              

                                

                                  

                                    
contains multiple sub-operations on the same data is undefined.

so when considering this request:

<edit-config>
<target><candidate/></target>
<config>
  <container operation="delete">
   <leaf operation="create"/>
  </container>
</config>
</edit-config>

the outcome is undefined, since the client wants do delete


                                  

                                

                              

                            

                            
container


                            

                              

                                

                                  

                                    
<container>, while simultaneously creating <leaf> which is part of
<container>.




                                  

                                  
It is defined.
Does the node /container exist in the target datastore?
If yes, then the create operation on /container/leaf MUST fail.
If no, then the delete operation on /container MUST fail.


                                

                                
what if /container exists but /container/leaf does not? this way both
sub-operations could be performed



                              

                              
not really. If implemented correctly then if the delete on /container
succeeds,
then all its descendants are also deleted.  The result in the target
datastore cannot
possibly complete both a delete on an ancestor and create of a


                            

                            
descendant


                            

                              
in the same edit. Our server returns an error because it cannot honor
both requests.



                            

                            
I believe that this is the part where

       If the <edit-config> operation contains multiple sub-operations
       that apply to the same conceptual node in the underlying data
       model, then the result of the operation is undefined (i.e.,
       outside the scope of the NETCONF protocol).

comes into play. Exactly as you say, target datastore cannot complete
both the deletion and creation, since both operate on the same data but
rule each other out.



                            

                              

                                

                                  

                                    
Now, when considering a simple list deletion:

<edit-config>
<target><candidate/></target>
<config>
  <list operation="delete">
   <key-node>key-value</key-node>
  </list>
</config>
</edit-config>

and rigorously reading the RFC regarding operation and
default-operation, the operation attribute for <key-node> is


                                  

                                

                              

                            

                            
"merge",


                            

                              

                                

                                  

                                    
thus, technically, this edit-config operation operates on the


                                  

                                

                                
<key-node>


                                

                                  

                                    
twice:



                                  

                                  
The operation is inherited from its parent if no "nc:operation"
attribute is specified. The keys need to be present to specify the


                                

                              

                            

                            
list


                            

                              

                                

                                  
node to be deleted.


                                

                                
can you point to the paragraph in netconf RFC which says that the
operation is inherited?




                              

                              
the delete operation on the /container node is for the container and


                            

                            
all its


                            

                              
descendants.  That is how it is inherited. I should have said


                            

                            
"effective"


                            

                              
operation
instead of "inherited".


                            

                            
       operation:  Elements in the <config> subtree MAY contain an
          "operation" attribute, which belongs to the NETCONF namespace
          defined in Section 3.1.  The attribute identifies the point in
          the configuration to perform the operation and MAY appear on
          multiple elements throughout the <config> subtree.

          If the "operation" attribute is not specified, the
          configuration is merged into the configuration datastore.

in this case, the "operation" attribute for <key-node> is not specified.
So the provided example request is equivalent to this request:

<list operation="delete">
  <key-node operation="merge">key-value</key-node>
</list>

so basically it's the same as above - there is a request do delete
<list> while creating and/or keeping <key-node> around - both cannot be
done. I cannot find any exception in the RFC for list/key-node combo
case.




                          

                          
  Perhaps 1 new sentence (After the 1 about no attribute=merge):

    If the operation attribute is not present for a key leaf node, and
   the edit operation for the parent node is "delete" or "remove",
   then the operation for the key leaf node is the same as its parent node.


  Andy





                          

                            

                              

                                

                                  

                                    
1.) deleting the value via deletion of the list entity <list>
2.) merging in a new value via "merge" on the <key-node>


The RFC has <default-operation>none</default-operation> in all


                                  

                                

                              

                            

                            
deletion


                            

                              

                                

                                  

                                    
examples, which makes us believe that indeed when processing the
mentioned request, the <key-node>'s operation would be "merge"


                                  

                                

                              

                            

                            
and thus


                            

                              

                                

                                  

                                    
the operation undefined.

Is this how it's supposed to be or are we reading it wrong?




                                  

                                  
the latter




                                  

                                    
Thanks,
Klement
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf



                                  

                                

                              

                              
Andy


                            

                          

                          
_______________________________________________
Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf


--
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com




                        

                      

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


                    

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


                  

                   

                 

                    
-- 
--
Xiang Li, 
Seguesoft, Champaign, IL
(217) 721-5341


                  

              

              _______________________________________________

              Netconf mailing list

              Netconf@ietf.org

              https://www.ietf.org/mailman/listinfo/netconf

              

            

          

          

        

      

      

      

      

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


    

    

    
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


  



From nobody Wed Jul 30 08:02:05 2014
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14FF81A017C for ; Wed, 30 Jul 2014 08:01:54 -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, NORMAL_HTTP_TO_IP=0.001] autolearn=ham
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 1rZVNHlCB9-d for ; Wed, 30 Jul 2014 08:01:49 -0700 (PDT)
Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (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 0D0351A0195 for ; Wed, 30 Jul 2014 08:01:49 -0700 (PDT)
Received: from nene.ripe.net ([193.0.23.10]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XCVNu-0000RS-8Z; Wed, 30 Jul 2014 17:01:44 +0200
Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=macintosh-6.fritz.box) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1XCVNu-0004Dd-3N; Wed, 30 Jul 2014 17:01:42 +0200
Message-ID: <53D908D5.6090108@bwijnen.net>
Date: Wed, 30 Jul 2014 17:01:41 +0200
From: "Bert Wijnen (IETF)" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Balazs Lengyel ,  Andy Bierman , Xiang Li 
References: <1406560309.12287.21.camel@ksekera-fedora>  <1406561507.12287.24.camel@ksekera-fedora>  <1406619859.12287.31.camel@ksekera-fedora>  <53D7B316.8020903@ericsson.com>  <1406646178.21825.6.camel@ksekera-fedora> <53D7BFE2.9080003@seguesoft.com> <1406649697.21825.11.camel@ksekera-fedora> <53D7CEC0.4020300@seguesoft.com>  <53D90815.3080905@ericsson.com>
In-Reply-To: <53D90815.3080905@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points:   -2.9 points pts rule name              description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP 0.0 NORMAL_HTTP_TO_IP      URI: URI host has a public dotted-decimal IPv4 address -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4f2b9fb66870a119c24edee5617618546
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/YiPRlD869v4ZdwZ6hQSrukQ9XMU
Cc: "netconf@ietf.org" 
Subject: Re: [Netconf] edit-config operation inconsistency
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Jul 2014 15:01:54 -0000

So Andy, why don't you file a formal erratum with the RFC-Editor,
then we get to automagially process it.

Bert

On 30/07/14 16:58, Balazs Lengyel wrote:
> I would vote for errata on RFC 6241 as Andy described.
> Even if the inheritance is IMHO the XML way and thus natural, the effect of the default operation is missing from the paragraph.
> Balazs
>
> On 2014-07-30 04:18, Andy Bierman wrote:
>> Hi,
>>
>>
>> I know the intent was that the operation attribute was for the entire sub-tree until explicitly
>> changed.
>>
>>           If the "operation" attribute is not specified, the
>>           configuration is merged into the configuration datastore.
>>
>> The preceding text on page 37 is incomplete.
>> Look further down on page 38 (default-operation parameter)
>>
>>           default-operation:  Selects the default operation (as described in
>>           the "operation" attribute) for this  request.  The
>>           default value for the  parameter is "merge".
>> Obviously the text on page 37 is incomplete because the default-operation overrides "merge".
>> It is very common to use default-operation="none" to make sure the target resource already exists
>> when doing an update.
>>
>> The text on page 37 needs to be updated somehow (as errata).
>> I don't think we agree on the text yet, but here is an attempt
>>
>> RFC 6241, sec 7.2, para 6:
>>
>> OLD:
>>
>>           If the "operation" attribute is not specified, the
>>           configuration is merged into the configuration datastore.
>>
>>
>> NEW:
>>
>>           If the "operation" attribute is not specified, then
>>           the operation applied to the parent data node of the configuration
>>           is used.If no parent data node is available, then the 'default-operation'value is used.
>>
>> Andy
>>
>>
>>
>> On Tue, Jul 29, 2014 at 9:41 AM, Xiang Li > wrote:
>>
>>
>>     On 7/29/2014 11:01 AM, Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco) wrote:
>>>     On Tue, 2014-07-29 at 10:38 -0500, Xiang Li wrote:
>>>>     On 7/29/2014 10:03 AM, Klement Sekera -X (ksekera - Pantheon
>>>>     Technologies SRO at Cisco) wrote:
>>>>>     On Tue, 2014-07-29 at 07:54 -0700, Andy Bierman wrote:
>>>>>>     On Tue, Jul 29, 2014 at 7:43 AM, Balazs Lengyel 
>>>>>>>     wrote:
>>>>>>>        Hello,
>>>>>>>     I always tought the operation attribute is inherited.
>>>>>>>
>>>>>>     This is how everybody implements it, and what we intended (pre-4741).
>>>>>>     Otherwise, would a "replace" operation for some arbitrary subtree
>>>>>>     require nc:operation="replace" in every replacement descendant node?
>>>>>>
>>>>>>
>>>>>>     Andy
>>>>>>
>>>>>     Well if the default-operation is unchanged, then
>>>>>
>>>>>     
>>>>>        
>>>>>     
>>>>>
>>>>>     works perfectly fine if the operation for  is assumed to be a
>>>>>     "merge". First, the server removes the existing , replaces it
>>>>>     with empty one and then merges the  in.
>>>>>
>>>>>       From this point of view, "merge" on child is compatible with "create" or
>>>>>     "replace" on parent.
>>>>>
>>>>>     I don't see any sentence in the RFC which says that the operation is
>>>>>     inherited.
>>>>     RFC6243
>>>>
>>>>
>>>>        With-defaults Capability for NETCONF may help clarify wh "effective
>>>>        operation" means in an "edit-config":
>>>>
>>>>
>>>>
>>>>              4.5.2  .
>>>>               Operation
>>>>
>>>>     ...
>>>>
>>>>     If the 'default' attribute is present, then the effective operation
>>>>          for the target data node MUST be 'create', 'merge', or 'replace'.  If
>>>>          not, then the server MUST return an  response with an
>>>>          'invalid-value' error-tag.  For example, if 'create' is the effective
>>>>          operation, then the create request must be valid on its own (e.g.,
>>>>          current data node MUST NOT exist).  The procedure for determining the
>>>>          effective operation is defined in [RFC6241  ].  I*t is derived from the
>>>>          'default-operation' parameter and/or any operation attributes that
>>>>          are present in the data node or any of its ancestor nodes, within the
>>>>           request.*
>>>>
>>>>     In other words the "operation" attribute has a "scope", that is, it applies
>>>>     to the nested nodes, until is is redefined. This is logical too.
>>>     side-note: not every netconf server must support with-defaults
>>>     capability
>>
>>     The point is not about whether a sever supports " with-defaults capability". The paragraph
>>     I quoted simply helps us see the  NETCONF protocol authors' intention.
>>
>>>     It says that the operation is derived from default-operation and/or any
>>>     operation attributes present.
>>
>>     To be precise, RFC6243 says:
>>
>>       It is derived from the 'default-operation' parameter and/or any operation attributes that
>>         are present in the data node or any of its ancestor nodes, within the
>>          request.
>>
>>     Notice the "ancestor nodes" wording.
>>
>>
>>>     Now RFC 6241 says:
>>>
>>>            default-operation:  Selects the default operation (as described in
>>>               the "operation" attribute) for this  request.  The
>>>               default value for the  parameter is "merge".
>>>
>>>     so whenever a node does not have an operation attribute, this clause
>>>     forces the server to operate as if it was "merge", if not set to other
>>>     value.
>>
>>     But if there is "operation" attribute specified in itself or any parent node then the effective
>>     operation is not "merge" anymore.
>>
>>>       I think this is prevents any inheritance logic.
>>
>>     I don't see why the sentence above prevents any inheritance.
>>
>>     RFC6241 says:
>>
>>         operation:  Elements in the  subtree MAY contain an
>>               "operation" attribute, which belongs to the NETCONF namespace
>>               defined inSection 3.1  .  The attribute identifies the point in
>>               the configuration to perform the operation and MAY appear on
>>               multiple elements throughout the  subtree.
>>
>>
>>     Notice the "point" wording used here. In other words "operation" identifies
>>     a point (a subtree) where the config data should be applied. My understanding
>>     is that it does not make sense if the "point" means the "element" here.
>>
>>     Perhaps it could be clearer if it were written as " the attribute identifies
>>     the point and below in the configuration...".
>>
>>
>>
>>     --Xiang
>>
>>
>>>>     --Xiang Li
>>>>
>>>>
>>>>>>>     Inherited in a sense that an XML element actually contains/includes all
>>>>>>>     sub-elements under it. So creating/deleting/merging the element means
>>>>>>>     creating/deleting/merging all its contents as well. So unless you later
>>>>>>>     override this with more specific instructions for one of the contained
>>>>>>>     elements it should be valid for the complete element with all its content.
>>>>>>>
>>>>>>>     If operation is not inheritable we have some interesting cases:
>>>>>>>     - your examples
>>>>>>>     - default operation=none and I want to create a sizeable subtree. I have
>>>>>>>     to place the merge/create operation on every node. Don't like it, makes
>>>>>>>     none-unusable except for delete/remove.
>>>>>>>     Lets say we have the following data model:
>>>>>>>
>>>>>>>     routing
>>>>>>>         +--static-routing
>>>>>>>         |   +--route [routeId]
>>>>>>>         |        +--routeId 			ipprefix
>>>>>>>         |        +--path-to-destination 	[nexthop]
>>>>>>>         |            +--nextHop 		ipAddress
>>>>>>>         |            +--outgoingInterface   	string
>>>>>>>                      +--bfdActive		boolean
>>>>>>>
>>>>>>>     I want to create a static route with all its sub-elements but only if the
>>>>>>>     static-routing presence container exists (static routing is
>>>>>>>     allowed/enabled).
>>>>>>>     none
>>>>>>>     
>>>>>>>            --- this will check that static routing exists.
>>>>>>>               --this will create the interface
>>>>>>>                1.1.1.1/24     -- I don't want to put
>>>>>>>     operation=create on all further nodes 5 times or more depending on the
>>>>>>>     number of paths
>>>>>>>                
>>>>>>>                   1.1.1.5
>>>>>>>                   eth0
>>>>>>>                   true
>>>>>>>                
>>>>>>>             
>>>>>>>          
>>>>>>>     
>>>>>>>
>>>>>>>        This was very nice and logical. I hope it still works.
>>>>>>>     regards Balazs
>>>>>>>
>>>>>>>     On 2014-07-29 14:17, Andy Bierman wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>     On Tue, Jul 29, 2014 at 12:44 AM, Klement Sekera -X (ksekera - Pantheon
>>>>>>>     Technologies SRO at Cisco)    wrote:
>>>>>>>
>>>>>>>>     On Mon, 2014-07-28 at 08:43 -0700, Andy Bierman wrote:
>>>>>>>>>     On Mon, Jul 28, 2014 at 8:31 AM, Klement Sekera -X (ksekera - Pantheon
>>>>>>>>>     Technologies SRO at Cisco)    wrote:
>>>>>>>>>
>>>>>>>>>>     On Mon, 2014-07-28 at 08:22 -0700, Andy Bierman wrote:
>>>>>>>>>>>     On Mon, Jul 28, 2014 at 8:11 AM, Klement Sekera -X (ksekera -
>>>>>>>>     Pantheon
>>>>>>>>>>>     Technologies SRO at Cisco)    wrote:
>>>>>>>>>>>
>>>>>>>>>>>>     Hi all,
>>>>>>>>>>>>
>>>>>>>>>>>>     we are currently debating an issue we found and would like to
>>>>>>>>     have some
>>>>>>>>>>>>     clarification. Netconf RFC says that the edit-config operation
>>>>>>>>     which
>>>>>>>>>>>>     contains multiple sub-operations on the same data is undefined.
>>>>>>>>>>>>
>>>>>>>>>>>>     so when considering this request:
>>>>>>>>>>>>
>>>>>>>>>>>>     
>>>>>>>>>>>>     
>>>>>>>>>>>>     
>>>>>>>>>>>>        
>>>>>>>>>>>>         
>>>>>>>>>>>>        
>>>>>>>>>>>>     
>>>>>>>>>>>>     
>>>>>>>>>>>>
>>>>>>>>>>>>     the outcome is undefined, since the client wants do delete
>>>>>>>>     container
>>>>>>>>>>>>     , while simultaneously creating  which is part of
>>>>>>>>>>>>     .
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>     It is defined.
>>>>>>>>>>>     Does the node /container exist in the target datastore?
>>>>>>>>>>>     If yes, then the create operation on /container/leaf MUST fail.
>>>>>>>>>>>     If no, then the delete operation on /container MUST fail.
>>>>>>>>>>     what if /container exists but /container/leaf does not? this way both
>>>>>>>>>>     sub-operations could be performed
>>>>>>>>>>
>>>>>>>>>     not really. If implemented correctly then if the delete on /container
>>>>>>>>>     succeeds,
>>>>>>>>>     then all its descendants are also deleted.  The result in the target
>>>>>>>>>     datastore cannot
>>>>>>>>>     possibly complete both a delete on an ancestor and create of a
>>>>>>>>     descendant
>>>>>>>>>     in the same edit. Our server returns an error because it cannot honor
>>>>>>>>>     both requests.
>>>>>>>>>
>>>>>>>>     I believe that this is the part where
>>>>>>>>
>>>>>>>>             If the  operation contains multiple sub-operations
>>>>>>>>             that apply to the same conceptual node in the underlying data
>>>>>>>>             model, then the result of the operation is undefined (i.e.,
>>>>>>>>             outside the scope of the NETCONF protocol).
>>>>>>>>
>>>>>>>>     comes into play. Exactly as you say, target datastore cannot complete
>>>>>>>>     both the deletion and creation, since both operate on the same data but
>>>>>>>>     rule each other out.
>>>>>>>>
>>>>>>>>>>>>     Now, when considering a simple list deletion:
>>>>>>>>>>>>
>>>>>>>>>>>>     
>>>>>>>>>>>>     
>>>>>>>>>>>>     
>>>>>>>>>>>>        
>>>>>>>>>>>>         key-value
>>>>>>>>>>>>        
>>>>>>>>>>>>     
>>>>>>>>>>>>     
>>>>>>>>>>>>
>>>>>>>>>>>>     and rigorously reading the RFC regarding operation and
>>>>>>>>>>>>     default-operation, the operation attribute for  is
>>>>>>>>     "merge",
>>>>>>>>>>>>     thus, technically, this edit-config operation operates on the
>>>>>>>>>>     
>>>>>>>>>>>>     twice:
>>>>>>>>>>>>
>>>>>>>>>>>     The operation is inherited from its parent if no "nc:operation"
>>>>>>>>>>>     attribute is specified. The keys need to be present to specify the
>>>>>>>>     list
>>>>>>>>>>>     node to be deleted.
>>>>>>>>>>     can you point to the paragraph in netconf RFC which says that the
>>>>>>>>>>     operation is inherited?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>     the delete operation on the /container node is for the container and
>>>>>>>>     all its
>>>>>>>>>     descendants.  That is how it is inherited. I should have said
>>>>>>>>     "effective"
>>>>>>>>>     operation
>>>>>>>>>     instead of "inherited".
>>>>>>>>             operation:  Elements in the  subtree MAY contain an
>>>>>>>>                "operation" attribute, which belongs to the NETCONF namespace
>>>>>>>>                defined in Section 3.1.  The attribute identifies the point in
>>>>>>>>                the configuration to perform the operation and MAY appear on
>>>>>>>>                multiple elements throughout the  subtree.
>>>>>>>>
>>>>>>>>                If the "operation" attribute is not specified, the
>>>>>>>>                configuration is merged into the configuration datastore.
>>>>>>>>
>>>>>>>>     in this case, the "operation" attribute for  is not specified.
>>>>>>>>     So the provided example request is equivalent to this request:
>>>>>>>>
>>>>>>>>     
>>>>>>>>        key-value
>>>>>>>>     
>>>>>>>>
>>>>>>>>     so basically it's the same as above - there is a request do delete
>>>>>>>>      while creating and/or keeping  around - both cannot be
>>>>>>>>     done. I cannot find any exception in the RFC for list/key-node combo
>>>>>>>>     case.
>>>>>>>>
>>>>>>>>
>>>>>>>        Perhaps 1 new sentence (After the 1 about no attribute=merge):
>>>>>>>
>>>>>>>          If the operation attribute is not present for a key leaf node, and
>>>>>>>         the edit operation for the parent node is "delete" or "remove",
>>>>>>>         then the operation for the key leaf node is the same as its parent node.
>>>>>>>
>>>>>>>
>>>>>>>        Andy
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>     1.) deleting the value via deletion of the list entity 
>>>>>>>>>>>>     2.) merging in a new value via "merge" on the 
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>     The RFC has none in all
>>>>>>>>     deletion
>>>>>>>>>>>>     examples, which makes us believe that indeed when processing the
>>>>>>>>>>>>     mentioned request, the 's operation would be "merge"
>>>>>>>>     and thus
>>>>>>>>>>>>     the operation undefined.
>>>>>>>>>>>>
>>>>>>>>>>>>     Is this how it's supposed to be or are we reading it wrong?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>     the latter
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>     Thanks,
>>>>>>>>>>>>     Klement
>>>>>>>>>>>>     _______________________________________________
>>>>>>>>>>>>     Netconf mailing list
>>>>>>>>>>>>     Netconf@ietf.org  
>>>>>>>>>>>>     https://www.ietf.org/mailman/listinfo/netconf
>>>>>>>>>>>>
>>>>>>>>>     Andy
>>>>>>>     _______________________________________________
>>>>>>>     Netconf mailinglistNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf  
>>>>>>>
>>>>>>>
>>>>>>>     --
>>>>>>>     Balazs Lengyel                       Ericsson Hungary Ltd.
>>>>>>>     Senior Specialist
>>>>>>>     ECN: 831 7320                        Tel: +36-1-437-7320
>>>>>>>     Mobile: +36-70-330-7909              email:Balazs.Lengyel@ericsson.com  
>>>>>>>
>>>>>>>
>>>>>     _______________________________________________
>>>>>     Netconf mailing list
>>>>>     Netconf@ietf.org  
>>>>>     https://www.ietf.org/mailman/listinfo/netconf
>>>>     _______________________________________________
>>>>     Netconf mailing list
>>>>     Netconf@ietf.org  
>>>>     https://www.ietf.org/mailman/listinfo/netconf
>>
>>     --
>>     --
>>     Xiang Li,
>>     Seguesoft, Champaign, IL
>>     (217) 721-5341
>>
>>
>>     _______________________________________________
>>     Netconf mailing list
>>     Netconf@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/netconf
>>
>>
>>
>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>
> --
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> ECN: 831 7320                        Tel: +36-1-437-7320
> Mobile: +36-70-330-7909              email:Balazs.Lengyel@ericsson.com
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>


From nobody Thu Jul 31 06:14:44 2014
Return-Path: 
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B8D1B27CD for ; Thu, 31 Jul 2014 06:14:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 avDUj84jIlQO for ; Thu, 31 Jul 2014 06:14:40 -0700 (PDT)
Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (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 C05A81B27B2 for ; Thu, 31 Jul 2014 06:14:40 -0700 (PDT)
Received: from nene.ripe.net ([193.0.23.10]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XCqBq-00049l-It; Thu, 31 Jul 2014 15:14:39 +0200
Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest92.guestnet.ripe.net) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1XCqBq-00072z-FX; Thu, 31 Jul 2014 15:14:38 +0200
Message-ID: <53DA413D.3060701@bwijnen.net>
Date: Thu, 31 Jul 2014 15:14:37 +0200
From: "Bert Wijnen (IETF)" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Netconf 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points:   -2.9 points pts rule name              description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4ea49df546ef779e489b9ceab9fcfad5d
Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/l9k3xkA36NMgpEE8OkJlw19zOuE
Subject: [Netconf] do we want to demo at Bits and Bytes at IETF91 (or 92) ??
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Jul 2014 13:14:42 -0000

The IETF chair wrote in his IETF90 summary:

    The third new item was the Bits-and-Bites event,
    which has been running for some years, but this time we
    had a new format and a focus topic. We had ten different
    organisations demonstrating Internet of Things solutions,
    and a lot of interested participants looking at the demos.
    We will be continuing the Bits-and-Bites event series in
    future IETFs in the same fashion – please propose focus
    topics that you would like to see.

We could propose demos of products in the NETCONF/NETMOD
space. But it would mean that we need willing participants
(basically sponsors). IIRC it is 10K per vendor (we
can ask specifics if people need to know before they
want to commit). And we need multiple before it makes sense
I think.

We could do generic NM so that we get potentially more
participants, but I would love the focus on NETCONF related
topics.

Bert (speaking as an individual).