From nobody Wed Jan 4 06:21:00 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBF5129586 for ; Wed, 4 Jan 2017 06:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.221 X-Spam-Level: X-Spam-Status: No, score=-16.221 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tp4pLRzBkRbG for ; Wed, 4 Jan 2017 06:20:58 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB8ED1294F0 for ; Wed, 4 Jan 2017 06:20:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2136; q=dns/txt; s=iport; t=1483539658; x=1484749258; h=from:subject:to:message-id:date:mime-version; bh=Nl3T4XoSprtDoSkFhUEdXK0twFbskV3o4kIP9wamBX4=; b=HYiU7FKYiRQU2dQ8z9qy88NQemaQKgJtgHu70E1tuIf5eMhWwlyulvcE HRkUpbS0kIPBypUrGAddBL4aAbPt632DGtwW5gr9rYYp3thYmr6rRdOOg aEptcokuWBmjRaq1Yb5Ooe/cqM2L7O8LhL9jfcPOSisGPMxCABL8Ui/XH U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CBBQBhBG1Y/xbLJq1eGwEBAQMBAQEJA?= =?us-ascii?q?QEBgzgBAQEBAX4vXY5Jo02DGoQXKogNEQECAQEBAQEBAWMohRJvBgE9Al8NCAE?= =?us-ascii?q?BiGwOkVqNTJABgiUrigkBCwElhkWCAgiKIoJeBZsJgUuFC4prgXZRhDeDJ4Y0h?= =?us-ascii?q?3+CS4d2NSKBCBYNhhI9NAGFdiuCEAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,459,1477958400"; d="scan'208,217";a="648495006" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jan 2017 14:20:53 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v04EKrTH010122 for ; Wed, 4 Jan 2017 14:20:53 GMT From: Benoit Claise To: NETMOD Working Group Message-ID: <8b73b6d9-eebf-7448-154c-2e0c4d37f6d6@cisco.com> Date: Wed, 4 Jan 2017 15:20:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------CCC5951FDCFDD42CD69A1A3E" Archived-At: Subject: [netmod] The different YANG validators updated X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 14:20:59 -0000 This is a multi-part message in MIME format. --------------CCC5951FDCFDD42CD69A1A3E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, At the last IETF hackathon, I included two new YANG validators on claise.be: yangdump-pro and yanglint Today, I updated the different validator versions. pyang: version 1.7.1 confdc/ version 5.10.4 yangdump-pro: version 16.10-3 yanglint: version 0.11.94 Some of the YANG validation issues have been fixed. Thanks to the tool developers. The graphical evolution is here . YANG module authors, please check your YANG modules for the latest warnings/errors, and update if necessary at at http://www.claise.be/IETFYANGPageCompilation.html Regards, Benoit --------------CCC5951FDCFDD42CD69A1A3E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Dear all,

At the last IETF hackathon, I included two new YANG validators on claise.be: yangdump-pro and yanglint
Today, I updated the different validator versions.
    pyang: version 1.7.1
    confdc/ version 5.10.4   
    yangdump-pro: version 16.10-3
    yanglint: version 0.11.94

Some of the YANG validation issues have been fixed. Thanks to the tool developers.
The graphical evolution is here.

YANG module authors, please check your YANG modules for the latest warnings/errors, and update if necessary at at http://www.claise.be/IETFYANGPageCompilation.html

Regards, Benoit





--------------CCC5951FDCFDD42CD69A1A3E-- From nobody Wed Jan 4 09:44:56 2017 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A61FA12969C; Wed, 4 Jan 2017 09:44:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148355189563.12985.10543703297913881204.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 09:44:55 -0800 Archived-At: Cc: netmod-chairs@ietf.org, netmod@ietf.org Subject: [netmod] netmod - New Meeting Session Request for IETF 98 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 17:44:56 -0000 A new meeting session request has just been submitted by Lou Berger, a Chair of the netmod working group. --------------------------------------------------------- Working Group Name: NETCONF Data Modeling Language Area Name: Operations and Management Area Session Requester: Lou Berger Number of Sessions: 2 Length of Session(s): 1 Hour, 2.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: netconf rtgwg Second Priority: i2rs anima isis ospf Third Priority: saag Special Requests: --------------------------------------------------------- From nobody Thu Jan 5 04:57:32 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CF412954B for ; Thu, 5 Jan 2017 04:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.621 X-Spam-Level: X-Spam-Status: No, score=-17.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vAb3JQWQSpj for ; Thu, 5 Jan 2017 04:57:30 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3669C129500 for ; Thu, 5 Jan 2017 04:57:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3538; q=dns/txt; s=iport; t=1483621050; x=1484830650; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=uuGZ2FdTq7wZogg7qxacpJi9xY9WpWANQerHyjQxfwY=; b=bg+lqN2/yFreeC4svjCbX+MFgAMl683WqjkfwH9P7Wmfr5PWN5uTvaZQ 9FIRq82A6FG4F11mSZhaUO1zoftmd2Yae8aXVVwtQAj8K55AiuQBB2s0y 2PUEn501xsuGKh1epHLOYgkahAFXmcWTAzfQSgNkU80hm2mZSvcJp6Q6V 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CfAgDFQW5Y/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzgBAQEBAX6BDI5Jk1WPfYUqggkfAQqFLkoCghgTAQIBAQEBAQE?= =?us-ascii?q?BYyiEaQEBBAEBbBsLBBQuJzAGDQYCAQGIbA6xXyuJeQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2GRYICCIJXiiwFmxCGVoptgXZRhDeDJ4Y1iAOCTId3IQE1gQ8SBxM?= =?us-ascii?q?VM4YkPTUBhiorghABAQE?= X-IronPort-AV: E=Sophos;i="5.33,321,1477958400"; d="scan'208,217";a="651364302" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jan 2017 12:57:25 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v05CvP1R020598 for ; Thu, 5 Jan 2017 12:57:25 GMT To: NETMOD Working Group References: <8b73b6d9-eebf-7448-154c-2e0c4d37f6d6@cisco.com> From: Benoit Claise Message-ID: Date: Thu, 5 Jan 2017 13:57:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <8b73b6d9-eebf-7448-154c-2e0c4d37f6d6@cisco.com> Content-Type: multipart/alternative; boundary="------------012415724C1240621335FF44" Archived-At: Subject: Re: [netmod] The different YANG validators updated X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 12:57:32 -0000 This is a multi-part message in MIME format. --------------012415724C1240621335FF44 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 1/4/2017 3:20 PM, Benoit Claise wrote: > Dear all, > > At the last IETF hackathon, I included two new YANG validators on > claise.be: yangdump-pro and yanglint > Today, I updated the different validator versions. > pyang: version 1.7.1 > confdc/ version 5.10.4 this was actually confdc version 6.3 Sorry for the confusion. Regards, Benoit > > yangdump-pro: version 16.10-3 > yanglint: version 0.11.94 > > Some of the YANG validation issues have been fixed. Thanks to the tool > developers. > The graphical evolution is here > . > > YANG module authors, please check your YANG modules for the latest > warnings/errors, and update if necessary at at > http://www.claise.be/IETFYANGPageCompilation.html > > Regards, Benoit > > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------012415724C1240621335FF44 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 1/4/2017 3:20 PM, Benoit Claise wrote:
Dear all,

At the last IETF hackathon, I included two new YANG validators on claise.be: yangdump-pro and yanglint
Today, I updated the different validator versions.
pyang: version 1.7.1
confdc/ version 5.10.4
this was actually confdc version 6.3
Sorry for the confusion.

Regards, Benoit

yangdump-pro: version 16.10-3
yanglint: version 0.11.94

Some of the YANG validation issues have been fixed. Thanks to the tool developers.
The graphical evolution is here.

YANG module authors, please check your YANG modules for the latest warnings/errors, and update if necessary at at http://www.claise.be/IETFYANGPageCompilation.html

Regards, Benoit







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

--------------012415724C1240621335FF44-- From nobody Fri Jan 6 10:04:25 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FF21295C9; Fri, 6 Jan 2017 10:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSYtFbfAqVPr; Fri, 6 Jan 2017 10:04:18 -0800 (PST) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87899128824; Fri, 6 Jan 2017 10:04:17 -0800 (PST) Received: by mail-wm0-x242.google.com with SMTP id u144so6766952wmu.0; Fri, 06 Jan 2017 10:04:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version:thread-index :content-language:disposition-notification-to; bh=il2hxBZjk7ZB4KVCTrre4FIhpssKsryxNFBaRi8T+6c=; b=UEfhIxN+KTwC3MvxAEmvAaNWc47qV1nxiwfFk0C8phS2xAUrbcvastULP1eGS4O2ns d7jZIL+2OQwvv2+7GA7WrsXVJ/SRIllPuxEpqCKgsKOwTl52KZdW7QefRDoCCq/KRh/J /x3btI6bzPOACLEimQymSC2YgbJ6DDtFI2oP0fvHL97lFnLGgalF/fUHuyOQ/3K8J8wx 8lOcylYi+u13he7PnHGDOjNU9xCaEYF7HAEsjCOcedQC4gb2LBMBDLPW1Gt0u46t1/xE xA9KCdNH2Uz32nMzGbzGjlpq0v10LXCzJmUU/77v+maL22k72Yi2YzxA7AzynGAWANvT U5Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :thread-index:content-language:disposition-notification-to; bh=il2hxBZjk7ZB4KVCTrre4FIhpssKsryxNFBaRi8T+6c=; b=julazoQsDtpalskSLIhXb2xavQZZbmki+oYYgWn+1WJwZbpMoX2Dfi7SUbWWp9IEg6 qLRjzHCVceg4nLkC7YvwhZFYOQLv/SDKk77K2vPuVypeYnR4EH6PAega0PMKO68JU+P2 AkF/IYAwycRKdldJNL/qWhvVZNRiCbjm2DzjYiQAht6D6oDKVwAKPqJeWFkoZlz1ROE9 oVMWfmIQcUdUZCzcijde6hRtbrcuemj4g6W3Mq04WYXLq1ggMRvWvWPjW2R6cWFcSJFp 7f0M4GJvWZ/tM76r1dn5XuA2VEPCHJJ/c/rsEqC/QjAroeMQsg2RGZqvdCbmjonBmijG 6AnA== X-Gm-Message-State: AIkVDXLPO7wCbCWeS+/mkTaa9GMS7bibUT5Lgw0UJJCIxRoBOponi3KToyWF6viULTphpA== X-Received: by 10.28.145.2 with SMTP id t2mr4030101wmd.23.1483725855931; Fri, 06 Jan 2017 10:04:15 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5B340C74.dip0.t-ipconnect.de. [91.52.12.116]) by smtp.gmail.com with ESMTPSA id ke6sm109931929wjb.21.2017.01.06.10.04.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Jan 2017 10:04:15 -0800 (PST) From: "Mehmet Ersue" To: "'Andy Bierman'" , "'Ladislav Lhotka'" Date: Fri, 6 Jan 2017 19:04:14 +0100 Message-ID: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0192_01D2684F.AC4565E0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdJne0TirCGAmbjyTxuK3L5tumskaw== Content-Language: de X-AVK-Virus-Check: AVA 25.9819;2DC73FAF X-AVK-Spam-Check: 1; str=0001.0A0C0205.586FDC1F.0054,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Cc: 'Netconf' , 'NetMod WG' Subject: [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: [Netconf] :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 18:04:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0192_01D2684F.AC4565E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi All, =20 [NETMOD CCed as this is relevant to the revised DS draft] =20 > > > > I wrote it already several times: I support(ed) Mehmet's = proposal to make the revised-datastores I-D informative. The document = was adopted as a Standard Track WG item although I didn't see anything = close to rough consensus during the adoption poll. > > > > > > > It appears to me that there is consensus to making this a = standards track solution. > > > > > Where is any evidence of this? > > I think there was approval in the room in Seoul, and it is being = confirmed on the mailing list. It is correct that we agreed in Seoul to start a consensus call on both = maillists for the adoption of the DT draft and executed such an adoption = call. However we did not have any decision on the intended draft status in = Seoul and did not have any agreement during the adoption call. I = explained my concerns on the currently indicated status being standard = track and did not hear any other argument. =20 It is correct that we need a standard track document for the new DS = framework - to provide a basis for other RFCs to develope. However the = current DT solution draft has not been prepared as a standard track = document nor it has standard relevant content. Such concept description = is usually prepared as an architecture document (see example in = RFC 6244). As I stated earlier I believe =E2=80=9Ca new protocol- and = language-independent standard document=E2=80=9D should be prepared = defining the generic datastore framework (based on and following the = concept in the DT solution draft). =20 IMO the intended status of the DS draft is still open and subject to = decide. =20 Regards, Mehmet =20 From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy = Bierman Sent: Wednesday, December 28, 2016 6:37 PM To: Ladislav Lhotka Cc: Netconf Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits =20 =20 =20 On Wed, Dec 28, 2016 at 1:06 AM, Ladislav Lhotka > wrote: > On 27 Dec 2016, at 19:34, Andy Bierman > wrote: > > > > On Tue, Dec 27, 2016 at 10:01 AM, Ladislav Lhotka > wrote: > > > On 27 Dec 2016, at 16:37, Juergen Schoenwaelder = > wrote: > > > > On Tue, Dec 27, 2016 at 03:47:10PM +0100, Ladislav Lhotka wrote: > >> > >>> > >>> A remote API for management applications was our original target = and > >>> this is where YANG is doing well (and we apparently still have = work to > >>> do to improve things). > >> > >> By "management application" I mean a specific implementation with a = fixed set of datastores and precise semantics. I do argue that neither = RFC 6241, nor "revised-datastores" nor any other *specific* setup of = datastores is going to work for all use cases, yet the protocols and = YANG can be pretty universal. > >> > >> We have already seen YANG being used in areas that are, strictly = speaking, not supported by 6020/7950. Rather than tolerating such uses = (which is a slippery slope), I would prefer to make them - within = reasonable limits - officially supported. > >> > > > > This is too abstract for me. What do you suggest to change in the > > revised datastore architecture? I do believe that having a number of > > well defined datastores with specific semantics is necessary for > > having interoperability. > > I wrote it already several times: I support(ed) Mehmet's proposal to = make the revised-datastores I-D informative. The document was adopted as = a Standard Track WG item although I didn't see anything close to rough = consensus during the adoption poll. > > > > It appears to me that there is consensus to making this a standards = track solution. Where is any evidence of this? =20 =20 I think there was approval in the room in Seoul, and it is being = confirmed on the mailing list. =20 =20 > > Datastores allow universal concepts about managed data to be = standardized > across multiple protocols. In a protocol, the datastore name serves = as > an input parameter value. It needs to be normative in order for a > standards-track protocol to use it. For the protocol, the RPC parameter needs to be normative, not a = particular datastore name or semantics. > > Changing standards track status never addresses real technical = problems. > I do not understand your objections or alternate proposals. I think this proposal will lead to rather significant changes to the = protocols and YANG, and their extent IMO isn't clear yet. For one, the = draft aims at moving validation from "running" to "intended". But if = "intended" is optional to implement (sec. 6.1), I don't get how = validation in YANG can be (re)defined to apply also to implementations = that don't have "intended". =20 =20 =20 It should be possible to add new operations to NETCONF and new query parameters to RESTCONF that support the operator requirements, and still preserve existing operations. =20 I am not in favor of rewriting operations that move the validation to = 'intended'. That would not be backward-compatible so it is a non-starter. =20 =20 What I would like to do is to make protocols and YANG work equally well = for all datastore architectures so that the protocols and YANG needn't = be changed each time the current architecture is found to require = adjustments. =20 =20 This does not make sense to me. First, I do not care about non-standard, private architectures, just the standard architecture. Applications cannot be forced to hard-wire all = the details about configuration management. Let's not go back to data silo = architecture. =20 The standards need to expose the details in a common framework to enable data-driven automation tools. That means the protocols and the data = models have to support a standard datastore framework. =20 =20 > > My Applicability Statement concerns are related to developers deciding > if a server implementation needs to expose 'intended' and 'applied'. > I would like a definitive statement like "If an intended value takes = more than 5 seconds > to become applied (due to implementation, not missing hardware), then > the 'intended' and 'applied' datastores SHOULD be supported." > > I think the definitions of the datastores apply to all servers, and = the > set of new datastores is the correct and the semantics are clear. For some servers running-intended-applied is way too complicated, and = good old "running" may be all that's needed. =20 =20 Agreed. These servers do not need to implement the new datastores. The same is true for the 'candidate' and 'startup' datastores already. =20 Lada =20 =20 Andy =20 > > > Lada > > Andy > > > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > > Fax: +49 421 200 3103 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 =20 ------=_NextPart_000_0192_01D2684F.AC4565E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi All,

 

[NETMOD CCed as this is relevant to the revised DS = draft]

 

> > > > I wrote it already = several times: I support(ed) Mehmet's proposal to make the = revised-datastores I-D informative. The document was adopted as a = Standard Track WG item although I didn't see anything close to rough = consensus during the adoption poll.
> > > >
> > = > It appears to me that there is consensus to making this a standards = track solution.
> > >
> > Where is any evidence of = this?
>
> I think there was approval in the room in Seoul, = and it is being confirmed on the mailing list.

It is correct that we agreed in Seoul to start a consensus call on both = maillists for the adoption of the DT draft and executed such an adoption = call.

However we did not have any decision on the intended draft status in = Seoul and did not have any agreement during the adoption call. I = explained my concerns on the currently indicated status being standard = track and did not hear any other argument.

 

It is correct that we need a standard track document for the new DS = framework - to provide a basis for other RFCs to develope. =C2=A0However = the current DT solution draft has not been prepared as a standard track = document nor it has standard relevant content. Such concept description = is usually prepared as an architecture document (see example = in RFC 6244).

As I stated earlier I believe =E2=80=9Ca new protocol- and = language-independent standard document=E2=80=9D should be prepared = defining the generic datastore framework (based on and following the = concept in the DT solution draft).

 

IMO the intended status of the DS draft is still open and subject to = decide.

 

Regards,

Mehmet

 

From:<= /b> = Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy = Bierman
Sent: Wednesday, December 28, 2016 6:37 = PM
To: Ladislav Lhotka <lhotka@nic.cz>
Cc: = Netconf <netconf@ietf.org>
Subject: Re: [Netconf] = :candidate, :writable-running and RESTCONF edits

 

 

 

On Wed, = Dec 28, 2016 at 1:06 AM, Ladislav Lhotka <lhotka@nic.cz> = wrote:


> On 27 = Dec 2016, at 19:34, Andy Bierman <andy@yumaworks.com> = wrote:
>
>
>
> On Tue, Dec 27, 2016 at 10:01 AM, = Ladislav Lhotka <lhotka@nic.cz> = wrote:
>
> > On 27 Dec 2016, at 16:37, Juergen = Schoenwaelder <j.schoenwaelder@jaco= bs-university.de> wrote:
> >
> > On Tue, Dec = 27, 2016 at 03:47:10PM +0100, Ladislav Lhotka wrote:
> = >>
> >>>
> >>> A remote API for = management applications was our original target and
> >>> = this is where YANG is doing well (and we apparently still have work = to
> >>> do to improve things).
> >>
> = >> By "management application" I mean a specific = implementation with a fixed set of datastores and precise semantics. I = do argue that neither RFC 6241, nor "revised-datastores" nor = any other *specific* setup of datastores is going to work for all use = cases, yet the protocols and YANG can be pretty universal.
> = >>
> >> We have already seen YANG being used in areas = that are, strictly speaking, not supported by 6020/7950. Rather than = tolerating such uses (which is a slippery slope), I would prefer to make = them - within reasonable limits - officially supported.
> = >>
> >
> > This is too abstract for me. What do = you suggest to change in the
> > revised datastore = architecture? I do believe that having a number of
> > well = defined datastores with specific semantics is necessary for
> > = having interoperability.
>
> I wrote it already several = times: I support(ed) Mehmet's proposal to make the revised-datastores = I-D informative. The document was adopted as a Standard Track WG item = although I didn't see anything close to rough consensus during the = adoption poll.
>
>
>
> It appears to me that = there is consensus to making this a standards track = solution.

Where is any evidence of = this?

 

 

I = think there was approval in the room in Seoul, and it is being confirmed = on the mailing list.

 

 

>
> Datastores allow universal = concepts about managed data to be standardized
> across multiple = protocols.  In a protocol, the datastore name serves as
> an = input parameter value.  It needs to be normative in order for = a
> standards-track protocol to use it.

For the protocol, = the RPC parameter needs to be normative, not a particular datastore name = or semantics.

>
> Changing standards track status never = addresses real technical problems.
> I do not understand your = objections or alternate proposals.

I think this proposal will = lead to rather significant changes to the protocols and YANG, and their = extent IMO isn't clear yet. For one, the draft aims at moving validation = from "running" to "intended". But if = "intended" is optional to implement (sec. 6.1), I don't get = how validation in YANG can be (re)defined to apply also to = implementations that don't have = "intended".

 

 

 

It should be possible to add new operations to NETCONF = and

new query parameters = to RESTCONF that support the operator = requirements,

and still = preserve existing operations.

 

I = am not in favor of rewriting operations that move the validation to = 'intended'.

That would not = be backward-compatible so it is a = non-starter.

 

 


What I = would like to do is to make protocols and YANG work equally well for all = datastore architectures so that the protocols and YANG needn't be = changed each time the current architecture is found to require = adjustments.

 

 

This does not make sense to = me.

First, I do not care = about non-standard, private architectures, just = the

standard = architecture.  Applications cannot be forced to hard-wire all = the

details about = configuration management.  Let's not go back to data silo = architecture.

 

The standards need to expose the details in a common = framework to enable

data-driven automation tools.  That means the = protocols and the data models

have to support a standard datastore = framework.

 

 

>
> My Applicability Statement = concerns are related to developers deciding
> if a server = implementation needs to expose 'intended' and 'applied'.
> I would = like a definitive statement like "If an intended value takes more = than 5 seconds
> to become applied (due to implementation, not = missing hardware), then
> the 'intended' and 'applied' datastores = SHOULD be supported."
>
> I think the definitions of = the datastores apply to all servers, and the
> set of new = datastores is the correct and the semantics are clear.

For some = servers running-intended-applied is way too complicated, and good old = "running" may be all that's = needed.

 

 

Agreed.  These servers do not need to implement = the new datastores.

The = same is true for the 'candidate' and 'startup' datastores = already.

 


Lada

<= p class=3DMsoNormal> 

 

Andy

 

>
>
> Lada
>
> = Andy
>
>
> >
> > /js
> >
> = > --
> > 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/>
>
>= ; --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: = 0xB8F92B08A9F76C67

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key = ID: = 0xB8F92B08A9F76C67




<= p class=3DMsoNormal> 

------=_NextPart_000_0192_01D2684F.AC4565E0-- From nobody Fri Jan 6 10:45:17 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A998129D99; Fri, 6 Jan 2017 10:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWcqTNs8JG4g; Fri, 6 Jan 2017 10:45:13 -0800 (PST) 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 5BB76129628; Fri, 6 Jan 2017 10:45:13 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BAE1370D; Fri, 6 Jan 2017 19:45:11 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Q0pIidqqd-cI; Fri, 6 Jan 2017 19:45:08 +0100 (CET) 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; Fri, 6 Jan 2017 19:45:11 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 73FEF20086; Fri, 6 Jan 2017 19:45:11 +0100 (CET) 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 vpsBm1jP5dIk; Fri, 6 Jan 2017 19:45:11 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C45220085; Fri, 6 Jan 2017 19:45:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7B5353E03CC0; Fri, 6 Jan 2017 19:45:13 +0100 (CET) Date: Fri, 6 Jan 2017 19:45:13 +0100 From: Juergen Schoenwaelder To: Mehmet Ersue Message-ID: <20170106184513.GA11816@elstar.local> Mail-Followup-To: Mehmet Ersue , 'Netconf' , 'NetMod WG' References: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: 'Netconf' , 'NetMod WG' Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 18:45:15 -0000 On Fri, Jan 06, 2017 at 07:04:14PM +0100, Mehmet Ersue wrote: > > It is correct that we need a standard track document for the new DS framework - to provide a basis for other RFCs to develope. However the current DT solution draft has not been prepared as a standard track document nor it has standard relevant content. Such concept description is usually prepared as an architecture document (see example in RFC 6244). > > As I stated earlier I believe “a new protocol- and language-independent standard document” should be prepared defining the generic datastore framework (based on and following the concept in the DT solution draft). > To me, this sounds like duplicate work for no real technical value. If the existance of two WG results into actions like this, we should seriously consider the option to merge NETMOD and NETCONF into one WG. /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 Fri Jan 6 11:05:24 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75934129BB0; Fri, 6 Jan 2017 11:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZlwHeVxVlcq; Fri, 6 Jan 2017 11:05:21 -0800 (PST) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA5E129BAE; Fri, 6 Jan 2017 11:05:20 -0800 (PST) Received: by mail-wm0-x244.google.com with SMTP id l2so7160644wml.2; Fri, 06 Jan 2017 11:05:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language:disposition-notification-to; bh=XsJSqAzgPXgeMldoAiK8yHy1STtw3kzPXhJOnGdgjSk=; b=ndzVLfx/GsT3bF/2KxnbDsbmjJD9KXAaENT32ziVQ749O/AqhwTJXdfBXuUkUVKkSs nhotslw4yQYFGXcQcJhlitK+vG4+2o1OJ4EfYCSYWYuOe54Ed5BsgN43vDSWtg2Z/DFo Hy3wjfHngU5dJia2ORJHswdXkDF8QoKj4xKqg0yNqEo562/KXF0ZzcKXdDK12q52hfga h8kE5Bl0jCkwj0Skmnej2s0Yg3AVcb+poZuMU45A+6T9exRX0DPgd1SwPuSB4m/yCZVb i1TWEpEoKPCvEIzvJSdfqn1a2cJ6AK0JMMnHLpc2g07GX6rBDywYwn4N7H6pOrnq9JZU UaXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language:disposition-notification-to; bh=XsJSqAzgPXgeMldoAiK8yHy1STtw3kzPXhJOnGdgjSk=; b=S7SV1d71lNTxRkH+UDhOiuYerUPh7IsZqTOyskKbGrHeUK15NfNOXiG5ya5UKor08E FtLdchDL1WvRWBolmsgH/mjceKKGGV/pbnLUM+GqDCCWyVCVH11b4CLufpNe6ZqiEcbx gMR2bO5TlPYpHHN5UEbCJrzMRTzvgztdJpcxxjWe3FJ4fO1xatWdXa5Tcxztv9o5lhXD VWt4ziKbQ7lA0Bo6V4Q3HkW61kavKUKe/5PRFhnpJczn4XjVzPshEQpLwxISHpKsoe4I iSyUTUlQdbmr79v4FUZKo+vBelCjHYIi9W54seYwBRYHjfEjLATQ6l/ipSSS3spaLDst mtHA== X-Gm-Message-State: AIkVDXJsr8ix4MVuqrRFtNAKmp9veZD0hf0QFgsYEmR7De3/nxLBizV6dfNWn5KR0DQRaA== X-Received: by 10.223.165.138 with SMTP id g10mr2324823wrc.157.1483729519222; Fri, 06 Jan 2017 11:05:19 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5B340C74.dip0.t-ipconnect.de. [91.52.12.116]) by smtp.gmail.com with ESMTPSA id m10sm10623073wjg.45.2017.01.06.11.05.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Jan 2017 11:05:18 -0800 (PST) From: "Mehmet Ersue" To: "'Juergen Schoenwaelder'" References: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> <20170106184513.GA11816@elstar.local> In-Reply-To: <20170106184513.GA11816@elstar.local> Date: Fri, 6 Jan 2017 20:05:17 +0100 Message-ID: <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQM68I+vWqVG6862+ZiAo2vzjtZG8wFL/2G6nlBdjpA= Content-Language: de X-AVK-Virus-Check: AVA 25.9819;2DC73FAF X-AVK-Spam-Check: 1; str=0001.0A0C0208.586FEA6E.0066,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Cc: 'Netconf' , 'NetMod WG' Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 19:05:22 -0000 Hi Juergen, I don't think it is duplicate work. One is as I understand the = architecture and concept document you were asking for=20 and the other draft is the standard DS framework RFC to be used as the = basis for different documents. Cheers, Mehmet -----Original Message----- From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Friday, January 6, 2017 7:45 PM To: Mehmet Ersue Cc: 'Netconf' ; 'NetMod WG' Subject: Re: [Netconf] Decision on the Intended Status of the Revised DS = Draft WAS:RE: :candidate, :writable-running and RESTCONF edits On Fri, Jan 06, 2017 at 07:04:14PM +0100, Mehmet Ersue wrote: >=20 > It is correct that we need a standard track document for the new DS = framework - to provide a basis for other RFCs to develope. However the = current DT solution draft has not been prepared as a standard track = document nor it has standard relevant content. Such concept description = is usually prepared as an architecture document (see example in = RFC 6244). >=20 > As I stated earlier I believe =E2=80=9Ca new protocol- and = language-independent standard document=E2=80=9D should be prepared = defining the generic datastore framework (based on and following the = concept in the DT solution draft). >=20 To me, this sounds like duplicate work for no real technical value. If = the existance of two WG results into actions like this, we should = seriously consider the option to merge NETMOD and NETCONF into one WG. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Jan 6 11:57:48 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6ED12964A for ; Fri, 6 Jan 2017 11:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZzxF49u4lpz for ; Fri, 6 Jan 2017 11:57:45 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A20B129625 for ; Fri, 6 Jan 2017 11:57:45 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id s140so62498419qke.0 for ; Fri, 06 Jan 2017 11:57:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QoQqQ36oH6gMwkH0RTvlWFzRcsy1rWOsF8z3Fl7iQCA=; b=SIkZhMzff5ie6qjQsM7yw9JZBQomVcHJjBwN7Qe5Wenu1LhCqqNB/2jC7aq5pnwY8h 0ahQ8CboTQCnGlZ4jBqLT1/UgOcPXo3i5YLDiGWDehlAk/pZGOnUkgmIqmM+Unl6tEiQ 20tBaVG77OclAtk6FUjTUtmStBi8ifQY0hc9CKp/6EYs8gH+UIay3jYPXkRZWO7kQGbm JJVb6sDhah9OjL2avO5SEMl7DIZaLcmjb3BORPq0xQwvHicB33KlQhkMXdV427RKOv20 I/kOTdbQV88YCL/wOqgrolR4aCka/k+NWGYZhbC0Q9POoFS6TfhxXKd5ntXJcFAqXqbo ttyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QoQqQ36oH6gMwkH0RTvlWFzRcsy1rWOsF8z3Fl7iQCA=; b=IPKKENKz53bLOQAC1dQODs/B0O05eWXwlIQdv09AxsPjjMp1SMNypqj0R+FpNQR007 6h4ZnNTVuVzHPVWB/3jPITdvEfY9Ebo7LmLOwIZJ/pkod8XUfHwNqUfOVNo4UZbXwaxn 3a8S+CIFJkbZbWWGh13q8T/br/DSJXUh658T7qSva9v4AVkIWn06BHYKzdZrIuj+PPrw mEmPgrpc7S8A97ZoeSUFaTpv+pS6LerPH2eJXrSBHTsKiX26yYYhNIk98pHpBhA3ESNX Zsd5hWH9RX3TO4MjRNid45rqDWYtZiEcc2OLDiHrKX/c8wfViYrzFnEhGBkvfDjIeFSi MLVQ== X-Gm-Message-State: AIkVDXKxgldRVOl4nmf0tT7R4oXaVB2OmdauW1rVpA1ozEcBapb7YFX5BMXEup9Gh/fKhmm48AiqEgR4gec0bw== X-Received: by 10.55.20.137 with SMTP id 9mr6547317qku.237.1483732664698; Fri, 06 Jan 2017 11:57:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Fri, 6 Jan 2017 11:57:44 -0800 (PST) In-Reply-To: <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> References: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> From: Andy Bierman Date: Fri, 6 Jan 2017 11:57:44 -0800 Message-ID: To: Mehmet Ersue Content-Type: multipart/alternative; boundary=001a1144d2266be35c0545726efa Archived-At: Cc: Netconf , NetMod WG Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 19:57:47 -0000 --001a1144d2266be35c0545726efa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jan 6, 2017 at 11:05 AM, Mehmet Ersue wrote: > Hi Juergen, > > I don't think it is duplicate work. One is as I understand the > architecture and concept document you were asking for > and the other draft is the standard DS framework RFC to be used as the > basis for different documents. > > I do not understand the difference between these 2 documents. There should be 1 document that is protocol-independent that includes: - definition of datastores - discussion of interactions between datastores - use-cases in scope for new datastores - applicability guidance for server developers Each protocol that wants to use these new datastores needs to define mechanisms to do that in a separate document. Cheers, > Mehmet > Andy > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, January 6, 2017 7:45 PM > To: Mehmet Ersue > Cc: 'Netconf' ; 'NetMod WG' > Subject: Re: [Netconf] Decision on the Intended Status of the Revised DS > Draft WAS:RE: :candidate, :writable-running and RESTCONF edits > > On Fri, Jan 06, 2017 at 07:04:14PM +0100, Mehmet Ersue wrote: > > > > It is correct that we need a standard track document for the new DS > framework - to provide a basis for other RFCs to develope. However the > current DT solution draft has not been prepared as a standard track > document nor it has standard relevant content. Such concept description i= s > usually prepared as an architecture document (see example in < > https://tools.ietf.org/html/rfc6244> RFC 6244). > > > > As I stated earlier I believe =E2=80=9Ca new protocol- and language-ind= ependent > standard document=E2=80=9D should be prepared defining the generic datast= ore > framework (based on and following the concept in the DT solution draft). > > > > To me, this sounds like duplicate work for no real technical value. If th= e > existance of two WG results into actions like this, we should seriously > consider the option to merge NETMOD and NETCONF into one WG. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1144d2266be35c0545726efa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jan 6, 2017 at 11:05 AM, Mehmet Ersue <mersue@gmail.com>= wrote:
Hi Juergen,

I don't think it is duplicate work. One is as I understand the architec= ture and concept document you were asking for
and the other draft is the standard DS framework RFC to be used as the basi= s for different documents.


I do not understand the difference bet= ween these 2 documents.

There should be 1 document= that is protocol-independent that includes:
=C2=A0 =C2=A0- defin= ition of datastores
=C2=A0 =C2=A0- discussion of interactions bet= ween datastores
=C2=A0 =C2=A0- use-cases in scope for new datasto= res
=C2=A0 =C2=A0- applicability guidance for server developers

Each protocol that wants to use these new datastore= s needs to define
mechanisms to do that in a separate document.




Cheers,
Mehmet


Andy
= =C2=A0

-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
Sent: Friday, January 6, 2017 7:45 PM
To: Mehmet Ersue <mersue@gmail.com>
Cc: 'Netconf' <
netconf@ietf.= org>; 'NetMod WG' <net= mod@ietf.org>
Subject: Re: [Netconf] Decision on the Intended Status of the Revised DS Dr= aft WAS:RE: :candidate, :writable-running and RESTCONF edits

On Fri, Jan 06, 2017 at 07:04:14PM +0100, Mehmet Ersue wrote:
>
> It is correct that we need a standard track document for the new DS fr= amework - to provide a basis for other RFCs to develope.=C2=A0 However the = current DT solution draft has not been prepared as a standard track documen= t nor it has standard relevant content. Such concept description is usually= prepared as an architecture document (see example in=C2=A0 <h= ttps://tools.ietf.org/html/rfc6244> RFC 6244).
>
> As I stated earlier I believe =E2=80=9Ca new protocol- and language-in= dependent standard document=E2=80=9D should be prepared defining the generi= c datastore framework (based on and following the concept in the DT solutio= n draft).
>

To me, this sounds like duplicate work for no real technical value. If the = existance of two WG results into actions like this, we should seriously con= sider the option to merge NETMOD and NETCONF into one WG.

/js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

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

--001a1144d2266be35c0545726efa-- From nobody Mon Jan 9 04:17:17 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5321F129C48 for ; Mon, 9 Jan 2017 04:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeO2CIzQliFS for ; Mon, 9 Jan 2017 04:17:14 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 9A120129C45 for ; Mon, 9 Jan 2017 04:17:14 -0800 (PST) X-AuditID: c1b4fb2d-e97ff7000000561e-a7-58737f47f2b9 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 16.D2.22046.74F73785; Mon, 9 Jan 2017 13:17:12 +0100 (CET) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.63) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 9 Jan 2017 13:17:54 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=guDNewrmAMhOscQ0LyIaYBJ9ulbedEz1CBK5mguQ+x4=; b=iO/C7ESP/ouTCHOTfhQwOb5WgqQEUVcINX0Dyhcn18LvvMF5kDTVTexxYGeRrSS7Bs4z/FP1ZxoZeDK6etCx/QEH3liC8nr0NeNMpSYq6QOOKcFrBnRmZotlJRNZwtqxy7AzM5mXTCQpT14fgf7XbBTOewz4sATQgZFeMDFY1zI= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; Received: from [159.107.198.120] (91.82.100.59) by VI1PR07MB0959.eurprd07.prod.outlook.com (10.161.110.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.829.4; Mon, 9 Jan 2017 12:17:09 +0000 To: "netmod@ietf.org" From: Balazs Lengyel Message-ID: Date: Mon, 9 Jan 2017 13:16:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [91.82.100.59] X-ClientProxiedBy: VI1PR1001CA0032.EURPRD10.PROD.OUTLOOK.COM (10.167.204.42) To VI1PR07MB0959.eurprd07.prod.outlook.com (10.161.110.151) X-MS-Office365-Filtering-Correlation-Id: 73d5f9b1-880f-4be9-1c35-08d438896f87 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:VI1PR07MB0959; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0959; 3:ltPXf+rNWnDPmfAb6aJlJs6dxundI5u7CAHrG7K3jGOvpFwPU4m9Oo14y0/Xw+6FqJa3M8n7BZz4bgYEaezDv+i+ETI+4THLTJSotgVQgwKcP1xe7wOuxqTOdvn6fBNAQ34Ry8S0/1+/QNfgbGqZopz6lHsKVPRmtV914UgXYyTrHgEONW6xMJC4tTvtuAmVFkaaQiPvIw9nO/FRIFY7NmjZBCENOrxRwcrTC8PQ98MelaHhMI6NskcMCU0XWHTPstmS4ShL2RjfOhNI/TkdmA==; 25:88RtzjwaX3fL5nafu7b2ea8DR0QMefuiGX0X3eilEWmDRu3XVhgnwiV0qmpkhyru7Uf+Hv7LPlx5GDquUi2ZbiEeWy0sMFlkbcTFLFbK2djIytKKrJvhxAGBZGsozPw+dhn+hx33ISgoVYwy/NE43GgkcsBbUjNpuRI45aVPd6aq85DS0dxhB9NmMBkjvXyaywLZ5wv9yJKpZPahR1+MkcIEFus4G+KhrzMHNJ8pFoIGEVGxzRee47hx24uNBTFaHj46VkyYQt/aSo7Bc94PfgEMOcNmEJIBQ0Zbfn26Y1fzZPKQs/6Mod6yw5LxoLAOFcKIzS4IStUefHFGVO3AD77zemItgzrJ/q4ZDvE2scyDpHgtwxFL7F0c4Z2Ces+01Ws6MHhLHwFDLm56Y7EZFO05suosTFnX/pmGKgSEAabBtW86+wXzgu6JHQrMhcdpOeO1zN/wgcmDDrB/fvD5hw== X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0959; 31:IpVnZRIZnquJXOvabUtbAXDvFXi67jAmhJuXGofAB0JusWh5MZkupz9/IqK2fESz4QqFFYvRt5ZajO1wwZ7qOaWGPU8dEwmwextKuXqDrtXOCUp4FUUxO/lZ8QeSeDmRyjWVfg6Wg9Ec5udXVVwN4MUm10U4ZdEygUz+anFbrrAdQagBUgguzQaLrAzIMcFNwnrBR7haboj+EmafOAATx8zhQ98b5YppupZ6HjjrNCSzlWooO+Akdl35cM3xI+OZ; 20:HB9ZOXIUf/OU+oUeXhPz3wYv6uRUzP3jiQ7g85DyoOMuucoQYMaICKlFK0PlTyGtykpQgqtocCXCC776CIu36tukp1WbRNoxhHN7B6vd6rMRuosX/VW5n1d9MTp/W13rEPLonDacXzLlW5+pAbPHyuPvIBWiU/NcJdAxx3AWowN1hI6Drd5GICIEBcrzwMz1eoUSPiAPFIJgTzhW97mv0fvHeLTot8AAzrGnyiWUiPHvCiF2lNjvfLv7hzGR1DknG9o/Dh6yY5TfKkZEuNjn27L+GyB0m4hC5J4Xf9TX9bAvZElzG2wGG+xcsVQi2VROrXswCw0NJOS9iZ18VjJQf7VHOgIKooVVKtqFFSSvX/Rk0BCv1nlL00/ExZ8b21lzdT5S2rVIvyg14mmi+Hkt+V7iO4uuD53V5InZiJ+STI5d1Rtm0desNZktVK/1z7dODWlG2magPTxu9O4ToSUlKTB4wNETvMY6QBHyaWGhXf4tpPTzRiRZvVnrzZtCXOaI X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:VI1PR07MB0959; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB0959; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0959; 4:KeXGKiuPy/7jExtvH4jOhKs3Fd5TrZ9r/RXF70JHlJNqDZFlXNDpIfwXKSD9DhdRkQ3Y1nAWitXuT5adaTuZZ9z4stvMP+LqzJ3Ln6aHyDNyB1FKvgKYv+6N80PvDlI6RCYuwWTYskhhtXdCHFGS+G1a+HOAbwVeMmnWaxPaR2ouSLfA1xvMPf9v0ydTD/dEdsGufRfq2oaV90z/LgQxwyVJQLU+p3E4hIhYlSDL5iMuQb4//CYIZj7oC5UpwQ93Zd84CIBZ/T+vtTDMEbV72uGTwvxU80zNjmCA/km9E9Lo06v/oaSjUEOLjWnPhOCQqe3eushU8Q3TVpcHCAHHdzPlDYoALi44wrp6G9gGCFSib4x3tu9CJ+z3X0PxG3Y248AS2EDqaXX+hCzyjNEm66iZXKMN4BeglcDlz3KCVhER0+5gJosaFRupEZRK0+duILCwry7WGDUnnHi57uLcXgmFxQlINBM3WyVt/iR93oIdyapgyD6JA3mpYeZVP2Af2ZWcVdKVxibrhlc7xk71OxAma95veqP99D+sP4vZVdjiqY4jVTAHu+qmxC6uQJoZ4Jcmgabqd1xNlGekY7QY3AOSc8ZezkE3QDAcez9nON4L/HrCaunMofrwtwiuciHj X-Forefront-PRVS: 0182DBBB05 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6049001)(6009001)(7916002)(39450400003)(189002)(199003)(252514010)(50986999)(4326007)(65956001)(92566002)(66066001)(65806001)(47776003)(105586002)(3846002)(50466002)(90366009)(5660300001)(65826007)(54356999)(7116003)(189998001)(106356001)(6486002)(38730400001)(6116002)(68736007)(64126003)(5640700003)(83506001)(25786008)(230700001)(8676002)(1730700003)(81156014)(81166006)(97736004)(86362001)(107886002)(6916009)(110136003)(4001430100002)(3480700004)(2501003)(7736002)(4001350100001)(33646002)(31696002)(2906002)(2351001)(101416001)(6666003)(31686004)(42186005)(450100001)(36756003)(23676002)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB0959; H:[159.107.198.120]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3TUIwOTU5OzIzOkZ4VUV6VFRJSG1BMnhwWFU2MkZrUmhaL0E2?= =?utf-8?B?c05ZSWFiWlc3aDd5MnU1N0luUzdRQ0xVUzJ2NUd5cFhNZFVuWVBma2FSbmxX?= =?utf-8?B?RkllNlNJV1V3N2ZoQnErVXQvNERaOHowUmZaNkZwVjJGaldldUFBaXVtN2k0?= =?utf-8?B?SEkrZ240MnJMWUE0bGxidkxNUW9WanlvUld3TTk1ZWpZa0ZwZTRYL2tEOGYr?= =?utf-8?B?WnM3VzFQU2Y3WDJubndISWFpRmNvaGZYalZGb2lGYmw5UDBuVGVENEE3VXpq?= =?utf-8?B?ZnVIVkhzVm1Uck5OL3N5TWRVMXRyc2RLK3BMR0NuSlFEL1hrN3V4Q3R1UDF1?= =?utf-8?B?bzJhT2lHSTdkQ2dySFFlLzkzYUVrNzhqLzdtelgzRUFNUXk1QnZtbDUxcGJZ?= =?utf-8?B?TlVFWXpFOFRaWHV6T0V5d0RKVlhKYWxYUkt6NlJjY1FGYVBWTTg4OFREdTAw?= =?utf-8?B?L2ZaWk5mRHhXVUlsYVZyNEtaRUI3VGF6LytuZ0tSTDkvMlFZbmVxM2xvaDBY?= =?utf-8?B?a0JydGJ0NDJWUG1CazNZN0ltMmpEdDVxSThJN2lwSEpZNUxlK0NIVitmR0pl?= =?utf-8?B?cUI2R2FycGRQQjZWTmhoMUw1dXVlazY1ZkhUa01Kb0d1d3BCV09GSTJic3J0?= =?utf-8?B?WjVzRk8vaWhhRXRLbS9nZWVwZWl4TDI0WUZFVnR6S1c1K1hvbm9IdENRU3F6?= =?utf-8?B?Qk5Jd0NKMXpsVTI2Nkt2THdGWnA5a21yM3J3eXhqNGUrd1dVcUVNUUlFSkI2?= =?utf-8?B?K3NKaVRLY3krQ0xBU3FsMHJhOFExd2MrcWllZmxTTHZ2T1B6UmN6ZEc3bXlU?= =?utf-8?B?MlNDU3dlcHBYY0JoUENzMDljMDJKdkVERm1aaCt3SzNHam1aL3p4RHRrV0cy?= =?utf-8?B?Rzk5Y0Vtcm1MWXg3OTZMdlhJbnBpblQ0VTdJb1ZUYmRVNGdZY1U5S0tXN21p?= =?utf-8?B?UlE4blZQVDN0OEJHTWhhSFk5a3NsYUdReUN6cTY5S2xRWHh3RWM2cHc5dmFM?= =?utf-8?B?YmhXUUh2d0JRdFhZZGpoTTQyZEg0aHhKYU4xUFlYWXdaKy9JRlgrc0FPN2Uz?= =?utf-8?B?UjZwYzk3UEMyVkxUVi84K2JLdXRUV0JXNENQVnR0aFl2UlZvd1RkY1ZyaWFV?= =?utf-8?B?Z2xCcDlGVGluaWJCaE85Vm1BUzgxcElhV1BmY0x4czVDaW5Bakd5NktFb0VH?= =?utf-8?B?OS80SjRIZHhkZStoc09TWXMyelpPT01qbW1tZG14WWVLbGl4aUxnRkhkUFZi?= =?utf-8?B?NWt6Qm5nb24rMzBZK3ZUMithNjk0a0pkV2ZsOHZjcTdqay9sNVJzOUZ2U0pY?= =?utf-8?B?bzBYVUFMbUxXdjJFa0lwMStFRTNaa010VUoxeHpIM1dubG8xRUtTc3ZJazhl?= =?utf-8?B?TnFaRXFCeEkvalhoOWgrcmFBM3hrNEQvVWlVNk5YSXdRM0dOVjN6RkJ5eG1Y?= =?utf-8?B?TDl1SFdQTHpVUmVTWEVnQjdyTWwweTNIOW5GVGJJaDZsVnlsMng1VkUxdEdw?= =?utf-8?B?WGI3aDVpUWRMQitQZUhMMVhmSjNZaGlWUDRTY0RNdjdSNVRDZ0lMVXE3ekdB?= =?utf-8?B?c1A1alljazJpeDlkVFB6ZjFnVzRRVlU1RVR4OEZOSVZ4dnFRUjdPcmFpbUJy?= =?utf-8?B?endCVWRYNXZqbG4yM0l1RDRYdXpUUHkvZzVkbE5Fc1JnN2tqZkRlYXUxbFY0?= =?utf-8?B?Um56c2FsU0haeHdaYThUMUVzL1NoRVQxaUFCbndZcWdZeUhaQ2FGT05yWktv?= =?utf-8?B?UEZpRVdLZzVOWTQ0NFVoeUlIKzhRa2NTYXdlb0NoWXZtcHh1QXFLWElEVkJj?= =?utf-8?B?Tm1ZamlzZzRXYzlJMHVtNHh2Y2JwTEdaRTBoc0NpckVrYmY5aHJpN3NiOURG?= =?utf-8?B?T0tld1ZUQUJ0S0Zkc1VOSElGSDdCTkJCZGhwRjF4NmI0SEtGZUE2WU0ySno1?= =?utf-8?Q?u9RtcmzBP91oiC0HO3XoHqY0em31KA=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0959; 6:VaGs/b8XJyyT+G1fYGY0vZ8P53qAkE9xLLknXooQ6Y2/WyTwSZ1jpKPOIvi7WKzuFBAG0V2+2mXungNTdayRBZMlkwvLm5POyLn+ARzobGyOaF7Rs647+7II5E8cHXI5tfMPAiajYFr9QlRcopWDpLY7zaSmTokVw1A3B/dKAPSh4rusYFczIIR9jltuXQYrb7to9lZN3jblf1wgVTo/29YFGltu98S7qC65chqGL4ZFC2as5OxPbXZlCEeEQIOp4xjTX/ZWrWCPUbmqXg5oV34Fnk0kUF24uYNPlIrLD4SfT/afGNrqRjAmWlgXdPttdHE2jTdrxdbFEdZGV4U7dK1/VNx7hF6iNP+SwWUEtAy5Z+MAqCHSTRTzzAKh0x4W+Rs3xaTSFD+s6TzkXmZENFDL3SNaxk1BtF04ay1BRK8=; 5:0a6uQN/jVD+Us5fMPK+JFWiRi/lr1bfdcWAXQNBeAGIIwYVIjlSissWjIC6nlf6B5cefyxF4TvHnzqmee+pp4i6xJhjhLUqlMbxEPSCaqWoJxjTIbzSDGaffGpMw8zByjvAZ4p1Hq5Zg2M2Ih/XWlvuqt3IyfXuDOPNOj+m8kqE=; 24:KVmpIU4lWpZBWwOhXBbyh/+3kAxlA1/S8zbnHUmPuS5cOKWNgZbMKDmbLp50hBBJC5w6g2zKcRZVDlUCQe1GzWnrO8PlucszInO4NDx4pd0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0959; 7:hbWDhLbOdhvaqUrMl3b/o6wrF1Fit96PWKvTbqJ4U4+X+STkT0quYyggPIKSO2u5RxTXZno+TDeNBsIGBAv+GjhLUGSUlXrN8xYOTPOcPhopyCah0qcFdpVSsS281zOv3x2WjqIrI9gtiQmYrEnaiDv5F1YJ6xuW90MFvfcT+ABGJ5jBj73NlZG7DOBAUCvVquCwTvEeWfjSa/Df1vieXvWNaHND5ms/tyV6VkHHJqXpmUTZ2f8MFhEnIV5u0OPc1cNnL8CC9fhlnFhzz4f+mDdTfaoKQm8gQ6U80RG6iTndIZ7IfGiGNsXEbiO/1+0J6qvRc0vgEQBPSsboVYFpmp4tfC9mU9oWdi4m4z7S2qjTei014h6Q9CJd+XQLRS1IoNSQCcC5se80VpwvKFAGoZMIzdILI4ppp1llY8UuWJudEbP5vzNdAUKYSSOdFJ+MzS1qIqdy6PcNxconZ00WkA== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jan 2017 12:17:09.8032 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB0959 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrIIsWRmVeSWpSXmKPExsUyM2K7va5HfXGEwbvr2hbzLzayOjB6LFny kymAMYrLJiU1J7MstUjfLoErY9WZnILXzBUTv5xlaWB8y9TFyMkhIWAi8WbDOvYuRi4OIYF1 jBLd0/4zQzjHGSWad71kBHFYBHqZJZ7smckM0sIoECexc81CVoiqf4wSi7fdYgdJiAioS8zc uZ4NxGYWcJTov3cerIFNwEhiav95FhBbWEBCYtu7WawgNq+AvcTOx7fAalgEVCSevHoCViMq ECPxdv1ydogaQYmTMyHizAIWEjPnn2eEsOUltr+dwwzxg4LE9c3XWSDsLkaJh18LQGwhAQ2J hxf+skLEfSWerTzFDmNf2rgY6v8VbBJH91qAPCMhsJNN4uqVpVCJbIlT3UegGqwkXv/6zghR 1MUk8efDRXYIZwurxJQly6BWy0gcP/sdyu5lk1gwJQXijFSJLTda2CAa1gtLbOvdxgrh/GeV mPb9O+MERvVZSH6dheTXWUh+XcDIvIpRtDi1uDg33chYL7UoM7m4OD9PLy+1ZBMjMCEc3PJb dwfj6teOhxgFOBiVeHg/BBdFCLEmlhVX5h5ilOBgVhLhDaktjhDiTUmsrEotyo8vKs1JLT7E KM3BoiTOa7byfriQQHpiSWp2ampBahFMlomDU6qBsTtE8/OqDzEOxy/arm2U91rcs59DjO3w f5HyA6zaE01+FKeJ+88Uv7ssmP/PG6tjTl/Nrs680X4hVWpeUZ7xk09tbrYJOvlSRo5d9Z5y jLNVeLJ+LOX0d/S6MmXPn/CJdjpTvnF7Fd7J9F3+dwOf5HF9K6WgU5WiexsOK/b83BHrKMT2 f5KgEktxRqKhFnNRcSIAxuJJ9wQDAAA= Archived-At: Cc: =?UTF-8?B?QmFsw6F6cyBLb3bDoWNz?= Subject: [netmod] Tacacs and YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 12:17:16 -0000 Hello, We already have a radius model part in ietf-system; but are there any plans to develop a TACACS+ model for YANG? How widely is TACACS+ used for remote authorization/accounting ? As an outsider I would guess that remote authorization could really slow down processing e.g. a big CLI script. regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Mon Jan 9 04:24:42 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A53129C59; Mon, 9 Jan 2017 04:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12xJmiRRhu2X; Mon, 9 Jan 2017 04:24:39 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3515129C56; Mon, 9 Jan 2017 04:24:30 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:4589:6a62:5975:ccec] (unknown [IPv6:2a01:5e0:29:fffe:4589:6a62:5975:ccec]) by mail.nic.cz (Postfix) with ESMTPSA id 9306860091; Mon, 9 Jan 2017 13:24:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1483964669; bh=BXFYYSLU9g+QpJzAZo0qrI8cKw+WY8QEN5JUpwsUaRA=; h=From:Date:To; b=wu9pLl/GgSNK/ULaSILUdflohSWYwUvJTC4u+yCVYOHSpXpKlQCAU4Kww2stRHxV+ ymGhSlu+/sksaMDrGE9pIAlHhmIA4cXrSWrdUaaqloTjovZNJMR03g32xsqF4gR6Ei +50jckyQKxdKfpnYJgXlogUH1XCEz9wcFZlNnAUU= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 9 Jan 2017 13:24:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> References: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> To: Andy Bierman X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NetMod WG , Netconf Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 12:24:41 -0000 > On 6 Jan 2017, at 20:57, Andy Bierman wrote: >=20 >=20 >=20 > On Fri, Jan 6, 2017 at 11:05 AM, Mehmet Ersue = wrote: > Hi Juergen, >=20 > I don't think it is duplicate work. One is as I understand the = architecture and concept document you were asking for > and the other draft is the standard DS framework RFC to be used as the = basis for different documents. >=20 >=20 > I do not understand the difference between these 2 documents. >=20 > There should be 1 document that is protocol-independent that includes: > - definition of datastores > - discussion of interactions between datastores > - use-cases in scope for new datastores > - applicability guidance for server developers The current document involves quite a lot of hand-waving, and that's why = I was also reluctant to accept it as a WG standard-track deliverable. I = don't care that much about the number of documents that depend on it = because any mistakes may be pretty expensive here. I pointed out some = gaps in my previous review, e.g. it talks about templates without = defining what they are. If running contains templates, does it mean it = needn't be valid according to the data model? >=20 > Each protocol that wants to use these new datastores needs to define > mechanisms to do that in a separate document. >=20 That's one part, the other are changes inflicted to YANG. I think the = best way would be to make YANG independent of a particular setup of = datastores and their semantics. Then I2RS or anybody else can do = whatever they need without affecting YANG spec any more. I believe this wouldn't be a terribly difficult thing to do, but Juergen = wants me to write a meta-model document first. Lada >=20 >=20 >=20 > Cheers, > Mehmet >=20 >=20 > Andy > =20 >=20 > -----Original Message----- > From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, January 6, 2017 7:45 PM > To: Mehmet Ersue > Cc: 'Netconf' ; 'NetMod WG' > Subject: Re: [Netconf] Decision on the Intended Status of the Revised = DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits >=20 > On Fri, Jan 06, 2017 at 07:04:14PM +0100, Mehmet Ersue wrote: > > > > It is correct that we need a standard track document for the new DS = framework - to provide a basis for other RFCs to develope. However the = current DT solution draft has not been prepared as a standard track = document nor it has standard relevant content. Such concept description = is usually prepared as an architecture document (see example in = RFC 6244). > > > > As I stated earlier I believe =E2=80=9Ca new protocol- and = language-independent standard document=E2=80=9D should be prepared = defining the generic datastore framework (based on and following the = concept in the DT solution draft). > > >=20 > To me, this sounds like duplicate work for no real technical value. If = the existance of two WG results into actions like this, we should = seriously consider the option to merge NETMOD and NETCONF into one WG. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Jan 9 04:38:26 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D898D129C5D for ; Mon, 9 Jan 2017 04:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJSw1R07LMZ4 for ; Mon, 9 Jan 2017 04:38:20 -0800 (PST) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) by ietfa.amsl.com (Postfix) with SMTP id 43A0C129C2C for ; Mon, 9 Jan 2017 04:38:19 -0800 (PST) Received: (qmail 24777 invoked by uid 0); 9 Jan 2017 12:38:17 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy3.mail.unifiedlayer.com with SMTP; 9 Jan 2017 12:38:17 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id WCeD1u00Z2SSUrH01CeGVy; Mon, 09 Jan 2017 05:38:17 -0700 X-Authority-Analysis: v=2.1 cv=YpOcGeoX c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=IgFoBzBjUZAA:10 a=oJz0gAw5pYE2X979_FIA:9 a=CjuIK1q_8ugA:10 a=NBv74QYyziwA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From; bh=JGRqTlhAGLB4rQ5r3xVZ0jVcjYebXj6qchg21VR7+BI=; b=Xbmo3mFw+z8Pus1D4Va2RDegHd Keo+fPLyC0/0X36gw10Ay9Fqkcm4ku9e+OJ8emxKz04W0jFaZIS89HTSQqZGou82YH4rG50+TVCFX AeGUUPfV6GZOfRGrhCPuqq+Fh; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:46561 helo=[11.4.0.238]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.86_1) (envelope-from ) id 1cQZDJ-00055h-8p; Mon, 09 Jan 2017 05:38:13 -0700 From: Lou Berger To: Ladislav Lhotka , Andy Bierman Date: Mon, 09 Jan 2017 07:38:11 -0500 Message-ID: <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> References: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> User-Agent: AquaMail/1.7.1-88 (build: 100700100) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1cQZDJ-00055h-8p X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([11.4.0.238]) [100.15.85.191]:46561 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: Netconf , NetMod WG Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 12:38:21 -0000 On January 9, 2017 7:25:24 AM Ladislav Lhotka wrote: > > The current document involves quite a lot of hand-waving, and that's why I > was also reluctant to accept it as a WG standard-track deliverable. IMO I think we should do and document the work and then, once the is general agreement, worry about number and publication status of documents. Lou From nobody Mon Jan 9 04:50:53 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103DF129C5E; Mon, 9 Jan 2017 04:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQQV_3g3LmyK; Mon, 9 Jan 2017 04:50:48 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30590129C5C; Mon, 9 Jan 2017 04:50:47 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:4589:6a62:5975:ccec] (unknown [IPv6:2a01:5e0:29:fffe:4589:6a62:5975:ccec]) by mail.nic.cz (Postfix) with ESMTPSA id 227BF60963; Mon, 9 Jan 2017 13:50:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1483966246; bh=ZUcP8X8+ftRaSAbtmVvGil2Mj+98s7GNAHEduO+b3w4=; h=From:Date:To; b=QKZn9CrcO/AUSowUjWVVmt4KYsBuqXKVcxC8Z8vfvGe2cGLCIHYcUwt+JUacq155+ FCQk1Egd++J+lMFqz145BhSU/hUDzDGwIWMciSiIjzuZRlcvQOJIKpnIJrHigr7Unw FcwUyCkJ4bDXjfQsmSeA25LyCu2zleYCPWdDADNI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Date: Mon, 9 Jan 2017 13:50:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> References: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> To: Lou Berger X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NetMod WG , Netconf Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 12:50:49 -0000 > On 9 Jan 2017, at 13:38, Lou Berger wrote: >=20 >=20 >=20 > On January 9, 2017 7:25:24 AM Ladislav Lhotka wrote: >>=20 >> The current document involves quite a lot of hand-waving, and that's = why I was also reluctant to accept it as a WG standard-track = deliverable. >=20 > IMO I think we should do and document the work and then, once the is = general agreement, worry about number and publication status of = documents. I agree, but we have to accept it will take some time. The problem I see = is that quite a few people already work with the solution. Lada=20 >=20 > Lou >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Jan 9 10:37:24 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F3612984C for ; Mon, 9 Jan 2017 10:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ycx8qmxj6227 for ; Mon, 9 Jan 2017 10:37:17 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5995412984A for ; Mon, 9 Jan 2017 10:37:17 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id x49so78075184qtc.2 for ; Mon, 09 Jan 2017 10:37:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MX6yOnVUFSGwiHUfxMVAH8/48agyYRKJ+Usifm+uoZo=; b=dJvYP/TnBC8ohWm95hon++6Wkm8YSn/GivpwuMj46D9a1QDE7FxTUuqNrJiy6YNl98 YPjC4VWHYHrA2LaQrYtYR6oqyzPw4CY+kcZ3WGjvc2QmFQxbwg+9wLxwsxKhQExNnVuq Urjk8zVdp9UGEYsvSz+gCqXKZiVjIUhDp+IChU+tLHzOn9ZHlmTKGtPcCm2o7vzsbcBy Sux6nGMP977gnM2t+GXOi70g5nWlp0km2xz6ienxR3rMVm8Ue9rbGdjwjzCFhThfJTpN XAb5lQ1rtNau88QXe4LB7+995elt4+i6+BoWbuZN+qnbufkBidOsI5DpoHf+Lj4g8OEy 2taA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MX6yOnVUFSGwiHUfxMVAH8/48agyYRKJ+Usifm+uoZo=; b=XLcXwJ9yj/Gy3XsXJh/yeXAumPrgnOEdl02tIfYWGm+QJ9PdPSmYvsrdAsj84AO3+K 9OsMeIhGsfaZATQ1qWSIvF2hcB+l1v0cbG/DEta8W5iEIPypbXESJPWrYvMsi88bm4Bk eWBdzek47ZpZzUEOPVcL75UitPEW8EVdp1+y17SoM/MqwpZuHU3X6ckQq6Y4EJM41sMI 7rh1JNoXMgkcBK6ZIXP8tr4tsYHr4HShL5GFHp/tr7lzCtTgpllQqRr7Mts5OyFl1JVg WrDfQJQUxGUYflVbxvOjaHajekN77OClw5gyg/4Ix4XjfpGwLXEWDcWDPIf47WDVwhwZ gQMQ== X-Gm-Message-State: AIkVDXLENUgzrSVBitIdgtAaV2IugyLswhJKrpavv0UoFXqEKLq7JIx8tF9Emru7MuH26dNiZ3lY2I1Wv+1C+w== X-Received: by 10.237.34.239 with SMTP id q44mr12276095qtc.18.1483987036426; Mon, 09 Jan 2017 10:37:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Mon, 9 Jan 2017 10:37:16 -0800 (PST) In-Reply-To: <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> References: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> From: Andy Bierman Date: Mon, 9 Jan 2017 10:37:16 -0800 Message-ID: To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a113e7aee2875c70545ada855 Archived-At: Cc: Netconf , NetMod WG Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 18:37:19 -0000 --001a113e7aee2875c70545ada855 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 9, 2017 at 4:50 AM, Ladislav Lhotka wrote: > > > On 9 Jan 2017, at 13:38, Lou Berger wrote: > > > > > > > > On January 9, 2017 7:25:24 AM Ladislav Lhotka wrote: > >> > >> The current document involves quite a lot of hand-waving, and that's > why I was also reluctant to accept it as a WG standard-track deliverable. > > > I do not agree with this hand-waving assessment. What are the show-shoppers? I agree the draft is light on use-cases. There are no standard mechanisms that cause to be different from , so I would agree the intended datastore needs a lot more standards support before it is useful. > > IMO I think we should do and document the work and then, once the is > general agreement, worry about number and publication status of documents. > > I agree, but we have to accept it will take some time. The problem I see > is that quite a few people already work with the solution. > > The solutions I've seen were not very good, so they need a lot of work. I expect that the operational datastore will be more widely implemented than any of the others. Designing a replacement is not that difficult. Lada > Andy > > > > > Lou > > > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > --001a113e7aee2875c70545ada855 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 9, 2017 at 4:50 AM, Ladislav Lhotka <<= a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz> wrote:

> On 9 Jan 2017, at 13:38, Lou Berger <lberger@labn.net> wrote:
>
>
>
> On January 9, 2017 7:25:24 AM Ladislav Lhotka <lhotka@nic.cz> wrote:
>>
>> The current document involves quite a lot of hand-waving, and that= 's why I was also reluctant to accept it as a WG standard-track deliver= able.
>


I do not agree with= this hand-waving assessment.
What are the show-shoppers?

I agree the draft is light on use-cases.
There = are no standard mechanisms that cause <running> to be
diffe= rent from <intended>, so I would agree the intended datastore
needs a lot more standards support before it is useful.


=C2=A0
> IMO I think we should do and document the work and then, once the is g= eneral agreement,=C2=A0 worry about number and publication status of docume= nts.

I agree, but we have to accept it will take some time. The problem I see is= that quite a few people already work with the solution.


The solutions I've seen were not v= ery good, so they need a lot of work.
I expect that the operation= al datastore will be more widely implemented
than any of the othe= rs.=C2=A0 Designing a <get> replacement is not that difficult.
<= div>


Lada

Andy
=C2=A0

>
> Lou
>
>

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67






--001a113e7aee2875c70545ada855-- From nobody Mon Jan 9 12:18:14 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66FAA12959E for ; Mon, 9 Jan 2017 12:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7mK1ppMUJYq for ; Mon, 9 Jan 2017 12:18:11 -0800 (PST) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFBBE12959D for ; Mon, 9 Jan 2017 12:18:10 -0800 (PST) Received: by mail-pf0-x243.google.com with SMTP id f144so6234566pfa.2 for ; Mon, 09 Jan 2017 12:18:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hna8rDFmWtv1pjqgAWHBO2+5MKWVR5dafaEYJ9c1rp0=; b=KD0oCJSs8vacpVGc/5lWTwKjYk1anYJEduwF4IyP2H/HzT59Phyg8r2n/bUunMK4xJ VL+aKOmXKahxnhp+SUWK6OXp/cDCkbOp0hIQBafd+lMChrvDLpXx+q2A80Y5DDPu4ka/ SXi8QS8JEXmRK2ZIOhzMgVzmq1iQeVfHu1Lui1L6I8mrmDfC6Ipvj+QnCn19gTZa4Ejd hmO7fjQ0J3kJsexuON+6KmpAagR3ouO2Jk5T3+a+JPsTUlFPumFHp20S/F5gUj7LtJDO IhFFMB0HZ6GqS5IMn6vxFEH6HNQXssdqI7z7O3e4HuQlm28lmM6qKIVizsAvANJv42UQ J4NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hna8rDFmWtv1pjqgAWHBO2+5MKWVR5dafaEYJ9c1rp0=; b=cLIXpNH58BA91eL4iibGEk/INl8wx7ofW4DkmkDm1qtTwkQX2z4IwyYqrnQXTalSYb gzf/BaKtls2xZbuacURGqqDh8mBrtuvX1MK8/GxcJ2zR44KFtoGJldBOURmBCUKasJlE lQq92GVHLJG7g3TwWLMLdMz7K8vWlhr6Qm3sLOpYOCa/pvFvQspg7EmA/RCmBlMPlMcX zU5Z9BNPjq2Y5ZPMQRUGwNO7wU83gLQTXHeVwLA5GyJYfpHRwo3rOandHvDn9OhgfXbW PIKeym2hkgbm2MrfRAPtR9G8cYUPtI/P5OjjfN742//BpUVcUmqlyeyktNVtpgNU0tp+ Lspg== X-Gm-Message-State: AIkVDXKy9grN81RPOsz18q9fLD+Eo5uyFdKBOCjcs4l5PailGRQPD80GyXTOwVw/XxzI8Q== X-Received: by 10.84.232.137 with SMTP id i9mr160550176plk.95.1483993090590; Mon, 09 Jan 2017 12:18:10 -0800 (PST) Received: from [10.154.163.18] ([128.107.241.189]) by smtp.gmail.com with ESMTPSA id s3sm149220322pfg.14.2017.01.09.12.18.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 09 Jan 2017 12:18:08 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: Date: Mon, 9 Jan 2017 12:18:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Balazs Lengyel X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "netmod@ietf.org" , =?utf-8?Q?Bal=C3=A1zs_Kov=C3=A1cs?= Subject: Re: [netmod] Tacacs and YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 20:18:12 -0000 > On Jan 9, 2017, at 4:16 AM, Balazs Lengyel = wrote: >=20 > Hello, >=20 > We already have a radius model part in ietf-system; but are there any = plans to develop a TACACS+ model for YANG? >=20 > How widely is TACACS+ used for remote authorization/accounting ? As an = outsider I would guess that remote authorization could really slow down = processing e.g. a big CLI script. Of the customers that I am interacting with, both use TACACS+ for = authorization and accounting. My take is that there would a requirement = for NETCONF to be able to interact with the server. One way to deal with authorization is for the server to download the = authorization rules and do local authorization instead of sending all = the requests to the server, which as you point out would otherwise slow = authorization down.=20 A related question is, if NACM is used to setup rules for authorization, = and there is a remote AAA server configured, are the rules for the = NETCONF server to store and manage or are they for the AAA server? If = the latter, what is communication channel between them? Thanks. Mahesh Jethanandani mjethanandani@gmail.com From nobody Mon Jan 9 12:18:55 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14359129631; Mon, 9 Jan 2017 12:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4dVAcSsBoHH; Mon, 9 Jan 2017 12:18:49 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B675E1295B0; Mon, 9 Jan 2017 12:18:48 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:4c91:54e5:3faf:470f] (unknown [IPv6:2a01:5e0:29:fffe:4c91:54e5:3faf:470f]) by mail.nic.cz (Postfix) with ESMTPSA id 44DDC61366; Mon, 9 Jan 2017 21:18:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1483993127; bh=S0WvRVzvIb2uE7wfCTG4BNfdPsQ+YhPVFquypgO49rM=; h=From:Date:To; b=EWTzFfRDZAnt0O9crEujCkD0Guk/mLBQjMgQvU2baEjNtjDYFT7tjNxADzuyUf+DX nehaVBUWwYjiIHocOAantFktqnLK4HHuaK6MSS0UrcK+ltU2ag/7Yl6bq9MIPjzBdP 2osmid/vVzeeG4upoE7aYQV2+qFZkkCUgTHVrWY0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 9 Jan 2017 21:18:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf , NetMod WG Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 20:18:51 -0000 > On 9 Jan 2017, at 19:37, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Jan 9, 2017 at 4:50 AM, Ladislav Lhotka wrote: >=20 > > On 9 Jan 2017, at 13:38, Lou Berger wrote: > > > > > > > > On January 9, 2017 7:25:24 AM Ladislav Lhotka wrote: > >> > >> The current document involves quite a lot of hand-waving, and = that's why I was also reluctant to accept it as a WG standard-track = deliverable. > > >=20 >=20 > I do not agree with this hand-waving assessment. > What are the show-shoppers? >=20 > I agree the draft is light on use-cases. I am more concerned about use cases that are not known so far, and so I = am against standardizing this (or any other) workflow as the only one = supported by NETCONF/RESTCONF and YANG. I believe both the protocols and = YANG can work with any set of datastores, but their choice depends on = the use case at hand. Why should IoT developers be exposed to the = running-intended-applied complexity, even if they are allowed to lump = all three into one? =20 > There are no standard mechanisms that cause to be > different from , so I would agree the intended datastore > needs a lot more standards support before it is useful. >=20 The only difference seems to be the presence of templates but I don't = know what they are. Lada >=20 > =20 > > IMO I think we should do and document the work and then, once the is = general agreement, worry about number and publication status of = documents. >=20 > I agree, but we have to accept it will take some time. The problem I = see is that quite a few people already work with the solution. >=20 >=20 > The solutions I've seen were not very good, so they need a lot of = work. > I expect that the operational datastore will be more widely = implemented > than any of the others. Designing a replacement is not that = difficult. >=20 >=20 >=20 > Lada >=20 > Andy > =20 >=20 > > > > Lou > > > > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 >=20 >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Jan 9 12:51:19 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEAAE1295B7; Mon, 9 Jan 2017 12:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaEdi9JNwjfn; Mon, 9 Jan 2017 12:51:15 -0800 (PST) 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 D47771294B6; Mon, 9 Jan 2017 12:51:14 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D2AB36CE; Mon, 9 Jan 2017 21:51:12 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id w1-yI4yVqttT; Mon, 9 Jan 2017 21:51:11 +0100 (CET) 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; Mon, 9 Jan 2017 21:51:12 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F1DF2008C; Mon, 9 Jan 2017 21:51:12 +0100 (CET) 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 9bPT3Df__RAE; Mon, 9 Jan 2017 21:51:11 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D15120089; Mon, 9 Jan 2017 21:51:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3962B3E072CB; Mon, 9 Jan 2017 21:51:11 +0100 (CET) Date: Mon, 9 Jan 2017 21:51:11 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20170109205109.GA15144@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Netconf , NetMod WG References: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: NetMod WG , Netconf Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 20:51:18 -0000 On Mon, Jan 09, 2017 at 09:18:46PM +0100, Ladislav Lhotka wrote: > > I am more concerned about use cases that are not known so far, and so I am against standardizing this (or any other) workflow as the only one supported by NETCONF/RESTCONF and YANG. I believe both the protocols and YANG can work with any set of datastores, but their choice depends on the use case at hand. Why should IoT developers be exposed to the running-intended-applied complexity, even if they are allowed to lump all three into one? > Please point me to the statement in the I-D that makes you believe an implementation is required to support all datastores. > > There are no standard mechanisms that cause to be > > different from , so I would agree the intended datastore > > needs a lot more standards support before it is useful. > > > > The only difference seems to be the presence of templates but I don't know what they are. > The I-D says: | // e.g., removal of 'inactive' | // nodes, expansion of templates So it is not just templates. And yes, these are things several real-world implementations can do but where the IETF did not yet managed to standardize anything. The basic question is whether we want a model that is (a) capable to match real-world implementation and that allows for future standards of existing proprietary technology or (b) we go with what we have today (either chartered or published) and we keep revising the model as we move ahead. /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 Jan 9 13:17:14 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAC5129522 for ; Mon, 9 Jan 2017 13:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nl2ohEyUa8F for ; Mon, 9 Jan 2017 13:17:10 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5F461295EA for ; Mon, 9 Jan 2017 13:17:10 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id v23so148164053qtb.0 for ; Mon, 09 Jan 2017 13:17:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=7/ywd0bSWTmjlsMyk+YbgF2MueENh23gG7QaiOoWQIY=; b=LddZl/0XnajepTLf8QUovLc0LugRJCgh9KS+MCuh/L124DuKXIlKNGQU/iXhqFqiXJ JozwdgDJrNrSIjihKOajX0rRz/QeTOkAKJMZwO0zM1a3uuoBLQ2nHjaq6Ym4GVENusUM o/OPjcbRalqYniv/xgresjN7nU0B4vz3w5+zVJ+hAilP0qb4FtULMTWmAOnipC5jIjNd iVXYeIjp5DbFVNxyU9b2fb3bKsc2JZ1XuKAQRnaqGHOoX8I+dSdasrMYTVZXNno6awpr LQNN+2MxQ3jXX2c+4ecIwumy4eSdKxB0j11B7GHo15WBQs4UxtoFkIkfPvJEFGsbQuky cbpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=7/ywd0bSWTmjlsMyk+YbgF2MueENh23gG7QaiOoWQIY=; b=UK9vh3owIZ1yj2askTj4d07W9EMR0VGtDq07hVLakVGUbFe6GRYl+nqW6h+5YJHSEj IKTSxV1v24hmn8ZdiqF22VblbKJIJjjwdK+/RSRX179dAN8bJ/zuPuOQ25TIzVT7QA5o mDxp8yGv1olOGySGjBP9rupiIgF/JA6VQCyG6TMjOQ2NnNm5LgDGUidQDYmbY29RhafD iFNvuuaSA3x+LABBjwSf77TPc0bw2VrGiAps/E+m7YJzrVETaTI/IrnbvpQehjOd4kZ0 c/lCUTT+G/4NmZ0VARYkieULGeIrf3BruP3/nZJOG0vh0xvqzZpyHUpcllpQoZVe22Hr mLBw== X-Gm-Message-State: AIkVDXIoBmWBWAhClYJlUzC3wf1aZhk4LmDn0g1WOOiyc24xhBBrU/ncXA426pZk/yTtBchNbHj/KntzDbixqA== X-Received: by 10.200.40.245 with SMTP id j50mr21677281qtj.72.1483996629761; Mon, 09 Jan 2017 13:17:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Mon, 9 Jan 2017 13:17:09 -0800 (PST) In-Reply-To: <20170109205109.GA15144@elstar.local> References: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> From: Andy Bierman Date: Mon, 9 Jan 2017 13:17:09 -0800 Message-ID: To: Juergen Schoenwaelder , Ladislav Lhotka , Andy Bierman , Netconf , NetMod WG Content-Type: multipart/alternative; boundary=001a1146f762f729510545afe310 Archived-At: Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 21:17:13 -0000 --001a1146f762f729510545afe310 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 9, 2017 at 12:51 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Jan 09, 2017 at 09:18:46PM +0100, Ladislav Lhotka wrote: > > > > I am more concerned about use cases that are not known so far, and so I > am against standardizing this (or any other) workflow as the only one > supported by NETCONF/RESTCONF and YANG. I believe both the protocols and > YANG can work with any set of datastores, but their choice depends on the > use case at hand. Why should IoT developers be exposed to the > running-intended-applied complexity, even if they are allowed to lump all > three into one? > > > > Please point me to the statement in the I-D that makes you believe an > implementation is required to support all datastores. > > > > There are no standard mechanisms that cause to be > > > different from , so I would agree the intended datastore > > > needs a lot more standards support before it is useful. > > > > > > > The only difference seems to be the presence of templates but I don't > know what they are. > > > > The I-D says: > > | // e.g., removal of 'inactive' > | // nodes, expansion of templates > > So it is not just templates. And yes, these are things several > real-world implementations can do but where the IETF did not yet > managed to standardize anything. The basic question is whether we want > a model that is (a) capable to match real-world implementation and > that allows for future standards of existing proprietary technology or > (b) we go with what we have today (either chartered or published) and > we keep revising the model as we move ahead. > > I think itt is not realistic to say that datastores are optional. e.g. leaf: If there is a standard way to enable/disable config then individual "enabled" leafs are redundant. However XPath (must/when) has no way to describe if the subtree is enabled (which is a show-stopper) vs . If the applied or operational datastore is assumed, then there is no need to model the redundant config-as-operstate. If this is left out of the model, then the datastore becomes mandatory. If it is left in the model, the datasore becomes redundant. The basic premise that these datastores are optional is flawed. One cannot design a YANG module assuming the datastores are present if they are in fact optional. /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a1146f762f729510545afe310 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 9, 2017 at 12:51 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Jan 09, 2017 at 09:18:46PM +0100, Ladislav L= hotka wrote:
>
> I am more concerned about use cases that are not known so far, and so = I am against standardizing this (or any other) workflow as the only one sup= ported by NETCONF/RESTCONF and YANG. I believe both the protocols and YANG = can work with any set of datastores, but their choice depends on the use ca= se at hand. Why should IoT developers be exposed to the running-intended-ap= plied complexity, even if they are allowed to lump all three into one?
>

Please point me to the statement in the I-D that makes you believe an
implementation is required to support all datastores.

> > There are no standard mechanisms that cause <running> to be=
> > different from <intended>, so I would agree the intended da= tastore
> > needs a lot more standards support before it is useful.
> >
>
> The only difference seems to be the presence of templates but I don= 9;t know what they are.
>

The I-D says:

=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 // e.g., removal of &= #39;inactive'
=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 // nodes, expansion o= f templates

So it is not just templates. And yes, these are things several
real-world implementations can do but where the IETF did not yet
managed to standardize anything. The basic question is whether we want
a model that is (a) capable to match real-world implementation and
that allows for future standards of existing proprietary technology or
(b) we go with what we have today (either chartered or published) and
we keep revising the model as we move ahead.



I think itt is not realistic to say t= hat datastores are optional.

e.g. <enabled> = leaf: =C2=A0If there is a standard way to enable/disable config
t= hen individual "enabled" leafs are redundant. However XPath (must= /when)
has no way to describe if the subtree is enabled (which is= a show-stopper)

<foo-config> vs <foo-ope= r>.=C2=A0 If the applied or operational datastore is assumed,
= then there is no need to model the redundant config-as-operstate.
If this is left out of the model, then the datastore becomes mandatory.
If it is left in the model, the datasore becomes redundant.

The basic premise that these datastores are optional is f= lawed.
One cannot design a YANG module assuming the datastores ar= e present
if they are in fact optional.

=
/js


Andy

=C2=A0
--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--001a1146f762f729510545afe310-- From nobody Mon Jan 9 13:56:29 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F38129879 for ; Mon, 9 Jan 2017 13:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFT55lNobaxq for ; Mon, 9 Jan 2017 13:56:26 -0800 (PST) Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2D70129411 for ; Mon, 9 Jan 2017 13:56:26 -0800 (PST) From: Alex Campbell To: "netmod@ietf.org" Thread-Topic: "when" statement deviation Thread-Index: AQHSasHnw6Q6qakWhES8uSJgdt8CKg== Date: Mon, 9 Jan 2017 21:56:24 +0000 Message-ID: <1483998985075.53748@Aviatnet.com> Accept-Language: en-NZ, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.15.6.10] Content-Type: multipart/alternative; boundary="_000_148399898507553748Aviatnetcom_" MIME-Version: 1.0 Archived-At: Subject: [netmod] "when" statement deviation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 21:56:28 -0000 --_000_148399898507553748Aviatnetcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have a module that adds some configuration to interfaces (the specific fe= ature being configured isn't important here, so I'll just call it "feature"= ). I want to implement this module, but the device I'm working on only support= s the feature on some kinds of interfaces. So I want to add a "when" constraint in a deviation module that says the fe= ature configuration is only available for these kinds of interfaces. However, I found that "when" statements are not allowed to be affected by d= eviations (according to the RFC and according to confdc). Is there a reason for this? It seems like an oversight. Example: module feature-module { // ... prefix, imports, etc ... import ietf-interfaces {prefix if;} augment /if:interfaces/if:interface { container feature { leaf enabled { type boolean; description "Enables the feature"; } } } } module feature-module-deviations { // ... prefix, imports, etc ... import feature-module {prefix fm;} import iana-if-types {prefix ianaift;} deviation /if:interfaces/if:interface/fm:feature { deviate add { // parsing fails here; "when" is not allowed as a child of = "deviate" when "../if:type =3D 'ianaift:ethernetCsmacd' or ../if:type= =3D 'ianaift:ieee8023adLag'"; } } } Alex --_000_148399898507553748Aviatnetcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,


I have a module that adds some configuration to interfaces (the specific= feature being configured isn't important here, so I'll just call it "= feature").

I want to implement this module, but the device I'm working on only supp= orts the feature on some kinds of interfaces.

So I want to add a "when" constraint in a deviation module tha= t says the feature configuration is only available for these kinds of inter= faces.


However, I found that "when" statements are not allowed to be = affected by deviations (according to the RFC and according to confdc).

Is there a reason for this? It seems like an oversight.


Example:


    module feature-module {

        // ... prefix, imports, etc ...

        import ietf-interfaces {prefix if;}


        augment /if:interfaces/if:interface {

            container feature {

                leaf enabled {

                    ty= pe boolean;

                    de= scription "Enables the feature";

                }

            }

        }

    }


    module feature-module-deviations {

        // ... prefix, imports, etc ...

        import feature-module {prefix fm;}

        import iana-if-types {prefix ianaift;}


        deviation /if:interfaces/if:interface/fm:fea= ture {

            deviate add {

                // parsing fails= here; "when" is not allowed as a child of "deviate"

                when "../if= :type =3D 'ianaift:ethernetCsmacd' or ../if:type =3D 'ianaift:ieee8023adLag= '";

            }

        }

    }


Alex


--_000_148399898507553748Aviatnetcom_-- From nobody Mon Jan 9 14:20:59 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCA012960E for ; Mon, 9 Jan 2017 14:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLGUuhUteGtO for ; Mon, 9 Jan 2017 14:20:55 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B91E4129634 for ; Mon, 9 Jan 2017 14:20:55 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id a20so157054962qkc.1 for ; Mon, 09 Jan 2017 14:20:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xBriKVRrSTFRODdMwleM58kD6KrnFDN+ZNC0qG9xI9k=; b=ZptUF1zXv/xXgHh4213t+3Gd4s1bsdw9BvIznpMurfpa7hGFWp83B3YvzSDVO7hjkR nExM7PIhBjoSbzuFAAqQU5uRQu8i/1vSydr7KUFX86On7xTFw0sKyGjgzmOYabaJPKuS xWGsnmRa38LXzbkX/0iAgIpF9bB0tWxSdn5sI7uCWEdJqjm5fFlBFC6XNYPEzUw/cJsx kSlzG9lE9qAQW7gb5K6f1oJ03zV8tJO1npGNGEDvgVkgCYjD6eCgsYjnB1VOPBKBUURt EdvFsrp2O4PXsgqfYdhyq21EZ7Wp03MADHn0Ps+6eF4wKT5zS7HS0NZQIv88M7HqtEoD KPQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xBriKVRrSTFRODdMwleM58kD6KrnFDN+ZNC0qG9xI9k=; b=QXH2vaoNJdxYjxmhtytUoKqnjMfOQhDNLX3GblOXRawsXGqMu6uqZUTRU6na2NDlCq ge1FmPXiDntwNmY9xKZoDuFgd+3RWNCxQFsG/xXehBNr27hCBeCWrObFP8Vkxi6/fEsv Duw/1fwKIhJxPmSDFpKfECPScbIauDev3xyxvVhPhRbaINd7rcN2zVsG9ticzvqU3Rk8 kMzAH0z4XsniLVZgGMhgCK6AJH53ZSwKjuyS6RCB2YAc/0mOHCd8+/BB2OBZ4NElQJ57 WW1/6eFZU6wf9xmRdLQLP4nAMgT56OpvPAQBtGM1vCpEUODS7iYECWRaKjWLz4LQUO89 izTw== X-Gm-Message-State: AIkVDXKwpN7ebXQqFr9i/viDZCi5WdzgMm60fNFRc4Xjf5nWDQt59jJOY3r/M/lqqoAifXbZjW5KkIfJaT6SbQ== X-Received: by 10.55.76.197 with SMTP id z188mr86734143qka.184.1484000454877; Mon, 09 Jan 2017 14:20:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Mon, 9 Jan 2017 14:20:54 -0800 (PST) In-Reply-To: <1483998985075.53748@Aviatnet.com> References: <1483998985075.53748@Aviatnet.com> From: Andy Bierman Date: Mon, 9 Jan 2017 14:20:54 -0800 Message-ID: To: Alex Campbell Content-Type: multipart/alternative; boundary=001a114a8062f5c26e0545b0c7e7 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] "when" statement deviation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 22:20:58 -0000 --001a114a8062f5c26e0545b0c7e7 Content-Type: text/plain; charset=UTF-8 Hi, This is not allowed because it is too complicated to implement. Changing the schema tree based on values of instances within the schema tree is full of complications. Note that when-stmt used where allowed enables or disables the schema tree without changing it. This is hard enough to support. Andy On Mon, Jan 9, 2017 at 1:56 PM, Alex Campbell wrote: > Hi, > > > I have a module that adds some configuration to interfaces (the specific > feature being configured isn't important here, so I'll just call it > "feature"). > > I want to implement this module, but the device I'm working on only > supports the feature on some kinds of interfaces. > > So I want to add a "when" constraint in a deviation module that says the > feature configuration is only available for these kinds of interfaces. > > > However, I found that "when" statements are not allowed to be affected by > deviations (according to the RFC and according to confdc). > > Is there a reason for this? It seems like an oversight. > > > Example: > > > module feature-module { > > // ... prefix, imports, etc ... > > import ietf-interfaces {prefix if;} > > > augment /if:interfaces/if:interface { > > container feature { > > leaf enabled { > > type boolean; > > description "Enables the feature"; > > } > > } > > } > > } > > > module feature-module-deviations { > > // ... prefix, imports, etc ... > > import feature-module {prefix fm;} > > import iana-if-types {prefix ianaift;} > > > deviation /if:interfaces/if:interface/fm:feature { > > deviate add { > > // parsing fails here; "when" is not allowed as a child of > "deviate" > > when "../if:type = 'ianaift:ethernetCsmacd' or ../if:type > = 'ianaift:ieee8023adLag'"; > > } > > } > > } > > > Alex > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --001a114a8062f5c26e0545b0c7e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

This is not allowed because it is t= oo complicated to implement.
Changing the schema tree based on va= lues of instances within the schema tree
is full of complications= .

Note that when-stmt used where allowed enables o= r disables the schema tree
without changing it. This is hard enou= gh to support.


Andy

<= /div>

On Mon= , Jan 9, 2017 at 1:56 PM, Alex Campbell <Alex.Campbell@aviatnet.c= om> wrote:

Hi,


I have a module that adds some configuration to interfaces (the specific= feature being configured isn't important here, so I'll just call i= t "feature").

I want to implement this module, but the device I'm working on only = supports the feature on some kinds of interfaces.

So I want to add a "when" constraint in a deviation module tha= t says the feature configuration is only available for these kinds of inter= faces.


However, I found that "when" statements are not allowed to be = affected by deviations (according to the RFC and according to confdc).

Is there a reason for this? It seems like an oversight.


Example:


=C2=A0 =C2=A0 module feature-module {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 // ... prefix, imports, etc ...

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0import ietf-interfaces {prefix if;}


=C2=A0 =C2=A0 =C2=A0 =C2=A0 augment /if:interfaces/if:interface {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 container feature {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf enabled {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ty= pe boolean;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 de= scription "Enables the feature";

=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 module feature-module-deviations {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 // ... prefix, imports, etc ...

=C2=A0 =C2=A0 =C2=A0 =C2=A0 import feature-module {prefix fm;}

=C2=A0 =C2=A0 =C2=A0 =C2=A0 import iana-if-types {prefix ianaift;}


=C2=A0 =C2=A0 =C2=A0 =C2=A0 deviation /if:interfaces/if:interface/f= m:feature {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 deviate add {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // parsing fails= here; "when" is not allowed as a child of "deviate"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 when "../if= :type =3D 'ianaift:ethernetCsmacd' or ../if:type =3D 'ianaift:i= eee8023adLag'";

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

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

=C2=A0 =C2=A0 }


Alex



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

--001a114a8062f5c26e0545b0c7e7-- From nobody Mon Jan 9 14:27:01 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8087512963E for ; Mon, 9 Jan 2017 14:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfzhX3ASJkjR for ; Mon, 9 Jan 2017 14:26:58 -0800 (PST) Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9519412960E for ; Mon, 9 Jan 2017 14:26:58 -0800 (PST) From: Alex Campbell To: Andy Bierman Thread-Topic: [netmod] "when" statement deviation Thread-Index: AQHSasHnw6Q6qakWhES8uSJgdt8CKqExPeEA//97QZ8= Date: Mon, 9 Jan 2017 22:26:57 +0000 Message-ID: <1484000817348.22234@Aviatnet.com> References: <1483998985075.53748@Aviatnet.com>, In-Reply-To: Accept-Language: en-NZ, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.15.6.10] Content-Type: multipart/alternative; boundary="_000_148400081734822234Aviatnetcom_" MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] "when" statement deviation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 22:27:00 -0000 --_000_148400081734822234Aviatnetcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't see how a "when" statement modified by a deviation is any more comp= licated to implement than a "when" statement outside of a deviation - presu= ming that augments and deviations are processed before "when" statements. Alex ________________________________ From: Andy Bierman Sent: Tuesday, 10 January 2017 11:20 a.m. To: Alex Campbell Cc: netmod@ietf.org Subject: Re: [netmod] "when" statement deviation Hi, This is not allowed because it is too complicated to implement. Changing the schema tree based on values of instances within the schema tre= e is full of complications. Note that when-stmt used where allowed enables or disables the schema tree without changing it. This is hard enough to support. Andy On Mon, Jan 9, 2017 at 1:56 PM, Alex Campbell > wrote: Hi, I have a module that adds some configuration to interfaces (the specific fe= ature being configured isn't important here, so I'll just call it "feature"= ). I want to implement this module, but the device I'm working on only support= s the feature on some kinds of interfaces. So I want to add a "when" constraint in a deviation module that says the fe= ature configuration is only available for these kinds of interfaces. However, I found that "when" statements are not allowed to be affected by d= eviations (according to the RFC and according to confdc). Is there a reason for this? It seems like an oversight. Example: module feature-module { // ... prefix, imports, etc ... import ietf-interfaces {prefix if;} augment /if:interfaces/if:interface { container feature { leaf enabled { type boolean; description "Enables the feature"; } } } } module feature-module-deviations { // ... prefix, imports, etc ... import feature-module {prefix fm;} import iana-if-types {prefix ianaift;} deviation /if:interfaces/if:interface/fm:feature { deviate add { // parsing fails here; "when" is not allowed as a child of = "deviate" when "../if:type =3D 'ianaift:ethernetCsmacd' or ../if:type= =3D 'ianaift:ieee8023adLag'"; } } } Alex _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_148400081734822234Aviatnetcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I don't see how a "when" statement modified by a deviation is = any more complicated to implement than a "when" statement outside= of a deviation - presuming that augments and deviations are processed befo= re "when" statements.


Alex



From: Andy Bierman <and= y@yumaworks.com>
Sent: Tuesday, 10 January 2017 11:20 a.m.
To: Alex Campbell
Cc: netmod@ietf.org
Subject: Re: [netmod] "when" statement deviation
 
Hi,

This is not allowed because it is too complicated to implement.
Changing the schema tree based on values of instances within the schem= a tree
is full of complications.

Note that when-stmt used where allowed enables or disables the schema = tree
without changing it. This is hard enough to support.


Andy


On Mon, Jan 9, 2017 at 1:56 PM, Alex Campbell <Alex.Ca= mpbell@aviatnet.com> wrote:

Hi,


I have a module that adds some configuration to interfaces (the specific= feature being configured isn't important here, so I'll just call it "= feature").

I want to implement this module, but the device I'm working on only supp= orts the feature on some kinds of interfaces.

So I want to add a "when" constraint in a deviation module tha= t says the feature configuration is only available for these kinds of inter= faces.


However, I found that "when" statements are not allowed to be = affected by deviations (according to the RFC and according to confdc).

Is there a reason for this? It seems like an oversight.


Example:


    module feature-module {

        // ... prefix, imports, etc ...

        import ietf-interfaces {prefix if;}


        augment /if:interfaces/if:interface {

            container feature {

                leaf enabled {

                    ty= pe boolean;

                    de= scription "Enables the feature";

                }

            }

        }

    }


    module feature-module-deviations {

        // ... prefix, imports, etc ...

        import feature-module {prefix fm;}

        import iana-if-types {prefix ianaift;}


        deviation /if:interfaces/if:interface/f= m:feature {

            deviate add {

                // parsing fails= here; "when" is not allowed as a child of "deviate"

                when "../if= :type =3D 'ianaift:ethernetCsmacd' or ../if:type =3D 'ianaift:ieee8023adLag= '";

            }

        }

    }


Alex



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

--_000_148400081734822234Aviatnetcom_-- From nobody Mon Jan 9 14:32:42 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F161129893 for ; Mon, 9 Jan 2017 14:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUhqF13pixEm for ; Mon, 9 Jan 2017 14:32:39 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C9B712988C for ; Mon, 9 Jan 2017 14:32:39 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id k15so379563578qtg.3 for ; Mon, 09 Jan 2017 14:32:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ar5fK51cToWyxiGwn8siOZVpCe3OF0Z+XiFG2ZPCmCU=; b=y+wSUvm2NNL4AmWZ2Hg5IgD4q7AUn+aJaUu594n/qQtaA4k/aWnVRuefLo6L82CQbi bYOX39BFidWZ+ahPomj6YS+43BfJLcDZlWVG0YfLGy7ySVUwmkZLitZzDJ7KsDVlSAQ9 8U7+sVZCz5Y0Jq3cqjyG+mSmF0/8FMc4Solg6RUVPCQxprgOJE5C1oVi/Bs0XA/gJ1n1 top60DQTn9F9+4J4dHEDj6TbQTNotPItsLQzF0WA3hDuXpQB/Pi/00yQjmDLc25K6GDo 4zT2xUfqzc+XrNQN7aMwraeevj7hVj8vrCww8h2Kmjkc/SYfKMDk36w6DsHEQP3Lczd4 k7jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ar5fK51cToWyxiGwn8siOZVpCe3OF0Z+XiFG2ZPCmCU=; b=OJgIaKPfRyLnWfZWBDQqRfSor7Wr3VrIedocTD+d4FM3Y7rv6W+AxJ733PgaFlA1ZF wRBqTCSaCWNACi/QWy0+4lSIzKqxbSgXkE6KWOBph71cfhywm2IRjdy0lL+No+TQ5ZfH LVOyPCZoSl/u1JmBkdzp97vTD+J9B0FQxRr+zgxHnFsiB5aBmrpMFrUiNKaFeJhM9IPZ VEtVFUFxh6yM6ZHgXGLBfGbI0MZ47yqe+aQol6x0tHm0tJsqoqTt3kE3dY1HYqGjVjgD ZCPenyaz7o1r5VtwbHC76JBTHU8rREiMLHKajOwnumm4H278xYgXW/xvZatfuinLR5dy 08lQ== X-Gm-Message-State: AIkVDXIqdCHVgl7AUQf9tBc8JkEXaBfKaCWnwW8Rr3EzhlbatlHk2RsV9IwsdTZTjTYlE3/X7jEZszHy50UL6Q== X-Received: by 10.237.34.239 with SMTP id q44mr30918qtc.18.1484001158224; Mon, 09 Jan 2017 14:32:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Mon, 9 Jan 2017 14:32:37 -0800 (PST) In-Reply-To: <1484000817348.22234@Aviatnet.com> References: <1483998985075.53748@Aviatnet.com> <1484000817348.22234@Aviatnet.com> From: Andy Bierman Date: Mon, 9 Jan 2017 14:32:37 -0800 Message-ID: To: Alex Campbell Content-Type: multipart/alternative; boundary=001a113e7aeee2087c0545b0f194 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] "when" statement deviation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 22:32:41 -0000 --001a113e7aeee2087c0545b0f194 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 9, 2017 at 2:26 PM, Alex Campbell wrote: > I don't see how a "when" statement modified by a deviation is any more > complicated to implement than a "when" statement outside of a deviation - > presuming that augments and deviations are processed before "when" > statements. > > > augments and deviations are processed once when the module is loaded. A when-stmt is processed anytime the value of the XPath boolean result changes. Alex > > > Andy > ------------------------------ > *From:* Andy Bierman > *Sent:* Tuesday, 10 January 2017 11:20 a.m. > *To:* Alex Campbell > *Cc:* netmod@ietf.org > *Subject:* Re: [netmod] "when" statement deviation > > Hi, > > This is not allowed because it is too complicated to implement. > Changing the schema tree based on values of instances within the schema > tree > is full of complications. > > Note that when-stmt used where allowed enables or disables the schema tree > without changing it. This is hard enough to support. > > > Andy > > > On Mon, Jan 9, 2017 at 1:56 PM, Alex Campbell > wrote: > >> Hi, >> >> >> I have a module that adds some configuration to interfaces (the specific >> feature being configured isn't important here, so I'll just call it >> "feature"). >> >> I want to implement this module, but the device I'm working on only >> supports the feature on some kinds of interfaces. >> >> So I want to add a "when" constraint in a deviation module that says the >> feature configuration is only available for these kinds of interfaces. >> >> >> However, I found that "when" statements are not allowed to be affected by >> deviations (according to the RFC and according to confdc). >> >> Is there a reason for this? It seems like an oversight. >> >> >> Example: >> >> >> module feature-module { >> >> // ... prefix, imports, etc ... >> >> import ietf-interfaces {prefix if;} >> >> >> augment /if:interfaces/if:interface { >> >> container feature { >> >> leaf enabled { >> >> type boolean; >> >> description "Enables the feature"; >> >> } >> >> } >> >> } >> >> } >> >> >> module feature-module-deviations { >> >> // ... prefix, imports, etc ... >> >> import feature-module {prefix fm;} >> >> import iana-if-types {prefix ianaift;} >> >> >> deviation /if:interfaces/if:interface/fm:feature { >> >> deviate add { >> >> // parsing fails here; "when" is not allowed as a child >> of "deviate" >> >> when "../if:type = 'ianaift:ethernetCsmacd' or ../if:type >> = 'ianaift:ieee8023adLag'"; >> >> } >> >> } >> >> } >> >> >> Alex >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> > --001a113e7aeee2087c0545b0f194 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 9, 2017 at 2:26 PM, Alex Campbell <Alex.Campbell@= aviatnet.com> wrote:

I don't see how a "when" statement modified by a deviation= is any more complicated to implement than a "when" statement out= side of a deviation - presuming that augments and deviations are processed = before "when" statements.



augments and deviations a= re processed once when the module is loaded.
A when-stmt is proce= ssed anytime the value of the XPath boolean result changes.=C2=A0


Alex



Andy
=C2=A0


From:= Andy Bierman <a= ndy@yumaworks.com>
Sent: Tuesday, 10 January 2017 11:20 a.m.
To: Alex Campbell
Cc: netmod@ietf= .org
Subject: Re: [netmod] "when" statement deviation
=C2=A0
Hi,

This is not allowed because it is too complicated to implement.
Changing the schema tree based on values of instances within the schem= a tree
is full of complications.

Note that when-stmt used where allowed enables or disables the schema = tree
without changing it. This is hard enough to support.


Andy


On Mon, Jan 9, 2017 at 1:56 PM, Alex Campbell <Alex.Ca= mpbell@aviatnet.com> wrote:

Hi,


I have a module that adds some configuration to interfaces (the specific= feature being configured isn't important here, so I'll just call i= t "feature").

I want to implement this module, but the device I'm working on only = supports the feature on some kinds of interfaces.

So I want to add a "when" constraint in a deviation module tha= t says the feature configuration is only available for these kinds of inter= faces.


However, I found that "when" statements are not allowed to be = affected by deviations (according to the RFC and according to confdc).

Is there a reason for this? It seems like an oversight.


Example:


=C2=A0 =C2=A0 module feature-module {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 // ... prefix, imports, etc ...

=C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0import ietf-interfaces {prefix if;}


=C2=A0 =C2=A0 =C2=A0 =C2=A0 augment /if:interfaces/if:interface {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 container feature {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf enabled {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ty= pe boolean;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 de= scription "Enables the feature";

=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 module feature-module-deviations {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 // ... prefix, imports, etc ...

=C2=A0 =C2=A0 =C2=A0 =C2=A0 import feature-module {prefix fm;}

=C2=A0 =C2=A0 =C2=A0 =C2=A0 import iana-if-types {prefix ianaift;}


=C2=A0 =C2=A0 =C2=A0 =C2=A0 deviation /if:interfaces/if:interface/fm:feature {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 deviate add {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // parsing fails= here; "when" is not allowed as a child of "deviate"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 when "../if= :type =3D 'ianaift:ethernetCsmacd' or ../if:type =3D 'ianaift:i= eee8023adLag'";

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

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

=C2=A0 =C2=A0 }


Alex



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


--001a113e7aeee2087c0545b0f194-- From nobody Mon Jan 9 17:31:05 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0361296A1 for ; Mon, 9 Jan 2017 17:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 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_NONE=-0.0001, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hq.sk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3oFZ5C1xd0J for ; Mon, 9 Jan 2017 17:31:01 -0800 (PST) Received: from mail.hq.sk (hq.sk [81.89.59.181]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CF2F1299D2 for ; Mon, 9 Jan 2017 17:31:01 -0800 (PST) Received: from [10.137.2.13] (chello085216197060.chello.sk [85.216.197.60]) by mail.hq.sk (Postfix) with ESMTPSA id C753E242383; Tue, 10 Jan 2017 02:30:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1484011858; bh=XpWOUsCDrxgJVaV4qRSe7LQCMRRAsDoohiQQt3iC7PQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=BuLNb7mhvCNlg19DbCWUr3SnhpWlEleosdXElJ0m7FzyA1ZIG6d0brk1StfA8rwQt lXjuy22QdDiqm1E/IG9UsXYfeAZM1mGqdVILcuD/kLgTcQX/AVT40GmAEWdGCAFspq BbrzzkqjA64cbDvvvFMFJJKriqRPCnV/LMc+PfNs= To: Andy Bierman , Alex Campbell References: <1483998985075.53748@Aviatnet.com> <1484000817348.22234@Aviatnet.com> From: Robert Varga Message-ID: <961c106a-a30a-5704-f279-5787787767e1@hq.sk> Date: Tue, 10 Jan 2017 02:30:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9dnkLNUBk3wePFBp8s6Alb2a6JRR9OnWj" Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] "when" statement deviation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 01:31:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9dnkLNUBk3wePFBp8s6Alb2a6JRR9OnWj Content-Type: multipart/mixed; boundary="nmpWw1i9FTFTwtAueatPIno810we26uCb"; protected-headers="v1" From: Robert Varga To: Andy Bierman , Alex Campbell Cc: "netmod@ietf.org" Message-ID: <961c106a-a30a-5704-f279-5787787767e1@hq.sk> Subject: Re: [netmod] "when" statement deviation References: <1483998985075.53748@Aviatnet.com> <1484000817348.22234@Aviatnet.com> In-Reply-To: --nmpWw1i9FTFTwtAueatPIno810we26uCb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01/09/2017 11:32 PM, Andy Bierman wrote: >=20 >=20 > On Mon, Jan 9, 2017 at 2:26 PM, Alex Campbell > > wrote:= >=20 > I don't see how a "when" statement modified by a deviation is any > more complicated to implement than a "when" statement outside of a > deviation - presuming that augments and deviations are processed > before "when" statements. >=20 >=20 >=20 > augments and deviations are processed once when the module is loaded. > A when-stmt is processed anytime the value of the XPath boolean result > changes.=20 Right, but that also means that processing a 'deviate add { when ... }' would occur only once, after which the cost would be the same as if that when statement was present in the original definition. In any case, the same effect can be achieved by deviate-adding an appropriate must statement -- which seems appropriate, as presumably you want to restrict the leaf from becoming 'true' rather than enforce it not being available at all. Regards, Robert --nmpWw1i9FTFTwtAueatPIno810we26uCb-- --9dnkLNUBk3wePFBp8s6Alb2a6JRR9OnWj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIoBAEBCgASBQJYdDlJCxxuaXRlQGhxLnNrAAoJECsDwSqgzwDTGYIQAImSfmhE EM5PF9c9yCi3h8f37IVlxg2vOuQ520wibFCa7KDnlADoCfFqi0jHpb6aQ2rk64p+ KYDIb9I5VeSeGeMZWqf68c0Hzn75igGpbLVE+gnRJv6lHC3586HPyOj7iE/O7rrr +bHmpNCpZC2zYfpAxQSUBI21e5xWBggIOwc20CYYa/mOCN6A2Rmu92fYWSOQPr/h +XiBZOOwR2vR4Fih8dpnReJd8sa6tD0d3CZhnfs9Zkp5KG42jnSl+Ifn1iGDaX80 0/3BoEGJtpLlBTD5ovUa4LCTVCtEoPrFw60btks69GcWOOckLz84o2uyEb/5ruEL vzObtLLDDbpH76lZZZJ7gJWYcJMiuDDws0R1R0B1Ifckbgfpsn8DWGgkb4ebcBvY hiWHBsoCxhJbpjxaTH4LzX4V/8u+0ZJ2vg/dzAkrS9ABQ9zxvBkwOtPNEZiuO+mf p821J89di2OlWWMbDtJ+ENWtncRGd9nZPyCfxjLZutPeHs6DWdBTf1yQK8dtxuBX SWDRdJXefC5fI/+7t1N+J6VT+/djfydabLSRoZdiPFsJ3KCqgyB1EPrixSZTkIN9 Y6O357+UlV5UiRIUmWSorNuaqVhnCwk7AdFxcHmGj9Nh2ZFUkKEYy0GkN0TkpiaL 1JVDr/s8MVjoAmF213t1SgRXCGpx+a5u6HTB =R5mk -----END PGP SIGNATURE----- --9dnkLNUBk3wePFBp8s6Alb2a6JRR9OnWj-- From nobody Mon Jan 9 23:21:11 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D29DE129B0E; Mon, 9 Jan 2017 23:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYJuDJETxp78; Mon, 9 Jan 2017 23:21:03 -0800 (PST) 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 80AF5129B09; Mon, 9 Jan 2017 23:21:03 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D95C775C; Tue, 10 Jan 2017 08:21:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id oMd8Ei57x-bR; Tue, 10 Jan 2017 08:21:00 +0100 (CET) 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, 10 Jan 2017 08:21:01 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 89CD02008D; Tue, 10 Jan 2017 08:21:01 +0100 (CET) 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 tH4epit3K4zZ; Tue, 10 Jan 2017 08:21:01 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 329972008C; Tue, 10 Jan 2017 08:21:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A6F963E078C4; Tue, 10 Jan 2017 08:21:03 +0100 (CET) Date: Tue, 10 Jan 2017 08:21:03 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20170110072103.GA16120@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , Netconf , NetMod WG References: <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: NetMod WG , Netconf Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 07:21:06 -0000 On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote: > > I think itt is not realistic to say that datastores are optional. > > e.g. leaf: If there is a standard way to enable/disable config > then individual "enabled" leafs are redundant. However XPath (must/when) > has no way to describe if the subtree is enabled (which is a show-stopper) I may not understand what you are saying. From what I know, there are implementations that allow to 'comment out' nodes and subtrees and that work with clients in a backwards compatible way. > vs . If the applied or operational datastore is > assumed, > then there is no need to model the redundant config-as-operstate. > If this is left out of the model, then the datastore becomes mandatory. > If it is left in the model, the datasore becomes redundant. > > The basic premise that these datastores are optional is flawed. > One cannot design a YANG module assuming the datastores are present > if they are in fact optional. The claim that all datastores are mandatory is equally flawed. /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 Jan 10 00:20:41 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8DC129B4E; Tue, 10 Jan 2017 00:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZNzfjC_GyQl; Tue, 10 Jan 2017 00:20:37 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A773127058; Tue, 10 Jan 2017 00:20:37 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:a482:2948:cd7d:d9e] (unknown [IPv6:2a01:5e0:29:fffe:a482:2948:cd7d:d9e]) by mail.nic.cz (Postfix) with ESMTPSA id B760960CAE; Tue, 10 Jan 2017 09:20:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484036435; bh=2FQhYzeXF8eynKSdK6lUIDeoKEuDyLHIfRIlfEXQ+E8=; h=From:Date:To; b=Wu1dpL5b0adJBIQGr1/4pcUF5guCgWQ2Mp/Gcnl2iTDgEPHHJDiwRInKVF56z2eyk Y+z8SQchTSTjgfmq23nhGnQcnG3gZPyh3iYBBFTGOyAC5vSMh7+XEaMaJddg71arzI drnOp4UaqMf/F1zicE/kxZs3wXbvuf2x5yejGfxs= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170109205109.GA15144@elstar.local> Date: Tue, 10 Jan 2017 09:20:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3DFB70DC-010A-4CD0-BBBB-1478AC814923@nic.cz> References: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NetMod WG , Netconf Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 08:20:40 -0000 > On 9 Jan 2017, at 21:51, Juergen Schoenwaelder = wrote: >=20 > On Mon, Jan 09, 2017 at 09:18:46PM +0100, Ladislav Lhotka wrote: >>=20 >> I am more concerned about use cases that are not known so far, and so = I am against standardizing this (or any other) workflow as the only one = supported by NETCONF/RESTCONF and YANG. I believe both the protocols and = YANG can work with any set of datastores, but their choice depends on = the use case at hand. Why should IoT developers be exposed to the = running-intended-applied complexity, even if they are allowed to lump = all three into one? =20 >>=20 >=20 > Please point me to the statement in the I-D that makes you believe an > implementation is required to support all datastores. Sec. 6.3: "YANG currently describes validation in terms of the = configuration datastore while it really happens on the = configuration datastore." This seems to indicate that and are required, at = least conceptually. The original datastore model (sec. 4) was hardwired into NETCONF and = YANG specs but it was found insufficient for some use cases. So now we = come up with another datastore model, and I am against doing the same = mistake again. What if some future use cases again need something else? We could instead define the protocols and YANG in terms of reasonable = abstractions (e.g. resource and data tree), and use a run-time = specification of the datastore model (there could also be several = standardized alternatives). To some extent, we do it already now by = using capabilites such as "candidate", "startup" and "writable-running". >=20 >>> There are no standard mechanisms that cause to be >>> different from , so I would agree the intended datastore >>> needs a lot more standards support before it is useful. >>>=20 >>=20 >> The only difference seems to be the presence of templates but I don't = know what they are. >>=20 >=20 > The I-D says: >=20 > | // e.g., removal of 'inactive' > | // nodes, expansion of templates >=20 > So it is not just templates. And yes, these are things several > real-world implementations can do but where the IETF did not yet > managed to standardize anything. The basic question is whether we want > a model that is (a) capable to match real-world implementation and > that allows for future standards of existing proprietary technology or > (b) we go with what we have today (either chartered or published) and > we keep revising the model as we move ahead. I think we need protocol and YANG specs that are not tied to any = particular model and that are thus capable of matching unforeseen = real-world implementations. This is no sci-fi, HTTP and XML schema = languages work this way. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Jan 10 00:28:13 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E016129B58 for ; Tue, 10 Jan 2017 00:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwwYgPGJrjaM for ; Tue, 10 Jan 2017 00:28:10 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFFEA129B51 for ; Tue, 10 Jan 2017 00:28:09 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:a482:2948:cd7d:d9e] (unknown [IPv6:2a01:5e0:29:fffe:a482:2948:cd7d:d9e]) by mail.nic.cz (Postfix) with ESMTPSA id 8E15B60A57; Tue, 10 Jan 2017 09:28:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484036888; bh=4Z/6YCkk8kgZyDMp1l8TFv4s3c0bsVy0BD8d7nZSS3g=; h=From:Date:To; b=fSaZnfolbWF0yf3sfwsOy9+f/z9aqUGadnRRWfI2HVc+JJohAuVef+mk5ZH59U4a4 N5/ieSeQW5WW0zjitPRkJ8ZbUaBq8wlPmnhH0ay0GK534kpXZuSmB9+YB4NAnkyn9M MRcCmEPlFb1hsHxnhV/TImHeYF2vHPRnpBkIjEpA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <961c106a-a30a-5704-f279-5787787767e1@hq.sk> Date: Tue, 10 Jan 2017 09:28:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1483998985075.53748@Aviatnet.com> <1484000817348.22234@Aviatnet.com> <961c106a-a30a-5704-f279-5787787767e1@hq.sk> To: Robert Varga X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] "when" statement deviation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 08:28:11 -0000 > On 10 Jan 2017, at 02:30, Robert Varga wrote: >=20 > On 01/09/2017 11:32 PM, Andy Bierman wrote: >>=20 >>=20 >> On Mon, Jan 9, 2017 at 2:26 PM, Alex Campbell >> > = wrote: >>=20 >> I don't see how a "when" statement modified by a deviation is any >> more complicated to implement than a "when" statement outside of a >> deviation - presuming that augments and deviations are processed >> before "when" statements. >>=20 >>=20 >>=20 >> augments and deviations are processed once when the module is loaded. >> A when-stmt is processed anytime the value of the XPath boolean = result >> changes.=20 >=20 > Right, but that also means that processing a 'deviate add { when ... = }' > would occur only once, after which the cost would be the same as if = that > when statement was present in the original definition. I agree. >=20 > In any case, the same effect can be achieved by deviate-adding an > appropriate must statement -- which seems appropriate, as presumably = you > want to restrict the leaf from becoming 'true' rather than enforce it > not being available at all. Yes, except that a "when" constraint is stronger - it has to be = satisfied in all trees whereas "must" only in a valid tree (sec. 8.1 of = RFC 7950). Lada >=20 > Regards, > Robert >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Jan 10 00:39:48 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522FD129B7E; Tue, 10 Jan 2017 00:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6evzwb9ntZV; Tue, 10 Jan 2017 00:39:44 -0800 (PST) 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 D28E4129B59; Tue, 10 Jan 2017 00:39:43 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 81E83791; Tue, 10 Jan 2017 09:39:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id GEqsfH9bt1Z0; Tue, 10 Jan 2017 09:39:41 +0100 (CET) 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, 10 Jan 2017 09:39:42 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3B16A2008C; Tue, 10 Jan 2017 09:39:42 +0100 (CET) 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 DOM-z_iPEEbh; Tue, 10 Jan 2017 09:39:41 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DE87C20089; Tue, 10 Jan 2017 09:39:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A162F3E07C3A; Tue, 10 Jan 2017 09:39:43 +0100 (CET) Date: Tue, 10 Jan 2017 09:39:43 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20170110083942.GC16255@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Netconf , NetMod WG References: <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <3DFB70DC-010A-4CD0-BBBB-1478AC814923@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DFB70DC-010A-4CD0-BBBB-1478AC814923@nic.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: NetMod WG , Netconf Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 08:39:45 -0000 On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka wrote: > > I think we need protocol and YANG specs that are not tied to any particular model and that are thus capable of matching unforeseen real-world implementations. This is no sci-fi, HTTP and XML schema languages work this way. > I disagree that HTTP and XML schema languages do the same thing. Our goal is interoperable configuration of network devices; the notion of configuration datastore validation and specification of semantics goes well beyond what you usually find in web interactions, where typically all semantics are left to the implementor of a service. We validate configurations (residing in datastores), not the syntactic aspects of protocol messages. But yes, I am looking forward to a concrete I-D. /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 Jan 10 01:20:39 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC72D129BA5; Tue, 10 Jan 2017 01:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMjwxLhQMSWY; Tue, 10 Jan 2017 01:20:37 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AFA5129B94; Tue, 10 Jan 2017 01:20:36 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:a482:2948:cd7d:d9e] (unknown [IPv6:2a01:5e0:29:fffe:a482:2948:cd7d:d9e]) by mail.nic.cz (Postfix) with ESMTPSA id C4DB5600BE; Tue, 10 Jan 2017 10:20:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484040034; bh=xazYos30vLENnxtxr2O1elEh3e1kM5+ldNQDB9tao0g=; h=From:Date:To; b=FIR8NSr74Cp/l5wCfa2RKMh9L77DFM74+tjXzN2eclgQbwxAtA+Z1V2wtZLe9RRB9 NhsZV99+c4u4PdnnYnYSJPd7cyxVRtC20sRQbz4lr/rnwkMBjP3DhHAiwoU+PHYG6e tCnDBvw+uDEkICxnMzNjnl/eVcll1GIsxXICD7jo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170110083942.GC16255@elstar.local> Date: Tue, 10 Jan 2017 10:20:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2D981A38-CBE9-4F2D-A7A8-A366DE3A95CB@nic.cz> References: <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <3DFB70DC-010A-4CD0-BBBB-1478AC814923@nic.cz> <20170110083942.GC16255@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NetMod WG , Netconf Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 09:20:39 -0000 > On 10 Jan 2017, at 09:39, Juergen Schoenwaelder = wrote: >=20 > On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka wrote: >>=20 >> I think we need protocol and YANG specs that are not tied to any = particular model and that are thus capable of matching unforeseen = real-world implementations. This is no sci-fi, HTTP and XML schema = languages work this way. >>=20 >=20 > I disagree that HTTP and XML schema languages do the same thing. Our > goal is interoperable configuration of network devices; the notion of Even now, a client that's programmed to write straight to running isn't = interoperable with a server that has candidate and read-only running. A = RESTCONF server that supports only JSON isn't interoperable with a = client that supports only XML. We are not in a situation that every pair of a randomly chosen server = and client need to be interoperable. It's IMO perfectly fine if IoT and = ISP networks use different clients. Yet, both can still use the same = RESTCONF, same YANG, and even same YANG modules.=20 > configuration datastore validation and specification of semantics goes > well beyond what you usually find in web interactions, where typically > all semantics are left to the implementor of a service. We validate > configurations (residing in datastores), not the syntactic aspects of > protocol messages. But yes, I am looking forward to a concrete I-D. Where did I write anything about syntactic aspects of protocol messages? = Of course we need to validate datastores. In the case of YANG, my point = is that its spec could just define what a valid datastore (data tree) = is. What it needn't state is that running, intended or whatever MUST be = valid - it can be said elsewhere. Lada >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Jan 10 01:34:27 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4771C1296A7; Tue, 10 Jan 2017 01:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzeUY1H5zqH4; Tue, 10 Jan 2017 01:34:21 -0800 (PST) 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 8F6511279EB; Tue, 10 Jan 2017 01:34:21 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6571D6C8; Tue, 10 Jan 2017 10:34:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id UdjBgVddHOia; Tue, 10 Jan 2017 10:34:18 +0100 (CET) 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, 10 Jan 2017 10:34:19 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E45632008D; Tue, 10 Jan 2017 10:34:19 +0100 (CET) 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 znFrCYv2Xfcq; Tue, 10 Jan 2017 10:34:19 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7B3D82008C; Tue, 10 Jan 2017 10:34:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0205B3E07E38; Tue, 10 Jan 2017 10:34:21 +0100 (CET) Date: Tue, 10 Jan 2017 10:34:21 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20170110093421.GC16426@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Netconf , NetMod WG References: <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <3DFB70DC-010A-4CD0-BBBB-1478AC814923@nic.cz> <20170110083942.GC16255@elstar.local> <2D981A38-CBE9-4F2D-A7A8-A366DE3A95CB@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D981A38-CBE9-4F2D-A7A8-A366DE3A95CB@nic.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: NetMod WG , Netconf Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 09:34:23 -0000 On Tue, Jan 10, 2017 at 10:20:35AM +0100, Ladislav Lhotka wrote: > > > On 10 Jan 2017, at 09:39, Juergen Schoenwaelder wrote: > > > > On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka wrote: > >> > >> I think we need protocol and YANG specs that are not tied to any particular model and that are thus capable of matching unforeseen real-world implementations. This is no sci-fi, HTTP and XML schema languages work this way. > >> > > > > I disagree that HTTP and XML schema languages do the same thing. Our > > goal is interoperable configuration of network devices; the notion of > > Even now, a client that's programmed to write straight to running isn't interoperable with a server that has candidate and read-only running. A RESTCONF server that supports only JSON isn't interoperable with a client that supports only XML. > > We are not in a situation that every pair of a randomly chosen server and client need to be interoperable. It's IMO perfectly fine if IoT and ISP networks use different clients. Yet, both can still use the same RESTCONF, same YANG, and even same YANG modules. > Yes, there are optional protocol features and the protocols support negotiations of protocol features. Not a big deal. HTTP is full of this as well. The point is that writing to candidate has a well defined meaning because we defined how candidate behaves and interacts with the other datastores. If a client commits candidate, it knows what kind of changes it can expect to see in other datastores. If you want to do away with well-known datastores, you (a) either provide all the semantics we currently have hard-wired into well-known datastores as meta-data at runting (and you require that every client is able to interpret this meta-information correctly) or (b) you significantly loose functionality and we end up with generic editing protocols that unfortunately do not help much with configuration management (since we lost how information in differnet datastores interacts). In case I completely mis-understand you, consider to write an I-D. /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 Jan 10 06:33:41 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136C0129CE4; Tue, 10 Jan 2017 06:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuRMyQuVaK-4; Tue, 10 Jan 2017 06:33:29 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 529931294A3; Tue, 10 Jan 2017 06:33:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13891; q=dns/txt; s=iport; t=1484058808; x=1485268408; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=d6x5f20b1NJjFA54UIRr5jIbkKiMqZYwRGUD8IT2b8M=; b=AbVsuYbynopzHTlkSLQWKdxUtzHDkVZz6/TRbCoyG7GFE3ZFvR9Dw5Xa yEUgf6xhRN3MxODW9aP2AEKntKivDqrpJqUyRn4sLUWkTteugPALENZfj rCFfflEJs9LMYMPn+rn8q8XRbGiupkMvqQraj+jcl3TfPVOvGmhIdNXz1 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQD/73RY/xbLJq1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMsDgEBAQEBfgMsXo1XcpE1j3yFK4ILHwEKhB6BEEoCgjwUAQI?= =?us-ascii?q?BAQEBAQEBYyiEaQEBAQMBAQFsGQILEAgjBAcbDB8RBgEMBgIBAReITQgOskwri?= =?us-ascii?q?XcBAQEBAQEBAQEBAQEBAQEBAQEBAQEdBYZAggIIgleEZyaCB4MYBZUjhgCRUgK?= =?us-ascii?q?BdYULgyqGNYpjh3sfODZcEgcVFTiDejgcGIFHPjWIZgEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,344,1477958400"; d="scan'208,217";a="649678742" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jan 2017 14:33:24 +0000 Received: from [10.63.23.107] (dhcp-ensft1-uk-vla370-10-63-23-107.cisco.com [10.63.23.107]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v0AEXNYJ021844; Tue, 10 Jan 2017 14:33:23 GMT To: Andy Bierman , Juergen Schoenwaelder , Ladislav Lhotka , Netconf , NetMod WG References: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> From: Robert Wilton Message-ID: <77552791-5c65-23ca-0a2f-6af82d4cbd9e@cisco.com> Date: Tue, 10 Jan 2017 14:31:56 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EFBB52BABCFC9CF2A012F79E" Archived-At: Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 14:33:37 -0000 This is a multi-part message in MIME format. --------------EFBB52BABCFC9CF2A012F79E Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi, On 09/01/2017 21:17, Andy Bierman wrote: > > > On Mon, Jan 9, 2017 at 12:51 PM, Juergen Schoenwaelder > > wrote: > > On Mon, Jan 09, 2017 at 09:18:46PM +0100, Ladislav Lhotka wrote: > > > > I am more concerned about use cases that are not known so far, > and so I am against standardizing this (or any other) workflow as > the only one supported by NETCONF/RESTCONF and YANG. I believe > both the protocols and YANG can work with any set of datastores, > but their choice depends on the use case at hand. Why should IoT > developers be exposed to the running-intended-applied complexity, > even if they are allowed to lump all three into one? > > > > Please point me to the statement in the I-D that makes you believe an > implementation is required to support all datastores. > > > > There are no standard mechanisms that cause to be > > > different from , so I would agree the intended datastore > > > needs a lot more standards support before it is useful. > > > > > > > The only difference seems to be the presence of templates but I > don't know what they are. > > > > The I-D says: > > | // e.g., removal of 'inactive' > | // nodes, expansion of templates > > So it is not just templates. And yes, these are things several > real-world implementations can do but where the IETF did not yet > managed to standardize anything. The basic question is whether we want > a model that is (a) capable to match real-world implementation and > that allows for future standards of existing proprietary technology or > (b) we go with what we have today (either chartered or published) and > we keep revising the model as we move ahead. > > > > I think itt is not realistic to say that datastores are optional. > > e.g. leaf: If there is a standard way to enable/disable config > then individual "enabled" leafs are redundant. However XPath (must/when) > has no way to describe if the subtree is enabled (which is a show-stopper) > > vs . If the applied or operational datastore > is assumed, > then there is no need to model the redundant config-as-operstate. > If this is left out of the model, then the datastore becomes mandatory. > If it is left in the model, the datasore becomes redundant. > > The basic premise that these datastores are optional is flawed. > One cannot design a YANG module assuming the datastores are present > if they are in fact optional. I agree that these datastores are not all really optional. Current YANG models are structured assuming that there is no operational state datastore. They could be used on devices that support an operational state datastore, but there would likely be duplication of some of the data because it is represented in two places. But to design clean models with combined config and state, it is necessary to assume support for both "running" and also "operational state" datatstores. Such models could theoretically be used by devices that don't support the operational state datastore, but key information would be unavailable, so this doesn't feel like a pragmatic solution. However, it would to straight forward to write tooling (i.e. a plugin to pyang) that takes a YANG module designed assuming an operational state datastore and generate the missing config false leaves so that the model could also be used on devices that don't support an operational state datastore. This raises the question, or how do you know whether a model has been designed assuming support for an operational state datastore? For me the simplest solution appears to be to mark the models as YANG version 2.0. I would also propose revising NETCONF and RESTCONF to version 2, allowing the protocols to change to support an operational state datastore in a clean way. E.g. if a device supports an operational state datastore then it doesn't really make sense to continue to support the existing NETCONF GET operation. Thanks, Rob > > > /js > > > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------EFBB52BABCFC9CF2A012F79E Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi,


On 09/01/2017 21:17, Andy Bierman wrote:


On Mon, Jan 9, 2017 at 12:51 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Jan 09, 2017 at 09:18:46PM +0100, Ladislav Lhotka wrote:
>
> I am more concerned about use cases that are not known so far, and so I am against standardizing this (or any other) workflow as the only one supported by NETCONF/RESTCONF and YANG. I believe both the protocols and YANG can work with any set of datastores, but their choice depends on the use case at hand. Why should IoT developers be exposed to the running-intended-applied complexity, even if they are allowed to lump all three into one?
>

Please point me to the statement in the I-D that makes you believe an
implementation is required to support all datastores.

> > There are no standard mechanisms that cause <running> to be
> > different from <intended>, so I would agree the intended datastore
> > needs a lot more standards support before it is useful.
> >
>
> The only difference seems to be the presence of templates but I don't know what they are.
>

The I-D says:

| // e.g., removal of 'inactive'
| // nodes, expansion of templates

So it is not just templates. And yes, these are things several
real-world implementations can do but where the IETF did not yet
managed to standardize anything. The basic question is whether we want
a model that is (a) capable to match real-world implementation and
that allows for future standards of existing proprietary technology or
(b) we go with what we have today (either chartered or published) and
we keep revising the model as we move ahead.



I think itt is not realistic to say that datastores are optional.

e.g. <enabled> leaf: If there is a standard way to enable/disable config
then individual "enabled" leafs are redundant. However XPath (must/when)
has no way to describe if the subtree is enabled (which is a show-stopper)

<foo-config> vs <foo-oper>. If the applied or operational datastore is assumed,
then there is no need to model the redundant config-as-operstate.
If this is left out of the model, then the datastore becomes mandatory.
If it is left in the model, the datasore becomes redundant.

The basic premise that these datastores are optional is flawed.
One cannot design a YANG module assuming the datastores are present
if they are in fact optional.

I agree that these datastores are not all really optional.

Current YANG models are structured assuming that there is no operational state datastore. They could be used on devices that support an operational state datastore, but there would likely be duplication of some of the data because it is represented in two places.

But to design clean models with combined config and state, it is necessary to assume support for both "running" and also "operational state" datatstores. Such models could theoretically be used by devices that don't support the operational state datastore, but key information would be unavailable, so this doesn't feel like a pragmatic solution. However, it would to straight forward to write tooling (i.e. a plugin to pyang) that takes a YANG module designed assuming an operational state datastore and generate the missing config false leaves so that the model could also be used on devices that don't support an operational state datastore.

This raises the question, or how do you know whether a model has been designed assuming support for an operational state datastore? For me the simplest solution appears to be to mark the models as YANG version 2.0. I would also propose revising NETCONF and RESTCONF to version 2, allowing the protocols to change to support an operational state datastore in a clean way. E.g. if a device supports an operational state datastore then it doesn't really make sense to continue to support the existing NETCONF GET operation.

Thanks,
Rob




/js


Andy

--
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/>



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

--------------EFBB52BABCFC9CF2A012F79E-- From nobody Tue Jan 10 06:44:54 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F052D1294E6; Tue, 10 Jan 2017 06:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0Ye8UHvxLb5; Tue, 10 Jan 2017 06:44:48 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 548EB1294D2; Tue, 10 Jan 2017 06:44:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1171; q=dns/txt; s=iport; t=1484059487; x=1485269087; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=9B7jdtpg0eBBFmmf06Mx7nk35PrBImEGflpKp1+xkhs=; b=eQOtznmY3vux101tuqMv+9O+5LcW0Ussdhay+u0AD3bcmz99rNmgLvjS jbyfNUE0nJrVC7HTchD85B7lUrOMtJZWPhmKgtQDlVZ9gvYHmlqgomptT +WARhOMCn9cQxL99HRgQvf+YZgfiJuao79eD1z47bD8CiD80VyJBIYf/T g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAQBZ8nRY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzoBAQEBAX4DLF6NV3KRNZUnggsfC4UuSgKCPRQBAgEBAQEBAQF?= =?us-ascii?q?jKIRpAQEBAwEBATY2CxALDgojCycwBgEMBgIBAReITQgOslKKIgEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFhkWCAgiCV4osBZsjkVKKLIY1imOHex84gRISBxUVOIR?= =?us-ascii?q?mgUc+NYhmAQEB?= X-IronPort-AV: E=Sophos;i="5.33,344,1477958400"; d="scan'208";a="649679126" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jan 2017 14:44:43 +0000 Received: from [10.63.23.107] (dhcp-ensft1-uk-vla370-10-63-23-107.cisco.com [10.63.23.107]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v0AEigSH025464; Tue, 10 Jan 2017 14:44:42 GMT To: Lou Berger , Ladislav Lhotka , Andy Bierman References: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> From: Robert Wilton Message-ID: Date: Tue, 10 Jan 2017 14:43:15 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Netconf , NetMod WG Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 14:44:51 -0000 On 09/01/2017 12:38, Lou Berger wrote: > > > On January 9, 2017 7:25:24 AM Ladislav Lhotka wrote: >> >> The current document involves quite a lot of hand-waving, and that's >> why I was also reluctant to accept it as a WG standard-track >> deliverable. > > IMO I think we should do and document the work and then, once the is > general agreement, worry about number and publication status of > documents. +1 I would like to get on with the interesting work of actually working out the solution. Personally, I think that having it in one document makes it easier to review/discuss/etc. I also think that it would help this work progress more quickly which I still regard as being particularly important. I do also agree with Mehmet's suggestion of restructuring the existing YANG docs to make them more consistent, but I think that it would be a mistake to slow down this important work to what seems like a documentation cleanup task. Rob > > Lou > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Tue Jan 10 07:30:59 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E957129CF4 for ; Tue, 10 Jan 2017 07:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oh6ltiHn3Gpo for ; Tue, 10 Jan 2017 07:30:53 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEAD8129521 for ; Tue, 10 Jan 2017 07:30:52 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id k15so398161057qtg.3 for ; Tue, 10 Jan 2017 07:30:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=oqmPqaEMwErmf3hCrG9ogF/wBassD/oXkECv0Dwpjq8=; b=hGYh9vqeP1tq5bIVZ8SY93pltnfmrn6Wu7ipD9EE18LVMmiUHapgRyhcYZBnhkNL2+ fFvp6Ej8LcKI0MNz2tWDHX4hEaoCGghUX08FlUqr7pkL7TGkU7sqVP/hwo/8aQMRiSQC bHzTTaMzqB/0RuwaeLInllBB5W/ag94T9ly9Tlfl5HZHeXq13XHzKSqwirPwUin+GSm6 B1yjTnPiyaooyVMRtzh6Si9BqpLlLidjqGmEDdfFY5nNGpXleBhLXHCRVuzhALgtlZOe ol61xzSgwwVwITIYebFQLXPsqFx6e/3PjbeKuGgccjS0/Pm2qYxk9NzT3F7pLTpobv5L jiZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=oqmPqaEMwErmf3hCrG9ogF/wBassD/oXkECv0Dwpjq8=; b=UaYsTCVbsPuMrvwj1rnmXSXDFJ4p/ryQVJwXv1A158JjBRW0lRh1XWlsw/a9DTgisi MoWPKl132PeUM0O8QB04Bo6gsESK+gDKRsVh465gEJIosBqFyrr1TpiXKN3sLdItZ1DM ZVHOayfX8ruN2kKvMyB9sbWW/bxQY/SpV8a+iaoYuxK0w6WV8IQc8nPiYxFWetjxo0sY y5RcrHY1xDn4f4zC580RNtgnr5e7tOx/xoD/a+UUFuBXvDDU+ePcf81MuaBWomTM3Mbj ttQJyoIAsQ7EC+8np4oyY3xSqOdrXXb7CA0gDVwYWJ/14+jIHn5xXwqndGftoDh27/HL pfMw== X-Gm-Message-State: AIkVDXIpZl5u15pOzYuNEUzJ2EC8PkW0Y1POHTBYYxBVqKpTZFD61hkp1GhAZRiwESxn/aCLkjrwgpoBumnVag== X-Received: by 10.200.36.171 with SMTP id s40mr3057199qts.142.1484062251945; Tue, 10 Jan 2017 07:30:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Tue, 10 Jan 2017 07:30:51 -0800 (PST) In-Reply-To: <20170110072103.GA16120@elstar.local> References: <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> From: Andy Bierman Date: Tue, 10 Jan 2017 07:30:51 -0800 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , Ladislav Lhotka , Netconf , NetMod WG Content-Type: multipart/alternative; boundary=001a114033425a2e1c0545bf2b8a Archived-At: Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 15:30:55 -0000 --001a114033425a2e1c0545bf2b8a Content-Type: text/plain; charset=UTF-8 On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote: > > > > I think itt is not realistic to say that datastores are optional. > > > > e.g. leaf: If there is a standard way to enable/disable config > > then individual "enabled" leafs are redundant. However XPath (must/when) > > has no way to describe if the subtree is enabled (which is a > show-stopper) > > I may not understand what you are saying. From what I know, there are > implementations that allow to 'comment out' nodes and subtrees and > that work with clients in a backwards compatible way. > > > vs . If the applied or operational datastore is > > assumed, > > then there is no need to model the redundant config-as-operstate. > > If this is left out of the model, then the datastore becomes mandatory. > > If it is left in the model, the datasore becomes redundant. > > > > The basic premise that these datastores are optional is flawed. > > One cannot design a YANG module assuming the datastores are present > > if they are in fact optional. > > The claim that all datastores are mandatory is equally flawed. > > correct -- nobody is saying that. The reason this is different is that the YANG objects are impacted. Candidate vs. running has no impact whatsoever on the set of YANG modules. The protocol is not self-selecting some objects and making other objects invisible. But if I want to model , I will soon have to decide to use and allow all protocols to read it or model get-state(foo) and require a different module for each protocol. /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a114033425a2e1c0545bf2b8a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierm= an wrote:
>
> I think itt is not realistic to say that datastores are optional.
>
> e.g. <enabled> leaf:=C2=A0 If there is a standard way to enable/= disable config
> then individual "enabled" leafs are redundant. However XPath= (must/when)
> has no way to describe if the subtree is enabled (which is a show-stop= per)

I may not understand what you are saying. From what I know, there are
implementations that allow to 'comment out' nodes and subtrees and<= br> that work with clients in a backwards compatible way.

> <foo-config> vs <foo-oper>.=C2=A0 If the applied or operat= ional datastore is
> assumed,
> then there is no need to model the redundant config-as-operstate.
> If this is left out of the model, then the datastore becomes mandatory= .
> If it is left in the model, the datasore becomes redundant.
>
> The basic premise that these datastores are optional is flawed.
> One cannot design a YANG module assuming the datastores are present > if they are in fact optional.

The claim that all datastores are mandatory is equally flawed.


correct -- nobody is saying that.


The reason this is different is that the YANG objects= are impacted.
Candidate vs. running has no impact whatsoever on = the set of
YANG modules.=C2=A0 The protocol is not self-selecting= some objects
and making other objects invisible.

<= /div>
But if I want to model <foo-state>, I will soon have to dec= ide
to use <foo-state> and allow all protocols to read it o= r
model get-state(foo) and require a different module for each
protocol.


/js


Andy
=C2=A0
=
--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--001a114033425a2e1c0545bf2b8a-- From nobody Tue Jan 10 08:11:45 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3041D1295D9; Tue, 10 Jan 2017 08:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvv8i0QAWXdK; Tue, 10 Jan 2017 08:11:42 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD54A129BDD; Tue, 10 Jan 2017 08:11:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9248; q=dns/txt; s=iport; t=1484064691; x=1485274291; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=gcWZpBCNP3H6FuKSTalZsJ3VHZtgdxFPiZRAmP3gT5o=; b=Q+OG11vQYAEyt9NZIhxQqLH5edJi4EY65PdBfUO9XF6vaW0i8YT6D2pS HT0AHw+x6hNHPkgfsWP1ytNtfsCXZxHTT6Nw4V6eH1M11nDVcD1+fzNlE ig/V//zECYaRYVyrGpATQIBDanrjtXlQSvT7yb/4upUIEgnftyvrPpxHt Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQCyBnVY/xbLJq1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM6AQEBAQF+AyxejVdykTSPfIUrggsfAQqEHoEQSgKCQRQBAgE?= =?us-ascii?q?BAQEBAQFjKIRpAQEBBAEBbBkCCxAIIwQHGwwfEQYBDAYCAQGIbA6yZSuJeAEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR0FhkCCAoJfhGcmggeDGAWVI4YAkVKBd4g1I4Y?= =?us-ascii?q?SimOHex84gRISBxUVOIN6bIFHPjWIZgEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,344,1477958400"; d="scan'208,217";a="648660618" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jan 2017 16:11:27 +0000 Received: from [10.63.23.107] (dhcp-ensft1-uk-vla370-10-63-23-107.cisco.com [10.63.23.107]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v0AGBQAc022998; Tue, 10 Jan 2017 16:11:27 GMT To: Andy Bierman , Juergen Schoenwaelder , Ladislav Lhotka , Netconf , NetMod WG References: <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> From: Robert Wilton Message-ID: Date: Tue, 10 Jan 2017 16:11:21 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------AE56B3AA3639E1D0FC4B9D98" Archived-At: Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 16:11:44 -0000 This is a multi-part message in MIME format. --------------AE56B3AA3639E1D0FC4B9D98 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 10/01/2017 15:30, Andy Bierman wrote: > > > On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder > > wrote: > > On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote: > > > > I think itt is not realistic to say that datastores are optional. > > > > e.g. leaf: If there is a standard way to > enable/disable config > > then individual "enabled" leafs are redundant. However XPath > (must/when) > > has no way to describe if the subtree is enabled (which is a > show-stopper) > > I may not understand what you are saying. From what I know, there are > implementations that allow to 'comment out' nodes and subtrees and > that work with clients in a backwards compatible way. > > > vs . If the applied or operational > datastore is > > assumed, > > then there is no need to model the redundant config-as-operstate. > > If this is left out of the model, then the datastore becomes > mandatory. > > If it is left in the model, the datasore becomes redundant. > > > > The basic premise that these datastores are optional is flawed. > > One cannot design a YANG module assuming the datastores are present > > if they are in fact optional. > > The claim that all datastores are mandatory is equally flawed. > > > correct -- nobody is saying that. > > > The reason this is different is that the YANG objects are impacted. > Candidate vs. running has no impact whatsoever on the set of > YANG modules. The protocol is not self-selecting some objects > and making other objects invisible. > > But if I want to model , I will soon have to decide > to use and allow all protocols to read it or > model get-state(foo) and require a different module for each > protocol. The same module can be used for the set of protocols that are conceptually built around the same set of mandatory datastores. I.e. it isn't necessary to have a separate module for each protocol, and that hasn't been proposed. Rob > > > /js > > > > Andy > > > -- > 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 --------------AE56B3AA3639E1D0FC4B9D98 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 10/01/2017 15:30, Andy Bierman wrote:


On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote:
>
> I think itt is not realistic to say that datastores are optional.
>
> e.g. <enabled> leaf: If there is a standard way to enable/disable config
> then individual "enabled" leafs are redundant. However XPath (must/when)
> has no way to describe if the subtree is enabled (which is a show-stopper)

I may not understand what you are saying. From what I know, there are
implementations that allow to 'comment out' nodes and subtrees and
that work with clients in a backwards compatible way.

> <foo-config> vs <foo-oper>. If the applied or operational datastore is
> assumed,
> then there is no need to model the redundant config-as-operstate.
> If this is left out of the model, then the datastore becomes mandatory.
> If it is left in the model, the datasore becomes redundant.
>
> The basic premise that these datastores are optional is flawed.
> One cannot design a YANG module assuming the datastores are present
> if they are in fact optional.

The claim that all datastores are mandatory is equally flawed.


correct -- nobody is saying that.


The reason this is different is that the YANG objects are impacted.
Candidate vs. running has no impact whatsoever on the set of
YANG modules. The protocol is not self-selecting some objects
and making other objects invisible.

But if I want to model <foo-state>, I will soon have to decide
to use <foo-state> and allow all protocols to read it or
model get-state(foo) and require a different module for each
protocol.

The same module can be used for the set of protocols that are conceptually built around the same set of mandatory datastores. I.e. it isn't necessary to have a separate module for each protocol, and that hasn't been proposed.

Rob



/js


Andy

--
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

--------------AE56B3AA3639E1D0FC4B9D98-- From nobody Tue Jan 10 08:17:13 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2403129D1A; Tue, 10 Jan 2017 08:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMpQuxK5BXoO; Tue, 10 Jan 2017 08:17:08 -0800 (PST) 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 3535D129D27; Tue, 10 Jan 2017 08:16:44 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8B4C7769; Tue, 10 Jan 2017 17:16:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id EDpI-wANQ-tB; Tue, 10 Jan 2017 17:16:40 +0100 (CET) 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, 10 Jan 2017 17:16:42 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0F48F20090; Tue, 10 Jan 2017 17:16:42 +0100 (CET) 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 WAViZKz9uQkU; Tue, 10 Jan 2017 17:16:41 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 843E02008E; Tue, 10 Jan 2017 17:16:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0A9D33E08616; Tue, 10 Jan 2017 17:16:44 +0100 (CET) Date: Tue, 10 Jan 2017 17:16:43 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20170110161643.GE17035@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , Netconf , NetMod WG References: <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: NetMod WG , Netconf Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 16:17:10 -0000 On Tue, Jan 10, 2017 at 07:30:51AM -0800, Andy Bierman wrote: > On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote: > > > > > > I think itt is not realistic to say that datastores are optional. > > > > > > e.g. leaf: If there is a standard way to enable/disable config > > > then individual "enabled" leafs are redundant. However XPath (must/when) > > > has no way to describe if the subtree is enabled (which is a > > show-stopper) > > > > I may not understand what you are saying. From what I know, there are > > implementations that allow to 'comment out' nodes and subtrees and > > that work with clients in a backwards compatible way. > > > > > vs . If the applied or operational datastore is > > > assumed, > > > then there is no need to model the redundant config-as-operstate. > > > If this is left out of the model, then the datastore becomes mandatory. > > > If it is left in the model, the datasore becomes redundant. > > > > > > The basic premise that these datastores are optional is flawed. > > > One cannot design a YANG module assuming the datastores are present > > > if they are in fact optional. > > > > The claim that all datastores are mandatory is equally flawed. > > > > > correct -- nobody is saying that. Well, I originally commented on the statement that intened would be required and adding complexity - it does not. > The reason this is different is that the YANG objects are impacted. > Candidate vs. running has no impact whatsoever on the set of > YANG modules. The protocol is not self-selecting some objects > and making other objects invisible. Yes. And the same is true for intended as long as an implementation does not support templates or inactive configuration objects. > But if I want to model , I will soon have to decide > to use and allow all protocols to read it or > model get-state(foo) and require a different module for each > protocol. If you do /foo and /foo-state, things will just work with or without an operational state datastore. If you have only /foo, then an operational state datastore may come in handy if you have to support config and state with different lifetimes. /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 Jan 10 09:08:07 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFFC12967D; Tue, 10 Jan 2017 09:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPAIHGUJ47mD; Tue, 10 Jan 2017 09:08:01 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56BCE129666; Tue, 10 Jan 2017 09:08:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3656; q=dns/txt; s=iport; t=1484068080; x=1485277680; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=PiFSH8al9uOmNpmayKqAxnb0hsrqfcHHTHMSpn3o3tM=; b=Cq0wi1v96lMuGVzQsyOV6VzvsTtIz00N2I3q8FLF37qDlGoh2BBqLC1f tUPlu8vzNCmVo3DeYQk+W7FqFwGUh+toqrIE3vZSdmj44uP9DhT7y47J1 8QuF85KWrugV841OWRBa20VBQINRjf0e3olJduRWkcbhGcoPXck9+VJ48 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B9AQBHFHVY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgywOAQEBAQGBASxejVdykTSTGIIPgguGIgKCQRQBAgEBAQEBAQF?= =?us-ascii?q?jKIRpAQEBAwE4RgsLEAgjC1cGAQwGAgEBiGQIsniKFgEBAQEBAQEBAgEBAQEBA?= =?us-ascii?q?SKGRYICgl+KLAWbI5FSgXeINSOGEopjh3sfOIESEgcVFYUegUc+NYhmAQEB?= X-IronPort-AV: E=Sophos;i="5.33,344,1477958400"; d="scan'208";a="651502814" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jan 2017 17:07:55 +0000 Received: from [10.63.23.107] (dhcp-ensft1-uk-vla370-10-63-23-107.cisco.com [10.63.23.107]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0AH7tt9011033; Tue, 10 Jan 2017 17:07:55 GMT To: Andy Bierman , Ladislav Lhotka , Netconf , NetMod WG References: <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> <20170110161643.GE17035@elstar.local> From: Robert Wilton Message-ID: <8f0b1abe-b00e-95d1-f62f-7bc99d414bc6@cisco.com> Date: Tue, 10 Jan 2017 17:07:54 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <20170110161643.GE17035@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 17:08:02 -0000 On 10/01/2017 16:16, Juergen Schoenwaelder wrote: > On Tue, Jan 10, 2017 at 07:30:51AM -0800, Andy Bierman wrote: >> On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de> wrote: >> >>> On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote: >>>> I think itt is not realistic to say that datastores are optional. >>>> >>>> e.g. leaf: If there is a standard way to enable/disable config >>>> then individual "enabled" leafs are redundant. However XPath (must/when) >>>> has no way to describe if the subtree is enabled (which is a >>> show-stopper) >>> >>> I may not understand what you are saying. From what I know, there are >>> implementations that allow to 'comment out' nodes and subtrees and >>> that work with clients in a backwards compatible way. >>> >>>> vs . If the applied or operational datastore is >>>> assumed, >>>> then there is no need to model the redundant config-as-operstate. >>>> If this is left out of the model, then the datastore becomes mandatory. >>>> If it is left in the model, the datasore becomes redundant. >>>> >>>> The basic premise that these datastores are optional is flawed. >>>> One cannot design a YANG module assuming the datastores are present >>>> if they are in fact optional. >>> The claim that all datastores are mandatory is equally flawed. >>> >>> >> correct -- nobody is saying that. > Well, I originally commented on the statement that intened would be > required and adding complexity - it does not. > >> The reason this is different is that the YANG objects are impacted. >> Candidate vs. running has no impact whatsoever on the set of >> YANG modules. The protocol is not self-selecting some objects >> and making other objects invisible. > Yes. And the same is true for intended as long as an implementation > does not support templates or inactive configuration objects. > >> But if I want to model , I will soon have to decide >> to use and allow all protocols to read it or >> model get-state(foo) and require a different module for each >> protocol. > If you do /foo and /foo-state, things will just work with or without > an operational state datastore. True, but there would also be an undesirable duplication of data in the data tree. > If you have only /foo, then an > operational state datastore may come in handy if you have to support > config and state with different lifetimes. I think that this may be more than "come in handy". I think that there would be key information that clients would expect to be available in a model but wouldn't be easily retrievable without supporting the operational state datastore. Specifically you lose the ability to easily query an operational property of a system that can be configured, but hasn't been configured. Example: Consider an Ethernet interface speed leaf that in the running ds represents the configured speed, and in the operational state ds represents the actual operational speed in use. Normally, the operational speed would default to the maximum speed supported by the hardware (or the negotiated value if auto-neg is in effect). If a device doesn't support the operational state datastore then you wouldn't be able to query the operational speed of an interface if it hasn't also been configured. If the device support the with-defaults extension and appropriate options then they could presumably retrieve the "complex default" value from the device using one of the with-default query parameters. Rob > > /js > From nobody Tue Jan 10 09:25:13 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88005129516 for ; Tue, 10 Jan 2017 09:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QI-sgG8zNU2f for ; Tue, 10 Jan 2017 09:25:11 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9520A1294E3 for ; Tue, 10 Jan 2017 09:25:10 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id s140so158950047qke.0 for ; Tue, 10 Jan 2017 09:25:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kPNurlDI0+M3diSPTeEqBal7VM+HQg7VF9Db62UMWr0=; b=kJTa5brh1o5lq9MDVbAtChH5hIcC1LYKLB3pzgwxIM3mU3io5/gsGwgqx+sgra+NU6 mdovapvIQxliAj4Dn5p1b66YbHOq2w9Zv4tKgBzVutfuOPjZwpPWcqN1pEsQfXvaxagM zuqlbvHvpQRFJw55JquxwJHOcOS18VY3h+SzG/YhmjjDL0t3Th6W9RuBbUai9dtnlDOz MwmvUWwW1BrP9//xkPq7vmNeM3DF4cBtiYBAVYZQZxf1J33P+V5D+h4uEen63p9vtkM9 GXX57qdplofJwKkfYEgXqI7sQeeLl159mKSHZU488tm719czyBymjHAJsbDg/Y5y7SQ6 GVpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kPNurlDI0+M3diSPTeEqBal7VM+HQg7VF9Db62UMWr0=; b=TwEWFDgNmiPSkuJ2BM9VYTsry54+/f4sRAmhxGQDKrb8BXs2QwWmJ9CvL0cOE2hBvq bwp/uUU6fmljVX9I/oUsjMVsvOmjvvxodp4bNwXbFJNqEay7606yCZY86/Z2trwxkSit 4jiOH0bn2884uRf2GdhsJ+zRtZB/jumeK3e4W6WlaiUbGXh0foTuz/o34wyVCtR4T08V HI8fCVxqMfv1+iiEC5EpNJHUtfxD2IuDfPYKwURsH7s6k3z0Lpppy4Ahzzx5Qwzv5X9W PxPb919n/Zxstxe+FWEGaeGe1hSiSu9acFg4a9ZmfpsHgsyMlHrVZOmV5Qmbv/6lrgpt Kkyw== X-Gm-Message-State: AIkVDXJ1rvhhwmIti/SdMh0wWux/mMCPRciLgr7io95eIJDEv33y5KsG9MIw2bzG1ZTV22hOoVZzgKy9tPu4pw== X-Received: by 10.55.135.197 with SMTP id j188mr3901396qkd.71.1484069109589; Tue, 10 Jan 2017 09:25:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Tue, 10 Jan 2017 09:25:08 -0800 (PST) In-Reply-To: <8f0b1abe-b00e-95d1-f62f-7bc99d414bc6@cisco.com> References: <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> <20170110161643.GE17035@elstar.local> <8f0b1abe-b00e-95d1-f62f-7bc99d414bc6@cisco.com> From: Andy Bierman Date: Tue, 10 Jan 2017 09:25:08 -0800 Message-ID: To: Robert Wilton Content-Type: multipart/alternative; boundary=94eb2c0777e6198c5c0545c0c4ee Archived-At: Cc: NetMod WG , Netconf Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 17:25:12 -0000 --94eb2c0777e6198c5c0545c0c4ee Content-Type: text/plain; charset=UTF-8 On Tue, Jan 10, 2017 at 9:07 AM, Robert Wilton wrote: > > > On 10/01/2017 16:16, Juergen Schoenwaelder wrote: > >> On Tue, Jan 10, 2017 at 07:30:51AM -0800, Andy Bierman wrote: >> >>> On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder < >>> j.schoenwaelder@jacobs-university.de> wrote: >>> >>> On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote: >>>> >>>>> I think itt is not realistic to say that datastores are optional. >>>>> >>>>> e.g. leaf: If there is a standard way to enable/disable >>>>> config >>>>> then individual "enabled" leafs are redundant. However XPath >>>>> (must/when) >>>>> has no way to describe if the subtree is enabled (which is a >>>>> >>>> show-stopper) >>>> >>>> I may not understand what you are saying. From what I know, there are >>>> implementations that allow to 'comment out' nodes and subtrees and >>>> that work with clients in a backwards compatible way. >>>> >>>> vs . If the applied or operational datastore is >>>>> assumed, >>>>> then there is no need to model the redundant config-as-operstate. >>>>> If this is left out of the model, then the datastore becomes mandatory. >>>>> If it is left in the model, the datasore becomes redundant. >>>>> >>>>> The basic premise that these datastores are optional is flawed. >>>>> One cannot design a YANG module assuming the datastores are present >>>>> if they are in fact optional. >>>>> >>>> The claim that all datastores are mandatory is equally flawed. >>>> >>>> >>>> correct -- nobody is saying that. >>> >> Well, I originally commented on the statement that intened would be >> required and adding complexity - it does not. >> >> >>> The reason this is different is that the YANG objects are impacted. >>> Candidate vs. running has no impact whatsoever on the set of >>> YANG modules. The protocol is not self-selecting some objects >>> and making other objects invisible. >>> >> Yes. And the same is true for intended as long as an implementation >> does not support templates or inactive configuration objects. >> >> But if I want to model , I will soon have to decide >>> to use and allow all protocols to read it or >>> model get-state(foo) and require a different module for each >>> protocol. >>> >> If you do /foo and /foo-state, things will just work with or without >> an operational state datastore. >> > True, but there would also be an undesirable duplication of data in the > data tree. > > > If you have only /foo, then an >> operational state datastore may come in handy if you have to support >> config and state with different lifetimes. >> > I think that this may be more than "come in handy". I think that there > would be key information that clients would expect to be available in a > model but wouldn't be easily retrievable without supporting the operational > state datastore. Specifically you lose the ability to easily query an > operational property of a system that can be configured, but hasn't been > configured. > > Example: Consider an Ethernet interface speed leaf that in the running ds > represents the configured speed, and in the operational state ds represents > the actual operational speed in use. Normally, the operational speed would > default to the maximum speed supported by the hardware (or the negotiated > value if auto-neg is in effect). If a device doesn't support the > operational state datastore then you wouldn't be able to query the > operational speed of an interface if it hasn't also been configured. > This is my concern -- that data modelers will put in the leaf to make sure all protocols (including existing NETCONF) can retrieve the oper-value. For many decades, this has been the design approach. There have not been many leafs where interactions with control-plane protocols is a factor. The SNMP-style solution is ad-hoc, but the problem is somewhat rare, so it didn't really matter. The premise now seems to be that the problem is no longer rare and lots of type of data is needed. I am not even sure this will be true if I2RS is constrained to RIB data (as the charter dictates). Presumably, the same instrumentation gets invoked for get(oper-speed) as get-state(admin-speed) > If the device support the with-defaults extension and appropriate options > then they could presumably retrieve the "complex default" value from the > device using one of the with-default query parameters. > with-defaults is a bit different because the YANG module can provide the default even if the server won't. > > Rob > > > >> /js >> >> > Andy --94eb2c0777e6198c5c0545c0c4ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 10, 2017 at 9:07 AM, Robert Wilton <rwilton@cisco.com&= gt; wrote:


On 10/01/2017 16:16, Juergen Schoenwaelder wrote:
On Tue, Jan 10, 2017 at 07:30:51AM -0800, Andy Bierman wrote:
On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder <
j= .schoenwaelder@jacobs-university.de> wrote:

On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote:
I think itt is not realistic to say that datastores are optional.

e.g. <enabled> leaf:=C2=A0 If there is a standard way to enable/disab= le config
then individual "enabled" leafs are redundant. However XPath (mus= t/when)
has no way to describe if the subtree is enabled (which is a
show-stopper)

I may not understand what you are saying. From what I know, there are
implementations that allow to 'comment out' nodes and subtrees and<= br> that work with clients in a backwards compatible way.

<foo-config> vs <foo-oper>.=C2=A0 If the applied or operational= datastore is
assumed,
then there is no need to model the redundant config-as-operstate.
If this is left out of the model, then the datastore becomes mandatory.
If it is left in the model, the datasore becomes redundant.

The basic premise that these datastores are optional is flawed.
One cannot design a YANG module assuming the datastores are present
if they are in fact optional.
The claim that all datastores are mandatory is equally flawed.


correct -- nobody is saying that.
Well, I originally commented on the statement that intened would be
required and adding complexity - it does not.
=C2=A0
The reason this is different is that the YANG objects are impacted.
Candidate vs. running has no impact whatsoever on the set of
YANG modules.=C2=A0 The protocol is not self-selecting some objects
and making other objects invisible.
Yes. And the same is true for intended as long as an implementation
does not support templates or inactive configuration objects.

But if I want to model <foo-state>, I will soon have to decide
to use <foo-state> and allow all protocols to read it or
model get-state(foo) and require a different module for each
protocol.
If you do /foo and /foo-state, things will just work with or without
an operational state datastore.
True, but there would also be an undesirable duplication of data in the dat= a tree.


=C2=A0 If you have only /foo, then an
operational state datastore may come in handy if you have to support
config and state with different lifetimes.
I think that this may be more than "come in handy".=C2=A0 I think= that there would be key information that clients would expect to be availa= ble in a model but wouldn't be easily retrievable without supporting th= e operational state datastore.=C2=A0 Specifically you lose the ability to e= asily query an operational property of a system that can be configured, but= hasn't been configured.

Example: Consider an Ethernet interface speed leaf that in the running ds r= epresents the configured speed, and in the operational state ds represents = the actual operational speed in use.=C2=A0 Normally, the operational speed = would default to the maximum speed supported by the hardware (or the negoti= ated value if auto-neg is in effect). If a device doesn't support the o= perational state datastore then you wouldn't be able to query the opera= tional speed of an interface if it hasn't also been configured.

This is my concern -- that data modelers will = put in the <oper-speed> leaf to make sure
all protocols (in= cluding existing NETCONF) can retrieve the oper-value.

=
For many decades, this has been the design approach.
There h= ave not been many leafs where interactions with control-plane protocols
is a factor.=C2=A0 The SNMP-style solution is ad-hoc, but the proble= m is somewhat rare,
so it didn't really matter.
The premise now seems to be that the problem is no longer rare<= /div>
and lots of <oper-speed> type of data is needed.=C2=A0 I am= not even sure this will
be true if I2RS is constrained to RIB da= ta (as the charter dictates).

Presumably, the same= instrumentation gets invoked for get(oper-speed) as get-state(admin-speed)=



If the device support the with-defaults extension and appropriate options t= hen they could presumably retrieve the "complex default" value fr= om the device using one of the with-default query parameters.

with-defaults is a bit different because the YANG mo= dule can provide the default
even if the server won't.
<= div>
=C2=A0

Rob



/js



Andy

--94eb2c0777e6198c5c0545c0c4ee-- From nobody Tue Jan 10 10:17:55 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBBB129D53 for ; Tue, 10 Jan 2017 10:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTnjdlVDunbU for ; Tue, 10 Jan 2017 10:17:48 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 315C0129D79 for ; Tue, 10 Jan 2017 10:17:48 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id u25so567335391qki.2 for ; Tue, 10 Jan 2017 10:17:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=jedrU6XdZiNnWnAEKjijLjH7FLmuAtwLGh7uhyf5ikg=; b=yJAgsR/G2OBy33YcQjdogT8o9Nw7ohm49MoGBRoyk87tCQ8ga8InAYBOJK5RdvVLjz eQXm1b1yefCJXmK4Mz6KGH/L42G6VZCNqcL5Oc3hed2zUlNwSI5LeSIP86mnJnCph2np UhBx8bCV/HeJAYOT49amHrYSO+F1Lkcg+BuBj4+vTzoiVDCtUgsPnE+VgE6mx4x7+1V4 3m/BC1KbMTi2Gtmj1I9KwQiOghC4vMpO8nLo/HhXwJGm1Z7QDMl1WniGCkDrBOuMuLK1 gNzlkuR5D6YXh4Y6cwCBFtg/32yAS0P62I3mtLg7be4sQvVmskj9ARHuC7ClAjpPUtMt Mdcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=jedrU6XdZiNnWnAEKjijLjH7FLmuAtwLGh7uhyf5ikg=; b=tzHPLGmDVA1n9Jj+K2aDIKqt+m/i9OVnYghwoShwegpNsyJCsCG02WtYGzn/fVvbFl Q1tdHGsLkWKkcUW692Suj2C69gyKs9NH80jX58QeriQhDfdj2IGL/n/FnBIYBgCGm+S8 scptt37qpkWTt5gRV15QWo41TB/ErN3jyXroE+HdbDt57h4Ow6aw2BEkImJwTvuRCihy c3Zo1Kbk75Zc1CRR92tc0a7AJUStksug5ZseK1XkHZ+UKVg2iJFzkND+tO9YNLpyVjYT KBIjNWxVJCWUJukyXUusgX6UEDZ1sHdwH6mFdQOVvDsbdKwFuztOmRDC1TDZ3RSMdVLA Q9dg== X-Gm-Message-State: AIkVDXKTXCKNse+qDVIrfRWq1cTHjZDr8hgbAkr6ZH6q/qeykVIXjf79jKgpnhc+U8kCDK/qabigDR0tYiUoTg== X-Received: by 10.55.7.2 with SMTP id 2mr4800001qkh.228.1484072267291; Tue, 10 Jan 2017 10:17:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Tue, 10 Jan 2017 10:17:46 -0800 (PST) In-Reply-To: <20170110161643.GE17035@elstar.local> References: <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> <20170110161643.GE17035@elstar.local> From: Andy Bierman Date: Tue, 10 Jan 2017 10:17:46 -0800 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , Ladislav Lhotka , Netconf , NetMod WG Content-Type: multipart/alternative; boundary=001a114c877c502f990545c1809e Archived-At: Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 18:17:51 -0000 --001a114c877c502f990545c1809e Content-Type: text/plain; charset=UTF-8 On Tue, Jan 10, 2017 at 8:16 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Jan 10, 2017 at 07:30:51AM -0800, Andy Bierman wrote: > > On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote: > > > > > > > > I think itt is not realistic to say that datastores are optional. > > > > > > > > e.g. leaf: If there is a standard way to enable/disable > config > > > > then individual "enabled" leafs are redundant. However XPath > (must/when) > > > > has no way to describe if the subtree is enabled (which is a > > > show-stopper) > > > > > > I may not understand what you are saying. From what I know, there are > > > implementations that allow to 'comment out' nodes and subtrees and > > > that work with clients in a backwards compatible way. > > > > > > > vs . If the applied or operational datastore > is > > > > assumed, > > > > then there is no need to model the redundant config-as-operstate. > > > > If this is left out of the model, then the datastore becomes > mandatory. > > > > If it is left in the model, the datasore becomes redundant. > > > > > > > > The basic premise that these datastores are optional is flawed. > > > > One cannot design a YANG module assuming the datastores are present > > > > if they are in fact optional. > > > > > > The claim that all datastores are mandatory is equally flawed. > > > > > > > > correct -- nobody is saying that. > > Well, I originally commented on the statement that intened would be > required and adding complexity - it does not. > > > The reason this is different is that the YANG objects are impacted. > > Candidate vs. running has no impact whatsoever on the set of > > YANG modules. The protocol is not self-selecting some objects > > and making other objects invisible. > > Yes. And the same is true for intended as long as an implementation > does not support templates or inactive configuration objects. > > > But if I want to model , I will soon have to decide > > to use and allow all protocols to read it or > > model get-state(foo) and require a different module for each > > protocol. > > If you do /foo and /foo-state, things will just work with or without > an operational state datastore. If you have only /foo, then an > operational state datastore may come in handy if you have to support > config and state with different lifetimes. > Will they really work without /foo-state? How will I write XPath must/when/leafref statements for foo-state if it doesn't exist? (BTW, why do I need foo-state in both applied and operational datastores? This part is not clear) If the solution is to introduce an XPath function like operational-value(/top/speed) then this is both complicated and mandatory (YANG designers need the same XPath function set on every server) > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a114c877c502f990545c1809e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 10, 2017 at 8:16 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Jan 10, 2017 at 07:30:51AM -0800, Andy Bierm= an wrote:
> On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
> > On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote:
> > >
> > > I think itt is not realistic to say that datastores are opti= onal.
> > >
> > > e.g. <enabled> leaf:=C2=A0 If there is a standard way = to enable/disable config
> > > then individual "enabled" leafs are redundant. How= ever XPath (must/when)
> > > has no way to describe if the subtree is enabled (which is a=
> > show-stopper)
> >
> > I may not understand what you are saying. From what I know, there= are
> > implementations that allow to 'comment out' nodes and sub= trees and
> > that work with clients in a backwards compatible way.
> >
> > > <foo-config> vs <foo-oper>.=C2=A0 If the applied= or operational datastore is
> > > assumed,
> > > then there is no need to model the redundant config-as-opers= tate.
> > > If this is left out of the model, then the datastore becomes= mandatory.
> > > If it is left in the model, the datasore becomes redundant.<= br> > > >
> > > The basic premise that these datastores are optional is flaw= ed.
> > > One cannot design a YANG module assuming the datastores are = present
> > > if they are in fact optional.
> >
> > The claim that all datastores are mandatory is equally flawed. > >
> >
> correct -- nobody is saying that.

Well, I originally commented on the statement that intened would be
required and adding complexity - it does not.

> The reason this is different is that the YANG objects are impacted. > Candidate vs. running has no impact whatsoever on the set of
> YANG modules.=C2=A0 The protocol is not self-selecting some objects > and making other objects invisible.

Yes. And the same is true for intended as long as an implementation
does not support templates or inactive configuration objects.

> But if I want to model <foo-state>, I will soon have to decide > to use <foo-state> and allow all protocols to read it or
> model get-state(foo) and require a different module for each
> protocol.

If you do /foo and /foo-state, things will just work with or without
an operational state datastore. If you have only /foo, then an
operational state datastore may come in handy if you have to support
config and state with different lifetimes.

<= div>Will they really work without /foo-state?

How = will I write XPath must/when/leafref statements for foo-state if it doesn&#= 39;t exist?

(BTW, why do I need foo-state in both = applied and operational datastores?
This part is not clear)
=

If the solution is to introduce an XPath function like = operational-value(/top/speed)
then this is both complicated and m= andatory (YANG designers need the same
XPath function set on ever= y server)




=

/js


Andy
=C2=A0
=
--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--001a114c877c502f990545c1809e-- From nobody Tue Jan 10 10:18:31 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2240A129D7F; Tue, 10 Jan 2017 10:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9rZm12W28qS; Tue, 10 Jan 2017 10:18:27 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77387129D80; Tue, 10 Jan 2017 10:18:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21348; q=dns/txt; s=iport; t=1484072300; x=1485281900; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=anzoJpP7MNxYVw00Ly4quwTi9M+tNPbkAQxDUWk4DuE=; b=SsdeMyfwRLVZYRj2LdGijW/BMPOhKIH55vnFSNAX6U7ce3JGGr708uHn yeVPeVvXpyI/EEX9udK+8j7iJ3jXK8/zAynSuG39gkFn2pWZl58zJsJ5k HIj3jopCHAyms+Of5ZywoMFJlSoyxRNMjTxK8tCFjEfxH3ijHYcsGh1R/ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CRAQC9JHVY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgywOAQEBAQGBASxeg0+KCHKRNZMYgg+CC4YiAoJCFAECAQEBAQE?= =?us-ascii?q?BAWMohGkBAQEDASNWEAsQCCMEAwICRhEGDQYCAQEXiE0IsF+CJSuJawEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR2GRYICCIJXhDCDHoJeBYhuh3GKRJFSgXeINSOGEop?= =?us-ascii?q?jh3sfOIESEgcVFYUegUc+NYhmAQEB?= X-IronPort-AV: E=Sophos;i="5.33,344,1477958400"; d="scan'208,217";a="651504373" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jan 2017 18:18:15 +0000 Received: from [10.63.23.107] (dhcp-ensft1-uk-vla370-10-63-23-107.cisco.com [10.63.23.107]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v0AIIFFR024475; Tue, 10 Jan 2017 18:18:15 GMT To: Andy Bierman References: <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> <20170110161643.GE17035@elstar.local> <8f0b1abe-b00e-95d1-f62f-7bc99d414bc6@cisco.com> From: Robert Wilton Message-ID: <0f607346-cb4e-1e10-9956-956cb24dc49e@cisco.com> Date: Tue, 10 Jan 2017 18:18:15 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CFD0D02E2419FAC63CAAF3FD" Archived-At: Cc: NetMod WG , Netconf Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 18:18:29 -0000 This is a multi-part message in MIME format. --------------CFD0D02E2419FAC63CAAF3FD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 10/01/2017 17:25, Andy Bierman wrote: > > > On Tue, Jan 10, 2017 at 9:07 AM, Robert Wilton > wrote: > > > > On 10/01/2017 16:16, Juergen Schoenwaelder wrote: > > On Tue, Jan 10, 2017 at 07:30:51AM -0800, Andy Bierman wrote: > > On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de > > wrote: > > On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman > wrote: > > I think itt is not realistic to say that > datastores are optional. > > e.g. leaf: If there is a standard way > to enable/disable config > then individual "enabled" leafs are redundant. > However XPath (must/when) > has no way to describe if the subtree is enabled > (which is a > > show-stopper) > > I may not understand what you are saying. From what I > know, there are > implementations that allow to 'comment out' nodes and > subtrees and > that work with clients in a backwards compatible way. > > vs . If the applied or > operational datastore is > assumed, > then there is no need to model the redundant > config-as-operstate. > If this is left out of the model, then the > datastore becomes mandatory. > If it is left in the model, the datasore becomes > redundant. > > The basic premise that these datastores are > optional is flawed. > One cannot design a YANG module assuming the > datastores are present > if they are in fact optional. > > The claim that all datastores are mandatory is equally > flawed. > > > correct -- nobody is saying that. > > Well, I originally commented on the statement that intened > would be > required and adding complexity - it does not. > > The reason this is different is that the YANG objects are > impacted. > Candidate vs. running has no impact whatsoever on the set of > YANG modules. The protocol is not self-selecting some objects > and making other objects invisible. > > Yes. And the same is true for intended as long as an > implementation > does not support templates or inactive configuration objects. > > But if I want to model , I will soon have to decide > to use and allow all protocols to read it or > model get-state(foo) and require a different module for each > protocol. > > If you do /foo and /foo-state, things will just work with or > without > an operational state datastore. > > True, but there would also be an undesirable duplication of data > in the data tree. > > > If you have only /foo, then an > operational state datastore may come in handy if you have to > support > config and state with different lifetimes. > > I think that this may be more than "come in handy". I think that > there would be key information that clients would expect to be > available in a model but wouldn't be easily retrievable without > supporting the operational state datastore. Specifically you lose > the ability to easily query an operational property of a system > that can be configured, but hasn't been configured. > > Example: Consider an Ethernet interface speed leaf that in the > running ds represents the configured speed, and in the operational > state ds represents the actual operational speed in use. > Normally, the operational speed would default to the maximum speed > supported by the hardware (or the negotiated value if auto-neg is > in effect). If a device doesn't support the operational state > datastore then you wouldn't be able to query the operational speed > of an interface if it hasn't also been configured. > > > This is my concern -- that data modelers will put in the > leaf to make sure > all protocols (including existing NETCONF) can retrieve the oper-value. I think that there may be a better way here: The data modelers design the model on the assumption that an operational state datastore will be present. We can then use a pyang plugin to generate an extra YANG model that contains the missing state leaves that would be required for the split config/state trees. E.g. if it finds a config leaf in foo/speed it creates a module that contains foo-state/speed. I've been playing around with pyang and I don't think that this would be too hard to do. > > For many decades, this has been the design approach. > There have not been many leafs where interactions with control-plane > protocols > is a factor. The SNMP-style solution is ad-hoc, but the problem is > somewhat rare, > so it didn't really matter. Yes, OK. But I think that SNMP failed for programmatic configuration, it only seemed to get traction returning operational state. > > The premise now seems to be that the problem is no longer rare > and lots of type of data is needed. I am not even sure > this will > be true if I2RS is constrained to RIB data (as the charter dictates). I think that I2RS is orthogonal to what the operational state datastore is really solving, it just happens to help for I2RS as well. > > Presumably, the same instrumentation gets invoked for get(oper-speed) > as get-state(admin-speed) Yes, in the general case, I think that using the same instrumentation would be a valid implementation. But you may also be able to optimize this to fetching the information from the running configuration datastore (if you know for sure that the value will be the same). If the additional metadata is being supported and returned then it may also need to compare the operational value with the configured value and schema default to choose the correct metadata annotation. > > > > If the device support the with-defaults extension and appropriate > options then they could presumably retrieve the "complex default" > value from the device using one of the with-default query parameters. > > > with-defaults is a bit different because the YANG module can provide > the default > even if the server won't. I was thinking of the "report-all" option. Wouldn't that mean that the server would have to return the actual value for a config leaf that had a complex default value (i.e. based on the hardware present)? Rob > > > Rob > > > > /js > > > > Andy > --------------CFD0D02E2419FAC63CAAF3FD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 10/01/2017 17:25, Andy Bierman wrote:


On Tue, Jan 10, 2017 at 9:07 AM, Robert Wilton <rwilton@cisco.com> wrote:


On 10/01/2017 16:16, Juergen Schoenwaelder wrote:
On Tue, Jan 10, 2017 at 07:30:51AM -0800, Andy Bierman wrote:
On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote:
I think itt is not realistic to say that datastores are optional.

e.g. <enabled> leaf:  If there is a standard way to enable/disable config
then individual "enabled" leafs are redundant. However XPath (must/when)
has no way to describe if the subtree is enabled (which is a
show-stopper)

I may not understand what you are saying. From what I know, there are
implementations that allow to 'comment out' nodes and subtrees and
that work with clients in a backwards compatible way.

<foo-config> vs <foo-oper>.  If the applied or operational datastore is
assumed,
then there is no need to model the redundant config-as-operstate.
If this is left out of the model, then the datastore becomes mandatory.
If it is left in the model, the datasore becomes redundant.

The basic premise that these datastores are optional is flawed.
One cannot design a YANG module assuming the datastores are present
if they are in fact optional.
The claim that all datastores are mandatory is equally flawed.


correct -- nobody is saying that.
Well, I originally commented on the statement that intened would be
required and adding complexity - it does not.
 
The reason this is different is that the YANG objects are impacted.
Candidate vs. running has no impact whatsoever on the set of
YANG modules.  The protocol is not self-selecting some objects
and making other objects invisible.
Yes. And the same is true for intended as long as an implementation
does not support templates or inactive configuration objects.

But if I want to model <foo-state>, I will soon have to decide
to use <foo-state> and allow all protocols to read it or
model get-state(foo) and require a different module for each
protocol.
If you do /foo and /foo-state, things will just work with or without
an operational state datastore.
True, but there would also be an undesirable duplication of data in the data tree.


  If you have only /foo, then an
operational state datastore may come in handy if you have to support
config and state with different lifetimes.
I think that this may be more than "come in handy".  I think that there would be key information that clients would expect to be available in a model but wouldn't be easily retrievable without supporting the operational state datastore.  Specifically you lose the ability to easily query an operational property of a system that can be configured, but hasn't been configured.

Example: Consider an Ethernet interface speed leaf that in the running ds represents the configured speed, and in the operational state ds represents the actual operational speed in use.  Normally, the operational speed would default to the maximum speed supported by the hardware (or the negotiated value if auto-neg is in effect). If a device doesn't support the operational state datastore then you wouldn't be able to query the operational speed of an interface if it hasn't also been configured.

This is my concern -- that data modelers will put in the <oper-speed> leaf to make sure
all protocols (including existing NETCONF) can retrieve the oper-value.
I think that there may be a better way here:  The data modelers design the model on the assumption that an operational state datastore will be present.  We can then use a pyang plugin to generate an extra YANG model that contains the missing state leaves that would be required for the split config/state trees.  E.g. if it finds a config leaf in foo/speed it creates a module that contains foo-state/speed.  I've been playing around with pyang and I don't think that this would be too hard to do.


For many decades, this has been the design approach.
There have not been many leafs where interactions with control-plane protocols
is a factor.  The SNMP-style solution is ad-hoc, but the problem is somewhat rare,
so it didn't really matter.
Yes, OK.  But I think that SNMP failed for programmatic configuration, it only seemed to get traction returning operational state.



The premise now seems to be that the problem is no longer rare
and lots of <oper-speed> type of data is needed.  I am not even sure this will
be true if I2RS is constrained to RIB data (as the charter dictates).
I think that I2RS is orthogonal to what the operational state datastore is really solving, it just happens to help for I2RS as well.



Presumably, the same instrumentation gets invoked for get(oper-speed) as get-state(admin-speed)
Yes, in the general case, I think that using the same instrumentation would be a valid implementation.

But you may also be able to optimize this to fetching the information from the running configuration datastore (if you know for sure that the value will be the same).

If the additional metadata is being supported and returned then it may also need to compare the operational value with the configured value and schema default to choose the correct metadata annotation.




If the device support the with-defaults extension and appropriate options then they could presumably retrieve the "complex default" value from the device using one of the with-default query parameters.

with-defaults is a bit different because the YANG module can provide the default
even if the server won't.
I was thinking of the "report-all" option.  Wouldn't that mean that the server would have to return the actual value for a config leaf that had a complex default value (i.e. based on the hardware present)?

Rob


 

Rob



/js



Andy


--------------CFD0D02E2419FAC63CAAF3FD-- From nobody Tue Jan 10 10:31:55 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7EC312955E for ; Tue, 10 Jan 2017 10:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9_yR1LmW2faj for ; Tue, 10 Jan 2017 10:31:52 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7E4A12940A for ; Tue, 10 Jan 2017 10:31:51 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id l7so124811515qtd.1 for ; Tue, 10 Jan 2017 10:31:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jqSuNMPHWNSwrIlbOnxq4WgZGb7ulncVHq6I10mol7s=; b=koylWTXVDGMwEasWTzhNZebVpxfRLTeyvCkwJd/bLkr0mS2OJnqqnS+jG2Kh5FmQYD kcUbdB7Ul0MWwCJLCKWmc9tbmsD4mFkr9oh/FmQhvmKMZF/ExUmXVzc/ypN9pONl/zPs 2ukNCg3zoRDhBdf2kAfLVm+XlALKB+2EO3Hs+pYjHWtelQgNlVfKMEV7U1Clm3fpvu9W IunUKF20TMXFSHhGNq0QrNcC+J/EVcGBiUI4ZmJpnD6WjrgPx/RkF6rOtiljih1IhKvT kFabUPIlI0bUGXrLOUUoM1Ueqx8+IgF6Ui5ovh4pz1aKpgijF2jRNlT7ytl3T+Tw8TX1 lXTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jqSuNMPHWNSwrIlbOnxq4WgZGb7ulncVHq6I10mol7s=; b=UYHw4BL9EKqM8vpgSliIrHIl98ker3nl1LC/brTXgzzLZb+brCC1i63271IU5l7Jq1 Y8vIkE8IcPqLhbuKoVxXxzFHdlVIqInX8lQIlhO24DRSDrnqo9sIC7ipU5lhlcE/Fr2H WdYW1QCIvi7Q1TNmse/LBiVlHCt0Wnb/b7/6uxAixHXosm4mHGUcnVpIHRJQ9IuXERoN NeG/wuTarp/lQkHvYC+ifw09Uf12JNl0pYsxjdbwc/pbS5uAGI6EhIO0/nLa5V92wl+X VGM4qH8c1hiF3JqvAqOqNa9hjraWOo5REiOZbg4G1XoqDQOS/6GJP17Yd2fTvNsC7Gyg 09QA== X-Gm-Message-State: AIkVDXL0Ma5gg4i64/leKvG7KlZbh5vp6TVILAJJbgVG1wV01joDfUhQcRev4OjQdabXKRW8xvzwmKvq7XvyjQ== X-Received: by 10.237.57.137 with SMTP id m9mr4253540qte.35.1484073110850; Tue, 10 Jan 2017 10:31:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Tue, 10 Jan 2017 10:31:49 -0800 (PST) In-Reply-To: <0f607346-cb4e-1e10-9956-956cb24dc49e@cisco.com> References: <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> <20170110161643.GE17035@elstar.local> <8f0b1abe-b00e-95d1-f62f-7bc99d414bc6@cisco.com> <0f607346-cb4e-1e10-9956-956cb24dc49e@cisco.com> From: Andy Bierman Date: Tue, 10 Jan 2017 10:31:49 -0800 Message-ID: To: Robert Wilton Content-Type: multipart/alternative; boundary=001a11410e6297ff4c0545c1b235 Archived-At: Cc: NetMod WG , Netconf Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 18:31:54 -0000 --001a11410e6297ff4c0545c1b235 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 10, 2017 at 10:18 AM, Robert Wilton wrote: > > > On 10/01/2017 17:25, Andy Bierman wrote: > > > > On Tue, Jan 10, 2017 at 9:07 AM, Robert Wilton wrote: > >> >> >> On 10/01/2017 16:16, Juergen Schoenwaelder wrote: >> >>> On Tue, Jan 10, 2017 at 07:30:51AM -0800, Andy Bierman wrote: >>> >>>> On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder < >>>> j.schoenwaelder@jacobs-university.de> wrote: >>>> >>>> On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote: >>>>> >>>>>> I think itt is not realistic to say that datastores are optional. >>>>>> >>>>>> e.g. leaf: If there is a standard way to enable/disable >>>>>> config >>>>>> then individual "enabled" leafs are redundant. However XPath >>>>>> (must/when) >>>>>> has no way to describe if the subtree is enabled (which is a >>>>>> >>>>> show-stopper) >>>>> >>>>> I may not understand what you are saying. From what I know, there are >>>>> implementations that allow to 'comment out' nodes and subtrees and >>>>> that work with clients in a backwards compatible way. >>>>> >>>>> vs . If the applied or operational datastore is >>>>>> assumed, >>>>>> then there is no need to model the redundant config-as-operstate. >>>>>> If this is left out of the model, then the datastore becomes >>>>>> mandatory. >>>>>> If it is left in the model, the datasore becomes redundant. >>>>>> >>>>>> The basic premise that these datastores are optional is flawed. >>>>>> One cannot design a YANG module assuming the datastores are present >>>>>> if they are in fact optional. >>>>>> >>>>> The claim that all datastores are mandatory is equally flawed. >>>>> >>>>> >>>>> correct -- nobody is saying that. >>>> >>> Well, I originally commented on the statement that intened would be >>> required and adding complexity - it does not. >>> >>> >>>> The reason this is different is that the YANG objects are impacted. >>>> Candidate vs. running has no impact whatsoever on the set of >>>> YANG modules. The protocol is not self-selecting some objects >>>> and making other objects invisible. >>>> >>> Yes. And the same is true for intended as long as an implementation >>> does not support templates or inactive configuration objects. >>> >>> But if I want to model , I will soon have to decide >>>> to use and allow all protocols to read it or >>>> model get-state(foo) and require a different module for each >>>> protocol. >>>> >>> If you do /foo and /foo-state, things will just work with or without >>> an operational state datastore. >>> >> True, but there would also be an undesirable duplication of data in the >> data tree. >> >> >> If you have only /foo, then an >>> operational state datastore may come in handy if you have to support >>> config and state with different lifetimes. >>> >> I think that this may be more than "come in handy". I think that there >> would be key information that clients would expect to be available in a >> model but wouldn't be easily retrievable without supporting the operational >> state datastore. Specifically you lose the ability to easily query an >> operational property of a system that can be configured, but hasn't been >> configured. >> >> Example: Consider an Ethernet interface speed leaf that in the running ds >> represents the configured speed, and in the operational state ds represents >> the actual operational speed in use. Normally, the operational speed would >> default to the maximum speed supported by the hardware (or the negotiated >> value if auto-neg is in effect). If a device doesn't support the >> operational state datastore then you wouldn't be able to query the >> operational speed of an interface if it hasn't also been configured. >> > > This is my concern -- that data modelers will put in the leaf > to make sure > all protocols (including existing NETCONF) can retrieve the oper-value. > > I think that there may be a better way here: The data modelers design the > model on the assumption that an operational state datastore will be > present. We can then use a pyang plugin to generate an extra YANG model > that contains the missing state leaves that would be required for the split > config/state trees. E.g. if it finds a config leaf in foo/speed it creates > a module that contains foo-state/speed. I've been playing around with > pyang and I don't think that this would be too hard to do. > > > This is a real hack. I liked the if-feature approach much better e.g. leaf oper-speed { if-feature "not operational-datastore"; ... } > For many decades, this has been the design approach. > There have not been many leafs where interactions with control-plane > protocols > is a factor. The SNMP-style solution is ad-hoc, but the problem is > somewhat rare, > so it didn't really matter. > > Yes, OK. But I think that SNMP failed for programmatic configuration, it > only seemed to get traction returning operational state. > > It failed because there are no transactions, not because the oper-speed leaf exists or not. > > > The premise now seems to be that the problem is no longer rare > and lots of type of data is needed. I am not even sure this > will > be true if I2RS is constrained to RIB data (as the charter dictates). > > I think that I2RS is orthogonal to what the operational state datastore is > really solving, it just happens to help for I2RS as well. > > OK -- Joel informs me the I2RS charter is not constrained to RIB data at all. > > > Presumably, the same instrumentation gets invoked for get(oper-speed) as > get-state(admin-speed) > > Yes, in the general case, I think that using the same instrumentation > would be a valid implementation. > > But you may also be able to optimize this to fetching the information from > the running configuration datastore (if you know for sure that the value > will be the same). > > If the additional metadata is being supported and returned then it may > also need to compare the operational value with the configured value and > schema default to choose the correct metadata annotation. > > > > >> If the device support the with-defaults extension and appropriate options >> then they could presumably retrieve the "complex default" value from the >> device using one of the with-default query parameters. >> > > with-defaults is a bit different because the YANG module can provide the > default > even if the server won't. > > I was thinking of the "report-all" option. Wouldn't that mean that the > server would have to return the actual value for a config leaf that had a > complex default value (i.e. based on the hardware present)? > basic=report-all just means the server never suppresses defaults. It always returns them in messages. > > Rob > Andy > > > > >> >> Rob >> >> >> >>> /js >>> >>> >> > Andy > > > --001a11410e6297ff4c0545c1b235 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 10, 2017 at 10:18 AM, Robert Wilton <<= a href=3D"mailto:rwilton@cisco.com" target=3D"_blank">rwilton@cisco.com= > wrote:
=20 =20 =20



On 10/01/2017 17:25= , Andy Bierman wrote:
=20


On Tue, Jan 10, 2017 at 9:07 AM, Robert Wilton <rwilton@cisco.com> wrote:


On 10/01/2017 16:16, Juergen Schoenwaelder wrote:
On Tue, Jan 10, 2017 at 07:30:51AM -0800, Andy Bierman wrote:
On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote:
I think itt is not realistic to say that datastores are optional.

e.g. <enabled> leaf:=C2=A0 If there is a standa= rd way to enable/disable config
then individual "enabled" leafs are redunda= nt. However XPath (must/when)
has no way to describe if the subtree is enabled (which is a
show-stopper)

I may not understand what you are saying. From what I know, there are
implementations that allow to 'comment out' nod= es and subtrees and
that work with clients in a backwards compatible way.

<foo-config> vs <foo-oper>.=C2=A0 If the applied or operational datastore is
assumed,
then there is no need to model the redundant config-as-operstate.
If this is left out of the model, then the datastore becomes mandatory.
If it is left in the model, the datasore becomes redundant.

The basic premise that these datastores are optional is flawed.
One cannot design a YANG module assuming the datastores are present
if they are in fact optional.
The claim that all datastores are mandatory is equally flawed.


correct -- nobody is saying that.
Well, I originally commented on the statement that intened would be
required and adding complexity - it does not.
=C2=A0
The reason this is different is that the YANG objects are impacted.
Candidate vs. running has no impact whatsoever on the set of
YANG modules.=C2=A0 The protocol is not self-selecting so= me objects
and making other objects invisible.
Yes. And the same is true for intended as long as an implementation
does not support templates or inactive configuration objects.

But if I want to model <foo-state>, I will soon have to decide
to use <foo-state> and allow all protocols to read it or
model get-state(foo) and require a different module for each
protocol.
If you do /foo and /foo-state, things will just work with or without
an operational state datastore.
True, but there would also be an undesirable duplication of data in the data tree.


=C2=A0 If you have only /foo, then an
operational state datastore may come in handy if you have to support
config and state with different lifetimes.
I think that this may be more than "come in handy".= =C2=A0 I think that there would be key information that clients would expect to be available in a model but wouldn't be easily retrievable without supporting the operational state datastore.=C2=A0 Specifically you lose the ability to easily query an operational property of a system that can be configured, but hasn't been configured.

Example: Consider an Ethernet interface speed leaf that in the running ds represents the configured speed, and in the operational state ds represents the actual operational speed in use.=C2=A0 Normally, the operational speed would default to the maximum speed supported by the hardware (or the negotiated value if auto-neg is in effect). If a device doesn't support the operational state datastore then you wouldn't be able to query the operational speed of an interface if it hasn't also been configured.

This is my concern -- that data modelers will put in the <oper-speed> leaf to make sure
all protocols (including existing NETCONF) can retrieve the oper-value.
I think that there may be a better way here:=C2=A0 The data modelers design the model on the assumption that an operational state datastore will be present.=C2=A0 We can then use a pyang plugin to generate an extra YANG model that contains the missing state leaves that would be required for the split config/state trees.=C2=A0 E.g. if = it finds a config leaf in foo/speed it creates a module that contains foo-state/speed.=C2=A0 I've been playing around with pyang and I do= n't think that this would be too hard to do.




This is a real hack.

I liked the if-feature approach much better
e.g.

=C2=A0 =C2=A0leaf oper-speed {
=C2=A0 =C2=A0 =C2= =A0 =C2=A0if-feature "not operational-datastore";
=C2= =A0 =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0}

=C2=A0
For many decades, this has been the design approach.
There have not been many leafs where interactions with control-plane protocols
is a factor.=C2=A0 The SNMP-style solution is ad-hoc, but the problem is somewhat rare,
so it didn't really matter.
Yes, OK.=C2=A0 But I think that SNMP failed for programmatic configuration, it only seemed to get traction returning operational state.



It failed bec= ause there are no transactions,
not because the oper-speed leaf e= xists or not.

=C2=A0


The premise now seems to be that the problem is no longer rare
and lots of <oper-speed> type of data is needed.=C2= =A0 I am not even sure this will
be true if I2RS is constrained to RIB data (as the charter dictates).
I think that I2RS is orthogonal to what the operational state datastore is really solving, it just happens to help for I2RS as well.


OK -- Joel informs me the I2= RS charter is not constrained to RIB data at all.

= =C2=A0


Presumably, the same instrumentation gets invoked for get(oper-speed) as get-state(admin-speed)
Yes, in the general case, I think that using the same instrumentation would be a valid implementation.

But you may also be able to optimize this to fetching the information from the running configuration datastore (if you know for sure that the value will be the same).

If the additional metadata is being supported and returned then it may also need to compare the operational value with the configured value and schema default to choose the correct metadata annotation.




If the device support the with-defaults extension and appropriate options then they could presumably retrieve the "complex default" value from the device using o= ne of the with-default query parameters.

with-defaults is a bit different because the YANG module can provide the default
even if the server won't.
I was thinking of the "report-all" option.=C2=A0 Wouldn't= that mean that the server would have to return the actual value for a config leaf that had a complex default value (i.e. based on the hardware present)?

basic=3Dreport-all = just means the server never suppresses defaults.
It always return= s them in <rpc-reply> messages.

=C2=A0
=

Rob

Andy
=C2=A0


=C2=A0

Rob



/js



Andy



--001a11410e6297ff4c0545c1b235-- From nobody Tue Jan 10 11:09:03 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A86612954C; Tue, 10 Jan 2017 11:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kmz8k75lA41b; Tue, 10 Jan 2017 11:08:58 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0113.outbound.protection.outlook.com [104.47.38.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 441C012950B; Tue, 10 Jan 2017 11:08:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XCiuURfbkuC+AP9cw8Ya7Uu1SC98aLj8TVE8EliDKKQ=; b=j401j67P8QBDOT5GyllH8dvwLQirOaLgjX1ARlIHo+7fxbWwQ1i0p4IIlWiGT9+n3bJs5cY2miVCc3O+wXjL4HMtPArVyO3Er3LQOvSNQu65S5ui1O5uUCId+OIUhI1MwUy/CBeuB18IVi7ibnecuwDUL6g5NUFoCRH5OvBsmhs= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.3; Tue, 10 Jan 2017 19:08:48 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0829.017; Tue, 10 Jan 2017 19:08:48 +0000 From: Kent Watsen To: Andy Bierman , Robert Wilton Thread-Topic: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits Thread-Index: AQHSa2aD89RzNHtVJkqt3M8SCXRmh6EyBQSAgAADy4D//7aBAA== Date: Tue, 10 Jan 2017 19:08:47 +0000 Message-ID: <0A89256A-35FA-4FC3-95FF-0C88A9B5F4EC@juniper.net> References: <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> <20170110161643.GE17035@elstar.local> <8f0b1abe-b00e-95d1-f62f-7bc99d414bc6@cisco.com> <0f607346-cb4e-1e10-9956-956cb24dc49e@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/f.1d.0.161209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: ea6e7eb4-ea5f-4997-205f-08d4398c1b2d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1441; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:z6KKg2XgpMFAGVuhUKhlrKFs7vkOQE7JW6TlyZMeu9Fgs6GSlBebdwubDo3uE7p2cEiny7d9FoXwgR9mxBmoNmcEmEiokZyIAS6vQtnjPO7w8XtcLQ4h1qInCRtkhwblLdYxeOVWmutwCWyt9UdXXPDCtfrm0Qd5QIYReEM3Iqu9UfYvKwOHH1Gn/BCtuTjUh35rnaTlovpUbH/43r2pWf/A/mPCCpI1E6Pg+R00ZJocHQwOuSEMlZfD8mCqA6KGcMNG4IMroBKEobXflN2EfpgggUQWFm/6u4QSvZ0IL7G4rLrmeuyIm9dOk4VXb81ctSB5nn61UjpG7iVTfxayUkWEwNh85m6YyRIe0tMvbWQJzA9TzL3/ZcdAdKPysiPvVWge21WCKkU3wK/QcdHjf7SXxtWOWQewrANqHWpgrd8siR1elzcESJ+wjgQgvyXMszHvktDM/07cripWfJwvTQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(150554046322364)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 01834E39B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39850400002)(39860400002)(39450400003)(39840400002)(51444003)(199003)(189002)(7736002)(105586002)(106356001)(106116001)(54906002)(2950100002)(76176999)(50986999)(54356999)(101416001)(68736007)(6116002)(33656002)(8936002)(5660300001)(81166006)(561944003)(81156014)(3846002)(66066001)(93886004)(102836003)(36756003)(8676002)(99286003)(2900100001)(6512007)(6306002)(54896002)(4001350100001)(189998001)(6506006)(77096006)(122556002)(6486002)(6436002)(229853002)(86362001)(38730400001)(3280700002)(92566002)(82746002)(3660700001)(83506001)(97736004)(5001770100001)(25786008)(4326007)(83716003)(2906002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_0A89256A35FA4FC395FF0C88A9B5F4ECjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2017 19:08:47.8368 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Cc: Netconf , NetMod WG Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 19:09:00 -0000 --_000_0A89256A35FA4FC395FF0C88A9B5F4ECjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGF0IHRoZXJlIG1heSBiZSBhIGJldHRlciB3YXkgaGVyZTogIFRoZSBkYXRhIG1v ZGVsZXJzIGRlc2lnbiB0aGUgbW9kZWwgb24gdGhlIGFzc3VtcHRpb24gdGhhdCBhbiBvcGVyYXRp b25hbCBzdGF0ZSBkYXRhc3RvcmUgd2lsbCBiZSBwcmVzZW50LiAgV2UgY2FuIHRoZW4gdXNlIGEg cHlhbmcgcGx1Z2luIHRvIGdlbmVyYXRlIGFuIGV4dHJhIFlBTkcgbW9kZWwgdGhhdCBjb250YWlu cyB0aGUgbWlzc2luZyBzdGF0ZSBsZWF2ZXMgdGhhdCB3b3VsZCBiZSByZXF1aXJlZCBmb3IgdGhl IHNwbGl0IGNvbmZpZy9zdGF0ZSB0cmVlcy4gIEUuZy4gaWYgaXQgZmluZHMgYSBjb25maWcgbGVh ZiBpbiBmb28vc3BlZWQgaXQgY3JlYXRlcyBhIG1vZHVsZSB0aGF0IGNvbnRhaW5zIGZvby1zdGF0 ZS9zcGVlZC4gIEkndmUgYmVlbiBwbGF5aW5nIGFyb3VuZCB3aXRoIHB5YW5nIGFuZCBJIGRvbid0 IHRoaW5rIHRoYXQgdGhpcyB3b3VsZCBiZSB0b28gaGFyZCB0byBkby4NCg0KSSBnZW5lcmFsbHkg c3VwcG9ydCB0aGlzIGFwcHJvYWNoIGFzIHN0b3AtZ2FwIHNvbHV0aW9uIHdoaWxlIHRoZSBpbmR1 c3RyeSBnb2VzIHRocnUgdGhlIHRyYW5zaXRpb24uICBIb3dldmVyLCBJIHJlY29tbWVuZCBhIHZh cmlhbnQgd2hlcmVieSB0aGUgcHlhbmcgcGx1Z2luIG9ubHkgbWlncmF0ZXMgdGhlIGNvbmZpZyBm YWxzZSB2YWx1ZXMgKG5vdCBhbHNvIHRoZSBjb25maWcgdHJ1ZSB2YWx1ZXMpLiAgVGhlIHJlYXNv biBmb3IgdGhpcyBpcyBhcyBmb2xsb3dzOg0KDQpNaWdyYXRpbmcgb25seSB0aGUgY29uZmlnIGZh bHNlIHZhbHVlcyBpcyBzdWZmaWNpZW50IGZvciBtYXRjaGluZyBleGlzdGluZyBmdW5jdGlvbmFs aXR5IChyZWFkOiBhIG11c3QtaGF2ZSByZXF1aXJlbWVudCk7IHRoYXQgaXMsIGN1cnJlbnRseSB0 b3AtbGV2ZWwgL2Zvby1zdGF0ZSBpcyB1c2VkIHRvIHN1cHBvcnQgY29udmV5aW5nIHRoZSBvcHN0 YXRlIGZvciBzeXN0ZW0tZ2VuZXJhdGVkIG9iamVjdHMsIHRoYXQgaGF2ZSBsaWZldGltZXMgaW5k ZXBlbmRlbnQgb2YgY29uZmlnLg0KDQpNaWdyYXRpbmcgdGhlIGNvbmZpZyB0cnVlIG5vZGVzIGFs c28gaXMgcG9zc2libGUsIGJ1dCBvbmx5IG5lZWRlZCBpZiB3YW50aW5nIHRvIHJlcG9ydCB0aGUg b3BzdGF0ZSB2YWx1ZSBmb3IgY29uZmlnIHRydWUgbm9kZXMgKGUuZy4sIGhvc3RuYW1lKSwgYnV0 IHRoaXMgd291bGQgYmUgYWJvdmUgYW5kIGJleW9uZCB3aGF0IGlzIHBvc3NpYmxlIHRvZGF5IChy ZWFkOiBhIG5pY2UtdG8taGF2ZSByZXF1aXJlbWVudCksIGFuZCBoZW5jZSBJ4oCZZCByYXRoZXIg c3RlZXIgZm9sa3MgdG93YXJkcyB0aGUgbmV3IGFwcHJvYWNoIHJhdGhlciB0aGFuIGRvdWJsZS1k b3duIG9uIHRoZSBhcHByb2FjaCB3ZeKAmXJlIHRyeWluZyB0byBnZXQgYXdheSBmcm9tLg0KDQoN Cg0KPiBUaGlzIGlzIGEgcmVhbCBoYWNrLg0KPg0KPiBJIGxpa2VkIHRoZSBpZi1mZWF0dXJlIGFw cHJvYWNoIG11Y2ggYmV0dGVyDQo+IGUuZy4NCj4NCj4gICBsZWFmIG9wZXItc3BlZWQgew0KPiAg ICAgICBpZi1mZWF0dXJlICJub3Qgb3BlcmF0aW9uYWwtZGF0YXN0b3JlIjsNCj4gICAgICAgLi4u DQo+ICAgfQ0KDQpJcyB5b3VyIHByb3Bvc2FsIGZvciB0aGUgWUFORyBtb2R1bGVzIHRvIHNpbXVs dGFuZW91c2x5IGRlZmluZSBib3RoIG9wc3RhdGUtYXdhcmUgYW5kIG9wc3RhdGUtdW5hd2FyZSB0 cmVlcz8gIFdvdWxkbuKAmXQgdGhhdCBtYWtlIHRoZSBtb2R1bGVzIGxlc3MgcmVhZGFibGUsIGxh cmdlbHkgcmVkdW5kYW50LCBhbmQgcmlwZSBmb3IgaW5jb25zaXN0ZW5jaWVzPw0KDQoNCg0KS2Vu dCAgLy8gYXMgYSBjb250cmlidXRvcg0KDQoNCg== --_000_0A89256A35FA4FC395FF0C88A9B5F4ECjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6Q2FsaWJyaTsNCglmb250LXZhcmlhbnQ6bm9ybWFsICFpbXBvcnRhbnQ7DQoJY29sb3I6 d2luZG93dGV4dDsNCgl0ZXh0LXRyYW5zZm9ybTpub25lOw0KCXRleHQtZGVjb3JhdGlvbjpub25l IG5vbmU7DQoJdmVydGljYWwtYWxpZ246YmFzZWxpbmU7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMS41NXB0Ij5JIHRoaW5rIHRoYXQgdGhlcmUg bWF5IGJlIGEgYmV0dGVyIHdheSBoZXJlOiZuYnNwOyBUaGUgZGF0YSBtb2RlbGVycyBkZXNpZ24g dGhlIG1vZGVsIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgYW4gb3BlcmF0aW9uYWwgc3RhdGUgZGF0 YXN0b3JlIHdpbGwgYmUgcHJlc2VudC4mbmJzcDsgV2UgY2FuIHRoZW4gdXNlIGEgcHlhbmcgcGx1 Z2luIHRvIGdlbmVyYXRlIGFuIGV4dHJhIFlBTkcNCiBtb2RlbCB0aGF0IGNvbnRhaW5zIHRoZSBt aXNzaW5nIHN0YXRlIGxlYXZlcyB0aGF0IHdvdWxkIGJlIHJlcXVpcmVkIGZvciB0aGUgc3BsaXQg Y29uZmlnL3N0YXRlIHRyZWVzLiZuYnNwOyBFLmcuIGlmIGl0IGZpbmRzIGEgY29uZmlnIGxlYWYg aW4gZm9vL3NwZWVkIGl0IGNyZWF0ZXMgYSBtb2R1bGUgdGhhdCBjb250YWlucyBmb28tc3RhdGUv c3BlZWQuJm5ic3A7IEkndmUgYmVlbiBwbGF5aW5nIGFyb3VuZCB3aXRoIHB5YW5nIGFuZCBJIGRv bid0IHRoaW5rIHRoYXQNCiB0aGlzIHdvdWxkIGJlIHRvbyBoYXJkIHRvIGRvLjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBnZW5lcmFsbHkgc3VwcG9ydCB0aGlzIGFwcHJvYWNoIGFz IHN0b3AtZ2FwIHNvbHV0aW9uIHdoaWxlIHRoZSBpbmR1c3RyeSBnb2VzIHRocnUgdGhlIHRyYW5z aXRpb24uJm5ic3A7IEhvd2V2ZXIsIEkgcmVjb21tZW5kIGEgdmFyaWFudCB3aGVyZWJ5IHRoZSBw eWFuZyBwbHVnaW4gb25seSBtaWdyYXRlcyB0aGUgY29uZmlnIGZhbHNlIHZhbHVlcyAobm90IGFs c28gdGhlIGNvbmZpZyB0cnVlIHZhbHVlcykuJm5ic3A7IFRoZSByZWFzb24NCiBmb3IgdGhpcyBp cyBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NaWdyYXRpbmcgb25seSB0aGUg Y29uZmlnIGZhbHNlIHZhbHVlcyBpcyBzdWZmaWNpZW50IGZvciBtYXRjaGluZyBleGlzdGluZyBm dW5jdGlvbmFsaXR5IChyZWFkOiBhIG11c3QtaGF2ZSByZXF1aXJlbWVudCk7IHRoYXQgaXMsIGN1 cnJlbnRseSB0b3AtbGV2ZWwgL2Zvby1zdGF0ZSBpcyB1c2VkIHRvIHN1cHBvcnQgY29udmV5aW5n IHRoZSBvcHN0YXRlIGZvciBzeXN0ZW0tZ2VuZXJhdGVkIG9iamVjdHMsIHRoYXQNCiBoYXZlIGxp ZmV0aW1lcyBpbmRlcGVuZGVudCBvZiBjb25maWcuJm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5NaWdyYXRpbmcgdGhlIGNvbmZpZyB0cnVlIG5vZGVzIGFsc28gaXMgcG9zc2libGUsIGJ1 dCBvbmx5IG5lZWRlZCBpZiB3YW50aW5nIHRvIHJlcG9ydCB0aGUgb3BzdGF0ZSB2YWx1ZSBmb3Ig Y29uZmlnIHRydWUgbm9kZXMgKGUuZy4sIGhvc3RuYW1lKSwgYnV0IHRoaXMgd291bGQgYmUgYWJv dmUgYW5kIGJleW9uZCB3aGF0IGlzIHBvc3NpYmxlIHRvZGF5IChyZWFkOiBhIG5pY2UtdG8taGF2 ZSByZXF1aXJlbWVudCksDQogYW5kIGhlbmNlIEnigJlkIHJhdGhlciBzdGVlciBmb2xrcyB0b3dh cmRzIHRoZSBuZXcgYXBwcm9hY2ggcmF0aGVyIHRoYW4gZG91YmxlLWRvd24gb24gdGhlIGFwcHJv YWNoIHdl4oCZcmUgdHJ5aW5nIHRvIGdldCBhd2F5IGZyb20uDQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsg VGhpcyBpcyBhIHJlYWwgaGFjay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgSSBsaWtlZCB0aGUgaWYtZmVhdHVyZSBhcHByb2Fj aCBtdWNoIGJldHRlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jmd0OyBlLmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jmd0OyZuYnNwOyAmbmJzcDtsZWFmIG9wZXItc3BlZWQgezxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO2lmLWZlYXR1cmUgJnF1b3Q7bm90IG9wZXJhdGlvbmFsLWRhdGFz dG9yZSZxdW90Ozs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsuLi48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmbmJzcDsgJm5ic3A7fTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIHlvdXIgcHJvcG9zYWwgZm9yIHRoZSBZ QU5HIG1vZHVsZXMgdG8gc2ltdWx0YW5lb3VzbHkgZGVmaW5lIGJvdGggb3BzdGF0ZS1hd2FyZSBh bmQgb3BzdGF0ZS11bmF3YXJlIHRyZWVzPyZuYnNwOyBXb3VsZG7igJl0IHRoYXQgbWFrZSB0aGUg bW9kdWxlcyBsZXNzIHJlYWRhYmxlLCBsYXJnZWx5IHJlZHVuZGFudCwgYW5kIHJpcGUgZm9yIGlu Y29uc2lzdGVuY2llcz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPktlbnQmbmJzcDsgLy8gYXMgYSBjb250cmlidXRvcjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_0A89256A35FA4FC395FF0C88A9B5F4ECjunipernet_-- From nobody Tue Jan 10 11:34:12 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45351289C4 for ; Tue, 10 Jan 2017 11:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEH7FkVJsrHf for ; Tue, 10 Jan 2017 11:34:09 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0130.outbound.protection.outlook.com [104.47.41.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42E391297ED for ; Tue, 10 Jan 2017 11:34:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5IRVVYdvtB9pZnLm1/ssOY3O7dtXO4pihJXPGucQXXE=; b=FRpyWJ95RfatdnKszg0tiDSCyMix7OxlTT605dJ/YiXSd7biiiBZz86lW+ScrYrbEdX1UJDCNdprPCW+mn0dcdM401UNrk6B9PpEcQ82hw1NHSTKZ8SnUDOzXUWooHIA9sLOfonVEH5+CoeUSC5ninCLYXtNBUVlIAZcT+7zeyY= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.3; Tue, 10 Jan 2017 19:34:07 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0829.017; Tue, 10 Jan 2017 19:34:07 +0000 From: Kent Watsen To: "Clyde Wildes (cwildes)" Thread-Topic: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 Thread-Index: AQHSa3iCf0zqhzKmtE+Zpe9My2EhJg== Date: Tue, 10 Jan 2017 19:34:06 +0000 Message-ID: <6C644FF6-BA30-4B3F-814F-929333300D7A@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: c6569419-4275-4cba-2610-08d4398fa4ab x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1441; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:lHs8vTyDr9qVEBNgxr5f0kznHBFPIXpN9q9BJFlCxDZAs3ICVQ/SsQyQxJm5QQC5SgLpATE1qTgUkFf2ZLSqt7BPJGKfpWwmBFHEPOCq+sZdZF4desHGvX5IZ2bF54fNreEZh6qQARZHOVJq8UFJWcXSU8VOPl+ZUAMUsHknCz1cieQZcRSz+IjoN8oAVrySuAFo3KZCqldIfb1UhcbHQXkMh/EN30ioxsk39PGgKqtdMj7WtYXafwd2sofu0VmxGMHZqR/clj7baiZvKvxF0Q8hEcXdV2EibUu+hgcWjPpAb+kQG/ft77nWdNrwEgqX+FYdvX1csrAGkdjM+2VSSaQrGSRWPkLusF7qCtfXk4llVLJ6jsQlTz79Kn1lBpAksNhRJQgvmPP/eVJbzRGR+CsK4n/b/iOc2PLmHM4Ky4u7oNusegEmFPyHjXSXSLL+XknIPd6UCpbtCQgKtTB9yg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 01834E39B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39450400003)(39860400002)(39410400002)(39850400002)(199003)(189002)(230783001)(4001350100001)(6506006)(77096006)(6486002)(122556002)(189998001)(2900100001)(99286003)(6512007)(83506001)(97736004)(92566002)(3660700001)(82746002)(2906002)(83716003)(25786008)(4326007)(86362001)(229853002)(6436002)(3280700002)(38730400001)(54356999)(6916009)(50986999)(101416001)(7736002)(305945005)(105586002)(106356001)(106116001)(110136003)(81156014)(102836003)(36756003)(8676002)(66066001)(3846002)(33656002)(68736007)(6116002)(81166006)(5660300001)(8936002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <322196B9386C3A47BBE6F121BEF1DAC0@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2017 19:34:06.9987 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 19:34:12 -0000 SGkgQ2x5ZGUsDQoNClRoZSBMQyBwZXJpb2QgaGFzIGVuZGVkLiAgV2hpbGUgd2Ugb25seSByZWNl aXZlZCB0d28gcmV2aWV3cywgSSB0aGluayBib3RoIHdlcmUgcXVpdGUgZ29vZCBhbmQgdGhvcm91 Z2ggYW5kLCBhcyBmYXIgYXMgSSBjYW4gdGVsbCwgZW50YWlsIG5lZWRpbmcgYSBub24tdHJpdmlh bCB1cGRhdGUgdG8gdGhlIGRyYWZ0Lg0KDQpNeSB0aG91Z2h0cyBhcmUgdGhhdCB5b3Ugc2hvdWxk IGNvbnRpbnVlIHdvcmtpbmcgd2l0aCBBbGV4IGFuZCBBbmR5IHRvIGVuc3VyZSB0aGVpciBpc3N1 ZXMgYXJlIHJlc29sdmVkLCBhbmQgdGhlbiBwb3N0IGFuIHVwZGF0ZWQgZHJhZnQgdGhhdCB3ZSBj YW4gcnVuIGFub3RoZXIgTEMgb24gd2l0aCB0aGUgaG9wZSBvZiBnZXR0aW5nIGEgbGFyZ2VyIHJl c3BvbnNlLiAgTWFrZXMgc2Vuc2U/DQoNCktlbnQgLy8gYXMgc2hlcGhlcmQNCg0KDQoNCg0K From nobody Tue Jan 10 12:01:01 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF01F129865 for ; Tue, 10 Jan 2017 12:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFossuYx6d2B for ; Tue, 10 Jan 2017 12:00:52 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C5D129866 for ; Tue, 10 Jan 2017 12:00:42 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id a20so187362226qkc.1 for ; Tue, 10 Jan 2017 12:00:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OaWJtltIJmZr6QRPK8p8efmP/B3fcxTYEcgfgQwQXUY=; b=gRfwV9BWWNkFVr1Ti8J13Ufn1WotIJvci7cBwt9sKwbWtuWiwx2GrJk939OOt0Tnow 7geUf+9XQtpuDJoFU9q0xKGIzaucKX7JVZirW36IkPjXWtdWDY+KstCA2OzyRPjVP+A/ NXcVj95dLgUNr3wr3cNinYKV2G8DUmmJEmMqHU3D88oCXNTzt/HzGaiGmESz/EngvrF/ hiA9iLDXQQ1zPid410x9iAMCk2I/F6Pi82lo/zJESGIaUm9dZsC5HvYtxClH3QI2hlIb 1iCcDrxkTLcvelIZPwXWvmmoC1TIxUOmd7k0P1mhbNhn+WlaaHlmtued0IHJl2lw2ZPC iKUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OaWJtltIJmZr6QRPK8p8efmP/B3fcxTYEcgfgQwQXUY=; b=hnkcVPnwgyERAYVziBbQKM4kZqBJt59SAO6r9HB1naexTGZPBjiKF/2Ftsj6wJxQnl htP3xM2fPgfp8sRL0fiXFyOJL+3iT5Wh2KdyNxffXR+V6xuB822PoDf02roQkt6fDZiD g3KD4wE668cMFkdZMX4oNT0uV8UfNEzTr1fq5PQt+4JWtmBsRZJ6oeEm5TwuET7H4kiU 79G5uR9v90BDnApX9XG4ot2jz21Lbu4CBCxTpXBRBNFSzYaKNl5uclCfKYUJaDPd5QSC 5SrgdUYZdoVlqGVztNDATBYJNppu6VJN5+LBuC0R+KHWMdUE9EpBOthY5kBjkZBJCV5s 37hg== X-Gm-Message-State: AIkVDXKissALP208hJ8mBkVDb/dKxN7qEKFMzqnLac75ERbgYQpcHtcKIyVyqOMPVpW9TQJKocxyzEOhH2589A== X-Received: by 10.55.20.137 with SMTP id 9mr4378065qku.237.1484078441906; Tue, 10 Jan 2017 12:00:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Tue, 10 Jan 2017 12:00:40 -0800 (PST) In-Reply-To: <0A89256A-35FA-4FC3-95FF-0C88A9B5F4EC@juniper.net> References: <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> <20170110161643.GE17035@elstar.local> <8f0b1abe-b00e-95d1-f62f-7bc99d414bc6@cisco.com> <0f607346-cb4e-1e10-9956-956cb24dc49e@cisco.com> <0A89256A-35FA-4FC3-95FF-0C88A9B5F4EC@juniper.net> From: Andy Bierman Date: Tue, 10 Jan 2017 12:00:40 -0800 Message-ID: To: Kent Watsen Content-Type: multipart/alternative; boundary=001a1144d226599e0c0545c2f0fe Archived-At: Cc: Netconf , NetMod WG Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 20:01:00 -0000 --001a1144d226599e0c0545c2f0fe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 10, 2017 at 11:08 AM, Kent Watsen wrote: > I think that there may be a better way here: The data modelers design th= e > model on the assumption that an operational state datastore will be > present. We can then use a pyang plugin to generate an extra YANG model > that contains the missing state leaves that would be required for the spl= it > config/state trees. E.g. if it finds a config leaf in foo/speed it creat= es > a module that contains foo-state/speed. I've been playing around with > pyang and I don't think that this would be too hard to do. > > > > I generally support this approach as stop-gap solution while the industry > goes thru the transition. However, I recommend a variant whereby the pya= ng > plugin only migrates the config false values (not also the config true > values). The reason for this is as follows: > > > > Migrating only the config false values is sufficient for matching existin= g > functionality (read: a must-have requirement); that is, currently top-lev= el > /foo-state is used to support conveying the opstate for system-generated > objects, that have lifetimes independent of config. > > > > Migrating the config true nodes also is possible, but only needed if > wanting to report the opstate value for config true nodes (e.g., hostname= ), > but this would be above and beyond what is possible today (read: a > nice-to-have requirement), and hence I=E2=80=99d rather steer folks towar= ds the new > approach rather than double-down on the approach we=E2=80=99re trying to = get away > from. > > > > > > > > > This is a real hack. > > > > > > I liked the if-feature approach much better > > > e.g. > > > > > > leaf oper-speed { > > > if-feature "not operational-datastore"; > > > ... > > > } > > > > Is your proposal for the YANG modules to simultaneously define both > opstate-aware and opstate-unaware trees? Wouldn=E2=80=99t that make the = modules > less readable, largely redundant, and ripe for inconsistencies? > > > > > I think it is better to have a human decide what is in the module instead of relying on a pyang plugin to generate some additional module that follows some simplistic pattern. Of course this solution only works if the value-set of operational data is exactly the same as the configurable value-set (which is sometimes not the case at all). What is an "opstate-aware tree". The point of this work is that the opstate tree goes away and is replaced b= y a protocol operation instead. In fact, there are no new datastores needed whatsoever to add the RPC , or even . > > Kent // as a contributor > > > > > Andy --001a1144d226599e0c0545c2f0fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 10, 2017 at 11:08 AM, Kent Watsen <kwatsen@juniper.net> wrote:

I think that there may= be a better way here:=C2=A0 The data modelers design the model on the assu= mption that an operational state datastore will be present.=C2=A0 We can th= en use a pyang plugin to generate an extra YANG model that contains the missing state leaves that would be required for th= e split config/state trees.=C2=A0 E.g. if it finds a config leaf in foo/spe= ed it creates a module that contains foo-state/speed.=C2=A0 I've been p= laying around with pyang and I don't think that this would be too hard to do.

=C2=A0

I generally support this approach as stop-gap soluti= on while the industry goes thru the transition.=C2=A0 However, I recommend = a variant whereby the pyang plugin only migrates the config false values (n= ot also the config true values).=C2=A0 The reason for this is as follows:

=C2=A0

Migrating only the config false values is sufficient= for matching existing functionality (read: a must-have requirement); that = is, currently top-level /foo-state is used to support conveying the opstate= for system-generated objects, that have lifetimes independent of config.=C2=A0

=C2=A0

Migrating the config true nodes also is possible, bu= t only needed if wanting to report the opstate value for config true nodes = (e.g., hostname), but this would be above and beyond what is possible today= (read: a nice-to-have requirement), and hence I=E2=80=99d rather steer folks towards the new approach rather t= han double-down on the approach we=E2=80=99re trying to get away from.

=C2=A0

=C2=A0

=C2=A0

> This is a real hack.

>=C2=A0

> I liked the if-feature approach much better<= /u>

> e.g.

>

>=C2=A0 =C2=A0leaf oper-speed {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0if-feature "not = operational-datastore";

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

>=C2=A0 =C2=A0}

=C2=A0

Is your proposal for the YANG modules to simultaneou= sly define both opstate-aware and opstate-unaware trees?=C2=A0 Wouldn=E2=80= =99t that make the modules less readable, largely redundant, and ripe for i= nconsistencies?

=C2=A0

=C2=A0


<= /div>

I think it is better to have a human decide what i= s in the module
instead of relying on a pyang plugin to generate = some additional module
that follows some simplistic pattern.

Of course this solution only works if the value-set of= operational data
is exactly the same as the configurable value-s= et (which is sometimes
not the case at all).

=
What is an =C2=A0"opstate-aware tree".

The point of this work is that the opstate tree goes away and is re= placed by
a protocol operation instead.

= In fact, there are no new datastores needed whatsoever to
add the= RPC <resource-ready>, or even <get-operational>.


=C2=A0

Kent=C2=A0 // as a contributor

=C2=A0

=C2=A0


<= /div>

Andy
=C2=A0

--001a1144d226599e0c0545c2f0fe-- From nobody Tue Jan 10 13:20:14 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA37129DA9; Tue, 10 Jan 2017 13:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzU0e_aCgFvg; Tue, 10 Jan 2017 13:20:07 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0120.outbound.protection.outlook.com [104.47.33.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D80531295B0; Tue, 10 Jan 2017 13:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nllfPif2a7IGl8DlSH0J5MKQOvukznkh6VwbUBCkZN8=; b=ZidRpmzqwaLLCVHlVSxlAVWT08qnapvLnK9wksIWxd5nr6MrN3aZkTiRibQDME93LGBZSsgBw+qMU8G3GNQuMUsG5APb6Kiu6kw3mAlRN5kEbJcSsdJxYB8eo1TbY1ufwke123HlmGWmSPh0I1PHgEMfZ8FkcRcQ1nKBcZXA6v0= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.3; Tue, 10 Jan 2017 21:20:04 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0829.017; Tue, 10 Jan 2017 21:20:04 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits Thread-Index: AQHSa2aD89RzNHtVJkqt3M8SCXRmh6EyBQSAgAADy4D//7aBAIAAYlIA///CXIA= Date: Tue, 10 Jan 2017 21:20:04 +0000 Message-ID: <6425C57C-C3DF-4099-AE77-4521B58B8D69@juniper.net> References: <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> <20170110161643.GE17035@elstar.local> <8f0b1abe-b00e-95d1-f62f-7bc99d414bc6@cisco.com> <0f607346-cb4e-1e10-9956-956cb24dc49e@cisco.com> <0A89256A-35FA-4FC3-95FF-0C88A9B5F4EC@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: 71b1e4a4-b19d-4973-e01e-08d4399e71c6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1441; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:7nAWm9zTBjpqTZfudvM8iCGyQtkuS1E6+AuNGow4bcybmNy8OqzRjPlM3tToqYXld9ArAjAVrcx3wy15Orjb7+NqmJ3/dSakTkQrO16sBrn1GzLVShz/G9XHm2hCzLeoi2zqOqWHWO8mnpkdVFKjS6RThFZWCmpE/1eRVTY8Mn49dcll77QR3vsD/5cOLi67Lg1KBielUfU6eUTD1Avit0CdKfkOJCQjqTrlyHLfvb+JJCPUid99oLShk/duH97UFyQxKMOny1aZC/5GtScBwBziIxcUBo6roB9Dr/QPas5XJ11VFVVXCpIRpDRXHhlLt/B/X5XGdxer45GwTzmnlzsBj3dC0AHyGTckmKraWcW8w+mCa2D2xqVQp04/rRx6eT75gPzwB6JK3zULsf66okUeIcxUj7MDPQw2d5tYulFQJLScJwzls3F8VK9TRjbVXKV7wdVMWMqw/OE9ct5N/A== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(150554046322364); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 01834E39B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39410400002)(39860400002)(39840400002)(39450400003)(199003)(189002)(2950100002)(305945005)(7736002)(110136003)(106356001)(106116001)(54906002)(105586002)(76176999)(50986999)(54356999)(6916009)(101416001)(68736007)(6116002)(33656002)(5660300001)(8936002)(81166006)(81156014)(3846002)(66066001)(93886004)(102836003)(36756003)(8676002)(99286003)(2900100001)(6512007)(4001350100001)(189998001)(77096006)(6506006)(122556002)(6486002)(6436002)(229853002)(86362001)(38730400001)(3280700002)(82746002)(3660700001)(92566002)(83506001)(97736004)(25786008)(83716003)(4326007)(2906002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2017 21:20:04.1196 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Cc: Netconf , NetMod WG Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 21:20:09 -0000 DQo+IEkgdGhpbmsgaXQgaXMgYmV0dGVyIHRvIGhhdmUgYSBodW1hbiBkZWNpZGUgd2hhdCBpcyBp biB0aGUgbW9kdWxlDQo+IGluc3RlYWQgb2YgcmVseWluZyBvbiBhIHB5YW5nIHBsdWdpbiB0byBn ZW5lcmF0ZSBzb21lIGFkZGl0aW9uYWwgbW9kdWxlDQo+IHRoYXQgZm9sbG93cyBzb21lIHNpbXBs aXN0aWMgcGF0dGVybi4NCg0KSXQgbWF5IGJlIHNpbXBsZSwgYnV0IEnigJltIHRoaW5raW5nIHRo YXTigJlzIG9ubHkgYmVjYXVzZSBpdOKAmXMgbm90IHRyaWNreSAgOykNCg0KDQo+IE9mIGNvdXJz ZSB0aGlzIHNvbHV0aW9uIG9ubHkgd29ya3MgaWYgdGhlIHZhbHVlLXNldCBvZiBvcGVyYXRpb25h bCBkYXRhDQo+IGlzIGV4YWN0bHkgdGhlIHNhbWUgYXMgdGhlIGNvbmZpZ3VyYWJsZSB2YWx1ZS1z ZXQgKHdoaWNoIGlzIHNvbWV0aW1lcw0KPiBub3QgdGhlIGNhc2UgYXQgYWxsKS4NCg0KVGhlIHZh bHVlLXNldCBvZiB0aGUgb3BlcmF0aW9uYWwgZGF0YSB3b3VsZCBiZSB0aGUgY29tYmluYXRpb24g b2YgYm90aCB0aGUgY29uZmlnIHRydWUgYW5kIGNvbmZpZyBmYWxzZSBub2Rlcy4gICBbRGlkIHlv dSBzZWUgdGhpcyBpbiBteSBsYXN0IHJlc3BvbnNlPyBJIHJlY2VpdmVkIGFuIG9mZmxpbmUgbWVz c2FnZSBpbmRpY2F0aW5nIHRoYXQgbXkgcHJldmlvdXMgcmVzcG9uc2Ugd2FzIHNvbWV3aGF0IG1h bGZvcm1lZCwgc28geW91IG1pZ2h04oCZdmUgbWlzc2VkIGl0Li4uXS4gICBUaGUgY29uZmlnIGZh bHNlIG5vZGVzIGFyZSBvYnZpb3VzbHkgcGFydCBvZiB0aGUgb3BlcmF0aW9uYWwgZGF0YS4gIEZv ciB0aGUgY29uZmlnIHRydWUgbm9kZXMsIEnigJl2ZSBiZWVuIHN3YXllZCB0byBiZWxpZXZlIHRo YXQgZXZlcnkgY29uZmlnIHRydWUgbm9kZSBjYW4gYWxzbyBoYXZlIGFuIG9wZXJhdGlvbmFsIHZh bHVlLiAgSSBkaWRu4oCZdCB0aGluayBzbyBhdCBmaXJzdCwgdXNpbmcg4oCYaG9zdG5hbWXigJkg YXMgYW4gZXhhbXBsZSB0byBtYWtlIG15IHBvaW50LCBidXQgaXQgd2FzIHBvaW50ZWQgb3V0IHRo YXQgdGhlIGFkbWluIG1pZ2h0IGNpcmN1bXZlbnQgdGhlIFlBTkctZHJpdmVuIGNvbmZpZyBlbmdp bmUgY29tcGxldGVseSBhbmQgc2V0IHRoZSBob3N0bmFtZSB2aWEgdGhlIFVOSVggY29tbWFuZCBs aW5lIGluc3RlYWQuICBJbiB0aGlzIGNhc2UsIHRoZSBpbnRlbmRlZCBob3N0bmFtZSB2YWx1ZSBt aWdodCBkaWZmZXIgZnJvbSB0aGUgb3BlcmF0aW9uYWwgaG9zdG5hbWUgdmFsdWUuICBFdmVuIGZv ciBub2RlcyB3aGVyZSB3ZeKAmXJlIGNvbnZpbmNlZCB0aGVyZSBjYW4gbmV2ZXIgYmUgYW4gb3Bl cmF0aW9uYWwgdmFsdWUgdGhhdCBkaWZmZXJzIGZyb20gdGhlIGludGVuZGVkIHZhbHVlLCB0aGVy ZSBzdGlsbCBtaWdodCBiZSBhIHByb3BhZ2F0aW9uIGRlbGF5IHRoYXQgY2F1c2VzIGEgZGlmZmVy ZW5jZSB0byBiZSBwZXJjZWl2ZWQgaW4gdGltZS4gIEFsbCB0aGlzIHBvaW50cyB0byBhIHJhdGhl ciBjb25zZXJ2YXRpdmUgYW5kIHRoYW5rZnVsbHkgc2ltcGxlIHNvbHV0aW9uIHRoYXQgdGhlIHZh bHVlLXNldCBvZiBvcHN0YXRlIGlzIHRoZSBjb21iaW5hdGlvbiBvZiAqYWxsKiB0aGUgY29uZmln IHRydWUgYW5kIGNvbmZpZyBmYWxzZSBub2Rlcy4NCg0KDQoNCj4gV2hhdCBpcyBhbiAib3BzdGF0 ZS1hd2FyZSB0cmVlIi4NCg0KSSBzaG91bGTigJl2ZSB3cml0dGVuIOKAnG9wc3RhdGUtYXdhcmUg ZGF0YSBtb2RlbOKAnS4gICANCg0KVG8gYmUgY2xlYXIsIGJ5IOKAnG9wc3RhdGUtYXdhcmUgdHJl ZeKAnSwgSSBtZWFudCB0aGUgWUFORyBtb2R1bGUgd291bGQgb25seSBoYXZlIGEgdG9wLWxldmVs IC9mb28gdHJlZSB0aGF0IGhhcyBib3RoIGNvbmZpZyB0cnVlIGFuZCBjb25maWcgZmFsc2Ugbm9k ZXMsIHdpdGggdGhlIGV4cGVjdGF0aW9uIHRoYXQgdGhlIHNvbHV0aW9uIHByb3ZpZGVkIGJ5IGRy YWZ0LWlldGYtbmV0bW9kLXJldmlzZWQtZGF0YXN0b3JlcyBlbmFibGVzIDEpIG9wc3RhdGUgZm9y IGJvdGggc3lzdGVtLWdlbmVyYXRlZCBvYmplY3RzIGFzIHdlbGwgYXMgZm9yIGNvbmZpZyB0cnVl IG5vZGVzIGFuZCAyKSBvcHN0YXRlIGZvciBhbGwgY29uZmlnIHRydWUgbm9kZXMgYWxzbyAobm90 ZTogdGhpcyBkb2VzbuKAmXQgcmVtb3ZlIHRoZSBuZWVkIGZvciBleHBsaWNpdCBjb25maWcgZmFs c2Ugbm9kZXMgZm9yIG5lZ290aWF0ZWQgdmFsdWVzIGxpa2UgTVRVKS4NCg0KU2ltaWxhcmx5LCBi eSDigJxvcHN0YXRlLXVuYXdhcmUgdHJlZeKAnSwgSSBtZWFudCB0aGUgWUFORyBtb2R1bGUgd291 bGQgaGF2ZSBib3RoIHRvcC1sZXZlbCAvZm9vIGFuZCAvZm9vLXN0YXRlIHRyZWVzLiAgRXNzZW50 aWFsbHksIHdoYXQgd2UgaGF2ZSB0b2RheSwgd2hpY2ggd2XigJlyZSB0cnlpbmcgdG8gZ2V0IGF3 YXkgZnJvbS4NCg0KDQo+IFRoZSBwb2ludCBvZiB0aGlzIHdvcmsgaXMgdGhhdCB0aGUgb3BzdGF0 ZSB0cmVlIGdvZXMgYXdheSBhbmQgaXMgcmVwbGFjZWQgYnkNCj4gYSBwcm90b2NvbCBvcGVyYXRp b24gaW5zdGVhZC4NCg0KQ29ycmVjdCwgdGhlIGhvcGUgaXMgdGhhdCB0aGUgdG9wLWxldmVsIC9m b28tc3RhdGUgdHJlZSBubyBsb25nZXIgbmVlZHMgdG8gYmUgZGVmaW5lZCBpbiBZQU5HIG1vZHVs ZXMuICBUaGlzIGlzIHRoZSBnb2FsIGFzIHdlIGJlbGlldmUgaXQgd2lsbCBtYWtlIFlBTkcgbW9k dWxlcyBlYXNpZXIgdG8gcmVhZCBhbmQgd3JpdGUuDQoNCg0KPiBJbiBmYWN0LCB0aGVyZSBhcmUg bm8gbmV3IGRhdGFzdG9yZXMgbmVlZGVkIHdoYXRzb2V2ZXIgdG8NCj4gYWRkIHRoZSBSUEMgPHJl c291cmNlLXJlYWR5Piwgb3IgZXZlbiA8Z2V0LW9wZXJhdGlvbmFsPi4NCg0KSeKAmW0gbm90IHN1 cmUgd2hhdCB5b3UgbWVhbiBieSBSUEMgPHJlc291cmNlLXJlYWR5Pi4gIFRydWUsIGEgPGdldC1v cGVyYXRpb25hbD4gUlBDIGNvdWxkIGJlIGRlZmluZWQgbm93LCBidXQgd2XigJlkIHN0aWxsIHdh bnQgdGhlIFlBTkcgbW9kdWxlcyB0byBiZSBhIGNlcnRhaW4gd2F5IGFuZCB3ZeKAmWQgc3RpbGwg d2FudCB0byBkZWZpbmUgYSBjb25jZXB0dWFsIG9wZXJhdGlvbmFsLXN0YXRlIGRhdGFzdG9yZSBz byB0aGF0IHdlIGNvdWxkIGRlc2NyaWJlIGl0IHVuYW1iaWd1b3VzbHkuDQoNCg0KS2VudCAvLyBh cyBhIGNvbnRyaWJ1dG9yDQoNCg0K From nobody Tue Jan 10 14:20:13 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7C212A05E for ; Tue, 10 Jan 2017 14:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id od2k9V5N2bT5 for ; Tue, 10 Jan 2017 14:20:08 -0800 (PST) Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED85112960C for ; Tue, 10 Jan 2017 14:20:07 -0800 (PST) From: Alex Campbell To: "Clyde Wildes (cwildes)" Thread-Topic: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 Thread-Index: AQHSVwEmf0zqhzKmtE+Zpe9My2EhJqEybjB/ Date: Tue, 10 Jan 2017 22:20:06 +0000 Message-ID: <1484086805617.18585@Aviatnet.com> References: In-Reply-To: Accept-Language: en-NZ, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.15.6.9] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 22:20:10 -0000 Hi,=0A= =0A= I approve of all of your proposed changes.=0A= =0A= However, I'm still not sure that "[implementing] the minimum set of functio= nality that is contained in at least three vendor implementations" is a sen= sible policy.=0A= The fact that three vendors produce devices that support a feature doesn't = necessarily mean that every device that would implement this model supports= the feature - especially for a widely-used, generic model such as syslog.= =0A= =0A= In my opinion the syslog model should be designed to accommodate all sorts = of devices, not just rack-mount switches and routers.=0A= For example, many IP phones don't have a console or an accessible filesyste= m. (Just an example; I'm not actually familiar with the internals of IP pho= nes)=0A= The same goes for small managed switches, such as the HP 1810-G8 that happe= ned to be on a nearby coworker's desk when I wrote this.=0A= =0A= Alex=0A= ________________________________________=0A= From: Clyde Wildes (cwildes) =0A= Sent: Friday, 16 December 2016 7:29 a.m.=0A= To: Alex Campbell=0A= Cc: netmod@ietf.org; Kent Watsen; Juergen Schoenwaelder=0A= Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11=0A= =0A= Hi Alex,=0A= =0A= Thanks for your review. My comments are inline as [clyde]=85=0A= =0A= On 12/13/16, 8:16 PM, "netmod on behalf of Alex Campbell" wrote:=0A= =0A= I am considering to implement the data model in this draft.=0A= =0A= I have reviewed this draft and found the following issues. In approxima= tely decreasing order of severity:=0A= =0A= * In the "selector-facility" choice statement the cases have misleading= names - the case where no facility is matched is named "facility", and the= case where specific facilities are matched is named "name". I suggest "no-= facilities" and "specified-facilities", or similar.=0A= =0A= [clyde] I understand your concern and agree. Please see the next answer whe= re I have removed the no-facilities case from the model.=0A= =0A= =0A= * I disagree with the premise of the "no-facilities" case, which is tha= t it can be used to disable a log action, according to the description:=0A= =0A= description=0A= "This case specifies no facilities will match when=0A= comparing the syslog message facility. This is a=0A= method that can be used to effectively disable a=0A= particular log-action (buffer, file, etc).";=0A= =0A= If an administrator wants to disable a log action they should do it b= y either removing it from the configuration, or by setting an "enabled" lea= f to false.=0A= With that in mind, there is no reason for the "no-facilities" case to= exist.=0A= =0A= [clyde] I agree with your suggestion to simplify by removing the no-facilit= ies case. Please see the revised selector grouping which will appear in the= next draft:=0A= =0A= grouping selector {=0A= description=0A= "This grouping defines a syslog selector which is used to=0A= select log messages for the log-action (console, file,=0A= remote, etc.). Choose one or both of the following:=0A= facility [ ...]=0A= pattern-match regular-expression-match-string=0A= If both facility and pattern-match are specified, both must=0A= match in order for a log message to be selected.";=0A= container selector {=0A= description=0A= "This container describes the log selector parameters=0A= for syslog.";=0A= list facility-list {=0A= key facility;=0A= description=0A= "This list describes a collection of syslog=0A= facilities and severities.";=0A= leaf facility {=0A= type union {=0A= type identityref {=0A= base syslogtypes:syslog-facility;=0A= }=0A= type enumeration {=0A= enum all {=0A= description=0A= "This enum describes the case where all=0A= facilities are requested.";=0A= }=0A= }=0A= }=0A= description=0A= "The leaf uniquely identifies a syslog facility.";=0A= }=0A= uses log-severity;=0A= }=0A= leaf pattern-match {=0A= if-feature select-match;=0A= type string;=0A= description=0A= "This leaf desribes a Posix 1003.2 regular expression=0A= string that can be used to select a syslog message for=0A= logging. The match is performed on the RFC 5424=0A= SYSLOG-MSG field.";=0A= }=0A= }=0A= }=0A= =0A= =0A= * What is the behaviour of a selector if neither "no-facilities" nor "f= acility-list" is present?=0A= =0A= [clyde] At least one or both of the following must be specified: facility; = pattern-match (if supported).=0A= =0A= I have updated the description at the beginning of the selector =96 please = see above.=0A= =0A= =0A= * In the "selector" grouping it is not clear how the facility and patte= rn conditions are combined to decide whether a message is selected.=0A= =0A= Must they both match the message, or is it sufficient for either one = to match the message?=0A= =0A= [clyde] If both are specified they must both match the message. This is con= sistent with the syslog implementations by Cisco and Juniper.=0A= =0A= =0A= * Not all servers have a console; there should be a feature to indicate= whether logging to the console is supported.=0A= =0A= [clyde] I have received comments in earlier reviews that we should implemen= t the minimum set of functionality that is contained in at least three vend= or implementations.=0A= =0A= Console is supported by Alcatel/Lucent, Brocade, Cisco (XE, XR, and NXOS), = Juniper, and Linux-rsyslog. Removal of the console action for your case cou= ld be done through a vendor specific deviation statement.=0A= =0A= =0A= * Likewise, not all servers may support logging to user sessions.=0A= =0A= [clyde] User sessions are supported by Alcatel/Lucent, and Juniper. I will = make this a feature in the next revision of the draft since only two vendor= s implement it.=0A= =0A= =0A= * Likewise, not all servers may support a user-accessible filesystem.= =0A= =0A= [clyde] Files are supported by Alcatel/Lucent, Cisco (XE, XR, and NXOS), Ju= niper, and Linux-rsyslog. Removal of the file action for your case could be= done through a vendor specific deviation statement.=0A= =0A= =0A= * RFC 5424 states that the severity and protocol values are not normati= ve.=0A= =0A= [clyde] Is it that you are asking for RFC 5424 to be removed from the Norma= tive Reference section of the draft and added to the Informative section?= =0A= =0A= =0A= * It's not clear to me why this needs to be split into two modules. Is = it so that other modules can define logging parameters but still be usable = on a device without syslog?=0A= =0A= [clyde] We were guided by an early Yang Dr.=92s advice in the choice of two= modules =96 one for types and one for the model. I will defer to our mento= r J=FCrgen for his advice.=0A= =0A= =0A= * "log-severity" defines a severity filter, not a severity, so its name= is misleading.=0A= =0A= [clyde] Please suggest a better name.=0A= =0A= =0A= * Perhaps the "severity" type and the facility identities should have "= reference" statements referring to RFC 5424, rather than referring to it in= the description.=0A= =0A= [clyde] I will defer to our mentor J=FCrgen for his advice. We previously f= ollowed his advice here.=0A= =0A= =0A= * In section "8.2", "admisintrator" is a typo.=0A= =0A= [clyde] This will be fixed in the next draft.=0A= =0A= =0A= I assume that the means of accessing the memory buffer and log files ar= e out of scope of this data model.=0A= =0A= [clyde] This draft covers syslog configuration only.=0A= =0A= =0A= Thanks,=0A= =0A= Clyde=0A= =0A= =0A= Alex=0A= =0A= ________________________________________=0A= From: netmod on behalf of Kent Watsen =0A= Sent: Wednesday, 14 December 2016 2:01 p.m.=0A= To: netmod@ietf.org=0A= Subject: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11=0A= =0A= This is a notice to start a two-week NETMOD WG last call for the docume= nt:=0A= =0A= A YANG Data Model for Syslog Configuration=0A= https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-11=0A= =0A= Please indicate your support or concerns by Tuesday, December 27, 2016.= =0A= =0A= We are particularly interested in statements of the form:=0A= * I have reviewed this draft and found no issues.=0A= * I have reviewed this draft and found the following issues: ...=0A= =0A= As well as:=0A= * I have implemented the data model in this draft.=0A= * I am implementing the data model in this draft.=0A= * I am considering to implement the data model in this draft.=0A= * I am not considering to implement the data model in this draft.=0A= =0A= Thank you,=0A= NETMOD WG Chairs=0A= =0A= =0A= =0A= _______________________________________________=0A= netmod mailing list=0A= netmod@ietf.org=0A= https://www.ietf.org/mailman/listinfo/netmod=0A= =0A= _______________________________________________=0A= netmod mailing list=0A= netmod@ietf.org=0A= https://www.ietf.org/mailman/listinfo/netmod=0A= =0A= =0A= From nobody Tue Jan 10 14:23:30 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0BF1294BC for ; Tue, 10 Jan 2017 14:23:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEk2HNgHOIvu for ; Tue, 10 Jan 2017 14:23:24 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB79A129585 for ; Tue, 10 Jan 2017 14:23:24 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id 11so91841345qkl.3 for ; Tue, 10 Jan 2017 14:23:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=88qnGhPZ24csPvO5kEq28rtGhI0d12GPmRXonJYMwj0=; b=q1LyuQgyzAXdK04YCw9N3PaMWKzPhRIrucMCXeWlXvffAvxjbkDJLDSKqYAvLXHL8A mLe77Gkqh64KNX+ljn7St8yFih6u4eGtskl4BBMD9h1/UfM6tIIRzTeq0JmHIwFQ/ieA hCalsj7Rjpch4K5bJ82sYyg95iemHKMUdX6Jkgem1RS+M27rZ4fuqSpWrDyyKE4MxwLM 1PgXMGEf+9Z5rWWtWbO5VkPNlQfS7FzFIQ2k+wINtcGBAApI0NRClWaVP2rBRpDL6vri DjChFI7C1VPh40s/c8t3EOuas06vzKNXql1+kapHVt82C4I4Ki8l3oNbWern1bu48dn9 nHKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=88qnGhPZ24csPvO5kEq28rtGhI0d12GPmRXonJYMwj0=; b=cGSQTPpiq/HQ816NqkBsWCmOAxwDqxtr569ol000T4h56zNvB0iaCYRMx3HfcA9F9d Ns/9d7NyJpsNQsMOYP8ciLDxI3UT40vBHXxhCnSPAf6SIA09QbSbeE3r7bnMhq+rsWj2 tStfI74/pdRYZAh61dad4cnJH5tQ8gkR2FF3nqRtgZy79zKZ9VaHB5u8IFsNSSnf1AwO 1M2Pk0JFJA1KM8UEy8i2rlYaN/WoeA9EJBIJMENvY0XxMkR5AWmbPNwZvp+gdn6Yt78g +VkmOQsO9YY1+BUrVMw8LJbHwOkEUMaNMDy5PVBRl4PsU7l08eYzWQzNSuA68hxjjs/Q C58Q== X-Gm-Message-State: AIkVDXLbkrxkOYmLGaQL09gnkTbLfMvbdnc11EACaUlvUd0HL17tWw1I8QovpOlt743uCMEHhPMiMm41rPMFJQ== X-Received: by 10.55.152.4 with SMTP id a4mr4980500qke.69.1484087003896; Tue, 10 Jan 2017 14:23:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Tue, 10 Jan 2017 14:23:23 -0800 (PST) In-Reply-To: <6425C57C-C3DF-4099-AE77-4521B58B8D69@juniper.net> References: <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> <20170110161643.GE17035@elstar.local> <8f0b1abe-b00e-95d1-f62f-7bc99d414bc6@cisco.com> <0f607346-cb4e-1e10-9956-956cb24dc49e@cisco.com> <0A89256A-35FA-4FC3-95FF-0C88A9B5F4EC@juniper.net> <6425C57C-C3DF-4099-AE77-4521B58B8D69@juniper.net> From: Andy Bierman Date: Tue, 10 Jan 2017 14:23:23 -0800 Message-ID: To: Kent Watsen Content-Type: multipart/alternative; boundary=94eb2c07ecfaaef0ab0545c4ee9d Archived-At: Cc: Netconf , NetMod WG Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 22:23:27 -0000 --94eb2c07ecfaaef0ab0545c4ee9d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen wrote: > > > I think it is better to have a human decide what is in the module > > instead of relying on a pyang plugin to generate some additional module > > that follows some simplistic pattern. > > It may be simple, but I=E2=80=99m thinking that=E2=80=99s only because it= =E2=80=99s not tricky ;) > > The client and server developers still need to know about this auto-generated module and implement it. Operators might have to know about it to use it. > > Of course this solution only works if the value-set of operational data > > is exactly the same as the configurable value-set (which is sometimes > > not the case at all). > > The value-set of the operational data would be the combination of both th= e > config true and config false nodes. [Did you see this in my last > response? I received an offline message indicating that my previous > response was somewhat malformed, so you might=E2=80=99ve missed it...]. = The > config false nodes are obviously part of the operational data. For the > config true nodes, I=E2=80=99ve been swayed to believe that every config = true node > can also have an operational value. I didn=E2=80=99t think so at first, = using > =E2=80=98hostname=E2=80=99 as an example to make my point, but it was poi= nted out that the > admin might circumvent the YANG-driven config engine completely and set t= he > hostname via the UNIX command line instead. In this case, the intended > hostname value might differ from the operational hostname value. Even fo= r > nodes where we=E2=80=99re convinced there can never be an operational val= ue that > differs from the intended value, there still might be a propagation delay > that causes a difference to be perceived in time. All this points to a > rather conservative and thankfully simple solution that the value-set of > opstate is the combination of *all* the config true and config false node= s. > > But the foo-state node is being omitted from the module. How does the pyang plugin know how to produce the extra values so the auto-generated foo-state node has all the combined values? > > > What is an "opstate-aware tree". > > I should=E2=80=99ve written =E2=80=9Copstate-aware data model=E2=80=9D. > > To be clear, by =E2=80=9Copstate-aware tree=E2=80=9D, I meant the YANG mo= dule would only > have a top-level /foo tree that has both config true and config false > nodes, with the expectation that the solution provided by > draft-ietf-netmod-revised-datastores enables 1) opstate for both > system-generated objects as well as for config true nodes and 2) opstate > for all config true nodes also (note: this doesn=E2=80=99t remove the nee= d for > explicit config false nodes for negotiated values like MTU). > > Similarly, by =E2=80=9Copstate-unaware tree=E2=80=9D, I meant the YANG mo= dule would have > both top-level /foo and /foo-state trees. Essentially, what we have toda= y, > which we=E2=80=99re trying to get away from. > > > > The point of this work is that the opstate tree goes away and is > replaced by > > a protocol operation instead. > > Correct, the hope is that the top-level /foo-state tree no longer needs t= o > be defined in YANG modules. This is the goal as we believe it will make > YANG modules easier to read and write. > > > > In fact, there are no new datastores needed whatsoever to > > add the RPC , or even . > > I=E2=80=99m not sure what you mean by RPC . True, a > RPC could be defined now, but we=E2=80=99d still want t= he YANG > modules to be a certain way and we=E2=80=99d still want to define a conce= ptual > operational-state datastore so that we could describe it unambiguously. > > I could have an RPC that tested a config subtree. It would return 'true' if intended=3Dapplied for that subtree. I agree it is good to have clear definitions that are widely understood. It would be nice to have any clear definition of config=3Dfalse YANG nodes, whether datastores are used or not. (e.g., does operational state include counters?) > Kent // as a contributor > > > Andy --94eb2c07ecfaaef0ab0545c4ee9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --94eb2c07ecfaaef0ab0545c4ee9d-- From nobody Tue Jan 10 14:38:40 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8E81294BC for ; Tue, 10 Jan 2017 14:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgM6Uyg3a_Yq for ; Tue, 10 Jan 2017 14:38:36 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3DCE129585 for ; Tue, 10 Jan 2017 14:29:19 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id 11so91979736qkl.3 for ; Tue, 10 Jan 2017 14:29:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=J/gecMXO50uMo8HcL+9kTMjFj7r/1W6ja7KRldOD8WA=; b=E3ktMmQtKZk8hkRwqgsuUrukpNQnhYkHtjoI0UvuZSUeLJhgI64MlB2fRV+uDX+NmV N34AuuN+pvywNIboh1o2x/c+2oActPuBkiXVd+ci4deISYhO2cD3JyziqjXCxNApmg3A HhRwXBBq3JRLi/CAqn2g0LO7tmKBPgrUKBkti4GYa4XzNxj65jeIv1EiiMw8XlB1XZM1 05aBXwXL+0gFuG9gJQMPhGGsKBNhJdfggmRz7zAF6rtMHCnPlrB9Iri50CtEBEgIJX3F 7wy21Qi2EK3MUkpJTR2ORJGRKmGmTccw5gjHuEnJVPVzw6SOXi9hj3pm5onHyUNKwmP7 W5wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=J/gecMXO50uMo8HcL+9kTMjFj7r/1W6ja7KRldOD8WA=; b=UIA5P34XY8FhxlIs68E1TsgBOCkBmrMt3Wx5TyOD86+Lf2dErAYLphHVCAvbo+vTfq iyrPlF2qp9lmGSz2g3iEEbBD5FphI/j2pbeZGvd5oSbPGt0zZHVmpgdtHO52GUZNEKXW s0b4stTrwSs29h+P4JacjrFlH1/hM8f0IKcSiM9QUcWUFeiw1Yqqkg+3x3hyUZkO8Ggp SGDN3u8AMUwY1jWKdcicENQh3+ermDdnA2SSljj/0vSYrWcqP11/uxhLdBA6Yx0lp07j TPjWf3A9wEWCiT2cL/ss5uEfKeGJ50EfXeYFpNeChed7wYT3mG9g/KuB6sVk93ZZo1Uk j7/g== X-Gm-Message-State: AIkVDXIJupuC7hKEVUt75Z66UN92jBZjgQUuYecAvnKKcuU8J48oaHG0C1MRM+g8GJ8e/nZ25vKwPFQJu1sz7w== X-Received: by 10.55.152.4 with SMTP id a4mr4998180qke.69.1484087359099; Tue, 10 Jan 2017 14:29:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Tue, 10 Jan 2017 14:29:18 -0800 (PST) In-Reply-To: <1484086805617.18585@Aviatnet.com> References: <1484086805617.18585@Aviatnet.com> From: Andy Bierman Date: Tue, 10 Jan 2017 14:29:18 -0800 Message-ID: To: Alex Campbell Content-Type: multipart/alternative; boundary=94eb2c07ecfadae30c0545c503a9 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 22:38:39 -0000 --94eb2c07ecfadae30c0545c503a9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 10, 2017 at 2:20 PM, Alex Campbell wrote: > Hi, > > I approve of all of your proposed changes. > > However, I'm still not sure that "[implementing] the minimum set of > functionality that is contained in at least three vendor implementations" > is a sensible policy. > The fact that three vendors produce devices that support a feature doesn'= t > necessarily mean that every device that would implement this model suppor= ts > the feature - especially for a widely-used, generic model such as syslog. > > In my opinion the syslog model should be designed to accommodate all sort= s > of devices, not just rack-mount switches and routers. > For example, many IP phones don't have a console or an accessible > filesystem. (Just an example; I'm not actually familiar with the internal= s > of IP phones) > The same goes for small managed switches, such as the HP 1810-G8 that > happened to be on a nearby coworker's desk when I wrote this. > > totally agree - I was going to send a followup, glad you already did. YANG mandatory-to-implement should be coupled to the feature set, not the assumed platform. For example, is there something in the SYSLOG standard that mandates console ports or user logins? If not, why are these mandatory parts of the syslog configuration? The draft is light on context and use-cases. A user of the standard should not need to be aware of proprietary predecessors in order to understand it. > Alex > Andy > ________________________________________ > From: Clyde Wildes (cwildes) > Sent: Friday, 16 December 2016 7:29 a.m. > To: Alex Campbell > Cc: netmod@ietf.org; Kent Watsen; Juergen Schoenwaelder > Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 > > Hi Alex, > > Thanks for your review. My comments are inline as [clyde]=E2=80=A6 > > On 12/13/16, 8:16 PM, "netmod on behalf of Alex Campbell" < > netmod-bounces@ietf.org on behalf of Alex.Campbell@Aviatnet.com> wrote: > > I am considering to implement the data model in this draft. > > I have reviewed this draft and found the following issues. In > approximately decreasing order of severity: > > * In the "selector-facility" choice statement the cases have > misleading names - the case where no facility is matched is named > "facility", and the case where specific facilities are matched is named > "name". I suggest "no-facilities" and "specified-facilities", or similar. > > [clyde] I understand your concern and agree. Please see the next answer > where I have removed the no-facilities case from the model. > > > * I disagree with the premise of the "no-facilities" case, which is > that it can be used to disable a log action, according to the description= : > > description > "This case specifies no facilities will match when > comparing the syslog message facility. This is a > method that can be used to effectively disable a > particular log-action (buffer, file, etc)."; > > If an administrator wants to disable a log action they should do it > by either removing it from the configuration, or by setting an "enabled" > leaf to false. > With that in mind, there is no reason for the "no-facilities" case > to exist. > > [clyde] I agree with your suggestion to simplify by removing the > no-facilities case. Please see the revised selector grouping which will > appear in the next draft: > > grouping selector { > description > "This grouping defines a syslog selector which is used to > select log messages for the log-action (console, file, > remote, etc.). Choose one or both of the following: > facility [ ...] > pattern-match regular-expression-match-string > If both facility and pattern-match are specified, both must > match in order for a log message to be selected."; > container selector { > description > "This container describes the log selector parameters > for syslog."; > list facility-list { > key facility; > description > "This list describes a collection of syslog > facilities and severities."; > leaf facility { > type union { > type identityref { > base syslogtypes:syslog-facility; > } > type enumeration { > enum all { > description > "This enum describes the case where all > facilities are requested."; > } > } > } > description > "The leaf uniquely identifies a syslog facility."; > } > uses log-severity; > } > leaf pattern-match { > if-feature select-match; > type string; > description > "This leaf desribes a Posix 1003.2 regular expression > string that can be used to select a syslog message for > logging. The match is performed on the RFC 5424 > SYSLOG-MSG field."; > } > } > } > > > * What is the behaviour of a selector if neither "no-facilities" nor > "facility-list" is present? > > [clyde] At least one or both of the following must be specified: facility= ; > pattern-match (if supported). > > I have updated the description at the beginning of the selector =E2=80=93= please > see above. > > > * In the "selector" grouping it is not clear how the facility and > pattern conditions are combined to decide whether a message is selected. > > Must they both match the message, or is it sufficient for either on= e > to match the message? > > [clyde] If both are specified they must both match the message. This is > consistent with the syslog implementations by Cisco and Juniper. > > > * Not all servers have a console; there should be a feature to > indicate whether logging to the console is supported. > > [clyde] I have received comments in earlier reviews that we should > implement the minimum set of functionality that is contained in at least > three vendor implementations. > > Console is supported by Alcatel/Lucent, Brocade, Cisco (XE, XR, and NXOS)= , > Juniper, and Linux-rsyslog. Removal of the console action for your case > could be done through a vendor specific deviation statement. > > > * Likewise, not all servers may support logging to user sessions. > > [clyde] User sessions are supported by Alcatel/Lucent, and Juniper. I wil= l > make this a feature in the next revision of the draft since only two > vendors implement it. > > > * Likewise, not all servers may support a user-accessible filesystem. > > [clyde] Files are supported by Alcatel/Lucent, Cisco (XE, XR, and NXOS), > Juniper, and Linux-rsyslog. Removal of the file action for your case coul= d > be done through a vendor specific deviation statement. > > > * RFC 5424 states that the severity and protocol values are not > normative. > > [clyde] Is it that you are asking for RFC 5424 to be removed from the > Normative Reference section of the draft and added to the Informative > section? > > > * It's not clear to me why this needs to be split into two modules. I= s > it so that other modules can define logging parameters but still be usabl= e > on a device without syslog? > > [clyde] We were guided by an early Yang Dr.=E2=80=99s advice in the choic= e of two > modules =E2=80=93 one for types and one for the model. I will defer to ou= r mentor > J=C3=BCrgen for his advice. > > > * "log-severity" defines a severity filter, not a severity, so its > name is misleading. > > [clyde] Please suggest a better name. > > > * Perhaps the "severity" type and the facility identities should have > "reference" statements referring to RFC 5424, rather than referring to it > in the description. > > [clyde] I will defer to our mentor J=C3=BCrgen for his advice. We previou= sly > followed his advice here. > > > * In section "8.2", "admisintrator" is a typo. > > [clyde] This will be fixed in the next draft. > > > I assume that the means of accessing the memory buffer and log files > are out of scope of this data model. > > [clyde] This draft covers syslog configuration only. > > > Thanks, > > Clyde > > > Alex > > ________________________________________ > From: netmod on behalf of Kent Watsen < > kwatsen@juniper.net> > Sent: Wednesday, 14 December 2016 2:01 p.m. > To: netmod@ietf.org > Subject: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 > > This is a notice to start a two-week NETMOD WG last call for the > document: > > A YANG Data Model for Syslog Configuration > https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-11 > > Please indicate your support or concerns by Tuesday, December 27, 201= 6. > > We are particularly interested in statements of the form: > * I have reviewed this draft and found no issues. > * I have reviewed this draft and found the following issues: ... > > As well as: > * I have implemented the data model in this draft. > * I am implementing the data model in this draft. > * I am considering to implement the data model in this draft. > * I am not considering to implement the data model in this draft. > > Thank you, > NETMOD WG Chairs > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --94eb2c07ecfadae30c0545c503a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 10, 2017 at 2:20 PM, Alex Campbell <Alex.Campbell= @aviatnet.com> wrote:
Hi,
I approve of all of your proposed changes.

However, I'm still not sure that "[implementing] the minimum set o= f functionality that is contained in at least three vendor implementations&= quot; is a sensible policy.
The fact that three vendors produce devices that support a feature doesn= 9;t necessarily mean that every device that would implement this model supp= orts the feature - especially for a widely-used, generic model such as sysl= og.
=C2=A0
In my opinion the syslog model should be designed to accommodate all sorts = of devices, not just rack-mount switches and routers.
For example, many IP phones don't have a console or an accessible files= ystem. (Just an example; I'm not actually familiar with the internals o= f IP phones)
The same goes for small managed switches, such as the HP 1810-G8 that happe= ned to be on a nearby coworker's desk when I wrote this.


totally agree - I was going to send a = followup, glad you already did.

YANG mandatory-to-= implement should be coupled to the feature set, not the assumed platform.
For example, is there something in the SYSLOG standard that mandat= es console ports or user logins?
If not, why are these mandatory = parts of the syslog configuration?

The draft is li= ght on context and use-cases.
A user of the standard should not n= eed to be aware of proprietary predecessors
in order to understan= d it.


=C2=A0
Alex

Andy
=C2=A0
________________________________________
From: Clyde Wildes (cwildes) <cwild= es@cisco.com>
Sent: Friday, 16 December 2016 7:29 a.m.
To: Alex Campbell
Cc: netmod@ietf.org; Kent Watsen; Ju= ergen Schoenwaelder
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-= 11

Hi Alex,

Thanks for your review. My comments are inline as [clyde]=E2=80=A6

On 12/13/16, 8:16 PM, "netmod on behalf of Alex Campbell" <netmod-bounces@ietf.org on beha= lf of Alex.Campbell@Aviatnet.com> wrote:

=C2=A0 =C2=A0 I am considering to implement the data model in this draft.
=C2=A0 =C2=A0 I have reviewed this draft and found the following issues. In= approximately decreasing order of severity:

=C2=A0 =C2=A0 * In the "selector-facility" choice statement the c= ases have misleading names - the case where no facility is matched is named= "facility", and the case where specific facilities are matched i= s named "name". I suggest "no-facilities" and "spe= cified-facilities", or similar.

[clyde] I understand your concern and agree. Please see the next answer whe= re I have removed the no-facilities case from the model.


=C2=A0 =C2=A0 * I disagree with the premise of the "no-facilities"= ; case, which is that it can be used to disable a log action, according to = the description:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "This case spe= cifies no facilities will match when
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0comparing the= syslog message facility. This is a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0method that c= an be used to effectively disable a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0particular lo= g-action (buffer, file, etc).";

=C2=A0 =C2=A0 =C2=A0 If an administrator wants to disable a log action they= should do it by either removing it from the configuration, or by setting a= n "enabled" leaf to false.
=C2=A0 =C2=A0 =C2=A0 With that in mind, there is no reason for the "no= -facilities" case to exist.

[clyde] I agree with your suggestion to simplify by removing the no-facilit= ies case. Please see the revised selector grouping which will appear in the= next draft:

=C2=A0 grouping selector {
=C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 "This grouping defines a syslog selector which is= used to
=C2=A0 =C2=A0 =C2=A0 =C2=A0select log messages for the log-action (console,= file,
=C2=A0 =C2=A0 =C2=A0 =C2=A0remote, etc.). Choose one or both of the followi= ng:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0facility [<facility> <severity&g= t;...]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pattern-match regular-expression-match-string
=C2=A0 =C2=A0 =C2=A0 =C2=A0If both facility and pattern-match are specified= , both must
=C2=A0 =C2=A0 =C2=A0 =C2=A0match in order for a log message to be selected.= ";
=C2=A0 =C2=A0 container selector {
=C2=A0 =C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "This container describes the log selector= parameters
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for syslog.";
=C2=A0 =C2=A0 =C2=A0 list facility-list {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 key facility;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "This list describes a collection o= f syslog
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0facilities and severities.";<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf facility {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type union {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type identityref {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 base syslogtypes:syslog-fa= cility;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type enumeration {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum all {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "This e= num describes the case where all
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0facili= ties are requested.";
=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 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "The leaf uniquely identifie= s a syslog facility.";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 uses log-severity;
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 leaf pattern-match {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if-feature select-match;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 type string;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 description
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "This leaf desribes a Posix 1003.2 = regular expression
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0string that can be used to select = a syslog message for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0logging. The match is performed on= the RFC 5424
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SYSLOG-MSG field.";
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 }


=C2=A0 =C2=A0 * What is the behaviour of a selector if neither "no-fac= ilities" nor "facility-list" is present?

[clyde] At least one or both of the following must be specified: facility; = pattern-match (if supported).

I have updated the description at the beginning of the selector =E2=80=93 p= lease see above.


=C2=A0 =C2=A0 * In the "selector" grouping it is not clear how th= e facility and pattern conditions are combined to decide whether a message = is selected.

=C2=A0 =C2=A0 =C2=A0 Must they both match the message, or is it sufficient = for either one to match the message?

[clyde] If both are specified they must both match the message. This is con= sistent with the syslog implementations by Cisco and Juniper.


=C2=A0 =C2=A0 * Not all servers have a console; there should be a feature t= o indicate whether logging to the console is supported.

[clyde] I have received comments in earlier reviews that we should implemen= t the minimum set of functionality that is contained in at least three vend= or implementations.

Console is supported by Alcatel/Lucent, Brocade, Cisco (XE, XR, and NXOS), = Juniper, and Linux-rsyslog. Removal of the console action for your case cou= ld be done through a vendor specific deviation statement.


=C2=A0 =C2=A0 * Likewise, not all servers may support logging to user sessi= ons.

[clyde] User sessions are supported by Alcatel/Lucent, and Juniper. I will = make this a feature in the next revision of the draft since only two vendor= s implement it.


=C2=A0 =C2=A0 * Likewise, not all servers may support a user-accessible fil= esystem.

[clyde] Files are supported by Alcatel/Lucent, Cisco (XE, XR, and NXOS), Ju= niper, and Linux-rsyslog. Removal of the file action for your case could be= done through a vendor specific deviation statement.


=C2=A0 =C2=A0 * RFC 5424 states that the severity and protocol values are n= ot normative.

[clyde] Is it that you are asking for RFC 5424 to be removed from the Norma= tive Reference section of the draft and added to the Informative section?

=C2=A0 =C2=A0 * It's not clear to me why this needs to be split into tw= o modules. Is it so that other modules can define logging parameters but st= ill be usable on a device without syslog?

[clyde] We were guided by an early Yang Dr.=E2=80=99s advice in the choice = of two modules =E2=80=93 one for types and one for the model. I will defer = to our mentor J=C3=BCrgen for his advice.


=C2=A0 =C2=A0 * "log-severity" defines a severity filter, not a s= everity, so its name is misleading.

[clyde] Please suggest a better name.


=C2=A0 =C2=A0 * Perhaps the "severity" type and the facility iden= tities should have "reference" statements referring to RFC 5424, = rather than referring to it in the description.

[clyde] I will defer to our mentor J=C3=BCrgen for his advice. We previousl= y followed his advice here.


=C2=A0 =C2=A0 * In section "8.2", "admisintrator" is a = typo.

[clyde] This will be fixed in the next draft.


=C2=A0 =C2=A0 I assume that the means of accessing the memory buffer and lo= g files are out of scope of this data model.

[clyde] This draft covers syslog configuration only.


Thanks,

Clyde


=C2=A0 =C2=A0 Alex

=C2=A0 =C2=A0 ________________________________________
=C2=A0 =C2=A0 From: netmod <n= etmod-bounces@ietf.org> on behalf of Kent Watsen <kwatsen@juniper.net>
=C2=A0 =C2=A0 Sent: Wednesday, 14 December 2016 2:01 p.m.
=C2=A0 =C2=A0 To: netmod@ietf.org =C2=A0 =C2=A0 Subject: [netmod] WG Last Call for draft-ietf-netmod-syslog-<= wbr>model-11

=C2=A0 =C2=A0 This is a notice to start a two-week NETMOD WG last call for = the document:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 A YANG Data Model for Syslog Configuration
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://too= ls.ietf.org/html/draft-ietf-netmod-syslog-model-11

=C2=A0 =C2=A0 Please indicate your support or concerns by Tuesday, December= 27, 2016.

=C2=A0 =C2=A0 We are particularly interested in statements of the form:
=C2=A0 =C2=A0 =C2=A0 * I have reviewed this draft and found no issues.
=C2=A0 =C2=A0 =C2=A0 * I have reviewed this draft and found the following i= ssues: ...

=C2=A0 =C2=A0 As well as:
=C2=A0 =C2=A0 =C2=A0 * I have implemented the data model in this draft.
=C2=A0 =C2=A0 =C2=A0 * I am implementing the data model in this draft.
=C2=A0 =C2=A0 =C2=A0 * I am considering to implement the data model in this= draft.
=C2=A0 =C2=A0 =C2=A0 * I am not considering to implement the data model in = this draft.

=C2=A0 =C2=A0 Thank you,
=C2=A0 =C2=A0 NETMOD WG Chairs



=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 netmod mailing list
=C2=A0 =C2=A0 netmod@ietf.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/netmod

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 netmod mailing list
=C2=A0 =C2=A0 netmod@ietf.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/netmod



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

--94eb2c07ecfadae30c0545c503a9-- From nobody Tue Jan 10 15:54:21 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAB01293F4; Tue, 10 Jan 2017 15:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bE7Tkhgd-DT; Tue, 10 Jan 2017 15:54:17 -0800 (PST) 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 0B1AF126D74; Tue, 10 Jan 2017 15:54:17 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 61BF07BB; Wed, 11 Jan 2017 00:54:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id bbj6J_pEy5-N; Wed, 11 Jan 2017 00:54:13 +0100 (CET) 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; Wed, 11 Jan 2017 00:54:14 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E670C2008D; Wed, 11 Jan 2017 00:54:14 +0100 (CET) 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 SEMIlGAFQw9f; Wed, 11 Jan 2017 00:54:13 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AF9D42008C; Wed, 11 Jan 2017 00:54:13 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C781A3E08EA2; Wed, 11 Jan 2017 00:54:14 +0100 (CET) Date: Wed, 11 Jan 2017 00:54:13 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20170110235411.GA18000@elstar.local> Mail-Followup-To: Kent Watsen , Andy Bierman , Robert Wilton , Netconf , NetMod WG References: <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> <20170110161643.GE17035@elstar.local> <8f0b1abe-b00e-95d1-f62f-7bc99d414bc6@cisco.com> <0f607346-cb4e-1e10-9956-956cb24dc49e@cisco.com> <0A89256A-35FA-4FC3-95FF-0C88A9B5F4EC@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <0A89256A-35FA-4FC3-95FF-0C88A9B5F4EC@juniper.net> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: NetMod WG , Netconf Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 23:54:19 -0000 I believe that shortening tranistion pain is in the longer term better than prociding tools that at the end just extend the transition pain. /js On Tue, Jan 10, 2017 at 07:08:47PM +0000, Kent Watsen wrote: > I think that there may be a better way here: The data modelers design the model on the assumption that an operational state datastore will be present. We can then use a pyang plugin to generate an extra YANG model that contains the missing state leaves that would be required for the split config/state trees. E.g. if it finds a config leaf in foo/speed it creates a module that contains foo-state/speed. I've been playing around with pyang and I don't think that this would be too hard to do. > > I generally support this approach as stop-gap solution while the industry goes thru the transition. However, I recommend a variant whereby the pyang plugin only migrates the config false values (not also the config true values). The reason for this is as follows: > > Migrating only the config false values is sufficient for matching existing functionality (read: a must-have requirement); that is, currently top-level /foo-state is used to support conveying the opstate for system-generated objects, that have lifetimes independent of config. > > Migrating the config true nodes also is possible, but only needed if wanting to report the opstate value for config true nodes (e.g., hostname), but this would be above and beyond what is possible today (read: a nice-to-have requirement), and hence I’d rather steer folks towards the new approach rather than double-down on the approach we’re trying to get away from. > > > > > This is a real hack. > > > > I liked the if-feature approach much better > > e.g. > > > > leaf oper-speed { > > if-feature "not operational-datastore"; > > ... > > } > > Is your proposal for the YANG modules to simultaneously define both opstate-aware and opstate-unaware trees? Wouldn’t that make the modules less readable, largely redundant, and ripe for inconsistencies? > > > > Kent // as a contributor > > > _______________________________________________ > 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 Jan 10 16:34:55 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8B11293D8 for ; Tue, 10 Jan 2017 16:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekvgFR4Mwy5x for ; Tue, 10 Jan 2017 16:34:46 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C80F8129574 for ; Tue, 10 Jan 2017 16:34:45 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id u25so577104843qki.2 for ; Tue, 10 Jan 2017 16:34:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=CrozdQJ+YmaOHloBJkEFVAI7qll7TY0f1EUVl35XT2w=; b=dEYqdP3KsyjNC44Hml8qY343JyZU7xOMIgr2+DksxsA21+kPh+3I7uDwBN6kyRbwBV WAcv55Rrdi9jszviDQ4gsweJMDMtr4WnvES002S/RuZIMFMhIZ/iDI+3G8DXsydH5Q0r Whaojra5UrlqJxUOJsGjQvGEPr4bxYm9qVc8kChv/h8TbjWNW/T2Bbl/HBU5YGHxXcer dly7xP+9y2zjmUef8+H4hSR3AFjo8MgN2b8bH4M0zINByDjGLzmNE76vPnmnH8EWN7AY 4B8yKK7EoIiKlEf5TE51gpjMZ1IzdMytm1LthcyNR9fjuN3T5QROPqUCBp6cJAZDU0Sx 4W6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=CrozdQJ+YmaOHloBJkEFVAI7qll7TY0f1EUVl35XT2w=; b=TR8U7FMQdcaHRrKATg4Xo9+qWcHJOvmX0xccVFLQo+kYIantXT2OzLvGZMITKPZ6pv XQG0nlUCRrf3qtRQCE3WxWb4KVVj1tR0QI4Re97dJrB0tV6p8vUlcvxQmyONV3XmUtw6 CLnGWiCPJaC9wgFIgFUExxCIavwMSXkq/VY9pLMXy/0P0JCF7mreLLVW5fW6w+HDa1XE p+d4dNlc8jzH4hdEHDD2t12EfCbO3lM7ZDxDLFDtW9Fa3G6MbaqTBCRXxsKzquCe6I+g UUGAH8aZPhx2eF5lgHsMvfhrEL7/dQabGEEMycbe/8IOcPGMWkTnAgsJ6DmAtwDjMs2E QLxg== X-Gm-Message-State: AIkVDXJSF2A89OzFnHaasuuenuXIrum1xb7EqMcU3mmKJ7PBVa1FjX47NM62bKVaW9LuNbPc6JnWWMGuzGKTqg== X-Received: by 10.55.166.77 with SMTP id p74mr5541736qke.314.1484094884881; Tue, 10 Jan 2017 16:34:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Tue, 10 Jan 2017 16:34:43 -0800 (PST) In-Reply-To: <20170110235411.GA18000@elstar.local> References: <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> <20170110161643.GE17035@elstar.local> <8f0b1abe-b00e-95d1-f62f-7bc99d414bc6@cisco.com> <0f607346-cb4e-1e10-9956-956cb24dc49e@cisco.com> <0A89256A-35FA-4FC3-95FF-0C88A9B5F4EC@juniper.net> <20170110235411.GA18000@elstar.local> From: Andy Bierman Date: Tue, 10 Jan 2017 16:34:43 -0800 Message-ID: To: Juergen Schoenwaelder , Kent Watsen , Andy Bierman , Robert Wilton , Netconf , NetMod WG Content-Type: multipart/alternative; boundary=94eb2c06ed9a6d74e80545c6c4dc Archived-At: Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 00:34:51 -0000 --94eb2c06ed9a6d74e80545c6c4dc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 10, 2017 at 3:54 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > I believe that shortening tranistion pain is in the longer term better > than prociding tools that at the end just extend the transition pain. > > That is a good goal, but ending up with a stable and useful solution is more important. The WG decided that an RPC-based solution was preferrred under the assumption that the data model design would not be impacted and existing YANG modules could report intended vs. actual values without any changes. I certainly agree with Kent that real systems can override config values in ways that were not anticipated at module design-time. All the more reason for an RPC-based solution. I am willing to accept the design team output as the architectural model. I liked Phil's approach -- identify all the state transitions and decide which ones need to be exposed in the standard. I don't see how tweaking this mode= l will have any impact on the transition pain of the solution path. Until the basic show-stoppers are solved, the redundant opstate objects are not important. Removing the foo-state objects means they are now invisible wrt/ YANG constraints (must, when, leafref, min/max, etc). IMO this is a show-shopper. YANG can only cross-reference YANG statements. Invisible opstate hiding behind a datastore label seems elegant wrt/ , but it looks like a disaster wrt/ YANG. /js > Andy > > On Tue, Jan 10, 2017 at 07:08:47PM +0000, Kent Watsen wrote: > > I think that there may be a better way here: The data modelers design > the model on the assumption that an operational state datastore will be > present. We can then use a pyang plugin to generate an extra YANG model > that contains the missing state leaves that would be required for the spl= it > config/state trees. E.g. if it finds a config leaf in foo/speed it creat= es > a module that contains foo-state/speed. I've been playing around with > pyang and I don't think that this would be too hard to do. > > > > I generally support this approach as stop-gap solution while the > industry goes thru the transition. However, I recommend a variant whereb= y > the pyang plugin only migrates the config false values (not also the conf= ig > true values). The reason for this is as follows: > > > > Migrating only the config false values is sufficient for matching > existing functionality (read: a must-have requirement); that is, currentl= y > top-level /foo-state is used to support conveying the opstate for > system-generated objects, that have lifetimes independent of config. > > > > Migrating the config true nodes also is possible, but only needed if > wanting to report the opstate value for config true nodes (e.g., hostname= ), > but this would be above and beyond what is possible today (read: a > nice-to-have requirement), and hence I=E2=80=99d rather steer folks towar= ds the new > approach rather than double-down on the approach we=E2=80=99re trying to = get away > from. > > > > > > > > > This is a real hack. > > > > > > I liked the if-feature approach much better > > > e.g. > > > > > > leaf oper-speed { > > > if-feature "not operational-datastore"; > > > ... > > > } > > > > Is your proposal for the YANG modules to simultaneously define both > opstate-aware and opstate-unaware trees? Wouldn=E2=80=99t that make the = modules > less readable, largely redundant, and ripe for inconsistencies? > > > > > > > > Kent // as a contributor > > > > > > > _______________________________________________ > > 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 > --94eb2c06ed9a6d74e80545c6c4dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 10, 2017 at 3:54 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
I believe that shortening tranistion pain is in the = longer term better
than prociding tools that at the end just extend the transition pain.



That is a good goal, bu= t ending up with a stable and useful solution
is more important.<= /div>

The WG decided that an RPC-based solution was pref= errred under the assumption
that the data model design would not = be impacted and existing YANG modules could
report intended vs. a= ctual values without any changes.

I certainly agre= e with Kent that real systems can override config values in ways
= that were not anticipated at module design-time. =C2=A0 All the more reason= for
an RPC-based solution.

I am willing= to accept the design team output as the architectural model.
I l= iked Phil's approach -- identify all the state transitions and decide w= hich
ones need to be exposed in the standard. I don't see how= tweaking this model
will have any impact on the transition pain = of the solution path.

Until the basic show-stopper= s are solved, the redundant opstate objects are not important.
Re= moving the foo-state objects means they are now invisible wrt/ YANG constra= ints
(must, when, leafref, min/max, etc).=C2=A0 IMO this is a sho= w-shopper.=C2=A0 YANG can only cross-reference
YANG statements.= =C2=A0 Invisible opstate hiding behind a datastore label seems elegant
wrt/ <get>, but it looks like a disaster wrt/ YANG.
<= br>

/js


Andy
=C2= =A0

On Tue, Jan 10, 2017 at 07:08:47PM +0000, Kent Watsen wrote:
> I think that there may be a better way here:=C2=A0 The data modelers d= esign the model on the assumption that an operational state datastore will = be present.=C2=A0 We can then use a pyang plugin to generate an extra YANG = model that contains the missing state leaves that would be required for the= split config/state trees.=C2=A0 E.g. if it finds a config leaf in foo/spee= d it creates a module that contains foo-state/speed.=C2=A0 I've been pl= aying around with pyang and I don't think that this would be too hard t= o do.
>
> I generally support this approach as stop-gap solution while the indus= try goes thru the transition.=C2=A0 However, I recommend a variant whereby = the pyang plugin only migrates the config false values (not also the config= true values).=C2=A0 The reason for this is as follows:
>
> Migrating only the config false values is sufficient for matching exis= ting functionality (read: a must-have requirement); that is, currently top-= level /foo-state is used to support conveying the opstate for system-genera= ted objects, that have lifetimes independent of config.
>
> Migrating the config true nodes also is possible, but only needed if w= anting to report the opstate value for config true nodes (e.g., hostname), = but this would be above and beyond what is possible today (read: a nice-to-= have requirement), and hence I=E2=80=99d rather steer folks towards the new= approach rather than double-down on the approach we=E2=80=99re trying to g= et away from.
>
>
>
> > This is a real hack.
> >
> > I liked the if-feature approach much better
> > e.g.
> >
> >=C2=A0 =C2=A0leaf oper-speed {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0if-feature "not operational-datast= ore";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0...
> >=C2=A0 =C2=A0}
>
> Is your proposal for the YANG modules to simultaneously define both op= state-aware and opstate-unaware trees?=C2=A0 Wouldn=E2=80=99t that make the= modules less readable, largely redundant, and ripe for inconsistencies? >
>
>
> Kent=C2=A0 // as a contributor
>
>

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


--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--94eb2c06ed9a6d74e80545c6c4dc-- From nobody Tue Jan 10 16:53:41 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DECCC12949B; Tue, 10 Jan 2017 16:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id if6PUgnyhQOr; Tue, 10 Jan 2017 16:53:35 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0092.outbound.protection.outlook.com [104.47.33.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE303129454; Tue, 10 Jan 2017 16:53:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/BRfLNYnPaNYvRIhuiubFEO3Jch3/bqDwIhuM1/Mqro=; b=YGHMhf0eH1kvE2zCUQAP72KqO863uNriebXj6hb0KZRsL2qTLXEs7SuAatRO9tpE6u+55iOlDQ3S0CD2AX4fQUCxIO6dFTQMXJSfhZgDMo5OEbd1ZbKDN8m63/ONxdOxIj6QTNFRrLbSAhpyqMKc8b7x7mArXtASdvjSk7oucxE= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.3; Wed, 11 Jan 2017 00:53:33 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0829.017; Wed, 11 Jan 2017 00:53:32 +0000 From: Kent Watsen To: Andy Bierman , Juergen Schoenwaelder , Robert Wilton , Netconf , NetMod WG Thread-Topic: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits Thread-Index: AQHSa5zb9rU+yryOKESiKoFr4nGJlaEybceA//+xcAA= Date: Wed, 11 Jan 2017 00:53:32 +0000 Message-ID: References: <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> <20170110161643.GE17035@elstar.local> <8f0b1abe-b00e-95d1-f62f-7bc99d414bc6@cisco.com> <0f607346-cb4e-1e10-9956-956cb24dc49e@cisco.com> <0A89256A-35FA-4FC3-95FF-0C88A9B5F4EC@juniper.net> <20170110235411.GA18000@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: 4dc899f5-f5e7-45b3-81d2-08d439bc4455 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1441; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:sXDeIH1cH/LJw98HON8rQIghO341E678r0svg8gihuQqYRqYTOBy8KmK/ZP4yXYSwiiqnOcae7cioq9BDo/nVIw2Vi1zfbEClWauUZlV42TPRGvv76r3APKdz9MtumTQqSTuyoOyKjt3tph9wRMYQpD9rAhLnkzt9o+G/TxyUdhfwfhw66YbQQvn5WbSXk083Di+LuCflgNBaNZF5ndnHwcgaswAwIeU982IvUmamqFO9WbJ9kXKvmFxNGMoaXOGRg5UxEQx3okL7phpEfBBeCAqDSmPACqwy9uZKrVO62XIzTk4aPayYf0YreqccGwf4ZdrZ5KlfgfJ7qQOG9moNDOkVpKnA5tGek3iEDp/X3nvs+9YKnLl0G5l1JHbyV/U7WFVsQxgsieKg6okH+CedtdKx1PQMeFGqgFBjzyRYApoP/jga0+COSeoaPsDvDHKpmVZwzOGPAsFA6n3J0IXJA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 01842C458A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39860400002)(39850400002)(39410400002)(199003)(189002)(4001350100001)(6506006)(77096006)(6486002)(122556002)(189998001)(2900100001)(99286003)(6306002)(54896002)(6512007)(83506001)(97736004)(3660700001)(82746002)(92566002)(2906002)(5001770100001)(25786008)(83716003)(86362001)(229853002)(6436002)(3280700002)(38730400001)(54356999)(50986999)(101416001)(7736002)(76176999)(2950100002)(105586002)(106356001)(106116001)(9326002)(81156014)(107886002)(102836003)(93886004)(8676002)(36756003)(66066001)(3846002)(33656002)(68736007)(6116002)(81166006)(8936002)(5660300001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_E3A712FFE21741A3997A67117F5EB9FCjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2017 00:53:32.8531 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 00:53:37 -0000 --_000_E3A712FFE21741A3997A67117F5EB9FCjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KPiBVbnRpbCB0aGUgYmFzaWMgc2hvdy1zdG9wcGVycyBhcmUgc29sdmVkLCB0 aGUgcmVkdW5kYW50IG9wc3RhdGUgb2JqZWN0cyBhcmUgbm90IGltcG9ydGFudC4NCj4gUmVtb3Zp bmcgdGhlIGZvby1zdGF0ZSBvYmplY3RzIG1lYW5zIHRoZXkgYXJlIG5vdyBpbnZpc2libGUgd3J0 LyBZQU5HIGNvbnN0cmFpbnRzDQo+IChtdXN0LCB3aGVuLCBsZWFmcmVmLCBtaW4vbWF4LCBldGMp LiAgSU1PIHRoaXMgaXMgYSBzaG93LXNob3BwZXIuICBZQU5HIGNhbiBvbmx5IGNyb3NzLXJlZmVy ZW5jZQ0KPiBZQU5HIHN0YXRlbWVudHMuICBJbnZpc2libGUgb3BzdGF0ZSBoaWRpbmcgYmVoaW5k IGEgZGF0YXN0b3JlIGxhYmVsIHNlZW1zIGVsZWdhbnQNCj4gd3J0LyA8Z2V0PiwgYnV0IGl0IGxv b2tzIGxpa2UgYSBkaXNhc3RlciB3cnQvIFlBTkcuDQoNCk5vdGhpbmcgaGFzIGJlZW4gcmVtb3Zl ZC4gIEFsbCB0aGUgY29uZmlnIGZhbHNlIG5vZGVzIGFyZSBzdGlsbCBhdmFpbGFibGUsIGJ1dCBu b3cgdGhleeKAmXJlIG5vIGxvbmdlciBzZXBhcmF0ZWQgaW50byBhIHRvcC1sZXZlbCAvZm9vLXN0 YXRlIHRyZWUgZm9yIHRoZSBzb2xlIHB1cnBvc2Ugb2YgYmVpbmcgYWJsZSB0byByZXBvcnQgb3Bz dGF0ZSBmb3Igc3lzdGVtLWdlbmVyYXRlZCBvYmplY3RzLiAgTGlrZXdpc2UsIGFsbCBZQU5HIGNv bnN0cmFpbnRzIGNvbnRpbnVlIHRvIHdvcmssIGJ1dCByYXRoZXIgdGhhbiByZWZlcmVuY2Ugbm9k ZXMgaW4gL2Zvby1zdGF0ZSwgdGhleeKAmWxsIG5vdyByZWZlcmVuY2Ugbm9kZXMgaW4gL2Zvby4g ICBEb2VzIHRoaXMgbWFrZSBzZW5zZT8gIERvIHlvdSBzdGlsbCBoYXZlIGFuIGlzc3VlPw0KDQoN CktlbnQgLy8gYXMgYSBjb250cmlidXRvcg0KDQoNCg== --_000_E3A712FFE21741A3997A67117F5EB9FCjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJy aTsNCglmb250LXZhcmlhbnQ6bm9ybWFsICFpbXBvcnRhbnQ7DQoJY29sb3I6d2luZG93dGV4dDsN Cgl0ZXh0LXRyYW5zZm9ybTpub25lOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7DQoJdmVy dGljYWwtYWxpZ246YmFzZWxpbmU7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8 Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5IaSBBbmR5LDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZndDsgVW50aWwgdGhlIGJhc2ljIHNob3ctc3RvcHBlcnMgYXJlIHNvbHZlZCwgdGhlIHJlZHVu ZGFudCBvcHN0YXRlIG9iamVjdHMgYXJlIG5vdCBpbXBvcnRhbnQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IFJlbW92aW5nIHRoZSBmb28t c3RhdGUgb2JqZWN0cyBtZWFucyB0aGV5IGFyZSBub3cgaW52aXNpYmxlIHdydC8gWUFORyBjb25z dHJhaW50czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jmd0OyAobXVzdCwgd2hlbiwgbGVhZnJlZiwgbWluL21heCwgZXRjKS4mbmJzcDsgSU1PIHRo aXMgaXMgYSBzaG93LXNob3BwZXIuJm5ic3A7IFlBTkcgY2FuIG9ubHkgY3Jvc3MtcmVmZXJlbmNl PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 IFlBTkcgc3RhdGVtZW50cy4mbmJzcDsgSW52aXNpYmxlIG9wc3RhdGUgaGlkaW5nIGJlaGluZCBh IGRhdGFzdG9yZSBsYWJlbCBzZWVtcyBlbGVnYW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IHdydC8gJmx0O2dldCZndDssIGJ1dCBpdCBs b29rcyBsaWtlIGEgZGlzYXN0ZXIgd3J0LyBZQU5HLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90aGluZyBoYXMgYmVlbiByZW1vdmVkLiZu YnNwOyBBbGwgdGhlIGNvbmZpZyBmYWxzZSBub2RlcyBhcmUgc3RpbGwgYXZhaWxhYmxlLCBidXQg bm93IHRoZXnigJlyZSBubyBsb25nZXIgc2VwYXJhdGVkIGludG8gYSB0b3AtbGV2ZWwgL2Zvby1z dGF0ZSB0cmVlIGZvciB0aGUgc29sZSBwdXJwb3NlIG9mIGJlaW5nIGFibGUgdG8gcmVwb3J0IG9w c3RhdGUgZm9yIHN5c3RlbS1nZW5lcmF0ZWQgb2JqZWN0cy4mbmJzcDsgTGlrZXdpc2UsDQogYWxs IFlBTkcgY29uc3RyYWludHMgY29udGludWUgdG8gd29yaywgYnV0IHJhdGhlciB0aGFuIHJlZmVy ZW5jZSBub2RlcyBpbiAvZm9vLXN0YXRlLCB0aGV54oCZbGwgbm93IHJlZmVyZW5jZSBub2RlcyBp biAvZm9vLiZuYnNwOyZuYnNwOyBEb2VzIHRoaXMgbWFrZSBzZW5zZT8mbmJzcDsgRG8geW91IHN0 aWxsIGhhdmUgYW4gaXNzdWU/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2VudCAvLyBhcyBhIGNvbnRyaWJ1dG9yPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E3A712FFE21741A3997A67117F5EB9FCjunipernet_-- From nobody Tue Jan 10 16:57:45 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F03129640 for ; Tue, 10 Jan 2017 16:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpLw_vHVDVrW for ; Tue, 10 Jan 2017 16:57:40 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25871129616 for ; Tue, 10 Jan 2017 16:57:40 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id u25so577520486qki.2 for ; Tue, 10 Jan 2017 16:57:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZDiWtuVO799VaJvU40YqGPPRGDZWFrnqvoORxwETquM=; b=mNfwF048K2Iwxx8Dm0QPWs/P9aTWJadbsEKG39bQ/Bgakgsyn4gbHsTZRm+/+0ua1B OOqHkb6Hdyhl3EiPjIPOrESFhid20Sy+CMsAs229Ponu5rqKfDpaPp7N0HYXEl6BR09d AXuyhEQHl005cFlrF8ppm8BlR3oDq9nabrW8eTeRr00hqdL7P179OwJnJ+6wF2DAsjPH VieYHBM1RNH2CS1K+nB1ej2A32aEegI2RUpHN6A1EoctC7Untg4TaG2WFjiqqFmb2ML6 ORKSDoSgBKGzH9kjiBn2ghmB9TdWnhAtRguWtDpxDLjyl56wqg11cGesx3xKxIP193Fh bBvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZDiWtuVO799VaJvU40YqGPPRGDZWFrnqvoORxwETquM=; b=n4ofN6pHzPSQA5YXvT2a9TRuazlg8cW+R2psgOePQDnXMBW2aKEK6EB7BvaXbRAAKn Lqt9gxAmi6lziXSJnvThrRetOQdKfrt8gC2v8ZlHIu9TOflNQgfSIQDkeaXZLN2UrAL5 yjn2C75Nh3EkwpYkDCvWlrRRfTOFfME1ya1p2YSykuZsx6PJKK7yDWu+xGl3JwV0wL3K ycDdpk2PV8LUswF6KSp5hsQyq5BYIGrGF6VDPAltVVwEp9tS17DFKD02SamUWLQBVdIR 2+8dznYN/haUQCzbmthz8RvTb27epNUH0JpIygglYlbY6qO0Bh0ODkjNLHPP38cWMRpx 3fXw== X-Gm-Message-State: AIkVDXJwG7btEyyQ4B+uSxRa54jCL2e1hHyivhuAOyTXXUD9VrRlDFOttvlUZ4AkLplhOjA3ojuHw1fvog3DEQ== X-Received: by 10.55.135.197 with SMTP id j188mr5658348qkd.71.1484096259327; Tue, 10 Jan 2017 16:57:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Tue, 10 Jan 2017 16:57:38 -0800 (PST) In-Reply-To: References: <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> <20170110161643.GE17035@elstar.local> <8f0b1abe-b00e-95d1-f62f-7bc99d414bc6@cisco.com> <0f607346-cb4e-1e10-9956-956cb24dc49e@cisco.com> <0A89256A-35FA-4FC3-95FF-0C88A9B5F4EC@juniper.net> <20170110235411.GA18000@elstar.local> From: Andy Bierman Date: Tue, 10 Jan 2017 16:57:38 -0800 Message-ID: To: Kent Watsen Content-Type: multipart/alternative; boundary=94eb2c0777e659b8050545c716ba Archived-At: Cc: Netconf , NetMod WG Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 00:57:42 -0000 --94eb2c0777e659b8050545c716ba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 10, 2017 at 4:53 PM, Kent Watsen wrote: > Hi Andy, > > > > > Until the basic show-stoppers are solved, the redundant opstate objects > are not important. > > > Removing the foo-state objects means they are now invisible wrt/ YANG > constraints > > > (must, when, leafref, min/max, etc). IMO this is a show-shopper. YANG > can only cross-reference > > > YANG statements. Invisible opstate hiding behind a datastore label > seems elegant > > > wrt/ , but it looks like a disaster wrt/ YANG. > > > > Nothing has been removed. All the config false nodes are still available= , > but now they=E2=80=99re no longer separated into a top-level /foo-state t= ree for > the sole purpose of being able to report opstate for system-generated > objects. Likewise, all YANG constraints continue to work, but rather tha= n > reference nodes in /foo-state, they=E2=80=99ll now reference nodes in /fo= o. Does > this make sense? Do you still have an issue? > > > > > This does not work. There are no config=3Dfalse nodes if they are overlaid onto the config=3Dtrue nodes. There is no way to say in the YANG XPath that you mean the configured value of /foo vs. the operational value of /foo. There is just 1 leaf that YANG says has 0 or 1 instance (and therefore 0 or 1 value). > Kent // as a contributor > > > > > Andy --94eb2c0777e659b8050545c716ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

--94eb2c0777e659b8050545c716ba-- From nobody Wed Jan 11 01:22:17 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057E7129AC6; Wed, 11 Jan 2017 01:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWon6eHHxRTu; Wed, 11 Jan 2017 01:22:14 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 29774129ACB; Wed, 11 Jan 2017 01:22:11 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 65C031AE02BA; Wed, 11 Jan 2017 10:22:09 +0100 (CET) Date: Wed, 11 Jan 2017 10:22:09 +0100 (CET) Message-Id: <20170111.102209.310040071380723970.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <6425C57C-C3DF-4099-AE77-4521B58B8D69@juniper.net> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 09:22:16 -0000 QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiBPbiBUdWUsIEphbiAx MCwgMjAxNyBhdCAxOjIwIFBNLCBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4gd3Jv dGU6DQo+IA0KPiA+DQo+ID4gPiBJIHRoaW5rIGl0IGlzIGJldHRlciB0byBoYXZlIGEgaHVtYW4g ZGVjaWRlIHdoYXQgaXMgaW4gdGhlIG1vZHVsZQ0KPiA+ID4gaW5zdGVhZCBvZiByZWx5aW5nIG9u IGEgcHlhbmcgcGx1Z2luIHRvIGdlbmVyYXRlIHNvbWUgYWRkaXRpb25hbCBtb2R1bGUNCj4gPiA+ IHRoYXQgZm9sbG93cyBzb21lIHNpbXBsaXN0aWMgcGF0dGVybi4NCj4gPg0KPiA+IEl0IG1heSBi ZSBzaW1wbGUsIGJ1dCBJ4oCZbSB0aGlua2luZyB0aGF04oCZcyBvbmx5IGJlY2F1c2UgaXTigJlz IG5vdCB0cmlja3kgIDspDQo+ID4NCj4gPg0KPiBUaGUgY2xpZW50IGFuZCBzZXJ2ZXIgZGV2ZWxv cGVycyBzdGlsbCBuZWVkIHRvIGtub3cgYWJvdXQgdGhpcw0KPiBhdXRvLWdlbmVyYXRlZCBtb2R1 bGUNCj4gYW5kIGltcGxlbWVudCBpdC4gIE9wZXJhdG9ycyBtaWdodCBoYXZlIHRvIGtub3cgYWJv dXQgaXQgdG8gdXNlIGl0Lg0KDQpFeGFjdGx5LiAgSSBhZ3JlZSB0aGF0IHRoaXMgaXMgYSByZWFs IGhhY2suICBJbXBsZW1lbnRhdGlvbnMgY2FuIHVzZQ0Kd2hhdGV2ZXIgdHJhbnNmb3JtYXRpb24g dHJpY2tzIHRoZXkgd2FudCBpbiBvcmRlciB0byBjb21wbHkgd2l0aA0KZGlmZmVyZW50IHN0YW5k YXJkcywgYnV0IHRoZSBzdGFuZGFyZCBtb2R1bGVzIHNob3VsZCBiZSB2ZXJ5IGNsZWFyLg0KDQoN Ci9tYXJ0aW4NCg== From nobody Wed Jan 11 01:27:34 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524D4129ACF; Wed, 11 Jan 2017 01:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54B4hC5-4YHK; Wed, 11 Jan 2017 01:27:31 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 02AAE129ACE; Wed, 11 Jan 2017 01:27:30 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id D34AB1AE02BA; Wed, 11 Jan 2017 10:27:29 +0100 (CET) Date: Wed, 11 Jan 2017 10:27:29 +0100 (CET) Message-Id: <20170111.102729.1180268284224378559.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 09:27:32 -0000 QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiBPbiBUdWUsIEphbiAx MCwgMjAxNyBhdCA0OjUzIFBNLCBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4gd3Jv dGU6DQo+IA0KPiA+IEhpIEFuZHksDQo+ID4NCj4gPg0KPiA+DQo+ID4gPiBVbnRpbCB0aGUgYmFz aWMgc2hvdy1zdG9wcGVycyBhcmUgc29sdmVkLCB0aGUgcmVkdW5kYW50IG9wc3RhdGUgb2JqZWN0 cw0KPiA+IGFyZSBub3QgaW1wb3J0YW50Lg0KPiA+DQo+ID4gPiBSZW1vdmluZyB0aGUgZm9vLXN0 YXRlIG9iamVjdHMgbWVhbnMgdGhleSBhcmUgbm93IGludmlzaWJsZSB3cnQvIFlBTkcNCj4gPiBj b25zdHJhaW50cw0KPiA+DQo+ID4gPiAobXVzdCwgd2hlbiwgbGVhZnJlZiwgbWluL21heCwgZXRj KS4gIElNTyB0aGlzIGlzIGEgc2hvdy1zaG9wcGVyLiAgWUFORw0KPiA+IGNhbiBvbmx5IGNyb3Nz LXJlZmVyZW5jZQ0KPiA+DQo+ID4gPiBZQU5HIHN0YXRlbWVudHMuICBJbnZpc2libGUgb3BzdGF0 ZSBoaWRpbmcgYmVoaW5kIGEgZGF0YXN0b3JlIGxhYmVsDQo+ID4gc2VlbXMgZWxlZ2FudA0KPiA+ DQo+ID4gPiB3cnQvIDxnZXQ+LCBidXQgaXQgbG9va3MgbGlrZSBhIGRpc2FzdGVyIHdydC8gWUFO Ry4NCj4gPg0KPiA+DQo+ID4NCj4gPiBOb3RoaW5nIGhhcyBiZWVuIHJlbW92ZWQuICBBbGwgdGhl IGNvbmZpZyBmYWxzZSBub2RlcyBhcmUgc3RpbGwgYXZhaWxhYmxlLA0KPiA+IGJ1dCBub3cgdGhl eeKAmXJlIG5vIGxvbmdlciBzZXBhcmF0ZWQgaW50byBhIHRvcC1sZXZlbCAvZm9vLXN0YXRlIHRy ZWUgZm9yDQo+ID4gdGhlIHNvbGUgcHVycG9zZSBvZiBiZWluZyBhYmxlIHRvIHJlcG9ydCBvcHN0 YXRlIGZvciBzeXN0ZW0tZ2VuZXJhdGVkDQo+ID4gb2JqZWN0cy4gIExpa2V3aXNlLCBhbGwgWUFO RyBjb25zdHJhaW50cyBjb250aW51ZSB0byB3b3JrLCBidXQgcmF0aGVyIHRoYW4NCj4gPiByZWZl cmVuY2Ugbm9kZXMgaW4gL2Zvby1zdGF0ZSwgdGhleeKAmWxsIG5vdyByZWZlcmVuY2Ugbm9kZXMg aW4gL2Zvby4gICBEb2VzDQo+ID4gdGhpcyBtYWtlIHNlbnNlPyAgRG8geW91IHN0aWxsIGhhdmUg YW4gaXNzdWU/DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiANCj4gVGhpcyBkb2VzIG5vdCB3 b3JrLiBUaGVyZSBhcmUgbm8gY29uZmlnPWZhbHNlIG5vZGVzIGlmIHRoZXkgYXJlIG92ZXJsYWlk DQo+IG9udG8gdGhlIGNvbmZpZz10cnVlIG5vZGVzLg0KPiBUaGVyZSBpcyBubyB3YXkgdG8gc2F5 IGluIHRoZSBZQU5HIFhQYXRoIHRoYXQgeW91IG1lYW4gdGhlIGNvbmZpZ3VyZWQgdmFsdWUNCj4g b2YgL2Zvbw0KPiB2cy4gdGhlIG9wZXJhdGlvbmFsIHZhbHVlIG9mIC9mb28uICBUaGVyZSBpcyBq dXN0IDEgbGVhZiB0aGF0IFlBTkcgc2F5cyBoYXMNCj4gMCBvciAxIGluc3RhbmNlDQo+IChhbmQg dGhlcmVmb3JlIDAgb3IgMSB2YWx1ZSkuDQoNClRoaXMgaXMgY29ycmVjdC4gIEJ1dCBub3RlIHRo YXQgWUFORyBkb2Vzbid0IGFsbG93IGNvbmZpZyB0cnVlIG5vZGVzDQp0byByZWZlciB0byBjb25m aWcgZmFsc2Ugbm9kZXMgYW55d2F5LCBzbyB0aGlzIGlzIGxlc3Mgb2YgYW4gaXNzdWUuDQpBbHNv IG5vdGUgdGhhdCBkcmFmdC1pZXRmLW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9yZXMtMDAgcHJvcG9z ZXMgdGhhdA0Kc2VtYW50aWMgY29uc3RyYWludHMgZG9uJ3QgYXBwbHkgdG8gdGhlIG9wZXJhdGlv bmFsLXN0YXRlIGRhdGFzdG9yZQ0KKHNlZSBzZWN0aW9uIDUuMykuDQoNCkJUVywgaXQgaGFzIGJl ZW4gc3VnZ2VzdGVkIGJlZm9yZSB0byBhZGQgYSBmdW5jdGlvbiBzaW1pbGFyIHRvIHRoZQ0KWFNM VCAxLjAgZnVuY3Rpb24gImRvY3VtZW50IiwgdGhhdCBjb3VsZCBiZSB1c2VkIHRvIHJlZmVyIHRv IG5vZGVzIGluDQpvdGhlciBkb2N1bWVudHMgKG9yIHJhdGhlciBvdGhlciBkYXRhc3RvcmVzIGlu IG91ciBjYXNlKS4NCg0KDQovbWFydGluDQo= From nobody Wed Jan 11 01:36:18 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C084129AD9; Wed, 11 Jan 2017 01:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdatYyczuZ2t; Wed, 11 Jan 2017 01:36:15 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D6AAA129AD5; Wed, 11 Jan 2017 01:36:14 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 17E2B1AE02BA; Wed, 11 Jan 2017 10:36:14 +0100 (CET) Date: Wed, 11 Jan 2017 10:36:13 +0100 (CET) Message-Id: <20170111.103613.452189352000719595.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <2D981A38-CBE9-4F2D-A7A8-A366DE3A95CB@nic.cz> References: <3DFB70DC-010A-4CD0-BBBB-1478AC814923@nic.cz> <20170110083942.GC16255@elstar.local> <2D981A38-CBE9-4F2D-A7A8-A366DE3A95CB@nic.cz> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 09:36:16 -0000 Ladislav Lhotka wrote: > > > On 10 Jan 2017, at 09:39, Juergen Schoenwaelder > > wrote: > > > > On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka wrote: > >> > >> I think we need protocol and YANG specs that are not tied to any > >> particular model and that are thus capable of matching unforeseen > >> real-world implementations. This is no sci-fi, HTTP and XML schema > >> languages work this way. > >> > > > > I disagree that HTTP and XML schema languages do the same thing. Our > > goal is interoperable configuration of network devices; the notion of > > Even now, a client that's programmed to write straight to running > isn't interoperable with a server that has candidate and read-only > running. A RESTCONF server that supports only JSON isn't interoperable > with a client that supports only XML. > > We are not in a situation that every pair of a randomly chosen server > and client need to be interoperable. It's IMO perfectly fine if IoT > and ISP networks use different clients. Yet, both can still use the > same RESTCONF, same YANG, and even same YANG modules. The fact is that that data models are written with a certain set of protocol features and datastores in mind (the "meta-model"). Some examples: If we had an "operational-state" datastore like the one proposed, we would not see the /foo vs /foo-state split. If SNMP would have had a CREATE operation, MIBs would not have used RowStatus. If NETCONF didn't have a way to create instances, we would have seen something similar in YANG models. If NETCONF had a way to add comments to any node in a datastore, we wouldn't have "leaf description" sprinkled throughout the models. If NETCONF didn't have a generic way to filter retreived data, we'd see lots of specific get-* rpcs in YANG models. /martin From nobody Wed Jan 11 03:05:12 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8AF129B8B; Wed, 11 Jan 2017 03:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P76Gen44L5wr; Wed, 11 Jan 2017 03:05:00 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A51EA129B99; Wed, 11 Jan 2017 03:05:00 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:2914:3b97:4da6:fc1e] (unknown [IPv6:2a01:5e0:29:fffe:2914:3b97:4da6:fc1e]) by mail.nic.cz (Postfix) with ESMTPSA id 42BF660FDA; Wed, 11 Jan 2017 12:04:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484132698; bh=Qa9+RKxakDRa43Y7JIpL4H2V6l169PnKmeL2dPgObwU=; h=From:Date:To; b=lhC6robjq2IEnkLf8kb41wVFlvjNPrbDaYs96B7+dD4Sj9PsW31oEjhkvzUNcPnJa xtf8FkpVx9lmgDX1f1fONQ+0zx3lkWtf2gC/03Sk8Lz1A/3dHU4Qo2P6Dibo1fXID8 vqG6tsBPjwc2kaN7c1shdKCMLnxxfeCmMSkigFiA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170111.103613.452189352000719595.mbj@tail-f.com> Date: Wed, 11 Jan 2017 12:05:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3DFB70DC-010A-4CD0-BBBB-1478AC814923@nic.cz> <20170110083942.GC16255@elstar.local> <2D981A38-CBE9-4F2D-A7A8-A366DE3A95CB@nic.cz> <20170111.103613.452189352000719595.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf , netmod@ietf.org Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 11:05:08 -0000 > On 11 Jan 2017, at 10:36, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 10 Jan 2017, at 09:39, Juergen Schoenwaelder >>> wrote: >>>=20 >>> On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka wrote: >>>>=20 >>>> I think we need protocol and YANG specs that are not tied to any >>>> particular model and that are thus capable of matching unforeseen >>>> real-world implementations. This is no sci-fi, HTTP and XML schema >>>> languages work this way. >>>>=20 >>>=20 >>> I disagree that HTTP and XML schema languages do the same thing. Our >>> goal is interoperable configuration of network devices; the notion = of >>=20 >> Even now, a client that's programmed to write straight to running >> isn't interoperable with a server that has candidate and read-only >> running. A RESTCONF server that supports only JSON isn't = interoperable >> with a client that supports only XML. >>=20 >> We are not in a situation that every pair of a randomly chosen server >> and client need to be interoperable. It's IMO perfectly fine if IoT >> and ISP networks use different clients. Yet, both can still use the >> same RESTCONF, same YANG, and even same YANG modules. >=20 > The fact is that that data models are written with a certain set of > protocol features and datastores in mind (the "meta-model"). Some > examples: >=20 > If we had an "operational-state" datastore like the one proposed, we > would not see the /foo vs /foo-state split. Yes, but I assume this will go away anyway. However, we can still have = YANG modules (and complete schemas) designed for the operational = datastore. The important property of the "meta-model" so far has been = that config and state data are separate, and this is not going to = change. >=20 > If SNMP would have had a CREATE operation, MIBs would not have used > RowStatus. If NETCONF didn't have a way to create instances, we would > have seen something similar in YANG models. >=20 > If NETCONF had a way to add comments to any node in a datastore, we > wouldn't have "leaf description" sprinkled throughout the models. >=20 > If NETCONF didn't have a generic way to filter retreived data, we'd > see lots of specific get-* rpcs in YANG models. Maybe, but are the last three points relevant to this discussion? Lada >=20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jan 11 03:16:25 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22CFD129D83; Wed, 11 Jan 2017 03:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gomculRQaqA; Wed, 11 Jan 2017 03:16:17 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A2893129B81; Wed, 11 Jan 2017 03:16:17 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 14A491AE02BA; Wed, 11 Jan 2017 12:16:16 +0100 (CET) Date: Wed, 11 Jan 2017 12:16:15 +0100 (CET) Message-Id: <20170111.121615.1087515400647852978.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <2D981A38-CBE9-4F2D-A7A8-A366DE3A95CB@nic.cz> <20170111.103613.452189352000719595.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 11:16:19 -0000 Ladislav Lhotka wrote: > > > On 11 Jan 2017, at 10:36, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> > >>> On 10 Jan 2017, at 09:39, Juergen Schoenwaelder > >>> wrote: > >>> > >>> On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka wrote: > >>>> > >>>> I think we need protocol and YANG specs that are not tied to any > >>>> particular model and that are thus capable of matching unforeseen > >>>> real-world implementations. This is no sci-fi, HTTP and XML schema > >>>> languages work this way. > >>>> > >>> > >>> I disagree that HTTP and XML schema languages do the same thing. Our > >>> goal is interoperable configuration of network devices; the notion of > >> > >> Even now, a client that's programmed to write straight to running > >> isn't interoperable with a server that has candidate and read-only > >> running. A RESTCONF server that supports only JSON isn't interoperable > >> with a client that supports only XML. > >> > >> We are not in a situation that every pair of a randomly chosen server > >> and client need to be interoperable. It's IMO perfectly fine if IoT > >> and ISP networks use different clients. Yet, both can still use the > >> same RESTCONF, same YANG, and even same YANG modules. > > > > The fact is that that data models are written with a certain set of > > protocol features and datastores in mind (the "meta-model"). Some > > examples: > > > > If we had an "operational-state" datastore like the one proposed, we > > would not see the /foo vs /foo-state split. > > Yes, but I assume this will go away anyway. However, we can still have > YANG modules (and complete schemas) designed for the operational > datastore. The important property of the "meta-model" so far has been > that config and state data are separate, and this is not going to > change. > > > > > If SNMP would have had a CREATE operation, MIBs would not have used > > RowStatus. If NETCONF didn't have a way to create instances, we would > > have seen something similar in YANG models. > > > > If NETCONF had a way to add comments to any node in a datastore, we > > wouldn't have "leaf description" sprinkled throughout the models. > > > > If NETCONF didn't have a generic way to filter retreived data, we'd > > see lots of specific get-* rpcs in YANG models. > > Maybe, but are the last three points relevant to this discussion? The point is that data models are designed with some meta-model in mind. The meta-model includes (some) datastores. You wrote: I believe both the protocols and YANG can work with any set of datastores [...] And I don't think that this is true (practically). For example, a YANG module that is designed with the new operational state datastore in mind will be of limited use in a legacy NETCONF server. /martin From nobody Wed Jan 11 03:43:49 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BEB129DF4; Wed, 11 Jan 2017 03:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4Hdnjkl78Nn; Wed, 11 Jan 2017 03:43:43 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99FA5129DF2; Wed, 11 Jan 2017 03:43:41 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:2914:3b97:4da6:fc1e] (unknown [IPv6:2a01:5e0:29:fffe:2914:3b97:4da6:fc1e]) by mail.nic.cz (Postfix) with ESMTPSA id E0A9060ACD; Wed, 11 Jan 2017 12:43:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484135019; bh=KSaqK619JkpNV3lab24bR/PU/aSiOh584iVwXl2VCVw=; h=From:Date:To; b=rIuLf3a+MKASi+cStceNDu9Hjs6QvjHbF1hQdkuDCtYJryNnugQ4PPxOeIrW6YDeu /OGK1GpZV3hB0D5rKe9HKE1W7hSyIoSTtMIg/+rhVt56KK7ZosdxEOIIncq99puLXz 4G9oWtFqswsXrW3kwZe2zjA6AwhLcerWoO905pCE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170111.121615.1087515400647852978.mbj@tail-f.com> Date: Wed, 11 Jan 2017 12:43:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2C96B1C8-3D97-41FF-AD91-44432868C5CF@nic.cz> References: <2D981A38-CBE9-4F2D-A7A8-A366DE3A95CB@nic.cz> <20170111.103613.452189352000719595.mbj@tail-f.com> <20170111.121615.1087515400647852978.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf , netmod@ietf.org Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 11:43:45 -0000 > On 11 Jan 2017, at 12:16, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 11 Jan 2017, at 10:36, Martin Bjorklund wrote: >>>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>>> On 10 Jan 2017, at 09:39, Juergen Schoenwaelder >>>>> wrote: >>>>>=20 >>>>> On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka wrote: >>>>>>=20 >>>>>> I think we need protocol and YANG specs that are not tied to any >>>>>> particular model and that are thus capable of matching unforeseen >>>>>> real-world implementations. This is no sci-fi, HTTP and XML = schema >>>>>> languages work this way. >>>>>>=20 >>>>>=20 >>>>> I disagree that HTTP and XML schema languages do the same thing. = Our >>>>> goal is interoperable configuration of network devices; the notion = of >>>>=20 >>>> Even now, a client that's programmed to write straight to running >>>> isn't interoperable with a server that has candidate and read-only >>>> running. A RESTCONF server that supports only JSON isn't = interoperable >>>> with a client that supports only XML. >>>>=20 >>>> We are not in a situation that every pair of a randomly chosen = server >>>> and client need to be interoperable. It's IMO perfectly fine if IoT >>>> and ISP networks use different clients. Yet, both can still use the >>>> same RESTCONF, same YANG, and even same YANG modules. >>>=20 >>> The fact is that that data models are written with a certain set of >>> protocol features and datastores in mind (the "meta-model"). Some >>> examples: >>>=20 >>> If we had an "operational-state" datastore like the one proposed, we >>> would not see the /foo vs /foo-state split. >>=20 >> Yes, but I assume this will go away anyway. However, we can still = have >> YANG modules (and complete schemas) designed for the operational >> datastore. The important property of the "meta-model" so far has been >> that config and state data are separate, and this is not going to >> change. >>=20 >>>=20 >>> If SNMP would have had a CREATE operation, MIBs would not have used >>> RowStatus. If NETCONF didn't have a way to create instances, we = would >>> have seen something similar in YANG models. >>>=20 >>> If NETCONF had a way to add comments to any node in a datastore, we >>> wouldn't have "leaf description" sprinkled throughout the models. >>>=20 >>> If NETCONF didn't have a generic way to filter retreived data, we'd >>> see lots of specific get-* rpcs in YANG models. >>=20 >> Maybe, but are the last three points relevant to this discussion? >=20 > The point is that data models are designed with some meta-model in > mind. The meta-model includes (some) datastores. You wrote: But where and how is this reflected in existing YANG modules (except for = the foo and foo-state split, which is IMO a minor issue)? >=20 > I believe both the protocols and YANG can work with any set of > datastores [...] >=20 > And I don't think that this is true (practically). For example, a > YANG module that is designed with the new operational state datastore > in mind will be of limited use in a legacy NETCONF server. Please explain. My idea what could be done e.g. with ietf-interfaces is = this: 1. Split it into two modules, say ietf-interfaces-config and = ietf-interfaces-state. The former would contain exactly what's now = inside "interfaces", and the latter will augment it with extra state = data that are now under "interfaces-state". 2. The data model for configuration datastores will be defined to = contain only ietf-interfaces-config whereas for operational-state = datastore it will be ietf-interfaces-config *and* ietf-interfaces-state. Am I completely misguided here? If not, then I don't see where the new = modules refer to any particular datastore model. Yes, they do reflect = that there is configuration and state data, but we don't want to get rid = of this distinction, right? Lada >=20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jan 11 04:28:13 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC18129E4D; Wed, 11 Jan 2017 04:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJUe3U81edEv; Wed, 11 Jan 2017 04:28:06 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7E70D129BE8; Wed, 11 Jan 2017 04:28:00 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id BD7BD1AE02BA; Wed, 11 Jan 2017 13:27:59 +0100 (CET) Date: Wed, 11 Jan 2017 13:27:59 +0100 (CET) Message-Id: <20170111.132759.746322711124349871.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <2C96B1C8-3D97-41FF-AD91-44432868C5CF@nic.cz> References: <20170111.121615.1087515400647852978.mbj@tail-f.com> <2C96B1C8-3D97-41FF-AD91-44432868C5CF@nic.cz> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 12:28:08 -0000 Ladislav Lhotka wrote: > > > On 11 Jan 2017, at 12:16, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> > >>> On 11 Jan 2017, at 10:36, Martin Bjorklund wrote: > >>> > >>> Ladislav Lhotka wrote: > >>>> > >>>>> On 10 Jan 2017, at 09:39, Juergen Schoenwaelder > >>>>> wrote: > >>>>> > >>>>> On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka wrote: > >>>>>> > >>>>>> I think we need protocol and YANG specs that are not tied to any > >>>>>> particular model and that are thus capable of matching unforeseen > >>>>>> real-world implementations. This is no sci-fi, HTTP and XML schema > >>>>>> languages work this way. > >>>>>> > >>>>> > >>>>> I disagree that HTTP and XML schema languages do the same thing. Our > >>>>> goal is interoperable configuration of network devices; the notion of > >>>> > >>>> Even now, a client that's programmed to write straight to running > >>>> isn't interoperable with a server that has candidate and read-only > >>>> running. A RESTCONF server that supports only JSON isn't interoperable > >>>> with a client that supports only XML. > >>>> > >>>> We are not in a situation that every pair of a randomly chosen server > >>>> and client need to be interoperable. It's IMO perfectly fine if IoT > >>>> and ISP networks use different clients. Yet, both can still use the > >>>> same RESTCONF, same YANG, and even same YANG modules. > >>> > >>> The fact is that that data models are written with a certain set of > >>> protocol features and datastores in mind (the "meta-model"). Some > >>> examples: > >>> > >>> If we had an "operational-state" datastore like the one proposed, we > >>> would not see the /foo vs /foo-state split. > >> > >> Yes, but I assume this will go away anyway. However, we can still have > >> YANG modules (and complete schemas) designed for the operational > >> datastore. The important property of the "meta-model" so far has been > >> that config and state data are separate, and this is not going to > >> change. > >> > >>> > >>> If SNMP would have had a CREATE operation, MIBs would not have used > >>> RowStatus. If NETCONF didn't have a way to create instances, we would > >>> have seen something similar in YANG models. > >>> > >>> If NETCONF had a way to add comments to any node in a datastore, we > >>> wouldn't have "leaf description" sprinkled throughout the models. > >>> > >>> If NETCONF didn't have a generic way to filter retreived data, we'd > >>> see lots of specific get-* rpcs in YANG models. > >> > >> Maybe, but are the last three points relevant to this discussion? > > > > The point is that data models are designed with some meta-model in > > mind. The meta-model includes (some) datastores. You wrote: > > But where and how is this reflected in existing YANG modules (except > for the foo and foo-state split, which is IMO a minor issue)? I don't this split is a minor issue. For the openconfig group, this is one of the major problems with YANG, leading to their design with duplicate leafs. The reason for adding the operational state datastore in the form we propose in the draft it to be able to get rid of this split. > > I believe both the protocols and YANG can work with any set of > > datastores [...] > > > > And I don't think that this is true (practically). For example, a > > YANG module that is designed with the new operational state datastore > > in mind will be of limited use in a legacy NETCONF server. > > Please explain. If a YANG module is designed with this new architecture in mind, it will have a single top-level tree, which can support pre-configuration and different instances in the config and operational state. If such a module is implemented in a legacy NETCONF server, the only way to get the operational state is to used . But will return the union between running and operational state. The client can't tell if an instance is really present in the operational state, or just in the config. My idea what could be done e.g. with ietf-interfaces > is this: > > 1. Split it into two modules, say ietf-interfaces-config and > ietf-interfaces-state. The former would contain exactly what's now > inside "interfaces", and the latter will augment it with extra state > data that are now under "interfaces-state". > > 2. The data model for configuration datastores will be defined to > contain only ietf-interfaces-config whereas for operational-state > datastore it will be ietf-interfaces-config *and* > ietf-interfaces-state. If we do this for all modules then we haven't gained anything; we still have duplicate definitions. /martin > Am I completely misguided here? If not, then I don't see where the new > modules refer to any particular datastore model. Yes, they do reflect > that there is configuration and state data, but we don't want to get > rid of this distinction, right? > > Lada > > > > > > > > > /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > From nobody Wed Jan 11 04:45:31 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71A1129E71; Wed, 11 Jan 2017 04:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdlrATxI70rK; Wed, 11 Jan 2017 04:45:29 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0A64127077; Wed, 11 Jan 2017 04:45:28 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c] (unknown [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c]) by mail.nic.cz (Postfix) with ESMTPSA id 406F360ABE; Wed, 11 Jan 2017 13:45:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484138727; bh=p9M3pCPC6UgV7XcEt9C+MPRAiODCj9NFb0GMTTLBq/8=; h=From:Date:To; b=bn2iemxWOmrRs3TQ8L6et0ZWfrW7JF8CuMq8+plrcEihd+wG3HR+w5l+c/gO0b1r5 B8LwHeO66+3BzHcMFFWxQOQgFowvaBURVGt27uIMvYxRNDeoXBkm2ElhaxAw8zBy6p e7pPK5uNXNIX/GuLf12fRiBu/x2HTploEQ6OBZZk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170111.132759.746322711124349871.mbj@tail-f.com> Date: Wed, 11 Jan 2017 13:45:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <25050412-8C71-44E7-8865-24320902ED2D@nic.cz> References: <20170111.121615.1087515400647852978.mbj@tail-f.com> <2C96B1C8-3D97-41FF-AD91-44432868C5CF@nic.cz> <20170111.132759.746322711124349871.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf , NetMod WG Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 12:45:31 -0000 > On 11 Jan 2017, at 13:27, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 11 Jan 2017, at 12:16, Martin Bjorklund wrote: >>>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>>> On 11 Jan 2017, at 10:36, Martin Bjorklund wrote: >>>>>=20 >>>>> Ladislav Lhotka wrote: >>>>>>=20 >>>>>>> On 10 Jan 2017, at 09:39, Juergen Schoenwaelder >>>>>>> wrote: >>>>>>>=20 >>>>>>> On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka wrote: >>>>>>>>=20 >>>>>>>> I think we need protocol and YANG specs that are not tied to = any >>>>>>>> particular model and that are thus capable of matching = unforeseen >>>>>>>> real-world implementations. This is no sci-fi, HTTP and XML = schema >>>>>>>> languages work this way. >>>>>>>>=20 >>>>>>>=20 >>>>>>> I disagree that HTTP and XML schema languages do the same thing. = Our >>>>>>> goal is interoperable configuration of network devices; the = notion of >>>>>>=20 >>>>>> Even now, a client that's programmed to write straight to running >>>>>> isn't interoperable with a server that has candidate and = read-only >>>>>> running. A RESTCONF server that supports only JSON isn't = interoperable >>>>>> with a client that supports only XML. >>>>>>=20 >>>>>> We are not in a situation that every pair of a randomly chosen = server >>>>>> and client need to be interoperable. It's IMO perfectly fine if = IoT >>>>>> and ISP networks use different clients. Yet, both can still use = the >>>>>> same RESTCONF, same YANG, and even same YANG modules. >>>>>=20 >>>>> The fact is that that data models are written with a certain set = of >>>>> protocol features and datastores in mind (the "meta-model"). Some >>>>> examples: >>>>>=20 >>>>> If we had an "operational-state" datastore like the one proposed, = we >>>>> would not see the /foo vs /foo-state split. >>>>=20 >>>> Yes, but I assume this will go away anyway. However, we can still = have >>>> YANG modules (and complete schemas) designed for the operational >>>> datastore. The important property of the "meta-model" so far has = been >>>> that config and state data are separate, and this is not going to >>>> change. >>>>=20 >>>>>=20 >>>>> If SNMP would have had a CREATE operation, MIBs would not have = used >>>>> RowStatus. If NETCONF didn't have a way to create instances, we = would >>>>> have seen something similar in YANG models. >>>>>=20 >>>>> If NETCONF had a way to add comments to any node in a datastore, = we >>>>> wouldn't have "leaf description" sprinkled throughout the models. >>>>>=20 >>>>> If NETCONF didn't have a generic way to filter retreived data, = we'd >>>>> see lots of specific get-* rpcs in YANG models. >>>>=20 >>>> Maybe, but are the last three points relevant to this discussion? >>>=20 >>> The point is that data models are designed with some meta-model in >>> mind. The meta-model includes (some) datastores. You wrote: >>=20 >> But where and how is this reflected in existing YANG modules (except >> for the foo and foo-state split, which is IMO a minor issue)? >=20 > I don't this split is a minor issue. For the openconfig group, this > is one of the major problems with YANG, leading to their design with > duplicate leafs. The reason for adding the operational state > datastore in the form we propose in the draft it to be able to get rid > of this split. >=20 >>> I believe both the protocols and YANG can work with any set of >>> datastores [...] >>>=20 >>> And I don't think that this is true (practically). For example, a >>> YANG module that is designed with the new operational state = datastore >>> in mind will be of limited use in a legacy NETCONF server. >>=20 >> Please explain. >=20 > If a YANG module is designed with this new architecture in mind, it > will have a single top-level tree, which can support pre-configuration > and different instances in the config and operational state. >=20 > If such a module is implemented in a legacy NETCONF server, the only > way to get the operational state is to used . But will > return the union between running and operational state. The client > can't tell if an instance is really present in the operational state, > or just in the config. >=20 >=20 > My idea what could be done e.g. with ietf-interfaces >> is this: >>=20 >> 1. Split it into two modules, say ietf-interfaces-config and >> ietf-interfaces-state. The former would contain exactly what's now >> inside "interfaces", and the latter will augment it with extra state >> data that are now under "interfaces-state". >>=20 >> 2. The data model for configuration datastores will be defined to >> contain only ietf-interfaces-config whereas for operational-state >> datastore it will be ietf-interfaces-config *and* >> ietf-interfaces-state. >=20 > If we do this for all modules then we haven't gained anything; we > still have duplicate definitions. Show me a single YANG data node definition that's duplicate in my = concept above. But then maybe I didn't explain it properly. Note also that you slightly misinterpreted my statement that you cited: I believe both the protocols and YANG can work with any set of datastores [...] I didn't say that there cannot be *modules* that are somehow designed = for a particular datastore model - I meant YANG the language.=20 Lada >=20 >=20 > /martin >=20 >=20 >> Am I completely misguided here? If not, then I don't see where the = new >> modules refer to any particular datastore model. Yes, they do reflect >> that there is configuration and state data, but we don't want to get >> rid of this distinction, right? >>=20 >> Lada >>=20 >>>=20 >>>=20 >>>=20 >>> /martin >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jan 11 04:54:03 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAE6129BE7; Wed, 11 Jan 2017 04:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndebAYZecZ5P; Wed, 11 Jan 2017 04:54:00 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 56145129BDC; Wed, 11 Jan 2017 04:54:00 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 285491AE02BA; Wed, 11 Jan 2017 13:53:59 +0100 (CET) Date: Wed, 11 Jan 2017 13:53:59 +0100 (CET) Message-Id: <20170111.135359.1145355019648401300.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <25050412-8C71-44E7-8865-24320902ED2D@nic.cz> References: <2C96B1C8-3D97-41FF-AD91-44432868C5CF@nic.cz> <20170111.132759.746322711124349871.mbj@tail-f.com> <25050412-8C71-44E7-8865-24320902ED2D@nic.cz> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 12:54:02 -0000 Ladislav Lhotka wrote: > > > On 11 Jan 2017, at 13:27, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> > >>> On 11 Jan 2017, at 12:16, Martin Bjorklund wrote: > >>> > >>> Ladislav Lhotka wrote: > >>>> > >>>>> On 11 Jan 2017, at 10:36, Martin Bjorklund wrote: > >>>>> > >>>>> Ladislav Lhotka wrote: > >>>>>> > >>>>>>> On 10 Jan 2017, at 09:39, Juergen Schoenwaelder > >>>>>>> wrote: > >>>>>>> > >>>>>>> On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka wrote: > >>>>>>>> > >>>>>>>> I think we need protocol and YANG specs that are not tied to any > >>>>>>>> particular model and that are thus capable of matching unforeseen > >>>>>>>> real-world implementations. This is no sci-fi, HTTP and XML schema > >>>>>>>> languages work this way. > >>>>>>>> > >>>>>>> > >>>>>>> I disagree that HTTP and XML schema languages do the same thing. Our > >>>>>>> goal is interoperable configuration of network devices; the notion of > >>>>>> > >>>>>> Even now, a client that's programmed to write straight to running > >>>>>> isn't interoperable with a server that has candidate and read-only > >>>>>> running. A RESTCONF server that supports only JSON isn't interoperable > >>>>>> with a client that supports only XML. > >>>>>> > >>>>>> We are not in a situation that every pair of a randomly chosen server > >>>>>> and client need to be interoperable. It's IMO perfectly fine if IoT > >>>>>> and ISP networks use different clients. Yet, both can still use the > >>>>>> same RESTCONF, same YANG, and even same YANG modules. > >>>>> > >>>>> The fact is that that data models are written with a certain set of > >>>>> protocol features and datastores in mind (the "meta-model"). Some > >>>>> examples: > >>>>> > >>>>> If we had an "operational-state" datastore like the one proposed, we > >>>>> would not see the /foo vs /foo-state split. > >>>> > >>>> Yes, but I assume this will go away anyway. However, we can still have > >>>> YANG modules (and complete schemas) designed for the operational > >>>> datastore. The important property of the "meta-model" so far has been > >>>> that config and state data are separate, and this is not going to > >>>> change. > >>>> > >>>>> > >>>>> If SNMP would have had a CREATE operation, MIBs would not have used > >>>>> RowStatus. If NETCONF didn't have a way to create instances, we would > >>>>> have seen something similar in YANG models. > >>>>> > >>>>> If NETCONF had a way to add comments to any node in a datastore, we > >>>>> wouldn't have "leaf description" sprinkled throughout the models. > >>>>> > >>>>> If NETCONF didn't have a generic way to filter retreived data, we'd > >>>>> see lots of specific get-* rpcs in YANG models. > >>>> > >>>> Maybe, but are the last three points relevant to this discussion? > >>> > >>> The point is that data models are designed with some meta-model in > >>> mind. The meta-model includes (some) datastores. You wrote: > >> > >> But where and how is this reflected in existing YANG modules (except > >> for the foo and foo-state split, which is IMO a minor issue)? > > > > I don't this split is a minor issue. For the openconfig group, this > > is one of the major problems with YANG, leading to their design with > > duplicate leafs. The reason for adding the operational state > > datastore in the form we propose in the draft it to be able to get rid > > of this split. > > > >>> I believe both the protocols and YANG can work with any set of > >>> datastores [...] > >>> > >>> And I don't think that this is true (practically). For example, a > >>> YANG module that is designed with the new operational state datastore > >>> in mind will be of limited use in a legacy NETCONF server. > >> > >> Please explain. > > > > If a YANG module is designed with this new architecture in mind, it > > will have a single top-level tree, which can support pre-configuration > > and different instances in the config and operational state. > > > > If such a module is implemented in a legacy NETCONF server, the only > > way to get the operational state is to used . But will > > return the union between running and operational state. The client > > can't tell if an instance is really present in the operational state, > > or just in the config. > > > > > > My idea what could be done e.g. with ietf-interfaces > >> is this: > >> > >> 1. Split it into two modules, say ietf-interfaces-config and > >> ietf-interfaces-state. The former would contain exactly what's now > >> inside "interfaces", and the latter will augment it with extra state > >> data that are now under "interfaces-state". > >> > >> 2. The data model for configuration datastores will be defined to > >> contain only ietf-interfaces-config whereas for operational-state > >> datastore it will be ietf-interfaces-config *and* > >> ietf-interfaces-state. > > > > If we do this for all modules then we haven't gained anything; we > > still have duplicate definitions. > > Show me a single YANG data node definition that's duplicate in my > concept above. But then maybe I didn't explain it properly. The interface's "type" leaf. With the new operational-state datastore, /interfaces/interface/type in operational-state and /interfaces-state/interface/type are duplicate. > Note also that you slightly misinterpreted my statement that you > cited: > > I believe both the protocols and YANG can work with any set of > datastores [...] > > I didn't say that there cannot be *modules* that are somehow designed > for a particular datastore model - I meant YANG the language. Ok. Yes, you're right, but then we'd probably need some new statement in each module that tells which meta-model the YANG module is written for. /martin > > Lada > > > > > > > /martin > > > > > >> Am I completely misguided here? If not, then I don't see where the new > >> modules refer to any particular datastore model. Yes, they do reflect > >> that there is configuration and state data, but we don't want to get > >> rid of this distinction, right? > >> > >> Lada > >> > >>> > >>> > >>> > >>> /martin > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: 0xB8F92B08A9F76C67 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > From nobody Wed Jan 11 05:05:21 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4EA12007C; Wed, 11 Jan 2017 05:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3c5gFiyl-uKz; Wed, 11 Jan 2017 05:05:16 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2736129BEB; Wed, 11 Jan 2017 05:05:14 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c] (unknown [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c]) by mail.nic.cz (Postfix) with ESMTPSA id 0E69E6114F; Wed, 11 Jan 2017 14:05:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484139912; bh=/MOse1kvZdMHX0VM7wUkV8Qw5PMdPkS+w8oVE9sYMqg=; h=From:Date:To; b=Hq6SKDBu7/voOgxcPpmJ3kTkh01I03EV2AO3vSxqSgt7+HcYBDO2GZOKA/s2kH04X nscY46G0Wyb2KDvDw29Hr8cnCSak9GUZL7agN5y76tTmVeRKIbvGo1KjNeuq16ToUX +9lsH3CgDatxgSkSLHwEMNJzLeXGs3E9BrOKUdvk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170111.135359.1145355019648401300.mbj@tail-f.com> Date: Wed, 11 Jan 2017 14:05:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <74141E09-06C2-439E-BA85-81E3FC12DD17@nic.cz> References: <2C96B1C8-3D97-41FF-AD91-44432868C5CF@nic.cz> <20170111.132759.746322711124349871.mbj@tail-f.com> <25050412-8C71-44E7-8865-24320902ED2D@nic.cz> <20170111.135359.1145355019648401300.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf , NetMod WG Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 13:05:18 -0000 > On 11 Jan 2017, at 13:53, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 11 Jan 2017, at 13:27, Martin Bjorklund wrote: >>>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>>> On 11 Jan 2017, at 12:16, Martin Bjorklund wrote: >>>>>=20 >>>>> Ladislav Lhotka wrote: >>>>>>=20 >>>>>>> On 11 Jan 2017, at 10:36, Martin Bjorklund = wrote: >>>>>>>=20 >>>>>>> Ladislav Lhotka wrote: >>>>>>>>=20 >>>>>>>>> On 10 Jan 2017, at 09:39, Juergen Schoenwaelder >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka = wrote: >>>>>>>>>>=20 >>>>>>>>>> I think we need protocol and YANG specs that are not tied to = any >>>>>>>>>> particular model and that are thus capable of matching = unforeseen >>>>>>>>>> real-world implementations. This is no sci-fi, HTTP and XML = schema >>>>>>>>>> languages work this way. >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I disagree that HTTP and XML schema languages do the same = thing. Our >>>>>>>>> goal is interoperable configuration of network devices; the = notion of >>>>>>>>=20 >>>>>>>> Even now, a client that's programmed to write straight to = running >>>>>>>> isn't interoperable with a server that has candidate and = read-only >>>>>>>> running. A RESTCONF server that supports only JSON isn't = interoperable >>>>>>>> with a client that supports only XML. >>>>>>>>=20 >>>>>>>> We are not in a situation that every pair of a randomly chosen = server >>>>>>>> and client need to be interoperable. It's IMO perfectly fine if = IoT >>>>>>>> and ISP networks use different clients. Yet, both can still use = the >>>>>>>> same RESTCONF, same YANG, and even same YANG modules. >>>>>>>=20 >>>>>>> The fact is that that data models are written with a certain set = of >>>>>>> protocol features and datastores in mind (the "meta-model"). = Some >>>>>>> examples: >>>>>>>=20 >>>>>>> If we had an "operational-state" datastore like the one = proposed, we >>>>>>> would not see the /foo vs /foo-state split. >>>>>>=20 >>>>>> Yes, but I assume this will go away anyway. However, we can still = have >>>>>> YANG modules (and complete schemas) designed for the operational >>>>>> datastore. The important property of the "meta-model" so far has = been >>>>>> that config and state data are separate, and this is not going to >>>>>> change. >>>>>>=20 >>>>>>>=20 >>>>>>> If SNMP would have had a CREATE operation, MIBs would not have = used >>>>>>> RowStatus. If NETCONF didn't have a way to create instances, we = would >>>>>>> have seen something similar in YANG models. >>>>>>>=20 >>>>>>> If NETCONF had a way to add comments to any node in a datastore, = we >>>>>>> wouldn't have "leaf description" sprinkled throughout the = models. >>>>>>>=20 >>>>>>> If NETCONF didn't have a generic way to filter retreived data, = we'd >>>>>>> see lots of specific get-* rpcs in YANG models. >>>>>>=20 >>>>>> Maybe, but are the last three points relevant to this discussion? >>>>>=20 >>>>> The point is that data models are designed with some meta-model in >>>>> mind. The meta-model includes (some) datastores. You wrote: >>>>=20 >>>> But where and how is this reflected in existing YANG modules = (except >>>> for the foo and foo-state split, which is IMO a minor issue)? >>>=20 >>> I don't this split is a minor issue. For the openconfig group, this >>> is one of the major problems with YANG, leading to their design with >>> duplicate leafs. The reason for adding the operational state >>> datastore in the form we propose in the draft it to be able to get = rid >>> of this split. >>>=20 >>>>> I believe both the protocols and YANG can work with any set of >>>>> datastores [...] >>>>>=20 >>>>> And I don't think that this is true (practically). For example, a >>>>> YANG module that is designed with the new operational state = datastore >>>>> in mind will be of limited use in a legacy NETCONF server. >>>>=20 >>>> Please explain. >>>=20 >>> If a YANG module is designed with this new architecture in mind, it >>> will have a single top-level tree, which can support = pre-configuration >>> and different instances in the config and operational state. >>>=20 >>> If such a module is implemented in a legacy NETCONF server, the only >>> way to get the operational state is to used . But will >>> return the union between running and operational state. The client >>> can't tell if an instance is really present in the operational = state, >>> or just in the config. >>>=20 >>>=20 >>> My idea what could be done e.g. with ietf-interfaces >>>> is this: >>>>=20 >>>> 1. Split it into two modules, say ietf-interfaces-config and >>>> ietf-interfaces-state. The former would contain exactly what's now >>>> inside "interfaces", and the latter will augment it with extra = state >>>> data that are now under "interfaces-state". >>>>=20 >>>> 2. The data model for configuration datastores will be defined to >>>> contain only ietf-interfaces-config whereas for operational-state >>>> datastore it will be ietf-interfaces-config *and* >>>> ietf-interfaces-state. >>>=20 >>> If we do this for all modules then we haven't gained anything; we >>> still have duplicate definitions. >>=20 >> Show me a single YANG data node definition that's duplicate in my >> concept above. But then maybe I didn't explain it properly. >=20 > The interface's "type" leaf. With the new operational-state > datastore, /interfaces/interface/type in operational-state and > /interfaces-state/interface/type are duplicate. As I said, ietf-interfaces-state state would consist of augments = containing extra state nodes (i.e. those that are not in configuration). = So "type" won't be there. >=20 >> Note also that you slightly misinterpreted my statement that you >> cited: >>=20 >> I believe both the protocols and YANG can work with any set of >> datastores [...] >>=20 >> I didn't say that there cannot be *modules* that are somehow designed >> for a particular datastore model - I meant YANG the language. >=20 > Ok. Yes, you're right, but then we'd probably need some new statement > in each module that tells which meta-model the YANG module is written > for. I would prefer to have it as state data, basically separate YANG = libraries for configuration datastores and operational-state. Lada >=20 >=20 > /martin >=20 >=20 >>=20 >> Lada >>=20 >>>=20 >>>=20 >>> /martin >>>=20 >>>=20 >>>> Am I completely misguided here? If not, then I don't see where the = new >>>> modules refer to any particular datastore model. Yes, they do = reflect >>>> that there is configuration and state data, but we don't want to = get >>>> rid of this distinction, right? >>>>=20 >>>> Lada >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> /martin >>>>=20 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: 0xB8F92B08A9F76C67 >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jan 11 05:20:03 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDAEF129C12; Wed, 11 Jan 2017 05:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQqvZEejHpJZ; Wed, 11 Jan 2017 05:19:59 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18EC4129C13; Wed, 11 Jan 2017 05:19:59 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c] (unknown [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c]) by mail.nic.cz (Postfix) with ESMTPSA id C3B7260A57; Wed, 11 Jan 2017 14:19:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484140797; bh=31QZlLtJVmwEX3PsgArISf8FsPVOIqY/snrtUkpllIw=; h=From:Date:To; b=ejsrfZjOuyuKZl79rDeC92tubWZ6CMC6u9OvbQ+3Pci03NAuVEFE0+BUYA9J7CSjE LCVcq4WBPmh1ParFL5MVRO+v1iP1sRGnKLeiMBkmuBk/S5XWK+1ZwgFUeueH7DKPGn sjEoBhxtW+o11Afccck6G/xnEftpqbnbgGPm65iw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <74141E09-06C2-439E-BA85-81E3FC12DD17@nic.cz> Date: Wed, 11 Jan 2017 14:19:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <43102666-6730-4AD9-9E4E-CEAF86C8C5F0@nic.cz> References: <2C96B1C8-3D97-41FF-AD91-44432868C5CF@nic.cz> <20170111.132759.746322711124349871.mbj@tail-f.com> <25050412-8C71-44E7-8865-24320902ED2D@nic.cz> <20170111.135359.1145355019648401300.mbj@tail-f.com> <74141E09-06C2-439E-BA85-81E3FC12DD17@nic.cz> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf , NetMod WG Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 13:20:02 -0000 > On 11 Jan 2017, at 14:05, Ladislav Lhotka wrote: >=20 >>=20 >> On 11 Jan 2017, at 13:53, Martin Bjorklund wrote: >>=20 >> Ladislav Lhotka wrote: >>>=20 >>>> On 11 Jan 2017, at 13:27, Martin Bjorklund wrote: >>>>=20 >>>> Ladislav Lhotka wrote: >>>>>=20 >>>>>> On 11 Jan 2017, at 12:16, Martin Bjorklund = wrote: >>>>>>=20 >>>>>> Ladislav Lhotka wrote: >>>>>>>=20 >>>>>>>> On 11 Jan 2017, at 10:36, Martin Bjorklund = wrote: >>>>>>>>=20 >>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>=20 >>>>>>>>>> On 10 Jan 2017, at 09:39, Juergen Schoenwaelder >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>> On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka = wrote: >>>>>>>>>>>=20 >>>>>>>>>>> I think we need protocol and YANG specs that are not tied to = any >>>>>>>>>>> particular model and that are thus capable of matching = unforeseen >>>>>>>>>>> real-world implementations. This is no sci-fi, HTTP and XML = schema >>>>>>>>>>> languages work this way. >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> I disagree that HTTP and XML schema languages do the same = thing. Our >>>>>>>>>> goal is interoperable configuration of network devices; the = notion of >>>>>>>>>=20 >>>>>>>>> Even now, a client that's programmed to write straight to = running >>>>>>>>> isn't interoperable with a server that has candidate and = read-only >>>>>>>>> running. A RESTCONF server that supports only JSON isn't = interoperable >>>>>>>>> with a client that supports only XML. >>>>>>>>>=20 >>>>>>>>> We are not in a situation that every pair of a randomly chosen = server >>>>>>>>> and client need to be interoperable. It's IMO perfectly fine = if IoT >>>>>>>>> and ISP networks use different clients. Yet, both can still = use the >>>>>>>>> same RESTCONF, same YANG, and even same YANG modules. >>>>>>>>=20 >>>>>>>> The fact is that that data models are written with a certain = set of >>>>>>>> protocol features and datastores in mind (the "meta-model"). = Some >>>>>>>> examples: >>>>>>>>=20 >>>>>>>> If we had an "operational-state" datastore like the one = proposed, we >>>>>>>> would not see the /foo vs /foo-state split. >>>>>>>=20 >>>>>>> Yes, but I assume this will go away anyway. However, we can = still have >>>>>>> YANG modules (and complete schemas) designed for the operational >>>>>>> datastore. The important property of the "meta-model" so far has = been >>>>>>> that config and state data are separate, and this is not going = to >>>>>>> change. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> If SNMP would have had a CREATE operation, MIBs would not have = used >>>>>>>> RowStatus. If NETCONF didn't have a way to create instances, = we would >>>>>>>> have seen something similar in YANG models. >>>>>>>>=20 >>>>>>>> If NETCONF had a way to add comments to any node in a = datastore, we >>>>>>>> wouldn't have "leaf description" sprinkled throughout the = models. >>>>>>>>=20 >>>>>>>> If NETCONF didn't have a generic way to filter retreived data, = we'd >>>>>>>> see lots of specific get-* rpcs in YANG models. >>>>>>>=20 >>>>>>> Maybe, but are the last three points relevant to this = discussion? >>>>>>=20 >>>>>> The point is that data models are designed with some meta-model = in >>>>>> mind. The meta-model includes (some) datastores. You wrote: >>>>>=20 >>>>> But where and how is this reflected in existing YANG modules = (except >>>>> for the foo and foo-state split, which is IMO a minor issue)? >>>>=20 >>>> I don't this split is a minor issue. For the openconfig group, = this >>>> is one of the major problems with YANG, leading to their design = with >>>> duplicate leafs. The reason for adding the operational state >>>> datastore in the form we propose in the draft it to be able to get = rid >>>> of this split. >>>>=20 >>>>>> I believe both the protocols and YANG can work with any set of >>>>>> datastores [...] >>>>>>=20 >>>>>> And I don't think that this is true (practically). For example, = a >>>>>> YANG module that is designed with the new operational state = datastore >>>>>> in mind will be of limited use in a legacy NETCONF server. >>>>>=20 >>>>> Please explain. >>>>=20 >>>> If a YANG module is designed with this new architecture in mind, it >>>> will have a single top-level tree, which can support = pre-configuration >>>> and different instances in the config and operational state. >>>>=20 >>>> If such a module is implemented in a legacy NETCONF server, the = only >>>> way to get the operational state is to used . But = will >>>> return the union between running and operational state. The client >>>> can't tell if an instance is really present in the operational = state, >>>> or just in the config. >>>>=20 >>>>=20 >>>> My idea what could be done e.g. with ietf-interfaces >>>>> is this: >>>>>=20 >>>>> 1. Split it into two modules, say ietf-interfaces-config and >>>>> ietf-interfaces-state. The former would contain exactly what's now >>>>> inside "interfaces", and the latter will augment it with extra = state >>>>> data that are now under "interfaces-state". >>>>>=20 >>>>> 2. The data model for configuration datastores will be defined to >>>>> contain only ietf-interfaces-config whereas for operational-state >>>>> datastore it will be ietf-interfaces-config *and* >>>>> ietf-interfaces-state. >>>>=20 >>>> If we do this for all modules then we haven't gained anything; we >>>> still have duplicate definitions. >>>=20 >>> Show me a single YANG data node definition that's duplicate in my >>> concept above. But then maybe I didn't explain it properly. >>=20 >> The interface's "type" leaf. With the new operational-state >> datastore, /interfaces/interface/type in operational-state and >> /interfaces-state/interface/type are duplicate. >=20 > As I said, ietf-interfaces-state state would consist of augments = containing extra state nodes (i.e. those that are not in configuration). = So "type" won't be there. >=20 >>=20 >>> Note also that you slightly misinterpreted my statement that you >>> cited: >>>=20 >>> I believe both the protocols and YANG can work with any set of >>> datastores [...] >>>=20 >>> I didn't say that there cannot be *modules* that are somehow = designed >>> for a particular datastore model - I meant YANG the language. >>=20 >> Ok. Yes, you're right, but then we'd probably need some new = statement >> in each module that tells which meta-model the YANG module is written >> for. >=20 > I would prefer to have it as state data, basically separate YANG = libraries for configuration datastores and operational-state. BTW, this approach could also solve the issue of different "levels" of = data that Rob asked about previously: https://www.ietf.org/mail-archive/web/netmod/current/msg17125.html A server could then provide additional operational-state datastores, for = example "operational-state-diagnostics" and = "operational-state-registers". This is IMO quite a clean solution. Lada >=20 > Lada >=20 >>=20 >>=20 >> /martin >>=20 >>=20 >>>=20 >>> Lada >>>=20 >>>>=20 >>>>=20 >>>> /martin >>>>=20 >>>>=20 >>>>> Am I completely misguided here? If not, then I don't see where the = new >>>>> modules refer to any particular datastore model. Yes, they do = reflect >>>>> that there is configuration and state data, but we don't want to = get >>>>> rid of this distinction, right? >>>>>=20 >>>>> Lada >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> /martin >>>>>=20 >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: 0xB8F92B08A9F76C67 >>>=20 >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: 0xB8F92B08A9F76C67 >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jan 11 06:18:25 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0F3129C84; Wed, 11 Jan 2017 06:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CbXXyXzi6O8; Wed, 11 Jan 2017 06:18:22 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 484B5129C7A; Wed, 11 Jan 2017 06:18:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2736; q=dns/txt; s=iport; t=1484144302; x=1485353902; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=hl8ArC+/IJddqntZ2aVOiri068u1/Moj1KJBrixmoho=; b=WlmOUMTb8sD7oVIE8dqX6kunzszEa64ZVnVHLl6K09d/6ku23YGNgN7k MR4Xilzb5pcZ0thBjj2vhZ+KNumk/qfnKsNi2bZZ20Ly79ALFdYDytE+O Q5sLqQfDsMbPEjpquX3+kAL682tKd0FZqkz5wYDjFYTiINbx4jtwMM4d6 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3AQDuPXZY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzsBAQEBAX4DLF6NV3KRIZUnggsfC4UuSgKCOBQBAgEBAQEBAQF?= =?us-ascii?q?jKIRpAQEBAwEBATY2CxALGCMLJzAGAQwGAgEBiHQIDrJkihYBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYZFggKCX4osBZsqkVOBd4g2I4YVimaHex84Nl0SBxUVOoQ?= =?us-ascii?q?0HBiBRz41iGYBAQE?= X-IronPort-AV: E=Sophos;i="5.33,346,1477958400"; d="scan'208";a="651530567" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2017 14:18:19 +0000 Received: from [10.63.23.107] (dhcp-ensft1-uk-vla370-10-63-23-107.cisco.com [10.63.23.107]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v0BEIJix010465; Wed, 11 Jan 2017 14:18:19 GMT To: Ladislav Lhotka , =?UTF-8?Q?Martin_Bj=c3=b6rklund?= References: <2C96B1C8-3D97-41FF-AD91-44432868C5CF@nic.cz> <20170111.132759.746322711124349871.mbj@tail-f.com> <25050412-8C71-44E7-8865-24320902ED2D@nic.cz> <20170111.135359.1145355019648401300.mbj@tail-f.com> <74141E09-06C2-439E-BA85-81E3FC12DD17@nic.cz> From: Robert Wilton Message-ID: Date: Wed, 11 Jan 2017 14:18:19 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <74141E09-06C2-439E-BA85-81E3FC12DD17@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Netconf , NetMod WG Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 14:18:25 -0000 Hi, On 11/01/2017 13:05, Ladislav Lhotka wrote: >> On 11 Jan 2017, at 13:53, Martin Bjorklund wrote: >> >> Ladislav Lhotka wrote: >>> Show me a single YANG data node definition that's duplicate in my >>> concept above. But then maybe I didn't explain it properly. >> The interface's "type" leaf. With the new operational-state >> datastore, /interfaces/interface/type in operational-state and >> /interfaces-state/interface/type are duplicate. > As I said, ietf-interfaces-state state would consist of augments containing extra state nodes (i.e. those that are not in configuration). So "type" won't be there. I think that this effectively just achieves the same thing that the "config: true|false" statement indicates in a combined config/state tree. Personally, I think that a file of augmentations is probably going to be harder to read than having the config and state schema in one tree in one file. The models may also be slightly more inconvenient to use because the state tree leaves would presumably be in a different namespace from the configuration? If you wanted this file level split then using submodules would allow for separate config/state files but still be managed as a single combined module. Rob > >>> Note also that you slightly misinterpreted my statement that you >>> cited: >>> >>> I believe both the protocols and YANG can work with any set of >>> datastores [...] >>> >>> I didn't say that there cannot be *modules* that are somehow designed >>> for a particular datastore model - I meant YANG the language. >> Ok. Yes, you're right, but then we'd probably need some new statement >> in each module that tells which meta-model the YANG module is written >> for. > I would prefer to have it as state data, basically separate YANG libraries for configuration datastores and operational-state. > > Lada > >> >> /martin >> >> >>> Lada >>> >>>> >>>> /martin >>>> >>>> >>>>> Am I completely misguided here? If not, then I don't see where the new >>>>> modules refer to any particular datastore model. Yes, they do reflect >>>>> that there is configuration and state data, but we don't want to get >>>>> rid of this distinction, right? >>>>> >>>>> Lada >>>>> >>>>>> >>>>>> >>>>>> /martin >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: 0xB8F92B08A9F76C67 >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: 0xB8F92B08A9F76C67 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > . > From nobody Wed Jan 11 06:37:12 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41A6129ED7; Wed, 11 Jan 2017 06:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9G1U03KtrMq; Wed, 11 Jan 2017 06:37:04 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B7CC8129CA4; Wed, 11 Jan 2017 06:37:04 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 008B51AE02BA; Wed, 11 Jan 2017 15:37:03 +0100 (CET) Date: Wed, 11 Jan 2017 15:37:03 +0100 (CET) Message-Id: <20170111.153703.778626501770378439.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <74141E09-06C2-439E-BA85-81E3FC12DD17@nic.cz> References: <25050412-8C71-44E7-8865-24320902ED2D@nic.cz> <20170111.135359.1145355019648401300.mbj@tail-f.com> <74141E09-06C2-439E-BA85-81E3FC12DD17@nic.cz> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 14:37:07 -0000 Ladislav Lhotka wrote: > > > On 11 Jan 2017, at 13:53, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> > >>> On 11 Jan 2017, at 13:27, Martin Bjorklund wrote: > >>> > >>> Ladislav Lhotka wrote: > >>>> > >>>>> On 11 Jan 2017, at 12:16, Martin Bjorklund wrote: > >>>>> > >>>>> Ladislav Lhotka wrote: > >>>>>> > >>>>>>> On 11 Jan 2017, at 10:36, Martin Bjorklund wrote: > >>>>>>> > >>>>>>> Ladislav Lhotka wrote: > >>>>>>>> > >>>>>>>>> On 10 Jan 2017, at 09:39, Juergen Schoenwaelder > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka wrote: > >>>>>>>>>> > >>>>>>>>>> I think we need protocol and YANG specs that are not tied to any > >>>>>>>>>> particular model and that are thus capable of matching unforeseen > >>>>>>>>>> real-world implementations. This is no sci-fi, HTTP and XML schema > >>>>>>>>>> languages work this way. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> I disagree that HTTP and XML schema languages do the same thing. Our > >>>>>>>>> goal is interoperable configuration of network devices; the notion of > >>>>>>>> > >>>>>>>> Even now, a client that's programmed to write straight to running > >>>>>>>> isn't interoperable with a server that has candidate and read-only > >>>>>>>> running. A RESTCONF server that supports only JSON isn't interoperable > >>>>>>>> with a client that supports only XML. > >>>>>>>> > >>>>>>>> We are not in a situation that every pair of a randomly chosen server > >>>>>>>> and client need to be interoperable. It's IMO perfectly fine if IoT > >>>>>>>> and ISP networks use different clients. Yet, both can still use the > >>>>>>>> same RESTCONF, same YANG, and even same YANG modules. > >>>>>>> > >>>>>>> The fact is that that data models are written with a certain set of > >>>>>>> protocol features and datastores in mind (the "meta-model"). Some > >>>>>>> examples: > >>>>>>> > >>>>>>> If we had an "operational-state" datastore like the one proposed, we > >>>>>>> would not see the /foo vs /foo-state split. > >>>>>> > >>>>>> Yes, but I assume this will go away anyway. However, we can still have > >>>>>> YANG modules (and complete schemas) designed for the operational > >>>>>> datastore. The important property of the "meta-model" so far has been > >>>>>> that config and state data are separate, and this is not going to > >>>>>> change. > >>>>>> > >>>>>>> > >>>>>>> If SNMP would have had a CREATE operation, MIBs would not have used > >>>>>>> RowStatus. If NETCONF didn't have a way to create instances, we would > >>>>>>> have seen something similar in YANG models. > >>>>>>> > >>>>>>> If NETCONF had a way to add comments to any node in a datastore, we > >>>>>>> wouldn't have "leaf description" sprinkled throughout the models. > >>>>>>> > >>>>>>> If NETCONF didn't have a generic way to filter retreived data, we'd > >>>>>>> see lots of specific get-* rpcs in YANG models. > >>>>>> > >>>>>> Maybe, but are the last three points relevant to this discussion? > >>>>> > >>>>> The point is that data models are designed with some meta-model in > >>>>> mind. The meta-model includes (some) datastores. You wrote: > >>>> > >>>> But where and how is this reflected in existing YANG modules (except > >>>> for the foo and foo-state split, which is IMO a minor issue)? > >>> > >>> I don't this split is a minor issue. For the openconfig group, this > >>> is one of the major problems with YANG, leading to their design with > >>> duplicate leafs. The reason for adding the operational state > >>> datastore in the form we propose in the draft it to be able to get rid > >>> of this split. > >>> > >>>>> I believe both the protocols and YANG can work with any set of > >>>>> datastores [...] > >>>>> > >>>>> And I don't think that this is true (practically). For example, a > >>>>> YANG module that is designed with the new operational state datastore > >>>>> in mind will be of limited use in a legacy NETCONF server. > >>>> > >>>> Please explain. > >>> > >>> If a YANG module is designed with this new architecture in mind, it > >>> will have a single top-level tree, which can support pre-configuration > >>> and different instances in the config and operational state. > >>> > >>> If such a module is implemented in a legacy NETCONF server, the only > >>> way to get the operational state is to used . But will > >>> return the union between running and operational state. The client > >>> can't tell if an instance is really present in the operational state, > >>> or just in the config. > >>> > >>> > >>> My idea what could be done e.g. with ietf-interfaces > >>>> is this: > >>>> > >>>> 1. Split it into two modules, say ietf-interfaces-config and > >>>> ietf-interfaces-state. The former would contain exactly what's now > >>>> inside "interfaces", and the latter will augment it with extra state > >>>> data that are now under "interfaces-state". > >>>> > >>>> 2. The data model for configuration datastores will be defined to > >>>> contain only ietf-interfaces-config whereas for operational-state > >>>> datastore it will be ietf-interfaces-config *and* > >>>> ietf-interfaces-state. > >>> > >>> If we do this for all modules then we haven't gained anything; we > >>> still have duplicate definitions. > >> > >> Show me a single YANG data node definition that's duplicate in my > >> concept above. But then maybe I didn't explain it properly. > > > > The interface's "type" leaf. With the new operational-state > > datastore, /interfaces/interface/type in operational-state and > > /interfaces-state/interface/type are duplicate. > > As I said, ietf-interfaces-state state would consist of augments > containing extra state nodes (i.e. those that are not in > configuration). So "type" won't be there. So how would a client learn the type of a system-controlled interface? > >> Note also that you slightly misinterpreted my statement that you > >> cited: > >> > >> I believe both the protocols and YANG can work with any set of > >> datastores [...] > >> > >> I didn't say that there cannot be *modules* that are somehow designed > >> for a particular datastore model - I meant YANG the language. > > > > Ok. Yes, you're right, but then we'd probably need some new statement > > in each module that tells which meta-model the YANG module is written > > for. > > I would prefer to have it as state data, basically separate YANG > libraries for configuration datastores and operational-state. But the use case is that a particular module is designed for a certain datastore model (which you wrote above). This is a design-time property, not a rum-time property, so state data (run-time) is not the right solution. If a module is designed for a certain datastore model, that module cannot be implemented in a server with some other datastore model. /martin From nobody Wed Jan 11 06:43:24 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E89129CAF; Wed, 11 Jan 2017 06:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjd7daW9y4Um; Wed, 11 Jan 2017 06:43:18 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B5EB9129CAE; Wed, 11 Jan 2017 06:43:18 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 03D0D1AE02BA; Wed, 11 Jan 2017 15:43:18 +0100 (CET) Date: Wed, 11 Jan 2017 15:43:17 +0100 (CET) Message-Id: <20170111.154317.387424575739598718.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <20170111.153703.778626501770378439.mbj@tail-f.com> References: <20170111.135359.1145355019648401300.mbj@tail-f.com> <74141E09-06C2-439E-BA85-81E3FC12DD17@nic.cz> <20170111.153703.778626501770378439.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 14:43:20 -0000 Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > > > > On 11 Jan 2017, at 13:53, Martin Bjorklund wrote: > > > > > > Ladislav Lhotka wrote: > > >> > > >>> On 11 Jan 2017, at 13:27, Martin Bjorklund wrote: > > >>> > > >>> Ladislav Lhotka wrote: > > >>>> > > >>>>> On 11 Jan 2017, at 12:16, Martin Bjorklund wrote: > > >>>>> > > >>>>> Ladislav Lhotka wrote: > > >>>>>> > > >>>>>>> On 11 Jan 2017, at 10:36, Martin Bjorklund wrote: > > >>>>>>> > > >>>>>>> Ladislav Lhotka wrote: > > >>>>>>>> > > >>>>>>>>> On 10 Jan 2017, at 09:39, Juergen Schoenwaelder > > >>>>>>>>> wrote: > > >>>>>>>>> > > >>>>>>>>> On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka wrote: > > >>>>>>>>>> > > >>>>>>>>>> I think we need protocol and YANG specs that are not tied to any > > >>>>>>>>>> particular model and that are thus capable of matching unforeseen > > >>>>>>>>>> real-world implementations. This is no sci-fi, HTTP and XML schema > > >>>>>>>>>> languages work this way. > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> I disagree that HTTP and XML schema languages do the same thing. Our > > >>>>>>>>> goal is interoperable configuration of network devices; the notion of > > >>>>>>>> > > >>>>>>>> Even now, a client that's programmed to write straight to running > > >>>>>>>> isn't interoperable with a server that has candidate and read-only > > >>>>>>>> running. A RESTCONF server that supports only JSON isn't interoperable > > >>>>>>>> with a client that supports only XML. > > >>>>>>>> > > >>>>>>>> We are not in a situation that every pair of a randomly chosen server > > >>>>>>>> and client need to be interoperable. It's IMO perfectly fine if IoT > > >>>>>>>> and ISP networks use different clients. Yet, both can still use the > > >>>>>>>> same RESTCONF, same YANG, and even same YANG modules. > > >>>>>>> > > >>>>>>> The fact is that that data models are written with a certain set of > > >>>>>>> protocol features and datastores in mind (the "meta-model"). Some > > >>>>>>> examples: > > >>>>>>> > > >>>>>>> If we had an "operational-state" datastore like the one proposed, we > > >>>>>>> would not see the /foo vs /foo-state split. > > >>>>>> > > >>>>>> Yes, but I assume this will go away anyway. However, we can still have > > >>>>>> YANG modules (and complete schemas) designed for the operational > > >>>>>> datastore. The important property of the "meta-model" so far has been > > >>>>>> that config and state data are separate, and this is not going to > > >>>>>> change. > > >>>>>> > > >>>>>>> > > >>>>>>> If SNMP would have had a CREATE operation, MIBs would not have used > > >>>>>>> RowStatus. If NETCONF didn't have a way to create instances, we would > > >>>>>>> have seen something similar in YANG models. > > >>>>>>> > > >>>>>>> If NETCONF had a way to add comments to any node in a datastore, we > > >>>>>>> wouldn't have "leaf description" sprinkled throughout the models. > > >>>>>>> > > >>>>>>> If NETCONF didn't have a generic way to filter retreived data, we'd > > >>>>>>> see lots of specific get-* rpcs in YANG models. > > >>>>>> > > >>>>>> Maybe, but are the last three points relevant to this discussion? > > >>>>> > > >>>>> The point is that data models are designed with some meta-model in > > >>>>> mind. The meta-model includes (some) datastores. You wrote: > > >>>> > > >>>> But where and how is this reflected in existing YANG modules (except > > >>>> for the foo and foo-state split, which is IMO a minor issue)? > > >>> > > >>> I don't this split is a minor issue. For the openconfig group, this > > >>> is one of the major problems with YANG, leading to their design with > > >>> duplicate leafs. The reason for adding the operational state > > >>> datastore in the form we propose in the draft it to be able to get rid > > >>> of this split. > > >>> > > >>>>> I believe both the protocols and YANG can work with any set of > > >>>>> datastores [...] > > >>>>> > > >>>>> And I don't think that this is true (practically). For example, a > > >>>>> YANG module that is designed with the new operational state datastore > > >>>>> in mind will be of limited use in a legacy NETCONF server. > > >>>> > > >>>> Please explain. > > >>> > > >>> If a YANG module is designed with this new architecture in mind, it > > >>> will have a single top-level tree, which can support pre-configuration > > >>> and different instances in the config and operational state. > > >>> > > >>> If such a module is implemented in a legacy NETCONF server, the only > > >>> way to get the operational state is to used . But will > > >>> return the union between running and operational state. The client > > >>> can't tell if an instance is really present in the operational state, > > >>> or just in the config. > > >>> > > >>> > > >>> My idea what could be done e.g. with ietf-interfaces > > >>>> is this: > > >>>> > > >>>> 1. Split it into two modules, say ietf-interfaces-config and > > >>>> ietf-interfaces-state. The former would contain exactly what's now > > >>>> inside "interfaces", and the latter will augment it with extra state > > >>>> data that are now under "interfaces-state". > > >>>> > > >>>> 2. The data model for configuration datastores will be defined to > > >>>> contain only ietf-interfaces-config whereas for operational-state > > >>>> datastore it will be ietf-interfaces-config *and* > > >>>> ietf-interfaces-state. > > >>> > > >>> If we do this for all modules then we haven't gained anything; we > > >>> still have duplicate definitions. > > >> > > >> Show me a single YANG data node definition that's duplicate in my > > >> concept above. But then maybe I didn't explain it properly. > > > > > > The interface's "type" leaf. With the new operational-state > > > datastore, /interfaces/interface/type in operational-state and > > > /interfaces-state/interface/type are duplicate. > > > > As I said, ietf-interfaces-state state would consist of augments > > containing extra state nodes (i.e. those that are not in > > configuration). So "type" won't be there. > > So how would a client learn the type of a system-controlled interface? Never mind; I misread your proposal, sorry about that. But I agree with Rob; how is the proposal with two modules different than having them in the same module (apart from the additional namespace required)? /martin From nobody Wed Jan 11 06:48:10 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6112A129B3A; Wed, 11 Jan 2017 06:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sjr43PdRjPsh; Wed, 11 Jan 2017 06:48:06 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55D4D129518; Wed, 11 Jan 2017 06:48:06 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c] (unknown [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c]) by mail.nic.cz (Postfix) with ESMTPSA id EAE3360ABB; Wed, 11 Jan 2017 15:48:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484146085; bh=hlOqx2zwI0DT8F/z60z+OeHiCS+mVpW81qfYgPest88=; h=From:Date:To; b=XupAButoxATWq1Hin752hkpHPpnbp94o37QR/IWbi6hZESxHdb4rMn8fE3x+h4VU0 tKxX+VOpeYB5GfbinGLF8QA8j8YrhGgKufHhAUl4NAQGVQWfU4BkfBXx4kxq5amSku 57dPgd+wnN3C08kEDkig8TvJrL8bMKcNLomnJ1xk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 11 Jan 2017 15:48:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <203F849C-A116-4C48-A3F3-98D2F31D12A8@nic.cz> References: <2C96B1C8-3D97-41FF-AD91-44432868C5CF@nic.cz> <20170111.132759.746322711124349871.mbj@tail-f.com> <25050412-8C71-44E7-8865-24320902ED2D@nic.cz> <20170111.135359.1145355019648401300.mbj@tail-f.com> <74141E09-06C2-439E-BA85-81E3FC12DD17@nic.cz> To: Robert Wilton X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf , NetMod WG Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 14:48:08 -0000 > On 11 Jan 2017, at 15:18, Robert Wilton wrote: >=20 > Hi, >=20 > On 11/01/2017 13:05, Ladislav Lhotka wrote: >>> On 11 Jan 2017, at 13:53, Martin Bjorklund wrote: >>>=20 >>> Ladislav Lhotka wrote: > >>>> Show me a single YANG data node definition that's duplicate in my >>>> concept above. But then maybe I didn't explain it properly. >>> The interface's "type" leaf. With the new operational-state >>> datastore, /interfaces/interface/type in operational-state and >>> /interfaces-state/interface/type are duplicate. >> As I said, ietf-interfaces-state state would consist of augments = containing extra state nodes (i.e. those that are not in configuration). = So "type" won't be there. > I think that this effectively just achieves the same thing that the = "config: true|false" statement indicates in a combined config/state = tree. >=20 > Personally, I think that a file of augmentations is probably going to = be harder to read than having the config and state schema in one tree in = one file. Possibly we could also use schema mount. On the other hand, it doesn't = enforce the use of operational-state datastore. A simple device like a = WiFi-controlled electric socket could easily use just = ietf-interfaces-config (and ietf-ip-config), i.e. no state data. Another example I am dealing with now is OpenWRT: with some effort, it = would be possible to translate our nice configuration data into UCI = files without touching the OpenWRT system itself. On the other hand, = serving state data according to our YANG modules is a non-starter. >=20 > The models may also be slightly more inconvenient to use because the = state tree leaves would presumably be in a different namespace from the = configuration? >=20 Yes, but I don't think it is a big problem - even for human readers. > If you wanted this file level split then using submodules would allow = for separate config/state files but still be managed as a single = combined module. But it means you have to implement both. Lada >=20 > Rob >=20 >=20 >>=20 >>>> Note also that you slightly misinterpreted my statement that you >>>> cited: >>>>=20 >>>> I believe both the protocols and YANG can work with any set of >>>> datastores [...] >>>>=20 >>>> I didn't say that there cannot be *modules* that are somehow = designed >>>> for a particular datastore model - I meant YANG the language. >>> Ok. Yes, you're right, but then we'd probably need some new = statement >>> in each module that tells which meta-model the YANG module is = written >>> for. >> I would prefer to have it as state data, basically separate YANG = libraries for configuration datastores and operational-state. >=20 >=20 >>=20 >> Lada >>=20 >>>=20 >>> /martin >>>=20 >>>=20 >>>> Lada >>>>=20 >>>>>=20 >>>>> /martin >>>>>=20 >>>>>=20 >>>>>> Am I completely misguided here? If not, then I don't see where = the new >>>>>> modules refer to any particular datastore model. Yes, they do = reflect >>>>>> that there is configuration and state data, but we don't want to = get >>>>>> rid of this distinction, right? >>>>>>=20 >>>>>> Lada >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> /martin >>>>>> -- >>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>> PGP Key ID: 0xB8F92B08A9F76C67 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: 0xB8F92B08A9F76C67 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> . -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jan 11 07:10:20 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16338129493; Wed, 11 Jan 2017 07:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKVDsH6qPbwd; Wed, 11 Jan 2017 07:10:17 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2373A12948C; Wed, 11 Jan 2017 07:10:17 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c] (unknown [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c]) by mail.nic.cz (Postfix) with ESMTPSA id 7431060CAC; Wed, 11 Jan 2017 16:10:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484147415; bh=b0QaPQqdZ6zFWWhvEr68L7bdFFGSKSOC+dLmphKL/ls=; h=From:Date:To; b=c7bVOehlbNuHXrZ1ymjFCpJbz4dsBJlXeu1e1U63EsXwZ4C+eThY+x2C1YK5SnKoe eXUIh3q4hbWYuzrksuIQfob0ybcFuWe+9/FskHPbaHwOqRNAltyvBWcDEY0xGQhMBG /73s1wwjsu+44zUTkFdT0UQdExrLRda20BFlSzis= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170111.153703.778626501770378439.mbj@tail-f.com> Date: Wed, 11 Jan 2017 16:10:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <91CB84A8-5C90-4971-90A7-F4B68CE041F0@nic.cz> References: <25050412-8C71-44E7-8865-24320902ED2D@nic.cz> <20170111.135359.1145355019648401300.mbj@tail-f.com> <74141E09-06C2-439E-BA85-81E3FC12DD17@nic.cz> <20170111.153703.778626501770378439.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf , NetMod WG Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 15:10:19 -0000 > On 11 Jan 2017, at 15:37, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 11 Jan 2017, at 13:53, Martin Bjorklund wrote: >>>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>>> On 11 Jan 2017, at 13:27, Martin Bjorklund wrote: >>>>>=20 >>>>> Ladislav Lhotka wrote: >>>>>>=20 >>>>>>> On 11 Jan 2017, at 12:16, Martin Bjorklund = wrote: >>>>>>>=20 >>>>>>> Ladislav Lhotka wrote: >>>>>>>>=20 >>>>>>>>> On 11 Jan 2017, at 10:36, Martin Bjorklund = wrote: >>>>>>>>>=20 >>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>>=20 >>>>>>>>>>> On 10 Jan 2017, at 09:39, Juergen Schoenwaelder >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>> On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka = wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> I think we need protocol and YANG specs that are not tied = to any >>>>>>>>>>>> particular model and that are thus capable of matching = unforeseen >>>>>>>>>>>> real-world implementations. This is no sci-fi, HTTP and XML = schema >>>>>>>>>>>> languages work this way. >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> I disagree that HTTP and XML schema languages do the same = thing. Our >>>>>>>>>>> goal is interoperable configuration of network devices; the = notion of >>>>>>>>>>=20 >>>>>>>>>> Even now, a client that's programmed to write straight to = running >>>>>>>>>> isn't interoperable with a server that has candidate and = read-only >>>>>>>>>> running. A RESTCONF server that supports only JSON isn't = interoperable >>>>>>>>>> with a client that supports only XML. >>>>>>>>>>=20 >>>>>>>>>> We are not in a situation that every pair of a randomly = chosen server >>>>>>>>>> and client need to be interoperable. It's IMO perfectly fine = if IoT >>>>>>>>>> and ISP networks use different clients. Yet, both can still = use the >>>>>>>>>> same RESTCONF, same YANG, and even same YANG modules. >>>>>>>>>=20 >>>>>>>>> The fact is that that data models are written with a certain = set of >>>>>>>>> protocol features and datastores in mind (the "meta-model"). = Some >>>>>>>>> examples: >>>>>>>>>=20 >>>>>>>>> If we had an "operational-state" datastore like the one = proposed, we >>>>>>>>> would not see the /foo vs /foo-state split. >>>>>>>>=20 >>>>>>>> Yes, but I assume this will go away anyway. However, we can = still have >>>>>>>> YANG modules (and complete schemas) designed for the = operational >>>>>>>> datastore. The important property of the "meta-model" so far = has been >>>>>>>> that config and state data are separate, and this is not going = to >>>>>>>> change. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> If SNMP would have had a CREATE operation, MIBs would not have = used >>>>>>>>> RowStatus. If NETCONF didn't have a way to create instances, = we would >>>>>>>>> have seen something similar in YANG models. >>>>>>>>>=20 >>>>>>>>> If NETCONF had a way to add comments to any node in a = datastore, we >>>>>>>>> wouldn't have "leaf description" sprinkled throughout the = models. >>>>>>>>>=20 >>>>>>>>> If NETCONF didn't have a generic way to filter retreived data, = we'd >>>>>>>>> see lots of specific get-* rpcs in YANG models. >>>>>>>>=20 >>>>>>>> Maybe, but are the last three points relevant to this = discussion? >>>>>>>=20 >>>>>>> The point is that data models are designed with some meta-model = in >>>>>>> mind. The meta-model includes (some) datastores. You wrote: >>>>>>=20 >>>>>> But where and how is this reflected in existing YANG modules = (except >>>>>> for the foo and foo-state split, which is IMO a minor issue)? >>>>>=20 >>>>> I don't this split is a minor issue. For the openconfig group, = this >>>>> is one of the major problems with YANG, leading to their design = with >>>>> duplicate leafs. The reason for adding the operational state >>>>> datastore in the form we propose in the draft it to be able to get = rid >>>>> of this split. >>>>>=20 >>>>>>> I believe both the protocols and YANG can work with any set of >>>>>>> datastores [...] >>>>>>>=20 >>>>>>> And I don't think that this is true (practically). For example, = a >>>>>>> YANG module that is designed with the new operational state = datastore >>>>>>> in mind will be of limited use in a legacy NETCONF server. >>>>>>=20 >>>>>> Please explain. >>>>>=20 >>>>> If a YANG module is designed with this new architecture in mind, = it >>>>> will have a single top-level tree, which can support = pre-configuration >>>>> and different instances in the config and operational state. >>>>>=20 >>>>> If such a module is implemented in a legacy NETCONF server, the = only >>>>> way to get the operational state is to used . But = will >>>>> return the union between running and operational state. The = client >>>>> can't tell if an instance is really present in the operational = state, >>>>> or just in the config. >>>>>=20 >>>>>=20 >>>>> My idea what could be done e.g. with ietf-interfaces >>>>>> is this: >>>>>>=20 >>>>>> 1. Split it into two modules, say ietf-interfaces-config and >>>>>> ietf-interfaces-state. The former would contain exactly what's = now >>>>>> inside "interfaces", and the latter will augment it with extra = state >>>>>> data that are now under "interfaces-state". >>>>>>=20 >>>>>> 2. The data model for configuration datastores will be defined to >>>>>> contain only ietf-interfaces-config whereas for operational-state >>>>>> datastore it will be ietf-interfaces-config *and* >>>>>> ietf-interfaces-state. >>>>>=20 >>>>> If we do this for all modules then we haven't gained anything; we >>>>> still have duplicate definitions. >>>>=20 >>>> Show me a single YANG data node definition that's duplicate in my >>>> concept above. But then maybe I didn't explain it properly. >>>=20 >>> The interface's "type" leaf. With the new operational-state >>> datastore, /interfaces/interface/type in operational-state and >>> /interfaces-state/interface/type are duplicate. >>=20 >> As I said, ietf-interfaces-state state would consist of augments >> containing extra state nodes (i.e. those that are not in >> configuration). So "type" won't be there. >=20 > So how would a client learn the type of a system-controlled interface? >=20 >=20 >>>> Note also that you slightly misinterpreted my statement that you >>>> cited: >>>>=20 >>>> I believe both the protocols and YANG can work with any set of >>>> datastores [...] >>>>=20 >>>> I didn't say that there cannot be *modules* that are somehow = designed >>>> for a particular datastore model - I meant YANG the language. >>>=20 >>> Ok. Yes, you're right, but then we'd probably need some new = statement >>> in each module that tells which meta-model the YANG module is = written >>> for. >>=20 >> I would prefer to have it as state data, basically separate YANG >> libraries for configuration datastores and operational-state. >=20 > But the use case is that a particular module is designed for a certain > datastore model (which you wrote above). This is a design-time Not necessarily, and certainly not all modules. In my example with = ietf-interfaces, one could still emulate the current situation with = "interfaces" and "interfaces-state" by defining these containers as two = mount points and then schema-mounting the necessary schemas under each. = There are some minor annoyances regarding namespaces but it could IMO = also work fine for a client that uses the "old" datastore model. Lada > property, not a rum-time property, so state data (run-time) is not the > right solution. If a module is designed for a certain datastore > model, that module cannot be implemented in a server with some other > datastore model. >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jan 11 07:12:54 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616FB129468; Wed, 11 Jan 2017 07:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmfRzC6uey2T; Wed, 11 Jan 2017 07:12:48 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB9EC129493; Wed, 11 Jan 2017 07:12:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6367; q=dns/txt; s=iport; t=1484147568; x=1485357168; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=oWJD7mhI2T+ITOFJgkgOqDeJlB94O0t/9NPtoIxEa5Q=; b=MC8d3N7dsXdExco3pLJMyPQmTgTIuNoYiHhJhQ8SMBG6WnYdi1h9gnMd Mdok4/jbG6GfAg+BN1aP34vF4Dy5vsT+OKRzK5fMG8pCi01Z9KGtAcfuF 6RQghlfa3B+iiMMJ/kaNfsPrSBnWegxZVUIwzs5W/ydmlpi+c15+MHWG8 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAQAPS3ZY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzsBAQEBAX4DLF6DT4oIcpEhlSeCCx8LhS5KAoI5FAECAQEBAQE?= =?us-ascii?q?BAWMohGkBAQEDAQEBIQ8BBTYLBQsLDgoCAh8HAgInMAYBDAYCAQEXiF0IDrBGg?= =?us-ascii?q?iWKFQEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuFOoICCIJXhDCDHoJeBY8cjA6?= =?us-ascii?q?JcIdjii2GOIpmh3sfOIETEgcVFTqEaIFHPjWIZgEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,346,1477958400"; d="scan'208";a="649712011" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2017 15:12:43 +0000 Received: from [10.63.23.107] (dhcp-ensft1-uk-vla370-10-63-23-107.cisco.com [10.63.23.107]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0BFChAu004043; Wed, 11 Jan 2017 15:12:43 GMT To: Martin Bjorklund , andy@yumaworks.com References: <6425C57C-C3DF-4099-AE77-4521B58B8D69@juniper.net> <20170111.102209.310040071380723970.mbj@tail-f.com> From: Robert Wilton Message-ID: <9d4c54bf-ac6f-0d64-0361-668f9a793cd1@cisco.com> Date: Wed, 11 Jan 2017 15:12:42 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <20170111.102209.310040071380723970.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 15:12:50 -0000 On 11/01/2017 09:22, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen wrote: >> >>>> I think it is better to have a human decide what is in the module >>>> instead of relying on a pyang plugin to generate some additional module >>>> that follows some simplistic pattern. >>> It may be simple, but I’m thinking that’s only because it’s not tricky ;) >>> >>> >> The client and server developers still need to know about this >> auto-generated module >> and implement it. Operators might have to know about it to use it. My idea is not to auto generate models on the fly. My aim is to allow folks to start writing models in the desired long term format (i.e. combined config and state tree) with the model designer being able to assume the existence of the operational state datastore. The tooling would be there to statically generate the extra foo-state config false node modules for servers that don't support the operational state datastore. This could be done once, and the extra foo-state modules committed to the github YANG respository in the same way that models are extracted from IETF RFCs today. The aim here is that the single model being produced by IETF would be usable both by new client/servers that support an operational state datastore, and also by existing NETCONF client/servers that don't implement an operational state datastore. I'm not proposing that as a long term solution, but as a path to make it easier for folk to migrate, and to not slow down the model writing effort. Otherwise, it may be hard to get a protocol model writer to design the YANG model in a way that is not fully usable on any current devices. As an illustration, an RFC published combined ietf-interfaces model may look like this: module: ietf-interfaces-combined +--rw interfaces +--rw interface* [name] +--rw name string +--rw description? string +--rw type identityref +--rw enabled? boolean +--rw link-up-down-trap-enable? enumeration {if-mib}? +--ro oper-status enumeration +--ro last-change? yang:date-and-time +--ro if-index int32 {if-mib}? +--ro phys-address? yang:phys-address +--ro higher-layer-if* interface-ref +--ro lower-layer-if* interface-ref +--ro speed? yang:gauge64 +--ro statistics +--ro discontinuity-time yang:date-and-time +--ro in-octets? yang:counter64 +--ro in-unicast-pkts? yang:counter64 +--ro in-broadcast-pkts? yang:counter64 +--ro in-multicast-pkts? yang:counter64 +--ro in-discards? yang:counter32 +--ro in-errors? yang:counter32 +--ro in-unknown-protos? yang:counter32 +--ro out-octets? yang:counter64 +--ro out-unicast-pkts? yang:counter64 +--ro out-broadcast-pkts? yang:counter64 +--ro out-multicast-pkts? yang:counter64 +--ro out-discards? yang:counter32 +--ro out-errors? yang:counter32 The extra generated model would look like this: module: ietf-interfaces-combined-state +--ro interfaces-state +--ro interface* [name] +--ro name string +--ro description? string +--ro type identityref +--ro enabled? boolean +--ro link-up-down-trap-enable? enumeration {if:if-mib}? +--ro oper-status enumeration +--ro last-change? yang:date-and-time +--ro if-index int32 {if:if-mib}? +--ro phys-address? yang:phys-address +--ro higher-layer-if* if:interface-ref +--ro lower-layer-if* if:interface-ref +--ro speed? yang:gauge64 +--ro statistics +--ro discontinuity-time yang:date-and-time +--ro in-octets? yang:counter64 +--ro in-unicast-pkts? yang:counter64 +--ro in-broadcast-pkts? yang:counter64 +--ro in-multicast-pkts? yang:counter64 +--ro in-discards? yang:counter32 +--ro in-errors? yang:counter32 +--ro in-unknown-protos? yang:counter32 +--ro out-octets? yang:counter64 +--ro out-unicast-pkts? yang:counter64 +--ro out-broadcast-pkts? yang:counter64 +--ro out-multicast-pkts? yang:counter64 +--ro out-discards? yang:counter32 +--ro out-errors? yang:counter32 Servers that support operational-state would just implement ietf-interfaces-combined Servers that don't support operational-state could implement ietf-interfaces-combined and ietf-interfaces-combined-state, probably not implementing the duplicate config false leaves under the interfaces config tree. Deviations could also be auto-generated to remove the config false leaves from the config tree so that they are only in the state tree. Of course, Clients may need to support both schemes depending on what types of devices they are interacting with. Finally, I've illustrated this using ietf-interfaces, but I'm not actually proposing immediately changing that model. I was more thinking about IETF protocols that in the process of working on their YANG models. Rob > Exactly. I agree that this is a real hack. Implementations can use > whatever transformation tricks they want in order to comply with > different standards, but the standard modules should be very clear. > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Jan 11 07:18:17 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6762F129485; Wed, 11 Jan 2017 07:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4KqN_SJ9pwz; Wed, 11 Jan 2017 07:18:14 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC43128E19; Wed, 11 Jan 2017 07:18:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4124; q=dns/txt; s=iport; t=1484147894; x=1485357494; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=2OL/15lsPvFtaWxcmUtNPLK9EC9YLEspXI8JZXd5gIM=; b=OQkSVbtDjN9Ah76zie/k4+FMU+IbeWlv91Im7d4SRE/RDjMMciYk2Y5L hM8euAkcrspvGHbMGPVus3D1hGoykZ+v7oliXVTaXksVkgVTzCIupXFet rsCOOBUhy0o/9kTCX9V3fyZ6A3RBhQEKbn5eH1nWRF/CmnxDsS2YicCuq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3AQALTHZY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzsBAQEBAX4DLF6NV3KRIZUnggsfC4UuSgKCORQBAgEBAQEBAQF?= =?us-ascii?q?jKIRpAQEBAwEBATY2CxALGCMLJzAGDQYCAQGIdAgOsm2KFQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFhkWCAgiCV4osBZsqkVOBd4g2I4YVimaHex84gRMSBxUVOoQ?= =?us-ascii?q?0HBiBRz41iGYBAQE?= X-IronPort-AV: E=Sophos;i="5.33,346,1477958400"; d="scan'208";a="691253264" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2017 15:18:09 +0000 Received: from [10.63.23.107] (dhcp-ensft1-uk-vla370-10-63-23-107.cisco.com [10.63.23.107]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0BFI98I005560; Wed, 11 Jan 2017 15:18:09 GMT To: Ladislav Lhotka References: <2C96B1C8-3D97-41FF-AD91-44432868C5CF@nic.cz> <20170111.132759.746322711124349871.mbj@tail-f.com> <25050412-8C71-44E7-8865-24320902ED2D@nic.cz> <20170111.135359.1145355019648401300.mbj@tail-f.com> <74141E09-06C2-439E-BA85-81E3FC12DD17@nic.cz> <203F849C-A116-4C48-A3F3-98D2F31D12A8@nic.cz> From: Robert Wilton Message-ID: <3d286f25-f383-8029-639c-5091838190c6@cisco.com> Date: Wed, 11 Jan 2017 15:18:09 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <203F849C-A116-4C48-A3F3-98D2F31D12A8@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Netconf , NetMod WG Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 15:18:16 -0000 On 11/01/2017 14:48, Ladislav Lhotka wrote: >> On 11 Jan 2017, at 15:18, Robert Wilton wrote: >> >> Hi, >> >> On 11/01/2017 13:05, Ladislav Lhotka wrote: >>>> On 11 Jan 2017, at 13:53, Martin Bjorklund wrote: >>>> >>>> Ladislav Lhotka wrote: >> >>>>> Show me a single YANG data node definition that's duplicate in my >>>>> concept above. But then maybe I didn't explain it properly. >>>> The interface's "type" leaf. With the new operational-state >>>> datastore, /interfaces/interface/type in operational-state and >>>> /interfaces-state/interface/type are duplicate. >>> As I said, ietf-interfaces-state state would consist of augments containing extra state nodes (i.e. those that are not in configuration). So "type" won't be there. >> I think that this effectively just achieves the same thing that the "config: true|false" statement indicates in a combined config/state tree. >> >> Personally, I think that a file of augmentations is probably going to be harder to read than having the config and state schema in one tree in one file. > Possibly we could also use schema mount. On the other hand, it doesn't enforce the use of operational-state datastore. A simple device like a WiFi-controlled electric socket could easily use just ietf-interfaces-config (and ietf-ip-config), i.e. no state data. > > Another example I am dealing with now is OpenWRT: with some effort, it would be possible to translate our nice configuration data into UCI files without touching the OpenWRT system itself. On the other hand, serving state data according to our YANG modules is a non-starter. Isn't the proper answer here to generate deviations to remove the state leaves that won't be implemented. > >> The models may also be slightly more inconvenient to use because the state tree leaves would presumably be in a different namespace from the configuration? >> > Yes, but I don't think it is a big problem - even for human readers. I'm not sure. I think that you might end up with a variation of the OpenConfig models, and based on experience I would say that those models are hard to read if they haven't been compiled first to expand the groupings and reveal the actual structure. Rob > >> If you wanted this file level split then using submodules would allow for separate config/state files but still be managed as a single combined module. > But it means you have to implement both. > > Lada > >> Rob >> >> >>>>> Note also that you slightly misinterpreted my statement that you >>>>> cited: >>>>> >>>>> I believe both the protocols and YANG can work with any set of >>>>> datastores [...] >>>>> >>>>> I didn't say that there cannot be *modules* that are somehow designed >>>>> for a particular datastore model - I meant YANG the language. >>>> Ok. Yes, you're right, but then we'd probably need some new statement >>>> in each module that tells which meta-model the YANG module is written >>>> for. >>> I would prefer to have it as state data, basically separate YANG libraries for configuration datastores and operational-state. >> >>> Lada >>> >>>> /martin >>>> >>>> >>>>> Lada >>>>> >>>>>> /martin >>>>>> >>>>>> >>>>>>> Am I completely misguided here? If not, then I don't see where the new >>>>>>> modules refer to any particular datastore model. Yes, they do reflect >>>>>>> that there is configuration and state data, but we don't want to get >>>>>>> rid of this distinction, right? >>>>>>> >>>>>>> Lada >>>>>>> >>>>>>>> >>>>>>>> /martin >>>>>>> -- >>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>> PGP Key ID: 0xB8F92B08A9F76C67 >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: 0xB8F92B08A9F76C67 >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: 0xB8F92B08A9F76C67 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> . > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > . > From nobody Wed Jan 11 07:37:24 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C463C1294FC; Wed, 11 Jan 2017 07:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nD9i2ic8nwhS; Wed, 11 Jan 2017 07:37:19 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675D31294C5; Wed, 11 Jan 2017 07:37:19 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c] (unknown [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c]) by mail.nic.cz (Postfix) with ESMTPSA id 127B760A76; Wed, 11 Jan 2017 16:37:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484149038; bh=gtiNAr2djj5TwD6rfsDaDGzjraHEFZapiGQyDXx5msM=; h=From:Date:To; b=svygttnLBPuCNJgYm32fGW7PYrCE07E9aIQrkVysi7CdTqWegGFGeJJb/hHtvQLeA LJXCAc49CGwAo37lBpjrvlyUQyD/v9YULOIPN8YH8HrRKN5QskYfyT2lpDNp/8bcy8 39L+FbWJ+WsIM12/DzILVhEZKCWjA3O2VHFL77fs= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <3d286f25-f383-8029-639c-5091838190c6@cisco.com> Date: Wed, 11 Jan 2017 16:37:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <82A87092-828B-4838-B327-C05791FBB8A0@nic.cz> References: <2C96B1C8-3D97-41FF-AD91-44432868C5CF@nic.cz> <20170111.132759.746322711124349871.mbj@tail-f.com> <25050412-8C71-44E7-8865-24320902ED2D@nic.cz> <20170111.135359.1145355019648401300.mbj@tail-f.com> <74141E09-06C2-439E-BA85-81E3FC12DD17@nic.cz> <203F849C-A116-4C48-A3F3-98D2F31D12A8@nic.cz> <3d286f25-f383-8029-639c-5091838190c6@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf , NetMod WG Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 15:37:23 -0000 > On 11 Jan 2017, at 16:18, Robert Wilton wrote: >=20 >=20 >=20 > On 11/01/2017 14:48, Ladislav Lhotka wrote: >>> On 11 Jan 2017, at 15:18, Robert Wilton wrote: >>>=20 >>> Hi, >>>=20 >>> On 11/01/2017 13:05, Ladislav Lhotka wrote: >>>>> On 11 Jan 2017, at 13:53, Martin Bjorklund wrote: >>>>>=20 >>>>> Ladislav Lhotka wrote: >>> >>>>>> Show me a single YANG data node definition that's duplicate in my >>>>>> concept above. But then maybe I didn't explain it properly. >>>>> The interface's "type" leaf. With the new operational-state >>>>> datastore, /interfaces/interface/type in operational-state and >>>>> /interfaces-state/interface/type are duplicate. >>>> As I said, ietf-interfaces-state state would consist of augments = containing extra state nodes (i.e. those that are not in configuration). = So "type" won't be there. >>> I think that this effectively just achieves the same thing that the = "config: true|false" statement indicates in a combined config/state = tree. >>>=20 >>> Personally, I think that a file of augmentations is probably going = to be harder to read than having the config and state schema in one tree = in one file. >> Possibly we could also use schema mount. On the other hand, it = doesn't enforce the use of operational-state datastore. A simple device = like a WiFi-controlled electric socket could easily use just = ietf-interfaces-config (and ietf-ip-config), i.e. no state data. >>=20 >> Another example I am dealing with now is OpenWRT: with some effort, = it would be possible to translate our nice configuration data into UCI = files without touching the OpenWRT system itself. On the other hand, = serving state data according to our YANG modules is a non-starter. > Isn't the proper answer here to generate deviations to remove the = state leaves that won't be implemented. This is of course possible but deviations are generally frowned upon, so = why not use the modularity features for making it a little more = flexible? I know some people will now say that without state data it is = no proper network management but, speaking pragmatically, automated = configuration would be a big boon by itself. >=20 >>=20 >>> The models may also be slightly more inconvenient to use because the = state tree leaves would presumably be in a different namespace from the = configuration? >>>=20 >> Yes, but I don't think it is a big problem - even for human readers. > I'm not sure. I think that you might end up with a variation of the = OpenConfig models, and based on experience I would say that those models = are hard to read if they haven't been compiled first to expand the = groupings and reveal the actual structure. One thing that makes modules really hard to read are augments, and we = already have them all over the place. It's a trade-off between = readability and modularity. Lada >=20 > Rob >=20 >=20 >>=20 >>> If you wanted this file level split then using submodules would = allow for separate config/state files but still be managed as a single = combined module. >> But it means you have to implement both. >>=20 >> Lada >>=20 >>> Rob >>>=20 >>>=20 >>>>>> Note also that you slightly misinterpreted my statement that you >>>>>> cited: >>>>>>=20 >>>>>> I believe both the protocols and YANG can work with any set of >>>>>> datastores [...] >>>>>>=20 >>>>>> I didn't say that there cannot be *modules* that are somehow = designed >>>>>> for a particular datastore model - I meant YANG the language. >>>>> Ok. Yes, you're right, but then we'd probably need some new = statement >>>>> in each module that tells which meta-model the YANG module is = written >>>>> for. >>>> I would prefer to have it as state data, basically separate YANG = libraries for configuration datastores and operational-state. >>>=20 >>>> Lada >>>>=20 >>>>> /martin >>>>>=20 >>>>>=20 >>>>>> Lada >>>>>>=20 >>>>>>> /martin >>>>>>>=20 >>>>>>>=20 >>>>>>>> Am I completely misguided here? If not, then I don't see where = the new >>>>>>>> modules refer to any particular datastore model. Yes, they do = reflect >>>>>>>> that there is configuration and state data, but we don't want = to get >>>>>>>> rid of this distinction, right? >>>>>>>>=20 >>>>>>>> Lada >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> /martin >>>>>>>> -- >>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>> PGP Key ID: 0xB8F92B08A9F76C67 >>>>>> -- >>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>> PGP Key ID: 0xB8F92B08A9F76C67 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: 0xB8F92B08A9F76C67 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >>>> . >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >>=20 >>=20 >>=20 >>=20 >>=20 >> . -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jan 11 08:34:54 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4E712998B for ; Wed, 11 Jan 2017 08:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvSuURVBvgYS for ; Wed, 11 Jan 2017 08:34:51 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47AB2129A68 for ; Wed, 11 Jan 2017 08:34:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1048; q=dns/txt; s=iport; t=1484152491; x=1485362091; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YPQvPwwbO6O+jqs2k6mUi43DoE5yzcVwwC657f/wle4=; b=ARPr5XhW/8l0e1DsXFmjiE5IV90jO2jzjgrOfS22KFeTSudQ+OJ9pbEC wFBE3OMvekTyb0EAtuFhBS17f/ivXZzXma4lF85afK9g8MhY8aMNRnYzT Cb/fnecI/hwqFKn/90dpuOR7X3ECHCuZJLXkiDLurgfkKyqoDonUAKws5 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQDTXXZY/5NdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzsBAQEBAR+BbAeNUKc6gguGIgIagWg/FAECAQEBAQEBAWMohGo?= =?us-ascii?q?GHQYRRRACAQgODAImAgICMBUQAgQOBYkAsHSCJYoVAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBHYELhTqCAoJfhEaDCC2CMQEEmyoBkVKBd45uiBGKTwEfOIFBFUoBhh5?= =?us-ascii?q?zh1mBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,346,1477958400"; d="scan'208";a="191592806" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2017 16:34:50 +0000 Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v0BGYoPF023232 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Jan 2017 16:34:50 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 11 Jan 2017 10:34:49 -0600 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1210.000; Wed, 11 Jan 2017 10:34:49 -0600 From: "Clyde Wildes (cwildes)" To: Kent Watsen Thread-Topic: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 Thread-Index: AQHSa3iCf0zqhzKmtE+Zpe9My2EhJqEzWMiA Date: Wed, 11 Jan 2017 16:34:49 +0000 Message-ID: References: <6C644FF6-BA30-4B3F-814F-929333300D7A@juniper.net> In-Reply-To: <6C644FF6-BA30-4B3F-814F-929333300D7A@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.27.7.182] Content-Type: text/plain; charset="utf-8" Content-ID: <156DA8399A7196498F30A19F44A81595@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 16:34:53 -0000 S2VudCwNCg0KSSB3aWxsIHJlc3BvbmQgdG8gQW5keeKAmXMgY29tbWVudHMgdGhpcyBtb3JuaW5n IGFuZCBwdWJsaXNoIGEgbmV3IGRyYWZ0IEFTQVAuIEl0IHdvdWxkIGJlIHZlcnkgaGVscGZ1bCBp ZiBBbmR5IGFuZCBBbGV4IGNvdWxkIHdvcmsgd2l0aCBtZSBvbiB0aGUgbmV3IGRyYWZ0Lg0KDQpU aGFua3MsDQoNCkNseWRlDQoNCk9uIDEvMTAvMTcsIDExOjM0IEFNLCAiS2VudCBXYXRzZW4iIDxr d2F0c2VuQGp1bmlwZXIubmV0PiB3cm90ZToNCg0KICAgIEhpIENseWRlLA0KICAgIA0KICAgIFRo ZSBMQyBwZXJpb2QgaGFzIGVuZGVkLiAgV2hpbGUgd2Ugb25seSByZWNlaXZlZCB0d28gcmV2aWV3 cywgSSB0aGluayBib3RoIHdlcmUgcXVpdGUgZ29vZCBhbmQgdGhvcm91Z2ggYW5kLCBhcyBmYXIg YXMgSSBjYW4gdGVsbCwgZW50YWlsIG5lZWRpbmcgYSBub24tdHJpdmlhbCB1cGRhdGUgdG8gdGhl IGRyYWZ0Lg0KICAgIA0KICAgIE15IHRob3VnaHRzIGFyZSB0aGF0IHlvdSBzaG91bGQgY29udGlu dWUgd29ya2luZyB3aXRoIEFsZXggYW5kIEFuZHkgdG8gZW5zdXJlIHRoZWlyIGlzc3VlcyBhcmUg cmVzb2x2ZWQsIGFuZCB0aGVuIHBvc3QgYW4gdXBkYXRlZCBkcmFmdCB0aGF0IHdlIGNhbiBydW4g YW5vdGhlciBMQyBvbiB3aXRoIHRoZSBob3BlIG9mIGdldHRpbmcgYSBsYXJnZXIgcmVzcG9uc2Uu ICBNYWtlcyBzZW5zZT8NCiAgICANCiAgICBLZW50IC8vIGFzIHNoZXBoZXJkDQogICAgDQogICAg DQogICAgDQogICAgDQogICAgDQoNCg== From nobody Wed Jan 11 08:56:22 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF629129CF3 for ; Wed, 11 Jan 2017 08:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rszbRqFHbmH5 for ; Wed, 11 Jan 2017 08:56:16 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D0D0129BC5 for ; Wed, 11 Jan 2017 08:56:16 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id u25so598841322qki.2 for ; Wed, 11 Jan 2017 08:56:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MgKqjg2SESvZtiqDPU1pKJdYMfh7HjCTRlz+WDO/0aw=; b=N8OGmqBaPjJhFEWiNgid4yHPB/ZdqDdjksMnOyGTVQC3Vd7FSzll5Yr/ctZZnDnTM7 lgyuk+ZCXhaoMy21Lr8O7SCTJMoHvRndBKnfT5UVQqyqVv0PCNCpnvDgUCLD0xlCrfta 3Axkr1URfQ57FP80a7mgoUji4vU9OQI5GUgQc1knB1fMihWthtRmnJHe99Jjgy9hT3UU FEHYewI0TH2dIOpBKKRZEfFayxt3UBYKQi7uM/qKaL2DDaKOCAAL+9LB4GikIXHi1dRX eeQ1RNE5Oc/NibXyv9IemOvCKGi5UQWjSBeJ1rd/Yb6HdM8Zt9aszFJnWwZ2dM3LikvC VgiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MgKqjg2SESvZtiqDPU1pKJdYMfh7HjCTRlz+WDO/0aw=; b=ZKRGEr46YwcgxNCbxTPhMQr3npB7QaY29rXKiZ4C+kFBWaW72MRig4bV30JTxrRzB9 EAa/Rg9vk1ydrDYixDmIpqK7cQLADO5d6jFowAuOaOzpgkhR6HzfPBHKn24WbbOcQXYg lMDXMtunGo9PXvjeaIvPYQHsORs85GWqKE4/tU7INX9JDifNpCgQjLQmldbVmfOprU/J sb1uiHYR9NXsroJSFYoCGg5g/A30vtq6uHRn4V8L6dT9Szzas22Lw+dv0rjIxqUsbE/E 1mnzEmRPZpQnR+7yKTrkRQ/4P6ZLZYgqzvuOZEv7FpT77Vinj2fAZDM4M+quMAJ6zrPl 5cuA== X-Gm-Message-State: AIkVDXIyXNgTGic3XVpxgwRoWOCWREMfgeP8OHnChG/bJ7/2Yc8+d9VqBB0JcK0zDQFuGfJPj23IZzk8Wy2NpA== X-Received: by 10.55.7.2 with SMTP id 2mr10347559qkh.228.1484153775264; Wed, 11 Jan 2017 08:56:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Wed, 11 Jan 2017 08:56:14 -0800 (PST) In-Reply-To: <9d4c54bf-ac6f-0d64-0361-668f9a793cd1@cisco.com> References: <6425C57C-C3DF-4099-AE77-4521B58B8D69@juniper.net> <20170111.102209.310040071380723970.mbj@tail-f.com> <9d4c54bf-ac6f-0d64-0361-668f9a793cd1@cisco.com> From: Andy Bierman Date: Wed, 11 Jan 2017 08:56:14 -0800 Message-ID: To: Robert Wilton Content-Type: multipart/alternative; boundary=001a114c877c91307d0545d47a49 Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 16:56:19 -0000 --001a114c877c91307d0545d47a49 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton wrote: > > > On 11/01/2017 09:22, Martin Bjorklund wrote: > >> Andy Bierman wrote: >> >>> On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen >>> wrote: >>> >>> I think it is better to have a human decide what is in the module >>>>> instead of relying on a pyang plugin to generate some additional modu= le >>>>> that follows some simplistic pattern. >>>>> >>>> It may be simple, but I=E2=80=99m thinking that=E2=80=99s only because= it=E2=80=99s not tricky >>>> ;) >>>> >>>> >>>> The client and server developers still need to know about this >>> auto-generated module >>> and implement it. Operators might have to know about it to use it. >>> >> My idea is not to auto generate models on the fly. > > My aim is to allow folks to start writing models in the desired long term > format (i.e. combined config and state tree) with the model designer bein= g > able to assume the existence of the operational state datastore. > > I am not convinced this "new format" has solved anything. Don't you need separate description-stmts in every node for each datastore? What does the value mean if pre-configured? configured? operational? Will the auto-generated objects be exactly correct and never need any alterations or additional text? They still need to be used by developers and YANG tools. Is is that realistic to force the config structure and operational structur= e to be the same? Seems it is quite common to monitor data structures with additional keys or different keys. This is completely unsupported so separate /foo and /foo-state trees will still exist. IMO this combination of trees needs to be proven. Take ietf-interfaces and show how much better it will work if the /interfaces and /interfaces-state trees were combined. Andy The tooling would be there to statically generate the extra foo-state > config false node modules for servers that don't support the operational > state datastore. This could be done once, and the extra foo-state module= s > committed to the github YANG respository in the same way that models are > extracted from IETF RFCs today. > > The aim here is that the single model being produced by IETF would be > usable both by new client/servers that support an operational state > datastore, and also by existing NETCONF client/servers that don't impleme= nt > an operational state datastore. > > I'm not proposing that as a long term solution, but as a path to make it > easier for folk to migrate, and to not slow down the model writing effort= . > Otherwise, it may be hard to get a protocol model writer to design the YA= NG > model in a way that is not fully usable on any current devices. > > As an illustration, an RFC published combined ietf-interfaces model may > look like this: > > module: ietf-interfaces-combined > +--rw interfaces > +--rw interface* [name] > +--rw name string > +--rw description? string > +--rw type identityref > +--rw enabled? boolean > +--rw link-up-down-trap-enable? enumeration {if-mib}? > +--ro oper-status enumeration > +--ro last-change? yang:date-and-time > +--ro if-index int32 {if-mib}? > +--ro phys-address? yang:phys-address > +--ro higher-layer-if* interface-ref > +--ro lower-layer-if* interface-ref > +--ro speed? yang:gauge64 > +--ro statistics > +--ro discontinuity-time yang:date-and-time > +--ro in-octets? yang:counter64 > +--ro in-unicast-pkts? yang:counter64 > +--ro in-broadcast-pkts? yang:counter64 > +--ro in-multicast-pkts? yang:counter64 > +--ro in-discards? yang:counter32 > +--ro in-errors? yang:counter32 > +--ro in-unknown-protos? yang:counter32 > +--ro out-octets? yang:counter64 > +--ro out-unicast-pkts? yang:counter64 > +--ro out-broadcast-pkts? yang:counter64 > +--ro out-multicast-pkts? yang:counter64 > +--ro out-discards? yang:counter32 > +--ro out-errors? yang:counter32 > > The extra generated model would look like this: > > module: ietf-interfaces-combined-state > +--ro interfaces-state > +--ro interface* [name] > +--ro name string > +--ro description? string > +--ro type identityref > +--ro enabled? boolean > +--ro link-up-down-trap-enable? enumeration {if:if-mib}? > +--ro oper-status enumeration > +--ro last-change? yang:date-and-time > +--ro if-index int32 {if:if-mib}? > +--ro phys-address? yang:phys-address > +--ro higher-layer-if* if:interface-ref > +--ro lower-layer-if* if:interface-ref > +--ro speed? yang:gauge64 > +--ro statistics > +--ro discontinuity-time yang:date-and-time > +--ro in-octets? yang:counter64 > +--ro in-unicast-pkts? yang:counter64 > +--ro in-broadcast-pkts? yang:counter64 > +--ro in-multicast-pkts? yang:counter64 > +--ro in-discards? yang:counter32 > +--ro in-errors? yang:counter32 > +--ro in-unknown-protos? yang:counter32 > +--ro out-octets? yang:counter64 > +--ro out-unicast-pkts? yang:counter64 > +--ro out-broadcast-pkts? yang:counter64 > +--ro out-multicast-pkts? yang:counter64 > +--ro out-discards? yang:counter32 > +--ro out-errors? yang:counter32 > > Servers that support operational-state would just implement > ietf-interfaces-combined > > Servers that don't support operational-state could implement > ietf-interfaces-combined and ietf-interfaces-combined-state, probably not > implementing the duplicate config false leaves under the interfaces confi= g > tree. Deviations could also be auto-generated to remove the config false > leaves from the config tree so that they are only in the state tree. > > Of course, Clients may need to support both schemes depending on what > types of devices they are interacting with. > > Finally, I've illustrated this using ietf-interfaces, but I'm not actuall= y > proposing immediately changing that model. I was more thinking about IET= F > protocols that in the process of working on their YANG models. > > Rob > > > Exactly. I agree that this is a real hack. Implementations can use >> whatever transformation tricks they want in order to comply with >> different standards, but the standard modules should be very clear. >> > > > > > >> >> /martin >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > --001a114c877c91307d0545d47a49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,


On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton <rwilton@cisco.= com> wrote:


On 11/01/2017 09:22, Martin Bjorklund wrote:
Andy Bierman <an= dy@yumaworks.com> wrote:
On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen <kwatsen@juniper.net> wrote:

I think it is better to have a human decide what is in the module
instead of relying on a pyang plugin to generate some additional module
that follows some simplistic pattern.
It may be simple, but I=E2=80=99m thinking that=E2=80=99s only because it= =E2=80=99s not tricky=C2=A0 ;)


The client and server developers still need to know about this
auto-generated module
and implement it.=C2=A0 Operators might have to know about it to use it.
My idea is not to auto generate models on the fly.

My aim is to allow folks to start writing models in the desired long term f= ormat (i.e. combined config and state tree) with the model designer being a= ble to assume the existence of the operational state datastore.



I am not convinced this= "new format" has solved anything.
Don't you need s= eparate description-stmts in every node for each
datastore?=C2=A0= What does the value mean if pre-configured? configured?
operatio= nal?=C2=A0 Will the auto-generated objects be exactly correct
and= never need any alterations or additional text?
They still need t= o be used by developers and YANG tools.

Is is that= realistic to force the config structure and operational structure
to be the same? Seems it is quite common to monitor data structures
=
with additional keys or different keys.=C2=A0 This is completely unsup= ported
so separate /foo and /foo-state trees will still exist.

IMO this combination of trees needs to be proven.
Take ietf-interfaces and show how much better it will work
if the /interfaces and /interfaces-state trees were combined.
<= br>

Andy


The tooling would be there to statically generate the extra foo-state confi= g false node modules for servers that don't support the operational sta= te datastore.=C2=A0 This could be done once, and the extra foo-state module= s committed to the github YANG respository in the same way that models are = extracted from IETF RFCs today.

The aim here is that the single model being produced by IETF would be usabl= e both by new client/servers that support an operational state datastore, a= nd also by existing NETCONF client/servers that don't implement an oper= ational state datastore.

I'm not proposing that as a long term solution, but as a path to make i= t easier for folk to migrate, and to not slow down the model writing effort= .=C2=A0 Otherwise, it may be hard to get a protocol model writer to design = the YANG model in a way that is not fully usable on any current devices.
As an illustration, an RFC published combined ietf-interfaces model may loo= k like this:

module: ietf-interfaces-combined
=C2=A0 =C2=A0 +--rw interfaces
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw interface* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw name=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw description?=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw type=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 identityref
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw enabled?=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 boolean
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw link-up-down-trap-enable?=C2=A0 = =C2=A0enumeration {if-mib}?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro oper-status=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enumeration
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro last-change? yang:date-and-time =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro if-index=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int32 {if-mib}?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro phys-address? yang:phys-address =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro higher-layer-if*=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 interface-ref
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro lower-layer-if*=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interface-ref
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro speed?=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:gauge64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro statistics
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro discontinuity-time=C2= =A0 =C2=A0 yang:date-and-time
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-octets?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-unicast-pkts?=C2= =A0 =C2=A0 =C2=A0 yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-broadcast-pkts?=C2= =A0 =C2=A0 yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-multicast-pkts?=C2= =A0 =C2=A0 yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-discards?=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-errors?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-unknown-protos?=C2= =A0 =C2=A0 yang:counter32
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-octets?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-unicast-pkts?=C2= =A0 =C2=A0 =C2=A0yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-broadcast-pkts?= =C2=A0 =C2=A0yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-multicast-pkts?= =C2=A0 =C2=A0yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-discards?=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-errors?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32

The extra generated model would look like this:

module: ietf-interfaces-combined-state
=C2=A0 =C2=A0 +--ro interfaces-state
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro interface* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro name=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro description?=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro type=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 identityref
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro enabled?=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 boolean
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro link-up-down-trap-enable?=C2=A0 = =C2=A0enumeration {if:if-mib}?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro oper-status=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enumeration
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro last-change? yang:date-and-time =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro if-index=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int32 {if:if-mib}?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro phys-address? yang:phys-address =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro higher-layer-if* if:interface-ref<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro lower-layer-if* if:interface-ref =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro speed?=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:gauge64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro statistics
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro discontinuity-time=C2= =A0 =C2=A0 yang:date-and-time
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-octets?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-unicast-pkts?=C2= =A0 =C2=A0 =C2=A0 yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-broadcast-pkts?=C2= =A0 =C2=A0 yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-multicast-pkts?=C2= =A0 =C2=A0 yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-discards?=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-errors?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-unknown-protos?=C2= =A0 =C2=A0 yang:counter32
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-octets?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-unicast-pkts?=C2= =A0 =C2=A0 =C2=A0yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-broadcast-pkts?= =C2=A0 =C2=A0yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-multicast-pkts?= =C2=A0 =C2=A0yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-discards?=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-errors?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32

Servers that support operational-state would just implement ietf-interfaces= -combined

Servers that don't support operational-state could implement ietf-inter= faces-combined and ietf-interfaces-combined-state, probably not implem= enting the duplicate config false leaves under the interfaces config tree.= =C2=A0 Deviations could also be auto-generated to remove the config false l= eaves from the config tree so that they are only in the state tree.

Of course, Clients may need to support both schemes depending on what types= of devices they are interacting with.

Finally, I've illustrated this using ietf-interfaces, but I'm not a= ctually proposing immediately changing that model.=C2=A0 I was more thinkin= g about IETF protocols that in the process of working on their YANG models.=

Rob


Exactly.=C2=A0 I agree that this is a real hack.=C2=A0 Implementations can = use
whatever transformation tricks they want in order to comply with
different standards, but the standard modules should be very clear.






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


--001a114c877c91307d0545d47a49-- From nobody Wed Jan 11 09:21:22 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4FA12960B; Wed, 11 Jan 2017 09:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yw_VfXH3cu7W; Wed, 11 Jan 2017 09:21:19 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE52129610; Wed, 11 Jan 2017 09:21:18 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c] (unknown [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c]) by mail.nic.cz (Postfix) with ESMTPSA id 5261E60CAF; Wed, 11 Jan 2017 18:21:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484155277; bh=U3IOHnchTbxuDyoCYtO8p6ftJuvst5WUq2IlEkVPYUI=; h=From:Date:To; b=bmCtn8zy+UTK8DwN7hzZRM5HLhMekrxP9IKcQ49LqhqfbkL7lLhmM6XSvrMUuYE9J U5hKviRw31wIwezAYAQ3QSxypaRUfu1OgqctoBTkOm++T8W+58I0eBxT2ekFxBS1yP p/QbNA0KEYsb50zpbdW89VpYzCIPYHsbS6P3DWWg= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 11 Jan 2017 18:21:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> References: <6425C57C-C3DF-4099-AE77-4521B58B8D69@juniper.net> <20170111.102209.310040071380723970.mbj@tail-f.com> <9d4c54bf-ac6f-0d64-0361-668f9a793cd1@cisco.com> To: Andy Bierman X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 17:21:21 -0000 > On 11 Jan 2017, at 17:56, Andy Bierman wrote: >=20 > Hi, >=20 >=20 > On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton = wrote: >=20 >=20 > On 11/01/2017 09:22, Martin Bjorklund wrote: > Andy Bierman wrote: > On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen = wrote: >=20 > I think it is better to have a human decide what is in the module > instead of relying on a pyang plugin to generate some additional = module > that follows some simplistic pattern. > It may be simple, but I=E2=80=99m thinking that=E2=80=99s only because = it=E2=80=99s not tricky ;) >=20 >=20 > The client and server developers still need to know about this > auto-generated module > and implement it. Operators might have to know about it to use it. > My idea is not to auto generate models on the fly. >=20 > My aim is to allow folks to start writing models in the desired long = term format (i.e. combined config and state tree) with the model = designer being able to assume the existence of the operational state = datastore. >=20 >=20 >=20 > I am not convinced this "new format" has solved anything. > Don't you need separate description-stmts in every node for each > datastore? What does the value mean if pre-configured? configured? > operational? Will the auto-generated objects be exactly correct > and never need any alterations or additional text? > They still need to be used by developers and YANG tools. Right, this is one problem of this "deduplication": even if two nodes - = one config and the other state - have the same name or even type (which = is not always the case, as we know), their semantics is often different. = An IP address in configuration means a manually configured address = whereas in state it may come from any source. So writing sensible = descriptions will become tricky. >=20 > Is is that realistic to force the config structure and operational = structure > to be the same? Seems it is quite common to monitor data structures > with additional keys or different keys. This is completely = unsupported > so separate /foo and /foo-state trees will still exist. I agree. Lada >=20 > IMO this combination of trees needs to be proven. > Take ietf-interfaces and show how much better it will work > if the /interfaces and /interfaces-state trees were combined. >=20 >=20 > Andy >=20 >=20 > The tooling would be there to statically generate the extra foo-state = config false node modules for servers that don't support the operational = state datastore. This could be done once, and the extra foo-state = modules committed to the github YANG respository in the same way that = models are extracted from IETF RFCs today. >=20 > The aim here is that the single model being produced by IETF would be = usable both by new client/servers that support an operational state = datastore, and also by existing NETCONF client/servers that don't = implement an operational state datastore. >=20 > I'm not proposing that as a long term solution, but as a path to make = it easier for folk to migrate, and to not slow down the model writing = effort. Otherwise, it may be hard to get a protocol model writer to = design the YANG model in a way that is not fully usable on any current = devices. >=20 > As an illustration, an RFC published combined ietf-interfaces model = may look like this: >=20 > module: ietf-interfaces-combined > +--rw interfaces > +--rw interface* [name] > +--rw name string > +--rw description? string > +--rw type identityref > +--rw enabled? boolean > +--rw link-up-down-trap-enable? enumeration {if-mib}? > +--ro oper-status enumeration > +--ro last-change? yang:date-and-time > +--ro if-index int32 {if-mib}? > +--ro phys-address? yang:phys-address > +--ro higher-layer-if* interface-ref > +--ro lower-layer-if* interface-ref > +--ro speed? yang:gauge64 > +--ro statistics > +--ro discontinuity-time yang:date-and-time > +--ro in-octets? yang:counter64 > +--ro in-unicast-pkts? yang:counter64 > +--ro in-broadcast-pkts? yang:counter64 > +--ro in-multicast-pkts? yang:counter64 > +--ro in-discards? yang:counter32 > +--ro in-errors? yang:counter32 > +--ro in-unknown-protos? yang:counter32 > +--ro out-octets? yang:counter64 > +--ro out-unicast-pkts? yang:counter64 > +--ro out-broadcast-pkts? yang:counter64 > +--ro out-multicast-pkts? yang:counter64 > +--ro out-discards? yang:counter32 > +--ro out-errors? yang:counter32 >=20 > The extra generated model would look like this: >=20 > module: ietf-interfaces-combined-state > +--ro interfaces-state > +--ro interface* [name] > +--ro name string > +--ro description? string > +--ro type identityref > +--ro enabled? boolean > +--ro link-up-down-trap-enable? enumeration {if:if-mib}? > +--ro oper-status enumeration > +--ro last-change? yang:date-and-time > +--ro if-index int32 {if:if-mib}? > +--ro phys-address? yang:phys-address > +--ro higher-layer-if* if:interface-ref > +--ro lower-layer-if* if:interface-ref > +--ro speed? yang:gauge64 > +--ro statistics > +--ro discontinuity-time yang:date-and-time > +--ro in-octets? yang:counter64 > +--ro in-unicast-pkts? yang:counter64 > +--ro in-broadcast-pkts? yang:counter64 > +--ro in-multicast-pkts? yang:counter64 > +--ro in-discards? yang:counter32 > +--ro in-errors? yang:counter32 > +--ro in-unknown-protos? yang:counter32 > +--ro out-octets? yang:counter64 > +--ro out-unicast-pkts? yang:counter64 > +--ro out-broadcast-pkts? yang:counter64 > +--ro out-multicast-pkts? yang:counter64 > +--ro out-discards? yang:counter32 > +--ro out-errors? yang:counter32 >=20 > Servers that support operational-state would just implement = ietf-interfaces-combined >=20 > Servers that don't support operational-state could implement = ietf-interfaces-combined and ietf-interfaces-combined-state, probably = not implementing the duplicate config false leaves under the interfaces = config tree. Deviations could also be auto-generated to remove the = config false leaves from the config tree so that they are only in the = state tree. >=20 > Of course, Clients may need to support both schemes depending on what = types of devices they are interacting with. >=20 > Finally, I've illustrated this using ietf-interfaces, but I'm not = actually proposing immediately changing that model. I was more thinking = about IETF protocols that in the process of working on their YANG = models. >=20 > Rob >=20 >=20 > Exactly. I agree that this is a real hack. Implementations can use > whatever transformation tricks they want in order to comply with > different standards, but the standard modules should be very clear. >=20 >=20 >=20 >=20 >=20 >=20 > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jan 11 09:34:30 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06B81294D5 for ; Wed, 11 Jan 2017 09:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CA06nNmAod_K for ; Wed, 11 Jan 2017 09:34:27 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10B8412945F for ; Wed, 11 Jan 2017 09:34:27 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id 11so117572329qkl.3 for ; Wed, 11 Jan 2017 09:34:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yD7Cufkwr889CeKjSVHNK1jYlgkn7u3JH8M03UkdTpM=; b=pzHEXbJYP2MF/0yUlslIfnzWK6zLk+PFMoBjegP7nD9iDfx7aNxQ9kEosNo75pOm4N Oe5jycbcfHQ0TtdmagVwFj0fECBb/Ete49s5YR+3vC18UCF2ZW9/rHQu/se4NRpB8b96 gWiOwuJF0gV9VDvXKRZzHjaTr8lIrzFUfwh2QLEAj8c1bpjwQeRkKZRpWEp9c4V3ERm0 g1B0fgSir2+D6MR2PZWWj81Oyl9k7tCyWziW4Eq3G3bYNUHlfczTfmWhsi99j/SZ3pbH gp4N1e+cLdx4SuaYsGa0JuXeO44SWfr1kf9Uo7BcjqxJ+c5LFUj9PbdD9Ji2YZdvuvHw J3cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yD7Cufkwr889CeKjSVHNK1jYlgkn7u3JH8M03UkdTpM=; b=KDYua2O+uxo9oEORhCxWKvSXrXDQoGQE/kxF/4FLy1o5YljFlSfDq/yj8MdH6KwGrB DfUESMiUqjK8mCFLoabqNglwa1lkZQ3nBZkQ68qWiJy0RRLYdLt0rAfQELlssg7I9G28 j4YRFYcn0Vj+ZfhvCfJiWKjU5O9/E/q//QPEjqVL/7C1c3NePLa8ou49Dk1D5QuX3wd7 czktQihi2nGdyZ//3NfqB/hg1Cwa4wNEhHYervvd7Pzw2fYLsieRTk8Rd1e5cT19H4kd ra4lq4HIyfeRwrfU7AnJFpjQfJi1d5nVfzPPTw051BoFn9vE1yQhQV81xMS9IG/4m75D xD3A== X-Gm-Message-State: AIkVDXKqIl5ENUjUfMvoQ39h6aGUdA1atwW+8WPNFfnnV0vcySxnxbnAaylIWxi+nycUTcS+wtg2Q3a9qni7hA== X-Received: by 10.55.152.4 with SMTP id a4mr8788619qke.69.1484156066192; Wed, 11 Jan 2017 09:34:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Wed, 11 Jan 2017 09:34:25 -0800 (PST) In-Reply-To: <20170111.102729.1180268284224378559.mbj@tail-f.com> References: <20170111.102729.1180268284224378559.mbj@tail-f.com> From: Andy Bierman Date: Wed, 11 Jan 2017 09:34:25 -0800 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=94eb2c07ecfa1df3990545d503a2 Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 17:34:29 -0000 --94eb2c07ecfa1df3990545d503a2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jan 11, 2017 at 1:27 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Tue, Jan 10, 2017 at 4:53 PM, Kent Watsen > wrote: > > > > > Hi Andy, > > > > > > > > > > > > > Until the basic show-stoppers are solved, the redundant opstate > objects > > > are not important. > > > > > > > Removing the foo-state objects means they are now invisible wrt/ YA= NG > > > constraints > > > > > > > (must, when, leafref, min/max, etc). IMO this is a show-shopper. > YANG > > > can only cross-reference > > > > > > > YANG statements. Invisible opstate hiding behind a datastore label > > > seems elegant > > > > > > > wrt/ , but it looks like a disaster wrt/ YANG. > > > > > > > > > > > > Nothing has been removed. All the config false nodes are still > available, > > > but now they=E2=80=99re no longer separated into a top-level /foo-sta= te tree > for > > > the sole purpose of being able to report opstate for system-generated > > > objects. Likewise, all YANG constraints continue to work, but rather > than > > > reference nodes in /foo-state, they=E2=80=99ll now reference nodes in= /foo. > Does > > > this make sense? Do you still have an issue? > > > > > > > > > > > > > > > > > > > This does not work. There are no config=3Dfalse nodes if they are overl= aid > > onto the config=3Dtrue nodes. > > There is no way to say in the YANG XPath that you mean the configured > value > > of /foo > > vs. the operational value of /foo. There is just 1 leaf that YANG says > has > > 0 or 1 instance > > (and therefore 0 or 1 value). > > This is correct. But note that YANG doesn't allow config true nodes > to refer to config false nodes anyway, so this is less of an issue. > Also note that draft-ietf-netmod-revised-datastores-00 proposes that > semantic constraints don't apply to the operational-state datastore > (see section 5.3). > So valid YANG constraints applying to config=3Dfalse nodes would now be ignored? Just put in the YANG module to fool people? How can you propose to ignore YANG constraints on operational data? > > BTW, it has been suggested before to add a function similar to the > XSLT 1.0 function "document", that could be used to refer to nodes in > other documents (or rather other datastores in our case). > > So a new version of YANG is needed to support combining config and oper into 1 tree? > > /martin > Andy --94eb2c07ecfa1df3990545d503a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 11, 2017 at 1:27 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Tue, Jan 10, 2017 at 4:53 PM, Kent Watsen <kwatsen@juniper.net> wrote:
>
> > Hi Andy,
> >
> >
> >
> > > Until the basic show-stoppers are solved, the redundant opst= ate objects
> > are not important.
> >
> > > Removing the foo-state objects means they are now invisible = wrt/ YANG
> > constraints
> >
> > > (must, when, leafref, min/max, etc).=C2=A0 IMO this is a sho= w-shopper.=C2=A0 YANG
> > can only cross-reference
> >
> > > YANG statements.=C2=A0 Invisible opstate hiding behind a dat= astore label
> > seems elegant
> >
> > > wrt/ <get>, but it looks like a disaster wrt/ YANG. > >
> >
> >
> > Nothing has been removed.=C2=A0 All the config false nodes are st= ill available,
> > but now they=E2=80=99re no longer separated into a top-level /foo= -state tree for
> > the sole purpose of being able to report opstate for system-gener= ated
> > objects.=C2=A0 Likewise, all YANG constraints continue to work, b= ut rather than
> > reference nodes in /foo-state, they=E2=80=99ll now reference node= s in /foo.=C2=A0 =C2=A0Does
> > this make sense?=C2=A0 Do you still have an issue?
> >
> >
> >
> >
> >
>
> This does not work. There are no config=3Dfalse nodes if they are over= laid
> onto the config=3Dtrue nodes.
> There is no way to say in the YANG XPath that you mean the configured = value
> of /foo
> vs. the operational value of /foo.=C2=A0 There is just 1 leaf that YAN= G says has
> 0 or 1 instance
> (and therefore 0 or 1 value).

This is correct.=C2=A0 But note that YANG doesn't allow config true nod= es
to refer to config false nodes anyway, so this is less of an issue.
Also note that draft-ietf-netmod-revised-datastores-00 proposes that semantic constraints don't apply to the operational-state datastore
(see section 5.3).


So va= lid YANG constraints applying to config=3Dfalse nodes would now be
ignored?=C2=A0 Just put in the YANG module to fool people?
How = can you propose to ignore YANG constraints on operational data?
= =C2=A0

BTW, it has been suggested before to add a function similar to the
XSLT 1.0 function "document", that could be used to refer to node= s in
other documents (or rather other datastores in our case).


So a new version of YANG is needed to support combin= ing
config and oper into 1 tree?
=C2=A0

/martin


<= /div>
Andy

--94eb2c07ecfa1df3990545d503a2-- From nobody Wed Jan 11 12:32:32 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D267F1294A5 for ; Wed, 11 Jan 2017 12:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkbePsna_8Ih for ; Wed, 11 Jan 2017 12:32:27 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87A16129449 for ; Wed, 11 Jan 2017 12:32:27 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id a20so222538380qkc.1 for ; Wed, 11 Jan 2017 12:32:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6njUCWLqpIBFm8dv/R+vbuCl6eW1/VzdtPIBvf1qEP4=; b=YqIH2dsK2W1yABEwmlppGwFe7KTooi1grlqt3655ZijaVhAe3DnH16mF34IYnH8vTa 6MSfdVMZ5Nrm+7lvyT2m0tNl9oPW63451gZHQDqRyoSWxlfLSbFeRw9HcWXemqbP1Oyx x0bYx681C6DZU+cVmkTPoZezgjAlmJUPP9sz+/EIpXBdS85bwRhwre6ylC2GY/UGnEcw lwRy2zuY+mBma+I7DeDNHvTLdzNYPwC0jy6fr0s/gt5LTGWbgcXrJgb+VqBBG5gcXV7l 7TpuQvhXpXMx1elRs4M8ZyIjAc7hUlvQbzw8tRzqgt022TtHCYj+CLJgiVpQjqYrSd1G qLag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6njUCWLqpIBFm8dv/R+vbuCl6eW1/VzdtPIBvf1qEP4=; b=hNh8KXm8Fb42uWVSg2ReLQrM2BdlqIddMYn4nRn2wNOMihbHf8BRmolxTVFWdFOF2V nmMqKXM2QyoGcxhN1LN7oO9LYsvpcgHFTxhsx+riBJ+froxc487t/YP7JRq5H0Fo1ya9 dg9UeZdF3FVUp07IWkR/i1e7zvNJIk79WT2PqSEYyQp/Ci5w8q1DWaZUlbmmvpeO2o6k dIwOrxs4gezzVaCQWAvMoIo02rIGi8gqMB/X3TDW4Qksmr+imhaO0jOgEI3YvogLQLnM HlFuAUMf+3aIACm5BwVcMMs1VZk9NoW1uuevpoom5nAUkxLn3MaJRLydT5H7f4ZHPXdE ta6g== X-Gm-Message-State: AIkVDXJ6g8wInorAAD5dzpeIPHTnO3gxuw8udOdXo3/RHuOuQPv+QLRAKHehmOAN2fRLpsK40dbKTP+CIeh6yw== X-Received: by 10.55.22.97 with SMTP id g94mr9734388qkh.287.1484166746505; Wed, 11 Jan 2017 12:32:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Wed, 11 Jan 2017 12:32:25 -0800 (PST) In-Reply-To: <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> References: <6425C57C-C3DF-4099-AE77-4521B58B8D69@juniper.net> <20170111.102209.310040071380723970.mbj@tail-f.com> <9d4c54bf-ac6f-0d64-0361-668f9a793cd1@cisco.com> <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> From: Andy Bierman Date: Wed, 11 Jan 2017 12:32:25 -0800 Message-ID: To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a114967eab6c6070545d77fb8 Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 20:32:31 -0000 --001a114967eab6c6070545d77fb8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jan 11, 2017 at 9:21 AM, Ladislav Lhotka wrote: > > > On 11 Jan 2017, at 17:56, Andy Bierman wrote: > > > > Hi, > > > > > > On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton > wrote: > > > > > > On 11/01/2017 09:22, Martin Bjorklund wrote: > > Andy Bierman wrote: > > On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen > wrote: > > > > I think it is better to have a human decide what is in the module > > instead of relying on a pyang plugin to generate some additional module > > that follows some simplistic pattern. > > It may be simple, but I=E2=80=99m thinking that=E2=80=99s only because = it=E2=80=99s not tricky > ;) > > > > > > The client and server developers still need to know about this > > auto-generated module > > and implement it. Operators might have to know about it to use it. > > My idea is not to auto generate models on the fly. > > > > My aim is to allow folks to start writing models in the desired long > term format (i.e. combined config and state tree) with the model designer > being able to assume the existence of the operational state datastore. > > > > > > > > I am not convinced this "new format" has solved anything. > > Don't you need separate description-stmts in every node for each > > datastore? What does the value mean if pre-configured? configured? > > operational? Will the auto-generated objects be exactly correct > > and never need any alterations or additional text? > > They still need to be used by developers and YANG tools. > > Right, this is one problem of this "deduplication": even if two nodes - > one config and the other state - have the same name or even type (which i= s > not always the case, as we know), their semantics is often different. An = IP > address in configuration means a manually configured address whereas in > state it may come from any source. So writing sensible descriptions will > become tricky. > > > > > Is is that realistic to force the config structure and operational > structure > > to be the same? Seems it is quite common to monitor data structures > > with additional keys or different keys. This is completely unsupported > > so separate /foo and /foo-state trees will still exist. > > I agree. > > Lada > > > > > IMO this combination of trees needs to be proven. > > Take ietf-interfaces and show how much better it will work > > if the /interfaces and /interfaces-state trees were combined. > > > > > > Andy > > > > > > The tooling would be there to statically generate the extra foo-state > config false node modules for servers that don't support the operational > state datastore. This could be done once, and the extra foo-state module= s > committed to the github YANG respository in the same way that models are > extracted from IETF RFCs today. > > > > The aim here is that the single model being produced by IETF would be > usable both by new client/servers that support an operational state > datastore, and also by existing NETCONF client/servers that don't impleme= nt > an operational state datastore. > > > > I'm not proposing that as a long term solution, but as a path to make i= t > easier for folk to migrate, and to not slow down the model writing effort= . > Otherwise, it may be hard to get a protocol model writer to design the YA= NG > model in a way that is not fully usable on any current devices. > > > > As an illustration, an RFC published combined ietf-interfaces model may > look like this: > > > OK -- let me see if I understand the value of combining ietf-interfaces. Here is the starting tree: +--rw interfaces | +--rw interface* [name] | +--rw name string | +--rw description? string | +--rw type identityref | +--rw enabled? boolean | +--rw link-up-down-trap-enable? enumeration +--ro interfaces-state +--ro interface* [name] +--ro name string +--ro type identityref +--ro admin-status enumeration +--ro oper-status enumeration +--ro last-change? yang:date-and-time +--ro if-index int32 +--ro phys-address? yang:phys-address +--ro higher-layer-if* interface-state-ref +--ro lower-layer-if* interface-state-ref +--ro speed? yang:gauge64 +--ro statistics +--ro discontinuity-time yang:date-and-time +--ro in-octets? yang:counter64 +--ro in-unicast-pkts? yang:counter64 +--ro in-broadcast-pkts? yang:counter64 +--ro in-multicast-pkts? yang:counter64 +--ro in-discards? yang:counter32 +--ro in-errors? yang:counter32 +--ro in-unknown-protos? yang:counter32 +--ro out-octets? yang:counter64 +--ro out-unicast-pkts? yang:counter64 +--ro out-broadcast-pkts? yang:counter64 +--ro out-multicast-pkts? yang:counter64 +--ro out-discards? yang:counter32 +--ro out-errors? yang:counter32 So these are the objects that would no longer be duplicated: - name - type Neither one is supposed to have a different value in operational state vs configuration. - enabled - link-up-down-trap-enable These 2 could be different in operational state I suppose. An RPC can provide the operational value without changing the YANG module rpc get-oper-value { input { leaf node { type instance-identifier; description "the config=3Dtrue node to check"; } } output { anydata value { description "contains 1 child node matching the input 'node' parameter. The value of the node is the current operational value." } } } /if:interfaces/if:interface[if:name=3D'eth0']/enabled false I don't need to change the YANG module at all to support operational state. Andy > > module: ietf-interfaces-combined > > +--rw interfaces > > +--rw interface* [name] > > +--rw name string > > +--rw description? string > > +--rw type identityref > > +--rw enabled? boolean > > +--rw link-up-down-trap-enable? enumeration {if-mib}? > > +--ro oper-status enumeration > > +--ro last-change? yang:date-and-time > > +--ro if-index int32 {if-mib}? > > +--ro phys-address? yang:phys-address > > +--ro higher-layer-if* interface-ref > > +--ro lower-layer-if* interface-ref > > +--ro speed? yang:gauge64 > > +--ro statistics > > +--ro discontinuity-time yang:date-and-time > > +--ro in-octets? yang:counter64 > > +--ro in-unicast-pkts? yang:counter64 > > +--ro in-broadcast-pkts? yang:counter64 > > +--ro in-multicast-pkts? yang:counter64 > > +--ro in-discards? yang:counter32 > > +--ro in-errors? yang:counter32 > > +--ro in-unknown-protos? yang:counter32 > > +--ro out-octets? yang:counter64 > > +--ro out-unicast-pkts? yang:counter64 > > +--ro out-broadcast-pkts? yang:counter64 > > +--ro out-multicast-pkts? yang:counter64 > > +--ro out-discards? yang:counter32 > > +--ro out-errors? yang:counter32 > > > > The extra generated model would look like this: > > > > module: ietf-interfaces-combined-state > > +--ro interfaces-state > > +--ro interface* [name] > > +--ro name string > > +--ro description? string > > +--ro type identityref > > +--ro enabled? boolean > > +--ro link-up-down-trap-enable? enumeration {if:if-mib}? > > +--ro oper-status enumeration > > +--ro last-change? yang:date-and-time > > +--ro if-index int32 {if:if-mib}? > > +--ro phys-address? yang:phys-address > > +--ro higher-layer-if* if:interface-ref > > +--ro lower-layer-if* if:interface-ref > > +--ro speed? yang:gauge64 > > +--ro statistics > > +--ro discontinuity-time yang:date-and-time > > +--ro in-octets? yang:counter64 > > +--ro in-unicast-pkts? yang:counter64 > > +--ro in-broadcast-pkts? yang:counter64 > > +--ro in-multicast-pkts? yang:counter64 > > +--ro in-discards? yang:counter32 > > +--ro in-errors? yang:counter32 > > +--ro in-unknown-protos? yang:counter32 > > +--ro out-octets? yang:counter64 > > +--ro out-unicast-pkts? yang:counter64 > > +--ro out-broadcast-pkts? yang:counter64 > > +--ro out-multicast-pkts? yang:counter64 > > +--ro out-discards? yang:counter32 > > +--ro out-errors? yang:counter32 > > > > Servers that support operational-state would just implement > ietf-interfaces-combined > > > > Servers that don't support operational-state could implement > ietf-interfaces-combined and ietf-interfaces-combined-state, probably not > implementing the duplicate config false leaves under the interfaces confi= g > tree. Deviations could also be auto-generated to remove the config false > leaves from the config tree so that they are only in the state tree. > > > > Of course, Clients may need to support both schemes depending on what > types of devices they are interacting with. > > > > Finally, I've illustrated this using ietf-interfaces, but I'm not > actually proposing immediately changing that model. I was more thinking > about IETF protocols that in the process of working on their YANG models. > > > > Rob > > > > > > Exactly. I agree that this is a real hack. Implementations can use > > whatever transformation tricks they want in order to comply with > > different standards, but the standard modules should be very clear. > > > > > > > > > > > > > > /martin > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > --001a114967eab6c6070545d77fb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 11, 2017 at 9:21 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 11 Jan 2017, at 17:56, Andy Bierman <andy@yumaworks.com> wrote:
>
> Hi,
>
>
> On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton <rwilton@cisco.com> wrote:
>
>
> On 11/01/2017 09:22, Martin Bjorklund wrote:
> Andy Bierman <andy@yumaworks.= com> wrote:
> On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen <kwatsen@juniper.net> wrote:
>
> I think it is better to have a human decide what is in the module
> instead of relying on a pyang plugin to generate some additional modul= e
> that follows some simplistic pattern.
> It may be simple, but I=E2=80=99m thinking that=E2=80=99s only because= it=E2=80=99s not tricky=C2=A0 ;)
>
>
> The client and server developers still need to know about this
> auto-generated module
> and implement it.=C2=A0 Operators might have to know about it to use i= t.
> My idea is not to auto generate models on the fly.
>
> My aim is to allow folks to start writing models in the desired long t= erm format (i.e. combined config and state tree) with the model designer be= ing able to assume the existence of the operational state datastore.
>
>
>
> I am not convinced this "new format" has solved anything. > Don't you need separate description-stmts in every node for each > datastore?=C2=A0 What does the value mean if pre-configured? configure= d?
> operational?=C2=A0 Will the auto-generated objects be exactly correct<= br> > and never need any alterations or additional text?
> They still need to be used by developers and YANG tools.

Right, this is one problem of this "deduplication": even if two n= odes - one config and the other state - have the same name or even type (wh= ich is not always the case, as we know), their semantics is often different= . An IP address in configuration means a manually configured address wherea= s in state it may come from any source. So writing sensible descriptions wi= ll become tricky.

>
> Is is that realistic to force the config structure and operational str= ucture
> to be the same? Seems it is quite common to monitor data structures > with additional keys or different keys.=C2=A0 This is completely unsup= ported
> so separate /foo and /foo-state trees will still exist.

I agree.

Lada

>
> IMO this combination of trees needs to be proven.
> Take ietf-interfaces and show how much better it will work
> if the /interfaces and /interfaces-state trees were combined.
>
>
> Andy
>
>
> The tooling would be there to statically generate the extra foo-state = config false node modules for servers that don't support the operationa= l state datastore.=C2=A0 This could be done once, and the extra foo-state m= odules committed to the github YANG respository in the same way that models= are extracted from IETF RFCs today.
>
> The aim here is that the single model being produced by IETF would be = usable both by new client/servers that support an operational state datasto= re, and also by existing NETCONF client/servers that don't implement an= operational state datastore.
>
> I'm not proposing that as a long term solution, but as a path to m= ake it easier for folk to migrate, and to not slow down the model writing e= ffort.=C2=A0 Otherwise, it may be hard to get a protocol model writer to de= sign the YANG model in a way that is not fully usable on any current device= s.
>
> As an illustration, an RFC published combined ietf-interfaces model ma= y look like this:
>


OK -- let me see if= I understand the value of combining ietf-interfaces.

<= div>
Here is the starting tree:


=
     =
+--rw interfaces
      |  +--rw interface* [name]
      |     +--rw name                        string
      |     +--rw description?                string
      |     +--rw type                        identityref
      |     +--rw enabled?                    boolean
      |     +--rw link-up-down-trap-enable?   enumeration
      +--ro interfaces-state
         +--ro interface* [name]
            +--ro name               string
            +--ro type               identityref
            +--ro admin-status       enumeration
            +--ro oper-status        enumeration
            +--ro last-change?       yang:date-and-time
            +--ro if-index           int32
            +--ro phys-address?      yang:phys-address
            +--ro higher-layer-if*   interface-state-ref
            +--ro lower-layer-if*    interface-state-ref
            +--ro speed?             yang:gauge64
            +--ro statistics
               +--ro discontinuity-time    yang:date-and-time
               +--ro in-octets?            yang:counter64
               +--ro in-unicast-pkts?      yang:counter64
               +--ro in-broadcast-pkts?    yang:counter64
               +--ro in-multicast-pkts?    yang:counter64
               +--ro in-discards?          yang:counter32
               +--ro in-errors?            yang:counter32
               +--ro in-unknown-protos?    yang:counter32
               +--ro out-o=
ctets?           yang:counter64
               +--ro out-unicast-pkts?     yang:counter64
               +--ro out-broadcast-pkts?   yang:counter64
               +--ro out-multicast-pkts?   yang:counter64
               +--ro out-discards?         yang:counter32
               +--ro out-errors?           yang:counter32


So these are the objects tha= t would no longer be duplicated:

=C2=A0 =C2=A0 - n= ame
=C2=A0 =C2=A0 - type

Neither one is = supposed to have a different value in operational state vs configuration.

=C2=A0 =C2=A0- enabled
=C2=A0 =C2=A0- lin= k-up-down-trap-enable

These 2 could be different i= n operational state I suppose.
An RPC can provide the operational= value without changing the YANG module

=C2=A0 =C2= =A0 rpc get-oper-value {
=C2=A0 =C2=A0 =C2=A0 input {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf node {=C2=A0
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 type instance-identifier;=C2=A0
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description "the config= =3Dtrue node to check";
=C2=A0 =C2=A0 =C2=A0 =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 anydata value {
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description=C2=A0
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"contains 1 chi= ld node matching the input 'node' parameter.
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The value of the node is the = current operational value."
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 }
=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0}

=C2=A0 =C2=A0<rpc>
=C2=A0 =C2= =A0 =C2=A0 <get-oper-value>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 <node>/if:interfaces/if:interface[if:name=3D'eth0']/enabl= ed</node>
=C2=A0 =C2=A0 =C2=A0 </get-oper-value>
=C2=A0 =C2=A0</rpc>


=C2= =A0 =C2=A0<rpc-reply>
=C2=A0 =C2=A0 =C2=A0 =C2=A0<value&= gt;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <if:enabled>false<= ;/if:enabled>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </value>
=
=C2=A0 =C2=A0 =C2=A0</rpc-reply>

I don&= #39;t need to change the YANG module at all to support operational state.


Andy

=C2=A0=
> module: ietf-interfaces-combined
>=C2=A0 =C2=A0 =C2=A0+--rw interfaces
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw interface* [name]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw name=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw description?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw type=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 identityref=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw enabled?=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 boolean
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw link-up-down-trap-enable= ?=C2=A0 =C2=A0enumeration {if-mib}?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro oper-status=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enumeration
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro last-change? yang:date-a= nd-time
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro if-index=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int32 {if-mib}?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro phys-address? yang:phys-= address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro higher-layer-if*=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 interface-ref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro lower-layer-if*=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interface-ref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro speed?=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:gauge64 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro statistics
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro discontinuity-ti= me=C2=A0 =C2=A0 yang:date-and-time
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-octets?=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-unicast-pkts?= =C2=A0 =C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-broadcast-pkt= s?=C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-multicast-pkt= s?=C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-discards?=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-errors?=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-unknown-proto= s?=C2=A0 =C2=A0 yang:counter32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-octets?=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-unicast-pkts= ?=C2=A0 =C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-broadcast-pk= ts?=C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-multicast-pk= ts?=C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-discards?=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-errors?=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32
>
> The extra generated model would look like this:
>
> module: ietf-interfaces-combined-state
>=C2=A0 =C2=A0 =C2=A0+--ro interfaces-state
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro interface* [name]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro name=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro description?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro type=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 identityref=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro enabled?=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 boolean
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro link-up-down-trap-enable= ?=C2=A0 =C2=A0enumeration {if:if-mib}?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro oper-status=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enumeration
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro last-change? yang:date-a= nd-time
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro if-index=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int32 {if:if-mib}?<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro phys-address? yang:phys-= address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro higher-layer-if* if:inte= rface-ref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro lower-layer-if* if:inter= face-ref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro speed?=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:gauge64 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro statistics
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro discontinuity-ti= me=C2=A0 =C2=A0 yang:date-and-time
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-octets?=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-unicast-pkts?= =C2=A0 =C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-broadcast-pkt= s?=C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-multicast-pkt= s?=C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-discards?=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-errors?=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-unknown-proto= s?=C2=A0 =C2=A0 yang:counter32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-octets?=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-unicast-pkts= ?=C2=A0 =C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-broadcast-pk= ts?=C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-multicast-pk= ts?=C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-discards?=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-errors?=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32
>
> Servers that support operational-state would just implement ietf-inter= faces-combined
>
> Servers that don't support operational-state could implement ietf-= interfaces-combined and ietf-interfaces-combined-state, probably not i= mplementing the duplicate config false leaves under the interfaces config t= ree.=C2=A0 Deviations could also be auto-generated to remove the config fal= se leaves from the config tree so that they are only in the state tree.
>
> Of course, Clients may need to support both schemes depending on what = types of devices they are interacting with.
>
> Finally, I've illustrated this using ietf-interfaces, but I'm = not actually proposing immediately changing that model.=C2=A0 I was more th= inking about IETF protocols that in the process of working on their YANG mo= dels.
>
> Rob
>
>
> Exactly.=C2=A0 I agree that this is a real hack.=C2=A0 Implementations= can use
> whatever transformation tricks they want in order to comply with
> different standards, but the standard modules should be very clear. >
>
>
>
>
>
> /martin
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>
> _______________________________________________
> netmod mailing list
>
netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67






--001a114967eab6c6070545d77fb8-- From nobody Wed Jan 11 14:54:34 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB921293E8 for ; Wed, 11 Jan 2017 14:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sr9cFXxYE_g8 for ; Wed, 11 Jan 2017 14:54:29 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CD141294EA for ; Wed, 11 Jan 2017 14:54:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=87808; q=dns/txt; s=iport; t=1484175269; x=1485384869; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CPemDoS3/+6/EUYnN7vqIBzPIQS34ys89ToXMMkJ/Ls=; b=TjOzM786drvhCuQs8N/a1jSDqyMZDDlrJBi3miF1rg0Y34SQmKg4ob9W oxxLjKRcvN0aKusX/r3wOyBsID/mUHsEzD8h7J9gFNCn4JizCZdovQDVN PUMTgLS2jmIoS3ZGpGObxnGMrbZyxMtQJUBF1NXc+J8413XaFJL3KAHBO 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAQDstnZY/5tdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnFKAQEBAQEfX4ENB4NIigiSEpUnggoDHwEOhSpKAhqBbj8UAQI?= =?us-ascii?q?BAQEBAQEBYyiEaQEBAQQBARgDBgpBCxACAQgRAwEBASEBBgMCAgIlCxQJCAIED?= =?us-ascii?q?gUbiGUOsG+CJSuJbgEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GRYICgl+EDhUNHQc?= =?us-ascii?q?CBwkWAoJQLYIxBY8bAYV1FYYEAYZagxWDGoRJgXcYhHSEXoUEjk6EEgEfODaBC?= =?us-ascii?q?xU6EAGEHgIDHIFfcwEBAYYnDheBCoENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,347,1477958400"; d="scan'208,217";a="370067169" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2017 22:54:27 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0BMsRvE027580 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Jan 2017 22:54:27 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 11 Jan 2017 16:54:26 -0600 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1210.000; Wed, 11 Jan 2017 16:54:26 -0600 From: "Clyde Wildes (cwildes)" To: Andy Bierman Thread-Topic: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 Thread-Index: AQHSVaWfIiJK4a4BSkqW0KAWiGRnmqEGzUbWgBYXToCAA+AjAIAB+SyAgBEwmQA= Date: Wed, 11 Jan 2017 22:54:26 +0000 Message-ID: <1CC274D2-72B9-4F79-A70F-3DF332C65A60@cisco.com> References: <19039254-973A-461A-8749-95F74C33DAD1@juniper.net> <1481689016940.22442@Aviatnet.com> <3F4C49C9-1A6A-4644-97C6-F9CDC2E4EB4B@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.27.7.182] Content-Type: multipart/alternative; boundary="_000_1CC274D272B94F79A70F3DF332C65A60ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 22:54:33 -0000 --_000_1CC274D272B94F79A70F3DF332C65A60ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW55DQoNCk15IGNvbW1lbnRzIGlubGluZSBhcyBbY2x5ZGUyXeKApg0KDQpGcm9tOiBBbmR5IEJp ZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4NCkRhdGU6IFNhdHVyZGF5LCBEZWNlbWJlciAzMSwg MjAxNiBhdCA4OjI0IEFNDQpUbzogIkNseWRlIFdpbGRlcyAoY3dpbGRlcykiIDxjd2lsZGVzQGNp c2NvLmNvbT4NCkNjOiBBbGV4IENhbXBiZWxsIDxBbGV4LkNhbXBiZWxsQGF2aWF0bmV0LmNvbT4s ICJuZXRtb2RAaWV0Zi5vcmciIDxuZXRtb2RAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW25ldG1v ZF0gV0cgTGFzdCBDYWxsIGZvciBkcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWwtMTENCg0K DQoNCk9uIEZyaSwgRGVjIDMwLCAyMDE2IGF0IDEwOjE2IEFNLCBDbHlkZSBXaWxkZXMgKGN3aWxk ZXMpIDxjd2lsZGVzQGNpc2NvLmNvbTxtYWlsdG86Y3dpbGRlc0BjaXNjby5jb20+PiB3cm90ZToN CkhpIEFuZHksDQoNClRoYW5rcyBmb3IgdGFraW5nIHRoZSB0aW1lIHRvIHJldmlldyB0aGUgbW9k ZWwuDQoNCk15IGNvbW1lbnRzIGFyZSBpbmxpbmUgYXMgW2NseWRlXeKApg0KDQpGcm9tOiBuZXRt b2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9y Zz4+IG9uIGJlaGFsZiBvZiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86 YW5keUB5dW1hd29ya3MuY29tPj4NCkRhdGU6IFR1ZXNkYXksIERlY2VtYmVyIDI3LCAyMDE2IGF0 IDM6MDQgUE0NClRvOiBBbGV4IENhbXBiZWxsIDxBbGV4LkNhbXBiZWxsQEF2aWF0bmV0LmNvbT4N CkNjOiAibmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+IiA8bmV0bW9kQGll dGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtuZXRtb2RdIFdH IExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsLTExDQoNCkhpLA0K DQpJIGFtIGFsc28gY29uc2lkZXJpbmcgYW4gaW1wbGVtZW50YXRpb24uDQpJIHNoYXJlIHRoZSBz YW1lIGNvbmNlcm5zIHRoYXQgQWxleCBoYXMgYnJvdWdodCB1cC4NCg0KU29tZSBkZXRhaWxlZCBj b21tZW50czoNCg0KMSkgL3N5c2xvZy9hY3Rpb25zOiBzZWVtcyBsaWtlIGV2ZXJ5dGhpbmcgaXMg aW4gdGhpcyBjb250YWluZXIuDQogV2h5IGlzIGl0IG5lZWRlZD8gIFNlZW1zIGxpa2UgaXQgY291 bGQgYmUgcmVtb3ZlZCBhcyBpdCBzZXJ2ZXMgbm8gcHVycG9zZQ0KDQpbY2x5ZGVdIEFsdGhvdWdo IHRoaXMgbW9kZWwgaXMgY3VycmVudGx5IGRlc2lnbmF0ZWQgYXMgY29uZmlnIG9ubHksIHdlIGNv dWxkIGFkZCBvcGVyYXRpb25hbCBkYXRhIGFuZCBycGMgbGVhdmVzIGluIHRoZSBmdXR1cmUuIFRo ZSBhY3Rpb25zIGNvbnRhaW5lciBpcyB0byBmdXR1cmUtcHJvb2YgdGhlIG1vZGVsLg0KDQoyKSA4 IGZlYXR1cmVzOiB0aGUgZ3JhbnVsYXJpdHkgc2VlbXMgd3JvbmcuICBUaGUgbWFpbiBjb250YWlu ZXIgZm9yIGVhY2ggc2VjdGlvbg0KIHNob3VsZCBoYXZlIGl0cyBvd24gaWYtZmVhdHVyZQ0KICAg ICAgL2NvbnNvbGUNCiAgICAgIC9idWZmZXINCiAgICAgIC9maWxlDQogICAgICAvcmVtb3RlDQoN CltjbHlkZV0gV2UgaGF2ZSBnb25lIGJhY2sgYW5kIGZvcnRoIG9uIHRoaXPigKZzb21lIGhhdmUg Y29tcGxhaW5lZCB0aGF0IHRoZXJlIGFyZSB0b28gbWFueSBmZWF0dXJlcy4gSSB3aWxsIGJlIGhh cHB5IHRvIGFkZCBhIGZlYXR1cmUgZm9yIGVhY2ggYWN0aW9uLiBOb3RlIHRoYXQgd2Ugc3R1ZGll ZCB0aGUgaW1wbGVtZW50YXRpb24gb2YgZWFjaCBhY3Rpb24gYnkgc2l4IHZlbmRvcnMgaW5jbHVk aW5nIExpbnV4IGFuZCBvcHRlZCB0byBub3QgYWRkIGZlYXR1cmVzIGZvciBhY3Rpb25zIGltcGxl bWVudGVkIGJ5IGF0IGxlYXN0IDMgdmVuZG9ycy4gVmVuZG9ycyBub3QgaW1wbGVtZW50aW5nIGFu IGFjdGlvbiBjb3VsZCBjcmVhdGUgYSBkZXZpYXRpb24uDQoNCg0KSSBwcmVmZXIgMSBtYW5kYXRv cnktdG8taW1wbGVtZW50IGFuZCBhIG1pbmltYWwgbnVtYmVyIG9mIGFkZGl0aW9uYWwgb3B0aW9u cy4NCg0KICAvY29uc29sZQ0KICAvZmlsZQ0KICAvcmVtb3RlDQoNClRoZXNlIGFyZSBhbGwgbWFu ZGF0b3J5LXRvLWltcGxlbWVudC4uDQpJTU8gb25seSAvZmlsZSBzaG91bGQgYmUgbWFuZGF0b3J5 LXRvLWltcGxlbWVudC4NCg0KW2NseWRlMl0gSSB3aWxsIHJlbW92ZSB0aGUgYnVmZmVyIGFuZCBz ZXNzaW9uIGFjdGlvbnMgaW4gdGhlIG5leHQgZHJhZnQgYW5kIHdpbGwgbWFrZSB0aGUgcmVtYWlu aW5nIHRocmVlIGZlYXR1cmVzLg0KDQoNCjMpIFdoYXQgaXMgdGhlICdidWZmZXInIGNvbnRhaW5l ciBmb3I/DQogIEhvdyBpcyB0aGUgaW50ZXJuYWwgbWVtb3J5IGFjY2Vzc2VkIGJ5IHRoZSBjbGll bnQ/DQoNCltjbHlkZV0gYnVmZmVyIGlzIGltcGxlbWVudGVkIGJ5IHZlbmRvcnMgdHlwaWNhbGx5 IGZvciByb3V0ZXJzIGNhcGFibGUgb2YgZ2VuZXJhdGluZyBtYW55IHN5c2xvZyBtZXNzYWdlcyBp biBldmVudC1zdG9ybSBidXJzdHMuIExvZ2dpbmcgdG8gbWVtb3J5IChha2EgYnVmZmVyKSBhbGxv d3MgdGhlIHByZXNlcnZhdGlvbiBvZiBzeXNsb2cgbWVzc2FnZXMgd2hpY2ggbWlnaHQgb3RoZXJ3 aXNlIGJlIGxvc3QuDQoNCg0KDQpJTU8gaXQgc2hvdWxkIGJlIHJlbW92ZWQgZnJvbSB0aGUgZHJh ZnQuDQpXZSBjZXJ0YWlubHkgaGF2ZSBjaGFuZ2VkIHRoZSBJRVRGIE5NIGZvY3VzLg0KSW4gU05N UC1sYW5kIHdlIHJvdXRpbmVseSBsZWZ0IHRoZSBjb25maWd1cmF0aW9uIG91dCBvZiBzY29wZQ0K YW5kIHN0YW5kYXJkaXplZCB0aGUgbW9uaXRvcmluZy4gIE5vdyB3ZSBhcmUgc3RhbmRhcmRpemlu Zw0KdGhlIGNvbmZpZ3VyYXRpb24gYW5kIGxlYXZpbmcgdGhlIG1vbml0b3Jpbmcgb3V0IG9mIHNj b3BlPw0KSSBwcmVmZXIgY29tcGxldGUgc3RhbmRhcmQgc29sdXRpb25zIG9ubHkuDQoNClRoZXJl IGlzIG5vIHN0YW5kYXJkIHdheSB0byBhY2Nlc3MgdGhlIC9jb25zb2xlIGVpdGhlci4NClNpbmNl IHRoZSBjb25zb2xlIHByb3ZpZGVzICJzaG93IGxvZyIgSSByZWFsbHkgZG8gbm90IHNlZSBhIG5l ZWQgZm9yDQovYnVmZmVyIGF0IGFsbC4NCg0KW2NseWRlMl0gVGhlIGJ1ZmZlciBhY3Rpb24gd2ls bCBiZSByZW1vdmVkLg0KQSDigJxzaG93IGxvZ+KAnSBjb21tYW5kIGlzIHVzZWQgdG8gYWNjZXNz IHRoZSBidWZmZXJzLiBBcyB0aGlzIG1vZGVsIGlzIGN1cnJlbnQgZGVzaWduZWQgYXMgYSBjb25m aWd1cmF0aW9uIG9ubHkgbW9kZWwsIHRoZXJlIGlzIG5vIG9wZXJhdGlvbmFsIGxlYXZlcyBmb3Ig c2hvdyBsb2csIG9yIHJwYyBsZWF2ZXMgZm9yIGNsZWFyIGxvZy4NCg0KNCkgc2VsZWN0b3ItZmFj aWxpdHk6IFNlZW1zIGxpa2Ugbm8tZmFjaWxpdGllcyBzZXJ2ZXJzIHRoZSBzYW1lIHB1cnBvc2UN CiAgICBhcyBhbiBlbXB0eSBmYWNpbGl0eS1saXN0LiBUaGUgY2hvaWNlIGlzIG5vdCBuZWVkZWQ7 IGp1c3QgdXNlIHRoZSBmYWNpbGl0eS1saXN0DQoNCltjbHlkZV0gVGhpcyB3YXMgY2hhbmdlZCBh cyBhIHJlc3VsdCBvZiBBbGV44oCZcyBmZWVkYmFjayDigJMgcGxlYXNlIHNlZSBteSByZXNwb25z ZSB0byBoaW0uIFRoZSBtb2RlbCB3aWxsIGJlIGNoYW5nZWQgdG8gdGhlIGZvbGxvd2luZzoNCg0K DQogICAgY29udGFpbmVyIHNlbGVjdG9yIHsNCg0KICAgICAgZGVzY3JpcHRpb24NCg0KICAgICAg ICAiVGhpcyBjb250YWluZXIgZGVzY3JpYmVzIHRoZSBsb2cgc2VsZWN0b3IgcGFyYW1ldGVycw0K DQogICAgICAgICBmb3Igc3lzbG9nLiI7DQoNCiAgICAgIGxpc3QgZmFjaWxpdHktbGlzdCB7DQoN CiAgICAgICAga2V5IGZhY2lsaXR5Ow0KDQogICAgICAgIGRlc2NyaXB0aW9uDQoNCiAgICAgICAg ICAiVGhpcyBsaXN0IGRlc2NyaWJlcyBhIGNvbGxlY3Rpb24gb2Ygc3lzbG9nDQoNCiAgICAgICAg ICAgZmFjaWxpdGllcyBhbmQgc2V2ZXJpdGllcy4iOw0KDQogICAgICAgIGxlYWYgZmFjaWxpdHkg ew0KDQogICAgICAgICAgdHlwZSB1bmlvbiB7DQoNCiAgICAgICAgICAgIHR5cGUgaWRlbnRpdHly ZWYgew0KDQogICAgICAgICAgICAgIGJhc2Ugc3lzbG9ndHlwZXM6c3lzbG9nLWZhY2lsaXR5Ow0K DQogICAgICAgICAgICB9DQoNCiAgICAgICAgICAgIHR5cGUgZW51bWVyYXRpb24gew0KDQogICAg ICAgICAgICAgIGVudW0gYWxsIHsNCg0KICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQoNCiAg ICAgICAgICAgICAgICAgICJUaGlzIGVudW0gZGVzY3JpYmVzIHRoZSBjYXNlIHdoZXJlIGFsbA0K DQogICAgICAgICAgICAgICAgICAgZmFjaWxpdGllcyBhcmUgcmVxdWVzdGVkLiI7DQoNCiAgICAg ICAgICAgICAgfQ0KDQogICAgICAgICAgICB9DQoNCiAgICAgICAgICB9DQoNCiAgICAgICAgICBk ZXNjcmlwdGlvbg0KDQogICAgICAgICAgICAiVGhlIGxlYWYgdW5pcXVlbHkgaWRlbnRpZmllcyBh IHN5c2xvZyBmYWNpbGl0eS4iOw0KDQogICAgICAgIH0NCg0KICAgICAgICB1c2VzIGxvZy1zZXZl cml0eTsNCg0KICAgICAgfQ0KDQogICAgICBsZWFmIHBhdHRlcm4tbWF0Y2ggew0KDQogICAgICAg IGlmLWZlYXR1cmUgc2VsZWN0LW1hdGNoOw0KDQogICAgICAgIHR5cGUgc3RyaW5nOw0KDQogICAg ICAgIGRlc2NyaXB0aW9uDQoNCiAgICAgICAgICAiVGhpcyBsZWFmIGRlc3JpYmVzIGEgUG9zaXgg MTAwMy4yIHJlZ3VsYXIgZXhwcmVzc2lvbg0KDQogICAgICAgICAgIHN0cmluZyB0aGF0IGNhbiBi ZSB1c2VkIHRvIHNlbGVjdCBhIHN5c2xvZyBtZXNzYWdlIGZvcg0KDQogICAgICAgICAgIGxvZ2dp bmcuIFRoZSBtYXRjaCBpcyBwZXJmb3JtZWQgb24gdGhlIFJGQyA1NDI0DQoNCiAgICAgICAgICAg U1lTTE9HLU1TRyBmaWVsZC4iOw0KDQogICAgICB9DQoNCg0KNSkgcGF0dGVybi1tYXRjaDoNCg0K DQogICAgICBsZWFmIHBhdHRlcm4tbWF0Y2ggew0KDQogICAgICAgIGlmLWZlYXR1cmUgc2VsZWN0 LW1hdGNoOw0KDQogICAgICAgIHR5cGUgc3RyaW5nOw0KDQogICAgICAgIGRlc2NyaXB0aW9uDQoN CiAgICAgICAgICAiVGhpcyBsZWFmIGRlc3JpYmVzIGEgUG9zaXggMTAwMy4yIHJlZ3VsYXIgZXhw cmVzc2lvbg0KDQogICAgICAgICAgIHN0cmluZyB0aGF0IGNhbiBiZSB1c2VkIHRvIHNlbGVjdCBh IHN5c2xvZyBtZXNzYWdlIGZvcg0KDQogICAgICAgICAgIGxvZ2dpbmcuIFRoZSBtYXRjaCBpcyBw ZXJmb3JtZWQgb24gdGhlIFJGQyA1NDI0DQoNCiAgICAgICAgICAgU1lTTE9HLU1TRyBmaWVsZC4i Ow0KDQogICAgICB9DQoNCg0KVGhlIGZpZWxkIFNZU0xPRy1NU0cgaXMgcmVmZXJlbmNlZCBidXQg bmV2ZXIgZGVmaW5lZCBvciBsaXN0ZWQgaW4NCnRoZSB0ZXJtaW5vbG9neSBzZWN0aW9uLg0KDQpb Y2x5ZGVdIFRoaXMgd2lsbCBiZSBmaXhlZCBpbiB0aGUgbmV4dCBkcmFmdC4NCg0KNikgaG93IGFy ZSB0aGUgc3lzbG9nLWZhY2lsaXR5IGlkZW50aXRpZXMgbWFwcGVkIHRvIFNZU0xPRyBtZXNzYWdl cz8NCjZhKSBob3cgdG8gZGlzdGluZ3Vpc2ggYWNtZTpmb28tZmFjaWxpdHkgZnJvbSBleGFtcGxl OmZvby1mYWNpbGl0eSBpbiBhIFNZU0xPRyBtZXNzYWdlPw0KDQpbY2x5ZGVdIEkgZG8gbm90IHVu ZGVyc3RhbmQgeW91ciBxdWVzdGlvbi4gVGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gb2YgZmFj aWxpdGllcyB3YXMgZGVzaWduZWQgd2l0aCB0aGUgaGVscCBvZiBzZXZlcmFsIFlhbmcgRG9jdG9y cy4gVGhlIHJlcXVpcmVtZW50IGlzIHRvIHN1cHBvcnQgdGhlIGZhY2lsaXRpZXMgYXMgY2FsbGVk IG91dCBpbiBSRkMgNTQyNCBhcyB3ZWxsIGFzIHZlbmRvciBzcGVjaWZpYyBmYWNpbGl0aWVzIHRo YXQgY2FuIGJlIGFkZGVkIHRocm91Z2ggYXVnbWVudGF0aW9uLiBWZW5kb3Igc3BlY2lmaWMgZmFj aWxpdGllcyBhcmUgbm90IG1lYW50IHRvIGJlIHVzZWQgYWNyb3NzIG11bHRpcGxlIHZlbmRvciBp bXBsZW1lbnRhdGlvbnMuDQoNCg0KDQpUaGUgZmlsdGVyIGlzIGJhc2VkIG9uIGFuIGlkZW50aXR5 cmVmLCB3aGljaCBpcyBhIG1vZHVsZS1xdWFsaWZpZWQgbmFtZSwNCmUuZy4sIGFjbWU6Zm9vLWZh Y2lsaXR5IGFuZCBleGFtcGxlOmZvby1mYWNpbGl0eSBhcmUgZGlmZmVyZW50IGVudGl0aWVzLg0K SW4gdGhlIHN5c2xvZyBtZXNzYWdlLCBvbmx5IHRoZSBzdHJpbmcgZm9vLWZhY2lsaXR5IHdpbGwg YmUgcHJlc2VudC4NClRoZSBkcmFmdCBjbGFpbXMgdG8gcHJvdmlkZSBleHRlbnNpYmxlIGZhY2ls aXRpZXMsKHNlZSBBLjEpICBidXQgaXQgb25seQ0Kc2VlbXMgdG8gd29yayBpZiB0aGUgaWRlbnRp dGllcyBkbyBub3QgY29udGFpbiBhbnkgZHVwbGljYXRlcy4NCg0KDQpbY2x5ZGUyXSBJbiBteSBl eHBlcmllbmNlIGxvb2tpbmcgYXQgbXVsdGlwbGUgdmVuZG9yIGltcGxlbWVudGF0aW9ucyBJIGRp ZCBub3Qgc2VlIGFueSBkdXBsaWNhdGVzLiBJZiB5b3UgaGF2ZSBhIHN1Z2dlc3Rpb24gb24gYW5v dGhlciB3YXkgdG8gZXh0ZW5kIGZhY2lsaXRpZXMsIEkgYW0gYWxsIGVhcnMuDQoNCjcpIHNvdXJj ZS1pbnRlcmZhY2U6IHdoYXQgaWYgdGhlIHNlcnZlciBkb2VzIG5vdCBsZXQgYSBzb3VyY2UgaW50 ZXJmYWNlIGJlIHVzZWQgYW5kIGluc3RlYWQNCiAgICBub3JtYWwgcm91dGluZyBkZXRlcm1pbmVz IHRoZSBzb3VyY2UgaW50ZXJmYWNlICh0aGlzIGxlYWYgaXMgdmVyeSByb3V0ZXItY2VudHJpYykN Cg0KW2NseWRlXSBzb3VyY2UtaW50ZXJmYWNlIGlzIG9wdGlvbmFsLiBJZiBub3Qgc3BlY2lmaWVk IG5vcm1hbCByb3V0aW5nIGZsb3cgd291bGQgYmUgdXNlZC4NCg0KOCkgc2lnbmluZy1vcHRpb25z OiBhcmUgdGhlc2Ugd2lkZWx5IGRlcGxveWVkIG9uIGFsbCByb3V0ZXJzIGFuZCBMaW51eCBob3N0 cz8NCg0KW2NseWRlXSBBbGV4IENsZW1tIGFza2VkIHRoYXQgd2UgaW5jbHVkZSBzeXNsb2cgc2ln bmluZy1vcHRpb25zLiBUaGlzIGlzIGltcGxlbWVudGVkIGJ5IGF0IGxlYXN0IExpbnV4IHJzeXNs b2cuDQoNCjkpIGxvZ3JvdGF0ZTogdGhlcmUgYXJlIHNldmVyYWwgZmVhdHVyZXMgcmVsYXRlZCB0 byBsb2cgZmlsZSBjbGVhbnVwIGFsbG93aW5nIGxvdHMgb2YNCiAgICBzZXJ2ZXIgdmFyaWFiaWxp dHkgYW5kIGZvcmNlcyB0aGUgY2xpZW50IHRvIHN1cHBvcnQgYWxsIHRoZSBvcHRpb25zLiAgQ2Fu J3QgdGhpcyBiZSBzaW1wbGlmaWVkDQogICBhbmQgYWxsIHRoZSBtaWNyby1iZWhhdmlvciBZQU5H IGZlYXR1cmVzIHJlbW92ZWQ/DQoNCltjbHlkZV0gVGhpcyB3YXMgZGVzaWduZWQgYnkgbWVyZ2lu ZyB0aGUgcmVxdWlyZW1lbnRzIGZyb20gc2V2ZXJhbCB2ZW5kb3JzLiBBbGwgb2YgdGhlIHZhcmlh bnRzIHNwZWNpZmllZCBhcmUgd2l0aCBpZi1mZWF0dXJlIHNvIHRoYXQgdGhlIGNsaWVudCBkb2Vz IG5vdCBoYXZlIHRvIHN1cHBvcnQgYWxsIG9wdGlvbnMuDQoNCg0KVGhlcmUgc2VlbXMgdG8gYmUg c29tZSBwcm9jZWR1cmVzIGltcGxpZWQgYnkgdGhlc2UgWUFORyBvYmplY3RzLA0KYnV0IGl0IGlz IG5vdCBzcGVjaWZpZWQuDQoNClRoZSA0IGRpZmZlcmVudCBtZXRob2RzIChlYWNoIHdpdGggaXRz IG93biBmZWF0dXJlKSwgYXJlIGluIGEgY29udGFpbmVyLg0KU2luY2UgY29udGFpbmVyICdmaWxl LXJvdGF0aW9uJyBpcyBpbiBsaXN0ICdsb2ctZmlsZScsIHRoZSByb3RhdGlvbiB2YXJpYW50DQpj YW4gYmUgZGlmZmVyZW50IGZvciBldmVyeSBmaWxlLiAgSXMgdGhpcyByZWFsbHkgaG93IGltcGxl bWVudGF0aW9ucyB3b3JrPw0KDQpbY2x5ZGUyXSBXZSBjb25zb2xpZGF0ZWQgdGhlIHJlcXVpcmVt ZW50cyBmcm9tIG11bHRpcGxlIHZlbmRvcnMuDQoNCkp1bmlwZXIgbG9nIGZpbGUgYXJjaGl2aW5n IGlzIGF2YWlsYWJsZSB2aWEgYSBnbG9iYWwgc2V0dGluZyBvciBvbiBhbiBpbmRpdmlkdWFsIGZp bGUg4oCTIGJvdGggbnVtYmVyIG9mIGZpbGVzIGFuZCBmaWxlIHNpemUgYXJlIHN1cHBvcnRlZC4g U2VlIGh0dHBzOi8vd3d3Lmp1bmlwZXIubmV0L2RvY3VtZW50YXRpb24vZW5fVVMvanVub3MxMi4z L2luZm9ybWF0aW9uLXByb2R1Y3RzL3RvcGljLWNvbGxlY3Rpb25zL3N5c2xvZy1tZXNzYWdlcy9p bmRleC5odG1sP2pkMGU5MjEuaHRtbA0KDQpDaXNjbyBsb2cgZmlsZSBhcmNoaXZpbmcgaXMgc3Bl Y2lmaWVkIGZvciBhbiBpbmRpdmlkdWFsIGZpbGUuIEZpbGUgc2l6ZSBhbmQgb3B0aW9uYWxseSBh IGhhcmQgY29kZSBtYXhpbXVtIG51bWJlciBvZiBieXRlcyBzZXQgYXNpZGUgZm9yIGxvZ2dpbmcg b3IgYSBwZXJjZW50IG9mIHRvdGFsIGRpc2sgc3BhY2UgYXZhaWxhYmxlIGZvciBsb2dnaW5nIG1h eSBiZSBzcGVjaWZpZWQuDQpodHRwOi8vd3d3LmNpc2NvLmNvbS9jL2VuL3VzL3RkL2RvY3MvaW9z LXhtbC9pb3MvZXNtL2NvbW1hbmQvZXNtLWNyLWJvb2svZXNtLWNyLWExLmh0bWwjd3A4NzA4NTM0 NzQwDQoNCkFsY2F0ZWwtTHVjZW50IGxvZyBmaWxlIGFyY2hpdmluZyBpcyBzcGVjaWZpZWQgZm9y IGFuIGluZGl2aWR1YWwgZmlsZSBhbmQgc3VwcG9ydHMgcm9sbG92ZXIgaW4gbWludXRlcyBhbmQg cmV0ZW50aW9uIGluIGhvdXJzLg0KaHR0cHM6Ly9pbmZvcHJvZHVjdHMuYWxjYXRlbC1sdWNlbnQu Y29tL2h0bWwvMF9hZGQtaC1mLzkzLTAwNzEtMTAtMDEvNzc1MF9TUl9PU19TeXN0ZW1fTWFuYWdl bWVudF9HdWlkZS9Mb2djbGkuaHRtbCMxMDM4MzAxDQoNClRoZSBzZXJ2ZXIgaXMgZnJlZSB0byBz dXBwb3J0IGZyb20gbm9uZSB0byBhbGwgb2YgdGhlIGFyY2hpdmluZyBmZWF0dXJlcyAobm90ZTog dGhleSBhcmUgc3BlY2lmaWVkIGFzIGZlYXR1cmVzKS4NCg0KDQpBbHNvLCB0aGUgZGlmZmVyZW50 IHBhcmFtZXRlcnMgaW4gdGhpcyBjb250YWluZXIgY2FuIGludGVyYWN0IGlmIHRoZSBzZXJ2ZXIN CnN1cHBvcnRzIG1vcmUgdGhhbiAxIGZlYXR1cmUuICBUaGUgZHJhZnQgZG9lcyBub3Qgc2F5IGFu eXRoaW5nIGFib3V0DQpjb21iaW5pbmcgdGhlbS4NCg0KRS5nLjoNCg0KDQogICAgICAgICAgIGxl YWYgbnVtYmVyLW9mLWZpbGVzIHsNCg0KICAgICAgICAgICAgICBpZi1mZWF0dXJlIGZpbGUtbGlt aXQtc2l6ZTsNCg0KICAgICAgICAgICAgICB0eXBlIHVpbnQzMjsNCg0KICAgICAgICAgICAgICBk ZXNjcmlwdGlvbg0KDQogICAgICAgICAgICAgICAgIlRoaXMgbGVhZiBzcGVjaWZpZXMgdGhlIG1h eGltdW0gbnVtYmVyIG9mIGxvZw0KDQogICAgICAgICAgICAgICAgIGZpbGVzIHJldGFpbmVkLiBT cGVjaWZ5IDEgZm9yIGltcGxlbWVudGF0aW9ucw0KDQogICAgICAgICAgICAgICAgIHRoYXQgb25s eSBzdXBwb3J0IG9uZSBsb2cgZmlsZS4iOw0KDQogICAgICAgICAgICB9DQoNCg0KSG93IGRvZXMg dGhlIGNsaWVudCBrbm93IGlmIHRoZSBzZXJ2ZXIgb25seSBzdXBwb3J0cyAxIGZpbGUgb3Igbm90 Pw0KVGhpcyBzaG91bGQgcmVhbGx5IGJlIHJldmlzaW9ucywgc2luY2UgdGhlc2UgZmlsZXMgYXJl IHBlciBsb2ctZmlsZSBsaXN0IGVudHJ5Lg0KDQpbY2x5ZGUyXSBNYWtlIHRoZSBkZWZhdWx0IDE/ DQoNCklmIG9ubHkgMSByZXZpc2lvbiBvZiB0aGUgbG9nLWZpbGUgaXMgcmV0YWluZWQsIHRoZW4g dGhlIG1lYW5pbmcgb2YgdGhlIG90aGVyDQpsZWFmcyBpcyB1bmNsZWFyLiBJZiB0aGVyZSBpcyBv bmx5IDEgbG9nLWZpbGUgcmV2aXNpb24sIHRoZW4gd2hhdCBoYXBwZW5zDQppZiB0aGUgbWF4LWZp bGUtc2l6ZSAjIG9mIG1lZ2FieXRlcywgcm9sbG92ZXIgIyBvZiBtaW51dGVzLCBvciByZXRlbnRp b24gIyBvZiBob3Vycw0KaXMgcmVhY2hlZD8gIERvZXMgc3lzbG9nIG1vbml0b3Jpbmcgc3RvcCBm b3IgdGhlIGxvZy1maWxlIGVudHJ5Pw0KDQpbY2x5ZGUyXSBJZiBvbmUgbG9nLWZpbGUgaXMgc3Bl Y2lmaWVkIGFuZCBtYXgtZmlsZS1zaXplIGlzIHNwZWNpZmllZCwgdGhlIHNpbmdsZSBmaWxlIGlz IG92ZXJ3cml0dGVuIHdoZW4gbWF4LWZpbGUtc2l6ZSBsaW1pdCBpcyBlbmNvdW50ZXJlZC4NCg0K SG93IGRvZXMgdGhlIGNsaWVudCBhY2Nlc3MgZGlmZmVyZW50IHJldmlzaW9ucyBvZiB0aGUgbG9n IGZpbGU/IE9yIGV2ZW4gbGlzdCB0aGVtPw0KSG93IGRvZXMgdGhlIGNsaWVudCBrbm93IHRoZSBj dXJyZW50IHNpemUgb2YgbGlmZXRpbWUgb2YgdGhlIGxvZy1maWxlDQpUaGV5IGRvIG5vdCBoYXZl IG5hbWVzLiBJcyBpdCBhc3N1bWVkIHRoZXkgd2lsbCBiZSB0aGUgbG9nLWZpbGUvbmFtZSBmaWVs ZA0KYXBwZW5kZWQgd2l0aCAiLjEiLCAiLjIiLCBldGMuPw0KDQpbY2x5ZGUyXSBUaGVyZSBpcyBu byBhdHRlbXB0IHRvIHN1cHBvcnQgb3BlciBkYXRhIGluIHRoaXMgbW9kZWwuDQoNCg0KVGhhbmtz LA0KDQpDbHlkZQ0KMTApIG51bWVyaWMgbGltaXRzOiB0aGVyZSBpcyBzb21lIG9kZCB1c2FnZSBv ZiBZQU5HIHR5cGVzOyBzb21lIGxpbWl0cyBhcmUgdWludDY0LCBzb21lIHVpbnQzMiwNCnNvbWUg dWludDE2LiAgU2VlbXMgbGlrZSB1aW50MzIgaXMgc3VmZmljaWVudA0KDQpbY2x5ZGVdICBUaGUg c2lnbmluZy1vcHRpb25zIGNvdW50cyBhcmUgYXMgcGVyIHRoZSBzeXNsb2ctc2lnbiBzcGVjIChS RkMgNTg0OCkgd2hpY2ggaXMgdWludDE2LiBJIHdpbGwgbWFrZSBhbGwgb3RoZXJzIHVpbnQzMiBl eGNlcHQgZm9yIHRoZSBidWZmZXIgc2l6ZSBsaW1pdCB3aGljaCBJIHdpbGwgbGVhdmUgYXQgdW5p dDY0Lg0KDQpSZXN1bHQ6DQo8c2V2ZW4gc2lnbmluZy1vcHRpb25zIGNvdW50ZXJzPiB1aW50MTYN CmJ1ZmZlci1saW1pdC1ieXRlcyB1aW50NjQNCmJ1ZmZlci1saW1pdC1tZXNzYWdlcyB1aW50MzIg KHdhcyBmb3JtYWxseSB1aW50NjQpDQpudW1iZXItb2YtZmlsZXMgdWludDMyDQptYXgtZmlsZS1z aXplIHVpbnQzMiAod2FzIGZvcm1hbGx5IHVpbnQ2NCkNCnJvbGxvdmVyIHVuaXQzMg0KcmV0ZW50 aW9uIHVuaXQzMiAod2FzIGZvcm1hbGx5IHVpbnQxNikNCg0KDQpUaGFua3MsDQoNCkNseWRlDQoN Cg0KDQoNCg0KQW5keQ0KDQoNCkFuZHkNCg0KDQpPbiBUdWUsIERlYyAxMywgMjAxNiBhdCA4OjE2 IFBNLCBBbGV4IENhbXBiZWxsIDxBbGV4LkNhbXBiZWxsQGF2aWF0bmV0LmNvbTxtYWlsdG86QWxl eC5DYW1wYmVsbEBhdmlhdG5ldC5jb20+PiB3cm90ZToNCkkgYW0gY29uc2lkZXJpbmcgdG8gaW1w bGVtZW50IHRoZSBkYXRhIG1vZGVsIGluIHRoaXMgZHJhZnQuDQoNCkkgaGF2ZSByZXZpZXdlZCB0 aGlzIGRyYWZ0IGFuZCBmb3VuZCB0aGUgZm9sbG93aW5nIGlzc3Vlcy4gSW4gYXBwcm94aW1hdGVs eSBkZWNyZWFzaW5nIG9yZGVyIG9mIHNldmVyaXR5Og0KDQoqIEluIHRoZSAic2VsZWN0b3ItZmFj aWxpdHkiIGNob2ljZSBzdGF0ZW1lbnQgdGhlIGNhc2VzIGhhdmUgbWlzbGVhZGluZyBuYW1lcyAt IHRoZSBjYXNlIHdoZXJlIG5vIGZhY2lsaXR5IGlzIG1hdGNoZWQgaXMgbmFtZWQgImZhY2lsaXR5 IiwgYW5kIHRoZSBjYXNlIHdoZXJlIHNwZWNpZmljIGZhY2lsaXRpZXMgYXJlIG1hdGNoZWQgaXMg bmFtZWQgIm5hbWUiLiBJIHN1Z2dlc3QgIm5vLWZhY2lsaXRpZXMiIGFuZCAic3BlY2lmaWVkLWZh Y2lsaXRpZXMiLCBvciBzaW1pbGFyLg0KDQoqIEkgZGlzYWdyZWUgd2l0aCB0aGUgcHJlbWlzZSBv ZiB0aGUgIm5vLWZhY2lsaXRpZXMiIGNhc2UsIHdoaWNoIGlzIHRoYXQgaXQgY2FuIGJlIHVzZWQg dG8gZGlzYWJsZSBhIGxvZyBhY3Rpb24sIGFjY29yZGluZyB0byB0aGUgZGVzY3JpcHRpb246DQoN CiAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICJUaGlzIGNhc2Ugc3BlY2lmaWVzIG5vIGZh Y2lsaXRpZXMgd2lsbCBtYXRjaCB3aGVuDQogICAgICAgICAgICAgY29tcGFyaW5nIHRoZSBzeXNs b2cgbWVzc2FnZSBmYWNpbGl0eS4gVGhpcyBpcyBhDQogICAgICAgICAgICAgbWV0aG9kIHRoYXQg Y2FuIGJlIHVzZWQgdG8gZWZmZWN0aXZlbHkgZGlzYWJsZSBhDQogICAgICAgICAgICAgcGFydGlj dWxhciBsb2ctYWN0aW9uIChidWZmZXIsIGZpbGUsIGV0YykuIjsNCg0KICBJZiBhbiBhZG1pbmlz dHJhdG9yIHdhbnRzIHRvIGRpc2FibGUgYSBsb2cgYWN0aW9uIHRoZXkgc2hvdWxkIGRvIGl0IGJ5 IGVpdGhlciByZW1vdmluZyBpdCBmcm9tIHRoZSBjb25maWd1cmF0aW9uLCBvciBieSBzZXR0aW5n IGFuICJlbmFibGVkIiBsZWFmIHRvIGZhbHNlLg0KICBXaXRoIHRoYXQgaW4gbWluZCwgdGhlcmUg aXMgbm8gcmVhc29uIGZvciB0aGUgIm5vLWZhY2lsaXRpZXMiIGNhc2UgdG8gZXhpc3QuDQoNCiog V2hhdCBpcyB0aGUgYmVoYXZpb3VyIG9mIGEgc2VsZWN0b3IgaWYgbmVpdGhlciAibm8tZmFjaWxp dGllcyIgbm9yICJmYWNpbGl0eS1saXN0IiBpcyBwcmVzZW50Pw0KKiBJbiB0aGUgInNlbGVjdG9y IiBncm91cGluZyBpdCBpcyBub3QgY2xlYXIgaG93IHRoZSBmYWNpbGl0eSBhbmQgcGF0dGVybiBj b25kaXRpb25zIGFyZSBjb21iaW5lZCB0byBkZWNpZGUgd2hldGhlciBhIG1lc3NhZ2UgaXMgc2Vs ZWN0ZWQuDQogIE11c3QgdGhleSBib3RoIG1hdGNoIHRoZSBtZXNzYWdlLCBvciBpcyBpdCBzdWZm aWNpZW50IGZvciBlaXRoZXIgb25lIHRvIG1hdGNoIHRoZSBtZXNzYWdlPw0KKiBOb3QgYWxsIHNl cnZlcnMgaGF2ZSBhIGNvbnNvbGU7IHRoZXJlIHNob3VsZCBiZSBhIGZlYXR1cmUgdG8gaW5kaWNh dGUgd2hldGhlciBsb2dnaW5nIHRvIHRoZSBjb25zb2xlIGlzIHN1cHBvcnRlZC4NCiogTGlrZXdp c2UsIG5vdCBhbGwgc2VydmVycyBtYXkgc3VwcG9ydCBsb2dnaW5nIHRvIHVzZXIgc2Vzc2lvbnMu DQoqIExpa2V3aXNlLCBub3QgYWxsIHNlcnZlcnMgbWF5IHN1cHBvcnQgYSB1c2VyLWFjY2Vzc2li bGUgZmlsZXN5c3RlbS4NCiogUkZDIDU0MjQgc3RhdGVzIHRoYXQgdGhlIHNldmVyaXR5IGFuZCBw cm90b2NvbCB2YWx1ZXMgYXJlIG5vdCBub3JtYXRpdmUuDQoqIEl0J3Mgbm90IGNsZWFyIHRvIG1l IHdoeSB0aGlzIG5lZWRzIHRvIGJlIHNwbGl0IGludG8gdHdvIG1vZHVsZXMuIElzIGl0IHNvIHRo YXQgb3RoZXIgbW9kdWxlcyBjYW4gZGVmaW5lIGxvZ2dpbmcgcGFyYW1ldGVycyBidXQgc3RpbGwg YmUgdXNhYmxlIG9uIGEgZGV2aWNlIHdpdGhvdXQgc3lzbG9nPw0KKiAibG9nLXNldmVyaXR5IiBk ZWZpbmVzIGEgc2V2ZXJpdHkgZmlsdGVyLCBub3QgYSBzZXZlcml0eSwgc28gaXRzIG5hbWUgaXMg bWlzbGVhZGluZy4NCiogUGVyaGFwcyB0aGUgInNldmVyaXR5IiB0eXBlIGFuZCB0aGUgZmFjaWxp dHkgaWRlbnRpdGllcyBzaG91bGQgaGF2ZSAicmVmZXJlbmNlIiBzdGF0ZW1lbnRzIHJlZmVycmlu ZyB0byBSRkMgNTQyNCwgcmF0aGVyIHRoYW4gcmVmZXJyaW5nIHRvIGl0IGluIHRoZSBkZXNjcmlw dGlvbi4NCiogSW4gc2VjdGlvbiAiOC4yIiwgImFkbWlzaW50cmF0b3IiIGlzIGEgdHlwby4NCg0K SSBhc3N1bWUgdGhhdCB0aGUgbWVhbnMgb2YgYWNjZXNzaW5nIHRoZSBtZW1vcnkgYnVmZmVyIGFu ZCBsb2cgZmlsZXMgYXJlIG91dCBvZiBzY29wZSBvZiB0aGlzIGRhdGEgbW9kZWwuDQoNCkFsZXgN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogbmV0bW9k IDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+ PiBvbiBiZWhhbGYgb2YgS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ8bWFpbHRvOmt3 YXRzZW5AanVuaXBlci5uZXQ+Pg0KU2VudDogV2VkbmVzZGF5LCAxNCBEZWNlbWJlciAyMDE2IDI6 MDEgcC5tLg0KVG86IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KU3Vi amVjdDogW25ldG1vZF0gV0cgTGFzdCBDYWxsIGZvciBkcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ct bW9kZWwtMTENCg0KVGhpcyBpcyBhIG5vdGljZSB0byBzdGFydCBhIHR3by13ZWVrIE5FVE1PRCBX RyBsYXN0IGNhbGwgZm9yIHRoZSBkb2N1bWVudDoNCg0KICAgIEEgWUFORyBEYXRhIE1vZGVsIGZv ciBTeXNsb2cgQ29uZmlndXJhdGlvbg0KICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWwtMTENCg0KUGxlYXNlIGluZGljYXRlIHlvdXIg c3VwcG9ydCBvciBjb25jZXJucyBieSBUdWVzZGF5LCBEZWNlbWJlciAyNywgMjAxNi4NCg0KV2Ug YXJlIHBhcnRpY3VsYXJseSBpbnRlcmVzdGVkIGluIHN0YXRlbWVudHMgb2YgdGhlIGZvcm06DQog ICogSSBoYXZlIHJldmlld2VkIHRoaXMgZHJhZnQgYW5kIGZvdW5kIG5vIGlzc3Vlcy4NCiAgKiBJ IGhhdmUgcmV2aWV3ZWQgdGhpcyBkcmFmdCBhbmQgZm91bmQgdGhlIGZvbGxvd2luZyBpc3N1ZXM6 IC4uLg0KDQpBcyB3ZWxsIGFzOg0KICAqIEkgaGF2ZSBpbXBsZW1lbnRlZCB0aGUgZGF0YSBtb2Rl bCBpbiB0aGlzIGRyYWZ0Lg0KICAqIEkgYW0gaW1wbGVtZW50aW5nIHRoZSBkYXRhIG1vZGVsIGlu IHRoaXMgZHJhZnQuDQogICogSSBhbSBjb25zaWRlcmluZyB0byBpbXBsZW1lbnQgdGhlIGRhdGEg bW9kZWwgaW4gdGhpcyBkcmFmdC4NCiAgKiBJIGFtIG5vdCBjb25zaWRlcmluZyB0byBpbXBsZW1l bnQgdGhlIGRhdGEgbW9kZWwgaW4gdGhpcyBkcmFmdC4NCg0KVGhhbmsgeW91LA0KTkVUTU9EIFdH IENoYWlycw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9k QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1v ZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0KDQo= --_000_1CC274D272B94F79A70F3DF332C65A60ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9u dCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ291cmllciBOZXci Ow0KCXBhbm9zZS0xOjIgNyAzIDkgMiAyIDUgMiA0IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg NCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZh bWlseTpDb3VyaWVyO30NCnAuZ21haWwtbS00MjE2MzQ1MTc2MjcxMTYwNDk0cDEsIGxpLmdtYWls LW0tNDIxNjM0NTE3NjI3MTE2MDQ5NHAxLCBkaXYuZ21haWwtbS00MjE2MzQ1MTc2MjcxMTYwNDk0 cDENCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtbV8tNDIxNjM0NTE3NjI3MTE2MDQ5NHAxOw0KCW1z by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KcC5nbWFpbC1tLTQyMTYzNDUxNzYyNzEx NjA0OTRwMiwgbGkuZ21haWwtbS00MjE2MzQ1MTc2MjcxMTYwNDk0cDIsIGRpdi5nbWFpbC1tLTQy MTYzNDUxNzYyNzExNjA0OTRwMg0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXy00MjE2MzQ1MTc2 MjcxMTYwNDk0cDI7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBp bjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpwLmdtYWls LW0tNDIxNjM0NTE3NjI3MTE2MDQ5NHAzLCBsaS5nbWFpbC1tLTQyMTYzNDUxNzYyNzExNjA0OTRw MywgZGl2LmdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NHAzDQoJe21zby1zdHlsZS1uYW1lOmdt YWlsLW1fLTQyMTYzNDUxNzYyNzExNjA0OTRwMzsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCnNwYW4uZ21haWwtbS00MjE2MzQ1MTc2MjcxMTYwNDk0YXBwbGUtY29udmVydGVk LXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fLTQyMTYzNDUxNzYyNzExNjA0OTRhcHBs ZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5nbWFpbC1tLTQyMTYzNDUxNzYyNzExNjA0OTRzMQ0K CXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXy00MjE2MzQ1MTc2MjcxMTYwNDk0czE7fQ0Kc3Bhbi5n bWFpbC1tLTQyMTYzNDUxNzYyNzExNjA0OTRzMg0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXy00 MjE2MzQ1MTc2MjcxMTYwNDk0czI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjp3aW5kb3d0 ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFuLkVt YWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6d2luZG93dGV4dDsNCglmb250LXdlaWdodDpub3Jt YWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI3Ii8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIi8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2Nv bG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5B bnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPk15IGNvbW1lbnRzIGlubGluZSBhcyBbY2x5ZGUyXeKApjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbTogPC9z cGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5B bmR5IEJpZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+ U2F0dXJkYXksIERlY2VtYmVyIDMxLCAyMDE2IGF0IDg6MjQgQU08YnI+DQo8Yj5UbzogPC9iPiZx dW90O0NseWRlIFdpbGRlcyAoY3dpbGRlcykmcXVvdDsgJmx0O2N3aWxkZXNAY2lzY28uY29tJmd0 Ozxicj4NCjxiPkNjOiA8L2I+QWxleCBDYW1wYmVsbCAmbHQ7QWxleC5DYW1wYmVsbEBhdmlhdG5l dC5jb20mZ3Q7LCAmcXVvdDtuZXRtb2RAaWV0Zi5vcmcmcXVvdDsgJmx0O25ldG1vZEBpZXRmLm9y ZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtuZXRtb2RdIFdHIExhc3QgQ2FsbCBmb3Ig ZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsLTExPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIERlYyAzMCwgMjAxNiBhdCAxMDoxNiBB TSwgQ2x5ZGUgV2lsZGVzIChjd2lsZGVzKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmN3aWxkZXNAY2lz Y28uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y3dpbGRlc0BjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5I aSBBbmR5LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPlRoYW5rcyBmb3IgdGFraW5nIHRoZSB0aW1lIHRvIHJldmlldyB0aGUgbW9k ZWwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+TXkgY29tbWVudHMgYXJlIGlubGluZSBhcyBbY2x5ZGVd4oCmPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW47Ym9yZGVyLXJpZ2h0LXdp ZHRoOmluaXRpYWw7Ym9yZGVyLWJvdHRvbS13aWR0aDppbml0aWFsO2JvcmRlci1sZWZ0LXdpZHRo OmluaXRpYWw7Ym9yZGVyLXJpZ2h0LWNvbG9yOmluaXRpYWw7Ym9yZGVyLWJvdHRvbS1jb2xvcjpp bml0aWFsO2JvcmRlci1sZWZ0LWNvbG9yOmluaXRpYWwiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFjayI+RnJvbToN Cjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2si Pm5ldG1vZCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5uZXRt b2QtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmk7Y29sb3I6YmxhY2siPiZndDsgb24gYmVoYWxmIG9mDQogQW5keSBCaWVybWFuICZsdDs8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5hbmR5QHl1bWF3b3Jrcy5jb208L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj4mZ3Q7 PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIERlY2VtYmVyIDI3LCAyMDE2IGF0IDM6MDQgUE08 YnI+DQo8Yj5UbzogPC9iPkFsZXggQ2FtcGJlbGwgJmx0O0FsZXguQ2FtcGJlbGxAQXZpYXRuZXQu Y29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpuZXRt b2RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSI+bmV0bW9kQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaTtjb2xvcjpibGFjayI+JnF1b3Q7ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm5l dG1vZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD YWxpYnJpIj5uZXRtb2RAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpDYWxpYnJpO2NvbG9yOmJsYWNrIj4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbbmV0 bW9kXSBXRyBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYtbmV0bW9kLXN5c2xvZy1tb2RlbC0xMTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkhpLA0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SSBhbSBhbHNvIGNvbnNpZGVyaW5nIGFuIGltcGxlbWVudGF0aW9uLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHNoYXJlIHRoZSBz YW1lIGNvbmNlcm5zIHRoYXQgQWxleCBoYXMgYnJvdWdodCB1cC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNvbWUgZGV0YWlsZWQgY29t bWVudHM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4xKSAvc3lzbG9nL2FjdGlvbnM6IHNlZW1zIGxpa2UgZXZlcnl0aGluZyBpcyBpbiB0 aGlzIGNvbnRhaW5lci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7V2h5IGlzIGl0IG5lZWRlZD8mbmJzcDsgU2VlbXMgbGlrZSBpdCBj b3VsZCBiZSByZW1vdmVkIGFzIGl0IHNlcnZlcyBubyBwdXJwb3NlPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5bY2x5ZGVdIEFsdGhvdWdoIHRoaXMgbW9kZWwgaXMgY3VycmVudGx5IGRlc2ln bmF0ZWQgYXMgY29uZmlnIG9ubHksIHdlIGNvdWxkIGFkZCBvcGVyYXRpb25hbCBkYXRhIGFuZCBy cGMgbGVhdmVzIGluIHRoZSBmdXR1cmUuIFRoZSBhY3Rpb25zIGNvbnRhaW5lciBpcyB0byBmdXR1 cmUtcHJvb2YgdGhlIG1vZGVsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+MikgOCBmZWF0dXJlczogdGhlIGdyYW51bGFyaXR5IHNlZW1z IHdyb25nLiZuYnNwOyBUaGUgbWFpbiBjb250YWluZXIgZm9yIGVhY2ggc2VjdGlvbjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDtzaG91 bGQgaGF2ZSBpdHMgb3duIGlmLWZlYXR1cmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgL2NvbnNvbGU8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgL2J1ZmZlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAvZmlsZTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAvcmVtb3RlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5bY2x5ZGVdIFdlIGhh dmUgZ29uZSBiYWNrIGFuZCBmb3J0aCBvbiB0aGlz4oCmc29tZSBoYXZlIGNvbXBsYWluZWQgdGhh dCB0aGVyZSBhcmUgdG9vIG1hbnkgZmVhdHVyZXMuIEkgd2lsbCBiZSBoYXBweSB0byBhZGQgYSBm ZWF0dXJlIGZvciBlYWNoIGFjdGlvbi4gTm90ZSB0aGF0IHdlIHN0dWRpZWQgdGhlIGltcGxlbWVu dGF0aW9uDQogb2YgZWFjaCBhY3Rpb24gYnkgc2l4IHZlbmRvcnMgaW5jbHVkaW5nIExpbnV4IGFu ZCBvcHRlZCB0byBub3QgYWRkIGZlYXR1cmVzIGZvciBhY3Rpb25zIGltcGxlbWVudGVkIGJ5IGF0 IGxlYXN0IDMgdmVuZG9ycy4gVmVuZG9ycyBub3QgaW1wbGVtZW50aW5nIGFuIGFjdGlvbiBjb3Vs ZCBjcmVhdGUgYSBkZXZpYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSBwcmVmZXIgMSBtYW5kYXRvcnktdG8taW1wbGVtZW50IGFuZCBhIG1pbmltYWwgbnVtYmVy IG9mIGFkZGl0aW9uYWwgb3B0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IC9jb25zb2xlPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgL2ZpbGU8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAvcmVtb3RlPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXNl IGFyZSBhbGwgbWFuZGF0b3J5LXRvLWltcGxlbWVudC4uPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JTU8gb25seSAvZmlsZSBzaG91bGQgYmUgbWFu ZGF0b3J5LXRvLWltcGxlbWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+W2NseWRlMl0gSSB3aWxsIHJlbW92ZSB0aGUgYnVmZmVyIGFuZCBz ZXNzaW9uIGFjdGlvbnMgaW4gdGhlIG5leHQgZHJhZnQgYW5kIHdpbGwgbWFrZSB0aGUgcmVtYWlu aW5nIHRocmVlIGZlYXR1cmVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjMpIFdoYXQgaXMgdGhlICdidWZm ZXInIGNvbnRhaW5lciBmb3I/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOyBIb3cgaXMgdGhlIGludGVybmFsIG1lbW9yeSBhY2Nlc3Nl ZCBieSB0aGUgY2xpZW50PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+W2NseWRlXSBidWZm ZXIgaXMgaW1wbGVtZW50ZWQgYnkgdmVuZG9ycyB0eXBpY2FsbHkgZm9yIHJvdXRlcnMgY2FwYWJs ZSBvZiBnZW5lcmF0aW5nIG1hbnkgc3lzbG9nIG1lc3NhZ2VzIGluIGV2ZW50LXN0b3JtIGJ1cnN0 cy4gTG9nZ2luZyB0byBtZW1vcnkgKGFrYSBidWZmZXIpIGFsbG93cyB0aGUgcHJlc2VydmF0aW9u DQogb2Ygc3lzbG9nIG1lc3NhZ2VzIHdoaWNoIG1pZ2h0IG90aGVyd2lzZSBiZSBsb3N0LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JTU8gaXQgc2hvdWxkIGJlIHJlbW92ZWQgZnJvbSB0aGUg ZHJhZnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5XZSBjZXJ0YWlubHkgaGF2ZSBjaGFuZ2VkIHRoZSBJRVRGIE5NIGZvY3VzLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gU05NUC1sYW5kIHdl IHJvdXRpbmVseSBsZWZ0IHRoZSBjb25maWd1cmF0aW9uIG91dCBvZiBzY29wZTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kIHN0YW5kYXJkaXpl ZCB0aGUgbW9uaXRvcmluZy4mbmJzcDsgTm93IHdlIGFyZSBzdGFuZGFyZGl6aW5nPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgY29uZmlndXJh dGlvbiBhbmQgbGVhdmluZyB0aGUgbW9uaXRvcmluZyBvdXQgb2Ygc2NvcGU/PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHByZWZlciBjb21wbGV0 ZSBzdGFuZGFyZCBzb2x1dGlvbnMgb25seS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgaXMgbm8gc3RhbmRhcmQgd2F5IHRv IGFjY2VzcyB0aGUgL2NvbnNvbGUgZWl0aGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2luY2UgdGhlIGNvbnNvbGUgcHJvdmlkZXMgJnF1b3Q7 c2hvdyBsb2cmcXVvdDsgSSByZWFsbHkgZG8gbm90IHNlZSBhIG5lZWQgZm9yPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vYnVmZmVyIGF0IGFsbC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W2NseWRlMl0gVGhlIGJ1ZmZl ciBhY3Rpb24gd2lsbCBiZSByZW1vdmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkEg4oCcc2hvdyBsb2figJ0gY29t bWFuZCBpcyB1c2VkIHRvIGFjY2VzcyB0aGUgYnVmZmVycy4gQXMgdGhpcyBtb2RlbCBpcyBjdXJy ZW50IGRlc2lnbmVkIGFzIGEgY29uZmlndXJhdGlvbiBvbmx5IG1vZGVsLCB0aGVyZSBpcyBubyBv cGVyYXRpb25hbCBsZWF2ZXMgZm9yIHNob3cgbG9nLCBvciBycGMgbGVhdmVzIGZvcg0KIGNsZWFy IGxvZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjQpIHNlbGVjdG9yLWZhY2lsaXR5OiBTZWVtcyBsaWtlIG5vLWZhY2lsaXRpZXMgc2Vy dmVycyB0aGUgc2FtZSBwdXJwb3NlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgYXMgYW4gZW1wdHkgZmFjaWxpdHktbGlz dC4gVGhlIGNob2ljZSBpcyBub3QgbmVlZGVkOyBqdXN0IHVzZSB0aGUgZmFjaWxpdHktbGlzdDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+W2NseWRlXSBUaGlzIHdhcyBjaGFuZ2VkIGFzIGEg cmVzdWx0IG9mIEFsZXjigJlzIGZlZWRiYWNrIOKAkyBwbGVhc2Ugc2VlIG15IHJlc3BvbnNlIHRv IGhpbS4gVGhlIG1vZGVsIHdpbGwgYmUgY2hhbmdlZCB0byB0aGUgZm9sbG93aW5nOjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJnbWFpbC1tLTQyMTYzNDUxNzYyNzExNjA0OTRwMSI+PHNwYW4gY2xhc3M9ImdtYWls LW0tNDIxNjM0NTE3NjI3MTE2MDQ5NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7ICZuYnNw Ow0KPC9zcGFuPjxzcGFuIGNsYXNzPSJnbWFpbC1tLTQyMTYzNDUxNzYyNzExNjA0OTRzMSI+Y29u dGFpbmVyPC9zcGFuPiBzZWxlY3RvciB7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwt bS00MjE2MzQ1MTc2MjcxMTYwNDk0cDIiPjxzcGFuIGNsYXNzPSJnbWFpbC1tLTQyMTYzNDUxNzYy NzExNjA0OTRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ZGVzY3JpcHRpb248bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTQyMTYzNDUxNzYyNzExNjA0OTRwMyI+PHNwYW4gY2xh c3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCjwvc3Bh bj48L3NwYW4+PHNwYW4gY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NHMyIj4mcXVv dDs8L3NwYW4+VGhpcyBjb250YWluZXIgZGVzY3JpYmVzIHRoZSBsb2cgc2VsZWN0b3IgcGFyYW1l dGVyczxzcGFuIGNsYXNzPSJnbWFpbC1tLTQyMTYzNDUxNzYyNzExNjA0OTRhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1t LTQyMTYzNDUxNzYyNzExNjA0OTRwMyI+PHNwYW4gY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3 MTE2MDQ5NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQo8L3NwYW4+Zm9yIHN5c2xvZy48c3BhbiBjbGFzcz0iZ21haWwtbS00MjE2MzQ1MTc2 MjcxMTYwNDk0czIiPiZxdW90Ozs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21h aWwtbS00MjE2MzQ1MTc2MjcxMTYwNDk0cDEiPjxzcGFuIGNsYXNzPSJnbWFpbC1tLTQyMTYzNDUx NzYyNzExNjA0OTRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOyAmbmJzcDsgJm5ic3A7DQo8 L3NwYW4+PHNwYW4gY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NHMxIj5saXN0PC9z cGFuPiBmYWNpbGl0eS1saXN0IHs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTQy MTYzNDUxNzYyNzExNjA0OTRwMSI+PHNwYW4gY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2 MDQ5NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQo8 L3NwYW4+PHNwYW4gY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NHMxIj5rZXk8L3Nw YW4+IGZhY2lsaXR5OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3 NjI3MTE2MDQ5NHAyIj48c3BhbiBjbGFzcz0iZ21haWwtbS00MjE2MzQ1MTc2MjcxMTYwNDk0YXBw bGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KPC9zcGFuPjwvc3Bhbj5kZXNjcmlwdGlvbjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NHAzIj48c3BhbiBjbGFzcz0i Z21haWwtbS00MjE2MzQ1MTc2MjcxMTYwNDk0YXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NHMyIj4m cXVvdDs8L3NwYW4+VGhpcyBsaXN0IGRlc2NyaWJlcyBhIGNvbGxlY3Rpb24gb2Ygc3lzbG9nPHNw YW4gY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NGFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tNDIxNjM0 NTE3NjI3MTE2MDQ5NHAzIj48c3BhbiBjbGFzcz0iZ21haWwtbS00MjE2MzQ1MTc2MjcxMTYwNDk0 YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQo8L3NwYW4+ZmFjaWxpdGllcyBhbmQgc2V2ZXJpdGllcy48c3BhbiBjbGFzcz0iZ21h aWwtbS00MjE2MzQ1MTc2MjcxMTYwNDk0czIiPiZxdW90Ozs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iZ21haWwtbS00MjE2MzQ1MTc2MjcxMTYwNDk0cDEiPjxzcGFuIGNsYXNzPSJn bWFpbC1tLTQyMTYzNDUxNzYyNzExNjA0OTRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KPC9zcGFuPjxzcGFuIGNsYXNzPSJnbWFpbC1tLTQyMTYzNDUx NzYyNzExNjA0OTRzMSI+bGVhZjwvc3Bhbj4gZmFjaWxpdHkgezxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NHAxIj48c3BhbiBjbGFzcz0iZ21haWwt bS00MjE2MzQ1MTc2MjcxMTYwNDk0YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQo8L3NwYW4+PHNwYW4gY2xhc3M9ImdtYWlsLW0tNDIxNjM0 NTE3NjI3MTE2MDQ5NHMxIj50eXBlPC9zcGFuPiA8c3BhbiBjbGFzcz0iZ21haWwtbS00MjE2MzQ1 MTc2MjcxMTYwNDk0czEiPg0KdW5pb248L3NwYW4+IHs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJnbWFpbC1tLTQyMTYzNDUxNzYyNzExNjA0OTRwMSI+PHNwYW4gY2xhc3M9ImdtYWlsLW0tNDIx NjM0NTE3NjI3MTE2MDQ5NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCjwvc3Bhbj48c3BhbiBjbGFzcz0iZ21haWwtbS00MjE2 MzQ1MTc2MjcxMTYwNDk0czEiPnR5cGU8L3NwYW4+IDxzcGFuIGNsYXNzPSJnbWFpbC1tLTQyMTYz NDUxNzYyNzExNjA0OTRzMSI+DQppZGVudGl0eXJlZjwvc3Bhbj4gezxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NHAxIj48c3BhbiBjbGFzcz0iZ21h aWwtbS00MjE2MzQ1MTc2MjcxMTYwNDk0YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCjwvc3Bhbj48c3BhbiBjbGFz cz0iZ21haWwtbS00MjE2MzQ1MTc2MjcxMTYwNDk0czEiPmJhc2U8L3NwYW4+IHN5c2xvZ3R5cGVz OnN5c2xvZy1mYWNpbGl0eTs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTQyMTYz NDUxNzYyNzExNjA0OTRwMSI+PHNwYW4gY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5 NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCjwvc3Bhbj59PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbS00MjE2 MzQ1MTc2MjcxMTYwNDk0cDEiPjxzcGFuIGNsYXNzPSJnbWFpbC1tLTQyMTYzNDUxNzYyNzExNjA0 OTRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQo8L3NwYW4+PHNwYW4gY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5 NHMxIj50eXBlPC9zcGFuPiA8c3BhbiBjbGFzcz0iZ21haWwtbS00MjE2MzQ1MTc2MjcxMTYwNDk0 czEiPg0KZW51bWVyYXRpb248L3NwYW4+IHs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFp bC1tLTQyMTYzNDUxNzYyNzExNjA0OTRwMSI+PHNwYW4gY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3 NjI3MTE2MDQ5NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQo8L3NwYW4+PHNwYW4gY2xhc3M9ImdtYWlsLW0tNDIx NjM0NTE3NjI3MTE2MDQ5NHMxIj5lbnVtPC9zcGFuPiBhbGwgezxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NHAxIj48c3BhbiBjbGFzcz0iZ21haWwt bS00MjE2MzQ1MTc2MjcxMTYwNDk0YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQo8L3NwYW4+PHNwYW4g Y2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NHMxIj5kZXNjcmlwdGlvbjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTQyMTYzNDUxNzYyNzExNjA0OTRwMyI+ PHNwYW4gY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NGFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48c3Bh biBjbGFzcz0iZ21haWwtbS00MjE2MzQ1MTc2MjcxMTYwNDk0czIiPiZxdW90Ozwvc3Bhbj5UaGlz IGVudW0gZGVzY3JpYmVzIHRoZSBjYXNlIHdoZXJlIGFsbDxzcGFuIGNsYXNzPSJnbWFpbC1tLTQy MTYzNDUxNzYyNzExNjA0OTRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTQyMTYzNDUxNzYyNzExNjA0OTRwMyI+PHNw YW4gY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NGFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCjwvc3Bhbj5mYWNpbGl0aWVzIGFyZSByZXF1ZXN0ZWQuPHNwYW4gY2xh c3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NHMyIj4mcXVvdDs7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NHAxIj48c3BhbiBj bGFzcz0iZ21haWwtbS00MjE2MzQ1MTc2MjcxMTYwNDk0YXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCjwvc3Bhbj59 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbS00MjE2MzQ1MTc2MjcxMTYwNDk0cDEi PjxzcGFuIGNsYXNzPSJnbWFpbC1tLTQyMTYzNDUxNzYyNzExNjA0OTRhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQo8L3NwYW4+ fTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NHAx Ij48c3BhbiBjbGFzcz0iZ21haWwtbS00MjE2MzQ1MTc2MjcxMTYwNDk0YXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQo8L3NwYW4+fTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NHAyIj48c3Bh biBjbGFzcz0iZ21haWwtbS00MjE2MzQ1MTc2MjcxMTYwNDk0YXBwbGUtY29udmVydGVkLXNwYWNl Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsNCjwvc3Bhbj48L3NwYW4+ZGVzY3JpcHRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJnbWFpbC1tLTQyMTYzNDUxNzYyNzExNjA0OTRwMyI+PHNwYW4gY2xhc3M9ImdtYWlsLW0tNDIx NjM0NTE3NjI3MTE2MDQ5NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KPC9zcGFu Pjwvc3Bhbj48c3BhbiBjbGFzcz0iZ21haWwtbS00MjE2MzQ1MTc2MjcxMTYwNDk0czIiPiZxdW90 Ozwvc3Bhbj5UaGUgbGVhZiB1bmlxdWVseSBpZGVudGlmaWVzIGEgc3lzbG9nIGZhY2lsaXR5Ljxz cGFuIGNsYXNzPSJnbWFpbC1tLTQyMTYzNDUxNzYyNzExNjA0OTRzMiI+JnF1b3Q7Ozwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTQyMTYzNDUxNzYyNzExNjA0OTRwMSI+ PHNwYW4gY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NGFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQo8L3NwYW4+fTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NHAxIj48c3BhbiBjbGFzcz0i Z21haWwtbS00MjE2MzQ1MTc2MjcxMTYwNDk0YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCjwvc3Bhbj48c3BhbiBjbGFzcz0iZ21haWwtbS00MjE2MzQ1 MTc2MjcxMTYwNDk0czEiPnVzZXM8L3NwYW4+IGxvZy1zZXZlcml0eTs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJnbWFpbC1tLTQyMTYzNDUxNzYyNzExNjA0OTRwMSI+PHNwYW4gY2xhc3M9Imdt YWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsNCjwvc3Bhbj59PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbS00 MjE2MzQ1MTc2MjcxMTYwNDk0cDEiPjxzcGFuIGNsYXNzPSJnbWFpbC1tLTQyMTYzNDUxNzYyNzEx NjA0OTRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOyAmbmJzcDsgJm5ic3A7DQo8L3NwYW4+ PHNwYW4gY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NHMxIj5sZWFmPC9zcGFuPiBw YXR0ZXJuLW1hdGNoIHs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTQyMTYzNDUx NzYyNzExNjA0OTRwMSI+PHNwYW4gY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NGFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQo8L3NwYW4+ PHNwYW4gY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NHMxIj5pZi1mZWF0dXJlPC9z cGFuPiBzZWxlY3QtbWF0Y2g7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbS00MjE2 MzQ1MTc2MjcxMTYwNDk0cDEiPjxzcGFuIGNsYXNzPSJnbWFpbC1tLTQyMTYzNDUxNzYyNzExNjA0 OTRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KPC9z cGFuPjxzcGFuIGNsYXNzPSJnbWFpbC1tLTQyMTYzNDUxNzYyNzExNjA0OTRzMSI+dHlwZTwvc3Bh bj4gc3RyaW5nOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3 MTE2MDQ5NHAyIj48c3BhbiBjbGFzcz0iZ21haWwtbS00MjE2MzQ1MTc2MjcxMTYwNDk0YXBwbGUt Y29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KPC9zcGFuPjwvc3Bhbj5kZXNjcmlwdGlvbjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NHAzIj48c3BhbiBjbGFzcz0iZ21h aWwtbS00MjE2MzQ1MTc2MjcxMTYwNDk0YXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCjwvc3Bh bj48L3NwYW4+PHNwYW4gY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NHMyIj4mcXVv dDs8L3NwYW4+VGhpcyBsZWFmIGRlc3JpYmVzIGEgUG9zaXggMTAwMy4yIHJlZ3VsYXIgZXhwcmVz c2lvbjxzcGFuIGNsYXNzPSJnbWFpbC1tLTQyMTYzNDUxNzYyNzExNjA0OTRhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1t LTQyMTYzNDUxNzYyNzExNjA0OTRwMyI+PHNwYW4gY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3 MTE2MDQ5NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KPC9zcGFuPnN0cmluZyB0aGF0IGNhbiBiZSB1c2VkIHRvIHNlbGVjdCBh IHN5c2xvZyBtZXNzYWdlIGZvcjxzcGFuIGNsYXNzPSJnbWFpbC1tLTQyMTYzNDUxNzYyNzExNjA0 OTRhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJnbWFpbC1tLTQyMTYzNDUxNzYyNzExNjA0OTRwMyI+PHNwYW4gY2xhc3M9ImdtYWls LW0tNDIxNjM0NTE3NjI3MTE2MDQ5NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KPC9zcGFuPmxvZ2dpbmcuIFRoZSBtYXRjaCBp cyBwZXJmb3JtZWQgb24gdGhlIFJGQyA1NDI0PHNwYW4gY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3 NjI3MTE2MDQ5NGFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW0tNDIxNjM0NTE3NjI3MTE2MDQ5NHAzIj48c3BhbiBjbGFz cz0iZ21haWwtbS00MjE2MzQ1MTc2MjcxMTYwNDk0YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQo8L3NwYW4+U1lTTE9HLU1TRyBm aWVsZC48c3BhbiBjbGFzcz0iZ21haWwtbS00MjE2MzQ1MTc2MjcxMTYwNDk0czIiPiZxdW90Ozs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbS00MjE2MzQ1MTc2MjcxMTYw NDk0cDEiPjxzcGFuIGNsYXNzPSJnbWFpbC1tLTQyMTYzNDUxNzYyNzExNjA0OTRhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOyAmbmJzcDsgJm5ic3A7DQo8L3NwYW4+fTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjUpIHBhdHRlcm4tbWF0Y2g6Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9Indv cmQtd3JhcDpicmVhay13b3JkO3doaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsZWFmIHBhdHRlcm4tbWF0 Y2ggezwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZi1mZWF0dXJl IHNlbGVjdC1tYXRjaDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg dHlwZSBzdHJpbmc7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRl c2NyaXB0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZxdW90O1RoaXMgbGVhZiBkZXNyaWJlcyBhIFBvc2l4IDEwMDMuMiByZWd1bGFyIGV4 cHJlc3Npb248L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgc3RyaW5nIHRoYXQgY2FuIGJlIHVzZWQgdG8gc2VsZWN0IGEgc3lzbG9nIG1l c3NhZ2UgZm9yPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGxvZ2dpbmcuIFRoZSBtYXRjaCBpcyBwZXJmb3JtZWQgb24gdGhlIFJGQyA1 NDI0PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFNZU0xPRy1NU0cgZmllbGQuJnF1b3Q7Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB9PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJl YWstd29yZDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhl IGZpZWxkIFNZU0xPRy1NU0cgaXMgcmVmZXJlbmNlZCBidXQgbmV2ZXIgZGVmaW5lZCBvciBsaXN0 ZWQgaW48YnI+DQp0aGUgdGVybWlub2xvZ3kgc2VjdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPltjbHlkZV0gVGhpcyB3aWxsIGJlIGZpeGVkIGluIHRoZSBuZXh0IGRyYWZ0LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Nikg aG93IGFyZSB0aGUgc3lzbG9nLWZhY2lsaXR5IGlkZW50aXRpZXMgbWFwcGVkIHRvIFNZU0xPRyBt ZXNzYWdlcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+NmEpIGhvdyB0byBkaXN0aW5ndWlzaCBhY21lOmZvby1mYWNpbGl0eSBmcm9tIGV4YW1w bGU6Zm9vLWZhY2lsaXR5IGluIGEgU1lTTE9HIG1lc3NhZ2U/PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5bY2x5ZGVdIEkgZG8gbm90IHVuZGVyc3RhbmQgeW91ciBxdWVzdGlvbi4gVGhlIGN1 cnJlbnQgaW1wbGVtZW50YXRpb24gb2YgZmFjaWxpdGllcyB3YXMgZGVzaWduZWQgd2l0aCB0aGUg aGVscCBvZiBzZXZlcmFsIFlhbmcgRG9jdG9ycy4gVGhlIHJlcXVpcmVtZW50IGlzIHRvIHN1cHBv cnQgdGhlIGZhY2lsaXRpZXMNCiBhcyBjYWxsZWQgb3V0IGluIFJGQyA1NDI0IGFzIHdlbGwgYXMg dmVuZG9yIHNwZWNpZmljIGZhY2lsaXRpZXMgdGhhdCBjYW4gYmUgYWRkZWQgdGhyb3VnaCBhdWdt ZW50YXRpb24uIFZlbmRvciBzcGVjaWZpYyBmYWNpbGl0aWVzIGFyZSBub3QgbWVhbnQgdG8gYmUg dXNlZCBhY3Jvc3MgbXVsdGlwbGUgdmVuZG9yIGltcGxlbWVudGF0aW9ucy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZmlsdGVyIGlzIGJhc2Vk IG9uIGFuIGlkZW50aXR5cmVmLCB3aGljaCBpcyBhIG1vZHVsZS1xdWFsaWZpZWQgbmFtZSw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmUuZy4sIGFj bWU6Zm9vLWZhY2lsaXR5IGFuZCBleGFtcGxlOmZvby1mYWNpbGl0eSBhcmUgZGlmZmVyZW50IGVu dGl0aWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SW4gdGhlIHN5c2xvZyBtZXNzYWdlLCBvbmx5IHRoZSBzdHJpbmcgZm9vLWZhY2lsaXR5IHdp bGwgYmUgcHJlc2VudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZSBkcmFmdCBjbGFpbXMgdG8gcHJvdmlkZSBleHRlbnNpYmxlIGZhY2lsaXRp ZXMsKHNlZSBBLjEpICZuYnNwO2J1dCBpdCBvbmx5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zZWVtcyB0byB3b3JrIGlmIHRoZSBpZGVudGl0aWVz IGRvIG5vdCBjb250YWluIGFueSBkdXBsaWNhdGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltjbHlkZTJdIEluIG15IGV4cGVyaWVuY2Ug bG9va2luZyBhdCBtdWx0aXBsZSB2ZW5kb3IgaW1wbGVtZW50YXRpb25zIEkgZGlkIG5vdCBzZWUg YW55IGR1cGxpY2F0ZXMuIElmIHlvdSBoYXZlIGEgc3VnZ2VzdGlvbiBvbiBhbm90aGVyIHdheSB0 byBleHRlbmQgZmFjaWxpdGllcywgSSBhbSBhbGwgZWFycy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj43 KSBzb3VyY2UtaW50ZXJmYWNlOiB3aGF0IGlmIHRoZSBzZXJ2ZXIgZG9lcyBub3QgbGV0IGEgc291 cmNlIGludGVyZmFjZSBiZSB1c2VkIGFuZCBpbnN0ZWFkPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgbm9ybWFsIHJvdXRp bmcgZGV0ZXJtaW5lcyB0aGUgc291cmNlIGludGVyZmFjZSAodGhpcyBsZWFmIGlzIHZlcnkgcm91 dGVyLWNlbnRyaWMpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5bY2x5ZGVdIHNvdXJjZS1p bnRlcmZhY2UgaXMgb3B0aW9uYWwuIElmIG5vdCBzcGVjaWZpZWQgbm9ybWFsIHJvdXRpbmcgZmxv dyB3b3VsZCBiZSB1c2VkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+OCkgc2lnbmluZy1vcHRpb25zOiBhcmUgdGhlc2Ugd2lkZWx5IGRl cGxveWVkIG9uIGFsbCByb3V0ZXJzIGFuZCBMaW51eCBob3N0cz88bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPltjbHlkZV0gQWxleCBDbGVtbSBhc2tlZCB0aGF0IHdlIGluY2x1ZGUgc3lzbG9n IHNpZ25pbmctb3B0aW9ucy4gVGhpcyBpcyBpbXBsZW1lbnRlZCBieSBhdCBsZWFzdCBMaW51eCBy c3lzbG9nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+OSkgbG9ncm90YXRlOiB0aGVyZSBhcmUgc2V2ZXJhbCBmZWF0dXJlcyByZWxhdGVk IHRvIGxvZyBmaWxlIGNsZWFudXAgYWxsb3dpbmcgbG90cyBvZjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IHNlcnZlciB2 YXJpYWJpbGl0eSBhbmQgZm9yY2VzIHRoZSBjbGllbnQgdG8gc3VwcG9ydCBhbGwgdGhlIG9wdGlv bnMuJm5ic3A7IENhbid0IHRoaXMgYmUgc2ltcGxpZmllZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7YW5kIGFsbCB0aGUg bWljcm8tYmVoYXZpb3IgWUFORyBmZWF0dXJlcyByZW1vdmVkPzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+W2NseWRlXSBUaGlzIHdhcyBkZXNpZ25lZCBieSBtZXJnaW5nIHRoZSByZXF1aXJl bWVudHMgZnJvbSBzZXZlcmFsIHZlbmRvcnMuIEFsbCBvZiB0aGUgdmFyaWFudHMgc3BlY2lmaWVk IGFyZSB3aXRoIGlmLWZlYXR1cmUgc28gdGhhdCB0aGUgY2xpZW50IGRvZXMgbm90IGhhdmUgdG8g c3VwcG9ydCBhbGwgb3B0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlcmUgc2VlbXMgdG8gYmUgc29tZSBwcm9jZWR1cmVzIGltcGxpZWQgYnkg dGhlc2UgWUFORyBvYmplY3RzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+YnV0IGl0IGlzIG5vdCBzcGVjaWZpZWQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSA0IGRpZmZlcmVudCBtZXRo b2RzIChlYWNoIHdpdGggaXRzIG93biBmZWF0dXJlKSwgYXJlIGluIGEgY29udGFpbmVyLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2luY2UgY29u dGFpbmVyICdmaWxlLXJvdGF0aW9uJyBpcyBpbiBsaXN0ICdsb2ctZmlsZScsIHRoZSByb3RhdGlv biB2YXJpYW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5jYW4gYmUgZGlmZmVyZW50IGZvciBldmVyeSBmaWxlLiZuYnNwOyBJcyB0aGlzIHJlYWxs eSBob3cgaW1wbGVtZW50YXRpb25zIHdvcms/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPltjbHlkZTJdIFdlIGNvbnNvbGlkYXRlZCB0aGUgcmVxdWlyZW1lbnRzIGZyb20g bXVsdGlwbGUgdmVuZG9ycy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVuaXBlciBsb2cgZmls ZSBhcmNoaXZpbmcgaXMgYXZhaWxhYmxlIHZpYSBhIGdsb2JhbCBzZXR0aW5nIG9yIG9uIGFuIGlu ZGl2aWR1YWwgZmlsZSDigJMgYm90aCBudW1iZXIgb2YgZmlsZXMgYW5kIGZpbGUgc2l6ZSBhcmUg c3VwcG9ydGVkLiBTZWUNCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmp1bmlwZXIubmV0L2RvY3VtZW50 YXRpb24vZW5fVVMvanVub3MxMi4zL2luZm9ybWF0aW9uLXByb2R1Y3RzL3RvcGljLWNvbGxlY3Rp b25zL3N5c2xvZy1tZXNzYWdlcy9pbmRleC5odG1sP2pkMGU5MjEuaHRtbCI+DQpodHRwczovL3d3 dy5qdW5pcGVyLm5ldC9kb2N1bWVudGF0aW9uL2VuX1VTL2p1bm9zMTIuMy9pbmZvcm1hdGlvbi1w cm9kdWN0cy90b3BpYy1jb2xsZWN0aW9ucy9zeXNsb2ctbWVzc2FnZXMvaW5kZXguaHRtbD9qZDBl OTIxLmh0bWw8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNpc2NvIGxvZyBmaWxlIGFyY2hp dmluZyBpcyBzcGVjaWZpZWQgZm9yIGFuIGluZGl2aWR1YWwgZmlsZS4gRmlsZSBzaXplIGFuZCBv cHRpb25hbGx5IGEgaGFyZCBjb2RlIG1heGltdW0gbnVtYmVyIG9mIGJ5dGVzIHNldCBhc2lkZSBm b3IgbG9nZ2luZyBvciBhIHBlcmNlbnQgb2YgdG90YWwgZGlzayBzcGFjZSBhdmFpbGFibGUgZm9y IGxvZ2dpbmcgbWF5IGJlIHNwZWNpZmllZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly93d3cuY2lzY28uY29tL2MvZW4vdXMvdGQvZG9jcy9pb3Mt eG1sL2lvcy9lc20vY29tbWFuZC9lc20tY3ItYm9vay9lc20tY3ItYTEuaHRtbCN3cDg3MDg1MzQ3 NDAiPmh0dHA6Ly93d3cuY2lzY28uY29tL2MvZW4vdXMvdGQvZG9jcy9pb3MteG1sL2lvcy9lc20v Y29tbWFuZC9lc20tY3ItYm9vay9lc20tY3ItYTEuaHRtbCN3cDg3MDg1MzQ3NDA8L2E+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFsY2F0ZWwtTHVjZW50IGxvZyBmaWxlIGFyY2hpdmluZyBpcyBz cGVjaWZpZWQgZm9yIGFuIGluZGl2aWR1YWwgZmlsZSBhbmQgc3VwcG9ydHMgcm9sbG92ZXIgaW4g bWludXRlcyBhbmQgcmV0ZW50aW9uIGluIGhvdXJzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9pbmZvcHJvZHVjdHMuYWxjYXRlbC1sdWNlbnQu Y29tL2h0bWwvMF9hZGQtaC1mLzkzLTAwNzEtMTAtMDEvNzc1MF9TUl9PU19TeXN0ZW1fTWFuYWdl bWVudF9HdWlkZS9Mb2djbGkuaHRtbCMxMDM4MzAxIj5odHRwczovL2luZm9wcm9kdWN0cy5hbGNh dGVsLWx1Y2VudC5jb20vaHRtbC8wX2FkZC1oLWYvOTMtMDA3MS0xMC0wMS83NzUwX1NSX09TX1N5 c3RlbV9NYW5hZ2VtZW50X0d1aWRlL0xvZ2NsaS5odG1sIzEwMzgzMDE8L2E+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoZSBzZXJ2ZXIgaXMgZnJlZSB0byBzdXBwb3J0IGZyb20gbm9uZSB0byBh bGwgb2YgdGhlIGFyY2hpdmluZyBmZWF0dXJlcyAobm90ZTogdGhleSBhcmUgc3BlY2lmaWVkIGFz IGZlYXR1cmVzKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNvLCB0aGUgZGlmZmVyZW50 IHBhcmFtZXRlcnMgaW4gdGhpcyBjb250YWluZXIgY2FuIGludGVyYWN0IGlmIHRoZSBzZXJ2ZXI8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnN1cHBv cnRzIG1vcmUgdGhhbiAxIGZlYXR1cmUuJm5ic3A7IFRoZSBkcmFmdCBkb2VzIG5vdCBzYXkgYW55 dGhpbmcgYWJvdXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmNvbWJpbmluZyB0aGVtLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5FLmcuOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGxlYWYgbnVtYmVyLW9mLWZpbGVzIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaWYtZmVhdHVyZSBmaWxlLWxpbWl0LXNp emU7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9y ZTphbHdheXMiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHR5cGUgdWludDMyOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1i cmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBkZXNjcmlwdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls ZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtUaGlzIGxlYWYgc3BlY2lmaWVz IHRoZSBtYXhpbXVtIG51bWJlciBvZiBsb2c8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUg c3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZmlsZXMgcmV0YWluZWQu IFNwZWNpZnkgMSBmb3IgaW1wbGVtZW50YXRpb25zPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoYXQgb25seSBz dXBwb3J0IG9uZSBsb2cgZmlsZS4mcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xv cjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PGJyIGNsZWFyPSJhbGwiIHN0eWxl PSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPg0KPGJyIGNsZWFyPSJhbGwiIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMiPg0KPC9zcGFuPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93 IGRvZXMgdGhlIGNsaWVudCBrbm93IGlmIHRoZSBzZXJ2ZXIgb25seSBzdXBwb3J0cyAxIGZpbGUg b3Igbm90PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhpcyBzaG91bGQgcmVhbGx5IGJlIHJldmlzaW9ucywgc2luY2UgdGhlc2UgZmlsZXMgYXJl Jm5ic3A7cGVyIGxvZy1maWxlIGxpc3QgZW50cnkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltj bHlkZTJdIE1ha2UgdGhlIGRlZmF1bHQgMT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgb25seSAxIHJldmlzaW9uIG9mIHRoZSBsb2ctZmls ZSBpcyByZXRhaW5lZCwgdGhlbiB0aGUgbWVhbmluZyBvZiB0aGUgb3RoZXI8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmxlYWZzIGlzIHVuY2xlYXIu IElmIHRoZXJlIGlzIG9ubHkgMSBsb2ctZmlsZSByZXZpc2lvbiwgdGhlbiB3aGF0IGhhcHBlbnM8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmlmIHRo ZSBtYXgtZmlsZS1zaXplICMgb2YgbWVnYWJ5dGVzLCByb2xsb3ZlciAjIG9mIG1pbnV0ZXMsIG9y IHJldGVudGlvbiAjIG9mIGhvdXJzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5pcyByZWFjaGVkPyZuYnNwOyBEb2VzIHN5c2xvZyBtb25pdG9yaW5n IHN0b3AgZm9yIHRoZSBsb2ctZmlsZSBlbnRyeT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W2Ns eWRlMl0gSWYgb25lIGxvZy1maWxlIGlzIHNwZWNpZmllZCBhbmQgbWF4LWZpbGUtc2l6ZSBpcyBz cGVjaWZpZWQsIHRoZSBzaW5nbGUgZmlsZSBpcyBvdmVyd3JpdHRlbiB3aGVuIG1heC1maWxlLXNp emUgbGltaXQgaXMgZW5jb3VudGVyZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBkb2VzIHRoZSBjbGllbnQgYWNjZXNzIGRpZmZlcmVu dCByZXZpc2lvbnMgb2YgdGhlIGxvZyBmaWxlPyBPciBldmVuIGxpc3QgdGhlbT88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBkb2VzIHRoZSBj bGllbnQga25vdyB0aGUgY3VycmVudCBzaXplIG9mIGxpZmV0aW1lIG9mIHRoZSBsb2ctZmlsZTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhleSBk byBub3QgaGF2ZSBuYW1lcy4gSXMgaXQgYXNzdW1lZCB0aGV5IHdpbGwgYmUgdGhlIGxvZy1maWxl L25hbWUgZmllbGQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmFwcGVuZGVkIHdpdGggJnF1b3Q7LjEmcXVvdDssICZxdW90Oy4yJnF1b3Q7LCBldGMu PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bY2x5ZGUyXSBUaGVyZSBp cyBubyBhdHRlbXB0IHRvIHN1cHBvcnQgb3BlciBkYXRhIGluIHRoaXMgbW9kZWwuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DbHlkZTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4xMCkgbnVtZXJpYyBsaW1pdHM6IHRoZXJlIGlzIHNvbWUgb2RkIHVz YWdlIG9mIFlBTkcgdHlwZXM7IHNvbWUgbGltaXRzIGFyZSB1aW50NjQsIHNvbWUgdWludDMyLDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5zb21l IHVpbnQxNi4mbmJzcDsgU2VlbXMgbGlrZSB1aW50MzIgaXMgc3VmZmljaWVudDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+W2NseWRlXSZuYnNwOyBUaGUgc2lnbmluZy1vcHRpb25zIGNvdW50 cyBhcmUgYXMgcGVyIHRoZSBzeXNsb2ctc2lnbiBzcGVjIChSRkMgNTg0OCkgd2hpY2ggaXMgdWlu dDE2LiBJIHdpbGwgbWFrZSBhbGwgb3RoZXJzIHVpbnQzMiBleGNlcHQgZm9yIHRoZSBidWZmZXIg c2l6ZSBsaW1pdCB3aGljaCBJIHdpbGwgbGVhdmUNCiBhdCB1bml0NjQuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5SZXN1bHQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZsdDtzZXZlbiBzaWduaW5nLW9wdGlvbnMgY291bnRlcnMmZ3Q7IHVpbnQxNjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5idWZmZXItbGltaXQtYnl0ZXMgdWludDY0 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmJ1ZmZlci1saW1pdC1tZXNz YWdlcyB1aW50MzIgKHdhcyBmb3JtYWxseSB1aW50NjQpPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPm51bWJlci1vZi1maWxlcyB1aW50MzI8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+bWF4LWZpbGUtc2l6ZSB1aW50MzIgKHdhcyBmb3JtYWxseSB1 aW50NjQpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnJvbGxvdmVyIHVu aXQzMjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5yZXRlbnRpb24gdW5p dDMyICh3YXMgZm9ybWFsbHkgdWludDE2KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rcyw8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkNseWRlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW5k eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5P biBUdWUsIERlYyAxMywgMjAxNiBhdCA4OjE2IFBNLCBBbGV4IENhbXBiZWxsICZsdDs8YSBocmVm PSJtYWlsdG86QWxleC5DYW1wYmVsbEBhdmlhdG5ldC5jb20iIHRhcmdldD0iX2JsYW5rIj5BbGV4 LkNhbXBiZWxsQGF2aWF0bmV0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdDtib3JkZXItdG9wLXdp ZHRoOmluaXRpYWw7Ym9yZGVyLXJpZ2h0LXdpZHRoOmluaXRpYWw7Ym9yZGVyLWJvdHRvbS13aWR0 aDppbml0aWFsO2JvcmRlci10b3AtY29sb3I6aW5pdGlhbDtib3JkZXItcmlnaHQtY29sb3I6aW5p dGlhbDtib3JkZXItYm90dG9tLWNvbG9yOmluaXRpYWwiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5JIGFtIGNvbnNpZGVyaW5nIHRvIGltcGxlbWVudCB0aGUgZGF0YSBtb2RlbCBpbiB0aGlzIGRy YWZ0Ljxicj4NCjxicj4NCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRyYWZ0IGFuZCBmb3VuZCB0aGUg Zm9sbG93aW5nIGlzc3Vlcy4gSW4gYXBwcm94aW1hdGVseSBkZWNyZWFzaW5nIG9yZGVyIG9mIHNl dmVyaXR5Ojxicj4NCjxicj4NCiogSW4gdGhlICZxdW90O3NlbGVjdG9yLWZhY2lsaXR5JnF1b3Q7 IGNob2ljZSBzdGF0ZW1lbnQgdGhlIGNhc2VzIGhhdmUgbWlzbGVhZGluZyBuYW1lcyAtIHRoZSBj YXNlIHdoZXJlIG5vIGZhY2lsaXR5IGlzIG1hdGNoZWQgaXMgbmFtZWQgJnF1b3Q7ZmFjaWxpdHkm cXVvdDssIGFuZCB0aGUgY2FzZSB3aGVyZSBzcGVjaWZpYyBmYWNpbGl0aWVzIGFyZSBtYXRjaGVk IGlzIG5hbWVkICZxdW90O25hbWUmcXVvdDsuIEkgc3VnZ2VzdCAmcXVvdDtuby1mYWNpbGl0aWVz JnF1b3Q7IGFuZCAmcXVvdDtzcGVjaWZpZWQtZmFjaWxpdGllcyZxdW90OywNCiBvciBzaW1pbGFy Ljxicj4NCjxicj4NCiogSSBkaXNhZ3JlZSB3aXRoIHRoZSBwcmVtaXNlIG9mIHRoZSAmcXVvdDtu by1mYWNpbGl0aWVzJnF1b3Q7IGNhc2UsIHdoaWNoIGlzIHRoYXQgaXQgY2FuIGJlIHVzZWQgdG8g ZGlzYWJsZSBhIGxvZyBhY3Rpb24sIGFjY29yZGluZyB0byB0aGUgZGVzY3JpcHRpb246PGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtkZXNjcmlwdGlvbjxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O1RoaXMgY2FzZSBzcGVjaWZpZXMgbm8g ZmFjaWxpdGllcyB3aWxsIG1hdGNoIHdoZW48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjb21wYXJpbmcgdGhlIHN5c2xvZyBtZXNzYWdlIGZhY2ls aXR5LiBUaGlzIGlzIGE8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDttZXRob2QgdGhhdCBjYW4gYmUgdXNlZCB0byBlZmZlY3RpdmVseSBkaXNhYmxl IGE8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtw YXJ0aWN1bGFyIGxvZy1hY3Rpb24gKGJ1ZmZlciwgZmlsZSwgZXRjKS4mcXVvdDs7PGJyPg0KPGJy Pg0KJm5ic3A7IElmIGFuIGFkbWluaXN0cmF0b3Igd2FudHMgdG8gZGlzYWJsZSBhIGxvZyBhY3Rp b24gdGhleSBzaG91bGQgZG8gaXQgYnkgZWl0aGVyIHJlbW92aW5nIGl0IGZyb20gdGhlIGNvbmZp Z3VyYXRpb24sIG9yIGJ5IHNldHRpbmcgYW4gJnF1b3Q7ZW5hYmxlZCZxdW90OyBsZWFmIHRvIGZh bHNlLjxicj4NCiZuYnNwOyBXaXRoIHRoYXQgaW4gbWluZCwgdGhlcmUgaXMgbm8gcmVhc29uIGZv ciB0aGUgJnF1b3Q7bm8tZmFjaWxpdGllcyZxdW90OyBjYXNlIHRvIGV4aXN0Ljxicj4NCjxicj4N CiogV2hhdCBpcyB0aGUgYmVoYXZpb3VyIG9mIGEgc2VsZWN0b3IgaWYgbmVpdGhlciAmcXVvdDtu by1mYWNpbGl0aWVzJnF1b3Q7IG5vciAmcXVvdDtmYWNpbGl0eS1saXN0JnF1b3Q7IGlzIHByZXNl bnQ/PGJyPg0KKiBJbiB0aGUgJnF1b3Q7c2VsZWN0b3ImcXVvdDsgZ3JvdXBpbmcgaXQgaXMgbm90 IGNsZWFyIGhvdyB0aGUgZmFjaWxpdHkgYW5kIHBhdHRlcm4gY29uZGl0aW9ucyBhcmUgY29tYmlu ZWQgdG8gZGVjaWRlIHdoZXRoZXIgYSBtZXNzYWdlIGlzIHNlbGVjdGVkLjxicj4NCiZuYnNwOyBN dXN0IHRoZXkgYm90aCBtYXRjaCB0aGUgbWVzc2FnZSwgb3IgaXMgaXQgc3VmZmljaWVudCBmb3Ig ZWl0aGVyIG9uZSB0byBtYXRjaCB0aGUgbWVzc2FnZT88YnI+DQoqIE5vdCBhbGwgc2VydmVycyBo YXZlIGEgY29uc29sZTsgdGhlcmUgc2hvdWxkIGJlIGEgZmVhdHVyZSB0byBpbmRpY2F0ZSB3aGV0 aGVyIGxvZ2dpbmcgdG8gdGhlIGNvbnNvbGUgaXMgc3VwcG9ydGVkLjxicj4NCiogTGlrZXdpc2Us IG5vdCBhbGwgc2VydmVycyBtYXkgc3VwcG9ydCBsb2dnaW5nIHRvIHVzZXIgc2Vzc2lvbnMuPGJy Pg0KKiBMaWtld2lzZSwgbm90IGFsbCBzZXJ2ZXJzIG1heSBzdXBwb3J0IGEgdXNlci1hY2Nlc3Np YmxlIGZpbGVzeXN0ZW0uPGJyPg0KKiBSRkMgNTQyNCBzdGF0ZXMgdGhhdCB0aGUgc2V2ZXJpdHkg YW5kIHByb3RvY29sIHZhbHVlcyBhcmUgbm90IG5vcm1hdGl2ZS48YnI+DQoqIEl0J3Mgbm90IGNs ZWFyIHRvIG1lIHdoeSB0aGlzIG5lZWRzIHRvIGJlIHNwbGl0IGludG8gdHdvIG1vZHVsZXMuIElz IGl0IHNvIHRoYXQgb3RoZXIgbW9kdWxlcyBjYW4gZGVmaW5lIGxvZ2dpbmcgcGFyYW1ldGVycyBi dXQgc3RpbGwgYmUgdXNhYmxlIG9uIGEgZGV2aWNlIHdpdGhvdXQgc3lzbG9nPzxicj4NCiogJnF1 b3Q7bG9nLXNldmVyaXR5JnF1b3Q7IGRlZmluZXMgYSBzZXZlcml0eSBmaWx0ZXIsIG5vdCBhIHNl dmVyaXR5LCBzbyBpdHMgbmFtZSBpcyBtaXNsZWFkaW5nLjxicj4NCiogUGVyaGFwcyB0aGUgJnF1 b3Q7c2V2ZXJpdHkmcXVvdDsgdHlwZSBhbmQgdGhlIGZhY2lsaXR5IGlkZW50aXRpZXMgc2hvdWxk IGhhdmUgJnF1b3Q7cmVmZXJlbmNlJnF1b3Q7IHN0YXRlbWVudHMgcmVmZXJyaW5nIHRvIFJGQyA1 NDI0LCByYXRoZXIgdGhhbiByZWZlcnJpbmcgdG8gaXQgaW4gdGhlIGRlc2NyaXB0aW9uLjxicj4N CiogSW4gc2VjdGlvbiAmcXVvdDs4LjImcXVvdDssICZxdW90O2FkbWlzaW50cmF0b3ImcXVvdDsg aXMgYSB0eXBvLjxicj4NCjxicj4NCkkgYXNzdW1lIHRoYXQgdGhlIG1lYW5zIG9mIGFjY2Vzc2lu ZyB0aGUgbWVtb3J5IGJ1ZmZlciBhbmQgbG9nIGZpbGVzIGFyZSBvdXQgb2Ygc2NvcGUgb2YgdGhp cyBkYXRhIG1vZGVsLjxicj4NCjxicj4NCkFsZXg8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KRnJvbTogbmV0bW9kICZsdDs8YSBocmVmPSJt YWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRtb2QtYm91 bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBLZW50IFdhdHNlbiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQiIHRhcmdldD0iX2JsYW5rIj5rd2F0c2VuQGp1 bmlwZXIubmV0PC9hPiZndDs8YnI+DQpTZW50OiBXZWRuZXNkYXksIDE0IERlY2VtYmVyIDIwMTYg MjowMSBwLm0uPGJyPg0KVG86IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogW25ldG1vZF0gV0cg TGFzdCBDYWxsIGZvciBkcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWwtMTE8YnI+DQo8YnI+ DQpUaGlzIGlzIGEgbm90aWNlIHRvIHN0YXJ0IGEgdHdvLXdlZWsgTkVUTU9EIFdHIGxhc3QgY2Fs bCBmb3IgdGhlIGRvY3VtZW50Ojxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgQSBZQU5HIERhdGEg TW9kZWwgZm9yIFN5c2xvZyBDb25maWd1cmF0aW9uPGJyPg0KJm5ic3A7ICZuYnNwOyA8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1v ZGVsLTExIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsLTExPC9hPjxicj4NCjxicj4NClBsZWFzZSBpbmRp Y2F0ZSB5b3VyIHN1cHBvcnQgb3IgY29uY2VybnMgYnkgVHVlc2RheSwgRGVjZW1iZXIgMjcsIDIw MTYuPGJyPg0KPGJyPg0KV2UgYXJlIHBhcnRpY3VsYXJseSBpbnRlcmVzdGVkIGluIHN0YXRlbWVu dHMgb2YgdGhlIGZvcm06PGJyPg0KJm5ic3A7ICogSSBoYXZlIHJldmlld2VkIHRoaXMgZHJhZnQg YW5kIGZvdW5kIG5vIGlzc3Vlcy48YnI+DQombmJzcDsgKiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBk cmFmdCBhbmQgZm91bmQgdGhlIGZvbGxvd2luZyBpc3N1ZXM6IC4uLjxicj4NCjxicj4NCkFzIHdl bGwgYXM6PGJyPg0KJm5ic3A7ICogSSBoYXZlIGltcGxlbWVudGVkIHRoZSBkYXRhIG1vZGVsIGlu IHRoaXMgZHJhZnQuPGJyPg0KJm5ic3A7ICogSSBhbSBpbXBsZW1lbnRpbmcgdGhlIGRhdGEgbW9k ZWwgaW4gdGhpcyBkcmFmdC48YnI+DQombmJzcDsgKiBJIGFtIGNvbnNpZGVyaW5nIHRvIGltcGxl bWVudCB0aGUgZGF0YSBtb2RlbCBpbiB0aGlzIGRyYWZ0Ljxicj4NCiZuYnNwOyAqIEkgYW0gbm90 IGNvbnNpZGVyaW5nIHRvIGltcGxlbWVudCB0aGUgZGF0YSBtb2RlbCBpbiB0aGlzIGRyYWZ0Ljxi cj4NCjxicj4NClRoYW5rIHlvdSw8YnI+DQpORVRNT0QgV0cgQ2hhaXJzPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjxicj4N Cjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KbmV0bW9kIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1CC274D272B94F79A70F3DF332C65A60ciscocom_-- From nobody Wed Jan 11 23:40:15 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C3912943E for ; Wed, 11 Jan 2017 23:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnWY6PdyHqM3 for ; Wed, 11 Jan 2017 23:40:12 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CEE1E12948D for ; Wed, 11 Jan 2017 23:40:11 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 476691AE01AA; Thu, 12 Jan 2017 08:40:10 +0100 (CET) Date: Thu, 12 Jan 2017 08:40:08 +0100 (CET) Message-Id: <20170112.084008.1351626812220200931.mbj@tail-f.com> To: cwildes@cisco.com From: Martin Bjorklund In-Reply-To: <1CC274D2-72B9-4F79-A70F-3DF332C65A60@cisco.com> References: <3F4C49C9-1A6A-4644-97C6-F9CDC2E4EB4B@cisco.com> <1CC274D2-72B9-4F79-A70F-3DF332C65A60@cisco.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 07:40:13 -0000 SGksDQoNCiJDbHlkZSBXaWxkZXMgKGN3aWxkZXMpIiA8Y3dpbGRlc0BjaXNjby5jb20+IHdyb3Rl Og0KPiBBbnkNCj4gDQo+IE15IGNvbW1lbnRzIGlubGluZSBhcyBbY2x5ZGUyXeKApg0KPiANCj4g RnJvbTogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+DQo+IERhdGU6IFNhdHVyZGF5 LCBEZWNlbWJlciAzMSwgMjAxNiBhdCA4OjI0IEFNDQo+IFRvOiAiQ2x5ZGUgV2lsZGVzIChjd2ls ZGVzKSIgPGN3aWxkZXNAY2lzY28uY29tPg0KPiBDYzogQWxleCBDYW1wYmVsbCA8QWxleC5DYW1w YmVsbEBhdmlhdG5ldC5jb20+LCAibmV0bW9kQGlldGYub3JnIg0KPiA8bmV0bW9kQGlldGYub3Jn Pg0KPiBTdWJqZWN0OiBSZTogW25ldG1vZF0gV0cgTGFzdCBDYWxsIGZvcg0KPiBkcmFmdC1pZXRm LW5ldG1vZC1zeXNsb2ctbW9kZWwtMTENCj4gDQo+IA0KPiANCj4gT24gRnJpLCBEZWMgMzAsIDIw MTYgYXQgMTA6MTYgQU0sIENseWRlIFdpbGRlcyAoY3dpbGRlcykNCj4gPGN3aWxkZXNAY2lzY28u Y29tPG1haWx0bzpjd2lsZGVzQGNpc2NvLmNvbT4+IHdyb3RlOg0KPiBIaSBBbmR5LA0KPiANCj4g VGhhbmtzIGZvciB0YWtpbmcgdGhlIHRpbWUgdG8gcmV2aWV3IHRoZSBtb2RlbC4NCj4gDQo+IE15 IGNvbW1lbnRzIGFyZSBpbmxpbmUgYXMgW2NseWRlXeKApg0KPiANCj4gRnJvbTogbmV0bW9kIDxu ZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+Pg0K PiBvbiBiZWhhbGYgb2YgQW5keSBCaWVybWFuDQo+IDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRv OmFuZHlAeXVtYXdvcmtzLmNvbT4+DQo+IERhdGU6IFR1ZXNkYXksIERlY2VtYmVyIDI3LCAyMDE2 IGF0IDM6MDQgUE0NCj4gVG86IEFsZXggQ2FtcGJlbGwgPEFsZXguQ2FtcGJlbGxAQXZpYXRuZXQu Y29tPg0KPiBDYzogIm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPiINCj4g PG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPj4NCj4gU3ViamVjdDogUmU6 IFtuZXRtb2RdIFdHIExhc3QgQ2FsbCBmb3INCj4gZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1v ZGVsLTExDQo+IA0KPiBIaSwNCj4gDQo+IEkgYW0gYWxzbyBjb25zaWRlcmluZyBhbiBpbXBsZW1l bnRhdGlvbi4NCj4gSSBzaGFyZSB0aGUgc2FtZSBjb25jZXJucyB0aGF0IEFsZXggaGFzIGJyb3Vn aHQgdXAuDQo+IA0KPiBTb21lIGRldGFpbGVkIGNvbW1lbnRzOg0KPiANCj4gMSkgL3N5c2xvZy9h Y3Rpb25zOiBzZWVtcyBsaWtlIGV2ZXJ5dGhpbmcgaXMgaW4gdGhpcyBjb250YWluZXIuDQo+ICBX aHkgaXMgaXQgbmVlZGVkPyAgU2VlbXMgbGlrZSBpdCBjb3VsZCBiZSByZW1vdmVkIGFzIGl0IHNl cnZlcyBubw0KPiAgcHVycG9zZQ0KPiANCj4gW2NseWRlXSBBbHRob3VnaCB0aGlzIG1vZGVsIGlz IGN1cnJlbnRseSBkZXNpZ25hdGVkIGFzIGNvbmZpZyBvbmx5LCB3ZQ0KPiBjb3VsZCBhZGQgb3Bl cmF0aW9uYWwgZGF0YSBhbmQgcnBjIGxlYXZlcyBpbiB0aGUgZnV0dXJlLiBUaGUgYWN0aW9ucw0K PiBjb250YWluZXIgaXMgdG8gZnV0dXJlLXByb29mIHRoZSBtb2RlbC4NCj4gDQo+IDIpIDggZmVh dHVyZXM6IHRoZSBncmFudWxhcml0eSBzZWVtcyB3cm9uZy4gIFRoZSBtYWluIGNvbnRhaW5lciBm b3INCj4gZWFjaCBzZWN0aW9uDQo+ICBzaG91bGQgaGF2ZSBpdHMgb3duIGlmLWZlYXR1cmUNCj4g ICAgICAgL2NvbnNvbGUNCj4gICAgICAgL2J1ZmZlcg0KPiAgICAgICAvZmlsZQ0KPiAgICAgICAv cmVtb3RlDQo+IA0KPiBbY2x5ZGVdIFdlIGhhdmUgZ29uZSBiYWNrIGFuZCBmb3J0aCBvbiB0aGlz 4oCmc29tZSBoYXZlIGNvbXBsYWluZWQgdGhhdA0KPiB0aGVyZSBhcmUgdG9vIG1hbnkgZmVhdHVy ZXMuIEkgd2lsbCBiZSBoYXBweSB0byBhZGQgYSBmZWF0dXJlIGZvciBlYWNoDQo+IGFjdGlvbi4g Tm90ZSB0aGF0IHdlIHN0dWRpZWQgdGhlIGltcGxlbWVudGF0aW9uIG9mIGVhY2ggYWN0aW9uIGJ5 IHNpeA0KPiB2ZW5kb3JzIGluY2x1ZGluZyBMaW51eCBhbmQgb3B0ZWQgdG8gbm90IGFkZCBmZWF0 dXJlcyBmb3IgYWN0aW9ucw0KPiBpbXBsZW1lbnRlZCBieSBhdCBsZWFzdCAzIHZlbmRvcnMuIFZl bmRvcnMgbm90IGltcGxlbWVudGluZyBhbiBhY3Rpb24NCj4gY291bGQgY3JlYXRlIGEgZGV2aWF0 aW9uLg0KDQpUaGlzIGlzIG5vdCBhIGdvb2QgdXNhZ2Ugb2YgZGV2aWF0aW9ucy4gIERldmlhdGlv bnMgc2hvdWxkIGJlIHVzZWQgYXMNCmEgbGFzdCByZXNvcnQgYnkgdmVuZG9ycyB0aGF0IGNhbm5v dCBjb21wbHkgd2l0aCB0aGUgc3RhbmRhcmQuDQpEZXNpZ25pbmcgdGhlIHVzYWdlIG9mIGRldmlh dGlvbnMgaW50byB0aGUgb3ZlcmFsbCBzb2x1dGlvbiBpcyBub3QgYQ0KZ29vZCBpZGVhLiAgVGhl c2Ugc2hvdWxkIHJlYWxseSBiZSBmZWF0dXJlcywgZXZlbiBpZiB0aGUgbnVtYmVyIG9mDQpmZWF0 dXJlcyBiZWNvbWVzIGhpZ2hlci4NCg0KPiBJIHByZWZlciAxIG1hbmRhdG9yeS10by1pbXBsZW1l bnQgYW5kIGEgbWluaW1hbCBudW1iZXIgb2YgYWRkaXRpb25hbA0KPiBvcHRpb25zLg0KPiANCj4g ICAvY29uc29sZQ0KPiAgIC9maWxlDQo+ICAgL3JlbW90ZQ0KPiANCj4gVGhlc2UgYXJlIGFsbCBt YW5kYXRvcnktdG8taW1wbGVtZW50Li4NCj4gSU1PIG9ubHkgL2ZpbGUgc2hvdWxkIGJlIG1hbmRh dG9yeS10by1pbXBsZW1lbnQuDQoNCkJ1dCBub3QgYWxsIHN5c3RlbXMgaGF2ZSBhIGxvY2FsIGZp bGUgc3lzdGVtIHRvIHdyaXRlIGxvZ3MgdG8uICBJZg0KdGhlcmUgbXVzdCBiZSBvbmUgbWFuZGF0 b3J5LXRvLWltcGxlbWVudCwgc2hvdWxkbid0IGl0IGJlICdyZW1vdGUnPw0KDQo+IFtjbHlkZTJd IEkgd2lsbCByZW1vdmUgdGhlIGJ1ZmZlciBhbmQgc2Vzc2lvbiBhY3Rpb25zIGluIHRoZSBuZXh0 DQo+IGRyYWZ0IGFuZCB3aWxsIG1ha2UgdGhlIHJlbWFpbmluZyB0aHJlZSBmZWF0dXJlcy4NCg0K R29vZCENCg0KDQoNCi9tYXJ0aW4NCg== From nobody Thu Jan 12 01:52:10 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8FD12953F; Thu, 12 Jan 2017 01:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuDOvVqkYGRc; Thu, 12 Jan 2017 01:51:57 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF9EB1293F8; Thu, 12 Jan 2017 01:51:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37438; q=dns/txt; s=iport; t=1484214717; x=1485424317; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=3tyQBiPh2EGXGfH1NtvLzofAwFva8TQ+w2ycHQsRvOM=; b=Rye+Ltw3cjmM8udEksYlZ5BOOAZlbq+ff78KCb3AVfAztmxq70sfZmoy laXyqULc1XRFtBKJqdKS06IMfYBoYOEQjQHlA5wqaMJI/CeiT3GK4Ebcw RqtFtpxO7DSsjwYtsl8Axvz0MvEy27V0VMSX6bwhDKn+6QSlISIgTPa1n 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRAwBcUXdY/xbLJq0aA0AZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCcUoBAQEBAX4DgQqDUIoIcpEhlSiCDR8BCoUuSgKCThQBAgE?= =?us-ascii?q?BAQEBAQFjKIRpAQEBAwEBARgJSwsFCwkCGCABAgQDAgInHxEGAQwGAgEBF4hdC?= =?us-ascii?q?A6SIkKdToIlK4lnAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGRYICCIJXhDCDHoJ?= =?us-ascii?q?eBY8chgqGBIlwh2aKLYY4immHex84gRUSCBUVOoN8bIFHPjWIZgEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,349,1477958400"; d="scan'208,217";a="649734349" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2017 09:51:37 +0000 Received: from [10.63.23.107] (dhcp-ensft1-uk-vla370-10-63-23-107.cisco.com [10.63.23.107]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v0C9pb1H001041; Thu, 12 Jan 2017 09:51:37 GMT To: Andy Bierman , Ladislav Lhotka References: <6425C57C-C3DF-4099-AE77-4521B58B8D69@juniper.net> <20170111.102209.310040071380723970.mbj@tail-f.com> <9d4c54bf-ac6f-0d64-0361-668f9a793cd1@cisco.com> <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> From: Robert Wilton Message-ID: <801aee49-4599-86ae-fe47-7a79980da62f@cisco.com> Date: Thu, 12 Jan 2017 09:51:37 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0893CB482947FB27EFEAD959" Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 09:52:08 -0000 This is a multi-part message in MIME format. --------------0893CB482947FB27EFEAD959 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/01/2017 20:32, Andy Bierman wrote: > > > On Wed, Jan 11, 2017 at 9:21 AM, Ladislav Lhotka > wrote: > > > > On 11 Jan 2017, at 17:56, Andy Bierman > wrote: > > > > Hi, > > > > > > On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton > > wrote: > > > > > > On 11/01/2017 09:22, Martin Bjorklund wrote: > > Andy Bierman > wrote: > > On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen > > wrote: > > > > I think it is better to have a human decide what is in the module > > instead of relying on a pyang plugin to generate some additional > module > > that follows some simplistic pattern. > > It may be simple, but I’m thinking that’s only because it’s not > tricky ;) > > > > > > The client and server developers still need to know about this > > auto-generated module > > and implement it. Operators might have to know about it to use it. > > My idea is not to auto generate models on the fly. > > > > My aim is to allow folks to start writing models in the desired > long term format (i.e. combined config and state tree) with the > model designer being able to assume the existence of the > operational state datastore. > > > > > > > > I am not convinced this "new format" has solved anything. > > Don't you need separate description-stmts in every node for each > > datastore? What does the value mean if pre-configured? configured? > > operational? Will the auto-generated objects be exactly correct > > and never need any alterations or additional text? > > They still need to be used by developers and YANG tools. > > Right, this is one problem of this "deduplication": even if two > nodes - one config and the other state - have the same name or > even type (which is not always the case, as we know), their > semantics is often different. An IP address in configuration means > a manually configured address whereas in state it may come from > any source. So writing sensible descriptions will become tricky. > I don't disagree that in some cases there is some nuanced differences between configured values and values that may be learned via other dynamic mechanisms. The pragmatic point solution for these sorts of cases is to add an extra leaf to indicate the source of the value. The existing ietf-ip YANG model already has a "source" leaf to indicate whether the address is static, dhcp, link-layer, random. This type of adhoc mechanism will continue to work with a combined config/state data tree as well. However, draft-ietf-netmod-revised-datastores also provides a generalized solution to this problem, via using origin metadata annotations (sections 5.2 and 8). This allows the server to annotate whether a node in the operational state datastore has been populated via running configuration, or has been acquired via some other mechanism. Yes, the descriptions may have to be written in a slightly different way, but I don't think that it is going to be too tricky to understand that was is in running represents the configuration given to the system, vs what is in the operational state datastore represents what configuration the device is actually running, along with all of the associated other operational state. Rob > > > > > Is is that realistic to force the config structure and > operational structure > > to be the same? Seems it is quite common to monitor data structures > > with additional keys or different keys. This is completely > unsupported > > so separate /foo and /foo-state trees will still exist. > > I agree. > > Lada > > > > > IMO this combination of trees needs to be proven. > > Take ietf-interfaces and show how much better it will work > > if the /interfaces and /interfaces-state trees were combined. > > > > > > Andy > > > > > > The tooling would be there to statically generate the extra > foo-state config false node modules for servers that don't support > the operational state datastore. This could be done once, and the > extra foo-state modules committed to the github YANG respository > in the same way that models are extracted from IETF RFCs today. > > > > The aim here is that the single model being produced by IETF > would be usable both by new client/servers that support an > operational state datastore, and also by existing NETCONF > client/servers that don't implement an operational state datastore. > > > > I'm not proposing that as a long term solution, but as a path to > make it easier for folk to migrate, and to not slow down the model > writing effort. Otherwise, it may be hard to get a protocol model > writer to design the YANG model in a way that is not fully usable > on any current devices. > > > > As an illustration, an RFC published combined ietf-interfaces > model may look like this: > > > > > > OK -- let me see if I understand the value of combining ietf-interfaces. > > > Here is the starting tree: > > > +--rw interfaces > | +--rw interface* [name] > | +--rw name string > | +--rw description? string > | +--rw type identityref > | +--rw enabled? boolean > | +--rw link-up-down-trap-enable? enumeration > +--ro interfaces-state > +--ro interface* [name] > +--ro name string > +--ro type identityref > +--ro admin-status enumeration > +--ro oper-status enumeration > +--ro last-change? yang:date-and-time > +--ro if-index int32 > +--ro phys-address? yang:phys-address > +--ro higher-layer-if* interface-state-ref > +--ro lower-layer-if* interface-state-ref > +--ro speed? yang:gauge64 > +--ro statistics > +--ro discontinuity-time yang:date-and-time > +--ro in-octets? yang:counter64 > +--ro in-unicast-pkts? yang:counter64 > +--ro in-broadcast-pkts? yang:counter64 > +--ro in-multicast-pkts? yang:counter64 > +--ro in-discards? yang:counter32 > +--ro in-errors? yang:counter32 > +--ro in-unknown-protos? yang:counter32 > +--ro out-octets? yang:counter64 > +--ro out-unicast-pkts? yang:counter64 > +--ro out-broadcast-pkts? yang:counter64 > +--ro out-multicast-pkts? yang:counter64 > +--ro out-discards? yang:counter32 > +--ro out-errors? yang:counter32 > > > So these are the objects that would no longer be duplicated: > > - name > - type > > Neither one is supposed to have a different value in operational state > vs configuration. > > - enabled > - link-up-down-trap-enable > > These 2 could be different in operational state I suppose. > An RPC can provide the operational value without changing the YANG module > > rpc get-oper-value { > input { > leaf node { > type instance-identifier; > description "the config=true node to check"; > } > } > output { > anydata value { > description > "contains 1 child node matching the input 'node' parameter. > The value of the node is the current operational value." > } > } > } > > > > > /if:interfaces/if:interface[if:name='eth0']/enabled > > > > > > > false > > > > I don't need to change the YANG module at all to support operational > state. > > > Andy > > > module: ietf-interfaces-combined > > +--rw interfaces > > +--rw interface* [name] > > +--rw name string > > +--rw description? string > > +--rw type identityref > > +--rw enabled? boolean > > +--rw link-up-down-trap-enable? enumeration {if-mib}? > > +--ro oper-status enumeration > > +--ro last-change? yang:date-and-time > > +--ro if-index int32 {if-mib}? > > +--ro phys-address? yang:phys-address > > +--ro higher-layer-if* interface-ref > > +--ro lower-layer-if* interface-ref > > +--ro speed? yang:gauge64 > > +--ro statistics > > +--ro discontinuity-time yang:date-and-time > > +--ro in-octets? yang:counter64 > > +--ro in-unicast-pkts? yang:counter64 > > +--ro in-broadcast-pkts? yang:counter64 > > +--ro in-multicast-pkts? yang:counter64 > > +--ro in-discards? yang:counter32 > > +--ro in-errors? yang:counter32 > > +--ro in-unknown-protos? yang:counter32 > > +--ro out-octets? yang:counter64 > > +--ro out-unicast-pkts? yang:counter64 > > +--ro out-broadcast-pkts? yang:counter64 > > +--ro out-multicast-pkts? yang:counter64 > > +--ro out-discards? yang:counter32 > > +--ro out-errors? yang:counter32 > > > > The extra generated model would look like this: > > > > module: ietf-interfaces-combined-state > > +--ro interfaces-state > > +--ro interface* [name] > > +--ro name string > > +--ro description? string > > +--ro type identityref > > +--ro enabled? boolean > > +--ro link-up-down-trap-enable? enumeration {if:if-mib}? > > +--ro oper-status enumeration > > +--ro last-change? yang:date-and-time > > +--ro if-index int32 {if:if-mib}? > > +--ro phys-address? yang:phys-address > > +--ro higher-layer-if* if:interface-ref > > +--ro lower-layer-if* if:interface-ref > > +--ro speed? yang:gauge64 > > +--ro statistics > > +--ro discontinuity-time yang:date-and-time > > +--ro in-octets? yang:counter64 > > +--ro in-unicast-pkts? yang:counter64 > > +--ro in-broadcast-pkts? yang:counter64 > > +--ro in-multicast-pkts? yang:counter64 > > +--ro in-discards? yang:counter32 > > +--ro in-errors? yang:counter32 > > +--ro in-unknown-protos? yang:counter32 > > +--ro out-octets? yang:counter64 > > +--ro out-unicast-pkts? yang:counter64 > > +--ro out-broadcast-pkts? yang:counter64 > > +--ro out-multicast-pkts? yang:counter64 > > +--ro out-discards? yang:counter32 > > +--ro out-errors? yang:counter32 > > > > Servers that support operational-state would just implement > ietf-interfaces-combined > > > > Servers that don't support operational-state could implement > ietf-interfaces-combined and ietf-interfaces-combined-state, > probably not implementing the duplicate config false leaves under > the interfaces config tree. Deviations could also be > auto-generated to remove the config false leaves from the config > tree so that they are only in the state tree. > > > > Of course, Clients may need to support both schemes depending on > what types of devices they are interacting with. > > > > Finally, I've illustrated this using ietf-interfaces, but I'm > not actually proposing immediately changing that model. I was > more thinking about IETF protocols that in the process of working > on their YANG models. > > > > Rob > > > > > > Exactly. I agree that this is a real hack. Implementations can use > > whatever transformation tricks they want in order to comply with > > different standards, but the standard modules should be very clear. > > > > > > > > > > > > > > /martin > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > --------------0893CB482947FB27EFEAD959 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 11/01/2017 20:32, Andy Bierman wrote:


On Wed, Jan 11, 2017 at 9:21 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

> On 11 Jan 2017, at 17:56, Andy Bierman <andy@yumaworks.com> wrote:
>
> Hi,
>
>
> On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton <rwilton@cisco.com> wrote:
>
>
> On 11/01/2017 09:22, Martin Bjorklund wrote:
> Andy Bierman <andy@yumaworks.com> wrote:
> On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen <kwatsen@juniper.net> wrote:
>
> I think it is better to have a human decide what is in the module
> instead of relying on a pyang plugin to generate some additional module
> that follows some simplistic pattern.
> It may be simple, but I’m thinking that’s only because it’s not tricky  ;)
>
>
> The client and server developers still need to know about this
> auto-generated module
> and implement it.  Operators might have to know about it to use it.
> My idea is not to auto generate models on the fly.
>
> My aim is to allow folks to start writing models in the desired long term format (i.e. combined config and state tree) with the model designer being able to assume the existence of the operational state datastore.
>
>
>
> I am not convinced this "new format" has solved anything.
> Don't you need separate description-stmts in every node for each
> datastore?  What does the value mean if pre-configured? configured?
> operational?  Will the auto-generated objects be exactly correct
> and never need any alterations or additional text?
> They still need to be used by developers and YANG tools.

Right, this is one problem of this "deduplication": even if two nodes - one config and the other state - have the same name or even type (which is not always the case, as we know), their semantics is often different. An IP address in configuration means a manually configured address whereas in state it may come from any source. So writing sensible descriptions will become tricky.
I don't disagree that in some cases there is some nuanced differences between configured values and values that may be learned via other dynamic mechanisms.

The pragmatic point solution for these sorts of cases is to add an extra leaf to indicate the source of the value.  The existing ietf-ip YANG model already has a "source" leaf to indicate whether the address is static, dhcp, link-layer, random.  This type of adhoc mechanism will continue to work with a combined config/state data tree as well.

However, draft-ietf-netmod-revised-datastores also provides a generalized solution to this problem, via using origin metadata annotations (sections 5.2 and 8).  This allows the server to annotate whether a node in the operational state datastore has been populated via running configuration, or has been acquired via some other mechanism.

Yes, the descriptions may have to be written in a slightly different way, but I don't think that it is going to be too tricky to understand that was is in running represents the configuration given to the system, vs what is in the operational state datastore represents what configuration the device is actually running, along with all of the associated other operational state.

Rob



>
> Is is that realistic to force the config structure and operational structure
> to be the same? Seems it is quite common to monitor data structures
> with additional keys or different keys.  This is completely unsupported
> so separate /foo and /foo-state trees will still exist.

I agree.

Lada

>
> IMO this combination of trees needs to be proven.
> Take ietf-interfaces and show how much better it will work
> if the /interfaces and /interfaces-state trees were combined.
>
>
> Andy
>
>
> The tooling would be there to statically generate the extra foo-state config false node modules for servers that don't support the operational state datastore.  This could be done once, and the extra foo-state modules committed to the github YANG respository in the same way that models are extracted from IETF RFCs today.
>
> The aim here is that the single model being produced by IETF would be usable both by new client/servers that support an operational state datastore, and also by existing NETCONF client/servers that don't implement an operational state datastore.
>
> I'm not proposing that as a long term solution, but as a path to make it easier for folk to migrate, and to not slow down the model writing effort.  Otherwise, it may be hard to get a protocol model writer to design the YANG model in a way that is not fully usable on any current devices.
>
> As an illustration, an RFC published combined ietf-interfaces model may look like this:
>


OK -- let me see if I understand the value of combining ietf-interfaces.


Here is the starting tree:


     +--rw interfaces
      |  +--rw interface* [name]
      |     +--rw name                        string
      |     +--rw description?                string
      |     +--rw type                        identityref
      |     +--rw enabled?                    boolean
      |     +--rw link-up-down-trap-enable?   enumeration
      +--ro interfaces-state
         +--ro interface* [name]
            +--ro name               string
            +--ro type               identityref
            +--ro admin-status       enumeration
            +--ro oper-status        enumeration
            +--ro last-change?       yang:date-and-time
            +--ro if-index           int32
            +--ro phys-address?      yang:phys-address
            +--ro higher-layer-if*   interface-state-ref
            +--ro lower-layer-if*    interface-state-ref
            +--ro speed?             yang:gauge64
            +--ro statistics
               +--ro discontinuity-time    yang:date-and-time
               +--ro in-octets?            yang:counter64
               +--ro in-unicast-pkts?      yang:counter64
               +--ro in-broadcast-pkts?    yang:counter64
               +--ro in-multicast-pkts?    yang:counter64
               +--ro in-discards?          yang:counter32
               +--ro in-errors?            yang:counter32
               +--ro in-unknown-protos?    yang:counter32
               +--ro out-octets?           yang:counter64
               +--ro out-unicast-pkts?     yang:counter64
               +--ro out-broadcast-pkts?   yang:counter64
               +--ro out-multicast-pkts?   yang:counter64
               +--ro out-discards?         yang:counter32
               +--ro out-errors?           yang:counter32


So these are the objects that would no longer be duplicated:

    - name
    - type

Neither one is supposed to have a different value in operational state vs configuration.

   - enabled
   - link-up-down-trap-enable

These 2 could be different in operational state I suppose.
An RPC can provide the operational value without changing the YANG module

    rpc get-oper-value {
      input {
         leaf node { 
            type instance-identifier; 
             description "the config=true node to check";
          }
      }
      output {
          anydata value {
             description 
               "contains 1 child node matching the input 'node' parameter.
                The value of the node is the current operational value."
          }
     }
   }


   <rpc>
      <get-oper-value>
          <node>/if:interfaces/if:interface[if:name='eth0']/enabled</node>
      </get-oper-value>
   </rpc>


   <rpc-reply>
       <value>
          <if:enabled>false</if:enabled>
        </value>
     </rpc-reply>

I don't need to change the YANG module at all to support operational state.


Andy

 
> module: ietf-interfaces-combined
>     +--rw interfaces
>        +--rw interface* [name]
>           +--rw name                        string
>           +--rw description?                string
>           +--rw type                        identityref
>           +--rw enabled?                    boolean
>           +--rw link-up-down-trap-enable?   enumeration {if-mib}?
>           +--ro oper-status                 enumeration
>           +--ro last-change? yang:date-and-time
>           +--ro if-index                    int32 {if-mib}?
>           +--ro phys-address? yang:phys-address
>           +--ro higher-layer-if*            interface-ref
>           +--ro lower-layer-if*             interface-ref
>           +--ro speed?                      yang:gauge64
>           +--ro statistics
>              +--ro discontinuity-time    yang:date-and-time
>              +--ro in-octets?            yang:counter64
>              +--ro in-unicast-pkts?      yang:counter64
>              +--ro in-broadcast-pkts?    yang:counter64
>              +--ro in-multicast-pkts?    yang:counter64
>              +--ro in-discards?          yang:counter32
>              +--ro in-errors?            yang:counter32
>              +--ro in-unknown-protos?    yang:counter32
>              +--ro out-octets?           yang:counter64
>              +--ro out-unicast-pkts?     yang:counter64
>              +--ro out-broadcast-pkts?   yang:counter64
>              +--ro out-multicast-pkts?   yang:counter64
>              +--ro out-discards?         yang:counter32
>              +--ro out-errors?           yang:counter32
>
> The extra generated model would look like this:
>
> module: ietf-interfaces-combined-state
>     +--ro interfaces-state
>        +--ro interface* [name]
>           +--ro name                        string
>           +--ro description?                string
>           +--ro type                        identityref
>           +--ro enabled?                    boolean
>           +--ro link-up-down-trap-enable?   enumeration {if:if-mib}?
>           +--ro oper-status                 enumeration
>           +--ro last-change? yang:date-and-time
>           +--ro if-index                    int32 {if:if-mib}?
>           +--ro phys-address? yang:phys-address
>           +--ro higher-layer-if* if:interface-ref
>           +--ro lower-layer-if* if:interface-ref
>           +--ro speed?                      yang:gauge64
>           +--ro statistics
>              +--ro discontinuity-time    yang:date-and-time
>              +--ro in-octets?            yang:counter64
>              +--ro in-unicast-pkts?      yang:counter64
>              +--ro in-broadcast-pkts?    yang:counter64
>              +--ro in-multicast-pkts?    yang:counter64
>              +--ro in-discards?          yang:counter32
>              +--ro in-errors?            yang:counter32
>              +--ro in-unknown-protos?    yang:counter32
>              +--ro out-octets?           yang:counter64
>              +--ro out-unicast-pkts?     yang:counter64
>              +--ro out-broadcast-pkts?   yang:counter64
>              +--ro out-multicast-pkts?   yang:counter64
>              +--ro out-discards?         yang:counter32
>              +--ro out-errors?           yang:counter32
>
> Servers that support operational-state would just implement ietf-interfaces-combined
>
> Servers that don't support operational-state could implement ietf-interfaces-combined and ietf-interfaces-combined-state, probably not implementing the duplicate config false leaves under the interfaces config tree.  Deviations could also be auto-generated to remove the config false leaves from the config tree so that they are only in the state tree.
>
> Of course, Clients may need to support both schemes depending on what types of devices they are interacting with.
>
> Finally, I've illustrated this using ietf-interfaces, but I'm not actually proposing immediately changing that model.  I was more thinking about IETF protocols that in the process of working on their YANG models.
>
> Rob
>
>
> Exactly.  I agree that this is a real hack.  Implementations can use
> whatever transformation tricks they want in order to comply with
> different standards, but the standard modules should be very clear.
>
>
>
>
>
>
> /martin
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67







--------------0893CB482947FB27EFEAD959-- From nobody Thu Jan 12 02:32:53 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC055129563; Thu, 12 Jan 2017 02:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsRLfF2IeNAW; Thu, 12 Jan 2017 02:32:48 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA9A6129525; Thu, 12 Jan 2017 02:32:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30061; q=dns/txt; s=iport; t=1484217168; x=1485426768; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=hz/JZEQNnmXKrikZDcJ7plyarmG3Dsqi2HOZWpUiU4E=; b=Vkm5rkQeOFYQDcbeNQjdEJi9KMtMAhfQiNVkitudsN9DSXRJNx1IXLmC DIGziRKT1xkFcHP5BoWBpxYdi1Fuer3ENx28oyCkqpJKW0ZJ51iXJZw/w HQ92fPZUwcKwFXguPecbRdHzlnSlvnTuv1pEYCzhOdAiXb90glanAlksQ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BfAQBeWXdY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgywPAQEBAQF+A4EKg1CKCHKRIZUogg0fAQqFLkoCgk4UAQIBAQE?= =?us-ascii?q?BAQEBYyiEaQEBAQMBAQEhSwsFCwkCEgYgAwQDAgInHwMOBg0GAgEBFQKIXQgOk?= =?us-ascii?q?mCdToIlK4lmAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGRYICgl+EMIMegl4Fjxy?= =?us-ascii?q?MDolwh2aKLYY4immHex84Nl8SCBUVOoN8bIFHPjWIZgEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,349,1477958400"; d="scan'208,217";a="691276773" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2017 10:32:45 +0000 Received: from [10.63.23.107] (dhcp-ensft1-uk-vla370-10-63-23-107.cisco.com [10.63.23.107]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0CAWilk028270; Thu, 12 Jan 2017 10:32:44 GMT To: Andy Bierman References: <6425C57C-C3DF-4099-AE77-4521B58B8D69@juniper.net> <20170111.102209.310040071380723970.mbj@tail-f.com> <9d4c54bf-ac6f-0d64-0361-668f9a793cd1@cisco.com> From: Robert Wilton Message-ID: <5ff7521f-75f7-e59e-30da-9482c63dcc04@cisco.com> Date: Thu, 12 Jan 2017 10:32:44 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9EBC1A57B6F066A5623D5C4B" Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 10:32:52 -0000 This is a multi-part message in MIME format. --------------9EBC1A57B6F066A5623D5C4B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/01/2017 16:56, Andy Bierman wrote: > Hi, > > > On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton > wrote: > > > > On 11/01/2017 09:22, Martin Bjorklund wrote: > > Andy Bierman > > wrote: > > On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen > > wrote: > > I think it is better to have a human decide what > is in the module > instead of relying on a pyang plugin to generate > some additional module > that follows some simplistic pattern. > > It may be simple, but I’m thinking that’s only because > it’s not tricky ;) > > > The client and server developers still need to know about this > auto-generated module > and implement it. Operators might have to know about it > to use it. > > My idea is not to auto generate models on the fly. > > My aim is to allow folks to start writing models in the desired > long term format (i.e. combined config and state tree) with the > model designer being able to assume the existence of the > operational state datastore. > > > > I am not convinced this "new format" has solved anything. > Don't you need separate description-stmts in every node for each > datastore? No, generally I don't this so. Assuming clients understand the general semantics and datastore architecture it should be fairly easy for them to understand the difference between the configured value and operational value. There might need to be some nuance as to how the description statements are written, but this still seems better than requiring two separate leaves for each property so that first one can have a description that says "this is the configured value" and the second says "this is the operational value". Anywhere where it is necessary to have manual duplication leads to mistakes and inconsistencies creeping in. > What does the value mean if pre-configured? configured? > operational? The datastore architecture defines the semantic meaning of what a node means in a particular datastore. This is true even today between startup, candidate, and running datastores. > Will the auto-generated objects be exactly correct > and never need any alterations or additional text? Yes, they will be exactly correct, and never need any alterations, since they have exactly the same semantic meaning as for the equivalent config true leaf in the operational state datastore. The auto-generation script could trivially append to each description statement for nodes in the generated model to indicate that it represents the operational value. > They still need to be used by developers and YANG tools. > > Is is that realistic to force the config structure and operational > structure > to be the same? Seems it is quite common to monitor data structures > with additional keys or different keys. This is completely unsupported > so separate /foo and /foo-state trees will still exist. It is not forcing the config and operational state structure to be the same, only that the operational state must extend from the config structure. These "monitor data structures" can continue to exist as config false structures just as they do today somewhere in the combined tree. They could even be put in top level foo-state objects if there was nowhere lower down the tree that is a better place for them, but I think that in the general case (for components that can be configured on or off, they can live under a single top level, config true, component container). Finally, if you allow the core structure of the config tree and state tree to deviate that it makes life much harder for management clients because they have to be hardcoded to know where the corresponding state lives for a particular set of configuration. > > IMO this combination of trees needs to be proven. > Take ietf-interfaces and show how much better it will work > if the /interfaces and /interfaces-state trees were combined. Yes, this might be a good idea. But doing this for the base IETF interface model on its own isn't really going to be informative. I think that a larger example is necessary to properly see the benefits. Rob > > > Andy > > > The tooling would be there to statically generate the extra > foo-state config false node modules for servers that don't support > the operational state datastore. This could be done once, and the > extra foo-state modules committed to the github YANG respository > in the same way that models are extracted from IETF RFCs today. > > The aim here is that the single model being produced by IETF would > be usable both by new client/servers that support an operational > state datastore, and also by existing NETCONF client/servers that > don't implement an operational state datastore. > > I'm not proposing that as a long term solution, but as a path to > make it easier for folk to migrate, and to not slow down the model > writing effort. Otherwise, it may be hard to get a protocol model > writer to design the YANG model in a way that is not fully usable > on any current devices. > > As an illustration, an RFC published combined ietf-interfaces > model may look like this: > > module: ietf-interfaces-combined > +--rw interfaces > +--rw interface* [name] > +--rw name string > +--rw description? string > +--rw type identityref > +--rw enabled? boolean > +--rw link-up-down-trap-enable? enumeration {if-mib}? > +--ro oper-status enumeration > +--ro last-change? yang:date-and-time > +--ro if-index int32 {if-mib}? > +--ro phys-address? yang:phys-address > +--ro higher-layer-if* interface-ref > +--ro lower-layer-if* interface-ref > +--ro speed? yang:gauge64 > +--ro statistics > +--ro discontinuity-time yang:date-and-time > +--ro in-octets? yang:counter64 > +--ro in-unicast-pkts? yang:counter64 > +--ro in-broadcast-pkts? yang:counter64 > +--ro in-multicast-pkts? yang:counter64 > +--ro in-discards? yang:counter32 > +--ro in-errors? yang:counter32 > +--ro in-unknown-protos? yang:counter32 > +--ro out-octets? yang:counter64 > +--ro out-unicast-pkts? yang:counter64 > +--ro out-broadcast-pkts? yang:counter64 > +--ro out-multicast-pkts? yang:counter64 > +--ro out-discards? yang:counter32 > +--ro out-errors? yang:counter32 > > The extra generated model would look like this: > > module: ietf-interfaces-combined-state > +--ro interfaces-state > +--ro interface* [name] > +--ro name string > +--ro description? string > +--ro type identityref > +--ro enabled? boolean > +--ro link-up-down-trap-enable? enumeration {if:if-mib}? > +--ro oper-status enumeration > +--ro last-change? yang:date-and-time > +--ro if-index int32 {if:if-mib}? > +--ro phys-address? yang:phys-address > +--ro higher-layer-if* if:interface-ref > +--ro lower-layer-if* if:interface-ref > +--ro speed? yang:gauge64 > +--ro statistics > +--ro discontinuity-time yang:date-and-time > +--ro in-octets? yang:counter64 > +--ro in-unicast-pkts? yang:counter64 > +--ro in-broadcast-pkts? yang:counter64 > +--ro in-multicast-pkts? yang:counter64 > +--ro in-discards? yang:counter32 > +--ro in-errors? yang:counter32 > +--ro in-unknown-protos? yang:counter32 > +--ro out-octets? yang:counter64 > +--ro out-unicast-pkts? yang:counter64 > +--ro out-broadcast-pkts? yang:counter64 > +--ro out-multicast-pkts? yang:counter64 > +--ro out-discards? yang:counter32 > +--ro out-errors? yang:counter32 > > Servers that support operational-state would just implement > ietf-interfaces-combined > > Servers that don't support operational-state could implement > ietf-interfaces-combined and ietf-interfaces-combined-state, > probably not implementing the duplicate config false leaves under > the interfaces config tree. Deviations could also be > auto-generated to remove the config false leaves from the config > tree so that they are only in the state tree. > > Of course, Clients may need to support both schemes depending on > what types of devices they are interacting with. > > Finally, I've illustrated this using ietf-interfaces, but I'm not > actually proposing immediately changing that model. I was more > thinking about IETF protocols that in the process of working on > their YANG models. > > Rob > > > Exactly. I agree that this is a real hack. Implementations > can use > whatever transformation tricks they want in order to comply with > different standards, but the standard modules should be very > clear. > > > > > > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > > --------------9EBC1A57B6F066A5623D5C4B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 11/01/2017 16:56, Andy Bierman wrote:
Hi,


On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton <rwilton@cisco.com> wrote:


On 11/01/2017 09:22, Martin Bjorklund wrote:
Andy Bierman <andy@yumaworks.com> wrote:
On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen <kwatsen@juniper.net> wrote:

I think it is better to have a human decide what is in the module
instead of relying on a pyang plugin to generate some additional module
that follows some simplistic pattern.
It may be simple, but I’m thinking that’s only because it’s not tricky  ;)


The client and server developers still need to know about this
auto-generated module
and implement it.  Operators might have to know about it to use it.
My idea is not to auto generate models on the fly.

My aim is to allow folks to start writing models in the desired long term format (i.e. combined config and state tree) with the model designer being able to assume the existence of the operational state datastore.



I am not convinced this "new format" has solved anything.
Don't you need separate description-stmts in every node for each
datastore?
No, generally I don't this so.  Assuming clients understand the general semantics and datastore architecture it should be fairly easy for them to understand the difference between the configured value and operational value.

There might need to be some nuance as to how the description statements are written, but this still seems better than requiring two separate leaves for each property so that first one can have a description that says "this is the configured value" and the second says "this is the operational value".  Anywhere where it is necessary to have manual duplication leads to mistakes and inconsistencies creeping in.



  What does the value mean if pre-configured? configured?
operational?

The datastore architecture defines the semantic meaning of what a node means in a particular datastore.

This is true even today between startup, candidate, and running datastores.



  Will the auto-generated objects be exactly correct
and never need any alterations or additional text?

Yes, they will be exactly correct, and never need any alterations, since they have exactly the same semantic meaning as for the equivalent config true leaf in the operational state datastore.

The auto-generation script could trivially append to each description statement for nodes in the generated model to indicate that it represents the operational value.


They still need to be used by developers and YANG tools.

Is is that realistic to force the config structure and operational structure
to be the same? Seems it is quite common to monitor data structures
with additional keys or different keys.  This is completely unsupported
so separate /foo and /foo-state trees will still exist.

It is not forcing the config and operational state structure to be the same, only that the operational state must extend from the config structure.

These "monitor data structures" can continue to exist as config false structures just as they do today somewhere in the combined tree.  They could even be put in top level foo-state objects if there was nowhere lower down the tree that is a better place for them, but I think that in the general case (for components that can be configured on or off, they can live under a single top level, config true, component container).

Finally, if you allow the core structure of the config tree and state tree to deviate that it makes life much harder for management clients because they have to be hardcoded to know where the corresponding state lives for a particular set of configuration.


IMO this combination of trees needs to be proven.
Take ietf-interfaces and show how much better it will work
if the /interfaces and /interfaces-state trees were combined.

Yes, this might be a good idea.  But doing this for the base IETF interface model on its own isn't really going to be informative.  I think that a larger example is necessary to properly see the benefits.

Rob




Andy


The tooling would be there to statically generate the extra foo-state config false node modules for servers that don't support the operational state datastore.  This could be done once, and the extra foo-state modules committed to the github YANG respository in the same way that models are extracted from IETF RFCs today.

The aim here is that the single model being produced by IETF would be usable both by new client/servers that support an operational state datastore, and also by existing NETCONF client/servers that don't implement an operational state datastore.

I'm not proposing that as a long term solution, but as a path to make it easier for folk to migrate, and to not slow down the model writing effort.  Otherwise, it may be hard to get a protocol model writer to design the YANG model in a way that is not fully usable on any current devices.

As an illustration, an RFC published combined ietf-interfaces model may look like this:

module: ietf-interfaces-combined
    +--rw interfaces
       +--rw interface* [name]
          +--rw name                        string
          +--rw description?                string
          +--rw type                        identityref
          +--rw enabled?                    boolean
          +--rw link-up-down-trap-enable?   enumeration {if-mib}?
          +--ro oper-status                 enumeration
          +--ro last-change? yang:date-and-time
          +--ro if-index                    int32 {if-mib}?
          +--ro phys-address? yang:phys-address
          +--ro higher-layer-if*            interface-ref
          +--ro lower-layer-if*             interface-ref
          +--ro speed?                      yang:gauge64
          +--ro statistics
             +--ro discontinuity-time    yang:date-and-time
             +--ro in-octets?            yang:counter64
             +--ro in-unicast-pkts?      yang:counter64
             +--ro in-broadcast-pkts?    yang:counter64
             +--ro in-multicast-pkts?    yang:counter64
             +--ro in-discards?          yang:counter32
             +--ro in-errors?            yang:counter32
             +--ro in-unknown-protos?    yang:counter32
             +--ro out-octets?           yang:counter64
             +--ro out-unicast-pkts?     yang:counter64
             +--ro out-broadcast-pkts?   yang:counter64
             +--ro out-multicast-pkts?   yang:counter64
             +--ro out-discards?         yang:counter32
             +--ro out-errors?           yang:counter32

The extra generated model would look like this:

module: ietf-interfaces-combined-state
    +--ro interfaces-state
       +--ro interface* [name]
          +--ro name                        string
          +--ro description?                string
          +--ro type                        identityref
          +--ro enabled?                    boolean
          +--ro link-up-down-trap-enable?   enumeration {if:if-mib}?
          +--ro oper-status                 enumeration
          +--ro last-change? yang:date-and-time
          +--ro if-index                    int32 {if:if-mib}?
          +--ro phys-address? yang:phys-address
          +--ro higher-layer-if* if:interface-ref
          +--ro lower-layer-if* if:interface-ref
          +--ro speed?                      yang:gauge64
          +--ro statistics
             +--ro discontinuity-time    yang:date-and-time
             +--ro in-octets?            yang:counter64
             +--ro in-unicast-pkts?      yang:counter64
             +--ro in-broadcast-pkts?    yang:counter64
             +--ro in-multicast-pkts?    yang:counter64
             +--ro in-discards?          yang:counter32
             +--ro in-errors?            yang:counter32
             +--ro in-unknown-protos?    yang:counter32
             +--ro out-octets?           yang:counter64
             +--ro out-unicast-pkts?     yang:counter64
             +--ro out-broadcast-pkts?   yang:counter64
             +--ro out-multicast-pkts?   yang:counter64
             +--ro out-discards?         yang:counter32
             +--ro out-errors?           yang:counter32

Servers that support operational-state would just implement ietf-interfaces-combined

Servers that don't support operational-state could implement ietf-interfaces-combined and ietf-interfaces-combined-state, probably not implementing the duplicate config false leaves under the interfaces config tree.  Deviations could also be auto-generated to remove the config false leaves from the config tree so that they are only in the state tree.

Of course, Clients may need to support both schemes depending on what types of devices they are interacting with.

Finally, I've illustrated this using ietf-interfaces, but I'm not actually proposing immediately changing that model.  I was more thinking about IETF protocols that in the process of working on their YANG models.

Rob


Exactly.  I agree that this is a real hack.  Implementations can use
whatever transformation tricks they want in order to comply with
different standards, but the standard modules should be very clear.






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



--------------9EBC1A57B6F066A5623D5C4B-- From nobody Thu Jan 12 02:45:23 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55DCD129545; Thu, 12 Jan 2017 02:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zk06TdairGSt; Thu, 12 Jan 2017 02:45:14 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5D23129547; Thu, 12 Jan 2017 02:45:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35534; q=dns/txt; s=iport; t=1484217914; x=1485427514; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=xhcdxDShO7rBabBfrWjubn5Jlw1Ltv2/lrO119pevSc=; b=gmPg1/Hn/EjV6F39sojYnb161hQ4c3H5ON+AmhU8A3frBRxWO0njWt6y O+Um0C63lwfUzR9XmLYyAiQiut3TsHCeg3Ul97CIfgPgFA/kM6bN361tE nIJL0YJ+0Gnm27G7ONcaA5NBhkKSDXro9ct8/4SUTf+z/Qa4012PAmeU5 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAQCQXXdY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnJKAQEBAQF+A4EDg1CKCHKRIpUrggoDHwEKhS5KAoJNFAECAQE?= =?us-ascii?q?BAQEBAWMohGkBAQEDAQEBGAlLCwULCQIYIAECBAMCAicfEQYBDAYCAQEXiF0ID?= =?us-ascii?q?pJXnU6CJSuJZwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhkWCAoJfhCIOgxyCXgW?= =?us-ascii?q?PHoYKhgSJcIdmii+GO4pph3sfOIEVEggVFTqDfGyBRz41himCPQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,349,1477958400"; d="scan'208,217";a="648715477" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2017 10:45:09 +0000 Received: from [10.63.23.107] (dhcp-ensft1-uk-vla370-10-63-23-107.cisco.com [10.63.23.107]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v0CAj7T9018310; Thu, 12 Jan 2017 10:45:08 GMT To: Andy Bierman , Ladislav Lhotka References: <6425C57C-C3DF-4099-AE77-4521B58B8D69@juniper.net> <20170111.102209.310040071380723970.mbj@tail-f.com> <9d4c54bf-ac6f-0d64-0361-668f9a793cd1@cisco.com> <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> From: Robert Wilton Message-ID: <5c26b1eb-b811-00cb-e362-b2d8d02b6b5d@cisco.com> Date: Thu, 12 Jan 2017 10:45:07 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BF2D67C373073DA840A083C2" Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 10:45:17 -0000 This is a multi-part message in MIME format. --------------BF2D67C373073DA840A083C2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/01/2017 20:32, Andy Bierman wrote: > > > On Wed, Jan 11, 2017 at 9:21 AM, Ladislav Lhotka > wrote: > > > > On 11 Jan 2017, at 17:56, Andy Bierman > wrote: > > > > Hi, > > > > > > On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton > > wrote: > > > > > > On 11/01/2017 09:22, Martin Bjorklund wrote: > > Andy Bierman > wrote: > > On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen > > wrote: > > > > I think it is better to have a human decide what is in the module > > instead of relying on a pyang plugin to generate some additional > module > > that follows some simplistic pattern. > > It may be simple, but I’m thinking that’s only because it’s not > tricky ;) > > > > > > The client and server developers still need to know about this > > auto-generated module > > and implement it. Operators might have to know about it to use it. > > My idea is not to auto generate models on the fly. > > > > My aim is to allow folks to start writing models in the desired > long term format (i.e. combined config and state tree) with the > model designer being able to assume the existence of the > operational state datastore. > > > > > > > > I am not convinced this "new format" has solved anything. > > Don't you need separate description-stmts in every node for each > > datastore? What does the value mean if pre-configured? configured? > > operational? Will the auto-generated objects be exactly correct > > and never need any alterations or additional text? > > They still need to be used by developers and YANG tools. > > Right, this is one problem of this "deduplication": even if two > nodes - one config and the other state - have the same name or > even type (which is not always the case, as we know), their > semantics is often different. An IP address in configuration means > a manually configured address whereas in state it may come from > any source. So writing sensible descriptions will become tricky. > > > > > Is is that realistic to force the config structure and > operational structure > > to be the same? Seems it is quite common to monitor data structures > > with additional keys or different keys. This is completely > unsupported > > so separate /foo and /foo-state trees will still exist. > > I agree. > > Lada > > > > > IMO this combination of trees needs to be proven. > > Take ietf-interfaces and show how much better it will work > > if the /interfaces and /interfaces-state trees were combined. > > > > > > Andy > > > > > > The tooling would be there to statically generate the extra > foo-state config false node modules for servers that don't support > the operational state datastore. This could be done once, and the > extra foo-state modules committed to the github YANG respository > in the same way that models are extracted from IETF RFCs today. > > > > The aim here is that the single model being produced by IETF > would be usable both by new client/servers that support an > operational state datastore, and also by existing NETCONF > client/servers that don't implement an operational state datastore. > > > > I'm not proposing that as a long term solution, but as a path to > make it easier for folk to migrate, and to not slow down the model > writing effort. Otherwise, it may be hard to get a protocol model > writer to design the YANG model in a way that is not fully usable > on any current devices. > > > > As an illustration, an RFC published combined ietf-interfaces > model may look like this: > > > > > > OK -- let me see if I understand the value of combining ietf-interfaces. > > > Here is the starting tree: > > > +--rw interfaces > | +--rw interface* [name] > | +--rw name string > | +--rw description? string > | +--rw type identityref > | +--rw enabled? boolean > | +--rw link-up-down-trap-enable? enumeration > +--ro interfaces-state > +--ro interface* [name] > +--ro name string > +--ro type identityref > +--ro admin-status enumeration > +--ro oper-status enumeration > +--ro last-change? yang:date-and-time > +--ro if-index int32 > +--ro phys-address? yang:phys-address > +--ro higher-layer-if* interface-state-ref > +--ro lower-layer-if* interface-state-ref > +--ro speed? yang:gauge64 > +--ro statistics > +--ro discontinuity-time yang:date-and-time > +--ro in-octets? yang:counter64 > +--ro in-unicast-pkts? yang:counter64 > +--ro in-broadcast-pkts? yang:counter64 > +--ro in-multicast-pkts? yang:counter64 > +--ro in-discards? yang:counter32 > +--ro in-errors? yang:counter32 > +--ro in-unknown-protos? yang:counter32 > +--ro out-octets? yang:counter64 > +--ro out-unicast-pkts? yang:counter64 > +--ro out-broadcast-pkts? yang:counter64 > +--ro out-multicast-pkts? yang:counter64 > +--ro out-discards? yang:counter32 > +--ro out-errors? yang:counter32 > > > So these are the objects that would no longer be duplicated: > > - name > - type > > Neither one is supposed to have a different value in operational state > vs configuration. > > - enabled I (personally) would make the config "enabled" and the state "admin-status" leaf the same as well. But this example is really too simple on its own, a larger model needs to be considered to properly see the benefits. > - link-up-down-trap-enable > > These 2 could be different in operational state I suppose. > An RPC can provide the operational value without changing the YANG module > > rpc get-oper-value { > input { > leaf node { > type instance-identifier; > description "the config=true node to check"; > } > } > output { > anydata value { > description > "contains 1 child node matching the input 'node' parameter. > The value of the node is the current operational value." > } > } > } > > > > > /if:interfaces/if:interface[if:name='eth0']/enabled > > > > > > > false > > > > I don't need to change the YANG module at all to support operational > state. This solution would naively seem to be very limited. Rob > > > Andy > > > module: ietf-interfaces-combined > > +--rw interfaces > > +--rw interface* [name] > > +--rw name string > > +--rw description? string > > +--rw type identityref > > +--rw enabled? boolean > > +--rw link-up-down-trap-enable? enumeration {if-mib}? > > +--ro oper-status enumeration > > +--ro last-change? yang:date-and-time > > +--ro if-index int32 {if-mib}? > > +--ro phys-address? yang:phys-address > > +--ro higher-layer-if* interface-ref > > +--ro lower-layer-if* interface-ref > > +--ro speed? yang:gauge64 > > +--ro statistics > > +--ro discontinuity-time yang:date-and-time > > +--ro in-octets? yang:counter64 > > +--ro in-unicast-pkts? yang:counter64 > > +--ro in-broadcast-pkts? yang:counter64 > > +--ro in-multicast-pkts? yang:counter64 > > +--ro in-discards? yang:counter32 > > +--ro in-errors? yang:counter32 > > +--ro in-unknown-protos? yang:counter32 > > +--ro out-octets? yang:counter64 > > +--ro out-unicast-pkts? yang:counter64 > > +--ro out-broadcast-pkts? yang:counter64 > > +--ro out-multicast-pkts? yang:counter64 > > +--ro out-discards? yang:counter32 > > +--ro out-errors? yang:counter32 > > > > The extra generated model would look like this: > > > > module: ietf-interfaces-combined-state > > +--ro interfaces-state > > +--ro interface* [name] > > +--ro name string > > +--ro description? string > > +--ro type identityref > > +--ro enabled? boolean > > +--ro link-up-down-trap-enable? enumeration {if:if-mib}? > > +--ro oper-status enumeration > > +--ro last-change? yang:date-and-time > > +--ro if-index int32 {if:if-mib}? > > +--ro phys-address? yang:phys-address > > +--ro higher-layer-if* if:interface-ref > > +--ro lower-layer-if* if:interface-ref > > +--ro speed? yang:gauge64 > > +--ro statistics > > +--ro discontinuity-time yang:date-and-time > > +--ro in-octets? yang:counter64 > > +--ro in-unicast-pkts? yang:counter64 > > +--ro in-broadcast-pkts? yang:counter64 > > +--ro in-multicast-pkts? yang:counter64 > > +--ro in-discards? yang:counter32 > > +--ro in-errors? yang:counter32 > > +--ro in-unknown-protos? yang:counter32 > > +--ro out-octets? yang:counter64 > > +--ro out-unicast-pkts? yang:counter64 > > +--ro out-broadcast-pkts? yang:counter64 > > +--ro out-multicast-pkts? yang:counter64 > > +--ro out-discards? yang:counter32 > > +--ro out-errors? yang:counter32 > > > > Servers that support operational-state would just implement > ietf-interfaces-combined > > > > Servers that don't support operational-state could implement > ietf-interfaces-combined and ietf-interfaces-combined-state, > probably not implementing the duplicate config false leaves under > the interfaces config tree. Deviations could also be > auto-generated to remove the config false leaves from the config > tree so that they are only in the state tree. > > > > Of course, Clients may need to support both schemes depending on > what types of devices they are interacting with. > > > > Finally, I've illustrated this using ietf-interfaces, but I'm > not actually proposing immediately changing that model. I was > more thinking about IETF protocols that in the process of working > on their YANG models. > > > > Rob > > > > > > Exactly. I agree that this is a real hack. Implementations can use > > whatever transformation tricks they want in order to comply with > > different standards, but the standard modules should be very clear. > > > > > > > > > > > > > > /martin > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > --------------BF2D67C373073DA840A083C2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 11/01/2017 20:32, Andy Bierman wrote:


On Wed, Jan 11, 2017 at 9:21 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

> On 11 Jan 2017, at 17:56, Andy Bierman <andy@yumaworks.com> wrote:
>
> Hi,
>
>
> On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton <rwilton@cisco.com> wrote:
>
>
> On 11/01/2017 09:22, Martin Bjorklund wrote:
> Andy Bierman <andy@yumaworks.com> wrote:
> On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen <kwatsen@juniper.net> wrote:
>
> I think it is better to have a human decide what is in the module
> instead of relying on a pyang plugin to generate some additional module
> that follows some simplistic pattern.
> It may be simple, but I’m thinking that’s only because it’s not tricky  ;)
>
>
> The client and server developers still need to know about this
> auto-generated module
> and implement it.  Operators might have to know about it to use it.
> My idea is not to auto generate models on the fly.
>
> My aim is to allow folks to start writing models in the desired long term format (i.e. combined config and state tree) with the model designer being able to assume the existence of the operational state datastore.
>
>
>
> I am not convinced this "new format" has solved anything.
> Don't you need separate description-stmts in every node for each
> datastore?  What does the value mean if pre-configured? configured?
> operational?  Will the auto-generated objects be exactly correct
> and never need any alterations or additional text?
> They still need to be used by developers and YANG tools.

Right, this is one problem of this "deduplication": even if two nodes - one config and the other state - have the same name or even type (which is not always the case, as we know), their semantics is often different. An IP address in configuration means a manually configured address whereas in state it may come from any source. So writing sensible descriptions will become tricky.

>
> Is is that realistic to force the config structure and operational structure
> to be the same? Seems it is quite common to monitor data structures
> with additional keys or different keys.  This is completely unsupported
> so separate /foo and /foo-state trees will still exist.

I agree.

Lada

>
> IMO this combination of trees needs to be proven.
> Take ietf-interfaces and show how much better it will work
> if the /interfaces and /interfaces-state trees were combined.
>
>
> Andy
>
>
> The tooling would be there to statically generate the extra foo-state config false node modules for servers that don't support the operational state datastore.  This could be done once, and the extra foo-state modules committed to the github YANG respository in the same way that models are extracted from IETF RFCs today.
>
> The aim here is that the single model being produced by IETF would be usable both by new client/servers that support an operational state datastore, and also by existing NETCONF client/servers that don't implement an operational state datastore.
>
> I'm not proposing that as a long term solution, but as a path to make it easier for folk to migrate, and to not slow down the model writing effort.  Otherwise, it may be hard to get a protocol model writer to design the YANG model in a way that is not fully usable on any current devices.
>
> As an illustration, an RFC published combined ietf-interfaces model may look like this:
>


OK -- let me see if I understand the value of combining ietf-interfaces.


Here is the starting tree:


     +--rw interfaces
      |  +--rw interface* [name]
      |     +--rw name                        string
      |     +--rw description?                string
      |     +--rw type                        identityref
      |     +--rw enabled?                    boolean
      |     +--rw link-up-down-trap-enable?   enumeration
      +--ro interfaces-state
         +--ro interface* [name]
            +--ro name               string
            +--ro type               identityref
            +--ro admin-status       enumeration
            +--ro oper-status        enumeration
            +--ro last-change?       yang:date-and-time
            +--ro if-index           int32
            +--ro phys-address?      yang:phys-address
            +--ro higher-layer-if*   interface-state-ref
            +--ro lower-layer-if*    interface-state-ref
            +--ro speed?             yang:gauge64
            +--ro statistics
               +--ro discontinuity-time    yang:date-and-time
               +--ro in-octets?            yang:counter64
               +--ro in-unicast-pkts?      yang:counter64
               +--ro in-broadcast-pkts?    yang:counter64
               +--ro in-multicast-pkts?    yang:counter64
               +--ro in-discards?          yang:counter32
               +--ro in-errors?            yang:counter32
               +--ro in-unknown-protos?    yang:counter32
               +--ro out-octets?           yang:counter64
               +--ro out-unicast-pkts?     yang:counter64
               +--ro out-broadcast-pkts?   yang:counter64
               +--ro out-multicast-pkts?   yang:counter64
               +--ro out-discards?         yang:counter32
               +--ro out-errors?           yang:counter32


So these are the objects that would no longer be duplicated:

    - name
    - type

Neither one is supposed to have a different value in operational state vs configuration.

   - enabled

I (personally) would make the config "enabled" and the state "admin-status" leaf the same as well.

But this example is really too simple on its own, a larger model needs to be considered to properly see the benefits.


   - link-up-down-trap-enable

These 2 could be different in operational state I suppose.
An RPC can provide the operational value without changing the YANG module

    rpc get-oper-value {
      input {
         leaf node { 
            type instance-identifier; 
             description "the config=true node to check";
          }
      }
      output {
          anydata value {
             description 
               "contains 1 child node matching the input 'node' parameter.
                The value of the node is the current operational value."
          }
     }
   }


   <rpc>
      <get-oper-value>
          <node>/if:interfaces/if:interface[if:name='eth0']/enabled</node>
      </get-oper-value>
   </rpc>


   <rpc-reply>
       <value>
          <if:enabled>false</if:enabled>
        </value>
     </rpc-reply>

I don't need to change the YANG module at all to support operational state.

This solution would naively seem to be very limited.

Rob




Andy

 
> module: ietf-interfaces-combined
>     +--rw interfaces
>        +--rw interface* [name]
>           +--rw name                        string
>           +--rw description?                string
>           +--rw type                        identityref
>           +--rw enabled?                    boolean
>           +--rw link-up-down-trap-enable?   enumeration {if-mib}?
>           +--ro oper-status                 enumeration
>           +--ro last-change? yang:date-and-time
>           +--ro if-index                    int32 {if-mib}?
>           +--ro phys-address? yang:phys-address
>           +--ro higher-layer-if*            interface-ref
>           +--ro lower-layer-if*             interface-ref
>           +--ro speed?                      yang:gauge64
>           +--ro statistics
>              +--ro discontinuity-time    yang:date-and-time
>              +--ro in-octets?            yang:counter64
>              +--ro in-unicast-pkts?      yang:counter64
>              +--ro in-broadcast-pkts?    yang:counter64
>              +--ro in-multicast-pkts?    yang:counter64
>              +--ro in-discards?          yang:counter32
>              +--ro in-errors?            yang:counter32
>              +--ro in-unknown-protos?    yang:counter32
>              +--ro out-octets?           yang:counter64
>              +--ro out-unicast-pkts?     yang:counter64
>              +--ro out-broadcast-pkts?   yang:counter64
>              +--ro out-multicast-pkts?   yang:counter64
>              +--ro out-discards?         yang:counter32
>              +--ro out-errors?           yang:counter32
>
> The extra generated model would look like this:
>
> module: ietf-interfaces-combined-state
>     +--ro interfaces-state
>        +--ro interface* [name]
>           +--ro name                        string
>           +--ro description?                string
>           +--ro type                        identityref
>           +--ro enabled?                    boolean
>           +--ro link-up-down-trap-enable?   enumeration {if:if-mib}?
>           +--ro oper-status                 enumeration
>           +--ro last-change? yang:date-and-time
>           +--ro if-index                    int32 {if:if-mib}?
>           +--ro phys-address? yang:phys-address
>           +--ro higher-layer-if* if:interface-ref
>           +--ro lower-layer-if* if:interface-ref
>           +--ro speed?                      yang:gauge64
>           +--ro statistics
>              +--ro discontinuity-time    yang:date-and-time
>              +--ro in-octets?            yang:counter64
>              +--ro in-unicast-pkts?      yang:counter64
>              +--ro in-broadcast-pkts?    yang:counter64
>              +--ro in-multicast-pkts?    yang:counter64
>              +--ro in-discards?          yang:counter32
>              +--ro in-errors?            yang:counter32
>              +--ro in-unknown-protos?    yang:counter32
>              +--ro out-octets?           yang:counter64
>              +--ro out-unicast-pkts?     yang:counter64
>              +--ro out-broadcast-pkts?   yang:counter64
>              +--ro out-multicast-pkts?   yang:counter64
>              +--ro out-discards?         yang:counter32
>              +--ro out-errors?           yang:counter32
>
> Servers that support operational-state would just implement ietf-interfaces-combined
>
> Servers that don't support operational-state could implement ietf-interfaces-combined and ietf-interfaces-combined-state, probably not implementing the duplicate config false leaves under the interfaces config tree.  Deviations could also be auto-generated to remove the config false leaves from the config tree so that they are only in the state tree.
>
> Of course, Clients may need to support both schemes depending on what types of devices they are interacting with.
>
> Finally, I've illustrated this using ietf-interfaces, but I'm not actually proposing immediately changing that model.  I was more thinking about IETF protocols that in the process of working on their YANG models.
>
> Rob
>
>
> Exactly.  I agree that this is a real hack.  Implementations can use
> whatever transformation tricks they want in order to comply with
> different standards, but the standard modules should be very clear.
>
>
>
>
>
>
> /martin
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67







--------------BF2D67C373073DA840A083C2-- From nobody Thu Jan 12 04:47:49 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35522129615; Thu, 12 Jan 2017 04:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0i2uHiB7_uK; Thu, 12 Jan 2017 04:47:41 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 95A981295EE; Thu, 12 Jan 2017 04:47:40 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 563F51AE01AA; Thu, 12 Jan 2017 13:47:38 +0100 (CET) Date: Thu, 12 Jan 2017 13:47:37 +0100 (CET) Message-Id: <20170112.134737.887226373918047146.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org, netconf@ietf.org Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 12:47:43 -0000 QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiBPbiBXZWQsIEphbiAx MSwgMjAxNyBhdCA5OjIxIEFNLCBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o+IHdyb3Rl Og0KPiANCj4gPg0KPiA+ID4gT24gMTEgSmFuIDIwMTcsIGF0IDE3OjU2LCBBbmR5IEJpZXJtYW4g PGFuZHlAeXVtYXdvcmtzLmNvbT4gd3JvdGU6DQo+ID4gPg0KPiA+ID4gSGksDQo+ID4gPg0KPiA+ ID4NCj4gPiA+IE9uIFdlZCwgSmFuIDExLCAyMDE3IGF0IDc6MTIgQU0sIFJvYmVydCBXaWx0b24g PHJ3aWx0b25AY2lzY28uY29tPg0KPiA+IHdyb3RlOg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBPbiAx MS8wMS8yMDE3IDA5OjIyLCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3RlOg0KPiA+ID4gQW5keSBCaWVy bWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiA+ID4gT24gVHVlLCBKYW4gMTAsIDIw MTcgYXQgMToyMCBQTSwgS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+DQo+ID4gd3Jv dGU6DQo+ID4gPg0KPiA+ID4gSSB0aGluayBpdCBpcyBiZXR0ZXIgdG8gaGF2ZSBhIGh1bWFuIGRl Y2lkZSB3aGF0IGlzIGluIHRoZSBtb2R1bGUNCj4gPiA+IGluc3RlYWQgb2YgcmVseWluZyBvbiBh IHB5YW5nIHBsdWdpbiB0byBnZW5lcmF0ZSBzb21lIGFkZGl0aW9uYWwgbW9kdWxlDQo+ID4gPiB0 aGF0IGZvbGxvd3Mgc29tZSBzaW1wbGlzdGljIHBhdHRlcm4uDQo+ID4gPiBJdCBtYXkgYmUgc2lt cGxlLCBidXQgSeKAmW0gdGhpbmtpbmcgdGhhdOKAmXMgb25seSBiZWNhdXNlIGl04oCZcyBub3Qg dHJpY2t5DQo+ID4gOykNCj4gPiA+DQo+ID4gPg0KPiA+ID4gVGhlIGNsaWVudCBhbmQgc2VydmVy IGRldmVsb3BlcnMgc3RpbGwgbmVlZCB0byBrbm93IGFib3V0IHRoaXMNCj4gPiA+IGF1dG8tZ2Vu ZXJhdGVkIG1vZHVsZQ0KPiA+ID4gYW5kIGltcGxlbWVudCBpdC4gIE9wZXJhdG9ycyBtaWdodCBo YXZlIHRvIGtub3cgYWJvdXQgaXQgdG8gdXNlIGl0Lg0KPiA+ID4gTXkgaWRlYSBpcyBub3QgdG8g YXV0byBnZW5lcmF0ZSBtb2RlbHMgb24gdGhlIGZseS4NCj4gPiA+DQo+ID4gPiBNeSBhaW0gaXMg dG8gYWxsb3cgZm9sa3MgdG8gc3RhcnQgd3JpdGluZyBtb2RlbHMgaW4gdGhlIGRlc2lyZWQgbG9u Zw0KPiA+IHRlcm0gZm9ybWF0IChpLmUuIGNvbWJpbmVkIGNvbmZpZyBhbmQgc3RhdGUgdHJlZSkg d2l0aCB0aGUgbW9kZWwgZGVzaWduZXINCj4gPiBiZWluZyBhYmxlIHRvIGFzc3VtZSB0aGUgZXhp c3RlbmNlIG9mIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBkYXRhc3RvcmUuDQo+ID4gPg0KPiA+ID4N Cj4gPiA+DQo+ID4gPiBJIGFtIG5vdCBjb252aW5jZWQgdGhpcyAibmV3IGZvcm1hdCIgaGFzIHNv bHZlZCBhbnl0aGluZy4NCj4gPiA+IERvbid0IHlvdSBuZWVkIHNlcGFyYXRlIGRlc2NyaXB0aW9u LXN0bXRzIGluIGV2ZXJ5IG5vZGUgZm9yIGVhY2gNCj4gPiA+IGRhdGFzdG9yZT8gIFdoYXQgZG9l cyB0aGUgdmFsdWUgbWVhbiBpZiBwcmUtY29uZmlndXJlZD8gY29uZmlndXJlZD8NCj4gPiA+IG9w ZXJhdGlvbmFsPyAgV2lsbCB0aGUgYXV0by1nZW5lcmF0ZWQgb2JqZWN0cyBiZSBleGFjdGx5IGNv cnJlY3QNCj4gPiA+IGFuZCBuZXZlciBuZWVkIGFueSBhbHRlcmF0aW9ucyBvciBhZGRpdGlvbmFs IHRleHQ/DQo+ID4gPiBUaGV5IHN0aWxsIG5lZWQgdG8gYmUgdXNlZCBieSBkZXZlbG9wZXJzIGFu ZCBZQU5HIHRvb2xzLg0KPiA+DQo+ID4gUmlnaHQsIHRoaXMgaXMgb25lIHByb2JsZW0gb2YgdGhp cyAiZGVkdXBsaWNhdGlvbiI6IGV2ZW4gaWYgdHdvIG5vZGVzIC0NCj4gPiBvbmUgY29uZmlnIGFu ZCB0aGUgb3RoZXIgc3RhdGUgLSBoYXZlIHRoZSBzYW1lIG5hbWUgb3IgZXZlbiB0eXBlICh3aGlj aCBpcw0KPiA+IG5vdCBhbHdheXMgdGhlIGNhc2UsIGFzIHdlIGtub3cpLCB0aGVpciBzZW1hbnRp Y3MgaXMgb2Z0ZW4gZGlmZmVyZW50LiBBbiBJUA0KPiA+IGFkZHJlc3MgaW4gY29uZmlndXJhdGlv biBtZWFucyBhIG1hbnVhbGx5IGNvbmZpZ3VyZWQgYWRkcmVzcyB3aGVyZWFzIGluDQo+ID4gc3Rh dGUgaXQgbWF5IGNvbWUgZnJvbSBhbnkgc291cmNlLiBTbyB3cml0aW5nIHNlbnNpYmxlIGRlc2Ny aXB0aW9ucyB3aWxsDQo+ID4gYmVjb21lIHRyaWNreS4NCj4gPg0KPiA+ID4NCj4gPiA+IElzIGlz IHRoYXQgcmVhbGlzdGljIHRvIGZvcmNlIHRoZSBjb25maWcgc3RydWN0dXJlIGFuZCBvcGVyYXRp b25hbA0KPiA+IHN0cnVjdHVyZQ0KPiA+ID4gdG8gYmUgdGhlIHNhbWU/IFNlZW1zIGl0IGlzIHF1 aXRlIGNvbW1vbiB0byBtb25pdG9yIGRhdGEgc3RydWN0dXJlcw0KPiA+ID4gd2l0aCBhZGRpdGlv bmFsIGtleXMgb3IgZGlmZmVyZW50IGtleXMuICBUaGlzIGlzIGNvbXBsZXRlbHkgdW5zdXBwb3J0 ZWQNCj4gPiA+IHNvIHNlcGFyYXRlIC9mb28gYW5kIC9mb28tc3RhdGUgdHJlZXMgd2lsbCBzdGls bCBleGlzdC4NCj4gPg0KPiA+IEkgYWdyZWUuDQo+ID4NCj4gPiBMYWRhDQo+ID4NCj4gPiA+DQo+ ID4gPiBJTU8gdGhpcyBjb21iaW5hdGlvbiBvZiB0cmVlcyBuZWVkcyB0byBiZSBwcm92ZW4uDQo+ ID4gPiBUYWtlIGlldGYtaW50ZXJmYWNlcyBhbmQgc2hvdyBob3cgbXVjaCBiZXR0ZXIgaXQgd2ls bCB3b3JrDQo+ID4gPiBpZiB0aGUgL2ludGVyZmFjZXMgYW5kIC9pbnRlcmZhY2VzLXN0YXRlIHRy ZWVzIHdlcmUgY29tYmluZWQuDQo+ID4gPg0KPiA+ID4NCj4gPiA+IEFuZHkNCj4gPiA+DQo+ID4g Pg0KPiA+ID4gVGhlIHRvb2xpbmcgd291bGQgYmUgdGhlcmUgdG8gc3RhdGljYWxseSBnZW5lcmF0 ZSB0aGUgZXh0cmEgZm9vLXN0YXRlDQo+ID4gY29uZmlnIGZhbHNlIG5vZGUgbW9kdWxlcyBmb3Ig c2VydmVycyB0aGF0IGRvbid0IHN1cHBvcnQgdGhlIG9wZXJhdGlvbmFsDQo+ID4gc3RhdGUgZGF0 YXN0b3JlLiAgVGhpcyBjb3VsZCBiZSBkb25lIG9uY2UsIGFuZCB0aGUgZXh0cmEgZm9vLXN0YXRl IG1vZHVsZXMNCj4gPiBjb21taXR0ZWQgdG8gdGhlIGdpdGh1YiBZQU5HIHJlc3Bvc2l0b3J5IGlu IHRoZSBzYW1lIHdheSB0aGF0IG1vZGVscyBhcmUNCj4gPiBleHRyYWN0ZWQgZnJvbSBJRVRGIFJG Q3MgdG9kYXkuDQo+ID4gPg0KPiA+ID4gVGhlIGFpbSBoZXJlIGlzIHRoYXQgdGhlIHNpbmdsZSBt b2RlbCBiZWluZyBwcm9kdWNlZCBieSBJRVRGIHdvdWxkIGJlDQo+ID4gdXNhYmxlIGJvdGggYnkg bmV3IGNsaWVudC9zZXJ2ZXJzIHRoYXQgc3VwcG9ydCBhbiBvcGVyYXRpb25hbCBzdGF0ZQ0KPiA+ IGRhdGFzdG9yZSwgYW5kIGFsc28gYnkgZXhpc3RpbmcgTkVUQ09ORiBjbGllbnQvc2VydmVycyB0 aGF0IGRvbid0IGltcGxlbWVudA0KPiA+IGFuIG9wZXJhdGlvbmFsIHN0YXRlIGRhdGFzdG9yZS4N Cj4gPiA+DQo+ID4gPiBJJ20gbm90IHByb3Bvc2luZyB0aGF0IGFzIGEgbG9uZyB0ZXJtIHNvbHV0 aW9uLCBidXQgYXMgYSBwYXRoIHRvIG1ha2UgaXQNCj4gPiBlYXNpZXIgZm9yIGZvbGsgdG8gbWln cmF0ZSwgYW5kIHRvIG5vdCBzbG93IGRvd24gdGhlIG1vZGVsIHdyaXRpbmcgZWZmb3J0Lg0KPiA+ IE90aGVyd2lzZSwgaXQgbWF5IGJlIGhhcmQgdG8gZ2V0IGEgcHJvdG9jb2wgbW9kZWwgd3JpdGVy IHRvIGRlc2lnbiB0aGUgWUFORw0KPiA+IG1vZGVsIGluIGEgd2F5IHRoYXQgaXMgbm90IGZ1bGx5 IHVzYWJsZSBvbiBhbnkgY3VycmVudCBkZXZpY2VzLg0KPiA+ID4NCj4gPiA+IEFzIGFuIGlsbHVz dHJhdGlvbiwgYW4gUkZDIHB1Ymxpc2hlZCBjb21iaW5lZCBpZXRmLWludGVyZmFjZXMgbW9kZWwg bWF5DQo+ID4gbG9vayBsaWtlIHRoaXM6DQo+ID4gPg0KPiA+DQo+IA0KPiANCj4gT0sgLS0gbGV0 IG1lIHNlZSBpZiBJIHVuZGVyc3RhbmQgdGhlIHZhbHVlIG9mIGNvbWJpbmluZyBpZXRmLWludGVy ZmFjZXMuDQo+IA0KPiANCj4gSGVyZSBpcyB0aGUgc3RhcnRpbmcgdHJlZToNCj4gDQo+IA0KPiAg ICAgICstLXJ3IGludGVyZmFjZXMNCj4gICAgICAgfCAgKy0tcncgaW50ZXJmYWNlKiBbbmFtZV0N Cj4gICAgICAgfCAgICAgKy0tcncgbmFtZSAgICAgICAgICAgICAgICAgICAgICAgIHN0cmluZw0K PiAgICAgICB8ICAgICArLS1ydyBkZXNjcmlwdGlvbj8gICAgICAgICAgICAgICAgc3RyaW5nDQo+ ICAgICAgIHwgICAgICstLXJ3IHR5cGUgICAgICAgICAgICAgICAgICAgICAgICBpZGVudGl0eXJl Zg0KPiAgICAgICB8ICAgICArLS1ydyBlbmFibGVkPyAgICAgICAgICAgICAgICAgICAgYm9vbGVh bg0KPiAgICAgICB8ICAgICArLS1ydyBsaW5rLXVwLWRvd24tdHJhcC1lbmFibGU/ICAgZW51bWVy YXRpb24NCj4gICAgICAgKy0tcm8gaW50ZXJmYWNlcy1zdGF0ZQ0KPiAgICAgICAgICArLS1ybyBp bnRlcmZhY2UqIFtuYW1lXQ0KPiAgICAgICAgICAgICArLS1ybyBuYW1lICAgICAgICAgICAgICAg c3RyaW5nDQo+ICAgICAgICAgICAgICstLXJvIHR5cGUgICAgICAgICAgICAgICBpZGVudGl0eXJl Zg0KPiAgICAgICAgICAgICArLS1ybyBhZG1pbi1zdGF0dXMgICAgICAgZW51bWVyYXRpb24NCj4g ICAgICAgICAgICAgKy0tcm8gb3Blci1zdGF0dXMgICAgICAgIGVudW1lcmF0aW9uDQo+ICAgICAg ICAgICAgICstLXJvIGxhc3QtY2hhbmdlPyAgICAgICB5YW5nOmRhdGUtYW5kLXRpbWUNCj4gICAg ICAgICAgICAgKy0tcm8gaWYtaW5kZXggICAgICAgICAgIGludDMyDQo+ICAgICAgICAgICAgICst LXJvIHBoeXMtYWRkcmVzcz8gICAgICB5YW5nOnBoeXMtYWRkcmVzcw0KPiAgICAgICAgICAgICAr LS1ybyBoaWdoZXItbGF5ZXItaWYqICAgaW50ZXJmYWNlLXN0YXRlLXJlZg0KPiAgICAgICAgICAg ICArLS1ybyBsb3dlci1sYXllci1pZiogICAgaW50ZXJmYWNlLXN0YXRlLXJlZg0KPiAgICAgICAg ICAgICArLS1ybyBzcGVlZD8gICAgICAgICAgICAgeWFuZzpnYXVnZTY0DQo+ICAgICAgICAgICAg ICstLXJvIHN0YXRpc3RpY3MNCj4gICAgICAgICAgICAgICAgKy0tcm8gZGlzY29udGludWl0eS10 aW1lICAgIHlhbmc6ZGF0ZS1hbmQtdGltZQ0KPiAgICAgICAgICAgICAgICArLS1ybyBpbi1vY3Rl dHM/ICAgICAgICAgICAgeWFuZzpjb3VudGVyNjQNCj4gICAgICAgICAgICAgICAgKy0tcm8gaW4t dW5pY2FzdC1wa3RzPyAgICAgIHlhbmc6Y291bnRlcjY0DQo+ICAgICAgICAgICAgICAgICstLXJv IGluLWJyb2FkY2FzdC1wa3RzPyAgICB5YW5nOmNvdW50ZXI2NA0KPiAgICAgICAgICAgICAgICAr LS1ybyBpbi1tdWx0aWNhc3QtcGt0cz8gICAgeWFuZzpjb3VudGVyNjQNCj4gICAgICAgICAgICAg ICAgKy0tcm8gaW4tZGlzY2FyZHM/ICAgICAgICAgIHlhbmc6Y291bnRlcjMyDQo+ICAgICAgICAg ICAgICAgICstLXJvIGluLWVycm9ycz8gICAgICAgICAgICB5YW5nOmNvdW50ZXIzMg0KPiAgICAg ICAgICAgICAgICArLS1ybyBpbi11bmtub3duLXByb3Rvcz8gICAgeWFuZzpjb3VudGVyMzINCj4g DQo+ICAgICAgICAgICAgICAgICstLXJvIG91dC1vY3RldHM/ICAgICAgICAgICB5YW5nOmNvdW50 ZXI2NA0KPiAgICAgICAgICAgICAgICArLS1ybyBvdXQtdW5pY2FzdC1wa3RzPyAgICAgeWFuZzpj b3VudGVyNjQNCj4gICAgICAgICAgICAgICAgKy0tcm8gb3V0LWJyb2FkY2FzdC1wa3RzPyAgIHlh bmc6Y291bnRlcjY0DQo+ICAgICAgICAgICAgICAgICstLXJvIG91dC1tdWx0aWNhc3QtcGt0cz8g ICB5YW5nOmNvdW50ZXI2NA0KPiAgICAgICAgICAgICAgICArLS1ybyBvdXQtZGlzY2FyZHM/ICAg ICAgICAgeWFuZzpjb3VudGVyMzINCj4gICAgICAgICAgICAgICAgKy0tcm8gb3V0LWVycm9ycz8g ICAgICAgICAgIHlhbmc6Y291bnRlcjMyDQo+IA0KPiANCj4gDQo+IFNvIHRoZXNlIGFyZSB0aGUg b2JqZWN0cyB0aGF0IHdvdWxkIG5vIGxvbmdlciBiZSBkdXBsaWNhdGVkOg0KPiANCj4gICAgIC0g bmFtZQ0KPiAgICAgLSB0eXBlDQo+IA0KPiBOZWl0aGVyIG9uZSBpcyBzdXBwb3NlZCB0byBoYXZl IGEgZGlmZmVyZW50IHZhbHVlIGluIG9wZXJhdGlvbmFsIHN0YXRlIHZzDQo+IGNvbmZpZ3VyYXRp b24uDQo+IA0KPiAgICAtIGVuYWJsZWQNCj4gICAgLSBsaW5rLXVwLWRvd24tdHJhcC1lbmFibGUN Cj4gDQo+IFRoZXNlIDIgY291bGQgYmUgZGlmZmVyZW50IGluIG9wZXJhdGlvbmFsIHN0YXRlIEkg c3VwcG9zZS4NCj4gQW4gUlBDIGNhbiBwcm92aWRlIHRoZSBvcGVyYXRpb25hbCB2YWx1ZSB3aXRo b3V0IGNoYW5naW5nIHRoZSBZQU5HIG1vZHVsZQ0KPiANCj4gICAgIHJwYyBnZXQtb3Blci12YWx1 ZSB7DQo+ICAgICAgIGlucHV0IHsNCj4gICAgICAgICAgbGVhZiBub2RlIHsNCj4gICAgICAgICAg ICAgdHlwZSBpbnN0YW5jZS1pZGVudGlmaWVyOw0KPiAgICAgICAgICAgICAgZGVzY3JpcHRpb24g InRoZSBjb25maWc9dHJ1ZSBub2RlIHRvIGNoZWNrIjsNCj4gICAgICAgICAgIH0NCj4gICAgICAg fQ0KPiAgICAgICBvdXRwdXQgew0KPiAgICAgICAgICAgYW55ZGF0YSB2YWx1ZSB7DQo+ICAgICAg ICAgICAgICBkZXNjcmlwdGlvbg0KPiAgICAgICAgICAgICAgICAiY29udGFpbnMgMSBjaGlsZCBu b2RlIG1hdGNoaW5nIHRoZSBpbnB1dCAnbm9kZScgcGFyYW1ldGVyLg0KPiAgICAgICAgICAgICAg ICAgVGhlIHZhbHVlIG9mIHRoZSBub2RlIGlzIHRoZSBjdXJyZW50IG9wZXJhdGlvbmFsIHZhbHVl LiINCj4gICAgICAgICAgIH0NCj4gICAgICB9DQo+ICAgIH0NCg0KVGhpcyBpcyBlc3NlbnRpYWxs eSB3aGF0IHdlIHByb3Bvc2UsIGV4Y2VwdCB0aGF0IHdlIGhhdmUgZ2VuZXJhbGl6ZWQNCml0IHNv IHRoYXQgbW9yZSB0aGFuIG9uZSB2YWx1ZSBjYW4gYmUgcmV0cmVpdmVkOiA8Z2V0LXN0YXRlPiBv cg0KPGdldC1kYXRhPiB3aGljaCB0YWtlcyBhIGZpbHRlciBqdXN0IGxpa2UgPGdldD4uDQoNCg0K PiAgICA8cnBjPg0KPiAgICAgICA8Z2V0LW9wZXItdmFsdWU+DQo+ICAgICAgICAgICA8bm9kZT4v aWY6aW50ZXJmYWNlcy9pZjppbnRlcmZhY2VbaWY6bmFtZT0nZXRoMCddL2VuYWJsZWQ8L25vZGU+ DQo+ICAgICAgIDwvZ2V0LW9wZXItdmFsdWU+DQo+ICAgIDwvcnBjPg0KPiANCj4gDQo+ICAgIDxy cGMtcmVwbHk+DQo+ICAgICAgICA8dmFsdWU+DQo+ICAgICAgICAgICA8aWY6ZW5hYmxlZD5mYWxz ZTwvaWY6ZW5hYmxlZD4NCj4gICAgICAgICA8L3ZhbHVlPg0KPiAgICAgIDwvcnBjLXJlcGx5Pg0K PiANCj4gSSBkb24ndCBuZWVkIHRvIGNoYW5nZSB0aGUgWUFORyBtb2R1bGUgYXQgYWxsIHRvIHN1 cHBvcnQgb3BlcmF0aW9uYWwgc3RhdGUuDQoNCkNvcnJlY3QuICBPbGQgbW9kdWxlcyB3aWxsIGNv bnRpbnVlIHRvIHdvcmsuICBDbGllbnRzIHRoYXQgPGdldC1zdGF0ZT4NCmJvdGggL2ludGVyZmFj ZXMgYW5kIC9pbnRlcmZhY2VzLXN0YXRlIHdpbGwgcmVjZWl2ZSBzb21lIGR1cGxpY2F0ZQ0KZGF0 YS4NCg0KSG93ZXZlciwgdGhlIG5ldyBtb2RlbCBhbGxvd3MgZm9yIGNvbWJpbmVkIHRyZWVzIHRv IGJlIGRlZmluZWQuDQoNCg0KL21hcnRpbg0KDQo+IA0KPiANCj4gQW5keQ0KPiANCj4gDQo+IA0K PiA+ID4gbW9kdWxlOiBpZXRmLWludGVyZmFjZXMtY29tYmluZWQNCj4gPiA+ICAgICArLS1ydyBp bnRlcmZhY2VzDQo+ID4gPiAgICAgICAgKy0tcncgaW50ZXJmYWNlKiBbbmFtZV0NCj4gPiA+ICAg ICAgICAgICArLS1ydyBuYW1lICAgICAgICAgICAgICAgICAgICAgICAgc3RyaW5nDQo+ID4gPiAg ICAgICAgICAgKy0tcncgZGVzY3JpcHRpb24/ICAgICAgICAgICAgICAgIHN0cmluZw0KPiA+ID4g ICAgICAgICAgICstLXJ3IHR5cGUgICAgICAgICAgICAgICAgICAgICAgICBpZGVudGl0eXJlZg0K PiA+ID4gICAgICAgICAgICstLXJ3IGVuYWJsZWQ/ICAgICAgICAgICAgICAgICAgICBib29sZWFu DQo+ID4gPiAgICAgICAgICAgKy0tcncgbGluay11cC1kb3duLXRyYXAtZW5hYmxlPyAgIGVudW1l cmF0aW9uIHtpZi1taWJ9Pw0KPiA+ID4gICAgICAgICAgICstLXJvIG9wZXItc3RhdHVzICAgICAg ICAgICAgICAgICBlbnVtZXJhdGlvbg0KPiA+ID4gICAgICAgICAgICstLXJvIGxhc3QtY2hhbmdl PyB5YW5nOmRhdGUtYW5kLXRpbWUNCj4gPiA+ICAgICAgICAgICArLS1ybyBpZi1pbmRleCAgICAg ICAgICAgICAgICAgICAgaW50MzIge2lmLW1pYn0/DQo+ID4gPiAgICAgICAgICAgKy0tcm8gcGh5 cy1hZGRyZXNzPyB5YW5nOnBoeXMtYWRkcmVzcw0KPiA+ID4gICAgICAgICAgICstLXJvIGhpZ2hl ci1sYXllci1pZiogICAgICAgICAgICBpbnRlcmZhY2UtcmVmDQo+ID4gPiAgICAgICAgICAgKy0t cm8gbG93ZXItbGF5ZXItaWYqICAgICAgICAgICAgIGludGVyZmFjZS1yZWYNCj4gPiA+ICAgICAg ICAgICArLS1ybyBzcGVlZD8gICAgICAgICAgICAgICAgICAgICAgeWFuZzpnYXVnZTY0DQo+ID4g PiAgICAgICAgICAgKy0tcm8gc3RhdGlzdGljcw0KPiA+ID4gICAgICAgICAgICAgICstLXJvIGRp c2NvbnRpbnVpdHktdGltZSAgICB5YW5nOmRhdGUtYW5kLXRpbWUNCj4gPiA+ICAgICAgICAgICAg ICArLS1ybyBpbi1vY3RldHM/ICAgICAgICAgICAgeWFuZzpjb3VudGVyNjQNCj4gPiA+ICAgICAg ICAgICAgICArLS1ybyBpbi11bmljYXN0LXBrdHM/ICAgICAgeWFuZzpjb3VudGVyNjQNCj4gPiA+ ICAgICAgICAgICAgICArLS1ybyBpbi1icm9hZGNhc3QtcGt0cz8gICAgeWFuZzpjb3VudGVyNjQN Cj4gPiA+ICAgICAgICAgICAgICArLS1ybyBpbi1tdWx0aWNhc3QtcGt0cz8gICAgeWFuZzpjb3Vu dGVyNjQNCj4gPiA+ICAgICAgICAgICAgICArLS1ybyBpbi1kaXNjYXJkcz8gICAgICAgICAgeWFu Zzpjb3VudGVyMzINCj4gPiA+ICAgICAgICAgICAgICArLS1ybyBpbi1lcnJvcnM/ICAgICAgICAg ICAgeWFuZzpjb3VudGVyMzINCj4gPiA+ICAgICAgICAgICAgICArLS1ybyBpbi11bmtub3duLXBy b3Rvcz8gICAgeWFuZzpjb3VudGVyMzINCj4gPiA+ICAgICAgICAgICAgICArLS1ybyBvdXQtb2N0 ZXRzPyAgICAgICAgICAgeWFuZzpjb3VudGVyNjQNCj4gPiA+ICAgICAgICAgICAgICArLS1ybyBv dXQtdW5pY2FzdC1wa3RzPyAgICAgeWFuZzpjb3VudGVyNjQNCj4gPiA+ICAgICAgICAgICAgICAr LS1ybyBvdXQtYnJvYWRjYXN0LXBrdHM/ICAgeWFuZzpjb3VudGVyNjQNCj4gPiA+ICAgICAgICAg ICAgICArLS1ybyBvdXQtbXVsdGljYXN0LXBrdHM/ICAgeWFuZzpjb3VudGVyNjQNCj4gPiA+ICAg ICAgICAgICAgICArLS1ybyBvdXQtZGlzY2FyZHM/ICAgICAgICAgeWFuZzpjb3VudGVyMzINCj4g PiA+ICAgICAgICAgICAgICArLS1ybyBvdXQtZXJyb3JzPyAgICAgICAgICAgeWFuZzpjb3VudGVy MzINCj4gPiA+DQo+ID4gPiBUaGUgZXh0cmEgZ2VuZXJhdGVkIG1vZGVsIHdvdWxkIGxvb2sgbGlr ZSB0aGlzOg0KPiA+ID4NCj4gPiA+IG1vZHVsZTogaWV0Zi1pbnRlcmZhY2VzLWNvbWJpbmVkLXN0 YXRlDQo+ID4gPiAgICAgKy0tcm8gaW50ZXJmYWNlcy1zdGF0ZQ0KPiA+ID4gICAgICAgICstLXJv IGludGVyZmFjZSogW25hbWVdDQo+ID4gPiAgICAgICAgICAgKy0tcm8gbmFtZSAgICAgICAgICAg ICAgICAgICAgICAgIHN0cmluZw0KPiA+ID4gICAgICAgICAgICstLXJvIGRlc2NyaXB0aW9uPyAg ICAgICAgICAgICAgICBzdHJpbmcNCj4gPiA+ICAgICAgICAgICArLS1ybyB0eXBlICAgICAgICAg ICAgICAgICAgICAgICAgaWRlbnRpdHlyZWYNCj4gPiA+ICAgICAgICAgICArLS1ybyBlbmFibGVk PyAgICAgICAgICAgICAgICAgICAgYm9vbGVhbg0KPiA+ID4gICAgICAgICAgICstLXJvIGxpbmst dXAtZG93bi10cmFwLWVuYWJsZT8gICBlbnVtZXJhdGlvbiB7aWY6aWYtbWlifT8NCj4gPiA+ICAg ICAgICAgICArLS1ybyBvcGVyLXN0YXR1cyAgICAgICAgICAgICAgICAgZW51bWVyYXRpb24NCj4g PiA+ICAgICAgICAgICArLS1ybyBsYXN0LWNoYW5nZT8geWFuZzpkYXRlLWFuZC10aW1lDQo+ID4g PiAgICAgICAgICAgKy0tcm8gaWYtaW5kZXggICAgICAgICAgICAgICAgICAgIGludDMyIHtpZjpp Zi1taWJ9Pw0KPiA+ID4gICAgICAgICAgICstLXJvIHBoeXMtYWRkcmVzcz8geWFuZzpwaHlzLWFk ZHJlc3MNCj4gPiA+ICAgICAgICAgICArLS1ybyBoaWdoZXItbGF5ZXItaWYqIGlmOmludGVyZmFj ZS1yZWYNCj4gPiA+ICAgICAgICAgICArLS1ybyBsb3dlci1sYXllci1pZiogaWY6aW50ZXJmYWNl LXJlZg0KPiA+ID4gICAgICAgICAgICstLXJvIHNwZWVkPyAgICAgICAgICAgICAgICAgICAgICB5 YW5nOmdhdWdlNjQNCj4gPiA+ICAgICAgICAgICArLS1ybyBzdGF0aXN0aWNzDQo+ID4gPiAgICAg ICAgICAgICAgKy0tcm8gZGlzY29udGludWl0eS10aW1lICAgIHlhbmc6ZGF0ZS1hbmQtdGltZQ0K PiA+ID4gICAgICAgICAgICAgICstLXJvIGluLW9jdGV0cz8gICAgICAgICAgICB5YW5nOmNvdW50 ZXI2NA0KPiA+ID4gICAgICAgICAgICAgICstLXJvIGluLXVuaWNhc3QtcGt0cz8gICAgICB5YW5n OmNvdW50ZXI2NA0KPiA+ID4gICAgICAgICAgICAgICstLXJvIGluLWJyb2FkY2FzdC1wa3RzPyAg ICB5YW5nOmNvdW50ZXI2NA0KPiA+ID4gICAgICAgICAgICAgICstLXJvIGluLW11bHRpY2FzdC1w a3RzPyAgICB5YW5nOmNvdW50ZXI2NA0KPiA+ID4gICAgICAgICAgICAgICstLXJvIGluLWRpc2Nh cmRzPyAgICAgICAgICB5YW5nOmNvdW50ZXIzMg0KPiA+ID4gICAgICAgICAgICAgICstLXJvIGlu LWVycm9ycz8gICAgICAgICAgICB5YW5nOmNvdW50ZXIzMg0KPiA+ID4gICAgICAgICAgICAgICst LXJvIGluLXVua25vd24tcHJvdG9zPyAgICB5YW5nOmNvdW50ZXIzMg0KPiA+ID4gICAgICAgICAg ICAgICstLXJvIG91dC1vY3RldHM/ICAgICAgICAgICB5YW5nOmNvdW50ZXI2NA0KPiA+ID4gICAg ICAgICAgICAgICstLXJvIG91dC11bmljYXN0LXBrdHM/ICAgICB5YW5nOmNvdW50ZXI2NA0KPiA+ ID4gICAgICAgICAgICAgICstLXJvIG91dC1icm9hZGNhc3QtcGt0cz8gICB5YW5nOmNvdW50ZXI2 NA0KPiA+ID4gICAgICAgICAgICAgICstLXJvIG91dC1tdWx0aWNhc3QtcGt0cz8gICB5YW5nOmNv dW50ZXI2NA0KPiA+ID4gICAgICAgICAgICAgICstLXJvIG91dC1kaXNjYXJkcz8gICAgICAgICB5 YW5nOmNvdW50ZXIzMg0KPiA+ID4gICAgICAgICAgICAgICstLXJvIG91dC1lcnJvcnM/ICAgICAg ICAgICB5YW5nOmNvdW50ZXIzMg0KPiA+ID4NCj4gPiA+IFNlcnZlcnMgdGhhdCBzdXBwb3J0IG9w ZXJhdGlvbmFsLXN0YXRlIHdvdWxkIGp1c3QgaW1wbGVtZW50DQo+ID4gaWV0Zi1pbnRlcmZhY2Vz LWNvbWJpbmVkDQo+ID4gPg0KPiA+ID4gU2VydmVycyB0aGF0IGRvbid0IHN1cHBvcnQgb3BlcmF0 aW9uYWwtc3RhdGUgY291bGQgaW1wbGVtZW50DQo+ID4gaWV0Zi1pbnRlcmZhY2VzLWNvbWJpbmVk IGFuZCBpZXRmLWludGVyZmFjZXMtY29tYmluZWQtc3RhdGUsIHByb2JhYmx5IG5vdA0KPiA+IGlt cGxlbWVudGluZyB0aGUgZHVwbGljYXRlIGNvbmZpZyBmYWxzZSBsZWF2ZXMgdW5kZXIgdGhlIGlu dGVyZmFjZXMgY29uZmlnDQo+ID4gdHJlZS4gIERldmlhdGlvbnMgY291bGQgYWxzbyBiZSBhdXRv LWdlbmVyYXRlZCB0byByZW1vdmUgdGhlIGNvbmZpZyBmYWxzZQ0KPiA+IGxlYXZlcyBmcm9tIHRo ZSBjb25maWcgdHJlZSBzbyB0aGF0IHRoZXkgYXJlIG9ubHkgaW4gdGhlIHN0YXRlIHRyZWUuDQo+ ID4gPg0KPiA+ID4gT2YgY291cnNlLCBDbGllbnRzIG1heSBuZWVkIHRvIHN1cHBvcnQgYm90aCBz Y2hlbWVzIGRlcGVuZGluZyBvbiB3aGF0DQo+ID4gdHlwZXMgb2YgZGV2aWNlcyB0aGV5IGFyZSBp bnRlcmFjdGluZyB3aXRoLg0KPiA+ID4NCj4gPiA+IEZpbmFsbHksIEkndmUgaWxsdXN0cmF0ZWQg dGhpcyB1c2luZyBpZXRmLWludGVyZmFjZXMsIGJ1dCBJJ20gbm90DQo+ID4gYWN0dWFsbHkgcHJv cG9zaW5nIGltbWVkaWF0ZWx5IGNoYW5naW5nIHRoYXQgbW9kZWwuICBJIHdhcyBtb3JlIHRoaW5r aW5nDQo+ID4gYWJvdXQgSUVURiBwcm90b2NvbHMgdGhhdCBpbiB0aGUgcHJvY2VzcyBvZiB3b3Jr aW5nIG9uIHRoZWlyIFlBTkcgbW9kZWxzLg0KPiA+ID4NCj4gPiA+IFJvYg0KPiA+ID4NCj4gPiA+ DQo+ID4gPiBFeGFjdGx5LiAgSSBhZ3JlZSB0aGF0IHRoaXMgaXMgYSByZWFsIGhhY2suICBJbXBs ZW1lbnRhdGlvbnMgY2FuIHVzZQ0KPiA+ID4gd2hhdGV2ZXIgdHJhbnNmb3JtYXRpb24gdHJpY2tz IHRoZXkgd2FudCBpbiBvcmRlciB0byBjb21wbHkgd2l0aA0KPiA+ID4gZGlmZmVyZW50IHN0YW5k YXJkcywgYnV0IHRoZSBzdGFuZGFyZCBtb2R1bGVzIHNob3VsZCBiZSB2ZXJ5IGNsZWFyLg0KPiA+ ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gL21hcnRpbg0KPiA+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gPiA+DQo+ID4gPg0KPiA+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gPg0KPiA+IC0tDQo+ID4g TGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPiA+IFBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhB OUY3NkM2Nw0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0K From nobody Thu Jan 12 09:20:04 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5F51294F8 for ; Thu, 12 Jan 2017 09:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lS7XMgsnv1Ic for ; Thu, 12 Jan 2017 09:19:56 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00E281294CF for ; Thu, 12 Jan 2017 09:19:55 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id u25so27461845qki.2 for ; Thu, 12 Jan 2017 09:19:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9X6ExlFTK9by5VCRAK8tDvKc9+wppnYra3WaKlBbxSE=; b=GGQXHHnTQruxbZIAsxFbVaOT5bMC9fe5ZNtqNIF0dgK9F7jhitZNC+2f0tehIfCoQ1 u70M/VVI5Ri+WoFOyjFvl8GwzFuxwPLG+iNfdaf7XynhxQCQJrjNu242elJvy+II7j5U d1OM295+cte+l4WJQ0wEXzpnbxqBgO7vOstRQsJHFkteV/uZmIW1aXYCUArp1m0xZuJJ q7gkvCzYelo59kJ0KZ1MoKVjzv3/vtPjCDGMN11YWqhU/QUGSji8qFjKYIRY8ZWU/Jvz tqoA5s65xD4w1hid7zh6Gt7oh6oWO1tlILD3M491sCQN/77TNUgrt0UT520e04Mx0F/J 7YfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9X6ExlFTK9by5VCRAK8tDvKc9+wppnYra3WaKlBbxSE=; b=cNEyxOqX+XbVZm3GMjZk2gTSbSqPM7c8Gtsw6yQHqvMaNbhpMP6XTNC9HKFVINrf9+ 98n0QO585epyXIM+Si8rpjUKRM95NBIWii3d1kQ5TXcvmszkGIDIJDQF+hj/ndeLa+b9 K8OfZD1Ib86W/pDvlgf9/z2JxCYAEj3WKkQTjtqURrX5SHOxNwDftriRuiqxB15hpxr7 cE2Yu1rKgRm30TkfauUoUVlzQN9EuGMm4hrdgYOECg5syKyVCKsLHOsehGLhh5fGgriG mZ4rluLbMGycLQrl7h8SD0f2x2NKmKbQd0cnJPj20ajD13k1sLCJTNvSsRtb8A5GuyC8 9xGA== X-Gm-Message-State: AIkVDXJxiBhJj5piN890m3dDc6+O9e3V68C47cvuI3Wolpqfm+A6GxBdJGMl2Lh8Uyrj8fyiXYqy9o/aikYxnw== X-Received: by 10.55.22.97 with SMTP id g94mr13869401qkh.287.1484241595041; Thu, 12 Jan 2017 09:19:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Thu, 12 Jan 2017 09:19:54 -0800 (PST) In-Reply-To: <20170112.134737.887226373918047146.mbj@tail-f.com> References: <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> <20170112.134737.887226373918047146.mbj@tail-f.com> From: Andy Bierman Date: Thu, 12 Jan 2017 09:19:54 -0800 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a114967ea08bd820545e8ed9e Archived-At: Cc: "netmod@ietf.org" , Netconf Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 17:20:02 -0000 --001a114967ea08bd820545e8ed9e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jan 12, 2017 at 4:47 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Wed, Jan 11, 2017 at 9:21 AM, Ladislav Lhotka wrote: > > > > > > > > > On 11 Jan 2017, at 17:56, Andy Bierman wrote: > > > > > > > > Hi, > > > > > > > > > > > > On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton > > > wrote: > > > > > > > > > > > > On 11/01/2017 09:22, Martin Bjorklund wrote: > > > > Andy Bierman wrote: > > > > On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen > > > wrote: > > > > > > > > I think it is better to have a human decide what is in the module > > > > instead of relying on a pyang plugin to generate some additional > module > > > > that follows some simplistic pattern. > > > > It may be simple, but I=E2=80=99m thinking that=E2=80=99s only beca= use it=E2=80=99s not > tricky > > > ;) > > > > > > > > > > > > The client and server developers still need to know about this > > > > auto-generated module > > > > and implement it. Operators might have to know about it to use it. > > > > My idea is not to auto generate models on the fly. > > > > > > > > My aim is to allow folks to start writing models in the desired lon= g > > > term format (i.e. combined config and state tree) with the model > designer > > > being able to assume the existence of the operational state datastore= . > > > > > > > > > > > > > > > > I am not convinced this "new format" has solved anything. > > > > Don't you need separate description-stmts in every node for each > > > > datastore? What does the value mean if pre-configured? configured? > > > > operational? Will the auto-generated objects be exactly correct > > > > and never need any alterations or additional text? > > > > They still need to be used by developers and YANG tools. > > > > > > Right, this is one problem of this "deduplication": even if two nodes= - > > > one config and the other state - have the same name or even type > (which is > > > not always the case, as we know), their semantics is often different. > An IP > > > address in configuration means a manually configured address whereas = in > > > state it may come from any source. So writing sensible descriptions > will > > > become tricky. > > > > > > > > > > > Is is that realistic to force the config structure and operational > > > structure > > > > to be the same? Seems it is quite common to monitor data structures > > > > with additional keys or different keys. This is completely > unsupported > > > > so separate /foo and /foo-state trees will still exist. > > > > > > I agree. > > > > > > Lada > > > > > > > > > > > IMO this combination of trees needs to be proven. > > > > Take ietf-interfaces and show how much better it will work > > > > if the /interfaces and /interfaces-state trees were combined. > > > > > > > > > > > > Andy > > > > > > > > > > > > The tooling would be there to statically generate the extra foo-sta= te > > > config false node modules for servers that don't support the > operational > > > state datastore. This could be done once, and the extra foo-state > modules > > > committed to the github YANG respository in the same way that models > are > > > extracted from IETF RFCs today. > > > > > > > > The aim here is that the single model being produced by IETF would = be > > > usable both by new client/servers that support an operational state > > > datastore, and also by existing NETCONF client/servers that don't > implement > > > an operational state datastore. > > > > > > > > I'm not proposing that as a long term solution, but as a path to > make it > > > easier for folk to migrate, and to not slow down the model writing > effort. > > > Otherwise, it may be hard to get a protocol model writer to design th= e > YANG > > > model in a way that is not fully usable on any current devices. > > > > > > > > As an illustration, an RFC published combined ietf-interfaces model > may > > > look like this: > > > > > > > > > > > > > OK -- let me see if I understand the value of combining ietf-interfaces= . > > > > > > Here is the starting tree: > > > > > > +--rw interfaces > > | +--rw interface* [name] > > | +--rw name string > > | +--rw description? string > > | +--rw type identityref > > | +--rw enabled? boolean > > | +--rw link-up-down-trap-enable? enumeration > > +--ro interfaces-state > > +--ro interface* [name] > > +--ro name string > > +--ro type identityref > > +--ro admin-status enumeration > > +--ro oper-status enumeration > > +--ro last-change? yang:date-and-time > > +--ro if-index int32 > > +--ro phys-address? yang:phys-address > > +--ro higher-layer-if* interface-state-ref > > +--ro lower-layer-if* interface-state-ref > > +--ro speed? yang:gauge64 > > +--ro statistics > > +--ro discontinuity-time yang:date-and-time > > +--ro in-octets? yang:counter64 > > +--ro in-unicast-pkts? yang:counter64 > > +--ro in-broadcast-pkts? yang:counter64 > > +--ro in-multicast-pkts? yang:counter64 > > +--ro in-discards? yang:counter32 > > +--ro in-errors? yang:counter32 > > +--ro in-unknown-protos? yang:counter32 > > > > +--ro out-octets? yang:counter64 > > +--ro out-unicast-pkts? yang:counter64 > > +--ro out-broadcast-pkts? yang:counter64 > > +--ro out-multicast-pkts? yang:counter64 > > +--ro out-discards? yang:counter32 > > +--ro out-errors? yang:counter32 > > > > > > > > So these are the objects that would no longer be duplicated: > > > > - name > > - type > > > > Neither one is supposed to have a different value in operational state = vs > > configuration. > > > > - enabled > > - link-up-down-trap-enable > > > > These 2 could be different in operational state I suppose. > > An RPC can provide the operational value without changing the YANG modu= le > > > > rpc get-oper-value { > > input { > > leaf node { > > type instance-identifier; > > description "the config=3Dtrue node to check"; > > } > > } > > output { > > anydata value { > > description > > "contains 1 child node matching the input 'node' > parameter. > > The value of the node is the current operational value.= " > > } > > } > > } > > This is essentially what we propose, except that we have generalized > it so that more than one value can be retreived: or > which takes a filter just like . > > OK How do I retrieve the same subtree from multiple contexts at once so I can reduce time-skew caused by retrieving config-tree then oper-tree? > > > > > > > /if:interfaces/if:interface[if:name=3D'eth0']/ > enabled > > > > > > > > > > > > > > false > > > > > > > > I don't need to change the YANG module at all to support operational > state. > > Correct. Old modules will continue to work. Clients that > both /interfaces and /interfaces-state will receive some duplicate > data. > > However, the new model allows for combined trees to be defined. > > Here are the things that do not work anymore if a designer uses the new tree approach: YANG statements: - It is not possible to define these statements so they are different for config and oper - must - when - unique - key - min-elements - max-elements - leafref (path) - if-feature - deviation - type (or any sub-statements of type-stmt) - status - description - reference YANG allows must-when to reference state data nodes in every XPath context except 1: - state data - RPC input - RPC output - action input - action output - notification payload Seems like you are removing a lot of YANG functionality in order to make the problem-space fit your solution-space. > > /martin > > > > > > > Andy > > > Andy > > > > > > > > module: ietf-interfaces-combined > > > > +--rw interfaces > > > > +--rw interface* [name] > > > > +--rw name string > > > > +--rw description? string > > > > +--rw type identityref > > > > +--rw enabled? boolean > > > > +--rw link-up-down-trap-enable? enumeration {if-mib}? > > > > +--ro oper-status enumeration > > > > +--ro last-change? yang:date-and-time > > > > +--ro if-index int32 {if-mib}? > > > > +--ro phys-address? yang:phys-address > > > > +--ro higher-layer-if* interface-ref > > > > +--ro lower-layer-if* interface-ref > > > > +--ro speed? yang:gauge64 > > > > +--ro statistics > > > > +--ro discontinuity-time yang:date-and-time > > > > +--ro in-octets? yang:counter64 > > > > +--ro in-unicast-pkts? yang:counter64 > > > > +--ro in-broadcast-pkts? yang:counter64 > > > > +--ro in-multicast-pkts? yang:counter64 > > > > +--ro in-discards? yang:counter32 > > > > +--ro in-errors? yang:counter32 > > > > +--ro in-unknown-protos? yang:counter32 > > > > +--ro out-octets? yang:counter64 > > > > +--ro out-unicast-pkts? yang:counter64 > > > > +--ro out-broadcast-pkts? yang:counter64 > > > > +--ro out-multicast-pkts? yang:counter64 > > > > +--ro out-discards? yang:counter32 > > > > +--ro out-errors? yang:counter32 > > > > > > > > The extra generated model would look like this: > > > > > > > > module: ietf-interfaces-combined-state > > > > +--ro interfaces-state > > > > +--ro interface* [name] > > > > +--ro name string > > > > +--ro description? string > > > > +--ro type identityref > > > > +--ro enabled? boolean > > > > +--ro link-up-down-trap-enable? enumeration {if:if-mib}= ? > > > > +--ro oper-status enumeration > > > > +--ro last-change? yang:date-and-time > > > > +--ro if-index int32 {if:if-mib}? > > > > +--ro phys-address? yang:phys-address > > > > +--ro higher-layer-if* if:interface-ref > > > > +--ro lower-layer-if* if:interface-ref > > > > +--ro speed? yang:gauge64 > > > > +--ro statistics > > > > +--ro discontinuity-time yang:date-and-time > > > > +--ro in-octets? yang:counter64 > > > > +--ro in-unicast-pkts? yang:counter64 > > > > +--ro in-broadcast-pkts? yang:counter64 > > > > +--ro in-multicast-pkts? yang:counter64 > > > > +--ro in-discards? yang:counter32 > > > > +--ro in-errors? yang:counter32 > > > > +--ro in-unknown-protos? yang:counter32 > > > > +--ro out-octets? yang:counter64 > > > > +--ro out-unicast-pkts? yang:counter64 > > > > +--ro out-broadcast-pkts? yang:counter64 > > > > +--ro out-multicast-pkts? yang:counter64 > > > > +--ro out-discards? yang:counter32 > > > > +--ro out-errors? yang:counter32 > > > > > > > > Servers that support operational-state would just implement > > > ietf-interfaces-combined > > > > > > > > Servers that don't support operational-state could implement > > > ietf-interfaces-combined and ietf-interfaces-combined-state, probably > not > > > implementing the duplicate config false leaves under the interfaces > config > > > tree. Deviations could also be auto-generated to remove the config > false > > > leaves from the config tree so that they are only in the state tree. > > > > > > > > Of course, Clients may need to support both schemes depending on wh= at > > > types of devices they are interacting with. > > > > > > > > Finally, I've illustrated this using ietf-interfaces, but I'm not > > > actually proposing immediately changing that model. I was more > thinking > > > about IETF protocols that in the process of working on their YANG > models. > > > > > > > > Rob > > > > > > > > > > > > Exactly. I agree that this is a real hack. Implementations can us= e > > > > whatever transformation tricks they want in order to comply with > > > > different standards, but the standard modules should be very clear. > > > > > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > > > > > > > > > > --001a114967ea08bd820545e8ed9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 12, 2017 at 4:47 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Wed, Jan 11, 2017 at 9:21 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> >
> > > On 11 Jan 2017, at 17:56, Andy Bierman <andy@yumaworks.com> wrote:
> > >
> > > Hi,
> > >
> > >
> > > On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton <rwilton@cisco.com>
> > wrote:
> > >
> > >
> > > On 11/01/2017 09:22, Martin Bjorklund wrote:
> > > Andy Bierman <andy@= yumaworks.com> wrote:
> > > On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen <kwatsen@juniper.net>
> > wrote:
> > >
> > > I think it is better to have a human decide what is in the m= odule
> > > instead of relying on a pyang plugin to generate some additi= onal module
> > > that follows some simplistic pattern.
> > > It may be simple, but I=E2=80=99m thinking that=E2=80=99s on= ly because it=E2=80=99s not tricky
> > ;)
> > >
> > >
> > > The client and server developers still need to know about th= is
> > > auto-generated module
> > > and implement it.=C2=A0 Operators might have to know about i= t to use it.
> > > My idea is not to auto generate models on the fly.
> > >
> > > My aim is to allow folks to start writing models in the desi= red long
> > term format (i.e. combined config and state tree) with the model = designer
> > being able to assume the existence of the operational state datas= tore.
> > >
> > >
> > >
> > > I am not convinced this "new format" has solved an= ything.
> > > Don't you need separate description-stmts in every node = for each
> > > datastore?=C2=A0 What does the value mean if pre-configured?= configured?
> > > operational?=C2=A0 Will the auto-generated objects be exactl= y correct
> > > and never need any alterations or additional text?
> > > They still need to be used by developers and YANG tools.
> >
> > Right, this is one problem of this "deduplication": eve= n if two nodes -
> > one config and the other state - have the same name or even type = (which is
> > not always the case, as we know), their semantics is often differ= ent. An IP
> > address in configuration means a manually configured address wher= eas in
> > state it may come from any source. So writing sensible descriptio= ns will
> > become tricky.
> >
> > >
> > > Is is that realistic to force the config structure and opera= tional
> > structure
> > > to be the same? Seems it is quite common to monitor data str= uctures
> > > with additional keys or different keys.=C2=A0 This is comple= tely unsupported
> > > so separate /foo and /foo-state trees will still exist.
> >
> > I agree.
> >
> > Lada
> >
> > >
> > > IMO this combination of trees needs to be proven.
> > > Take ietf-interfaces and show how much better it will work > > > if the /interfaces and /interfaces-state trees were combined= .
> > >
> > >
> > > Andy
> > >
> > >
> > > The tooling would be there to statically generate the extra = foo-state
> > config false node modules for servers that don't support the = operational
> > state datastore.=C2=A0 This could be done once, and the extra foo= -state modules
> > committed to the github YANG respository in the same way that mod= els are
> > extracted from IETF RFCs today.
> > >
> > > The aim here is that the single model being produced by IETF= would be
> > usable both by new client/servers that support an operational sta= te
> > datastore, and also by existing NETCONF client/servers that don&#= 39;t implement
> > an operational state datastore.
> > >
> > > I'm not proposing that as a long term solution, but as a= path to make it
> > easier for folk to migrate, and to not slow down the model writin= g effort.
> > Otherwise, it may be hard to get a protocol model writer to desig= n the YANG
> > model in a way that is not fully usable on any current devices. > > >
> > > As an illustration, an RFC published combined ietf-interface= s model may
> > look like this:
> > >
> >
>
>
> OK -- let me see if I understand the value of combining ietf-interface= s.
>
>
> Here is the starting tree:
>
>
>=C2=A0 =C2=A0 =C2=A0 +--rw interfaces
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw interface* [name]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw name=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 stri= ng
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw description?=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw type=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 iden= tityref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw enabled?=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 boolean
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw link-up-down-trap= -enable?=C2=A0 =C2=A0enumeration
>=C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro interfaces-state
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro interface* [name]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro name=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0string
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro type=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0identityref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro admin-status=C2= =A0 =C2=A0 =C2=A0 =C2=A0enumeration
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro oper-status=C2=A0= =C2=A0 =C2=A0 =C2=A0 enumeration
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro last-change?=C2= =A0 =C2=A0 =C2=A0 =C2=A0yang:date-and-time
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro if-index=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0int32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro phys-address?=C2= =A0 =C2=A0 =C2=A0 yang:phys-address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro higher-layer-if*= =C2=A0 =C2=A0interface-state-ref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro lower-layer-if*= =C2=A0 =C2=A0 interface-state-ref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro speed?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:gauge64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro statistics
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro discontin= uity-time=C2=A0 =C2=A0 yang:date-and-time
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-octets= ?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-unicas= t-pkts?=C2=A0 =C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-broadc= ast-pkts?=C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-multic= ast-pkts?=C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-discar= ds?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-errors= ?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-unknow= n-protos?=C2=A0 =C2=A0 yang:counter32
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-octet= s?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-unica= st-pkts?=C2=A0 =C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-broad= cast-pkts?=C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-multi= cast-pkts?=C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-disca= rds?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-error= s?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32
>
>
>
> So these are the objects that would no longer be duplicated:
>
>=C2=A0 =C2=A0 =C2=A0- name
>=C2=A0 =C2=A0 =C2=A0- type
>
> Neither one is supposed to have a different value in operational state= vs
> configuration.
>
>=C2=A0 =C2=A0 - enabled
>=C2=A0 =C2=A0 - link-up-down-trap-enable
>
> These 2 could be different in operational state I suppose.
> An RPC can provide the operational value without changing the YANG mod= ule
>
>=C2=A0 =C2=A0 =C2=A0rpc get-oper-value {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0input {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf node {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type instance-identifie= r;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description "the = config=3Dtrue node to check";
>=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=A0output {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0anydata value {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "contains = 1 child node matching the input 'node' parameter.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The value= of the node is the current operational value."
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 }

This is essentially what we propose, except that we have generalized
it so that more than one value can be retreived: <get-state> or
<get-data> which takes a filter just like <get>.


OK

How do I r= etrieve the same subtree from multiple contexts at once
so I can = reduce time-skew caused by retrieving config-tree then oper-tree?
=C2=A0

>=C2=A0 =C2=A0 <rpc>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<get-oper-value>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<node>/if:interfaces/if:= interface[if:name=3D'eth0']/enabled</node>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0</get-oper-value>
>=C2=A0 =C2=A0 </rpc>
>
>
>=C2=A0 =C2=A0 <rpc-reply>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <value>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<if:enabled>false</if= :enabled>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</value>
>=C2=A0 =C2=A0 =C2=A0 </rpc-reply>
>
> I don't need to change the YANG module at all to support operation= al state.

Correct.=C2=A0 Old modules will continue to work.=C2=A0 Clients that <ge= t-state>
both /interfaces and /interfaces-state will receive some duplicate
data.

However, the new model allows for combined trees to be defined.



Here are the things tha= t do not work anymore if a designer uses the new tree approach:
<= br>

YANG statements:
=C2=A0 =C2=A0- It i= s not possible to define these statements so they are different for config = and oper
=C2=A0 =C2=A0 =C2=A0 - must
=C2=A0 =C2=A0 =C2= =A0 - when
=C2=A0 =C2=A0 =C2=A0 - unique
=C2=A0 =C2=A0 = =C2=A0 - key
=C2=A0 =C2=A0 =C2=A0 - min-elements
=C2=A0= =C2=A0 =C2=A0 - max-elements
=C2=A0 =C2=A0 =C2=A0 - leafref (pat= h)
=C2=A0 =C2=A0 =C2=A0 - if-feature
=C2=A0 =C2=A0 =C2= =A0 - deviation
=C2=A0 =C2=A0 =C2=A0 - type (or any sub-statement= s of type-stmt)
=C2=A0 =C2=A0 =C2=A0 - status
=C2=A0 = =C2=A0 =C2=A0 - description
=C2=A0 =C2=A0 =C2=A0 - reference

YANG allows must-when to reference state data nodes in= every XPath context except 1:
=C2=A0 =C2=A0- state data
=C2=A0 =C2=A0- RPC input
=C2=A0 =C2=A0- RPC output
= =C2=A0 =C2=A0- action input
=C2=A0 =C2=A0- action output
=C2=A0 =C2=A0- notification payload

Seems like y= ou are removing a lot of YANG functionality in order to make the problem-sp= ace
fit your solution-space.

=C2=A0

/martin

>
>
> Andy
>


Andy
=C2= =A0
>
>
> > > module: ietf-interfaces-combined
> > >=C2=A0 =C2=A0 =C2=A0+--rw interfaces
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw interface* [name]
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw name=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 s= tring
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw description?= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw type=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 i= dentityref
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw enabled?=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 boolean
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw link-up-down-t= rap-enable?=C2=A0 =C2=A0enumeration {if-mib}?
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro oper-status=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enumeration
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro last-change? y= ang:date-and-time
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro if-index=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int32 {if-m= ib}?
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro phys-address? = yang:phys-address
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro higher-layer-i= f*=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 interface-ref
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro lower-layer-if= *=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interface-ref
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro speed?=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:= gauge64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro statistics
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro discon= tinuity-time=C2=A0 =C2=A0 yang:date-and-time
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-oct= ets?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-uni= cast-pkts?=C2=A0 =C2=A0 =C2=A0 yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-bro= adcast-pkts?=C2=A0 =C2=A0 yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-mul= ticast-pkts?=C2=A0 =C2=A0 yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-dis= cards?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-err= ors?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-unk= nown-protos?=C2=A0 =C2=A0 yang:counter32
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-oc= tets?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-un= icast-pkts?=C2=A0 =C2=A0 =C2=A0yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-br= oadcast-pkts?=C2=A0 =C2=A0yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-mu= lticast-pkts?=C2=A0 =C2=A0yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-di= scards?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-er= rors?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32
> > >
> > > The extra generated model would look like this:
> > >
> > > module: ietf-interfaces-combined-state
> > >=C2=A0 =C2=A0 =C2=A0+--ro interfaces-state
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro interface* [name]
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro name=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 s= tring
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro description?= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro type=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 i= dentityref
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro enabled?=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 boolean
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro link-up-down-t= rap-enable?=C2=A0 =C2=A0enumeration {if:if-mib}?
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro oper-status=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enumeration
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro last-change? y= ang:date-and-time
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro if-index=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int32 {if:i= f-mib}?
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro phys-address? = yang:phys-address
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro higher-layer-i= f* if:interface-ref
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro lower-layer-if= * if:interface-ref
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro speed?=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:= gauge64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro statistics
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro discon= tinuity-time=C2=A0 =C2=A0 yang:date-and-time
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-oct= ets?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-uni= cast-pkts?=C2=A0 =C2=A0 =C2=A0 yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-bro= adcast-pkts?=C2=A0 =C2=A0 yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-mul= ticast-pkts?=C2=A0 =C2=A0 yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-dis= cards?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-err= ors?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-unk= nown-protos?=C2=A0 =C2=A0 yang:counter32
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-oc= tets?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-un= icast-pkts?=C2=A0 =C2=A0 =C2=A0yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-br= oadcast-pkts?=C2=A0 =C2=A0yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-mu= lticast-pkts?=C2=A0 =C2=A0yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-di= scards?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-er= rors?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32
> > >
> > > Servers that support operational-state would just implement<= br> > > ietf-interfaces-combined
> > >
> > > Servers that don't support operational-state could imple= ment
> > ietf-interfaces-combined and ietf-interfaces-combined-state,= probably not
> > implementing the duplicate config false leaves under the interfac= es config
> > tree.=C2=A0 Deviations could also be auto-generated to remove the= config false
> > leaves from the config tree so that they are only in the state tr= ee.
> > >
> > > Of course, Clients may need to support both schemes dependin= g on what
> > types of devices they are interacting with.
> > >
> > > Finally, I've illustrated this using ietf-interfaces, bu= t I'm not
> > actually proposing immediately changing that model.=C2=A0 I was m= ore thinking
> > about IETF protocols that in the process of working on their YANG= models.
> > >
> > > Rob
> > >
> > >
> > > Exactly.=C2=A0 I agree that this is a real hack.=C2=A0 Imple= mentations can use
> > > whatever transformation tricks they want in order to comply = with
> > > different standards, but the standard modules should be very= clear.
> > >
> > >
> > >
> > >
> > >
> > >
> > > /martin
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinf= o/netmod
> > >
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinf= o/netmod
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> >
> >
> >
> >
> >
> >

--001a114967ea08bd820545e8ed9e-- From nobody Thu Jan 12 09:34:18 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061E312959B; Thu, 12 Jan 2017 09:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-diHiLb_sOZ; Thu, 12 Jan 2017 09:34:04 -0800 (PST) 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 8180412956C; Thu, 12 Jan 2017 09:34:04 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D6EA06D5; Thu, 12 Jan 2017 18:34:02 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ggU5cZL2ve18; Thu, 12 Jan 2017 18:33:59 +0100 (CET) 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, 12 Jan 2017 18:34:02 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 95AD720091; Thu, 12 Jan 2017 18:34:02 +0100 (CET) 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 sQx4bIXLdDm5; Thu, 12 Jan 2017 18:34:02 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2AE462008D; Thu, 12 Jan 2017 18:34:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0258E3E0B377; Thu, 12 Jan 2017 18:34:02 +0100 (CET) Date: Thu, 12 Jan 2017 18:34:02 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20170112173402.GB21677@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" , Netconf References: <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> <20170112.134737.887226373918047146.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 17:34:11 -0000 On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman wrote: > > YANG statements: > - It is not possible to define these statements so they are different > for config and oper > - must > - when > - unique > - key > - min-elements > - max-elements > - leafref (path) > - if-feature > - deviation > - type (or any sub-statements of type-stmt) > - status > - description > - reference Considering statements that constraint 'values', it is not entirely clear to me what they mean for state nodes. If a server has operational state that violates a must or range or ... constraint in the YANG model, what is the server expected to do? /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 Jan 12 09:38:56 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E5D12951D for ; Thu, 12 Jan 2017 09:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cH9SxMfUAosO for ; Thu, 12 Jan 2017 09:38:49 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54A91129447 for ; Thu, 12 Jan 2017 09:38:49 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id x49so24685476qtc.2 for ; Thu, 12 Jan 2017 09:38:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=+pGt2j1lufCBXwYKSCaUTSSdWKjAkv8ggAIZd+jr1UQ=; b=GsZx+Jk07ZtGK4ejOpdox6T6afP6zTGZSkIjh3JCyU4/YNxyf09ZWI7COCh5S73S57 dylyr+nliFTXVgKZwwClyWPeuYu1GoYSlpkWMyyeiiRiY6WyT4+nvZ07Nkg5n6pP7B+W 7JZO0q2VBtQNUCdqsHqiDppsYTcroySzuhb7/8Sh3TAo7/8CEbvQy2aYBYlxNwuaotnB ZL4IeFDt80jyi0Z4ku+YxfNQ1OEeKL0kuOfuoxJv/ZGEKqJw8NzOslrZ0RKQTNZ3jSgy /erDXmU8PVLzXeSOkmGjP5gnq958iFBq60WFJByQ9yK5imLLTXZx1J+Eux34RO2Grzkz Ge6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=+pGt2j1lufCBXwYKSCaUTSSdWKjAkv8ggAIZd+jr1UQ=; b=IenXQa9ODGXlZasR2LEJt73UUuURqbb1lCrdfA57ASIDrMbeWUC3gMV1QX2U7N3SHS ErNLHut6DWbsPOYfgg2dJHId2t9t+ib5t7aCalFhKEDq1rqMIbIqqDtoGtl3w1pnX4qP RMcFgGaKcRwkHqAYLbGUVB1K/FSKP6Utk56m3eqC584MHGRgDtx0lR130P96y/A+NH41 B+/EemKrlGl6gkJINcGBoPFQXZ2eHWRGeSF+RyUGCQuxdbX9y/eq+9Za7uAdo84cKTIp K6phKFX2ixWjID+HryobIbgR0pM8bUBzAY2c1adHJKgEcDwcQn3/Y/2ltdgrxfSmg3Iv Ehzw== X-Gm-Message-State: AIkVDXKUwy58xldkbLifXpYUR1No9+uIR+LUGm2tIRnXrLmi5T9zDBcqnBHgXVtZ6FJPb8rzL7GpAvr7YUIdBg== X-Received: by 10.200.1.2 with SMTP id e2mr2161449qtg.142.1484242728342; Thu, 12 Jan 2017 09:38:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Thu, 12 Jan 2017 09:38:46 -0800 (PST) In-Reply-To: <20170112173402.GB21677@elstar.local> References: <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> <20170112.134737.887226373918047146.mbj@tail-f.com> <20170112173402.GB21677@elstar.local> From: Andy Bierman Date: Thu, 12 Jan 2017 09:38:46 -0800 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , "netmod@ietf.org" , Netconf Content-Type: multipart/alternative; boundary=f403045f39e4956b0b0545e930c5 Archived-At: Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 17:38:52 -0000 --f403045f39e4956b0b0545e930c5 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman wrote: > > > > YANG statements: > > - It is not possible to define these statements so they are different > > for config and oper > > - must > > - when > > - unique > > - key > > - min-elements > > - max-elements > > - leafref (path) > > - if-feature > > - deviation > > - type (or any sub-statements of type-stmt) > > - status > > - description > > - reference > > Considering statements that constraint 'values', it is not entirely > clear to me what they mean for state nodes. If a server has > operational state that violates a must or range or ... constraint in > the YANG model, what is the server expected to do? > The client uses the YANG validation to check on what the server is sending. The server is buggy if it is sending data that violates YANG constraints. If any of these statements need to be different for config and oper then the old style YANG has to be used instead. > > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --f403045f39e4956b0b0545e930c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierm= an wrote:
>
> YANG statements:
>=C2=A0 =C2=A0 - It is not possible to define these statements so they a= re different
> for config and oper
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- must
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- when
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- unique
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- key
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- min-elements
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- max-elements
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- leafref (path)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- if-feature
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- deviation
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- type (or any sub-statements of type-stmt)<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0- status
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- reference

Considering statements that constraint 'values', it is not entirely=
clear to me what they mean for state nodes. If a server has
operational state that violates a must or range or ... constraint in
the YANG model, what is the server expected to do?
The client uses the YANG validation to check on what the server= is sending.
The server is buggy if it is sending data that viola= tes YANG constraints.
If any of these statements need to be diffe= rent for config and oper
then the old style YANG has to be used i= nstead.

=C2=A0

/js

Andy
=C2=A0=

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--f403045f39e4956b0b0545e930c5-- From nobody Thu Jan 12 09:54:13 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829901294D2; Thu, 12 Jan 2017 09:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bj6I-OIz8sLr; Thu, 12 Jan 2017 09:54:07 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3ABC129447; Thu, 12 Jan 2017 09:54:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7746; q=dns/txt; s=iport; t=1484243647; x=1485453247; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=xUHvkiVGbAu/2DABkKo3bWpHsr0TJyne4nB/KvLiotA=; b=A6Pv/PQwc5fssFcLECBG0t5+lpkc5Xqen8tpMWxQVMSfeCY4NwS11rkE QZfc3Xi2cySK7ahVlxOF6tzQlEtEm7qLSwyRySq7fx0c4jPI5B88UxZag iH6fNmhZDIOk2djjyFZJnEspwWNQWV2rCaNUusZvWCN/rmK3d9RunBFdp M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAQBQwndY/xbLJq1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM8AQEBAQF+A4EGjVhykSKPf4Urgg0fAQqEHoEQSgKCRBQBAgE?= =?us-ascii?q?BAQEBAQFjKIRpAQEBBAEBbBkCCxAIIwQHGwwfEQYBDAYCAQGIfA6zByuJbQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR0FhkCCAgiCV4QwNyaCBYMYBZsskVaKL4Y7imm?= =?us-ascii?q?Hex84gRUSCBUVOoN8bIFHPjWGKyuCEAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,219,1477958400"; d="scan'208,217";a="649749111" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2017 17:54:02 +0000 Received: from [10.63.23.107] (dhcp-ensft1-uk-vla370-10-63-23-107.cisco.com [10.63.23.107]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v0CHs2gh025452; Thu, 12 Jan 2017 17:54:02 GMT To: Andy Bierman , Juergen Schoenwaelder , Martin Bjorklund , "netmod@ietf.org" , Netconf References: <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> <20170112.134737.887226373918047146.mbj@tail-f.com> <20170112173402.GB21677@elstar.local> From: Robert Wilton Message-ID: <67fae2eb-faa2-7bc3-4763-51a38296233b@cisco.com> Date: Thu, 12 Jan 2017 17:54:03 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EA9C078E1E67848E7E4646EA" Archived-At: Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 17:54:09 -0000 This is a multi-part message in MIME format. --------------EA9C078E1E67848E7E4646EA Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 12/01/2017 17:38, Andy Bierman wrote: > > > On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder > > wrote: > > On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman wrote: > > > > YANG statements: > > - It is not possible to define these statements so they are > different > > for config and oper > > - must > > - when > > - unique > > - key > > - min-elements > > - max-elements > > - leafref (path) > > - if-feature > > - deviation > > - type (or any sub-statements of type-stmt) > > - status > > - description > > - reference > > Considering statements that constraint 'values', it is not entirely > clear to me what they mean for state nodes. If a server has > operational state that violates a must or range or ... constraint in > the YANG model, what is the server expected to do? > > > The client uses the YANG validation to check on what the server is > sending. > The server is buggy if it is sending data that violates YANG constraints. > If any of these statements need to be different for config and oper > then the old style YANG has to be used instead. You just have a separate state leaf. These are still allowed in a combined tree. The config true leaf in the operational state datastore represents the applied configuration. The additional state leaf represents some more complex state derived from the applied configuration, just like the rest of the config false leaves. Rob > > > /js > > > Andy > > > -- > 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 --------------EA9C078E1E67848E7E4646EA Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 12/01/2017 17:38, Andy Bierman wrote:


On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman wrote:
>
> YANG statements:
> - It is not possible to define these statements so they are different
> for config and oper
> - must
> - when
> - unique
> - key
> - min-elements
> - max-elements
> - leafref (path)
> - if-feature
> - deviation
> - type (or any sub-statements of type-stmt)
> - status
> - description
> - reference

Considering statements that constraint 'values', it is not entirely
clear to me what they mean for state nodes. If a server has
operational state that violates a must or range or ... constraint in
the YANG model, what is the server expected to do?

The client uses the YANG validation to check on what the server is sending.
The server is buggy if it is sending data that violates YANG constraints.
If any of these statements need to be different for config and oper
then the old style YANG has to be used instead.
You just have a separate state leaf. These are still allowed in a combined tree.

The config true leaf in the operational state datastore represents the applied configuration.
The additional state leaf represents some more complex state derived from the applied configuration, just like the rest of the config false leaves.

Rob




/js

Andy

--
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

--------------EA9C078E1E67848E7E4646EA-- From nobody Thu Jan 12 10:44:57 2017 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36EEE129435; Thu, 12 Jan 2017 10:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heN2KVIOWi2Q; Thu, 12 Jan 2017 10:44:53 -0800 (PST) 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 40AC41293F3; Thu, 12 Jan 2017 10:44:53 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 184CC7C2; Thu, 12 Jan 2017 19:44:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id T-yJd-aitBPt; Thu, 12 Jan 2017 19:44:48 +0100 (CET) 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, 12 Jan 2017 19:44:51 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B21DB2008E; Thu, 12 Jan 2017 19:44:51 +0100 (CET) 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 FbGHND9kSYxT; Thu, 12 Jan 2017 19:44:50 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 928E22008C; Thu, 12 Jan 2017 19:44:50 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F01FE3E0B4E8; Thu, 12 Jan 2017 19:44:52 +0100 (CET) Date: Thu, 12 Jan 2017 19:44:52 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20170112184452.GC21677@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" , Netconf References: <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> <20170112.134737.887226373918047146.mbj@tail-f.com> <20170112173402.GB21677@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At:


On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen <kwatsen@juniper.net> wrote:

> I think it is better to have a human decide what is in the module
> instead of relying on a pyang plugin to generate some additional modul= e
> that follows some simplistic pattern.

It may be simple, but I=E2=80=99m thinking that=E2=80=99s only because it= =E2=80=99s not tricky=C2=A0 ;)


The client and server developers still= need to know about this auto-generated module
and implement it.= =C2=A0 Operators might have to know about it to use it.=C2=A0

> Of course this solution only works if the value-set of operational dat= a
> is exactly the same as the configurable value-set (which is sometimes<= br> > not the case at all).

The value-set of the operational data would be the combination of both the = config true and config false nodes.=C2=A0 =C2=A0[Did you see this in my las= t response? I received an offline message indicating that my previous respo= nse was somewhat malformed, so you might=E2=80=99ve missed it...].=C2=A0 = =C2=A0The config false nodes are obviously part of the operational data.=C2= =A0 For the config true nodes, I=E2=80=99ve been swayed to believe that eve= ry config true node can also have an operational value.=C2=A0 I didn=E2=80= =99t think so at first, using =E2=80=98hostname=E2=80=99 as an example to m= ake my point, but it was pointed out that the admin might circumvent the YA= NG-driven config engine completely and set the hostname via the UNIX comman= d line instead.=C2=A0 In this case, the intended hostname value might diffe= r from the operational hostname value.=C2=A0 Even for nodes where we=E2=80= =99re convinced there can never be an operational value that differs from t= he intended value, there still might be a propagation delay that causes a d= ifference to be perceived in time.=C2=A0 All this points to a rather conser= vative and thankfully simple solution that the value-set of opstate is the = combination of *all* the config true and config false nodes.



But the foo-state node = is being omitted from the module.
How does the pyang plugin know = how to produce the extra values so the
auto-generated foo-state n= ode has all the combined values?




> What is an "opstate-aware tree".

I should=E2=80=99ve written =E2=80=9Copstate-aware data model=E2=80=9D.

To be clear, by =E2=80=9Copstate-aware tree=E2=80=9D, I meant the YANG modu= le would only have a top-level /foo tree that has both config true and conf= ig false nodes, with the expectation that the solution provided by draft-ie= tf-netmod-revised-datastores enables 1) opstate for both system-genera= ted objects as well as for config true nodes and 2) opstate for all config = true nodes also (note: this doesn=E2=80=99t remove the need for explicit co= nfig false nodes for negotiated values like MTU).

Similarly, by =E2=80=9Copstate-unaware tree=E2=80=9D, I meant the YANG modu= le would have both top-level /foo and /foo-state trees.=C2=A0 Essentially, = what we have today, which we=E2=80=99re trying to get away from.


> The point of this work is that the opstate tree goes away and is repla= ced by
> a protocol operation instead.

Correct, the hope is that the top-level /foo-state tree no longer needs to = be defined in YANG modules.=C2=A0 This is the goal as we believe it will ma= ke YANG modules easier to read and write.


> In fact, there are no new datastores needed whatsoever to
> add the RPC <resource-ready>, or even <get-operational>.
I=E2=80=99m not sure what you mean by RPC <resource-ready>.=C2=A0 Tru= e, a <get-operational> RPC could be defined now, but we=E2=80=99d sti= ll want the YANG modules to be a certain way and we=E2=80=99d still want to= define a conceptual operational-state datastore so that we could describe = it unambiguously.



I could have an RPC tha= t tested a config subtree.
It would return 'true' if inte= nded=3Dapplied for that subtree.

=C2=A0
=
I agree it is good to have clear definitions that are widely= understood.
It would be nice to have any clear definition of con= fig=3Dfalse YANG nodes,
whether datastores are used or not. =C2= =A0(e.g., does operational state
include counters?)


Kent // as a contributor